Could not identify that register is clobbered already
Hi, I was analyzing an issue for avr target (gcc-4.7.2). Issue is that already clobbered register is used after the transformation in post reload pass. insns after reload pass: set (reg:HI r24 (const:HI (plus:HI (symbol_ref:HI (array)) (const_int 4)) )) ... parallel set (reg:HI r14 (and:HI (reg:HI r14) (const_int 3))) clobber:QI r25 ... set (reg:HI r28 (const:HI (plus:HI (symbol_ref:HI (array)) (const_int 4)) )) After post reload pass, insn-3 transformed as follows: set (reg:HI r28 reg:HI r24) this transformation happened in reload_cse_move2add function. Since r25 is clobbered in insn-2, above transformation (r28/29 = r24/25) become incorrect. Function 'move2add_use_add3_insn' sets only r24 info for insn-1 instead of setting info for both r24/25. Function 'validate_change' checks only r24 info for insn-3 transformation. is it possible to identify clobbered register and avoid transformation? Regards, Pitchumani
CPATH, LIBRARY_PATH, and cross-compilers
Hi, GCC honors CPATH, LIBRARY_PATH, co. regardless of whether it’s built as a cross-compiler. Consequently, when cross-compiling a package that contains both support tools to be compiled natively and the main code to be cross-compiled, these variables are useless because they don’t allow host and build headers and libraries to be distinguished. To fix that, I’d build the cross-compiler with something like: --- gcc-4.7.2/gcc/incpath.c 2012-01-27 00:34:58.0 +0100 +++ gcc-4.7.2/gcc/incpath.c 2013-02-12 10:11:27.0 +0100 @@ -452,7 +452,7 @@ register_include_chains (cpp_reader *pfi /* CPATH and language-dependent environment variables may add to the include chain. */ - add_env_var_paths (CPATH, BRACKET); + add_env_var_paths (CROSS_CPATH, BRACKET); add_env_var_paths (lang_env_vars[idx], SYSTEM); target_c_incpath.extra_pre_includes (sysroot, iprefix, stdinc); --- gcc-4.7.2/gcc/system.h 2012-02-17 00:16:28.0 +0100 +++ gcc-4.7.2/gcc/system.h 2013-02-12 10:22:17.0 +0100 @@ -1023,4 +1023,6 @@ helper_const_non_const_cast (const char #define DEBUG_VARIABLE #endif +#define LIBRARY_PATH_ENV CROSS_LIBRARY_PATH + #endif /* ! GCC_SYSTEM_H */ What about changing GCC to honor CROSS_CPATH ( co.) and CROSS_LIBRARY_PATH when built as a cross-compiler? The behavior would be to honor the CROSS_ variable when it’s defined, and to discard its non-CROSS_ variant. Native compilers would still behave the same. I can prepare a patch if there’s interest. Thanks, Ludo’.
Re: CPATH, LIBRARY_PATH, and cross-compilers
On 2/12/2013 12:48 PM, Ludovic Courtès wrote: Hi, GCC honors CPATH, LIBRARY_PATH, co. regardless of whether it’s built as a cross-compiler. Consequently, when cross-compiling a package that contains both support tools to be compiled natively and the main code to be cross-compiled, these variables are useless because they don’t allow host and build headers and libraries to be distinguished. To fix that, I’d build the cross-compiler with something like: This is a long standing issue with gcc. Whether your solution is OK with the other developers, I don't know. It is a step in the right direction. But it still doesn't address the situation where you have multiple cross compilers in your PATH all for different targets. It addresses the most common use case though. -- Joel Sherrill, Ph.D. Director of Research Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985
Re: CPATH, LIBRARY_PATH, and cross-compilers
Joel Sherrill joel.sherr...@oarcorp.com skribis: But it still doesn't address the situation where you have multiple cross compilers in your PATH all for different targets. Yeah, I thought about it, but couldn’t come up with a practical use case where you’d need to use different cross-compilers in a single build. Ludo’.
Re: expansion of vector shifts...
From: David Miller da...@redhat.com
Date: Fri, 16 Nov 2012 00:33:05 -0500 (EST)
From: Richard Sandiford rdsandif...@googlemail.com
Date: Mon, 29 Oct 2012 10:14:53 +
...given that the code is like you say written:
if (SHIFT_COUNT_TRUNCATED)
{
if (CONST_INT_P (op1)
...
else if (GET_CODE (op1) == SUBREG
subreg_lowpart_p (op1)
INTEGRAL_MODE_P (GET_MODE (SUBREG_REG (op1
op1 = SUBREG_REG (op1);
}
INTEGRAL_MODE_P (GET_MODE (op1)) might be better than an explicit
VECTOR_MODE_P check. The code really doesn't make sense for anything
other than integers.
(It amounts to the same thing in practice, of course...)
Agreed, I've just committed the following. Thanks!
Fix gcc.c-torture/compile/pr53410-2.c on sparc.
* expmed.c (expand_shift_1): Don't strip non-integral SUBREGs.
This is broken on sparc again, although I'm confused about how this
has happened.
The suggestion was to use INTEGRAL_MODE_P as the test, so what's there
in expand_shift_1() is:
else if (GET_CODE (op1) == SUBREG
subreg_lowpart_p (op1)
INTEGRAL_MODE_P (GET_MODE (SUBREG_REG (op1)))
INTEGRAL_MODE_P (GET_MODE (op1)))
op1 = SUBREG_REG (op1);
but INTEGRAL_MODE_P accepts vectors. This is really confusing because
I was absolutely sure I re-ran the test case with the fix I committed
and it didn't crash any more.
Maybe what we really mean to do here is check both op1 and SUBREG_REG
(op1) against SCALAR_INT_MODE_P instead of INTEGRAL_MODE_P?
Something like this:
gcc/
2013-02-12 David S. Miller da...@davemloft.net
* expmed.c (expand_shift_1): Only strip scalar integer subregs.
diff --git a/gcc/expmed.c b/gcc/expmed.c
index 4a6ddb0..954a360 100644
--- a/gcc/expmed.c
+++ b/gcc/expmed.c
@@ -2116,8 +2116,8 @@ expand_shift_1 (enum tree_code code, enum machine_mode
mode, rtx shifted,
% GET_MODE_BITSIZE (mode));
else if (GET_CODE (op1) == SUBREG
subreg_lowpart_p (op1)
- INTEGRAL_MODE_P (GET_MODE (SUBREG_REG (op1)))
- INTEGRAL_MODE_P (GET_MODE (op1)))
+ SCALAR_INT_MODE_P (GET_MODE (SUBREG_REG (op1)))
+ SCALAR_INT_MODE_P (GET_MODE (op1)))
op1 = SUBREG_REG (op1);
}
CPIC for mips
CPIC is added to .o files for mips a lot. Is that needed? What is it for? Tia. Reed rkotler@ubuntu-rkotler:~/testmips16$ mips-linux-gnu-gcc null.c -c mipsrkotler@ubuntu-rkotler:~/testmips16$ mips-linux-gnu-objdump -x null.o null.o: file format elf32-tradbigmips null.o architecture: mips:isa32r2, flags 0x0011: HAS_RELOC, HAS_SYMS start address 0x private flags = 70001005: [abi=O32] [mips32r2] [not 32bitmode] [noreorder] [CPIC] Sections: Idx Name Size VMA LMA File off Algn 0 .text 0030 0040 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .data 0070 2**4 CONTENTS, ALLOC, LOAD, DATA 2 .bss 0070 2**4 ALLOC 3 .reginfo 0018 0070 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA, LINK_ONCE_SAME_SIZE 4 .pdr 0020 0088 2**2 CONTENTS, RELOC, READONLY 5 .mdebug.abi32 00a8 2**0 CONTENTS, READONLY 6 .comment 002c 00a8 2**0 CONTENTS, READONLY 7 .gnu.attributes 0010 00d4 2**0 CONTENTS, READONLY SYMBOL TABLE: ldf *ABS* null.c ld .text .text ld .data .data ld .bss .bss ld .mdebug.abi32 .mdebug.abi32 ld .reginfo .reginfo ld .pdr .pdr ld .comment .comment ld .gnu.attributes .gnu.attributes g F .text0024 main RELOCATION RECORDS FOR [.pdr]: OFFSET TYPE VALUE R_MIPS_32 main rkotler@ubuntu-rkotler:~/testmips16$
Re: Could not identify that register is clobbered already
[Removing avr-gcc-list from CC because there is no need to cross-post] S, Pitchumani wrote: I was analyzing an issue for avr target (gcc-4.7.2). Issue is that already clobbered register is used after the transformation in post reload pass. insns after reload pass: set (reg:HI r24 (const:HI (plus:HI (symbol_ref:HI (array)) (const_int 4)) )) ... parallel set (reg:HI r14 (and:HI (reg:HI r14) (const_int 3))) clobber:QI r25 ... set (reg:HI r28 (const:HI (plus:HI (symbol_ref:HI (array)) (const_int 4)) )) After post reload pass, insn-3 transformed as follows: set (reg:HI r28 reg:HI r24) this transformation happened in reload_cse_move2add function. Since r25 is clobbered in insn-2, above transformation (r28/29 = r24/25) become incorrect. You have a test case so that this can be reproduced? Function 'move2add_use_add3_insn' sets only r24 info for insn-1 instead of setting info for both r24/25. Function 'validate_change' checks only r24 info for insn-3 transformation. is it possible to identify clobbered register and avoid transformation? Some passes assume that the frame pointer only spans one register, which does not hold for the avr target where FP lives in R28/R29. Trying to introduce hard_frame_pointer was dropped because the code turned out to have unusable had efficiency. I don't find the patch, AFAIR it is Denis' work, thus CCing him. But without a test case nobody can tell...
Re: CPIC for mips
On Tue, Feb 12, 2013 at 2:48 PM, reed kotler rkot...@mips.com wrote: CPIC is added to .o files for mips a lot. This is a better question for the binutils mailing list rather than the gcc list. Is that needed? What is it for? It says if the object file will call into PIC code. http://sourceware.org/ml/binutils/2003-05/msg00679.html http://sourceware.org/ml/binutils/2008-06/msg00280.html Thanks, Andrew Pinski Tia. Reed rkotler@ubuntu-rkotler:~/testmips16$ mips-linux-gnu-gcc null.c -c mipsrkotler@ubuntu-rkotler:~/testmips16$ mips-linux-gnu-objdump -x null.o null.o: file format elf32-tradbigmips null.o architecture: mips:isa32r2, flags 0x0011: HAS_RELOC, HAS_SYMS start address 0x private flags = 70001005: [abi=O32] [mips32r2] [not 32bitmode] [noreorder] [CPIC] Sections: Idx Name Size VMA LMA File off Algn 0 .text 0030 0040 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .data 0070 2**4 CONTENTS, ALLOC, LOAD, DATA 2 .bss 0070 2**4 ALLOC 3 .reginfo 0018 0070 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA, LINK_ONCE_SAME_SIZE 4 .pdr 0020 0088 2**2 CONTENTS, RELOC, READONLY 5 .mdebug.abi32 00a8 2**0 CONTENTS, READONLY 6 .comment 002c 00a8 2**0 CONTENTS, READONLY 7 .gnu.attributes 0010 00d4 2**0 CONTENTS, READONLY SYMBOL TABLE: ldf *ABS* null.c ld .text .text ld .data .data ld .bss .bss ld .mdebug.abi32 .mdebug.abi32 ld .reginfo .reginfo ld .pdr .pdr ld .comment .comment ld .gnu.attributes .gnu.attributes g F .text0024 main RELOCATION RECORDS FOR [.pdr]: OFFSET TYPE VALUE R_MIPS_32 main rkotler@ubuntu-rkotler:~/testmips16$
Re: gcc : c++11 : full support : eta?
On Feb 8, 2013, at 8:24 AM, Jeff Law l...@redhat.com wrote: I'm not quite sure that this clean split is possible, even after making amends for template instantiation. It's great for syntax-driven tools, but once you move beyond that, you tend to ignore stuff like destructors (or the cleanup attribute), life-times of temporaries etc., things which are just not visible in an AST. You have to reimplement many program analysis algorithms typically part of compiler optimizers, after lowering the AST to a less elaborate intermediate representation (a step which requires a fair amount of knowledge about the language in question). There's always going to be some things that are best done with the raw ASTs and others which are best done when we've got a lowered IL, CFG, SSA graph, etc. The big question is how well can you go from the output of clang into a lower level IR where you can do in depth analysis and how much you allow optimizers to perturb the results of the analysis. One could argue that clang - gimple would be a useful translator to allow the nice things from the clang front-end, but also still allow the more in-depth analysis done by our tree-ssa code. FWIW, the Clang static analyzer uses just such a representation: it is a CFG formed out of AST nodes. -Chris
Register Allocation issues with microblaze-elf
Hi --
I'm seeing register allocation problems and code size increases
with gcc-4.6.2 (and gcc-head) compared with older (gcc-4.1.2).
Both are compiled using -O3.
One test case that I have has a long series of nested if's
each with the same comparison and similar computation.
if (nmax_no){
n+=*(cp-*p++);
if (nmax_no){
n+=*(cp-*p);
if (nmax_no){
. . . ~20 levels of nesting
more computations with 'cp' and 'p'
. . . }}}
Gcc-4.6.2 generates many blocks like the following:
lwi r28,r1,68 -- load into dead reg
lwi r31,r1,140 -- load p from stack
lbuir28,r31,0
rsubk r31,r28,r19
lbuir31,r31,0
addkr29,r29,r31
swi r31,r1,308
lwi r31,r1,428 -- load of max_no from stack
cmp r28,r31,r29 -- n in r29
bgeid r28,$L46
gcc-4.1.2 generates the following:
lbuir3,r26,3
rsubk r3,r3,r19
lbuir3,r3,0
addkr30,r30,r3
swi r3,r1,80
cmp r18,r9,r30 -- max_no in r9, n in r30
bgeir18,$L6
gcc-4.6.2 (and gcc-head) load max_no from the stack in each block.
There also are extra loads into r28 (which is not used) and r31 at
the start of each block. Only r28, r29, and r31 are used.
I'm having a hard time telling what is happening or why. The
IRA dump has this line:
Ignoring reg 772, has equiv memory
where pseudo 772 is loaded with max_no early in the function.
The reload dump has
Reloads for insn # 254
Reload 0: reload_in (SI) = (reg/v:SI 722 [ max_no ])
GR_REGS, RELOAD_FOR_INPUT (opnum = 1)
reload_in_reg: (reg/v:SI 722 [ max_no ])
reload_reg_rtx: (reg:SI 31 r31)
and similar for each of the other insns using 722.
This is followed by
Spilling for insn 254.
Using reg 31 for reload 0
for each insn using pseudo 722.
Any idea what is going on?
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
#if 0
mb-gcc -O3 -mhard-float -fdump-rtl-all -c s.c -save-temps
#endif
typedef unsigned char uchar;
typedef struct {int x,y,info, dx, dy, I;} CORNER_LIST[15000];
susan_corners(in,r,bp,max_no,corner_list,x_size,y_size)
uchar *in, *bp;
int *r, max_no, x_size, y_size;
CORNER_LIST corner_list;
{
int n,x,y,sq,xx,yy,
i,j,*cgx,*cgy;
float divide;
uchar c,*p,*cp;
for (i=5;iy_size-5;i++)
for (j=5;jx_size-5;j++)
{
n=100;
p=in + (i-3)*x_size + j - 1;
cp=bp + in[i*x_size+j];
n+=*(cp-*p++);
n+=*(cp-*p++);
n+=*(cp-*p);
p+=x_size-3;
n+=*(cp-*p++);
n+=*(cp-*p++);
n+=*(cp-*p++);
n+=*(cp-*p++);
n+=*(cp-*p);
p+=x_size-5;
n+=*(cp-*p++);
n+=*(cp-*p++);
n+=*(cp-*p++);
n+=*(cp-*p++);
n+=*(cp-*p++);
n+=*(cp-*p++);
n+=*(cp-*p);
p+=x_size-6;
n+=*(cp-*p++);
n+=*(cp-*p++);
n+=*(cp-*p);
if (nmax_no){
p+=2;
n+=*(cp-*p++);
#if 1
if (nmax_no){
n+=*(cp-*p++);
if (nmax_no){
n+=*(cp-*p);
if (nmax_no){
p+=x_size-6;
n+=*(cp-*p++);
if (nmax_no){
n+=*(cp-*p++);
if (nmax_no){
n+=*(cp-*p++);
if (nmax_no){
n+=*(cp-*p++);
if (nmax_no){
n+=*(cp-*p++);
if (nmax_no){
n+=*(cp-*p++);
if (nmax_no){
n+=*(cp-*p);
if (nmax_no){
p+=x_size-5;
n+=*(cp-*p++);
if (nmax_no){
n+=*(cp-*p++);
if (nmax_no){
n+=*(cp-*p++);
if (nmax_no){
n+=*(cp-*p++);
if (nmax_no){
n+=*(cp-*p);
if (nmax_no){
p+=x_size-3;
n+=*(cp-*p++);
#endif
if (nmax_no){
n+=*(cp-*p++);
if (nmax_no){
n+=*(cp-*p);
if (nmax_no)
{
x=0;y=0;
p=in + (i-3)*x_size + j - 1;
c=*(cp-*p++);x-=c;y-=3*c;
c=*(cp-*p++);y-=3*c;
c=*(cp-*p);x+=c;y-=3*c;
p+=x_size-3;
c=*(cp-*p++);x-=2*c;y-=2*c;
c=*(cp-*p++);x-=c;y-=2*c;
c=*(cp-*p++);y-=2*c;
c=*(cp-*p++);x+=c;y-=2*c;
c=*(cp-*p);x+=2*c;y-=2*c;
p+=x_size-5;
c=*(cp-*p++);x-=3*c;y-=c;
c=*(cp-*p++);x-=2*c;y-=c;
c=*(cp-*p++);x-=c;y-=c;
c=*(cp-*p++);y-=c;
[Bug c++/56292] New: False positive for constexpr arithmetics (-Wconversion)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56292
Bug #: 56292
Summary: False positive for constexpr arithmetics
(-Wconversion)
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: lcid-f...@gmx.net
For the following code one gets 'conversion' diagnostics, while the compiler
should be able to compute, that it is actually fine.
#include cstdint
constexpr std::uint8_t func() { return 2; }
std::uint8_t value = func() + 2;
Results in:
warning: conversion to ‘uint8_t {aka unsigned char}’ from ‘int’ may alter its
value [-Wconversion]
Diagnostics works fine if you replace 'func()' with a number.
[Bug sanitizer/55309] gcc's address-sanitizer 66% slower than clang's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309 --- Comment #34 from Jakub Jelinek jakub at gcc dot gnu.org 2013-02-12 08:39:33 UTC --- (In reply to comment #32) Good news, 0x7fff8000 seems great: There is another suggestion (from dvyukov) to use -Wl,-Ttext-segment=0x4000 together with zerobase (pie is not required) which is worth investigating. Glad to hear that. The disadvantage of -Wl,-Ttext-segment=0x4000 is that it requires special command line option for building the executable, i.e. you can't e.g. just build some shared library with -fsanitize=address and leave the main executable non-instrumented. Plus, I don't see how can -Wl,-Ttext-segment=0x4000 be used for x86_64, where you need 16TB of shadow memory for 3 scale. For zero shadow offset you'd need to place the executable above 16TB, and that implies non-small model. If -Ttext-segment is meant for 32-bit programs, then it could allow zero shadow offset, but with the disadvantage of special building of executables, and on i?86 the offset already fits into the immediates, so it is basically the 0x7fff8000 case for x86_64 already. (In reply to comment #33) , it might be better to have the scale and offset as arguments of __asan_init? We did this in the very early version, but it did not work in general. Consider you are linking your program with a third-party object not built with asan. It may have constructor functions called before main and before __asan_init, and those functions call malloc which has to call __asan_init, but can not pass arguments. I see, but then you could use the global vars (perhaps weak ones in libasan with some default), combined together with arguments to __asan_init (or some alternative name of the same function for compatibility). All that it would do beyond normal initialization would be complain if the requested scale/offset pair is different from the chosen one.
[Bug sanitizer/55309] gcc's address-sanitizer 66% slower than clang's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309 --- Comment #35 from Dmitry Vyukov dvyukov at google dot com 2013-02-12 08:47:21 UTC --- On Tue, Feb 12, 2013 at 12:39 PM, jakub at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309 --- Comment #34 from Jakub Jelinek jakub at gcc dot gnu.org 2013-02-12 08:39:33 UTC --- (In reply to comment #32) Good news, 0x7fff8000 seems great: There is another suggestion (from dvyukov) to use -Wl,-Ttext-segment=0x4000 together with zerobase (pie is not required) which is worth investigating. Glad to hear that. The disadvantage of -Wl,-Ttext-segment=0x4000 is that it requires special command line option for building the executable, i.e. you can't e.g. just build some shared library with -fsanitize=address and leave the main executable non-instrumented. Plus, I don't see how can -Wl,-Ttext-segment=0x4000 be used for x86_64, where you need 16TB of shadow memory for 3 scale. For zero shadow offset you'd need to place the executable above 16TB, and that implies non-small model. It is intended for x86_64. The binary is situated at 0x4000 and it's shadow is at 0x1000-0x3fff (MAP_32BIT can live here as well). Dynamic libraries and mmap live either at 0x7fxx or at 0x55xx, that is mapped way above the executable. So there are no overlaps. If -Ttext-segment is meant for 32-bit programs, then it could allow zero shadow offset, but with the disadvantage of special building of executables, and on i?86 the offset already fits into the immediates, so it is basically the 0x7fff8000 case for x86_64 already. (In reply to comment #33) , it might be better to have the scale and offset as arguments of __asan_init? We did this in the very early version, but it did not work in general. Consider you are linking your program with a third-party object not built with asan. It may have constructor functions called before main and before __asan_init, and those functions call malloc which has to call __asan_init, but can not pass arguments. I see, but then you could use the global vars (perhaps weak ones in libasan with some default), combined together with arguments to __asan_init (or some alternative name of the same function for compatibility). All that it would do beyond normal initialization would be complain if the requested scale/offset pair is different from the chosen one. -- 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.
[Bug c++/56291] [4.6/4.7/4.8 Regression] ICE for C++11 in output_constructor_regular_field, at varasm.c:4821
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56291 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-02-12 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Target Milestone|--- |4.6.4 Summary|ICE for C++11 in|[4.6/4.7/4.8 Regression] |output_constructor_regular_ |ICE for C++11 in |field, at varasm.c:4821 |output_constructor_regular_ ||field, at varasm.c:4821 Ever Confirmed|0 |1 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2013-02-12 08:57:16 UTC --- Then please provide complete testcase next time, the one line shorter testcase certainly ICEs with r191000 and doesn't with r191100, while the one with the var definition started to ICE with http://gcc.gnu.org/viewcvs?root=gccview=revrev=166167
[Bug sanitizer/55309] gcc's address-sanitizer 66% slower than clang's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309 --- Comment #36 from Kostya Serebryany kcc at gcc dot gnu.org 2013-02-12 08:58:56 UTC --- I see, but then you could use the global vars (perhaps weak ones in libasan with some default), combined together with arguments to __asan_init (or some alternative name of the same function for compatibility). All that it would do beyond normal initialization would be complain if the requested scale/offset pair is different from the chosen one. Maybe we could add calls to e.g. __asan_check_abi_mismatch(uptr a1, uptr a2, uptr a3, uptr a4, uptr a5, uptr a6) after every call to __asan_init (a1 == offset, a2 == shift, a3 == something_else, etc) if any of a1..a6 is different between the calls to __asan_check_abi_mismatch -- fire an error. WDYT?
[Bug c++/56292] False positive for constexpr arithmetics (-Wconversion)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56292
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 2013-02-12
09:03:44 UTC ---
func() + 2 is evaluated as (unsigned char) (((int) func ()) + 2), so when the
-Wconversion warning is diagnosed before evaluating all the constexpr
expressions into constants if possible, the warning is reasonable.
Consider
constexpr std::uint8_t func() { return 0xff; }
std::uint8_t value = func() + 2;
[Bug c++/56291] [4.6/4.7/4.8 Regression] ICE for C++11 in output_constructor_regular_field, at varasm.c:4821
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56291 --- Comment #5 from Freddie Chopin freddie_chopin at op dot pl 2013-02-12 09:07:37 UTC --- Yes, sorry about the fuzz with the testcase and thx for confirming.
[Bug fortran/56293] New: I/O: Segfault in write_float when trying to print a not-word-aligned REAL(16) / -fno-align-commons
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56293 Bug #: 56293 Summary: I/O: Segfault in write_float when trying to print a not-word-aligned REAL(16) / -fno-align-commons Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: j...@gcc.gnu.org, jvdeli...@gcc.gnu.org Reported by Maciej Skrzypek at http://gcc.gnu.org/ml/fortran/2013-02/msg00058.html In the following code, p is not aligned; using it fails in GCC 4.8 with a segfault in #0 0x77ba5e16 in write_float (dtp=dtp@entry=0x7fffde40, f=f@entry=0x7fffdd70, source=source@entry=0x601084 sss_+4 , len=len@entry=16, comp_d=comp_d@entry=1) at libgfortran/io/write_float.def:1259 #1 0x77ba8365 in _gfortrani_write_real (dtp=dtp@entry=0x7fffde40, source=source@entry=0x601084 sss_+4 , length=length@entry=16) at libgfortran/io/write.c:1470 #2 0x77ba8dcf in list_formatted_write_scalar (size=16, kind=16, p=0x601084 sss_+4, type=BT_REAL, dtp=0x7fffde40) at libgfortran/io/write.c:1571 #3 _gfortrani_list_formatted_write (dtp=0x7fffde40, type=BT_REAL, p=optimized out, kind=16, size=16, nelems=1) at libgfortran/io/write.c:1599 Compile with: -fno-align-commons program main real(16) p integer i common/sss/ i, p print*, p end
[Bug fortran/56293] I/O: Segfault in write_float when trying to print a not-word-aligned REAL(16) / -fno-align-commons
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56293 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 2013-02-12 09:52:09 UTC --- Ditto for READ: 0x77b9b55f in _gfortrani_convert_real (dtp=dtp@entry=0x7fffde40, dest=dest@entry=0x601084 sss_+4, buffer=0x604fb0 445.54, length=length@entry=16) at libgfortran/io/read.c:155
[Bug c++/56292] False positive for constexpr arithmetics (-Wconversion)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56292 --- Comment #2 from lcid-fire at gmx dot net 2013-02-12 10:13:17 UTC --- But should it be evaluated before constexpr are processed?
[Bug fortran/56293] I/O: Segfault in write_float when trying to print a not-word-aligned REAL(16) / -fno-align-commons
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56293 Tobias Schlüter tobi at gcc dot gnu.org changed: What|Removed |Added CC||tobi at gcc dot gnu.org --- Comment #2 from Tobias Schlüter tobi at gcc dot gnu.org 2013-02-12 10:23:32 UTC --- This is valid behavior, -fno-align-common is documented to potentially break stuff (though the documentation could be more explicit on that).
[Bug rtl-optimization/56151] [4.8 Regression] Performance degradation after r194054 on x86 Atom.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56151 --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org 2013-02-12 10:37:42 UTC --- Author: jakub Date: Tue Feb 12 10:37:38 2013 New Revision: 195972 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195972 Log: PR rtl-optimization/56151 * optabs.c (add_equal_note): Don't return 0 if target is a MEM, equal to op0 or op1, and last_insn pattern is CODE operation with MEM dest and one of the operands matches that MEM. * gcc.target/i386/pr56151.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr56151.c Modified: trunk/gcc/ChangeLog trunk/gcc/optabs.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/56151] [4.8 Regression] Performance degradation after r194054 on x86 Atom.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56151 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org 2013-02-12 10:39:17 UTC --- Fixed.
[Bug tree-optimization/56294] New: BOOT_CFLAGS='-O2 -g -fno-ipa-sra' leads to bootstrap comparison failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56294 Bug #: 56294 Summary: BOOT_CFLAGS='-O2 -g -fno-ipa-sra' leads to bootstrap comparison failure Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: jamb...@gcc.gnu.org Bootstrapping pristine trunk with BOOT_CFLAGS='-O2 -g -fno-ipa-sra' leads to comparison failure because gcc/tree-ssa-loop-ivopts.o differs. Just switching IPA-SRA on (by a patch) when compiling that file resolves the problem. The failure has been introduced with revision 192848: 2012-10-26 Martin Jambor mjam...@suse.cz PR debug/54971 * tree-sra.c (struct access): New flag grp_to_be_debug_replaced. (dump_access): Dump the new flag. (analyze_access_subtree): Set the new flag when appropriate. (create_access_replacement): Handle debug replacements differently. (generate_subtree_copies): Handle the grp_to_be_debug_replaced flag. (init_subtree_with_zero): Likewise. (sra_modify_expr): Likewise. (load_assign_lhs_subreplacements): Likewise. (sra_modify_assign): Likewise. So I'll assign it to myself.
[Bug tree-optimization/56294] BOOT_CFLAGS='-O2 -g -fno-ipa-sra' leads to bootstrap comparison failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56294 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-02-12 AssignedTo|unassigned at gcc dot |jamborm at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Martin Jambor jamborm at gcc dot gnu.org 2013-02-12 10:46:31 UTC --- Sigh.
[Bug lto/56295] New: [4.8 Regression] Missed optimization with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56295 Bug #: 56295 Summary: [4.8 Regression] Missed optimization with LTO Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: d.g.gorbac...@gmail.com Created attachment 29422 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29422 Testcase In this testcase, LTO generates a call to memcpy at -O3 optimization level.
[Bug lto/56295] [4.8 Regression] Missed optimization with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56295 --- Comment #1 from Dmitry Gorbachev d.g.gorbachev at gmail dot com 2013-02-12 11:02:05 UTC --- Created attachment 29423 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29423 Three other testcases These are unrelated testcases which also demonstrate differences between LTO and non-LTO.
[Bug tree-optimization/56049] [4.8 Regression] Simplification to constants not done
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56049
--- Comment #6 from rguenther at suse dot de rguenther at suse dot de
2013-02-12 11:06:23 UTC ---
On Mon, 11 Feb 2013, hubicka at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56049
--- Comment #5 from Jan Hubicka hubicka at gcc dot gnu.org 2013-02-11
22:55:44 UTC ---
Well, I think we should try to toamn fantasy of our optimizers here. What
unroller sees at -O3 -fno-tree-vectorize is quite ugly:
bb 2:
a = {};
bb 3:
# i_1 = PHI 1(2), i_7(7)
# prephitmp_99 = PHI 0(2), pretmp_98(7)
# prephitmp_102 = PHI 0(2), pretmp_101(7)
# prephitmp_105 = PHI 0(2), pretmp_104(7)
# prephitmp_108 = PHI 0(2), pretmp_107(7)
# prephitmp_111 = PHI 0(2), pretmp_110(7)
# prephitmp_114 = PHI 0(2), pretmp_113(7)
# prephitmp_117 = PHI 0(2), pretmp_116(7)
# prephitmp_120 = PHI 0(2), pretmp_119(7)
# ivtmp_57 = PHI 1000(2), ivtmp_64(7)
bb 4:
# S.0_90 = PHI S.0_36(5), 1(3)
# prephitmp_126 = PHI pretmp_125(5), prephitmp_99(3)
# prephitmp_129 = PHI pretmp_128(5), prephitmp_102(3)
# prephitmp_132 = PHI pretmp_131(5), prephitmp_105(3)
# prephitmp_135 = PHI pretmp_134(5), prephitmp_108(3)
# prephitmp_138 = PHI pretmp_137(5), prephitmp_111(3)
# prephitmp_141 = PHI pretmp_140(5), prephitmp_114(3)
# prephitmp_144 = PHI pretmp_143(5), prephitmp_117(3)
# prephitmp_147 = PHI pretmp_146(5), prephitmp_120(3)
# ivtmp_43 = PHI ivtmp_50(5), 8(3)
_29 = S.0_90 * 8;
_42 = _29 + -8;
_44 = prephitmp_126 + 1;
b[_42] = _44;
_49 = _29 + -7;
_51 = prephitmp_129 + 1;
b[_49] = _51;
_56 = _29 + -6;
_58 = prephitmp_132 + 1;
b[_56] = _58;
_63 = _29 + -5;
_65 = prephitmp_135 + 1;
b[_63] = _65;
_70 = _29 + -4;
b[_63] = _65;
_70 = _29 + -4;
_72 = prephitmp_138 + 1;
b[_70] = _72;
_77 = _29 + -3;
_79 = prephitmp_141 + 1;
b[_77] = _79;
_84 = _29 + -2;
_86 = prephitmp_144 + 1;
b[_84] = _86;
_91 = _29 + -1;
_93 = prephitmp_147 + 1;
b[_91] = _93;
S.0_36 = S.0_90 + 1;
ivtmp_50 = ivtmp_43 - 1;
if (ivtmp_50 == 0)
goto bb 6;
else
goto bb 5;
bb 5:
pretmp_122 = S.0_36 * 8;
pretmp_124 = pretmp_122 + -8;
pretmp_125 = a[pretmp_124];
pretmp_127 = pretmp_122 + -7;
pretmp_128 = a[pretmp_127];
pretmp_130 = pretmp_122 + -6;
pretmp_131 = a[pretmp_130];
pretmp_133 = pretmp_122 + -5;
pretmp_134 = a[pretmp_133];
pretmp_136 = pretmp_122 + -4;
pretmp_137 = a[pretmp_136];
pretmp_139 = pretmp_122 + -3;
pretmp_140 = a[pretmp_139];
pretmp_142 = pretmp_122 + -2;
pretmp_143 = a[pretmp_142];
pretmp_145 = pretmp_122 + -1;
pretmp_146 = a[pretmp_145];
goto bb 4;
With vectorization we actually unroll the inner loop but the outer one gets so
ugly that we don't do much about it...
So what about keeping it as enhancement request? I will try to poke about it,
but htere is but about PR overactivity of this type already, right?
Not that I know of (well there is some about PRE over-activity creating
lots of PHI nodes like this). Yes, keep it as enhancement request
I suppose.
Does the unroller even look at PHI nodes for costs?
[Bug middle-end/56231] warning traces have bogus line information when using LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56231
--- Comment #13 from rguenther at suse dot de rguenther at suse dot de
2013-02-12 11:11:11 UTC ---
On Tue, 12 Feb 2013, matt at use dot net wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56231
--- Comment #12 from Matt Hargett matt at use dot net 2013-02-12 02:02:33
UTC ---
looking at the patch for merging elsewhere, I noticed that
location_t
lto_input_location (struct bitpack_d *bp, struct data_in *data_in)
{
+ static const char *current_file;
+ static int current_line;
+ static int current_col;
bool file_change, line_change, column_change;
unsigned len;
- bool prev_file = data_in-current_file != NULL;
+ bool prev_file = current_file != NULL;
current_file is potentially of unknown value on the comparison in the last
line, right? or is there some static const initialization rule that implicitly
initializes it to 0?
Yes, all statics are zero-initialized.
As for the testcase, the LTO testsuite harness does not support
dg-warning and friends so it's not possible to add a meaningful
testcase.
[Bug sanitizer/55309] gcc's address-sanitizer 66% slower than clang's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309 --- Comment #37 from Kostya Serebryany kcc at gcc dot gnu.org 2013-02-12 11:17:45 UTC --- http://llvm.org/viewvc/llvm-project?rev=174957view=rev (and r174958) change the default offset for x86_64 to 7fff8000 and changes __asan_init to __asan_init_v1
[Bug middle-end/56288] always true conditional expression in verify_ssa_name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56288 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org 2013-02-12 11:18:17 UTC --- Author: rguenth Date: Tue Feb 12 11:18:05 2013 New Revision: 195973 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195973 Log: 2013-02-12 Richard Biener rguent...@suse.de PR middle-end/56288 * tree-ssa.c (verify_ssa_name): Fix check, move SSA_NAME_IN_FREE_LIST check up. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa.c
[Bug middle-end/56288] always true conditional expression in verify_ssa_name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56288 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org 2013-02-12 11:18:41 UTC --- Fixed.
[Bug sanitizer/55309] gcc's address-sanitizer 66% slower than clang's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309 Kostya Serebryany kcc at gcc dot gnu.org changed: What|Removed |Added CC||glider at google dot com --- Comment #38 from Kostya Serebryany kcc at gcc dot gnu.org 2013-02-12 11:31:20 UTC --- Unfortunately, this does not work on Mac, so we will have to keep the old mapping on Mac. gr
[Bug testsuite/56082] FAIL: gfortran.dg/bind_c_bool_1.f90 -O (test for errors, line 18) on powerpc-apple-darwin9 with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56082 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2013-02-12 11:33:37 UTC --- I just noticed that I swapped the patches for (a) and (b).
[Bug libgcc/56296] New: Undefined reference to __sync_add_and_fetch_8 for int64_t on MIPS32.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56296
Bug #: 56296
Summary: Undefined reference to __sync_add_and_fetch_8 for
int64_t on MIPS32.
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcc
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kilva...@homejinni.com
compiling inc.c:
#include inttypes.h
int main()
{
int64_t var = 7;
__sync_add_and_fetch(var, 1);
return 0;
}
Output:
(squeeze)/data/kilvadyb/webkit-mips$ mipsel-linux-gnu-gcc -Wall -o i inc.c
/tmp/ccGwTrIE.o: In function `main':
inc.c:(.text+0x3c): undefined reference to `__sync_add_and_fetch_8'
collect2: ld returned 1 exit status
Compiler version:
Using built-in specs.
Target: mipsel-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/mipsel-linux-gnu/include/c++/4.4.5
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--disable-libssp --enable-checking=release --program-prefix=mipsel-linux-gnu-
--includedir=/usr/mipsel-linux-gnu/include --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=mipsel-linux-gnu
--with-headers=/usr/mipsel-linux-gnu/include
--with-libs=/usr/mipsel-linux-gnu/lib
Thread model: posix
gcc version 4.4.5 (Debian 4.4.5-8)
[Bug sanitizer/55309] gcc's address-sanitizer 66% slower than clang's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309
--- Comment #39 from Jakub Jelinek jakub at gcc dot gnu.org 2013-02-12
11:42:33 UTC ---
So, if Darwin keeps the old 1ULL 44, then the corresponding gcc change (to
be applied together with asan merge) would be something like (untested):
--- gcc/sanitizer.def2013-01-11 09:02:37.879637130 +0100
+++ gcc/sanitizer.def2013-02-12 12:39:12.743272092 +0100
@@ -27,7 +27,7 @@ along with GCC; see the file COPYING3.
for other FEs by asan.c. */
/* Address Sanitizer */
-DEF_SANITIZER_BUILTIN(BUILT_IN_ASAN_INIT, __asan_init,
+DEF_SANITIZER_BUILTIN(BUILT_IN_ASAN_INIT, __asan_init_v1,
BT_FN_VOID, ATTR_NOTHROW_LEAF_LIST)
/* Do not reorder the BUILT_IN_ASAN_REPORT* builtins, e.g. cfgcleanup.c
relies on this order. */
--- gcc/config/i386/i386.c2013-02-12 11:23:35.400193705 +0100
+++ gcc/config/i386/i386.c2013-02-12 12:38:30.775503155 +0100
@@ -5436,7 +5436,9 @@ ix86_legitimate_combined_insn (rtx insn)
static unsigned HOST_WIDE_INT
ix86_asan_shadow_offset (void)
{
- return (unsigned HOST_WIDE_INT) 1 (TARGET_LP64 ? 44 : 29);
+ return TARGET_LP64 ? (TARGET_MACHO ? (HOST_WIDE_INT_1 44)
+ : HOST_WIDE_INT_C (0x7fff8000))
+ : (HOST_WIDE_INT_1 29);
}
/* Argument support functions. */
[Bug c++/56291] [4.6/4.7/4.8 Regression] ICE for C++11 in output_constructor_regular_field, at varasm.c:4821
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56291 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2013-02-12 11:50:02 UTC --- I think the problem is in sort_constexpr_mem_initializers, which doesn't handle this case. CLASSTYPE_PRIMARY_BINFO (type) is NULL, thus it doesn't reorder anything, but in this case, because the base class is not virtual, but type is, the _vptr field comes last in the field list (and in the v vector), yet it is placed before the base. Jason, can you please have a look? Do you think this is the only problematic case left? Worst case we could fall through into a full blown vec qsort based on field offsets.
[Bug libgcc/56296] Undefined reference to __sync_add_and_fetch_8 for int64_t on MIPS32.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56296 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 2013-02-12 11:56:39 UTC --- Why do you think this is a bug? If a target doesn't support atomic operations on certain variable sizes, this is what you get, you are out of luck with atomicity in that case. In GCC 4.8 you can use libatomic which will provide emulation for that case using locks (though, of course, in that case all accesses to the var need to be done using atomic builtins).
[Bug libgcc/56296] Undefined reference to __sync_add_and_fetch_8 for int64_t on MIPS32.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56296 --- Comment #2 from Balazs Kilvady kilvadyb at homejinni dot com 2013-02-12 12:12:22 UTC --- (In reply to comment #1) Why do you think this is a bug? If a target doesn't support atomic operations on certain variable sizes, this is what you get, you are out of luck with atomicity in that case. In GCC 4.8 you can use libatomic which will provide emulation for that case using locks (though, of course, in that case all accesses to the var need to be done using atomic builtins). Thank you for the quick reply.
[Bug fortran/46952] [OOP] Spurious recursive call error with type bound procedure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46952 --- Comment #7 from janus at gcc dot gnu.org 2013-02-12 12:15:40 UTC --- Author: janus Date: Tue Feb 12 12:15:26 2013 New Revision: 195975 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195975 Log: 2013-02-12 Janus Weil ja...@gcc.gnu.org PR fortran/46952 * resolve.c (resolve_call): Do not check deferred procedures for recursiveness. 2013-02-12 Janus Weil ja...@gcc.gnu.org PR fortran/46952 * gfortran.dg/typebound_deferred_1.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/typebound_deferred_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/46952] [OOP] Spurious recursive call error with type bound procedure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46952 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from janus at gcc dot gnu.org 2013-02-12 12:21:01 UTC --- Fixed with r195975. Closing.
[Bug lto/56295] [4.8 Regression] Missed optimization with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56295
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2013-02-12
AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org
|gnu.org |
Target Milestone|--- |4.8.0
Ever Confirmed|0 |1
--- Comment #2 from Richard Biener rguenth at gcc dot gnu.org 2013-02-12
12:21:19 UTC ---
With -O3 -flto the loop is not peeled before loop-distribution and thus the
inner loop is identified as memcpy. With -O3 the inner loop is peeled.
That is because at cunrolli we see with -flto
Statement _8 = b[i_1][j_2];
is probably executed at most 3 (bounded by 3) + 1 times in loop 2.
vs. without -flto
Statement _8 = b[i_1][j_2];
is executed at most 3 (bounded by 3) + 1 times in loop 1.
With -flto we run into
/* For arrays at the end of the structure, we are not guaranteed that they
do not really extend over their declared size. However, for arrays of
size greater than one, this is unlikely to be intended. */
if (array_at_struct_end_p (base))
{
at_end = true;
upper = false;
for b[i_1][j_2] (where it is really a MEM[b][i_1][j_2]). That's because
array_at_struct_end_p doesn't consider MEM_REFs and we (in this case)
needlessly wrap b in a MEM_REF during streaming out (so that at input time
prevailing decl replacement does not change aliasing / tree code validity).
We should probably undo this at streaming in time where possible.
I have a patch that does this.
[Bug tree-optimization/56294] BOOT_CFLAGS='-O2 -g -fno-ipa-sra' leads to bootstrap comparison failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56294 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org 2013-02-12 12:28:28 UTC --- Is it a compare-debug failure?
[Bug c++/56292] False positive for constexpr arithmetics (-Wconversion)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56292 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org 2013-02-12 12:29:28 UTC --- Does it also warn if you make value a constexpr?
[Bug middle-end/56290] [4.8 Regression] ICE building OpenFOAM in in ipa_make_edge_direct_to_target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56290 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug lto/56297] New: LTO: multiple definition error with global register variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56297 Bug #: 56297 Summary: LTO: multiple definition error with global register variables Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: d.g.gorbac...@gmail.com Created attachment 29424 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29424 Testcase This testcase causes multiple definition of 'esp' error (note that esp has a fixed role, there is no need to reserve it).
[Bug fortran/56293] Segfault when trying to access pass-by-reference value of a not-word-aligned REAL(16) / -fno-align-commons
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56293 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Summary|I/O: Segfault in|Segfault when trying to |write_float when trying to |access pass-by-reference |print a not-word-aligned|value of a not-word-aligned |REAL(16) / |REAL(16) / |-fno-align-commons |-fno-align-commons --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2013-02-12 12:35:19 UTC --- Also occurs if one calls (call foo(p)): subroutine foo(x) real(16) :: x, y y = x ! FAILS HERE ! print *, y end subroutine foo instead of print *, p. The bug is probably somewhere in gcc/fortran/trans-common.c's. For instance at build_common_decl, which uses: if (!com-is_bind_c) DECL_ALIGN (decl) = BIGGEST_ALIGNMENT; or/and in build_field, which has: known_align = (offset -offset) * BITS_PER_UNIT; if (known_align == 0 || known_align BIGGEST_ALIGNMENT) known_align = BIGGEST_ALIGNMENT; desired_align = update_alignment_for_field (rli, field, known_align); if (desired_align known_align) (field) = 1; or …
[Bug fortran/56293] Segfault when trying to access pass-by-reference value of a not-word-aligned REAL(16) / -fno-align-commons
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56293 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org 2013-02-12 12:39:55 UTC --- (In reply to comment #3) Also occurs if one calls (call foo(p)): subroutine foo(x) real(16) :: x, y y = x ! FAILS HERE ! print *, y end subroutine foo instead of print *, p. The bug is probably somewhere in gcc/fortran/trans-common.c's. For instance at build_common_decl, which uses: if (!com-is_bind_c) DECL_ALIGN (decl) = BIGGEST_ALIGNMENT; or/and in build_field, which has: known_align = (offset -offset) * BITS_PER_UNIT; if (known_align == 0 || known_align BIGGEST_ALIGNMENT) known_align = BIGGEST_ALIGNMENT; desired_align = update_alignment_for_field (rli, field, known_align); if (desired_align known_align) (field) = 1; or … The problem is that you are in no way dealing with the interface mismatches in a correct way. Not that I think you can. I suggest to remove -fno-align-commons. Or is there a fortran way to say that subroutine foo(x) real(16) :: x, y may receive an unaligned x? It seems to me that with an -fno-align-commons common you cannot do very much. You'd have to make sure to always access it though the common and never pass pieces of it to another function (maybe the frontend could warn about this). Can you specify -fno-align-commons per common block?
[Bug other/56298] New: wmmintrin.h aborts compilation on the machines without AES
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56298
Bug #: 56298
Summary: wmmintrin.h aborts compilation on the machines without
AES
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: piotr.wyder...@gmail.com
I have a piece of C++ code which computes a hash function
using the AES-NI extensions of the Sandy/IvyBridge x64 processors.
It is automatically selected if the target platform supports the
mentioned extensions via cpuid. To use e.g. _mm_aesenc_si128()
one needs to include wmmintrin.h, which is also a full test
case here. If the host does not implement AES-NI (detected via
-march=native or it is not explicitly enabled by -maes), the
compilation process fails abruptly due to the content of wmmintrin.h:
#if !defined (__AES__) !defined (__PCLMUL__)
# error AES/PCLMUL instructions not enabled
#else
It is a very serious bug (so I decided to mark is as major),
because the intrinsics available should not depend on command
line settings -- it is the user who takes full responsibility
for their correct use and availability checking, as it is in
my case. Enabling -maes is not an option, because it would then
allow the code generator to unconditionally emit the AES-NI
instructions in places I don't control, which will result in
SIGILL and a core dump. This bug probably applies to all
recent GCC versions, including 4.7.2 and 4.6.3.
On MSVC2010 the respective header contains no such compile-time
checks, i.e. it is fully consistent with the intended behaviour
described above:
/*
* wmmintrin.h
*
* Principal header file for Intel(R) AES and PCLMULQDQ intrinsics.
*/
#pragma once
#ifndef __midl
#ifndef _INCLUDED_WMM
#define _INCLUDED_WMM
#if defined(_M_CEE_PURE)
#error ERROR: EMM intrinsics not supported in the pure mode!
#else
#include nmmintrin.h
#if __cplusplus
extern C {
#endif
/*
* Performs 1 round of AES decryption of the first m128i using
* the second m128i as a round key.
*/
extern __m128i _mm_aesdec_si128(__m128i v, __m128i rkey);
etc.
[Bug fortran/56284] [OOP] ICE with alternate return in type-bound procedure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56284 --- Comment #9 from Dominique d'Humieres dominiq at lps dot ens.fr 2013-02-12 12:57:55 UTC --- Do you understand why the test in gfc_match_return (file match.c) if (gfc_notify_std (GFC_STD_F95_OBS, Alternate RETURN at %C) == FAILURE) return MATCH_ERROR; is not used? Note that the error is slightly different to the one used in comment #5. Otherwise the patches fix this PR without regression. Thanks.
[Bug tree-optimization/56175] Issue with combine phase on x86.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56175 --- Comment #7 from Yuri Rumyantsev ysrumyan at gmail dot com 2013-02-12 13:05:16 UTC --- (In reply to comment #6) (In reply to comment #5) This pattern is already recognized by simplify_bitwise_binary but only for usual int type, i.e. if we change all short types to the ordinary int (or unsigned) this simplification takes place (dump after 1st forwprop): bb 4: x_8 = x_2(D) 1; y_9 = y_4(D) 1; _10 = x_8 1; _11 = y_9 1; _16 = x_8 ^ y_9; z_12 = _16 1; i.e. the issue is redundant type conversions: bb 3: x_7 = x_2(D) 1; y_8 = y_4(D) 1; _13 = x_7 1; _9 = (signed char) _13; _14 = y_8 1; _10 = (signed char) _14; _11 = _9 ^ _10; I assume that if we delete these redundant conversions the required simplification will happen. Ah, well. The issue is that we transformed (unsigned char)y 1 to (unsigned char)(y 1). Hi Richard, We'd like to fix this issue since we can get +10.5% speedup on Atom. What is your opinion on how better to fix this issue with 1st pattern in simplify_bitwise_binary? I have no idea why gcc does such transformation and what gain we can get from it - decrease size of constant or create more opportunities for cse? I can propose the following possible changes: 1. Introduce a hook for doing such transformation. 2. Introduce a new forwprop pass that does not do such transformation. 3. Do not perform such transformation for small positive constant. 4. Do not performa such transformation if (type-x) c == c. etc. Any help will be appreciated. Yuri.
[Bug fortran/56293] Segfault when trying to access pass-by-reference value of a not-word-aligned REAL(16) / -fno-align-commons
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56293 --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2013-02-12 13:07:10 UTC --- Some tests with ifort, which by default uses unaligned commons: The first test case works, i.e. I/O with the unaligned p works. However, if one calls a user procedure (call foo(p)), it segfaults. Possible solutions: a) Copy-in/copy-out around procedure calls - which is fun with large arrays. b) Require the user to annotate the functions to possibly accept unaligned input – or do so automatically. (With all the fun of third-party libraries like LAPACK, BLAS, ...) c) Simply deprecating the -fno-align-commons flag, improving the wording of the diagnostic and the description in the man page. Somehow, I am in favour of (c). The question is also whether one can construct a fully standard-conform example which fails without -fno-align-commons – and whether some real-world code uses COMMON in a way that would fails with alignments/padding.
[Bug other/56298] wmmintrin.h aborts compilation on the machines without AES
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56298 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 2013-02-12 13:13:50 UTC --- It is not a bug, it is a way all the intrinsics headers are written. You can use #pragma GCC push_options #pragma GCC target (aes) #include wmmintrin.h #pragma GCC pop_options and similar.
[Bug other/56298] wmmintrin.h aborts compilation on the machines without AES
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56298 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org 2013-02-12 13:16:47 UTC --- The intrinsics do _not_ work if the corresponding CPU ISA feature is not enabled on the command-line. That's a fact - whether that's good is another question. A CPU feature agnostic intrinsics implementation would need to use inline-asm. A workaround is to put the AES-NI using function into a separate translation unit that you compile with -maes. This bug also applies to the new multiversioning feature or the target attribute feature all of which do not allow intrinsic header uses without globally enabling CPU ISA features (well, for the target attribute you could switch the ISA features _off_ in all places you do not want to use them ... ick). Thus, confirmed. The situation isn't really desirable (but maybe not easily fixable, too). The Intel compiler intrinsic headers do not use inline functions but the intrinsic decls directly (as if they were builtins). GCC 4.1 simply effectively made the intrinsics headers empty (by wrapping them in #ifdef FEATURE), at least since GCC 4.3 we have the #errors.
[Bug target/56298] wmmintrin.h aborts compilation on the machines without AES
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56298 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target||x86_64-*-*, i?86-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2013-02-12 Component|other |target Ever Confirmed|0 |1
[Bug target/56298] wmmintrin.h aborts compilation on the machines without AES
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56298 --- Comment #3 from Piotr Wyderski piotr.wyderski at gmail dot com 2013-02-12 13:22:04 UTC --- I beg to disagree, Jakub. In that case all the intrinsics headers are written in a wrong way. At least if one takes MSVC as a reference (which behaves exactly as I expected). Could somebody check how does ICC implement them? Thank you for the workaround, BTW.
[Bug target/55431] Invalid auxv search in ppc linux-unwind code.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55431 --- Comment #7 from Alan Modra amodra at gmail dot com 2013-02-12 13:23:59 UTC --- On thinking about this a little more, the idea of using /proc/self/auxv isn't that good. MD_FALLBACK_FRAME_STATE_FOR is only needed for older kernels; Kernels 2.6.15 and later provide a vdso with unwind info for signal frames. So I don't think it makes sense to restrict libgcc's support for old kernels to 2.6.0 thru 2.6.14. If we're going to support old kernels, then we ought to continue supporting them all as best we can. And, yes, really old kernels used a different sigcontext for the simple reason that they predated altivec. I'm inclined to close this bug as WONTFIX, or possibly make __libc_stack_end weak so that libgcc builds with musl libc.
[Bug tree-optimization/56175] Issue with combine phase on x86.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56175 --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org 2013-02-12 13:25:59 UTC --- (In reply to comment #7) (In reply to comment #6) (In reply to comment #5) This pattern is already recognized by simplify_bitwise_binary but only for usual int type, i.e. if we change all short types to the ordinary int (or unsigned) this simplification takes place (dump after 1st forwprop): bb 4: x_8 = x_2(D) 1; y_9 = y_4(D) 1; _10 = x_8 1; _11 = y_9 1; _16 = x_8 ^ y_9; z_12 = _16 1; i.e. the issue is redundant type conversions: bb 3: x_7 = x_2(D) 1; y_8 = y_4(D) 1; _13 = x_7 1; _9 = (signed char) _13; _14 = y_8 1; _10 = (signed char) _14; _11 = _9 ^ _10; I assume that if we delete these redundant conversions the required simplification will happen. Ah, well. The issue is that we transformed (unsigned char)y 1 to (unsigned char)(y 1). Hi Richard, We'd like to fix this issue since we can get +10.5% speedup on Atom. What is your opinion on how better to fix this issue with 1st pattern in simplify_bitwise_binary? I have no idea why gcc does such transformation and what gain we can get from it - decrease size of constant or create more opportunities for cse? Well, you'd have to track down what is responsible for that transform. Generally promoting operations (and automatic vars) to word-mode may be beneficial on most targets. But that should be done late. I can propose the following possible changes: 1. Introduce a hook for doing such transformation. 2. Introduce a new forwprop pass that does not do such transformation. 3. Do not perform such transformation for small positive constant. 4. Do not performa such transformation if (type-x) c == c. etc. First track it down ;) Any help will be appreciated. Yuri.
[Bug c++/56299] New: Dependent lambda expression breaks explicit template instantiation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56299
Bug #: 56299
Summary: Dependent lambda expression breaks explicit template
instantiation
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ers.tr...@gmail.com
The following code produces an internal compiler error:
templateclass T
class Foo
{
void process(Foo m);
void bar()
{
[this] { process(Foo()); }();
}
};
template class Fooint;
Output:
foo.cpp: In lambda function:
foo.cpp:11:24: internal compiler error: in get_expr_operands, at
tree-ssa-operands.c:1035
Please submit a full bug report,
with preprocessed source if appropriate.
Compiler info:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/src/gcc-4.7.2/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.2 (GCC)
[Bug target/56298] wmmintrin.h aborts compilation on the machines without AES
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56298 --- Comment #4 from Piotr Wyderski piotr.wyderski at gmail dot com 2013-02-12 13:30:37 UTC --- @Richard: I don't have ICC right now, so a follow-up question is: does ICC enable those built-in intrinsics conditionally (as does GCC) or not (as MSVC). I think that ICC is the golden standard in this respect, so the answer would ultimately indicate whether my report is valid (and the bug should be fixed some day) or not. Thanks.
[Bug fortran/56284] [OOP] ICE with alternate return in type-bound procedure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56284
--- Comment #10 from janus at gcc dot gnu.org 2013-02-12 13:31:22 UTC ---
(In reply to comment #9)
Do you understand why the test in gfc_match_return (file match.c)
if (gfc_notify_std (GFC_STD_F95_OBS, Alternate RETURN
at %C) == FAILURE)
return MATCH_ERROR;
is not used?
Yeah. The reason is that this one only triggers on an actual RETURN statement,
but not if an unused alt-return argument is declared (as e.g. in comment 2).
Note that the error is slightly different to the one used in comment #5.
Yes, I did that on purpose, since both warn for slightly different things: The
former for an ('alternate') RETURN statement and the latter for an
alternate-return dummy argument.
In fact one could think about removing the error message in gfc_match_return
and only keeping the one in gfc_match_formal_arglist. After all it makes no
sense to have an alternate RETURN statement without an alternate-return dummy.
However, since gfortran only gives a warning for this case(*), I think it does
not hurt to keep both error messages.
(*) Warning: An alternate return at (1) without a * dummy argument
[Bug lto/56297] LTO: multiple definition error with global register variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56297 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-02-12 CC||hubicka at gcc dot gnu.org AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2013-02-12 13:39:15 UTC --- Confirmed. We put register int i asm (esp); into the LTO symbol table. Oops. The GCC symtab and the partition contains (gdb) call debug_symtab_node (node) *esp/0 (*esp) @0x76e1a068 Type: variable Visibility: force_output public References: Referring: main/1 (read) Availability: overwritable Varpool flags: analyzed finalized not sure if we want to put global hardregs into the symtab at all ... (certainly not in the LTO symbol table we feed to the linker). Thus, maybe Index: gcc/lto-streamer-out.c === --- gcc/lto-streamer-out.c (revision 195973) +++ gcc/lto-streamer-out.c (working copy) @@ -1166,7 +1166,8 @@ write_symbol (struct streamer_tree_cache if (!TREE_PUBLIC (t) || is_builtin_fn (t) || DECL_ABSTRACT (t) - || TREE_CODE (t) == RESULT_DECL) + || TREE_CODE (t) == RESULT_DECL + || (TREE_CODE (t) == VAR_DECL DECL_HARD_REGISTER (t))) return; gcc_assert (TREE_CODE (t) == VAR_DECL ? At least it works with that change. Testing it.
[Bug lto/56297] LTO: multiple definition error with global register variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56297 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org 2013-02-12 13:46:52 UTC --- GCC 4.7 says /tmp/ccQAPnYJ.o (symbol from plugin): In function `esp': (.text+0x0): multiple definition of `esp' /tmp/ccihIbJc.o (symbol from plugin):(.text+0x0): first defined here In file included from foo.c:6:0, from :0: bar.c:1:14: warning: register of 'i' used for multiple global register variables [enabled by default] In file included from :0:0: foo.c:1:14: note: conflicts with 'i' collect2: error: ld returned 1 exit status with trunk we lost that (bogus) warning. Even when using two different variable names.
[Bug target/56298] wmmintrin.h aborts compilation on the machines without AES
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56298 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org 2013-02-12 13:49:41 UTC --- Can you give me a testcase that I can compile?
[Bug target/56298] wmmintrin.h aborts compilation on the machines without AES
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56298
--- Comment #6 from Piotr Wyderski piotr.wyderski at gmail dot com 2013-02-12
13:55:08 UTC ---
#include wmmintrin.h
__m128i f(__m128i x, __m128i y) {
return _mm_aesenc_si128(x, y);
}
[Bug sanitizer/55309] gcc's address-sanitizer 66% slower than clang's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309 Jack Howarth howarth at nitro dot med.uc.edu changed: What|Removed |Added CC||howarth at nitro dot ||med.uc.edu --- Comment #40 from Jack Howarth howarth at nitro dot med.uc.edu 2013-02-12 14:00:15 UTC --- (In reply to comment #23) #1 afaict, the asan pass happens in the middle of the gcc optimization flow. imho it should happen as late as possible so that the instrumentation happens on fully optimized code. I can confirm this is the case from my experiments compiling xplor-nih with -fsanitize=address. This code is habitually miscompiled by gfortran at the higher optimizations levels. The addition of the -fsanitize=address flag to the build suppresses most of the xplor-nih testsuite failures indicating that it has changed the code optimization in gfortran. Is there any chance of moving the asan pass or is that definitely stage 1 material?
[Bug lto/56295] [4.8 Regression] Missed optimization with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56295 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org 2013-02-12 14:04:50 UTC --- Author: rguenth Date: Tue Feb 12 14:04:44 2013 New Revision: 195976 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195976 Log: 2013-02-12 Richard Biener rguent...@suse.de PR lto/56295 * gimple-streamer-in.c (input_gimple_stmt): Strip MEM_REFs off decls again if possible. Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-streamer-in.c
[Bug lto/56295] [4.8 Regression] Missed optimization with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56295 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org 2013-02-12 14:05:17 UTC --- Fixed.
[Bug target/56298] wmmintrin.h aborts compilation on the machines without AES
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56298 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2013-02-12 14:08:05 UTC --- Headers are one thing, but you certainly can't use AES builtins in code not compiled with -maes or functions not using __attribute__((target (aes))) or similar. That just can't work, the insns the intrinsics want to use just aren't enabled in those ISA selections, and in other cases (think say just SSE2 ISA code, using AVX intrinsics) neither are the registers, nor modes available, in addition to the instructions.
[Bug sanitizer/55309] gcc's address-sanitizer 66% slower than clang's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309 --- Comment #41 from Jakub Jelinek jakub at gcc dot gnu.org 2013-02-12 14:11:28 UTC --- That is definitely stage1 material, and a lot of work, especially to teach the vectorizer how to deal with these. And, we don't want to introduce the asan instrumentation too late, e.g. vectorization often reads even from memory outside of what the source code actually accesses, when it e.g. knows it is sufficiently aligned and won't cause crashes. That would be false positives for asan.
[Bug tree-optimization/56049] [4.8 Regression] Simplification to constants not done
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56049 Aldy Hernandez aldyh at gcc dot gnu.org changed: What|Removed |Added Severity|normal |enhancement
[Bug tree-optimization/56049] [4.8 Regression] Simplification to constants not done
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56049 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P1 |P2 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2013-02-12 14:28:15 UTC --- Enhancement shouldn't be P1.
[Bug c++/56299] Dependent lambda expression breaks explicit template instantiation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56299 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2013-02-12 14:41:23 UTC --- Already fixed mainline and 4.7.3. *** This bug has been marked as a duplicate of bug 53137 ***
[Bug c++/53137] [4.7/4.8 Regression] g++ segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53137 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||ers.trion at gmail dot com --- Comment #21 from Paolo Carlini paolo.carlini at oracle dot com 2013-02-12 14:41:23 UTC --- *** Bug 56299 has been marked as a duplicate of this bug. ***
[Bug sanitizer/55309] gcc's address-sanitizer 66% slower than clang's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309 --- Comment #42 from Jack Howarth howarth at nitro dot med.uc.edu 2013-02-12 14:41:56 UTC --- (In reply to comment #41) FYI, most of the codegen issues with xplor-nih compiled with gfortran can be suppressed with -fno-tree-vectorize at -O3 (hence my interest in a function libasan on darwin).
[Bug go/56171] syscall FAILs on Solaris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56171 --- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2013-02-12 14:43:41 UTC --- --- Comment #6 from Ian Lance Taylor ian at airs dot com 2013-02-11 19:16:41 UTC --- [...] Note that this test case execs itself in a separate process, so when using truss you need to trace both processes to see what is happening. The WriteMsgUnix failure is happening in the child process. It indicates that sendmsg is returning an EBADF errno value, but I don't know why. One place to look would be the function UnixRights in syscall/sockcmsg_unix.go. Is that the right format for passing a file descriptor on Solaris? It turned out that there was a mismatch between configure.ac which defines -D_XOPEN_SOURCE=500 for Solaris, and libcalls.go: the latter has e.g. //extern sendmsg but according to sys/socket.h, we need #ifdef_XPG4_2 #ifdef__PRAGMA_REDEFINE_EXTNAME #pragma redefine_extname bind __xnet_bind #pragma redefine_extname connect __xnet_connect #pragma redefine_extname recvmsg __xnet_recvmsg #pragma redefine_extname sendmsg __xnet_sendmsg #pragma redefine_extname sendto __xnet_sendto #pragma redefine_extname socket __xnet_socket #pragma redefine_extname socketpair __xnet_socketpair #pragma redefine_extname getsockopt __xnet_getsockopt Depending on whether sendmsg or __xnet_sendmsg is used, the kernel expects different variants of struct msghdr. I hacked around this by manually adapting libcalls.go to use the __xnet_ forms, which allowed the test to pass. I've not yet checked what's the best way to handle this properly. Rainer
[Bug tree-optimization/56175] Issue with combine phase on x86.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56175 --- Comment #9 from Yuri Rumyantsev ysrumyan at gmail dot com 2013-02-12 14:43:53 UTC --- (In reply to comment #8) (In reply to comment #7) (In reply to comment #6) (In reply to comment #5) This pattern is already recognized by simplify_bitwise_binary but only for usual int type, i.e. if we change all short types to the ordinary int (or unsigned) this simplification takes place (dump after 1st forwprop): bb 4: x_8 = x_2(D) 1; y_9 = y_4(D) 1; _10 = x_8 1; _11 = y_9 1; _16 = x_8 ^ y_9; z_12 = _16 1; i.e. the issue is redundant type conversions: bb 3: x_7 = x_2(D) 1; y_8 = y_4(D) 1; _13 = x_7 1; _9 = (signed char) _13; _14 = y_8 1; _10 = (signed char) _14; _11 = _9 ^ _10; I assume that if we delete these redundant conversions the required simplification will happen. Ah, well. The issue is that we transformed (unsigned char)y 1 to (unsigned char)(y 1). Hi Richard, We'd like to fix this issue since we can get +10.5% speedup on Atom. What is your opinion on how better to fix this issue with 1st pattern in simplify_bitwise_binary? I have no idea why gcc does such transformation and what gain we can get from it - decrease size of constant or create more opportunities for cse? Well, you'd have to track down what is responsible for that transform. Generally promoting operations (and automatic vars) to word-mode may be beneficial on most targets. But that should be done late. I can propose the following possible changes: 1. Introduce a hook for doing such transformation. 2. Introduce a new forwprop pass that does not do such transformation. 3. Do not perform such transformation for small positive constant. 4. Do not performa such transformation if (type-x) c == c. etc. First track it down ;) Any help will be appreciated. Yuri. Richard, I am familiar with type promotion transformation that e.g. can transform byte loop counter to word, but this is done by another phases, e.g. lto. We found out the owner of this change http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01988.html What our next steps? Thanks ahead. Yuri.
[Bug tree-optimization/56175] Issue with combine phase on x86.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56175 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||ktietz at gcc dot gnu.org --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2013-02-12 14:46:50 UTC --- For 4.9, Kai is working on type promotion/demotion GIMPLE pass(es), so when discussing that change this can be also taken into account.
[Bug target/54222] [avr] Implement fixed-point support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54222 --- Comment #13 from Georg-Johann Lay gjl at gcc dot gnu.org 2013-02-12 14:55:22 UTC --- Author: gjl Date: Tue Feb 12 14:55:16 2013 New Revision: 195978 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195978 Log: gcc/ PR target/54222 * config/avr/avr-dimode.md (umulsidi3, mulsidi3): New expanders. (umulsidi3_insn, mulsidi3_insn): New insns. libgcc/ PR target/54222 * config/avr/t-avr (LIB2FUNCS_EXCLUDE): Add: _usmulUHA, _usmulUSA, _ssmulHA, _ssmulSA. (LIB1ASMFUNCS): Add: _muldi3_6, _mulsidi3, _umulsidi3, _usmuluha3, _ssmulha3, _usmulusa3, _ssmulsa3. * config/avr/lib1funcs.S (__muldi3_6): Break out of __muldi3. (__muldi3): XCALL __muldi3_6 instead of rcall. (__umulsidi3, __mulsidi3): New functions. (do_prologue_saves, do_epilogue_restores): New .macros. (__divdi3_moddi3): Use them. * config/avr/lib1funcs-fixed.S (__usmuluha3, __ssmulha3) (__usmulusa3, __ssmulsa3): New functions. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr-dimode.md trunk/libgcc/ChangeLog trunk/libgcc/config/avr/lib1funcs-fixed.S trunk/libgcc/config/avr/lib1funcs.S trunk/libgcc/config/avr/t-avr
[Bug go/56171] syscall FAILs on Solaris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56171 --- Comment #8 from Ian Lance Taylor ian at airs dot com 2013-02-12 15:02:12 UTC --- I think we'll need to pull the relevant //sys lines out of socket.go into, e.g., socket_posix.go, and then add socket_xnet.go, and arrange for the Makefile to choose between them based on LIBGO_IS_SOLARIS.
[Bug c++/56291] [4.6/4.7/4.8 Regression] ICE for C++11 in output_constructor_regular_field, at varasm.c:4821
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56291 Freddie Chopin freddie_chopin at op dot pl changed: What|Removed |Added CC||freddie_chopin at op dot pl --- Comment #7 from Freddie Chopin freddie_chopin at op dot pl 2013-02-12 15:08:42 UTC --- I really don't understand why Paolo Carlini is constantly removing me from the CC list...
[Bug lto/56297] LTO: multiple definition error with global register variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56297 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org 2013-02-12 15:14:37 UTC --- Author: rguenth Date: Tue Feb 12 15:14:32 2013 New Revision: 195979 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195979 Log: 2013-02-12 Richard Biener rguent...@suse.de PR lto/56297 * lto-streamer-out.c (write_symbol): Do not output symbols for hard register variables. * gcc.dg/lto/pr56297_0.c: New testcase. * gcc.dg/lto/pr56297_0.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/lto/pr56297_0.c trunk/gcc/testsuite/gcc.dg/lto/pr56297_1.c Modified: trunk/gcc/ChangeLog trunk/gcc/lto-streamer-out.c trunk/gcc/testsuite/ChangeLog
[Bug lto/56297] LTO: multiple definition error with global register variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56297 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org 2013-02-12 15:16:11 UTC --- Fixed for 4.8.
[Bug c++/56291] [4.6/4.7/4.8 Regression] ICE for C++11 in output_constructor_regular_field, at varasm.c:4821
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56291 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2013-02-12 15:17:45 UTC --- Perhaps because you are the reporter and reporter is always CCed on the PRs, no matter if on CC or not?
[Bug c++/56292] False positive for constexpr arithmetics (-Wconversion)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56292 --- Comment #4 from lcid-fire at gmx dot net 2013-02-12 15:23:58 UTC --- constexpr std::uint8_t value = func() + 2; does generate the same warning.
[Bug lto/55493] [4.8 Regression] LTO always ICEs on i686-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55493 --- Comment #10 from Kai Tietz ktietz at gcc dot gnu.org 2013-02-12 15:27:45 UTC --- Well, I re-tried to reproduce this issue with current 4.8 gcc version (native). As before, I can't reproduce that issue. Anyway I don't get what report was actual doing differently as I did, so I will keep this bug open. Nevertheless we had recently some changes to lto, which are affecting mingw targets, so it might be worth that report are retrying to reproduce. Please make sure that you aren't mixing objects with LTO-infomration of different versions.
[Bug target/55431] Invalid auxv search in ppc linux-unwind code.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55431 --- Comment #8 from Rich Felker bugdal at aerifal dot cx 2013-02-12 15:27:58 UTC --- Is there nothing internal in the sigcontext structure that distinguishes the version? Making the reference to __libc_stack_end weak won't help. If the symbol is undefined, the code in libgcc would crash or malfunction; if it's defined but does not point exactly to the argc/argv start (which, since it's not defined in the ABI, seems to be something that could happen in the future even with glibc), the code will also badly malfunction. If you want to keep using __libc_stack_end, I think it should be conditional at runtime on old/broken kernel and libc versions, and auxv should be ignored otherwise.
[Bug c++/56291] [4.6/4.7/4.8 Regression] ICE for C++11 in output_constructor_regular_field, at varasm.c:4821
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56291 --- Comment #9 from Freddie Chopin freddie_chopin at op dot pl 2013-02-12 15:31:46 UTC --- (In reply to comment #8) Perhaps because you are the reporter and reporter is always CCed on the PRs, no matter if on CC or not? If you remove me from the CC list I won't receive the comments that appear here, and I don't mind reading them. If my mailbox gets spammed with messages from bugzilla I'll remove myself, so no worries (; Thx in advance for NOT-removing me again.
[Bug target/52122] [4.6/4.7/4.8 Regression] incorrect ln -s replacement for mingw like targets in configure files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52122 --- Comment #15 from Kai Tietz ktietz at gcc dot gnu.org 2013-02-12 15:32:15 UTC --- Author: ktietz Date: Tue Feb 12 15:32:01 2013 New Revision: 195980 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195980 Log: PR target/52122 * Makefile.in (LN_S_RECUSIVE): New. (adainclude, adalib): Use LN_S_RECURSIVE for copy. Modified: trunk/libada/ChangeLog trunk/libada/Makefile.in
[Bug target/52122] [4.6/4.7/4.8 Regression] incorrect ln -s replacement for mingw like targets in configure files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52122 --- Comment #16 from Kai Tietz ktietz at gcc dot gnu.org 2013-02-12 15:37:09 UTC --- Author: ktietz Date: Tue Feb 12 15:36:56 2013 New Revision: 195981 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195981 Log: PR target/52122 * Makefile.in (LN_S_RECUSIVE): New. (adainclude, adalib): Use LN_S_RECURSIVE for copy. Modified: branches/gcc-4_7-branch/libada/ChangeLog branches/gcc-4_7-branch/libada/Makefile.in
[Bug target/52122] [4.6/4.7/4.8 Regression] incorrect ln -s replacement for mingw like targets in configure files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52122 --- Comment #17 from Kai Tietz ktietz at gcc dot gnu.org 2013-02-12 15:39:07 UTC --- Author: ktietz Date: Tue Feb 12 15:38:57 2013 New Revision: 195982 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195982 Log: PR target/52122 * Makefile.in (LN_S_RECUSIVE): New. (adainclude, adalib): Use LN_S_RECURSIVE for copy. Modified: branches/gcc-4_6-branch/libada/ChangeLog branches/gcc-4_6-branch/libada/Makefile.in
[Bug target/52122] [4.6/4.7/4.8 Regression] incorrect ln -s replacement for mingw like targets in configure files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52122 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Priority|P2 |P5 Status|UNCONFIRMED |WAITING Last reconfirmed||2013-02-12 Ever Confirmed|0 |1 --- Comment #18 from Kai Tietz ktietz at gcc dot gnu.org 2013-02-12 15:44:07 UTC --- So required patch is applied to 4.6 branch , 4.7 branch, and trunk. Issue is fixed. As reminder I will keep this bug in status waiting, so we don't miss to remove this patch as soon as libtool got updated.
[Bug target/56298] wmmintrin.h aborts compilation on the machines without AES
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56298
--- Comment #8 from Richard Biener rguenth at gcc dot gnu.org 2013-02-12
15:47:33 UTC ---
(In reply to comment #6)
#include wmmintrin.h
__m128i f(__m128i x, __m128i y) {
return _mm_aesenc_si128(x, y);
}
Compiling that with icc -S t.c results in
f:
# parameter 1: %xmm0
# parameter 2: %xmm1
..B1.1: # Preds ..B1.0
..___tag_value_f.1: #3.33
aesenc%xmm1, %xmm0 #5.16
ret #5.16
[Bug c++/56291] [4.6/4.7/4.8 Regression] ICE for C++11 in output_constructor_regular_field, at varasm.c:4821
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56291 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC|freddie_chopin at op dot pl | --- Comment #10 from Paolo Carlini paolo.carlini at oracle dot com 2013-02-12 15:51:07 UTC --- Because you are *already* CC-ed as submitter.
[Bug testsuite/56082] FAIL: gfortran.dg/bind_c_bool_1.f90 -O (test for errors, line 18) on powerpc-apple-darwin9 with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56082 --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2013-02-12 16:22:26 UTC --- Author: burnus Date: Tue Feb 12 16:22:13 2013 New Revision: 195984 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195984 Log: 2013-02-12 Dominique d'Humieres domi...@lps.ens.fr Tobias Burnus bur...@net-b.de PR fortran/56082 * gfortran.dg/bind_c_bool_1.f90 (sub): Change kind=4 to kind=2 as 32bit Darwin has C_Bool == 4. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/bind_c_bool_1.f90
[Bug lto/56297] LTO: multiple definition error with global register variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56297 --- Comment #5 from Jan Hubicka hubicka at ucw dot cz 2013-02-12 16:23:37 UTC --- Confirmed. We put register int i asm (esp); into the LTO symbol table. Oops. The GCC symtab and the partition contains (gdb) call debug_symtab_node (node) *esp/0 (*esp) @0x76e1a068 Type: variable Visibility: force_output public References: Referring: main/1 (read) Availability: overwritable Varpool flags: analyzed finalized not sure if we want to put global hardregs into the symtab at all ... (certainly not in the LTO symbol table we feed to the linker). Thus, maybe Index: gcc/lto-streamer-out.c === --- gcc/lto-streamer-out.c (revision 195973) +++ gcc/lto-streamer-out.c (working copy) @@ -1166,7 +1166,8 @@ write_symbol (struct streamer_tree_cache if (!TREE_PUBLIC (t) || is_builtin_fn (t) || DECL_ABSTRACT (t) - || TREE_CODE (t) == RESULT_DECL) + || TREE_CODE (t) == RESULT_DECL + || (TREE_CODE (t) == VAR_DECL DECL_HARD_REGISTER (t))) return; gcc_assert (TREE_CODE (t) == VAR_DECL ? At least it works with that change. Testing it. Yeah, I suppose we ought to put those out of symbol table for 4.9. I have local patch for that. Honza
[Bug tree-optimization/56273] [4.8 regression] Bogus -Warray-bounds warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56273 --- Comment #9 from vincenzo Innocente vincenzo.innocente at cern dot ch 2013-02-12 16:24:11 UTC --- I am just rebuilding (Updated to revision 195983.) and noticed /home/data/newsoft/gcc-build/./gcc/xgcc -B/home/data/newsoft/gcc-build/./gcc/ -B/afs/cern.ch/user/i/innocent/w2/x86_64-unknown-linux-gnu/bin/ -B/afs/cern.ch/user/i/innocent/w2/x86_64-unknown-linux-gnu/lib/ -isystem /afs/cern.ch/user/i/innocent/w2/x86_64-unknown-linux-gnu/include -isystem /afs/cern.ch/user/i/innocent/w2/x86_64-unknown-linux-gnu/sys-include-g -O2 -ftree-vectorize -fPIC -O2 -g -O2 -ftree-vectorize -fPIC -DIN_GCC -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I. -I../.././gcc -I../../../gcc-trunk/libgcc -I../../../gcc-trunk/libgcc/. -I../../../gcc-trunk/libgcc/../gcc -I../../../gcc-trunk/libgcc/../include -I../../../gcc-trunk/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -g0 -finhibit-size-directive -fno-inline -fno-exceptions -fno-zero-initialized-in-bss -fno-toplevel-reorder -fno-tree-vectorize -fno-stack-protector -I. -I. -I../.././gcc -I../../../gcc-trunk/libgcc -I../../../gcc-trunk/libgcc/. -I../../../gcc-trunk/libgcc/../gcc -I../../../gcc-trunk/libgcc/../include -I../../../gcc-trunk/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -o crtend.o -MT crtend.o -MD -MP -MF crtend.dep -fno-omit-frame-pointer -fno-asynchronous-unwind-tables -c ../../../gcc-trunk/libgcc/crtstuff.c -DCRT_END ../../../gcc-trunk/libgcc/crtstuff.c: In function 'frame_dummy': ../../../gcc-trunk/libgcc/crtstuff.c:463:19: warning: array subscript is above array bounds [-Warray-bounds] if (__JCR_LIST__[0]) is this real or bogus?
[Bug inline-asm/56148] [4.8 Regression] inline asm matching constraint with different mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56148
Steven Bosscher steven at gcc dot gnu.org changed:
What|Removed |Added
CC||steven at gcc dot gnu.org
--- Comment #7 from Steven Bosscher steven at gcc dot gnu.org 2013-02-12
16:24:39 UTC ---
(in my previous post I of course mean inputs and constraints...)
Breaking down the insn once more in something that's more readable
to me at least:
(parallel [
(set (reg:DI 63 [ a ]) (asm_in[0] (reg:SI 67) 0))
(set (reg:DI 64 [ c ]) (asm_in[1] (reg:DI 65) mr))
(set (reg:DI 65 [ d ]) (asm_in[2] (reg:SI 69) 1))
(set (reg:DI 66 [ b ]) (asm_in[3] (reg:DI 65) 2))
(asm_in[4] (reg:SI 67) 3)])
so
- r67:SI must match r63:DI
- r69:SI must match r64:DI
- r65:DI must match r65:DI
- r67:SI must match r66:DI
The last constraint comes from CSE, which transforms:
[ (reg:SI 67)
(reg:DI 68)
(reg:SI 69)
(reg:DI 70)
(reg:SI 71) ]
to
[ (reg:SI 67)
(reg/f:DI 68)
(reg:SI 69)
(reg/f:DI 68)
(reg:SI 67) ]
because r70 and r68 have the same value before CSE:
6: {r68:DI=frame:DI-0x10;clobber flags:CC;}
8: {r70:DI=frame:DI-0x10;clobber flags:CC;}
and CSE cleans that up:
6: {r68:DI=frame:DI-0x10;clobber flags:CC;}
8: r70:DI=r68:DI
Disabling or undoing that transformation makes the ICE disappear.
This is also in effect what old reload does with reload insn 21.
[Bug lto/56295] [4.8 Regression] Missed optimization with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56295 --- Comment #5 from Dmitry Gorbachev d.g.gorbachev at gmail dot com 2013-02-12 16:26:39 UTC --- Created attachment 29425 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29425 Modified testcase This slightly modified testcase still shows some strange difference between LTO / non-LTO.
[Bug testsuite/56082] FAIL: gfortran.dg/bind_c_bool_1.f90 -O (test for errors, line 18) on powerpc-apple-darwin9 with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56082 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||burnus at gcc dot gnu.org Resolution||FIXED --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2013-02-12 16:27:12 UTC --- Should be FIXED. Thanks Dominique for the report, debugging the issue, and for the patch!
