[Bug libfortran/25697] libfortran - Segmentation fault/ Bad Address on unformatted read
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2006-01-12 06:46 --- This is interesting. I noticed before that with the previous test case i could get two different error message depending on the size of the data. I will have to study this a bit closer. BTW Thanks for the testing. We really wantthis I/O bullet proof as we can get it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25697
[Bug fortran/25062] same name for parameter and common block
--- Comment #7 from kargl at gcc dot gnu dot org 2006-01-12 05:25 --- See 14.1.2.1. A common block name in a scoping unit also may be the name of any local entity other than a named constant, intrinsic procedure, or a local variable that is also an external function in a function subprogram. -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||kargl at gcc dot gnu dot org Last reconfirmed|2006-01-11 23:46:46 |2006-01-12 05:25:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25062
[Bug target/25758] New: gcc.c-torture/compile/20030921-1.c fails at -O0
The fix is:
Index: i386.c
===
--- i386.c (revision 109602)
+++ i386.c (working copy)
@@ -6680,6 +6682,8 @@ output_pic_addr_const (FILE *file, rtx x
break;
case SYMBOL_REF:
+ if (SYMBOL_REF_DECL (x))
+ mark_decl_referenced (SYMBOL_REF_DECL (x));
assemble_name (file, XSTR (x, 0));
if (!TARGET_MACHO && code == 'P' && ! SYMBOL_REF_LOCAL_P (x))
fputs ("@PLT", file);
-
But I cannot test it at all
--
Summary: gcc.c-torture/compile/20030921-1.c fails at -O0
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: assemble-failure
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
GCC target triplet: i686-apple-darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25758
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #33 from hhinnant at apple dot com 2006-01-12 02:49 ---
(In reply to comment #32)
> As I said before, there is still a diagnostic issue and now it is worse
> with
> doing that in the front-end since people don't read docs that well so
> we will
> be getting bug reports about try/catch not doing the correct thing when
> -fno-exceptions is supplied (yes I am serious).
Yes, excellent point. Let's back up a minute:
What do we want to happen for this program (under -fno-exceptions)?
int main()
{
try
{
}
catch (...)
{
}
}
?
My recommendation would be something along the lines of:
error: exception handling disabled, use -fexceptions to enable
(which is what currently happens, good job all around).
Now: what do we want to happen for this program:
#include
int main()
{
try
{
}
catch (...)
{
}
}
?
My recommendation: Same as the last program. Today's results: Compiles with
no diagnostic.
I don't think this is the best quality that we can offer, mainly due to the
difference in behavior by merely including .
So it comes back to the first example: What is the best solution for the
customer if try/catch is used with -fno-exceptions? Perhaps I am wrong that an
error is best? What do other compilers do in this situation?
EDG:
"ComeauTest.c", line 3: error: support for exception handling is disabled
try
^
CodeWarrior:
Error : exception handling option is disabled
HelloWorld.cp line 4{
If I'm wrong about a diagnostic being preferrable, I'm in good company. And
both of these products give the same result if is included.
If there is to be a front end fix, it would have to be special for #pragma GCC
system_header. Just seems like a lot of fuss just so you can read "try"
instead of "__try" in a libstdc++ header. But I have no objection to someone
fixing the front end that way.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug target/24959] Trampolines fail on i686-apple-darwin because stack is not executable
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-01-12 01:57 --- I will submit this. -- 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 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24959
[Bug target/24959] Trampolines fail on i686-apple-darwin because stack is not executable
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-01-12 01:56 --- gcc.c-torture/execute/2822-1.c fails the same way. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24959
[Bug testsuite/25728] File descriptor leak in lib/gcov.exp
--- Comment #6 from hjl at lucon dot org 2006-01-12 01:47 --- Fixed. -- hjl at lucon dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25728
[Bug testsuite/25728] File descriptor leak in lib/gcov.exp
--- Comment #5 from hjl at gcc dot gnu dot org 2006-01-12 01:45 --- Subject: Bug 25728 Author: hjl Date: Thu Jan 12 01:45:54 2006 New Revision: 109632 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109632 Log: 2006-01-11 H.J. Lu <[EMAIL PROTECTED]> PR testsuite/25728 * lib/gcov.exp (verify-lines): Add "close $fd". Modified: branches/gcc-3_4-branch/gcc/testsuite/ChangeLog branches/gcc-3_4-branch/gcc/testsuite/lib/gcov.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25728
[Bug testsuite/25728] File descriptor leak in lib/gcov.exp
--- Comment #4 from hjl at gcc dot gnu dot org 2006-01-12 01:40 --- Subject: Bug 25728 Author: hjl Date: Thu Jan 12 01:40:48 2006 New Revision: 109631 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109631 Log: 2006-01-11 H.J. Lu <[EMAIL PROTECTED]> PR testsuite/25728 * lib/gcov.exp (verify-lines): Add "close $fd". Modified: branches/gcc-4_0-branch/gcc/testsuite/ChangeLog branches/gcc-4_0-branch/gcc/testsuite/lib/gcov.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25728
[Bug testsuite/25728] File descriptor leak in lib/gcov.exp
--- Comment #3 from hjl at gcc dot gnu dot org 2006-01-12 01:35 --- Subject: Bug 25728 Author: hjl Date: Thu Jan 12 01:35:21 2006 New Revision: 109628 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109628 Log: 2006-01-11 H.J. Lu <[EMAIL PROTECTED]> PR testsuite/25728 * lib/gcov.exp (verify-lines): Add "close $fd". Modified: branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/lib/gcov.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25728
[Bug testsuite/25728] File descriptor leak in lib/gcov.exp
--- Comment #2 from hjl at gcc dot gnu dot org 2006-01-12 01:29 --- Subject: Bug 25728 Author: hjl Date: Thu Jan 12 01:29:07 2006 New Revision: 109627 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109627 Log: 2006-01-11 H.J. Lu <[EMAIL PROTECTED]> PR testsuite/25728 * lib/gcov.exp (verify-lines): Add "close $fd". Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/lib/gcov.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25728
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #32 from pinskia at gcc dot gnu dot org 2006-01-12 01:26 --- Subject: Re: exception_defines.h #defines try/catch On Jan 11, 2006, at 8:10 PM, gdr at cs dot tamu dot edu wrote: > | I realize that once the customer specifies -fno-exceptions, all bets > | are off. > > Great. Fix the problem in the front-end. As I said before, there is still a diagnostic issue and now it is worse with doing that in the front-end since people don't read docs that well so we will be getting bug reports about try/catch not doing the correct thing when -fno-exceptions is supplied (yes I am serious). -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
Re: [Bug libstdc++/25191] exception_defines.h #defines try/catch
On Jan 11, 2006, at 8:10 PM, gdr at cs dot tamu dot edu wrote: | I realize that once the customer specifies -fno-exceptions, all bets | are off. Great. Fix the problem in the front-end. As I said before, there is still a diagnostic issue and now it is worse with doing that in the front-end since people don't read docs that well so we will be getting bug reports about try/catch not doing the correct thing when -fno-exceptions is supplied (yes I am serious). -- Pinski
[Bug target/25613] [4.0 Regression] sh compiler hangs when compiling some inline asm
--- Comment #6 from kkojima at gcc dot gnu dot org 2006-01-12 01:20 --- Subject: Bug 25613 Author: kkojima Date: Thu Jan 12 01:20:32 2006 New Revision: 109625 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109625 Log: PR target/25613 * config/sh/sh.h (CONSTRAINT_LEN): Use unchecking version. Modified: branches/gcc-3_4-branch/gcc/ChangeLog branches/gcc-3_4-branch/gcc/config/sh/sh.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25613
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #31 from gdr at cs dot tamu dot edu 2006-01-12 01:15 --- Subject: Re: exception_defines.h #defines try/catch "hhinnant at apple dot com" <[EMAIL PROTECTED]> writes: [...] | I'm simply pointing out that the effort could be improved. | Obviously no standard is going to back this view up. Great. Then stopping making conformance claims. Also consider the suggestion made earlier that the root of the problem is elsewhere -- extend the front-end to be complete. | We have a conforming C++ program, which does not use try/catch/throw, it uses the identifier "try". | which | works as expected under -fno-exceptions if you don't include , and | breaks if you do. I think libstdc++ can and should do better than that. We | have customer complaints on this issue. I'm developing a library-based patch | to improve our support in this area. given than bkoz and I have already expressed our suggestion of no further uglification of libstdc++, I'm waiting to see how the library-based patch would look like. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #30 from gdr at cs dot tamu dot edu 2006-01-12 01:10 --- Subject: Re: exception_defines.h #defines try/catch "hhinnant at apple dot com" <[EMAIL PROTECTED]> writes: | (In reply to comment #28) | > Subject: Re: exception_defines.h #defines try/catch | > | > | No, "try" in this context is not a keyword. | > | > I did not say it was a keyword. I know what it is in that phase. | > | > try/catch are special when -fno-exceptions. | | In the preprocess stage, try/catch are not special when -fno-exceptions | according to the compiler. They are for libstdc++. You can debate at length. You won't change that fundamental fact. However, you'll make progress, when you recognize that and solve the problem where it should be. [...] | I realize that once the customer specifies -fno-exceptions, all bets | are off. Great. Fix the problem in the front-end. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #29 from hhinnant at apple dot com 2006-01-12 00:59 ---
(In reply to comment #28)
> Subject: Re: exception_defines.h #defines try/catch
>
> | No, "try" in this context is not a keyword.
>
> I did not say it was a keyword. I know what it is in that phase.
>
> try/catch are special when -fno-exceptions.
In the preprocess stage, try/catch are not special when -fno-exceptions
according to the compiler. They are only special at this stage according to
libstdc++, and for no reason I find convincing.
> | > Can you provide standard specs that says the program must work with
> | > -fno-exceptions?
> |
> | Of course not.
>
> Then stop claiming that your use was conformant.
*No* program is conformant if it uses -fno-exceptions (by definition). I'm
claiming that this demo is conforming if it does not use -fno-exceptions. I'm
also claiming that it does not use the C++ try, catch, or throw, and therefore
is an excellent candidate to work correctly under -fno-exceptions.
> | I would rather not document that the libstdc++ takes a position
> | contrary to the compiler
>
> It does not take a position contrary to the compiler. It complements
> the compiler, with its own additional requirement. That is not new.
The mere inclusion of breaks the conforming C++ program (under
-fno-excepttions).
#include
#include
#define glue(a, b) a ## b
#define xglue(a, b) glue(a, b)
#define tryLOW "hello"
#define LOW LOW ", world"
int main()
{
printf("%s\n", xglue(try, LOW));
}
I realize that once the customer specifies -fno-exceptions, all bets are off.
Nothing has to work. Not g++, not libstdc++. But there has obviously been
effort to make g++ and libstdc++ work under this environment. I'm simply
pointing out that the effort could be improved. Obviously no standard is going
to back this view up.
We have a conforming C++ program, which does not use try/catch/throw, which
works as expected under -fno-exceptions if you don't include , and
breaks if you do. I think libstdc++ can and should do better than that. We
have customer complaints on this issue. I'm developing a library-based patch
to improve our support in this area.
> The way you solve this is to make the front-end complete
If you want to lead an effort to improve support of this issue in the front
end, that sounds really good to me. Please do. Note that this solution will
still involve libstdc++ being changed to not #define try and catch (which is
the fundamental problem).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug fortran/25062] same name for parameter and common block
--- Comment #6 from tobi at gcc dot gnu dot org 2006-01-12 00:18 --- I'm setting this to waiting until someone quotes something from the standard. Fortran has its quirks, but disallowing this special case would break the distintion between the names of commons and those of other named objects, which is otherwise maintained, so I'm sure this is valid code. But since being sure is not sufficient, I also checked the standard and I couldn't find anything disallowing this case. -- tobi at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25062
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #28 from gdr at cs dot tamu dot edu 2006-01-12 00:12 --- Subject: Re: exception_defines.h #defines try/catch "hhinnant at apple dot com" <[EMAIL PROTECTED]> writes: | --- Comment #26 from hhinnant at apple dot com 2006-01-11 18:02 --- | (In reply to comment #25) | > Subject: Re: exception_defines.h #defines try/catch | > | The demo program does not play tricks with try/catch. | > | > It does, with xlgue(try, ). | | No, "try" in this context is not a keyword. I did not say it was a keyword. I know what it is in that phase. try/catch are special when -fno-exceptions. [...] | > Can you provide standard specs that says the program must work with | > -fno-exceptions? | | Of course not. Then stop claiming that your use was conformant. [...] | I would rather not document that the libstdc++ takes a position | contrary to the compiler It does not take a position contrary to the compiler. It complements the compiler, with its own additional requirement. That is not new. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #27 from gdr at cs dot tamu dot edu 2006-01-12 00:12 --- Subject: Re: exception_defines.h #defines try/catch "hhinnant at apple dot com" <[EMAIL PROTECTED]> writes: | Or are our quality standards higher than that? The way you solve this is neither through rhetorics, neither as a libstdc++ PR. The way you solve this is to make the front-end complete -- try/catch are special with -fno-exceptions. Really. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug tree-optimization/25734] [4.2 Regression] ice for legal kernel code with -Os
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-01-12 00:09 --- Subject: Bug 25734 Author: rguenth Date: Wed Jan 11 19:44:57 2006 New Revision: 109598 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109598 Log: 2006-01-11 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/25734 * tree-ssa-forwprop.c (forward_propagate_addr_expr_1): Do not stop propagation after successful propagation to the LHS. * gcc.dg/tree-ssa/pr25734.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr25734.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-forwprop.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25734
[Bug testsuite/20567] dg-options in gcc.c-torture
--- Comment #3 from janis at gcc dot gnu dot org 2006-01-11 22:21 --- It's easy to replace gcc.c-torture/execute/execute.exp with compile/compile.exp, use "run" for the default instead of "assemble", and then add test directives to the .c files to replace the functionaity in the .x files. There are a couple of things that lib/c-torture.exp does that are not supported with this: if the test isn't executed on native hardware, skip execution of a test whose binary is identical to the binary built with the previous set of options skip execution of tests that use "long long" when it isn't supported on the target There are a few odd things in gcc/c-torture/execute/*.c: 920710-1.x skips a "long long" test based on a specific target, but there are lots of tests that use "long long" and aren't skipped 941014-1.x tries to xfail the compile step, but in a way where the xfail info is evaluated after the compile has already happened; also, it checks for either -mthumb or -O0; does it really want the combination? 981130-1.x xfails the test for -O0, -O1, -O2, or -Os when the comment implies that it should be xfailed for -O2 or -O3 990413-2.x says the test is x86 specific; should it be limited to ilp32? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20567
[Bug rtl-optimization/24376] wrong-code unless -fno-sched-interblock
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-01-11 23:46:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24376
[Bug c++/25386] packed structs
--- Comment #2 from nathan at gcc dot gnu dot org 2006-01-11 22:03 --- Subject: Bug 25386 Author: nathan Date: Wed Jan 11 18:09:17 2006 New Revision: 109595 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109595 Log: PR c++/25386 * tree.c (lvalue_p_1): Any part of a COMPONENT_REF affects packedness. * g++.dg/ext/packed3.C: Add expected packed error. Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/tree.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/packed3.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25386
[Bug fortran/24886] another runtime error goes undetected
--- Comment #6 from uttamp at us dot ibm dot com 2006-01-11 22:02 --- Subject: Re: another runtime error goes undetected On Wed, 2006-01-11 at 09:07 +, pault at gcc dot gnu dot org wrote: > > --- Comment #5 from pault at gcc dot gnu dot org 2006-01-11 09:07 --- > (In reply to comment #4) > > This is not a bug. gfortran behavior is identical to ifort. > > > Actually, it is quite specifically NOT permitted by the standard. To quote > 12.4.1.1: > > "If a scalar dummy argument is of type default character, the length len of > the > dummy argument shall be less than or equal to the length of the actual > argument. The dummy argument becomes associated with the leftmost len > characters of the actual argument. If an array dummy argument is of type > default character, the restriction on the length is for the entire array and > not for each array element." > > The reason for this is obvious enough; try writing beyond len and you will > eventually get a seg fault. > > Uttam is quite correct to pick this out as a bug, although I am not sure that > we want a runtime error, except when -fbounds-check is active. This could be > implemented, with advantage in trans-expr(gfc_conv_function_call) by copying > over some of the code from trans-array.c. Compile time check will be much better fix than the runtime. > > As it happens, in building a fix for PRs 20881, 23308 & 25710, I am about to > add "same file" argument checking, which is why I encountered this PR. It > will > fix Uttam's testcase but not the case where subroutine foo is truly external. > - Uttam -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24886
[Bug other/25757] New: Small memory leak in 'prefix_from_string' of file 'collect2.c'
In function 'prefix_from_string' of file 'collect2.c', a variable 'nstore' is xmalloc'ed. This variable is passed to 'add_prefix' where it is xstrdup'ed. But the variable nstore itself seems to never be free'ed. So, I think that a 'free(nstore)' should be added at the end of the function. CJ -- Summary: Small memory leak in 'prefix_from_string' of file 'collect2.c' Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: christophe dot jaillet at wanadoo dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25757
[Bug fortran/25756] ICE on valid code with labels
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-01-11 21:41 --- Confirmed. (well already via IRC). Note you will not get this email for a while anyways. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2006-01-11 21:41:00 date|| Summary|ICE on valid code |ICE on valid code with ||labels http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25756
[Bug fortran/25756] ICE on valid code
--- Comment #3 from aldot at gcc dot gnu dot org 2006-01-11 21:34 --- Created an attachment (id=10628) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10628&action=view) testcase label_5.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25756
[Bug fortran/25756] ICE on valid code
--- Comment #2 from aldot at gcc dot gnu dot org 2006-01-11 21:33 --- Created an attachment (id=10627) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10627&action=view) testcase label_4.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25756
[Bug fortran/25486] [4.1/4.2 Regression] fortran fixed-form literal character constant not padded.
--- Comment #14 from aldot at gcc dot gnu dot org 2006-01-11 21:37 --- Sure, will fix the changelog tomorrow, sorry! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25486
[Bug fortran/25756] ICE on valid code
--- Comment #1 from aldot at gcc dot gnu dot org 2006-01-11 21:32 --- Created an attachment (id=10626) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10626&action=view) testcase label_3.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25756
[Bug rtl-optimization/25654] [4.0/4.1/4.2 Regression] RTL alias analysis unprepared to handle stack slot sharing
-- steven at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25654
[Bug fortran/25756] New: ICE on valid code
attached label_3.f90, label_4.f90 and label_5.f90 ICE with
gcc version 4.1.0 20060111 (prerelease)
As this worked with g77, please make pr19292 depend on this.
Backtraces are provided for the sake of completeness.
$ gfortran-4.1-HEAD -v -c -o /tmp/foo.o label_3.f90
In file label_3.f90:4
1 ! { dg-warning "Ignoring statement label in empty statement" }
1
Warning: Ignoring statement label in empty statement at (1)
label_3.f90:5: internal compiler error: Segmentation fault
backtrace label_3.f90:
Program received signal SIGSEGV, Segmentation fault.
free_expr0 (e=0x12) at ../../../src/gcc-4.1/gcc/fortran/expr.c:141
141 switch (e->expr_type)
(gdb) bt
#0 free_expr0 (e=0x12) at ../../../src/gcc-4.1/gcc/fortran/expr.c:141
#1 0x0805f161 in gfc_free_expr (e=0x12) at
../../../src/gcc-4.1/gcc/fortran/expr.c:230
#2 0x08090663 in gfc_free_namespace (ns=0x8564d30) at
../../../src/gcc-4.1/gcc/fortran/symbol.c:1504
#3 0x08090728 in gfc_symbol_done_2 () at
../../../src/gcc-4.1/gcc/fortran/symbol.c:2393
#4 0x080783f8 in gfc_done_2 () at ../../../src/gcc-4.1/gcc/fortran/misc.c:293
#5 0x0807f1fe in gfc_parse_file () at
../../../src/gcc-4.1/gcc/fortran/parse.c:2685
#6 0x08098593 in gfc_be_parse_file (set_yydebug=0) at
../../../src/gcc-4.1/gcc/fortran/f95-lang.c:286
#7 0x082cc358 in toplev_main (argc=11, argv=0xbfb72194) at
../../../src/gcc-4.1/gcc/toplev.c:990
#8 0x080ba0f2 in main (argc=8191, argv=0x29) at
../../../src/gcc-4.1/gcc/main.c:35
==
$ gfortran-4.1-HEAD -v -c -o /tmp/foo.o label_4.f90
In file label_4.f90:4
1 ! { dg-warning "Ignoring statement label in empty statement" }
1
Warning: Ignoring statement label in empty statement at (1)
label_4.f90:5: internal compiler error: Segmentation fault
backtrace label_4.f90:
Program received signal SIGSEGV, Segmentation fault.
free_expr0 (e=0x12) at ../../../src/gcc-4.1/gcc/fortran/expr.c:141
141 switch (e->expr_type)
(gdb) bt
#0 free_expr0 (e=0x12) at ../../../src/gcc-4.1/gcc/fortran/expr.c:141
#1 0x0805f161 in gfc_free_expr (e=0x12) at
../../../src/gcc-4.1/gcc/fortran/expr.c:230
#2 0x08090663 in gfc_free_namespace (ns=0x8564d30) at
../../../src/gcc-4.1/gcc/fortran/symbol.c:1504
#3 0x08090728 in gfc_symbol_done_2 () at
../../../src/gcc-4.1/gcc/fortran/symbol.c:2393
#4 0x080783f8 in gfc_done_2 () at ../../../src/gcc-4.1/gcc/fortran/misc.c:293
#5 0x0807f1fe in gfc_parse_file () at
../../../src/gcc-4.1/gcc/fortran/parse.c:2685
#6 0x08098593 in gfc_be_parse_file (set_yydebug=0) at
../../../src/gcc-4.1/gcc/fortran/f95-lang.c:286
#7 0x082cc358 in toplev_main (argc=11, argv=0xbfd7a324) at
../../../src/gcc-4.1/gcc/toplev.c:990
#8 0x080ba0f2 in main (argc=8191, argv=0x29) at
../../../src/gcc-4.1/gcc/main.c:35
==
$ gfortran-4.1-HEAD -v -c -o /tmp/foo.o label_5.f90
In file label_5.f90:4
1 ! { dg-warning "Ignoring statement label in empty statement" }
1
Warning: Ignoring statement label in empty statement at (1)
In file label_5.f90:5
1 ! { dg-warning "Ignoring statement label in empty statement" }
1
Warning: Ignoring statement label in empty statement at (1)
label_5.f90:6: internal compiler error: Segmentation fault
backtrace label_5.f90:
Program received signal SIGSEGV, Segmentation fault.
free_expr0 (e=0x12) at ../../../src/gcc-4.1/gcc/fortran/expr.c:141
141 switch (e->expr_type)
(gdb) bt
#0 free_expr0 (e=0x12) at ../../../src/gcc-4.1/gcc/fortran/expr.c:141
#1 0x0805f161 in gfc_free_expr (e=0x12) at
../../../src/gcc-4.1/gcc/fortran/expr.c:230
#2 0x08090663 in gfc_free_namespace (ns=0x8564d90) at
../../../src/gcc-4.1/gcc/fortran/symbol.c:1504
#3 0x08090728 in gfc_symbol_done_2 () at
../../../src/gcc-4.1/gcc/fortran/symbol.c:2393
#4 0x080783f8 in gfc_done_2 () at ../../../src/gcc-4.1/gcc/fortran/misc.c:293
#5 0x0807f1fe in gfc_parse_file () at
../../../src/gcc-4.1/gcc/fortran/parse.c:2685
#6 0x08098593 in gfc_be_parse_file (set_yydebug=0) at
../../../src/gcc-4.1/gcc/fortran/f95-lang.c:286
#7 0x082cc358 in toplev_main (argc=11, argv=0xbf8d1e34) at
../../../src/gcc-4.1/gcc/toplev.c:990
#8 0x080ba0f2 in main (argc=8191, argv=0x29) at
../../../src/gcc-4.1/gcc/main.c:35
--
Summary: ICE on valid code
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aldot at gcc dot gnu dot org
GCC build triplet: i686-linux-gnu
GCC host triplet: i686-linux-gnu
GCC target triplet: i686-linux-gnu
OtherBugsDependingO 19292
[Bug fortran/25486] [4.1/4.2 Regression] fortran fixed-form literal character constant not padded.
--- Comment #13 from steven at gcc dot gnu dot org 2006-01-11 21:18 --- Bernhard, thanks for fixing this, but you have put your ChangeLog entries in the wrong ChangeLog. They should be in gcc/fortran/ChangeLog, and they are in gcc/ChangeLog. Could you please fix that? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25486
[Bug c/25755] New: ICE in testsuite/gcc.c-torture/execute/20050316-1.c
I'm getting an ICE in current 4.1 branch on Solaris 10 x86. It's trying to
compile testsuite/gcc.c-torture/execute/20050316-1.c and getting:
Executing on host: /var/tmp/gcc_4.1_svn/gcc_20060111/gcc/xgcc
-B/var/tmp/gcc_4.1_svn/gcc_20060111/gcc/
/var/tmp/gcc_4.1_svn/gcc/gcc/testsuite/gcc.c-torture/execute/20050316-1.c -w
-O0 -fno-show-column -lm -o
/var/tmp/gcc_4.1_svn/gcc_20060111/gcc/testsuite/20050316-1.x0(timeout =
300)
/var/tmp/gcc_4.1_svn/gcc/gcc/testsuite/gcc.c-torture/execute/20050316-1.c: In
function 'test3':
/var/tmp/gcc_4.1_svn/gcc/gcc/testsuite/gcc.c-torture/execute/20050316-1.c:26:
error: insn does not satisfy its constraints:
(insn 28 32 22 (set (reg/i:DI 29 [ ])
(mem/c:DI (plus:SI (reg/f:SI 6 bp)
(const_int -8 [0xfff8])) [0 S8 A8])) 80 {*movdi_2}
(nil)
(nil))
/var/tmp/gcc_4.1_svn/gcc/gcc/testsuite/gcc.c-torture/execute/20050316-1.c:26:
internal compiler error:
in extract_constrain_insn_cached, at recog.c:2002
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
compiler exited with status 1
output is:
/var/tmp/gcc_4.1_svn/gcc/gcc/testsuite/gcc.c-torture/execute/20050316-1.c: In
function 'test3':
/var/tmp/gcc_4.1_svn/gcc/gcc/testsuite/gcc.c-torture/execute/20050316-1.c:26:
error: insn does not satisfy its constraints:
(insn 28 32 22 (set (reg/i:DI 29 [ ])
(mem/c:DI (plus:SI (reg/f:SI 6 bp)
(const_int -8 [0xfff8])) [0 S8 A8])) 80 {*movdi_2}
(nil)
(nil))
/var/tmp/gcc_4.1_svn/gcc/gcc/testsuite/gcc.c-torture/execute/20050316-1.c:26:
internal compiler error:
in extract_constrain_insn_cached, at recog.c:2002
Please submit a full bug report,
Brett
--
Summary: ICE in testsuite/gcc.c-torture/execute/20050316-1.c
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: brett dot albertson at stratech dot com
GCC build triplet: i386-pc-solaris2.10
GCC host triplet: i386-pc-solaris2.10
GCC target triplet: i386-pc-solaris2.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25755
[Bug bootstrap/25753] [4.2 Regression] gfortran - fails to build on Mac OSX -10.4.3
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-11 20:44 --- Fixed by: 2005-01-11 Kenneth Zadeck <[EMAIL PROTECTED]> * Makefile.in Removed rotted odf.c entry. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|fortran |bootstrap Resolution||FIXED Summary|gfortran - fails to build on|[4.2 Regression] gfortran - |Mac OSX -10.4.3 |fails to build on Mac OSX - ||10.4.3 Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25753
[Bug pch/13676] GCC failes to recognize files ending in .hpp as headers to be precompiled
--- Comment #4 from pluto at agmk dot net 2006-01-11 19:51 --- Created an attachment (id=10625) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10625&action=view) patch for 4.1 branch. please check-in this patch befor 4.1.0-final. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13676
[Bug tree-optimization/25734] [4.2 Regression] ice for legal kernel code with -Os
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-01-11 19:49 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25734
[Bug libgcj/14572] System ClassLoader is not set according to java.system.class.loader property
--- Comment #4 from tromey at gcc dot gnu dot org 2006-01-11 19:46 --- This was fixed sometime during the 4.0 cycle. Tested on my x86 FC4 box with: opsy. gij --version java version "1.4.2" gij (GNU libgcj) version 4.0.1 20050727 (Red Hat 4.0.1-5) -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14572
[Bug tree-optimization/25680] Store CCP does not understand REALPART_EXPR < COMPLEX_CST >
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-01-11 19:18 --- Created an attachment (id=10624) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10624&action=view) Patch which fixes this bug ChangeLog: * tree-ssa-ccp.c (ccp_fold): Handle store CCP of REALPART_EXPR and IMAGPART_EXPR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25680
[Bug target/25750] g++ internal compiler error: Segmentation fault
--- Comment #5 from pablo at ipi dot fi 2006-01-11 18:41 --- Created an attachment (id=10623) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10623&action=view) the spec file I used -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25750
[Bug fortran/25753] New: gfortran - fails to build on Mac OSX -10.4.3
A fresh down load of everything this morning gets a error trying to build - gcc -c -g -no-cpp-precomp -DHAVE_DESIGNATED_INITIALIZERS=0 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I./../intl -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libdecnumber -I../libdecnumber../../gcc/gcc/debug.c -o debug.o gcc -c -g -no-cpp-precomp -DHAVE_DESIGNATED_INITIALIZERS=0 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I./../intl -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libdecnumber -I../libdecnumber../../gcc/gcc/df-core.c -o df-core.o gcc -c -g -no-cpp-precomp -DHAVE_DESIGNATED_INITIALIZERS=0 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I./../intl -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libdecnumber -I../libdecnumber../../gcc/gcc/df-problems.c -o df-problems.o make[3]: *** No rule to make target `odf.c', needed by `odf.o'. Stop. make[2]: *** [all-stage1-gcc] Error 2 make[1]: *** [stage1-bubble] Error 2 make: *** [all] Error 2 -- Summary: gfortran - fails to build on Mac OSX -10.4.3 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dir at lanl dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25753
[Bug c++/25386] packed structs
--- Comment #1 from nathan at gcc dot gnu dot org 2006-01-11 18:18 --- patch applied 2006-01-11 Nathan Sidwell <[EMAIL PROTECTED]> PR c++/25386 * tree.c (lvalue_p_1): Any part of a COMPONENT_REF affects packedness. * g++.dg/ext/packed3.C: Add expected packed error. -- nathan at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25386
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #26 from hhinnant at apple dot com 2006-01-11 18:02 --- (In reply to comment #25) > Subject: Re: exception_defines.h #defines try/catch > | The demo program does not play tricks with try/catch. > > It does, with xlgue(try, ). No, "try" in this context is not a keyword. There is no try, no catch, no exception, in this conforming C++ program. > | What subset of C++ programs do we expect to work under -fno-exceptions? > > Those that understand that try/catch are special. The intent of turning off exception handling in the compiler is to accomidate programs that are ignorant of try/catch, and have no need to process exceptions. > Can you provide standard specs that says the program must work with > -fno-exceptions? Of course not. Does this imply that we ought to lower our expectations of our product when exceptions are disabled such that it will seemingly randomly break conforming code? Or are our quality standards higher than that? > | Where do we document that some, but not all libstdc++ headers change the > | semantics of -fno-exception (as gcc documents it) and may render some > | conforming C++ programs broken? > > If the issue is that -fno-exceptions is not well documented, then we > should document it better. I'm happy to review documentation patches > that reflect the current state. I would rather not document that the libstdc++ takes a position contrary to the compiler and does not work with exception-ignorant but conforming code with -fno-exceptions. Such a position would be hard to justify. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug target/25750] g++ internal compiler error: Segmentation fault
--- Comment #4 from pablo at ipi dot fi 2006-01-11 17:58 --- I'm not using debian's compiler for SuperH target. On the host I'm using Ubuntu's compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25750
[Bug c++/25648] Spurious 'might be used uninitialized' warnings in STL headers with -O2
--- Comment #1 from chris at bubblescope dot net 2006-01-11 17:21 --- This bug is fixed in 4.1 (and possibly 4.0, I don't have a copy). Is suspect it isn't a serious enough bug to get the fix backported to 3.4 (although others may know better than me) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25648
[Bug fortran/25486] [4.1/4.2 Regression] fortran fixed-form literal character constant not padded.
--- Comment #12 from aldot at gcc dot gnu dot org 2006-01-11 17:08 --- Subject: Bug 25486 Author: aldot Date: Wed Jan 11 17:07:55 2006 New Revision: 109593 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109593 Log: 2006-01-11 Bernhard Fischer <[EMAIL PROTECTED]> PR fortran/25486 * scanner.c (load_line): use maxlen to determine the line-length used for padding lines in fixed form. Modified: branches/gcc-4_1-branch/gcc/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25486
[Bug fortran/25486] [4.1/4.2 Regression] fortran fixed-form literal character constant not padded.
--- Comment #11 from aldot at gcc dot gnu dot org 2006-01-11 17:06 --- Subject: Bug 25486 Author: aldot Date: Wed Jan 11 17:06:44 2006 New Revision: 109592 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109592 Log: gcc/fortran: 2006-01-11 Bernhard Fischer <[EMAIL PROTECTED]> PR fortran/25486 * scanner.c (load_line): use maxlen to determine the line-length used for padding lines in fixed form. gcc/testsuite: 2006-01-10 Bernhard Fischer <[EMAIL PROTECTED]> PR fortran/25486 * gfortran.dg/literal_character_constant_1_x.F: New test. * gfortran.dg/literal_character_constant_1_y.F: Ditto. * gfortran.dg/literal_character_constant_1_z.F: Ditto. * gfortran.dg/literal_character_constant_1.inc: Helper for new tests. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/literal_character_constant_1.inc branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/literal_character_constant_1_x.F branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/literal_character_constant_1_y.F branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/literal_character_constant_1_z.F Modified: branches/gcc-4_1-branch/gcc/fortran/scanner.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25486
[Bug libfortran/25697] libfortran - Segmentation fault/ Bad Address on unformatted read
--- Comment #10 from dir at lanl dot gov 2006-01-11 16:50 --- My thought on a possible fix is that the I/O buffers should be dumped before the read whenever a read immediately follows a write, but I have no idea how you would detect the situation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25697
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #25 from gdr at cs dot tamu dot edu 2006-01-11 16:41 --- Subject: Re: exception_defines.h #defines try/catch "hhinnant at apple dot com" <[EMAIL PROTECTED]> writes: | --- Comment #24 from hhinnant at apple dot com 2006-01-11 16:10 --- | (In reply to comment #23) | > You forgot to mentin that -fno-exceptions is neither mandated, nor | > required to work with programs that play tricks with try/catch. | > So, your assertion is unfounded. | | The demo program does not play tricks with try/catch. It does, with xlgue(try, ). | What subset of C++ programs do we expect to work under -fno-exceptions? Those that understand that try/catch are special. [...] | >You may also wish to disable this option if you are compiling older | >C++ programs that don't use exception handling. | | My demo is exactly that: A C++ program that does not use exception handling | (and yet is still conforming). Can you provide standard specs that says the program must work with -fno-exceptions? | Where do we document that some, but not all libstdc++ headers change the | semantics of -fno-exception (as gcc documents it) and may render some | conforming C++ programs broken? If the issue is that -fno-exceptions is not well documented, then we should document it better. I'm happy to review documentation patches that reflect the current state. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug fortran/25486] [4.1/4.2 Regression] fortran fixed-form literal character constant not padded.
--- Comment #10 from aldot at gcc dot gnu dot org 2006-01-11 16:38 --- Subject: Bug 25486 Author: aldot Date: Wed Jan 11 16:38:42 2006 New Revision: 109591 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109591 Log: gcc/fortran: 2006-01-11 Bernhard Fischer <[EMAIL PROTECTED]> PR fortran/25486 * scanner.c (load_line): use maxlen to determine the line-length used for padding lines in fixed form. gcc/testsuite: 2006-01-10 Bernhard Fischer <[EMAIL PROTECTED]> PR fortran/25486 * gfortran.dg/literal_character_constant_1_x.F: New test. * gfortran.dg/literal_character_constant_1_y.F: Ditto. * gfortran.dg/literal_character_constant_1_z.F: Ditto. * gfortran.dg/literal_character_constant_1.inc: Helper for new tests. Added: trunk/gcc/testsuite/gfortran.dg/literal_character_constant_1.inc trunk/gcc/testsuite/gfortran.dg/literal_character_constant_1_x.F trunk/gcc/testsuite/gfortran.dg/literal_character_constant_1_y.F trunk/gcc/testsuite/gfortran.dg/literal_character_constant_1_z.F Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/scanner.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25486
[Bug fortran/25083] non-common variable in block data
--- Comment #4 from tobi at gcc dot gnu dot org 2006-01-11 16:38 --- I forgot to say that g77 accepts this even with -pedantic. But this is undocumented and doesn't make much sense, so we can probably do away with it without alienating anybody. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25083
[Bug ada/24468] link failure for several acats tests
--- Comment #7 from r dot emrich at de dot tecosim dot com 2006-01-11 16:23 --- Subject: Re: link failure for several acats tests -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 laurent at guerby dot net schrieb: > --- Comment #5 from laurent at guerby dot net 2006-01-06 22:19 --- > Is 4.1 or 4.2 working there? > > for gcc-4.1 20060109: === acats tests === FAIL: a49027c FAIL: a83a02b FAIL: a85013b FAIL: a87b59a FAIL: a95001c FAIL: a95074d FAIL: a97106a FAIL: a99006a FAIL: aa2010a FAIL: ac3207a FAIL: ad7201a FAIL: ad7203b FAIL: ad7205b FAIL: ada101a FAIL: ae3702a FAIL: ae3709a FAIL: c250002 FAIL: c34007j FAIL: c34008a FAIL: c35102a FAIL: c354002 FAIL: c354003 FAIL: c37402a FAIL: c37403a FAIL: c380003 FAIL: c38102d FAIL: c38202a FAIL: c390010 FAIL: c39008a FAIL: c39008b FAIL: c39008c FAIL: c391002 FAIL: c392010 FAIL: c392011 FAIL: c392c05 FAIL: c392c07 FAIL: c393001 FAIL: c393008 FAIL: c393010 FAIL: c393012 FAIL: c3a0005 FAIL: c3a0007 FAIL: c3a0009 FAIL: c3a1001 FAIL: c3a1002 FAIL: c3a2001 FAIL: c410001 FAIL: c41306a FAIL: c41306b FAIL: c41306c FAIL: c41307d FAIL: c41401a FAIL: c43204g FAIL: c450001 FAIL: c45282b FAIL: c45291a FAIL: c46051a FAIL: c490001 FAIL: c490002 FAIL: c51004a All failure of the same type: splitting /SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/gcc-4.1/gcc-4.1/gcc/testsuite/ada/acats/tests/a/a49027c.ada into: a49027c.adb BUILD a49027c.adb gnatmake - --GCC="/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/gcc-4.1/gcc-4.1/gcc/xgcc - -B/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/gcc-4.1/gcc-4.1/gcc/" -gnatws -O2 - -I/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/gcc-4.1/gcc-4.1/gcc/testsuite/ada/acats/support a49027c.adb -largs - --GCC="/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/gcc-4.1/gcc-4.1/gcc/xgcc - -B/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/gcc-4.1/gcc-4.1/gcc/" /SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/gcc-4.1/gcc-4.1/gcc/xgcc -c - -B/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/gcc-4.1/gcc-4.1/gcc/ -gnatws -O2 - -I/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/gcc-4.1/gcc-4.1/gcc/testsuite/ada/acats/support a49027c.adb gnatbind -aO./ - -I/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/gcc-4.1/gcc-4.1/gcc/testsuite/ada/acats/support - -I- -x a49027c.ali gnatlink a49027c.ali - --GCC=/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/gcc-4.1/gcc-4.1/gcc/xgcc - -B/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/gcc-4.1/gcc-4.1/gcc/ /SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/install/bin/ld:GNAT-a0_Sfj: file format not recognized; treating as linker script /SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/install/bin/ld:GNAT-a0_Sfj:2: parse error collect2: ld returned 1 exit status gnatlink: cannot call /SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/gcc-4.1/gcc-4.1/gcc/xgcc gnatmake: *** link failed. FAIL: a49027c Rainer - -- Rainer Emrich TECOSIM GmbH Im Eichsfeld 3 65428 Rüsselsheim Phone: +49(0)6142/8272 12 Mobile: +49(0)163/56 949 20 Fax.: +49(0)6142/8272 49 Web: www.tecosim.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDxTD73s6elE6CYeURApzdAJ99swjaxfkoSsFTcRQcv8v8o2hFRACgoxQu ebX4Ydiy+Xsl6lOzC/gHTYk= =icPZ -END PGP SIGNATURE- -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24468
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #24 from hhinnant at apple dot com 2006-01-11 16:10 --- (In reply to comment #23) > You forgot to mentin that -fno-exceptions is neither mandated, nor > required to work with programs that play tricks with try/catch. > So, your assertion is unfounded. The demo program does not play tricks with try/catch. It uses the identifier "try" in a completely conforming manner. What subset of C++ programs do we expect to work under -fno-exceptions? And where is that documented? The only thing I can find in our documentation that addresses my question is: >You may also wish to disable this option if you are compiling older >C++ programs that don't use exception handling. My demo is exactly that: A C++ program that does not use exception handling (and yet is still conforming). And gcc (without libstdc++) handles it just fine. Where do we document that some, but not all libstdc++ headers change the semantics of -fno-exception (as gcc documents it) and may render some conforming C++ programs broken? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug fortran/25486] [4.1/4.2 Regression] fortran fixed-form literal character constant not padded.
--- Comment #9 from aldot at gcc dot gnu dot org 2006-01-11 16:07 --- I had trouble with the testcase: I wanted to have only one .F file with three dg-options but this didn't work out. I'm about to check the patch in during the next few hours. Really sorry for the long delay (flu). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25486
[Bug libfortran/25697] libfortran - Segmentation fault/ Bad Address on unformatted read
--- Comment #9 from dir at lanl dot gov 2006-01-11 16:02 --- With a larger amount of data it only takes one write - [dranta:~/tests/gfortran-D] dir% gfortran -o write22 write22.f [dranta:~/tests/gfortran-D] dir% write22 Bus error [dranta:~/tests/gfortran-D] dir% cat write22.f integer data(1) do i = 1,1 data(i)=-1 enddo open(unit=11,status='scratch',form='unformatted') data(1)=1 data(1)=-1 write(11)data read(11,end=1000 )data call abort() 1000 continue backspace 11 backspace 11 read(11,end=1001 )data if(data(1).ne. 1.or.data(1).ne. -1)then call abort() endif 1001 continue read(11,end=1002 )data call abort() 1002 continue close(11) end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25697
[Bug fortran/25083] non-common variable in block data
-- tobi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-01-11 16:00:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25083
[Bug fortran/25083] non-common variable in block data
--- Comment #3 from jv244 at cam dot ac dot uk 2006-01-11 15:58 --- (In reply to comment #2) > I think the problem is that I does not live in a common block, but i don't > have > the standard to check. > yes -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25083
[Bug fortran/25062] same name for parameter and common block
--- Comment #4 from jv244 at cam dot ac dot uk 2006-01-11 15:57 --- (In reply to comment #3) > Even Lahey's Fortran 90 and their 95 compiler does not error out about this. > > I wonder if xlf does. > xlf90 -qsuffix=f=f90 mytest.f90 "mytest.f90", line 2.9: 1514-259 (S) A name must not be both the name of a named constant and the name of a COMMON block. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25062
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #23 from gdr at cs dot tamu dot edu 2006-01-11 15:56 --- Subject: Re: exception_defines.h #defines try/catch "hhinnant at apple dot com" <[EMAIL PROTECTED]> writes: | #define'ing try and catch is non-conforming. You forgot to mentin that -fno-exceptions is neither mandated, nor required to work with programs that play tricks with try/catch. So, your assertion is unfounded. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug rtl-optimization/24376] wrong-code unless -fno-sched-interblock
--- Comment #11 from nickc at redhat dot com 2006-01-11 15:38 --- Hi Libor, Oops- there was a condition where the new code could walk backwards into a previous block. Sorry about that. I have uploaded a revised patch which should not fall into this trap. It certainly works with the two other test cases you provided. Cheers Nick -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24376
[Bug rtl-optimization/24376] wrong-code unless -fno-sched-interblock
--- Comment #10 from nickc at redhat dot com 2006-01-11 15:37 --- Created an attachment (id=10622) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10622&action=view) Revised patch which should not walk over blocks -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24376
[Bug libfortran/25697] libfortran - Segmentation fault/ Bad Address on unformatted read
--- Comment #8 from dir at lanl dot gov 2006-01-11 15:34 --- That fixed all the posted examples and it passed the 1048576 tests of all combinations of read,write,backspace, and rewind taken 10 at a time writing a single word, but when I increased the write size to 500 words it failed. The strange thing with this example is that if one of the five writes is removed it no longer fails (buffer flush problem ?) - [dranta:~/tests/gfortran-D] dir% gfortran -o write21 write21.f [dranta:~/tests/gfortran-D] dir% write21 Segmentation fault [dranta:~/tests/gfortran-D] dir% cat write21.f integer data(500) do i = 1,500 data(i)=-1 enddo open(unit=11,status='scratch',form='unformatted') write(11)data write(11)data write(11)data write(11)data write(11)data read(11,end=1000 )data call abort() 1000 continue backspace 11 backspace 11 read(11,end=1001 )data 1001 continue read(11,end=1002 )data call abort() 1002 continue close(11) end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25697
[Bug target/25725] libtool -rpath works only for GNU ld, not for Sun ld
--- Comment #1 from alex at milivojevic dot org 2006-01-11 15:30 --- I've just installed GNU binutils and recompiled gcc (languages=c,c++,objc,java,f95) for sparc-sun-solaris2.9 and with GNU linker and assembler. The problem exists there too. So it is libtool script not passing -rpath argument to the linker command (doesn't depend on which ld is used). It's kind of strange, sometimes libtool will pass the correct option to the link command, sometimes it won't. Also, for some targets, the Makefile doesn't seem to use libtool to create them (invokes link command directly). Also, when creating shared libraries, if the library depends on another shared library, I found that sometimes I need RPATH set in the shared library as well (at least when using Sun ld). I'm not yet completely sure, but it seems that if liba.so depends on libb.so the dynamic linker will be able to find libb.so only if exectubale directly depends on both liba.so and libb.so. If executable (with correct RPATH tag pointing to both liba.so and libb.so) depends only on liba.so, the dynamic linker will fail to find libb.so. I had this problem (when using Sun ld) with several programs that depended on libraries that in turn depended on libgcc_s.so. Relinking the library to include RPATH tag to where libgcc_s.so is, solved the problem. However it was kind of annoying to have to manually fix this after almost every single library I built. As I said, this seems to be the problem when using Sun ld. Comparing "dump -Lv f951" outputs from excutables created by Sun and Gnu ld, the one created by Sun ld depends only on libgmp and libc. The one created by Gnu ld depends on libgmp, libc and libgcc_s. Looks like Sun ld will include NEEDED tags only for libs the exectable directly depends on. Gnu ld will include NEEDED tags for libs the executable indirectly depends on too (the libgmp depends on libgcc_s). Because of this Sun ld behaviour, when creating shared libraries on Sun Solaris systems, the -R or --rpath (depending which linker is used) should be used regardless of which linker is used (since the user might mix and match libs created by both linkers). BTW, one difference between GNU ld and Sun ld I noticed was that Sun ld will set both RPATH and RUNPATH tags. The GNU ld will set only RPATH. It doesn't seem to make any difference during runtime. Couple of examples from the last GCC build I made. >From the build log, it doesn't seem libtool was used to create f951 (Makefile used xgcc directly). The resulting binary is missing RPATH. $ ldd f951 libgmp.so.3 => (file not found) libc.so.1 => /usr/lib/libc.so.1 libgcc_s.so.1 => (file not found) libdl.so.1 =>/usr/lib/libdl.so.1 /usr/platform/SUNW,UltraAX-e2/lib/libc_psr.so.1 $ dump -Lv f951 f951: DYNAMIC SECTION INFORMATION .dynamic: [INDEX] Tag Value [1] NEEDED libgmp.so.3 [2] NEEDED libc.so.1 [3] NEEDED libgcc_s.so.1 [4] INIT0x12154 [5] FINI0x384500 [6] HASH0x100e8 [7] STRTAB 0x110a8 [8] SYMTAB 0x105b8 [9] STRSZ 0x6fb [10]SYMENT 0x10 [11]DEBUG 0 [12]PLTGOT 0x3f0f60 [13]PLTSZ 0x714 [14]PLTREL 0x7 [15]JMPREL 0x11a40 [16]RELA0x119a4 [17]RELASZ 0x7b0 [18]RELAENT 0xc [19]VERNEED 0x11904 [20]VERNEEDNUM 0x2 [21]1879048176 Another example. The libstdc++.so. It is missing RPATH, so dynamic linker might fail to find libgcc_s.so during runtime (if executable was created using Sun ld): $ ldd libstdc++.so libm.so.1 => /usr/lib/libm.so.1 libgcc_s.so.1 => (file not found) libc.so.1 => /usr/lib/libc.so.1 libdl.so.1 =>/usr/lib/libdl.so.1 /usr/platform/SUNW,UltraAX-e2/lib/libc_psr.so.1 $ dump -Lv libstdc++.so libstdc++.so: DYNAMIC SECTION INFORMATION .dynamic: [INDEX] Tag Value [1] NEEDED libm.so.1 [2] NEEDED libgcc_s.so.1 [3] NEEDED libc.so.1 [4] SONAME libstdc++.so.6 [5] INIT0x3e9d0 [6] FINI0xbd4c0 [7] HASH0x94 [8] STRTAB 0x1168c [9] SYMTAB 0x44ec [10]STRSZ 0x21cee [11]SYMENT 0x10 [12]PLTGOT 0xe1ee4 [13]PLTSZ 0x1950 [14]PLTREL 0x7 [15]JMPREL 0x3d080 [16]RELA0x34fe0 [17]RELASZ 0x99f0 [18]RELAENT 0xc [19]VERDEF 0x34db0 [20]VERDEFNUM 0xa [21]VERNEED 0x34f00 [22]VERNEEDNUM 0x3 [23]1879048176 [24]RELACOUNT 0x32d -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25725
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #22 from hhinnant at apple dot com 2006-01-11 15:30 ---
Conforming C++ programs exist that work correctly with -fno-exceptions as long
as they don't include any libstdc++ header. These same programs can fail (at
either compile time or run time) if they also include some (not all) libstdc++
header.
For example:
#include
#define glue(a, b) a ## b
#define xglue(a, b) glue(a, b)
#define tryLOW "hello"
#define LOW LOW ", world"
int main()
{
printf("%s\n", xglue(try, LOW));
}
This is a conforming C++ program. It should run and print out:
hello, world
And it does so for gcc whether or not -fno-exceptions.
However if the same program includes or (just as an
example), then the program runs only if -fno-exceptions is not specified.
Otherwise:
/Volumes/Data/Development/XcTest/main.cpp:12:1: error: pasting ")" and "LOW"
does not give a valid preprocessing token
/Volumes/Data/Development/XcTest/main.cpp: In function 'int main()':
/Volumes/Data/Development/XcTest/main.cpp:12: error: expected
primary-expression before 'if'
#define'ing try and catch is non-conforming.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug c++/25751] New: Poor error when templating on undefined types
#include
int main(void)
{
std::vector v;
v.begin();
}
Produces:
temp.cc: In function 'int main()':
temp.cc:5: error: 'foo' was not declared in this scope
temp.cc:5: error: template argument 1 is invalid
temp.cc:5: error: template argument 2 is invalid
temp.cc:5: error: invalid type in declaration before ';' token
temp.cc:6: error: request for member 'begin' in 'v', which is of non-class type
'int'
That last warning doesn't seem to make any sense. Perhaps g++ should abandon
parsing / producing errors earlier?
--
Summary: Poor error when templating on undefined types
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chris at bubblescope dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25751
[Bug tree-optimization/25680] Store CCP does not understand REALPART_EXPR < COMPLEX_CST >
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-11 15:17 --- I have a three line fix. -- 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 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25680
[Bug fortran/25083] non-common variable in block data
--- Comment #2 from tobi at gcc dot gnu dot org 2006-01-11 14:36 --- I think the problem is that I does not live in a common block, but i don't have the standard to check. -- tobi at gcc dot gnu dot org changed: What|Removed |Added CC||tobi at gcc dot gnu dot org Summary|better diagnostic needed|non-common variable in block ||data http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25083
[Bug c++/25750] g++ internal compiler error: Segmentation fault
--- Comment #3 from pablo at ipi dot fi 2006-01-11 14:33 --- Created an attachment (id=10621) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10621&action=view) Output of the compile command The actual compiler command g++ -v -save-temps -DHAVE_CONFIG_H -I. -I. -I../../../pango -I../../../pango -I../../../atk -I../../../atk -I../../../gdk -I../../../gdk -I../../../gtk -I../../../gtk -D_XOPEN_SOURCE=500 -DXTHREADS -DXUSE_MTSAFE_API -I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -DGTKMM_DISABLE_DEPRECATED-Wall -g -O2 -MT main.o -MD -MP -MF ".deps/main.Tpo" -c -o main.o main.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25750
[Bug fortran/25062] same name for parameter and common block
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-11 14:32 --- Even Lahey's Fortran 90 and their 95 compiler does not error out about this. I wonder if xlf does. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25062
[Bug c++/25750] g++ internal compiler error: Segmentation fault
--- Comment #2 from pablo at ipi dot fi 2006-01-11 14:31 --- Created an attachment (id=10620) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10620&action=view) the preprocessed file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25750
[Bug tree-optimization/23948] [4.1 Regression] internal compiler error: verify_stmts failed
--- Comment #24 from bonzini at gnu dot org 2006-01-11 14:31 --- patch committed -- bonzini at gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23948
[Bug tree-optimization/24123] [4.1 Regression] Massive performance regression for -ffast-math due to the recip tree pass
--- Comment #28 from bonzini at gnu dot org 2006-01-11 14:30 --- patch committed to both branches -- bonzini at gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24123
[Bug tree-optimization/23109] [4.1 Regression] compiler generates wrong code leading to spurious division by zero with -funsafe-math-optimizations (instead of -ftrapping-math)
--- Comment #17 from bonzini at gnu dot org 2006-01-11 14:30 --- patch committed to 4.1 too -- bonzini at gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23109
[Bug tree-optimization/24123] [4.1 Regression] Massive performance regression for -ffast-math due to the recip tree pass
--- Comment #27 from bonzini at gnu dot org 2006-01-11 14:29 --- Subject: Bug 24123 Author: bonzini Date: Wed Jan 11 14:29:29 2006 New Revision: 109586 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109586 Log: gcc: 2006-01-11 Paolo Bonzini <[EMAIL PROTECTED]> PR tree-optimization/23109 PR tree-optimization/23948 PR tree-optimization/24123 * Makefile.in (tree-ssa-math-opts.o): Adjust dependencies. * tree-cfg.c (single_noncomplex_succ): New. * tree-flow.h (single_noncomplex_succ): Declare it. * tree-ssa-math-opts.c (enum place_reciprocal): Remove. * tree-ssa-math-opts.c (enum place_reciprocal): Remove. (struct occurrence, occ_head, occ_pool, is_divide_by, compute_merit, insert_bb, register_division_in, insert_reciprocals, replace_reciprocal, free_bb): New. (execute_cse_reciprocals_1): Rewritten. (execute_cse_reciprocals): Adjust calls to execute_cse_reciprocals_1. Do not commit any edge insertion. Always compute dominators and create the allocation pool. * target-def.h (TARGET_MIN_DIVISIONS_FOR_RECIP_MUL): New. * target.h (struct gcc_target): Add min_divistions_for_recip_mul. * targhooks.c (default_min_divistions_for_recip_mul): New. * targhooks.h (default_min_divistions_for_recip_mul): New prototype. * passes.c (init_optimization_passes): Run recip after tree loop optimizations. * doc/tm.texi (Misc): Document TARGET_MIN_DIVISIONS_FOR_RECIP_MUL. gcc/testsuite: 2006-01-11 Paolo Bonzini <[EMAIL PROTECTED]> PR tree-optimization/23109 PR tree-optimization/23948 PR tree-optimization/24123 * gcc.dg/tree-ssa/recip-3.c, gcc.dg/tree-ssa/recip-4.c, gcc.dg/tree-ssa/recip-5.c, gcc.dg/tree-ssa/recip-6.c, gcc.dg/tree-ssa/recip-7.c, gcc.dg/tree-ssa/pr23109.c, g++.dg/tree-ssa/pr23948.C: New testcases. * gcc.dg/tree-ssa/recip-2.c, gcc.dg/tree-ssa/pr23234.c: Provide three divisions in order to do the optimization. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/tree-ssa/pr23948.C - copied unchanged from r109578, trunk/gcc/testsuite/g++.dg/tree-ssa/pr23948.C branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/tree-ssa/pr23109.c - copied unchanged from r109578, trunk/gcc/testsuite/gcc.dg/tree-ssa/pr23109.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/tree-ssa/recip-3.c - copied unchanged from r109578, trunk/gcc/testsuite/gcc.dg/tree-ssa/recip-3.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/tree-ssa/recip-4.c - copied unchanged from r109578, trunk/gcc/testsuite/gcc.dg/tree-ssa/recip-4.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/tree-ssa/recip-5.c - copied unchanged from r109578, trunk/gcc/testsuite/gcc.dg/tree-ssa/recip-5.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/tree-ssa/recip-6.c - copied unchanged from r109578, trunk/gcc/testsuite/gcc.dg/tree-ssa/recip-6.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/tree-ssa/recip-7.c - copied unchanged from r109578, trunk/gcc/testsuite/gcc.dg/tree-ssa/recip-7.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/Makefile.in branches/gcc-4_1-branch/gcc/doc/tm.texi branches/gcc-4_1-branch/gcc/passes.c branches/gcc-4_1-branch/gcc/target-def.h branches/gcc-4_1-branch/gcc/target.h branches/gcc-4_1-branch/gcc/targhooks.c branches/gcc-4_1-branch/gcc/targhooks.h branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/tree-ssa/pr23234.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/tree-ssa/recip-2.c branches/gcc-4_1-branch/gcc/tree-cfg.c branches/gcc-4_1-branch/gcc/tree-flow.h branches/gcc-4_1-branch/gcc/tree-ssa-math-opts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24123
[Bug tree-optimization/23948] [4.1 Regression] internal compiler error: verify_stmts failed
--- Comment #23 from bonzini at gnu dot org 2006-01-11 14:29 --- Subject: Bug 23948 Author: bonzini Date: Wed Jan 11 14:29:29 2006 New Revision: 109586 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109586 Log: gcc: 2006-01-11 Paolo Bonzini <[EMAIL PROTECTED]> PR tree-optimization/23109 PR tree-optimization/23948 PR tree-optimization/24123 * Makefile.in (tree-ssa-math-opts.o): Adjust dependencies. * tree-cfg.c (single_noncomplex_succ): New. * tree-flow.h (single_noncomplex_succ): Declare it. * tree-ssa-math-opts.c (enum place_reciprocal): Remove. * tree-ssa-math-opts.c (enum place_reciprocal): Remove. (struct occurrence, occ_head, occ_pool, is_divide_by, compute_merit, insert_bb, register_division_in, insert_reciprocals, replace_reciprocal, free_bb): New. (execute_cse_reciprocals_1): Rewritten. (execute_cse_reciprocals): Adjust calls to execute_cse_reciprocals_1. Do not commit any edge insertion. Always compute dominators and create the allocation pool. * target-def.h (TARGET_MIN_DIVISIONS_FOR_RECIP_MUL): New. * target.h (struct gcc_target): Add min_divistions_for_recip_mul. * targhooks.c (default_min_divistions_for_recip_mul): New. * targhooks.h (default_min_divistions_for_recip_mul): New prototype. * passes.c (init_optimization_passes): Run recip after tree loop optimizations. * doc/tm.texi (Misc): Document TARGET_MIN_DIVISIONS_FOR_RECIP_MUL. gcc/testsuite: 2006-01-11 Paolo Bonzini <[EMAIL PROTECTED]> PR tree-optimization/23109 PR tree-optimization/23948 PR tree-optimization/24123 * gcc.dg/tree-ssa/recip-3.c, gcc.dg/tree-ssa/recip-4.c, gcc.dg/tree-ssa/recip-5.c, gcc.dg/tree-ssa/recip-6.c, gcc.dg/tree-ssa/recip-7.c, gcc.dg/tree-ssa/pr23109.c, g++.dg/tree-ssa/pr23948.C: New testcases. * gcc.dg/tree-ssa/recip-2.c, gcc.dg/tree-ssa/pr23234.c: Provide three divisions in order to do the optimization. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/tree-ssa/pr23948.C - copied unchanged from r109578, trunk/gcc/testsuite/g++.dg/tree-ssa/pr23948.C branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/tree-ssa/pr23109.c - copied unchanged from r109578, trunk/gcc/testsuite/gcc.dg/tree-ssa/pr23109.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/tree-ssa/recip-3.c - copied unchanged from r109578, trunk/gcc/testsuite/gcc.dg/tree-ssa/recip-3.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/tree-ssa/recip-4.c - copied unchanged from r109578, trunk/gcc/testsuite/gcc.dg/tree-ssa/recip-4.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/tree-ssa/recip-5.c - copied unchanged from r109578, trunk/gcc/testsuite/gcc.dg/tree-ssa/recip-5.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/tree-ssa/recip-6.c - copied unchanged from r109578, trunk/gcc/testsuite/gcc.dg/tree-ssa/recip-6.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/tree-ssa/recip-7.c - copied unchanged from r109578, trunk/gcc/testsuite/gcc.dg/tree-ssa/recip-7.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/Makefile.in branches/gcc-4_1-branch/gcc/doc/tm.texi branches/gcc-4_1-branch/gcc/passes.c branches/gcc-4_1-branch/gcc/target-def.h branches/gcc-4_1-branch/gcc/target.h branches/gcc-4_1-branch/gcc/targhooks.c branches/gcc-4_1-branch/gcc/targhooks.h branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/tree-ssa/pr23234.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/tree-ssa/recip-2.c branches/gcc-4_1-branch/gcc/tree-cfg.c branches/gcc-4_1-branch/gcc/tree-flow.h branches/gcc-4_1-branch/gcc/tree-ssa-math-opts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23948
[Bug tree-optimization/23109] [4.1 Regression] compiler generates wrong code leading to spurious division by zero with -funsafe-math-optimizations (instead of -ftrapping-math)
--- Comment #16 from bonzini at gnu dot org 2006-01-11 14:29 --- Subject: Bug 23109 Author: bonzini Date: Wed Jan 11 14:29:29 2006 New Revision: 109586 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109586 Log: gcc: 2006-01-11 Paolo Bonzini <[EMAIL PROTECTED]> PR tree-optimization/23109 PR tree-optimization/23948 PR tree-optimization/24123 * Makefile.in (tree-ssa-math-opts.o): Adjust dependencies. * tree-cfg.c (single_noncomplex_succ): New. * tree-flow.h (single_noncomplex_succ): Declare it. * tree-ssa-math-opts.c (enum place_reciprocal): Remove. * tree-ssa-math-opts.c (enum place_reciprocal): Remove. (struct occurrence, occ_head, occ_pool, is_divide_by, compute_merit, insert_bb, register_division_in, insert_reciprocals, replace_reciprocal, free_bb): New. (execute_cse_reciprocals_1): Rewritten. (execute_cse_reciprocals): Adjust calls to execute_cse_reciprocals_1. Do not commit any edge insertion. Always compute dominators and create the allocation pool. * target-def.h (TARGET_MIN_DIVISIONS_FOR_RECIP_MUL): New. * target.h (struct gcc_target): Add min_divistions_for_recip_mul. * targhooks.c (default_min_divistions_for_recip_mul): New. * targhooks.h (default_min_divistions_for_recip_mul): New prototype. * passes.c (init_optimization_passes): Run recip after tree loop optimizations. * doc/tm.texi (Misc): Document TARGET_MIN_DIVISIONS_FOR_RECIP_MUL. gcc/testsuite: 2006-01-11 Paolo Bonzini <[EMAIL PROTECTED]> PR tree-optimization/23109 PR tree-optimization/23948 PR tree-optimization/24123 * gcc.dg/tree-ssa/recip-3.c, gcc.dg/tree-ssa/recip-4.c, gcc.dg/tree-ssa/recip-5.c, gcc.dg/tree-ssa/recip-6.c, gcc.dg/tree-ssa/recip-7.c, gcc.dg/tree-ssa/pr23109.c, g++.dg/tree-ssa/pr23948.C: New testcases. * gcc.dg/tree-ssa/recip-2.c, gcc.dg/tree-ssa/pr23234.c: Provide three divisions in order to do the optimization. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/tree-ssa/pr23948.C - copied unchanged from r109578, trunk/gcc/testsuite/g++.dg/tree-ssa/pr23948.C branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/tree-ssa/pr23109.c - copied unchanged from r109578, trunk/gcc/testsuite/gcc.dg/tree-ssa/pr23109.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/tree-ssa/recip-3.c - copied unchanged from r109578, trunk/gcc/testsuite/gcc.dg/tree-ssa/recip-3.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/tree-ssa/recip-4.c - copied unchanged from r109578, trunk/gcc/testsuite/gcc.dg/tree-ssa/recip-4.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/tree-ssa/recip-5.c - copied unchanged from r109578, trunk/gcc/testsuite/gcc.dg/tree-ssa/recip-5.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/tree-ssa/recip-6.c - copied unchanged from r109578, trunk/gcc/testsuite/gcc.dg/tree-ssa/recip-6.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/tree-ssa/recip-7.c - copied unchanged from r109578, trunk/gcc/testsuite/gcc.dg/tree-ssa/recip-7.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/Makefile.in branches/gcc-4_1-branch/gcc/doc/tm.texi branches/gcc-4_1-branch/gcc/passes.c branches/gcc-4_1-branch/gcc/target-def.h branches/gcc-4_1-branch/gcc/target.h branches/gcc-4_1-branch/gcc/targhooks.c branches/gcc-4_1-branch/gcc/targhooks.h branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/tree-ssa/pr23234.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/tree-ssa/recip-2.c branches/gcc-4_1-branch/gcc/tree-cfg.c branches/gcc-4_1-branch/gcc/tree-flow.h branches/gcc-4_1-branch/gcc/tree-ssa-math-opts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23109
[Bug c++/25750] g++ internal compiler error: Segmentation fault
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-11 14:29 --- Are you using debian's compilers? If so you should have reported it to debian first. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25750
[Bug fortran/25062] same name for parameter and common block
--- Comment #2 from tobi at gcc dot gnu dot org 2006-01-11 14:29 --- I'm quite sure it's not, but it would be a first, if Joost were wrong. Is there anything special about parameters? Something like real x common /x/ y or even common /x/ x is perfectly valid. -- tobi at gcc dot gnu dot org changed: What|Removed |Added CC||tobi at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25062
[Bug c++/25750] New: g++ internal compiler error: Segmentation fault
Building debian package gtkmm2.4-2.4.10 for SuperH fails for internal compiler error. -- Summary: g++ internal compiler error: Segmentation fault Product: gcc Version: 3.4.5 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pablo at ipi dot fi GCC build triplet: i686-linux-gnu GCC host triplet: i686-linux-gnu GCC target triplet: sh3-linux-gcc http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25750
[Bug libfortran/25577] gfortran routine mvbits returns wrong answer.
--- Comment #3 from tobi at gcc dot gnu dot org 2006-01-11 14:26 --- Also fails on i686. -- tobi at gcc dot gnu dot org changed: What|Removed |Added CC||tobi at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC host triplet|powerpc-apple-darwin8.3.0 | Last reconfirmed|-00-00 00:00:00 |2006-01-11 14:26:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25577
[Bug c++/13140] declaration in global namespace, definition inside named or anon namespace
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-01-11 14:16 --- *** Bug 25748 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||igodard at pacbell dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13140
[Bug c++/25748] Template instantiated twice
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-11 14:16 --- Yes this is invalid code, in 4.1.0 and above we get: t.cc:2: error: definition of 'foo::t' is not in namespace enclosing 'foo' This is a dup of bug 13140. *** This bug has been marked as a duplicate of 13140 *** -- 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=25748
[Bug target/25042] [3.4/4.0 Regression] __float128 ICE on x86
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-01-11 14:11 --- Fixed in 4.1.0 and 4.2.0 at least. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail||3.4.0 4.0.0 Known to work||3.3.3 4.1.0 4.2.0 Summary|[3.4/4.0/4.1/4.2 Regression]|[3.4/4.0 Regression] |__float128 ICE on x86 |__float128 ICE on x86 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25042
[Bug fortran/25746] Elemental assignment gives wrong result
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-11 13:58 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2006-01-11 13:58:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25746
[Bug target/25706] [4.2 regression]: invalid asm: "mov"
--- Comment #4 from hp at gcc dot gnu dot org 2006-01-11 13:51 --- . -- hp at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25706
[Bug target/25706] [4.2 regression]: invalid asm: "mov"
--- Comment #3 from hp at gcc dot gnu dot org 2006-01-11 13:45 --- Subject: Bug 25706 Author: hp Date: Wed Jan 11 13:45:03 2006 New Revision: 109585 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109585 Log: PR target/25706 * gcc.dg/torture/pr25706-1.c: New test. Added: trunk/gcc/testsuite/gcc.dg/torture/pr25706-1.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25706
[Bug target/25706] [4.2 regression]: invalid asm: "mov"
--- Comment #2 from hp at gcc dot gnu dot org 2006-01-11 13:43 ---
Subject: Bug 25706
Author: hp
Date: Wed Jan 11 13:43:08 2006
New Revision: 109584
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109584
Log:
PR target/25706
* config/cris/cris.md ("*extopqihi_side", "*extopsi_side")
("*extopsi_swap_side_biap", "*extopsi_swap_side",
("*extopqihi", "*extopsi", "*extopsi_swap"): Use %E
output pattern modifier, not %e.
* config/cris/cris.c (cris_op_str): Update comment about pattern
modifier.
(cris_print_operand) : Clear cris_output_insn_is_bound
before falling through into...
: Redefined from old 'e' case.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/cris/cris.c
trunk/gcc/config/cris/cris.md
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25706
[Bug target/25042] [3.4/4.0/4.1/4.2 Regression] __float128 ICE on x86
--- Comment #6 from hubicka at gcc dot gnu dot org 2006-01-11 13:32 --- Subject: Bug 25042 Author: hubicka Date: Wed Jan 11 13:32:44 2006 New Revision: 109583 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109583 Log: PR target/25042 * i386.c (ix86_init_mmx_sse_builtins): Do not delcare float128 Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/i386/i386.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25042
[Bug target/25042] [3.4/4.0/4.1/4.2 Regression] __float128 ICE on x86
--- Comment #5 from hubicka at gcc dot gnu dot org 2006-01-11 13:26 --- Subject: Bug 25042 Author: hubicka Date: Wed Jan 11 13:26:45 2006 New Revision: 109582 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109582 Log: PR target/25042 * i386.c (ix86_init_mmx_sse_builtins): Do not delcare float128 Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25042
[Bug tree-optimization/25734] [4.2 Regression] ice for legal kernel code with -Os
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-01-11 13:21 --- I have a fix. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-01-11 13:07:38 |2006-01-11 13:21:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25734
[Bug tree-optimization/25734] [4.2 Regression] ice for legal kernel code with -Os
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-01-11 13:09 ---
The diff between dse and forwrop:
--- pr25734.c.t88.dse2 2006-01-11 14:08:11.0 +0100
+++ pr25734.c.t89.forwprop3 2006-01-11 14:08:11.0 +0100
@@ -1,6 +1,19 @@
;; Function sysfs_hash_and_remove (sysfs_hash_and_remove)
+
+
+Symbols to be put in SSA form
+
+TMT.6 TMT.7
+
+Incremental SSA update started at block: 0
+
+Number of blocks in CFG: 8
+Number of blocks to update: 6 ( 75%)
+
+
+
sysfs_hash_and_remove (dir, name)
{
struct list_head * entry;
@@ -32,10 +45,9 @@ sysfs_hash_and_remove (dir, name)
# sd_17 = PHI ;
:;
- entry_16 = &sd_17->s_sibling;
- D.1917_18 = entry_16->next;
+ D.1917_18 = sd_17->s_sibling.next;
__list_del (D.1917_18);
- entry_16->next = entry_16;
+ sd_17->s_sibling.next = entry_16;
goto ();
:;
---
Even though we prop entry_16 into simplify into sd_17, we still have a
reference to entry_16.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25734
[Bug tree-optimization/25734] [4.2 Regression] ice for legal kernel code with -Os
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-11 13:07 ---
Reduced testcase:
struct list_head {
struct list_head *next;
};
static inline __attribute__((always_inline)) void list_del_init(struct
list_head *entry)
{
__list_del(entry->next);
(entry)->next = (entry);
};
struct dentry {
void *d_fsdata;
};
struct sysfs_dirent {
struct list_head s_sibling;
struct list_head s_children;
};
void sysfs_hash_and_remove(struct dentry * dir, const char * name)
{
struct sysfs_dirent * sd;
struct sysfs_dirent * parent_sd = dir->d_fsdata;
for (sd = ((&parent_sd->s_children)->next);
&sd->s_sibling != (&parent_sd->s_children);
sd = sd->s_sibling.next) {
if (!__builtin_strcmp(sysfs_get_name(sd), name))
{
list_del_init(&sd->s_sibling);
break;
}
}
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
||org
Status|WAITING |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2006-01-11 13:07:38
date||
Summary|ice for legal kernel code |[4.2 Regression] ice for
|with -Os|legal kernel code with -Os
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25734
[Bug tree-optimization/23948] [4.1/4.2 Regression] internal compiler error: verify_stmts failed
--- Comment #22 from bonzini at gnu dot org 2006-01-11 13:02 --- Subject: Bug 23948 Author: bonzini Date: Wed Jan 11 13:02:18 2006 New Revision: 109578 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109578 Log: gcc: 2006-01-11 Paolo Bonzini <[EMAIL PROTECTED]> PR tree-optimization/23109 PR tree-optimization/23948 PR tree-optimization/24123 * Makefile.in (tree-ssa-math-opts.o): Adjust dependencies. * tree-cfg.c (single_noncomplex_succ): New. * tree-flow.h (single_noncomplex_succ): Declare it. * tree-ssa-math-opts.c (enum place_reciprocal): Remove. * tree-ssa-math-opts.c (enum place_reciprocal): Remove. (struct occurrence, occ_head, occ_pool, is_divide_by, compute_merit, insert_bb, register_division_in, insert_reciprocals, replace_reciprocal, free_bb): New. (execute_cse_reciprocals_1): Rewritten. (execute_cse_reciprocals): Adjust calls to execute_cse_reciprocals_1. Do not commit any edge insertion. Always compute dominators and create the allocation pool. * target-def.h (TARGET_MIN_DIVISIONS_FOR_RECIP_MUL): New. * target.h (struct gcc_target): Add min_divistions_for_recip_mul. * targhooks.c (default_min_divistions_for_recip_mul): New. * targhooks.h (default_min_divistions_for_recip_mul): New prototype. * passes.c (init_optimization_passes): Run recip after tree loop optimizations. * doc/tm.texi (Misc): Document TARGET_MIN_DIVISIONS_FOR_RECIP_MUL. gcc/testsuite: 2006-01-11 Paolo Bonzini <[EMAIL PROTECTED]> PR tree-optimization/23109 PR tree-optimization/23948 PR tree-optimization/24123 * gcc.dg/tree-ssa/recip-3.c, gcc.dg/tree-ssa/recip-4.c, gcc.dg/tree-ssa/recip-5.c, gcc.dg/tree-ssa/recip-6.c, gcc.dg/tree-ssa/recip-7.c, gcc.dg/tree-ssa/pr23109.c, g++.dg/tree-ssa/pr23948.C: New testcases. * gcc.dg/tree-ssa/recip-2.c, gcc.dg/tree-ssa/pr23234.c: Provide three divisions in order to do the optimization. Added: trunk/gcc/testsuite/g++.dg/tree-ssa/pr23948.C trunk/gcc/testsuite/gcc.dg/tree-ssa/pr23109.c trunk/gcc/testsuite/gcc.dg/tree-ssa/recip-3.c trunk/gcc/testsuite/gcc.dg/tree-ssa/recip-4.c trunk/gcc/testsuite/gcc.dg/tree-ssa/recip-5.c trunk/gcc/testsuite/gcc.dg/tree-ssa/recip-6.c trunk/gcc/testsuite/gcc.dg/tree-ssa/recip-7.c Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/doc/tm.texi trunk/gcc/passes.c trunk/gcc/target-def.h trunk/gcc/target.h trunk/gcc/targhooks.c trunk/gcc/targhooks.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/pr23234.c trunk/gcc/testsuite/gcc.dg/tree-ssa/recip-2.c trunk/gcc/tree-cfg.c trunk/gcc/tree-flow.h trunk/gcc/tree-ssa-math-opts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23948
[Bug tree-optimization/24123] [4.1/4.2 Regression] Massive performance regression for -ffast-math due to the recip tree pass
--- Comment #26 from bonzini at gnu dot org 2006-01-11 13:02 --- Subject: Bug 24123 Author: bonzini Date: Wed Jan 11 13:02:18 2006 New Revision: 109578 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109578 Log: gcc: 2006-01-11 Paolo Bonzini <[EMAIL PROTECTED]> PR tree-optimization/23109 PR tree-optimization/23948 PR tree-optimization/24123 * Makefile.in (tree-ssa-math-opts.o): Adjust dependencies. * tree-cfg.c (single_noncomplex_succ): New. * tree-flow.h (single_noncomplex_succ): Declare it. * tree-ssa-math-opts.c (enum place_reciprocal): Remove. * tree-ssa-math-opts.c (enum place_reciprocal): Remove. (struct occurrence, occ_head, occ_pool, is_divide_by, compute_merit, insert_bb, register_division_in, insert_reciprocals, replace_reciprocal, free_bb): New. (execute_cse_reciprocals_1): Rewritten. (execute_cse_reciprocals): Adjust calls to execute_cse_reciprocals_1. Do not commit any edge insertion. Always compute dominators and create the allocation pool. * target-def.h (TARGET_MIN_DIVISIONS_FOR_RECIP_MUL): New. * target.h (struct gcc_target): Add min_divistions_for_recip_mul. * targhooks.c (default_min_divistions_for_recip_mul): New. * targhooks.h (default_min_divistions_for_recip_mul): New prototype. * passes.c (init_optimization_passes): Run recip after tree loop optimizations. * doc/tm.texi (Misc): Document TARGET_MIN_DIVISIONS_FOR_RECIP_MUL. gcc/testsuite: 2006-01-11 Paolo Bonzini <[EMAIL PROTECTED]> PR tree-optimization/23109 PR tree-optimization/23948 PR tree-optimization/24123 * gcc.dg/tree-ssa/recip-3.c, gcc.dg/tree-ssa/recip-4.c, gcc.dg/tree-ssa/recip-5.c, gcc.dg/tree-ssa/recip-6.c, gcc.dg/tree-ssa/recip-7.c, gcc.dg/tree-ssa/pr23109.c, g++.dg/tree-ssa/pr23948.C: New testcases. * gcc.dg/tree-ssa/recip-2.c, gcc.dg/tree-ssa/pr23234.c: Provide three divisions in order to do the optimization. Added: trunk/gcc/testsuite/g++.dg/tree-ssa/pr23948.C trunk/gcc/testsuite/gcc.dg/tree-ssa/pr23109.c trunk/gcc/testsuite/gcc.dg/tree-ssa/recip-3.c trunk/gcc/testsuite/gcc.dg/tree-ssa/recip-4.c trunk/gcc/testsuite/gcc.dg/tree-ssa/recip-5.c trunk/gcc/testsuite/gcc.dg/tree-ssa/recip-6.c trunk/gcc/testsuite/gcc.dg/tree-ssa/recip-7.c Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/doc/tm.texi trunk/gcc/passes.c trunk/gcc/target-def.h trunk/gcc/target.h trunk/gcc/targhooks.c trunk/gcc/targhooks.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/pr23234.c trunk/gcc/testsuite/gcc.dg/tree-ssa/recip-2.c trunk/gcc/tree-cfg.c trunk/gcc/tree-flow.h trunk/gcc/tree-ssa-math-opts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24123
[Bug tree-optimization/23109] [4.1/4.2 Regression] compiler generates wrong code leading to spurious division by zero with -funsafe-math-optimizations (instead of -ftrapping-math)
--- Comment #15 from bonzini at gnu dot org 2006-01-11 13:02 --- Subject: Bug 23109 Author: bonzini Date: Wed Jan 11 13:02:18 2006 New Revision: 109578 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109578 Log: gcc: 2006-01-11 Paolo Bonzini <[EMAIL PROTECTED]> PR tree-optimization/23109 PR tree-optimization/23948 PR tree-optimization/24123 * Makefile.in (tree-ssa-math-opts.o): Adjust dependencies. * tree-cfg.c (single_noncomplex_succ): New. * tree-flow.h (single_noncomplex_succ): Declare it. * tree-ssa-math-opts.c (enum place_reciprocal): Remove. * tree-ssa-math-opts.c (enum place_reciprocal): Remove. (struct occurrence, occ_head, occ_pool, is_divide_by, compute_merit, insert_bb, register_division_in, insert_reciprocals, replace_reciprocal, free_bb): New. (execute_cse_reciprocals_1): Rewritten. (execute_cse_reciprocals): Adjust calls to execute_cse_reciprocals_1. Do not commit any edge insertion. Always compute dominators and create the allocation pool. * target-def.h (TARGET_MIN_DIVISIONS_FOR_RECIP_MUL): New. * target.h (struct gcc_target): Add min_divistions_for_recip_mul. * targhooks.c (default_min_divistions_for_recip_mul): New. * targhooks.h (default_min_divistions_for_recip_mul): New prototype. * passes.c (init_optimization_passes): Run recip after tree loop optimizations. * doc/tm.texi (Misc): Document TARGET_MIN_DIVISIONS_FOR_RECIP_MUL. gcc/testsuite: 2006-01-11 Paolo Bonzini <[EMAIL PROTECTED]> PR tree-optimization/23109 PR tree-optimization/23948 PR tree-optimization/24123 * gcc.dg/tree-ssa/recip-3.c, gcc.dg/tree-ssa/recip-4.c, gcc.dg/tree-ssa/recip-5.c, gcc.dg/tree-ssa/recip-6.c, gcc.dg/tree-ssa/recip-7.c, gcc.dg/tree-ssa/pr23109.c, g++.dg/tree-ssa/pr23948.C: New testcases. * gcc.dg/tree-ssa/recip-2.c, gcc.dg/tree-ssa/pr23234.c: Provide three divisions in order to do the optimization. Added: trunk/gcc/testsuite/g++.dg/tree-ssa/pr23948.C trunk/gcc/testsuite/gcc.dg/tree-ssa/pr23109.c trunk/gcc/testsuite/gcc.dg/tree-ssa/recip-3.c trunk/gcc/testsuite/gcc.dg/tree-ssa/recip-4.c trunk/gcc/testsuite/gcc.dg/tree-ssa/recip-5.c trunk/gcc/testsuite/gcc.dg/tree-ssa/recip-6.c trunk/gcc/testsuite/gcc.dg/tree-ssa/recip-7.c Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/doc/tm.texi trunk/gcc/passes.c trunk/gcc/target-def.h trunk/gcc/target.h trunk/gcc/targhooks.c trunk/gcc/targhooks.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/pr23234.c trunk/gcc/testsuite/gcc.dg/tree-ssa/recip-2.c trunk/gcc/tree-cfg.c trunk/gcc/tree-flow.h trunk/gcc/tree-ssa-math-opts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23109
[Bug target/25749] -msoft-float doesn't generate library calls.
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-11 12:44 --- SSE is not floating point in general. It is just used as the floating point but it is just the vector unit. Your "work around" is the true fix. -msoft-float only deals with the x87 part and not the SSE part. -- 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=25749
[Bug c++/25748] Template instantiated twice
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-11 12:42 ---
3) And also defined in the anonymous namespace in another module:
namespace { template T foo::t = 0; }
That is invalid code as you are instantiating in a different namespace. I
think there is a bug about accepting this code (I have not looked yet).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25748
[Bug c++/25632] [4.0 Regression] ICE with const int copied into two different functions
--- Comment #15 from rakdver at gcc dot gnu dot org 2006-01-11 11:39 --- Subject: Bug 25632 Author: rakdver Date: Wed Jan 11 11:39:49 2006 New Revision: 109575 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109575 Log: PR c++/25632 * g++.dg/other/pr25632.C: New test. Added: trunk/gcc/testsuite/g++.dg/other/pr25632.C Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25632
[Bug tree-optimization/25734] ice for legal kernel code with -Os
--- Comment #2 from dcb314 at hotmail dot com 2006-01-11 11:31 --- Created an attachment (id=10619) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10619&action=view) C source code which causes crash with -Os I've stripped out about 3,000 lines of source code to get the attachment down in size. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25734
