[Bug libgomp/47854] omp_get_wtime documentation incorrect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47854 --- Comment #1 from Jakub Jelinek 2011-02-23 08:58:19 UTC --- Author: jakub Date: Wed Feb 23 08:58:16 2011 New Revision: 170434 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170434 Log: PR libgomp/47854 * libgomp.texi (omp_get_wtime): Don't say time in the past must be Unix Epoch. Modified: trunk/libgomp/ChangeLog trunk/libgomp/libgomp.texi
[Bug fortran/47850] [4.6 Regression] ICE in gfc_conv_array_initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47850 --- Comment #1 from Tobias Burnus 2011-02-23 09:04:03 UTC --- The problem is that for integer,parameter :: C_INDEX(8) = unpack( & vector = [(i,i=1,size(SENSOR_CHANNEL))], & mask = [(any(SENSOR_CHANNEL(i) == NLTE_CHANNEL), & i=lbound(SENSOR_CHANNEL,1),ubound(SENSOR_CHANNEL,1))], & the mask is not regarded as gfc_is_constant_expr -> gfc_constant_ac.
[Bug libgomp/47854] omp_get_wtime documentation incorrect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47854 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||FIXED --- Comment #2 from Jakub Jelinek 2011-02-23 09:10:59 UTC --- Fixed.
[Bug target/47814] [4.6 Regression] Bootstrap fails on mingw32 by undefined reference to 'lexer_line'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47814 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek 2011-02-23 09:25:10 UTC --- lexer_line as well as the other problematic symbols are defined in gengtype-lex.c: nm build/gengtype-lex.o | egrep 'yybegin|yyend|lexer_line' 0030 B lexer_line 2e38 T yybegin 2e9d T yyend which is generated from gengtype-lex.l. Are you sure you don't have buggy or not installed flex?
[Bug debug/47794] [4.6 Regression] New debug failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47794 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #4 from Jakub Jelinek 2011-02-23 09:25:52 UTC --- Not a gcc bug then...
[Bug target/47855] New: missed cbnz optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47855
Summary: missed cbnz optimization
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: car...@google.com
Target: arm-linux-androideabi
Created attachment 23440
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23440
testcase
Compile the attached source code with options -march=armv7-a -mthumb -Os, GCC
4.6 generates
pnm_gethdr:
@ args = 0, pretend = 0, frame = 8
@ frame_needed = 0, uses_anonymous_args = 0
push{r0, r1, r2, r4, r5, lr}
movr5, r0
movr4, r1
blfoo2
cmpr0, #0// A
bne.L13 // B
addsr1, r4, #4
movr0, r5
blfoo3
cmpr0, #0// C
bne.L13 // D
addr1, r4, #8
movr0, r5
blfoo1
cbnzr0, .L13 // E
ldrr0, [r4, #0]
blpnm_type
cmpr0, #2
beq.L3
movr0, r5
addr1, sp, #4
blpnm_getsintstr
cbzr0, .L4
b.L13
.L3:
movsr3, #1
strr3, [sp, #4]
.L4:
ldrr3, [sp, #4]
cmpr3, #0
bge.L5
negsr3, r3
strr3, [r4, #16]
movsr3, #1
b.L14
.L5:
strr3, [r4, #16]
movsr3, #0
.L14:
strbr3, [r4, #20]
ldrr0, [r4, #0]
blpnm_type
cmpr0, #0
beq.L8
blt.L7
cmpr0, #2
bgt.L7
movsr3, #1
movsr0, #0
strr3, [r4, #12]
b.L2
.L8:
movsr3, #3
strr3, [r4, #12]
b.L2
.L7:
blabort
.L13:
movr0, #-1
.L2:
pop{r1, r2, r3, r4, r5, pc}
The branch distance of cbz/cbnz is 126 bytes. The size of the whole function is
124 bytes. So instructions AB and CD can be replaced by
cbnzr0, .L13
same as instruction E.
[Bug target/47856] New: PowerPC: Wrong assembler output with -mcpu=8540 -meabi -msdata -fno-common -mfloat-gprs=double -mspe -mabi=spe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47856 Summary: PowerPC: Wrong assembler output with -mcpu=8540 -meabi -msdata -fno-common -mfloat-gprs=double -mspe -mabi=spe Product: gcc Version: 4.5.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: sebastian.hu...@embedded-brains.de Target: powerpc-rtems4.11-gcc Created attachment 23441 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23441 Sample code. powerpc-rtems4.11-gcc -mcpu=8540 -meabi -msdata -fno-common -mfloat-gprs=double -mspe -mabi=spe -c docomplexf.i /tmp/ccIXOSTp.s: Assembler messages: /tmp/ccIXOSTp.s:72: Warning: setting incorrect section attributes for .sdata2 We have: .section.sdata2,"aw",@progbits This should be: .section.sdata2,"a",@progbits
[Bug preprocessor/47857] New: Pragma once warning when compiling PCH
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47857 Summary: Pragma once warning when compiling PCH Product: gcc Version: 4.4.5 Status: UNCONFIRMED Severity: minor Priority: P3 Component: preprocessor AssignedTo: unassig...@gcc.gnu.org ReportedBy: olafvds...@gmail.com g++ a.h a.h: #pragma once // warning: #pragma once in main file
[Bug lto/46911] [4.6 Regression] ICE: SIGSEGV in add_name_and_src_coords_attributes (dwarf2out.c:17792) with -flto -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46911 Richard Guenther changed: What|Removed |Added Blocks||47819 --- Comment #5 from Richard Guenther 2011-02-23 12:06:34 UTC --- Same happens for 416.gamess.
[Bug target/47814] [4.6 Regression] Bootstrap fails on mingw32 by undefined reference to 'lexer_line'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47814 --- Comment #2 from Daniel Starke 2011-02-23 12:31:52 UTC --- (In reply to comment #1) > lexer_line as well as the other problematic symbols are defined in > gengtype-lex.c: > nm build/gengtype-lex.o | egrep 'yybegin|yyend|lexer_line' > 0030 B lexer_line > 2e38 T yybegin > 2e9d T yyend > which is generated from gengtype-lex.l. Are you sure you don't have buggy or > not installed flex? Sorry, it seems that my msys environment was broken for flex which made flex crash. This did not cause the make process to terminate, hence the failure occured not until linking. It seems flex wasn't used by gcc 4.5.2 for this configuration.
[Bug target/47814] [4.6 Regression] Bootstrap fails on mingw32 by undefined reference to 'lexer_line'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47814 Kai Tietz changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ktietz at gcc dot gnu.org Resolution||INVALID --- Comment #3 from Kai Tietz 2011-02-23 12:38:59 UTC --- Thanks for clarification. Closed as invalid.
[Bug driver/47676] error: field âOttybâ has incomplete type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47676 Jonathan Wakely changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #4 from Jonathan Wakely 2011-02-23 13:28:12 UTC --- closing due to lack of response
[Bug lto/46911] [4.6 Regression] ICE: SIGSEGV in add_name_and_src_coords_attributes (dwarf2out.c:17792) with -flto -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46911 --- Comment #6 from Richard Guenther 2011-02-23 13:34:25 UTC --- There are several issues. First as Jakub noted we have a NULL DECL_INITAL for the inlined __MAIN. If we fix that during LTO streaming (avoiding direct input/output of DECL_INITIAL of all FUNCTION_DECLs) we run into the issue that cgraph sets DECL_INITIAL of __MAIN to error_mark_node after inlining it (assuming that debug_hooks->outlining_inline_function did everything that was necessary already). We can try to avoid this by setting abstract_and_needed in the cgraph node. Together this solves this ICE. It doesn't solve PR47799 though. This is because how we split trees between the global and the function-local sections during streaming. We end up with multiple copies of the abstract BLOCK tree as well as bogus cross-function references for all abstract origins (apart from that to the function-decl itself).
[Bug debug/47858] New: [4.5/4.6 Regression] IPA-SRA decreases quality of debug info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47858
Summary: [4.5/4.6 Regression] IPA-SRA decreases quality of
debug info
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
CC: aol...@gcc.gnu.org
struct inode
{
char i_pad[16];
unsigned int i_flags;
};
struct dentry
{
unsigned int d_pad[16];
struct inode *d_inode;
};
extern int inode_permission (struct inode *, int);
extern int fsnotify_create (struct inode *, struct dentry *);
static inline int
may_create (struct inode *dir, struct dentry *child)
{
if (child->d_inode)
return -17;
if (((dir)->i_flags & 16))
return -2;
return inode_permission (dir, 2 | 1);
}
int
foo (struct inode *dir, struct dentry *child)
{
if (may_create (dir, child) < 0)
return -1;
return fsnotify_create (dir, child);
}
int
bar (struct inode *dir, struct dentry *child)
{
if (may_create (dir, child) < 0)
return -1;
return fsnotify_create (dir, child);
}
int
baz (struct inode *dir, struct dentry *child)
{
if (may_create (dir, child) < 0)
return -1;
return fsnotify_create (dir, child);
}
at -Os on x86_64-linux (distilled from Linux kernel) pessimizes debug info
because child parameter in may_create (which isn't emitted inline) doesn't have
location (well, it doesn't have even DW_TAG_formal_parameter in the out of line
DIE, just in the abstract inline DIE).
This could be solvable with my proposed DW_TAG_GNU_call_site stuff and the
(still in drafting DW_OP_GNU_parameter_ref stuff for completely optimized away
parameters - here it isn't completely optimized away, just replaced by
something based on it).
In this testcase it is of course also questionable why IPA-SRC actually
performs this "optimization" when it increases code size and doesn't improve
anything at all.
[Bug libstdc++/47628] non-compliant C++0x erase methods on STL containers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47628 --- Comment #13 from Jonathan Wakely 2011-02-23 13:41:24 UTC --- any reason the change didn't make it into Boost 1.46.0 ?
[Bug libstdc++/47859] New: Makefile: Input/output error. Stop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47859 Summary: Makefile: Input/output error. Stop Product: gcc Version: 4.5.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: yuch...@gmail.com Created attachment 23442 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23442 Makefile in .../libstdc++-v3/libsupc++/ This is the problem I encountered in the "make" stage of gcc installation. My system is x86_64-redhat-linux (Red Hat Linux 3.2.3-56). The configure command is "--prefix=/usr/local/gcc-4.5.2 --enable-threads=posix --disable-checking --disable-multilib --enable-languages=c,c++,fortran --with-gmp=/usr/local/gmp-5.0.1 --with-mpfr=/usr/local/mpfr-2.4.2 --with-mpc=/usr/local/mpc-0.8.1" make[4]: warning: Clock skew detected. Your build may be incomplete. make[4]: Leaving directory `/data/yuchape/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include' Making all in libsupc++ make[4]: Entering directory `/data/yuchape/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++' make[4]: *** Makefile: Input/output error. Stop. make[4]: Leaving directory `/data/yuchape/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/data/yuchape/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3' make[2]: *** [all] Error 2 make[2]: Leaving directory `/data/yuchape/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3' make[1]: *** [all-target-libstdc++-v3] Error 2 make[1]: Leaving directory `/data/yuchape/gcc-build' make: *** [all] Error 2 The attachment is the Makefile in .../libstdc++-v3/libsupc++/
[Bug libstdc++/47859] Makefile: Input/output error. Stop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47859 --- Comment #1 from Jonathan Wakely 2011-02-23 14:15:17 UTC --- This is not a bug in gcc, it suggests a disk error or some other problem with your machine. Check /var/log/messages at the time of the error
[Bug libstdc++/47859] Makefile: Input/output error. Stop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47859 --- Comment #2 from Jonathan Wakely 2011-02-23 14:21:20 UTC --- Also, is the error repeatable? Does it happen every time you run 'make'?
[Bug libfortran/47802] [4.6 Regression] libgfortran/intrinsics/ctime.c:75:3: error: too few arguments to function 'ctime_r'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47802 --- Comment #17 from dave at hiauly1 dot hia.nrc.ca 2011-02-23 14:28:38 UTC --- On Tue, 22 Feb 2011, jb at gcc dot gnu.org wrote: > Patch: http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01453.html Patch resolves ctime.c build. However, _REENTRANT is not defined, so there are various warnings regarding the declaration of reentrant functions such as localtime_r: libtool: compile: /xxx/gnu/gcc/objdir/./gcc/xgcc -B/xxx/gnu/gcc/objdir/./gcc/ -B/opt/gnu/gcc/gcc-4.6/hppa1.1-hp-hpux10.20/bin/ -B/opt/gnu/gcc/gcc-4.6/hppa1.1-hp-hpux10.20/lib/ -isystem /opt/gnu/gcc/gcc-4.6/hppa1.1-hp-hpux10.20/include -isystem /opt/gnu/gcc/gcc-4.6/hppa1.1-hp-hpux10.20/sys-include -DHAVE_CONFIG_H -I. -I../../../gcc/libgfortran -iquote../../../gcc/libgfortran/io -I../../../gcc/libgfortran/../gcc -I../../../gcc/libgfortran/../gcc/config -I../../../gcc/libgfortran/../libquadmath -I../.././gcc -D_GNU_SOURCE -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -fcx-fortran-rules -g -O2 -MT ctime.lo -MD -MP -MF .deps/ctime.Tpo -c ../../../gcc/libgfortran/intrinsics/ctime.c -fPIC -DPIC -o .libs/ctime.o ../../../gcc/libgfortran/intrinsics/ctime.c: In function 'fctime': ../../../gcc/libgfortran/intrinsics/ctime.c:43:10: warning: implicit declaration of function 'localtime_r' [-Wimplicit-function-declaration] ../../../gcc/libgfortran/intrinsics/ctime.c:43:20: warning: initialization makes pointer from integer without a cast [enabled by default] Dave
[Bug libstdc++/47859] Makefile: Input/output error. Stop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47859 --- Comment #3 from yu 2011-02-23 14:29:32 UTC --- (In reply to comment #2) > Also, is the error repeatable? Does it happen every time you run 'make'? It has been 'make' for about more than 1 hour when this error occurs.
[Bug libfortran/47802] [4.6 Regression] libgfortran/intrinsics/ctime.c:75:3: error: too few arguments to function 'ctime_r'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47802 --- Comment #18 from dave at hiauly1 dot hia.nrc.ca 2011-02-23 14:30:15 UTC --- On Tue, 22 Feb 2011, jb at gcc dot gnu.org wrote: > Patch which should hopefully fix the getpwuid_r issue on HP-UX 10.2: > http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01478.html Patch fixes the getpwuid_r build issue on HP-UX 10.2. Dave
[Bug libstdc++/47859] Makefile: Input/output error. Stop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47859 --- Comment #4 from yu 2011-02-23 14:31:05 UTC --- (In reply to comment #3) > (In reply to comment #2) > > Also, is the error repeatable? Does it happen every time you run 'make'? > > It has been 'make' for about more than 1 hour when this error occurs. This is the first time of 'make'. I don't know whether it is repeatable.
[Bug lto/46911] [4.6 Regression] ICE: SIGSEGV in add_name_and_src_coords_attributes (dwarf2out.c:17792) with -flto -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46911 --- Comment #7 from Richard Guenther 2011-02-23 14:35:27 UTC --- Created attachment 23443 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23443 prototype patch Patch also trying to fix PR47799 (but we'll still have multiple copies of the BLOCK trees). For better clarity the BLOCK_ABSTRACT_ORIGIN BLOCK trees should probably be streamed from input/output_function by walking the functions DECL_INITIAL. That would make it clear that the BLOCKs are duplicated in each caller function section (and that we mess up DECL_INITIAL of the abstract origin function-decls for all but the last function). We probably need to output the abstract function and its BLOCK tree to the global decl&type LTO section, possibly triggered by debug_hooks->outlining_inline_function.
[Bug tree-optimization/47860] New: is vectorization of "condition in nested loop" supported
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47860
Summary: is vectorization of "condition in nested loop"
supported
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vincenzo.innoce...@cern.ch
In
http://gcc.gnu.org/projects/tree-ssa/vectorization.html#nested
I read that "condition in nested loop" was committed in the main line in
2009-12-03
for 4.6.0 I still get it non vectorize.
what is the real situation of the feature described ion the page above?
for instance
nestedCond.cc:2: note: not vectorized: control flow in loop.
nestedCond.cc:7: note: not vectorized: data ref analysis failed next_a_22 =
*D.2335_21;
full details below
cat nestedCond.cc
void nestedCond( double * __restrict__ x_in, double * __restrict__ x_out,
double * __restrict__ a, double * __restrict__ c, unsigned int M, unsigned int
N) {
for (unsigned int j = 0; j < M; j++)
{
double x = x_in[j];
double curr_a = a[0];
for (unsigned int i = 0; i < N; i++)
{
double next_a = a[i+1];
curr_a = x > c[i] ? curr_a : next_a;
}
x_out[j] = curr_a;
}
}
g++ $CXXFLAGS $OPTFLAGS -v -c nestedCond.cc
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --enable-gold=yes --enable-lto --with-fpmath=avx
Thread model: posix
gcc version 4.6.0 20110205 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-O2' '-std=gnu++0x' '-mavx' '-mtune=corei7-avx'
'-ftree-vectorize' '-ftree-vectorizer-verbose=7' '-pthread' '-fPIC'
'-fassociative-math' '-freciprocal-math' '-fno-math-errno' '-fno-signed-zeros'
'-fno-trapping-math' '-ffinite-math-only' '-v' '-c' '-shared-libgcc'
'-march=x86-64'
/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/cc1plus -quiet -v
-D_GNU_SOURCE -D_REENTRANT nestedCond.cc -quiet -dumpbase nestedCond.cc -mavx
-mtune=corei7-avx -march=x86-64 -auxbase nestedCond -O2 -std=gnu++0x -version
-ftree-vectorize -ftree-vectorizer-verbose=7 -fPIC -fassociative-math
-freciprocal-math -fno-math-errno -fno-signed-zeros -fno-trapping-math
-ffinite-math-only -o /tmp/innocent/ccmT7uly.s
GNU C++ (GCC) version 4.6.0 20110205 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.6.0 20110205 (experimental), GMP version 4.3.2,
MPFR version 2.4.2, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory
"/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/x86_64-unknown-linux-gnu
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/backward
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/include
/usr/local/include
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/include-fixed
/usr/include
End of search list.
GNU C++ (GCC) version 4.6.0 20110205 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.6.0 20110205 (experimental), GMP version 4.3.2,
MPFR version 2.4.2, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 0d52c927b640361d99f7371685058a2b
nestedCond.cc:2: note: not vectorized: control flow in loop.
nestedCond.cc:7: note: not vectorized: data ref analysis failed next_a_22 =
*D.2335_21;
nestedCond.cc:1: note: vectorized 0 loops in function.
COLLECT_GCC_OPTIONS='-O2' '-std=gnu++0x' '-mavx' '-mtune=corei7-avx'
'-ftree-vectorize' '-ftree-vectorizer-verbose=7' '-pthread' '-fPIC'
'-fassociative-math' '-freciprocal-math' '-fno-math-errno' '-fno-signed-zeros'
'-fno-trapping-math' '-ffinite-math-only' '-v' '-c' '-shared-libgcc'
'-march=x86-64'
as --64 -msse2avx -o nestedCond.o /tmp/innocent/ccmT7uly.s
COMPILER_PATH=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/:/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/:/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/:/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/:/usr/local/lib/gcc/x86_64-unknown-linux-gnu/
LIBRARY_PATH=/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/:/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-O2' '-std=gnu++0x' '-mavx' '-mtune=corei7-avx'
'-ftree-vectorize' '-ftree-vectorizer-verbose=7' '-pthread' '-fPIC'
'-fassociative-math' '-freciprocal-math' '-fno-math-errno' '-fno-signed-zeros'
'-fno-trapping-math' '-ffinite-math-only' '-v' '-c' '-shared-libgc
[Bug libstdc++/47859] Makefile: Input/output error. Stop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47859 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011.02.23 14:50:10 Ever Confirmed|0 |1 --- Comment #5 from Jonathan Wakely 2011-02-23 14:50:10 UTC --- (In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #2) > > > Also, is the error repeatable? Does it happen every time you run 'make'? > > > > It has been 'make' for about more than 1 hour when this error occurs. Yes, but if you run it again it will start from where it stopped. It won't start again from the beginning. > This is the first time of 'make'. I don't know whether it is repeatable. Please try it again.
[Bug fortran/47850] [4.6 Regression] ICE in gfc_conv_array_initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47850 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #2 from Paul Thomas 2011-02-23 15:00:20 UTC --- (In reply to comment #1) > The problem is that for > >integer,parameter :: C_INDEX(8) = unpack( & > vector = [(i,i=1,size(SENSOR_CHANNEL))], & > mask = [(any(SENSOR_CHANNEL(i) == NLTE_CHANNEL), & > i=lbound(SENSOR_CHANNEL,1),ubound(SENSOR_CHANNEL,1))], & > > the mask is not regarded as gfc_is_constant_expr -> gfc_constant_ac. I just found the same thing! That's what comes of not refreshing the page :-) Paul
[Bug debug/47858] [4.5/4.6 Regression] IPA-SRA decreases quality of debug info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47858 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.02.23 15:00:08 Target Milestone|--- |4.5.3 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther 2011-02-23 15:00:08 UTC --- The idea is that the load can be CSEd at the call-site. Something we can't easily verify and thus should be definitely disabled at -Os. OTOH I think it's not really worth the trouble in general without further IPA analysis (and I have IPA-SRA disabled even for -O2 for openSUSE because of the debuginfo issues).
[Bug tree-optimization/47849] ICE: SIGSEGV in find_edge (cfganal.c:491) with -ftree-loop-if-convert -fno-tree-reassoc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47849 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.02.23 15:18:38 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther 2011-02-23 15:18:38 UTC --- I have a patch.
[Bug target/46779] wrong code generation for array access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46779
--- Comment #6 from Georg-Johann Lay 2011-02-23 15:51:11
UTC ---
I can confirm the bug for gcc version 4.4.6 20110222 (prerelease) (GCC)
In pass .168r.asmcons we have
(insn 92 57 93 4 pr46779-1.c:17 (set (subreg:QI (reg/v:HI 85 [ w.30 ]) 1)
(mem:QI (plus:HI (reg:HI 88 [ ivtmp.21 ])
(const_int 1 [0x1])) [0 S1 A8])) 4 {*movqi} (nil))
(insn 93 92 61 4 pr46779-1.c:17 (set (subreg:QI (reg/v:HI 85 [ w.30 ]) 0)
(const_int 0 [0x0])) 4 {*movqi} (nil))
insn 93 invalidates insn 92. It accesses reg 85 as QI but doing so it
invalidated the high part. This is due to subreg semantic. After IRA we have in
.c.172r.ira:
(insn 105 57 92 4 pr46779-1.c:17 (set (reg:HI 14 r14)
(reg/v:HI 28 r28 [orig:85 w.30 ] [85])) 10 {*movhi} (nil))
(insn 92 105 107 4 pr46779-1.c:17 (set (reg:QI 22 r22)
(mem:QI (plus:HI (reg:HI 26 r26 [orig:88 ivtmp.21 ] [88])
(const_int 1 [0x1])) [0 S1 A8])) 4 {*movqi} (nil))
(insn 107 92 106 4 pr46779-1.c:17 (set (reg:QI 15 r15 [+1 ])
(reg:QI 22 r22)) 4 {*movqi} (nil))
(insn 106 107 93 4 pr46779-1.c:17 (set (reg/v:HI 28 r28 [orig:85 w.30 ] [85])
(reg:HI 14 r14)) 10 {*movhi} (nil))
(insn 93 106 108 4 pr46779-1.c:17 (set (reg:QI 22 r22)
(const_int 0 [0x0])) 4 {*movqi} (nil))
(insn 108 93 61 4 pr46779-1.c:17 (set (reg/v:HI 28 r28 [orig:85 w.30 ] [85])
(reg:HI 22 r22)) 10 {*movhi} (nil))
Now we see that insn 108 (from IRA/reload) overwrites the contents of reg 28.
So in fact we see a bug similar to PR45291 which also originates in bad
multiple subreg usage as Lvalue.
The difference is that in 4.4 the bad subreg moves come from
(define_insn_and_split "*rotlhi3_8"
(define_insn_and_split "*rotlsi3_16"
(define_insn_and_split "*rotlsi3_8"
(define_insn_and_split "*rotlsi3_24"
whereas in 4.5 and 4.6 they come from avr.c:avr_rotate_bytes()
[Bug tree-optimization/47838] FAIL: gcc.dg/tree-ssa/foldconst-2.c scan-tree-dump-not optimized "fundamentals..0"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47838 --- Comment #4 from John David Anglin 2011-02-23 15:53:56 UTC --- Author: danglin Date: Wed Feb 23 15:53:48 2011 New Revision: 170439 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170439 Log: PR tree-optimization/47838 * gcc.dg/tree-ssa/foldconst-2.c: Scan tree-ch dump. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/foldconst-2.c
[Bug tree-optimization/47838] FAIL: gcc.dg/tree-ssa/foldconst-2.c scan-tree-dump-not optimized "fundamentals..0"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47838 John David Anglin changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from John David Anglin 2011-02-23 15:55:02 UTC --- Fixed.
[Bug tree-optimization/47860] is vectorization of "condition in nested loop" supported
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47860
--- Comment #1 from vincenzo Innocente
2011-02-23 16:32:36 UTC ---
it seems that there is a problem in the use of "unsigned int":
shall I open a different bug report?
even a simple comparison fails to vectorize
float amin(float * c, unsigned int N) {
float min=c[0];
for (unsigned int i=1; i!=N; ++i)
min = min > c[i] ? c[i] : min;
return min;
}
while it DOES vectorize when I change it in
float amin(float * c, int N) {
float min=c[0];
for (int i=1; i!=N; ++i)
min = min > c[i] ? c[i] : min;
return min;
}
still the nested loop does not vectorize yet
cat nestedCond.cc
void nestedCond( double * __restrict__ x_in, double * __restrict__ x_out,
double * __restrict__ a, double * __restrict__ c, int M, int N) {
for (int j = 0; j < M; j++)
{
double x = x_in[j];
double curr_a = a[0];
for (int i = 0; i < N; i++)
{
double next_a = a[i+1];
curr_a = x > c[i] ? curr_a : next_a;
}
x_out[j] = curr_a;
}
}
gcc -O3 -ffast-math -Wall -c nestedCond.cc -ftree-vectorizer-verbose=7
nestedCond.cc:2: note: not vectorized: control flow in loop.
nestedCond.cc:7: note: not vectorized: unsupported use in stmt.
nestedCond.cc:7: note: not vectorized: unsupported use in stmt.
nestedCond.cc:1: note: vectorized 0 loops in function.
[Bug c++/46868] [4.6 Regression] ICE: SIGSEGV splay_tree_splay (splay-tree.c:149) on invalid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46868 --- Comment #5 from Nathan Froyd 2011-02-23 16:44:25 UTC --- Author: froydnj Date: Wed Feb 23 16:44:18 2011 New Revision: 170440 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170440 Log: fix PR c++/46868 gcc/cp/ PR c++/46868 * parser.c (cp_parser_class_specifier): Require a closing brace to attempt error recovery. gcc/testsuite/ PR c++/46868 * g++.dg/pr46868.C: New test. * g++.dg/parse/parameter-declaration-1.C: Adjust. * g++.dg/parse/error14.C: Adjust. Added: trunk/gcc/testsuite/g++.dg/pr46868.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/parse/error14.C trunk/gcc/testsuite/g++.dg/parse/parameter-declaration-1.C
[Bug c++/47861] New: static variables inside member functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47861 Summary: static variables inside member functions Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: micha...@tiscali.it I know it has been probably discussed several times and probably eons ago. The language semanthics may induct to assume static variables defined in a member function are going to be modified only for a specifc class instance - obviously this is not happening. Not a c++ bug, a c++ trap.
[Bug tree-optimization/47849] ICE: SIGSEGV in find_edge (cfganal.c:491) with -ftree-loop-if-convert -fno-tree-reassoc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47849 --- Comment #3 from Richard Guenther 2011-02-23 16:50:00 UTC --- Author: rguenth Date: Wed Feb 23 16:49:52 2011 New Revision: 170441 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170441 Log: 2011-02-23 Richard Guenther PR tree-optimization/47849 * tree-if-conv.c (main_tree_if_conversion): Free postdom info. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-if-conv.c
[Bug tree-optimization/47849] ICE: SIGSEGV in find_edge (cfganal.c:491) with -ftree-loop-if-convert -fno-tree-reassoc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47849 Richard Guenther changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Richard Guenther 2011-02-23 16:50:33 UTC --- Fixed.
[Bug fortran/47846] Deferred-string length: Length is wrong (gfortran.dg/allocate_deferred_char_scalar_1.f03)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47846 Uros Bizjak changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.02.23 16:56:47 Ever Confirmed|0 |1 --- Comment #2 from Uros Bizjak 2011-02-23 16:56:47 UTC --- The patch from comment 0 was applied at r170438, so the test now fails at runtime. Confirmed. [1] http://gcc.gnu.org/ml/gcc-cvs/2011-02/msg00984.html
[Bug c++/47861] static variables inside member functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47861 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011.02.23 16:59:33 Ever Confirmed|0 |1 --- Comment #1 from Paolo Carlini 2011-02-23 16:59:33 UTC --- In any case, which action would you like to see (I'm not arguing the technical point): a new warning? For which specific testcase? Otherwise I'm afraid we have to close the PR, this is not the proper place for discussing present and/or future C++ language features.
[Bug rtl-optimization/47862] New: Incorrect code for spilling a vector register
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47862 Summary: Incorrect code for spilling a vector register Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: pthau...@gcc.gnu.org CC: berg...@gcc.gnu.org, meiss...@gcc.gnu.org Host: powerpc64-linux Target: powerpc64-linux Build: powerpc64-linux Created attachment 23444 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23444 testcase Tracked down an issue in cpu2006 benchmark 456.hmmer where incorrect code is generated when spilling a vector register. The normal floating point stfd/lfd insns are being generated, which only spills half the vector (allowing the other half to get clobbered across a function call). Attatched testcase was compiled with: gcc -S -m64 -O3 -mcpu=power7 -mveclibabi=mass -ffast-math spill.c Spill is occuring in the vectorized loop with expd2() calls. A snippet of that loop showing the use vr11 as vector and incorrect spill follows. There are a few other regs spilled in similar fashion in the loop. xvmuldp 11,58,12 xvmuldp 34,57,12 xvadddp 10,63,60 stfd 11,144(1) xvadddp 53,53,10 bl expd2 nop lfd 11,144(1) xxlor 62,34,34 xxlor 34,11,11 xvmuldp 57,57,62 bl expd2
[Bug regression/47836] Some Cross Compiler can't build target-libiberty or target-zlib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47836
--- Comment #4 from th.r.klein at web dot de 2011-02-23 17:56:54 UTC ---
The original failing process was:
../../env/src/configure --prefix=${HOME}/local --with-mpc=${HOME}/local
--with-mpfr=${HOME}/local --with-gmp=${HOME}/local --with-ppl=${HOME}/local
--with-cloog=${HOME}/local --with-libelf=${HOME}/local --target=arm-elf-eabi
--enable-target-optspace --disable-nls --disable-werror --enable-target-static
--disable-target-shared --enable-languages=c,c++ --with-float=soft
--without-headers --enable-multilib --enable-tls --enable-lto
--with-libexpat-prefix=/usr/local --with-expat=/usr/local
--with-python=/usr/local --enable-gold --enable-ld
gmake
..
gmake[2]: Leaving directory
`/usr/home/thomas/work/build/env_eabi/arm-elf-eabi/libgcc'
Checking multilib configuration for libiberty...
mkdir arm-elf-eabi/libiberty
Configuring in arm-elf-eabi/libiberty
configure: creating cache ./config.cache
checking whether to enable maintainer-specific portions of Makefiles... no
checking for makeinfo... makeinfo --split-size=500
checking for perl... perl
checking build system type... x86_64-unknown-freebsd8.1
checking host system type... arm-elf-eabi
checking for arm-elf-eabi-ar...
/usr/home/thomas/work/build/env_eabi/./binutils/ar
checking for arm-elf-eabi-ranlib...
/usr/home/thomas/work/build/env_eabi/./binutils/ranlib
checking for arm-elf-eabi-gcc...
/usr/home/thomas/work/build/env_eabi/./gcc/xgcc
-B/usr/home/thomas/work/build/env_eabi/./gcc/
-B/usr/home/thomas/local/arm-elf-eabi/bin/
-B/usr/home/thomas/local/arm-elf-eabi/lib/ -isystem
/usr/home/thomas/local/arm-elf-eabi/include -isystem
/usr/home/thomas/local/arm-elf-eabi/sys-include
-L/usr/home/thomas/work/build/env_eabi/./ld
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether /usr/home/thomas/work/build/env_eabi/./gcc/xgcc
-B/usr/home/thomas/work/build/env_eabi/./gcc/
-B/usr/home/thomas/local/arm-elf-eabi/bin/
-B/usr/home/thomas/local/arm-elf-eabi/lib/ -isystem
/usr/home/thomas/local/arm-elf-eabi/include -isystem
/usr/home/thomas/local/arm-elf-eabi/sys-include
-L/usr/home/thomas/work/build/env_eabi/./ldaccepts -g... yes
checking for /usr/home/thomas/work/build/env_eabi/./gcc/xgcc
-B/usr/home/thomas/work/build/env_eabi/./gcc/
-B/usr/home/thomas/local/arm-elf-eabi/bin/
-B/usr/home/thomas/local/arm-elf-eabi/lib/ -isystem
/usr/home/thomas/local/arm-elf-eabi/include -isystem
/usr/home/thomas/local/arm-elf-eabi/sys-include
-L/usr/home/thomas/work/build/env_eabi/./ldoption to accept ISO C89...
unsupported
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... unknown
checking for _LARGE_FILES value needed for large files... unknown
checking how to run the C preprocessor...
/usr/home/thomas/work/build/env_eabi/./gcc/xgcc
-B/usr/home/thomas/work/build/env_eabi/./gcc/
-B/usr/home/thomas/local/arm-elf-eabi/bin/
-B/usr/home/thomas/local/arm-elf-eabi/lib/ -isystem
/usr/home/thomas/local/arm-elf-eabi/include -isystem
/usr/home/thomas/local/arm-elf-eabi/sys-include
-L/usr/home/thomas/work/build/env_eabi/./ld-E
checking whether /usr/home/thomas/work/build/env_eabi/./gcc/xgcc
-B/usr/home/thomas/work/build/env_eabi/./gcc/
-B/usr/home/thomas/local/arm-elf-eabi/bin/
-B/usr/home/thomas/local/arm-elf-eabi/lib/ -isystem
/usr/home/thomas/local/arm-elf-eabi/include -isystem
/usr/home/thomas/local/arm-elf-eabi/sys-include
-L/usr/home/thomas/work/build/env_eabi/./ldsupports -W... yes
checking whether /usr/home/thomas/work/build/env_eabi/./gcc/xgcc
-B/usr/home/thomas/work/build/env_eabi/./gcc/
-B/usr/home/thomas/local/arm-elf-eabi/bin/
-B/usr/home/thomas/local/arm-elf-eabi/lib/ -isystem
/usr/home/thomas/local/arm-elf-eabi/include -isystem
/usr/home/thomas/local/arm-elf-eabi/sys-include
-L/usr/home/thomas/work/build/env_eabi/./ldsupports -Wall... yes
checking whether /usr/home/thomas/work/build/env_eabi/./gcc/xgcc
-B/usr/home/thomas/work/build/env_eabi/./gcc/
-B/usr/home/thomas/local/arm-elf-eabi/bin/
-B/usr/home/thomas/local/arm-elf-eabi/lib/ -isystem
/usr/home/thomas/local/arm-elf-eabi/include -isystem
/usr/home/thomas/local/arm-elf-eabi/sys-include
-L/usr/home/thomas/work/build/env_eabi/./ldsupports -Wwrite-strings... yes
checking whether /usr/home/thomas/work/build/env_eabi/./gcc/xgcc
-B/usr/home/thomas/work/build/env_eabi/./gcc/
-B/usr/home/thomas/local/arm-elf-eabi/bin/
-B/usr/home/thomas/local/arm-elf-eabi/lib/ -isystem
/usr/home/thomas/local/arm-elf-eabi/include -isystem
/usr/home/thomas/local/arm-elf-eabi/sys-include
-L/usr/home/thomas/work/build/env_eabi/./ldsupports -Wc++-compat... yes
checking whether /usr/home/thomas/work/build/env_eabi/./gcc/xgcc
-B/usr/home/thomas/work/build/env_eabi/./gcc/
-B/usr/home/thomas/local/arm-elf-eabi/bin/
-B/usr/home/thomas/local/arm-elf-eabi/lib/ -isystem
/usr/home/thomas/local/arm-elf-eabi/include -isystem
/usr/home/thomas/l
[Bug target/43810] [4.5 Regression] linking results in undefined references to _savegpr_* _restgpr_*_x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43810 --- Comment #17 from Nathan Froyd 2011-02-23 18:06:38 UTC --- Author: froydnj Date: Wed Feb 23 18:06:29 2011 New Revision: 170443 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170443 Log: PR target/43810 Backport from mainline: 2010-07-23 Nathan Froyd * config.host (powerpc*-eabispe*): Set tmake_file. (powerpc*-eabi*): Likewise. * config/rs6000/t-ppccomm (EXTRA_PARTS): Add crtbegin, crtend, crtbeginS, crtendS, crtbeginT. Modified: branches/gcc-4_5-branch/libgcc/ChangeLog branches/gcc-4_5-branch/libgcc/config.host branches/gcc-4_5-branch/libgcc/config/rs6000/t-ppccomm
[Bug target/43810] [4.5 Regression] linking results in undefined references to _savegpr_* _restgpr_*_x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43810 Nathan Froyd changed: What|Removed |Added Status|WAITING |RESOLVED CC||froydnj at gcc dot gnu.org Resolution||FIXED --- Comment #18 from Nathan Froyd 2011-02-23 18:10:02 UTC --- Fixed on the 4.5 branch. If there are still problems with --enable-target-optspace, please open a separate bug for those.
[Bug c++/46868] [4.6 Regression] ICE: SIGSEGV splay_tree_splay (splay-tree.c:149) on invalid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46868 Nathan Froyd changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from Nathan Froyd 2011-02-23 18:10:43 UTC --- Fixed.
[Bug libfortran/47802] [4.6 Regression] libgfortran/intrinsics/ctime.c:75:3: error: too few arguments to function 'ctime_r'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47802 --- Comment #19 from Tobias Burnus 2011-02-23 18:24:20 UTC --- (In reply to comment #17) > Patch resolves ctime.c build. However, _REENTRANT is not defined, > so there are various warnings regarding the declaration of reentrant > functions such as localtime_r: As there localtime_r is also used in intrinsics/date_and_time.c, I would assume that one sees the same message there. I am also not quite sure that _REENTRANT is the correct solution. At least for Solaris, one should use _POSIX_C_SOURCE and not _REENTRANT to get the POSIX version, cf. http://download.oracle.com/docs/cd/E19455-01/806-5257/compile-4/ For HP-UX, I could not find anything (cf. also http://docs.hp.com/en/B2355-90683/ctime.3C.html). However, IBM has a statement regarding HP-UX, which is similar to Solaris's above: http://publib.boulder.ibm.com/infocenter/db2luw/v8/topic/com.ibm.db2.udb.doc/ad/t0007651.htm
[Bug c++/40831] g++ generated symbols for cloned function that be demangled.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40831 --- Comment #9 from Cary Coutant 2011-02-23 18:30:19 UTC --- > Does not work for `_Z3fooi.1988' or > `_Z3fooi.part.9.165493.constprop.775.31805'. Where does the _Z3fooi.1988 style come from? I guess your second example is from a cloned function (due to partial inlining) that got cloned again (due to constant propagation), but why are there two numbers on each?
[Bug testsuite/47863] New: [4.6 Regression] FAIL: gfortran.dg/allocate_deferred_char_scalar_1.f03
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47863 Summary: [4.6 Regression] FAIL: gfortran.dg/allocate_deferred_char_scalar_1.f03 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com CC: ubiz...@gmail.com On Linux/ia32, revision 170442 gave FAIL: gfortran.dg/allocate_deferred_char_scalar_1.f03 -O0 execution test FAIL: gfortran.dg/allocate_deferred_char_scalar_1.f03 -O1 execution test FAIL: gfortran.dg/allocate_deferred_char_scalar_1.f03 -O2 execution test FAIL: gfortran.dg/allocate_deferred_char_scalar_1.f03 -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/allocate_deferred_char_scalar_1.f03 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/allocate_deferred_char_scalar_1.f03 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/allocate_deferred_char_scalar_1.f03 -O3 -g execution test FAIL: gfortran.dg/allocate_deferred_char_scalar_1.f03 -Os execution test Revision 170436 is OK.
[Bug testsuite/47863] [4.6 Regression] FAIL: gfortran.dg/allocate_deferred_char_scalar_1.f03
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47863 Dominique d'Humieres changed: What|Removed |Added CC||bur...@net-b.de, pault at ||gcc dot gnu.org --- Comment #1 from Dominique d'Humieres 2011-02-23 18:46:13 UTC --- See pr47846. A temporary "fix" could be to silence the failures with the following patch: --- ../_clean/gcc/testsuite/gfortran.dg/allocate_deferred_char_scalar_1.f03 2011-02-23 16:42:20.0 +0100 +++ gcc/testsuite/gfortran.dg/allocate_deferred_char_scalar_1.f032011-02-22 14:08:06.0 +0100 @@ -14,8 +14,8 @@ program test call mold_check4() call source_check() call source_check4() - call ftn_test() - call ftn_test4() +! call ftn_test() +! call ftn_test4() call source3() contains subroutine source_check() until pr47846 is fixed.
[Bug fortran/47846] Deferred-string length: Length is wrong (gfortran.dg/allocate_deferred_char_scalar_1.f03)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47846 --- Comment #3 from Dominique d'Humieres 2011-02-23 18:51:53 UTC --- See pr47863.
[Bug c++/40831] g++ generated symbols for cloned function that be demangled.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40831
--- Comment #10 from Jan Hubicka 2011-02-23 19:03:36
UTC ---
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40831
>
> --- Comment #9 from Cary Coutant 2011-02-23
> 18:30:19 UTC ---
> > Does not work for `_Z3fooi.1988' or
> > `_Z3fooi.part.9.165493.constprop.775.31805'.
>
> Where does the _Z3fooi.1988 style come from?
We add the .1234 suffixes in LTO for local symbols (to avoid clashes in between
two static
variables of the same name).
As WHOPR progress, we might end up adding two numbered suffixes, because we
mangle at wpa time and then ship the mangled symbols to ltrans when we mangle
again. Disabling the second mangling is trivial, but no one did it yet. The
first mangling happens even when tere are no conflicts that is stupid, but in
case of conflicts it needs to happen.
>
> I guess your second example is from a cloned function (due to partial
> inlining)
> that got cloned again (due to constant propagation), but why are there two
> numbers on each?
_Z3fooi.1988 is created from _Z3fooi by LTO mangling.
We also do precisely same mangling from function static variables, i.e.
test()
{
static int a;
}
will get out a as a.1234
_Z3fooi becomes _Z3fooi.part.9 by partial inlining
.165493 is added at WPA time because function is static (all partial functions
are)
.constprop.775 is added because one of argument was proved to be constant by
cprop pass
.31805 comes from (completely redundant) name mangling at ltrans time.
It is possible to change way we mangle the LTO vars, if neccesary for some good
reason.
Those numbered suffixes that do not come from function versioning (i.e. don't
have .part or .constprop) are redundant, so I guess they might be just silently
dropped?
Honza
[Bug c++/47606] [trans-mem] internal compiler error in expand_block_tm with O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47606 Aldy Hernandez changed: What|Removed |Added Status|WAITING |ASSIGNED AssignedTo|unassigned at gcc dot |aldyh at gcc dot gnu.org |gnu.org | --- Comment #4 from Aldy Hernandez 2011-02-23 19:32:53 UTC --- Patrick. Ok, in that case we have two bugs. Your original testcase ICEing on valid code, and my incorrectly reduced testcase which is ICEing on invalid code. My incorrectly reduced code should complain about an unsafe function call within a transaction_safe function. It is correctly erroring at -O0, but ICEing at any optimization. Blah. These inline + TM bugs just won't go away :(
[Bug fortran/47846] Deferred-string length: Length is wrong (gfortran.dg/allocate_deferred_char_scalar_1.f03)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47846 Tobias Burnus changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #4 from Tobias Burnus 2011-02-23 19:45:40 UTC --- *** Bug 47863 has been marked as a duplicate of this bug. ***
[Bug testsuite/47863] [4.6 Regression] FAIL: gfortran.dg/allocate_deferred_char_scalar_1.f03
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47863 Tobias Burnus changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||burnus at gcc dot gnu.org Resolution||DUPLICATE --- Comment #2 from Tobias Burnus 2011-02-23 19:45:40 UTC --- That's known problem: See PR 47846 *** This bug has been marked as a duplicate of bug 47846 ***
[Bug regression/47836] Some Cross Compiler can't build target-libiberty or target-zlib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47836 --- Comment #5 from Andrew Pinski 2011-02-23 20:11:09 UTC --- >--enable-languages=c,c++ Where you really able to build libstdc++ without libc? I doubt that. Try just enabling C first and then build newlib. Or are you building a combined compiler?
[Bug libfortran/47802] [4.6 Regression] libgfortran/intrinsics/ctime.c:75:3: error: too few arguments to function 'ctime_r'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47802 --- Comment #20 from dave at hiauly1 dot hia.nrc.ca 2011-02-23 20:15:34 UTC --- > As there localtime_r is also used in intrinsics/date_and_time.c, I would > assume > that one sees the same message there. Yes. I see them for all _r uses. > I am also not quite sure that _REENTRANT is the correct solution. At least for > Solaris, one should use _POSIX_C_SOURCE and not _REENTRANT to get the POSIX > version, cf. http://download.oracle.com/docs/cd/E19455-01/806-5257/compile-4/ I looked at the headers. On HP-UX 11, _REENTRANT is defined by if _POSIX_C_SOURCE is defined and _REENTRANT is not defined. However, this does not occur on HP-UX 10. The system headers never define _REENTRANT. The default _HPUX_SOURCE is equivalent to -D_POSIX_C_SOURCE=199506L on HP-UX 11. Defining _REENTRANT also includes the same POSIX sources. The PA backend defines _REENTRANT if -threads is specified on HP-UX 10 and if -pthread is specified on HP-UX 11. -threads also defines _DCE_THREADS which we may not want for the single thread model. libgfortran.sl is built twice on HP-UX 10, once for the single thread model and once for the dce thread model. It's the single thread build that's the problem. > For HP-UX, I could not find anything (cf. also > http://docs.hp.com/en/B2355-90683/ctime.3C.html). However, IBM has a statement > regarding HP-UX, which is similar to Solaris's above: > http://publib.boulder.ibm.com/infocenter/db2luw/v8/topic/com.ibm.db2.udb.doc/ad/t0007651.htm All the reentrant functions are in libc. Dave
[Bug c++/47861] static variables inside member functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47861 --- Comment #2 from michal.tlk at gmail dot com 2011-02-23 20:45:23 UTC --- Yep a warning stating the similarity of a static member function variable to its counterpart as a static member would be appreciated...maybe when pedantic option is going to be used. The issue is real, just consider how the static members/attributes need to be defined and how instead the static member function variables do not. Thanks. Hai ragione Carlo, di certo non era il posto giusto per mettere tale notifica...un warning potrebbe essere d aiuto...vi ringrazierei se potreste valutarne l importanza. la semantica del c++ porta a sottovalutare la staticita delle variabili. Ad esempio potrebbe essere introddo un warning che notifichi l uguaglianza di una variabile statica di funzione membro alla sua analoga versione attributo di classe. Grazie per la risposta immediata. Buon lavoro. M. On Wed, Feb 23, 2011 at 5:59 PM, paolo.carlini at oracle dot com < gcc-bugzi...@gcc.gnu.org> wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47861 > > Paolo Carlini changed: > > What|Removed |Added > > > Status|UNCONFIRMED |WAITING > Last reconfirmed||2011.02.23 16:59:33 > Ever Confirmed|0 |1 > > --- Comment #1 from Paolo Carlini > 2011-02-23 16:59:33 UTC --- > In any case, which action would you like to see (I'm not arguing the > technical > point): a new warning? For which specific testcase? Otherwise I'm afraid we > have to close the PR, this is not the proper place for discussing present > and/or future C++ language features. > > -- > Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email > --- You are receiving this mail because: --- > You reported the bug. >
[Bug c++/47861] static variables inside member functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47861 --- Comment #3 from Jonathan Wakely 2011-02-23 20:55:08 UTC --- (In reply to comment #2) > Yep a warning stating the similarity of a static member function variable to > its counterpart as a static member would be appreciated...maybe when > pedantic option is going to be used. No no no! pedantic is for warning about using GCC extensions, not for warning about possible misunderstanding of the language. > The issue is real, just consider how the static members/attributes need to > be defined and how instead the static member function variables do not. > Thanks. I've never encountered anyone who is confused in this way. There is no such thing as a "static member function variable" it is a function-scope static and it has exactly the same semantics whether it is present in a member function or a non-member function. I don't see what providing definitions of static members has to do with it. I don't see a need for a new warning here.
[Bug c++/47861] static variables inside member functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47861 --- Comment #4 from Jonathan Wakely 2011-02-23 20:57:57 UTC --- As requested, please provide a code example showing what you mean, and explain what warning you would like to be issued.
[Bug c++/47861] static variables inside member functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47861 --- Comment #5 from Andrew Pinski 2011-02-23 21:19:56 UTC --- Also it is hard to produce a warning when it comes to a failure that will only be diagnostic at link time.
[Bug libstdc++/47859] Makefile: Input/output error. Stop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47859 --- Comment #6 from Andrew Pinski 2011-02-23 21:22:34 UTC --- Are you building of NFS also? "make[4]: warning: Clock skew detected. Your build may be incomplete." Usually means your clock and the server clock don't match up correctly. And the IO error could possibly be a network issue.
[Bug c++/47861] static variables inside member functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47861
--- Comment #6 from Jonathan Wakely 2011-02-23
21:28:10 UTC ---
(In reply to comment #5)
> Also it is hard to produce a warning when it comes to a failure that will only
> be diagnostic at link time.
IIUC I think the OP wants a warning for:
struct S {
int f();
};
int S::f() {
static int i = 0;
return ++i;
}
which doesn't require a definition and can't produce a linker error. I think
adding a warning for this is silly.
[Bug c++/47864] New: incorrect control reaches end of non-void function (switch+break+default)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47864
Summary: incorrect control reaches end of non-void function
(switch+break+default)
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: a...@fischman.org
Using -finstrument-functions together with a switch statement containing a
"break;" can result in incorrect warning about reaching the end of a non-void
function, even when the "break;" is a no-op (because it follows an
unconditional return statement).
$ nl t.cc ; g++ -finstrument-functions -Wreturn-type -Werror -c t.cc
1 int foo(int type) {
2switch(type) {
3 case 0: return 1; break;
4 default: return 0;
5}
6 }
cc1plus: warnings being treated as errors
t.cc: In function ‘int foo(int)’:
t.cc:6: error: control reaches end of non-void function
This is with:
$ gcc --version
gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3
Doing either of:
- remove the "break;"
- build without -finstrument-functions
makes gcc stop emitting the incorrect warning.
[Bug c++/20681] [4.3/4.4/4.5/4.6 Regression] wrong "control reaches" warning with switches
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20681 Andrew Pinski changed: What|Removed |Added CC||ami at fischman dot org --- Comment #28 from Andrew Pinski 2011-02-23 22:08:42 UTC --- *** Bug 47864 has been marked as a duplicate of this bug. ***
[Bug c++/47864] incorrect control reaches end of non-void function (switch+break+default)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47864 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Andrew Pinski 2011-02-23 22:08:42 UTC --- This is exactly the same issue as PR 20681. The issue is that is try finally block which will produce a fallthrough which is not needed. *** This bug has been marked as a duplicate of bug 20681 ***
[Bug c++/47865] New: [4.6 Regression] exception_defines.h: No such file or directory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47865 Summary: [4.6 Regression] exception_defines.h: No such file or directory Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com [hjl@gnu-6 tmp]$ cat x.cc #include [hjl@gnu-6 tmp]$ /usr/gcc-4.6/bin/g++ -M x.cc x.cc:1:31: fatal error: exception_defines.h: No such file or directory compilation terminated. [hjl@gnu-6 tmp]$ /usr/gcc-4.6/bin/g++ -v Using built-in specs. COLLECT_GCC=/usr/gcc-4.6/bin/g++ COLLECT_LTO_WRAPPER=/usr/gcc-4.6/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /net/gnu-13/export/gnu/src/gcc/gcc/configure --enable-clocale=gnu --with-system-zlib --enable-checking=assert --with-demangler-in-ld --prefix=/usr/gcc-4.6 --with-local-prefix=/usr/local --enable-cloog-backend=isl --enable-stage1-languages=c++ --with-ppl-include=/opt/gnu/include --with-ppl-lib=/opt/gnu/lib64 --with-cloog-include=/opt/gnu/include --with-cloog-lib=/opt/gnu/lib64 --with-fpmath=sse Thread model: posix gcc version 4.6.0 20110222 (experimental) [trunk revision 170401] (GCC) [hjl@gnu-6 tmp]$
[Bug c++/47865] [4.6 Regression] exception_defines.h: No such file or directory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47865 --- Comment #1 from Andrew Pinski 2011-02-23 22:32:17 UTC --- I don't think this is a bug. exception_defines.h is an internal header file which is not supposed to be included by an issue program.
[Bug fortran/40850] double free in nested types with allocatable components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40850 --- Comment #14 from Mikael Morin 2011-02-23 22:38:31 UTC --- Author: mikael Date: Wed Feb 23 22:38:27 2011 New Revision: 170445 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170445 Log: 2011-02-23 Mikael Morin PR fortran/40850 * trans.c (gfc_prepend_expr_to_block): New function. * trans.h (gfc_prepend_expr_to_block): Declare. * trans-array.c (gfc_conv_array_parameter): Replace gfc_add_expr_to_block with gfc_prepend_expr_to_block. 2011-02-23 Mikael Morin PR fortran/40850 * gfortran.dg/nested_allocatables_1.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/nested_allocatables_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans.c trunk/gcc/fortran/trans.h trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/47866] New: gcc.dg/torture/vector-2.c fails on IA64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47866
Summary: gcc.dg/torture/vector-2.c fails on IA64
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: s...@cup.hp.com
gcc.dg/torture/vector-2.c is failing on Linux and HP-UX IA64 platforms since
r165240 which is Richard Henderson's fix for PR rtl-opt/33721. This may be a
target specific bug but the change that caused the failure to show up is not
target specific.
gcc.dg/torture/vector-2.c fails at -O2, but passes at -O0 or -O1. With the
latest sources I can use this cutdown test case to see the difference:
#define vector __attribute__((vector_size(16) ))
vector int f0(vector int t, int a)
{
((int*)&t)[0] = a;
return t;
}
vector int f1(vector int t, int a)
{
((int*)&t)[1] = a;
return t;
}
int main(void)
{
vector int a = {0, 0, 0, 0};
vector int a0;
a0 = f0(a, 1);
printf("%d %d %d %d\n", a0[0], a0[1], a0[2], a0[3]);
a0 = f1(a, 1);
printf("%d %d %d %d\n", a0[0], a0[1], a0[2], a0[3]);
return 0;
}
At -O0 or -O1 it prints:
1 0 0 0
0 1 0 0
At -O2 it prints:
1 0 0 0
0 0 0 0
[Bug fortran/42769] [OOP] ICE in resolve_typebound_procedure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #31 from Mikael Morin 2011-02-23 23:08:18 UTC --- (In reply to comment #25) > This seems to be a module-loading bug. When reading the specific binding of > the > TBP 'get' from 'mod1' (which happens in module.c, mio_typebound_proc), we > expect to get the symbol 'my_get' from 'mod1', but instead we get 'my_get' > from > 'mod2'. > > My knowledge of the module-reading code is not sufficient to see where stuff > goes wrong. Maybe someone else can? This is not a module loading problem I think. It's true that the two `my_get' functions do conflict in the program namespace. One does not need to pass by the program namespace to resolve the typebound call however. That is, the gfc_typebound_proc.u.specific field should be a gfc_symbol, not a gfc_symtree. This way, even if that gfc_symbol is not accessible through a gfc_symtree in the program namespace, it is loaded anyway (and gets a unique symtree but this is an implementation detail) because it is needed in the gfc_typebound_proc struct. That being said, I suppose there is a reason for it to be a gfc_symtree, and not a gfc_symbol.
[Bug c++/47865] [4.6 Regression] exception_defines.h: No such file or directory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47865 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Paolo Carlini 2011-02-23 23:29:37 UTC --- Right, it's an internal header file, which, for 4.6.0, is more neatly installed under /bits. The same happens for other internal headers (personally, I moved c++0x_warning.h, just as an example) and it's entirely on purpose.
[Bug c++/20681] [4.3/4.4/4.5/4.6 Regression] wrong "control reaches" warning with switches
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20681
--- Comment #29 from Ami Fischman 2011-02-23 23:35:45
UTC ---
Further reduced test case from dup bug 47864:
$ nl t.cc ; g++ -finstrument-functions -Wreturn-type -Werror -c t.cc
1 int foo(int type) {
2switch(type) {
3 case 0: return 1; break;
4 default: return 0;
5}
6 }
cc1plus: warnings being treated as errors
t.cc: In function ‘int foo(int)’:
t.cc:6: error: control reaches end of non-void function
(in 4.4.3)
[Bug target/47867] New: lto language is not supported on 32-bit HP-UX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47867 Summary: lto language is not supported on 32-bit HP-UX Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: dang...@gcc.gnu.org Host: hppa*-*-hpux* (32-bit) Target: hppa*-*-hpux* (32-bit) Build: hppa*-*-hpux* (32-bit) If lto is specified in --enable-languages, then many lto testsuite failures occur. For example, Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ - O2 -flto -flto-partition=none -w -c -o 2105-1.o /test/gnu/gcc/gcc/gcc/test suite/gcc.c-torture/compile/2105-1.c(timeout = 300) /test/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/2105-1.c:25:1: interna l compiler error: in default_no_named_section, at varasm.c:6128 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. compiler exited with status 1 output is: /test/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/2105-1.c:25:1: interna l compiler error: in default_no_named_section, at varasm.c:6128 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. FAIL: gcc.c-torture/compile/2105-1.c -O2 -flto -flto-partition=none (inter Breakpoint 1, default_no_named_section (name=0x7afb56c0 ".gnu.lto_.jmpfuncs.92c364e5", flags=2098176, decl=0x0) at ../../gcc/gcc/varasm.c:6128 6128 gcc_unreachable (); (gdb) bt #0 default_no_named_section (name=0x7afb56c0 ".gnu.lto_.jmpfuncs.92c364e5", flags=2098176, decl=0x0) at ../../gcc/gcc/varasm.c:6128 #1 0x0037e54c in switch_to_section (new_section=0x7afaf580) at ../../gcc/gcc/varasm.c:6997 #2 0x0027f9cc in lhd_begin_section (name=0x7afb56c0 ".gnu.lto_.jmpfuncs.92c364e5") at ../../gcc/gcc/langhooks.c:631 #3 0x004b7aa0 in lto_begin_section (name=0x7afb56c0 ".gnu.lto_.jmpfuncs.92c364e5", compress=1 '\001') at ../../gcc/gcc/lto-section-out.c:130 #4 0x004b4a1c in produce_asm (ob=0x400eaa30, fn=0x200400) at ../../gcc/gcc/lto-streamer-out.c:1873 #5 0x006678c0 in ipa_prop_write_jump_functions (set=0x7af55e40) at ../../gcc/gcc/ipa-prop.c:2853 #6 0x00657c7c in ipcp_write_summary (set=0x7afb56c0, vset=0x200400) at ../../gcc/gcc/ipa-cp.c:1543 #7 0x002b5edc in ipa_write_summaries_2 (pass=0x40024eb8, set=0x7af55e40, vset=0x7af55e50, state=0x400e87a8) at ../../gcc/gcc/passes.c:1643 #8 0x002b68e8 in ipa_write_summaries () at ../../gcc/gcc/passes.c:1672 #9 0x003a6780 in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1814 #10 0x003a69f0 in cgraph_finalize_compilation_unit () at ../../gcc/gcc/cgraphunit.c:1096 #11 0x00055540 in c_write_global_declarations () at ../../gcc/gcc/c-decl.c:9872 #12 0x002e20b0 in toplev_main (argc=0, argv=0x0) at ../../gcc/gcc/toplev.c:591 #13 0x000e539c in main (argc=2063292096, argv=0x200400) at ../../gcc/gcc/main.c:36 -bash-3.2$ ./xgcc -B./ -v Reading specs from ./specs COLLECT_GCC=./xgcc COLLECT_LTO_WRAPPER=./lto-wrapper Target: hppa2.0w-hp-hpux11.11 Configured with: ../gcc/configure --with-gnu-as --with-as=/opt/gnu/bin/as --enable-shared --with-local-prefix=/opt/gnu --prefix=/opt/gnu/gcc/gcc-4.6 --with-gmp=/opt/gnu/gcc/gcc-4.6.0 --enable-threads=posix --enable-debug=no --disable-nls --without-cloog --without-ppl --enable-languages=c,c++,objc,fortran,java,ada,obj-c++,lto Thread model: posix gcc version 4.6.0 20110223 (experimental) [trunk revision 170426] (GCC) Either the section handling needs to be fixed or lto language selection needs to be suppressed on this target.
[Bug driver/47868] New: Compiling support files...xgcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47868 Summary: Compiling support files...xgcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassig...@gcc.gnu.org ReportedBy: dang...@gcc.gnu.org Host: hppa-unknown-linux-gnu Target: hppa-unknown-linux-gnu Build: hppa-unknown-linux-gnu === acats support === Generating support files...gnatmake --GCC="/home/dave/gnu/gcc/objdir/gcc/xgcc -B/home/dave/gnu/gcc/objdir/gcc/" -gnatws -O2 /home/dave/gnu/gcc/gcc/gcc/testsuite/ada/acats/support/impbit.adb -largs --GCC="/home/dave/gnu/gcc/objdir/gcc/xgcc -B/home/dave/gnu/gcc/objdir/gcc/" /home/dave/gnu/gcc/objdir/gcc/xgcc -c -I/home/dave/gnu/gcc/gcc/gcc/testsuite/ada/acats/support/ -B/home/dave/gnu/gcc/objdir/gcc/ -gnatws -O2 -I- /home/dave/gnu/gcc/gcc/gcc/testsuite/ada/acats/support/impbit.adb gnatbind -x impbit.ali gnatlink impbit.ali -O2 --GCC=/home/dave/gnu/gcc/objdir/gcc/xgcc -B/home/dave/gnu/gcc/objdir/gcc/ target_bit= 32 target_insn=nop splitting /home/dave/gnu/gcc/objdir/gcc/testsuite/ada/acats/support/checkfil.ada into: check_file.adb splitting /home/dave/gnu/gcc/objdir/gcc/testsuite/ada/acats/support/enumchek.ada into: enum_check.ads enum_check.adb splitting /home/dave/gnu/gcc/objdir/gcc/testsuite/ada/acats/support/fcndecl.ada into: fcndecl.ads splitting /home/dave/gnu/gcc/objdir/gcc/testsuite/ada/acats/support/lencheck.ada into: length_check.ads length_check.adb splitting /home/dave/gnu/gcc/objdir/gcc/testsuite/ada/acats/support/macrosub.ada into: defs.ads getsubs.ads getsubs.adb parsemac.ads parsemac.adb macrosub.adb splitting /home/dave/gnu/gcc/objdir/gcc/testsuite/ada/acats/support/repbody.ada into: report.adb splitting /home/dave/gnu/gcc/objdir/gcc/testsuite/ada/acats/support/repspec.ada into: report.ads splitting /home/dave/gnu/gcc/objdir/gcc/testsuite/ada/acats/support/tctouch.ada into: tctouch.ads tctouch.adb splitting /home/dave/gnu/gcc/objdir/gcc/testsuite/ada/acats/support/f340a000.a into: f340a000.ads f340a000.adb splitting /home/dave/gnu/gcc/objdir/gcc/testsuite/ada/acats/support/f340a001.a into: f340a001.ads f340a001.adb splitting /home/dave/gnu/gcc/objdir/gcc/testsuite/ada/acats/support/f341a00.a into: f341a00_0.ads f341a00_0.adb f341a00_1.ads f341a00_1.adb f341a00_2.ads f341a00_2.adb splitting /home/dave/gnu/gcc/objdir/gcc/testsuite/ada/acats/support/f390a00.a into: f390a00.ads f390a00.adb splitting /home/dave/gnu/gcc/objdir/gcc/testsuite/ada/acats/support/f392a00.a into: f392a00.ads f392a00.adbsplitting /home/dave/gnu/gcc/objdir/gcc/testsuite/ada/acats/support/f392c00.a in to: f392c00_1.ads f392c00_1.adbsplitting /home/dave/gnu/gcc/objdir/gcc/testsuite/ada/acats/support/f392d00.a in to: f392d00.ads f392d00.adbsplitting /home/dave/gnu/gcc/objdir/gcc/testsuite/ada/acats/support/f393a00.a in to: f393a00_0.ads f393a00_0.adb f393a00_1.ads f393a00_1.adb f393a00_2.ads f393a00_2.adb f393a00_3.ads f393a00_3.adb f393a00_4.ads f393a00_4.adb splitting /home/dave/gnu/gcc/objdir/gcc/testsuite/ada/acats/support/f393b00.a in to: f393b00.ads f393b00.adb splitting /home/dave/gnu/gcc/objdir/gcc/testsuite/ada/acats/support/f3a2a00.a into: f3a2a00.ads f3a2a00.adb splitting /home/dave/gnu/gcc/objdir/gcc/testsuite/ada/acats/support/f460a00.a into: f460a00.ads f460a00.adb splitting /home/dave/gnu/gcc/objdir/gcc/testsuite/ada/acats/support/f730a000.a into: f730a000.ads f730a000.adb splitting /home/dave/gnu/gcc/objdir/gcc/testsuite/ada/acats/support/f730a001.a into: f730a001.ads f730a001.adb splitting /home/dave/gnu/gcc/objdir/gcc/testsuite/ada/acats/support/f731a00.a into: f731a00.ads ... splitting /home/dave/gnu/gcc/objdir/gcc/testsuite/ada/acats/support/widechr.a into: widechr.adb done. Compiling support files...xgcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found compilation terminated. spprt13s.adt: parse errors detected spprt13s.adt: chop may not be successful ... === acats tests ===Running chapter a ... xgcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not foundcompilation terminated.
[Bug target/46655] invalid '.line 0' directive emitted with -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655 Richard Nolde changed: What|Removed |Added CC||richard.nolde at cybox dot ||com --- Comment #18 from Richard Nolde 2011-02-24 01:16:22 UTC --- I'm building gcc-4.5.0 from the current GNU archive on AIX 6.1 (oslevel -s returns 6100-06-03-1048) using gcc 4.2.4 and the native AIX ld, as, ar, nm, and ranlib. I do not have any GNU binutils packages installed but I do have bash, GNU make, and a full compliment of GNU tools in the /opt/freeware tree where they are typically installed on AIX. I've built numerous other large open source packages successfully. I've applied the patch to gcc/xcoffout.c that is provided at the bottom of this thread. Configure runs successfully but the build fails at this point (full logs of configure and make output are available: /usr/bin/gcc -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -Wl,-bbigtoc -o build/genattrtab \ build/genattrtab.o build/rtl.o build/read-rtl.o build/ggc-none.o build/vec.o build/min-insn-modes.o build/gensupport.o build/print-rtl.o build/errors.o ../../build-powerpc-ibm-aix6.1.0.0/libiberty/libiberty.a build/genattrtab ../.././gcc/config/rs6000/rs6000.md \ insn-conditions.md > tmp-attrtab.c /bin/sh ../.././gcc/../move-if-change tmp-attrtab.c insn-attrtab.c echo timestamp > s-attrtab /usr/bin/gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -I. -I. -I../.././gcc -I../.././gcc/. -I../.././gcc/../include -I../.././gcc/../libcpp/include -I../.././gcc/../libdecnumber -I../.././gcc/../libdecnumber/dpd -I../libdecnumber-I/opt/freeware/include insn-attrtab.c -o insn-attrtab.o Assembler: /ramdisk/udttmp/ccxcYMAe.s: line 26089: 1252-040 The specified expression is not valid. Make sure that all symbols are defined. Check the rules on symbols used in an arithmetic expression concerning relocation. /ramdisk/udttmp/ccxcYMAe.s: line 27243: 1252-040 The specified expression is not valid. Make sure that all symbols are defined. Check the rules on symbols used in an arithmetic expression concerning relocation. /ramdisk/udttmp/ccxcYMAe.s: line 27879: 1252-040 The specified expression is not valid. Make sure that all symbols are defined. Check the rules on symbols used in an arithmetic expression concerning relocation. Many more lines of the same error messages followed by: /ramdisk/udttmp/ccxcYMAe.s: line 139907: 1252-040 The specified expression is not valid. Make sure that all symbols are defined. Check the rules on symbols used in an arithmetic expression concerning relocation. /ramdisk/udttmp/ccxcYMAe.s: line 141711: 1252-040 The specified expression is not valid. Make sure that all symbols are defined. Check the rules on symbols used in an arithmetic expression concerning relocation. /ramdisk/udttmp/ccxcYMAe.s: line 143385: 1252-040 The specified expression is not valid. Make sure that all symbols are defined. Check the rules on symbols used in an arithmetic expression concerning relocation. /ramdisk/udttmp/ccxcYMAe.s: line 144343: 1252-040 The specified expression is not valid. Make sure that all symbols are defined. Check the rules on symbols used in an arithmetic expression concerning relocation. /ramdisk/udttmp/ccxcYMAe.s: line 146123: 1252-040 The specified expression is not valid. Make sure that all symbols are defined. Check the rules on symbols used in an arithmetic expression concerning relocation. gmake[3]: *** [insn-attrtab.o] Error 1 gmake[3]: Leaving directory `/devel/opensource/gcc/gcc-4.5.0/host-powerpc-ibm-aix6.1.0.0/gcc' gmake[2]: *** [all-stage1-gcc] Error 2 gmake[2]: Leaving directory `/devel/opensource/gcc/gcc-4.5.0' gmake[1]: *** [stage1-bubble] Error 2 gmake[1]: Leaving directory `/devel/opensource/gcc/gcc-4.5.0' make: *** [all] Error 2 Let me know if I can provide additional information or logs. It appears that line numbers are exceeding 65536 for at least some of the errors. I have run make distclean between each build followed by ./configure --prefix=/opt/freeware and configure seems to find the correct native utilities without a problem.
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 Perry Smith changed: What|Removed |Added CC||pedzsan at gmail dot com --- Comment #7 from Perry Smith 2011-02-24 01:21:52 UTC --- This change must be within TL10 too. I'm at 5300-10-05-1036 and have the same issue. There are three APARs that came out in 5.3 TL10 SP02 that hit bind: IZ69311, IZ69515, and IZ70028. One APAR in SP03: IZ73713. And one in SP04: IZ82696.
[Bug c++/47865] [4.6 Regression] exception_defines.h: No such file or directory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47865 Benjamin Kosnik changed: What|Removed |Added CC||bkoz at gcc dot gnu.org --- Comment #3 from Benjamin Kosnik 2011-02-24 01:51:36 UTC --- Agreed on invalid.
[Bug tree-optimization/47770] wrong code -O2 -ftree-loop-if-convert-stores -fno-tree-reassoc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47770 --- Comment #3 from Zdenek Sojka 2011-02-24 02:20:56 UTC --- It seems most of the exec failures disappeared between r170436 and r170443 - that is, probably by the fix for PR47849. Running testsuite (languages=c,c++,lto,fortran) with RUNTESTFLAGS="--target_board=unix/-ftree-loop-if-convert-stores/-fno-tree-reassoc/-fno-tree-vectorize" gives only one ICE - PR47738 and two exec failures: ext/pb_ds/example/tree_intervals.cc (PR46029) gfortran.dg/allocate_deferred_char_scalar_1.f03 (fails even with no optimisation flags) Also, the attachment in comment #0 doesn't fail anymore.
[Bug other/47869] New: fatal error: build/gencondmd.c: No such file or directory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47869 Summary: fatal error: build/gencondmd.c: No such file or directory Product: gcc Version: 4.5.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: yuch...@gmail.com Hello, When compiling gcc-4.5.2 on x86_64-redhat-linux (Red Hat Linux 3.2.3-56) I get the following error: hape/gcc-4.5.2/gcc/../libdecnumber/bid -I../libdecnumber -I/usr/include/libelf \ -o build/gencondmd.o build/gencondmd.c cc1: fatal error: build/gencondmd.c: No such file or directory compilation terminated. make[3]: *** [build/gencondmd.o] Error 1 make[3]: Leaving directory `/data/yuchape/gcc-build/gcc' make[2]: *** [all-stage3-gcc] Error 2 make[2]: Leaving directory `/data/yuchape/gcc-build' make[1]: *** [stage3-bubble] Error 2 make[1]: Leaving directory `/data/yuchape/gcc-build' make: *** [all] Error 2 The configure command is "--prefix=/usr/local/gcc-4.5.2 --enable-threads=posix --disable-checking --disable-multilib --enable-languages=c,c++,fortran --with-gmp=/usr/local/gmp-5.0.1 --with-mpfr=/usr/local/mpfr-2.4.2 --with-mpc=/usr/local/mpc-0.8.1"
[Bug rtl-optimization/44194] struct returned by value generates useless stores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
--- Comment #8 from Josh Haberman 2011-02-24
03:27:04 UTC ---
I found another test case for this. I thought I'd post it since it's extremely
different than the original one.
--
class Foo {
public:
virtual ~Foo() {}
virtual void DoSomething() = 0;
};
void foo(Foo *f, void (Foo::*member)()) {
(f->*member)();
}
--
$ g++ -c -O3 -fomit-frame-pointer test.cc
$ objdump -M intel -d test.o
test.o: file format elf64-x86-64
Disassembly of section .text:
<_Z3fooP3FooMS_FvvE>:
0:40 f6 c6 01 test sil,0x1
4:48 89 74 24 e8 movQWORD PTR [rsp-0x18],rsi
9:48 89 54 24 f0 movQWORD PTR [rsp-0x10],rdx
e:74 10je 20 <_Z3fooP3FooMS_FvvE+0x20>
10:48 01 d7 addrdi,rdx
13:48 8b 07 movrax,QWORD PTR [rdi]
16:48 8b 74 30 ff movrsi,QWORD PTR [rax+rsi*1-0x1]
1b:ff e6jmprsi
1d:0f 1f 00 nopDWORD PTR [rax]
20:48 01 d7 addrdi,rdx
23:ff e6jmprsi
--
We spilled rsi and rdx to the stack (in the red zone, it appears) for no reason
(AFAICS).
[Bug libfortran/47567] Wrong output for small absolute values with F editing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47567 --- Comment #23 from Jerry DeLisle 2011-02-24 04:52:05 UTC --- Author: jvdelisle Date: Thu Feb 24 04:52:00 2011 New Revision: 170458 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170458 Log: 2011-02-23 Jerry DeLisle PR libgfortran/47567 * io/write_float.def (output_float): Remove special case handling of zero with width 1. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/write_float.def
[Bug libfortran/47567] Wrong output for small absolute values with F editing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47567 --- Comment #24 from Jerry DeLisle 2011-02-24 05:10:41 UTC --- Author: jvdelisle Date: Thu Feb 24 05:10:37 2011 New Revision: 170461 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170461 Log: 2011-02-23 Jerry DeLisle PR libgfortran/47567 * gfortran.dg/fmt_f0_1.f90: Update test. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/fmt_f0_1.f90
[Bug lto/47870] New: internal compiler error: in get_alias_set, at alias.c:716
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47870 Summary: internal compiler error: in get_alias_set, at alias.c:716 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: d.g.gorbac...@gmail.com Created attachment 23445 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23445 Backtrace Target: i686-pc-linux-gnu Configured with: ../gcc-4.6/configure --enable-languages=c,c++ --enable-version-specific-runtime-libs --disable-nls --disable-shared --disable-bootstrap Thread model: posix gcc version 4.6.0 20110219 (experimental) (GCC) It happens when building GCC with -flto -O3 -march=pentium4 options: In file included from :111:0: varasm.c: In function 'initializer_constant_valid_p_1': varasm.c:4112:1: internal compiler error: in get_alias_set, at alias.c:716
[Bug lto/47870] internal compiler error: in get_alias_set, at alias.c:716
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47870 --- Comment #1 from Dmitry Gorbachev 2011-02-24 05:33:34 UTC --- Created attachment 23446 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23446 Preprocessed source files in .tar.lz archive I tried to minimize the testcase with Delta, but unfortunately it does not fail with other GCC build after that.
[Bug lto/47871] New: lto1: internal compiler error: in list_length, at tree.c:2089
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47871 Summary: lto1: internal compiler error: in list_length, at tree.c:2089 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: d.g.gorbac...@gmail.com Created attachment 23447 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23447 Compile with -flto
[Bug libfortran/47567] Wrong output for small absolute values with F editing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47567 Jerry DeLisle changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #25 from Jerry DeLisle 2011-02-24 06:17:30 UTC --- Closing.
[Bug libfortran/47872] New: Alternative syntax for intrinsics should be documented on separate line
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47872 Summary: Alternative syntax for intrinsics should be documented on separate line Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: libfortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: thenl...@users.sourceforge.net The syntax documentation for the ATAN, BESSEL_JN and BESSEL_YN intrinsic functions lists the alternative calls in one line, e.g.: RESULT = ATAN(X) RESULT = ATAN(Y, X) This should be split into separate lines: RESULT = ATAN(X) RESULT = ATAN(Y, X) or separated with a semicolon: RESULT = ATAN(X); RESULT = ATAN(Y, X)
[Bug c++/47873] New: Multiple Inheritance - Covariant Virtual Function - Segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47873 Summary: Multiple Inheritance - Covariant Virtual Function - Segfault Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: isa...@xtra.co.nz Created attachment 23448 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23448 gcc-4.6 -save-temps output, demos bug The attached BugReport.ii demos a reproducible bug in a complex multiple inheritance scheme. When the covariant virtual function BugReport::Object::This is overridden and called in a derived class then the program segfaults. ggc-4.6 -v == Using built-in specs. COLLECT_GCC=gcc-4.6 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6.0/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.6-20110216-1' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-gold --enable-ld=default --with-plugin-ld=ld.gold --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.6.0 20110216 (experimental) [trunk revision 170225] (Debian 4.6-20110216-1) gcc-4.6 build command line == -std=c++0x -Wall -Wextra -pedantic -g -save-temps Shell output Segmentation fault Gdb output == Program received signal SIGSEGV, Segmentation fault. 0x in ?? ()
[Bug c++/47874] New: Multiple Inheritance - Virtual Function - Segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47874 Summary: Multiple Inheritance - Virtual Function - Segfault Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: isa...@xtra.co.nz Created attachment 23449 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23449 gcc-4.6 -save-temps output, demos bug The attached BugReport.ii demos a reproducible bug in a complex multiple inheritance scheme. When the virtual function BugReport::Tier1::Object::Print is overridden and called in a derived class then the program segfaults. ggc-4.6 -v == Using built-in specs. COLLECT_GCC=gcc-4.6 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6.0/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.6-20110216-1' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-gold --enable-ld=default --with-plugin-ld=ld.gold --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.6.0 20110216 (experimental) [trunk revision 170225] (Debian 4.6-20110216-1) gcc-4.6 build command line == -std=c++0x -Wall -Wextra -pedantic -g -save-temps Shell output Segmentation fault Gdb output == Program received signal SIGSEGV, Segmentation fault. 0x in ?? ()
[Bug web/47875] New: What's new section in GFortran wiki page: Wrong function name: TAN2.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47875 Summary: What's new section in GFortran wiki page: Wrong function name: TAN2. Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: web AssignedTo: unassig...@gcc.gnu.org ReportedBy: thenl...@users.sourceforge.net The list of Fortran 2008 features in gfortran 4.5 (http://gcc.gnu.org/wiki/GFortran#GCC4.5) says: Add ATAN(Y,X) as alias for TAN2(Y,X). This must be ATAN2, not TAN2, as stated in http://gcc.gnu.org/onlinedocs/gfortran/ATAN.html#ATAN
[Bug fortran/47876] New: Host-assoc generic subroutine plus intrinsic function not rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47876 Summary: Host-assoc generic subroutine plus intrinsic function not rejected Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: accepts-invalid Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/8e0240bbb7628ce2 Steve Lionel claims the code is invalid and NAG also rejects it, which is a good indication that it is indeed invalid - even though at a glance I thought the code is valid. gfortran compiles the following without warning or error: module hostassoc implicit none interface pack module procedure pack_sub end interface contains subroutine pack_sub () end subroutine pack_sub subroutine foo (a) integer, intent(in) :: a(:) ! intrinsic :: pack ! Try uncommenting this line... print *, pack (a, a /= 0) end subroutine foo end module hostassoc Steve wrote: The key to this is paragraph number 5 on p286 of F2008 (12.4.3.4.5 Restrictions on generic declarations). It says: Within the scope of a generic name that is the same as the generic name of an intrinsic procedure, the intrinsic procedure is not accessible by its generic name if the procedures in the interface and the intrinsic procedure are not all functions or not all subroutines. In your case with the INTRINSIC commented out, the PACK intrinsic is made inaccessible because your generic PACK has a subroutine as one of the interfaces. Since the intrinsic is inaccessible, the reference to PACK as a function fails. If you uncomment the INTRINSIC, then you are violating constraint C1215 (F2008) "Within the scope of a generic name, each pair of procedures identified by that name shall both be subroutines or both be functions"
[Bug tree-optimization/47860] is vectorization of "condition in nested loop" supported
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47860 Ira Rosen changed: What|Removed |Added CC||irar at il dot ibm.com --- Comment #2 from Ira Rosen 2011-02-24 07:30:37 UTC --- The problem is not in nested condition but in outer loop vectorization. We don't support unknown outer loop bound, and if the inner loop bound is unknown, we need to know that it's greater than 0, otherwise there is control flow inside outer loop (to skip the inner loop if it's loop bound = 0). So, if you change M and N into constants, or only M, but also add if (N <= 0) return; outside the loop nest, the outer loop gets vectorized. Ira
[Bug libstdc++/43622] no C++ typeinfo for __float128 and __int128
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622 Benjamin Kosnik changed: What|Removed |Added CC||bkoz at gcc dot gnu.org AssignedTo|unassigned at gcc dot |bkoz at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.6.0 --- Comment #1 from Benjamin Kosnik 2011-02-24 07:33:56 UTC --- Mine.
