[Bug target/54009] New: incorrect code generated for DFmode lo_sum mem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54009
Bug #: 54009
Summary: incorrect code generated for DFmode lo_sum mem
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: amo...@gmail.com
/* -O2 -m32 store to x.d in w uses
lis 9,x+32764@ha
stw 10,x+32764@l(9)
stw 11,x+32768@l(9) -- wrap! */
struct big {
char a[32764];
double d __attribute__ ((aligned (4)));
} __attribute__ ((packed));
extern struct big x;
double y;
void r (void)
{
double tmp = x.d;
#if 1
asm (#: +r (tmp)
: : fr0, fr1, fr2, fr3, fr4, fr5, fr6, fr7,
fr8, fr9, fr10, fr11, fr12, fr13, fr14, fr15,
fr16, fr17, fr18, fr19, fr20, fr21, fr22, fr23,
fr24, fr25, fr26, fr27, fr28, fr29, fr30, fr31);
#endif
y = tmp;
}
void w (void)
{
double tmp = y;
#if 1
asm (#: +r (tmp)
: : fr0, fr1, fr2, fr3, fr4, fr5, fr6, fr7,
fr8, fr9, fr10, fr11, fr12, fr13, fr14, fr15,
fr16, fr17, fr18, fr19, fr20, fr21, fr22, fr23,
fr24, fr25, fr26, fr27, fr28, fr29, fr30, fr31);
#endif
x.d = tmp;
}
[Bug target/54009] incorrect code generated for DFmode lo_sum mem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54009 Alan Modra amodra at gmail dot com changed: What|Removed |Added Target||powerpc-linux Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-07-18 AssignedTo|unassigned at gcc dot |amodra at gmail dot com |gnu.org | Ever Confirmed|0 |1
[Bug c++/54002] [C++0x][constexpr] Initializing constexpr static member using constexpr static method fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54002 --- Comment #3 from Martin von Gagern Martin.vGagern at gmx dot net 2012-07-18 07:09:02 UTC --- (In reply to comment #2) See PR 52366, which makes this a dup of PR 52315 I agree that this is a duplicate of PR 52366. And although I'm still not convinced that this is really the same requirement as the one in PR 52315, I'm inclined to believe it nevertheless. Should PR 52366 be un-duped, like PR 52366 comment 4 requested out, then this here should still be duped to PR 52366 instead of PR 52315, so I suggest duping it there in the first place.
[Bug target/33135] [SH] -ffinite-math-only should not be on by default
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33135 --- Comment #6 from Oleg Endo olegendo at gcc dot gnu.org 2012-07-18 07:49:56 UTC --- Author: olegendo Date: Wed Jul 18 07:49:50 2012 New Revision: 189602 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189602 Log: PR target/33135 * config/sh/sh.opt (mieee): Use Var instead of Mask. Correct description. * config/sh/sh.c (sh_option_override): Do not change flag_finite_math_only. Set TARGET_IEEE to complement of flag_finite_math_only. * doc/invoke.texi (SH options): Add mno-ieee. Correct description of mieee and mno-ieee behavior. PR target/33135 * gcc.target/sh/pr33135-1.c: New. * gcc.target/sh/pr33135-2.c: New. * gcc.target/sh/pr33135-3.c: New. * gcc.target/sh/pr33135-4.c: New. Added: trunk/gcc/testsuite/gcc.target/sh/pr33135-1.c trunk/gcc/testsuite/gcc.target/sh/pr33135-2.c trunk/gcc/testsuite/gcc.target/sh/pr33135-3.c trunk/gcc/testsuite/gcc.target/sh/pr33135-4.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh.c trunk/gcc/config/sh/sh.opt trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/ChangeLog
[Bug target/38621] [4.6/4.7/4.8 Regression] sh gcc unable to spill register when building ghostscript-gpl with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38621 --- Comment #12 from Oleg Endo olegendo at gcc dot gnu.org 2012-07-18 07:57:07 UTC --- Author: olegendo Date: Wed Jul 18 07:56:57 2012 New Revision: 189605 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189605 Log: PR target/38621 * gcc.c-torture/compile/pr38621.c: New. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr38621.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug ada/54010] New: Sockets: C_Recv should restart the call on EINTR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54010 Bug #: 54010 Summary: Sockets: C_Recv should restart the call on EINTR Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassig...@gcc.gnu.org ReportedBy: baldr...@gcc.gnu.org If an Ada task receives a signal while blocked in a call to C_Recv, for example called from Receive_Socket, then a SOCKET_ERROR exception is raised with message [4] Interrupted system call. Instead I think C_Recv should just loop around and restart the system call when it sees EINTR, rather than exiting with an error like it does now: function C_Recv (S : C.int; Msg : System.Address; Len : C.int; Flags : C.int) return C.int is Res : C.int; begin loop Res := Syscall_Recv (S, Msg, Len, Flags); exit when SOSC.Thread_Blocking_IO or else Res /= Failure or else Non_Blocking_Socket (S) or else Errno /= SOSC.EWOULDBLOCK; delay Quantum; end loop; return Res; end C_Recv;
[Bug fortran/51081] [F03] Proc-pointer assignment: Rejects valid internal proc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51081 janus at gcc dot gnu.org changed: What|Removed |Added Summary|Proc-pointer assignment:|[F03] Proc-pointer |Rejects valid internal |assignment: Rejects valid |proc, -std=f2008 should |internal proc |mention F2008 | --- Comment #6 from janus at gcc dot gnu.org 2012-07-18 08:10:43 UTC --- (In reply to comment #4) An alternative would be to add the correct label automatically inside 'gfc_notify_std', based on the value of 'GFC_STD_*' passed. This has been implemented with r189589. ToDo: Fix the bogus errors about INT and INT2, cf. comment 2 and 3.
[Bug middle-end/54008] [4.8 Regression] gcc.dg/tree-prof/update-loopch.c and gcc.dg/tree-ssa/pr18133-1.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54008 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-07-18 Version|4.7.2 |4.8.0 Target Milestone|--- |4.8.0 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-18 08:32:13 UTC --- Confirmed.
[Bug tree-optimization/53970] -ftree-vectorization does not handle well unaligned data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53970 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added CC||ebotcazou at gcc dot ||gnu.org --- Comment #5 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-07-18 08:32:53 UTC --- That means that expr.c:contains_packed_reference does not work. Absolutely, contains_packed_reference is wrong since DECL_PACKED is only meant to drive stor-layout.c (and dwarf2out.c), i.e. it's only a declarative flag.
[Bug testsuite/54007] lto15.adb fails: gnat1: error: LTO support has not been enabled in this configuration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54007
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-07-18
Ever Confirmed|0 |1
--- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-18
08:37:45 UTC ---
Supposedly also on trunk. Would need { dg-require-effective-target lto }.
Can you check if that works for gnat.dg?
[Bug tree-optimization/54000] [4.6/4.7/4.8 Regression] Performance breakdown for gcc-4.{6,7} vs. gcc-4.5 using std::vector in matrix vector multiplication
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54000 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Target Milestone|--- |4.6.4
[Bug target/33135] [SH] -ffinite-math-only should not be on by default
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33135 --- Comment #7 from Oleg Endo olegendo at gcc dot gnu.org 2012-07-18 09:16:28 UTC --- Should this be backported to 4.6 or 4.7?
[Bug fortran/53993] gfortran ignores file part of #line directives for debugging
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53993 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|NEW --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2012-07-18 09:28:51 UTC --- Unfortunately, my attempts to generate a working patch failed, cf. http://gcc.gnu.org/ml/fortran/2012-07/msg00082.html http://gcc.gnu.org/ml/fortran/2012-07/msg00085.html I always end up with warnings of the form filename left but not entered. This warning is generated in scanner.c's preprocessor_line. I think someone needs to understand what input can be expected. In particular: How to handle the first few lines of the CPP output, of which only the last seems to be relevant vs. those of #line directives, all of which have no flag. For the last failing test case, the file (gfortran -E) starts with: # 1 libgfortran/generated/_abs_c4.F90 # 1 command-line # 1 gcc-build/x86_64-unknown-linux-gnu/libgfortran// # 1 libgfortran/generated/_abs_c4.F90 Which is one line more than before.
[Bug target/33135] [SH] -ffinite-math-only should not be on by default
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33135 --- Comment #8 from Kazumoto Kojima kkojima at gcc dot gnu.org 2012-07-18 09:32:08 UTC --- (In reply to comment #7) Should this be backported to 4.6 or 4.7? Maybe. It could be counted as a regression from 4.5 because currently we have no way to disable mieee on those branches.
[Bug c++/54011] missed optimization opportunities for bool struct/class members
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54011 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-18 09:35:42 UTC --- dup *** This bug has been marked as a duplicate of bug 23684 ***
[Bug rtl-optimization/23684] Combine stores for non strict alignment targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23684 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added CC||plasmahh at gmx dot net --- Comment #9 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-18 09:35:42 UTC --- *** Bug 54011 has been marked as a duplicate of this bug. ***
[Bug target/53967] GCC produces slow code for convolution algorithm with -mfpmath=sse (the AMD_64 default)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53967 Stupachenko Evgeny evstupac at gmail dot com changed: What|Removed |Added CC||evstupac at gmail dot com --- Comment #12 from Stupachenko Evgeny evstupac at gmail dot com 2012-07-18 09:45:15 UTC --- I tried it at -O2 and got low performance with -mfpmath=sse. It looks like it is caused by register dependency (%xmm0) between: addss%xmm0, %xmm1 cvtsi2ss%eax, %xmm0 Renaming %xmm0 in cvtsi2ss to another free register in all such cases resolves the issue. Also you can try -O2 -funroll-loops, which made sse code even faster and and -O2 -fschedule-insns which significantly reduced performance loses in sse case.
[Bug target/53974] [4.8 Regression] Nearly all tests fail with ADA.CALENDAR.TIME_ERROR : a-calend.adb:603
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53974 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-07-18 CC||ebotcazou at gcc dot ||gnu.org Component|ada |target Ever Confirmed|0 |1 --- Comment #2 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-07-18 10:15:23 UTC --- I have seen the same error on SPARC. The fix is * config/sparc/sparc.md (adddi3_insn_sp32): Add earlyclobber. so you might want to try something similar on line 4923 of pa.md.
[Bug tree-optimization/53970] -ftree-vectorization does not handle well unaligned data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53970 --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-18 10:46:11 UTC --- Author: rguenth Date: Wed Jul 18 10:46:05 2012 New Revision: 189609 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189609 Log: 2012-07-18 Richard Guenther rguent...@suse.de PR tree-optimization/53970 * tree.h (contains_packed_reference): Remove. * expr.c (contains_packed_reference): Likewise. * tree-vect-data-refs.c (not_size_aligned): New function. (vector_alignment_reachable_p): Use it. (vect_supportable_dr_alignment): Likewise. * g++.dg/torture/pr53970.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/torture/pr53970.C Modified: trunk/gcc/ChangeLog trunk/gcc/expr.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-data-refs.c trunk/gcc/tree.h
[Bug tree-optimization/53970] -ftree-vectorization does not handle well unaligned data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53970 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-18 10:46:11 UTC --- Author: rguenth Date: Wed Jul 18 10:46:05 2012 New Revision: 189609 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189609 Log: 2012-07-18 Richard Guenther rguent...@suse.de PR tree-optimization/53970 * tree.h (contains_packed_reference): Remove. * expr.c (contains_packed_reference): Likewise. * tree-vect-data-refs.c (not_size_aligned): New function. (vector_alignment_reachable_p): Use it. (vect_supportable_dr_alignment): Likewise. * g++.dg/torture/pr53970.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/torture/pr53970.C Modified: trunk/gcc/ChangeLog trunk/gcc/expr.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-data-refs.c trunk/gcc/tree.h --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-18 10:46:34 UTC --- Fixed for GCC 4.8.
[Bug tree-optimization/53970] -ftree-vectorization does not handle well unaligned data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53970 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-18 10:46:34 UTC --- Fixed for GCC 4.8.
[Bug target/53967] GCC produces slow code for convolution algorithm with -mfpmath=sse (the AMD_64 default)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53967 --- Comment #13 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-18 10:49:53 UTC --- You can also try -frename-registers
[Bug libfortran/54012] New: printf crush with -lgfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54012
Bug #: 54012
Summary: printf crush with -lgfortran
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: astrose...@gmail.com
It could be a bug of Magia distributive, not the gcc, but just in case.
The following code results in a segmentation fault if compile with -lgfortran!
%
#include stdio.h
int main ()
{
printf(
%% %% %% %% %% %% %% %% %% %%\n
%% %% %% %% %% %% %% %% %% %%\n
%% %% %% %% %% %% %% %% %% %%\n
%% %% %% %% %% %% %% %% %% %%\n
%% %% %% %% %% %% %% %% %% %%\n
%% %% %% %% %% %% %% %% %% %%\n
%% %% %% %% %% %% %% %% %% %%\n
%% %% %% %% %% %% %% %% %% %%\n
%% %% %% %% %% %% %% %% %% %%\n
%% %% %% %% %% %% %% %% %% %%\n
%% %% %% %% %% %% %% %% %% %%\n
%% %% %% %% %% %% %% %% %% %%\n
);
}
%%
gcc test.c -lgfortran
(without -lgfortran would work fine)
Distributive: Mageia release 2 (Official) for x86_64
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-mageia-linux-gnu/4.6.3/lto-wrapper
Target: x86_64-mageia-linux-gnu
Configured with: ../configure --prefix=/usr --libexecdir=/usr/lib
--with-slibdir=/lib64 --with-bugurl=http://bugs.mageia.org/
--mandir=/usr/share/man --infodir=/usr/share/info --enable-checking=release
--enable-languages=c,c++,ada,fortran,objc,obj-c++,java --enable-linker-build-id
--build=x86_64-mageia-linux-gnu --host=x86_64-mageia-linux-gnu
--with-cpu=generic --with-system-zlib --enable-threads=posix --enable-shared
--enable-objc-gc --enable-long-long --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --enable-java-awt=gtk
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-gtk-cairo
--disable-libjava-multilib --enable-ssp --disable-libssp --disable-werror
--with-ppl --with-cloog --with-python-dir=/lib/python2.7/site-packages
--enable-lto
Thread model: posix
gcc version 4.6.3 (GCC)
[Bug tree-optimization/54013] New: Loop with control flow not vectorized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54013
Bug #: 54013
Summary: Loop with control flow not vectorized
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org
Blocks: 53947
ICC manages to vectorize the following loop which happens in Polyhedron
mp_prop_design.
int foo (float x, float *tab)
{
int i;
for (i = 2; i 45; ++i)
if (x tab[i])
break;
return i - 1;
}
[Bug middle-end/53957] Polyhedron 11 benchmark: MP_PROP_DESIGN twice as long as other compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53957 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-07-18 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-18 11:25:55 UTC --- On trunk we do vectorize the loop at 552, but I'm not sure that unconditionally calling vmldAtan2 is profitable. That is, trunk for me has (-Ofast -mveclibabi=svml): 552: LOOP VECTORIZED. 576: LOOP VECTORIZED. 662: LOOP VECTORIZED. 1032: LOOP VECTORIZED. 1060: LOOP VECTORIZED. The loop at 639 is converted to two memset calls. mp_prop_design.f90(677): (col. 16) remark: PARTIAL LOOP WAS VECTORIZED. (Line number points to the outermost of the three loops; there are also conditional jumps) seems to be the important one to tackle. For the loop at 818 we fail to if-convert the nested if IF ( j.EQ.1 ) THEN tempa(j) = ZERO ELSE arg1 = -vefz(j) arg2 = vefphi(j) IF ( (arg2.LT.ZERO) .OR. (arg2.GT.ZERO) ) THEN tempa(j) = ATAN(arg1/arg2) - theta(j) ELSE tempa(j) = -theta(j) ENDIF ENDIF where we also fail to apply store-motion of tempa(j). The if (j == 1) conditional code makes the loop suitable for peeling, too. That said, this loop is suitable for analysis as well.
[Bug tree-optimization/54014] New: Value Range propagation bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54014 Bug #: 54014 Summary: Value Range propagation bug Classification: Unclassified Product: gcc Version: 4.5.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: ferra...@elet.polimi.it Created attachment 27822 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27822 sightly modified version of arith-rand.c Dears, I've found a problem with a sightly modified version of a gcc regression test (arith-rand.c). The regression test has been modified in order to abort on a specific condition. The test correctly aborts when no optimization is performed but it does not fail when -O2 is passed. The problem seems to be in how the VRP work, in fact once the -fno-tree-vrp is passed the test correctly fails. The line I've added to arith-rand.c is the following if((unsigned int) ABS (yy)==2147483648u) abort(); The VRP claims that (unsigned int) ABS (yy) is in the range [1, 2147483647] but the actual range should be [1, 2147483648]. Everything seems to be related to the managing of -(-2147483648). The test does not abort on these versions on gcc-4.5.3 (Ubuntu 12.04), 4.6.3 (Ubuntu 12.04) and on gcc-4.7.1 (debian wheezy/sid) with the following command line: gcc-4.5 arith-rand.c -O2 #(Ubuntu 12.04) gcc-4.5 arith-rand.c -O2 #(Ubuntu 12.04) gcc-4.7 arith-rand.c -O2 #(debian wheezy/sid) while it correctly aborts once the option -fno-tree-vrp is passed Cheers, Fabrizio
[Bug tree-optimization/54014] Value Range propagation bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54014 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-18 11:44:26 UTC --- The VRP claims that (unsigned int) ABS (yy) is in the range [1, 2147483647] but the actual range should be [1, 2147483648]. Everything seems to be related to the managing of -(-2147483648). abs () on an int is in the range [0, 2147483647], converting that to unsigned does not increase that range. You probably want a ABSU function which returns an unsigned number - but that does not exist.
[Bug tree-optimization/54014] Value Range propagation bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54014 --- Comment #2 from Fabrizio Ferrandi ferrandi at elet dot polimi.it 2012-07-18 11:56:26 UTC --- I do not agree. abs(-2147483648) returns -2147483648. May be is odd but is how the implementation of abs works. Isn't it?
[Bug middle-end/53957] Polyhedron 11 benchmark: MP_PROP_DESIGN twice as long as other compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53957 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-18 12:02:32 UTC --- All time is spent in the loop nest starting at line 677, 683, 694, 696 for all of them we claim they are in bad loop form.
[Bug fortran/53957] Polyhedron 11 benchmark: MP_PROP_DESIGN twice as long as other compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53957 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Component|middle-end |fortran --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-18 12:09:23 UTC --- The issue seems to be that the frontend uses two induction variables, one signed and one unsigned, for DO i = 1 , 1 + NINT(2.0D0*PI*trns/dphit) , NINT(ainc/(dphit*(180.0D0/PI))) ... END DO bb 78: # i_5 = PHI [mp_prop_design.f90 : 697:0] 1(77), [mp_prop_design.f90 : 696:0] i_621(79) # countm1.38_32 = PHI [mp_prop_design.f90 : 696:0] countm1.38_466(77), [mp_prop_design.f90 : 696:0] countm1.38_622(79) # prephitmp.386_3285 = PHI pretmp.385_3284(77), D.2618_614(79) # prephitmp.386_3287 = PHI pretmp.385_3286(77), D.2620_620(79) ... [mp_prop_design.f90 : 696:0] i_621 = i_5 + pretmp.378_3242; [mp_prop_design.f90 : 696:0] # DEBUG i = i_621 [mp_prop_design.f90 : 696:0] if (countm1.38_32 == 0) goto bb 80; else goto bb 79; bb 79: [mp_prop_design.f90 : 696:0] countm1.38_622 = countm1.38_32 + 4294967295; [mp_prop_design.f90 : 696 : 0] goto bb 78; and the decrement of countm1 happens in the loop latch block. It would be better to have this similar to other loops I see, bool flag = end-value == i; i = i + 1; if (flag) goto loop_exit;
[Bug c++/53990] wrong optimisation: automatic variable doesn't removed at fuction exit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53990 --- Comment #3 from litwr vol.litwr at gmail dot com 2012-07-18 12:18:54 UTC --- Thank you very much! Excuse me this little ignorancy. However it is a bit confusing that this allows to have code executed differently with different compilers.
[Bug tree-optimization/54014] Value Range propagation bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54014 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-18 12:21:06 UTC --- (In reply to comment #2) I do not agree. abs(-2147483648) returns -2147483648. May be is odd but is how the implementation of abs works. Isn't it? abs(-2147483648) invokes undefined behavior, similar to -(-2147483648), according to the C standard.
[Bug c++/53990] wrong optimisation: automatic variable doesn't removed at fuction exit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53990 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2012-07-18 12:40:42 UTC --- It's maybe a little confusing for beginners, until they learn how it works, but it makes certain operations up to three times faster so it's a huge benefit. All good quality compilers will perform the optimisation, but if you don't want G++ to do it (and want your programs to be slower) you can use -fno-elide-constructors
[Bug fortran/53957] Polyhedron 11 benchmark: MP_PROP_DESIGN twice as long as other compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53957
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2012-07-18
12:46:29 UTC ---
(In reply to comment #3)
It would be better to have this similar to other loops I see,
bool flag = end-value == i;
i = i + 1;
if (flag) goto loop_exit;
That's not that simple as one might not reach the end value due to the step. If
step is (plus or minus) unity and if one has integers (and not reals, added
in Fortran 77, deleted in Fortran 90), it is simple.
But if abs(step) != 1 or if the loop variable is not an integer, one either
needs to calculate the number of trips beforehand, or has to use or
rather than ==. The problem with / is that one has to do another
comparison, unless the sign of step is known:
if (step 0 ? dovar to : dovar to)
goto exit_label;
I don't see whether that version is better than the current version.
Suggestions or comments?
The current code is (comment from trans-stmt.c's gfc_trans_do):
cut-
We translate a do loop from:
DO dovar = from, to, step
body
END DO
to:
[evaluate loop bounds and step]
empty = (step 0 ? to from : to from);
countm1 = (to - from) / step;
dovar = from;
if (empty) goto exit_label;
for (;;)
{
body;
cycle_label:
dovar += step
if (countm1 ==0) goto exit_label;
countm1--;
}
exit_label:
countm1 is an unsigned integer. It is equal to the loop count minus one,
because the loop count itself can overflow. */
/cut-
[Bug fortran/51081] [F03] Proc-pointer assignment: Rejects valid internal proc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51081
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org
|gnu.org |
--- Comment #7 from janus at gcc dot gnu.org 2012-07-18 12:54:32 UTC ---
(In reply to comment #6)
ToDo: Fix the bogus errors about INT and INT2, cf. comment 2 and 3.
The following patch makes the test case in comment #1 work:
Index: gcc/fortran/primary.c
===
--- gcc/fortran/primary.c(revision 189608)
+++ gcc/fortran/primary.c(working copy)
@@ -2843,9 +2843,6 @@ gfc_match_rvalue (gfc_expr **result)
/* Parse functions returning a procptr. */
goto function0;
- if (gfc_is_intrinsic (sym, 0, gfc_current_locus)
- || gfc_is_intrinsic (sym, 1, gfc_current_locus))
-sym-attr.intrinsic = 1;
e = gfc_get_expr ();
e-expr_type = EXPR_VARIABLE;
e-symtree = symtree;
However, it regresses on proc_ptr_{1,6,11,12,15}.f90 and sizeof_proc.f90.
Surely the setting of attr.intrinsic comes too early in gfc_match_rvalue. It
probably should be deferred to resolution stage, where we know about the
presence of the internal proc.
[Bug c++/54015] New: problem in compiling Qgis source code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54015 Bug #: 54015 Summary: problem in compiling Qgis source code Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: manojk.softengin...@gmail.com
[Bug fortran/53957] Polyhedron 11 benchmark: MP_PROP_DESIGN twice as long as other compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53957
--- Comment #5 from rguenther at suse dot de rguenther at suse dot de
2012-07-18 13:18:13 UTC ---
On Wed, 18 Jul 2012, burnus at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53957
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2012-07-18
12:46:29 UTC ---
(In reply to comment #3)
It would be better to have this similar to other loops I see,
bool flag = end-value == i;
i = i + 1;
if (flag) goto loop_exit;
That's not that simple as one might not reach the end value due to the step.
If
step is (plus or minus) unity and if one has integers (and not reals, added
in Fortran 77, deleted in Fortran 90), it is simple.
But if abs(step) != 1 or if the loop variable is not an integer, one either
needs to calculate the number of trips beforehand, or has to use or
rather than ==. The problem with / is that one has to do another
comparison, unless the sign of step is known:
if (step 0 ? dovar to : dovar to)
goto exit_label;
I don't see whether that version is better than the current version.
Suggestions or comments?
The current code is (comment from trans-stmt.c's gfc_trans_do):
cut-
We translate a do loop from:
DO dovar = from, to, step
body
END DO
to:
[evaluate loop bounds and step]
empty = (step 0 ? to from : to from);
countm1 = (to - from) / step;
dovar = from;
if (empty) goto exit_label;
for (;;)
{
body;
cycle_label:
dovar += step
if (countm1 ==0) goto exit_label;
countm1--;
}
exit_label:
countm1 is an unsigned integer. It is equal to the loop count minus one,
because the loop count itself can overflow. */
If you do
[evaluate loop bounds and step]
empty = (step 0 ? to from : to from);
countm1 = (to - from) / step;
dovar = from;
if (empty) goto exit_label;
for (;;)
{
body;
cycle_label:
dovar += step
exit = countm1 == 0;
countm1--;
if (exit) goto exit_label;
}
exit_label:
it would work for this case.
[Bug c++/54015] problem in compiling Qgis source code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54015 --- Comment #1 from manoj manojk.softengineer at gmail dot com 2012-07-18 13:19:40 UTC --- 17:30:55: Running build steps for project qgis1.7.4... 17:30:55: Starting: C:\QtSDK\mingw\bin\mingw32-make.exe [ 0%] Built target version [ 8%] Built target ui [ 25%] Built target qgis_core [ 35%] Built target qgis_gui [ 38%] Built target qgis_analysis [ 65%] Built target qgis [ 68%] Built target translations [ 68%] Built target compile_python_files [ 69%] Built target python_module_qgis_analysis [ 69%] Building CXX object python/CMakeFiles/python_module_qgis_core.dir/core/sipcorepart1.cpp.obj F:/qgis1.7.4/qt_july2/python/core/sipcorepart1.cpp: In member function 'virtual bool sipQgsVectorLayer::eventFilter(QObject*, QEvent*)': F:/qgis1.7.4/qt_july2/python/core/sipcorepart1.cpp:19049:42: internal compiler error: in build_base_path, at cp/class.c:270 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. mingw32-make.exe[2]: *** [python/CMakeFiles/python_module_qgis_core.dir/core/sipcorepart1.cpp.obj] Error 1 mingw32-make.exe[1]: *** [python/CMakeFiles/python_module_qgis_core.dir/all] Error 2 mingw32-make.exe: *** [all] Error 2 17:31:06: The process C:\QtSDK\mingw\bin\mingw32-make.exe exited with code 2. Error while building project qgis1.7.4 (target: Desktop) When executing build step 'Make'
[Bug tree-optimization/31079] 20% difference between ifort/gfortran, missed vectorization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31079 --- Comment #14 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-18 13:28:41 UTC --- Smart again - with stock trunk I get everything optimized away ;)
[Bug c++/54015] problem in compiling Qgis source code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54015 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-07-18 Ever Confirmed|0 |1 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-07-18 13:47:42 UTC --- (In reply to comment #1) Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug fortran/53957] Polyhedron 11 benchmark: MP_PROP_DESIGN twice as long as other compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53957 --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org 2012-07-18 14:04:45 UTC --- Created attachment 27823 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27823 Draft patch: Change comparison into bool assignment, decrement conditional jump (In reply to comment #5) If you do exit = countm1 == 0; countm1--; if (exit) goto exit_label; it would work for this case. If I apply the attached patch, I do not see any performance difference on my AMD Athlon64 x2 4800+ with -Ofast -funroll-loops -march=native. real 3m45.711s 3m45.589s 3m44.308s | 3m45.363s 3m45.328s 3m44.220s user 3m45.710s 3m45.582s 3m44.274s | 3m45.282s 3m45.286s 3m44.218s
[Bug tree-optimization/54016] New: tree loop optimizer: no branch on count on s390 anymore since revision 185913
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54016
Bug #: 54016
Summary: tree loop optimizer: no branch on count on s390
anymore since revision 185913
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kreb...@gcc.gnu.org
#include string.h
void *
foo (void *dest, const void *src)
{
return memcpy (dest, src, 5);
}
r185913: gcc -O3 -march=z10 -S:
foo:
.LFB12:
.cfi_startproc
lghi%r4,195
lgr %r1,%r2
.L2:
pfd 1,768(%r3)
pfd 2,768(%r1)
aghi%r4,-1
mvc 0(256,%r1),0(%r3)
la %r1,256(%r1)
la %r3,256(%r3)
jne .L2
mvc 0(80,%r1),0(%r3)
br %r14
With previous GCCs this used to be:
foo:
.LFB12:
.cfi_startproc
lghi%r4,195
lgr %r1,%r2
.L2:
pfd 1,768(%r3)
pfd 2,768(%r1)
mvc 0(256,%r1),0(%r3)
la %r1,256(%r1)
la %r3,256(%r3)
brctg %r4,.L2
mvc 0(80,%r1),0(%r3)
br %r14
[Bug target/53967] GCC produces slow code for convolution algorithm with -mfpmath=sse (the AMD_64 default)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53967 --- Comment #14 from bfriesen at simple dot dallas.tx.us 2012-07-18 14:28:04 UTC --- With -m64 -mtune=generic -march=x86-64 -mfpmath=sse -O2 -funroll-loops -fschedule-insns I see a whole-program performance jump from 0.047 iter/s to 0.156 iter/s (331% boost). That is huge! Given the fundamental properties of this algorithm (the image processing algorithm most often recommended to be moved to a GPU) the world would be a better place if this performance was the normal case. With -m64 -mtune=generic -march=x86-64 -mfpmath=sse -O2 -fschedule-insns I see 0.101 iter/s These must not be included in -O3 since -m64 -mtune=generic -march=x86-64 -mfpmath=sse -O3 produces only 0.048 iter/s
[Bug fortran/53957] Polyhedron 11 benchmark: MP_PROP_DESIGN twice as long as other compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53957 --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-18 14:47:49 UTC --- It helps to make us even consider the loop. We now run into 696: worklist: examine stmt: D.2574_254 = (real(kind=4)) i_5; 696: vect_is_simple_use: operand i_5 696: def_stmt: i_5 = PHI 1(77), i_324(80) 696: Unsupported pattern. 696: not vectorized: unsupported use in stmt. 696: unexpected pattern. that is, the following induction is not handled: phit = phib + phie(k) + (REAL(i)-0.50D0) *dphit so it would be still worthwhile to pursue your patch if it does not have negative effects elsewhere. We should be able to fix the induction code to handle this case. If you can help isolating the innermost two loops into a smaller testcase that would be great, too.
[Bug rtl-optimization/54016] tree loop optimizer: no branch on count on s390 anymore since revision 185913
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54016 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Component|tree-optimization |rtl-optimization --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-18 14:56:28 UTC --- Surely happens on RTL.
[Bug c/54017] New: Incorrect implementation of infinite loops in OpenMP sections leads to SIGILL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54017
Bug #: 54017
Summary: Incorrect implementation of infinite loops in OpenMP
sections leads to SIGILL
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: il...@rz.rwth-aachen.de
Consider this very simple OpenMP sections code:
int main()
{
#pragma omp parallel sections
{
#pragma omp section
{
for(;1;) {}
}
}
return 0;
}
Since there is only one OpenMP section, if this code is run with more than one
thread, GOMP_sections_start() would return 0 in all but the first thread to
call it. Unfortunately the compiler generates the following assembly code to
test the return value:
movl$1, %edi
callGOMP_sections_start
cmpl$1, %eax
je .L4
.value 0x0b0f
.L4:
jmp .L4
In all threads but the first one the JE instruction would not branch and the
UD2 instruction emitted by __builtin_trap() would get hit and the program will
abort with SIGILL. Tested also with for(;;) {} and while(1) {} - same
assembly code emitted.
If instead the code of the section is modified to read:
#pragma omp section
{
int i = 1;
for(;i;) {}
}
the produced assembly code correctly handles 0 as the possible return value of
GOMP_sections_next():
callGOMP_sections_next
.L7:
testl %eax, %eax
je .L4
cmpl$1, %eax
je .L5
.value 0x0b0f
.L4:
callGOMP_sections_end_nowait
jmp .L8
.L5:
movl$1, -4(%rbp)
.L6:
cmpl$0, -4(%rbp)
jne .L6
callGOMP_sections_next
jmp .L7
.L8:
leave
Also if at least one another section without infinite loop is added, e.g.:
#pragma omp section
{
for(;1;) {}
}
#pragma omp section
{
int k = 5;
}
return value from GOMP_sections_next() is processed correctly:
callGOMP_sections_next
.L8:
cmpl$1, %eax
je .L6
cmpl$1, %eax
jb .L5
cmpl$2, %eax
je .L7
.value 0x0b0f
.L5:
callGOMP_sections_end_nowait
jmp .L9
.L7:
movl$5, -4(%rbp)
callGOMP_sections_next
jmp .L8
.L6:
jmp .L6
.L9:
leave
The correct behaviour in the first case should be that other threads would wait
infinitely at the barrier in GOMP_parallel_end() and not crash with SIGILL as
in the first case.
Unfortunately I don't have access to GCC versions higher than 4.7.0 but I've
tested it with previous versions down to 4.3.4 with the same result.
Optimisation level has no influence on the problem. It also fails in 32-bit
mode.
[Bug c++/52818] printf format %lf is erroneously rejected by C++11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52818 Scott Lipcon slipcon at gmail dot com changed: What|Removed |Added CC||slipcon at gmail dot com --- Comment #5 from Scott Lipcon slipcon at gmail dot com 2012-07-18 16:48:03 UTC --- I'm not sure how gcc development process goes - but could this be considered for inclusion in gcc 4.7.2? The patch applies cleanly and seems to work against 4.7.1, but we don't want to run local patches of gcc for obvious reasons. This issue is making 64-bit support in our code difficult, specifically for formatting size_t values using C99's %zu formatter, which 'g++ -std=c++0x -pedantic' is rejecting. Thanks.
[Bug libstdc++/54018] New: std::uncaught_exception hangs in pthread created during global initialization from dlopen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54018 Bug #: 54018 Summary: std::uncaught_exception hangs in pthread created during global initialization from dlopen Classification: Unclassified Product: gcc Version: 4.4.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: wer...@gmail.com Created attachment 27824 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27824 Reproducer for hang of std::uncaught_exception during thread join in global initialization from dlopen OS: Red Hat Enterprise Linux Server release 6.2 (Santiago) gcc/libstdc++: RHEL6's 4.4.6-3.el6.x86_64 glibc: RHEL6's 2.12-1.47.el6_2.12.x86_64 If std::uncaught_exception is called from the routine of a pthread created during global initialization initiated via dlopen, it hangs indefinitely while waiting for the thread to complete. I have attached a simple reproducer. Looking at the source for libstdc++ and the backtrace during the hang, it is fairly obvious that ld-linux-x86-64.so.2 is holding a mutex needed for tls operations during __cxa_get_globals during dlopen. If the thread is unjoined (detached or ignored) during global initialization from dlopen, it will successfully acquire a lock from tls and return from uncaught_exception. This is a regression from our other operating environment: gcc/libstdc++: 4.3.2 glibc: 2.5 Wherein running the 'main' program provided does not hang. I'm unsure whether this was introduced by glibc/ld.so changes or a change to libstdc++. I'll accept if this behavior is unsupported, as it does throw together dlopen, pthreads, and global initialization rather unceremoniously, but I'll remain optimistic that this is a genuine regression of previously safe behavior. Regards, -George
[Bug java/53973] [x32] libjava failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53973 --- Comment #2 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2012-07-18 17:38:46 UTC --- Author: hjl Date: Wed Jul 18 17:38:37 2012 New Revision: 189621 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189621 Log: Check and skip 67h address size prefix for x32 PR libjava/53973 * include/x86_64-signal.h (CHECK_67H_PREFIX): New. (HANDLE_DIVIDE_OVERFLOW): Check and and skip 67h address size prefix if CHECK_67H_PREFIX is 1. Use ULL suffix for 64-bit integer. Modified: trunk/libjava/ChangeLog trunk/libjava/include/x86_64-signal.h
[Bug tree-optimization/54014] Value Range propagation bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54014
--- Comment #4 from Fabrizio Ferrandi ferrandi at elet dot polimi.it
2012-07-18 17:41:48 UTC ---
Maybe I missing something but there is a specific code that deals with this
undefined behavior in tree-vrp.c:
else if (code == ABS_EXPR
!TYPE_UNSIGNED (type))
{
/* -TYPE_MIN_VALUE = TYPE_MIN_VALUE with flag_wrapv so we can't get a
useful range. */
if (!TYPE_OVERFLOW_UNDEFINED (type)
((vr0.type == VR_RANGE
vrp_val_is_min (vr0.min))
|| (vr0.type == VR_ANTI_RANGE
!vrp_val_is_min (vr0.min)
!range_includes_zero_p (vr0
{
set_value_range_to_varying (vr);
return;
}
This code is from gcc 4.5.3 and it still survives in gcc 4.7.1. I've spent some
further time on this issues and it seems that the range does not come from abs
restriction. I will spend some further effort later.
[Bug java/53973] [x32] libjava failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53973 --- Comment #3 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2012-07-18 18:09:56 UTC --- Author: hjl Date: Wed Jul 18 18:09:49 2012 New Revision: 189623 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189623 Log: Skip 67h address size prefix unconditionally PR libjava/53973 * include/x86_64-signal.h (CHECK_67H_PREFIX): Removed. (HANDLE_DIVIDE_OVERFLOW): Skip 67h address size prefix unconditionally. Modified: trunk/libjava/ChangeLog trunk/libjava/include/x86_64-signal.h
[Bug bootstrap/53468] debian/ubuntu changed the location of libraries on the disk which broke bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53468 Thomas Schwinge tschwinge at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-07-18 CC||doko at ubuntu dot com, ||tschwinge at gcc dot ||gnu.org Ever Confirmed|0 |1
[Bug bootstrap/53468] debian/ubuntu changed the location of libraries on the disk which broke bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53468 --- Comment #2 from Thomas Schwinge tschwinge at gcc dot gnu.org 2012-07-18 18:52:34 UTC --- Created attachment 27825 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27825 multiarch-2012-07-08 Latest version of the multiarch patch that makes GCC again buildable on Debian/Ubuntu: http://gcc.gnu.org/ml/gcc-patches/2012-07/msg00298.html, merely attaching patch here.
[Bug target/38621] [4.6/4.7/4.8 Regression] sh gcc unable to spill register when building ghostscript-gpl with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38621 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #13 from Oleg Endo olegendo at gcc dot gnu.org 2012-07-18 18:57:38 UTC --- (In reply to comment #11) (In reply to comment #10) I've tried to reproduce the issue with rev 189549 (GCC 4.8), GCC 4.7.2 20120711 (prerelease) and GCC 4.6.4 20120716 (prerelease). It seems this is no longer an issue. 4.6 and 4.7 are failing with -fschedule-insns for me. We changed the default behavior so that -fno-schedule-insns is default. 4.8 doesn't fail even with -fschedule-insns. I guess that your patches for index addressing fix it on trunk. Perhaps we can close this PR because it's fixed on trunk and looks no hope to fix it for 4.6 and 4.7 compilers with -fschedule-insns. OK. I think it's better to take any -fschedule-insns follow ups to PR 22553.
[Bug java/53982] gij built for x32 can't run a simple Hello World class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53982 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #5 from H.J. Lu hjl.tools at gmail dot com 2012-07-18 19:13:30 UTC --- Dup. *** This bug has been marked as a duplicate of bug 53973 ***
[Bug java/53973] [x32] libjava failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53973 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||dschepler at gmail dot com --- Comment #4 from H.J. Lu hjl.tools at gmail dot com 2012-07-18 19:13:30 UTC --- *** Bug 53982 has been marked as a duplicate of this bug. ***
[Bug target/54019] New: [SH] Tail calls with -fPIC use bsrf instead of braf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54019
Bug #: 54019
Summary: [SH] Tail calls with -fPIC use bsrf instead of braf
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: olege...@gcc.gnu.org
Target: sh*-*-*
The following function:
int a, b;
int bleh (int x, int y);
int foo (void)
{
return bleh (a + b, a - b);
}
compiled with -m4 -O2 -ml -fPIC:
mov.l r12,@-r15 ! 42movsi_ie/11[length = 2]
mova.L3,r0 ! 44mova[length = 2]
mov.l .L3,r12 ! 45movsi_ie/1[length = 2]
sts.l pr,@-r15! 43movsi_ie/13[length = 2]
add r0,r12 ! 46*addsi3_compact[length = 2]
mov.l .L4,r0 ! 5movsi_ie/1[length = 2]
mov.l @(r0,r12),r2! 7movsi_ie/7[length = 2]
mov.l .L5,r0 ! 34movsi_ie/1[length = 2]
mov.l @r2,r5 ! 8movsi_ie/7[length = 2]
mov.l @(r0,r12),r1! 11movsi_ie/7[length = 2]
mov r5,r4 ! 37movsi_ie/2[length = 2]
mov.l @r1,r1 ! 12movsi_ie/7[length = 2]
add r1,r4 ! 15*addsi3_compact[length = 2]
sub r1,r5 ! 16*subsi3_internal[length = 2]
mov.l .L6,r1 ! 39movsi_ie/1[length = 2]
bsrfr1 ! 41call_valuei_pcrel[length = 4]
.LPCS0:
nop
lds.l @r15+,pr! 55movsi_ie/17[length = 2]
rts ! 58*return_i[length = 2]
mov.l @r15+,r12 ! 56movsi_ie/7[length = 2]
.L7:
.align 2
.L3:
.long _GLOBAL_OFFSET_TABLE_
.L4:
.long _a@GOT
.L5:
.long _b@GOT
.L6:
.long __Z4blehii@PLT-(.LPCS0+2-.)
.cfi_endproc
Instead of 'bsrf' the 'braf' instruction could be used.
Maybe this is a side effect of PR 12306.
[Bug java/53982] gij built for x32 can't run a simple Hello World class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53982 --- Comment #6 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2012-07-18 19:19:40 UTC --- Author: hjl Date: Wed Jul 18 19:19:34 2012 New Revision: 189626 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189626 Log: Define FFI_SIZEOF_JAVA_RAW to 4 for x32 PR libffi/53982 PR libffi/53973 * src/x86/ffitarget.h: Check __ILP32__ instead of __LP64__ for x32. (FFI_SIZEOF_JAVA_RAW): Defined to 4 for x32. Modified: trunk/libffi/ChangeLog.libgcj trunk/libffi/src/x86/ffitarget.h
[Bug java/53973] [x32] libjava failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53973 --- Comment #5 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2012-07-18 19:19:40 UTC --- Author: hjl Date: Wed Jul 18 19:19:34 2012 New Revision: 189626 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189626 Log: Define FFI_SIZEOF_JAVA_RAW to 4 for x32 PR libffi/53982 PR libffi/53973 * src/x86/ffitarget.h: Check __ILP32__ instead of __LP64__ for x32. (FFI_SIZEOF_JAVA_RAW): Defined to 4 for x32. Modified: trunk/libffi/ChangeLog.libgcj trunk/libffi/src/x86/ffitarget.h
[Bug target/12306] GOT pointer (r12) reloaded unnecessarily
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12306 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added Target|sh-elf |sh*-*-* Last reconfirmed|2005-09-07 17:58:48 |2012-07-18 CC||olegendo at gcc dot gnu.org --- Comment #2 from Oleg Endo olegendo at gcc dot gnu.org 2012-07-18 19:25:41 UTC --- As of rev 189601 (4.8.0 20120718 (experimental)) this issue still persists.
[Bug c++/54020] New: [c++0x] incorrectly accepted constexpr functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54020
Bug #: 54020
Summary: [c++0x] incorrectly accepted constexpr functions
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: l...@mit.edu
Tested on a somewhat recent trunk build as well as 4.7-some branch version.
// Preliminaries.
extern int nonconst_func(int);
constexpr int identity(int x) { return x; }
constexpr int zero() { return identity(0); }
constexpr int one() { return identity(1); }
// Correctly accepted.
constexpr int three = one() ? 3 : nonconst_func(0);
// Incorrectly accepted. See [dcl.constexpr] #5:
// For a constexpr function, if no function argument values exist
// such that the function invocation sub-stitution would produce a
// constant expression (5.19), the program is ill-formed; no diagnostic
// required.
constexpr int bogus() { return zero () ? 3 : nonconst_func(0); }
// Correctly rejected (not sure why).
constexpr int correct_error() { return nonconst_func(0); }
// Correctly rejected.
constexpr int z = bogus();
// This is also correctly rejected.
constexpr int correct_failure() { return 0 ? 3 : nonconst_func(0); }
[Bug c++/54021] New: [c++0x] __builtin_constant_p should be constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54021
Bug #: 54021
Summary: [c++0x] __builtin_constant_p should be constexpr
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: l...@mit.edu
It's hard to tell how __builtin_constant_p works right now, due to PR54020.
// Preliminaries.
extern int nonconst_func(int);
constexpr int identity(int x) { return x; }
constexpr int zero() { return identity(0); }
constexpr int one() { return identity(1); }
// These are the same. Only the latter is accepted, though.
// I suspect that the acceptance of the latter is due to the bug above.
constexpr int rejected_const_4(int x) { return __builtin_constant_p(x) ? 4 :
nonconst_func(x); }
constexpr int accepted_const_4(int x) { return
identity(__builtin_constant_p(x)) ? 4 : nonconst_func(x); }
// This is rejected. I would like it to work.
constexpr int four = accepted_const_4(1);
The ability to use the construction __builtin_constant_p(x) ? const_func(x) :
nonconst_func(x) in constexpr context would be quite powerful.
[Bug target/22553] [4.6/4.7/4.8 regression] ICE building libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22553 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added CC||olegendo at gcc dot gnu.org --- Comment #22 from Oleg Endo olegendo at gcc dot gnu.org 2012-07-18 20:12:22 UTC --- On 'gcc version 4.8.0 20120718 (experimental)' I've commented out the 'if (targetm.small_register_classes_for_mode_p (VOIDmode))' block in sh.c (sh_option_override) and ran some CSiBE result-size tests. There is a total increase of +19746 bytes / +0.624419, but there are also some individual decreases. I've briefly compared some of the compiled files and it seems that with -fschedule-insn enabled the interleaving of LS/MT/EX group instructions seems to be a bit better, although I don't have any runtime numbers. Kaz, if you have some time, could you do something like that http://gcc.gnu.org/ml/gcc-patches/2005-09/msg01539.html again (if possible with mpeg2dec) with GCC 4.8?
[Bug target/53967] GCC produces slow code for convolution algorithm with -mfpmath=sse (the AMD_64 default)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53967 --- Comment #15 from bfriesen at simple dot dallas.tx.us 2012-07-18 20:42:22 UTC --- Testing shows that using -m64 -march=native -O2 -mfpmath=sse -frename-registers is sufficient to restore good performance.
[Bug tree-optimization/54022] New: [4.8 regression] ICE in hoist_edge_and_branch_if_true
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54022 Bug #: 54022 Summary: [4.8 regression] ICE in hoist_edge_and_branch_if_true Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: ebotca...@gcc.gnu.org Created attachment 27826 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27826 Reduced testcase Visible on x86-64/Linux at least at -O2: eric@hermes:~/build/gcc/native gcc/xgcc -Bgcc -S discr2.ads -O2 +===GNAT BUG DETECTED==+ | 4.8.0 20120716 (experimental) [trunk revision 189525] (x86_64-suse-linux) GCC error:| | in hoist_edge_and_branch_if_true, at tree-switch-conversion.c:80 | | Error detected around discr2.ads:6:1| The testcase can be added to the testsuite as gnat.dg/specs/discr2.ads.
[Bug c++/54023] New: [C++0x][initializer list] integer type to floating type narrowing type is not producing diagnostics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54023 Bug #: 54023 Summary: [C++0x][initializer list] integer type to floating type narrowing type is not producing diagnostics Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: ebewo...@gmail.com According to standard 8.5.4.7 A narrowing conversion is an implicit conversion... -from an integer type or unscoped enumeration type to a floating-point type, except where the source is a constant expression and the actual value after conversion will fit into the target type and will produce the original value when converted back to the original type, ... and not allowed at top level. Therefore followings should be generate diagnostics int i=3; double d=i; float f=i; long double ld=i; char c=3; double d=c; etc.. should give narrowing error.
[Bug c++/54023] [C++0x][initializer list] integer type to floating type narrowing type is not producing diagnostics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54023
ebeworld ebeworld at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
--- Comment #1 from ebeworld ebeworld at gmail dot com 2012-07-18 21:40:20
UTC ---
forgot the curly braces.It should have been double d={i} and the compiler gives
warning: narrowing conversion of 'i' from 'int' to 'double' inside { }
[-Wnarrowing]
[Bug testsuite/54007] lto15.adb fails: gnat1: error: LTO support has not been enabled in this configuration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54007
--- Comment #2 from dave.anglin at bell dot net 2012-07-18 22:11:24 UTC ---
On 18-Jul-12, at 4:37 AM, rguenth at gcc dot gnu.org wrote:
Supposedly also on trunk. Would need { dg-require-effective-target
lto }.
Can you check if that works for gnat.dg?
Yes, it works.
--
John David Anglindave.ang...@bell.net
[Bug target/53975] [ia64] Target register of a speculative load moved to a branch register prior to the chk.s instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53975 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW
[Bug target/53975] [ia64] Target register of a speculative load moved to a branch register prior to the chk.s instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53975
--- Comment #8 from Steven Bosscher steven at gcc dot gnu.org 2012-07-18
23:13:32 UTC ---
Created attachment 27827
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27827
Somewhat reduced, preprocessed test case
Fails with a cross-compiler from x86_64 to ia64 with trunk r189633. Compile
with: -O3 -ffreestanding -fno-builtin -std=gnu99 -fno-unwind-tables
-mfixed-range=f32-f127 -mno-pic -mno-sdata t.c -dAP -fdump-rtl-all.
Everything looks ok up to machine-reorg. The .218r.compgotos dump has:
(insn 2105 2104 2106 118 (set (reg:DI 122 r71)
(mem/f:DI (reg/f:DI 34 r37 [1005]) [3 ps_90(D)-data+0 S8 A64])) t.c:95
6 {movdi_internal}
(nil))
(insn 2106 2105 2107 118 (set (reg:DI 14 r14)
(mem/f:DI (reg/v/f:DI 113 r33 [orig:610 ps ] [610]) [3
ps_90(D)-str_write+0 S8 A64])) t.c:95 6 {movdi_internal}
(nil))
(insn 2107 2106 2108 118 (set (reg:DI 326 b6)
(reg:DI 14 r14)) t.c:95 6 {movdi_internal}
(expr_list:REG_DEAD (reg:DI 14 r14)
(nil)))
But the .220r.mach dump has:
deleting insn with uid = 2106.
scanning new insn with uid = 3366.
...
(insn 3366 3398 3365 117 (set (reg:DI 14 r14)
(unspec:DI [
(mem/f:DI (reg/v/f:DI 113 r33 [orig:610 ps ] [610]) [3
ps_90(D)-str_write+0 S8 A64])
] UNSPEC_LDS)) 23 {movdi_speculative}
(nil))
(insn 3365 3366 2104 117 (set (reg:DI 122 r71)
(unspec:DI [
(mem/f:DI (reg/f:DI 34 r37 [1005]) [3 ps_90(D)-data+0 S8 A64])
] UNSPEC_LDS)) 23 {movdi_speculative}
(nil))
...
(insn 2107 892 893 117 (set (reg:DI 326 b6)
(reg:DI 14 r14)) t.c:95 6 {movdi_internal}
(expr_list:REG_DEAD (reg:DI 14 r14)
(nil)))
...
(jump_insn:TI 3374 3410 3409 137 (set (pc)
(if_then_else (ne (unspec [
(reg:DI 14 r14)
] UNSPEC_CHKS)
(const_int 0 [0]))
(pc)
(label_ref 3369))) t.c:95 101 {speculation_check_di}
(nil)
- 3369)
This is done by the selective scheduler.
(Work-around: -fno-fselective-scheduling -fno-fselective-scheduling2)
[Bug target/53975] [ia64] Target register of a speculative load moved to a branch register prior to the chk.s instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53975 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code CC||amonakov at gcc dot gnu.org Known to fail||4.7.0, 4.7.1, 4.8.0 --- Comment #9 from Steven Bosscher steven at gcc dot gnu.org 2012-07-18 23:18:02 UTC --- Hello Alexander, this bug is a problem in the selective scheduler. A general register holding an ld8.s load is assigned to a branch register before the chk.s. But the branch registers have no NaT flag so the machine throws an exception. Could you have a look at this please?
[Bug c++/54024] New: Internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54024 Bug #: 54024 Summary: Internal compiler error Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: ian.e.macken...@gmail.com I received an internal compiler error trying to compile the attached (preprocessed) code using GCC 4.7.1 on Arch Linux (64 bit). The command line used was c++ -DOpenSolidPythonModule_EXPORTS -DHAVE_PTHREAD -D_USE_MATH_DEFINES -DQT_OPENGL_LIB -DQT_GUI_LIB -DQT_XML_LIB -DQT_CORE_LIB -DQT_NO_DEBUG -std=c++11 -pthread -Wall -Wno-unused-variable -Wno-enum-compare -fPIC -O2 -g -DNDEBUG -fPIC -o preprocessed.o -c preprocessed.cpp which results in c++: internal compiler error: Killed (program cc1plus) Please submit a full bug report, with preprocessed source if appropriate. See https://bugs.archlinux.org/ for instructions. gcc -v gives: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /build/src/gcc-4.7.1/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --enable-libstdcxx-time --enable-gnu-unique-object --enable-linker-build-id --with-ppl --enable-cloog-backend=isl --disable-ppl-version-check --disable-cloog-version-check --enable-lto --enable-gold --enable-ld=default --enable-plugin --with-plugin-ld=ld.gold --with-linker-hash-style=gnu --disable-multilib --disable-libssp --disable-build-with-cxx --disable-build-poststage1-with-cxx --enable-checking=release Thread model: posix gcc version 4.7.1 (GCC)
[Bug java/53973] [x32] libjava failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53973 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #6 from H.J. Lu hjl.tools at gmail dot com 2012-07-18 23:50:22 UTC --- Fixed: http://gcc.gnu.org/ml/gcc-testresults/2012-07/msg01494.html
[Bug c++/54024] Internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54024 --- Comment #1 from Ian Mackenzie ian.e.mackenzie at gmail dot com 2012-07-19 00:06:04 UTC --- Created attachment 27828 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27828 Preprocessed source file The preprocessed source file itself is too big (5 MB), so had to be zipped.
[Bug target/53974] [4.8 Regression] Nearly all tests fail with ADA.CALENDAR.TIME_ERROR : a-calend.adb:603
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53974 --- Comment #3 from dave.anglin at bell dot net 2012-07-19 00:33:48 UTC --- On 18-Jul-12, at 6:15 AM, ebotcazou at gcc dot gnu.org wrote: I have seen the same error on SPARC. The fix is * config/sparc/sparc.md (adddi3_insn_sp32): Add earlyclobber. so you might want to try something similar on line 4923 of pa.md. Eric, thanks very much! Even if this doesn't fix the bug, this is obviously a bug. Dave -- John David Anglindave.ang...@bell.net
[Bug c++/51213] [C++11][DR 1170] Access control checking has to be done under SFINAE conditions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51213 --- Comment #6 from Jason Merrill jason at gcc dot gnu.org 2012-07-19 01:36:55 UTC --- Author: jason Date: Thu Jul 19 01:36:50 2012 New Revision: 189639 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189639 Log: DR 1170 PR c++/51213 * semantics.c (perform_access_checks): Add complain parm, return bool. (perform_deferred_access_checks): Likewise. (perform_or_defer_access_check): Likewise. (speculative_access_check): Remove. * call.c (enforce_access): Add complain parm, return bool. * decl.c, friend.c, class.c, init.c, parser.c: Adjust callers. * search.c: Adjust callers. * cp-tree.h (TINFO_RECHECK_ACCESS_P): New macro. (FNDECL_RECHECK_ACCESS_P): New macro. * method.c (synthesized_method_walk): Stop deferring access checks. * pt.c (recheck_decl_substitution): New. (instantiate_template_1): Set and check FNDECL_RECHECK_ACCESS_P. Added: trunk/gcc/testsuite/g++.dg/cpp0x/sfinae37.C trunk/gcc/testsuite/g++.dg/template/access23.C trunk/libstdc++-v3/testsuite/20_util/pair/noncopyable.cc Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/class.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/cp/friend.c trunk/gcc/cp/init.c trunk/gcc/cp/method.c trunk/gcc/cp/parser.c trunk/gcc/cp/pt.c trunk/gcc/cp/search.c trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/template/access7.C trunk/gcc/testsuite/g++.dg/template/sfinae10.C trunk/gcc/testsuite/g++.dg/template/sfinae6_neg.C trunk/libstdc++-v3/ChangeLog
[Bug c++/51213] [C++11][DR 1170] Access control checking has to be done under SFINAE conditions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51213 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #7 from Jason Merrill jason at gcc dot gnu.org 2012-07-19 02:05:00 UTC --- Fixed for 4.8.
[Bug target/22553] [4.6/4.7/4.8 regression] ICE building libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22553 --- Comment #23 from Kazumoto Kojima kkojima at gcc dot gnu.org 2012-07-19 02:36:19 UTC --- (In reply to comment #22) Kaz, if you have some time, could you do something like that http://gcc.gnu.org/ml/gcc-patches/2005-09/msg01539.html again (if possible with mpeg2dec) with GCC 4.8? Here is: (CSiBE with -O2) test namesched1 no-sched1 sched1/no-sched1 bzip2-1.0.2 bzip2.d11.06 10.8067 1.02344 bzip2-1.0.2 bzip2recover4.54333 4.66333 0.974267 bzip2-1.0.2 bzip2.c42.8567 44.2067 0.969462 compiler vam.fib2.00333 1.97 1.01692 compiler vam.fact1.87333 1.88333 0.99469 compiler vam.test20.246667 0.25 0.986667 flex-2.5.31 flex13.1133 13.25 0.989686 jikespg-1.3 src/jikespg1.62 1.59333 1.01674 jpeg-6b jpegtran24.62667 4.74667 0.974719 jpeg-6b djpeg22.19333 2.28667 0.960641 jpeg-6b djpeg12.2 2.26667 0.970588 jpeg-6b cjpeg23.19333 3.05333 1.04585 jpeg-6b djpeg00.33 0.33 1 jpeg-6b cjpeg00.496667 0.496667 1 jpeg-6b cjpeg13.18 3.11667 1.02032 jpeg-6b jpegtran00.256667 0.256667 1 jpeg-6b jpegtran11.98667 2.00667 0.990033 libpng-1.2.5 png2pnm00.97 0.97 1.00344 libpng-1.2.5 pnm2png144.63 44.6933 0.998583 libpng-1.2.5 pnm2png07.94667 7.95 0.999581 libpng-1.2.5 png2pnm16.71667 6.71 1.00099 teem-1.6.0-src src/hex/dehex01.66 1.68 0.988095 teem-1.6.0-src src/hex/dehex110.8967 10.92 0.997863 teem-1.6.0-src src/hex/enhex140.5033 41.2133 0.982773 teem-1.6.0-src src/hex/enhex06.76333 6.86667 0.984951 zlib-1.1.4 minigzip044.73 45.0633 0.992603 zlib-1.1.4 minigzip5.41333 5.41333 1 (not CSiBE test with -O3. 201 frames decoded) mpeg2dec-0.3.12.18 2.22 0.981981
[Bug libstdc++/54025] New: atomicchrono::duration won't compile: chrono::duration::duration() is not C++11 compliant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54025
Bug #: 54025
Summary: atomicchrono::duration won't compile:
chrono::duration::duration() is not C++11 compliant
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: c...@pobox.com
Attempting to compile atomicduration fails, because the duration default
constructor is not = default as required by the standard, but instead
explicitly initializes its representation. Here is what libstdc++ says:
constexpr duration() : __r() { }
but here is what the standard says should be there, and if I make the change,
compilation succeeds:
constexpr duration() = default;
Test source:
#include atomic
#include chrono
using namespace std;
using namespace chrono;
int main() {
atomicdurationlong, micro dur;
}
Error before patch:
/usr/include/c++/4.7/atomic: In instantiation of ‘struct
std::atomicstd::chrono::durationlong int, std::ratio1ll, 100ll ’:
atdur.cc:6:35: required from here
/usr/include/c++/4.7/atomic:160:7: error: function ‘std::atomic_Tp::atomic()
[with _Tp = std::chrono::durationlong int, std::ratio1ll, 100ll ]’
defaulted on its first declaration with an exception-specification that differs
from the implicit declaration ‘constexpr std::atomicstd::chrono::durationlong
int, std::ratio1ll, 100ll ::atomic()’
[Bug libstdc++/54025] atomicchrono::duration won't compile: chrono::duration::duration() is not C++11 compliant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54025 --- Comment #1 from Chip Salzenberg chip at pobox dot com 2012-07-19 02:56:57 UTC --- Created attachment 27829 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27829 patch to duration default ctor
[Bug c++/53954] [C++11] Undefined reference to non-odr-used static const member variable of variadic class template in DSO with -flto and -Wl,--export-dynamic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53954 Ai Azuma ai.azuma at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #5 from Ai Azuma ai.azuma at gmail dot com 2012-07-19 03:12:21 UTC --- Hmm, now I have arrived at the conclusion that non-odr-used variables might require the definition, depending on compiler options etc., and this PR is invalid, since there is no guarantee in the specification that non-odr-used-ness of variables makes the definition unnecessary. I'm sorry. I created this PR based on the wrong assumption. I should have created a PR reporting the bug in libstdc++. And thank you for the quick fixes. Again, thank you for your time.
[Bug debug/53235] [4.8 Regression] 20120504 broke -fdebug-types-section
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53235 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-07-19 AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug c++/54026] New: [4.7/4.8 regression] template const struct with mutable members erroneously emitted to .rodata
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54026
Bug #: 54026
Summary: [4.7/4.8 regression] template const struct with
mutable members erroneously emitted to .rodata
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ppluzhni...@google.com
Reproduced with 4.7 and current trunk:
g++ (GCC) 4.8.0 20120719 (experimental)
// --- cut here ---
void non_const(int *);
template typename T
struct Foo {
T x;
mutable int y;
void func() const { non_const(y); }
};
struct Bar {
int x;
mutable int y;
void func() const { non_const(y); }
};
const Fooint foo = { 1, 2 };
const Bar bar = { 3, 4 };
// --- cut here ---
Results in:
.data
.align 4
.type_ZL3bar, @object
.size_ZL3bar, 8
_ZL3bar:
.long3
.long4
.section.rodata
.align 4
.type_ZL3foo, @object
.size_ZL3foo, 8
_ZL3foo:
.long1
.long2
But it is a bug to place foo into .rodata, since it contains a mutable
member.
[Bug c/54027] New: possible mis-optimization of signed left shift in c89 mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54027
Bug #: 54027
Summary: possible mis-optimization of signed left shift in c89
mode
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reg...@cs.utah.edu
The program below is clearly undefined in C99, but I'm not sure that it should
be undefined in C89 mode.
GCC pre-4.8.0 turns the code into an infinite loop even in C89 mode at -O2 and
higher.
regehr@home:~/svn/code$ cat shift.c
int main (void)
{
int x = 1;
while (x)
x = 1;
return x;
}
regehr@home:~/svn/code$ gcc -O2 -std=c89 shift.c ; ./a.out
^C
regehr@home:~/svn/code$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/regehr/z/compiler-install/gcc-r189449-install/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/regehr/z/compiler-source/gcc/configure
--with-libelf=/usr/local --enable-lto
--prefix=/home/regehr/z/compiler-install/gcc-r189449-install
--enable-languages=c,c++
Thread model: posix
gcc version 4.8.0 20120713 (experimental) (GCC)
[Bug target/22553] [4.6/4.7/4.8 regression] ICE building libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22553 --- Comment #24 from Kazumoto Kojima kkojima at gcc dot gnu.org 2012-07-19 04:58:46 UTC --- With -fPIC (CSiBE with -O2 -fPIC) test namesched1 no-sched1 sched1/no-sched1 bzip2-1.0.2 bzip2.d 11.1433 11.1833 0.996423 bzip2-1.0.2 bzip2recover 5.15333 5.14667 1.0013 bzip2-1.0.2 bzip2.c 43.3033 43.61 0.992968 compiler vam.fib 1.99333 2 0.996667 compiler vam.fact 1.87667 1.89667 0.989455 compiler vam.test2 0.27 0.26 1.01266 flex-2.5.31 flex 15.3 15.3 1 jikespg-1.3 src/jikespg 1.68 1.7 1.008 jpeg-6b jpegtran2 4.76 4.76333 0.9993 jpeg-6b djpeg2 2.41333 2.43 0.993141 jpeg-6b djpeg1 2.37333 2.36333 1.00423 jpeg-6b cjpeg2 3.01333 3.05333 0.9869 jpeg-6b djpeg0 0.35 0.32 1.08247 jpeg-6b cjpeg0 0.496667 0.476667 1.04196 jpeg-6b cjpeg1 3.08 3.07 1.00326 jpeg-6b jpegtran0 0.256667 0.27 0.9625 jpeg-6b jpegtran1 1.94333 1.95333 0.994881 libpng-1.2.5 png2pnm0 0.98 0.97 1.01031 libpng-1.2.5 pnm2png1 45 44.9667 1.00074 libpng-1.2.5 pnm2png0 7.99 7.99333 0.999583 libpng-1.2.5 png2pnm1 6.74333 6.78333 0.994103 teem-1.6.0-src src/hex/dehex0 1.69 1.67333 1.00996 teem-1.6.0-src src/hex/dehex1 11.0433 11.01 1.00303 teem-1.6.0-src src/hex/enhex1 41.0633 40.5333 1.01308 teem-1.6.0-src src/hex/enhex0 6.25667 6.24 1.00267 zlib-1.1.4 minigzip0 44.1267 44.1467 0.999547 zlib-1.1.4 minigzip 5.30667 5.30333 1.00063 (not CSiBE test with -O3 -fPIC. 201 frames decoded) mpeg2dec-0.3.12.27 2.27 1
