Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Gcc 7.2
View unanswered posts
View posts from last 24 hours

Goto page 1, 2  Next  
Reply to topic    Gentoo Forums Forum Index Other Things Gentoo
View previous topic :: View next topic  
Author Message
Spargeltarzan
Guru
Guru


Joined: 23 Jul 2017
Posts: 317

PostPosted: Sun Dec 03, 2017 10:04 am    Post subject: Gcc 7.2 Reply with quote

Hi,

I am curious trying GCC 7.2. Is someone already experienced in it, how did it work? I saw some open bugs with gcc 7.2, but not from a package I have installed.

I would try compile a stable amd64 system with it.

Regards
Spargeltarzan
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 54097
Location: 56N 3W

PostPosted: Sun Dec 03, 2017 10:17 am    Post subject: Reply with quote

Spargeltarzan,

I've been using gcc-7.x since it hit the tree. Its mostly OK and getting better. A few things won't build.
You will need to check bugs.gentoo.org when that happens.
There are often patches you can add to the right place in /etc/portage/patches/

If you can handle the odd breakage, go ahead. Contributing to bug reports would be a bonus.
Its harmless to mix gcc-7 and gcc-6 code too, unlike gcc-4 and gcc-5 that have a different C++ ABI.

I have yet to see a package that builds with gcc-7.2 then fails at run time. Its been all build failures for me.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Spargeltarzan
Guru
Guru


Joined: 23 Jul 2017
Posts: 317

PostPosted: Sun Dec 03, 2017 10:29 am    Post subject: Reply with quote

Neddy,

Thank you, nice to hear! Yes, I created already an Account on bugs.gentoo.org, if I find something, I would communicate it. :)

Which optimization level are you using?

Quote:
Optimization GUIDE
-O3: the highest level of optimization possible. It enables optimizations that are expensive in terms of compile time and memory usage. Compiling with -O3 is not a guaranteed way to improve performance, and in fact, in many cases, can slow down a system due to larger binaries and increased memory usage. -O3 is also known to break several packages. Using -O3 is not recommended. However, it also enables -ftree-vectorize so that loops in the code get vectorized and will use AVX YMM registers.


When I read this, I would not try -O3, especially when it was observed it could slow down my system or packages - do you have experience on it, is it worth a try?
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 54097
Location: 56N 3W

PostPosted: Sun Dec 03, 2017 10:37 am    Post subject: Reply with quote

Spargeltarzan,

I use -O2 globally.

A few packages and makefiles force -O3 but I like to think that hey have been tested that way.
-O3 makes things bigger, may change the results of floating point arithmetic and uses more compile time than -O2.
It can also make things slower as the bigger code may not fit your CPU cache.

That's the infamous excess precision bug/feature of all Intel FPUs.

You can add individual -O3 features as you see fit, without adding the floating point arithmetic things.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Spargeltarzan
Guru
Guru


Joined: 23 Jul 2017
Posts: 317

PostPosted: Mon Dec 04, 2017 9:04 pm    Post subject: Reply with quote

NeddySeagoon,

I made two backups of my system and started to emerge with gcc 7.2.0 today :)

Code:

accept gcc-7.2.0
emerge -av 1gcc:7.2.0
set gcc-config for gcc-7.2.0
source /etc/profile

emerge -av1 sys-devel/libtool
emerge -1 sys-devel/gcc:7.2.0

emerge -av1 sys-devel/binutils
emerge -av1 sys-libs/glibc


Glibc was a bit a hassle, I needed 3 attempts to emerge it successfully. Segmentation fault. I rebootet and than it emerged (somehow the black-magic method to reboot helps sometimes :D) I have read once that segmentation faults are usually caused by hardware errors, I was myself struggling with it while emerging llvm some days ago. Do you have an idea if this is really the only root cause? Previously my system was close to overheat with 99 ° C but my temperature is now very good with a new heat paste (maximum 55 ° C while compiling) so I hoped I will be segmentation-fault free.

