Was looking at a bug report and notice in env.log the presence of downgrade_arch_flags () { local arch bver i isa myarch mytune rep ver; bver=${1:-${GCC_BRANCH_VER}}; [[ $(gcc-version) < ${bver} ]] && return 0; [[ $(tc-arch) != amd64 && $(tc-arch) != x86 ]] && return 0; myarch=$(get-flag march); mytune=$(get-flag mtune); if [[ ${myarch} == native || ${mytune} == native ]]; then if [[ ${bver} < 4.2 ]]; then arch=$($(tc-getCC) -march=native -v -E -P - </dev/null 2>&1 | sed -rn "/cc1.*-march/s:.*-march=([^ ']*).*:\1:p"); replace-cpu-flags native ${arch}; fi; I'm not expert but to me it looks like this test is trying to do something weird: - It check if gcc is < 4.2 and if so, it try to replace -march=native with the proper -march to use for the cpu. Well, it look sane, if someone try to use native with a gcc that doesn't handle native, replacing it with a valid atom will help user. The problem is that on gcc versions that doesn't handle native, it will not gives anyone the cpu to use, but the error gcc cannot create executable. Only a gcc that handle native can be use to output the real cpu atom to use for march. So basically that test doesn't work. - It should be fix to throw an error telling user to not use native with a gcc version that doesn't handle it - It could also be fix to swap the native for gcc < 4.2 with the generic flag, so a "replace-cpu-flags native generic" or something like that Reproducible: Always Actual Results: Sorry as i don't know what eclass generate that result. But certainly some toolchain eclass. State as minor as it only affect user using native with a gcc version that doesn't handle it, something that should be hard to find (a user using a gcc < 4.2 certainly isn't doing that for nothing and certainly also have the knowledge to not use native in that case).
Seriously guys, even if anyone consider this one as tiny or comestic, that's a bug in toolchain. For gentoo, no other package is more important than toolchain, as such it should get some kind of priority in anyone eyes.
(In reply to nobody from comment #1) > Seriously guys, even if anyone consider this one as tiny or comestic, that's > a bug in toolchain. > For gentoo, no other package is more important than toolchain, as such it > should get some kind of priority in anyone eyes. Hi man, your bug report is much appreciated. I agree with your suggestions. The problem now we are facing is that toolchain herd is understaffed.
(In reply to nobody from comment #0) > Was looking at a bug report and notice in env.log the presence of > downgrade_arch_flags () > { > local arch bver i isa myarch mytune rep ver; > bver=${1:-${GCC_BRANCH_VER}}; > [[ $(gcc-version) < ${bver} ]] && return 0; > [[ $(tc-arch) != amd64 && $(tc-arch) != x86 ]] && return 0; > myarch=$(get-flag march); > mytune=$(get-flag mtune); > if [[ ${myarch} == native || ${mytune} == native ]]; then > if [[ ${bver} < 4.2 ]]; then > arch=$($(tc-getCC) -march=native -v -E -P - </dev/null 2>&1 > | sed -rn "/cc1.*-march/s:.*-march=([^ ']*).*:\1:p"); > replace-cpu-flags native ${arch}; > fi; > > > I'm not expert but to me it looks like this test is trying to do something > weird: > - It check if gcc is < 4.2 and if so, it try to replace -march=native with > the proper -march to use for the cpu. > Well, it look sane, if someone try to use native with a gcc that doesn't > handle native, replacing it with a valid atom will help user. > The problem is that on gcc versions that doesn't handle native, it will not > gives anyone the cpu to use, but the error gcc cannot create executable. > Only a gcc that handle native can be use to output the real cpu atom to use > for march. If you are using a GCC that doesn't support native, you won't have native in your flags, and this whole check is skipped. > So basically that test doesn't work. Sure it does.
(In reply to Ryan Hill from comment #3) > (In reply to nobody from comment #0) > > Was looking at a bug report and notice in env.log the presence of > > downgrade_arch_flags () > > { > > local arch bver i isa myarch mytune rep ver; > > bver=${1:-${GCC_BRANCH_VER}}; > > [[ $(gcc-version) < ${bver} ]] && return 0; > > [[ $(tc-arch) != amd64 && $(tc-arch) != x86 ]] && return 0; > > myarch=$(get-flag march); > > mytune=$(get-flag mtune); > > if [[ ${myarch} == native || ${mytune} == native ]]; then > > if [[ ${bver} < 4.2 ]]; then > > arch=$($(tc-getCC) -march=native -v -E -P - </dev/null 2>&1 > > | sed -rn "/cc1.*-march/s:.*-march=([^ ']*).*:\1:p"); > > replace-cpu-flags native ${arch}; > > fi; > > > > > > I'm not expert but to me it looks like this test is trying to do something > > weird: > > - It check if gcc is < 4.2 and if so, it try to replace -march=native with > > the proper -march to use for the cpu. > > Well, it look sane, if someone try to use native with a gcc that doesn't > > handle native, replacing it with a valid atom will help user. > > The problem is that on gcc versions that doesn't handle native, it will not > > gives anyone the cpu to use, but the error gcc cannot create executable. > > Only a gcc that handle native can be use to output the real cpu atom to use > > for march. > > If you are using a GCC that doesn't support native, you won't have native in > your flags, and this whole check is skipped. > > > So basically that test doesn't work. > > Sure it does. I couldn't make sense of the original report so I tested everything from 4.5 and below (except 2.95) on amd64 and mips and the test always worked. I was going to ask for an actual case of failure, but I think Ryan is basically right here.
(In reply to Ryan Hill from comment #3) > > If you are using a GCC that doesn't support native, you won't have native in > your flags, and this whole check is skipped. > > > So basically that test doesn't work. > > Sure it does. If you look at my comment on Actual Result, you would have seen i already saw this corner case is a corner case, as you might expect anyone using a gcc that doesn't handle native to not use native with it. But this code is for people doing that, using native with a gcc that doesn't handle it. It seems easy to test : use native in your cflags with a gcc below 4.2 and see the result. That's something i couldn't do myself as i don't have any gcc version that match that. It might even works, if another function clean out the native prior to reaching that part for user with a gcc that doesn't handle it. Making the whole code useless or just because i read it bad and it actually do what it is suppose to do. It might also works if that test is done while user is switching from a gcc version to another. Marking this invalid because you didn't trigger the code because it is stupid to use native with a gcc that doesn't handle it ; is not that nice. So if like i think this code try do that : 1- gcc < 4.2 2- cflags with march=native present 3- run gcc with -march=native and see what cpu atom you get as result 4- swap native with the cpu atom founded So the point is that part 3 cannot work because only a gcc that handle native will answer to it.
(In reply to Anthony Basile from comment #4) > I couldn't make sense of the original report so I tested everything from 4.5 > and below (except 2.95) on amd64 and mips and the test always worked. I was > going to ask for an actual case of failure, but I think Ryan is basically > right here. > and mips and the test always worked --> [[ $(tc-arch) != amd64 && $(tc-arch) != x86 ]] && return 0; M. Basile :(
(In reply to nobody from comment #6) > (In reply to Anthony Basile from comment #4) > > I couldn't make sense of the original report so I tested everything from 4.5 > > and below (except 2.95) on amd64 and mips and the test always worked. I was > > going to ask for an actual case of failure, but I think Ryan is basically > > right here. > > > > and mips and the test always worked > --> [[ $(tc-arch) != amd64 && $(tc-arch) != x86 ]] && return 0; > M. Basile :( Yes, I know. I tested it in place in the eclass. That's why I did mips as well. I just automated.
(In reply to nobody from comment #5) > (In reply to Ryan Hill from comment #3) > > > > If you are using a GCC that doesn't support native, you won't have native in > > your flags, and this whole check is skipped. > > > > > So basically that test doesn't work. > > > > Sure it does. > > If you look at my comment on Actual Result, you would have seen i already > saw this corner case is a corner case, as you might expect anyone using a > gcc that doesn't handle native to not use native with it. > Please give me steps to reproduce including your emerge -info so I know what arch you are on. @Ryan. I'll close this again either when its fixed or INVALID.
Created attachment 391828 [details] emerge info
Here's my emerge --info that's not revelant to this bug, as i already said, i don't have a gcc to test this one ; so my "understanding" of the code i see let me think the code is doing something odd and so there's a bug there as the code is not doing what the code was made for. The problem is that a gcc handling native could be query to get the expect real cpu atom to use, as a sample With a gcc that handle -march=native the query gcc -march=native -v -E -P - will answer on my cpu : Using built-in specs. ... COLLECT_GCC_OPTIONS='-march=native' '-v' '-E' '-P' /usr/libexec/gcc/i686-pc-linux-gnu/4.7.4/cc1 -E -quiet -v -P - -march=corei7 -mcx16 -msahf -mno-movbe -mno-aes -mno-pclmul -mpopcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mno-avx -mno-avx2 -msse4.2 -msse4.1 -mno-lzcnt -mno-rdrnd -mno-f16c -mno-fsgsbase --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=8192 -mtune=corei7 ... So you basically get the info that instead of native that cpu should be use with -march=corei7 The real problem is : if your gcc doesn't handle native, the result of gcc -march=native -v -E -P - will not gave you that, but a message telling you there's a problem with your cflags (or similar, like the C processor cannot compile kindof). Another problem swapping native with corei7 is a valid value for that gcc, but anyone knows corei7 is not a valid value for a gcc 4.2 (ok i'm unsure where the corei7 atom was add to gcc, but by memory i think i was using core2duo until something like gcc 4.5) So the expect swapping native with the good cpu atom can only be done if your gcc do handle native AND the atom given is support by the "old" gcc So that code is made to help people that forget they have native in cflags and swap it with the detect good cpu atom to help them ; but it fail. TBH i really fail to see what is hard to understand there, i could of course accept my interpretation of that code is totally wrong, but i really fail to see why nobody see where i see a problem in that code.
So step to reproduce would be as easy as that: - Use a gcc 4.2 or less and tell us what gcc output when you run it with -march=native (an error message but certainly not the info you expect to catch -march=corei7 for me or the march of the cpu you use for you) - Use a gcc 4.7+ or any and you will see that it will gives you the correct corei7 march to use intead of native, but in real it won't fix the issue, as march=corei7 is also not a valid atom for a gcc 4.2
(In reply to nobody from comment #10) > Here's my emerge --info that's not revelant to this bug, as i already said, > i don't have a gcc to test this one ; I have access to many non amd64/x86 hardware. Give me a test case you want me to test. > > The real problem is : if your gcc doesn't handle native, the result of gcc > -march=native -v -E -P - will not gave you that, but a message telling you > there's a problem with your cflags (or similar, like the C processor cannot > compile kindof). Can you point to a gcc that doesn't handle native. I don't know of any. I tested. I'm not going to act on this unless I see it fail. There is no reason why I can't produce a situation where it should fail.
(In reply to nobody from comment #11) > So step to reproduce would be as easy as that: > > - Use a gcc 4.2 or less and tell us what gcc output when you run it with > -march=native (an error message but certainly not the info you expect to > catch -march=corei7 for me or the march of the cpu you use for you) > > - Use a gcc 4.7+ or any and you will see that it will gives you the correct > corei7 march to use intead of native, but in real it won't fix the issue, as > march=corei7 is also not a valid atom for a gcc 4.2 I'm confused corei7 is amd64.
corei7 is not an arch it's a cpu familly, corei7 can do 64 or 32bits just like core2 or many other cpu. i don't know the gcc version that introduce -march=native, so i will basically "trust" a bit the code ; the code is looking to fix the problem with native when using a gcc < 4.2 : so i assume -march-native was add in gcc 4.2. So the answer would be "a gcc that doesn't handle native would be one prior to 4.2" And a real test case would be what is the result of: gcc -march=native -v -E -P - < /dev/null on a gcc that handle native you get the result -march=whatever_cpu_atom_gcc_has detect. on a gcc that doesn't know native, you get an error but in no way the detected cpu.
(In reply to nobody from comment #14) > corei7 is not an arch it's a cpu familly, corei7 can do 64 or 32bits just > like core2 or many other cpu. FYI, https://gcc.gnu.org/gcc-4.9/changes.html > Optimizing for other Intel microarchitectures have been renamed to -march=nehalem, westmere, sandybridge, ivybridge, haswell, bonnell. Before gcc-4.9 they are called corei7, corei7-avx, etc.
(In reply to nobody from comment #14) > corei7 is not an arch it's a cpu familly, corei7 can do 64 or 32bits just > like core2 or many other cpu. Yes but any arch running on corei7 is excluded by [[ $(tc-arch) != amd64 && $(tc-arch) != x86 ]] && return 0; > > i don't know the gcc version that introduce -march=native, so i will > basically "trust" a bit the code ; the code is looking to fix the problem > with native when using a gcc < 4.2 : so i assume -march-native was add in > gcc 4.2. So the answer would be "a gcc that doesn't handle native would be > one prior to 4.2" > > And a real test case would be what is the result of: > gcc -march=native -v -E -P - < /dev/null I tested this on all versions bug 2.95. It works. You are making too many false assumptions about how things work without testing. > on a gcc that doesn't know native, you get an error but in no way the > detected cpu. What gcc version woud this be?
You are lost, but really deeply lost in space :) Look : THIS is the REAL result of the FULL command use in the script so you might this time get what the command is trying to get from checking gcc output using the native as atom. That gcc is just the one i have in my emerge --info using the cpu from my emerge --info (so a corei7 running a gcc 4.7.4, so one that knows and answer to native) gcc -march=native -v -E -P - < /dev/null 2>&1 | sed -rn "/cc1.*-march/s:.*-march=([^ ']*).*:\1:p" >corei7 again same command but this time i gives gcc an unknown atom (something that a gcc that doesn't know native atom should also react in the same way) gcc -march=bug_atom -v -E -P - < /dev/null 2>&1 | sed -rn "/cc1.*-march/s:.*-march=([^ ']*).*:\1:p" >bug_atom So you can see, you don't get the thing you expect, instead of getting corei7 you get the same atom given, so when you run this line of code on a gcc that doesn't handle native, you should get back "native" as return value. And replacing "native" with founded result "native" will of course not do what the code is trying to do. So even this code exist and this check exist to help user not getting "C compiler cannot create executable" result because he try to use "native" in his cflags with a gcc that doesn't know what "native" is ; because of the bad check the whole code will never gives the expected result. My suggestion then is simple : do not swap "native" with "founded result" of a gcc check using native that it cannot understand. Instead when a gcc < 4.2 is found AND user have "native" in his cflags, that code should replace "native" with "generic", so the code will do what it was trying to do ; as user will have its cflags replace from a CFLAGS="-march=native" with a CFLAGS="-march=generic" an atom any gcc understand. I think the whole part you are kept missing is the check to get the atom is done using "native" and the problem is that check can only works with a gcc that do understand that "native" atom. And that code is done only to help user with a gcc that do not understand it. It's a chicken/egg problem. Now ok i really have no gcc < 4.2 to test the real result ; but as i'm mostly confident nobody update any gcc that are that old to add support for the native atom in them ; i "maybe wrongly" assume a gcc < 4.2 will not return the result the code author expect. My confidence is just backup because if anyone has add the "native" atom in a gcc < 4.2 that wasn't understanding it ; that whole code is useless, you don't need to change user cflags as the atom is understand and will works.
Created attachment 391852 [details] a gcc run knowing native atom look specially at line /usr/libexec/gcc/i686-pc-linux-gnu/4.7.4/cc1 you will see gcc gives you the atom to use there.
Created attachment 391854 [details] a gcc output when facing an unknown atom again look at /usr/libexec/gcc/i686-pc-linux-gnu/4.7.4/cc1 result
(In reply to Anthony Basile from comment #16) > (In reply to nobody from comment #14) > > corei7 is not an arch it's a cpu familly, corei7 can do 64 or 32bits just > > like core2 or many other cpu. > > Yes but any arch running on corei7 is excluded by > [[ $(tc-arch) != amd64 && $(tc-arch) != x86 ]] && return 0; > This is not how i understand this line of code. I'm not bash expert, but i think bash do like other language and test like "if true && true" will just be endup if first test is not true and everything next the && will not be even look at. So if tc-arch == amd64 the test end and return 0 will never be run if tc-arch == x86 the test end again To me this line exclude any arch except amd64 or x86. As i don't know other arch a corei7 could be run with ; this line for me is the total contrary of what you said : "All arch running on a corei7 are included with". That's why i :( when you said you tried it on mips, that line should kick out mips arch from running that code. Do i suck that bad at bash?
(In reply to nobody from comment #20) > Do i suck that bad at bash? No, you are correct, I read the code too quickly. Here's the results of my test leading me to the conclusion that that line of code works: fuschia ~ # gcc-config -l [1] x86_64-pc-linux-gnu-3.3.6 [2] x86_64-pc-linux-gnu-3.4.6 [3] x86_64-pc-linux-gnu-4.0.4 [4] x86_64-pc-linux-gnu-4.1.2 [5] x86_64-pc-linux-gnu-4.2.4 [6] x86_64-pc-linux-gnu-4.3.6 [7] x86_64-pc-linux-gnu-4.4.7 [8] x86_64-pc-linux-gnu-4.5.4 [9] x86_64-pc-linux-gnu-4.6.4 [10] x86_64-pc-linux-gnu-4.7.3 [11] x86_64-pc-linux-gnu-4.8.3 * fuschia ~ # for i in $(gcc-config -l | awk '{ print $2 }') ; do > gcc-config $i >/dev/null 2>&1 ; source /etc/profile > echo $i > gcc -march=native -v -E -P - </dev/null 2>&1 | sed -rn "/cc1.*-march/s:.*-march=([^ ']*).*:\1:p" > echo done x86_64-pc-linux-gnu-3.3.6 native x86_64-pc-linux-gnu-3.4.6 native x86_64-pc-linux-gnu-4.0.4 native x86_64-pc-linux-gnu-4.1.2 native x86_64-pc-linux-gnu-4.2.4 nocona x86_64-pc-linux-gnu-4.3.6 core2 x86_64-pc-linux-gnu-4.4.7 core2 x86_64-pc-linux-gnu-4.5.4 core2 x86_64-pc-linux-gnu-4.6.4 corei7 x86_64-pc-linux-gnu-4.7.3 corei7 x86_64-pc-linux-gnu-4.8.3 corei7
Thank you for the gcc version output given. But how can you confirm this works when i clearly see it confirm i'm right and this doesn't works? Remember the idea behind the code: remove "native" and change it to cpu atom so gcc will works. let's takes your x86_64-pc-linux-gnu-4.2.4 output as example: it output nocona what happen in real is: gcc < 4.2 -> no so the code is useless and nothing is done (let's assume we remove the <4.2 check to actually make the code working) arch = "nocona" is the result we get. CFLAGS="-march=native" becomes CFLAGS="-march=nocona" Now let look at the result with x86_64-pc-linux-gnu-4.1.2 arch = "native" (!!!) CFLAGS="-march=native" becomes CFLAGS="-march=native" (!!!) Can't you see the problem? Your cpu detection gave you back "native" and you were trying to remove native to fix the cflags because that gcc version doesn't handle native. Why it do that? Because to detect the cpu atom, you must run gcc with native, and doing that on a gcc that doesn't handle native is not doable.
This is funny, i really enjoy this bug :) It might be because i'm just wrong from what i think this code is aiming to do, or just because my English understanding and expression are wrong and people clearly fail to see what i'm speaking about ; but all in all, it really makes me smile as this lead to this. What i was thinking was a really simple to see problem to fix a little code that is almost unused (don't know who forget he have cflags with native set and try to run a gcc without native support) becomes that ; with me pointing the moon and saying "look at the moon" and anyone looking at my finger and answering "there's no problem with your finger" :)
(In reply to nobody from comment #5) > (In reply to Ryan Hill from comment #3) > > > > If you are using a GCC that doesn't support native, you won't have native in > > your flags, and this whole check is skipped. > > > > > So basically that test doesn't work. > > > > Sure it does. > > If you look at my comment on Actual Result, you would have seen i already > saw this corner case is a corner case, as you might expect anyone using a > gcc that doesn't handle native to not use native with it. > > But this code is for people doing that, using native with a gcc that doesn't > handle it. Well, no, it's not. The point of this code is to automatically substitute flags that the version of GCC you're using understands but the version you're bootstrapping does not. You can't put flags the current compiler doesn't understand into your CFLAGS and expect anything to work. But in this case I'll just point out that we do call strip-unsupported-flags which will strip -march=native on a compiler that doesn't support it, meaning all this is moot. > My suggestion then is simple : do not swap "native" with "founded result" of > a gcc check using native that it cannot understand. Instead when a gcc < 4.2 > is found AND user have "native" in his cflags, that code should replace > "native" with "generic", so the code will do what it was trying to do ; as > user will have its cflags replace from a CFLAGS="-march=native" with a > CFLAGS="-march=generic" an atom any gcc understand. There is no such thing as "-march=generic". I know what you mean though. But really, to encounter what you're talking about you'd need to be running < 4.2 as your system compiler (unsupported), building a version of GCC prior to that, and using flags that break everything. Somehow I don't think we care to complicate the code further to handle cases that absolutely no one will ever hit. Just to confirm, tc-arch gives you the portage arch (ie. keyword). It has nothing to do with compiler flags. The check makes it only run on amd64 and x86 profiles and exists simply because I don't know what flags are the equivalents of others for other archs. :p
(In reply to Ryan Hill from comment #24) > (In reply to nobody from comment #5) > > But this code is for people doing that, using native with a gcc that doesn't > > handle it. > > Well, no, it's not. The point of this code is to automatically substitute > flags that the version of GCC you're using understands but the version > you're bootstrapping does not. You can't put flags the current compiler > doesn't understand into your CFLAGS and expect anything to work. But in > this case I'll just point out that we do call strip-unsupported-flags which > will strip -march=native on a compiler that doesn't support it, meaning all > this is moot. I disagree with you there, this code clearly look to grab the output of the cpu atom found when running gcc with native to replace native in cflags with the founded cpu. This code then isn't to filter any cflags but only aiming at "native" one AND only for some gcc version (all < 4.2, and Comment 21 tests from M. Basile shown clearly why, all these version doesn't handle native atom). I really have no doubt the aiming of the script, the conclusion of that aiming appears clear for me: remove native from cflags when gcc doesn't handle native and replace it. I agree that i have just saw this code part from an environement.log of a user, so i don't know where this code and even if this code is trigger somewhere. - if this code is never trigger, removing it won't kill anyone, as it is bad, it doesn't do what it is suppose to do. - if this code comes after another one that remove native from cflags already (i suppose strip-unsupported-flags could do that), then this code do nothing, as nobody could reach it while still having native in his cflags. > There is no such thing as "-march=generic". I know what you mean though. https://gcc.gnu.org/onlinedocs/gcc-4.7.4/gcc/i386-and-x86-64-Options.html#i386-and-x86-64-Options -mtune=cpu-type Tune to cpu-type everything applicable about the generated code, except for the ABI and the set of available instructions. The choices for cpu-type are: generic Produce code optimized for the most common IA32/AMD64/EM64T processors. ... -march=cpu-type Generate instructions for the machine type cpu-type. The choices for cpu-type are the same as for -mtune. Moreover, specifying -march=cpu-type implies -mtune=cpu-type. ... However i have check (guys, i know i'm bugging you, but that's not my goal there) gcc https://gcc.gnu.org/onlinedocs/gcc-3.4.6/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options and in that version "generic" atom doesn't exist. So my suggestion to replace it with "generic" was bad (sorry really should have check it first). > > But really, to encounter what you're talking about you'd need to be running > < 4.2 as your system compiler (unsupported), building a version of GCC prior > to that, and using flags that break everything. Somehow I don't think we > care to complicate the code further to handle cases that absolutely no one > will ever hit. > I totally agree ; why someone has made this code appears really a mistery, it might have been create earlier when gcc with native appears and it was still common that users switch from one gcc handling native to another one not handling native. To me this code was made only to be really, but really kind with user by trying to fix an error made by user. But even the intention was nice, that code has never done what the author was trying to get. Hopefully this code just do nothing, as swapping "native" with "native" doesn't introduce bug, it just fail at its aim but at least doesn't do anything bad. But even doing nothing, a code that is suppose to do something and is not doing it ; is a bug for me.
(In reply to Ryan Hill from comment #24) > Well, no, it's not. The point of this code is to automatically substitute > flags that the version of GCC you're using understands but the version > you're bootstrapping does not. Sorry, reading my own comment, i totally get over the context of bootstrapping. However this is still bad code. (still base on gcc output given by M. Basile on Comment 21), you can see the concept is still broken. If you use a gcc 4.7 to bootstrap a 4.9 you don't have to clear out native from cflags, 4.9 still handle "native", so it won't bug out with it. While it is dangerous to replace it with the right cpu atom, the 4.7.3 output result in "corei7", and Banda Xu comment 15 shown us corei7 is remove in favor or more specific nehalem... So replacing native with corei7 will not works as 4.9 drop it ; while in this case keeping native would had do the job. It's even worst when boostrapping a lower gcc version: if M. Basile use its gcc 4.7.3 to boostrap a gcc 4.5.4 ; the native will be place with "corei7", and you can see by 4.5.4 output that this gcc when use with native answer "core2", so "corei7" isn't handle by the 4.5.4. In this case, replacing native with corei7 will bug out as your 4.5.4 doesn't handle it. This to prove, even if that code is to boostrap another gcc, this code is too weak, as gcc atom are add or remove between version. But as this code aim only gcc < 4.2 i don't think this code was a bootstrapping helper like you said ; or only to boostrap a < 4.2 that i think i already shown was badly made anyway.
(In reply to Anthony Basile from comment #12) > Can you point to a gcc that doesn't handle native. I don't know of any. I Rereading this bug I realize this is incorrect. gcc < 4.2 -march=natvie fails: fuschia ~ # gcc --version gcc (GCC) 4.1.2 (Gentoo 4.1.2 p1.5) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. fuschia ~ # gcc -march=native -c test.c test.c:1: error: bad value (native) for -march= switch test.c:1: error: bad value (native) for -mtune= switch But in that case replace-cpu-flags would be trying to replace -march=native in CFLAGS which shouldn't be there in the first place for gcc < 4.2 since nothing would compile. So this could be a problem in a case where someone has CFLAGS="... -narch=native" using gcc >= 4.2 then switches to gcc < 4.2 just to build some other version of gcc. That's pretty crazy. We could sanitize CFLAGS but I prefer breakage telling the user that his/her set of CFLAGS is not going to work. So I still don't see a problem here. (At least I'm becoming more familiar with how toolchian.eclass works :)
(In reply to Anthony Basile from comment #27) > So this could be a problem in a case where someone has CFLAGS="... > -narch=native" using gcc >= 4.2 then switches to gcc < 4.2 just to build > some other version of gcc. That's pretty crazy. We could sanitize CFLAGS > but I prefer breakage telling the user that his/her set of CFLAGS is not > going to work. or mabye not because toolchain_src_configure() { downgrade_arch_flags gcc_do_filter_flags So if -march=native makes it int here, then gcc_do_filter_flags calls strip-unsupported-flags (from flag-o-matic.eclass) which exports CFLAGS=$(test-flags-CC ${CFLAGS}) and which ultimately calls test-flag-CC() { test-flag-PROG "CC" c "$1"; } after a bunch of wrappers. This would return shell false if gcc -march=native fails. @Ryan thanks for the clue in comment 24.
I'm starting to see the end of the tunnel :) (In reply to Anthony Basile from comment #28) > or mabye not because > > toolchain_src_configure() { > downgrade_arch_flags > gcc_do_filter_flags Maybe, but this won't remove the fact the downgrade_arch_flags is not doing its work and is buggy. I could agree with a wontfix resolve but seriously, i just refuse the invalid status. toolchain_src_configure() { downgrade_arch_flags # Here add anything you wish that would prove downgrade_arch_flags has done any work, because it will always keep native as it only works for < 4.2 and can only replace native with native. gcc_do_filter_flags It's just better than to: toolchain_src_configure() { gcc_do_filter_flags Why there's no comment on the function itself? It is usual to have eclass without comment to define what a function should do...?
I realise i could look at toolchain.eclass just right from my portage tree. I'm a bit scared to find another odd thing in it :) I see the comment on the function and that the function isn't limit to that native check. So the part i'm speaking about should be fix. (the gcc < 4.2 check for native)
(In reply to nobody from comment #30) > I realise i could look at toolchain.eclass just right from my portage tree. > I'm a bit scared to find another odd thing in it :) The help would be appreciated. My advice though is to actually have a failing result with steps to reproduce. Then a suggested fix.
