[Bug rtl-optimization/38245] [4.4 Regression] apparent improper segfault in compiler output
--- Comment #1 from jakub at gcc dot gnu dot org 2008-11-24 09:01 ---
Smaller testcase:
static inline int
f1 (int si1, int si2)
{
return si2 == 0 ? si1 : si1 / si2;
}
static inline unsigned long long
f2 (unsigned long long ui1, unsigned long long ui2)
{
return ui1 % ui2;
}
unsigned char g;
volatile unsigned int h;
void
f3 (void)
{
if (!((signed char) f1 (0, f2 (g, 2123)) - 1))
h;
}
int
main (void)
{
f3 ();
return 0;
}
The problem seems to be that RTL DCE pass removes umoddi3 call:
(insn 8 6 34 2 u2.c:19 (set (mem:DI (plus:SI (reg/f:SI 7 sp)
(const_int 8 [0x8])) [0 S8 A32])
(const_int 2123 [0x84b])) 88 {*movdi_2} (nil))
(insn 34 8 35 2 u2.c:19 (set (mem:SI (reg/f:SI 7 sp) [0 S4 A32])
(reg:SI 61 [ g ])) 47 {*movsi_1} (expr_list:REG_DEAD (reg:SI 61 [ g ])
(nil)))
(insn 35 34 10 2 u2.c:19 (set (mem:SI (plus:SI (reg/f:SI 7 sp)
(const_int 4 [0x4])) [0 S4 A32])
(const_int 0 [0x0])) 47 {*movsi_1} (nil))
(call_insn/u 10 35 0 2 u2.c:19 (set (reg:DI 0 ax)
(call (mem:QI (symbol_ref:SI (__umoddi3) [flags 0x41]) [0 S1 A8])
(const_int 16 [0x10]))) 902 {*call_value_0} (expr_list:REG_UNUSED
(reg:SI 1 dx)
(expr_list:REG_EH_REGION (const_int -1 [0x])
(nil)))
(expr_list:REG_DEP_TRUE (use (mem:DI (reg/f:SI 7 sp) [0 S8 A8]))
(expr_list:REG_DEP_TRUE (use (mem:DI (plus:SI (reg/f:SI 7 sp)
(const_int 8 [0x8])) [0 S8 A8]))
(nil
but doesn't remove the pushes of its arguments, and then
ix86_compute_frame_layout doesn't allocate space for the outgoing arguments
as the function is leaf.
/* Add outgoing arguments area. Can be skipped if we eliminated
all the function calls as dead code.
Skipping is however impossible when function calls alloca. Alloca
expander assumes that last crtl-outgoing_args_size
of stack frame are unused. */
if (ACCUMULATE_OUTGOING_ARGS
(!current_function_is_leaf || cfun-calls_alloca
|| ix86_current_function_calls_tls_descriptor))
{
offset += crtl-outgoing_args_size;
frame-outgoing_arguments_size = crtl-outgoing_args_size;
}
else
frame-outgoing_arguments_size = 0;
I guess this was caused by the removal of REG_LIBCALL notes.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
CC||steven at gcc dot gnu dot
||org
Component|c |rtl-optimization
Known to fail||4.4.0
Known to work||4.3.2
Summary|apparent improper segfault |[4.4 Regression] apparent
|in compiler output |improper segfault in
||compiler output
Target Milestone|--- |4.4.0
Version|unknown |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38245
[Bug c/38243] Restrict constraint violation not an error with -pedantic-errors
--- Comment #1 from schwab at suse dot de 2008-11-24 09:06 --- *** Bug 38246 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38243
[Bug c/38246] Restrict constraint violation not an error with -pedantic-errors
--- Comment #1 from schwab at suse dot de 2008-11-24 09:06 --- *** This bug has been marked as a duplicate of 38243 *** -- schwab at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38246
[Bug rtl-optimization/38245] [4.4 Regression] apparent improper segfault in compiler output
-- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-24 09:10:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38245
[Bug c++/38242] Overeager ADL searches associated namespaces of base class's template arguments
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-11-24 10:07 --- Y is also not a template-id (?) Confirmed. EDG rejects this. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||accepts-invalid Known to fail||2.95.4 4.4.0 Last reconfirmed|-00-00 00:00:00 |2008-11-24 10:07:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38242
[Bug libstdc++/38244] bitset initialization from 0 rejected.
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-11-24 10:08 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||rejects-valid Last reconfirmed|-00-00 00:00:00 |2008-11-24 10:08:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38244
[Bug target/38054] Assertion failed in change_decl_assembler_name()
--- Comment #7 from hackbunny at reactos dot com 2008-11-24 10:24 --- Created an attachment (id=16756) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16756action=view) Smaller test case gcc -c -v -funit-at-a-time -nostdinc testcase.c Using built-in specs. Target: mingw32 Configured with: ../gcc-4.1.3/configure --prefix=/gcc-4.1.3 --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --build=mingw32 --enable-languages=c,c++ --enable-checking=release --enable-threads=win32 --disable-win32-registry --disable-nls --disable-shared Thread model: win32 gcc version 4.1.3 20071015 (prerelease) c:/users/hyperion/rosbe/4.1.3/bin/../libexec/gcc/mingw32/4.1.3/cc1.exe -quiet -nostdinc -v -iprefix c:\users\hyperion\rosbe\4.1.3\bin\../lib/gcc/mingw32/4.1.3/ testcase.c -quiet -dumpbase testcase.c -auxbase testcase -version -funit-at-a-time -o C:\Users\Hyperion\AppData\Local\Temp/cczKM08O.s #include ... search starts here: #include ... search starts here: C:/Users/Hyperion/RosBE/4.1.3/include C:/Users/Hyperion/RosBE/4.1.3/lib/gcc/mingw32/4.1.3/include End of search list. GNU C version 4.1.3 20071015 (prerelease) (mingw32) compiled by GNU C version 4.1.3 20071015 (prerelease). GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 3f527ff7c87fdc28aecf612037bc62b2 testcase.c: In function 'y': testcase.c:10: warning: y renamed after being referenced in assembly c:/users/hyperion/rosbe/4.1.3/bin/../lib/gcc/mingw32/4.1.3/../../../../mingw32/bin/as.exe -o testcase.o C:\Users\Hyperion\AppData\Local\Temp/cczKM08O.s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38054
[Bug libstdc++/38244] bitset initialization from 0 rejected.
--- Comment #3 from paolo dot carlini at oracle dot com 2008-11-24 10:21 --- This is essentially a defect in DR 778: http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#778 I'll see what we can do for now. -- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38244
[Bug target/38054] Assertion failed in change_decl_assembler_name()
--- Comment #8 from hackbunny at reactos dot com 2008-11-24 10:29 --- I have added a test case that shows a closely related issue with nested functions, -funit-at-a-time and unreferenced file-scope externs (yes, if you remove int x = 0; the warning goes away) The %D renamed after being referenced in assembly warning cannot be disabled, either, so this is a bit problematic for sources compiled with -Werror -- hackbunny at reactos dot com changed: What|Removed |Added CC||hackbunny at reactos dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38054
[Bug libstdc++/38244] [4.4 Regression] bitset initialization from 0 rejected.
-- paolo dot carlini at oracle dot com changed: What|Removed |Added Summary|bitset initialization from 0|[4.4 Regression] bitset |rejected. |initialization from 0 ||rejected. Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38244
[Bug libstdc++/38233] [4.4 Regression] 'map' value type + new uninitted const member warnings causes error
--- Comment #3 from paolo dot carlini at oracle dot com 2008-11-24 11:10 --- The default constructor of pair just implements DR 265, this is *very* old: http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#265 This is possibly a C++ front-end issue, because lately nothing changed in the library in this area. I'll CC Jason. -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||jason at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38233
[Bug libstdc++/38244] [4.4 Regression] bitset initialization from 0 rejected.
--- Comment #4 from paolo at gcc dot gnu dot org 2008-11-24 11:14 --- Subject: Bug 38244 Author: paolo Date: Mon Nov 24 11:13:44 2008 New Revision: 142152 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142152 Log: 2008-11-24 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/38244 * include/std/bitset (bitset::bitset(const char*, char, char)): Remove, do not implement DR 778. * doc/xml/manual/intro.xml: Remove entry for DR 778. * testsuite/23_containers/bitset/cons/2.cc: Remove. * testsuite/23_containers/bitset/cons/dr396.cc: Tweak. * testsuite/23_containers/bitset/cons/38244.cc: Add. Added: trunk/libstdc++-v3/testsuite/23_containers/bitset/cons/38244.cc Removed: trunk/libstdc++-v3/testsuite/23_containers/bitset/cons/2.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/doc/xml/manual/intro.xml trunk/libstdc++-v3/include/std/bitset trunk/libstdc++-v3/testsuite/23_containers/bitset/cons/dr396.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38244
[Bug libstdc++/38244] [4.4 Regression] bitset initialization from 0 rejected.
--- Comment #5 from paolo dot carlini at oracle dot com 2008-11-24 11:15 --- Fixed. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38244
[Bug libstdc++/38244] [4.4 Regression] bitset initialization from 0 rejected.
--- Comment #6 from paolo at gcc dot gnu dot org 2008-11-24 11:21 --- Subject: Bug 38244 Author: paolo Date: Mon Nov 24 11:19:39 2008 New Revision: 142153 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142153 Log: 2008-11-24 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/38244 (cont, debug bits) * include/debug/bitset (bitset::bitset(const char*, char, char)): Remove, do not implement DR 778. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/debug/bitset -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38244
[Bug fortran/35681] wrong result for vector subscripted array expression in MVBITS
--- Comment #21 from mikael at gcc dot gnu dot org 2008-11-24 12:15 --- Subject: Bug 35681 Author: mikael Date: Mon Nov 24 12:13:59 2008 New Revision: 142154 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142154 Log: 2008-11-24 Mikael Morin [EMAIL PROTECTED] PR fortran/35681 * dependency.c (gfc_check_argument_var_dependency): Add elemental check flag. Issue a warning if we find a dependency but don't generate a temporary. Add the case of an elemental function call as actual argument to an elemental procedure. Add the case of an operator expression as actual argument to an elemental procedure. (gfc_check_argument_dependency): Add elemental check flag. Update calls to gfc_check_argument_var_dependency. (gfc_check_fncall_dependency): Add elemental check flag. Update call to gfc_check_argument_dependency. * trans-stmt.c (gfc_trans_call): Make call to gfc_conv_elemental_dependency unconditional, but with a flag whether we should check dependencies between variables. (gfc_conv_elemental_dependency): Add elemental check flag. Update call to gfc_check_fncall_dependency. * trans-expr.c (gfc_trans_arrayfunc_assign): Update call to gfc_check_fncall_dependency. * resolve.c (find_noncopying_intrinsics): Update call to gfc_check_fncall_dependency. * dependency.h (enum gfc_dep_check): New enum. (gfc_check_fncall_dependency): Update prototype. 2008-11-24 Mikael Morin [EMAIL PROTECTED] PR fortran/35681 * gfortran.dg/elemental_dependency_1.f90: New test. Modified: branches/gcc-4_3-branch/gcc/fortran/ChangeLog branches/gcc-4_3-branch/gcc/fortran/dependency.c branches/gcc-4_3-branch/gcc/fortran/dependency.h branches/gcc-4_3-branch/gcc/fortran/resolve.c branches/gcc-4_3-branch/gcc/fortran/trans-expr.c branches/gcc-4_3-branch/gcc/fortran/trans-stmt.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35681
[Bug fortran/35681] wrong result for vector subscripted array expression in MVBITS
--- Comment #22 from mikael at gcc dot gnu dot org 2008-11-24 12:25 --- Argh!! elemental_dependency_1.f90 was not committed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35681
[Bug fortran/35681] wrong result for vector subscripted array expression in MVBITS
--- Comment #23 from mikael at gcc dot gnu dot org 2008-11-24 12:38 --- Subject: Bug 35681 Author: mikael Date: Mon Nov 24 12:37:25 2008 New Revision: 142155 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142155 Log: 2008-11-24 Mikael Morin [EMAIL PROTECTED] PR fortran/35681 * gfortran.dg/elemental_dependency_1.f90: Really commit it. Added: trunk/gcc/testsuite/gfortran.dg/elemental_dependency_1.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35681
[Bug fortran/35681] wrong result for vector subscripted array expression in MVBITS
--- Comment #24 from mikael at gcc dot gnu dot org 2008-11-24 12:48 --- Subject: Bug 35681 Author: mikael Date: Mon Nov 24 12:46:57 2008 New Revision: 142156 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142156 Log: 2008-11-24 Mikael Morin [EMAIL PROTECTED] PR fortran/35681 * gfortran.dg/elemental_dependency_1.f90: Really commit it. Added: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/elemental_dependency_1.f90 Modified: branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35681
[Bug middle-end/37135] [4.3/4.4 Regression] code size increase for bit-fields assignment
--- Comment #10 from jakub at gcc dot gnu dot org 2008-11-24 12:59 --- Subject: Bug 37135 Author: jakub Date: Mon Nov 24 12:57:37 2008 New Revision: 142157 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142157 Log: PR middle-end/37135 * dse.c (find_shift_sequence): Optimize extraction from a constant. Modified: trunk/gcc/ChangeLog trunk/gcc/dse.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37135
[Bug fortran/35681] wrong result for vector subscripted array expression in MVBITS
--- Comment #25 from mikael at gcc dot gnu dot org 2008-11-24 13:10 --- (In reply to comment #22) Argh!! elemental_dependency_1.f90 was not committed. Fixed now, sorry for the noise. (In reply to comment #20) Mikael, Daniel: Have I missed something or is everything in this PR fixed in 4.4 (trunk) and only some 4.3 back porting is needed? Sorry for forgetting about it. Yes, I think it is fixed, and I've just back-ported. closing now. -- mikael at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35681
[Bug fortran/37779] Missing RECURSIVE not detected
--- Comment #4 from domob at gcc dot gnu dot org 2008-11-24 13:12 --- Subject: Bug 37779 Author: domob Date: Mon Nov 24 13:10:37 2008 New Revision: 142158 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142158 Log: 2008-11-24 Daniel Kraft [EMAIL PROTECTED] PR fortran/37779 * resolve.c (resolve_procedure_expression): New method. (resolve_variable): Call it. (resolve_actual_arglist): Call gfc_resolve_expr for procedure arguments. 2008-11-24 Daniel Kraft [EMAIL PROTECTED] PR fortran/37779 * gfortran.dg/c_funloc_tests.f03: Added missing `RECURSIVE'. * gfortran.dg/c_funloc_tests_2.f03: Ditto. * gfortran.dg/recursive_check_4.f03: New test. * gfortran.dg/recursive_check_5.f03: New test. Added: trunk/gcc/testsuite/gfortran.dg/recursive_check_4.f03 trunk/gcc/testsuite/gfortran.dg/recursive_check_5.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/c_funloc_tests.f03 trunk/gcc/testsuite/gfortran.dg/c_funloc_tests_2.f03 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37779
[Bug fortran/38247] New: problem with contained subprocedure.
I am using the following gfortran compiler, installed on a 32-bit computer running Open SUSE 10.0: [EMAIL PROTECTED]:~/design/linux/gfortran/bug32_1/test gfortran --version GNU Fortran (GCC) 4.4.0 20081021 (experimental) [trunk revision 141258] Copyright (C) 2008 Free Software Foundation, Inc. After submitting this initial report I will upload an archive, bug32_1.tgz. Unpack it and invoke the the shell script contained in file bug32_1.sh. This will reproduce a problem with the compiler. After the script completes you will be able to see the problem by looking at cmndtype.xyz. I see the following: [EMAIL PROTECTED]:~/design/linux/gfortran/bug32_1/test more cmndtype.xyz cmndtypeM.f90:697.29: CALL PutALine (user_line) 1 Error: There is no specific subroutine for the generic 'putaline' at (1) cmndtypeM.f90:702.20: CALL PutALine () 1 Error: There is no specific subroutine for the generic 'putaline' at (1) cmndtypeM.f90:705.20: CALL PutALine () 1 Error: There is no specific subroutine for the generic 'putaline' at (1) cmndtypeM.f90:707.29: call PutALine (user_line) 1 Error: There is no specific subroutine for the generic 'putaline' at (1) If I remember correctly, I already submitted this problem with the AMD 64-bit version of the compiler, and you fixed it. Version 4.4 on my 64-bit AMD computer will compile this code. Thanks, as always, for your attention. Norm Clerman -- Summary: problem with contained subprocedure. Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: clerman at fuse dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38247
[Bug fortran/38247] problem with contained subprocedure.
--- Comment #1 from clerman at fuse dot net 2008-11-24 14:37 --- Created an attachment (id=16757) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16757action=view) archive described in the initial bug report Pleas see initial bug report. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38247
[Bug libstdc++/35569] [c++0x] std::bind result functor doesn't accept rvalues
--- Comment #1 from paolo dot carlini at oracle dot com 2008-11-24 14:55 --- *** Bug 38238 has been marked as a duplicate of this bug. *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||fuscated at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35569
[Bug libstdc++/38238] std::tr1::bind fails to compile with pointer to member function
--- Comment #1 from paolo dot carlini at oracle dot com 2008-11-24 14:55 --- The problem is the rvalue (2) *** This bug has been marked as a duplicate of 35569 *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38238
[Bug target/38177] Internal compiler error during gcc build with -march=amdfam10
--- Comment #4 from ubizjak at gmail dot com 2008-11-24 15:05 --- The sbitmap.i works for me with ~/gcc-build-43/gcc/cc1 -O2 -march=amdfam10 -mcx16 -msahf -fprofile-generate --param l1-cache-size=64 --param l1-cache-line-size=64 where GNU C (GCC) version 4.3.3 20081110 (prerelease) [gcc-4_3-branch revision 141732] (i686-pc-linux-gnu) and GNU C (GCC) version 4.4.0 20081121 (prerelease) [trunk revision 142081] (i686-pc-linux-gnu) Can you try latest 4.3 branch? -- ubizjak at gmail dot com changed: What|Removed |Added Known to work||4.3.3 4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38177
[Bug fortran/38248] New: Fatal Error: Reading module mmm: Expected left parenthesis
Minimal testcase to `use' some module cannot be compiled. Compilation works fine on Fedora gcc-gfortran-4.3.2-7.x86_64. GNU Fortran (GCC) version 4.4.0 20081124 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.4.0 20081124 (experimental), GMP version 4.2.2, MPFR version 2.3.2. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 $ gcc-build/gcc/f951 -o gccmod.s gccmod.f90 -Wall -ggdb2 initFatal Error: Reading module mmm at line 16 column 65: Expected left parenthesis $ cat gccmod.f90 module mmm contains subroutine init end subroutine init end module mmm program main use mmm end program main $ _ (In fact no `module mmm' part needs to be present there.) -- Summary: Fatal Error: Reading module mmm: Expected left parenthesis Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jan dot kratochvil at redhat dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38248
[Bug fortran/38247] problem with contained subprocedure.
--- Comment #2 from kargl at gcc dot gnu dot org 2008-11-24 15:19 --- Your shell script contains items of the form /home/norm/design/numrec/nrTypeM.f90 which of course doesn't exist so the shell script aborts when executed. BTW, if it is fixed on amd64, then it is mostlikely fixed on all target. This is probably too old: GNU Fortran (GCC) 4.4.0 20081021 (experimental) [trunk revision 141258] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38247
[Bug target/38177] Internal compiler error during gcc build with -march=amdfam10
--- Comment #5 from ubizjak at gmail dot com 2008-11-24 15:29 --- BTW: You should report this bug to: with-bugurl=http://bugs.gentoo.org/ -- ubizjak at gmail dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38177
[Bug fortran/38247] problem with contained subprocedure.
--- Comment #3 from mikael at gcc dot gnu dot org 2008-11-24 15:29 --- (In reply to comment #2) This is probably too old: GNU Fortran (GCC) 4.4.0 20081021 (experimental) [trunk revision 141258] Definitely, the bug is PR37445, which was fixed on 3rd November. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38247
[Bug target/38177] Internal compiler error during gcc build with -march=amdfam10
--- Comment #6 from special at dereferenced dot net 2008-11-24 15:36 --- I've already spoken to one of the GCC maintainers for gentoo - he advised me to report the issue directly upstream if I could reproduce it without gentoo-specific patches (which I have); this could be an issue with how the gentoo ebuild is building gcc, but even so it looks like a GCC bug, not a gentoo bug. I can try a build with the latest from the 4.3 branch later today. -- special at dereferenced dot net changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38177
[Bug fortran/38248] Fatal Error: Reading module mmm: Expected left parenthesis
--- Comment #1 from mikael at gcc dot gnu dot org 2008-11-24 15:37 --- Works for me. $ /usr/local/bin/gfortran -v Utilisation des specs internes. Target: x86_64-unknown-linux-gnu Configuré avec: ../src/configure --enable-languages=fortran --enable-maintainer-mode --disable-multilib : (reconfigured) ../src/configure --enable-maintainer-mode --disable-multilib --enable-languages=c,fortran --no-create --no-recursion : (reconfigured) ../src/configure --enable-maintainer-mode --disable-multilib --enable-languages=c,fortran --no-create --no-recursion Modèle de thread: posix gcc version 4.4.0 20081123 (experimental) (GCC) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38248
[Bug target/38177] Internal compiler error during gcc build with -march=amdfam10
--- Comment #7 from ubizjak at gmail dot com 2008-11-24 16:00 --- (In reply to comment #6) I've already spoken to one of the GCC maintainers for gentoo - he advised me to report the issue directly upstream if I could reproduce it without gentoo-specific patches (which I have); this could be an issue with how the The trick is, that gentoo maintainer should first check if the bug is already fixed in the SVN (on the branch they are using). The maintainer _should_ track the SVN branch head to filter out bugs that are already fixed. Please see http://gcc.gnu.org/bugs.html#dontwant -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38177
[Bug c/38243] Restrict constraint violation not an error with -pedantic-errors
-- jsm28 at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||16989 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-24 16:13:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38243
[Bug fortran/38248] Fatal Error: Reading module mmm: Expected left parenthesis
--- Comment #2 from burnus at gcc dot gnu dot org 2008-11-24 16:20 --- The error message looks as if you are mixing a gfortran 4.3 compiled .mod file with a gfortran 4.4 compiler (or vice versa). While the gfortran 4.3 compiled *.o/*.so/*.a files are supposed to be compatible with 4.4's libgfortran.so, for .mod files this is not the case. (.mod files are not like *.h files compiler independent, but simply a binary dump of the interfaces of a single module.) I think a solution would be to create a version number for the .mod data and add a checking. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38248
[Bug fortran/38247] problem with contained subprocedure.
--- Comment #5 from burnus at gcc dot gnu dot org 2008-11-24 16:22 --- To add: There is currently a build problem for the linux 32bit version of the gfortran nightlies; thus there has been no newer build since about one month. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38247
[Bug fortran/38249] New: read(*,*) seems to have broken
I have some legacy code that I just tried compiling with gfortan (on a i686-linux-slackware-12.1 box). There were a large number of warnings of the type: Warning: Nonconforming tab character in column 1 of line 69 (These where lines which started with a single tab instead of 7 spaces). In addition there were some errors related to continuation lines of the form: 6 spaces 1 tab code all this was easy to fix, but when I ran the code, it sigsev'd dieing on a read(*,*)x,y line. Changing it to read(1,*)x,y works. This is a regression I think. One last thing: I'd been running the program as: echo 1 2 | a.out when this happened. -- Summary: read(*,*) seems to have broken Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ronis at ronispc dot chem dot mcgill dot ca http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38249
[Bug middle-end/38250] New: ICE with -O2 -ftree-loop-distribution
GCC ICEs on folowing code with options -O2 -ftree-loop-distribution
typedef long unsigned int size_t;
typedef struct {
long dat[2];
} gsl_complex_long_double;
typedef struct {
size_t size;
size_t stride;
long *data;
} gsl_vector_complex_long_double;
void gsl_vector_complex_long_double_set_zero (gsl_vector_complex_long_double *
v)
{
long * const data = v-data;
const size_t n = v-size;
const size_t stride = v-stride;
const gsl_complex_long_double zero = { { 0,0} } ;
size_t i;
for (i = 0; i n; i++)
*(gsl_complex_long_double *) (data + 2 * i * stride) = zero;
}
as
prx.c: In function gsl_vector_complex_long_double_set_zero:
prx.c:10: internal compiler error: in fold_binary, at fold-const.c:9308
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/abuild/tbily/install/ --enable-checks
--enable-bootstrap --disable-multilib
Thread model: posix
gcc version 4.4.0 20081118 (experimental) (GCC)
--
Summary: ICE with -O2 -ftree-loop-distribution
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tomby at gcc dot gnu dot org
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38250
[Bug middle-end/38250] ICE with -O2 -ftree-loop-distribution
--- Comment #1 from tomby at gcc dot gnu dot org 2008-11-24 16:31 --- Created an attachment (id=16758) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16758action=view) gcc ICEs on this file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38250
[Bug fortran/38247] problem with contained subprocedure.
--- Comment #4 from kargl at gcc dot gnu dot org 2008-11-24 15:32 --- After removing all of your full path names, I get REMOVE:kargl[215] gfc4x WinModI.f90 -c -Wall -O3 -ffast-math -funroll-loops -std=f2003 -fno-backslash -owinmod.o winmod.xyz WinModI.f90:68: Error: Can't open included file 'FldSet1A.f90' WinModI.f90:73: Error: Can't open included file 'FldSet2A.f90' WinModI.f90:74.26: There is no FldSet1A.f90 or FldSet2A.f90. REMOVE:kargl[216] find . -name FldSet\* ./FldSet.a90 Any chance you can 1) update to a newer compiler, and 2) cut this down to a much smaller example. PS: This shell script isn't a Bourne shell script. It appears to be a csh script. Add '#! /bin/csh' as the first line. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38247
[Bug fortran/38248] Ignored temporary module files manipulation errors
-- jan dot kratochvil at redhat dot com changed: What|Removed |Added Severity|blocker |normal Summary|Fatal Error: Reading module |Ignored temporary module |mmm: Expected left |files manipulation errors |parenthesis | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38248
[Bug middle-end/38250] ICE with -O2 -ftree-loop-distribution
--- Comment #2 from tomby at gcc dot gnu dot org 2008-11-24 16:39 --- In tree-loop-distribution.c (generate_memset_zero) can be DR_STEP(dr) NULL. But it is passed into fold_build2 that expect two non null expressions. If program flow goes to end: due to goto then temporary variables created during force_gimple_operand are added to referenced vars. But this variables have not def bb. So later checks fails. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38250
[Bug fortran/38248] Ignored temporary module files manipulation errors
--- Comment #3 from jan dot kratochvil at redhat dot com 2008-11-24 16:40
---
Created an attachment (id=16759)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16759action=view)
Check the file manipulations errors.
Thanks Tobias B.,
unlink(mmm.mod) = -1 EPERM (Operation not permitted)
rename(mmm.mod0, mmm.mod) = -1 EPERM (Operation not permitted)
write(2, init..., 5) = 5
stat(mmm.mod, {st_mode=S_IFREG|0644, st_size=547, ...}) = 0
open(mmm.mod, O_RDONLY) = 4
With the attached patch the same command now fails for me:
Fatal Error: Can't delete module file 'mmm.mod': Operation not permitted
I have no GCC SVN write permissions.
Left one unchecked unlink() in an error recovery path there.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38248
[Bug middle-end/38250] ICE with -O2 -ftree-loop-distribution
--- Comment #3 from tomby at gcc dot gnu dot org 2008-11-24 16:42 --- Created an attachment (id=16760) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16760action=view) This patch fixes problems -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38250
[Bug target/36793] x86-64 does not get __sync_synchronize right
--- Comment #9 from uros at gcc dot gnu dot org 2008-11-24 16:57 --- Subject: Bug 36793 Author: uros Date: Mon Nov 24 16:55:49 2008 New Revision: 142160 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142160 Log: * config/i386/i386.md (UNSPECV_CMPXCHG): Rename from UNSPECV_CMPXCHG_[12]. * config/i386/sync.md: Use UNSPECV_CMPXCHG instead of UNSPECV_CMPXCHG_[12]. PR target/36793 * config/i386/sync.md (memory_barrier): New expander. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md trunk/gcc/config/i386/sync.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36793
[Bug target/36793] x86-64 does not get __sync_synchronize right
--- Comment #10 from ubizjak at gmail dot com 2008-11-24 16:59 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36793
[Bug fortran/38249] read(*,*) seems to have broken
--- Comment #1 from kargl at gcc dot gnu dot org 2008-11-24 17:00 --- (In reply to comment #0) I have some legacy code that I just tried compiling with gfortan (on a i686-linux-slackware-12.1 box). There were a large number of warnings of the type: Warning: Nonconforming tab character in column 1 of line 69 (These where lines which started with a single tab instead of 7 spaces). In addition there were some errors related to continuation lines of the form: 6 spaces 1 tab code You failed to give the command line. But, to fix the warning problem by replacing the tab character. all this was easy to fix, but when I ran the code, it sigsev'd dieing on a read(*,*)x,y line. Changing it to read(1,*)x,y works. Unit 1 is not equivalent to unit 5 or *. You need to define works. This is a regression I think. One last thing: I'd been running the program as: echo 1 2 | a.out Patient: It hurts when I do this. Dcotor: Well, don't do that! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38249
Re: [Bug middle-end/38250] ICE with -O2 -ftree-loop-distribution
The patch looks good. Please test and ask for approval to commit to trunk on [EMAIL PROTECTED] Thanks, Sebastian
[Bug middle-end/38250] ICE with -O2 -ftree-loop-distribution
--- Comment #4 from sebpop at gmail dot com 2008-11-24 17:27 --- Subject: Re: ICE with -O2 -ftree-loop-distribution The patch looks good. Please test and ask for approval to commit to trunk on [EMAIL PROTECTED] Thanks, Sebastian -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38250
[Bug fortran/38249] read(*,*) seems to have broken
--- Comment #2 from burnus at gcc dot gnu dot org 2008-11-24 17:07 --- Regarding TAB: Standard Fortran does not allow tabs, as extension gfortran does. Thus you do not need to change the code (though it does not harm to be standard compliant - that is what the warning tells you). But one needs to be careful: By default, every character after column 72 is ignored; I forgot how this interplays with tabs (i.e. whether they count as 1 or as 6 spaces). The line read(*,*)x,y looks harmless and of cause works here with a simple test program; the line should work since early gfortran 4.0.0. Can you attach a minimal program which fails? And include the exact command you entered and the exact gfortran version (gcc version and the Target: line shown by gfortran -v). Additionally, you could try a newer version, cf. http://gcc.gnu.org/wiki/GFortranBinaries, though I would expect that this does not help as the problem is probably elsewhere. (I'd expect that it is a bug in your program.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38249
[Bug middle-end/38167] Accessor to stdin breaks on -O2 optimization
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-11-24 17:46 --- This is most likely one of the aliasing bugs. Does -fno-strict-aliasing fix the issue? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |middle-end Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38167
[Bug libgcj/38251] New: [4.4 Regression] tools.zip doesn't build on systems with short command lines
As of trunk revision 142086, libgcj doesn't build any longer on Tru64 UNIX V5.1B: (cd classes; \ jar cf ../tools.zip `find . -name .svn -prune -o -type f -print`; \ cd ..) /usr/local/bin/bash: /vol/gnu/bin/jar: Arg list too long I think such systems still need to be taken into account. This was broken by this change: 2008-11-05 Andrew Haley [EMAIL PROTECTED] * tools/Makefile.am (UPDATE_TOOLS_ZIP, CREATE_TOOLS_ZIP): Exclude .svn directories. -- Summary: [4.4 Regression] tools.zip doesn't build on systems with short command lines Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: aph at gcc dot gnu dot org ReportedBy: ro at gcc dot gnu dot org GCC build triplet: alpha-dec-osf5.1b GCC host triplet: alpha-dec-osf5.1b GCC target triplet: alpha-dec-osf5.1b http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38251
[Bug libgcj/38251] [4.4 Regression] tools.zip doesn't build on systems with short command lines
--- Comment #1 from aph at gcc dot gnu dot org 2008-11-24 17:56 --- Please try jar cf ../tools.zip `find . -name .svn -prune -o -type d -print` -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38251
[Bug target/35018] [m68k-elf] Gcc ouputs invalid asm when compiling with -O2 or higher
--- Comment #5 from mkuvyrkov at gcc dot gnu dot org 2008-11-24 17:56 --- Subject: Bug 35018 Author: mkuvyrkov Date: Mon Nov 24 17:55:35 2008 New Revision: 142161 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142161 Log: PR target/35018 * config/m68k/m68k.md (ok_for_coldfire, enabled): New attributes. (addsi_lshrsi_31): Add ColdFire-friendly alternatives. * gcc.target/m68k/pr35018.c: New. Added: trunk/gcc/testsuite/gcc.target/m68k/pr35018.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/m68k/m68k.md trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35018
[Bug fortran/38252] New: Empty function with CONTAINS triggers Internal Error
This program gives an Internal Error pointing at the CONTAINS: INTEGER FUNCTION test () CONTAINS END FUNCTION test It works with gfortran 4.3.1. Replacing the FUNCTION by a SUBROUTINE gets rid of the error. Additionally, this program also works: FUNCTION test () INTEGER :: test CONTAINS END FUNCTION test -- Summary: Empty function with CONTAINS triggers Internal Error Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: domob at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38252
[Bug libgcj/38251] [4.4 Regression] tools.zip doesn't build on systems with short command lines
--- Comment #2 from ro at techfak dot uni-bielefeld dot de 2008-11-24 18:04 --- Subject: Re: [4.4 Regression] tools.zip doesn't build on systems with short command lines aph at gcc dot gnu dot org writes: Please try jar cf ../tools.zip `find . -name .svn -prune -o -type d -print` while this works, many files are added several times, e.g. % jar tf ../tools.zip |grep classes/com/sun/javadoc/ProgramElementDoc.class classes/com/sun/javadoc/ProgramElementDoc.class classes/com/sun/javadoc/ProgramElementDoc.class classes/com/sun/javadoc/ProgramElementDoc.class classes/com/sun/javadoc/ProgramElementDoc.class classes/com/sun/javadoc/ProgramElementDoc.class If one wanted to go this path, one would need to prune all but the deepest directories. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38251
[Bug c++/38076] FAIL: g++.dg/other/anon5.C
--- Comment #2 from janis at gcc dot gnu dot org 2008-11-24 18:07 --- Subject: Bug 38076 Author: janis Date: Mon Nov 24 18:05:50 2008 New Revision: 142163 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142163 Log: 2008-11-24 Jack Howarth [EMAIL PROTECTED] PR testsuite/38076 * g++.dg/other/anon5.C: Skip on Darwin. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/other/anon5.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38076
[Bug testsuite/38241] g++.old-deja/g++.pt/const2.C fails on *-apple-darwin9
--- Comment #3 from janis at gcc dot gnu dot org 2008-11-24 18:12 --- Subject: Bug 38241 Author: janis Date: Mon Nov 24 18:11:12 2008 New Revision: 142164 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142164 Log: 2008-11-24 Jack Howarth [EMAIL PROTECTED] PR testsuite/38241 * g++.old-deja/g++.pt/const2.C: Prune output for Darwin. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.old-deja/g++.pt/const2.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38241
[Bug middle-end/38167] Accessor to stdin breaks on -O2 optimization
--- Comment #7 from aleksi dot nurmi at helsinki dot fi 2008-11-24 18:17 --- (In reply to comment #6) This is most likely one of the aliasing bugs. Does -fno-strict-aliasing fix the issue? Nope. I did a little research and it seems that -fno-tree-vrp fixes it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38167
[Bug libgcj/38251] [4.4 Regression] tools.zip doesn't build on systems with short command lines
--- Comment #3 from aph at gcc dot gnu dot org 2008-11-24 18:29 --- Yes, of course. jar has an update mode that adds files, so I can use that. How long may an arglist be? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38251
[Bug middle-end/36359] missed optimization in some cases with PRE VRP and other passes combined together
--- Comment #17 from edwintorok at gmail dot com 2008-11-24 18:33 --- Created an attachment (id=16761) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16761action=view) drivers/scsi/sd.c Similar problem with drivers/scsi/sd.c I can compile the attached preprocessed on x86_64 linux: $ gcc-4.3 -c x.i -o x.o -O2 nm -u x.o|grep ilog2 $ ~/gcc_inst/bin/gcc -c x.i -o x.o -O2 nm -u x.o|grep ilog2 U ilog2_NaN IMHO the kernel is abusing gcc as a static analyzer, which gcc is not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36359
[Bug libgcj/38251] [4.4 Regression] tools.zip doesn't build on systems with short command lines
--- Comment #4 from ro at techfak dot uni-bielefeld dot de 2008-11-24 18:37 --- Subject: Re: [4.4 Regression] tools.zip doesn't build on systems with short command lines aph at gcc dot gnu dot org writes: jar has an update mode that adds files, so I can use that. How long may an arglist be? % getconf ARG_MAX 38912 I'm astonished that it is so low; I thought only IRIX 6 had a limit this close to the old 20k default. Unfortunately, the version of jar I use reports % jar u /vol/gnu/bin/jar: `-u' mode unimplemented. % jar --version jar (fastjar) 0.92-gcc Copyright 1999, 2000, 2001 Bryan Burns Copyright 2002 Free Software Foundation This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Perhaps I should simply move it out of the way and use zip instead. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38251
[Bug libgcj/38251] [4.4 Regression] tools.zip doesn't build on systems with short command lines
--- Comment #5 from aph at gcc dot gnu dot org 2008-11-24 18:48 --- Sure, if you can use zip instead, do that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38251
[Bug fortran/38247] problem with contained subprocedure.
--- Comment #6 from clerman at fuse dot net 2008-11-24 18:50 --- Created an attachment (id=16762) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16762action=view) updated, and corrected (I hope) archive hello, Sorry for the mixup on the archive. I've attached a new one, bug32_1a.tgz that should work. It's a bash shell. It seems to me that the problem is that you have not been able to build a new 32-bit version since you fixed the problem in the 64-bit version. Do you have any idea when you'll be able to update the former? In any case, let me know when you do. Thanks for your help. Norm -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38247
[Bug c++/38253] New: g++.dg/ipa/iinline-1.C scan-ipa-dump inline fails on powerpc-apple-darwin9
The test case for g++.dg/ipa/iinline-1.C scan-ipa-dump inline fails on powerpc-apple-darwin9 as follows in current gcc trunk... Executing on host: /sw/src/fink.build/gcc44-4.3.999-20081120/darwin_objdir/gcc/testsuite/g++/../../g++ -B/sw/src/fink.build/gcc44-4.3.999-20081120/darwin_objdir/gcc/testsuite/g++/../../ /sw/src/fink.build/gcc44-4.3.999-20081120/gcc-4.4-20081120/gcc/testsuite/g++.dg/ipa/iinline-1.C -nostdinc++ -I/sw/src/fink.build/gcc44-4.3.999-20081120/darwin_objdir/powerpc-apple-darwin9/libstdc++-v3/include/powerpc-apple-darwin9 -I/sw/src/fink.build/gcc44-4.3.999-20081120/darwin_objdir/powerpc-apple-darwin9/libstdc++-v3/include -I/sw/src/fink.build/gcc44-4.3.999-20081120/gcc-4.4-20081120/libstdc++-v3/libsupc++ -I/sw/src/fink.build/gcc44-4.3.999-20081120/gcc-4.4-20081120/libstdc++-v3/include/backward -I/sw/src/fink.build/gcc44-4.3.999-20081120/gcc-4.4-20081120/libstdc++-v3/testsuite/util -fmessage-length=0 -O3 -fdump-ipa-inline -fno-early-inlining -fpie -S -o iinline-1.s(timeout = 300) PASS: g++.dg/ipa/iinline-1.C (test for excess errors) FAIL: g++.dg/ipa/iinline-1.C scan-ipa-dump inline String::funcOne[^\n]*inline copy in int main -- Summary: g++.dg/ipa/iinline-1.C scan-ipa-dump inline fails on powerpc-apple-darwin9 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: howarth at nitro dot med dot uc dot edu GCC build triplet: powerpc-apple-darwin9 GCC host triplet: powerpc-apple-darwin9 GCC target triplet: powerpc-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38253
[Bug c++/38253] g++.dg/ipa/iinline-1.C scan-ipa-dump inline fails on powerpc-apple-darwin9
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2008-11-24 18:52 --- Created an attachment (id=16763) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16763action=view) assembly file for g++.dg/ipa/iinline-1.C on powerpc-apple-darwin9 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38253
[Bug libgcj/38251] [4.4 Regression] tools.zip doesn't build on systems with short command lines
--- Comment #6 from aph at gcc dot gnu dot org 2008-11-24 18:52 --- I suggest jar cf ... to create it, and zip u ... to add to it that way you'll get the correct META-INF directory. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38251
[Bug fortran/38247] problem with contained subprocedure.
--- Comment #7 from clerman at fuse dot net 2008-11-24 18:54 --- Subject: Re: problem with contained subprocedure. Hello, This appears to be the problem. In any case, I just submitted a new archive file. I hope this one's correct. Thanks for your help. Let me know when the fix has been made to the 32-bit version as well. Norm burnus at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #5 from burnus at gcc dot gnu dot org 2008-11-24 16:22 --- To add: There is currently a build problem for the linux 32bit version of the gfortran nightlies; thus there has been no newer build since about one month. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38247 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38247
[Bug fortran/38184] invariant RESHAPE not expanded if SOURCE is empty
--- Comment #4 from mikael at gcc dot gnu dot org 2008-11-24 19:06 --- Subject: Bug 38184 Author: mikael Date: Mon Nov 24 19:04:34 2008 New Revision: 142168 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142168 Log: 2008-11-24 Mikael Morin [EMAIL PROTECTED] PR fortran/38184 * simplify.c (is_constant_array_expr): Return true instead of false if the array constructor is empty. 2008-11-24 Mikael Morin [EMAIL PROTECTED] PR fortran/38184 * gfortran.dg/reshape_empty_1.f03: New test. Added: trunk/gcc/testsuite/gfortran.dg/reshape_empty_1.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/simplify.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38184
[Bug fortran/38249] read(*,*) seems to have broken
--- Comment #3 from ronis at ronispc dot chem dot mcgill dot ca 2008-11-24 19:07 --- OK, here's the information you requested: gfortran -v: Target: i686-pc-linux-gnu Configured with: ../gcc/configure --host=i686-pc-linux-gnu --prefix=/usr --with-gnu-as --enable-shared --with-gnu-ld --enable-threads=posix --with-ecj-jar=/usr/share/java/ecj.jar --enable-languages=c,c++,fortran,java,objc Thread model: posix gcc version 4.3.2 (GCC) Now for the more difficult part. I'll attach a tar file containing a sample program and a makefile. It turns out that the problem isn't with the read at all, rather it arises when I try to write to an array that is equivalenced to another. (This is all in the file niovers.f). Worse, the bug is triggered by passing -malign-double to gfortran I'm going to save this and make the attachment. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38249
[Bug fortran/38249] read(*,*) seems to have broken
--- Comment #4 from ronis at ronispc dot chem dot mcgill dot ca 2008-11-24 19:08 --- Created an attachment (id=16764) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16764action=view) sample source and makefile Running make or make DEBUG=x will generate the program. When you run and are prompted for input, enter 0.0001 and 1000 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38249
[Bug fortran/35681] wrong result for vector subscripted array expression in MVBITS
--- Comment #26 from pault at gcc dot gnu dot org 2008-11-24 19:14 --- Subject: Bug 35681 Author: pault Date: Mon Nov 24 19:13:12 2008 New Revision: 142169 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142169 Log: 2008-11-24 Steven G. Kargl [EMAIL PROTECTED] PR fortran/37792 * fortran/resolve.c (resolve_fl_variable): Simplify the initializer if there is one. 2008-11-24 Steven G. Kargl [EMAIL PROTECTED] PR fortran/37792 * gfortran.dg/arithmetic_overflow_1.f90: New test. 2008-11-24 Mikael Morin [EMAIL PROTECTED] PR fortran/35681 * gfortran.dg/elemental_dependency_1.f90: Correct strings in test. Added: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/arithmetic_overflow_1.f90 Modified: branches/gcc-4_3-branch/gcc/fortran/ChangeLog branches/gcc-4_3-branch/gcc/fortran/resolve.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/elemental_dependency_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35681
[Bug fortran/37926] Program gives wrong output (connected to char len)
--- Comment #8 from pault at gcc dot gnu dot org 2008-11-24 19:20 --- Subject: Bug 37926 Author: pault Date: Mon Nov 24 19:18:39 2008 New Revision: 142171 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142171 Log: 2008-11-24 Paul Thomas [EMAIL PROTECTED] PR fortran/37926 * trans-expr.c (gfc_free_interface_mapping): Null sym-formal (gfc_add_interface_mapping): Copy the pointer to the formal arglist and set attr.always_explicit if this is a procedure. 2008-11-24 Paul Thomas [EMAIL PROTECTED] PR fortran/37926 * gfortran.dg/dummy_procedure_3.f90: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/dummy_procedure_3.f90 Modified: branches/gcc-4_3-branch/gcc/fortran/ChangeLog branches/gcc-4_3-branch/gcc/fortran/trans-expr.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37926
[Bug fortran/37926] Program gives wrong output (connected to char len)
--- Comment #9 from pault at gcc dot gnu dot org 2008-11-24 19:20 --- Fixed on trunk and 4.3. Thanks for the report. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37926
[Bug fortran/37792] ICE in gfc_conv_array_initializer; works with -fno-range-check
--- Comment #3 from pault at gcc dot gnu dot org 2008-11-24 19:14 --- Subject: Bug 37792 Author: pault Date: Mon Nov 24 19:13:12 2008 New Revision: 142169 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142169 Log: 2008-11-24 Steven G. Kargl [EMAIL PROTECTED] PR fortran/37792 * fortran/resolve.c (resolve_fl_variable): Simplify the initializer if there is one. 2008-11-24 Steven G. Kargl [EMAIL PROTECTED] PR fortran/37792 * gfortran.dg/arithmetic_overflow_1.f90: New test. 2008-11-24 Mikael Morin [EMAIL PROTECTED] PR fortran/35681 * gfortran.dg/elemental_dependency_1.f90: Correct strings in test. Added: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/arithmetic_overflow_1.f90 Modified: branches/gcc-4_3-branch/gcc/fortran/ChangeLog branches/gcc-4_3-branch/gcc/fortran/resolve.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/elemental_dependency_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37792
[Bug fortran/37792] ICE in gfc_conv_array_initializer; works with -fno-range-check
--- Comment #4 from pault at gcc dot gnu dot org 2008-11-24 19:21 --- Fixed on trunk and 4.3 Thanks for the report Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37792
[Bug fortran/38249] read(*,*) seems to have broken
--- Comment #5 from kargl at gcc dot gnu dot org 2008-11-24 19:22 --- (In reply to comment #3) Now for the more difficult part. I'll attach a tar file containing a sample program and a makefile. It turns out that the problem isn't with the read at all, rather it arises when I try to write to an array that is equivalenced to another. (This is all in the file niovers.f). Worse, the bug is triggered by passing -malign-double to gfortran I'm going to save this and make the attachment. Does the code work without -malign-double? Don't use -malign-double. If you absolutely think you need -malign-double, you need to recompile the runtime library with this option. Also see the gcc manual for a description of this option. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38249
[Bug fortran/38249] read(*,*) seems to have broken
--- Comment #6 from ronis at ronispc dot chem dot mcgill dot ca 2008-11-24 19:29 --- It works without -malign-double, but has worked with it for years. I understand that all modules (even thouse in MY libraries) have to be compiled with the same flags, but nothing seems to imply that the compiler's libraries have to have it too. Something has changed recently. From the info page: Control whether GCC aligns `double', `long double', and `long long' variables on a two word boundary or a one word boundary. Aligning `double' variables on a two word boundary will produce code that runs somewhat faster on a `Pentium' at the expense of more memory. On x86-64, `-malign-double' is enabled by default. *Warning:* if you use the `-malign-double' switch, structures containing the above types will be aligned differently than the published application binary interface specifications for the 386 and will not be binary compatible with structures in code compiled without that switch. This is the same as what it's been for some time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38249
[Bug target/38254] New: [4.4 Regression] Revision 142160 causes PR27908 -O3
On Linux/ia32 SMP, revision 142160 http://gcc.gnu.org/ml/gcc-patches/2008-11/msg01194.html causes FAIL: PR27908 -O3 execution - source compiled test FAIL: PR27908 -O3 -findirect-dispatch execution - source compiled test -- Summary: [4.4 Regression] Revision 142160 causes PR27908 -O3 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38254
[Bug fortran/37319] [4.4 regression] gfortran.dg/function_kinds_5.f90 fails
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2008-11-24 19:32 --- The problem still reproduces on the SPARC as of today. When the compiler is rebuilt at -O0, it goes away; when decl.c and parser.c are rebuilt at -O2, it comes back. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|i686-apple-darwin9 | GCC host triplet|i686-apple-darwin9 | GCC target triplet|i686-apple-darwin9 | Last reconfirmed|2008-10-05 19:03:35 |2008-11-24 19:32:05 date|| Summary|FAIL the unexplained fix: |[4.4 regression] |gfortran.dg/function_kinds_5|gfortran.dg/function_kinds_5 |.f90|.f90 fails http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37319
[Bug fortran/38249] read(*,*) seems to have broken
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-11-24 19:32 --- Not just all your modules but libgfortran also and all of glibc etc. -- 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=38249
[Bug fortran/37319] [4.4 regression] gfortran.dg/function_kinds_5.f90 fails
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2008-11-24 19:32 --- Investigating. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-11-24 19:32:05 |2008-11-24 19:32:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37319
[Bug middle-end/38167] [4.2 Regression] Accessor to stdin breaks on -O2 optimization
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.2.4 Known to work||4.4.0 4.3.0 Summary|Accessor to stdin breaks on |[4.2 Regression] Accessor to |-O2 optimization|stdin breaks on -O2 ||optimization Target Milestone|--- |4.2.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38167
[Bug fortran/38249] read(*,*) seems to have broken
--- Comment #8 from ronis at ronispc dot chem dot mcgill dot ca 2008-11-24 19:36 --- I don't mean to be combative, but if EVERYTHING (glibc etc) needs to be build with -malign-double, not just fortran programs, then IMHO the flag is useless and should be removed. I've been using this flag in legacy fortran code for years--this is the first time ever that I've encountered this problem (as the info page suggests). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38249
[Bug fortran/38249] read(*,*) seems to have broken
--- Comment #9 from kargl at gcc dot gnu dot org 2008-11-24 19:52 --- (In reply to comment #8) I don't mean to be combative, but if EVERYTHING (glibc etc) needs to be build with -malign-double, not just fortran programs, then IMHO the flag is useless and should be removed. I've been using this flag in legacy fortran code for years--this is the first time ever that I've encountered this problem (as the info page suggests). The problem is that a large amount of libgfortran is actually written in Fortran and a data structure used by the IO facility has an alignment issue. By using -malign-double, this data structure becomes corrupt. I'm unfamiliar with the glibc issue, so can't comment on it. A long time ago, I wrote a patch that had gfortran intercept -malign-double. Compilation would abort. I don't remember why the patch was never accepted. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38249
[Bug fortran/37319] [4.4 regression] gfortran.dg/function_kinds_5.f90 fails
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2008-11-24 19:59
---
This looks like a missing or wrong initialisation.
Confirmed, it's 'name' in match_deferred_characteristics:
char name[GFC_MAX_SYMBOL_LEN + 1];
[...]
/* Set the function locus correctly. If we have not found the
function name, there is an error. */
gfc_match (function% %n, name);
if (m == MATCH_YES strcmp (name, gfc_current_block ()-name) == 0)
{
gfc_current_block ()-declared_at = gfc_current_locus;
gfc_commit_symbols ();
}
else
gfc_error_check ();
gfc_match (function% %n, name) doesn't touch 'name' so the outcome of the
string comparison is random. Would it make sense to test the return value
of gfc_match here?
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
CC||pault at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37319
[Bug debug/37941] Too many DW_TAG_Subprogram tags generated
--- Comment #1 from jan dot kratochvil at redhat dot com 2008-11-24 20:08 --- The excessive item 53 is really still present in Fedora gcc-c++-4.3.2-7.x86_64 but not in HEAD - 4.4.0 20081124: 12d: Abbrev Number: 2 (DW_TAG_namespace) 2e DW_AT_name: D 30 DW_AT_decl_file : 1 31 DW_AT_decl_line : 7 32 DW_AT_sibling : 0x48 236: Abbrev Number: 3 (DW_TAG_subprogram) 37 DW_AT_external: 1 38 DW_AT_name: foo 3c DW_AT_decl_file : 1 3d DW_AT_decl_line : 8 3e DW_AT_MIPS_linkage_name: (indirect string, offset: 0x3c): _ZN1D3fooEv 42 DW_AT_type: 0x48 46 DW_AT_declaration : 1 [...] 14f: Abbrev Number: 5 (DW_TAG_subprogram) 50 DW_AT_specification: 0x36 54 DW_AT_low_pc : 0x0 5c DW_AT_high_pc : 0x17 64 DW_AT_frame_base : 0x0 (location list) As D::foo() has no extra declaration as it is defined in the class definition 36 and 4f could be merged but it is only a minor optimization now as for common separate declaration and definition two DIEs still have to exist to have distinct DW_AT_decl_line. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37941
[Bug fortran/37319] [4.4 regression] gfortran.dg/function_kinds_5.f90 fails
--- Comment #9 from kargl at gcc dot gnu dot org 2008-11-24 20:24 ---
(In reply to comment #8)
This looks like a missing or wrong initialisation.
Confirmed, it's 'name' in match_deferred_characteristics:
char name[GFC_MAX_SYMBOL_LEN + 1];
[...]
/* Set the function locus correctly. If we have not found the
function name, there is an error. */
gfc_match (function% %n, name);
This should probably be
m = gfc_match (function% %n, name);
if (m == MATCH_YES strcmp (name, gfc_current_block ()-name) == 0)
Otherwise, the 'm == MATCH_YES' is using an old value.
{
gfc_current_block ()-declared_at = gfc_current_locus;
gfc_commit_symbols ();
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37319
[Bug fortran/37319] [4.4 regression] gfortran.dg/function_kinds_5.f90 fails
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2008-11-24 20:33
---
This should probably be
m = gfc_match (function% %n, name);
if (m == MATCH_YES strcmp (name, gfc_current_block ()-name) == 0)
Otherwise, the 'm == MATCH_YES' is using an old value.
But in this case the first assignment to 'm' would be dead. What about
if (m == MATCH_YES
gfc_match (function% %n, name) == MATCH_YES
strcmp (name, gfc_current_block ()-name) == 0)
{
gfc_current_block ()-declared_at = gfc_current_locus;
gfc_commit_symbols ();
}
else
gfc_error_check ();
instead?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37319
[Bug c++/38255] New: Invalid access with nested classes
Tested with g++ versions 4.1.2 and 4.3.2, they both fail to reject the
following invalid code:
class E {
int x;
class B { };
class I {
B b;// error: E::B is private
int y;
void f(E* p, int i)
{
p-x = i; // error: E::x is private
}
};
int g(I* p)
{
//return p-y;// error: I::y is private (g++ correctly errors here)
}
};
This is taken straight from the standard, section 11.8.1:
http://www.csci.csusb.edu/dick/c++std/cd2/access.html
1 The members of a nested class have no special access to members of an
enclosing class, nor to classes or functions that have granted friend-
ship to an enclosing class; the usual access rules (_class.access_)
shall be obeyed. The members of an enclosing class have no special
access to members of a nested class; the usual access rules
(_class.access_) shall be obeyed. [Example:
class E {
int x;
class B { };
class I {
B b;// error: E::B is private
int y;
void f(E* p, int i)
{
p-x = i; // error: E::x is private
}
};
int g(I* p)
{
return p-y;// error: I::y is private
}
};
--end example]
--
Summary: Invalid access with nested classes
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: grogers at tecore dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38255
[Bug c++/38256] New: [4.4 regression] ICE with operator auto
The following invalid code snippet triggers an ICE on mainline:
==
templateint struct A
{
templatetypename T operator T();
};
void foo()
{
A0().operator auto();
}
==
bug.cc: In function 'void foo()':
bug.cc:8: internal compiler error: tree check: expected function_decl, have
template_decl in build_over_call, at cp/call.c:5123
Please submit a full bug report, [etc.]
--
Summary: [4.4 regression] ICE with operator auto
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38256
[Bug c++/38256] [4.4 regression] ICE with operator auto
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38256
[Bug fortran/37319] [4.4 regression] gfortran.dg/function_kinds_5.f90 fails
--- Comment #11 from kargl at gcc dot gnu dot org 2008-11-24 20:46 ---
(In reply to comment #10)
This should probably be
m = gfc_match (function% %n, name);
if (m == MATCH_YES strcmp (name, gfc_current_block ()-name) == 0)
Otherwise, the 'm == MATCH_YES' is using an old value.
But in this case the first assignment to 'm' would be dead. What about
if (m == MATCH_YES
gfc_match (function% %n, name) == MATCH_YES
strcmp (name, gfc_current_block ()-name) == 0)
{
gfc_current_block ()-declared_at = gfc_current_locus;
gfc_commit_symbols ();
}
else
gfc_error_check ();
instead?
OK, I've found the code location in parse.c. Yes, I think the
above is probably correct. Note, I'm no longer a gfortran
maintainer, so I can't approve the patch and I haven't tested
it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37319
[Bug c++/359] [DR 45] g++ incorrectly grants access to private members to nested classes
--- Comment #10 from pinskia at gcc dot gnu dot org 2008-11-24 20:46 --- *** Bug 38255 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||grogers at tecore dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=359
[Bug c++/38255] Invalid access with nested classes
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-11-24 20:46 --- A defect to the C++ standard changed the C++ standard here to be what GCC does. See http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#45 . *** This bug has been marked as a duplicate of 359 *** -- 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=38255
[Bug c++/38257] New: [4.4 regression] ICE with auto and #pragma omp parallel
The following (IMHO valid) code snippet triggers an ICE on mainline when
compiled with -fopenmp:
==
templateint void foo()
{
#pragma omp parallel for
for (auto i=0; i4; ++i) ;
}
==
bug.cc: In function 'void foo()':
bug.cc:4: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
Without the template I get the following error message:
bug.cc: In function 'void foo()':
bug.cc:4: error: declaration of 'auto i' has no initializer
bug.cc:4: error: invalid type for iteration variable 'i'
which seems to be wrong because i has an initializer.
Without -fopenmp both versions compile fine.
--
Summary: [4.4 regression] ICE with auto and #pragma omp parallel
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38257
[Bug c++/38257] [4.4 regression] ICE with auto and #pragma omp parallel
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38257
[Bug libstdc++/38244] [4.4 Regression] bitset initialization from 0 rejected.
--- Comment #7 from cgd at google dot com 2008-11-24 20:55 --- Would it make sense to add a this test code as a test case? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38244
[Bug fortran/37319] [4.4 regression] gfortran.dg/function_kinds_5.f90 fails
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2008-11-24 20:55 --- OK, I've found the code location in parse.c. Yes, I think the above is probably correct. Note, I'm no longer a gfortran maintainer, so I can't approve the patch and I haven't tested it. Understood, I'm going to test and submit it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37319
[Bug c++/38175] Explicit instantiation of a template hides symbols with the default visibility attribute
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-11-24 21:03 --- I think this is expected behavior because you said only that one instantiation is not hidden and but not in all translational units. You should most likely use extern template to get the behavior you want. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38175