Currently emerging package 78 out of 1180. (emerge -eavb)

When I finished the second emerge of gcc:7.2.0 it stated "memory access error" or could be also "storage access error", in German "Speicherzugriffsfehler". I remember I had this issue only once on the machine but it was disappearing instantly again, so also today when I next emerged binutils.

Will keep you update when my emerge -e completed.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 54097
Location: 56N 3W

PostPosted: Mon Dec 04, 2017 9:25 pm    Post subject: Reply with quote

Spargeltarzan,

Segfaults fall into two groups.

Group one - the code is faulty, it really is trying ta access memory its not allowed to.
This code has never worked for anyone ever. The segfault is repeatable every time the code is run.

Group two - segfaults occur sometimes, for some people on some systems.
WIth faulty RAM, for example, sometimes the build will fail, other times the build will work - for the same package.
The kernel may not always allocate the faulty RAM.
This group also covers intermittent segfaults due to design margins being eroded by operating equipment outside of its specifications.
e.g. overrclocking, over temperature, undervolting.

So yes, random segfaults are usually hardware related.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Spargeltarzan
Guru
Guru


Joined: 23 Jul 2017
Posts: 317

PostPosted: Mon Dec 04, 2017 9:53 pm    Post subject: Reply with quote

I can confirm more segmentation faults occurring during my emerge -e. When I resume the emerge, the packages built in the second try. - Thank you for your very fast reply!

Great that I had the opportunity to realize I might have a hardware issue.

Since my CPU temperature is now okay and I didn't overclock my system, I will run Memtest86 to test my RAM.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 54097
Location: 56N 3W

PostPosted: Mon Dec 04, 2017 10:39 pm    Post subject: Reply with quote

Spargeltarzan,

If booting into memtest86+ says your RAM in good, it probably is.
If it finds problems, it may not be the RAM at all as memtest86 uses lots of other things to run too.

If you don't boot into it, it won't tell you anything useful.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Spargeltarzan
Guru
Guru


Joined: 23 Jul 2017
Posts: 317

PostPosted: Mon Dec 04, 2017 11:11 pm    Post subject: Reply with quote

I was booted into Passmark Memtest86 (Memtest86+ from Portage tree remains a black screen after selected in Grub, probably because it is not UEFI) and it found at least 3 errors (I aborted it ~ 80 %.)

I only saw now that these errors could be related to another issue beside RAM too. Didn't think about it, that's why I didn't note the name of the errors and aborted early.

I should re-run again and test with only one RAM piece too.

I guess it is not the most intelligent thing now to continue emerging my ~ 770 outstanding packages.
Back to top
View user's profile Send private message
Spargeltarzan
Guru
Guru


Joined: 23 Jul 2017
Posts: 317

PostPosted: Tue Dec 05, 2017 8:14 am    Post subject: Reply with quote

I removed one piece of RAM and the errors don't appear any more.
Back to top
View user's profile Send private message
ct85711
Veteran
Veteran


Joined: 27 Sep 2005
Posts: 1791

PostPosted: Tue Dec 05, 2017 8:24 am    Post subject: Reply with quote

So it may be that piece of ram is bad (or at least may contain the bad segments). One thing you should do to verify it is, by try swapping the stick of ram that is in the slot to verify that it is bad, or is it something else. I know I had recently one of my memory sticks go bad on my system, to the point that the system refuses to do POST with that stick in. Without that stick, the system has been rock stable once again (sad as that stick of ram used to work fine in that system for a while, until it gave up).
Back to top
View user's profile Send private message
Maitreya
Guru
Guru


Joined: 11 Jan 2006
Posts: 441

PostPosted: Tue Dec 05, 2017 8:28 am    Post subject: Reply with quote

You can map around this in grub to avoid loosing a bank :)
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 54097
Location: 56N 3W

