[Bug target/49001] GCC uses VMOVAPS/PD AVX instructions to access stack variables that are not 32-byte aligned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49001 --- Comment #3 from Norbert Pozar npozar at quick dot cz 2011-05-16 06:05:37 UTC --- (In reply to comment #1) Please provide testcase that can be compiled without changes. See [1]. I'm sorry about this. Probably mingw64 specific problem... CC added. Thank you for your time to test the code on linux. I was worried that this might be mingw64 specific. (In reply to comment #2) Stack alignment isn't supported on Windows. Since this bug effectively prevents using 256bit AVX instructions when compiling for Windows using GCC, I was wondering if there are any plans to support the stack alignment. It seems that simply adding andq$-32, %rsp to the function prologue would fix this. Or would it be feasible to replace VMOVAPS by unaligned VMOVUPS when accessing the stack?
[Bug middle-end/49009] New: internal compiler error: verify_gimple failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49009 Summary: internal compiler error: verify_gimple failed Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: joost.vandevond...@pci.uzh.ch current trunk fails with gfortran -flto -c bug.f90 bug.f90: In function ‘__min_heap_MOD_heap_pop’: bug.f90:13:0: error: invalid types in truth not logical(kind=4) logical(kind=4) D.1556_3 = !D.1555_2; bug.f90:13:0: internal compiler error: verify_gimple failed cat bug.f90 MODULE min_heap TYPE heap_t INTEGER :: n END TYPE heap_t CONTAINS SUBROUTINE heap_pop (heap, key, value, found, error) TYPE(heap_t), INTENT(INOUT) :: heap LOGICAL, INTENT(OUT) :: found, error IF (.NOT. error .AND. found) THEN IF (heap%n .GT. 1) THEN ENDIF ENDIF END SUBROUTINE heap_pop END MODULE min_heap
[Bug fortran/48955] [4.6/4.7 Regression] Wrong result for array assignment due to missing temporary
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48955 --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2011-05-16 07:27:07 UTC --- Submitted patch: http://gcc.gnu.org/ml/fortran/2011-05/msg00090.html It fixes the test case of comment 0, but (cf. review comment) it does not handle a modified version.
[Bug middle-end/49009] internal compiler error: verify_gimple failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49009 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-05-16 07:26:55 UTC --- Duplicate of 48989. A patch has been submitted at http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01033.html . *** This bug has been marked as a duplicate of bug 48989 ***
[Bug middle-end/48989] [4.7 Regression] FAIL: gfortran.dg/lto/pr46036 f_lto_pr46036_0.o assemble
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48989 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||Joost.VandeVondele at pci ||dot uzh.ch --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-05-16 07:26:55 UTC --- *** Bug 49009 has been marked as a duplicate of this bug. ***
[Bug target/46934] gcc ICE: error: unrecognizable insn: in extract_insn, at recog.c:2109
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46934 Chung-Lin Tang cltang at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from Chung-Lin Tang cltang at gcc dot gnu.org 2011-05-16 08:09:48 UTC --- This is fixed now.
[Bug fortran/49010] New: Result of MOD and MODULO intrinsic has wrong sign
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49010 Summary: Result of MOD and MODULO intrinsic has wrong sign Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: thenl...@users.sourceforge.net If the first argument to the MOD and MODULO intrinsic is negative, and the magnitude of the result is zero, the function returns a negative zero. Fortran 2003/2008: MOD: The value of the result is A − INT (A/P) * P. MODULO: The value of the result is A − FLOOR (A / P) * P. The values returned by these intrinsics should be the same as the expressions by which the functions are defined; which is zero, without a negative sign. Example: program test_mod real :: a, p a = -4.0 p = 2.0 print *, mod(a, p), a - int(a / p) * p ! -0 0 expected 0 0 print *, modulo(a, p), a - floor(a / p) * p ! -0 0 expected 0 0 end program test_mod
[Bug target/48941] [arm gcc] NEON: Stack pointer operations performed even tho stack is not accessed at all in function.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48941 --- Comment #4 from Richard Earnshaw rearnsha at gcc dot gnu.org 2011-05-16 08:13:04 UTC --- (In reply to comment #3) Created attachment 24234 [details] Proposed patch The attached patch seems to fix the testcase and doesn't regress neon.exp. I'll test it fully next week. We still generate more moves than necessary, but that's a separate problem. I think we should try to preserve the existing internal API, so that if someone manages to pick up an older version of arm_neon.h they won't get bizarre errors out of the compiler.
[Bug fortran/49011] New: Wrong repeat count in error message for REPEAT intrinsic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49011 Summary: Wrong repeat count in error message for REPEAT intrinsic Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: thenl...@users.sourceforge.net If the REPEAT intrinsic is given a negative NCOPIES argument at runtime, in the resulting error message an erraneous value is printed. Example: program test_repeat integer :: i = -1 print *, repeat(x, i) end program test_repeat $ ./a.out At line 3 of file test_repeat.f90 Fortran runtime error: Argument NCOPIES of REPEAT intrinsic is negative (its value is 4294967295) Expected result: At line 3 of file test_repeat.f90 Fortran runtime error: Argument NCOPIES of REPEAT intrinsic is negative (its value is -1)
[Bug c++/49004] Improve the error message for linking failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49004 Mu Qiao qiaomuf at gentoo dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #3 from Mu Qiao qiaomuf at gentoo dot org 2011-05-16 08:51:02 UTC --- Ok, I reported this problem in the binutil bug tracker: http://sourceware.org/bugzilla/show_bug.cgi?id=12768 Mark this as bug as invalid.
[Bug tree-optimization/49006] [4.6/4.7 Regression] Missed vectorization due to revision 167531
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49006 --- Comment #1 from rguenther at suse dot de rguenther at suse dot de 2011-05-16 08:57:46 UTC --- On Sun, 15 May 2011, dominiq at lps dot ens.fr wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49006 Summary: [4.6/4.7 Regression] Missed vectorization due to revision 167531 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: rgue...@gcc.gnu.org Created attachment 24250 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24250 source code On x86_64-apple-darwin10 the attached code (an avatar of the polyhedron test induct.f90) is no longer properly vectorized after revision 167531: The patch changes inliner heuristics only.
[Bug fortran/49011] Wrong repeat count in error message for REPEAT intrinsic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49011 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.05.16 09:22:14 Ever Confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-05-16 09:22:14 UTC --- On x86_64-apple-darwin10, the test returns Fortran runtime error: Argument NCOPIES of REPEAT intrinsic is negative (its value is -1) with -m64 (default). The value returned with -m32 depends on the version: 72057598332895231 for 4.4.4 and 4.5.2, 118064355999743 for 4.6.0 (r169227), and 4294967295 for trunk (r173786).
[Bug tree-optimization/49006] [4.6/4.7 Regression] Missed vectorization due to revision 167531
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49006 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-05-16 09:24:28 UTC --- The patch changes inliner heuristics only. Yes, but the vectorization of induct.f90 is very sensitive to inlining: see pr34265. Did you checked the vectorization of the test case on your favorite platform?
[Bug fortran/49010] Result of MOD and MODULO intrinsic has wrong sign
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49010 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2011-05-16 10:18:20 UTC --- I obtain as result for the test program: -0 0; -0 0 If a and p are PARAMETERs, the result is: 0 0; 0 0.
[Bug tree-optimization/49006] [4.6/4.7 Regression] Missed vectorization due to revision 167531
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49006 --- Comment #3 from rguenther at suse dot de rguenther at suse dot de 2011-05-16 10:41:58 UTC --- On Mon, 16 May 2011, dominiq at lps dot ens.fr wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49006 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-05-16 09:24:28 UTC --- The patch changes inliner heuristics only. Yes, but the vectorization of induct.f90 is very sensitive to inlining: see pr34265. Did you checked the vectorization of the test case on your favorite platform? I did not check it at all. The patch causes more inlining, making the cost of x*x the same with/without -ffast-math. Richard.
[Bug fortran/49011] Wrong repeat count in error message for REPEAT intrinsic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49011
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2011-05-16
10:15:03 UTC ---
With -m64:
_gfortran_runtime_error_at (At line 3 of file foo.f90[1]{lb: 1 sz: 1},
Argument NCOPIES of REPEAT intrinsic is negative (its value is %lld)[1]{lb:
1 sz: 1}, (integer(kind=8)) D.1547);
With -m32:
_gfortran_runtime_error_at (At line 3 of file foo.f90[1]{lb: 1 sz: 1},
Argument NCOPIES of REPEAT intrinsic is negative (its value is %lld)[1]{lb:
1 sz: 1}, (unnamed-signed:32) D.1501);
Thus, in both cases the argument value is wrongly cast; cf. POSIX's printf(3):
ll (ell-ell)
Specifies that a following d , i , o , u , x , or X
conversion specifier applies to a long long or
unsigned long long argument; or that a following n
conversion specifier applies to a pointer to a long
long argument.
[Bug c++/45853] Segfault while experimenting with c++-0x initializer lists
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45853 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011.05.16 11:00:14 Ever Confirmed|0 |1 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2011-05-16 11:00:14 UTC --- please try to reproduce this with a current FSF release or report it to Ubuntu for C++0x bugs please try 4.5 or later, lots of initializer list bugs have been fixed already
[Bug c++/48999] [4.7 Regression] FAIL: g++.dg/torture/20090706-1.C due to an ICE on *-*-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48999 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug c/48996] fixincl on Red Hat EL 5 breaks sys/stat.h fstat64()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48996 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011.05.16 11:04:03 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-05-16 11:04:03 UTC --- Please provide the un-fixincluded sys/stat.h file.
[Bug tree-optimization/49006] [4.6/4.7 Regression] Missed vectorization due to revision 167531
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49006 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.1
[Bug rtl-optimization/48986] Missed optimization in atomic decrement on x86/x64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48986
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|NEW
CC||uros at gcc dot gnu.org
AssignedTo|jakub at gcc dot gnu.org|unassigned at gcc dot
||gnu.org
--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-16
11:26:51 UTC ---
On:
int
foo (int *p)
{
return __sync_fetch_and_add (p, -1) == 1;
}
int
bar (int *p)
{
return __sync_add_and_fetch (p, -1) == 0;
}
I get better generated code for the second routine if I do:
--- gcc/config/i386/sync.md.jj 72010-05-21 11:46:29.0 +0200
+++ gcc/config/i386/sync.md 2011-05-16 13:06:13.0 +0200
@@ -170,7 +170,7 @@
[(match_operand:SWI 1 memory_operand +m)] UNSPECV_XCHG))
(set (match_dup 1)
(plus:SWI (match_dup 1)
- (match_operand:SWI 2 register_operand 0)))
+ (match_operand:SWI 2 nonmemory_operand 0)))
(clobber (reg:CC FLAGS_REG))]
TARGET_XADD
lock{%;} xadd{imodesuffix}\t{%0, %1|%1, %0})
and for foo identical code, so maybe that change is always beneficial, allowing
combiner and other early RTL passes to see there a constant instead of a REG.
Unfortunately, even with this change the combiner doesn't attempt to combine
this pattern with the following cmpsi_1 pattern, supposedly because
sync_old_addsi pattern isn't single_set. I guess we could handle this during
expansion, but it would be a mess, or some other pass (e.g. peephole2 or
something similar). peephole2 might kind of too late though, by that time the
constant must be loaded already into some register, so we'd need to peephole2 3
insns, where the load of the constant might often not be the first one.
[Bug target/48554] Regression for coldfire platform
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48554 --- Comment #3 from Mikael Pettersson mikpe at it dot uu.se 2011-05-16 11:52:32 UTC --- gcc-4.6-20110513 still ICEs on this test case, but after backporting the fix for PR47612 (r173393) compilation succeeds.
[Bug c++/49003] [C++0x] decltype in member function's trailing return type should deduce constness of *this
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49003 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-05-16 11:09:05 UTC --- ah I was thinking of PR 45908 (where I provided that reduced testcase - I knew it looked familiar!) but that was for an ICE which is fixed, so this one should be kept for the change in semantics
[Bug c++/45873] Parameter packs not expanding consistently in function return types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45873
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-05-16
12:01:31 UTC ---
Jason, should deduction succeed here?
templateclass, class
struct pair
{
templateclass T1, class U1
pair(T1 t, U1 u) { }
};
template template class... class T, class ...Args
auto foo(Args... args) - TArgs...
{ return TArgs...(args...); }
int main()
{
// error: no matching function for call to 'foo(int, double)'
foopair(1, 2.0);
}
It looks as though substituting T=pair fails because T's single parameter pack
fails to match pair's two parameters.
If pair is a variadic template with exactly one parameter pack , like p0 below,
then it matches T:
templateclass... struct p0 { };
templateclass, class... struct p1 { };
templateclass, class, class... struct p2 { };
template template class... class T, class ...Args
auto foo(Args... args) - TArgs...
{ return TArgs...(); }
int main()
{
foop0(1, 2.0); // ok
foop1(1, 2.0); // error
foop2(1, 2.0); // error
}
Is this behaviour correct?
Clang accepts all three calls
[Bug bootstrap/48679] [4.7 regression] bootstrap comparison failures on m68k-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48679 --- Comment #7 from Mikael Pettersson mikpe at it dot uu.se 2011-05-16 12:17:45 UTC --- The bootstrap comparison failure appears to be gone in a c-only build of gcc-4.7-20110514. I'll run a bisect to identify which rev fixed this bug.
[Bug c/48996] fixincl on Red Hat EL 5 breaks sys/stat.h fstat64()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48996 --- Comment #2 from psmith at gnu dot org 2011-05-16 11:56:33 UTC --- Created attachment 24251 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24251 Un-fixed sys/stat.h Yes, sorry, it was silly not to have done that.
[Bug target/48986] Missed optimization in atomic decrement on x86/x64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48986 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-16 12:50:59 UTC --- Created attachment 24252 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24252 gcc47-pr48986.patch Untested patch using peephole2.
[Bug fortran/48955] [4.6/4.7 Regression] Wrong result for array assignment due to missing temporary
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48955 --- Comment #6 from paul.richard.thomas at gmail dot com paul.richard.thomas at gmail dot com 2011-05-16 12:48:32 UTC --- Indeed - I just need to find the time to sort out the logic. Structurally the patch is OK. Cheers Paul On Mon, May 16, 2011 at 9:56 AM, burnus at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48955 --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2011-05-16 07:27:07 UTC --- Submitted patch: http://gcc.gnu.org/ml/fortran/2011-05/msg00090.html It fixes the test case of comment 0, but (cf. review comment) it does not handle a modified version. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. You are the assignee for the bug.
[Bug c/48996] fixincl on Red Hat EL 5 breaks sys/stat.h fstat64()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48996
--- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-05-16
13:07:56 UTC ---
I don't see anything wrong with the fixinclude though it is a bit fragile
as it wants to fixup both prototype and redicrected inline function and
both are not guarded with the same #ifdefs:
#ifdef __USE_LARGEFILE64
extern int stat64 (__const char *__restrict __file,
struct stat64 *__restrict __buf) __THROW __nonnull ((1, 2));
extern int fstat64 (int __fd, struct stat64 *__buf) __THROW __nonnull ((2));
#endif
but
# if defined __USE_LARGEFILE64 \
(! defined __USE_FILE_OFFSET64 \
|| (defined __REDIRECT_NTH defined __OPTIMIZE__))
extern __inline__ int
__NTH (fstat64 (int __fd, struct stat64 *__statbuf))
{
return __fxstat64 (_STAT_VER, __fd, __statbuf);
}
...
so if only the fixed fstat64 prototype remains after preprocessing that
will trigger the error you saw.
So, do you have a testcase that fails to build? And which flags do
you pass?
[Bug c/49012] New: weak const optimisations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49012
Summary: weak const optimisations
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: etienne_lorr...@yahoo.fr
With newer GCC compilers,
const struct { int a,b; } mystruct = {15, 0};
int adder (int x) { return x + mystruct.b; };
there isn't any addition performed in adder() because GCC knows that mystruct.b
is null,
and assumes that nobody is initialising mystruct.b is assembler or declaring
mystruct as
non-const in another module.
But if we add the weak attribute to mystruct, GCC-4.4.5 does the addition in
case mystruct
has been pre-loaded by for instance LD_PRELOAD, GCC-4.6 do not do the addition.
const struct { int a,b; } mystruct __attribute__((weak))= {15, 0};
int adder (int x) { return x + mystruct.b; };
LD_PRELOAD=/home/etienne/projet/toolchain/lib/libmpc.so.2:/home/etienne/projet/toolchain/lib/libgmp.so.10
/home/etienne/projet/toolchain/bin/gcc -Os -fomit-frame-pointer -S t.c -o t.s
gives:
.filet.c
.text
.globladder
.typeadder, @function
adder:
.LFB0:
.cfi_startproc
movl4(%esp), %eax
ret
.cfi_endproc
.LFE0:
.sizeadder, .-adder
.weakmystruct
.section.rodata
.align 4
.typemystruct, @object
.sizemystruct, 8
mystruct:
.long15
.long0
.identGCC: (GNU) 4.6.0
.section.note.GNU-stack,,@progbits
[Bug c/49012] weak const optimisations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49012 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-16 13:46:10 UTC --- You aren't compiling with -fpic, therefore the weak attribute is there irrelevant - the symbol is known to be defined in the current TU, and for anything that goes into the executable it can't be overridden. Note LD_PRELOAD inserts preloaded lib symbol search scope after executables, not before.
[Bug c++/48999] [4.7 Regression] FAIL: g++.dg/torture/20090706-1.C due to an ICE on *-*-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48999 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Target Milestone|4.7.0 |---
[Bug target/45099] [avr] Warning could be issued for use of register variables that will fail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45099 --- Comment #1 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-05-16 14:16:30 UTC --- Author: gjl Date: Mon May 16 14:16:22 2011 New Revision: 173791 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173791 Log: PR target/45099 * config/avr/avr.c (avr_function_arg_advance): Error if a fixed register is needed for a function argument. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.c
[Bug c++/48999] [4.7 Regression] FAIL: g++.dg/torture/20090706-1.C due to an ICE on *-*-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48999 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug target/41076] [avr] pessimal code for logical OR of 8-bit fields
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41076 --- Comment #2 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-05-16 14:20:25 UTC --- Author: gjl Date: Mon May 16 14:20:19 2011 New Revision: 173792 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173792 Log: PR target/27663 PR target/41076 * config/avr/predicates.md (const_8_16_24_operand): New predicate. * config/avr/avr.md (*iormodeqi.byte0, *iormodeqi.byte1-3): New define_insn_and_split patterns. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.md trunk/gcc/config/avr/predicates.md
[Bug middle-end/27663] missed-optimization transforming a byte array to unsigned long
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27663 --- Comment #6 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-05-16 14:20:25 UTC --- Author: gjl Date: Mon May 16 14:20:19 2011 New Revision: 173792 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173792 Log: PR target/27663 PR target/41076 * config/avr/predicates.md (const_8_16_24_operand): New predicate. * config/avr/avr.md (*iormodeqi.byte0, *iormodeqi.byte1-3): New define_insn_and_split patterns. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.md trunk/gcc/config/avr/predicates.md
[Bug c/49012] weak const optimisations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49012
--- Comment #2 from etienne_lorrain at yahoo dot fr 2011-05-16 14:36:41 UTC ---
Well, with gcc-4.4.5-8 the weak attribute did the trick:
$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.5-8'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.4 --enable-shared --enable-multiarch
--enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
--enable-targets=all --with-arch-32=i586 --with-tune=generic
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.4.5 (Debian 4.4.5-8)
$ cat t.c
//const struct { int a,b; } mystruct __attribute__((weak))= {15, 0};
const struct { int a,b; } mystruct = {15, 0};
int adder (int x) { return x + mystruct.b; };
$ gcc -Os -fomit-frame-pointer t.c -S -o t.s
$ cat t.s
.filet.c
.text
.globl adder
.typeadder, @function
adder:
movl4(%esp), %eax
ret
.sizeadder, .-adder
.globl mystruct
.section.rodata
.align 4
.typemystruct, @object
.sizemystruct, 8
mystruct:
.long15
.long0
.identGCC: (Debian 4.4.5-8) 4.4.5
.section.note.GNU-stack,,@progbits
$ cat t.c
const struct { int a,b; } mystruct __attribute__((weak))= {15, 0};
//const struct { int a,b; } mystruct = {15, 0};
int adder (int x) { return x + mystruct.b; };
$ cat t.s
.filet.c
.text
.globl adder
.typeadder, @function
adder:
movl4(%esp), %eax
addlmystruct+4, %eax
ret
.sizeadder, .-adder
.weakmystruct
.section.rodata
.align 4
.typemystruct, @object
.sizemystruct, 8
mystruct:
.long15
.long0
.identGCC: (Debian 4.4.5-8) 4.4.5
.section.note.GNU-stack,,@progbits
But in fact I just discovered volatile const structures which enables me to
have a C constant
initialised at run-time by the assembly preceding main(), so personally I do
not need this
weak trick.
Thanks for the quick answer,
Etienne.
[Bug c++/48999] [4.7 Regression] FAIL: g++.dg/torture/20090706-1.C due to an ICE on *-*-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48999 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2011-05-16 14:30:36 UTC --- Author: jason Date: Mon May 16 14:30:30 2011 New Revision: 173793 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173793 Log: PR c++/48999 * tree-inline.c (copy_statement_list): Put back recursion. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-inline.c
[Bug target/45099] [avr] Warning could be issued for use of register variables that will fail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45099 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||gjl at gcc dot gnu.org Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #2 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-05-16 14:36:32 UTC --- Closed as resolved+fixed according to the patch above. The patch issues an error and not a warning as indicated in the PR. This is because the code will break at runtime if it reaches the spot, anyway, so the program will always show malfunction. A global register is *global*, so it would be an error to save/restore it in function prologue/epilogue. For that reason, avr-gcc explicitely excludes global registers from prologue/epilogue (otherwise the value of a global reg could never escape a function, as opposed to being global).
[Bug c++/49003] [C++0x] decltype in member function's trailing return type should deduce constness of *this
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49003
--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2011-05-16
14:48:13 UTC ---
A simpler test for DR 1207 being implemented is:
struct A {
auto a() const - decltype(this) { return this; }
};
nc.cc:2:32: error: invalid use of 'this' at top level
nc.cc:2:32: error: invalid use of 'this' at top level
The late-specified return type should be accepted with the same type as the
return statement's expression i.e. const A*
[Bug middle-end/27663] missed-optimization transforming a byte array to unsigned long
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27663
Georg-Johann Lay gjl at gcc dot gnu.org changed:
What|Removed |Added
CC||gjl at gcc dot gnu.org
Known to fail||
--- Comment #7 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-05-16
15:05:41 UTC ---
The patch tries to fix the middle-end flaw in the BE by introducing some
combine patterns that recognize byte-insert.
Wouldn't it be possible to recognize such situations in the middle-end and map
them to something like (set (zero_extract:QI (reg:SI) ...)) or (set (subreg:QI
(reg:SI) ...)?
Even if the bytes inserted do not come from consecutive memory locations, such
a recognition would help.
The patch does not lead to optimal code, there is still room for improvement:
With -Os -mmcu=atmega8:
f:
push r16
push r17
/* prologue: function */
/* frame size = 0 */
/* stack size = 2 */
.L__stack_usage = 2
movw r30,r24
ldd r24,Z+1
ldd r16,Z+2
ldi r17,lo8(0)
ldi r18,lo8(0)
ldi r19,hi8(0)
movw r18,r16
clr r17
clr r16
or r19,r24
ldd r24,Z+4
or r16,r24
ldd r24,Z+3
or r17,r24
movw r22,r16
movw r24,r18
/* epilogue start */
pop r17
pop r16
ret
The usage of r16/r17 might be an artifact of IRA because only half of a SI reg
is call-saved, the other half is call-used. There is the following comment in
ira-color.c:
/* We need to save/restore the hard register in
epilogue/prologue. Therefore we increase the cost. */
{
/* ??? If only part is call clobbered. */
Despite subreg lowering, the call-used r26/r27 are not used.
Maybe you should also try to disable subreg lowering by means of
-fno-split-wide-types. For the code in question that gives:
With -Os -mmcu=atmega8 -fno-split-wide-types:
f:
/* prologue: function */
/* frame size = 0 */
/* stack size = 0 */
.L__stack_usage = 0
movw r30,r24
ldd r18,Z+1
ldd r22,Z+2
mov r24,r22
ldi r25,lo8(0)
ldi r26,lo8(0)
ldi r27,hi8(0)
clr r23
clr r22
or r25,r18
ldd r18,Z+4
or r22,r18
ldd r18,Z+3
or r23,r18
/* epilogue start */
ret
What I do not understand are the insns clearing r26/r27 because they are dead
(which is not detected). It is an HI insn that looks like that:
; (insn 32 34 42 (set (reg:HI 26 r26 [ MEM[(unsigned char *)P_1(D) + 2B]+2 ])
; (const_int 0 [0])) insert-byte.c:5 10 {*movhi}
; (nil))
ldi r26,lo8(0) ; 32*movhi/1[length = 2]
ldi r27,hi8(0)
[Bug c/48996] fixincl on Red Hat EL 5 breaks sys/stat.h fstat64()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48996 --- Comment #4 from psmith at gnu dot org 2011-05-16 15:07:40 UTC --- I'm attaching a small test program that fails for me. I'm just running the compiler with c++ -o tstfstat.o -c tstfstat.cpp; no extra flags. After looking more carefully I can see that when I build this without optimization I get this problem; the ifdef around the definition of the inline version is: # if defined __USE_LARGEFILE64 \ (! defined __USE_FILE_OFFSET64 \ || (defined __REDIRECT_NTH defined __OPTIMIZE__)) In my system __USE_LARGEFILE64 is 1, __USE_FILE_OFFSET64 is 1, and __REDIRECT_NTH is defined. So, this entire if statement is true if __OPTIMIZE__ is true, and false otherwise. On the other hand the declaration doesn't care about __OPTIMIZE__; it declares the function to be __inline__ regardless. Sure enough, when I add -O2 to the compile line I don't see any complaints from the compiler. However that's not something I can do :-).
[Bug c/48996] fixincl on Red Hat EL 5 breaks sys/stat.h fstat64()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48996 --- Comment #5 from psmith at gnu dot org 2011-05-16 15:08:35 UTC --- Created attachment 24253 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24253 Test invocation of fstat64()
[Bug c++/45873] Parameter packs not expanding consistently in function return types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45873 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2011-05-16 15:42:36 UTC --- This seems like a dup of 35722.
[Bug rtl-optimization/49007] ICE in extract_true_false_edges_from_block at tree-cfg.c:7379
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49007 --- Comment #4 from dave at hiauly1 dot hia.nrc.ca 2011-05-16 16:22:28 UTC --- On Mon, 16 May 2011, danglin at gcc dot gnu.org wrote: By trial and error, it appears tree-cfgcleanup.c is miscompiled at -O1 without -fno-delayed-branch. Attached .i file. Dave
[Bug c++/45873] Parameter packs not expanding consistently in function return types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45873 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2011-05-16 17:04:12 UTC --- (In reply to comment #3) This seems like a dup of 35722. Ah yes, it definitely is for the call to foop1 in my second example in comment 2: modifying pt.c to always complain at the FIXME in coerce_template_parms produces the sorry for the call to foop1 45873.c2.cc: In function 'int main()': 45873.c2.cc:14:18: sorry, unimplemented: cannot expand 'Args ...' into a fixed-length argument list 45873.c2.cc:14:18: error: no matching function for call to 'foo(int, double)' 45873.c2.cc:14:18: note: candidate is: 45873.c2.cc:8:6: note: templatetemplateclass ... class T, class ... Args TArgs ... foo(Args ...) 45873.c2.cc:15:18: error: no matching function for call to 'foo(int, double)' 45873.c2.cc:15:18: note: candidate is: 45873.c2.cc:8:6: note: templatetemplateclass ... class T, class ... Args TArgs ... foo(Args ...) But that sorry isn't reached for foop2 or for any foopair in the other testcases. I don't know if that means something else is going on there, or if it's just an undiagnosed case of the same situation.
[Bug c++/48999] [4.7 Regression] FAIL: g++.dg/torture/20090706-1.C due to an ICE on *-*-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48999 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Jason Merrill jason at gcc dot gnu.org 2011-05-16 17:30:35 UTC --- Fixed.
[Bug tree-optimization/49000] [4.6/4.7 Regression] ICE: verify_ssa failed with -O2 -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49000 Ian Lance Taylor ian at airs dot com changed: What|Removed |Added CC||ian at airs dot com, ||jamborm at gcc dot gnu.org --- Comment #2 from Ian Lance Taylor ian at airs dot com 2011-05-16 18:00:37 UTC --- Extremely unlikely that that patch introduced the bug. That patch just fixes a bug introduced by 2010-09-10 Martin Jambor mjam...@suse.cz PR tree-optimization/44972 * ipa-prop.c (ipa_modify_call_arguments): Build MEM_REF instead of calling build_ref_for_offset. Since that patch, Martin has rewritten the code further. Adding Martin to CC in case this is somehow related to that work. As far as I can see, the bug here is either that a GIMPLE_DEBUG statement has been created with a memory op, or that gimple_has_mem_ops returns false for GIMPLE_DEBUG. It looks like the GIMPLE_DEBUG statement is created when l_234 is addressable, but l_234 later becomes addressable due to inlining. So something has to change somewhere when that happens.
[Bug tree-optimization/49000] [4.6/4.7 Regression] ICE: verify_ssa failed with -O2 -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49000 Ian Lance Taylor ian at airs dot com changed: What|Removed |Added CC||aoliva at gcc dot gnu.org --- Comment #3 from Ian Lance Taylor ian at airs dot com 2011-05-16 18:01:25 UTC --- Adding lxo as this is related to DEBUG insns.
[Bug fortran/48955] [4.6/4.7 Regression] Wrong result for array assignment due to missing temporary
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48955 --- Comment #7 from tkoenig at netcologne dot de tkoenig at netcologne dot de 2011-05-16 18:10:03 UTC --- Hi Paul, Indeed - I just need to find the time to sort out the logic. Structurally the patch is OK. I think the logic could be as follows: You could have two flags, one FORWARD_ALLOWED and one BACKWARD_ALLOWED. Initialize both flags to true. Run through all the references which could introduce a dependency. If there is a GFC_EQUAL dependency, do nothing. If there is a GFC_FORWARD dependency, set BACKWARD_ALLOW to false. If there is a GFC_BACKWARD dependency, set FORWARD_ALLOW to false. When selecting the loop direction: - If FORWARD_ALLOW is set, select a forward loop; else If BACKWARD_ALLOW is set, select a forward loop; else mark this dimension as needing a temporary. Does this sound OK? Thomas
[Bug preprocessor/48677] cpp.exe broken ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48677 --- Comment #17 from Joseph S. Myers jsm28 at gcc dot gnu.org 2011-05-16 18:34:34 UTC --- Author: jsm28 Date: Mon May 16 18:34:31 2011 New Revision: 173801 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173801 Log: PR preprocessor/48677 * cppspec.c (lang_specific_driver): Set new_decoded_options[0] from decoded_options[0], not from itself. Modified: trunk/gcc/ChangeLog trunk/gcc/cppspec.c
[Bug bootstrap/49013] New: [4.7 Regression] LTO bootstrap failed with bootstrap-profiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49013 Summary: [4.7 Regression] LTO bootstrap failed with bootstrap-profiled Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com On Linux/x86-64, revision 173795 gave ../../src-trunk/gcc/read-md.c: In function 'print_c_condition': ../../src-trunk/gcc/read-md.c:230:1: internal compiler error: in splice_child_die, at dwarf2out.c:8274 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[7]: *** [/tmp/cc1LdCxa.ltrans2.ltrans.o] Error 1 lto-wrapper: make returned 2 exit status /usr/local/x86_64-unknown-linux-gnu/bin/ld: lto-wrapper failed collect2: ld returned 1 exit status make[6]: *** [build/genpreds] Error 1 In file included from ../../src-trunk/gcc/gensupport.c:312:0, from :82: ../../src-trunk/gcc/read-md.c: In function 'read_char': ../../src-trunk/gcc/read-md.c:517:9: internal compiler error: in splice_child_die, at dwarf2out.c:8274 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[7]: *** [/tmp/ccqJAwqa.ltrans4.ltrans.o] Error 1 make[7]: *** Waiting for unfinished jobs lto-wrapper: make returned 2 exit status /usr/local/x86_64-unknown-linux-gnu/bin/ld: lto-wrapper failed collect2: ld returned 1 exit status make[6]: *** [build/genattr] Error 1 In file included from ../../src-trunk/gcc/gensupport.c:312:0, from :82: ../../src-trunk/gcc/read-md.c: In function 'read_char': ../../src-trunk/gcc/read-md.c:517:9: internal compiler error: in splice_child_die, at dwarf2out.c:8274 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[7]: *** [/tmp/ccl8rWMa.ltrans4.ltrans.o] Error 1 make[7]: *** Waiting for unfinished jobs lto-wrapper: make returned 2 exit status /usr/local/x86_64-unknown-linux-gnu/bin/ld: lto-wrapper failed collect2: ld returned 1 exit status make[6]: *** [build/gencodes] Error 1 In file included from ../../src-trunk/gcc/gensupport.c:312:0, from :82: ../../src-trunk/gcc/read-md.c: In function 'read_char': ../../src-trunk/gcc/read-md.c:517:9: internal compiler error: in splice_child_die, at dwarf2out.c:8274 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[7]: *** [/tmp/ccMyblKa.ltrans4.ltrans.o] Error 1 make[7]: *** Waiting for unfinished jobs lto-wrapper: make returned 2 exit status /usr/local/x86_64-unknown-linux-gnu/bin/ld: lto-wrapper failed collect2: ld returned 1 exit status make[6]: *** [build/genconfig] Error 1 In file included from ../../src-trunk/gcc/gensupport.c:312:0, from :82: ../../src-trunk/gcc/read-md.c: In function 'read_char': ../../src-trunk/gcc/read-md.c:517:9: internal compiler error: in splice_child_die, at dwarf2out.c:8274 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[7]: *** [/tmp/ccxpFOla.ltrans5.ltrans.o] Error 1 make[7]: *** Waiting for unfinished jobs lto-wrapper: make returned 2 exit status /usr/local/x86_64-unknown-linux-gnu/bin/ld: lto-wrapper failed collect2: ld returned 1 exit status make[6]: *** [build/genflags] Error 1 In file included from ../../src-trunk/gcc/gensupport.c:320:0, from :86: ../../src-trunk/gcc/read-md.c: In function 'read_char': ../../src-trunk/gcc/read-md.c:487:9: internal compiler error: in splice_child_die, at dwarf2out.c:8274 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[7]: *** [/tmp/cc0kEiJc.ltrans4.ltrans.o] Error 1 make[7]: *** Waiting for unfinished jobs In file included from ../../src-trunk/gcc/read-md.c:344:0, from :89: ../../src-trunk/gcc/read-md.c: In function 'read_char': ../../src-trunk/gcc/read-md.c:332:9: internal compiler error: in splice_child_die, at dwarf2out.c:8274 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. lto1: internal compiler error: in splice_child_die, at dwarf2out.c:8274 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. profiling:/export/gnu/import/svn/gcc-test-profile/bld/libiberty/filename_cmp.gcda:Invocation mismatch - some data files may have been removedprofiling:/export/gnu/import/svn/gcc-test-profile/bld/gcc/insn-recog.gcda:Invocation mismatch - some data files may have been removedmake[7]: *** [/tmp/cc0kEiJc.ltrans6.ltrans.o] Error 1 make[7]: *** [/tmp/cc0kEiJc.ltrans8.ltrans.o] Error 1 lto-wrapper: make
[Bug rtl-optimization/49014] New: ICE: in reset_sched_cycles_in_current_ebb, at sel-sched.c:7132 with even more insane set of flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49014 Summary: ICE: in reset_sched_cycles_in_current_ebb, at sel-sched.c:7132 with even more insane set of flags Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz CC: a...@gcc.gnu.org Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 24255 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24255 reduced testcase (from gcc.dg/pr45352-3.c) Compiler output: $ gcc testcase.c -O -fprofile-generate -fgcse -fno-gcse-lm -fno-tree-loop-im -funroll-loops -fno-web -fschedule-insns2 -fselective-scheduling2 -fsel-sched-pipelining -fPIC -fno-forward-propagate -ftree-vrp testcase.c: In function 'foo': testcase.c:11:1: internal compiler error: in reset_sched_cycles_in_current_ebb, at sel-sched.c:7132 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Tested revisions: r173785 - crash 4.6 r173059 - OK 4.5 r173059 - OK
[Bug c++/45853] Segfault while experimenting with c++-0x initializer lists
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45853 --- Comment #5 from James Michael DuPont JamesMikeDuPont at googlemail dot com 2011-05-16 19:17:06 UTC --- Ok, I will have to look into it, thanks, mike On Mon, May 16, 2011 at 1:19 PM, redi at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45853 Jonathan Wakely redi at gcc dot gnu.org changed: What |Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed| |2011.05.16 11:00:14 Ever Confirmed|0 |1 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2011-05-16 11:00:14 UTC --- please try to reproduce this with a current FSF release or report it to Ubuntu for C++0x bugs please try 4.5 or later, lots of initializer list bugs have been fixed already -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You reported the bug.
[Bug fortran/49010] Result of MOD and MODULO intrinsic has wrong sign
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49010
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- Comment #2 from kargl at gcc dot gnu.org 2011-05-16 20:44:08 UTC ---
This appears to be caused by the use of __builtin_fmod in
trans-intrinsic.c (gfc_conv_intrinsic_mod). By hacking
the code to disallow the use of the builtin, one uses
the fallback code (which implements the simply code).
program foo
real a, p, m1, m2
a = -4.
p = 2.
m1 = mod(a, p)
m2 = a - int(a / p) * p
print *, m1, m2
end program foo
troutmask:sgk[239] gfc4x -o z t.f90 ./z
0. 0.
Thus, one gets the right answer. Also, note
#include stdio.h
#include math.h
int
main(void)
{
float a, p, m1, m2;
a = -4.f;
p = 2.f;
m1 = fmodf(a, p);
m2 = a - (int)(a / p) * p;
printf(%f %f\n, m1, m2);
return 0;
}
troutmask:sgk[241] cc -o z t.c -lm ./z
-0.00 0.00
which probably means that we either want to not
use the __builtin_fmod() (which is probably some
optimized bit twiddling routine).
[Bug c++/48969] ICE with -std=c++0x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48969 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org 2011-05-16 20:52:24 UTC --- Author: jason Date: Mon May 16 20:52:18 2011 New Revision: 173805 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173805 Log: PR c++/48969 * pt.c (deduction_tsubst_fntype): Use a VEC initially. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug fortran/49010] Result of MOD and MODULO intrinsic has wrong sign
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49010 --- Comment #3 from Steve Kargl sgk at troutmask dot apl.washington.edu 2011-05-16 21:17:44 UTC --- There is an additional problem with MOD(A,P) and MODULO(A,P). In F95, one finds P = 0, the result is processor dependent. In F2003 and F2008, one finds P shall not be zero. Consider the code, program foo real, parameter :: b = 0. real a, p, m1, m2 a = 2. p = 0. m1 = mod(a, p) m2 = mod(a, b) print *, m1, m2 end program foo with the __builtin_fmod function we get troutmask:sgk[215] gfc4x -o z t.f90 ./z NaN NaN (ie., there is no error or warning that P=0). If we simply eliminate the __builtin_fmod function, we get troutmask:sgk[212] gfc4x -o z t.f90 ./z 2. 2. which is worse than the NaN. :( __ Steve
[Bug c++/46071] [C++0x] ill-formed use of decltype and auto causes segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46071 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-05-16 21:20:25 UTC --- Jason, this doesn't ICE anymore in mainline, I guess thanks to your recent work. Shall we close it as fixed / dup ?
[Bug c++/49015] New: [C++0x] Non-defining constexpr function declarations require complete argument/return types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49015
Summary: [C++0x] Non-defining constexpr function declarations
require complete argument/return types
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com
CC: ja...@redhat.com
After successful resolution of bug 48948 gcc 4.7.0 20110514 (experimental) in
C++0x mode now rejects the following code at the lines marked with #L-4 until
#L-13:
//---
class A;
class B;
constexpr B f(A); // #L-4
class B {
friend constexpr B g(A); // #L-7
};
class A {};
constexpr B f(A) { return B(); } // #L-12
constexpr B g(A) { return B(); } // #L-13
//---
4|error: invalid type for parameter 1 of constexpr function 'constexpr B
f(A)'|
4|error: invalid return type 'B' of constexpr function 'constexpr B f(A)'|
7|error: invalid type for parameter 1 of constexpr function 'constexpr B g(A)'|
7|error: invalid type for parameter 1 of constexpr function 'constexpr B g(A)'|
|In function 'constexpr B f(A)':|
12|error: redeclaration 'constexpr B f(A)' differs in 'constexpr'|
4|error: from previous declaration 'B f(A)'|
|In function 'constexpr B g(A)':|
13|error: redeclaration 'constexpr B g(A)' differs in 'constexpr'|
7|error: from previous declaration 'B g(A)'|
||=== Build finished: 8 errors, 0 warnings ===|
The parts following line 8 have mainly be added to demonstrate the general
usefulness of the non-defining declarations and the error described by #L-12
and #L-13 is possibly overlaid by bug 48945 as well, so the main aspect of this
issue are the #L-4 and #L-7 rejections if interaction with bug 48945 is the
cause of #L-12 and #L-13.
I don't think that the literal-type requirements as of 3.9 p. 10 impose the
requirements of complete types for the non-defining declarations of these
constexpr functions, IMO the requirement for the complete type is only required
for the final definition of f and g, which also seems to be intended as
described by the example of 7.1.5 p. 1. In principle these examples are also
not much different from constexpr function templates, which must delay the
evaluation until the concrete instantiation and usage (The last aspect becomes
clear by the 7.1.5 p. 1 example and demonstrates that this is a general
character of constexpr functions irrespective of templates).
[Bug bootstrap/49013] [4.7 Regression] LTO bootstrap failed with bootstrap-profiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49013 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Target Milestone|--- |4.7.0 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2011-05-16 21:26:10 UTC --- It is caused by revision 173794: http://gcc.gnu.org/ml/gcc-cvs/2011-05/msg00573.html
[Bug preprocessor/48677] cpp.exe broken ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48677 --- Comment #18 from Joseph S. Myers jsm28 at gcc dot gnu.org 2011-05-16 21:23:18 UTC --- Author: jsm28 Date: Mon May 16 21:23:14 2011 New Revision: 173808 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173808 Log: PR preprocessor/48677 * cppspec.c (lang_specific_driver): Set new_decoded_options[0] from decoded_options[0], not from itself. Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/cppspec.c
[Bug fortran/49010] Result of MOD and MODULO intrinsic has wrong sign
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49010 --- Comment #4 from Steve Kargl sgk at troutmask dot apl.washington.edu 2011-05-16 21:43:57 UTC --- On Mon, May 16, 2011 at 09:31:57PM +, sgk at troutmask dot apl.washington.edu wrote: In F95, one finds P = 0, the result is processor dependent. In F2003 and F2008, one finds P shall not be zero. Consider the code, program foo real, parameter :: b = 0. real a, p, m1, m2 a = 2. p = 0. m1 = mod(a, p) m2 = mod(a, b) for the above case, I forgot to also make 'a' a parameter. so simplification did not occur. both mod and modulo is an error if both 'a' and 'b' are constants and b = 0. So, we are only missing a runtime error, which should probably be triggered with -fno-fast-math.
[Bug preprocessor/48677] cpp.exe broken ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48677 Joseph S. Myers jsm28 at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.1 --- Comment #19 from Joseph S. Myers jsm28 at gcc dot gnu.org 2011-05-16 22:09:38 UTC --- Fixed for 4.6.1 and 4.7.
[Bug c/49016] New: always_inline causes references below the current stack pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49016 Summary: always_inline causes references below the current stack pointer Product: gcc Version: 4.3.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: merrill_70...@yahoo.com Created attachment 24256 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24256 A script to run to compile t.c When inline __attribute__((always_inline)) is used, as is set up in some Linux 2.6 kernel builds in gcc-compiler.h / compiler.h etc., then references to memory below the current stack pointer can be made, when optimization is turned off. In fact, such references can also occur with -O2, but that is not such a simple test program to generate. Here is a test program which generates the problem with no optimization turned on. To compile, run the rc script.
[Bug c/49017] New: [avr] -ffunction-sections causes linker to fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49017 Summary: [avr] -ffunction-sections causes linker to fail Product: gcc Version: 4.5.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: stefan.hlad...@gmail.com I was compiling my code with -ffunction-sections for quite some time, so not sure why this problem now constantly appears when using this flag. I have a toolchain compiled with crossdev -t avr on gentoo, which means gcc-4.5.2 at the moment. When linking my object file with other files __muldi3 from libgcc.a is linked incorrectly. Attaching pre-linking (nol*) post-linking (obj*) object files. I'm not really sure about what to provide, so please let me know what you need. Stefan
[Bug c/49016] always_inline causes references below the current stack pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49016 --- Comment #1 from Lee Merrill merrill_707_1 at yahoo dot com 2011-05-16 22:45:58 UTC --- Created attachment 24257 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24257 The source file which generates the problem This file, when compiled via the attached rc script, will have references below the current stack pointer.
[Bug c/49016] always_inline causes references below the current stack pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49016 --- Comment #2 from Lee Merrill merrill_707_1 at yahoo dot com 2011-05-16 22:49:14 UTC --- Created attachment 24258 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24258 The output of running rc with -v -save-temps added. This is the output from running the rc script, with gcc parameters -v -save-temps added to the command line.
[Bug c/49017] [avr] -ffunction-sections causes linker to fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49017 --- Comment #1 from stefan.hladnik at gmail dot com 2011-05-16 22:51:14 UTC --- Created attachment 24259 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24259 Object files before and after linking
[Bug c/49016] always_inline causes references below the current stack pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49016 --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org 2011-05-16 23:09:13 UTC --- Well x86_64 ABI has a red zone which allows for these references to happen if they are under 128 bytes.
[Bug c/49016] always_inline causes references below the current stack pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49016 --- Comment #3 from Lee Merrill merrill_707_1 at yahoo dot com 2011-05-16 22:51:33 UTC --- A disassembly snippet to show the problem: fcPostWrite: 0: 55 push %rbp 1: 48 89 e5mov%rsp,%rbp # Note that these statements reference memory below the # current stack pointer. So any interrupt which occurs # here will corrupt these variables. 4: 48 89 7d e8 mov%rdi,-0x18(%rbp) 8: 89 75 e4mov%esi,-0x1c(%rbp) b: 8b 45 e4mov-0x1c(%rbp),%eax e: 89 45 fcmov%eax,-0x4(%rbp) 11: 48 8b 45 e8 mov-0x18(%rbp),%rax 15: 48 89 45 f0 mov%rax,-0x10(%rbp) 19: 48 8b 55 f0 mov-0x10(%rbp),%rdx 1d: 8b 45 fcmov-0x4(%rbp),%eax 20: 89 02 mov%eax,(%rdx) 22: c9 leaveq 23: c3 retq
[Bug target/46655] invalid '.line 0' directive emitted with -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655 --- Comment #29 from Richard Nolde richard.nolde at cybox dot com 2011-05-16 23:19:24 UTC --- On 04/01/2011 06:24 AM, michael.haubenwallner at salomon dot at wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655 --- Comment #28 from Michael Haubenwallnermichael.haubenwallner at salomon dot at 2011-04-01 12:24:32 UTC --- Looks like IBM fixed their Assembler to ignore invalid .line pseudo-ops again: https://www-304.ibm.com/support/docview.wss?uid=isg1IZ87535 I seem to be unable to use my Gcc Bugzilla account at the moment (waiting for an updated password token message), so I'll send this one to you in the hope that it adds to the known database of issues for Gcc on AIX. I received the URL to update my Bugzilla password and it accepted it but I still cannot login. The username or password you entered is not valid. comes up each time I try. I'm now running AIX 6.1, oslevel -s returns 6100-06-03-1048 and the problem seems to persist with newer versions of gcc as well. I installed gcc 4.4.6 today after having issues trying to build GNU barcode from source. gcc -v Using built-in specs. Target: powerpc-ibm-aix6.1.0.0 Configured with: ../gcc-4.4.6/configure --with-as=/usr/bin/as --with-ld=/usr/bin/ld --enable-languages=c,c++,fortran --prefix=/opt/freeware --enable-threads --enable-version-specific-runtime-libs --disable-nls --enable-decimal-float=dpd --host=powerpc-ibm-aix6.1.0.0 Thread model: aix gcc version 4.4.6 (GCC) The original Makefile includes -g among the CFLAGS, which produces the now well documented error message from the AIX assembler as noted in this thread. After revisiting the GCC Bugzilla site today, I added initializations for all the Static variables in the source code files that were not arrays and were not already initialized and then I tried to recompile with -g in the CFLAGS. This attempt now fails with the also reported message: ... /usr/bin/gcc -g -std=gnu89 -O2 -Wall -DPACKAGE_NAME=\\ -DPACKAGE_TARNAME=\\ -DPACKAGE_VERSION=\\ -DPACKAGE_STRING=\\ -DPACKAGE_BUGREPORT=\\ -DPACKAGE_URL=\\ -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_UNISTD_H=1 -DHAVE_STRCASECMP=1main.o cmdline.o -L. -lbarcode -lpaper -lm -o barcode ld: 0711-596 SEVERE ERROR: Object main.o An RLD for section 2 (.data) refers to symbol 944, but the storage class of the symbol is not C_EXT or C_HIDEXT. collect2: ld returned 12 exit status make: *** [barcode] Error 1 The only way to get a successful compile under AIX 6.1 TL 3 with IBM's fix-du-jour is to remove -g from the CFLAGS. Here is the top of the GNU barcode Makefile, the rest is standard install targets etc. # # This Makefile should run fine with both pmake and gmake # CC = /usr/bin/gcc CFLAGS = -std=gnu89 -O2 -Wall -DPACKAGE_NAME=\\ -DPACKAGE_TARNAME=\\ -DPACKAGE_VERSION=\\ -DPACKAGE_STRING=\\ -DPACKAGE_BUGREPORT=\\ -DPACKAGE_URL=\\ -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_UNISTD_H=1 -DHAVE_STRCASECMP=1 RANLIB = /usr/bin/ranlib INSTALL = /opt/freeware/bin/install -c LDFLAGS = -L. -l$(TARGET) -lpaper -lm prefix = /opt/freeware BINDIR = $(bindir) LIBDIR = $(libdir) INCDIR = $(includedir) MANDIR = $(prefix)/share MAN1DIR = $(mandir)/man1 MAN3DIR = $(mandir)/man3 INFODIR = $(infodir) # getopt may be installed or not, if not take our copy GETOPT_O = TARGET = barcode LIBRARY = lib$(TARGET).a MAN1 = $(TARGET).1 MAN3 = $(TARGET).3 #INFO = doc/$(TARGET).info HEADER = $(TARGET).h LIBOBJECTS = library.o ean.o code128.o code39.o code93.o i25.o \ msi.o plessey.o codabar.o \ ps.o pcl.o code11.o fonts.o EXEOBJECTS = main.o cmdline.o $(GETOPT_O) ALLSOURCES = $(LIBOBJECTS:.o=.c) $(EXEOBJECT:.o=.c) #Hmm... RM is undefined in pmake RM = rm #all: $(TARGET) $(LIBRARY) $(MAN1) $(MAN3) $(INFO) sample all: $(TARGET) $(LIBRARY) sample $(TARGET): $(LIBRARY) $(EXEOBJECTS) $(CC) $(CFLAGS) $(EXEOBJECTS) $(LDFLAGS) -o $(TARGET) ALSO, FWIW, gdb 7.2.1 under AIX 6.1 coredumps when trying to print any variable that is a pointer to char. I can compile programs that don't have static variables with -g, but I get a coredump when I tried to debug them. I can try to create a simple test case if this is not a known bug. Thanks, Richard Nolde
[Bug c/49016] always_inline causes references below the current stack pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49016 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||INVALID --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-17 05:22:06 UTC --- Yeah, 128 bytes below %rsp can be freely used on x86_64, interrupts must not clobber those.
