[Bug c++/35652] [4.2/4.3/4.4 Regression] offset warning should be given in the front-end
--- Comment #15 from andreasmeier80 at gmx dot de 2009-03-27 07:16 --- Approved here: http://gcc.gnu.org/ml/gcc-patches/2009-03/msg01079.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35652
[Bug c++/37647] [4.3/4.4 regression] ICE with invalid use of constructor
--- Comment #5 from andreasmeier80 at gmx dot de 2009-03-27 07:17 --- Approved patch: http://gcc.gnu.org/ml/gcc-patches/2009-03/msg01080.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37647
[Bug c++/29727] [4.2/4.3/4.4 regression] ICE on invalid initializer for template member
--- Comment #9 from andreasmeier80 at gmx dot de 2009-03-27 07:18 --- Approved: http://gcc.gnu.org/ml/gcc-patches/2009-03/msg01080.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29727
[Bug c++/36799] [c++0x] error on va_copy in -std=c++0x mode
--- Comment #5 from andreasmeier80 at gmx dot de 2009-03-27 07:20 --- Approved: http://gcc.gnu.org/ml/gcc-patches/2009-03/msg01082.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36799
[Bug c++/38638] [4.2/4.3/4.4 regression] ICE superfluous 'typename'
--- Comment #3 from andreasmeier80 at gmx dot de 2009-03-27 07:20 --- Approved: http://gcc.gnu.org/ml/gcc-patches/2009-03/msg01084.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38638
[Bug c++/39566] New: Optimization fails on templated iteration function
I tried to reduce the code to a minimum, so the example does no longer make
sense at all.
However, the point is, that the code is supposed to return half the count of
elements in a container (e.g. if the container holds 16 elements, the function
would return 16, if it holds 33 elements, the function would still return 16).
Compiled with -O0, things are alright. Using -O1 or -O2 breaks it and the
function returns 15 for a container with 32 elements.
Compiling with -DWORKS_OK, omitting the template, everything is fine.
mrohr...@linux-5tx5:~/test uname -a
Linux linux-5tx5 2.6.27-rc3-g8d0968ab-24-pae
#8d0968abd03ec6b407df117adc773562386702fa SMP 2008/24/14 00:24:3 i686 i686 i386
GNU/Linux
mrohr...@linux-5tx5:~/test cat test.cxx
#include string
#ifdef WORKS_OK
typedef std::string::iterator II;
#else
templatetypename II
#endif
size_t test(II from, II end)
{
size_t cnt=0;
while (from != end) {
++from;
if (from == end)
return cnt;
++from;
++cnt;
}
return cnt;
}
int main(int,char**)
{
std::string s=1234567890abcdef1234567890abcdef;
size_t cnt=test(s.begin(), s.end());
return cnt;
}
mrohr...@linux-5tx5:~/test g++ -v -O1 -Wall -pedantic test.cxx
Using built-in specs.
Target: i586-suse-linux
Configured with: ../configure --prefix=/usr --with-local-prefix=/usr/local
--infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib
--libexecdir=/usr/lib --enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.3
--enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/
--with-pkgversion='SUSE Linux' --disable-libgcj --with-slibdir=/lib
--with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new
--disable-libstdcxx-pch --program-suffix=-4.3
--enable-version-specific-runtime-libs --enable-linux-futex
--without-system-libunwind --with-cpu=generic --build=i586-suse-linux
Thread model: posix
gcc version 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision 135036] (SUSE
Linux)
COLLECT_GCC_OPTIONS='-v' '-O1' '-Wall' '-pedantic' '-shared-libgcc'
'-mtune=generic'
/usr/lib/gcc/i586-suse-linux/4.3/cc1plus -quiet -v -D_GNU_SOURCE test.cxx
-quiet -dumpbase test.cxx -mtune=generic -auxbase test -O1 -Wall -pedantic
-version -o /tmp/cc0jlsQi.s
#include ... search starts here:
#include ... search starts here:
/usr/include/c++/4.3
/usr/include/c++/4.3/i586-suse-linux
/usr/include/c++/4.3/backward
/usr/local/include
/usr/lib/gcc/i586-suse-linux/4.3/include
/usr/lib/gcc/i586-suse-linux/4.3/include-fixed
/usr/lib/gcc/i586-suse-linux/4.3/../../../../i586-suse-linux/include
/usr/include
End of search list.
GNU C++ (SUSE Linux) version 4.3.1 20080507 (prerelease) [gcc-4_3-branch
revision 135036] (i586-suse-linux)
compiled by GNU C version 4.3.1 20080507 (prerelease) [gcc-4_3-branch
revision 135036], GMP version 4.2.2, MPFR version 2.3.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 0a1ff4dd89b2c90c4ec1f432d1f05160
COLLECT_GCC_OPTIONS='-v' '-O1' '-Wall' '-pedantic' '-shared-libgcc'
'-mtune=generic'
/usr/lib/gcc/i586-suse-linux/4.3/../../../../i586-suse-linux/bin/as -V -Qy -o
/tmp/cc8Gof5B.o /tmp/cc0jlsQi.s
GNU assembler version 2.18.50 (i586-suse-linux) using BFD version (GNU
Binutils; openSUSE 11.0) 2.18.50.20080409-11.1
COMPILER_PATH=/usr/lib/gcc/i586-suse-linux/4.3/:/usr/lib/gcc/i586-suse-linux/4.3/:/usr/lib/gcc/i586-suse-linux/:/usr/lib/gcc/i586-suse-linux/4.3/:/usr/lib/gcc/i586-suse-linux/:/usr/lib/gcc/i586-suse-linux/4.3/:/usr/lib/gcc/i586-suse-linux/:/usr/lib/gcc/i586-suse-linux/4.3/../../../../i586-suse-linux/bin/
LIBRARY_PATH=/usr/lib/gcc/i586-suse-linux/4.3/:/usr/lib/gcc/i586-suse-linux/4.3/:/usr/lib/gcc/i586-suse-linux/4.3/../../../../i586-suse-linux/lib/:/usr/lib/gcc/i586-suse-linux/4.3/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-O1' '-Wall' '-pedantic' '-shared-libgcc'
'-mtune=generic'
/usr/lib/gcc/i586-suse-linux/4.3/collect2 --eh-frame-hdr -m elf_i386
-dynamic-linker /lib/ld-linux.so.2
/usr/lib/gcc/i586-suse-linux/4.3/../../../crt1.o
/usr/lib/gcc/i586-suse-linux/4.3/../../../crti.o
/usr/lib/gcc/i586-suse-linux/4.3/crtbegin.o -L/usr/lib/gcc/i586-suse-linux/4.3
-L/usr/lib/gcc/i586-suse-linux/4.3
-L/usr/lib/gcc/i586-suse-linux/4.3/../../../../i586-suse-linux/lib
-L/usr/lib/gcc/i586-suse-linux/4.3/../../.. /tmp/cc8Gof5B.o -lstdc++ -lm
-lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/i586-suse-linux/4.3/crtend.o
/usr/lib/gcc/i586-suse-linux/4.3/../../../crtn.o
--
Summary: Optimization fails on templated iteration function
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: m dot rohrbacher at r-dev dot de
GCC build triplet: gcc version 4.3.1 20080507 (prerelease) [gcc-4_3-branch
[Bug c++/39566] Optimization fails on templated iteration function
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-03-27 09:23 --- This was fixed in GCC 4.3.2. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to fail||4.3.1 Known to work||4.3.2 Resolution||FIXED Target Milestone|--- |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39566
[Bug target/39565] Static variable leaves undefined symbol in object file
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-03-27 09:19 --- I get t.o: file format elf32-i386 SYMBOL TABLE: ldf *ABS* t.c ld .text .text ld .data .data ld .bss .bss l O .rodata000f codestrs_4 000f l O .rodata0017 codestrs_8 ld .rodata .rodata ld .note.GNU-stack .note.GNU-stack ld .comment .comment g F .text 0022 psiginfo -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39565
[Bug target/39558] Bad interaction of decls named 'vector' and -maltivec vector support
--- Comment #5 from jakub at gcc dot gnu dot org 2009-03-27 11:09 --- Ah, I see. The problem is that rs6000_macro_to_expand sometimes calls cpp_get_token (when seeing a macro after vector token), and removes optionally some CPP_PADDING tokens and a NT_MACRO token (with PREV_WHITE set on it). This only affects vector, not pixel nor bool. Unfortunately, we can't expand vector to a macro defined as 'vector ' (without quotes), because that would mean infinite recursion. We could perhaps if macro_to_expand hook returns NULL set PREV_WHITE on the next token (on the libcpp side, as rs6000_macro_to_expand sees tokens as const cpp_token), or insert a CPP_PADDING token. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39558
[Bug debug/39563] C block scopes have no DW_TAG_lexical_block
--- Comment #2 from jakub at gcc dot gnu dot org 2009-03-27 12:38 --- This seems to be just a C FE problem, C++ FE compiling the exact same testcase gives the expected output (DW_TAG_lexical_block with DW_TAG_variable with DW_AT_external). So IMHO just the C FE should be fixed to handle it like the C++ FE and if there are gdb bugs, they should be fixed in gdb. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-03-27 12:38:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39563
[Bug c++/38638] [4.2/4.3/4.4 regression] ICE superfluous 'typename'
--- Comment #4 from hjl at gcc dot gnu dot org 2009-03-27 13:36 --- Subject: Bug 38638 Author: hjl Date: Fri Mar 27 13:36:33 2009 New Revision: 145107 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145107 Log: gcc/cp/ 2009-03-27 Andrew Pinski andrew_pin...@playstation.sony.com PR c++/38638 * parser.c (cp_parser_elaborated_type_specifier): If we have a typename tag and don't have either a TYPE_DECL or a TEMPLATE_ID_EXPR, set the type to NULL. gcc/testsuite/ 2009-03-27 Andrew Pinski andrew_pin...@playstation.sony.com PR c++/38638 * g++.dg/template/typename17.C: New testcase. * g++.dg/template/typename18.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/template/typename17.C trunk/gcc/testsuite/g++.dg/template/typename18.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38638
[Bug c++/35652] [4.2/4.3 Regression] offset warning should be given in the front-end
--- Comment #17 from dominiq at lps dot ens dot fr 2009-03-27 14:30 --- The commit in comment #16 breaks bootstrap on *-darwin9: ... cc1: warnings being treated as errors ../../gcc-4.4-work/gcc/c-common.c: In function 'pointer_int_sum': ../../gcc-4.4-work/gcc/c-common.c:3320: error: format '%ld' expects type 'long int', but argument 4 has type 'long long int' ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35652
[Bug c++/35652] [4.2/4.3 Regression] offset warning should be given in the front-end
--- Comment #18 from rguenth at gcc dot gnu dot org 2009-03-27 14:34 --- If this isn't resolved quickly please open a bugreport for this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35652
[Bug c++/35652] [4.2/4.3 Regression] offset warning should be given in the front-end
--- Comment #19 from dominiq at lps dot ens dot fr 2009-03-27 14:44 --- If this isn't resolved quickly please open a bugreport for this. I'll do it. This is a recurrent issue due to maintainers not using the -Werror in their tests. Unfortunately I don't remember how such failures have been fixed in the past (a cast to long int?). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35652
[Bug c++/35652] [4.2/4.3 Regression] offset warning should be given in the front-end
--- Comment #20 from dominiq at lps dot ens dot fr 2009-03-27 14:50 --- Currently testing the patch in http://gcc.gnu.org/ml/gcc-patches/2009-03/msg01377.html. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35652
[Bug target/39565] Static variable leaves undefined symbol in object file
--- Comment #2 from edmar at freescale dot com 2009-03-27 15:01 --- I noticed that too. On x86_64 there is no undefined symbol either. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39565
[Bug middle-end/39301] ICE in register_overhead, at bitmap.c:115
--- Comment #3 from lucier at math dot purdue dot edu 2009-03-27 15:12
---
I'm still seeing it with:
[luc...@descartes ~]$ /pkgs/gcc-mainline/bin/gcc -v
Using built-in specs.
Target: powerpc64-unknown-linux-gnu
Configured with: ../../mainline/configure --prefix=/pkgs/gcc-mainline
--enable-languages=c --enable-gather-detailed-mem-stats --with-cpu=default64
Thread model: posix
gcc version 4.4.0 20090327 (experimental) [trunk revision 145100] (GCC)
as
[luc...@descartes compiler.i-test]$
/pkgs/gcc-mainline/libexec/gcc/powerpc64-unknown-linux-gnu/4.4.0/cc1
-I../include -Wall -W -Wno-unused -O1 -fno-math-errno -fschedule-insns2 -O1
-fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing
-fwrapv -fomit-frame-pointer -fPIC -fno-common compiler.i
btowc wctob mbrlen {GC 5325k - 3526k} {GC 5325k - 4483k} code_size
___H__20_compiler_2e_o1 {GC 201152k - 113339k} ___init_proc
20_compiler_2e_o1
Analyzing compilation unit
{GC 181409k - 135700k}Performing interprocedural optimizations
visibility early_local_cleanups {GC 237979k - 236431k} summary generate
inline static-var pure-constAssembling functions:
code_size ___init_proc 20_compiler_2e_o1 ___H__20_compiler_2e_o1 {GC
349493k - 288659k} {GC 406233k - 272085k}
compiler.c: In function รข:
compiler.c:322876: internal compiler error: in register_overhead, at
bitmap.c:115
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
I have to admit I didn't see it with an x86-64 compiler; perhaps the ppc64 port
is more complicated and requires more bitmaps.
I suspect, given the error message, that you built a 32-bit compiler and ran
out of memory space before you hit this problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39301
[Bug c++/35652] [4.2/4.3 Regression] offset warning should be given in the front-end
--- Comment #21 from dominiq at lps dot ens dot fr 2009-03-27 15:13 --- The failure reported in comment #17 has been fixed by revision 145109. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35652
[Bug target/39558] Bad interaction of decls named 'vector' and -maltivec vector support
--- Comment #6 from meissner at linux dot vnet dot ibm dot com 2009-03-27
15:19 ---
Subject: Re: Bad interaction of decls named 'vector' and -maltivec vector
support
On Fri, Mar 27, 2009 at 11:09:57AM -, jakub at gcc dot gnu dot org wrote:
--- Comment #5 from jakub at gcc dot gnu dot org 2009-03-27 11:09 ---
Ah, I see. The problem is that rs6000_macro_to_expand sometimes calls
cpp_get_token (when seeing a macro after vector token), and removes optionally
some CPP_PADDING tokens and a NT_MACRO token (with PREV_WHITE set on it).
This only affects vector, not pixel nor bool. Unfortunately, we can't
expand vector to a macro defined as 'vector ' (without quotes), because that
would mean infinite recursion. We could perhaps if macro_to_expand hook
returns NULL set PREV_WHITE on the next token (on the libcpp side, as
rs6000_macro_to_expand sees tokens as const cpp_token), or insert a
CPP_PADDING
token.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39558
--- You are receiving this mail because: ---
You reported the bug, or are watching the reporter.
Note, there is problem with infinite recursion, since a macro is temporarily
undefined when it is being expanded, as per the ISO C rules. I tried the
following patch:
2009-03-26 Michael Meissner meiss...@linux.vnet.ibm.com
PR target/39558
* rs6000-c.c (rs6000_macro_to_expand): If the conditional macro is
not to be expanded, return the default definition which is the
macro defined as itself. This insures that the proper spacing is
put out if -save-temps or -E is used and the next token is an
identifier or macro.
Index: gcc/config/rs6000/rs6000-c.c
===
--- gcc/config/rs6000/rs6000-c.c(revision 145074)
+++ gcc/config/rs6000/rs6000-c.c(working copy)
@@ -155,9 +155,6 @@ rs6000_macro_to_expand (cpp_reader *pfil
ident = altivec_categorize_keyword (tok);
- if (ident != expand_this)
-expand_this = NULL;
-
if (ident == C_CPP_HASHNODE (__vector_keyword))
{
int idx = 0;
And it works for the compiler, but then gcc.target/powerpc/altivec-27.c fails,
which is crafted to test various cpp pasting, etc. I like your idea about
inserting a CPP_PADDING token.
The other way to do it is to add support for conditional keywords, like I did
for the named address space stuff for the cell, and not abuse the preprocessor.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39558
[Bug target/39558] Bad interaction of decls named 'vector' and -maltivec vector support
--- Comment #7 from meissner at linux dot vnet dot ibm dot com 2009-03-27 15:59 --- Subject: Re: Bad interaction of decls named 'vector' and -maltivec vector support On Fri, Mar 27, 2009 at 11:18:52AM -0400, Michael Meissner wrote: Note, there is problem with infinite recursion, since a macro is temporarily undefined when it is being expanded, as per the ISO C rules. I tried the following patch: Just to be clear, I meant to say there is no problem with infinite recursion. Whoops. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39558
[Bug c++/39567] New: class member template function won't compile
% g++ -v
Using built-in specs.
Target: i386-pc-solaris2.10
Configured with: ../gcc-4.3.3/configure --prefix=/home/robind/local
--with-gnu-as --with-as=/usr/sfw/bin/gas --without-gnu-ld
--with-ld=/usr/ccs/bin/ld
Thread model: posix
gcc version 4.3.3 (GCC)
With this source file:
templatetypename T
struct wom
{
T afunc();
};
struct foo
{
templatetypename T
T bfunc(womT w)
{
return w.afuncT();
}
};
I get this compilation error:
bug.cc: In member function 'T foo::bfunc(womT)':
bug.cc:12: error: expected primary-expression before '' token
bug.cc:12: error: expected primary-expression before ')' token
Renaming the function at line 10 from bfunc to afunc makes the code compile.
Thanks,
David Robinson
--
Summary: class member template function won't compile
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: drtr at dial dot pipex dot com
GCC build triplet: i386-pc-solaris2.10
GCC host triplet: i386-pc-solaris2.10
GCC target triplet: i386-pc-solaris2.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39567
[Bug c++/39567] class member template function won't compile
--- Comment #1 from paolo dot carlini at oracle dot com 2009-03-27 16:04 --- Just use, correctly: w.template afuncT(); -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39567
[Bug debug/39563] C block scopes have no DW_TAG_lexical_block
--- Comment #3 from jakub at gcc dot gnu dot org 2009-03-27 16:33 ---
Created an attachment (id=17544)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17544action=view)
gcc44-pr39563.patch
Untested fix.
The problem with this patch is that DW_AT_decl_file and DW_AT_decl_line of the
DW_AT_external DW_TAG_variable and DW_TAG_subprogram DIEs is wrong. Say for:
extern void abort (void);
int var = 1;
int
main (void)
{
int var = 2;
if (var != 2)
abort ();
{
extern int var;
extern void abort (void);
if (var != 1)
abort ();
{
int var = 3;
if (var != 3)
abort ();
{
extern int var;
extern void abort (void);
if (var != 1)
abort ();
}
}
}
return 0;
}
for all DW_AT_external DW_TAG_variable DIEs DW_AT_decl_line is 3 and for abort
DW_AT_decl_line is the last extern void abort (void) line.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39563
[Bug rtl-optimization/34999] Fallthru crossing edges in partition_hot_cold_basic_blocks are not been fixed when the section ends with call insn
--- Comment #22 from ghazi at gcc dot gnu dot org 2009-03-27 16:37 ---
I still see failures in bb-reorg.c and pr34999.c on x86_64-unknown-linux-gnu:
http://gcc.gnu.org/ml/gcc-testresults/2009-03/msg02744.html
The error message is slightly different than what others have posted here. I'm
using GNU assembler 2.17 Debian GNU/Linux on the GCC compile farm:
FAIL: gcc.dg/tree-prof/bb-reorg.c compilation, -fprofile-use -D_PROFILE_USE
/tmp/cc87gzwS.s: Assembler messages:
/tmp/cc87gzwS.s:116: Error: can't resolve `.text.unlikely' {.text.unlikely
section} - `L0^A' {.text section}
compiler exited with status 1
FAIL: gcc.dg/tree-prof/pr34999.c compilation, -fprofile-use -D_PROFILE_USE
/tmp/ccDOht2P.s: Assembler messages:
/tmp/ccDOht2P.s:109: Error: can't resolve `.text.unlikely' {.text.unlikely
section} - `L0^A' {.text section}
compiler exited with status 1
These are the last C testsuite failures I get on this box. Perhaps we can
xfail them when we branch if it won't be fixed in time for 4.4?
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
CC||ghazi at gcc dot gnu dot org
Last reconfirmed|2008-02-28 09:47:54 |2009-03-27 16:37:36
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34999
[Bug objc/36610] objc_msg_sendv is broken for targets which pass argument via registers
--- Comment #7 from ghazi at gcc dot gnu dot org 2009-03-27 16:51 --- Andrew - You added the testcase for this PR back in December to see which lp64 targets failed: http://gcc.gnu.org/ml/gcc-patches/2008-12/msg01199.html It's still failing several months later. x86_64: http://gcc.gnu.org/ml/gcc-patches/2008-12/msg01199.html ppc64: http://gcc.gnu.org/ml/gcc-testresults/2009-03/msg02732.html ia64: http://gcc.gnu.org/ml/gcc-testresults/2009-03/msg02716.html s390: http://gcc.gnu.org/ml/gcc-testresults/2009-03/msg02491.html sh4: http://gcc.gnu.org/ml/gcc-testresults/2009-03/msg02437.html etc. I think there's plenty of data now to see where it fails. You should XFAIL it until a fix is installed to avoid noise in the testsuite results. Thanks. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added CC||ghazi at gcc dot gnu dot ||org, pinskia at gcc dot gnu ||dot org Last reconfirmed|2009-01-01 16:23:10 |2009-03-27 16:51:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36610
[Bug objc/36610] objc_msg_sendv is broken for targets which pass argument via registers
--- Comment #8 from ghazi at gcc dot gnu dot org 2009-03-27 16:55 --- (In reply to comment #7) It's still failing several months later. x86_64: http://gcc.gnu.org/ml/gcc-patches/2008-12/msg01199.html The x86_64 link should be: http://gcc.gnu.org/ml/gcc-testresults/2009-03/msg02744.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36610
[Bug rtl-optimization/39510] [avr] missed optimisation with IO read and register variables
--- Comment #1 from eric dot weddington at atmel dot com 2009-03-27 17:06 --- This bug is invalid. Your test code is in main() which returns an int. The return value is stored in r24. So the code is correct to store the value in both r2 (test) and r24. See the avr-libc user manual, FAQ, for more information on the calling convention: http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_reg_usage Perhaps you need to try this in a function that has void return. -- eric dot weddington at atmel dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39510
[Bug target/29274] 4.1, 4.2 (possibly 4.0?) not using mulsidi3
--- Comment #3 from ramana at gcc dot gnu dot org 2009-03-27 17:12 --- I can see this with trunk as well as 4.3 branch today. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-03-27 17:12:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29274
[Bug objc/36610] objc_msg_sendv is broken for targets which pass argument via registers
--- Comment #9 from dave at hiauly1 dot hia dot nrc dot ca 2009-03-27 17:38 --- Subject: Re: objc_msg_sendv is broken for targets which pass argument via registers It's still failing several months later. x86_64: http://gcc.gnu.org/ml/gcc-patches/2008-12/msg01199.html ppc64: http://gcc.gnu.org/ml/gcc-testresults/2009-03/msg02732.html ia64: http://gcc.gnu.org/ml/gcc-testresults/2009-03/msg02716.html s390: http://gcc.gnu.org/ml/gcc-testresults/2009-03/msg02491.html sh4: http://gcc.gnu.org/ml/gcc-testresults/2009-03/msg02437.html Also, hppa. I think there's plenty of data now to see where it fails. You should XFAIL it until a fix is installed to avoid noise in the testsuite results. I tried but .x files don't seem to work in this directory. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36610
[Bug rtl-optimization/39510] [avr] missed optimisation with IO read and register variables
--- Comment #2 from k dot kosciuszkiewicz+gcc at gmail dot com 2009-03-27
17:46 ---
I can't see how register usage and calling convention affect this.
As I said before, this behaviour bit me in a naked interrupt handler, with no
arguments and no return value.
I'm attaching a fixed test case where functions have no arguments and void
return type.
#include avr/io.h
register uint8_t test asm(r2);
void fun1(void)
{
test = TCNT0;
}
void fun2(void)
{
TCNT0 = test;
}
Compile with -Os. Generated instruction sequence:
fun1:
0: 82 b7 in r24, 0x32 ; 50
2: 28 2e mov r2, r24
4: 08 95 ret
0006 fun2:
6: 22 be out 0x32, r2; 50
8: 08 95 ret
--
k dot kosciuszkiewicz+gcc at gmail dot com changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39510
[Bug rtl-optimization/39510] [avr] missed optimisation with IO read and register variables
--- Comment #3 from k dot kosciuszkiewicz+gcc at gmail dot com 2009-03-27 17:47 --- Created an attachment (id=17545) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17545action=view) Second test case with void functions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39510
[Bug middle-end/39568] New: [graphite] Remove GBB_LOOPS
We create an LOOPS vector for every gimple_bb in a SCoP. This is not necessary. It is just used for the functions gbb_loop_index and gbb_loop_at_index As the order of the LOOPS vector never changes (all transformations are made using the scattering functions) it can be replaced in gbb_loop_index with a simple call to sese_loop_depth gbb_loop_at_index can be implemented in the style of sese_loop_depth. -- Summary: [graphite] Remove GBB_LOOPS Product: gcc Version: unknown Status: UNCONFIRMED Severity: trivial Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: grosser at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39568
[Bug target/39558] Bad interaction of decls named 'vector' and -maltivec vector support
--- Comment #8 from jakub at gcc dot gnu dot org 2009-03-27 17:55 --- Created an attachment (id=17546) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17546action=view) gcc44-pr39558.patch Untested patch to fix this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39558
[Bug middle-end/39568] [graphite] Remove GBB_LOOPS
--- Comment #1 from spop at gcc dot gnu dot org 2009-03-27 18:01 --- Thanks Tobias for working on this one. -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-03-27 18:01:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39568
[Bug debug/39563] C block scopes have no DW_TAG_lexical_block
--- Comment #4 from jakub at gcc dot gnu dot org 2009-03-27 18:19 --- Created an attachment (id=17547) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17547action=view) gcc44-pr39563.patch Updated patch that preserves the correct location info for the nested extern decls. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39563
[Bug tree-optimization/39557] Invalid PDOM lead to infinite loop to be generated
--- Comment #2 from davidxl at gcc dot gnu dot org 2009-03-27 18:25 --- See SVN revision 145121 for the fix. -- davidxl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39557
[Bug tree-optimization/39548] gcc ICE compiling code with option -fprofile-generate
--- Comment #8 from davidxl at gcc dot gnu dot org 2009-03-27 18:28 --- See r145118 for the fix. -- davidxl at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39548
[Bug c++/34870] argument-dependent lookup wrongly finds friend declaration
--- Comment #9 from jason at gcc dot gnu dot org 2009-03-27 18:34 --- You're right, a template-id does still get argument-dependent lookup. -- jason at gcc dot gnu dot org changed: What|Removed |Added CC||jason at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34870
[Bug bootstrap/39001] lto branch doesn't build
--- Comment #8 from andreast at gcc dot gnu dot org 2009-03-27 19:53 --- I confirm a successful bootstrap on powerpc-unknown-linux-gnu. Thanks Rafael! [andre...@mini objdir]$ ./gcc/xgcc -v Using built-in specs. COLLECT_GCC=./gcc/xgcc Target: powerpc-unknown-linux-gnu Configured with: /share1/devel/gcc-testing/lto/gcc/configure --disable-checking --enable-languages=c,c++,lto Thread model: posix gcc version 4.4.0 20090305 (experimental) [lto revision 145091] (lto merged with rev 144635) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39001
[Bug tree-optimization/39557] Invalid PDOM lead to infinite loop to be generated
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39557
[Bug tree-optimization/39548] gcc ICE compiling code with option -fprofile-generate
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39548
[Bug debug/39563] C block scopes have no DW_TAG_lexical_block
--- Comment #5 from jakub at gcc dot gnu dot org 2009-03-27 20:46 --- Created an attachment (id=17548) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17548action=view) gcc44-pr39563.patch Patch that actually bootstrapped/regtested successfully. Jan, could you please test it with gdb/archer? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39563
[Bug target/39558] Bad interaction of decls named 'vector' and -maltivec vector support
--- Comment #9 from meissner at linux dot vnet dot ibm dot com 2009-03-27 21:20 --- Subject: Re: Bad interaction of decls named 'vector' and -maltivec vector support On Fri, Mar 27, 2009 at 05:55:05PM -, jakub at gcc dot gnu dot org wrote: --- Comment #8 from jakub at gcc dot gnu dot org 2009-03-27 17:55 --- Created an attachment (id=17546) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17546action=view) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17546action=view) gcc44-pr39558.patch Untested patch to fix this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39558 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. This does fix the problem and has no extra testsuite failures. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39558
[Bug debug/37959] g++ does not emit DW_AT_explicit
--- Comment #3 from jakub at gcc dot gnu dot org 2009-03-27 21:44 --- Subject: Bug 37959 Author: jakub Date: Fri Mar 27 21:44:21 2009 New Revision: 145128 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145128 Log: PR debug/37959 * dwarf2out.c (dwarf_attr_name): Handle DW_AT_explicit attribute. (gen_subprogram_die): When a function is explicit, generate the DW_AT_explicit attribute. * langhooks.h (struct lang_hooks_for_decls): Add function_decl_explicit_p langhook. * langhooks-def.h (LANG_HOOKS_FUNCTION_DECL_EXPLICIT_P): Define. (LANG_HOOKS_DECLS): Add LANG_HOOKS_FUNCTION_DECL_EXPLICIT_P. * cp-objcp-common.h (LANG_HOOKS_FUNCTION_DECL_EXPLICIT_P): Define. (cp_function_decl_explicit_p): New prototype. * cp-objcp-common.c (cp_function_decl_explicit_p): New function. * g++.dg/debug/dwarf2/explicit-constructor.C: New test. Added: trunk/gcc/testsuite/g++.dg/debug/dwarf2/explicit-constructor.C Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-objcp-common.c trunk/gcc/cp/cp-objcp-common.h trunk/gcc/dwarf2out.c trunk/gcc/langhooks-def.h trunk/gcc/langhooks.h trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37959
[Bug libstdc++/39569] New: Apparent memory corruption in std::stringstream after calling syslog()
Good afternoon, I've encountered a memory corruption problem writing to a stringstream after I've called syslog(), and I've been unable to find resolution. The short summary is that if my program makes a call to syslog(), then later during execution when I write 136 bytes of data into an std::stringstream object, the first 4 bytes in the stream get written as (or reset to) 0's. (If I write only 132 bytes into the object, the stream doesn't get corrupt. If I don't make the call to syslog(), the stream doesn't get corrupted.) I've created a small, self-contained test app that seems to reliably recreate the bug. I have tested (and recreated) it under Fedora 8 (x86_64), Fedora 8 (ppc), and Fedora 10 (i386). (I tried different compilers platforms to try and rule out problems with a particular installation/configuration.) I can make available a .tgz file containing this test app upon request. My apologies in advance for any mistakes I make in submitting the bug... this is my first gcc bug, so I'm unfamiliar with the process. The remainder of the requested Bug info: Exact GCC version: gcc version 4.3.2 20081105 (Red Hat 4.3.2-7) (GCC) System Type: Target: i386-redhat-linux GCC build options: Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-cpu=generic --build=i386-redhat-linux Command line which triggers bug: make # to generate test_main; ./test_main 1# to run the program and write to syslog Note: you can also enter ./test_main 0 to run writing with printf instead of syslog... this will not fail. Compiler output: g++ -c -O0 -g -Wall -save-temps test_main.cpp g++ -c -O0 -g -Wall -save-temps FfdDevice.cpp g++ -c -O0 -g -Wall -save-temps FfdDataPage.cpp g++ -c -O0 -g -Wall -save-temps Trace.cpp gcc -c -O0 -g -Wall -save-temps BoxLog.c g++ -o test_main test_main.o FfdDevice.o FfdDataPage.o Trace.o BoxLog.o -lstdc++ Preprocessed *.i* files: Hmm... you have me here... I don't see a way to attach them, or the source files themselves, to the Bugzilla bug. I will commit the bug and then see if some mechanism for attaching a .tgz with the sources and .i* files. If I can't find a way, then I will be happy to provide the .i* files and/or sources upon request, if someone will let me know the proper mechanism. -- Summary: Apparent memory corruption in std::stringstream after calling syslog() Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: major Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jmcdonald at fairfield dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39569
[Bug libstdc++/39569] Apparent memory corruption in std::stringstream after calling syslog()
--- Comment #1 from jmcdonald at fairfield dot com 2009-03-27 21:59 --- Created an attachment (id=17549) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17549action=view) Test case gcc preprocessed files (from Fedora8 x86_64 machine) I wasn't able to generate the preprocessed files on the Fedora 10 machine... the command 'g++ -c -O0 -g -Wall -save-temps file' produces the .o file, but no .i* files. So I generated the .i* files on the Fedora 8 machine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39569
[Bug libstdc++/39569] Apparent memory corruption in std::stringstream after calling syslog()
--- Comment #2 from jmcdonald at fairfield dot com 2009-03-27 22:05 ---
Created an attachment (id=17550)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17550action=view)
Sources for self-contained test case which recreated bug.
This attachment contains the complete sources makefile for recreating the
bug.
To recreate it, simply untar the file into an empty folder ('tar -xzvf
bug_39569_test_case.tgz'), cd to that folder, and enter the make command.
Once you have the test_main executable, you can enter:
./test_main
to run the executable and 'log' to std out, which will work correctly... or
./test_main 1
to run the executable and log to syslog(), which will demonstrate the apparent
memory corruption.
I've tried to make the example as concise and helpful as possible... but if
I've missed anything, please don't hesitate to contact me.
I thank you very much for any help you can provide...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39569
[Bug target/39472] Add -mabi=[ms|sysv]
--- Comment #6 from hjl at gcc dot gnu dot org 2009-03-27 22:22 --- Subject: Bug 39472 Author: hjl Date: Fri Mar 27 22:22:30 2009 New Revision: 145133 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145133 Log: gcc/ 2009-03-27 H.J. Lu hongjiu...@intel.com PR target/39472 * config/i386/i386.c (ix86_abi): New. (override_options): Handle -mabi=. (ix86_function_arg_regno_p): Replace DEFAULT_ABI with ix86_abi. (ix86_call_abi_override): Likewise. (init_cumulative_args): Likewise. (function_arg_advance): Likewise. (function_arg_64): Likewise. (function_arg): Likewise. (ix86_pass_by_reference): Likewise. (ix86_function_value_regno_p): Likewise. (ix86_build_builtin_va_list_abi): Likewise. (setup_incoming_varargs_64): Likewise. (is_va_list_char_pointer): Likewise. (ix86_init_machine_status): Likewise. (ix86_reg_parm_stack_space): Use enum calling_abi on call_abi. (ix86_function_type_abi): Return enum calling_abi. Rewrite for 64bit. Replace DEFAULT_ABI with ix86_abi. (ix86_function_abi): Make it static and return enum calling_abi. (ix86_cfun_abi): Return enum calling_abi. Replace DEFAULT_ABI with ix86_abi. (ix86_fn_abi_va_list): Updated. * config/i386/i386.h (ix86_abi): New. (STACK_BOUNDARY): Replace DEFAULT_ABI with ix86_abi. (CONDITIONAL_REGISTER_USAGE): Likewise. (CUMULATIVE_ARGS): Change call_abi type to enum calling_abi. (machine_function): Likewise. * config/i386/i386.md (untyped_call): Replace DEFAULT_ABI with ix86_abi. * config/i386/cygming.h (TARGET_64BIT_MS_ABI): Likewise. (STACK_BOUNDARY): Likewise. * config/i386/mingw32.h (EXTRA_OS_CPP_BUILTINS): Likewise. * config/i386/i386.opt (mabi=): New. * config/i386/i386-protos.h (ix86_cfun_abi): Changed to return enum calling_abi. (ix86_function_type_abi): Likewise. (ix86_function_abi): Removed. * doc/invoke.texi: Document -mabi= option for x86. gcc/testsuite/ 2009-03-27 H.J. Lu hongjiu...@intel.com PR target/39472 * gcc.target/x86_64/abi/callabi/func-2a.c: New. * gcc.target/x86_64/abi/callabi/func-2b.c: Likewise. * gcc.target/x86_64/abi/callabi/func-indirect-2a.c: Likewise. * gcc.target/x86_64/abi/callabi/func-indirect-2b.c: Likewise. * gcc.target/x86_64/abi/callabi/vaarg-4a.c: Likewise. * gcc.target/x86_64/abi/callabi/vaarg-4b.c: Likewise. * gcc.target/x86_64/abi/callabi/vaarg-5a.c: Likewise. * gcc.target/x86_64/abi/callabi/vaarg-5b.c: Likewise. Added: trunk/gcc/testsuite/gcc.target/x86_64/abi/callabi/func-2a.c trunk/gcc/testsuite/gcc.target/x86_64/abi/callabi/func-2b.c trunk/gcc/testsuite/gcc.target/x86_64/abi/callabi/func-indirect-2a.c trunk/gcc/testsuite/gcc.target/x86_64/abi/callabi/func-indirect-2b.c trunk/gcc/testsuite/gcc.target/x86_64/abi/callabi/vaarg-4a.c trunk/gcc/testsuite/gcc.target/x86_64/abi/callabi/vaarg-4b.c trunk/gcc/testsuite/gcc.target/x86_64/abi/callabi/vaarg-5a.c trunk/gcc/testsuite/gcc.target/x86_64/abi/callabi/vaarg-5b.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/cygming.h trunk/gcc/config/i386/i386-protos.h trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.h trunk/gcc/config/i386/i386.md trunk/gcc/config/i386/i386.opt trunk/gcc/config/i386/mingw32.h trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39472
[Bug rtl-optimization/38034] Unnecssary register move
--- Comment #3 from hjl at gcc dot gnu dot org 2009-03-27 22:28 --- Subject: Bug 38034 Author: hjl Date: Fri Mar 27 22:28:20 2009 New Revision: 145135 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145135 Log: gcc/ 2009-03-27 H.J. Lu hongjiu...@intel.com Jakub Jelinek ja...@redhat.com PR target/38034 * config/ia64/sync.md (cmpxchg_rel_mode): Replace input gr_register_operand with gr_reg_or_0_operand. (cmpxchg_rel_di): Likewise. (sync_lock_test_and_setmode): Likewise. gcc/testsuite/ 2009-03-27 H.J. Lu hongjiu...@intel.com PR target/38034 * gcc.target/ia64/sync-1.c: New. Added: trunk/gcc/testsuite/gcc.target/ia64/sync-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/ia64/sync.md trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38034
[Bug c/39323] MAX_OFILE_ALIGNMENT in elfos.h is too big
--- Comment #4 from hjl at gcc dot gnu dot org 2009-03-27 22:33 --- Subject: Bug 39323 Author: hjl Date: Fri Mar 27 22:33:16 2009 New Revision: 145136 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145136 Log: gcc/ 2009-03-27 H.J. Lu hongjiu...@intel.com PR c/39323 * c-common.c (handle_aligned_attribute): Properly check alignment overflow. Use (1U i) instead of (1 i). * emit-rtl.c (get_mem_align_offset): Use unsigned int for align. * expr.h (get_mem_align_offset): Updated. * tree.h (tree_decl_common): Change align to unsigned int and move it before pointer_alias_set. gcc/ada/ 2009-03-27 H.J. Lu hongjiu...@intel.com PR c/39323 * gcc-interface/utils.c (create_field_decl): Use unsigned int on bit_align. gcc/testsuite/ 2009-03-27 H.J. Lu hongjiu...@intel.com PR c/39323 * gcc.dg/pr39323-1.c: New. * gcc.dg/pr39323-2.c: Likewise. * gcc.dg/pr39323-3.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/pr39323-1.c trunk/gcc/testsuite/gcc.dg/pr39323-2.c trunk/gcc/testsuite/gcc.dg/pr39323-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/ada/ChangeLog trunk/gcc/ada/gcc-interface/utils.c trunk/gcc/c-common.c trunk/gcc/emit-rtl.c trunk/gcc/expr.h trunk/gcc/testsuite/ChangeLog trunk/gcc/tree.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39323
[Bug tree-optimization/39120] [4.2/4.3/4.4 Regression] Missed escape constraints for call results
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-03-27 22:36 --- Subject: Bug 39120 Author: rguenth Date: Fri Mar 27 22:36:33 2009 New Revision: 145137 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145137 Log: 2009-03-27 Richard Guenther rguent...@suse.de PR tree-optimization/39120 * tree-ssa-structalias.c (handle_rhs_call): Fill out return constraints. (handle_lhs_call): Process return constraints. Add escape constraints if necessary. (handle_const_call): Fill out return constraints. Make nested case more precise. Avoid consttmp if possible. (handle_pure_call): Fill out return constraints. Avoid callused if possible. (find_func_aliases): Simplify call handling. * gcc.c-torture/execute/pr39120.c: New testcase. 2009-03-27 Richard Guenther rguent...@suse.de PR tree-optimization/39120 * tree-ssa-structalias.c (do_sd_constraint): Do not use CALLUSED as a representative. (solve_graph): Do propagate CALLUSED. (handle_pure_call): Use a scalar constraint from CALLUSED for the return value. (find_what_p_points_to): CALLUSED shall not appear in poins-to solutions. * gcc.dg/torture/pta-callused-1.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr39120.c trunk/gcc/testsuite/gcc.dg/torture/pta-callused-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-structalias.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39120
[Bug middle-end/39315] Unaligned move used on aligned stack variable
--- Comment #9 from hjl at gcc dot gnu dot org 2009-03-27 22:37 --- Subject: Bug 39315 Author: hjl Date: Fri Mar 27 22:37:39 2009 New Revision: 145138 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145138 Log: gcc/ 2009-03-27 H.J. Lu hongjiu...@intel.com PR middle-end/39315 * cfgexpand.c (expand_one_stack_var_at): Change alignment limit to MAX_SUPPORTED_STACK_ALIGNMENT. gcc/testsuite/ 2009-03-27 H.J. Lu hongjiu...@intel.com PR middle-end/39315 * gcc.target/i386/pr39315-1.c: New. * gcc.target/i386/pr39315-2.c: Likewise. * gcc.target/i386/pr39315-3.c: Likewise. * gcc.target/i386/pr39315-4.c: Likewise. * gcc.target/i386/pr39315-check.c: Likewise. Added: trunk/gcc/testsuite/gcc.target/i386/pr39315-1.c trunk/gcc/testsuite/gcc.target/i386/pr39315-2.c trunk/gcc/testsuite/gcc.target/i386/pr39315-3.c trunk/gcc/testsuite/gcc.target/i386/pr39315-4.c trunk/gcc/testsuite/gcc.target/i386/pr39315-check.c Modified: trunk/gcc/ChangeLog trunk/gcc/cfgexpand.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39315
[Bug tree-optimization/39120] [4.2/4.3/4.4 Regression] Missed escape constraints for call results
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-03-27 22:41 --- Fixed for 4.5. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to work|4.1.2 |4.1.2 4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39120
[Bug fortran/39555] concat-op not allowed in STOP
--- Comment #1 from burnus at gcc dot gnu dot org 2009-03-27 23:28 --- I think it is allowed in Fortran 2008 (could also be F2003 - I don't recall). Since that Fortran version also STOP integer-expression is allowed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39555
[Bug target/35623] RTL check failure in arm_const_double_rtx
--- Comment #1 from ramana at gcc dot gnu dot org 2009-03-28 00:05 --- Since 4.4 is close to being our current release branch, it would be helpful if you could provide a testcase where you spot the ICE . It would be useful to have a preprocessed file to see why the ICE is occurring quickest. I've been bootstrapping trunk pretty regularly for arm-linux-gnueabi on the compile farm (though not building with latest libc) and haven't seen such a problem . Thanks, Ramana -- ramana at gcc dot gnu dot org changed: What|Removed |Added CC||ramana at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35623
[Bug target/35623] RTL check failure in arm_const_double_rtx
--- Comment #2 from rmansfield at qnx dot com 2009-03-28 00:16 --- Created an attachment (id=17551) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17551action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35623
[Bug fortran/39570] New: cabs and cabsf are named differently on NetBSD 5
On NetBSD 5.0, cabs and cabsf, defined in complex.h, are renames of __c99_cabs and __c99_cabsf. The build-in definitions in f95-lang.c specifically name cabs and cabsf. On NetBSD 5.0, these are provided for compatibility and emit a linker warning when linking. This causes 7000 or so tests to fail. -- Summary: cabs and cabsf are named differently on NetBSD 5 Product: gcc Version: 4.3.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aran at 100acres dot us GCC build triplet: i386-unknown-netbsdelf5.99.7 GCC host triplet: i386-unknown-netbsdelf5.99.7 GCC target triplet: i386-unknown-netbsdelf5.99.7 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39570
[Bug fortran/39570] cabs and cabsf are named differently on NetBSD 5
--- Comment #1 from aran at 100acres dot us 2009-03-28 00:22 --- Created an attachment (id=17552) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17552action=view) Grungy little patch. This is a dirty hack for NetBSD 5.x only. It is not intended to be applied to the main source. However, if you are running NetBSD 5.x and just want it fixed, here is the patch for you. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39570
[Bug fortran/39570] cabs and cabsf are named differently on NetBSD 5
--- Comment #2 from aran at 100acres dot us 2009-03-28 00:23 --- I really tried looking at Darwin's fix to the built-in problem, but that is completely beyond me. Any suggestions would be very nice. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39570
[Bug fortran/39571] New: Compiler crash with GNU MP: Cannot reallocate memory
Compiling program test print *, 2**huge(0) end program test cause gfortran to crash with: GNU MP: Cannot reallocate memory (old_size=4 new_size=268435472) f951: internal compiler error: Abort trap -- Summary: Compiler crash with GNU MP: Cannot reallocate memory Product: gcc Version: 4.3.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aran at 100acres dot us GCC build triplet: i386-unknown-netbsdelf5.99.7 GCC host triplet: i386-unknown-netbsdelf5.99.7 GCC target triplet: i386-unknown-netbsdelf5.99.7 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39571
[Bug fortran/39571] Compiler crash with GNU MP: Cannot reallocate memory
--- Comment #1 from steven at gcc dot gnu dot org 2009-03-28 00:51 --- Which version of GMP are you using? -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING GCC build triplet| i386-unknown- |i386-unknown-netbsdelf5.99.7 |netbsdelf5.99.7 | GCC host triplet| i386-unknown- |i386-unknown-netbsdelf5.99.7 |netbsdelf5.99.7 | GCC target triplet| i386-unknown- |i386-unknown-netbsdelf5.99.7 |netbsdelf5.99.7 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39571
[Bug target/39558] Bad interaction of decls named 'vector' and -maltivec vector support
--- Comment #10 from tromey at gcc dot gnu dot org 2009-03-28 01:15 --- I think this patch looks ok, assuming it works. I'd like to reiterate that all this vector stuff would probably be much cleaner if it were implemented as context-sensitive keywords in the parser. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39558
[Bug fortran/39570] cabs and cabsf are named differently on NetBSD 5
--- Comment #4 from aran at 100acres dot us 2009-03-28 01:34 --- Subject: Re: cabs and cabsf are named differently on NetBSD 5 What is beyond me is how darwin_patch_builtings gets called. It looks like it is called from rs6000.c in rs6000_init_builtins via the macro SUBTARGET_INIT_BUILTINS. i386.c doesn't appear to have this infrastructure. I am not familiar enough with gcc internals to know what the impacts might be on other platforms if I start making changes here. Also, these renames are only for NetBSD 5. How do I detect the os version. The darwin example uses darwin_macosx_version_min. Is there a NetBSD analog? Aran On Friday 27 March 2009 18:02:48 steven at gcc dot gnu dot org wrote: --- Comment #3 from steven at gcc dot gnu dot org 2009-03-28 01:02 --- Completely beyond you, how? What gcc does for darwin (and this is a hack, mind you), is basically replace the standard C99 builtins with darwin-specific ones. You have to do the same for NetBSD. See the following files in gcc/config/: * darwin.c * darwin-ppc-ldouble-patch.def The code in darwin_patch_builtin() changes the assembler name of the builtin function to a custom, darwin-specific version. E.g. cabsl has a PATCH_BUILTIN defines, so its DECL_NAME is the normal cabls name but its assembler name becomes _cabsl_$LDBL128. You need to do something similar (but probably less ugly) for NetBSD to make this work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39570
[Bug fortran/39571] Compiler crash with GNU MP: Cannot reallocate memory
--- Comment #4 from kargl at gcc dot gnu dot org 2009-03-28 03:02 --- (In reply to comment #3) I chased this to airth.c line 1054: mpz_pow_ui (result-value.integer, op1-value.integer, power); The variable power is 268435472. On FreeBSD I get REMOVE:kargl[6] gfc4x -o z a.f90 a.f90:2.12: print *, 2**huge(0) 1 Error: Arithmetic overflow at (1) REMOVE:kargl[7] gfc43 -o z a.f90 a.f90:2.12: print *, 2**huge(0) 1 Error: Arithmetic overflow at (1) REMOVE:kargl[8] REMOVE:kargl[8] gfc4x --version GNU Fortran (GCC) 4.4.0 20090308 (experimental) [trunk revision 140508] REMOVE:kargl[9] gfc43 --version GNU Fortran (GCC) 4.3.3 20081120 (prerelease) REMOVE:kargl[11] pkg_info | grep gmp libgmp-4.2.4A free library for arbitrary precision arithmetic REMOVE:kargl[12] pkg_info | grep mpfr mpfr-2.4.1 A library for multiple-precision floating-point computation Do your gmp/mpfr libraries pass their testsuites? Do you have more than one version of one of these libraries installed. The error message indicates that gmp is broken or perhaps NetBSD's malloc implementation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39571
[Bug fortran/39555] concat-op not allowed in STOP
--- Comment #2 from kargl at gcc dot gnu dot org 2009-03-28 03:40 --- (In reply to comment #1) I think it is allowed in Fortran 2008 (could also be F2003 - I don't recall). Since that Fortran version also STOP integer-expression is allowed. It is not allowed in F2003. 8.4 STOP statement R849 stop-stmt is STOP [ stop-code ] R850 stop-code is scalar-char-constant or digit [ digit [ digit [ digit [ digit ] ] ] ] The pdf I have marked as F2008 also contains the above text. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39555
[Bug fortran/39571] Compiler crash with GNU MP: Cannot reallocate memory
--- Comment #5 from aran at 100acres dot us 2009-03-28 04:46 --- gmp-4.2.4 passes all test. mpfr-2.4.0 pass all except the tsprintf tests where my version returns 1.899347461279296875e+07 and the test expects 1,899347461279296875e+07 (notice the decimal point is a period instead of a comma). Considering that gmp is being told to raise 2 to the 268435472nd power, I don't think any system's allocator would work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39571
[Bug fortran/39571] Compiler crash with GNU MP: Cannot reallocate memory
--- Comment #6 from kargl at gcc dot gnu dot org 2009-03-28 05:21 --- (In reply to comment #5) Considering that gmp is being told to raise 2 to the 268435472nd power, I don't think any system's allocator would work. See my first post. FreeBSD seems to handle it. But, there is something wrong on your OS becuase huge(0) isn't 268435472. REMOVE:kargl[58] cat b.f90 print*, huge(0) end REMOVE:kargl[60] gfc4x -o z b.f90 REMOVE:kargl[61] ./z 2147483647 NetBSD seems to be using jemalloc. which is the memory allocator from FreeBSD. Perhaps, your memory is defective. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39571
[Bug rtl-optimization/39510] [avr] missed optimisation with IO read and register variables
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-03-28 05:22 --- This might be the case hard registers are not always copy propogated except into inline-asm. Can you provide the preprocessed source? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|target |rtl-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39510
[Bug rtl-optimization/39510] [avr] missed optimisation with IO read and register variables
--- Comment #5 from k dot kosciuszkiewicz+gcc at gmail dot com 2009-03-28 05:55 --- Created an attachment (id=17553) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17553action=view) Preprocessed source of test case Created with avr-gcc -v -save-temps -mmcu=attiny13 -Os -c test.c -o test.o -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39510