PostPosted: Tue Dec 05, 2017 9:25 am    Post subject: Reply with quote

Spargeltarzan,

Look at the contacts on the RAM stick and on the socket you removed it from. They should be the same colour, either both gold or both silver.
If you have a mix, bimetallic contact problems arise. It works for about 18 months, then for another 18 months after its clean up and so on ...

Often 'wiping' the contacts by removing and refitting the RAM clears the problems.
The disturbance reduces the contract resistance for a while.

Its telling if you have a 'hard' fault or random faults.
If the same errors occur at the same address with the same bit pattern every pass, its likely the RAM is actually faulty.
If errors do not repeat, the RAM cells may be good. Look to contact resistance, power supply, (the on the motherboard Vram) and other things.

As Maitreya says, there was/is a kernel badram patch. It might still apply.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Spargeltarzan
Guru
Guru


Joined: 23 Jul 2017
Posts: 317

PostPosted: Tue Dec 05, 2017 1:24 pm    Post subject: Reply with quote

Thank you all for great support!

My errors appear to be quite random - I tried cleaning and used the bad RAM stick in another bank, only one error appeared again (failed test 8 ) - before test 7 & 8 failed reproduce-able

Cleaned both RAM sticks - use them in different order - suddenly test 3 fails, what has never failed, and test 7 & 8 was successful.

I will now try to test the good RAM in both banks and ensure this RAM and slots are good.

Maybe my slots need better cleaning?
Back to top
View user's profile Send private message
Naib
Watchman
Watchman


Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy

PostPosted: Tue Dec 05, 2017 1:37 pm    Post subject: Reply with quote

NeddySeagoon wrote:
Spargeltarzan,

I use -O2 globally.

A few packages and makefiles force -O3 but I like to think that hey have been tested that way.
-O3 makes things bigger, may change the results of floating point arithmetic and uses more compile time than -O2.
It can also make things slower as the bigger code may not fit your CPU cache.

That's the infamous excess precision bug/feature of all Intel FPUs.

You can add individual -O3 features as you see fit, without adding the floating point arithmetic things.
yikes! I use -02 partially because of the stack concern but this side effect I wasn't aware of.
This is of additional concern because mathworks started officially support GCC as a compiler and the "performance" option defaults to -03 ( they at least disable unrolling loops...) but damn! I have been in discussions with mathworks and they don't accept the stack stomping, they might accept this one so their default is -02 instead


-O3 -fno-loop-optimizer -fno-agressive-loop-optimization
_________________
Quote:
Removed by Chiitoo
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 54097
Location: 56N 3W

PostPosted: Tue Dec 05, 2017 2:21 pm    Post subject: Reply with quote

Naib,

Its the Intel "Excess Precision" bug that has been with us since the 8087 was a gleam in Intels eye.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Maitreya
Guru
Guru


Joined: 11 Jan 2006
Posts: 441

PostPosted: Tue Dec 05, 2017 5:34 pm    Post subject: Reply with quote

Spargeltarzan wrote:
Thank you all for great support!

My errors appear to be quite random - I tried cleaning and used the bad RAM stick in another bank, only one error appeared again (failed test 8 ) - before test 7 & 8 failed reproduce-able

Cleaned both RAM sticks - use them in different order - suddenly test 3 fails, what has never failed, and test 7 & 8 was successful.

I will now try to test the good RAM in both banks and ensure this RAM and slots are good.

Maybe my slots need better cleaning?

Please don't go and try putting anything (brushes) in those slots as you will need a very keen eye to pull any hairs (etc) out blocking contact.
Compressed air seems quite safe there.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 54097
Location: 56N 3W

PostPosted: Tue Dec 05, 2017 5:44 pm    Post subject: Reply with quote

Spargeltarzan,

Slot cleaning usually consists of removing and refitting the RAM stick a maximum of three times.
This 'wipes' the contacts on the slot and RAM stick.

