[Bug c++/30852] [4.1/4.2/4.3 regression] Trouble with __builtin_offsetof and volatile
--- Comment #4 from reichelt at gcc dot gnu dot org 2007-03-08 07:49 --- Fixed on mainline, 4.2 branch, and 4.1 branch. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30852
[Bug c++/30534] [4.3 regression] ICE with invalid template argument
--- Comment #5 from reichelt at gcc dot gnu dot org 2007-03-08 07:48 --- Fixed on mainline. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30534
[Bug c++/30852] [4.1/4.2/4.3 regression] Trouble with __builtin_offsetof and volatile
--- Comment #3 from reichelt at gcc dot gnu dot org 2007-03-08 07:39 --- Subject: Bug 30852 Author: reichelt Date: Thu Mar 8 07:39:04 2007 New Revision: 122688 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122688 Log: PR c++/30852 * c-common.c (fold_offsetof_1): Handle COMPOUND_EXPR. * semantics.c (finish_offsetof): Handle COMPOUND_EXPR. * g++.dg/ext/offsetof1.C: Add cases with volatile. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/c-common.c branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/semantics.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/offsetof1.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30852
[Bug c++/30852] [4.1/4.2/4.3 regression] Trouble with __builtin_offsetof and volatile
--- Comment #2 from reichelt at gcc dot gnu dot org 2007-03-08 07:36 --- Subject: Bug 30852 Author: reichelt Date: Thu Mar 8 07:36:17 2007 New Revision: 122687 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122687 Log: PR c++/30852 * c-common.c (fold_offsetof_1): Handle COMPOUND_EXPR. * semantics.c (finish_offsetof): Handle COMPOUND_EXPR. * g++.dg/ext/offsetof1.C: Add cases with volatile. Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/c-common.c branches/gcc-4_2-branch/gcc/cp/ChangeLog branches/gcc-4_2-branch/gcc/cp/semantics.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog branches/gcc-4_2-branch/gcc/testsuite/g++.dg/ext/offsetof1.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30852
[Bug c++/30852] [4.1/4.2/4.3 regression] Trouble with __builtin_offsetof and volatile
--- Comment #1 from reichelt at gcc dot gnu dot org 2007-03-08 07:31 --- Subject: Bug 30852 Author: reichelt Date: Thu Mar 8 07:31:47 2007 New Revision: 122686 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122686 Log: PR c++/30852 * c-common.c (fold_offsetof_1): Handle COMPOUND_EXPR. * semantics.c (finish_offsetof): Handle COMPOUND_EXPR. * g++.dg/ext/offsetof1.C: Add cases with volatile. Modified: trunk/gcc/ChangeLog trunk/gcc/c-common.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/ext/offsetof1.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30852
[Bug c++/30534] [4.3 regression] ICE with invalid template argument
--- Comment #4 from reichelt at gcc dot gnu dot org 2007-03-08 07:26 --- Subject: Bug 30534 Author: reichelt Date: Thu Mar 8 07:26:43 2007 New Revision: 122685 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122685 Log: PR c++/30534 * pt.c (any_template_arguments_need_structural_equality_p): Robustify. * g++.dg/template/arg5.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/arg5.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30534
[Bug c++/30917] [4.1/4.2/4.3 Regression] ICE with friend in local class (to a function)
--- Comment #4 from patchapp at dberlin dot org 2007-03-08 06:55 --- Subject: Bug number PR c++/30917 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00463.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30917
[Bug fortran/31011] Incorrect error: parameter array sections
--- Comment #2 from patchapp at dberlin dot org 2007-03-08 06:25 --- Subject: Bug number PR31011 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00459.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31011
[Bug libfortran/31052] Bad IOSTAT values when readings NAMELISTs past EOF
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2007-03-08 05:51 --- Here is a patch. Herald, do you want to see if this fixes it for you. I tested here, but it does not hurt to test some more. Index: file_pos.c === --- file_pos.c (revision 122529) +++ file_pos.c (working copy) @@ -311,7 +311,6 @@ st_rewind (st_parameter_filepos *fpp) u->endfile = NO_ENDFILE; u->current_record = 0; - u->bytes_left = 0; u->strm_pos = 1; u->read_bad = 0; test_endfile (u); I will prepare a submittal to the list and a test case in the next few days, but this will get you going I hope. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31052
[Bug fortran/31067] MINLOC should sometimes be inlined (gas_dyn is sooooo sloooow)
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-03-08 05:50 --- (In reply to comment #6) > This makes minloc have rank 0, and allows for > inlining. No, it's wrong. See F95 13.14.71: "Result Characteristics. The result is of type default integer. If DIM is absent, the result is an array of rank one and of size equal to the rank of ARRAY; otherwise, the result is of rank n-1 and shape ..." Note in particular the example for case (i), on the next page: "The value of MINLOC((/4,3,6,3/)) is [2]". If DIM is absent, the result is always an array of rank 1. Only if DIM is present, and the ARRAY is of rank 1, then MINLOC is a scalar: MINLOC((/4,3,6,3/),1) == 2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31067
[Bug c/31072] [4.2/4.3 Rgression] Wrong code for volatile var with initalization and optimization
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-03-08 03:41 --- I have a very simple fix to the C front-end that I am testing. The C front-end causes the DECL_RTL to be created early on. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Component|target |c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31072
[Bug c++/31074] [4.1/4.2/4.3 Regression] Reference casting involving multiple inheritance produces bad pointer
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-08 02:09 --- Oh and PR 22132 was already fixed :). And the reason why the patch for PR 22132 did not fix this bug is because comp_ptr_ttypes_const does not take into account REFERENCE_TYPEs. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31074
[Bug c++/31074] [4.1/4.2/4.3 Regression] Reference casting involving multiple inheritance produces bad pointer
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-08 02:06 --- Confirmed, related to PR 22132. The difference between this and that PR is this one has references while that one was only pointers. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||22132 Severity|normal |blocker Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Known to fail||4.0.2 4.1.0 4.2.0 4.3.0 Known to work||3.3.3 Last reconfirmed|-00-00 00:00:00 |2007-03-08 02:06:10 date|| Summary|Reference casting involving |[4.1/4.2/4.3 Regression] |multiple inheritance|Reference casting involving |produces bad pointer|multiple inheritance ||produces bad pointer Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31074
[Bug rtl-optimization/28173] [4.0/4.1 regression] misses constant folding
--- Comment #6 from roger at eyesopen dot com 2007-03-08 01:55 --- I suspect this problem is now fully resolved. The patch for PR24427 has been backported to the gcc-4_1-branch, and additionally on mainline, simplify-rtx.c has been enhanced to also perform the missed-optimization at the RTL level. Given that the 4.0 branch is now closed, I believe this is sufficient to close this PR. -- roger at eyesopen dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28173
[Bug c/30475] assert(int+100 > int) optimized away
--- Comment #54 from pinskia at gcc dot gnu dot org 2007-03-08 01:14 --- (In reply to comment #53) > I read all this and the mailing list thread with great interest, > however I think there is a fundamental flaw in the reasoning: > > C90 6.2.1.2 / C99 6.3.1.3 defines signed integer overflow > as "implementation-defined behaviour", which is something completely > different than "undefined behaviour". Those sections are not about singed integer overflow but conversion between the types which is implementation defined as you shown. If you look at what is being descibed here is conversion between types but overflow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
[Bug c/30475] assert(int+100 > int) optimized away
--- Comment #53 from js at linuxtv dot org 2007-03-08 01:03 --- I read all this and the mailing list thread with great interest, however I think there is a fundamental flaw in the reasoning: C90 6.2.1.2 / C99 6.3.1.3 defines signed integer overflow as "implementation-defined behaviour", which is something completely different than "undefined behaviour". See C90 3.11 vs. 3.18 / C99 3.4.1 vs. 3.4.3. (3.4.1 implementation-defined behavior: "unspecified behavior where each implementation documents how the choice is made"). And lo and behold: http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Integers-implementation.html http://gcc.gnu.org/onlinedocs/gcc-4.0.4/gcc/Integers-implementation.html "For conversion to a type of width N, the value is reduced modulo 2^N to be within range of the type; no signal is raised." (Older versions of gcc left this undocumented.) Of course, software which relies on that is non-portable, but that's different from being "invalid C". If it turns out that many major C compilers use a similar implementation (which is what I expect but have no proof of), then it would be wise if gcc would do the same. E.g. Sun C uses this definitions: http://docs.sun.com/source/819-3688/c90.implementation.app.html#pgfId-998756 "When an integer is converted to a shorter signed integer, the low order bits are copied from the longer integer to the shorter signed integer. The result may be negative." Anyway, gcc should behave as documented, which isn't the case at least for gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
[Bug middle-end/31076] New: ICE with double and unsigned long long with -march=prescott
I use
$ ~/gcc/bin/gcc --version
gcc (GCC) 4.3.0 20070307 (experimental)
to compile
double rdtsc_cputick;
double
rdtsc ()
{
unsigned long eax, edx;
asm volatile ("rdtsc" : "=a" (eax), "=d" (edx));
return rdtsc_cputick * ((unsigned long long) edx << 32 | eax);
}
and I receive the error
$ ~/gcc/bin/gcc -c rdtsc.c -march=prescott
rdtsc.c: In function rdtsc:
rdtsc.c:9: internal compiler error: in gen_split_1956, at
config/i386/sse.md:128
--
Summary: ICE with double and unsigned long long with -
march=prescott
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schnetter at aei dot mpg dot de
GCC build triplet: i386-apple-darwin8.8.1
GCC host triplet: i386-apple-darwin8.8.1
GCC target triplet: i386-apple-darwin8.8.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31076
[Bug c/31075] 2's complement arithmetic (LLONG_MIN-1) works differently with and without optimization
--- Comment #4 from sdirkse at gams dot com 2007-03-07 23:10 --- DOH! I wasn't running the executable compiled with -fwrapv. Using the -fwrapv flag does indeed make things work as I hoped and as documented. -- sdirkse at gams dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31075
[Bug c/31075] 2's complement arithmetic (LLONG_MIN-1) works differently with and without optimization
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-03-07 23:00 --- [EMAIL PROTECTED] ~]$ ~/gcc-mainline/bin/gcc t.c -O2 -fwrapv [EMAIL PROTECTED] ~]$ !./ ./a.out mini64: test 2's-complement arithmetic minint64-1 = 9223372036854775807 minint64 - 1 == MAXINT64 [EMAIL PROTECTED] ~]$ ~/gcc-mainline/bin/gcc t.c -O2 [EMAIL PROTECTED] ~]$ !./ ./a.out mini64: test 2's-complement arithmetic minint64-1 = 9223372036854775807 minint64 - 1 <> MAXINT64 [EMAIL PROTECTED] ~]$ ~/gcc-mainline/bin/gcc -v Using built-in specs. Target: powerpc64-unknown-linux-gnu Configured with: /home/apinski/src/local/gcc/configure --prefix=/home/apinski/gcc-mainline --with-mpfr=/usr/local --with-cpu=default32 Thread model: posix gcc version 4.3.0 20070303 (experimental) Unless something changed in the last two days. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31075
[Bug libstdc++/28080] header dependencies
--- Comment #23 from paolo at gcc dot gnu dot org 2007-03-07 22:59 --- Subject: Bug 28080 Author: paolo Date: Wed Mar 7 22:59:24 2007 New Revision: 122676 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122676 Log: 2007-03-06 Paolo Carlini <[EMAIL PROTECTED]> PR libstdc++/28080 (partial) * include/tr1/random (class random_device): Rework to use simple input, do not include . * include/tr1/random.tcc (all inserters and extractors): Refer to ios_base as base class of basic_istream or basic_ostream. Modified: branches/gcc-4_2-branch/libstdc++-v3/ChangeLog branches/gcc-4_2-branch/libstdc++-v3/include/tr1/random branches/gcc-4_2-branch/libstdc++-v3/include/tr1/random.tcc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28080
[Bug c/31075] 2's complement arithmetic (LLONG_MIN-1) works differently with and without optimization
--- Comment #2 from sdirkse at gams dot com 2007-03-07 22:52 --- Thanks for telling me about the -fwrapv flag, that's good to know - I should have double-checked my K&R 2nd Edition before sending the bug. But I tried running the above example with the addition of the -fwrapv flag, and it didn't change the behavior one bit. Also, I tried a similar example with 32- instead of 64-bit types. It behaved similarly. So, can we call this a bug now? -- sdirkse at gams dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31075
[Bug c++/28879] [4.0/4.1/4.2/4.3 regression] ICE with VLA in template function
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-03-07 22:39 --- *** Bug 31064 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||larsand at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28879
[Bug c++/31064] [4.1/4.2/4.3 Regression] Internal Compiler Error when using operator& from template function
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-07 22:39 --- *** This bug has been marked as a duplicate of 28879 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31064
[Bug target/31072] [4.2/4.3 Rgression] Wrong code for volatile var with initalization and optimization
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-03-07 22:34 --- I was looking at the bug wrong the first time. Anyways this is caused by section anchors. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|normal |blocker Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2007-03-07 22:34:33 date|| Summary|[4.3 Rgression] Wrong code |[4.2/4.3 Rgression] Wrong |for volatile var with |code for volatile var with |initalization and |initalization and |optimization|optimization Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31072
[Bug target/31072] [4.3 Rgression] Wrong code for volatile var with initalization and optimization
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-03-07 22:33 --- Woops. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Component|c |target GCC build triplet|mingw32 | GCC host triplet|mingw32 | GCC target triplet|powerpc-elf |powerpc-linux-gnu, powerpc- ||elf Resolution|INVALID | Summary|Wrong code for volatile var |[4.3 Rgression] Wrong code |with initalization and |for volatile var with |optimization|initalization and ||optimization Version|4.2.0 |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31072
[Bug middle-end/31058] overflow warnings should not be enabled with -Wall
--- Comment #19 from rakdver at atrey dot karlin dot mff dot cuni dot cz 2007-03-07 22:17 --- Subject: Re: overflow warnings should not be enabled with -Wall > IIRC there are some cases that are only caught in the 2nd vrp run. It is still > a possibility if this bug cannot be fixed otherwise. > > However, I don't see the issue with this testcase. > > a) its not a flex array well, it may be a flex array -- it is at the end of the structure. > b) the unrolled loop produces out of bounds accesses > c) hence, the unrolled version cannot ever be used no, this cannot be derived. > d) it shouldn't be produced in the first place. Well, yes, this is true. It is quite unlikely that a programmer would use length of 5 for a tail array, hence we should take this as a hint and avoid prefetching the array. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31058
[Bug middle-end/31058] overflow warnings should not be enabled with -Wall
--- Comment #18 from mueller at gcc dot gnu dot org 2007-03-07 22:03 --- IIRC there are some cases that are only caught in the 2nd vrp run. It is still a possibility if this bug cannot be fixed otherwise. However, I don't see the issue with this testcase. a) its not a flex array b) the unrolled loop produces out of bounds accesses c) hence, the unrolled version cannot ever be used d) it shouldn't be produced in the first place. we can turn this bug about a false positive warning into a code bloat regression by removing the warning (or disabling it from -Wall). That doesn't fix it though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31058
[Bug middle-end/31058] overflow warnings should not be enabled with -Wall
-- mueller at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-07 21:55:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31058
[Bug c++/31027] Compiler segfaults in simple virtual inheritance situation
--- Comment #3 from v dot lesk at ic dot ac dot uk 2007-03-07 21:44 --- Created an attachment (id=13166) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13166&action=view) Code which triggers bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31027
[Bug preprocessor/28709] [4.0/4.1 regression] Bad diagnostic pasting tokens with ##
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-03-07 21:39 --- (In reply to comment #9)> > If none of those are the case, what bit of info am I not understanding? Yes "alldone:" are really two seperate tokens in C :). If you change the definition of LABEL to: #define LABEL(a, b) a##b : it works exactly the same as you want it to work. And yes it is unrelated to this bug really. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28709
[Bug middle-end/31058] overflow warnings should not be enabled with -Wall
--- Comment #17 from gdr at cs dot tamu dot edu 2007-03-07 21:35 --- Subject: Re: bogus array overflow warnings in unrolled loops "rguenth at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | This is why we have this bug -- because loop unrolling creates possibly | unreachable code with out-of-bounds array access. While I don't think removing the warning from -Wall solves the problem, I tend to agree with Andrew Pinski that it should not be included there. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31058
[Bug fortran/31067] MINLOC should sometimes be inlined (gas_dyn is sooooo sloooow)
--- Comment #6 from tkoenig at gcc dot gnu dot org 2007-03-07 21:29 --- Created an attachment (id=13165) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13165&action=view) Setting the correct rank in minloc This makes minloc have rank 0, and allows for inlining. I guess we'll find out now wether the inline code works :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31067
[Bug middle-end/31046] some i386-pf-sse-1.c started to fail on 3/3/07
--- Comment #1 from brett dot albertson at stratech dot com 2007-03-07 21:29 --- (In reply to comment #0) As of last night, these now PASS again. Brett -- brett dot albertson at stratech dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31046
[Bug middle-end/31058] overflow warnings should not be enabled with -Wall
--- Comment #16 from rguenth at gcc dot gnu dot org 2007-03-07 21:25 --- We might now be able to disable the warning in the second vrp pass -- Dirk, did you try that after all the early optimizations we now got? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31058
[Bug middle-end/31058] overflow warnings should not be enabled with -Wall
--- Comment #15 from pinskia at gcc dot gnu dot org 2007-03-07 21:24 --- (In reply to comment #14) > This is why we have this bug -- because loop unrolling creates possibly > unreachable code with out-of-bounds array access. But the warning code is the real cause, sorry but there is no work around from loop unrolling. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|bogus array overflow|overflow warnings should not |warnings in unrolled loops |be enabled with -Wall http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31058
[Bug middle-end/31058] bogus array overflow warnings in unrolled loops
--- Comment #14 from rguenth at gcc dot gnu dot org 2007-03-07 21:22 --- This is why we have this bug -- because loop unrolling creates possibly unreachable code with out-of-bounds array access. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31058
[Bug middle-end/31058] bogus array overflow warnings in unrolled loops
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-03-07 21:22 --- Actually comment #3 shows this warning is not easy to avoid at all and should not be turned on with -Wall at all. I still had allways said it should not be included in -Wall. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31058
[Bug middle-end/31058] bogus array overflow warnings in unrolled loops
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-03-07 21:21 --- (In reply to comment #11) > Sorry, but I don't agree a bit with you. It doesn't have as much false > positives > as other warnings in -Wall. Actually if you read the documention for -Wall, it says enable warnings that are easy to avoid. "This enables all the warnings about constructions that some users consider questionable, and that are easy to avoid (or modify to prevent the warning), even in conjunction with macros. " So really this warning is not easy to avoid in the case of -fprefetch-loop-arrays (or -funroll-loops if it comes and does (non complete) unroll at the tree level). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31058
[Bug fortran/31067] MINLOC should sometimes be inlined (gas_dyn is sooooo sloooow)
--- Comment #5 from tkoenig at gcc dot gnu dot org 2007-03-07 21:09 --- (In reply to comment #3) > In gfc_conv_intrinsic_function, expr->rank is 0 for minval > and 1 for minloc (which is bogus). I wonder where this is > set... To answer my own question: This is set in gfc_resolve_minloc. I'll try to give it a shot. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added CC||tkoenig at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-03-07 12:18:10 |2007-03-07 21:09:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31067
[Bug fortran/31067] MINLOC should sometimes be inlined (gas_dyn is sooooo sloooow)
--- Comment #4 from fxcoudert at gmail dot com 2007-03-07 21:09 --- Subject: Re: MINLOC should sometimes be inlined (gas_dyn is so slw) > In gfc_conv_intrinsic_function, expr->rank is 0 for minval > and 1 for minloc (which is bogus). It's not bogus. The MINLOC is an array of rank 1, that's correct. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31067
[Bug c/28368] -std=c89 doesn't warn about gcc's "?:" extension
--- Comment #5 from joseph at codesourcery dot com 2007-03-07 21:06 --- Subject: Re: -std=c89 doesn't warn about gcc's "?:" extension On Wed, 7 Mar 2007, manu at gcc dot gnu dot org wrote: > Sorry, I still don't understand what is the difference between -std=c89 and > -std=gnu89. -std=c89 accepts C89 programs that conflict with the GNU C89 language. For example, ones using "inline" or "asm" as an identifier, or using any non-reserved identifier predefined as a macro in GNU C (such as "linux" or "i386") or using trigraphs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28368
[Bug fortran/31067] MINLOC should sometimes be inlined (gas_dyn is sooooo sloooow)
--- Comment #3 from tkoenig at gcc dot gnu dot org 2007-03-07 21:00 --- (In reply to comment #2) > No, because we never get into gfc_conv_intrinsic_minmaxloc. We translate the > expression directly into a function call by calling > gfc_conv_intrinsic_funcall() at the head of gfc_conv_intrinsic_function(), > instead of going down the list. I wonder how SUM and PRODUCT are inlined... In gfc_conv_intrinsic_function, expr->rank is 0 for minval and 1 for minloc (which is bogus). I wonder where this is set... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31067
[Bug middle-end/31058] bogus array overflow warnings in unrolled loops
--- Comment #11 from rguenth at gcc dot gnu dot org 2007-03-07 20:54 --- Sorry, but I don't agree a bit with you. It doesn't have as much false positives as other warnings in -Wall. And I think a warning for the testcase in comment #3 is ok -- the code looks very suspicious. Also the testcase in comment #3 has "unreachable" code produced by the programmer, while for the testcase in comment #1 the compiler inserts the unreachable code (and it can either avoid it in this particular case or set TREE_NO_WARNING on the array accesses it produces). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31058
[Bug middle-end/31058] bogus array overflow warnings in unrolled loops
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-03-07 20:37 --- > well, the unrolled body is generated code, it could set TREE_NO_WARNING (for > example). or it could avoid unrolling if its not a flex array. Except it cannot tell sorry, this is exactly the same issue as the bogus warning for the function given in comment #3. To really tell array overflows, you really need to emitt bounds checking. I think this warning should never have ended in VRP, as shown you can get many many bogus warnings. So really I think it might be best to remove the warning and have the C/C++ front-end emits bounds checking when ARRAY_REF and the size is known (for -fbounds-checking). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31058
[Bug c/31075] 2's complement arithmetic (LLONG_MIN-1) works differently with and without optimization
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-07 20:23 --- Signed integer overflow is undefined. Either use unsigned or -fwrapv. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31075
[Bug c/31075] New: 2's complement arithmetic (LLONG_MIN-1) works differently with and without optimization
testing if LLONG_MIN-1 == LLONG_MAX gives different results with -O3 and
without. Here's a short example and the output I get on my machine.
mamie:/home/distrib/lang/pas$cat mini64.c
#include
typedef signed long long int int64;
#define MAXINT64 9223372036854775807LL
#define MININT64 ((-9223372036854775807LL)-1LL)
int main (int argc, char **argv)
{
int64 minint64;
printf ("mini64: test 2's-complement arithmetic\n");
minint64 = MININT64;
printf ("minint64-1 = %lld\n", minint64-1);
if (minint64 - 1 != MAXINT64) {
printf ("minint64 - 1 <> MAXINT64\n");
}
else {
printf ("minint64 - 1 == MAXINT64\n");
}
return 0;
} /* main */
mamie:/home/distrib/lang/pas$gcc -o mini64 mini64.c && ./mini64
mini64: test 2's-complement arithmetic
minint64-1 = 9223372036854775807
minint64 - 1 == MAXINT64
mamie:/home/distrib/lang/pas$gcc -O3 -o mini64 mini64.c && ./mini64
mini64: test 2's-complement arithmetic
minint64-1 = 9223372036854775807
minint64 - 1 <> MAXINT64
mamie:/home/distrib/lang/pas$gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../configure --enable-languages=c,c++,fortran
Thread model: posix
gcc version 4.3.0 20070305 (experimental)
--
Summary: 2's complement arithmetic (LLONG_MIN-1) works
differently with and without optimization
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sdirkse at gams dot com
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31075
[Bug target/30848] [4.1/4.2/4.3 regression] ICE with invalid constraint in asm statement
--- Comment #5 from rth at gcc dot gnu dot org 2007-03-07 19:21 --- Fixed. -- rth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30848
[Bug target/30848] [4.1/4.2/4.3 regression] ICE with invalid constraint in asm statement
--- Comment #4 from rth at gcc dot gnu dot org 2007-03-07 19:18 --- Subject: Bug 30848 Author: rth Date: Wed Mar 7 19:18:22 2007 New Revision: 122672 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122672 Log: PR target/30848 * reg-stack.c (emit_swap_insn): If a malformed asm was seen, silently fix up the stack in the case of a missing register. Added: branches/gcc-4_2-branch/gcc/testsuite/gcc.target/i386/pr30848.c Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/reg-stack.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30848
[Bug target/30848] [4.1/4.2/4.3 regression] ICE with invalid constraint in asm statement
--- Comment #3 from rth at gcc dot gnu dot org 2007-03-07 19:16 --- Subject: Bug 30848 Author: rth Date: Wed Mar 7 19:15:46 2007 New Revision: 122671 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122671 Log: PR target/30848 * reg-stack.c (emit_swap_insn): If a malformed asm was seen, silently fix up the stack in the case of a missing register. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.target/i386/pr30848.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/reg-stack.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30848
[Bug libstdc++/30915] [4.3 regression] bootstrap fails while building libstdc++-v3 on x86_64-pc-linux-gnu
--- Comment #3 from pcarlini at suse dot de 2007-03-07 19:05 --- Well Ahmed, right now you can't possibly see the exact same error, because stl_algobase.h does *not* include anymore... Please provide more info. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30915
[Bug c++/31074] New: Reference casting involving multiple inheritance produces bad pointer
When casting a const reference of a derived class (which inherits from multiple
classes with virtual methods) to a non-const reference of one of it's base
classes, the resulting non-const base class reference points to an incorrect
address.
system type/gcc build options/version:
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/u
sr/share/info --enable-shared --enable-threads=posix --enable-checking=release
-
-with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--with-gx
x-include-dir=/usr/include/c++/3.4.3 --enable-libgcj-multifile
--enable-language
s=c,c++,java,f95 --enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/
jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=x86_64-redhat-linux
Thread model: posix
gcc version 4.1.0 20060515 (Red Hat 4.1.0-18)
command line:
compile code with command /usr/bin/g++4 cast.cpp
execute a.out
compiler output:
no compiler messages
execution of program results in "Segmentation fault"
preprocessed file:
# 1 "cast.cpp"
# 1 "/home/hagin//"
# 1 ""
# 1 ""
# 1 "cast.cpp"
class Shape
{
public:
Shape() {}
virtual ~Shape() {}
};
class Loop
{
public:
Loop() {}
virtual ~Loop() {}
virtual void func() {}
};
class Rect :
public Shape,
public Loop
{
public:
Rect() {}
virtual ~Rect() {}
};
int main ()
{
const Rect* rect = new Rect();
((Loop&)(*rect)).func();
return 0;
}
--
Summary: Reference casting involving multiple inheritance
produces bad pointer
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hagin at us dot ibm dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31074
[Bug preprocessor/28709] [4.0/4.1 regression] Bad diagnostic pasting tokens with ##
--- Comment #9 from ahs3 at fc dot hp dot com 2007-03-07 18:43 ---
Ah, my fault; I wasn't being clear. I still get the error message with -E,
that is true. However, the resulting code from cpp I thought was correct -- it
just produces what I thought was a normal C label, and if I ignore the error
message, I can compile the output from -E just fine. It seems to me that if
cpp no longer recognizes ##, then the message should say so ('deprecated cpp
token', or something); if cpp does recognize ##, then I don't think the error
message should be produced at all since the resulting tokens ('alldone:') are
valid C source.
If none of those are the case, what bit of info am I not understanding? And
I'm still not sure this is the same bug as the original report -- it seems
similar, but let me know if it's something different entirely.
Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28709
[Bug target/30848] [4.1/4.2/4.3 regression] ICE with invalid constraint in asm statement
--- Comment #2 from rth at gcc dot gnu dot org 2007-03-07 18:13 --- Subject: Bug 30848 Author: rth Date: Wed Mar 7 18:13:29 2007 New Revision: 122669 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122669 Log: PR target/30848 * reg-stack.c (emit_swap_insn): If a malformed asm was seen, silently fix up the stack in the case of a missing register. Added: trunk/gcc/testsuite/gcc.target/i386/pr30848.c Modified: trunk/gcc/ChangeLog trunk/gcc/reg-stack.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30848
[Bug c/28368] -std=c89 doesn't warn about gcc's "?:" extension
--- Comment #4 from manu at gcc dot gnu dot org 2007-03-07 18:11 ---
(In reply to comment #3)
> Subject: Re: -std=c89 doesn't warn about gcc's "?:" extension
>
> Where the standard specified with @option{-std} represents a GNU
> extended dialect of C, such as @samp{gnu89} or @samp{gnu99}, there is a
> corresponding @dfn{base standard}, the version of ISO C on which the GNU
> extended dialect is based. Warnings from @option{-pedantic} are given
> where they are required by the base standard. (It would not make sense
> for such warnings to be given only for features not in the specified GNU
> C dialect, since by definition the GNU dialects of C include all
> features the compiler supports with the given option, and there would be
> nothing to warn about.)
>
Sorry, I still don't understand what is the difference between -std=c89 and
-std=gnu89.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28368
[Bug c++/31049] G++ 4.1.1 forgets to allocate memory (skips part of user code)
--- Comment #4 from satyaakam at yahoo dot co dot in 2007-03-07 18:07 --- Created an attachment (id=13164) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13164&action=view) assembly code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31049
[Bug c/28368] -std=c89 doesn't warn about gcc's "?:" extension
--- Comment #3 from joseph at codesourcery dot com 2007-03-07 18:04 ---
Subject: Re: -std=c89 doesn't warn about gcc's "?:" extension
On Wed, 7 Mar 2007, manu at gcc dot gnu dot org wrote:
> The documentation says that you should use -pedantic to warn about GCC
> extensions[*], so I am not sure whether this is valid. But honestly, from the
> description of "-std=", I would understand that GNU extensions are disabled
> when using -std=c89 or that pedantic does not warn for them when using
> -std=gnu89, but neither of those are true.
The key concept is that of base standard, as described in this passage
from invoke.texi:
Where the standard specified with @option{-std} represents a GNU
extended dialect of C, such as @samp{gnu89} or @samp{gnu99}, there is a
corresponding @dfn{base standard}, the version of ISO C on which the GNU
extended dialect is based. Warnings from @option{-pedantic} are given
where they are required by the base standard. (It would not make sense
for such warnings to be given only for features not in the specified GNU
C dialect, since by definition the GNU dialects of C include all
features the compiler supports with the given option, and there would be
nothing to warn about.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28368
[Bug c/28368] -std=c89 doesn't warn about gcc's "?:" extension
--- Comment #2 from manu at gcc dot gnu dot org 2007-03-07 17:57 --- The documentation says that you should use -pedantic to warn about GCC extensions[*], so I am not sure whether this is valid. But honestly, from the description of "-std=", I would understand that GNU extensions are disabled when using -std=c89 or that pedantic does not warn for them when using -std=gnu89, but neither of those are true. [*] http://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html#C-Extensions -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28368
[Bug c/31072] Wrong code for volatile var with initalization and optimization
--- Comment #4 from a_fisch at gmx dot de 2007-03-07 17:43 --- Subject: Re: Wrong code for volatile var with initalization and optimization My runtime environment is clearing .bss but the problem is that the initialization value is != 0 . Because of the value != 0 it's not allowed to be placed in the bss part of sdata. And I'm requesting to reopen 31072 again. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31072
[Bug middle-end/31066] Suboptimal vectorization after inlining
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-03-07 17:19 --- (In reply to comment #1) > actually this function should be inlined as it is a nested function. It is inlined. It's the vectorization of the inlined function that is suboptimal (at least, that's what I diagnose, I'm not 100% sure). -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-07 17:19:30 date|| Summary|Fortran testcase where |Suboptimal vectorization |inlining would be a huge|after inlining |gain| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31066
[Bug middle-end/31066] Fortran testcase where inlining would be a huge gain
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-07 17:15 --- actually this function should be inlined as it is a nested function. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31066
[Bug fortran/31073] symbol names are not created with stdcall syntax
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-07 17:13 ---
> I am trying to compile f90 code into objects that generate the symbol names
> in stdcall syntax, i.e. [EMAIL PROTECTED]
I think you are not looking for -mrtd but for versioned symbols.
-mrtd does:
"Use a different function-calling convention, in which functions that take a
fixed number of arguments return with the "ret" num instruction, which pops
their arguments while returning."
According to the assembler that seems to work. I have frankly no idea how to do
symbol versioning and I have to admit I failed to find any usable information
on the net, the closed comes the glibc implementation notes at:
http://people.redhat.com/drepper/symbol-versioning
By far not sure whether the following works, but it produces the right symbol:
asm(".symver simple_sub, [EMAIL PROTECTED]");
void simple_sub(int *a,int *b)
{
*a = *b;
}
$nm foo.o
T simple_sub
T [EMAIL PROTECTED]
I have no idea how to do it properly and I don't know how to do it in Fortran.
You are probably better off in asking this question in a mailing list.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
CC||burnus at gcc dot gnu dot
||org
Severity|blocker |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31073
[Bug c/31072] Wrong code for volatile var with initalization and optimization
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-03-07 17:11 --- .sbss is .sdata but in the bss part of it. If your loader does not zero bss, then you can use -fno-zero-initialized-in-bss to get the variable not stored in the bss section. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31072
[Bug fortran/31073] New: symbol names are not created with stdcall syntax
GNU Fortran 95 (GCC) 4.3.0 20061021 (experimental), MINGW build I am trying to compile f90 code into objects that generate the symbol names in stdcall syntax, i.e. [EMAIL PROTECTED] We need the stdcall decorations since we build a dll that is called from an app that needs to do all calls with stdcall. I have tried each of the following options without success: -mrtd (gfortran -c -mrtd simple.f): compiles w/o problems, however no stdcall decorations in object nm simple.o: b .bss d .data t .text T _simple_sub_ --enable-stdcall-fixup (gfortran -c --enable-stdcall-fixup simple.f): compile error f951.exe: error: unrecognized command line option "-fenable-stdcall-fixup" --enable-stdcall-alias (gfortran -c --enable-stdcall-alias simple.f): compile error f951.exe: error: unrecognized command line option "-fadd-stdcall-alias" The following code was compiled (simple.f): SUBROUTINE simple_sub(a,b) integer a,b a = b end Any help greatly appreciated! regards Wolfgang -- Summary: symbol names are not created with stdcall syntax Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: wt at simpack dot de GCC build triplet: GNU Fortran 95 (GCC) 4.3.0 20061021 (experimental) GCC host triplet: winXP GCC target triplet: winXP http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31073
[Bug c/31072] Wrong code for volatile var with initalization and optimization
--- Comment #2 from a_fisch at gmx dot de 2007-03-07 15:44 --- Created an attachment (id=13163) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13163&action=view) Generated assembler output: powerpc-elf-gcc -O1 -S -o fg_O1.s fg.i -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31072
[Bug c/31072] Wrong code for volatile var with initalization and optimization
--- Comment #1 from a_fisch at gmx dot de 2007-03-07 15:41 --- Created an attachment (id=13162) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13162&action=view) Preprocessed source of code sample -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31072
[Bug c/31072] New: Wrong code for volatile var with initalization and optimization
I tracked it down to the following code, which is not compiled as expected, if optimization (> O1) is turned on. Contents of fg.c: ---8<--8<-8<--- extern volatile int ReadyFlag_NotProperlyInitialized; volatile int ReadyFlag_NotProperlyInitialized=1; volatile int ReadyFlag_InitializationOk=1; ---8<--8<-8<--- My command line for GCC 4.3-20070223: powerpc-elf-gcc -O1 -S -o fg_O1.s fg.i In the generated assembler output, the variable ReadyFlag_InitializationOk is placed in section .sbss (instead of .sdata) an is initialized with 0 instead of 1. ReadyFlag_InitializationOk is initialized as expected. The only difference is the extern declaration for ReadyFlag_NotProperlyInitialized. Contents of fg_O1.s: ---8<--8<-8<--- .file "fg.c" .globl ReadyFlag_NotProperlyInitialized .globl ReadyFlag_InitializationOk .section.sbss,"aw",@nobits .align 2 .type ReadyFlag_NotProperlyInitialized, @object .size ReadyFlag_NotProperlyInitialized, 4 ReadyFlag_NotProperlyInitialized: .zero 4 .section.sdata,"aw",@progbits .align 2 .type ReadyFlag_InitializationOk, @object .size ReadyFlag_InitializationOk, 4 ReadyFlag_InitializationOk: .long 1 .ident "GCC: (GNU) 4.3.0 20070223 (experimental)" ---8<--8<-8<--- gcc-3.4.6 built with the same system (same build, host and target) is ok! gcc-4.1.2 built with the same system (same build, host and target) is ok! gcc-4.2-20070221 shows the same error as 4.3-20070223 (both built as above) -- Summary: Wrong code for volatile var with initalization and optimization Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: a_fisch at gmx dot de GCC build triplet: mingw32 GCC host triplet: mingw32 GCC target triplet: powerpc-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31072
[Bug c/31069] execve doesn't work correct in some cases
--- Comment #3 from b dot krumboeck at rewe-group dot at 2007-03-07 15:27 --- Oh, you're right! Thank you! I tried to debug for 3 days, without success. Linux, HPUX, GCC 4.X and GCC 3.4.2, . You are a hero! Once again, thank you very much. PS: Sorry for wasting your time. best regards! Bernd -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31069
[Bug c/28368] -std=c89 doesn't warn about gcc's "?:" extension
--- Comment #1 from lloyd at randombit dot net 2007-03-07 14:47 --- This is also true for C++ unless -pedantic is specified (which is confusing since I thought -pedantic-errors was the default for C++, but apparently this changed at some point). Using '-Wall -Wextra -ansi -std=c++98' gives no warning. I'm not sure if it's really a bug, since the GCC docs make it pretty clear that -ansi et. al. are basically useless in terms of getting it to warn you about using extensions, but it is certainly unexpected. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28368
[Bug c/31069] execve doesn't work correct in some cases
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-03-07 14:34 --- Your argv array is too small. -- 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=31069
[Bug c++/16625] Discarded Linkonce sections in .rodata
--- Comment #47 from hjl at lucon dot org 2007-03-07 14:33 --- (In reply to comment #45) > Created an attachment (id=13157) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13157&action=view) [edit] > Patch to configure test for comdat support work with binutils snapshots > > gcc's configure test for COMDAT support seems to work only with regular > releases but not with snapshots, where gld doesn't print a version number: > > $ gld -v > GNU ld version 070227 20070227 > It has been fixed in CVS: bash-3.1$ ./ld/ld-new -V GNU ld (GNU Binutils) 2.17.50.20070307 Supported emulations: elf_x86_64 elf_i386 i386linux -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16625
[Bug middle-end/31068] ICE at -O1 -fipa-pta
--- Comment #1 from dberlin at gcc dot gnu dot org 2007-03-07 14:31 ---
Subject: Re: New: ICE at -O1 -fipa-pta
On 7 Mar 2007 10:32:37 -, fxcoudert at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
> I saw the -fipa-pta option in the GCC manual, and decided to try it on
> mainline. But... I can't get it to work with any C code (or Fortran):
>
> $ cat a.c
> void foo() { ; }
>
> $ gcc -c -O1 -fipa-pta a.c
> a.c: In function 'foo':
> a.c:5: error: stmt (0x2a983e4140) marked modified after optimization pass:
> return;
> a.c:5: internal compiler error: verify_ssa failed
>
> bonzini suggested I asked Daniel if it was expected or not, so... here it is.
>
Honza broke it when he merged IPA SSA changes.
Honza, can i just add TODO_update_ssa to an IPA pass, or is that broken?
If it works, then you can fix this just by adding TODO_update_ssa to
the todo_finish_flags of pass_ipa_pta.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31068
[Bug fortran/31053] print file name when file cannot be opened for writing
--- Comment #3 from tkoenig at gcc dot gnu dot org 2007-03-07 14:24 --- (In reply to comment #2) > I believe this has been fixed already by PR30005 since December 5. Correct. The fix isn't in 4.2 though (which is what I tried :-) Closing as a duplicate of 30005. *** This bug has been marked as a duplicate of 30005 *** -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Known to fail||4.2.0 Known to work||4.3.0 Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31053
[Bug libfortran/30005] Open errors (not/already exists etc.): show also the file name
--- Comment #7 from tkoenig at gcc dot gnu dot org 2007-03-07 14:24 --- *** Bug 31053 has been marked as a duplicate of this bug. *** -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added CC||vivekrao4 at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30005
[Bug other/31071] New: A discrepancy in handling %{...} and %W{...} in function do_spec_1
In spec langauge, %{...} and %W{...} are exactly same, except that %W{...} mark
last argument supplied within as a file to be deleted on failure. According to
this definition, the handling of these two commands is descrepant.
In do_spec_1, the handling of %W{...} is:
4943 case 'W':
{
int cur_index = argbuf_index;
/* Handle the {...} following the %W. */
if (*p != '{')
fatal ("spec '%s' has invalid '%%W%c", spec, *p);
p = handle_braces (p + 1);
if (p == 0)
return -1;
/* End any pending argument. */
4953 if (arg_going)
{
obstack_1grow (&obstack, 0);
string = XOBFINISH (&obstack, const char *);
if (this_is_library_file)
string = find_file (string);
store_arg (string, delete_this_arg, this_is_output_file);
if (this_is_output_file)
outfiles[input_file_number] = string;
arg_going = 0;
4963 }
/* If any args were output, mark the last one for deletion
on failure. */
if (argbuf_index != cur_index)
record_temp_file (argbuf[argbuf_index - 1], 0, 1);
break;
}
This processing I think is correct.
However for %{...}, that is:
5111 case '{':
p = handle_braces (p);
if (p == 0)
return -1;
5115 break;
It's possible for the last pending argument being lose. So suggest add
statements same of line 4953 to 4963 before 5115
--
Summary: A discrepancy in handling %{...} and %W{...} in function
do_spec_1
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wuhui1973 at 21cn dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31071
[Bug c++/31070] New: internal compiler error: in function_arg_slotno, at config/sparc/sparc.c:4562
Aurora SPARC Linux release 2.90 (Aurora Corona)/TI UltraSparc IIi (Sabre) sun4u: binutils-2.17.50.0.3-6.sparc.sparc bison-2.3-2.1.sparc dejagnu-1.4.4-5.1.noarch expect-5.43.0-5.1.sparc gcc-4.1.1-30.1.sparc glibc-2.5-3.1.sparcv9 glibc-2.5-3.1.sparc64 glibc-devel-2.5-3.1.sparc glibc-devel-2.5-3.1.sparc64 glibc-headers-2.5-3.1.sparc gmp-2.4.1 (local build from gcc's infrastructure) mpfr-2.2.1 (local build from gcc's infrastructure) kernel-2.6.18-1.2798.al3.1.sparc64 libgcc-4.1.1-30.1.sparc libgcc-4.1.1-30.1.sparc64 libgcj-4.1.1-30.1.sparc libgcj-4.1.1-30.1.sparc64 libgcj-devel-4.1.1-30.1.sparc libgcj-devel-4.1.1-30.1.sparc64 libstdc++-4.1.1-30.1.sparc libstdc++-4.1.1-30.1.sparc64 libstdc++-devel-4.1.1-30.1.sparc libstdc++-devel-4.1.1-30.1.sparc64 make-3.81-1.1.sparc tcl-8.4.13-3.al3.sparc LAST_UPDATED: Obtained from SVN: tags/gcc_4_1_2_release revision 121944 Native configuration is sparc64-unknown-linux-gnu The g++ testsuite, with -m64, fails (ICE) with these two test cases: Running target unix/-m64 FAIL: tmpdir-g++.dg-struct-layout-1/t026 cp_compat_x_tst.o compile, (internal compiler error) FAIL: tmpdir-g++.dg-struct-layout-1/t026 cp_compat_y_tst.o compile, (internal compiler error) Looking at the log file, we see > FAIL: tmpdir-g++.dg-struct-layout-1/t026 cp_compat_x_tst.o compile, > (internal compiler error) [EMAIL PROTECTED] g++]$ gdb /usr/local/src/branch/objdir/gcc/testsuite/g++/../../g++ GNU gdb Red Hat Linux (6.5-8.al3rh) Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc-redhat-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". (gdb) set args -B/usr/local/src/branch/objdir/gcc/testsuite/g++/../../ -nostdinc++ -I/usr/local/src/branch/objdir/sparc64-unknown-linux-gnu/64/libstdc++-v3/include/sparc64-unknown-linux-gnu -I/usr/local/src/branch/objdir/sparc64-unknown-linux-gnu/64/libstdc++-v3/include -I/usr/local/src/branch/gcc/libstdc++-v3/libsupc++ -I/usr/local/src/branch/gcc/libstdc++-v3/include/backward -I/usr/local/src/branch/gcc/libstdc++-v3/testsuite -fmessage-length=0 -w -I/usr/local/src/branch/gcc/gcc/testsuite/g++.dg/compat -c -m64 -o cp_compat_x_tst.o /usr/local/src/branch/objdir/gcc/testsuite/g++/g++.dg-struct-layout-1/t026_x.C (gdb) r Starting program: /usr/local/src/branch/objdir/gcc/g++ -B/usr/local/src/branch/objdir/gcc/testsuite/g++/../../ -nostdinc++ -I/usr/local/src/branch/objdir/sparc64-unknown-linux-gnu/64/libstdc++-v3/include/sparc64-unknown-linux-gnu -I/usr/local/src/branch/objdir/sparc64-unknown-linux-gnu/64/libstdc++-v3/include -I/usr/local/src/branch/gcc/libstdc++-v3/libsupc++ -I/usr/local/src/branch/gcc/libstdc++-v3/include/backward -I/usr/local/src/branch/gcc/libstdc++-v3/testsuite -fmessage-length=0 -w -I/usr/local/src/branch/gcc/gcc/testsuite/g++.dg/compat -c -m64 -o cp_compat_x_tst.o /usr/local/src/branch/objdir/gcc/testsuite/g++/g++.dg-struct-layout-1/t026_x.C /usr/local/src/branch/objdir/gcc/testsuite/g++/g++.dg-struct-layout-1/t026_test.h: In function $-1òøvoid checkx2400(S2400)òù: /usr/local/src/branch/objdir/gcc/testsuite/g++/g++.dg-struct-layout-1/t026_test.h:1: internal compiler error: in function_arg_slotno, at config/sparc/sparc.c:4562 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. Program exited with code 01. (gdb) bt No stack. (gdb) quit [EMAIL PROTECTED] g++]$ > FAIL: tmpdir-g++.dg-struct-layout-1/t026 cp_compat_y_tst.o compile, > (internal compiler error) [EMAIL PROTECTED] g++]$ gdb /usr/local/src/branch/objdir/gcc/testsuite/g++/../../g++ GNU gdb Red Hat Linux (6.5-8.al3rh) Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc-redhat-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". (gdb) set args -B/usr/local/src/branch/objdir/gcc/testsuite/g++/../../ -nostdinc++ -I/usr/local/src/branch/objdir/sparc64-unknown-linux-gnu/64/libstdc++-v3/include/sparc64-unknown-linux-gnu -I/usr/local/src/branch/objdir/sparc64-unknown-linux-gnu/64/libstdc++-v3/include -I/usr/local/src/branch/gcc/libstdc++-v3/libsupc++ -I/usr/local/src/branch/gcc/libstdc++-v3/include/backward -I/usr/local/src/branch/gcc/libstdc++-v3/testsuite -fmessage-length=0 -w -I/usr/local/src/branch/gcc/gcc/testsuite/g++.dg/compat -c -m64 -o cp_compat_y_tst.o /usr/local/src/branch/objdir/gcc/testsuite/g++/g
[Bug c/31069] execve doesn't work correct in some cases
--- Comment #1 from b dot krumboeck at rewe-group dot at 2007-03-07 12:33 --- Created an attachment (id=13161) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13161&action=view) example code to reproduce the problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31069
[Bug c/31069] New: execve doesn't work correct in some cases
This bug only occurs with gcc 4.x.x on hpux. In certain circumstances the parameter for the environment will be assigned as argument for the command. I've written some code which will show you the exact problem. You need openssl to reproduce this test. The expected output is: Generating a 1024 bit RSA private key ...++ ++ writing new private key to 'server.key' - You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. - Country Name (2 letter code) [AU]:State or Province Name (full name) [Some-State]:Locality Name (eg, city) []:Organization Name (eg, company) [Internet Widgits Pty Ltd]:Organizational Unit Name (eg, section) []:Common Name (eg, YOUR name) []:Email Address []: The same program compiled with gcc 4.x.x: unknown option MYVAR=TEST req [options] outfile where options are -inform arginput format - DER or PEM -outform arg output format - DER or PEM -in arginput file -out arg output file -text text form of request -pubkeyoutput public key -noout do not output REQ -verifyverify signature on REQ -modulus RSA modulus -nodes don't encrypt the output key -engine e use engine e, possibly a hardware device -subject output the request's subject -passinprivate key password source -key file use the private key contained in file -keyform arg key file format -keyout argfile to send the key to -rand file:file:... load the file (or the files in the directory) into the random number generator -newkey rsa:bits generate a new RSA key of 'bits' in size -newkey dsa:file generate a new DSA key, parameters taken from CA in 'file' -[digest] Digest to sign with (md5, sha1, md2, mdc2, md4) -config file request template file. -subj arg set or modify request subject -new new request. -batch do not ask anything during request generation -x509 output a x509 structure instead of a cert. req. -days number of days a certificate generated by -x509 is valid for. -set_serialserial number to use for a certificate generated by -x509. -newhdroutput "NEW" in the header lines -asn1-kludge Output the 'request' in a format that is wrong but some CA's have been reported as requiring -extensions .. specify certificate extension section (override value in config file) -reqexts ..specify request extension section (override value in config file) -utf8 input characters are UTF8 (default ASCII) -nameopt arg- various certificate name options -reqopt arg- various request text options best regards! Bernd -- Summary: execve doesn't work correct in some cases Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: b dot krumboeck at rewe-group dot at GCC build triplet: ia64-hp-hpux11.23 GCC host triplet: ia64-hp-hpux11.23 GCC target triplet: ia64-hp-hpux11.23 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31069
[Bug fortran/31067] MINLOC should sometimes be inlined (gas_dyn is sooooo sloooow)
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-03-07 12:18 --- (In reply to comment #1) > We do this for minval, and from glancing at > gfc_conv_intrinsic_minmaxval and gfc_conv_intrinsic_minmaxloc, > it should happen already. No, because we never get into gfc_conv_intrinsic_minmaxloc. We translate the expression directly into a function call by calling gfc_conv_intrinsic_funcall() at the head of gfc_conv_intrinsic_function(), instead of going down the list. I wonder how SUM and PRODUCT are inlined... -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2007-03-07 11:27:52 |2007-03-07 12:18:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31067
[Bug middle-end/31058] bogus array overflow warnings in unrolled loops
--- Comment #9 from mueller at gcc dot gnu dot org 2007-03-07 11:34 --- well, the unrolled body is generated code, it could set TREE_NO_WARNING (for example). or it could avoid unrolling if its not a flex array. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31058
[Bug fortran/31067] MINLOC should sometimes be inlined (gas_dyn is sooooo sloooow)
--- Comment #1 from tkoenig at gcc dot gnu dot org 2007-03-07 11:27 --- (In reply to comment #0) > Maybe we should have MINLOC inlined when there's no mask, stride 1 and > one-dimensional? Definitely. We do this for minval, and from glancing at gfc_conv_intrinsic_minmaxval and gfc_conv_intrinsic_minmaxloc, it should happen already. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-07 11:27:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31067
[Bug middle-end/31058] bogus array overflow warnings in unrolled loops
--- Comment #8 from rakdver at atrey dot karlin dot mff dot cuni dot cz 2007-03-07 11:02 --- Subject: Re: bogus array overflow warnings in unrolled loops > I don't think this is the same testcase. you will get any warning in this > case, > because the compiler cannot determine that it is supposed to be dead code. it is exactly the same in the unrolled loop case -- compiler cannot determine that the unrolled loop body is a dead code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31058
[Bug middle-end/31058] bogus array overflow warnings in unrolled loops
--- Comment #7 from mueller at gcc dot gnu dot org 2007-03-07 10:59 --- I don't think this is the same testcase. you will get any warning in this case, because the compiler cannot determine that it is supposed to be dead code. -- mueller at gcc dot gnu dot org changed: What|Removed |Added Summary|bogus array overflow|bogus array overflow |warnings in unreachable code|warnings in unrolled loops http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31058
[Bug fortran/30881] Select case of case(transfer(...)) wrongly rejected
--- Comment #4 from pault at gcc dot gnu dot org 2007-03-07 10:53 --- (In reply to comment #3) > fortran/trans-const.c:278 (because the expr is not an EXPR_CONSTANT). This > will > all be fixed when the simplifcation routine for TRANSFER is written. FX, You are correct - this is effectively PR18769. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||18769 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30881
[Bug middle-end/31068] New: ICE at -O1 -fipa-pta
I saw the -fipa-pta option in the GCC manual, and decided to try it on
mainline. But... I can't get it to work with any C code (or Fortran):
$ cat a.c
void foo() { ; }
$ gcc -c -O1 -fipa-pta a.c
a.c: In function foo:
a.c:5: error: stmt (0x2a983e4140) marked modified after optimization pass:
return;
a.c:5: internal compiler error: verify_ssa failed
bonzini suggested I asked Daniel if it was expected or not, so... here it is.
--
Summary: ICE at -O1 -fipa-pta
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fxcoudert at gcc dot gnu dot org
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31068
[Bug fortran/31067] New: MINLOC should sometimes be inlined (gas_dyn is sooooo sloooow)
[see http://www.polyhedron.co.uk/pb05/linux/f90bench_AMD.html for the original polyhedron benchmark results, an explanation of what the benchmark is and the source code] Typical timings for the gas_dyn.f90 benchmark on my AMD64/linux system are: * ifort -O3 -xW -ipo -static -V gas_dyn.f90 -o gas_dyn.intel => ./gas_dyn.intel 10.53s user 0.43s system 99% cpu 10.976 total * gfortran -static -ftree-vectorize -march=opteron -ffast-math -funroll-loops -O3 gas_dyn.f90 -o gas_dyn.gfortran ./gas_dyn.gfortran 15.92s user 0.05s system 99% cpu 15.969 total Experimenting a bit with Intel options to understand why it is so fast, I found that: * disabling inlining doesn't change the execution time * disabling vectorization drops it to the same execution time as gfortran (roughly speaking) Following an analysis by Tobias Burnus, and noting that 22.16% of the total time is spent in the MINLOC library routine, I modified the source by replacing a call to MINLOC by inline code: --- gas_dyn.f90 2007-03-07 09:36:23.0 +0100 +++ gas_dyn.modified.f902007-03-07 10:44:14.0 +0100 @@ -234,12 +234,23 @@ end module ints !--- ! L o c a l V a r i a b l e s !--- - INTEGER :: ISET(1) - REAL :: VSET, SSET + INTEGER :: ISET(1), I + REAL :: VSET, SSET, T REAL, DIMENSION (NODES) :: DTEMP !--- DTEMP = DX/(ABS(VEL) + SOUND) - ISET = MINLOC (DTEMP) +! FXC replace this: +! ISET = MINLOC (DTEMP) +! by this: + ISET(1) = 0 + T = HUGE(T) + DO I = 1, NODES +IF (DTEMP(I) < T) THEN + T = DTEMP(I) + ISET(1) = I +END IF + END DO +! end of modification DT = DTEMP(ISET(1)) VSET = VEL(ISET(1)) SSET = SOUND(ISET(1)) this makes the code faster by 14%: ./gas_dyn.modified.gfortran 13.56s user 0.05s system 99% cpu 13.614 total Maybe we should have MINLOC inlined when there's no mask, stride 1 and one-dimensional? PS: Other hot spots are: % cumulative self self total time seconds secondscalls Ts/call Ts/call name 29.13 4.18 4.18 eos_ (gas_dyn.f90:410 @ 413386) 14.22 6.22 2.04 chozdt_ (gas_dyn.f90:241 @ 4152b3) Both lines are whole-array operations, corresponding to: CS(:NODES) = SQRT(CGAMMA*PRES(:NODES)/DENS(:NODES)) and DTEMP = DX/(ABS(VEL) + SOUND) I filed PR31066, which is I think a small reproducer for the two lines above. -- Summary: MINLOC should sometimes be inlined (gas_dyn is so slw) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org BugsThisDependsOn: 31066 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31067
[Bug c++/16625] Discarded Linkonce sections in .rodata
--- Comment #46 from michael dot klein at fazi dot de 2007-03-07 10:20 --- Created an attachment (id=13158) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13158&action=view) Non-reversed patch to make configure test for comdat support work with binutils snapshots -- michael dot klein at fazi dot de changed: What|Removed |Added Attachment #13157|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16625
[Bug middle-end/31066] New: Fortran testcase where inlining would be a huge gain
On the following testcase: program test integer, parameter :: n = 25000 integer :: i real, dimension(n) :: iener, dens, pres, temp, gamma, cs do i = 1, 3 call eos (iener, dens, pres, temp, gamma, cs, sheat, cgamma) end do contains subroutine eos (iener, dens, pres, temp, gamma, cs, sheat, cgamma) real sheat, cgamma real, dimension(n) :: iener, dens, pres, temp, gamma, cs temp(:n) = iener(:n)/sheat pres(:n) = (cgamma - 1.0)*dens(:n)*iener(:n) gamma(:n) = cgamma cs(:n) = sqrt(cgamma*pres(:n)/dens(:n)) end subroutine eos end program test (derived from the Polyhedron gas_dyn.f90 benchmark), the Intel compiler gains 50% execution speedup by inlining the subroutine when vectorization is enabled (from 9.0s to 4.4s on my AMD64/linux, using option -ip in addition to -O3 -xW). gfortran does inline the eos_ subroutine also, but it somehow doesn't use it for better vectorization, and it stays at the same execution time (around 10s). -- Summary: Fortran testcase where inlining would be a huge gain Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31066
[Bug c++/16625] Discarded Linkonce sections in .rodata
--- Comment #45 from michael dot klein at fazi dot de 2007-03-07 10:13 --- Created an attachment (id=13157) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13157&action=view) Patch to configure test for comdat support work with binutils snapshots gcc's configure test for COMDAT support seems to work only with regular releases but not with snapshots, where gld doesn't print a version number: $ gld -v GNU ld version 070227 20070227 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16625
[Bug debug/26881] [4.1 Regression] internal compiler error in dwarf2out_finish
--- Comment #29 from rguenth at gcc dot gnu dot org 2007-03-07 10:09 --- *** Bug 31065 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||bugzilla at poradnik- ||webmastera dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26881
[Bug c/31065] ICE while building SpiderMonkey 1.60
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-03-07 10:09 --- *** This bug has been marked as a duplicate of 26881 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31065
[Bug c++/31064] [4.1/4.2/4.3 Regression] Internal Compiler Error when using operator& from template function
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-07 10:07 ---
Confirmed. For reference:
struct Dummy
{
int operator&(signed int &) { return 4; }
};
struct ICE
{
template
void aj(void)
{
signed int kalle = 9;
int size = Dummy() & kalle;
char buffer[size];
}
};
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||rejects-valid
Known to fail||3.4.6 4.0.4 4.1.2
Known to work||3.3.6
Last reconfirmed|-00-00 00:00:00 |2007-03-07 10:07:21
date||
Summary|Internal Compiler Error when|[4.1/4.2/4.3 Regression]
|using operator& from|Internal Compiler Error when
|template function |using operator& from
||template function
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31064
[Bug fortran/30940] Fortran 2003: Scalar CHARACTER supplied to array dummy
--- Comment #1 from pault at gcc dot gnu dot org 2007-03-07 09:55 --- Confirmed Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-07 09:55:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30940
[Bug fortran/31011] Incorrect error: parameter array sections
--- Comment #1 from pault at gcc dot gnu dot org 2007-03-07 09:41 --- confirmed - this is an arithmetic error in expr.c(find_array_section). The following fixes the problem, although it has not yet been regtested. Paul Index: gcc/fortran/expr.c === *** gcc/fortran/expr.c (révision 122159) --- gcc/fortran/expr.c (copie de travail) *** find_array_section (gfc_expr *expr, gfc_ *** 1137,1144 } /* Calculate the number of elements and the shape. */ ! mpz_abs (tmp_mpz, stride[d]); ! mpz_div (tmp_mpz, stride[d], tmp_mpz); mpz_add (tmp_mpz, end[d], tmp_mpz); mpz_sub (tmp_mpz, tmp_mpz, ctr[d]); mpz_div (tmp_mpz, tmp_mpz, stride[d]); --- 1137,1143 } /* Calculate the number of elements and the shape. */ ! mpz_set (tmp_mpz, stride[d]); mpz_add (tmp_mpz, end[d], tmp_mpz); mpz_sub (tmp_mpz, tmp_mpz, ctr[d]); mpz_div (tmp_mpz, tmp_mpz, stride[d]); -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-03-01 18:02:09 |2007-03-07 09:41:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31011
[Bug middle-end/31058] bogus array overflow warnings in unreachable code
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-03-07 09:39 --- Uh, yes. So let's teach CCP to convert a[110]++; to builtin_trap then ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31058
[Bug middle-end/31058] bogus array overflow warnings in unreachable code
--- Comment #5 from rakdver at atrey dot karlin dot mff dot cuni dot cz 2007-03-07 09:38 --- Subject: Re: bogus array overflow warnings in unreachable code > But real length of a cannot be greater than 100. I guess VRP could be > improved > to derive a value range for x in this case ... I think that in VRP, x is already eliminated, i.e., the code looks like if (real_length > 110) a[110]++; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31058
[Bug middle-end/31058] bogus array overflow warnings in unreachable code
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-03-07 09:33 --- But real length of a cannot be greater than 100. I guess VRP could be improved to derive a value range for x in this case ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31058
[Bug middle-end/31058] bogus array overflow warnings in unreachable code
--- Comment #3 from rakdver at gcc dot gnu dot org 2007-03-07 09:15 ---
The same problem appears in the following testcase.
int a[100];
void test (int real_length_of_a)
{
int x = 110;
if (x < real_length_of_a)
a[x]++;
}
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
Summary|array overflow warning due |bogus array overflow
|to incorrect loop unrolling |warnings in unreachable code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31058
[Bug c/31065] ICE while building SpiderMonkey 1.60
--- Comment #1 from bugzilla at poradnik-webmastera dot com 2007-03-07 08:32 --- Created an attachment (id=13156) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13156&action=view) Preprocessor output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31065
[Bug c/31065] New: ICE while building SpiderMonkey 1.60
I tried to build SpiderMonkey 1.60 (http://www.mozilla.org/js/spidermonkey/) on SunOS 5.9/SPARC, and I got this ICE. That code compiles successfully using GCC 4.1.1 bundled with Linux Fedora Core 6 (x86, 32-bit). gcc -o SunOS5.9_DBG.OBJ/jscpucfg.o -c -g -DXP_UNIX -DSVR4 -DSYSV -DSOLARIS -DHAVE_LOCALTIME_R -DDEBUG -DDEBUG_daniel -DEDITLINE -ISunOS5.9_DBG.OBJ jscpucfg.c jscpucfg.c:374: internal compiler error: in dwarf2out_finish, at dwarf2out.c:14117 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. # gcc --ver Using built-in specs. Target: sparc-sun-solaris2.9 Configured with: ../gcc-4.1.1/configure --prefix=/tools/gcc-4.1.1 --with-gnu-as --with-gnu-ld --with-as=/tools/gnu/bin/as --with-ld=/tools/gnu/bin/ld --with-gmp=/tools/gnu --with-mpfr=/tools/gnu Thread model: posix gcc version 4.1.1 # gcc --version gcc (GCC) 4.1.1 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. -- Summary: ICE while building SpiderMonkey 1.60 Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bugzilla at poradnik-webmastera dot com GCC build triplet: sparc-sun-solaris2.9 GCC host triplet: sparc-sun-solaris2.9 GCC target triplet: sparc-sun-solaris2.9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31065
[Bug tree-optimization/21596] [4.0/4.1/4.2/4.3 Regression] extra temporaries when using global register variables
--- Comment #10 from bonzini at gnu dot org 2007-03-07 08:22 --- Unfortunately, if I fix the fwprop bug (which is actually caused by wrong df information), I get again leal-4(%edi), %eax movl%eax, %edi movl(%eax), %eax testl %eax, %eax The df bug is fixed by: Index: ../../base-gcc-src/gcc/df-scan.c === --- ../../base-gcc-src/gcc/df-scan.c(revision 122624) +++ ../../base-gcc-src/gcc/df-scan.c(working copy) @@ -1833,6 +1833,13 @@ df_record_entry_block_defs (struct dataf #endif } + /* Mark all global registers as being defined at the entry of the + function since values set by our caller should not be treated as + uninitialized. */ + for (i = 0; i < FIRST_PSEUDO_REGISTER; i++) +if (global_regs[i]) + bitmap_set_bit (df->entry_block_defs, i); + /* Once the prologue has been generated, all of these registers should just show up in the first regular block. */ if (HAVE_prologue && epilogue_completed) -- bonzini at gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21596
