[Bug fortran/49359] fmm_aux_qlm_builder.f90:154: internal compiler error: in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49359 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||burnus at gcc dot gnu.org Resolution||DUPLICATE --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2011-06-10 06:10:10 UTC --- Same assert as PR 49297 - mark as duplicate. As written, without details about the compile (gfortran -v) and without access to the source code, debugging is impossible. I still believe that you use GCC 4.0 and not 4.6 as otherwise the line number (trans-expr.c:268) in the error message does not make sense. You could try to contact the Molcas developers as they do have access to the source code of Molcas: http://www.molcas.org/contact.html *** This bug has been marked as a duplicate of bug 49297 ***
[Bug fortran/49297] ICE gfc_conv_component_ref, at fortran/trans-expr.c:268 when compiling molcas7.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49297 --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2011-06-10 06:10:10 UTC --- *** Bug 49359 has been marked as a duplicate of this bug. ***
[Bug c/49360] New: generate wrong logic code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49360
Summary: generate wrong logic code
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: wux...@gmail.com
GCC version 4.6.0.
bug description:
gcc : *mipsel* cross compiler
in objdumped files :
=
bfc0003c:afc40018 swa0,24(s8)
bfc00040:afc5001c swa1,28(s8)
/home/wuxb/workspace/gcc/test_1001/mips_1001.c:5
int a, b, temp;
if(num1num2) /*want n1n2*/
bfc00044:8fc30018 lwv1,24(s8)
bfc00048:8fc2001c lwv0,28(s8)
bfc0004c: nop
bfc00050:0062102a sltv0,v1,v0
bfc00054:104a beqzv0,bfc00080 lcm+0x50
=
the logic int code was
if (num1 num2) {do-sth.}
but in the generated code, it is
if (! (num1 num2) {do-sth.}
in line bfc00054, the instruction should be bnez.
*
appendix :
*
GCC version 4.6.0. with binutils-2.21.1
System type: fedora 15 64bit, x86_64.
build a cross compile for 'mipsel'
config params:
export PREFIX=/home/wuxb/.mipsgcc0
export TARGET=mipsel-gnu-linux
../gcc-4.6.0/configure --prefix=$PREFIX --target=$TARGET
*
*
Makefile
*
.PHONY : all
SHAREFILES = ../global
CROSS = mipsel-gnu-linux-
CC = $(CROSS)gcc
LD = $(CROSS)ld
AS = $(CROSS)as
OBJCOPY = $(CROSS)objcopy
OBJDUMP = $(CROSS)objdump
INCLUDE = -I$(SHAREFILES)
CFLAGS = -v -save-temps -Wall -g -fno-builtin -fno-pic -mno-abicalls $(INCLUDE)
ASFLAGS = -gstabs -fno-pic -mno-abicalls -D__ASSEMBLY__ $(INCLUDE)
LDFLAGS = -T $(SHAREFILES)/mips.lds
COPYFLAGS = --gap-fill=0xff -O binary
BINELF = bin.elf
BINBIN = bin.bin
GLOBALSOURCES = $(SHAREFILES)/head.S
SOURCES = $(GLOBALSOURCES) mips_1001.c
ALLDEP = Makefile.dep
# .c - .o, .s - .o
OBJECTS = $(patsubst %.c, %.o, $(patsubst %.S, %.o, $(SOURCES)))
DEPENDS = $(patsubst %.o, %.d, $(OBJECTS)
all : $(ALLDEP) $(BINBIN)
$(BINBIN) : $(BINELF)
$(OBJCOPY) $(COPYFLAGS) $^ $@
$(BINELF) : $(OBJECTS)
$(LD) -o $@ $(LDFLAGS) $^
$(OBJDUMP) -lDS $@ $@.txt
%.o : %.c
$(CC) $(CFLAGS) -c $ -o $@
%.o : %.S
$(CC) $(ASFLAGS) -c $ -o $@
$(ALLDEP) : $(SOURCES)
$(CC) $(CFLAGS) -MM $^ $@
sinclude $(ALLDEP)
clean:
rm -vf $(OBJECTS) $(BINBIN) $(BINELF) $(ALLDEP)
*
end
*
*
file:test_1001.c
*
#include rawapi.h
long lcm(long num1,long num2)
{
int a, b, temp;
if(num1num2) /*want n1n2*/
{
temp=num1;
num1=num2;
num2=temp; /*swap*/
}
a=num1;//big
b=num2;//small
while(b!=0) /*gcd*/
{
temp=a%b;
a=b;
b=temp;
}
return num1*num2 / a;
}
long test (long a, long b)
{
return a+b;
}
int main()
{
int i, n = 0;
long a, b, g;
a = 123;
b = 321;
g = lcm(a, b);
uput(g);
return 0;
}
*
end
*
*
file:test_1001.i
*
# 1 mips_1001.c
# 1 /home/wuxb/workspace/gcc/test_1001//
# 1 built-in
# 1 命令行
# 1 mips_1001.c
# 1 ../global/rawapi.h 1
extern void uput(unsigned int value);
# 2 mips_1001.c 2
long lcm(long num1,long num2)
{
int a, b, temp;
if(num1num2)
{
temp=num1;
num1=num2;
num2=temp;
}
a=num1;
b=num2;
while(b!=0)
{
temp=a%b;
a=b;
b=temp;
}
return num1*num2 / a;
}
long test (long a, long b)
{
return a+b;
}
int main()
{
int i, n = 0;
long a, b, g;
a = 123;
b = 321;
g = lcm(a, b);
uput(g);
return 0;
}
*
*
*
mipsel-gnu-linux-objdump elf file.
*
bin.elf: file format elf32-tradlittlemips
Disassembly of section .text:
bfc0 _start:
../global/head.S:18
nop
.global uput
uput:
lui t0, 0xa000
sw a0, 0x700(t0)
jr ra
bfc0:3c10a000 luis0,0xa000
bfc4:2610fff0 addius0,s0,-16
bfc8:
[Bug c/49360] generate wrong logic code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49360
Wu Xingbo wuxb45 at gmail dot com changed:
What|Removed |Added
Target||mipsel-gnu-linux
Host||Fedora 15 x86_64
Build||Fedora 15 x86_64
--- Comment #1 from Wu Xingbo wuxb45 at gmail dot com 2011-06-10 06:29:00 UTC
---
long lcm(long num1,long num2)
{
int a, b, temp;
/***here*/
if(num1num2) /*want n1n2*/
{
temp=num1;
num1=num2;
num2=temp; /*swap*/
}
//
/***generates the logic:*/
if(!(num1num2))
{
temp=num1;
num1=num2;
num2=temp; /*swap*/
}
a=num1;//big
b=num2;//small
while(b!=0) /*gcd*/
{
temp=a%b;
a=b;
b=temp;
}
return num1*num2 / a;
}
[Bug c/49360] generate wrong logic code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49360 Wu Xingbo wuxb45 at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Wu Xingbo wuxb45 at gmail dot com 2011-06-10 06:55:56 UTC --- Sorry! my mistake.
[Bug tree-optimization/49318] [4.7 Regression] 177.mesa in SPEC CPU 2000 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49318 --- Comment #4 from irar at gcc dot gnu.org 2011-06-10 07:19:31 UTC --- Author: irar Date: Fri Jun 10 07:19:28 2011 New Revision: 174891 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174891 Log: PR tree-optimization/49318 * tree-vect-loop.c (vect_determine_vectorization_factor): Remove irrelevant pattern statements. Added: trunk/gcc/testsuite/gcc.dg/vect/pr49318.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-loop.c
[Bug debug/48459] [4.6/4.7 Regression] avr: Assertion failure with -gdwarf-2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48459
--- Comment #10 from Anitha Boyapati anitha.boyapati at atmel dot com
2011-06-10 07:37:19 UTC ---
(In reply to comment #9)
(In reply to comment #8)
I agree. But this does not fully solve the problem either.
INCOMING_RETURN_ADDR_RTX is being defined in dwarf2out.c to
gcc_unreachable()
:-(
Why is initial_return_save still being called? My patch should prevent
debug_unwind_info from returning UI_DWARF2.
Preprocessed output of default_debug_unwind_info()
enum unwind_info_type
default_debug_unwind_info (void)
{
# 1356 ../../gcc/targhooks.c
return UI_NONE;
}
I don't think initial_return_save() is called now. It passes the compilation
there but gets struck in other places. I think it is because
INCOMING_RETURN_ADDR_RTX is now seen as defined and hence CFI info is emitted.
But this runs into trouble because the above hook is gcc_unreachable().
[Bug bootstrap/49344] ICE in tree-flow-inline.h:745 while bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49344 --- Comment #8 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-06-10 08:32:37 UTC --- With the patch in comment #3 applied on top of revision 174846 I have been able to update powerpc-apple-darwin9 (long update, but not a full bootstrap).
[Bug fortran/49324] Deep copy missing for array constructors of DT w/ allocatable components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49324 --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org 2011-06-10 08:35:02 UTC --- (In reply to comment #5) The following should partially help It does - but it also leads to two test suite failures: gfortran.dg/alloc_comp_assign_5.f90 - failure around line 53. Output: if (ctr /= 1) call abort () fails as ctr is 5 instead of 1 gfortran.dg/alloc_comp_assign_6.f90 ERROR: should be ef, got: AA 2 Thus, the patch of comment 5 should be scratched. Next try: Use in the argument || expr_type == EXPR_ARRAY (in gfc_conv_expr_descriptor and gfc_trans_assignment_1), which seems to work. * * * The realloc on assignment still does not work: I get a segfault for the simple example: type t integer, allocatable :: A(:) end type t type(t) :: x type(t), allocatable :: z(:) print *, (1) z = [ x ] print *, (2) print *, allocated(z) end Excerpt (from the optimized dump): D.1622_32 = __builtin_malloc (48); SR.15_179 = MEM[(struct t[0:] *)D.1622_33].data; [...] bb 12: if (SR.15_179 != 0B) goto bb 6; The problem is: D.1622_33.data is never set. Depending on the malloc implementation, the returned memory may or may not be filled with NULL. If one forces that the returned memory is NULL, it works (by chance), if not, one gets - like I do - a segfault. Also valgrind shows a Conditional jump or move depends on uninitialised value warning. * * * For RESHAPE, gfortran seems to be a nontrivial bug: While the argument contains the allocatable components, one simply calls: _gfortran_reshape (D.1662, D.1685, D.1691, 0B, 0B); And for obvious reasons, doing reshape does not know anything about allocatable components and does only a shallow copy: memcpy(rptr, src, size); The solution is presumably to do a normal assignment - and only modify the shape in _gfortran_reshape.
[Bug rtl-optimization/42621] [4.4 Regression] Computed gotos on AMD 800% slower
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42621 Jaak Ristioja jaak at ristioja dot ee changed: What|Removed |Added CC||jaak at ristioja dot ee --- Comment #12 from Jaak Ristioja jaak at ristioja dot ee 2011-06-10 08:50:42 UTC --- (In reply to comment #9) Fixed for 4.5 sofar. Doesn't appear to be fixed in GCC 4.5.2 (under Gentoo Linux). PS: The additional jmp instruction (as in the bug description) even appears to be generated in case of -O0. PPS: As noted by other, this bug is likely a duplicate to bug 39284 and bug 43868.
[Bug rtl-optimization/42621] [4.4 Regression] Computed gotos on AMD 800% slower
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42621 --- Comment #13 from Jaak Ristioja jaak at ristioja dot ee 2011-06-10 08:52:47 UTC --- (In reply to comment #12) PPS: As noted by other, this bug is likely a duplicate to bug 39284 and bug 43868. As noted by others, this bug is likely a duplicate to bug 39284 and bug 43686. Sorry about the typos.
[Bug c/43686] GCC doesn't duplicate computed gotos for functions marked as hot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43686 --- Comment #3 from Jaak Ristioja jaak at ristioja dot ee 2011-06-10 09:19:49 UTC --- (In reply to comment #1) Duplicate of PR42621? And probably a duplicate of bug 39284 also. (In reply to comment #2) yes. It's definitely the same issue. The only additional note that __attribute__((hot)) doesn't fix the problem (as I would expect tracing down optimize_bb_for_size_p()), but makes an additional slowdown. In opposite, the __attribute__((cold)) solves the issue. It looks very strange. I suppose some condition has to be inverted :) Both __attribute__((cold)) and __attribute__((hot)) have this issue with GCC 4.5.2 on my Gentoo Linux box. Neither of them solves it.
[Bug rtl-optimization/49358] optimization regression in 4.6.1 from 4.5.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49358 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization, ra Status|UNCONFIRMED |NEW Last reconfirmed||2011.06.10 09:33:33 CC||law at gcc dot gnu.org, ||vmakarov at gcc dot gnu.org Component|c++ |rtl-optimization Known to work||4.4.5 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-10 09:33:33 UTC --- Confirmed.
[Bug rtl-optimization/49357] [4.7 Regression] register allocation worse
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49357 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug c++/49355] new T({}) crashes G++ when struct T { std::string foobar };
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49355
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2011.06.10 09:37:35
Ever Confirmed|0 |1
Known to fail||4.4.5, 4.5.3, 4.6.0, 4.7.0
--- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-10
09:37:35 UTC ---
Confirmed. 4.3 rejected the code, so does the EDG frontend of ICC 12.0:
t.C(7): error: expected an expression
T* x = new T({});
so not sure if it is valid code or not.
[Bug bootstrap/49354] [4.7 Regression] bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49354 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-10 09:38:04 UTC --- Fixed.
[Bug tree-optimization/49352] [4.7 Regression] -fcompare-debug failure with -O2 -ftree-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49352 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.06.10 09:44:18 CC||jakub at gcc dot gnu.org Known to work||4.6.1 Target Milestone|--- |4.7.0 Ever Confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-06-10 09:44:18 UTC --- Confirmed, caused by http://gcc.gnu.org/viewcvs?root=gccview=revrev=173856 Looking at it.
[Bug c++/49350] [4.7 Regression] Many C++ testsuite failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49350 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-10 09:46:10 UTC --- Patch has been reverted (without a ChangeLog entry).
[Bug rtl-optimization/49330] Integer arithmetic on addresses optimised with pointer arithmetic rules
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330 --- Comment #7 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-06-10 09:50:28 UTC --- The alias.c machinery is clearly based on the fundamental assumption of pointer arithmetics, i.e. that you aren't allowed to compute a difference unless both pointers point to the same enclosing object. The testcase is a nice attempt at smuggling the violation of this rule behind a uintptr_t based manipulation. Not clear what to do IMO. Richard is proposing to leverage the escape sites: px_1 = (uintptr_t) x; py_2 = (uintptr_t) y; but this will pessimize. Ideally we should leverage the one problematic line: p.2_6 = (int *) p_5; which creates the pointer out of the integer, but it has already disappeared in the very first RTL representation.
[Bug rtl-optimization/49330] Integer arithmetic on addresses optimised with pointer arithmetic rules
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330
--- Comment #8 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-10
09:59:06 UTC ---
(In reply to comment #7)
The alias.c machinery is clearly based on the fundamental assumption of
pointer
arithmetics, i.e. that you aren't allowed to compute a difference unless both
pointers point to the same enclosing object. The testcase is a nice attempt
at
smuggling the violation of this rule behind a uintptr_t based manipulation.
Not clear what to do IMO. Richard is proposing to leverage the escape sites:
px_1 = (uintptr_t) x;
py_2 = (uintptr_t) y;
but this will pessimize. Ideally we should leverage the one problematic line:
p.2_6 = (int *) p_5;
which creates the pointer out of the integer, but it has already disappeared
in
the very first RTL representation.
Creating that pointer is perfectly valid - you are allowed to cast a
pointer to an uintptr_t and back, which is what the code does (in some
obfuscated way of course).
p.2_6 = (int *) ((uintptr_t) y + ((uintptr_t) x - (uintptr_t) y)))
which is, as is trivially obvious, (int *) (uintptr_t) x.
Consider
int foo(uintptr_t a)
{
uintptr_t px = (uintptr_t) x;
uintptr_t py = a;
volatile uintptr_t d = px - py;
uintptr_t p = py + d;
x = 1;
*(int *) p = 2;
return x;
}
int main() { foo(y); }
which is equivalent.
[Bug c++/49355] new T({}) crashes G++ when struct T { std::string foobar };
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49355 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-06-10 10:00:00 UTC --- it's only valid in C++0x
[Bug c++/49351] Internal error: Segmentation fault (program cc1plus)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49351 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-10 10:00:58 UTC --- Needs quite some more memory for me ... (doesn't fit in my 3GB box).
[Bug c++/48660] ARM ICE in expand_expr_real_1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48660 --- Comment #3 from Mikael Pettersson mikpe at it dot uu.se 2011-06-10 10:04:52 UTC --- Created attachment 24484 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24484 reduced test case With the massively reduced test case and r154736 built as a cross to armv5tel-linux-gnueabi, I get: /tmp/objdir/gcc/g++ -B/tmp/objdir/gcc -O1 -S XMLServiceProvider.cc XMLServiceProvider.cc: In member function 'virtual thunk to XMLConfig::getBool() const': XMLServiceProvider.cc:24:19: internal compiler error: in expand_expr_real_1, at expr.c:8510
[Bug c/47599] -fno-short-wchar does not force long wchar
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47599 --- Comment #8 from Bastien ROUCARIES roucaries.bastien+bugs at gmail dot com 2011-06-10 10:14:06 UTC --- Any news of this bug ?
[Bug fortran/41209] Add full ATTRIBUTE support to gfortran (ALIGN, (WEAK)ALIAS, ...)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41209 Bastien ROUCARIES roucaries.bastien+bugs at gmail dot com changed: What|Removed |Added CC||roucaries.bastien+bugs at ||gmail dot com --- Comment #6 from Bastien ROUCARIES roucaries.bastien+bugs at gmail dot com 2011-06-10 10:16:51 UTC --- Please not that bug #35827 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35827) depend of this bug.
[Bug middle-end/35827] -fvisibility only works for C/C++/Objective-C/Objective-C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35827 Bastien ROUCARIES roucaries.bastien+bugs at gmail dot com changed: What|Removed |Added CC||roucaries.bastien+bugs at ||gmail dot com --- Comment #2 from Bastien ROUCARIES roucaries.bastien+bugs at gmail dot com 2011-06-10 10:20:15 UTC --- Dear andrew, You have miss that visibility is supported by intel fortran, and is therefore quite useful for fortran dso. See http://software.intel.com/sites/products/documentation/hpc/compilerpro/en-us/fortran/lin/compiler_f/optaps/common/optaps_cmp_visib.htm BTW could you mark that this bug is blocked by 41209 ? http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41209 Bastien
[Bug tree-optimization/49352] [4.7 Regression] -fcompare-debug failure with -O2 -ftree-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49352
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC||irar at gcc dot gnu.org
AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org
|gnu.org |
--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-06-10
10:28:28 UTC ---
The following fixes the -fcompare-debug failure:
--- gcc/tree-vect-loop.c.jj2011-05-31 08:03:10.0 +0200
+++ gcc/tree-vect-loop.c2011-06-10 12:04:28.0 +0200
@@ -1719,10 +1719,11 @@ vect_is_slp_reduction (loop_vec_info loo
nuses = 0;
FOR_EACH_IMM_USE_FAST (use_p, imm_iter, lhs)
{
+ if (is_gimple_debug (USE_STMT (use_p)))
+continue;
+
use_stmt = USE_STMT (use_p);
nuses++;
- if (is_gimple_debug (use_stmt))
-continue;
/* Check if we got back to the reduction phi. */
if (gimple_code (use_stmt) == GIMPLE_PHI
but the code still looks questionable to me. It is using use_stmt after the
loop, but what does use_stmt contain? The last use, which can be outside of
the loop, rather than the single loop use. So, if nuses 1, which use_stmt
you actually want?
[Bug c++/49351] Internal error: Segmentation fault (program cc1plus)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49351 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2011-06-10 10:39:58 UTC --- you're gonna need a bigger boat compiles ok on a 64-bit box, physical memory usage nears 4GB
[Bug rtl-optimization/49330] Integer arithmetic on addresses optimised with pointer arithmetic rules
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330 --- Comment #9 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-06-10 10:55:53 UTC --- Creating that pointer is perfectly valid - you are allowed to cast a pointer to an uintptr_t and back, which is what the code does (in some obfuscated way of course). No disagreement, problematic only in the sense that it breaks the assumption of the aliasing machinery, as you're creating a pointer out of nothing.
[Bug tree-optimization/49361] New: [4.7 Regression] Huge 470.lbm regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49361
Summary: [4.7 Regression] Huge 470.lbm regression
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org
CC: wschm...@gcc.gnu.org
+2011-06-06 Bill Schmidt wschm...@linux.vnet.ibm.com
+
+ PR tree-optimization/46728
+ * builtins.c (powi_table): Remove.
+ (powi_lookup_cost): Remove.
+ (powi_cost): Remove.
+ (expand_powi_1): Remove.
+ (expand_powi): Remove.
+ (expand_builtin_pow_root): Remove.
+ (expand_builtin_pow): Remove.
+ (expand_builtin_powi): Eliminate handling of constant exponent.
+ (expand_builtin): Use expand_builtin_mathfn_2 for BUILT_IN_POW.
caused a buge 470.lbm performance regression at -O3 -ffast-math.
This is because when PRE inserts an expression like x * x it folds it,
producing
pow (x, 2.0) again which is then never expanded to x * x again.
PRE does this folding in create_expression_by_pieces.
Arguably not the very best idea.
Eventually we should simply do
Index: gcc/fold-const.c
===
--- gcc/fold-const.c(revision 174891)
+++ gcc/fold-const.c(working copy)
@@ -10519,7 +10519,8 @@ fold_binary_loc (location_t loc,
}
/* Optimize x*x as pow(x,2.0), which is expanded as x*x. */
- if (optimize_function_for_speed_p (cfun)
+ if (!in_gimple_form
+ optimize_function_for_speed_p (cfun)
operand_equal_p (arg0, arg1, 0))
{
tree powfn = mathfn_built_in (type, BUILT_IN_POW);
[Bug tree-optimization/49361] [4.7 Regression] Huge 470.lbm regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49361 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug bootstrap/49344] ICE in tree-flow-inline.h:745 while bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49344 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #9 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-10 11:08:09 UTC --- Well, I'm going to test and install it.
[Bug rtl-optimization/49330] Integer arithmetic on addresses optimised with pointer arithmetic rules
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330
--- Comment #10 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-10
11:13:53 UTC ---
(In reply to comment #9)
Creating that pointer is perfectly valid - you are allowed to cast a
pointer to an uintptr_t and back, which is what the code does (in some
obfuscated way of course).
No disagreement, problematic only in the sense that it breaks the assumption
of the aliasing machinery, as you're creating a pointer out of nothing.
Indeed. I fixed similar bugs in tree points-to analysis, like
int x, y;
int foo (int *p)
{
int *q = x;
int *p = y;
int i;
for (i=0; isizeof(int *); ++i)
((char *)q)[i] = ((char *)p)[i];
*p = 1;
*q = 2;
return *p;
}
which I suspect might work on RTL only by accident (at -O3 with the
loop unrolled).
[Bug tree-optimization/49361] [4.7 Regression] Huge 470.lbm regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49361 --- Comment #1 from William J. Schmidt wschmidt at gcc dot gnu.org 2011-06-10 11:23:16 UTC --- OK, I'll clean this up.
[Bug tree-optimization/49343] [4.7 regression] ICE on field with variable offset
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49343 --- Comment #3 from Martin Jambor jamborm at gcc dot gnu.org 2011-06-10 11:23:32 UTC --- Apparently build_ref_for_model has to calculate offsets of COMPONENT_REFs with component_ref_field_offset just like get_ref_base_and_extent does in order to be able to make sense of placeholders ...whatever they are. I'll prepare a patch soon.
[Bug tree-optimization/49361] [4.7 Regression] Huge 470.lbm regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49361 --- Comment #2 from rguenther at suse dot de rguenther at suse dot de 2011-06-10 11:31:07 UTC --- On Fri, 10 Jun 2011, wschmidt at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49361 --- Comment #1 from William J. Schmidt wschmidt at gcc dot gnu.org 2011-06-10 11:23:16 UTC --- OK, I'll clean this up. I'm testing the fold-const.c patch currently and plan to install it as it makes sense to restrict this canonicalization to non-gimple.
[Bug c/49362] New: Arm Neon intrinsic types not correctly interpreted by compiler.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49362
Summary: Arm Neon intrinsic types not correctly interpreted by
compiler.
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mark.pupi...@dyson.com
Created attachment 24485
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24485
C-file with 2 funs that show the bug when compiled.
Arm neon intrinsics define the type uint32x4x2_t as
typedef struct uint32x4x2_t { uint32x4_t val[2]; };
This is interpreted by the compiler literally as a struct. This should not be
the case. The compiler should treat it as a pair of registers, just as it
treats uint32_t as a single register and not an array of 4 x uint32_t.
The attached c file contains two version of the same function - one that uses
quad word loads (vld1q), and one that uses double quad word loads (vld2q). The
function thats uses double quad word loads should take 2 instructions fewer but
it is actually 44 instructions long compared to 19 for the vld1q version. (Both
functions compute the same results).
I believe this bug arises because the compiler treats the following as array
access instead of a reference into the register file:
uint32x4x2_t A = vld2q_u32 ( a );
A.val[0]; // This statement should be treated as a reference to a register -
not an array access!
Assembly for vld2q version - hopefully I am not mistaken as I am new to ARM
assembly but it appears to do double quad word loads in Neon pipeline, then
transfers the registers back to the ARM processor, indexes them as arrays and
then reloads them into the Neon pipeline again!:
vld2q variant, 44 instructions:
0014 _ZN4Neon16hamming_distanceEPjS0_:
14:e92d0070 push{r4, r5, r6}
18:e24dd084 subsp, sp, #132; 0x84
1c:f460c38f vld2.32{d28-d31}, [r0]
20:e28d6020 addr6, sp, #32
24:ecc6cb08 vstmiar6, {d28-d31}
28:e1a0c001 movip, r1
2c:e8b6000f ldmr6!, {r0, r1, r2, r3}
30:e28d4060 addr4, sp, #96; 0x60
34:e1a05004 movr5, r4
38:f46c038f vld2.32{d16-d19}, [ip]
3c:e8a5000f stmiar5!, {r0, r1, r2, r3}
40:eccd0b08 vstmiasp, {d16-d19}
44:e896000f ldmr6, {r0, r1, r2, r3}
48:e1a0c00d movip, sp
4c:e28d4040 addr4, sp, #64; 0x40
50:e885000f stmr5, {r0, r1, r2, r3}
54:e1a05004 movr5, r4
58:e8bc000f ldmip!, {r0, r1, r2, r3}
5c:e8a5000f stmiar5!, {r0, r1, r2, r3}
60:e89c000f ldmip, {r0, r1, r2, r3}
64:e885000f stmr5, {r0, r1, r2, r3}
68:eddd4b10 vldrd20, [sp, #64]; 0x40
6c:eddd5b12 vldrd21, [sp, #72]; 0x48
70:edddab18 vldrd26, [sp, #96]; 0x60
74:edddbb1a vldrd27, [sp, #104]; 0x68
78:f34a61f4 veorq11, q13, q10
7c:eddd8b14 vldrd24, [sp, #80]; 0x50
80:eddd9b16 vldrd25, [sp, #88]; 0x58
84:eddd4b1c vldrd20, [sp, #112]; 0x70
88:eddd5b1e vldrd21, [sp, #120]; 0x78
8c:f30461f8 veorq3, q10, q12
90:f3f00546 vcnt.8q8, q3
94:f3b04566 vcnt.8q2, q11
98:f2042860 vadd.i8q1, q2, q8
9c:f3f022c2 vpaddl.u8q9, q1
a0:f3f422e2 vpaddl.u16q9, q9
a4:f22201b2 vorrd0, d18, d18
a8:f26321b3 vorrd18, d19, d19
ac:f2620b90 vpadd.i32d16, d18, d0
b0:f2600bb0 vpadd.i32d16, d16, d16
b4:ee100b90 vmov.32r0, d16[0]
b8:e28dd084 addsp, sp, #132; 0x84
bc:e8bd0070 pop{r4, r5, r6}
c0:e12fff1e bxlr
vld1q variant, only 19 instructions:
0014 _ZN4Neon16hamming_distanceEPjS0_:
14:e2802010 addr2, r0, #16
18:e2813010 addr3, r1, #16
1c:f4606a8f vld1.32{d22-d23}, [r0]
20:f4624a8f vld1.32{d20-d21}, [r2]
24:f463aa8f vld1.32{d26-d27}, [r3]
28:f461ca8f vld1.32{d28-d29}, [r1]
2c:f34681fc veorq12, q11, q14
30:f30461fa veorq3, q10, q13
34:f3f00546 vcnt.8q8, q3
38:f3b04568 vcnt.8q2, q12
3c:f2042860 vadd.i8q1, q2, q8
40:f3f022c2 vpaddl.u8q9, q1
44:f3f422e2 vpaddl.u16q9, q9
48:f22201b2 vorrd0, d18, d18
4c:f26321b3 vorrd18, d19, d19
50:f2620b90 vpadd.i32d16, d18, d0
54:f2600bb0 vpadd.i32d16, d16, d16
58:ee100b90 vmov.32r0, d16[0]
5c:e12fff1e bxlr
[Bug c/49362] Arm Neon intrinsic types not correctly interpreted by compiler.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49362 --- Comment #1 from mark.pupilli at dyson dot com 2011-06-10 11:38:40 UTC --- There is a typo - 'treats uint32_t as a single register and not an array of 4 x uint32_t' should read: 'treats uint32x4_t as a single register and not an array of 4 x uint32_t'
[Bug tree-optimization/49361] [4.7 Regression] Huge 470.lbm regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49361 --- Comment #3 from William J. Schmidt wschmidt at gcc dot gnu.org 2011-06-10 11:41:15 UTC --- OK, I won't clean this up. ;)
[Bug tree-optimization/49352] [4.7 Regression] -fcompare-debug failure with -O2 -ftree-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49352 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-06-10 11:44:03 UTC --- Created attachment 24486 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24486 gcc47-pr49352.patch Rough patch I've been playing with. There is no point testing gimple_code of use_stmt if it is GIMPLE_PHI, because phi is known to be a PHI. The patch attempts to only allow exactly one loop use stmt and use that stmt. I had to drop the use_stmt != first_stmt test, otherwise the transformation wouldn't ever happen, not sure if you want to allow in that case another loop use (if yes, which one of the two do you want as loop_use_stmt?). I also wonder if vect_is_slp_reduction should just return false; early if code is COND_EXPR, if for COND_EXPR def1 is not equal to phi I'm afraid it could be called.
[Bug middle-end/49363] New: [feature request] multiple target attribute (and runtime dispatching based on cpuid)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363
Summary: [feature request] multiple target attribute (and
runtime dispatching based on cpuid)
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vincenzo.innoce...@cern.ch
let me come back to the issue of supporting runtime dispatching based on cpuid
at compiler time:
would it be possible to implement a runtime dispatching based on a comma
separated list of targets. for instance something like
ret_type __attribute__ ((__target__ (sse2,avx,fma))) func(...) { ...}
?
I think many developers are by now using macros, templates and other magic to
implement their own dispatching schema. Support from the compiler would be more
than welcome!
[Bug target/49349] gfortran.dg/char_result_3.f90 fails with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49349
Alexander Monakov amonakov at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2011.06.10 12:13:45
AssignedTo|unassigned at gcc dot |amonakov at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #1 from Alexander Monakov amonakov at gcc dot gnu.org 2011-06-10
12:13:45 UTC ---
It's a rare bug in sel-sched: we fail to schedule some code in non-pipelining
mode. The root cause is that we put bookkeeping instructions above a fence
that is placed on the last insn (uncond. jump) of the bookkeeping block. We
could either make such blocks ineligible for bookkeeping or rewind such fences
from the jump back to the bookkeeping code (there's also a more involved
approach of re-introducing the idea of using local nops as placeholders for
fences). I'm testing the following patch that implements the second approach
(as it should result in a bit cleaner code in such situations).
diff --git a/gcc/sel-sched.c b/gcc/sel-sched.c
index 3f22a3c..f40ab90 100644
--- a/gcc/sel-sched.c
+++ b/gcc/sel-sched.c
@@ -4665,7 +4666,7 @@ create_block_for_bookkeeping (edge e1, edge e2)
/* Return insn after which we must insert bookkeeping code for path(s)
incoming
into E2-dest, except from E1-src. */
static insn_t
-find_place_for_bookkeeping (edge e1, edge e2)
+find_place_for_bookkeeping (edge e1, edge e2, fence_t *fence_to_rewind)
{
insn_t place_to_insert;
/* Find a basic block that can hold bookkeeping. If it can be found, do not
@@ -4707,9 +4708,13 @@ find_place_for_bookkeeping (edge e1, edge e2)
sel_print (Pre-existing bookkeeping block is %i\n, book_block-index);
}
+ *fence_to_rewind = NULL;
/* If basic block ends with a jump, insert bookkeeping code right before it.
*/
if (INSN_P (place_to_insert) control_flow_insn_p (place_to_insert))
-place_to_insert = PREV_INSN (place_to_insert);
+{
+ *fence_to_rewind = flist_lookup (fences, place_to_insert);
+ place_to_insert = PREV_INSN (place_to_insert);
+}
return place_to_insert;
}
@@ -4784,21 +4789,23 @@ generate_bookkeeping_insn (expr_t c_expr, edge e1, edge
e2)
insn_t join_point, place_to_insert, new_insn;
int new_seqno;
bool need_to_exchange_data_sets;
+ fence_t fence_to_rewind;
if (sched_verbose = 4)
sel_print (Generating bookkeeping insn (%d-%d)\n, e1-src-index,
e2-dest-index);
join_point = sel_bb_head (e2-dest);
- place_to_insert = find_place_for_bookkeeping (e1, e2);
- if (!place_to_insert)
-return NULL;
+ place_to_insert = find_place_for_bookkeeping (e1, e2, fence_to_rewind);
new_seqno = find_seqno_for_bookkeeping (place_to_insert, join_point);
need_to_exchange_data_sets
= sel_bb_empty_p (BLOCK_FOR_INSN (place_to_insert));
new_insn = emit_bookkeeping_insn (place_to_insert, c_expr, new_seqno);
+ if (fence_to_rewind)
+FENCE_INSN (fence_to_rewind) = new_insn;
+
/* When inserting bookkeeping insn in new block, av sets should be
following: old basic block (that now holds bookkeeping) data sets are
the same as was before generation of bookkeeping, and new basic block
[Bug tree-optimization/49361] [4.7 Regression] Huge 470.lbm regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49361 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-10 12:19:32 UTC --- Author: rguenth Date: Fri Jun 10 12:19:30 2011 New Revision: 174903 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174903 Log: 2011-06-10 Richard Guenther rguent...@suse.de PR tree-optimization/49361 * fold-const.c (fold_binary_loc): Only fold x * x to pow (x, 2.0) when not already in gimple form. Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c
[Bug bootstrap/49344] ICE in tree-flow-inline.h:745 while bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49344 --- Comment #10 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-10 12:18:59 UTC --- Author: rguenth Date: Fri Jun 10 12:18:55 2011 New Revision: 174902 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174902 Log: 2011-06-10 Richard Guenther rguent...@suse.de PR bootstrap/49344 * tree-ssa-math-opts.c (convert_mult_to_fma): Use FOR_EACH_PHI_OR_STMT_USE. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-math-opts.c
[Bug tree-optimization/49352] [4.7 Regression] -fcompare-debug failure with -O2 -ftree-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49352 Ira Rosen irar at il dot ibm.com changed: What|Removed |Added CC||irar at il dot ibm.com --- Comment #4 from Ira Rosen irar at il dot ibm.com 2011-06-10 12:22:17 UTC --- (In reply to comment #3) Created attachment 24486 [details] gcc47-pr49352.patch Rough patch I've been playing with. There is no point testing gimple_code of use_stmt if it is GIMPLE_PHI, because phi is known to be a PHI. Right :) The patch attempts to only allow exactly one loop use stmt and use that stmt. I had to drop the use_stmt != first_stmt test, otherwise the transformation wouldn't ever happen, not sure if you want to allow in that case another loop use (if yes, which one of the two do you want as loop_use_stmt?). I think it's ok. Sorry, I can't remember why I added this condition. It doesn't make sense to me now. I also wonder if vect_is_slp_reduction should just return false; early if code is COND_EXPR, if for COND_EXPR def1 is not equal to phi I'm afraid it could be called. Yes, probably a good idea. Thanks, Ira
[Bug bootstrap/49344] ICE in tree-flow-inline.h:745 while bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49344 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #11 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-10 12:19:41 UTC --- Fixed.
[Bug middle-end/49363] [feature request] multiple target attribute (and runtime dispatching based on cpuid)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.06.10 12:42:03 CC||dnovillo at gcc dot ||gnu.org, rguenth at gcc dot ||gnu.org, xinliangli at ||gmail dot com Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-10 12:42:03 UTC --- See the thread starting at http://gcc.gnu.org/ml/gcc-patches/2011-04/msg02285.html (continuing in May). Eventually we agreed that the user-side could be done by a kind of function overload resolution of properly tagged functions (proposed in http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00150.html). No idea if there is anybody working on it.
[Bug fortran/49324] Deep copy missing for array constructors of DT w/ allocatable components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49324 --- Comment #7 from Tobias Burnus burnus at gcc dot gnu.org 2011-06-10 12:45:13 UTC --- Submitted patch, which fixes - except of RESHAPE - the issue of comment 0 and comment 3: http://gcc.gnu.org/ml/fortran/2011-06/msg00095.html TODO: See comment 6: Namely, for realloc on assignment, the malloced memory is not NULLified - and RESHAPE is wrong (missing deep copy).
[Bug c++/49322] [4.7 Regression] Many libstdc++ testsuite failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49322 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|4.7.0 |--- --- Comment #5 from Jason Merrill jason at gcc dot gnu.org 2011-06-10 12:52:36 UTC --- Fixed.
[Bug tree-optimization/49352] [4.7 Regression] -fcompare-debug failure with -O2 -ftree-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49352
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Attachment #24486|0 |1
is obsolete||
--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2011-06-10
13:04:17 UTC ---
Created attachment 24487
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24487
gcc47-pr49352.patch
Updated patch, with the COND_EXPR check and testcase + ChangeLog.
Tested so far just with make check-gcc
RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} vect.exp'
Will do full bootstrap/regtest now.
Some further cleanups will be needed (e.g. the if (code == COND_EXPR || ...
code in vect_is_slp_reduction which can't be reached both because of
the new if (code != COND_EXPR) return false; and because
if (get_gimple_rhs_class (code) == GIMPLE_BINARY_RHS) around it as well), but I
guess that can be handled as followup.
[Bug tree-optimization/49352] [4.7 Regression] -fcompare-debug failure with -O2 -ftree-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49352 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2011-06-10 13:08:13 UTC --- Actually, should vect_is_slp_reduction be called at all if check_reduction is false? I think without check_reduction e.g. nothing ensures that code is commutative and associative...
[Bug tree-optimization/49352] [4.7 Regression] -fcompare-debug failure with -O2 -ftree-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49352 --- Comment #7 from Ira Rosen irar at il dot ibm.com 2011-06-10 13:30:52 UTC --- (In reply to comment #6) Actually, should vect_is_slp_reduction be called at all if check_reduction is false? I think without check_reduction e.g. nothing ensures that code is commutative and associative... Do you mean to avoid swapping of operands? We can pass a parameter to indicate whether to swap. But I am ok with not calling it at all. Thanks, Ira
[Bug c++/49351] Internal error: Segmentation fault (program cc1plus)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49351 --- Comment #4 from Mike Jarvis michael at jarvis dot net 2011-06-10 14:02:45 UTC --- That's a bit odd. The final function in the .ii file consists of two function calls. If I delete either one of these, the compile succeeds and only uses about 1100M (RSIZE in top). So I would have thought that a successful compilation with both functions there would take around 2GB, not 4. However, on my machine, the compiler bombs out before even getting to 1GB memory usage. (Around 785M, as I mentioned.) But either way, my machine has 8GB physical memory, so that should be plenty even if it wants to use 4GB.
[Bug c++/49351] Internal error: Segmentation fault (program cc1plus)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49351 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2011-06-10 14:06:19 UTC --- a single 32-bit process won't be able to use that much
[Bug debug/49364] New: [4.7 regressions] Empty .debug_abbrev sections confuse SGI nm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49364 Summary: [4.7 regressions] Empty .debug_abbrev sections confuse SGI nm Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org CC: ja...@gcc.gnu.org Host: mips-sgi-irix6.5 Target: mips-sgi-irix6.5 Build: mips-sgi-irix6.5 I just looked at a couple of recent gnat.dg/lto*.adb testsuite failures that started to occur between 20110322 and 20110401. They fail like this: collect2: error: /var/gcc/gcc-4.7.0-20110601/6.5-gcc/gcc/nm returned 1 exit status gnatlink: error when calling /var/gcc/gcc-4.7.0-20110601/6.5-gcc/gcc/xgcc gnatmake: *** link failed. I can see the nm failure if invoking nm manually: nm -Bng /var/gcc/gcc-4.7.0-20110601/6.5-gcc/mips-sgi-irix6.5/./libada/adainclude/ada.o /dev/null /var/gcc/gcc-4.7.0-20110601/6.5-gcc/mips-sgi-irix6.5/./libada/adainclude/ada.o ERROR: dwarf_elf_init: DW_DLE_DEBUG_ABBREV_NULL 34 .debug_abbrev section present but elf_getdata() failed or section is zero-length And indeed the .debug_abbrev section is 0-length, as seen with elfdump -h: SECTION HEADER TABLE [No] Type Addr Offset SizeName Link Info AdralgnEntsizeFlags [...] [5]SHT_MIPS_DWARF0 0x68 0 .debug_abbrev 0 0 0x10 0x This is a regression from 4.6 where this worked correctly. I'm attaching both the 4.6 and 4.7 assembler files. Rainer
[Bug debug/49364] [4.7 regressions] Empty .debug_abbrev sections confuse SGI nm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49364 --- Comment #1 from Rainer Orth ro at gcc dot gnu.org 2011-06-10 14:14:40 UTC --- Created attachment 24488 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24488 gcc 4.6.0 assembler output
[Bug debug/49364] [4.7 regressions] Empty .debug_abbrev sections confuse SGI nm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49364 --- Comment #2 from Rainer Orth ro at gcc dot gnu.org 2011-06-10 14:15:12 UTC --- Created attachment 24489 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24489 gcc 4.7.0 assembler output
[Bug debug/49364] [4.7 regressions] Empty .debug_abbrev sections confuse SGI nm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49364 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug target/48454] gfortran.dg/char_result_13.f90 fails with -O3 -funroll-loops -mvectorize-with-neon-quad
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48454 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.06.10 14:37:07 Ever Confirmed|0 |1 --- Comment #5 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2011-06-10 14:37:07 UTC --- Ah found it finally - this should fix it. Latent on trunk and 4.6 branch. Lengths are wrong in the backend for a vmovn pattern. cheers Ramana
[Bug tree-optimization/49365] New: 436.cactusADM performance regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49365 Summary: 436.cactusADM performance regression Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: rgue...@gcc.gnu.org Target: x86_64-*-* For 436.cactusADM we see a 20% regression in performance around 2010 Nov 10th here: http://gcc.opensuse.org/SPEC/CFP/sb-barbella.suse.de-head-64-2006/436_cactusADM_big.png Which is with -O3 -ffast-math -funroll-loops -fpeel-loops -march=barcelona
[Bug tree-optimization/49365] 436.cactusADM performance regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49365 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added CC||hjl at gcc dot gnu.org Known to fail||4.6.1, 4.7.0 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-10 15:11:50 UTC --- Bisecting this shows that rev. 166552 is the cause. 2010-11-10 H.J. Lu hongjiu...@intel.com PR tree-optimization/46414 * tree-inline.c (estimate_move_cost): Check preferred vector mode for vector type. The bug doesn't manifest itself on K8 or iCore7 nor does it show up with the default arch and generic tuning.
[Bug tree-optimization/49365] 436.cactusADM performance regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49365 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC|hjl at gcc dot gnu.org |hjl.tools at gmail dot com, ||sergos.gnu at gmail dot com --- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2011-06-10 15:21:24 UTC --- What is the problem?
[Bug lto/49302] [4.7 Regression] FAIL: gcc.dg/lto/20110201-1 c_lto_20110201-1_0.o-c_lto_20110201-1_0.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49302 --- Comment #11 from William J. Schmidt wschmidt at gcc dot gnu.org 2011-06-10 15:28:52 UTC --- Author: wschmidt Date: Fri Jun 10 15:28:46 2011 New Revision: 174912 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174912 Log: 2011-06-10 Bill Schmidt wschm...@linux.vnet.ibm.com PR lto/49302 * tree-ssa-math-opts.c (powi_as_mults): Minor cleanup. (build_and_insert_call): Likewise. (build_and_insert_ref): New. (gimple_expand_builtin_pow): Minor cleanup. (gimple_expand_builtin_cabs): New. (execute_cse_sincos): Add case for BUILT_IN_CABS. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-math-opts.c
[Bug lto/49302] [4.7 Regression] FAIL: gcc.dg/lto/20110201-1 c_lto_20110201-1_0.o-c_lto_20110201-1_0.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49302 --- Comment #12 from William J. Schmidt wschmidt at gcc dot gnu.org 2011-06-10 15:33:53 UTC --- Fixed.
[Bug tree-optimization/49365] 436.cactusADM performance regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49365 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-10 15:36:49 UTC --- I'm trying to get my hands on it. Most code differences betweeen good and bad rev. appear in loop array prefetching. Before aprefetch dumps differ only for datestamp.c, PUGH/SetupPGV.c and regex.c. I'm trying binaries with -fno-prefetch-loop-arrays now (well, on Monday that is). Prefetching uses tree_num_loop_insns which uses estimate_num_insns. Prefetching is enabled by default for barcelona (but also for K8 where I don't see this issue). So my bet is on prefetching costs getting confused and need adjustment.
[Bug debug/49366] New: pointer-to-member-function not given value in DW_TAG_template_value_param
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49366
Summary: pointer-to-member-function not given value in
DW_TAG_template_value_param
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: tro...@gcc.gnu.org
Consider this source:
struct S { void f() { } };
templatevoid (S::*F) () struct T { };
TS::f v;
The DWARF for F is:
250: Abbrev Number: 7 (DW_TAG_template_value_param)
51 DW_AT_name: F
53 DW_AT_type: 0x68
That is, it has a type but no value.
[Bug debug/41736] missing DW_TAG_template_*_ in some cases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41736 --- Comment #9 from Tom Tromey tromey at gcc dot gnu.org 2011-06-10 16:09:38 UTC --- See PR 49366 as well.
[Bug libfortran/48906] Wrong rounding results with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906 --- Comment #33 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2011-06-10 16:16:19 UTC --- The last test case I am working is fmt_g0_6.f08. The apparent failing case is: print (rc,g15.2), 0.995000_8 Which is resulting in 0.99 and we expect it to be 1.0. However, the raw internal representation of 0.995 is not exact and is: 99499555 This places the value less then the threshold given in the table in the Standard, giving the correct F format as: print (f11.2,4x), 0.995000_8 ! 0.99 Instead of print (f11.1,4x), 0.995000_8 ! 1.0 Our F formatting in the test case is using the f11.1 and the logic does not look at the third digit and dutifully rounds the value as it should. The new G formatting is using exact integer logic and dutifully does look at the third digit. If we do: print (rc,g15.2), 0.9950001_8 The internal value does cross the 0.995 threshold and we do get the 1.0 results. I think this issues is one of those splitting hairs things. We could artificially round the digits string early before we process it, but this would effectively be rounding twice to get there. I would prefer to revise the test case like so: call check_all(0.9951_RT, 15, 2, 0) and be done with this.
[Bug libfortran/48906] Wrong rounding results with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906 --- Comment #34 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2011-06-10 16:22:20 UTC --- Additional note: The standard states: Let N be the magnitude of the internal value The internal value is to be used to determine the conversion to F formatting. I think this adds to my point. I wonder if the standards committee knew the thresholds selected do not have an exact binary representation so that the internal values will always be above or below it.
[Bug debug/48459] [4.6/4.7 Regression] avr: Assertion failure with -gdwarf-2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48459 --- Comment #11 from Jason Merrill jason at gcc dot gnu.org 2011-06-10 16:24:12 UTC --- (In reply to comment #10) I don't think initial_return_save() is called now. It passes the compilation there but gets struck in other places. I think it is because INCOMING_RETURN_ADDR_RTX is now seen as defined and hence CFI info is emitted. But this runs into trouble because the above hook is gcc_unreachable(). It's only defined in dwarf2out.c, and there it's only used in the call to initial_return_save.
[Bug libfortran/48906] Wrong rounding results with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906 --- Comment #35 from Thomas Henlich thenlich at users dot sourceforge.net 2011-06-10 16:56:02 UTC --- (In reply to comment #33) The last test case I am working is fmt_g0_6.f08. The apparent failing case is: print (rc,g15.2), 0.995000_8 Which is resulting in 0.99 and we expect it to be 1.0. However, the raw internal representation of 0.995 is not exact and is: 99499555 This places the value less then the threshold given in the table in the Standard, giving the correct F format as: print (f11.2,4x), 0.995000_8 ! 0.99 Instead of print (f11.1,4x), 0.995000_8 ! 1.0 Our F formatting in the test case is using the f11.1 and the logic does not look at the third digit and dutifully rounds the value as it should. The new G formatting is using exact integer logic and dutifully does look at the third digit. If we do: print (rc,g15.2), 0.9950001_8 The internal value does cross the 0.995 threshold and we do get the 1.0 results. I think this issues is one of those splitting hairs things. We could artificially round the digits string early before we process it, but this would effectively be rounding twice to get there. I would prefer to revise the test case like so: call check_all(0.9951_RT, 15, 2, 0) and be done with this. The result is correct, but our expectation was wrong. 0.995000_8 which is internally 0.99499555... is smaller than 0.995 (exact value) so it must output 0.99, not 1.0. Please don't waste time with this test case (fmt_g0_6.f08), it is broken. I will fix this some time.
[Bug libfortran/48906] Wrong rounding results with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906 --- Comment #36 from Thomas Henlich thenlich at users dot sourceforge.net 2011-06-10 17:01:34 UTC --- (In reply to comment #34) Additional note: The standard states: Let N be the magnitude of the internal value The internal value is to be used to determine the conversion to F formatting. I think this adds to my point. I wonder if the standards committee knew the thresholds selected do not have an exact binary representation so that the internal values will always be above or below it. Not always (e.g. 99.5 is the exact internal value), but it many cases, yes. This and other problems with G editing will be fixed in the standard soon, if all goes well. I helped to prepare a request for this, which has now been submitted: http://j3-fortran.org/doc/year/2011/11-174.txt
[Bug tree-optimization/49367] New: missed optimization with __restrict field
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49367
Summary: missed optimization with __restrict field
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: trivial
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
GCC fails to optimize away the call to g() in this C testcase. It should
recognize that since we've established that a1 is different from a2, their
pointer fields must also be disjoint. This is necessary to be able to improve
optimization of C++ container classes, which currently have worse performance
than raw restricted pointers.
typedef struct A
{
int *__restrict p;
} A;
void g();
void f (A* a1, A* a2)
{
if (a1 == a2)
return;
*a1-p = 0;
*a2-p = 1;
if (*a1-p != 0)
g();
}
int main()
{
A a,b;
f (a,b);
}
[Bug c++/39415] static_cast used as downcast can silently lose const
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39415 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 Known to fail|| --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com 2011-06-10 17:28:51 UTC --- Fixed in 4.6.0.
[Bug libfortran/48906] Wrong rounding results with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906 --- Comment #37 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2011-06-10 17:29:54 UTC --- Updated patch posted for approval: http://gcc.gnu.org/ml/fortran/2011-06/msg00097.html Thomas, thanks for working the Standard issues and your testing.
[Bug c++/39684] GCC accepts template keyword where Comeau rejects it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39684 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2011-06-10 17:31:53 UTC --- Thus, let's resolve this as invalid.
[Bug c++/41769] Parameter names not restricted to identifiers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41769 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.06.10 17:34:54 AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com Ever Confirmed|0 |1 Known to fail|| --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-06-10 17:34:54 UTC --- Looking into it.
[Bug c/41138] Inconsistent (incorrect?) overflow in implicit constant conversion warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41138
--- Comment #3 from Martin Sebor msebor at gmail dot com 2011-06-10 17:44:47
UTC ---
Here's another test case, one that does involve slicing and where a consistent
but differently phrased warning would, IMO, be useful. Perhaps something like:
warning: slicing high order bits in implicit constant conversion
cat EOF | gcc -c -xc -
struct S {
unsigned a:1;
unsigned b:1;
};
void f (struct S *s, int i) {
s-a = i 0x10; /* line 7: no warning */
s-b = i 0x80; /* line 8: warning */
}
EOF
stdin: In function ‘f’:
stdin:8:5: warning: overflow in implicit constant conversion [-Woverflow]
[Bug c/49368] New: __builtin_constant_p is unable to determine if a union is constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49368
Summary: __builtin_constant_p is unable to determine if a union
is constant
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: david.me...@icron.com
In the following code GCC seems to be unable to determine that a const union is
actually const when passed as an argument to __builtin_constant_p(). If I use
a struct instead, then it seems to work, so there is only an issue when using a
union.
This is tested on GCC 4.5.1 GCC 4.1.2
$ cat dummy.c
#include stdio.h
union u {
int a;
int b;
};
#define DO_WORK(_arg_) \
do {\
if (__builtin_constant_p(_arg_))\
{ \
printf(Do optimized code\n); \
} \
else\
{ \
printf(Do slow code\n); \
} \
} while (0 == 1)
int main()
{
const union u x = { .a = 0 } ;
DO_WORK(x.b);
return 0;
}
$ gcc -Wall -Os dummy.c
$ ./a.out
Do slow code
[Bug c++/49347] G++ rejects Solaris spawn.h use of __restrict
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49347 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org Summary|G++ does not accept |G++ rejects Solaris spawn.h |T[__restrict] |use of __restrict --- Comment #4 from Jason Merrill jason at gcc dot gnu.org 2011-06-10 18:31:28 UTC --- C++ does not allow type-qualifiers between [], and it seems unnecessary to do so when the type is going to decay to a pointer anyway. Just have fixincludes correct the solaris header to char *const *_RESTRICT_KYWD argv, char *const *_RESTRICT_KYWD envp);
[Bug debug/49348] DW_TAG_template_* DIEs missing from template specializations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49348 --- Comment #3 from Dodji Seketeli dodji at gcc dot gnu.org 2011-06-10 18:47:46 UTC --- Candidate patch posted to http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00873.html
[Bug debug/49366] pointer-to-member-function not given value in DW_TAG_template_value_param
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49366 Dodji Seketeli dodji at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.06.10 18:48:56 CC||dodji at gcc dot gnu.org AssignedTo|unassigned at gcc dot |dodji at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug c++/49369] New: typeof() strips const from member when used in const method
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49369
Summary: typeof() strips const from member when used in const
method
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: shawn.boh...@gmail.com
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/home/software/gcc-4.6.0/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/home/software/gcc-4.6.0
--with-gmp=/home/jhand/inst --with-mpfr=/home/jhand/inst
Thread model: posix
gcc version 4.6.0 (GCC)
$ cat typeof.cpp
template typename Container
class A
{
public:
A(Container container) {}
};
class B {
protected:
int member;
};
class C: public B {
public:
int method() const;
};
int C::method() const {
Atypeof((B::member)) iter(B::member);
return 0;
}
int main()
{
return 0;
}
$ g++ -o typeof typeof.cpp
typeof3.cpp: In member function 'int C::method() const':
typeof3.cpp:19:42: error: no matching function for call to 'Aint::A(const
int)'
typeof3.cpp:19:42: note: candidates are:
typeof3.cpp:5:5: note: AContainer::A(Container) [with Container = int]
typeof3.cpp:5:5: note: no known conversion for argument 1 from 'const int' to
'int'
typeof3.cpp:2:7: note: Aint::A(const Aint)
typeof3.cpp:2:7: note: no known conversion for argument 1 from 'const int' to
'const Aint'
A couple of additional notes. I get the same error with gcc 4.4.3, 4.5.1, and
4.6.0. I get the same error if I use decltype instead of typeof. I can get it
to compile if I do not use the fully qualified name (B::member), however in my
real application I must use the fully qualified name.
[Bug target/49030] ICE in get_arm_condition_code, at config/arm/arm.c:17180
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49030 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se, ||sandra at gcc dot gnu.org --- Comment #6 from Mikael Pettersson mikpe at it dot uu.se 2011-06-10 19:02:07 UTC --- It's caused by r161764: Author: sandra Date: Sat Jul 3 01:00:37 2010 New Revision: 161764 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161764 Log: 2010-07-02 Daniel Jacobowitz d...@codesourcery.com Julian Brown jul...@codesourcery.com Sandra Loosemore san...@codesourcery.com gcc/ * config/arm/arm.c (arm_canonicalize_comparison): Canonicalize DImode comparisons. Adjust to take both operands. (arm_select_cc_mode): Handle DImode comparisons. (arm_gen_compare_reg): Generate a scratch register for DImode comparisons which require one. Use xor for Thumb equality checks. (arm_const_double_by_immediates): New. (arm_print_operand): Allow 'Q' and 'R' for constants. (get_arm_condition_code): Handle new CC_CZmode and CC_NCVmode. ...
[Bug c++/49369] typeof() strips const from member when used in const method
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49369 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-06-10 19:22:43 UTC --- can you use typeof(this-B::member) instead?
[Bug c++/41769] Parameter names not restricted to identifiers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41769 --- Comment #2 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2011-06-10 19:31:03 UTC --- Author: paolo Date: Fri Jun 10 19:31:00 2011 New Revision: 174927 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174927 Log: /cp 2011-06-10 Paolo Carlini paolo.carl...@oracle.com PR c++/41769 * decl.c (grokdeclarator): Reject operator names in parameters. /testsuite 2011-06-10 Paolo Carlini paolo.carl...@oracle.com PR c++/41769 * g++.dg/parse/error39.C: New. Added: trunk/gcc/testsuite/g++.dg/parse/error39.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog
[Bug c++/41769] Parameter names not restricted to identifiers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41769 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.7.0 Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2011-06-10 19:31:51 UTC --- Fixed.
[Bug target/43088] [avr] Suspect optimizer missed code in gcc 4.4.3..
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43088 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization CC||gjl at gcc dot gnu.org Known to fail|| --- Comment #5 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-06-10 19:59:47 UTC --- Funnc artifact. It occurs only if all low-bits are set, i.e. wich constants 0x3f, 0x1f, 0xf, ... So persumably a middle and pass makes some strange assumption. (In reply to comment #1) This bug is confirmed. andhi3/andsi3 causing this problem. conditional checks in andhi3 and andsi3 need to compare with zero instead of 0xff [etc]. i.e. in andhi3 we need to replace (mask 0x00ff) != 0xff by (mask 0x00ff) != 0. Similarly other checks in andhi3 and andsi3 need to be replaced. Can you explain? ANDding on a 8-bit part can only be omitted if the mask is 0xff. Otherwise, the AND has to be performed, even if the result is known to be always zero.
[Bug c++/49369] typeof() strips const from member when used in const method
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49369 --- Comment #2 from shawn.bohrer at gmail dot com 2011-06-10 20:20:11 UTC --- (In reply to comment #1) can you use typeof(this-B::member) instead? Yes this works for my application, thanks for the suggestion. Surely this is still a bug though correct?
[Bug target/26882] [AVR][C++] ICE when using template function with memory attributes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26882
Georg-Johann Lay gjl at gcc dot gnu.org changed:
What|Removed |Added
CC||gjl at gcc dot gnu.org
Known to fail||4.5.2
--- Comment #4 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-06-10
20:30:12 UTC ---
Reduded testcase that threds avr-gcc 4.5.2:
templatetypename T
T * rom (const T init)
{
static T t = init;
return t;
}
int * rom1 = rom(123);
extern bool __cxa_guard_acquire (void*);
[Bug other/49370] New: flags implemented in the specs file but undocumented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49370
Summary: flags implemented in the specs file but undocumented
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nlewy...@google.com
Please document the gcc -r flag, it's equivalent to -Wl,-r but isn't listed
in the documentation on
http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html#Link-Options (or the option
summary).
gcc.c includes %{r} in its #define LINK_COMMAND_SPEC (as well as a few other
undocumented flags). Alternatively, if you think users are wrong to use those
flags directly, please let me know.
[Bug c++/49107] [C++0x][4.7 Regression] incomplete type regression with std::pair
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49107
--- Comment #20 from Marc Glisse marc.glisse at normalesup dot org 2011-06-10
20:39:59 UTC ---
The patch fixes the example (thanks), but I still have trouble with the
following (and I also get a different type of failure elsewhere that I'll
investigate later):
#include utility
template class R_
struct Vector3
{
typedef typename R_::Ray_3 Ray_3;
Vector3() {}
explicit Vector3(const Ray_3 r);
};
template class R_ class LineC3
{
typedef typename R_::Vector_3 Vector_3;
std::pairint, Vector_3 x;
};
template class R_ class RayH3
{
typedef typename R_::Vector_3 Vector_3;
std::pairint, Vector_3 x;
};
template typename Kernel
struct Homogeneous_base
{
typedef LineC3Kernel Line_3;
typedef RayH3Kernel Ray_3;
};
template typename RT_
struct Simple_homogeneous
: public Homogeneous_base Simple_homogeneousRT_
{
typedef Vector3Simple_homogeneousRT_ Vector_3;
};
int main()
{
typedef Simple_homogeneousdouble R;
R::Line_3 l3;
}
which fails with:
In file included from
/tmp/gcc/inst/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/utility:72:0,
from Simple_homogeneous.cpp:1:
/tmp/gcc/inst/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/stl_pair.h:
In constructor 'std::pair_T1, _T2::pair(std::pair_T1, _T2) [with _T1 =
int, _T2 = Vector3Simple_homogeneousdouble , std::pair_T1, _T2 =
std::pairint, Vector3Simple_homogeneousdouble ]':
/tmp/gcc/inst/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/type_traits:740:46:
required from 'struct
std::__is_direct_constructible_implVector3Simple_homogeneousdouble ,
Vector3Simple_homogeneousdouble '
/tmp/gcc/inst/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/type_traits:89:12:
required from 'struct
std::__and_std::is_destructibleVector3Simple_homogeneousdouble ,
std::__is_direct_constructible_implVector3Simple_homogeneousdouble ,
Vector3Simple_homogeneousdouble '
/tmp/gcc/inst/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/type_traits:744:12:
required from 'struct
std::__is_direct_constructible_new_safeVector3Simple_homogeneousdouble ,
Vector3Simple_homogeneousdouble '
/tmp/gcc/inst/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/type_traits:816:12:
required from 'struct
std::__is_direct_constructible_newVector3Simple_homogeneousdouble ,
Vector3Simple_homogeneousdouble '
/tmp/gcc/inst/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/type_traits:824:12:
required from 'struct
std::__is_direct_constructibleVector3Simple_homogeneousdouble ,
Vector3Simple_homogeneousdouble '
/tmp/gcc/inst/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/type_traits:863:12:
[ skipping 3 instantiation contexts ]
/tmp/gcc/inst/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/type_traits:960:12:
required from 'struct
std::is_nothrow_constructibleVector3Simple_homogeneousdouble ,
Vector3Simple_homogeneousdouble '
/tmp/gcc/inst/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/type_traits:991:12:
required from 'struct
std::__is_nothrow_move_constructible_implVector3Simple_homogeneousdouble ,
false'
/tmp/gcc/inst/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/type_traits:997:12:
required from 'struct
std::is_nothrow_move_constructibleVector3Simple_homogeneousdouble '
/tmp/gcc/inst/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/type_traits:89:12:
required from 'struct std::__and_std::is_nothrow_move_constructibleint,
std::is_nothrow_move_constructibleVector3Simple_homogeneousdouble '
/tmp/gcc/inst/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/stl_pair.h:122:7:
required from 'std::pair_T1, _T2::pair(std::pair_T1, _T2) [with _T1 =
int, _T2 = Vector3Simple_homogeneousdouble , std::pair_T1, _T2 =
std::pairint, Vector3Simple_homogeneousdouble ]'
Simple_homogeneous.cpp:40:12: required from here
/tmp/gcc/inst/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/stl_pair.h:122:7:
error: incomplete type 'std::__and_std::is_nothrow_move_constructibleint,
std::is_nothrow_move_constructibleVector3Simple_homogeneousdouble '
used in nested name specifier
[Bug ada/48835] Porting GNAT to GNU/Linux/m68k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835 --- Comment #7 from Thorsten Glaser tg at mirbsd dot org 2011-06-10 20:54:58 UTC --- OK, so the fix is that the System.Address type must be changed in GNAT to be handled as pointer in the GCC middle-/back-end. Is any GCC/GNAT developer please working on this?
[Bug c++/49351] Internal error: Segmentation fault (program cc1plus)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49351 --- Comment #6 from Mike Jarvis michael at jarvis dot net 2011-06-10 21:04:59 UTC --- I figured out how to install a 64 bit version of g++ on my machine, and I also booted up the machine with 6 and 4 held down to get the 64 bit kernel. And this didn't help. I'm still getting the same Internal error: Segmentation fault. This time it got up to around 1300 MB memory usage before crashing (which of course could be at the same point in the compiling process, since I'm sure memory usage by g++ is different now). $ uname -a Darwin drl-dhcp42-064.sas.upenn.edu 10.7.0 Darwin Kernel Version 10.7.0: Sat Jan 29 15:16:10 PST 2011; root:xnu-1504.9.37~1/RELEASE_X86_64 x86_64 $ g++-4 -v -c TMV_TestSmallMatrixArith_6f.ii Using built-in specs. COLLECT_GCC=g++-4 COLLECT_LTO_WRAPPER=/sw64/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin10.7.0/4.5.2/lto-wrapper Target: x86_64-apple-darwin10.7.0 Configured with: ../gcc-4.5.2/configure --prefix=/sw64 --prefix=/sw64/lib/gcc4.5 --mandir=/sw64/share/man --infodir=/sw64/lib/gcc4.5/info --enable-languages=c,c++,fortran,objc,obj-c++,java --with-gmp=/sw64 --with-libiconv-prefix=/sw64 --with-ppl=/sw64 --with-cloog=/sw64 --with-mpc=/sw64 --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --program-suffix=-fsf-4.5 --enable-lto Thread model: posix gcc version 4.5.2 (GCC) COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.7' '-v' '-c' '-shared-libgcc' '-mtune=generic' /sw64/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin10.7.0/4.5.2/cc1plus -fpreprocessed TMV_TestSmallMatrixArith_6f.ii -fPIC -quiet -dumpbase TMV_TestSmallMatrixArith_6f.ii -mmacosx-version-min=10.6.7 -mtune=generic -auxbase TMV_TestSmallMatrixArith_6f -version -o /var/folders/UU/UU2-eU61GFOx3d6RzbOM4U+++TI/-Tmp-//cc8rFRK8.s GNU C++ (GCC) version 4.5.2 (x86_64-apple-darwin10.7.0) compiled by GNU C version 4.5.2, GMP version 4.3.2, MPFR version 2.4.2-p3, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C++ (GCC) version 4.5.2 (x86_64-apple-darwin10.7.0) compiled by GNU C version 4.5.2, GMP version 4.3.2, MPFR version 2.4.2-p3, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 43c0c50b4e3b4ab818a4452c96b3c3df g++-4: Internal error: Segmentation fault (program cc1plus) Please submit a full bug report. See http://gcc.gnu.org/bugs.html for instructions.
[Bug c++/49351] Internal error: Segmentation fault (program cc1plus)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49351 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org 2011-06-10 21:10:16 UTC --- does 'ulimit -a' show any limit on memory size? obviously it would be good if gcc didn't use so much memory, but I did verify that given a sufficiently beefy machine (64-bit, 24GB RAM) gcc 4.5.2 can compile the .ii, so I think your segfault is due to running out of memory rather than hitting a null pointer deference or other bug in gcc itself
[Bug c++/49369] typeof() strips const from member when used in const method
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49369 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2011-06-10 21:11:53 UTC --- (In reply to comment #2) (In reply to comment #1) can you use typeof(this-B::member) instead? Yes this works for my application, thanks for the suggestion. Surely this is still a bug though correct? I think so, but I'm not sure which is why I left it UNCONFIRMED Jason?
[Bug c++/49351] Internal error: Segmentation fault (program cc1plus)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49351 --- Comment #8 from Mike Jarvis michael at jarvis dot net 2011-06-10 21:26:59 UTC --- $ ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited file size (blocks, -f) unlimited max locked memory (kbytes, -l) unlimited max memory size (kbytes, -m) unlimited open files (-n) 256 pipe size(512 bytes, -p) 1 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 266 virtual memory (kbytes, -v) unlimited Should I try changing any of these? stack size? Also, I don't really understand why you think it's a memory issue, when it is not getting anywhere close to using 8GB, my machine's physical memory, before it crashes. Although, I do understand that it's hard to guess what the problem might be when you haven't been able to confirm the bug on one of your machines.
[Bug c++/49351] Internal error: Segmentation fault (program cc1plus)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49351 --- Comment #9 from Mike Jarvis michael at jarvis dot net 2011-06-10 21:47:37 UTC --- That worked. So I guess g++ is exceeding the stack limit and crashing, not the heap memory. $ ulimit -aH core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited file size (blocks, -f) unlimited max locked memory (kbytes, -l) unlimited max memory size (kbytes, -m) unlimited open files (-n) unlimited pipe size(512 bytes, -p) 1 stack size (kbytes, -s) 65532 cpu time (seconds, -t) unlimited max user processes (-u) 532 virtual memory (kbytes, -v) unlimited $ ulimit -s 65532 $ ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited file size (blocks, -f) unlimited max locked memory (kbytes, -l) unlimited max memory size (kbytes, -m) unlimited open files (-n) 256 pipe size(512 bytes, -p) 1 stack size (kbytes, -s) 65532 cpu time (seconds, -t) unlimited max user processes (-u) 266 virtual memory (kbytes, -v) unlimited $ g++-4 -c TMV_TestSmallMatrixArith_6f.ii $ I guess this is still a bug, so I won't close it. But I don't know how easy it would be for gcc to tell when it is going to exceed the stack limit and modify behavior accordingly. Or at least to give a useful error message that the stack size needs to be increased. But regardless, thank you for your help in diagnosing the problem. (And yes, it did end up using close to 4 GB.)
[Bug c++/49369] typeof() strips const from member when used in const method
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49369 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.06.11 05:05:12 Ever Confirmed|0 |1 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org 2011-06-11 05:05:12 UTC --- Yes, this is a bug. build_base_path is failing to preserve the cv-quals on this when converting to a pointer to B.
