[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #138 from jv244 at cam dot ac dot uk 2007-07-24 06:31 --- (In reply to comment #137) > Joost, > > Are you seeing this on bench01 and bench02? - this is on yesterday's tree > By chance I ran a test yesterday evening (rev. 126856) which ran OK. This was on an opteron with '"-O3 -ffast-math -ftree-vectorize -march=native"'. I'll start a new test with current trunk. The crash could of course be arch/option sensitive. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #137 from pault at gcc dot gnu dot org 2007-07-24 06:18 --- Joost, Are you seeing this on bench01 and bench02? - this is on yesterday's tree Program received signal SIGSEGV, Segmentation fault. 0x00c67e4a in __topology_util_MOD_topology_set_atm_mass () (gdb) backtrace #0 0x00c67e4a in __topology_util_MOD_topology_set_atm_mass () #1 0x00c14fb0 in __topology_MOD_connectivity_control () #2 0x00c158cc in __topology_MOD_topology_control () #3 0x009e3709 in __qs_environment_MOD_qs_init () #4 0x00abd19d in __qs_main_MOD_quickstep_create_force_env () #5 0x00597029 in __f77_interface_MOD_create_force_env () #6 0x004b0b5f in __cp2k_runs_MOD_cp2k_run () #7 0x004b2652 in __cp2k_runs_MOD_run_input () #8 0x004abc51 in MAIN__ () #9 0x00de593e in main (argc=14571838, argv=0x2) at ../../../trunk/libgfortran/fmain.c:22 Cheers Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug fortran/30814] non-conforming array sizes in PACK should raise an error
--- Comment #3 from tkoenig at gcc dot gnu dot org 2007-07-24 05:52 --- Subject: Bug 30814 Author: tkoenig Date: Tue Jul 24 05:52:44 2007 New Revision: 126866 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126866 Log: 2007-07-24 Thomas Koenig <[EMAIL PROTECTED]> PR fortran/30814 * trans-decl.c (generate_function_code): Add argument for flag_bounds_check to the array for set_options. * invoke.texi: Mention that some checks require -fbounds-check to be set during compilation of the main program. 2007-07-24 Thomas Koenig <[EMAIL PROTECTED]> PR fortran/30814 * libgfortran.h: Add bounds_check to compile_options_t. * runtime/compile_options.c (set_options): Add handling of compile_options.bounds_check. * intrinsics/pack_generic.c (pack_internal): Also determine the number of elements if compile_options.bounds_check is true. Raise runtime error if a different array shape is detected. 2007-07-24 Thomas Koenig <[EMAIL PROTECTED]> PR fortran/30814 * gfortran.dg/pack_bounds_1.f90: New test case. Added: trunk/gcc/testsuite/gfortran.dg/pack_bounds_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/invoke.texi trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/intrinsics/pack_generic.c trunk/libgfortran/runtime/compile_options.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30814
[Bug bootstrap/32101] xgcc invokes as with invalid -m option while assembling crtbegin.o
--- Comment #4 from mfouts at danger dot com 2007-07-24 05:17 --- OK, so this one's weird and starts out as a user error. If the path specified in --prefix=/usr/local/armdev-$CPU-4.2.0 in the original config is *not* writable by the account running the build, the make all-gcc fails with the bizarre error indicated in the original bug report. If the path specified *is* writable, then the build finishes just fine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32101
[Bug fortran/32867] [4.3 Regression] 459.GemsFDTD in SPEC CPU 2006 fails to compile
--- Comment #12 from hjl at lucon dot org 2007-07-24 03:33 --- (In reply to comment #9) > Currently regtesting the patch below without problem so far. > H.J. could you please verify that it fixes your problem? > > Index: expr.c > === > --- expr.c (revision 126826) > +++ expr.c (working copy) > @@ -2121,7 +2132,7 @@ > } > >if (m == MATCH_YES) > - t = SUCCESS; > + t = gfc_simplify_expr (e, 0); > >break; > I have verified that 459.GemsFDTD is compiled correctly with this patch. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32867
[Bug target/30271] -mstrict-align can cause bad code generation for struct agrument passing
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-07-24 02:14 --- (In reply to comment #2) > This is improved by > http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00573.html Also the store is still there: .L.f: srawi 0,3,16 stw 3,48(1) extsw 3,0 blr -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30271
[Bug target/30271] -mstrict-align can cause bad code generation for struct agrument passing
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-07-24 02:14 ---
This is improved by
http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00573.html
But for:
struct a
{
int t, t1;
};
int f(struct a b)
{
return b.t + b.t1;
}
We still get a store/load.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30271
[Bug middle-end/32761] [4.3 Regression] build broke: var_tracking loses track of register elimination, crashes in find_src_set_src on parallel set
--- Comment #5 from hp at gcc dot gnu dot org 2007-07-24 00:58 --- Caroline Tice, by the lack of comments I kind of doubt you're reading this, but for the record, there should have been a PR middle-end/32761 marker in the ChangeLog entry and one for PR32764; there are several examples of the format. I'm closing this PR as it was fixed by revision 126731. -- hp at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32761
[Bug middle-end/32852] [4.3 Regression] g++.old-deja/g++.jason/synth7.C
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-07-24 00:34 --- Confirmed, I saw this also. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC target triplet||i?86-*-linux-gnu x86_64- ||linux-gnu Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2007-07-24 00:34:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32852
[Bug tree-optimization/32852] [4.3 Regression] g++.old-deja/g++.jason/synth7.C
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32852
[Bug other/32859] [4.3 Regression] "make info" fails in libiberty
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32859
[Bug regression/32872] [4.3 Regression] Many tests fail with incorrect warning about inline function
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-23 23:52 --- I think this is related to the patch posted at: http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01668.html -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||diagnostic, wrong-code Summary|Many tests fail with|[4.3 Regression] Many tests |incorrect warning about |fail with incorrect warning |inline function |about inline function Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32872
[Bug tree-optimization/32873] [4.3 Regression] glibc ICE's gcc-4.3.0 SSA corruption
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-23 23:30 --- Value numbering spec_28(ab) stmt = spec_28(ab) = PHI Setting value number of spec_28(ab) to spec_7(ab) We should not value number this PHI node, yes it is a copy but a needed copy for abnormal edges. Note the reduced testcase is missing an optimization but that is already filed as PR 32810. -- 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 |2007-07-23 23:30:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32873
[Bug tree-optimization/32865] [4.3 Regression] glibc ICE's gcc-4.3.0 SSA corruption
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-07-23 23:30 --- As mentioned before closing this bug. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32865
[Bug tree-optimization/32865] [4.3 Regression] glibc ICE's gcc-4.3.0 SSA corruption
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-07-23 23:29 --- > Using a colleague's i686 machine vfprintf.c did not fail with recent gcc-4.3. > This led to further research prompting not only the CC's but also the quote. If it does not fail on i686 with the non preprocessed source does not mean it is a target specific bug. The quote is offtopic really. >Dr. Edelsohn metioned triage but there are no triage officers in the MAINTERNER list. Right because I am the unofficial bug maintainer :). With response to the glibc issue, Uli is the one who is holding glibc hositage anyways. Anyways, to make this bug cleaner, I am going to close this bug and I opened a new one as PR 32873. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC|dje at watson dot ibm dot | |com | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32865
[Bug tree-optimization/32873] [4.3 Regression] glibc ICE's gcc-4.3.0 SSA corruption
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32873
[Bug tree-optimization/32873] New: [4.3 Regression] glibc ICE's gcc-4.3.0 SSA corruption
Unable to coalesce ssa_names 1221 and 144 which are marked as MUST COALESCE.
is_long_double_1221(ab) and is_long_double_144(ab)
vfprintf.c: In function '_IO_vfprintf_internal':
vfprintf.c:184: internal compiler error: SSA corruption
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
Testcase:
void _IO_vfprintf_internal ( char *f )
{
static const void *const step0_jumps[] = { &&do_form_unknown, &&do_flag_plus,
&&do_form_float };
const void * ptr = step0_jumps[0];
do {
char spec;
spec = (*++f);
goto *ptr;
do_flag_plus:
read_int (&f);
do_number:
_itoa_word (spec);
do_form_float:
if (ptr != ((void *)0))
{
spec = 'x';
goto do_number;
}
if (spec != 'S')
__strnlen ();
return;
do_form_unknown:;
}
while (*f != '\0');
}
--
Summary: [4.3 Regression] glibc ICE's gcc-4.3.0 SSA corruption
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32873
[Bug tree-optimization/32865] [4.3 Regression] glibc ICE's gcc-4.3.0 SSA corruption
--- Comment #11 from michelin60 at gmail dot com 2007-07-23 23:17 --- Very interesting Using a colleague's i686 machine vfprintf.c did not fail with recent gcc-4.3. This led to further research prompting not only the CC's but also the quote. Dr. Edelsohn metioned triage but there are no triage officers in the MAINTERNER list. Also it might be useful to spell out the rights of submitters. It might discourage submissions which are quite onerous to conform to the already stated requirements. >From his webpage Mr. Berlin is a lawyer specializing in intellectual property and is also an author. He might want to provide some legal advice on conflicts of interest. The quote is specific to glibc and AIX. Potentially the AIX contortions forced upon glibc by Dr. Edelsohn could have caused the specific problem reported, not affecting i686. As an aside the officers of kernel.org (Torvalds, Morton) spell out quite clearly how they are not liable to any interpretation of conflict of interest. -- michelin60 at gmail dot com changed: What|Removed |Added CC||dje at watson dot ibm dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32865
[Bug target/29524] [4.2/4.3 Regression] Too much RAM used: __clz_tab[] linked
-- eweddington at cso dot atmel dot com changed: What|Removed |Added Target Milestone|4.2.1 |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29524
[Bug target/29524] [4.2/4.3 Regression] Too much RAM used: __clz_tab[] linked
--- Comment #9 from eweddington at cso dot atmel dot com 2007-07-23 22:57 --- Here's what I see: The array __clz_tab is used in a macro, count_leading_zeros, which is called in the function __clzSI2 in libgcc2.c, which (AFAICT) gets compiled to the function __clzsi2 and aggregated in libgcc. The __clzsi2 function is called from the function clzusi() (in fp-bit.c) which is also included in libgcc. The clzusi() function is called from si_to_float() and usi_to_float() (also in fp-bit.c and included in libgcc). AFAICT, these two functions are used to convert an int or unsigned int to float. The test case does exactly this type of conversion in main() in comment #5. Testing shows that with gcc 4.2.1, and all int-to-float conversions removed, that __clz_tab is correctly not linked into the application. The clzusi() function was created in revision 107345, on Nov 22, 2005: http://gcc.gnu.org/viewcvs?view=rev&revision=107345 This seems like it was an intended change. However, it is unfortunate that a 256-byte array is used in the count_leading_zeros macro. While using a table is fast and the size is neglible on larger platforms, using up 256 bytes is very significant on the AVR where 4K, 2K or even 1K of RAM is common. What is really needed is an alternative implementation (non-array) that is perhaps specific to the AVR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29524
[Bug middle-end/27002] [4.3 regression] ICE with -fipa-pta when calling a function
--- Comment #3 from reichelt at gcc dot gnu dot org 2007-07-23 22:26 --- Since the 4.2 branch doesn't show the bug, we have a regression. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Summary|ICE with -fipa-pta when |[4.3 regression] ICE with - |calling a function |fipa-pta when calling a ||function Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27002
[Bug middle-end/27002] ICE with -fipa-pta when calling a function
--- Comment #2 from reichelt at gcc dot gnu dot org 2007-07-23 22:22 --- The problem disappeared on the 4.2 branch (already for GCC 4.2.0), but is still present on the trunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27002
[Bug c++/24602] g++: Internal error: Illegal instruction (program cc1plus)
--- Comment #9 from reichelt at gcc dot gnu dot org 2007-07-23 22:08 --- *** Bug 24606 has been marked as a duplicate of this bug. *** -- Bug 24602 depends on bug 24606, which changed state. Bug 24606 Summary: ICE on template function which gets an template agrument as a function with a default argument http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24606 What|Old Value |New Value Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24602
[Bug c++/24606] ICE on template function which gets an template agrument as a function with a default argument
--- Comment #3 from reichelt at gcc dot gnu dot org 2007-07-23 22:08 --- Since Nathan's patch for PR32839 we get the same error message for PR24602 as for PR24606. This really looks like a duplicate. *** This bug has been marked as a duplicate of 24602 *** -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Keywords|ice-on-valid-code |ice-on-invalid-code Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24606
[Bug c++/24602] g++: Internal error: Illegal instruction (program cc1plus)
--- Comment #8 from reichelt at gcc dot gnu dot org 2007-07-23 22:05 --- Since Nathan's patch for PR32839, we get the following error message for the testcase in comment #7 (and similar messages for the original testcase, the testcase in comment #6, and PR 24606): bug.cc: In function 'void foo(F) [with F = void (*)(A)]': bug.cc:16: instantiated from here bug.cc:3: error: too few arguments to function I get the same error message if I make bar a non-template function. In contrast to my last sentence of comment #7, I now think the compiler does the right thing here. Nathan, do you think so, too? If yes, we can close this bug as fixed. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||nathan at gcc dot gnu dot ||org Keywords|ice-on-valid-code |ice-on-invalid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24602
[Bug libstdc++/32851] Sort of vector of template class fails
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-07-23 21:55 ---
The error message is:
/home/apinski/x86-local-fsf/lib/gcc/i686-pc-linux-gnu/4.3.0/../../../../include/c++/4.3.0/bits/stl_algo.h:2789:
instantiated from 'void std::sort(_RandomAccessIterator,
_RandomAccessIterator) [with _RandomAccessIterator =
__gnu_cxx::__normal_iterator >
>]'
t1212.cc:17: instantiated from 'void cards::sort() [with MyCard =
card]'
t1212.cc:25: instantiated from here
/home/apinski/x86-local-fsf/lib/gcc/i686-pc-linux-gnu/4.3.0/../../../../include/c++/4.3.0/bits/stl_algo.h:92:
error: passing 'const card' as 'this' argument of 'bool card::operator<(const
card&)' discards qualifiers
This is correct, you need to mark operator< as taking a const this variable.
Like:
bool operator<(const card & A)const { return this->id < A.id;};
Once doing that, the program compiles.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Component|c++ |libstdc++
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32851
[Bug tree-optimization/32746] [4.3 Regression] tree-ssa-operands int.comp error
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-07-23 21:38 --- Fixed by: http://gcc.gnu.org/viewcvs?view=rev&revision=126857 -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32746
[Bug tree-optimization/32865] [4.3 Regression] glibc ICE's gcc-4.3.0 SSA corruption
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-07-23 21:35 --- Value numbering spec_28(ab) stmt = spec_28(ab) = PHI Setting value number of spec_28(ab) to spec_7(ab) We should not value number this PHI node, yes it is a copy but a needed copy for abnormal edges. Note the reduced testcase is missing an optimization but that is already filed as PR 32810. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32865
[Bug c++/29727] [4.2/4.3 regression] ICE on invalid initializer for template member
--- Comment #3 from reichelt at gcc dot gnu dot org 2007-07-23 21:31 --- The bug disappeared on the 4.1 branch (already in GCC 4.1.2). It is still present on the 4.2 branch and mainline. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1/4.2/4.3 regression]|[4.2/4.3 regression] ICE on |ICE on invalid initializer |invalid initializer for |for template member |template member Target Milestone|4.1.3 |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29727
[Bug tree-optimization/32865] [4.3 Regression] glibc ICE's gcc-4.3.0 SSA corruption
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-07-23 21:31 ---
Generic (also ICEs on i686-linux-gnu) reduced testcase:
void _IO_vfprintf_internal ( char *f )
{
static const void *const step0_jumps[] = { &&do_form_unknown, &&do_flag_plus,
&&do_form_float };
const void * ptr = step0_jumps[0];
do {
char spec;
spec = (*++f);
goto *ptr;
do_flag_plus:
read_int (&f);
do_number:
_itoa_word (spec);
do_form_float:
if (ptr != ((void *)0))
{
spec = 'x';
goto do_number;
}
if (spec != 'S')
__strnlen ();
return;
do_form_unknown:;
}
while (*f != '\0');
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
GCC build triplet|rs6000 |
GCC host triplet|rs6000 |
GCC target triplet|rs6000 |
Keywords||ice-on-valid-code
Last reconfirmed|-00-00 00:00:00 |2007-07-23 21:31:48
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32865
[Bug c++/27211] Bogus error "template definition of non-template" when there is no non-template
--- Comment #5 from reichelt at gcc dot gnu dot org 2007-07-23 20:55 --- On mainline the diagnostic for the second testcase got even worse: bug.cc:3: error: no 'void A::foo()' member function declared in class 'A' bug.cc:3: error: prototype for 'void A::foo()' does not match any in class 'A' bug.cc:3: error: candidate is: void A::foo() bug.cc:3: error: 'void A::foo()' cannot be overloaded bug.cc:3: error: with 'void A::foo()' bug.cc:3: error: declaration of 'void A::foo()' outside of class is not definition bug.cc:3: error: template definition of non-template 'void A::foo()' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27211
[Bug regression/32849] Unnecessary %esp inc/decrements in trivial code
--- Comment #7 from vda dot linux at googlemail dot com 2007-07-23 20:50 --- I want to apologise. Apparently this behavior (16-byte stack alignment) can be turned off with an option => I can still have just word-aligned stack. As long as that still works, I am a more-or-less happy camper. Sorry guys. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32849
[Bug fortran/31639] [4.1/4.2/4.3] ICE in gfc_conv_constant, at fortran/trans-const.c:348 with len
--- Comment #13 from dfranke at gcc dot gnu dot org 2007-07-23 20:45 --- Closing again. The orginal testcase is now correctly handled for all standards. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31639
[Bug regression/32872] New: Many tests fail with incorrect warning about inline function
If I do a bootstrap build of GCC I get a large (160+) number of C test failures
due to extra warning output. This only happens with a bootstrap build so I
think GCC is miscompiling itself. The included program gives the warning:
x.c:2: warning: inline function 'foo' given attribute noinline
Which it should not give because the function was not declared to be inline.
The test case is:
void __attribute__ ((__noinline__)) foo (int xf)
{
}
int main()
{
foo (1);
return 0;
}
--
Summary: Many tests fail with incorrect warning about inline
function
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sje at cup dot hp dot com
GCC host triplet: ia64-*-linux-gnu
GCC target triplet: ia64-*-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32872
[Bug fortran/25104] [F2003] Non-initialization expr. as case-selector
--- Comment #10 from dfranke at gcc dot gnu dot org 2007-07-23 20:38 --- Commit shown in comment #9 restores the situation as described in comment #8, no further development yet. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25104
[Bug fortran/31639] [4.1/4.2/4.3] ICE in gfc_conv_constant, at fortran/trans-const.c:348 with len
--- Comment #12 from dfranke at gcc dot gnu dot org 2007-07-23 20:35 --- Subject: Bug 31639 Author: dfranke Date: Mon Jul 23 20:35:03 2007 New Revision: 126858 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126858 Log: gcc/fortran: 2007-07-23 Daniel Franke <[EMAIL PROTECTED]> PR fortran/25104 PR fortran/31639 * expr.c (check_transformational): Reject valid transformational intrinsics to avoid ICE. (check_inquiry): Report error for assumed character lengths for all supported standards. (check_init_expr): Whitespace fix. gcc/testsuite: 2007-07-23 Daniel Franke <[EMAIL PROTECTED]> PR fortran/31639 * gfortran.dg/initialization_9.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/initialization_9.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31639
[Bug fortran/25104] [F2003] Non-initialization expr. as case-selector
--- Comment #9 from dfranke at gcc dot gnu dot org 2007-07-23 20:35 --- Subject: Bug 25104 Author: dfranke Date: Mon Jul 23 20:35:03 2007 New Revision: 126858 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126858 Log: gcc/fortran: 2007-07-23 Daniel Franke <[EMAIL PROTECTED]> PR fortran/25104 PR fortran/31639 * expr.c (check_transformational): Reject valid transformational intrinsics to avoid ICE. (check_inquiry): Report error for assumed character lengths for all supported standards. (check_init_expr): Whitespace fix. gcc/testsuite: 2007-07-23 Daniel Franke <[EMAIL PROTECTED]> PR fortran/31639 * gfortran.dg/initialization_9.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/initialization_9.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25104
[Bug fortran/32867] [4.3 Regression] 459.GemsFDTD in SPEC CPU 2006 fails to compile
--- Comment #11 from dfranke at gcc dot gnu dot org 2007-07-23 20:08 --- Patch in comment #9 passed regression testing on i686-pc-linux-gnu. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32867
[Bug fortran/32867] [4.3 Regression] 459.GemsFDTD in SPEC CPU 2006 fails to compile
--- Comment #10 from hjl at lucon dot org 2007-07-23 19:53 --- (In reply to comment #9) > Currently regtesting the patch below without problem so far. > H.J. could you please verify that it fixes your problem? > > Index: expr.c > === > --- expr.c (revision 126826) > +++ expr.c (working copy) > @@ -2121,7 +2132,7 @@ > } > >if (m == MATCH_YES) > - t = SUCCESS; > + t = gfc_simplify_expr (e, 0); > >break; > It passed my small testcase. The full test will take several hours. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32867
[Bug other/32859] [4.3 Regression] "make info" fails in libiberty
--- Comment #4 from tkoenig at gcc dot gnu dot org 2007-07-23 19:47 --- Yes, it's fixed now. Thanks! -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32859
[Bug fortran/32867] [4.3 Regression] 459.GemsFDTD in SPEC CPU 2006 fails to compile
--- Comment #9 from dfranke at gcc dot gnu dot org 2007-07-23 19:42 --- Currently regtesting the patch below without problem so far. H.J. could you please verify that it fixes your problem? Index: expr.c === --- expr.c (revision 126826) +++ expr.c (working copy) @@ -2121,7 +2132,7 @@ } if (m == MATCH_YES) - t = SUCCESS; + t = gfc_simplify_expr (e, 0); break; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32867
[Bug c++/30818] [4.1/4.2 Regression] templates and typedefs cause function prototype not to match
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-07-23 19:24 --- Re-open, as the branches are still affected and this is a regression. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Known to fail|4.1.2 4.2.0 4.3.0 |4.1.2 4.2.0 Known to work|3.4.6 4.1.1 |3.4.6 4.1.1 4.3.0 Resolution|FIXED | Summary|[4.1/4.2/4.3 Regression]|[4.1/4.2 Regression] |templates and typedefs cause|templates and typedefs cause |function prototype not to |function prototype not to |match |match http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30818
[Bug c/32871] New: Bad optimasation - Gcc is pushing to many registers
Let's look at this:
long foo(long a, long b, long c, uint8_t d){
if(d){
return a+b;
}else{
return a-c;
}
}
The listing reports this:
long foo(long a, long b, long c, uint8_t d){
4e: cf 92 push r12 ;All this registers are pushed
50: ef 92 push r14 ;despite it's unessecary
52: ff 92 push r15 ;
54: 0f 93 push r16
56: 1f 93 push r17
if(d){
58: cc 20 and r12, r12
5a: 29 f0 breq .+10; 0x66
return a+b;
5c: 62 0f add r22, r18
5e: 73 1f adc r23, r19
60: 84 1f adc r24, r20
62: 95 1f adc r25, r21
64: 04 c0 rjmp .+8 ; 0x6e
}else{
return a-c;
66: 6e 19 sub r22, r14
68: 7f 09 sbc r23, r15
6a: 80 0b sbc r24, r16
6c: 91 0b sbc r25, r17
6e: 1f 91 pop r17 ;And they are getting restored
70: 0f 91 pop r16 ;despite they are not changed.
72: ff 90 pop r15
74: ef 90 pop r14
76: cf 90 pop r12
78: 08 95 ret
During all operation in the low register (r3-r17) are always zero, and they are
never changed in the hole file and even not in the function itself. So it's
useless to push and pop them, we're only loosing time, space and ram.
Please excuse my bad bug-reporting-style. This is my first report. For further
explainaition I can recomment you the german site, where this problem is beeing
discussed.
http://www.roboternetz.de/phpBB2/viewtopic.php?p=300953
I hope you can fix this.
Michael
--
Summary: Bad optimasation - Gcc is pushing to many registers
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: info at umfragen-service dot de
GCC build triplet: Linux - Slax
GCC host triplet: Linux - Slax
GCC target triplet: avr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32871
[Bug c++/32870] New: Unclear error message when declaring struct in wrong namespace
Compiling this code:
struct Foo {
struct Bar;
Foo();
};
namespace Baz {
Foo::Foo() { }
struct Foo::Bar { };
}
Gives the following two error messages:
test.C:6: error: definition of 'void Foo::Foo()' is not in namespace enclosing
'Foo'
test.C:7: error: declaration of 'struct Foo::Bar' in 'Baz' which does not
enclose 'struct Foo'
The first error is nice and clear; the second would be much easier to
understand quickly if it also identified 'Baz' as a namespace.
Note: this bug dates back at least as far as g++-3.4.4 (tested on 3.4.4, 4.1.2,
4.2.0 and 4.3-20070716)
--
Summary: Unclear error message when declaring struct in wrong
namespace
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: scovich at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32870
[Bug target/32869] New: _mm_cvtsi64x_si128/_mm_cvtsi64_si128 are valid in 32-bit x86 code as well
it's not clear to me why there is an ifdef __x86_64__ around the definitions of
_mm_cvtsi64_si128/_mm_cvtsi64x_si128 in emmintrin.h. the movq instruction
required to implement those has always been present in sse2 -- even on 32-bit
hosts.
gcc seems to do the right thing already if i just remove the #ifdef
__x86_64__... for example:
% cat movq.c
#include
#include
static __inline __m128i __attribute__((__always_inline__))
_mm_cvtsi64x_si128 (long long __A)
{
return _mm_set_epi64x (0, __A);
}
void foo(__m128i *x, const uint64_t *y)
{
*x = _mm_cvtsi64x_si128(*y);
}
generates:
:
0: 55 push %ebp
1: 89 e5 mov%esp,%ebp
3: 8b 45 0cmov0xc(%ebp),%eax
6: f3 0f 7e 00 movq (%eax),%xmm0
a: 8b 45 08mov0x8(%ebp),%eax
d: 66 0f 7f 00 movdqa %xmm0,(%eax)
11: 5d pop%ebp
12: c3 ret
(mind you i used a 4.1.2 gcc there, not 4.3... 'cause i neglected to build the
32-bit 4.3.x gcc. but the ifdefs are still present in the header file.)
-dean
--
Summary: _mm_cvtsi64x_si128/_mm_cvtsi64_si128 are valid in 32-bit
x86 code as well
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dean at arctic dot org
GCC build triplet: i686-unknown-linux-gnu
GCC host triplet: i686-unknown-linux-gnu
GCC target triplet: i686-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32869
[Bug tree-optimization/32865] [4.3 Regression] glibc ICE's gcc-4.3.0 SSA corruption
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-07-23 18:56 --- Working on a reduced testcase but when I quickly looked into it, PRE was messing up the variables that have abnormal set so this is unrelated to the rs6000 back-end. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC|dje at watson dot ibm dot |dberlin at gcc dot gnu dot |com, amacleod at redhat dot |org |com, drepper at redhat dot | |com | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32865
[Bug fortran/32867] [4.3 Regression] 459.GemsFDTD in SPEC CPU 2006 fails to compile
--- Comment #8 from dfranke at gcc dot gnu dot org 2007-07-23 18:50 --- > it is probably not related to the ICE, but the above is invalid F95. > Error: test.f90, line 2: Array constructor values have differing CHARACTER > lengths (11 and 10). gfortran should error out on this. This is PR29267 (and PR32707 is probably a dupe). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32867
[Bug fortran/32867] [4.3 Regression] 459.GemsFDTD in SPEC CPU 2006 fails to compile
--- Comment #7 from jv244 at cam dot ac dot uk 2007-07-23 18:46 --- (In reply to comment #5) > character(80), PARAMETER, dimension(1:2) :: keywords = & >(/'PROBLEMSIZE', & > 'NFTRANS_TD'/) it is probably not related to the ICE, but the above is invalid F95. Error: test.f90, line 2: Array constructor values have differing CHARACTER lengths (11 and 10). gfortran should error out on this. -- jv244 at cam dot ac dot uk changed: What|Removed |Added OtherBugsDependingO||32834 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32867
[Bug tree-optimization/32865] [4.3 Regression] glibc ICE's gcc-4.3.0 SSA corruption
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-07-23 18:42 --- (In reply to comment #6) > Well David here is an interesting quote: Lets put it this way, this quote is true but it is held hostage in a good way. You don't want broken code in your compiler do you? This is what David and AIX does for GCC, they prevent bad code from being in GCC. Have you looked into what has been found via compiling on AIX? Lots of bugs. Who wants bugs in their compiler? Anyways as I have mentioned before, I am 99% sure this is ___NOT___ related to the powerpc back-end at all. And next time please don't CC anyone unless you are sure at what patch caused the issue. Also don't you can't expect a response within 24 hours, GCC developers are busy with their day jobs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32865
[Bug tree-optimization/32865] [4.3 Regression] glibc ICE's gcc-4.3.0 SSA corruption
--- Comment #6 from michelin60 at gmail dot com 2007-07-23 18:33 --- (In reply to comment #5) > Subject: Re: [4.3 Regression] glibc ICE's gcc-4.3.0 SSA corruption > > No, you do not. You submitted the bug. Let the GCC developers > decide how best to triage and analyse the bug. > > David Well David here is an interesting quote: IMO the most notorious case is how the gcc development is held hostage by Edelsohn and maybe IBM as a whole by requesting that everything always works perfectly well on AIX. How often has one seen "this patch breaks AIX, back it out". It cannot reasonably be expected that everybody tests on AIX. It is an proprietary OS running on proprietary and expensive hardware which not many people have access to. The overall development speed could be significantly improved by dropping the AIX requirement which, in some form or another, has been agreed upon by the steering committee. AIX is irrelevant in general today, i.e., the situation changed. And the people in the steering committee are too nice to just tell the very small minority causing the problem to take a hike. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32865
[Bug tree-optimization/32865] [4.3 Regression] glibc ICE's gcc-4.3.0 SSA corruption
--- Comment #5 from dje at watson dot ibm dot com 2007-07-23 18:05 --- Subject: Re: [4.3 Regression] glibc ICE's gcc-4.3.0 SSA corruption > michelin60 at gmail dot com writes: michelin60> Doing a search of PR's filed I came up, surprise, with no remotely equivalent michelin60> report and I chose people that matched what I reported. As the author of the michelin60> report I think that I have the right to choose peple that match as provided by michelin60> the MAINTAINER's list No, you do not. You submitted the bug. Let the GCC developers decide how best to triage and analyse the bug. David -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32865
[Bug tree-optimization/32865] [4.3 Regression] glibc ICE's gcc-4.3.0 SSA corruption
--- Comment #4 from michelin60 at gmail dot com 2007-07-23 18:03 --- (In reply to comment #3) > Stop changing the CC for this bug, the issue is a generic issue and most > likely > unrelated to any of the CC you added. This is more likely to be a PRE issue > than anything else. When I get into work, I will look into it further to > double check. > The three person CC'd are listed per MAINTAINERS as follows: rs600o portDavid Edelsohn c++ runtime libs Ulrich Drepper (also glibc) tree-ssa Andrew Macloed while spu port Andre Pinski (spu ?= playsation.sony.???) Doing a search of PR's filed I came up, surprise, with no remotely equivalent report and I chose people that matched what I reported. As the author of the report I think that I have the right to choose peple that match as provided by the MAINTAINER's list -- michelin60 at gmail dot com changed: What|Removed |Added CC||dje at watson dot ibm dot ||com, amacleod at redhat dot ||com, drepper at redhat dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32865
[Bug fortran/32800] ISO Bind C: C_F_Pointer argument bogus checking
--- Comment #3 from burnus at gcc dot gnu dot org 2007-07-23 17:52 --- FIXED. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32800
[Bug fortran/32797] [ISO C Binding] Internal Error: gfc_basic_typename(): Undefined type
--- Comment #3 from burnus at gcc dot gnu dot org 2007-07-23 17:51 --- FIXED. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32797
[Bug fortran/32800] ISO Bind C: C_F_Pointer argument bogus checking
--- Comment #2 from burnus at gcc dot gnu dot org 2007-07-23 17:47 --- Subject: Bug 32800 Author: burnus Date: Mon Jul 23 17:47:16 2007 New Revision: 126856 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126856 Log: 2007-07-23 Christopher D. Rickett <[EMAIL PROTECTED]> PR fortran/32797 PR fortran/32800 * decl.c (verify_bind_c_sym): Use the result symbol for functions with a result clause. Warn if implicitly typed. Verify the type and rank of the SHAPE argument, if given. * resolve.c (gfc_iso_c_sub_interface): Use gfc_procedure_use to check the actual args against the formal, sorting them if necessary. * symbol.c (gen_shape_param): Initialize type of SHAPE param to BT_VOID. 2007-07-23 Christopher D. Rickett <[EMAIL PROTECTED]> PR fortran/32797 PR fortran/32800 * gfortran.dg/bind_c_usage_8.f03: New test case. * gfortran.dg/c_f_pointer_tests_2.f03: Ditto. * gfortran.dg/c_ptr_tests_5.f03: Updated expected error message. Added: trunk/gcc/testsuite/gfortran.dg/bind_c_usage_8.f03 trunk/gcc/testsuite/gfortran.dg/c_f_pointer_tests_2.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/c_ptr_tests_5.f03 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32800
[Bug fortran/32797] [ISO C Binding] Internal Error: gfc_basic_typename(): Undefined type
--- Comment #2 from burnus at gcc dot gnu dot org 2007-07-23 17:47 --- Subject: Bug 32797 Author: burnus Date: Mon Jul 23 17:47:16 2007 New Revision: 126856 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126856 Log: 2007-07-23 Christopher D. Rickett <[EMAIL PROTECTED]> PR fortran/32797 PR fortran/32800 * decl.c (verify_bind_c_sym): Use the result symbol for functions with a result clause. Warn if implicitly typed. Verify the type and rank of the SHAPE argument, if given. * resolve.c (gfc_iso_c_sub_interface): Use gfc_procedure_use to check the actual args against the formal, sorting them if necessary. * symbol.c (gen_shape_param): Initialize type of SHAPE param to BT_VOID. 2007-07-23 Christopher D. Rickett <[EMAIL PROTECTED]> PR fortran/32797 PR fortran/32800 * gfortran.dg/bind_c_usage_8.f03: New test case. * gfortran.dg/c_f_pointer_tests_2.f03: Ditto. * gfortran.dg/c_ptr_tests_5.f03: Updated expected error message. Added: trunk/gcc/testsuite/gfortran.dg/bind_c_usage_8.f03 trunk/gcc/testsuite/gfortran.dg/c_f_pointer_tests_2.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/c_ptr_tests_5.f03 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32797
[Bug other/32859] [4.3 Regression] "make info" fails in libiberty
--- Comment #3 from dj at redhat dot com 2007-07-23 17:29 --- Subject: Re: New: [4.3 Regression] "make info" fails in libiberty I've checked in a fix for this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32859
[Bug preprocessor/32868] New: Don't warn about redefinitions of __STDC_FORMAT_MACROS
Compiling this C or C++ file:
#define __STDC_FORMAT_MACROS 1
#define __STDC_FORMAT_MACROS 1
produces these warnings:
foo.c:2:1: warning: "__STDC_FORMAT_MACROS" redefined
foo.c:1:1: warning: this is the location of the previous definition
This is because of these lines in libcpp/macro.c:
if (! ustrncmp (NODE_NAME (node), DSC ("__STDC_")))
node->flags |= NODE_WARN;
The idea behind these lines is sound: the compiler defines macros whose name
begins with "__STDC_". The user should not redefine them.
However, __STDC_FORMAT_MACROS is an exception here. This macro is not defined
by the compiler. It is intended to be defined by the user when compiling a C++
file to direct the header file to define macros PRId32 and friends.
See footnote 182 in section 7.8.1 in C99.
If the user defines the macro in a .h file, as is permitted, then including
that some .h file twice, if it does not have an include guard, will give an
inappropriate warning. In particular this can happen with an autoconf-style
config.h file, as autoconf does not generate include guards for such files.
I expect that the right fix is to specifically exclude __STDC_FORMAT_MACROS
from this warning. Or perhaps another approach would be to specially mark the
macros defined in cpp_init_builtins.
--
Summary: Don't warn about redefinitions of __STDC_FORMAT_MACROS
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ian at airs dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32868
[Bug libgcj/32807] make fails, Java CLASSPATH
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-07-23 17:24 --- Normal issue of not following directions (Solaris's /bin/sh is not a POSIX shell). -- 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=32807
[Bug tree-optimization/32865] [4.3 Regression] glibc ICE's gcc-4.3.0 SSA corruption
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-07-23 17:22 --- Stop changing the CC for this bug, the issue is a generic issue and most likely unrelated to any of the CC you added. This is more likely to be a PRE issue than anything else. When I get into work, I will look into it further to double check. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC|dje at watson dot ibm dot | |com, amacleod at redhat dot | |com, drepper at redhat dot | |com | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32865
[Bug other/32859] [4.3 Regression] "make info" fails in libiberty
--- Comment #2 from tkoenig at gcc dot gnu dot org 2007-07-23 17:17 --- I currently cannot check the documentation changes requried in the review for PR 30814. The condition of a Blocker, "Blocks development and/or testing work" is fulfilled, IMHO. Andrew, you marked this as a non-blocker. How else can I check documentatin patches? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32859
[Bug libgcj/32807] make fails, Java CLASSPATH
--- Comment #4 from pieter dot donche at ua dot ac dot be 2007-07-23 16:43 --- Subject: Re: make fails, Java CLASSPATH Hi, Thanks. It did compile now.. (from midnight to 10:30 in the morning ...) P. \___ / Pieter Donche \ | ITC Manager e-mail [EMAIL PROTECTED] \ | Dept. Mathem. & Computer Science, University of Antwerp| | (UA) Middelheimlaan 1, B 2020 Antwerpen, BELGIUM (EU) | | room G1.16, tel +32 03.265.3870, fax +32 03.265.3777 | || On Sat, 21 Jul 2007, pinskia at gcc dot gnu dot org wrote: > > > --- Comment #3 from pinskia at gcc dot gnu dot org 2007-07-21 19:11 > --- > Please read: http://gcc.gnu.org/install/specific.html#x-x-solaris2 > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32807 > > --- You are receiving this mail because: --- > You reported the bug, or are watching the reporter. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32807
[Bug fortran/32867] [4.3 Regression] 459.GemsFDTD in SPEC CPU 2006 fails to compile
--- Comment #6 from dfranke at gcc dot gnu dot org 2007-07-23 16:36 --- Confirmed. Will look into it. As it works with scalars, I think I forgot to take arrays into account ... -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC|franke dot daniel at gmail | |dot com | AssignedTo|unassigned at gcc dot gnu |dfranke at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-23 16:36:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32867
[Bug fortran/32867] [4.3 Regression] 459.GemsFDTD in SPEC CPU 2006 fails to compile
--- Comment #5 from hjl at lucon dot org 2007-07-23 16:31 --- A smaller testcase: [EMAIL PROTECTED] 459.GemsFDTD]$ cat foo.f90 SUBROUTINE Parser(nx, ny, keyword) character(80), PARAMETER, dimension(1:2) :: keywords = & (/'PROBLEMSIZE', & 'NFTRANS_TD'/) integer, intent(inout) :: nx, ny character(80), intent(inout) :: keyword select case (keyword) case (trim(keywords(1))) ! PROBLEMSIZE nx = 1 case (trim(keywords(2))) !'NFTRANS_TD' ny = 1 end select END SUBROUTINE Parser [EMAIL PROTECTED] 459.GemsFDTD]$ ../126826/usr/bin/gfortran -O2 -ffast-math -DSPEC_CPU_LP64 -S foo.f90 foo.f90:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. [EMAIL PROTECTED] 459.GemsFDTD]$ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32867
[Bug fortran/32867] [4.3 Regression] 459.GemsFDTD in SPEC CPU 2006 fails to compile
--- Comment #4 from hjl at lucon dot org 2007-07-23 16:23 --- Here is a small testcase: [EMAIL PROTECTED] 459.GemsFDTD]$ cat foo.f90 MODULE Readdata_mod IMPLICIT NONE Private Public Parser integer, parameter:: nkeywords = 2 character(80), PARAMETER, dimension(1:nkeywords) :: keywords = & (/'PROBLEMSIZE ',& 'NFTRANS_TD '/) CONTAINS SUBROUTINE Parser(nx, ny, keyword) integer, intent(inout) :: nx, ny character(80), intent(inout) :: keyword select case (keyword) case (trim(keywords(1))) ! PROBLEMSIZE nx = 1 case (trim(keywords(2))) !'NFTRANS_TD' ny = 1 end select END SUBROUTINE Parser END MODULE Readdata_mod [EMAIL PROTECTED] 459.GemsFDTD]$ ../126826/usr/bin/gfortran -O2 -ffast-math -DSPEC_CPU_LP64 -S foo.f90 foo.f90:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. [EMAIL PROTECTED] 459.GemsFDTD]$ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32867
[Bug java/32862] bug in EnumMap implementation
--- Comment #1 from tromey at gcc dot gnu dot org 2007-07-23 16:11 --- I have a fix I'm testing. -- tromey at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-23 16:11:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32862
[Bug fortran/32867] [4.3 Regression] 459.GemsFDTD in SPEC CPU 2006 fails to compile
--- Comment #3 from hjl at lucon dot org 2007-07-23 16:09 --- (In reply to comment #2) > Not yet. > > http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01652.html > > is an update for the quoted patch, it might help to the extend that you get an > error, not an ice. It makes no difference. > > What does the corresponding Fortran code look like? I am working on a small testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32867
[Bug fortran/32867] [4.3 Regression] 459.GemsFDTD in SPEC CPU 2006 fails to compile
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-07-23 15:08 --- Not yet. http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01652.html is an update for the quoted patch, it might help to the extend that you get an error, not an ice. What does the corresponding Fortran code look like? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32867
[Bug testsuite/32841] FAIL: gfortran.dg/edit_real_1.f90 on Darwin8
--- Comment #10 from dominiq at lps dot ens dot fr 2007-07-23 15:03 --- This a regression from 4.2. The following code real(8) x, y real(8) down, up x = huge(x) y = down(x) print *, y, up(y)-x, up(up(y))-x, up(up(x))-x y = up(y) print *, x, y end real(8) function up(x) real(8) x up = nearest(x, 1.0d0) end real(8) function down(x) real(8) x down = nearest(x, -1.0d0) end gives with GNU F95 version 4.2.0 (powerpc-apple-darwin8): 1.797693134862316E+308 0.00+Infinity +Infinity 1.797693134862316E+308 1.797693134862316E+308 and with GNU F95 version 4.3.0 20070713 (experimental) (powerpc-apple-darwin8) 1.797693134862316E+308 0.00+Infinity +Infinity +Infinity +Infinity So the problem seems related to the output and not to a constant folding. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32841
[Bug fortran/32867] [4.3 Regression] 459.GemsFDTD in SPEC CPU 2006 fails to compile
--- Comment #1 from hjl at lucon dot org 2007-07-23 15:02 ---
(gdb) p b->value.character
$10 = {length = 15180528, string = 0xe660fd "__trim_1"}
(gdb) p a->value.character
$11 = {length = 15170912, string = 0xe660fd "__trim_1"}
The length field doesn't look right.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32867
[Bug fortran/32867] New: [4.3 Regression] 459.GemsFDTD in SPEC CPU 2006 fails to compile
This patch
http://gcc.gnu.org/ml/gcc-cvs/2007-07/msg00685.html
causes
(gdb) r readdata.f90 -quiet -dumpbase readdata.f90 -mtune=generic -auxbase
readdata -O2 -version -ffast-math -o readdata.s -fintrinsic-modules-path
/export/gnu/import/rrs/126826/usr/lib/gcc/x86_64-unknown-linux-gnu/4.3.0/finclude
Starting program:
/export/gnu/import/rrs/126826/usr/libexec/gcc/x86_64-unknown-linux-gnu/4.3.0/f951
readdata.f90 -quiet -dumpbase readdata.f90 -mtune=generic -auxbase readdata -O2
-version -ffast-math -o readdata.s -fintrinsic-modules-path
/export/gnu/import/rrs/126826/usr/lib/gcc/x86_64-unknown-linux-gnu/4.3.0/finclude
GNU F95 version 4.3.0 20070722 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 3.4.6 20060404 (Red Hat 3.4.6-8), GMP version
4.2.1, MPFR version 2.2.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Program received signal SIGSEGV, Segmentation fault.
0x004072b5 in gfc_compare_string (a=0xe78f90, b=0xe79710)
at ../../src/gcc/fortran/arith.c:1171
1171 ac = (unsigned char) ((i < alen) ? a->value.character.string[i] :
' ');
(gdb) p a->value
$1 = {logical = 15170912, integer = {{_mp_alloc = 15170912, _mp_size = 0,
_mp_d = 0xe660fd}}, real = {{_mpfr_prec = 15170912,
_mpfr_sign = 15098109, _mpfr_exp = 14833104, _mpfr_d = 0x0}}, complex = {
r = {{_mpfr_prec = 15170912, _mpfr_sign = 15098109, _mpfr_exp = 14833104,
_mpfr_d = 0x0}}, i = {{_mpfr_prec = 0, _mpfr_sign = 0, _mpfr_exp = 0,
_mpfr_d = 0x0}}}, op = {operator = 15170912, uop = 0xe660fd,
op1 = 0xe255d0, op2 = 0x0}, function = {actual = 0xe77d60,
name = 0xe660fd "__trim_1", isym = 0xe255d0, esym = 0x0}, character = {
length = 15170912, string = 0xe660fd "__trim_1"}, constructor = 0xe77d60}
(gdb) p a->value.character
$2 = {length = 15170912, string = 0xe660fd "__trim_1"}
(gdb) list
1166
1167 for (i = 0; i < len; i++)
1168{
1169 /* We cast to unsigned char because default char, if it is
signed,
1170 would lead to ac < 0 for string[i] > 127. */
1171 ac = (unsigned char) ((i < alen) ? a->value.character.string[i] :
' ');
1172 bc = (unsigned char) ((i < blen) ? b->value.character.string[i] :
' ');
1173
1174 if (ac < bc)
1175return -1;
(gdb) p b->value.character.string
$3 = 0xe660fd "__trim_1"
(gdb) p a->value.character.string
$4 = 0xe660fd "__trim_1"
(gdb) p i
$5 = 741123
(gdb) p len
$6 = 15180528
(gdb) bt
#0 0x004072b5 in gfc_compare_string (a=0xe78f90, b=0xe79710)
at ../../src/gcc/fortran/arith.c:1171
#1 0x00407393 in gfc_compare_expr (op1=0xe78f90, op2=0xe79710)
at ../../src/gcc/fortran/arith.c:1126
#2 0x0045567a in resolve_code (code=0xe78b30, ns=0xe6e770)
at ../../src/gcc/fortran/resolve.c:4541
#3 0x004558e4 in gfc_resolve_blocks (b=0xe75530, ns=0xe6e770)
at ../../src/gcc/fortran/resolve.c:5699
#4 0x00454150 in resolve_code (code=0xe71740, ns=0xe6e770)
at ../../src/gcc/fortran/resolve.c:5758
#5 0x0045771b in resolve_codes (ns=0xe6e770)
at ../../src/gcc/fortran/resolve.c:8463
#6 0x004576da in resolve_codes (ns=0xe63e70)
at ../../src/gcc/fortran/resolve.c:8455
#7 0x00457755 in gfc_resolve (ns=0xe63e70)
at ../../src/gcc/fortran/resolve.c:8482
#8 0x0044acac in gfc_parse_file ()
at ../../src/gcc/fortran/parse.c:3270
#9 0x0046d7ce in gfc_be_parse_file (set_yydebug=)
at ../../src/gcc/fortran/f95-lang.c:301
#10 0x005f9f7e in toplev_main (argc=,
argv=) at ../../src/gcc/toplev.c:1044
#11 0x0033b381c3fb in __libc_start_main () from /lib64/tls/libc.so.6
---Type to continue, or q to quit---
#12 0x004053da in _start ()
(gdb)
Daniel, does it ring a bell?
--
Summary: [4.3 Regression] 459.GemsFDTD in SPEC CPU 2006 fails to
compile
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32867
[Bug testsuite/32841] FAIL: gfortran.dg/edit_real_1.f90 on Darwin8
--- Comment #9 from dominiq at lps dot ens dot fr 2007-07-23 14:53 --- Created an attachment (id=13954) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13954&action=view) darwin_objdir/powerpc-apple-darwin8/libgfortran/config.h > Can you post the config.h file from your build directory? I attached the file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32841
[Bug tree-optimization/32865] [4.3 Regression] glibc ICE's gcc-4.3.0 SSA corruption
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Summary|glibc ICE's gcc-4.3.0 SSA |[4.3 Regression] glibc ICE's |corruption [4.3 Regression] |gcc-4.3.0 SSA corruption Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32865
[Bug c/32866] New: gcc-4.2.1 ICE in stage2 during make bootstrap
/vol/gnu/src/gcc-4.2.1/./gcc/xgcc -v -B/vol/gnu/src/gcc-4.2.1/./gcc/ -B/vol/gnu/alphaev6-dec-osf4.0f/bin/ -B/vol/gnu/alphaev6-dec-osf4.0f/lib/ -isystem /vol/gnu/alphaev6-dec-osf4.0f/include -isystem /vol/gnu/alphaev6-dec-osf4.0f/sys-include -O0 -I/vol/gnu/include -mieee -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -pthread -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -frandom-seed=gcc-crtfastmath -E -o crtfastmath.o ../../../share/src/gcc-4.2.1/gcc/config/alpha/crtfastmath.c produces the following output: Reading specs from /vol/gnu/src/gcc-4.2.1/./gcc/specs Target: alphaev6-dec-osf4.0f Configured with: ../../share/src/gcc-4.2.1/configure -v --prefix=/vol/gnu --with-system-zlib --with-libiconv-prefix=/vol/gnu --srcdir=../../share/src/gcc-4.2.1 Thread model: posix gcc version /vol/gnu/src/gcc-4.2.1/./gcc/cc1 -E -quiet -v -I/vol/gnu/include -iprefix /vol/gnu/src/gcc-4.2.1/gcc/../lib/gcc/alphaev6-dec-osf4.0f/4.2.1/ -isystem /vol/gnu/src/gcc-4.2.1/./gcc/include -D_REENTRANT -DIN_GCC -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -isystem /vol/gnu/alphaev6-dec-osf4.0f/include -isystem /vol/gnu/alphaev6-dec-osf4.0f/sys-include -isystem ./include ../../../share/src/gcc-4.2.1/gcc/config/alpha/crtfastmath.c -o crtfastmath.o -mieee -mcpu=ev6 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -frandom-seed=gcc-crtfastmath -fworking-directory -O0 ignoring nonexistent directory "/vol/gnu/alphaev6-dec-osf4.0f/sys-include" ignoring duplicate directory "./include" ignoring nonexistent directory "/vol/gnu/src/gcc-4.2.1/gcc/../lib/gcc/alphaev6-dec-osf4.0f/4.2.1/include" ignoring nonexistent directory "/vol/gnu/src/gcc-4.2.1/gcc/../lib/gcc/alphaev6-dec-osf4.0f/4.2.1/../../../../alphaev6-dec-osf4.0f/include" ignoring nonexistent directory "/vol/gnu/lib/gcc/alphaev6-dec-osf4.0f/4.2.1/include" ignoring duplicate directory "/vol/gnu/lib/gcc/alphaev6-dec-osf4.0f/../../../alphaev6-dec-osf4.0f/include" ignoring duplicate directory "/vol/gnu/include" as it is a non-system directory that duplicates a system directory #include "..." search starts here: #include <...> search starts here: /vol/gnu/src/gcc-4.2.1/./gcc/include /vol/gnu/alphaev6-dec-osf4.0f/include /usr/local/include /vol/gnu/include /usr/include End of search list. :0: internal compiler error: in define__GNUC__, at c-cppbuiltin.c:344 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. Of course the xgcc in make bootstrap runs without "-v" and with "-c" instead of "-E". These options are inserted just for demonstration purposes. After this error make bootstrap terminates with make[3]: *** [crtfastmath.o] Error 1 make[3]: Leaving directory `/vol/gnu/src/gcc-4.2.1/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/vol/gnu/src/gcc-4.2.1' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/vol/gnu/src/gcc-4.2.1' make: *** [bootstrap] Error 2 -- Summary: gcc-4.2.1 ICE in stage2 during make bootstrap Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Georg dot Wittig at ZV dot Fraunhofer dot de GCC build triplet: alphaev6-dec-osf4.0f GCC host triplet: alphaev6-dec-osf4.0f GCC target triplet: alphaev6-dec-osf4.0f http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32866
[Bug middle-end/32856] Invalid optimization in the face of aliasing
--- Comment #7 from falk at debian dot org 2007-07-23 14:17 --- (In reply to comment #6) > This program demonstrates the problem, it creates different output depending > on > if compiled with or without optimisation. This does not demonstrate the problem, since your code has undefined behavior (already c = ... is undefined). You really need something like the union mentioned earlier. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32856
[Bug c/32865] glibc ICE's gcc-4.3.0 SSA corruption [4.3 Regression]
--- Comment #2 from michelin60 at gmail dot com 2007-07-23 13:51 --- Created an attachment (id=13953) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13953&action=view) Partial *.s output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32865
[Bug c/32865] glibc ICE's gcc-4.3.0 SSA corruption [4.3 Regression]
--- Comment #1 from michelin60 at gmail dot com 2007-07-23 13:48 --- Created an attachment (id=13952) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13952&action=view) preprocessed vprintf.c from glibc-2.6 vprintf.c from glibc-2.6, glibc2.6.90, and glibc-2.5 differ in minor ways but cause the same SSA-Corruption -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32865
[Bug c/32865] New: glibc ICE's gcc-4.3.0 SSA corruption [4.3 Regression]
First noticed July 16, 2007 The skinny Using built-in specs. Target: powerpc-unknown-linux-gnu Configured with: ../gcc-4.3.0/configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --host=powerpc-unknown-linux-gnu --build=powerpc-unknown-linux-gnu --enable-__cxa_atexit --enable-threads=posix --enable-shared --enable-clocale=gnu --enable-bootstrap --enable-languages=c,c++,fortran --enable-altivec --disable-checking --disable-nls --disable-werror --disable-multilib --with-ibmlongdouble --with-cpu=G4 --enable-clocale=gnu --with-system-zlib Thread model: posix gcc version 4.3.0 20070723 (experimental) /usr/libexec/gcc/powerpc-unknown-linux-gnu/4.3.0/cc1 -fpreprocessed vfprintf.i -quiet -dumpbase vfprintf.i -mcpu=G4 -auxbase vfprintf -O2 -version -o /tmp/cc85HTF5.s GNU C version 4.3.0 20070723 (experimental) (powerpc-unknown-linux-gnu) compiled by GNU C version 4.3.0 20070723 (experimental), GMP version 4.2.1, MPFR version 2.2.1-p5. GGC heuristics: --param ggc-min-expand=81 --param ggc-min-heapsize=96556 Compiler executable checksum: 5d5139bad2f5d41bdb4959a445c33bb0 Unable to coalesce ssa_names 1221 and 144 which are marked as MUST COALESCE. is_long_double_1221(ab) and is_long_double_144(ab) vfprintf.c: In function '_IO_vfprintf_internal': vfprintf.c:184: internal compiler error: SSA corruption Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. The extended: powerpc-unknown-linux-gnu-gcc: warning: -pipe ignored because -save-temps specified Using built-in specs. Target: powerpc-unknown-linux-gnu Configured with: ../gcc-4.3.0/configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --host=powerpc-unknown-linux-gnu --build=powerpc-unknown-linux-gnu --enable-__cxa_atexit --enable-threads=posix --enable-shared --enable-clocale=gnu --enable-bootstrap --enable-languages=c,c++,fortran --enable-altivec --disable-checking --disable-nls --disable-werror --disable-multilib --with-ibmlongdouble --with-cpu=G4 --enable-clocale=gnu --with-system-zlib Thread model: posix gcc version 4.3.0 20070723 (experimental) /usr/libexec/gcc/powerpc-unknown-linux-gnu/4.3.0/cc1 -E -quiet -nostdinc -v -I../include -I/var/tmp/portage/sys-libs/glibc-2.6/work/build-default-powerpc-unknown-linux-gnu-nptl/stdio-common -I/var/tmp/portage/sys-libs/glibc-2.6/work/build-default-powerpc-unknown-linux-gnu-nptl -I../sysdeps/powerpc/powerpc32/elf -I../sysdeps/powerpc/elf -I../sysdeps/unix/sysv/linux/powerpc/powerpc32/fpu -I../sysdeps/powerpc/powerpc32/fpu -I../nptl/sysdeps/unix/sysv/linux/powerpc/powerpc32 -I../ports/sysdeps/unix/sysv/linux/powerpc/powerpc32 -I../sysdeps/unix/sysv/linux/powerpc/powerpc32 -I../nptl/sysdeps/unix/sysv/linux/powerpc -I../ports/sysdeps/unix/sysv/linux/powerpc -I../sysdeps/unix/sysv/linux/powerpc -I../sysdeps/ieee754/ldbl-128ibm -I../sysdeps/ieee754/ldbl-opt -I../nptl/sysdeps/unix/sysv/linux -I../nptl/sysdeps/pthread -I../sysdeps/pthread -I../ports/sysdeps/unix/sysv/linux -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../nptl/sysdeps/unix/sysv -I../ports/sysdeps/unix/sysv -I../sysdeps/unix/sysv -I../sysdeps/unix/powerpc -I../nptl/sysdeps/unix -I../ports/sysdeps/unix -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/powerpc/powerpc32 -I../sysdeps/wordsize-32 -I../sysdeps/powerpc/fpu -I../nptl/sysdeps/powerpc -I../ports/sysdeps/powerpc -I../sysdeps/powerpc -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -I../nptl -I../ports -I.. -I../libio -I. -MD /var/tmp/portage/sys-libs/glibc-2.6/work/build-default-powerpc-unknown-linux-gnu-nptl/stdio-common/vfprintf.d -MF /var/tmp/portage/sys-libs/glibc-2.6/work/build-default-powerpc-unknown-linux-gnu-nptl/stdio-common/vfprintf.o.dt -MP -MT /var/tmp/portage/sys-libs/glibc-2.6/work/build-default-powerpc-unknown-linux-gnu-nptl/stdio-common/vfprintf.o -D__unix__ -D__gnu_linux__ -D__linux__ -Dunix -D__unix -Dlinux -D__linux -Asystem=linux -Asystem=unix -Asystem=posix -D_LIBC_REENTRANT -D_IO_MTSAFE_IO -isystem include -isystem /usr/include -include ../include/libc-symbols.h vfprintf.c -mcpu=G4 -mnew-mnemonics -mlong-double-128 -std=gnu99 -Wall -Winline -Wwrite-strings -Wstrict-prototypes -Wno-uninitialized -fgnu89-inline -fmerge-all-constants -fno-strict-aliasing -freorder-blocks -O2 -fpch-preprocess -o vfprintf.i ignoring nonexistent directory "include" #include "..." search starts here: #include <...> search starts here: ../include /var/tmp/build-default-powerpc-unknown-linux-gnu-nptl/stdio-common /var/tmp/build-default-powerpc-unknown-linux-gnu-nptl ../sysdeps/powerpc/powerpc32/elf ../sysdeps/powerpc/elf ../sysdeps/unix/sysv/linux/powerpc/powerpc32/fpu ../sysdeps/powerpc/powerpc32/fpu ../nptl/sysdeps/unix/sysv/linux/powerpc/powerpc32 ../ports/sysdeps/unix/sysv/linux/powerp
[Bug middle-end/32856] Invalid optimization in the face of aliasing
--- Comment #6 from vogel at pi2 dot physik dot uni-erlangen dot de
2007-07-23 10:08 ---
This program demonstrates the problem, it creates different output depending on
if compiled with or without optimisation.
Without optimisation, n->next is not cached:
n->next = 0xbfb01af0
n->next = 0xbfb01af8
With optimisation, n->next is cached, this is wrong:
n->next = 0xbfdb3da0
n->next = 0xbfdb3da0
Note that the pointer c will point exactly one pointer-width above the
structure a, so n->next->next->prev=n -- which corresponds to c->prev=n -- will
overwrite n->next with n.
#include
struct node {
struct node *next, *prev;
};
void foo(struct node* n) {
printf("n->next = %p\n",n->next);
n->next->next->prev=n;
printf("n->next = %p\n",n->next);
};
int main(int argc,char **argv){
struct node a = { },b = { };
struct node *c = NULL;
c = ((void*)&(a.next)) - sizeof(void*);
b.next = c;
a.next = &b;
foo(&a);
}
--
vogel at pi2 dot physik dot uni-erlangen dot de changed:
What|Removed |Added
CC||vogel at pi2 dot physik dot
||uni-erlangen dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32856
[Bug bootstrap/32829] CVS bootstrap failure with as: unrecognised option -Qy
--- Comment #5 from brian dot sidebotham at gmail dot com 2007-07-23 09:39 --- Here is the output of a correctly built and installed toolchain: > arm-elf-as -V arm-elf-as: unrecognized option `-V' > arm-elf-as -Qy arm-elf-as: unrecognized option `-Qy' > arm-elf-as --version GNU assembler 2.17 Copyright 2005 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. This assembler was configured for a target of `arm-elf'. > arm-elf-gcc --version arm-elf-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. I don't think it's a binutils error, because the arm-elf target has never supported -Qy or -V. I thought that gcc made a decision depending on what tools it was making as to whether it would emit those options or not, hence why I posted the problem here. I can only go on what I've read over the internet though, as I don't even know what these options do, they are not documented in the gas documentation as far as I can see. I have seen some comments suggesting this error could be thrown up if there is a $PATH error. I will investigate to make sure the PATH is emitted correctly in my build script too. Or, are you saying that binutils must now support -Qy and -V for the arm-elf target? Thanks for your time. Brian. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32829
[Bug fortran/32797] [ISO C Binding] Internal Error: gfc_basic_typename(): Undefined type
--- Comment #1 from burnus at gcc dot gnu dot org 2007-07-23 09:32 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01543.html Cf. also PR 32800. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32797
[Bug fortran/32800] ISO Bind C: C_F_Pointer argument bogus checking
--- Comment #1 from burnus at gcc dot gnu dot org 2007-07-23 09:32 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01543.html Cf. also PR 32797. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32800
[Bug target/32818] i486 assembler bug (GLIBC 2.6) or feature?
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-07-23 09:24 --- Not a bug GCC can able to fix. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32818
[Bug other/32859] [4.3 Regression] "make info" fails in libiberty
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|blocker |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32859
[Bug target/32830] shared library create by hppa64-hp11.11 can't run.
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32830
[Bug fortran/32732] [Bind C] Character scalars are passed as arrays
--- Comment #3 from burnus at gcc dot gnu dot org 2007-07-23 09:08 --- FIXED. Steve, please check under IA64 HP-UX whether it works now. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32732
[Bug fortran/32842] User operator / allocateable array: Wrong code
--- Comment #2 from pault at gcc dot gnu dot org 2007-07-23 09:06 --- This is indeed fixed by my patch for PR31205. I had the breakthrough in understanding why this broke cp2K at about 3 o'clock this morning *sigh* The fix turned out to be very easy but understanding what was broken was not! I will leave this lot to regtest and hope to submit the composite patch tonight. Cheers Paul PS I am similarly stuck on the character patch that I keep promising; I can make it work but have been unable to remove all the middle-end kludges. -- 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-07-22 19:34:41 |2007-07-23 09:06:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32842
[Bug fortran/32732] [Bind C] Character scalars are passed as arrays
--- Comment #2 from burnus at gcc dot gnu dot org 2007-07-23 09:03 --- Subject: Bug 32732 Author: burnus Date: Mon Jul 23 09:03:30 2007 New Revision: 126836 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126836 Log: 2007-07-23 Christopher D. Rickett <[EMAIL PROTECTED]> PR fortran/32732 * trans-decl.c (generate_local_decl): Convert the TREE_TYPE for by value character dummy args of BIND(C) procedures. * trans-expr.c (gfc_conv_variable): Do not build address expression for BT_CHARACTER dummy args. 2007-07-23 Christopher D. Rickett <[EMAIL PROTECTED]> PR fortran/32732 * gfortran.dg/c_char_tests.f03: New test case. * gfortran.dg/c_char_driver.c: Driver for c_char_tests.f03. * gfortran.dg/c_char_tests_2.f03: New test case. * gfortran.dg/value_6.f03: Ditto. * gfortran.dg/value_7.f03: Ditto. Added: trunk/gcc/testsuite/gfortran.dg/c_char_driver.c trunk/gcc/testsuite/gfortran.dg/c_char_tests.f03 trunk/gcc/testsuite/gfortran.dg/c_char_tests_2.f03 trunk/gcc/testsuite/gfortran.dg/value_6.f03 trunk/gcc/testsuite/gfortran.dg/value_7.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32732
[Bug fortran/32860] Support %ld (for "long") for gfc_warning
-- burnus at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |minor Keywords|diagnostic | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32860
[Bug libfortran/32784] [win32] Using 'con' as assigned file generates Fortran runtime error: File 'con' does not exist
--- Comment #17 from dannysmith at users dot sourceforge dot net 2007-07-23 08:04 --- (In reply to comment #16) Maybe we > should make it match "con" with case ignored. No, please. "con", "nul", "prn" (with or without suffix) are reserved device names on windows. (eg "gcc -v -dM -E nul.c" is equivalent to gcc -v -dM -E -xc /dev/null) CONOUT$ is the win32api name for console output and is used in GUI progs that don't have default console output. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32784
[Bug java/32862] New: bug in EnumMap implementation
[forwarded from http://bugs.debian.org/423160]
seen with trunk 20070720
The gij implementation of EnumMap class contains a flaw: it returns
strange java.lang.Object classes for missing elements. The error can be
demonstrated with this program:
=== Cut ===
import java.util.*;
public class Test {
enum TestEnum {
FIRST, SECOND
}
public static void main(String[] args) {
Map map = new EnumMap(TestEnum.class);
map.put(TestEnum.FIRST, "first");
System.out.println(map);
System.out.println(map.containsKey(TestEnum.SECOND));
System.out.println(map.get(TestEnum.SECOND));
}
}
$ gcj -C Test.java
tmp $ gij Test
{FIRST=first}
false
Exception in thread "main" java.lang.ClassCastException:
java.lang.Object cannot be cast to java.lang.String
at Test.main(Test.java:13)
tmp $ java Test
{FIRST=first}
false
null
=== Cut ===
As you can see, Sun Java (the last call) returns correct null, while
GNU libgcj returns bogus java.lang.Object.
--
Summary: bug in EnumMap implementation
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian-gcc at lists dot debian dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32862
[Bug java/31900] Java line number debug info is bogus
--- Comment #1 from debian-gcc at lists dot debian dot org 2007-07-23 07:37 --- seen on the trunk 20070730 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31900
[Bug target/32830] shared library create by hppa64-hp11.11 can't run.
--- Comment #7 from cnstar9988 at gmail dot com 2007-07-23 07:15 --- I build with -lgcc_stub, So works ok. I think "_Jv_RegisterClasses" for GCJ. "__cxa_finalize" for G++. My Library only use C language, so works ok. :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32830
