[Bug libfortran/43844] open(unit, status=scratch) fails to create tempporary file
--- Comment #13 from burnus at gcc dot gnu dot org 2010-04-26 06:11 --- Kai, what about the GetTempPath? Cf. the rough draft in attachment 20460 ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43844
[Bug lto/41584] WHOPR doesn't grok empty units
--- Comment #4 from hubicka at gcc dot gnu dot org 2010-04-26 07:55 --- Well, or just use some default name of the unit ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41584
[Bug debug/33155] _stdcall assembler names in win32 vs gdb
--- Comment #7 from dannysmith at users dot sourceforge dot net 2010-04-26 08:19 --- This is fixed in 4.5.0 release. http://gcc.gnu.org/viewcvs?view=revisionrevision=148199 Danny -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Known to work|4.2.1 |4.2.1 4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33155
[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault
--- Comment #35 from dominiq at lps dot ens dot fr 2010-04-26 08:23 --- The testsuite completed cleanly, without any failures. Paul, if you agree that this patch is ok, I can commit it tomorrow. Confirmed without any problem on my own test. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274
[Bug target/43216] Use high registers to reduce code size and improve performance when targeting thumb2
--- Comment #5 from carrot at google dot com 2010-04-26 08:30 --- Yes, it looks much better for this case. The number of instructions is reduced from 49 to 39. All problems described have gone. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43216
[Bug target/43216] Use high registers to reduce code size and improve performance when targeting thumb2
--- Comment #6 from ramana at gcc dot gnu dot org 2010-04-26 08:47 --- Fixed now. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43216
[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault
--- Comment #36 from janus at gcc dot gnu dot org 2010-04-26 09:08 --- Subject: Bug 42274 Author: janus Date: Mon Apr 26 09:07:26 2010 New Revision: 158721 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158721 Log: 2010-04-26 Janus Weil ja...@gcc.gnu.org PR fortran/42274 * symbol.c (add_proc_component,add_proc_comps): Correctly set the 'ppc' attribute for all PPC members of the vtypes. (copy_vtab_proc_comps): Copy the correct interface. * trans.h (gfc_trans_assign_vtab_procs): Modified prototype. * trans-expr.c (gfc_trans_assign_vtab_procs): Pass the derived type as a dummy argument and make sure all PPC members of the vtab are initialized correctly. (gfc_conv_derived_to_class,gfc_trans_class_assign): Additional argument in call to gfc_trans_assign_vtab_procs. * trans-stmt.c (gfc_trans_allocate): Ditto. 2010-04-26 Janus Weil ja...@gcc.gnu.org PR fortran/42274 * gfortran.dg/class_15.f03: New. Added: branches/fortran-dev/gcc/testsuite/gfortran.dg/class_15.f03 Modified: branches/fortran-dev/gcc/fortran/ChangeLog.fortran-dev branches/fortran-dev/gcc/fortran/symbol.c branches/fortran-dev/gcc/fortran/trans-expr.c branches/fortran-dev/gcc/fortran/trans-stmt.c branches/fortran-dev/gcc/fortran/trans.h branches/fortran-dev/gcc/testsuite/ChangeLog.fortran-dev -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274
[Bug debug/42425] ICE declaring local class
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-04-26 09:13 --- Subject: Bug 42425 Author: rguenth Date: Mon Apr 26 09:13:00 2010 New Revision: 158722 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158722 Log: 2010-04-26 Richard Guenther rguent...@suse.de PR lto/42425 * tree.c (free_lang_data_in_type): Do not free TYPE_CONTEXT if emitting debug information and it is either a function or a namespace decl. * g++.dg/lto/20100423-2_0.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/lto/20100423-2_0.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42425
[Bug bootstrap/43858] [4.6 Regression] Bootstrap failure for powerpc-apple-darwin9: cannot compute suffix of object files
--- Comment #6 from dominiq at lps dot ens dot fr 2010-04-26 09:16 --- This PR is likely due to revision 158639: Author: bernds Date: Thu Apr 22 10:42:21 2010 UTC (3 days, 22 hours ago) Changed paths: 4 Log Message: * ifcvt.c (dead_or_predicable): Use df_simulate_find_defs and df_simulate_find_noclobber_defs as appropriate. Keep track of an extra set merge_set_noclobber, and use it to relax the final test slightly. * df.h (df_simulate_find_noclobber_defs): Declare. * df-problems.c (df_simulate_find_defs): Don't ignore partial or conditional defs. (df_simulate_find_noclobber_defs): New function. I have successfully bootstrapped revision 158633 (with r158643), revision 158639 (+r158643) fails to bootstrap with an ICE while configuring libgcc at stage 2, and revision 158634 (+r158643) is now at stage 3. I doubt that the revision in between 158634 and 158639 can break bootstap on ppc. -- dominiq at lps dot ens dot fr changed: What|Removed |Added CC||bernds at codesourcery dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43858
[Bug debug/42425] ICE declaring local class
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-04-26 09:17 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail||4.5.0 Resolution||FIXED Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42425
[Bug c++/43080] ICE with anonymous union and -flto
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-04-26 09:19 --- Subject: Bug 43080 Author: rguenth Date: Mon Apr 26 09:19:24 2010 New Revision: 158723 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158723 Log: 2010-04-26 Richard Guenther rguent...@suse.de PR lto/43080 * gimple.c (gimple_decl_printable_name): Deal gracefully with a NULL DECL_NAME. * g++.dg/lto/20100423-3_0.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/lto/20100423-3_0.C Modified: trunk/gcc/ChangeLog trunk/gcc/gimple.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43080
[Bug c++/43080] ICE with anonymous union and -flto
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-04-26 09:25 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail||4.5.0 Resolution||FIXED Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43080
[Bug c++/43890] [4.6 Regression] invalid uninitialized reference in class
--- Comment #1 from redi at gcc dot gnu dot org 2010-04-26 09:30 --- possibly caused by the changes for Bug 25811 -- redi at gcc dot gnu dot org changed: What|Removed |Added CC||jason at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43890
[Bug c++/43890] [4.6 Regression] invalid uninitialized reference in class
--- Comment #2 from fabien dot chene at gmail dot com 2010-04-26 09:58 --- (In reply to comment #1) possibly caused by the changes for Bug 25811 Confirmed, please assigned me on this regression. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43890
[Bug middle-end/39883] preprocessor fails with myassertion
--- Comment #2 from Denis dot Excoffier at airbus dot com 2010-04-26 09:58 --- I tried this morning to reproduce this bug with GCC 4.4.3 and GCC 4.5.0 and i didn't succeed (that is: the GCC 4.4.0 bug is gone). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39883
[Bug target/43884] [4.4/4.5/4.6 Regression] Performance degradation for simple fibonacci numbers calculation due to extra stack alignment
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-04-26 10:36 --- (In reply to comment #7) Subject: Re: [4.4/4.5/4.6 Regression] Performance degradation for simple fibonacci numbers calculation due to extra stack alignment The slowdown also happens on x86-64. Stack alignment checks leaf function. But I am sure if it detects tail-recursion. Is such information available to ix86_finalize_stack_realign_flags? Tail recursion is recognized at gimple level, so rtl code should not be at all bothered here. There is a recursive self-call left (but that's the only call, so its still a leaf function). Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43884
[Bug target/43889] [4.5/4.6 Regression]: mmix-knuth-mmixware gcc.c-torture/execute/arith-rand.c -O3 -fomit-frame-pointer -funroll-loops
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.6/4.5 Regression]: mmix- |[4.5/4.6 Regression]: mmix- |knuth-mmixware gcc.c- |knuth-mmixware gcc.c- |torture/execute/arith-rand.c|torture/execute/arith-rand.c |-O3 -fomit-frame-pointer - |-O3 -fomit-frame-pointer - |funroll-loops |funroll-loops Target Milestone|--- |4.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43889
[Bug fortran/42274] [fortran-dev Regression] ICE: segmentation fault
--- Comment #37 from pault at gcc dot gnu dot org 2010-04-26 10:57 --- I think that we can mark this as closed. Thanks, first to Salvatore for the report and second to Janus for the fix. Salvatore, to repeat Janus's request, could you please check that there are no further regressions, relative to trunk? I am aiming to synchronise the two trees later on this week. Thanks again for all the efforts 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=42274
[Bug tree-optimization/43833] false warning: array subscript is above array bounds with -O3
--- Comment #3 from jiez at gcc dot gnu dot org 2010-04-26 10:59 --- Subject: Bug 43833 Author: jiez Date: Mon Apr 26 10:59:34 2010 New Revision: 158727 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158727 Log: PR tree-optimization/43833 * tree-vrp.c (range_int_cst_p): New. (range_int_cst_singleton_p): New. (extract_range_from_binary_expr): Optimize BIT_AND_EXPR case when both operands are constants. Use range_int_cst_p in BIT_IOR_EXPR case. testsuite/ PR tree-optimization/43833 gcc.dg/Warray-bounds-8.c: New test case. Added: trunk/gcc/testsuite/gcc.dg/Warray-bounds-8.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43833
[Bug tree-optimization/43833] false warning: array subscript is above array bounds with -O3
--- Comment #4 from jiez at gcc dot gnu dot org 2010-04-26 11:00 --- Subject: Bug 43833 Author: jiez Date: Mon Apr 26 10:59:48 2010 New Revision: 158728 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158728 Log: PR tree-optimization/43833 * tree-vrp.c (range_int_cst_p): New. (range_int_cst_singleton_p): New. (extract_range_from_binary_expr): Optimize BIT_AND_EXPR case when both operands are constants. Use range_int_cst_p in BIT_IOR_EXPR case. testsuite/ PR tree-optimization/43833 gcc.dg/Warray-bounds-8.c: New test case. Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/Warray-bounds-8.c Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/testsuite/ChangeLog branches/gcc-4_5-branch/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43833
[Bug c++/43890] [4.6 Regression] invalid uninitialized reference in class
-- redi at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fabien dot chene at gmail |dot org |dot com Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-04-26 11:03:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43890
[Bug middle-end/43866] [4.3/4.4/4.5/4.6 Regression] wrong code with -fbounds-check -funswitch-loops
--- Comment #7 from jv244 at cam dot ac dot uk 2010-04-26 11:06 --- I have been trying to reduce more, but this is the smallest so far, seems like it needs the derived types, the 2D arrays, the pointers. I've reduced this with 4.5.1, using '-O2 -funswitch-loops' MODULE M1 IMPLICIT NONE TYPE cp_fm_type REAL(KIND=4), DIMENSION(:,:), POINTER :: local_data_sp REAL(KIND=8), DIMENSION(:,:), POINTER :: local_data END TYPE CONTAINS SUBROUTINE cp_fm_upper_to_full(matrix,nrow_global,ncol_global,use_sp) TYPE(cp_fm_type), POINTER :: matrix INTEGER, INTENT(IN) :: ncol_global, nrow_global INTEGER :: irow_global, icol_global LOGICAL :: use_sp REAL(KIND = 4), DIMENSION(:,:), POINTER :: a_sp REAL(KIND = 8), DIMENSION(:,:), POINTER :: a a = matrix%local_data a_sp = matrix%local_data_sp DO irow_global=1,nrow_global DO icol_global=irow_global+1,ncol_global IF(use_sp) THEN a_sp(icol_global,irow_global)=a_sp(irow_global,icol_global) ELSE a(icol_global,irow_global)=a(irow_global,icol_global) ENDIF ENDDO ENDDO END SUBROUTINE cp_fm_upper_to_full END MODULE M1 USE M1 TYPE(cp_fm_type), POINTER :: a INTEGER, PARAMETER :: N=17 ALLOCATE(a) ALLOCATE(a%local_data(N,N)) a%local_data=0 CALL cp_fm_upper_to_full(a,N,N,.FALSE.) END -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43866
[Bug lto/43218] [LTO] Conflicting function types cause ICE
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-04-26 11:22 --- Testcase #1 no longer fails on the branch or the trunk. Testcase #3 is a dup of PR43455, testcase #2 is related. I'll open a new clarified bug for #2. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43218
[Bug c++/38064] [c++0x] operator== doesn't work for enum classes
--- Comment #11 from redi at gcc dot gnu dot org 2010-04-26 11:23 ---
This is fixed for equality operators but not relational operators
enum class E { Foo, Bar };
bool b2 = E::Foo E::Bar;
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38064
[Bug lto/43891] New: ICE in expand_call_inline, at tree-inline.c:3820 with -fwhopr, missed fatal diagnostic
For
1.c
--
extern float f(void);
int main(void)
{
return f();
}
2.c
--
int f(void)
{
return 0;
}
we ICE when building with -O2 -fwhopr because we inline f() and the
return value compatibility check does not trigger there (see comment
in fixed PR43455).
When inlining we use a FLOAT_EXPR to convert the return value to
the expected (float) type - this is bogus in general. There are
two cases: if the ABI returns both types in the same way then
a VIEW_CONVERT_EXPR should be used to make inline vs. non-inline
behavior the same, if the ABI returns in different places then
the value returned is undefined.
We should try to emit a diagnostic here.
Runtime behavior of the non-LTO build should be preserved by not
inlining such calls also with -fwhopr.
--
Summary: ICE in expand_call_inline, at tree-inline.c:3820 with -
fwhopr, missed fatal diagnostic
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: lto
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43891
[Bug lto/43221] [LTO] ICE in get_alias_set, at alias.c:717
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-04-26 11:28 --- Confirmed. This is a type-merging issue. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|middle-end |lto Ever Confirmed|0 |1 GCC target triplet|i686-pc-linux-gnu |i?86-*-* x86_64-*-* Last reconfirmed|-00-00 00:00:00 |2010-04-26 11:28:54 date|| Summary|[LTO] ICE in get_alias_set |[LTO] ICE in get_alias_set, ||at alias.c:717 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43221
[Bug lto/43342] lto1: internal compiler error: failed to reclaim unneeded function
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-04-26 11:32 --- The problem no longer occurs. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43342
[Bug lto/43373] -fwhopr -fuse-linker-plugin ICE compressed stream data error
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-04-26 11:42 --- Confirmed. Huh. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-04-26 11:42:03 date|| Summary|whopr+linker plugin ICE |-fwhopr -fuse-linker-plugin |compressed stream data error|ICE compressed stream data ||error http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43373
[Bug lto/43786] ICE in lto_get_pickled_tree, at lto-streamer-in.c:2574
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-04-26 11:59 ---
b) has been fixed on the trunk.
a) is caused by using -fshort-double and LTO streamer interaction with
pre-recorded types and their merging. Testcase:
int main() { return 0; }
gcc-4.5 -o dc empty.c -flto -fshort-double
lto1: internal compiler error: in lto_get_pickled_tree, at
lto-streamer-in.c:2574
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords|lto |
Last reconfirmed|-00-00 00:00:00 |2010-04-26 11:59:43
date||
Summary|lto crash and/or infinite |ICE in lto_get_pickled_tree,
|loop|at lto-streamer-in.c:2574
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43786
[Bug bootstrap/43858] [4.6 Regression] Bootstrap failure for powerpc-apple-darwin9: cannot compute suffix of object files
--- Comment #7 from bernds at codesourcery dot com 2010-04-26 12:11 --- What happens if you replace the new call to df_simulate_find_noclobber_defs in ifcvt.c with a call to df_simulate_find_defs? If that fixes the bootstrap, can you find a testcase where this changes code generation? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43858
[Bug bootstrap/43858] [4.6 Regression] Bootstrap failure for powerpc-apple-darwin9: cannot compute suffix of object files
--- Comment #8 from dominiq at lps dot ens dot fr 2010-04-26 12:28 ---
What happens if you replace the new call to df_simulate_find_noclobber_defs in
ifcvt.c with a call to df_simulate_find_defs?
Bootstrapping with the change (crossing my finger that I won't have to remove
the definition of df_simulate_find_noclobber_defs!-). Allow for 3h30 to pass
the critical point and over 5h to complete the bootstrap.
If that fixes the bootstrap, can you find a testcase where this changes code
generation?
With the faulty cc1, the following trivial test ICE at -O1
int
main ()
{
;
return 0;
}
What would you need?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43858
[Bug target/43884] [4.4/4.5/4.6 Regression] Performance degradation for simple fibonacci numbers calculation due to extra stack alignment
--- Comment #9 from jakub at gcc dot gnu dot org 2010-04-26 12:40 --- In the leaf_function_p sense it is non-leaf. For the stack alignment it of course would be possible to change the stack alignment requirements of the function if it calls itself, doesn't call other functions (nor tail call them) and it is changed not to assume the standard alignment in the whole function. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43884
[Bug lto/43342] lto1: internal compiler error: failed to reclaim unneeded function
--- Comment #7 from hubicka at gcc dot gnu dot org 2010-04-26 12:41 --- -fwhopr and -flto are intended to be interchangeable at link time. So it does not matter with what flag you build the .o objects. The problem was fixed by the clone streaming fix I submitted last week. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43342
[Bug bootstrap/43858] [4.6 Regression] Bootstrap failure for powerpc-apple-darwin9: cannot compute suffix of object files
--- Comment #9 from bernds at codesourcery dot com 2010-04-26 12:56 --- One thing that would help would be to build just a stage1 compiler and target libraries, then run the testsuite. That might give us a smaller testcase to look at. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43858
[Bug bootstrap/43858] [4.6 Regression] Bootstrap failure for powerpc-apple-darwin9: cannot compute suffix of object files
--- Comment #10 from dominiq at lps dot ens dot fr 2010-04-26 13:15 --- Subject: Re: [4.6 Regression] Bootstrap failure for powerpc-apple-darwin9: cannot compute suffix of object files One thing that would help would be to build just a stage1 compiler and target libraries, then run the testsuite. Indeed I don't know how I could do that. I RTFM but did not find it. That might give us a smaller testcase to look at. Looking at the build process, it seems that the xgcc built at stage 1 is able to build xgcc at stage 2, the later being unable to compile the trivial test case. Note that prev-gcc/xgcc compiles the test at -O1 without ICE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43858
[Bug bootstrap/43858] [4.6 Regression] Bootstrap failure for powerpc-apple-darwin9: cannot compute suffix of object files
--- Comment #11 from bernds at codesourcery dot com 2010-04-26 13:19 --- (In reply to comment #10) Subject: Re: [4.6 Regression] Bootstrap failure for powerpc-apple-darwin9: cannot compute suffix of object files One thing that would help would be to build just a stage1 compiler and target libraries, then run the testsuite. Indeed I don't know how I could do that. I RTFM but did not find it. See http://gcc.gnu.org/wiki/Top-Level_Bootstrap I think Q3 is the one you need. Bernd -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43858
[Bug rtl-optimization/43892] New: PowerPC suboptimal add with carry optimization
PowerPC suboptimal add with carry optimization
Environment:
System: Linux gentoo-jocke 2.6.31-gentoo-r6 #1 SMP PREEMPT Sun Feb 28 22:54:53
CET 2010 i686 Intel(R) Core(TM)2 Duo CPU E8500 @ 3.16GHz GenuineIntel GNU/Linux
host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: /var/tmp/portage/sys-devel/gcc-4.3.4/work/gcc-4.3.4/configure
--prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.3.4
--includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.3.4
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.3.4/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.3.4/info
--with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4
--host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec
--disable-fixed-point --enable-nls --without-included-gettext
--with-system-zlib --disable-checking --disable-werror --enable-secureplt
--disable-multilib --enable-libmudflap --disable-libssp --enable-libgomp
--disable-libgcj --with-arch=i686 --enable-languages=c,c++,treelang,fortran
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/
--with-pkgversion='Gentoo 4.3.4 p1.0, pie-10.1.5'
How-To-Repeat:
Noticed that gcc 4.3.4 doesn't optimize add with carry properly:
static u32
add32carry(u32 sum, u32 x)
{
u32 z = sum + x;
if (sum + x x)
z++;
return z;
}
Becomes:
add32carry:
add 3,3,4
subfc 0,4,3
subfe 0,0,0
subfc 0,0,3
mr 3,0
Instead of:
addc 3,3,4
addze 3,3
This slows down the the Internet checksum sigificantly
Also, doing this in a loop can be further optimized:
for(;len; --len)
sum = add32carry(sum, *++buf);
addic 3, 3, 0 /* clear carry */
.L31:
lwzu 0,4(9)
adde 3, 3, 0 /* add with carry */
bdnz .L31
addze 3, 3 /* add in final carry */
--- Comment #1 from joakim dot tjernlund at transmode dot se 2010-04-26
13:33 ---
Fix:
None
--
Summary: PowerPC suboptimal add with carry optimization
Product: gcc
Version: 4.3.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joakim dot tjernlund at transmode dot se
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43892
[Bug rtl-optimization/43892] PowerPC suboptimal add with carry optimization
--- Comment #2 from jakub at gcc dot gnu dot org 2010-04-26 13:39 --- config/rs6000/rs6000.md would need to add a addmodecc expander and handle this, then if-conversion can do the rest of the work like it does on i?86. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43892
[Bug target/43884] [4.4/4.5/4.6 Regression] Performance degradation for simple fibonacci numbers calculation due to extra stack alignment
--- Comment #10 from hjl dot tools at gmail dot com 2010-04-26 13:44 --- (In reply to comment #9) In the leaf_function_p sense it is non-leaf. For the stack alignment it of course would be possible to change the stack alignment requirements of the function if it calls itself, doesn't call other functions (nor tail call them) and it is changed not to assume the standard alignment in the whole function. That is true. For tail call, we only need to align outgoing stack to minimum of maximum local stack alignment and incoming stack alignment. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43884
[Bug rtl-optimization/43892] PowerPC suboptimal add with carry optimization
--- Comment #3 from dje at gcc dot gnu dot org 2010-04-26 13:52 --- As Jakub mentioned, i386.md implements the addcc named pattern and rs6000.md does not provide that named pattern yet. -- dje at gcc dot gnu dot org changed: What|Removed |Added CC||dje at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC target triplet|i686-pc-linux-gnu |powerpc-*-* Last reconfirmed|-00-00 00:00:00 |2010-04-26 13:52:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43892
[Bug rtl-optimization/43892] PowerPC suboptimal add with carry optimization
-- dje at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43892
[Bug target/43884] [4.4/4.5/4.6 Regression] Performance degradation for simple fibonacci numbers calculation due to extra stack alignment
--- Comment #11 from jakub at gcc dot gnu dot org 2010-04-26 13:57 --- Tail call needs to consider incoming alignment requirements of the target function (which is often in other CU). In this case it is not a tail call, but non-tail recursion (tail-recursion would be handled by wrapping the function's body into a loop). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43884
[Bug rtl-optimization/43892] PowerPC suboptimal add with carry optimization
--- Comment #4 from joakim dot tjernlund at transmode dot se 2010-04-26 13:58 --- Subject: Re: PowerPC suboptimal add with carry optimization dje at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote on 2010/04/26 15:53:01: --- Comment #3 from dje at gcc dot gnu dot org 2010-04-26 13:52 --- As Jakub mentioned, i386.md implements the addcc named pattern and rs6000.md does not provide that named pattern yet. Will that also address the loop optimization? I don't think so. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43892
[Bug libgomp/43893] New: Error: Invalid controlling predicate with -fopenmp
templateuint32_t otherCOLS
MatrixROWS, otherCOLS, T operator* (const MatrixCOLS, otherCOLS, T o)
const throw()
{
MatrixROWS, otherCOLS, T res;
float sum;
uint32_t i, j, k;
116:#pragma omp parallel for private(i,j,k, sum)
117:for (i = 0; i ROWS; ++i)
118:{
for (j = 0; j otherCOLS; ++j)
{
sum = 0;
for (k = 0; k COLS; ++k)
{
sum += (*this)(i,k) * o(k,j);
}
res(i,j) = sum;
}
}
return res;
}
Trying to compile above function results in:
In file included from FWLSEPred.h:6,
from main.cpp:11:
Matrix.h: In member function MatrixROWS, otherCOLS, T MatrixROWS, COLS,
T::operator*(const MatrixCOLS, otherCOLS, T) const [with unsigned int
otherCOLS = 1u, unsigned int ROWS = 1u, unsigned int COLS = 100u, T = float]:
FWLSEPred.h:57: instantiated from void FWLSEPredORDER, T, C::pushSample(T)
[with int ORDER = 100, T = short int, int C = 2]
main.cpp:79: instantiated from here
Matrix.h:117: error: invalid controlling predicate
Compiled with:
g++ -o predictor -std=gnu++0x -fopenmp input cpp files...
Works and compiles fine without -fopenmp.
A possible problem is that in this specific instantiation of the template, ROWS
equals one and the parallel for pragma fails as there is nothing to
parallelize. But this case should be recognized and the code should compile
without parallelization and without errors.
--
Summary: Error: Invalid controlling predicate with -fopenmp
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: e0600347 at student dot tuwien dot ac dot at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43893
[Bug middle-end/43880] [4.5/4.6 Regression] internal compiler error: in make_decl_rtl
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-04-26 14:22 --- Ugh, this is slightly non-trivial. The C++ cloning does not properly clone DECL_VALUE_EXPR because we do not bother to do this from copy_body_r. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43880
[Bug c++/43894] New: with -std=c++0x, auto and for loop does not play nice when another variable is involved
#include iostream
#include map
int main()
{
std::mapint,int dummy;
for(int i=0;i5;i++) dummy[i*2] = (100-i);
#ifdef BUG
for(auto itr=dummy.begin(),int i=0;itr!=dummy.end();++itr,++i)
std::cout i: i std::endl;
#endif
#ifdef WORKAROUND
auto itr=dummy.begin();
for(int i=0;itr!=dummy.end();++itr,++i)
std::cout i: i std::endl;
#endif
return 0;
}
$ g++ -std=c++0x -DBUG -o auto.bug auto.bug.cpp
auto.bug.cpp: In function int main():
auto.bug.cpp:10:29: error: expected unqualified-id before int
auto.bug.cpp:10:62: error: name lookup of i changed for ISO for scoping
auto.bug.cpp:10:62: note: (if you use -fpermissive G++ will accept your code)
$ g++ -std=c++0x -DWORKAROUND -o auto.bug auto.bug.cpp
It should have worked the same in both the cases no?
--
Summary: with -std=c++0x, auto and for loop does not play nice
when another variable is involved
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ghodechhap at ghodechhap dot net
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=43894
[Bug target/43884] [4.4/4.5/4.6 Regression] Performance degradation for simple fibonacci numbers calculation due to extra stack alignment
--- Comment #12 from hubicka at ucw dot cz 2010-04-26 14:27 --- Subject: Re: [4.4/4.5/4.6 Regression] Performance degradation for simple fibonacci numbers calculation due to extra stack alignment That is true. For tail call, we only need to align outgoing stack to minimum of maximum local stack alignment and incoming stack alignment. Well, the tail call gets the same stack alignment as the function itself, so I guess when expanding a tail call, we need to bump up the incomming stack alignment to one needed by the call. We should special case the self recursion and do nothing in case of tail calls and in case of normal calls. In normal self recursive calls we need to remember the fact that function is self recursive and when finalizing be sure that outgoing stack alignment is at least as good as incomming. This can not be decided at expansion time since we do not know yet what alignment function has. Old preferred alignment code had this logic, I guess somehow this got broken during the merge of stack alignment branch? Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43884
[Bug fortran/43895] New: [fortran-dev] internal compiler error: verify_ssa failed
The attached code produces the subject message, but only with optimization; at -O0 it works. -- behaviour -- [sfili...@localhost bug14]$ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/home/local/gnudev/bin/../libexec/gcc/i686-pc-linux-gnu/4.6.0/lto-wrapper Target: i686-pc-linux-gnu Configured with: ../fortran-dev/configure --prefix=/usr/local/gnudev --enable-languages=c,c++,fortran : (reconfigured) ../fortran-dev/configure --prefix=/usr/local/gnudev --enable-languages=c,c++,fortran,lto --no-create --no-recursion : (reconfigured) ../fortran-dev/configure --prefix=/usr/local/gnudev --enable-languages=c,c++,fortran,lto --no-create --no-recursion : (reconfigured) ../fortran-dev/configure --prefix=/usr/local/gnudev --enable-languages=c,c++,fortran,lto --no-create --no-recursion : (reconfigured) ../fortran-dev/configure --prefix=/usr/local/gnudev --enable-languages=c,c++,fortran,lto --no-create --no-recursion : (reconfigured) ../fortran-dev/configure --prefix=/usr/local/gnudev --enable-languages=c,c++,fortran,lto --no-create --no-recursion : (reconfigured) ../fortran-dev/configure --prefix=/usr/local/gnudev --enable-languages=c,c++,fortran,lto --no-create --no-recursion Thread model: posix gcc version 4.6.0 20100421 (experimental) (GCC) [sfili...@localhost bug14]$ gfortran -O1 -c bug14.f90 bug14.f90: In function bug14: bug14.f90:30:0: error: statement makes a memory store, but has no VDEFS a_4.a.$data = 0B; bug14.f90:30:0: internal compiler error: verify_ssa failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. [sfili...@localhost bug14]$ gfortran -O0 -c bug14.f90 [sfili...@localhost bug14]$ -- Summary: [fortran-dev] internal compiler error: verify_ssa failed Product: gcc Version: fortran-dev Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sfilippone at uniroma2 dot it GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43895
[Bug libgomp/43893] Error: Invalid controlling predicate with -fopenmp
--- Comment #1 from jakub at gcc dot gnu dot org 2010-04-26 14:33 ---
This isn't self-contained testcase. Please either provide a preprocessed
source, or some small testcase that can be actually compiled. See
http://gcc.gnu.org/bugs.html for details.
templateint N void foo (void)
{
int i;
#pragma omp parallel for
for (i = 0; i N; i++)
;
}
void bar (void)
{
foo 1 ();
}
certainly compiles just fine with -fopenmp, so the precise details on what is
ROWS are needed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43893
[Bug fortran/43895] [fortran-dev] internal compiler error: verify_ssa failed
--- Comment #1 from sfilippone at uniroma2 dot it 2010-04-26 14:34 --- Created an attachment (id=20491) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20491action=view) test-case Funny thing: if I change the declaration type(d_sparse_mat) into class(d_sparse_mat) then it compiles. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43895
[Bug fortran/43895] [fortran-dev] internal compiler error: verify_ssa failed
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-04-26 14:38 --- smells like DECL_VALUE_EXPR -- rguenth at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet| i686-pc-linux-gnu |i686-pc-linux-gnu GCC host triplet| i686-pc-linux-gnu |i686-pc-linux-gnu GCC target triplet| i686-pc-linux-gnu |i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43895
[Bug rtl-optimization/43892] PowerPC suboptimal add with carry optimization
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-04-26 14:43 ---
(In reply to comment #4)
Subject: Re: PowerPC suboptimal add with carry optimization
dje at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote on 2010/04/26
15:53:01:
--- Comment #3 from dje at gcc dot gnu dot org 2010-04-26 13:52 ---
As Jakub mentioned, i386.md implements the addcc named pattern and rs6000.md
does not provide that named pattern yet.
Will that also address the loop optimization? I don't think so.
No.
Actually compilable testcase:
typedef unsigned int u32;
u32
add32carry(u32 sum, u32 x)
{
u32 z = sum + x;
if (sum + x x)
z++;
return z;
}
u32
loop(u32 *buf, int len)
{
u32 sum = 0;
for(; len; --len)
sum = add32carry(sum, *++buf);
return sum;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43892
[Bug target/43884] [4.4/4.5/4.6 Regression] Performance degradation for simple fibonacci numbers calculation due to extra stack alignment
--- Comment #13 from hjl dot tools at gmail dot com 2010-04-26 14:47 --- (In reply to comment #12) Subject: Re: [4.4/4.5/4.6 Regression] Performance degradation for simple fibonacci numbers calculation due to extra stack alignment That is true. For tail call, we only need to align outgoing stack to minimum of maximum local stack alignment and incoming stack alignment. Well, the tail call gets the same stack alignment as the function itself, so I guess when expanding a tail call, we need to bump up the incomming stack alignment to one needed by the call. We should special case the self recursion and do nothing in case of tail calls and in case of normal calls. In normal self recursive calls we need to remember the fact that function is self recursive and when finalizing be sure that outgoing stack alignment is at least as good as incomming. The outgoing stack alignment should be the minimum of incoming and local. If incoming stack is 16byte aligned and local variable only needs 4byte alignment, there is no difference in stack realignment when incoming stack is 4byte, 8byte and 16byte aligned. This can not be decided at expansion time since we do not know yet what alignment function has. Old preferred alignment code had this logic, I guess somehow this got broken during the merge of stack alignment branch? I will investigate. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43884
[Bug target/43729] Mach-O LTO support needed for darwin
--- Comment #8 from mrs at gcc dot gnu dot org 2010-04-26 14:49 --- One open question for me would be, are 16 bytes of an arbitrary named section/segment enough? It you carve out a slice, say lto_%d, that leaves just 12 bytes for the `name', if this big enough? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43729
[Bug fortran/43895] [fortran-dev] internal compiler error: verify_ssa failed
--- Comment #3 from janus at gcc dot gnu dot org 2010-04-26 14:56 --- Note: There is another OOP PR which fails only with optimization: PR41753. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43895
[Bug fortran/43895] [OOP] internal compiler error: verify_ssa failed
--- Comment #4 from janus at gcc dot gnu dot org 2010-04-26 15:04 --- Confirmed. It seems this fails already with the 4.5 release as well as with current trunk, which means that it's not specific to the fortran-dev branch. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-04-26 15:04:01 date|| Summary|[fortran-dev] internal |[OOP] internal compiler |compiler error: verify_ssa |error: verify_ssa failed |failed | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43895
[Bug c++/43894] with -std=c++0x, auto and for loop does not play nice when another variable is involved
--- Comment #1 from redi at gcc dot gnu dot org 2010-04-26 15:13 --- I don't think this is valid, it's equivalent to typedef std::mapint,int::iterator Iter; for (Iter itr = dummy.begin(), int i=0; i5; i++) which is invalid because you cannot declare two different types in a for-init-statement -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43894
[Bug libgomp/43893] Error: Invalid controlling predicate with -fopenmp
--- Comment #2 from e0600347 at student dot tuwien dot ac dot at 2010-04-26 15:17 --- Created an attachment (id=20492) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20492action=view) Preprocessed testcase source Compiled with: g++ -std=gnu++0x -fopenmp -save-temps -o test testcase.cpp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43893
[Bug rtl-optimization/43892] PowerPC suboptimal add with carry optimization
--- Comment #6 from joakim dot tjernlund at transmode dot se 2010-04-26 15:18 --- Subject: Re: PowerPC suboptimal add with carry optimization rguenth at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote on 2010/04/26 16:43:04: Will that also address the loop optimization? I don't think so. No. OK, would be nice if the loop case could be fixed too. Just noticed this too: add32carry: add 3,3,4 subfc 0,4,3 subfe 0,0,0 subfc 0,0,3 mr 3,0 That could have been better even without add with carry optimization: add32carry: add 3,3,4 subfc 0,4,3 subfe 0,0,0 subfc 3,0,3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43892
[Bug libgomp/43893] Error: Invalid controlling predicate with -fopenmp
--- Comment #3 from e0600347 at student dot tuwien dot ac dot at 2010-04-26 15:22 --- Exact error message with testcase: testcase.cpp: In member function MatrixROWS, otherCOLS, T MatrixROWS, COLS, T::operator*(const MatrixCOLS, otherCOLS, T) const [with unsigned int otherCOLS = 1u, unsigned int ROWS = 1u, unsigned int COLS = 1u, T = float]: testcase.cpp:72: instantiated from here testcase.cpp:52: error: invalid controlling predicate If the Matrix declaration in main() (Matrix1, 1, float) is replaced by 2x2 matrices (Matrix2, 2, float), then no error. Neither without -fopenmp. -- e0600347 at student dot tuwien dot ac dot at changed: What|Removed |Added GCC host triplet||x86_64 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43893
[Bug fortran/43895] [OOP] internal compiler error: verify_ssa failed
--- Comment #5 from sfilippone at uniroma2 dot it 2010-04-26 15:32 --- (In reply to comment #0) The attached code produces the subject message, but only with optimization; at -O0 it works. -- behaviour -- [sfili...@localhost bug14]$ gfortran -O1 -c bug14.f90 bug14.f90: In function bug14: bug14.f90:30:0: error: statement makes a memory store, but has no VDEFS a_4.a.$data = 0B; bug14.f90:30:0: internal compiler error: verify_ssa failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Fails at -O2 and -O3 as well.. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43895
[Bug fortran/43896] New: Compiler internal error
/opt/gfortran/bin/gfortran -c m_rotation_matrix.f03 m_vector.f03 m_vector.f03: In function rotation_matrix_times_vector: m_vector.f03:382:0: internal compiler error: in gfc_conv_variable, at fortran/trans-expr.c:551 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- Summary: Compiler internal error Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fmartinez at gmv dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43896
[Bug fortran/43896] Compiler internal error
--- Comment #1 from fmartinez at gmv dot com 2010-04-26 15:35 --- Created an attachment (id=20493) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20493action=view) Just a module, with a type and associated methods. Needed by the one causing the error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43896
[Bug fortran/43896] Compiler internal error
--- Comment #2 from fmartinez at gmv dot com 2010-04-26 15:36 --- Created an attachment (id=20494) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20494action=view) The file causing the error during compilation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43896
[Bug middle-end/43760] [4.6 regression] New test failures
--- Comment #5 from wilson at gcc dot gnu dot org 2010-04-26 15:46 --- Created an attachment (id=20495) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20495action=view) initial patch This patch fixes gcc.c-torture/compile/920625-1.c, but unfortunately doesn't fix any of the 3 failures reported in this PR. I will have to revise it and try again. I also noticed that we had support for an obsolete assembler errata warning, and removed that too in this patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43760
[Bug target/43897] New: IA-64 asm clobbers are ignored
I noticed this while looking at dependency violations that occur during a gcc
bootstrap. We get two in the libgcc build, both are due to the same problem.
Here is a testcase extracted from libgcc/soft-float/fixunstfti.c.
int
sub (int i)
{
float tmp;
if (i)
__asm__ __volatile__ (frcpa.s0 %0,p1=f0,f0\
: =f (tmp) : : p1 ); \
return i + 10;
}
Compiling this with -O2 gives a DV error because there is a missing stop bit
after the asm. The assembler code has
#APP
// 6 tmp.c 1
frcpa.s0 f6,p1=f0,f0
// 0 2
#NO_APP
.L2:
.mib
adds r8 = 10, r32
mov pr = r2, -1
br.ret.sptk.many b0
The problem is in rtx_needs_barrier in config/ia64/ia64.c, which has
case CLOBBER:
case USE:
/* Clobber use are for earlier compiler-phases only. */
break;
I think this was written in the olden days when we still had reg-no-conflict
blocks and libcall blocks and other stuff that would insert naked clobbers into
the rtl stream. These should be ignored, but I don't think that they will
occur anymore. However, it isn't safe to ignore a clobber inside a parallel,
particularly when that parallel is for an extended asm. This is a serious
problem that needs to be fixed.
The problem can be worked around by using -mvolatile-asm-stop, but this
obviously only works for volatile asms.
--
Summary: IA-64 asm clobbers are ignored
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wilson at gcc dot gnu dot org
GCC target triplet: ia64-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43897
[Bug target/43729] Mach-O LTO support needed for darwin
--- Comment #9 from stevenb dot gcc at gmail dot com 2010-04-26 16:06 --- Subject: Re: Mach-O LTO support needed for darwin Mach-O section names are too short, but I have solved this with a separate section with section names in a strings table. This is similar to the solution from lto-coff. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43729
[Bug bootstrap/43858] [4.6 Regression] Bootstrap failure for powerpc-apple-darwin9: cannot compute suffix of object files
--- Comment #12 from dominiq at lps dot ens dot fr 2010-04-26 16:24 --- What happens if you replace the new call to df_simulate_find_noclobber_defs in ifcvt.c with a call to df_simulate_find_defs? Bootstrapping with the change (crossing my finger that I won't have to remove the definition of df_simulate_find_noclobber_defs!-). Allow for 3h30 to pass the critical point and over 5h to complete the bootstrap. I am now at stage 3, so replacing df_simulate_find_noclobber_defs with df_simulate_find_defs seems to fix the bootstrap issue. See http://gcc.gnu.org/wiki/Top-Level_Bootstrap I think Q3 is the one you need. Thanks for the pointer. I'll try it after the build has completed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43858
[Bug c++/43894] with -std=c++0x, auto and for loop does not play nice when another variable is involved
--- Comment #2 from redi at gcc dot gnu dot org 2010-04-26 16:34 --- as stated above -- redi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43894
[Bug c++/43734] cerr related segmentation fault
--- Comment #4 from paul dot shaklan at solipsys dot com 2010-04-26 16:56 --- Exactly the same results with libfoo.so is built with fPIC -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43734
[Bug c/43893] Error: Invalid controlling predicate with -fopenmp
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|WAITING |ASSIGNED Component|libgomp |c Ever Confirmed|0 |1 Keywords||openmp Last reconfirmed|-00-00 00:00:00 |2010-04-26 17:10:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43893
[Bug target/43897] IA-64 asm clobbers are ignored
-- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2010-04-26 17:15:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43897
[Bug target/43897] [4.4/4.5 Regression] IA-64 asm clobbers are ignored
--- Comment #1 from steven at gcc dot gnu dot org 2010-04-26 17:21 --- Regression from GCC 4.3, which still had libcall notes. --- t.s.434 2010-04-26 10:21:18.0 -0700 +++ t.s.442 2010-04-26 10:21:36.0 -0700 @@ -2,6 +2,7 @@ .pred.safe_across_calls p1-p5,p16-p63 .text .align 16 + .align 64 .global sub# .type sub#, @function .proc sub# @@ -12,22 +13,22 @@ .save pr, r2 mov r2 = pr .body - nop 0 - .mmb cmp4.eq p6, p7 = 0, r32 + .mmb + nop 0 nop 0 (p6) br.cond.dpnt .L2 + ;; #APP // 6 t.c 1 frcpa.s0 f6,p1=f0,f0 // 0 2 #NO_APP - ;; .L2: .mib adds r8 = 10, r32 mov pr = r2, -1 br.ret.sptk.many b0 .endp sub# - .ident GCC: (Debian 4.3.4-6) 4.3.4 + .ident GCC: (Debian 4.4.2-9) 4.4.3 20100108 (prerelease) .section.note.GNU-stack,,@progbits -- steven at gcc dot gnu dot org changed: What|Removed |Added Summary|IA-64 asm clobbers are |[4.4/4.5 Regression] IA-64 |ignored |asm clobbers are ignored Target Milestone|--- |4.4.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43897
[Bug fortran/43896] [OOP] ICE in gfc_conv_variable, at fortran/trans-expr.c:551
--- Comment #3 from janus at gcc dot gnu dot org 2010-04-26 17:33 --- Confirmed. The ICE happens with 4.5, trunk and fortran-dev. Thanks for the report! -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2010-04-26 17:33:45 date|| Summary|Compiler internal error |[OOP] ICE in ||gfc_conv_variable, at ||fortran/trans-expr.c:551 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43896
[Bug fortran/43896] [OOP] ICE in gfc_conv_variable, at fortran/trans-expr.c:551
--- Comment #4 from burnus at gcc dot gnu dot org 2010-04-26 17:38 ---
Confirmed with 4.5.0 and 4.6.0.
At least NAG f95 thinks that the current code is invalid; it writes for the
second file:
Error: m_vector.f03, line 394: Reference via operator * to impure
ROTATION_MATRIX_TIMES_VECTOR from pure ROTATION_MATRIX_TIMES_VECTOR
which is in the following line:
! Compute result
res%x = rot * right%x
* * *
The assert fails at gfc_conv_variable for:
sym = expr-symtree-n.sym;
if (se-ss != NULL)
{
/* Check that something hasn't gone horribly wrong. */
gcc_assert (se-ss != gfc_ss_terminator);
gcc_assert (se-ss-expr == expr); ICE
* * *
My old 4.6.0 20100421 fortran-dev revision 158628 fails with another ICE:
ICE in gfc_build_null_descriptor, at fortran/trans-array.c:373
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-on-invalid-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43896
[Bug c/43893] Error: Invalid controlling predicate with -fopenmp
--- Comment #4 from jakub at gcc dot gnu dot org 2010-04-26 17:39 --- Created an attachment (id=20496) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20496action=view) gcc46-pr43893.patch Fix I'm going to test. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43893
[Bug lto/43898] New: -flto -g: tree check: expected class 'type', have 'declaration'
With -flto -g, the following source will bail out with an internal compiler
error:
void bug() {
struct Class {
Class(int a) {}
virtual void f() {}
};
Class a(0);
}
Command line: g++-4.5 -g -flto bug.cxx
Error message:
bug.cxx: In member function 'bug()::Class::f()':
bug.cxx:4:23: internal compiler error: tree check: expected class 'type', have
'declaration' (function_decl) in gen_type_die_with_usage, at dwarf2out.c:18962
Please submit a full bug report,
with preprocessed source if appropriate.
See file:///usr/share/doc/gcc-4.5/README.Bugs for instructions.
Compiler version: gcc version 4.5.1 20100419 (prerelease) (Debian 4.5.0-2)
--
Summary: -flto -g: tree check: expected class 'type', have
'declaration'
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: max at duempel dot org
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43898
[Bug c++/38064] [c++0x] operator== doesn't work for enum classes
--- Comment #12 from pinskia at gcc dot gnu dot org 2010-04-26 17:50
---
(In reply to comment #11)
This is fixed for equality operators but not relational operators
enum class E { Foo, Bar };
bool b2 = E::Foo E::Bar;
Is that even allowed for normal enums?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38064
[Bug ada/34598] Assert_Failure at atree.adb:886
--- Comment #5 from ve3wwg at gmail dot com 2010-04-26 17:51 --- I've also encountered this bug today, under 4.3.4: gnatmake -g -O0 -fno-tree-sra -gnat05 -Wall -gnatwl -gnata -gnatVa -gnatf -gnatwr z9.adb gcc -c -g -O0 -fno-tree-sra -gnat05 -Wall -gnatwl -gnata -gnatVa -gnatf -gnatwr z9-programs.adb +===GNAT BUG DETECTED==+ | 4.3.4 20090804 (release) 1 (i686-pc-cygwin) Assert_Failure atree.adb:886 | | Error detected at z9-programs.adb:245:69 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ -- ve3wwg at gmail dot com changed: What|Removed |Added CC||ve3wwg at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34598
[Bug c++/43890] [4.6 Regression] invalid uninitialized reference in class
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia 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| Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43890
[Bug fortran/43899] New: Wrong unused-variable warning with NAMELISTs
Found at http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/4e34a377097524f2 gfortran gives a -Wall warning for a variable which is only used via namelists: character(4) :: nml_string 1 Warning: Unused variable 'nml_string' declared at (1) For: character(4) :: nml_string namelist /nmlist/ nml_string read(7,nml=nmlist) write(*,nml=nmlist) end -- Summary: Wrong unused-variable warning with NAMELISTs Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43899
[Bug bootstrap/43900] New: ICE ind dbxout.c
I get an ICE in dbxout.c building a cross compiler from i686-pc-mingw32 to i686-w64-mingw32. i686-pc-mingw32-gcc -c -g -O2 -D__USE_MINGW_ACCESS -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -Wc++-compat -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I. -I../../../../../../../src/gcc-4.4.4/gcc -I../../../../../../../src/gcc-4.4.4/gcc/. -I../../../../../../../src/gcc-4.4.4/gcc/../include -I./../intl -I../../../../../../../src/gcc-4.4.4/gcc/../libcpp/include -I/mingw/i686-pc/i686-pc/i686-pc/gcc-4.4.4/mingw/include -I/mingw/i686-pc/i686-pc/i686-pc/gcc-4.4.4/mingw/include -I../../../../../../../src/gcc-4.4.4/gcc/../libdecnumber -I../../../../../../../src/gcc-4.4.4/gcc/../libdecnumber/dpd -I../libdecnumber -I/mingw/i686-pc/i686-pc/i686-pc/gcc-4.4.4/mingw/include -I/mingw/i686-pc/i686-pc/i686-pc/gcc-4.4.4/mingw/include -DCLOOG_PPL_BACKEND ../../../../../../../src/gcc-4.4.4/gcc/dbxout.c -o dbxout.o ../../../../../../../src/gcc-4.4.4/gcc/dbxout.c: In function 'dbxout_symbol': ../../../../../../../src/gcc-4.4.4/gcc/dbxout.c:2491: 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. make[2]: *** [dbxout.o] Error 1 Rainer -- Summary: ICE ind dbxout.c Product: gcc Version: 4.4.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rainer at emrich-ebersheim dot de GCC build triplet: i686-pc-mingw32 GCC host triplet: i686-w64-mingw32 GCC target triplet: i686-w64-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43900
[Bug bootstrap/43900] ICE in dbxout.c
--- Comment #1 from rainer at emrich-ebersheim dot de 2010-04-26 18:27 --- I'm still analyzing, what's going wrong here, it's a strange thing. I tried the build three times with a parallel make resulting in the above ICE. But can't reproduce it by compiling dbxout.c on the command line. Investigating Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43900
[Bug target/43729] Mach-O LTO support needed for darwin
--- Comment #10 from davek at gcc dot gnu dot org 2010-04-26 18:39 --- (In reply to comment #1) I don't speak Mach-O, but yes, the approach should work. You'd start by saying lto_binary_reader=lto-mach-o in config.gcc and adding a new lto/lto-mach-o.c with the same handful of toplevel functions: open and close file, build section hash, and create section and append binary data to section. Oh, and the one last thing I forgot to mention: update is_elf_or_coff() in collect2.c so it recognizes Mach-O object files as well as ELF/COFF. (That may be evident by now anyway, but I thought I'd leave it here for the record anyway.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43729
[Bug target/43884] [4.4/4.5/4.6 Regression] Performance degradation for simple fibonacci numbers calculation
--- Comment #14 from hjl dot tools at gmail dot com 2010-04-26 18:54 --- It is caused by revision 131576: http://gcc.gnu.org/ml/gcc-cvs/2008-01/msg00337.html -- hjl dot tools at gmail dot com changed: What|Removed |Added Summary|[4.4/4.5/4.6 Regression]|[4.4/4.5/4.6 Regression] |Performance degradation for |Performance degradation for |simple fibonacci numbers|simple fibonacci numbers |calculation due to extra|calculation |stack alignment | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43884
[Bug fortran/43899] Wrong unused-variable warning with NAMELISTs
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2010-04-26 19:05 --- Well in a sense it is unused. Regardless, adding a warning for the truncated string, the real issue, is straightforward and I will do so. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-04-26 19:05:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43899
[Bug fortran/43896] [fortran-dev Regression] ICE in gfc_conv_variable, at fortran/trans-expr.c:551
--- Comment #5 from janus at gcc dot gnu dot org 2010-04-26 19:10 --- (In reply to comment #3) The ICE happens with 4.5, trunk and fortran-dev. Actually this is only half-true. With fortran-dev one already gets an ICE on the first file, which is different from the one reported in comment #0: gfortran-dev -c m_rotation_matrix.f03 f951: internal compiler error: in gfc_build_null_descriptor, at fortran/trans-array.c:373 So obviously this is a fortran-dev regression. -- janus at gcc dot gnu dot org changed: What|Removed |Added Keywords|ice-on-invalid-code | Summary|[OOP] ICE in|[fortran-dev Regression] ICE |gfc_conv_variable, at |in gfc_conv_variable, at |fortran/trans-expr.c:551|fortran/trans-expr.c:551 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43896
[Bug middle-end/43901] New: [4.6 Regression] FAIL: gcc.c-torture/compile/pr42196-2.c
On Linux/ia32, revision 158720 gave FAIL: gcc.c-torture/compile/pr42196-2.c -O3 -fomit-frame-pointer (internal compiler error) FAIL: gcc.c-torture/compile/pr42196-2.c -O3 -fomit-frame-pointer (test for excess errors) FAIL: gcc.c-torture/compile/pr42196-2.c -O3 -g (internal compiler error) FAIL: gcc.c-torture/compile/pr42196-2.c -O3 -g (test for excess errors) Revision 158713 is OK. Revision 158719: http://gcc.gnu.org/ml/gcc-cvs/2010-04/msg00826.html may be the cause. -- Summary: [4.6 Regression] FAIL: gcc.c-torture/compile/pr42196-2.c Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43901
[Bug fortran/43896] [fortran-dev Regression] ICE in gfc_conv_variable, at fortran/trans-expr.c:551
--- Comment #6 from janus at gcc dot gnu dot org 2010-04-26 19:33 --- Here is a reduced test case for the fortran-dev failure, which turns out to be pretty trivial. All it takes is an array-valued TBP (wonder if we don't have such a thing in the testsuite already): module m_rotation_matrix type t_rotation_matrix contains procedure :: array = rotation_matrix_array end type contains function rotation_matrix_array( rot ) result(array) class(t_rotation_matrix) :: rot double precision, dimension(3,3):: array end function end module -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43896
[Bug bootstrap/43900] ICE in dbxout.c
--- Comment #2 from rainer at emrich-ebersheim dot de 2010-04-26 19:53 --- As it turns out, the ICE only manifests in a parallel build. I tried make -j 8, my default and make -j 3. For an ordinary make there is no issue. So, I'm curious how to handle this. Any thoughts? Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43900
[Bug c/43893] Error: Invalid controlling predicate with -fopenmp
--- Comment #5 from jakub at gcc dot gnu dot org 2010-04-26 20:07 --- Subject: Bug 43893 Author: jakub Date: Mon Apr 26 20:07:10 2010 New Revision: 158745 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158745 Log: PR c/43893 * c-omp.c (c_finish_omp_for): Handle also EQ_EXPR. * testsuite/libgomp.c/pr43893.c: New test. * testsuite/libgomp.c++/pr43893.C: New test. Added: trunk/libgomp/testsuite/libgomp.c++/pr43893.C trunk/libgomp/testsuite/libgomp.c/pr43893.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-omp.c trunk/libgomp/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43893
[Bug target/43902] New: suboptimal MIPS widening multiply accumulate
This testcase
int array1[100], array2[100];
long long
sub (int max)
{
int k;
long long total = 0;
for (k = 0; k max; k++)
total += (long long)array1[k] * (long long)array2[k];
return total;
}
Generates a macc instruction with gcc-3.4.5 when compiled with -O2
-march=sr71000 -mabi=32 -mgp32. This does not generate a macc instruction with
gcc-4.0.0. The difference is that the 32-bit adddi3 pattern was deleted in
between gcc-3.4.5 and gcc-4.0.0. So gcc-3.4.5 generates a 2 insn rtl sequence
which is trivial to combine into a multiply-add insn. But gcc-4.0.0 generates
a 5 insn rtl sequence which will not be combined.
I noticed this on mainline because I should be able to generate widening
multiply-accumulate instructions (madd) with a mipsisa32r2 target with the same
testcase, but I can't.
--
Summary: suboptimal MIPS widening multiply accumulate
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wilson at gcc dot gnu dot org
GCC target triplet: mips*-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43902
[Bug c/43893] Error: Invalid controlling predicate with -fopenmp
--- Comment #6 from jakub at gcc dot gnu dot org 2010-04-26 20:11 --- Subject: Bug 43893 Author: jakub Date: Mon Apr 26 20:11:01 2010 New Revision: 158746 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158746 Log: PR c/43893 * c-omp.c (c_finish_omp_for): Handle also EQ_EXPR. * testsuite/libgomp.c/pr43893.c: New test. * testsuite/libgomp.c++/pr43893.C: New test. Added: branches/gcc-4_5-branch/libgomp/testsuite/libgomp.c++/pr43893.C branches/gcc-4_5-branch/libgomp/testsuite/libgomp.c/pr43893.c Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/c-omp.c branches/gcc-4_5-branch/libgomp/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43893
[Bug fortran/43899] Wrong unused-variable warning with NAMELISTs
--- Comment #2 from burnus at gcc dot gnu dot org 2010-04-26 20:16 --- (In reply to comment #1) Well in a sense it is unused. Well, but only in a sense - in the example a value is assigned to and then printed ... Regardless, adding a warning for the truncated string, the real issue, is straightforward and I will do so. It might be straight forward, but it needs to be guarded by a special option as it is 100% valid code. I think printing a run-time warning by default is wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43899
[Bug bootstrap/43715] configure option --enable-plugin fails on darwin
--- Comment #7 from mrs at gcc dot gnu dot org 2010-04-26 20:34 --- Subject: Bug 43715 Author: mrs Date: Mon Apr 26 20:33:49 2010 New Revision: 158747 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158747 Log: 2010-04-21 Jack Howarth howa...@bromo.med.uc.edu PR 43715 * testsuite/lib/plugin-support.exp: Use -undefined dynamic_lookup on darwin. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/lib/plugin-support.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43715
[Bug fortran/43896] [fortran-dev Regression] ICE in gfc_conv_variable, at fortran/trans-expr.c:551
--- Comment #7 from fmartinez at gmv dot com 2010-04-26 20:34 ---
Actually both ROTATION_MATRIX_TIMES_VECTOR are pure; the one in m_vector is
elemental, therefore pure, and the one in m_rotation_matrix is pure.
I have changed the one in m_rotation_matrix to ROTATION_MATRIX_TIMES_ARRAY to
remove the names collision and the ICE remains (I guess as expected)
I am a bit surprised about the NAG compiler behaviour.
Confirmed with 4.5.0 and 4.6.0.
At least NAG f95 thinks that the current code is invalid; it writes for the
second file:
Error: m_vector.f03, line 394: Reference via operator * to impure
ROTATION_MATRIX_TIMES_VECTOR from pure ROTATION_MATRIX_TIMES_VECTOR
which is in the following line:
! Compute result
res%x = rot * right%x
* * *
The assert fails at gfc_conv_variable for:
sym = expr-symtree-n.sym;
if (se-ss != NULL)
{
/* Check that something hasn't gone horribly wrong. */
gcc_assert (se-ss != gfc_ss_terminator);
gcc_assert (se-ss-expr == expr); ICE
* * *
My old 4.6.0 20100421 fortran-dev revision 158628 fails with another ICE:
ICE in gfc_build_null_descriptor, at fortran/trans-array.c:373
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43896
[Bug fortran/43896] [fortran-dev Regression] ICE in gfc_conv_variable, at fortran/trans-expr.c:551
--- Comment #8 from janus at gcc dot gnu dot org 2010-04-26 20:40 --- Ok, here is a preliminary patch which fixes the fortran-dev problem: Index: gcc/fortran/symbol.c === --- gcc/fortran/symbol.c(revision 158741) +++ gcc/fortran/symbol.c(working copy) @@ -4831,8 +4831,7 @@ add_proc_component (gfc_component *c, gfc_symbol * /* A static initializer cannot be used here because the specific function is not a constant; internal compiler error: in output_constant, at varasm.c:4623 */ - c-initializer = gfc_get_expr (); - c-initializer-expr_type = EXPR_NULL; + c-initializer = NULL; } @@ -4944,8 +4943,7 @@ copy_vtab_proc_comps (gfc_symbol *declared, gfc_sy c-ts.u.derived = cmp-ts.u.derived; c-attr.flavor = FL_VARIABLE; c-attr.pointer = 1; - c-initializer = gfc_get_expr (); - c-initializer-expr_type = EXPR_NULL; + c-initializer = NULL; continue; } @@ -4959,8 +4957,7 @@ copy_vtab_proc_comps (gfc_symbol *declared, gfc_sy c-ts.interface = cmp-ts.interface; c-attr.untyped = 1; c-attr.if_source = IFSRC_IFBODY; - c-initializer = gfc_get_expr (); - c-initializer-expr_type = EXPR_NULL; + c-initializer = NULL; } } Will regtest now. -- janus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-04-26 17:33:45 |2010-04-26 20:40:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43896
[Bug bootstrap/43715] configure option --enable-plugin fails on darwin
--- Comment #8 from mrs at gcc dot gnu dot org 2010-04-26 20:48 --- Subject: Bug 43715 Author: mrs Date: Mon Apr 26 20:48:35 2010 New Revision: 158748 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158748 Log: 2010-04-26 Jack Howarth howa...@bromo.med.uc.edu PR 43715 * gcc/configure.ac: Use $gcc_cv_nm -g on darwin instead of $gcc_cv_objdump -T. Use -undefined dynamic_lookup on darwin. Modified: trunk/gcc/ChangeLog trunk/gcc/configure trunk/gcc/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43715
[Bug bootstrap/43715] configure option --enable-plugin fails on darwin
--- Comment #9 from mrs at gcc dot gnu dot org 2010-04-26 20:55 --- Trunk fixed, leaving open for 4.5.1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43715
[Bug bootstrap/43715] configure option --enable-plugin fails on darwin
-- mrs at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43715
