Re: Preprocessor for assembler macros?
gcc -S tmp.S for some reason prints to stdout, so gcc -S tmp.S tmp.s is what you need Thank you very much, I'll take a look. Regards, Phil -- Versioning your /etc, /home or even your whole installation? Try fsvs (fsvs.tigris.org)!
Re: -mfpmath=sse,387 is experimental ?
Timothy Madden wrote: Hello Is -mfpmath=both for i386 and x86-64 still experimental in gcc 4.3, as the in the online manual page ? Yes. It might (*might*) be better in GCC 4.4 thanks to the new register allocator, but it's unlikely that the manual page will be changed before the release. Paolo
cmath call builtin sqrtf but many platforms seem miss that(was Re: lrint lrintf problems )
Hello Richard
On 06.03.09, you wrote:
ah thanks for info, i understand now too wy sqrtf, fmod (work in C programs)
get linker error on C++ programs but sqrt and some other work on platform
68k.
in c++/4.3.2/cmath include
is this code.
using ::sqrt;
inline float
sqrt(float __x)
{ return __builtin_sqrtf(__x); }
But .md file of many architetures contain no entry for this.I see only i386,
rs6000, ia64, sh contain code for this.(I search for sqrtf and list files
that contain this)
the header files are build during GCC build, i change nothing.
Is there something wrong during compiler Build process ?
How can i then implement lrint func without asm Code ?
If the backend does not support inlining lrint then you need to link
against a C99 math library (-lm). You can add lrintsrcmodedestmode
patterns to m68k.md to provide inline expansions.
Richard.
please help
Regards
Re: Setting -frounding-math by default
On Mon, Mar 9, 2009 at 12:35 AM, Joseph S. Myers jos...@codesourcery.com wrote: - Show quoted text - On Mon, 9 Mar 2009, Steven Bosscher wrote: On Mon, Mar 9, 2009 at 12:24 AM, Joseph S. Myers jos...@codesourcery.com wrote: The defaults are deliberate decisions (and as such the adoption of those decisions cannot meaningfully be considered a regression: it's not a bug but a feature), but are more likely to change in the other direction from what you want. I wish the same not a bug but a feature measure would be applied to some of the optimization regressions (those in Bugzilla and those holding up big cleanups). I hope we judge optimizations based on whether they seem to improve (or not make worse) important benchmarks on important targets rather than the impossible standard of not making *any* code worse. (And cleanups likewise on not making a range of benchmarks worse.) A particular case made worse may still be a regression, but it could quite reasonably be a P4 or P5 regression depending on how much code is affected. It's pretty hard to qualify them as more or less important. So unless we get completely swamped in P2s like that I'd rather stay to the current policy. A more reasonable thing would be to downgrade optimization regressions once they shipped in a stable release, thus only make optimization regressions against the previous release series P3. Richard. -- - Show quoted text - Joseph S. Myers jos...@codesourcery.com
Re: GCC 4.4 is not able to build itself under Cygwin
Dave Korn wrote: Gah, yes of course, you showed the config in your first post. Well, that's the problem. Confirmed, with --enable-threads=posix the compiler builds correctly. Best regards, Piotr
Re: -mfpmath=sse,387 is experimental ?
On Mon, Mar 9, 2009 at 11:13 AM, Paolo Bonzini bonz...@gnu.org wrote: Timothy Madden wrote: Hello Is -mfpmath=both for i386 and x86-64 still experimental in gcc 4.3, as the in the online manual page ? Yes. It might (*might*) be better in GCC 4.4 thanks to the new register allocator, but it's unlikely that the manual page will be changed before the release. Thank you, I shall wait then. Timothy Madden
GCC-only software
Hi, Quite a long time ago I have decided to use GCC as the only compiler for my C++* applications (mostly heavy-duty high volume data stream processing). There are many reasons, but the most important are listed below: 1. A GCC port is available for every platform I am interested in; 2. It is impossible to maintain portability between compilers of differerent vendors at the language feature level I am used to. Otherwise I would either need to select the lowest common denominator supported language subset or raise a heavy #ifdef orgy in my code. None of them is an option. 3. GCC has a lot of extremely useful extensions and ingenious integration with inline assembly. The compiler's abilities are very weak if it comes to autovectorization, but it at least seamlessly allows me to do things right manually -- a vital feature. 4. I need as much C++0x features as possible. Even the experimental support in GCC 4.x dramatically improved the quality of my code. It is also the reason I use gcc-trunk as the development platform. Having said that, I wonder what else can I win by sticking to the GNU compiler as closely as possible. There is a lot of officially documented extensions (computed gotos, attributes, PMF conversions etc.) I am aware of (and I continuously monitor the list), but the purpose of this mail is a kind request to shed some light on the grey zone. Could you please point me the under the hood features you think may be interesting for me? I mean (presumming that there are) the extended type info, class layout description (e.g. in order to implement reflections and GC), the __cxa* function ZOO, stable compiler-wide assumptions in the places where the language standard is unclear or anything like that. A reference to their documentation will be appreciated. Best regards, Piotr Wyderski *) Or, I should say G++0x...
Re: GCC-only software
2009/3/9 Piotr Wyderski piotr.wyder...@gmail.com: Having said that, I wonder what else can I win by sticking to the GNU compiler as closely as possible. There is a lot of officially documented extensions (computed gotos, attributes, PMF conversions etc.) I am aware of (and I continuously monitor the list), but the purpose of this mail is a kind request to shed some light on the grey zone. Could you please point me the under the hood features you think may be interesting for me? I mean (presumming that there are) the extended type info, class layout description (e.g. in order to implement reflections and GC), the __cxa* function ZOO, stable compiler-wide assumptions in the places where the language standard is unclear or anything like that. A reference to their documentation will be appreciated. This is a question more for gcc-help. Anyway, the documentation is there http://gcc.gnu.org/onlinedocs/ Anything not documented there is likely to change or be removed in the future, so you should not rely on it. On the other hand, if you find some behaviour that you feel should be documented and it is not, please submit a documentation patch (or at least open a bug report). I would not recommend relying on trunk (specially not during stages 1 or 2) for production code. GCC is under heavy development and it undergoes deep changes during stage1 and that always introduces bugs. Cheers, Manuel.
Re: GCC-only software
Manuel López-Ibáñez wrote: Anyway, the documentation is there http://gcc.gnu.org/onlinedocs/ Yes, this is the official documentation I read frequently. Anything not documented there is likely to change or be removed in the future, so you should not rely on it. I can afford the process of perpetual adjustment in the critical parts :-) On the other hand, if you find some behaviour that you feel should be documented and it is not, please submit a documentation patch (or at least open a bug report). Well, the problem is that I don't know where to find the unofficial documentation, so it is hard to figure out the questions to be asked. I would not recommend relying on trunk (specially not during stages 1 or 2) for production code. Certainly. But for development it is perfectly acceptable. Best regards, Piotr
Re: GCC-only software
Well, the problem is that I don't know where to find the unofficial documentation, so it is hard to figure out the questions to be asked. Well, the unofficial documentation is the source code. :- Paolo
Re: cmath call builtin sqrtf but many platforms seem miss that(was Re: lrint lrintf problems )
Hello Gabriel
On 09.03.09, you wrote:
The above sqrt() function is distinct from the C version, because
it has a C++ linkage. Consequently, I would expect that if
__builtin_sqrtf() is not available, the compiler would emit a
library call to the out-of-line C version.
But it dont work.
I have define in math.h this func.see my below
example source that show important parts.look a little ugly, but this is
done to avoid in -o3 the remove of some function calls.
real problem i see in libdirac
inline float sqrtf(float x)
{
return sqrt(x);
}
...
int main(int argc, char** argv)
{
printf(%f\n,sqrtf((float)argc));// work
printf(%f\n,std::sqrt(static_castfloat(argc))); // work not
printf(%f\n,std::sqrt(static_castdouble(argc))); // work
..
when i change c++/4.3.2/cmath to this code, then all work
using ::sqrt;
inline float
sqrt(float __x)
- { return __builtin_sqrtf(__x); }
+ { return sqrtf(__x); }
.
now you can come to the idea and add it as link func, maybe then it work.
But then i get error at that line, but other lines work.
printf(%f\n,sqrtf((float)argc));
undefined reference to `sqrtf(float)'
You see there is the _ not in.normaly funcs that not find have a _ before
To get all work, it seem i need add the same function add in math.h and in
the linker
lib or change cmath file and remove all __builtin_ commands the architecture
not have.
On Mon, Mar 9, 2009 at 2:42 AM, Bernd Roesch nospamn...@web.de wrote:
Hello Richard
On 06.03.09, you wrote:
ah thanks for info, i understand now too wy sqrtf, fmod (work in C
programs)
get linker error on C++ programs but sqrt and some other work on
platform
68k.
in c++/4.3.2/cmath include
is this code.
using ::sqrt;
inline float
sqrt(float __x)
{ return __builtin_sqrtf(__x); }
But .md file of many architetures contain no entry for this.I see only
i386,
rs6000, ia64, sh contain code for this.(I search for sqrtf and list
files
that contain this)
the header files are build during GCC build, i change nothing.
Is there something wrong during compiler Build process ?
The above sqrt() function is distinct from the C version, because
it has a C++ linkage. Consequently, I would expect that if
__builtin_sqrtf() is not available, the compiler would emit a
library call to the out-of-line C version.
-- Gaby
Regards
Re: cmath call builtin sqrtf but many platforms seem miss that(was Re: lrint lrintf problems )
On Mon, Mar 9, 2009 at 7:11 AM, Bernd Roesch nospamn...@web.de wrote: Hello Gabriel [...] You see there is the _ not in.normaly funcs that not find have a _ before To get all work, it seem i need add the same function add in math.h and in the linker lib or change cmath file and remove all __builtin_ commands the architecture not have. I believe one should convince the middle end to emit libcall for __builtin_xxx when the target has no builtint support. -- Gaby
Re: cmath call builtin sqrtf but many platforms seem miss that(was Re: lrint lrintf problems )
On Mon, Mar 9, 2009 at 3:59 PM, Gabriel Dos Reis dosr...@gmail.com wrote: On Mon, Mar 9, 2009 at 7:11 AM, Bernd Roesch nospamn...@web.de wrote: Hello Gabriel [...] You see there is the _ not in.normaly funcs that not find have a _ before To get all work, it seem i need add the same function add in math.h and in the linker lib or change cmath file and remove all __builtin_ commands the architecture not have. I believe one should convince the middle end to emit libcall for __builtin_xxx when the target has no builtint support. It of course does. Richard.
Re: GCC-only software
On Mon, Mar 9, 2009 at 3:43 AM, Piotr Wyderski piotr.wyder...@gmail.com wrote: Could you please point me the under the hood features you think may be interesting for me? I mean (presumming that there are) the extended type info, class layout description (e.g. in order to implement reflections and GC), the __cxa* function ZOO, stable compiler-wide assumptions in the places where the language standard is unclear or anything like that. A reference to their documentation will be appreciated. So for C++, GCC follows the ia64 C++ ABI (except for arm-eabi but that is a derivative of that ABI with slight differences). So you should read that ABI. It is listed in further readings part of GCC's web page IIRC. Thanks, Andrew Pinski
RE: [gcov] stamp mismatch with graph file
Hi, I am experiencing a problem with retrieving coverage data from some instrumented fortran code. The error I receive is: stamp mismatch with graph file. Browsing Google I can find virtually no clues what might be wrong. Is there a clear scenario that triggers this? What info do I need to provide to debug this? I am using gfortran 4.3.2. Regards, Arjen Verweij
Re: cmath call builtin sqrtf but many platforms seem miss that(was Re: lrint lrintf problems )
On Mon, Mar 9, 2009 at 9:03 AM, Richard Guenther richard.guent...@gmail.com wrote: I believe one should convince the middle end to emit libcall for __builtin_xxx when the target has no builtint support. It of course does. Then, Bernd's report appears to be a mystery. -- Gaby
Re: Setting -frounding-math by default
Andrew Thomas Pinski wrote: The fact is that Roger's patch introduced a regression (this word should be clear enough here), in that some users now have their old code broken, and they are forced to add the -frounding-math option (after having lost some time finding about this non trivial issue). This is a long term hindrance. Actually before roger's patch the default is the same. Just there was no way to turn it off. Actually, there are 2 things controlled by -frounding-math : 1) constant propagation of FP operations 2) generic transformations like (-a)*b - -(a*b) At the time Roger's patch went in, I believe that only 2) was concerned, and GCC did not try to do anything special about 1). And *this*, is the regression I'm complaining about. Later, 1) started to be taken care of, and it was unfortunately added under the control of the same -frounding-math option. Which now, makes it harder to come back, since we want different defaults for these two aspects. I have already mentioned in a bugzilla PR that it could be nice to have 2 options, but IIRC, I did not get any reply to this. -- Sylvain Pion INRIA Sophia-Antipolis Geometrica Project-Team CGAL, http://cgal.org/
Re: Setting -frounding-math by default
Sylvain Pion wrote: Andrew Thomas Pinski wrote: The fact is that Roger's patch introduced a regression (this word should be clear enough here), in that some users now have their old code broken, and they are forced to add the -frounding-math option (after having lost some time finding about this non trivial issue). This is a long term hindrance. Actually before roger's patch the default is the same. Just there was no way to turn it off. Actually, there are 2 things controlled by -frounding-math : 1) constant propagation of FP operations 2) generic transformations like (-a)*b - -(a*b) I think 2) is taken care of by -fassociative-math, or it should at least. Paolo
Re: Setting -frounding-math by default
Joseph S. Myers wrote: On Sun, 8 Mar 2009, Sylvain Pion wrote: this pragma. I nevertheless try to find grants for funding people to implement some related things in GCC. And I also contribute time to help in the guidance of GCC with my expertise in this particular area, even if it requires a lot of time to convince people. So, please... Finding funding for implementing standard pragmas and completing the -frounding-math implementation is likely to be more productive than arguing about a default for an option that is known to have problems. I disagree. My opinion is that : - the C99 pragma is not the best thing that can be done, and if after 10 years nobody has done it in GCC, it can also mean that it does not feel the needs as correctly as it was supposed to. - C++ does not have it, so what's the plan for C++ ? Related to this, I argue that -frounding-math is not appropriately defined (see my other mail on splitting it in 2 parts, with different defaults for these 2 parts). So we must discuss it *before* we start hacking on code or funding proposals. All the people discussing the issue are familiar with the floating point optimization issues in GCC. (I have added many such bugs to the dependencies of bug 16989 in the past to help track them, and just added some more.) Since as far as I know all work done on the floating-point issues has been done as volunteers, time spent discussing the defaults is only going to mean time not available for implementing this or other features. Please step back and listen, it is sometimes worth it. The default is in accordance with standard requirements, and more more conservative than other compilers which tend to enable their -ffast-math equivalents by default rather than just -fno-rounding-math. At least these others have chosen to do it more consistently. They don't claim their default is anything sane at all for serious FP computations, which at least is clear. GCC does not try to make such a claim; it depends entirely on your definition of serious FP computations, which is clearly a bikeshed Sure. discussion even if the discussion of defaults isn't. GCC provides various options and documents the defaults. The defaults are deliberate decisions (and as such the adoption of those decisions cannot meaningfully be considered a regression: it's not a bug but a feature), but are more likely to change in the other direction from what you want. Which makes it yet another case that translation-unit level defaults won't solve this issue, and that these things should be made controllable at a finer granularity, in the source code. This is what the C99 pragma is supposed to do, but as I said, it would not be ideal anyway even if implemented. It is incomplete as it would prevent constant propagation through directed rounding operations. C++0x aims at improving the situation concerning constant propagation, with constexpr. I have therefore worked on N2811 http://www.open-std.org/JTC1/sc22/wg21/docs/papers/2008/n2811.pdf in order to provide a way to do things better than the pragma and with a better interaction with constant propagation. This proposal is aimed at being ideal for interval arithmetic and related ocmputations dealing with the rounding mode (I'll issue a revision of the document soon, based on the feedback I got at Summit). This is C++ syntax, but the core proposal is basically to add compiler built-ins to do FP operations with a specified rounding mode, so you may imagine a C or Fortran interface as well. (I don't claim N2811 is as complete as we could imagine it, it is driven my the interval arithmetic needs, and I would love to see other experts comment on it) A more general side remark is that it is really a pitty that the expertise in these domains is split among the C, C++ and Fortran committees. This is a reason why I proposed to create a dedicated working group for scientific computing in C++ (which might actually get real) and which would allow to gather scientific experts and focus on scientific aspects (numerics being one of them), while still having a relation with the dominant language, C++, but without bothering non-C++ experts too much with purely C++ aspects. Moreover, standards are far from saying anything about the best default for -frounding-math, it's a GCC matter. And GCC maintainers should be able to listen to expert users to help them making good choices. GCC maintainers must also bear in mind the bulk of users for whom the default options, complete with other issues such as x87 excess precision, are just fine, and the value of good benchmark scores in marketing GCC. (You will of course nevertheless note that I have fixed PR 323 for C for 4.5.) Yep, I did note, and this is impressive work. Though, as a C++ user, I won't see the benefit of it for now unfortunately :( -- Sylvain Pion INRIA Sophia-Antipolis Geometrica Project-Team CGAL, http://cgal.org/
Re: Setting -frounding-math by default
Paolo Bonzini wrote: Sylvain Pion wrote: Andrew Thomas Pinski wrote: The fact is that Roger's patch introduced a regression (this word should be clear enough here), in that some users now have their old code broken, and they are forced to add the -frounding-math option (after having lost some time finding about this non trivial issue). This is a long term hindrance. Actually before roger's patch the default is the same. Just there was no way to turn it off. Actually, there are 2 things controlled by -frounding-math : 1) constant propagation of FP operations 2) generic transformations like (-a)*b - -(a*b) I think 2) is taken care of by -fassociative-math, or it should at least. I don't think it is (I haven't checked), and I don't see why it should. This transformation has nothing to do with associativity : unless I'm mistaken, it is always valid when rounding is to the nearest or towards zero. -- Sylvain Pion INRIA Sophia-Antipolis Geometrica Project-Team CGAL, http://cgal.org/
No address_cost calls when inlining ?
Dear all,
I am currently working on defining the cost of an address calculation
and I have an issue when the function is inlined. It seems that when
the address cost is taken into account only sometimes.
Here is the test code that I am testing this on:
long tab[2];
void foo(long x) {
long i;
for (i = 0; i 2; i++) {
tab[i] = x;
}
return;
}
long main() {
int i;
for (i = 0; i 10; i++) {
foo(i);
}
return 0;
}
I get for the function foo :
la r6,tab
std r8,8(r6)
std r8,0(r6)
and for main:
std r7,tab
std r7,tab+8
I want the version of foo because the store with an address as
destination is costly on my architecture, which is why I defined
TARGET_ADDRESS_COST and added a cost when I get this scenario.
However, in the compilation of this code, it seems that, when the
function is inlined, the address_cost function does not seem to be
called anymore. Any ideas why ?
Thanks in advance,
Jean Christophe Beyler
Re: Setting -frounding-math by default
I think 2) is taken care of by -fassociative-math, or it should at least. I don't think it is (I haven't checked), and I don't see why it should. This transformation has nothing to do with associativity : unless I'm mistaken, it is always valid when rounding is to the nearest or towards zero. (-a) * b = -(a * b) is definitely reassociation (-a is -1 * a); no reassociation has to be valid in any rounding mode, which means two things: 1) it can be done even when other rounding-mode-dependent optimizations are disabled via flag_rounding_math (good); 2) it would also enable other optimization that you might not want (bad). Paolo
TREE_ADDRESSABLE types and SRA?
Hi, The description of TREE_ADDRESSABLE macro in tree.h says: In ..._TYPE nodes, it means that objects of this type must be fully addressable. This means that pieces of this object cannot go into register parameters, for example. Yet the current tree-sra does not check this flag and happily scalarizes variables of such types, there are even tests in our regression testsuite that check whether such types are indeed reduced (such as g++.dg/tree-ssa/ssa-sra-1.C). Moreover, such types are very common in C++, the one in the testcase mentioned above is even quite simple. On a related note, is the assert in create_tmp_var() checking this addressability the requested type really necessary? Is the comment outdated? Or have we been somehow lucky all this time while ignoring a sensible requirement? Thanks, Martin
Re: TREE_ADDRESSABLE types and SRA?
On Mon, Mar 9, 2009 at 2:21 PM, Martin Jambor mjam...@suse.cz wrote: Hi, The description of TREE_ADDRESSABLE macro in tree.h says: In ..._TYPE nodes, it means that objects of this type must be fully addressable. This means that pieces of this object cannot go into register parameters, for example. Yet the current tree-sra does not check this flag and happily scalarizes variables of such types, there are even tests in our regression testsuite that check whether such types are indeed reduced (such as g++.dg/tree-ssa/ssa-sra-1.C). Moreover, such types are very common in C++, the one in the testcase mentioned above is even quite simple. On a related note, is the assert in create_tmp_var() checking this addressability the requested type really necessary? Yes, we really don't want to create a temporary variable of this type because they need to be constructed and deconstructed. Is the comment outdated? Or have we been somehow lucky all this time while ignoring a sensible requirement? The comment is semi correct, it is more talking about the type has to be fully addressable if used fully but really can be scalarised if used only locally in the function. Thanks, Andrew Pinski
Re: The gcc-in-cxx branch now completes bootstrap
I'm curious whether there are any detectable differences in the resulting compiler when built with g++ rather than gcc. E.g. testsuite regressions, changes in the speed or size of cc1, etc. Also, is cc1 linked with libstdc++.so ? Stuff like that. Also, is there any significant difference in bootstrap times? Ben
Re: The gcc-in-cxx branch now completes bootstrap
Ben Elliston b...@au1.ibm.com writes: I'm curious whether there are any detectable differences in the resulting compiler when built with g++ rather than gcc. E.g. testsuite regressions, changes in the speed or size of cc1, etc. Also, is cc1 linked with libstdc++.so ? Stuff like that. Also, is there any significant difference in bootstrap times? I haven't actually measured, but subjectively bootstrap does seem to take longer. I encourage anybody interested in these sorts of questions to check out the branch and find out. gcc-in-cxx is something I do entirely in my spare time, and it's not like I have more spare time than anybody else does. Ian
Re: Setting -frounding-math by default
On Mon, 9 Mar 2009, Sylvain Pion wrote: - C++ does not have it, so what's the plan for C++ ? That's for C++ maintainers, possibly guided by anything that goes in the C++ standard. The pragma syntax is a fairly small part of the work, as would be control of the options at a per-function level. The large parts would be: * Disabling all problematic optimizations when the relevant options are set. * Control on a per-operation level, so block-level pragmas don't act like function-level ones and you can inline functions with different settings without making the most conservative settings apply to the merged function. Note that these large parts are language-independent. GCC maintainers must also bear in mind the bulk of users for whom the default options, complete with other issues such as x87 excess precision, are just fine, and the value of good benchmark scores in marketing GCC. (You will of course nevertheless note that I have fixed PR 323 for C for 4.5.) Yep, I did note, and this is impressive work. Though, as a C++ user, I won't see the benefit of it for now unfortunately :( The C++ maintainers (or others) are of course free to implement appropriate semantics for C++. (I don't think C++0x has followed C99 in providing any standard way to handle excess precision, but I imagine something reasonable and GCC-specific could be defined, just as I made GCC-specific interpretations of areas in which C99 was silent. There has certainly been some suggestion that Fortran might wish to implement something http://gcc.gnu.org/ml/fortran/2009-01/msg00332.html. -- Joseph S. Myers jos...@codesourcery.com
Re: Setting -frounding-math by default
On Mon, 9 Mar 2009, Sylvain Pion wrote: Later, 1) started to be taken care of, and it was unfortunately added under the control of the same -frounding-math option. Which now, makes it harder to come back, since we want different defaults for these two aspects. I have already mentioned in a bugzilla PR that it could be nice to have 2 options, but IIRC, I did not get any reply to this. Patches to split the option into two *clearly-defined* options are more likely to be accepted than changing the defaults, given that the fast-math and related flags have been split more than once before. -- Joseph S. Myers jos...@codesourcery.com
bitfields: types vs modes?
One of our customers has a chip with memory-mapped peripheral registers that need to be accessed in a specific mode. The registers represent bitfields within the hardware, so a volatile struct is an obvious choice to represent them in C. However, gcc has a very simplistic heuristic for deciding what mode to use to access bitfields in structures - it uses either the biggest or smallest mode practical. This offers the programmer no way to tell gcc what mode the accesses need to be in, aside from manually reading/writing memory with integer types and casting. Options? My thought, after some internal discussion, is that (if the target chooses) we allow gcc to honor the type of a volatile bitfield as the mode as long as it can do so without otherwise violating the structure's layout. Some new hook will be needed for the backend, and perhaps a -W option for when the type cannot be honored. I.e. if the programmer is careful enough to properly lay out the struct, the programmer should get what the programmer asks for. Comments? Alternatives?
Re: The gcc-in-cxx branch now completes bootstrap
On Mon, 2009-03-09 at 21:25 -0700, Ian Lance Taylor wrote: Also, is there any significant difference in bootstrap times? I haven't actually measured, but subjectively bootstrap does seem to take longer. A subjective assessment was all I was interested in. Thanks, Ben
[Bug c++/39404] New: -fpack-struct causes iostream to error, -O3 makes problem worse
the act of #including iostream or any of the streams and using the
-fpack-struct switch causes the compiler to flag lots of errors that it
normally wouldn't without the switch. adding -O3 makes the problem worse.
this is a consistent problem.
This problem persists in 5.1.4 version of MinGW (gcc 3.4.5).
Note: this problem persists in gcc 4.32 with djgpp (DOS port of gcc, including,
gcc-3.23, gcc-3.36, gcc-3.44, gcc-4.01, gcc-4.10).
I am using Dell 4600 Windows XP SP3 32-bit on Pentium 4HT (thinks its
dual-core) with 3GB Ram and 4GB Virtual Memory.
C:\prj\test\iostreamdostype io.cpp
#include iostream
using namespace std;
int main(void) {
std::coutzippy;
return 0;
}
-using MinGW 5.1.4
C:\prj\test\iostreamdosg++ -O3 -s -o io.exe io.cpp
C:\prj\test\iostreamdosg++ -fpack-struct io.cpp
In file included from
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/
c++/3.4.5/ios:49,
from
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/
c++/3.4.5/ostream:45,
from
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/
c++/3.4.5/iostream:45,
from io.cpp:1:
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h: In member function `std::_Ios_Fmtflags
std::ios_base::setf(std::_Ios_Fmtfla
gs)':
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h:579: error: cannot bind packed field
`((std::ios_base*)this)-std::ios_base:
:_M_flags' to `std::_Ios_Fmtflags'
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h: In member function `std::_Ios_Fmtflags
std::ios_base::setf(std::_Ios_Fmtfla
gs, std::_Ios_Fmtflags)':
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h:596: error: cannot bind packed field
`((std::ios_base*)this)-std::ios_base:
:_M_flags' to `std::_Ios_Fmtflags'
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h:597: error: cannot bind packed field
`((std::ios_base*)this)-std::ios_base:
:_M_flags' to `std::_Ios_Fmtflags'
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h: In member function `void std::ios_base::unsetf(std::_Ios_Fmtflags)':
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h:608: error: cannot bind packed field
`((std::ios_base*)this)-std::ios_base:
:_M_flags' to `std::_Ios_Fmtflags'
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h: In member function `long int std::ios_base::iword(int)':
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h:740: error: cannot bind packed field
`__word-std::ios_base::_Words::_M_iwor
d' to `long int'
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h: In member function `void* std::ios_base::pword(int)':
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h:761: error: cannot bind packed field
`__word-std::ios_base::_Words::_M_pwor
d' to `void*'
C:\prj\test\iostreamdosg++ -fpack-struct -O3 io.cpp
In file included from
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/
c++/3.4.5/ios:49,
from
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/
c++/3.4.5/ostream:45,
from
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/
c++/3.4.5/iostream:45,
from io.cpp:1:
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h: In member function `std::_Ios_Fmtflags
std::ios_base::setf(std::_Ios_Fmtfla
gs)':
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h:579: error: cannot bind packed field
`((std::ios_base*)this)-std::ios_base:
:_M_flags' to `std::_Ios_Fmtflags'
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h: In member function `std::_Ios_Fmtflags
std::ios_base::setf(std::_Ios_Fmtfla
gs, std::_Ios_Fmtflags)':
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h:596: error: cannot bind packed field
`((std::ios_base*)this)-std::ios_base:
:_M_flags' to `std::_Ios_Fmtflags'
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h:597: error: cannot bind packed field
`((std::ios_base*)this)-std::ios_base:
:_M_flags' to `std::_Ios_Fmtflags'
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h: In member function `void std::ios_base::unsetf(std::_Ios_Fmtflags)':
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h:608: error: cannot bind packed field
`((std::ios_base*)this)-std::ios_base:
:_M_flags' to `std::_Ios_Fmtflags'
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h: In member function `long int std::ios_base::iword(int)':
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h:740:
[Bug c++/39404] -fpack-struct causes iostream to error, -O3 makes problem worse
--- Comment #1 from jmichae3 at yahoo dot com 2009-03-09 06:32 --- Created an attachment (id=17420) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17420action=view) -fpack-struct -O3 with iostream .ii file g++ -v -save-temps -fpack-struct -O3 io.cpp this is the generated io.ii file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39404
[Bug ada/39138] Fix Copyright Dates Before 4.5.0 Branch (or sooner)
--- Comment #1 from rob1weld at aol dot com 2009-03-09 06:36 --- Also in contrib/test_summary : # (C) 1998, 1999, 2000, 2002 Free Software Foundation -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39138
[Bug lto/39279] [lto] - Werror in ../lto_trunk/gcc/lto/lto.c
--- Comment #1 from rob1weld at aol dot com 2009-03-09 06:40 --- Fix: /* munmap ((void *)computed_offset, computed_len); */ munmap ((caddr_t)computed_offset, computed_len); Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39279
[Bug c++/39404] -fpack-struct causes iostream to error, -O3 makes problem worse
--- Comment #2 from jmichae3 at yahoo dot com 2009-03-09 06:41 --- Created an attachment (id=17421) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17421action=view) -fpack-struct with iostream .ii file g++ -v -save-temps -fpack-struct io.cpp both attachments ( .ii files) are from gcc 3.4.5. the results are different, but the errors are the same regardless of compiler version. this is a single .ii file attached. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39404
[Bug c++/39404] -fpack-struct causes iostream to error, -O3 makes problem worse
--- Comment #3 from jmichae3 at yahoo dot com 2009-03-09 06:45 --- Created an attachment (id=17422) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17422action=view) io.cpp, an offending source file problem is it #includes iostream if -fpack-struct is used. that is all that is necessary. will have more bad examples later that are simpler which show the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39404
[Bug c++/39404] -fpack-struct causes iostream to error, -O3 makes problem worse
--- Comment #4 from jmichae3 at yahoo dot com 2009-03-09 06:50 ---
Created an attachment (id=17423)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17423action=view)
source that #includes istream and fails just as miserably with -fpack-struct
C:\prj\test\iostreamdosg++ -v -save-temps -fpack-struct i.cpp
Reading specs from c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/specs
Configured with: ../gcc-3.4.5-20060117-3/configure --with-gcc --with-gnu-ld
--wi
th-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads
--dis
able-nls --enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry
--d
isable-shared --enable-sjlj-exceptions --enable-libgcj --disable-java-awt
--with
out-x --enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter
--enabl
e-hash-synchronization --enable-libstdcxx-debug
Thread model: win32
gcc version 3.4.5 (mingw-vista special r3)
c:/MinGW/bin/../libexec/gcc/mingw32/3.4.5/cc1plus.exe -E -quiet -v -iprefix
c:\
MinGW\bin/../lib/gcc/mingw32/3.4.5/ i.cpp -fpack-struct -o i.ii
ignoring nonexistent directory
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../.
./mingw32/include
ignoring nonexistent directory
/mingw/lib/gcc/mingw32/3.4.5/../../../../mingw32
/include
#include ... search starts here:
#include ... search starts here:
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/mingw32
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/backward
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/include
/mingw/lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5
/mingw/lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/mingw32
/mingw/lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/backward
/mingw/lib/gcc/mingw32/3.4.5/../../../../include
/mingw/include
/mingw/lib/gcc/mingw32/3.4.5/include
/mingw/include
End of search list.
c:/MinGW/bin/../libexec/gcc/mingw32/3.4.5/cc1plus.exe -fpreprocessed i.ii
-quie
t -dumpbase i.cpp -auxbase i -version -fpack-struct -o i.s
GNU C++ version 3.4.5 (mingw-vista special r3) (mingw32)
compiled by GNU C version 3.4.5 (mingw-vista special r3).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
In file included from
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/
c++/3.4.5/ios:49,
from
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/
c++/3.4.5/istream:45,
from i.cpp:1:
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h: In member function `std::_Ios_Fmtflags
std::ios_base::setf(std::_Ios_Fmtfla
gs)':
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h:579: error: cannot bind packed field
`((std::ios_base*)this)-std::ios_base:
:_M_flags' to `std::_Ios_Fmtflags'
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h: In member function `std::_Ios_Fmtflags
std::ios_base::setf(std::_Ios_Fmtfla
gs, std::_Ios_Fmtflags)':
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h:596: error: cannot bind packed field
`((std::ios_base*)this)-std::ios_base:
:_M_flags' to `std::_Ios_Fmtflags'
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h:597: error: cannot bind packed field
`((std::ios_base*)this)-std::ios_base:
:_M_flags' to `std::_Ios_Fmtflags'
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h: In member function `void std::ios_base::unsetf(std::_Ios_Fmtflags)':
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h:608: error: cannot bind packed field
`((std::ios_base*)this)-std::ios_base:
:_M_flags' to `std::_Ios_Fmtflags'
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h: In member function `long int std::ios_base::iword(int)':
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h:740: error: cannot bind packed field
`__word-std::ios_base::_Words::_M_iwor
d' to `long int'
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h: In member function `void* std::ios_base::pword(int)':
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h:761: error: cannot bind packed field
`__word-std::ios_base::_Words::_M_pwor
d' to `void*'
C:\prj\test\iostreamdostype i.cpp
#include istream
int main(void) {
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39404
[Bug c++/39404] -fpack-struct causes iostream to error, -O3 makes problem worse
--- Comment #5 from jmichae3 at yahoo dot com 2009-03-09 06:55 ---
Created an attachment (id=17424)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17424action=view)
source that #includes fstream which also fails miserably with -fpack-struct
new attachment: source for f.cpp
C:\prj\test\iostreamdostype f.cpp
#include fstream
int main(void) {
return 0;
}
C:\prj\test\iostreamdosg++ -v -save-temps -fpack-struct f.cpp
Reading specs from c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/specs
Configured with: ../gcc-3.4.5-20060117-3/configure --with-gcc --with-gnu-ld
--wi
th-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads
--dis
able-nls --enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry
--d
isable-shared --enable-sjlj-exceptions --enable-libgcj --disable-java-awt
--with
out-x --enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter
--enabl
e-hash-synchronization --enable-libstdcxx-debug
Thread model: win32
gcc version 3.4.5 (mingw-vista special r3)
c:/MinGW/bin/../libexec/gcc/mingw32/3.4.5/cc1plus.exe -E -quiet -v -iprefix
c:\
MinGW\bin/../lib/gcc/mingw32/3.4.5/ f.cpp -fpack-struct -o f.ii
ignoring nonexistent directory
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../.
./mingw32/include
ignoring nonexistent directory
/mingw/lib/gcc/mingw32/3.4.5/../../../../mingw32
/include
#include ... search starts here:
#include ... search starts here:
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/mingw32
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/backward
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/include
/mingw/lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5
/mingw/lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/mingw32
/mingw/lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/backward
/mingw/lib/gcc/mingw32/3.4.5/../../../../include
/mingw/include
/mingw/lib/gcc/mingw32/3.4.5/include
/mingw/include
End of search list.
c:/MinGW/bin/../libexec/gcc/mingw32/3.4.5/cc1plus.exe -fpreprocessed f.ii
-quie
t -dumpbase f.cpp -auxbase f -version -fpack-struct -o f.s
GNU C++ version 3.4.5 (mingw-vista special r3) (mingw32)
compiled by GNU C version 3.4.5 (mingw-vista special r3).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
In file included from
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/
c++/3.4.5/ios:49,
from
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/
c++/3.4.5/istream:45,
from
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/
c++/3.4.5/fstream:45,
from f.cpp:1:
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h: In member function `std::_Ios_Fmtflags
std::ios_base::setf(std::_Ios_Fmtfla
gs)':
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h:579: error: cannot bind packed field
`((std::ios_base*)this)-std::ios_base:
:_M_flags' to `std::_Ios_Fmtflags'
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h: In member function `std::_Ios_Fmtflags
std::ios_base::setf(std::_Ios_Fmtfla
gs, std::_Ios_Fmtflags)':
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h:596: error: cannot bind packed field
`((std::ios_base*)this)-std::ios_base:
:_M_flags' to `std::_Ios_Fmtflags'
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h:597: error: cannot bind packed field
`((std::ios_base*)this)-std::ios_base:
:_M_flags' to `std::_Ios_Fmtflags'
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h: In member function `void std::ios_base::unsetf(std::_Ios_Fmtflags)':
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h:608: error: cannot bind packed field
`((std::ios_base*)this)-std::ios_base:
:_M_flags' to `std::_Ios_Fmtflags'
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h: In member function `long int std::ios_base::iword(int)':
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h:740: error: cannot bind packed field
`__word-std::ios_base::_Words::_M_iwor
d' to `long int'
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h: In member function `void* std::ios_base::pword(int)':
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/bits/ios_bas
e.h:761: error: cannot bind packed field
`__word-std::ios_base::_Words::_M_pwor
d' to `void*'
C:\prj\test\iostreamdos
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39404
[Bug c++/39404] -fpack-struct causes iostream to error, -O3 makes problem worse
--- Comment #6 from jmichae3 at yahoo dot com 2009-03-09 06:57 --- Created an attachment (id=17425) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17425action=view) f.ii for fstream problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39404
[Bug c++/39404] -fpack-struct causes iostream to error, -O3 makes problem worse
--- Comment #7 from jmichae3 at yahoo dot com 2009-03-09 06:59 --- Created an attachment (id=17426) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17426action=view) i.ii for istream problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39404
[Bug target/37121] g++ create global symbol for inline function, which make link failed with multiple defination
--- Comment #13 from dannysmith at users dot sourceforge dot net 2009-03-09 07:46 --- (In reply to comment #12) Was this broken in 4.3 compilers? Is it a 4.4 regression? This is not a new bug in the compiler (the same multiple definition will occur with 3.4.5) , but an old 'feature' of the the PE-COFF linker _InterlockedIncrement is defined as an ordinary C library function in lib64_libmingwex_a-wininterlocked.o In thread.cpp, it is defined and emitted using linkonce semantics (it is put into its own .text$_InterlockedIncrement link_once sections, which is how PE-COFF implements vague linkage. The linker grabs the one and only .text$_InterlockedIncrement section in thread.o and then while resolving another symbol it needs from lib64_libmingwex_a-wininterlocked.o finds an ordinary (not .linkonce) definition InterlockedIncrement Hence the multiple definition. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37121
[Bug c++/39404] -fpack-struct causes iostream to error, -O3 makes problem worse
--- Comment #8 from dannysmith at users dot sourceforge dot net 2009-03-09 07:52 --- From gcc.info: *Warning:* the `-fpack-struct' switch causes GCC to generate code that is not binary compatible with code generated without that switch. Additionally, it makes the code suboptimal. Use it to conform to a non-default application binary interface. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39404
[Bug c++/39371] [4.2/4.3/4.4 Regression] Incorrectly rejects switch((unsigned int)boolvar)
--- Comment #2 from jakub at gcc dot gnu dot org 2009-03-09 08:22 ---
This isn't related to just bool, e.g.:
void
foo (unsigned char b)
{
switch ((unsigned int) b)
{
case 1:
case 257:
break;
}
}
also results in
pr39371-2.C:7: warning: large integer implicitly truncated to unsigned type
pr39371-2.C:7: error: duplicate case value
pr39371-2.C:6: error: previously used here
In C both testcases are fine.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39371
[Bug c/39394] gcc 4.4.0 20090306 segfaults at argp-help.c in glibc 2.7 and 2.9
--- Comment #2 from cneil at yahoo dot com 2009-03-09 09:58 --- I think I'm hitting the same bug as the reporter. i686-pc-linux-gnu-gcc argp-help.c -c -std=gnu99 -fgnu89-inline -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -fno-strict-aliasing -ggdb -march=i686 -pipe -Wstrict-prototypes -mpreferred-stack-boundary=2 -g0 -O99 -fomit-frame-pointer -D__USE_STRING_INLINES -fexceptions -mpreferred-stack-boundary=4 -fexceptions -I../include -I/var/tmp/portage/sys-libs/glibc-2.9_p20081201-r2/work/build-default-i686-pc-linux-gnu-nptl/argp -I/var/tmp/portage/sys-libs/glibc-2.9_p20081201-r2/work/build-default-i686-pc-linux-gnu-nptl -I../sysdeps/i386/elf -I../nptl/sysdeps/unix/sysv/linux/i386/i686 -I../nptl/sysdeps/unix/sysv/linux/i386 -I../sysdeps/unix/sysv/linux/i386 -I../nptl/sysdeps/unix/sysv/linux -I../nptl/sysdeps/pthread -I../sysdeps/pthread -I../ports/sysdeps/unix/sysv/linux -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../ports/sysdeps/unix/sysv/i386 -I../sysdeps/unix/sysv/i386 -I../nptl/sysdeps/unix/sysv -I../ports/sysdeps/unix/sysv-I../sysdeps/unix/sysv -I../sysdeps/unix/i386 -I../nptl/sysdeps/unix -I../ports/sysdeps/unix -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/i386/i686/fpu -I../nptl/sysdeps/i386/i686 -I../sysdeps/i386/i686 -I../sysdeps/i386/i486 -I../nptl/sysdeps/i386/i486 -I../sysdeps/i386/fpu -I../nptl/sysdeps/i386 -I../sysdeps/i386 -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -I../nptl -I../ports -I.. -I../libio -I. -nostdinc -isystem /usr/lib/gcc/i686-pc-linux-gnu/4.4.0-alpha20090306/include -isystem /usr/lib/gcc/i686-pc-linux-gnu/4.4.0-alpha20090306/include-fixed -isystem /usr/include -D_LIBC_REENTRANT -include ../include/libc-symbols.h -U_FORTIFY_SOURCE -U_FORTIFY_SOURCE -o /var/tmp/portage/sys-libs/glibc-2.9_p20081201-r2/work/build-default-i686-pc-linux-gnu-nptl/argp/argp-help.o -MD -MP -MF /var/tmp/portage/sys-libs/glibc-2.9_p20081201-r2/work/build-default-i686-pc-linux-gnu-nptl/argp/argp-help.o.dt -MT /var/tmp/portage/sys-libs/glibc-2.9_p20081201-r2/work/build-default-i686-pc-linux-gnu-nptl/argp/argp-help.o argp-help.c: In function #8216;print_header#8217;: argp-help.c:1024: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://bugs.gentoo.org/ for instructions. This is from a gentoo ebuild, but no patches are being applied. I'm using the gcc-4.4 snapshot from 20090306, and argp-help.c is from a glibc-2.9 snapshot from 20091201. I used -save-temps to get a preprocessed file (I'll attach momentarily) and did a little trial-and-error experimenting. Here's what I found: gcc -c argp-help.i -o argp-help.o -O0 : succeeds gcc -c argp-help.i -o argp-help.o -O1 : fails gcc -c argp-help.i -o argp-help.o -O1 -fno-inline : succeeds This is on an i686 (athlon-xp) machine, but I get the same failure on my x86_64 (amdfam10) machine. Here's my output from gcc -v (on the athlon-xp machine): Using built-in specs. Target: i686-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.4.0_alpha20090306/work/gcc-4.4-20090306/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.4.0-alpha20090306 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.4.0-alpha20090306/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.4.0-alpha20090306 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.4.0-alpha20090306/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.4.0-alpha20090306/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.4.0-alpha20090306/include/g++-v4 --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec --disable-fixed-point --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-multilib --enable-libmudflap --disable-libssp --enable-libgomp --enable-cld --enable-java-awt=gtk --with-arch=i686 --enable-objc-gc --enable-languages=c,c++,java,objc,obj-c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.4.0_alpha20090306' --without-ppl --without-cloog --disable-ppl-version-check --disable-cloog-version-check Thread model: posix gcc version 4.4.0-alpha20090306 (experimental) (Gentoo 4.4.0_alpha20090306) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39394
[Bug c/39394] gcc 4.4.0 20090306 segfaults at argp-help.c in glibc 2.7 and 2.9
--- Comment #3 from cneil at yahoo dot com 2009-03-09 10:00 --- Created an attachment (id=17427) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17427action=view) preprocessed argp-help.c If any additional information is needed, I'll do my best to provide it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39394
[Bug c/39394] gcc 4.4.0 20090306 segfaults at argp-help.c in glibc 2.7 and 2.9
--- Comment #4 from cneil at yahoo dot com 2009-03-09 10:14 --- OK, maybe I should slept before I submitted this. 1. The glibc-2.9 snapshot is from 20081201. I am not capable of time travel. 2. I successfully compiled this same glibc-2.9 snapshot with the gcc-4.4 snapshot from 20090220. Hopefully this helps. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39394
[Bug c++/39371] [4.2/4.3/4.4 Regression] Incorrectly rejects switch((unsigned int)boolvar)
--- Comment #3 from jakub at gcc dot gnu dot org 2009-03-09 10:31 --- Patch posted: http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00463.html -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2009- ||03/msg00463.html Status|NEW |ASSIGNED Last reconfirmed|2009-03-05 10:35:56 |2009-03-09 10:31:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39371
[Bug c++/39405] New: std::shared_ptr barfs on incomplete template class that boost::shared_ptr accepts
Can't see why this shouldn't work with std::shared_ptr; changing the type of
m_foo to std::shared_ptrfoo, i.e. leaving out the redundant template
argument, changes nothing; only when making foo a class instead of a class
template, and removing all template arguments, does it compile.
co...@weasel:/tmp g++-mp-4.3 -v
Using built-in specs.
Target: i386-apple-darwin9.6.0
Configured with: ../gcc-4.3.3/configure --prefix=/opt/local
--enable-languages=c,c++,objc,obj-c++,java,fortran
--libdir=/opt/local/lib/gcc43 --includedir=/opt/local/include/gcc43
--infodir=/opt/local/share/info --mandir=/opt/local/share/man
--with-local-prefix=/opt/local --with-system-zlib --disable-nls
--program-suffix=-mp-4.3 --with-gxx-include-dir=/opt/local/include/gcc43/c++/
--with-gmp=/opt/local --with-mpfr=/opt/local
Thread model: posix
gcc version 4.3.3 (GCC)
co...@weasel:/tmp cat t.cc
#include memory
template typename T
struct foo
{
std::shared_ptr foo T m_foo;
};
int main()
{
std::shared_ptr foo int t;
return sizeof( t );
}
co...@weasel:/tmp make t
g++-mp-4.3 -O3 -Wall -Wextra -Woverloaded-virtual -std=gnu++0x -m32
-fno-enforce-eh-specs -I/opt/local/includet.cc -o t
t.cc: In instantiation of 'fooint':
/opt/local/include/gcc43/c++/tr1_impl/type_traits:291: instantiated from
'std::is_abstractfooint '
/opt/local/include/gcc43/c++/tr1_impl/type_traits:206: instantiated from
'std::is_functionfooint '
/opt/local/include/gcc43/c++/type_traits:127: instantiated from
'std::add_lvalue_referencefooint '
/opt/local/include/gcc43/c++/tr1_impl/boost_shared_ptr.h:463: instantiated
from 'std::__shared_ptrfooint, _S_mutex'
/opt/local/include/gcc43/c++/tr1_impl/boost_shared_ptr.h:822: instantiated
from 'std::shared_ptrfooint '
t.cc:11: instantiated from here
t.cc:6: error: 'fooT::m_foo' has incomplete type
/opt/local/include/gcc43/c++/tr1_impl/boost_shared_ptr.h:822: error:
declaration of 'class std::shared_ptrfooint '
make: *** [t] Error 1
co...@weasel:/tmp cat b.cc
#include boost/shared_ptr.hpp
template typename T
struct foo
{
boost::shared_ptr foo T m_foo;
};
int main()
{
boost::shared_ptr foo int t;
return sizeof( t );
}
co...@weasel:/tmp make b
g++-mp-4.3 -O3 -Wall -Wextra -Woverloaded-virtual -std=gnu++0x -m32
-fno-enforce-eh-specs -I/opt/local/includeb.cc -o b
co...@weasel:/tmp
--
Summary: std::shared_ptr barfs on incomplete template class that
boost::shared_ptr accepts
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at cohi dot at
GCC host triplet: i386-apple-darwin9.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39405
[Bug tree-optimization/39394] [4.4 regression] ICE in copy_tree_body_r
--- Comment #5 from falk at debian dot org 2009-03-09 10:59 ---
Here's a test case:
void *p;
extern inline void *f1(int n) {
asm volatile( : =m(*(struct { char x[n]; }*) p));
}
int x;
extern inline void f2() {
x ? f1(1) : f1(2);
}
inline void f3() { f2(); }
void f4() { f3(); }
With trunk #144708, I'm getting:
min.c: In function 'f4':
min.c:12: internal compiler error: in copy_tree_body_r, at tree-inline.c:1042
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
--
falk at debian dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|c |tree-optimization
Ever Confirmed|0 |1
Keywords||ice-on-valid-code
Known to fail||4.4.0
Known to work||4.3.1
Summary|gcc 4.4.0 20090306 segfaults|[4.4 regression] ICE in
|at argp-help.c in glibc 2.7 |copy_tree_body_r
|and 2.9 |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39394
[Bug c/39394] gcc 4.4.0 20090306 segfaults at argp-help.c in glibc 2.7 and 2.9
--- Comment #6 from jakub at gcc dot gnu dot org 2009-03-09 11:09 ---
Confirmed. Simplified testcase:
extern inline void *
asmfn (void *dest, const void *src, unsigned long n)
{
asm volatile (
: =m (*(struct { char x[n]; } *) dest)
: r (n), r (dest), r (src),
m (*(struct { char x[n]; } *) src)
: cc);
return dest;
}
extern inline void
baz (char *dest, const char *str, unsigned long len)
{
if (__builtin_constant_p (len))
asmfn (dest, str, len + 1);
else
asmfn (dest, str, len);
}
extern inline void
bar (char *dest, const char *str)
{
baz (dest, str, __builtin_strlen (str));
}
void
foo (char *dest, const char *str)
{
bar (dest, str);
}
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Component|tree-optimization |c
Keywords|ice-on-valid-code |
Known to fail|4.4.0 |
Known to work|4.3.1 |
Priority|P3 |P1
Last reconfirmed|-00-00 00:00:00 |2009-03-09 11:09:57
date||
Summary|[4.4 regression] ICE in |gcc 4.4.0 20090306 segfaults
|copy_tree_body_r|at argp-help.c in glibc 2.7
||and 2.9
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39394
[Bug tree-optimization/39394] [4.4 regression] ICE in copy_tree_body_r
--- Comment #7 from jakub at gcc dot gnu dot org 2009-03-09 11:28 --- Oops, sorry. I guess the problem is that this VL type isn't gimplified. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Component|c |tree-optimization GCC host triplet|pentium2-slackware-linux-gnu| GCC target triplet|pentium2-slackware-linux-gnu| Known to fail||4.4.0 Known to work||4.3.3 Summary|gcc 4.4.0 20090306 segfaults|[4.4 regression] ICE in |at argp-help.c in glibc 2.7 |copy_tree_body_r |and 2.9 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39394
[Bug libfortran/39402] gfortran 20090306: internal write of 0.0 with F0.3 gives **
--- Comment #7 from davidgkinniburgh at yahoo dot co dot uk 2009-03-09 11:33 --- Thanks Jerry. PS CHARACTER(80) :: str no longer needed in test case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39402
[Bug libfortran/39402] gfortran 20090306: internal write of 0.0 with F0.3 gives **
--- Comment #8 from davidgkinniburgh at yahoo dot co dot uk 2009-03-09 11:34 --- Thanks Jerry. PS CHARACTER(80) :: str no longer required in test case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39402
[Bug c/39406] New: ice in tree-dfa.c for legal code with -O2
I just tried to compile the Suse Linux package sparse sparse-0.4.1.git1-1.56 with the GNU C compiler version 4.4 snapshot 20090306 and the compiler said sparse.c: In function 'check_context': sparse.c:546: internal compiler error: in referenced_var_lookup, at tree-dfa.c:563 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Preprocessed source code attached. Flag -O2 required. -- Summary: ice in tree-dfa.c for legal code with -O2 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcb314 at hotmail dot com GCC host triplet: x86_64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39406
[Bug tree-optimization/39394] [4.4 regression] ICE in copy_tree_body_r
--- Comment #8 from jakub at gcc dot gnu dot org 2009-03-09 11:52 --- Created an attachment (id=17428) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17428action=view) gcc44-pr39394.patch Patch I'm going to bootstrap/regtest. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39394
[Bug c/39406] ice in tree-dfa.c for legal code with -O2
--- Comment #1 from dcb314 at hotmail dot com 2009-03-09 11:53 --- Created an attachment (id=17429) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17429action=view) C source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39406
[Bug libstdc++/39407] New: Parse error in stack when user declares template-name c
It was just brought to my attention that this fails to compile:
template typename void c();
#include stack
In file included from
/sbcimp/run/pd/gcc/32-bit/4.3.2/lib/gcc/i686-pc-linux-gnu/4.3.2/../../../../include/c++/4.3.2/stack:67,
from mark.cc:2:
/sbcimp/run/pd/gcc/32-bit/4.3.2/lib/gcc/i686-pc-linux-gnu/4.3.2/../../../../include/c++/4.3.2/bits/stl_stack.h:
In function bool std::operator(const std::stack_Tp, _Seq, const
std::stack_Tp, _Seq):
/sbcimp/run/pd/gcc/32-bit/4.3.2/lib/gcc/i686-pc-linux-gnu/4.3.2/../../../../include/c++/4.3.2/bits/stl_stack.h:257:
error: `.' cannot appear in a constant-expression
/sbcimp/run/pd/gcc/32-bit/4.3.2/lib/gcc/i686-pc-linux-gnu/4.3.2/../../../../include/c++/4.3.2/bits/stl_stack.h:257:
error: parse error in template argument list
The problem is here:
templatetypename _Tp, typename _Seq
inline bool
operator(const stack_Tp, _Seq __x, const stack_Tp, _Seq __y)
{ return __x.c __y.c; }
The presence of the template ::c means that c is parsed as the start of a
template-id, which then fails.
I *think* the compiler is doing the right thing here, but that doesn't help
users who've declared a template 'c'. libstdc++ could make it a non-issue by
using parentheses to prevent __x.c being parsed as a template-id:
{ return (__x.c) __y.c; }
I've only tested it with 4.3.2 but it apparently fails with 3.2 - 4.3.3, and I
assume with 4.4 too.
--
Summary: Parse error in stack when user declares template-name
c
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jwakely dot gcc at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39407
[Bug c/39406] ice in tree-dfa.c for legal code with -O2
--- Comment #2 from jakub at gcc dot gnu dot org 2009-03-09 13:16 --- This is likely dup of PR39360, please retry with a newer snapshot. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39406
[Bug tree-optimization/39300] vectorizer confused by predictive commoning and PRE
--- Comment #6 from matz at gcc dot gnu dot org 2009-03-09 13:25 --- It's also PRE that produces such patterns, so moving predcom behind vectorization alone won't help this problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39300
[Bug libstdc++/39407] Parse error in stack when user declares template-name c
--- Comment #1 from paolo dot carlini at oracle dot com 2009-03-09 14:00 --- disgusting ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39407
[Bug tree-optimization/39394] [4.4 regression] ICE in copy_tree_body_r
--- Comment #9 from jakub at gcc dot gnu dot org 2009-03-09 14:01 --- Subject: Bug 39394 Author: jakub Date: Mon Mar 9 14:01:29 2009 New Revision: 144727 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144727 Log: PR tree-optimization/39394 * gimplify.c (gimplify_type_sizes): Gimplify DECL_SIZE and DECL_SIZE_UNIT of variable length FIELD_DECLs. * gcc.c-torture/compile/pr39394.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr39394.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39394
[Bug libstdc++/39407] Parse error in stack when user declares template-name c
--- Comment #2 from paolo dot carlini at oracle dot com 2009-03-09 14:02 --- FWIW, if I use v3 together with the Intel C++ compiler, it builds... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39407
[Bug tree-optimization/39394] [4.4 regression] ICE in copy_tree_body_r
--- Comment #10 from jakub at gcc dot gnu dot org 2009-03-09 14:03 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39394
[Bug libstdc++/39407] Parse error in stack when user declares template-name c
--- Comment #3 from jwakely dot gcc at gmail dot com 2009-03-09 14:25 --- (In reply to comment #2) FWIW, if I use v3 together with the Intel C++ compiler, it builds... That's interesting, Comeau's online compiler gives a very similar error to gcc 4.3.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39407
[Bug c++/39409] New: internal compiler error: Segmentation fault
$ uname -a system type: AIX aix52a 1 6 000921F2D700 $ gcc -v Using built-in specs. Target: powerpc-ibm-aix6.1.0.0 Configured with: ../configure --with-as=/usr/bin/as --with-ld=/usr/bin/ld --enable-languages=c,c++,java --prefix=/opt/freeware --enable-threads --enable-version-specific-runtime-libs --host=powerpc-ibm-aix6.1.0.0 --target=powerpc-ibm-aix6.1.0.0 --build=powerpc-ibm-aix6.1.0.0 --disable-libjava-multilib Thread model: aix gcc version 4.2.0 gcc command: g++ -g -fstack-check -DAIX -fPIC -D_REENTRANT -DTUNICODE -g -fstack-check -DAIX -D_PTHREADS -fcheck-new -D__STL_ASSERTIONS -D__STDC_LIMIT_MACROS -c -o updatethread.o updatethread.cpp error: updatethread.cpp: At global scope: updatethread.cpp:2777: internal compiler error: Segmentation fault -- Summary: internal compiler error: Segmentation fault Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amit at mobiletornado dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39409
[Bug c++/39409] internal compiler error: Segmentation fault
--- Comment #1 from amit at mobiletornado dot com 2009-03-09 14:38 --- Created an attachment (id=17430) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17430action=view) the preprocessed file (gzipped) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39409
[Bug driver/39356] assembler isn't called
--- Comment #5 from r dot emrich at de dot tecosim dot com 2009-03-09 15:07 --- (In reply to comment #4) Sorry, pex_run co aren't the reason for this issue. By further debugging I found that for bigger functions using alloca with variable sizes wrong code is generated for optimizations bigger then -O0. By this reason the driver gcc.c in execute is broken. The interesting issue about this is, when trying to make a smaller testcase out of it, code is produced correct. I can confirm this. Building the compiler with CFLAGS=-O0 results in a working driver. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39356
[Bug libstdc++/39407] Parse error in stack when user declares template-name c
--- Comment #4 from paolo dot carlini at oracle dot com 2009-03-09 15:08 --- Before considering touching the library, I want evidence that at least another widespread implementation has that operator somehow different than the obvious way. Besides, the issue affects queue too, of course, and in that case the Standard is even explicit about implementing exactly as x.c y.c. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39407
[Bug c/39403] Excessive optimization issue
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-03-09 15:36 --- You need to specify that the registers are clobbered by the asm. The only way to do that is to use output constraints (+D, +c, etc.) on proper temporaries. int lent = len; char *dstt = dst; char *srct = src; __asm__ __volatile__( cld\n\t rep movsb : +c (lent), +D(dstt), +S(src) ); Otherwise GCC thinks the registers still hold the original value. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39403
[Bug c++/39404] -fpack-struct causes iostream to error, -O3 makes problem worse
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-03-09 15:37 --- This flag isn't supposed to be used with libstdc++. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39404
[Bug c++/39407] Parse error in stack when user declares template-name c
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-03-09 15:40 --- I think this is more likely a C++ frontend issue. At least I cannot believe this behavior is mandated by the std ;) Jason? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||jason at redhat dot com Component|libstdc++ |c++ Keywords||rejects-valid http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39407
Re: [Bug c/39403] Excessive optimization issue
Sent from my iPhone On Mar 9, 2009, at 8:36 AM, rguenth at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #1 from rguenth at gcc dot gnu dot org 2009-03-09 15:36 --- You need to specify that the registers are clobbered by the asm. The only way to do that is to use output constraints (+D, +c, etc.) on proper temporaries. int lent = len; char *dstt = dst; char *srct = src; __asm__ __volatile__( cld\n\t rep movsb : +c (lent), +D(dstt), +S(src) ); Otherwise GCC thinks the registers still hold the original value. Oh and mark this inline-ask as clobbering memory. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added --- --- -- Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39403
[Bug c/39403] Excessive optimization issue
--- Comment #2 from pinskia at gmail dot com 2009-03-09 15:57 --- Subject: Re: Excessive optimization issue Sent from my iPhone On Mar 9, 2009, at 8:36 AM, rguenth at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #1 from rguenth at gcc dot gnu dot org 2009-03-09 15:36 --- You need to specify that the registers are clobbered by the asm. The only way to do that is to use output constraints (+D, +c, etc.) on proper temporaries. int lent = len; char *dstt = dst; char *srct = src; __asm__ __volatile__( cld\n\t rep movsb : +c (lent), +D(dstt), +S(src) ); Otherwise GCC thinks the registers still hold the original value. Oh and mark this inline-ask as clobbering memory. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added --- --- -- Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39403 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39403
[Bug c++/39407] Parse error in stack when user declares template-name c
--- Comment #8 from hjl dot tools at gmail dot com 2009-03-09 15:58 --- Icc 11 has no problems. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39407
Re: [Bug c++/39407] Parse error in stack when user declares template-name c
Sent from my iPhone On Mar 9, 2009, at 8:40 AM, rguenth at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #7 from rguenth at gcc dot gnu dot org 2009-03-09 15:40 --- I think this is more likely a C++ frontend issue. At least I cannot believe this behavior is mandated by the std ;) Jason? There is a dup of this bug somewhere also. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added --- --- -- CC||jason at redhat dot com Component|libstdc++ |c++ Keywords||rejects-valid http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39407
[Bug c++/39407] Parse error in stack when user declares template-name c
--- Comment #9 from pinskia at gmail dot com 2009-03-09 15:59 --- Subject: Re: Parse error in stack when user declares template-name c Sent from my iPhone On Mar 9, 2009, at 8:40 AM, rguenth at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #7 from rguenth at gcc dot gnu dot org 2009-03-09 15:40 --- I think this is more likely a C++ frontend issue. At least I cannot believe this behavior is mandated by the std ;) Jason? There is a dup of this bug somewhere also. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added --- --- -- CC||jason at redhat dot com Component|libstdc++ |c++ Keywords||rejects-valid http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39407 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39407
[Bug ada/39411] New: GNAT BUG DETECTED: implementation of protected interface by protected type
Hi Team, I have 'GNAT BUG DETECTED' error message when I try to compile my project. I am providing the more simple example of source code which will help to reproduce the problem. Please, advise +===GNAT BUG DETECTED==+ | 4.3.2 (i386-portbld-freebsd7.0) Assert_Failure sinfo.adb:1079| | Error detected at sample.ads:29:5| | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ The gcc -v output: Using built-in specs. Target: i386-portbld-freebsd7.0 Configured with: ./..//gcc-4.3.2/configure --enable-languages=c,ada --disable-nls --with-system-zlib --with-libiconv-prefix=/usr/local --program-suffix=43 --bindir=/usr/local/bin/gcc43 --libdir=/usr/local/lib/gcc-4.3.2 --prefix=/usr/local --mandir=/usr/local/man --infodir=/usr/local/info/gcc43 --build=i386-portbld-freebsd7.0 Thread model: posix gcc version 4.3.2 (GCC) The compilation command: $ gnatmake -p -P sample.gpr The source/project files: sample.ads - -- -- -- Author: Andriy Bakay and...@irbisnet.com -- -- -- -- Indent: 4 -- -- Tabs: no -- -- -- -- Copyright (c) Andriy Bakay. 2009 -- -- All rights reserved. -- -- -- - package Sample is type Return_Code is mod 2 ** 32; type Interface_Type is protected interface; procedure Write( Inst: in out Interface_Type; RC :out Return_Code; D : in Integer ) is abstract; function Read( Inst: in Interface_Type; D : not null access Integer ) return Return_Code is abstract; protected type Instance is new Interface_Type with overriding procedure Write( RC :out Return_Code; D : in Integer ); overriding function Read( D : not null access Integer ) returnReturn_Code; private Data: Integer := 0; end Instance; end Sample; sample.ads - sample.adb - -- -- -- Author: Andriy Bakay and...@irbisnet.com -- -- -- -- Indent: 4 -- -- Tabs: no -- -- -- -- Copyright (c) Andriy Bakay. 2009 -- -- All rights reserved. -- -- -- - package body Sample is protected body Instance is procedure Write( RC :out Return_Code; D : in Integer ) is begin RC := 0; Data:= D; end Write; function Read( D : not null access Integer ) returnReturn_Code is begin D.all := Data; return 0; end Read; end Instance; end Sample; sample.adb - common.gpr - -- -- -- Author: Andriy Bakay
[Bug c++/39407] Parse error in stack when user declares template-name c
--- Comment #10 from jwakely dot gcc at gmail dot com 2009-03-09 16:08
---
reduced:
template typename struct x;
template typename struct y { int x; };
templatetypename T
bool operator(const yT l, const yT r) { return l.x r.x; }
It doesn't happen except in a template context, so it seems that l.x is parsed
differently depending on whether it's inside a template or not. This is OK:
template typename struct x;
struct z { int x; };
bool operator(const z l, const z r) { return l.x r.x; }
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39407
[Bug c++/39407] Parse error in stack when user declares template-name c
--- Comment #11 from paolo dot carlini at oracle dot com 2009-03-09 16:19 --- Better... ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39407
[Bug c++/39407] Parse error in stack when user declares template-name c
--- Comment #12 from paolo dot carlini at oracle dot com 2009-03-09 16:24 --- Seriously, thanks Jonathan for the reduced C++ snippet. Really, this way of seeing the issue makes much more sense to me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39407
[Bug debug/39412] New: [4.4 Regression] ICE in gen_tagged_type_instantiation_die
struct S { int i; };
void
bar (const void *x, unsigned long y)
{
const union { struct S a[y / sizeof (struct S)]; } *u = x;
}
void
foo (const void *x, unsigned long y)
{
bar (x, y);
}
ICEs at -O[23s] -g with
internal compiler error: in gen_tagged_type_instantiation_die, at
dwarf2out.c:14850
--
Summary: [4.4 Regression] ICE in
gen_tagged_type_instantiation_die
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39412
[Bug debug/39412] [4.4 Regression] ICE in gen_tagged_type_instantiation_die
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39412
[Bug c++/39413] New: static_assert and SFINAE
G++ fails when compiling the following program in
g++0x mode. It displays spooky action at a distance
when instantiating the member_ptr template, but I
expect the converting assignment operator from weak_ptr
to be selected instead.
-8---
#include type_traits
class A {
};
class B : public A {
};
class C {
};
namespace gc {
template typename T class member_ptr;
}
template typename T class weak_ptr {
public:
weak_ptr() {}
template typename X weak_ptr(const weak_ptrX v) {}
weak_ptr(const weak_ptr) = default;
weak_ptr(const gc::member_ptrT v);
~weak_ptr() = default;
// --
weak_ptr operator =(const weak_ptr) = default;
template typename X weak_ptr operator =(const weak_ptrX v) {
return *this; }
};
namespace gc {
template typename T class member_ptr {
static_assert(std::is_base_ofC, T::value,
spooky action at a distance);
};
}
int main(int argc, char *argv[]) {
weak_ptrA ap1;
weak_ptrB bp1;
ap1 = bp1;
return 0;
}
-8---
--
Summary: static_assert and SFINAE
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: piotr dot wyderski at gmail dot com
GCC host triplet: GCC-4.4.0 (20090309), Cygwin, Windows XP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39413
[Bug c++/39407] Parse error in stack when user declares template-name c
--- Comment #13 from pinskia at gcc dot gnu dot org 2009-03-09 17:42 --- This is related to PR 11814 or is the same bug. I thought there was an exact duplicate of this parsing issue but I cannot find it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39407
[Bug debug/39412] [4.4 Regression] ICE in gen_tagged_type_instantiation_die
-- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.3.3 4.4.0 Known to work||4.1.2 Last reconfirmed|-00-00 00:00:00 |2009-03-09 17:47:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39412
[Bug c++/39413] static_assert and SFINAE
--- Comment #1 from paolo dot carlini at oracle dot com 2009-03-09 17:48 --- let's try to simplify the issue as much as possible... are defaulted / deleted functions really necessary to trigger the bug? Thus, is c++0x mode really necessary? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39413
[Bug c++/39413] static_assert and SFINAE
--- Comment #2 from paolo dot carlini at oracle dot com 2009-03-09 18:10
---
The below, not using any header neither C++0x mode (very likely can be further
reduced), doesn't compile with mainline and 4_3-branch, does with EDG-based
compilers in strict mode:
templatebool
class __static_assert { };
template
class __static_assertfalse;
templatetypename T, typename U
struct __are_same { static const bool value = false; };
templatetypename T
struct __are_sameT, T { static const bool value = true; };
class A {
};
class B : public A {
};
class C {
};
namespace gc {
template typename T class member_ptr;
}
template typename T class weak_ptr {
public:
weak_ptr() {}
template typename X weak_ptr(const weak_ptrX v) {}
weak_ptr(const gc::member_ptrT v);
template typename X weak_ptr operator=(const weak_ptrX v) {
return *this; }
};
namespace gc {
template typename T class member_ptr {
__static_assert__are_sameC, T::value sa;
};
}
int main() {
weak_ptrA ap1;
weak_ptrB bp1;
ap1 = bp1;
}
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-03-09 18:10:02
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39413
[Bug c++/39407] Parse error in stack when user declares template-name c
--- Comment #14 from jwakely dot gcc at gmail dot com 2009-03-09 18:13 --- aha, on PR 11814 you mention PR 20308 which is the same. Thanks, Andrew! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39407
[Bug c++/39407] Parse error in stack when user declares template-name c
--- Comment #15 from pinskia at gcc dot gnu dot org 2009-03-09 18:16 --- *** This bug has been marked as a duplicate of 10200 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39407
[Bug c++/10200] Weird clash with same names in different scopes
--- Comment #15 from pinskia at gcc dot gnu dot org 2009-03-09 18:16 --- *** Bug 39407 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||jwakely dot gcc at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10200
[Bug c++/39413] static_assert and SFINAE
--- Comment #3 from paolo dot carlini at oracle dot com 2009-03-09 18:17 --- Volunteers for a better Summary? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39413
[Bug fortran/39414] New: PROCEDURE statement double declaration bug
The following code is invalid, but currently accepted by gfortran: procedure(iabs) :: p integer :: p end It is also accepted when the two statements are reversed in order. It's not completely obvious to me whether this variant is invalid, too: procedure() :: p integer :: p It is rejected by g95, but one could argue that it is valid in the same way as: external :: p integer :: p -- Summary: PROCEDURE statement double declaration bug Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: accepts-invalid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janus at gcc dot gnu dot org GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39414
[Bug c++/39413] static_assert and SFINAE
-- paolo dot carlini at oracle dot com changed: What|Removed |Added Severity|major |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39413
[Bug c++/39371] [4.2/4.3/4.4 Regression] Incorrectly rejects switch((unsigned int)boolvar)
--- Comment #4 from jakub at gcc dot gnu dot org 2009-03-09 19:34 --- Subject: Bug 39371 Author: jakub Date: Mon Mar 9 19:34:10 2009 New Revision: 144732 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144732 Log: PR c++/39371 * semantics.c (finish_switch_cond): Don't call get_unwidened. * decl.c (finish_case_label): Pass SWITCH_STMT_TYPE as 3rd argument instead of TREE_TYPE (cond). * g++.dg/opt/switch2.C: Add -w to dg-options. * g++.dg/warn/Wswitch-1.C: Adjust expected warnings. * g++.dg/warn/switch1.C: New test. * g++.dg/other/switch3.C: New test. Added: trunk/gcc/testsuite/g++.dg/other/switch3.C trunk/gcc/testsuite/g++.dg/warn/switch1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/opt/switch2.C trunk/gcc/testsuite/g++.dg/warn/Wswitch-1.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39371
[Bug c++/39371] [4.2/4.3 Regression] Incorrectly rejects switch((unsigned int)boolvar)
--- Comment #5 from jakub at gcc dot gnu dot org 2009-03-09 19:35 --- Fixed on the trunk so far. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Known to work|2.95.4 |2.95.4 4.4.0 Summary|[4.2/4.3/4.4 Regression]|[4.2/4.3 Regression] |Incorrectly rejects |Incorrectly rejects |switch((unsigned|switch((unsigned |int)boolvar)|int)boolvar) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39371
[Bug c++/39415] New: static_cast used as downcast can silently lose const
This is silently accepted:
struct T { };
struct T_impl: public T { };
T_impl *g(T *tp) { return static_castconst T_impl*(tp); }
The result type of the static_cast is pointer-to-const and should not
convert to a pointer-to-non-const. This seems to be specific to when
it is used as a downcast. Replacing the last line with
T *g(T *tp) { return static_castconst T*(tp); }
is faulted as expected.
--
Summary: static_cast used as downcast can silently lose const
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: algrant at acm dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39415
[Bug c++/39404] -fpack-struct causes iostream to error, -O3 makes problem worse
--- Comment #10 from jmichae3 at yahoo dot com 2009-03-09 20:12 --- I didn't read that in the documentation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39404
[Bug libstdc++/39416] New: std::map::operator[] inserts a new item in RHS context
#include iostream
#include map
#include string
// Demonstrate unexpected behaviour of std::map::operator[] when used in a read
// context, e.g. on the right hand side of an assignment.
//
// The intended application is a shell environment table, where accessing a
// non-existent variable should yield an empty string, but not alter the table.
// In my shell, I sometimes wish to distinguish between an existing variable
// with an empty value, and a non-existent variable. The behaviour of
// std::map::operator[] defeats this, so I have to use the more verbose
// std::map::find interface for reading from the map.
int main(int argc, char * argv[])
{
typedef std::mapstd::string, std::string env_type;
env_type env;
env[my_var] = Hello world!; // Add an item.
std::cout env[thing] std::endl; // Empty string, as expected.
// List all variables and their values.
for(env_type::const_iterator it = env.begin(); it != env.end(); ++it)
{
std::cout it-first '=' it-second std::endl;
}
// Oh no! The non-existent variable 'thing' has been added to the map.
//
// my_var=Hello world!
// thing=
return 0;
}
--
Summary: std::map::operator[] inserts a new item in RHS context
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: glyn at adgie dot f9 dot co dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39416
[Bug debug/39412] [4.2/4.3/4.4 Regression] ICE in gen_tagged_type_instantiation_die
--- Comment #1 from hjl dot tools at gmail dot com 2009-03-09 20:52 --- This is introduced by revision 117493: http://gcc.gnu.org/ml/gcc-cvs/2006-10/msg00158.html http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00239.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||hainque at adacore dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39412
[Bug libstdc++/39416] std::map::operator[] inserts a new item in RHS context
--- Comment #1 from paolo dot carlini at oracle dot com 2009-03-09 20:53 --- There is nothing wrong here, the bahavior is fully specified in the Standard, 23.3.1.2 as: Returns: (*((insert(make_pair(x, T(.first)).second. Note, our inline documentation comments are also very clear about this. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39416