Brushes, fluids and even compressed air do more harm than good.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
CaptainBlood
Advocate
Advocate


Joined: 24 Jan 2010
Posts: 3561

PostPosted: Tue Dec 05, 2017 6:17 pm    Post subject: Reply with quote

~ 2000 packages, all gcc 7.2, -O2, latest binutils & glibc.
Maybe 3 unsuccessful : codeblocks, meshlab & &k3d.

gold linker, graphite & lto by default.

Beware that among the 2000 packages some required DIY patches to build. So some patching skills may be required, i.e EAPI user_patch & local repository managements; code patching bits being googled.

glibc 2.26 being the only unsafe part, IMHO.

intel ivybridge here.

Thks 4 ur attention , interest & support.
Back to top
View user's profile Send private message
Spargeltarzan
Guru
Guru


Joined: 23 Jul 2017
Posts: 317

PostPosted: Tue Dec 05, 2017 10:52 pm    Post subject: Reply with quote

For the moment my RAM errors disappeared

I did the "put in cleaning" several times - the suspicious good and the suspicious bad RAM was both good in both slots, single tested. (4 tests total)

My RAM is 1866Mhz RAM, after the good results I still switched to 1333 Mhz (to be on the safe side) with XMP activated and performed another Memtest with the dual channel RAMs - no errors, only a note that my "RAM may be vulnerable to high frequency row hammer bit flips". - is acting needed to reduce this risk? (but I actually underclocked already...)

I read that setting the frequency in XMP will force the frequency, and it cannot go lower too - but I didn't saw an "Auto" or "Max frequency" for this field. I could switch off XMP and change to AUTO - I don't know if XMP is used only for overclocking (what I am not interested in) or it makes also some other good settings. - Probably some of you know what is best practice here?

I resumed now my emerge -e and hope my memory issues are away :) I am actually still surprised, because in my first test I changed already the position of the RAM, but it seems that only now it is "clean enough" - thanks for this great information!
Back to top
View user's profile Send private message
Spargeltarzan
Guru
Guru


Joined: 23 Jul 2017
Posts: 317

PostPosted: Wed Dec 06, 2017 5:59 pm    Post subject: Reply with quote

Hi,

Still not sure if RAM is okay, I have got segmentation faults when compiling llvm (again)

3 packages didn't compile on GCC 7.2 with emerge -e

-) llvm
-) xen-tools
-) libreoffice

I don't find open bugs for it. Did someone compile it already on gcc-7.2?


-) xen-tools:
VfrUtilityLib.cpp:3287:26: error: ISO C++ forbids comparison between pointer and integer [-fpermissive]
if (mStringFileName == '\0' ) {

log:
fprintf(stderr, ^[[01;35m^[[K"^[[m^[[Kset_new: Cannot allocate set with max of %d\n", _max); \
^[[01;35m^[[K^^[[m^[[K
^[[01m^[[K../support/set/set.h:58:25:^[[m^[[K ^[[01;36m^[[Knote: ^[[m^[[Kin definition of macro ‘^[[01m^[[Kset_new^[[m^[[K’
fprintf(stderr, ^[[01;36m^[[K"set_new: Cannot allocate set with max of %d\n"^[[m^[[K, _max); \
^[[01;36m^[[K^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^[[m^[[K

Will check for llvm & libreoffice again. It seems to fail different every time.
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6747

PostPosted: Wed Dec 06, 2017 6:28 pm    Post subject: Reply with quote

Spargeltarzan wrote:
3 packages didn't compile on GCC 7.2 with emerge -e

-) llvm
-) xen-tools
-) libreoffice

llvm and libreoffice should compile fine with gcc-7.2. For xen-tools, I don't know.

I also had a machine which failed compilation at random places. It helped a lot to use ccache. (Of course, this is only a workaround, not a real solution...)

Another idea: Do you perhaps use zram and/or zswap?
If you are running out of ram, these things might perhaps cause problems. I suspect that my problems on mentioned machine were due to this...
Back to top
View user's profile Send private message
Spargeltarzan
Guru
Guru


Joined: 23 Jul 2017
Posts: 317

PostPosted: Wed Dec 06, 2017 8:12 pm    Post subject: Reply with quote

mv,

I don't use zram or zswap. I have 8GB Ram and a normal swap file enabled.

-) Log files llvm-3.9.1-r1:
Code:

[ebuild   R   ] sys-devel/llvm-3.9.1-r1  USE="clang libffi ncurses sanitize static-analyzer xml -debug -default-compiler-rt -default-libcxx -doc -gold -libedit (-lldb) -multitarget -ocaml -python {-test}" ABI_X86="32 (64) (-x32)" LLVM_TARGETS="AMDGPU BPF NVPTX (X86) -AArch64 -ARM -Hexagon -MSP430 -Mips -PowerPC -Sparc -SystemZ -XCore" PYTHON_TARGETS="python2_7"

segmentation fault ---- ninja: build stopped: subcommand failed.
https://paste.pound-python.org/show/ZRFTxHhYkAAPlNoaOsLA/
https://paste.pound-python.org/show/9EYoVp8VKTqJwx9SBf4g/


-) Log files Libreoffice 5.4.2.2
Code:

[ebuild   R   ] app-office/libreoffice-5.4.2.2  USE="bluetooth branding collada cups dbus eds gltf gnome gstreamer gtk gtk3 pdfimport vlc (-coinmp) -debug (-firebird) -googledrive -java -jemalloc -kde -libressl -mysql -odk -postgres -quickstarter {-test}" LIBREOFFICE_EXTENSIONS="-nlpsolver -scripting-beanshell -scripting-javascript -wiki-publisher" PYTHON_SINGLE_TARGET="python3_5 -python2_7 -python3_4 (-python3_6)" PYTHON_TARGETS="python2_7 python3_5 -python3_4 (-python3_6)"


https://paste.pound-python.org/show/zuidwwIFlQymXCfuVdQX/
https://paste.pound-python.org/show/le0555MU8J3btz6f5UAL/

/usr/include/unistd.h:277:21: internal compiler error: Segmentation fault
typedef __socklen_t socklen_t;
No Error Message

ADD: I planned to try xen-tools 4.9, but it depends on linux 4.13 what I do not want to install at the moment
Back to top
View user's profile Send private message
Spargeltarzan
Guru
Guru


Joined: 23 Jul 2017
Posts: 317

PostPosted: Thu Dec 07, 2017 11:34 am    Post subject: Reply with quote

Call me paranoid, but after my RAM troubles I made again (3rd time) a new approach to rebuild my whole system (libtool, gcc, binutils, glibc, emerge -e). In the first run 8 packages failed (including llvm, webkit-gtk and xen-tools, but libreoffice emerged successfully). In my second attempt to oneshot/re-emerge the 8 failed packages, 7 (with the exception of xen-tools) emerged. So now I have got llvm, webkit-gtk, libreoffice, etc. all working)

Since I don't have that much experience in Gentoo yet, is it common that in emerge -e some packages will emerge only in the second try? (I believe emerge -e should resolve dependencies right - therefore for me especially the fact that mostly bigger packages fail to build make me believe I still suffer from a hardware issue)

ADD: I opened a bug report for xen-tools, this might have something todo with gcc-7.2 , Bug 640162

ADD: Is there a command to show the compiler version of every emerged package?[/url]
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6747

PostPosted: Thu Dec 07, 2017 7:57 pm    Post subject: Reply with quote

Spargeltarzan wrote:
Is it common that in emerge -e some packages will emerge only in the second try?

No. This should be very exceptional.
But since you mention failures on different places it looks like a hardware problem.
Or it might be a kernel bug. (On my machine the problem had eventually vanished with some new kernel version.)
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Other Things Gentoo All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum