[Bug bootstrap/41771] Bootstrap with Sun Studio 12.1 fails

[ghazi at gcc dot gnu dot org]

--- Comment #9 from ghazi at gcc dot gnu dot org  2009-11-05 02:55 ---
(In reply to comment #8)
> > Say I have a silly question, how is gmp.h getting pulled into gcc.c in the
> > first place?  It's supposed to come in via real.h which should only get
> > included by middle-end files linking with real.o ...

So the sequence is gcc.c includes flags.h which includes real.h.  That last
include was introduced by this patch:
http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00716.html

IMHO, flags.h should not include real.h if things like gcc.c will include it
and not link against real.o and -lgmp etc.  But I don't know which if any
targets now depend on this include.  I tried x86_64-linux-gnu and I was able to
link xgcc and cc1.  But some other target may have a problem.

Perhaps Ulrich can explain why he chose to add that include so we can see if
there's another way to accomplish the goal.


-- 

ghazi at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||uweigand at gcc dot gnu dot
   ||org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41771

[Bug libstdc++/38875] parallel fill and copy in the parallel version of libstdc++

[bkoz at gcc dot gnu dot org]

--- Comment #9 from bkoz at gcc dot gnu dot org  2009-11-05 02:52 ---

Yes, of course. Just providing the framework, since that was a bit tricky.

I should add all the steps here to the parallel mode docs to make this less
confusing for people trying to experiment.

best,
benjamin


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38875

[Bug c/41946] New: tree-vrp eliminates needed conditioanl

[kevfox at cisco dot com]

# 1 "strcmp.c"
# 1 ""
# 1 ""
# 1 "strcmp.c"
int strcmp (const char *, const char *);

int
strcmp (const char *s1, const char *s2)
{

if ((!s1 && s2) || (s1 && !s2))
return (int) (s1 - s2);

if (s1 == s2)
return 0;

while (*s1 == *s2++)
if (*s1++ == '\0')
 return 0;

return (*(unsigned char *)s1 - *(unsigned char *)--s2);
}

The first conditional is eliminated causing a crash when a pointer is null.
Code is correct when -fno-tree-vrp is specified.

Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.1-4ubuntu8'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch --enable-linker-build-id --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
--enable-targets=all --disable-werror --with-arch-32=i486 --with-tune=generic
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu8)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-c' '-mtune=generic'
'-march=i486'
 /usr/lib/gcc/i486-linux-gnu/4.4.1/cc1 -E -quiet -v strcmp.c
-D_FORTIFY_SOURCE=2 -mtune=generic -march=i486 -O3 -fpch-preprocess
-fstack-protector -o strcmp.i
ignoring nonexistent directory "/usr/local/include/i486-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/i486-linux-gnu/4.4.1/../../../../i486-linux-gnu/include"
ignoring nonexistent directory "/usr/include/i486-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/lib/gcc/i486-linux-gnu/4.4.1/include
 /usr/lib/gcc/i486-linux-gnu/4.4.1/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-c' '-mtune=generic'
'-march=i486'
 /usr/lib/gcc/i486-linux-gnu/4.4.1/cc1 -fpreprocessed strcmp.i -quiet -dumpbase
strcmp.c -mtune=generic -march=i486 -auxbase strcmp -O3 -version
-fstack-protector -o strcmp.s
GNU C (Ubuntu 4.4.1-4ubuntu8) version 4.4.1 (i486-linux-gnu)
compiled by GNU C version 4.4.1, GMP version 4.3.1, MPFR version
2.4.1-p2.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 293503c4ddf766b61fc5ff6a5ff38cdc
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-c' '-mtune=generic'
'-march=i486'
 as -V -Qy -o strcmp.o strcmp.s
GNU assembler version 2.20 (i486-linux-gnu) using BFD version (GNU Binutils for
Ubuntu) 2.20
COMPILER_PATH=/usr/lib/gcc/i486-linux-gnu/4.4.1/:/usr/lib/gcc/i486-linux-gnu/4.4.1/:/usr/lib/gcc/i486-linux-gnu/:/usr/lib/gcc/i486-linux-gnu/4.4.1/:/usr/lib/gcc/i486-linux-gnu/:/usr/lib/gcc/i486-linux-gnu/4.4.1/:/usr/lib/gcc/i486-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/i486-linux-gnu/4.4.1/:/usr/lib/gcc/i486-linux-gnu/4.4.1/:/usr/lib/gcc/i486-linux-gnu/4.4.1/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/i486-linux-gnu/4.4.1/../../../:/lib/:/usr/lib/:/usr/lib/i486-linux-gnu/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-c' '-mtune=generic'
'-march=i486'


-- 
   Summary: tree-vrp eliminates needed conditioanl
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kevfox at cisco dot com
  GCC host triplet: i486-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41946

[Bug middle-end/41924] graphite miscompiles aermod

[lifeng at gcc dot gnu dot org]

--- Comment #2 from lifeng at gcc dot gnu dot org  2009-11-05 02:38 ---
(In reply to comment #1)
> What are the options that you used to produce this?
> I am not able to reproduce the failing clast with -O2, nor with -O3 with the
> current graphite branch.

I produce this with -O2. It seems I use the wrong version of cloog-ppl.
I'll check this later.


-- 

lifeng at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||lifeng at gcc dot gnu dot
   ||org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41924

[Bug libstdc++/38875] parallel fill and copy in the parallel version of libstdc++

[paolo dot carlini at oracle dot com]

--- Comment #8 from paolo dot carlini at oracle dot com  2009-11-05 02:33 
---
Cool. Now it would be nice to benchmark it a bit, somehow, a version of it with
the actual code not commented out, I mean ;)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38875

[Bug libstdc++/38875] parallel fill and copy in the parallel version of libstdc++

[bkoz at gcc dot gnu dot org]

--- Comment #7 from bkoz at gcc dot gnu dot org  2009-11-05 02:16 ---

Here's how parallel fill would look, based on Johannes patch.

-benjamin


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38875

[Bug libstdc++/38875] parallel fill and copy in the parallel version of libstdc++

[bkoz at gcc dot gnu dot org]

--- Comment #6 from bkoz at gcc dot gnu dot org  2009-11-05 02:15 ---
Created an attachment (id=18970)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18970&action=view)
patch for parallel fill and fill_n


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38875

[Bug c/27065] [4.3/4.4/4.5 Regression] error: array type has incomplete element type

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2009-11-05 01:08 ---
Actually I take that back, C99 explicitly says arrays cannot be an incomplete
type.  See 6.7.5.2/1.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27065

[Bug bootstrap/41709] Failing bootstrap in stage 2 while building Ada + C

[anhvofrcaus at gmail dot com]

--- Comment #7 from anhvofrcaus at gmail dot com  2009-11-05 01:00 ---
I did look at it. However, I do not understand it thinks ./a.exe has bad file
number as shown in the fragment of the /intl/config.log. The question is how
can I fix this problem? Thanks.


[...]
configure:2947:  /c/Gcc/Build-Test/./prev-gcc/xgcc
-B/c/Gcc/Build-Test/./prev-gcc/ -B/usr/local/i686-pc-mingw32/bin/
-L/c/Gcc/Build-Test/i686-pc-mingw32/winsup/mingw
-L/c/Gcc/Build-Test/i686-pc-mingw32/winsup/w32api/lib -isystem
/c/Gcc/gcc-4.5-20091015/winsup/mingw/include -isystem
/c/Gcc/gcc-4.5-20091015/winsup/w32api/include -B/usr/local/i686-pc-mingw32/bin/
-B/usr/local/i686-pc-mingw32/lib/ -isystem /usr/local/i686-pc-mingw32/include
-isystem /usr/local/i686-pc-mingw32/sys-include-qversion >&5
xgcc.exe: unrecognized option '-qversion'
xgcc.exe: no input files
configure:2958: $? = 1
configure:2978: checking for C compiler default output file name
configure:3000:  /c/Gcc/Build-Test/./prev-gcc/xgcc
-B/c/Gcc/Build-Test/./prev-gcc/ -B/usr/local/i686-pc-mingw32/bin/
-L/c/Gcc/Build-Test/i686-pc-mingw32/winsup/mingw
-L/c/Gcc/Build-Test/i686-pc-mingw32/winsup/w32api/lib -isystem
/c/Gcc/gcc-4.5-20091015/winsup/mingw/include -isystem
/c/Gcc/gcc-4.5-20091015/winsup/w32api/include -B/usr/local/i686-pc-mingw32/bin/
-B/usr/local/i686-pc-mingw32/lib/ -isystem /usr/local/i686-pc-mingw32/include
-isystem /usr/local/i686-pc-mingw32/sys-include-g -O2 -D__USE_MINGW_ACCESS
-Wno-pedantic-ms-format -gtoggleconftest.c  >&5
Warning: .drectve `-aligncomm:___CTOR_LIST__,2 ' unrecognized
Warning: .drectve `-aligncomm:___DTOR_LIST__,2' unrecognized
configure:3004: $? = 0
configure:3041: result: a.exe
configure:3057: checking whether the C compiler works
configure:3066: ./a.exe
/c/Gcc/gcc-4.5-20091015/intl/configure: line 3068: ./a.exe: Bad file number
configure:3070: $? = 126
configure:3077: error: in `/c/Gcc/Build-Test/intl':
configure:3081: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41709

[Bug c/27065] [4.3/4.4/4.5 Regression] error: array type has incomplete element type

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2009-11-05 00:45 ---
6.7.5.3/4 says:
After adjustment, the parameters in the a parameter type list in a function
declarator that is part of a definition of that function shall not have
incomplete type.

But the adjustment is the decaying from [] to * which is mentioned in
6.7.5.3/7.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||rejects-valid
   Last reconfirmed|-00-00 00:00:00 |2009-11-05 00:45:37
   date||
Summary|error: array type has   |[4.3/4.4/4.5 Regression]
   |incomplete element type |error: array type has
   ||incomplete element type
   Target Milestone|--- |4.3.5


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27065

[Bug c/27065] error: array type has incomplete element type

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2009-11-05 00:42 ---
Actually this is valid C99 code after all.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27065

[Bug c++/35067] [4.3/4.4/4.5 Regression] multiple definition of virtual thunk

[vincent dot riviere at freesbee dot fr]

--- Comment #16 from vincent dot riviere at freesbee dot fr  2009-11-04 
23:41 ---
Hello, I've just tested with GCC trunk, it seems to be fixed !
Thanks, Jason.


-- 

vincent dot riviere at freesbee dot fr changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35067

[Bug c++/10291] error referencing a static local from a local struct in template code

[jason at gcc dot gnu dot org]

--- Comment #8 from jason at gcc dot gnu dot org  2009-11-04 23:27 ---
The problem is that we use a local_specializations hash table to look up locals
when instantiating a template, and i isn't in bar()'s local_specializations, so
we fail.  We need to make static locals their own temploid.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10291

[Bug rtl-optimization/41903] [4.5 Regression] Segmentation fault in bitmap_clear

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-11-04 23:24 ---
I'm reducing this one for a C testcase.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41903

[Bug c++/36912] [4.3/4.4/4.5 regression] ICE with "-frounding-math -g"

[jason at gcc dot gnu dot org]

--- Comment #13 from jason at gcc dot gnu dot org  2009-11-04 23:13 ---
Subject: Bug 36912

Author: jason
Date: Wed Nov  4 23:13:23 2009
New Revision: 153921

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153921
Log:
PR c++/36912
* varasm.c (initializer_constant_valid_p): A PLUS_EXPR
or MINUS_EXPR of REAL_TYPE is not a valid constant initializer.
(output_constant): Avoid crash after error.

Added:
trunk/gcc/testsuite/g++.dg/init/static-init2.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/varasm.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36912

[Bug rtl-optimization/41903] [4.5 Regression] Segmentation fault in bitmap_clear

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-11-04 22:45:09
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41903

[Bug c++/41884] diagnostics: error vs. context

[jason at gcc dot gnu dot org]

--- Comment #12 from jason at gcc dot gnu dot org  2009-11-04 22:36 ---
Paolo's point about -Wfatal-errors makes me inclined to leave this alone.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41884

[Bug c++/8858] Gcc "rebinds" template member names.

[jason at gcc dot gnu dot org]

--- Comment #5 from jason at gcc dot gnu dot org  2009-11-04 22:34 ---
14.7.1 [temp.local]

Like normal (non-template) classes, class templates have an injected-class-name
(Clause 9). The injected-class-name can be used with or without a
template-argument-list. When it is used without a template-argument-list, it is
equivalent to the injected-class-name followed by the template-parameters of
the class template enclosed in <>. When it is used with a
template-argument-list, it refers to the specified class template
specialization, which could be the current specialization or another
specialization.

So within foo::bar, the name "bar" refers to foo::bar, and G++ is correct.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8858

[Bug c++/39413] static_assert and SFINAE

[jason at gcc dot gnu dot org]

--- Comment #8 from jason at gcc dot gnu dot org  2009-11-04 22:31 ---
Fixed for 4.5.0.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39413

[Bug c++/39413] static_assert and SFINAE

[jason at gcc dot gnu dot org]

--- Comment #7 from jason at gcc dot gnu dot org  2009-11-04 22:29 ---
Subject: Bug 39413

Author: jason
Date: Wed Nov  4 22:29:35 2009
New Revision: 153920

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153920
Log:
PR c++/39413
* search.c (lookup_base): Don't complete_type (base).

Added:
trunk/gcc/testsuite/g++.dg/template/overload11.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/search.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/template/nested3.C


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39413

[Bug rtl-optimization/41944] ICE while compiling

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-11-04 22:25 ---
Likely a dup of PR41891.

(gdb) bt
#0  0x081bc9a2 in bitmap_clear (head=0x74)
at /home/richard/src/trunk/gcc/bitmap.c:297
#1  0x0846602c in free_loop_data (loop=0xb3470bb0)
at /home/richard/src/trunk/gcc/loop-invariant.c:1568
#2  0x084673a3 in move_loop_invariants ()
at /home/richard/src/trunk/gcc/loop-invariant.c:1906
#3  0x08462650 in rtl_move_loop_invariants ()
at /home/richard/src/trunk/gcc/loop-init.c:254
#4  0x084bc43d in execute_one_pass (pass=0x8d72280)


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn||41891
  Component|c   |rtl-optimization


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41944

[Bug middle-end/41945] [4.5 regression] tree_check failed

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|c   |middle-end
  GCC build triplet|i586-suse-linux and x86_64  |
   GCC host triplet|i586-suse-linux and x86_64  |
 GCC target triplet|i586-suse-linux and x86_64  |i586-suse-linux, x86_64-*-*
   Target Milestone|--- |4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41945

[Bug c/41945] [4.5 regression] tree_check failed

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-11-04 22:19 ---
Likely a dup of PR41935


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn||41935


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41945

[Bug c/41945] [4.5 regression] tree_check failed

[hideaki at sogetthis dot com]

--- Comment #1 from hideaki at sogetthis dot com  2009-11-04 22:16 ---
Created an attachment (id=18969)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18969&action=view)
testcase


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41945

[Bug c/41945] New: [4.5 regression] tree_check failed

[hideaki at sogetthis dot com]

While compiling kernel parts, I got an internal compile error. Testfile is
attached.

$ gcc-4.5 -c ch.i -o ch.o
ch.i: In function ‘nf_ct_tuplehash_to_ctrack’:
ch.i:19:65: internal compiler error: tree check: expected integer_cst, have
nop_expr in int_cst_value, at tree.c:9619
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

gcc45 is from opensuse/repositories:/home/rguenther/openSUSE_11.1/i586.
The previously available RPM (20091029) did not have this issue.

GOOD: gcc version 4.5.0 20091029 (experimental) [trunk revision 153698] (SUSE
Linux) 

BAD:
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i586-suse-linux/4.5/lto-wrapper
Target: i586-suse-linux
Configured with: ../configure --prefix=/usr --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=yes
--with-gxx-include-dir=/usr/include/c++/4.5 --enable-ssp --disable-libssp
--disable-plugin --with-bugurl=http://bugs.opensuse.org/
--with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap
--with-slibdir=/lib --with-system-zlib --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --program-suffix=-4.5
--enable-linux-futex --without-system-libunwind --enable-gold
--with-arch-32=i586 --with-tune=generic --build=i586-suse-linux
Thread model: posix
gcc version 4.5.0 20091103 (experimental) [trunk revision 153845] (SUSE Linux)


-- 
   Summary: [4.5 regression] tree_check failed
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hideaki at sogetthis dot com
 GCC build triplet: i586-suse-linux and x86_64
  GCC host triplet: i586-suse-linux and x86_64
GCC target triplet: i586-suse-linux and x86_64


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41945

[Bug c++/36912] [4.3/4.4/4.5 regression] ICE with "-frounding-math -g"

[jason at gcc dot gnu dot org]

-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-09-20 20:09:14 |2009-11-04 22:15:15
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36912

[Bug c/41944] ICE while compiling

[fijall at gmail dot com]

--- Comment #1 from fijall at gmail dot com  2009-11-04 22:01 ---
Since attachments are far too small, the testcase is available for download
here:
http://codespeak.net/~fijal/testcase.i


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41944

[Bug c/41944] New: ICE while compiling

[fijall at gmail dot com]

my output looks roughly like this:

fi...@bigdog24vm1ub90432:/tmp/usession-trunk-57/testing_1$ gcc -v -save-temps
-O1 -g testcase.i
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/fijal/b/libexec/gcc/i686-pc-linux-gnu/4.5.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ./configure --prefix=/home/fijal/b
Thread model: posix
gcc version 4.5.0 20091024 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O1' '-g' '-mtune=generic'
 /home/fijal/b/libexec/gcc/i686-pc-linux-gnu/4.5.0/cc1 -fpreprocessed
testcase.i -quiet -dumpbase testcase.i -mtune=generic -auxbase testcase -g -O1
-version -o testcase.s
GNU C (GCC) version 4.5.0 20091024 (experimental) (i686-pc-linux-gnu)
compiled by GNU C version 4.5.0 20091024 (experimental), GMP version
4.2.4, MPFR version 2.4.0
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C (GCC) version 4.5.0 20091024 (experimental) (i686-pc-linux-gnu)
compiled by GNU C version 4.5.0 20091024 (experimental), GMP version
4.2.4, MPFR version 2.4.0
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: dc2bdfc20ec8a4ccd50ddee7af3a5500
testcase.i: In function ‘pypy_g_ll_time_ll_time_time’:
testcase.i:122051:2: warning: passing argument 2 of ‘gettimeofday’ from
incompatible pointer type
testcase.i:1200:12: note: expected ‘struct timezone * __restrict__’ but
argument is of type ‘char *’
testcase.i: In function ‘pypy_g_ll_math_ll_math_frexp’:
testcase.i:346924:2: warning: passing argument 2 of ‘frexp’ from
incompatible pointer type
testcase.i:9318:15: note: expected ‘int *’ but argument is of type ‘long
int *’
testcase.i: In function ‘pypy_g_dispatch_bytecode__AccessDirect_None’:
testcase.i:219703:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: ICE while compiling
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fijall at gmail dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41944

[Bug ada/41929] 64-bit null_pointer_deref1 gnat.dg test consumes all available memory

[rguenther at suse dot de]

--- Comment #7 from rguenther at suse dot de  2009-11-04 21:51 ---
Subject: Re:  64-bit null_pointer_deref1 gnat.dg test consumes
 all available memory

On Wed, 4 Nov 2009, rguenther at suse dot de wrote:

> --- Comment #6 from rguenther at suse dot de  2009-11-04 13:12 ---
> Subject: Re:  64-bit null_pointer_deref1 gnat.dg test consumes
>  all available memory
> 
> On Wed, 4 Nov 2009, ebotcazou at gcc dot gnu dot org wrote:
> 
> > --- Comment #5 from ebotcazou at gcc dot gnu dot org  2009-11-04 11:57 
> > ---
> > > Running target unix//-m32
> > > FAIL: gnat.dg/null_pointer_deref1.adb execution test
> > > 
> > > the 64bit variant passes.
> > > 
> > > the log just states
> > > 
> > > raised STORAGE_ERROR : stack overflow (or erroneous memory access)
> > 
> > OK, thanks for the clarification.  Which kernel do you run?  Does the 
> > following
> > patch help?
> 
> I run 2.6.16.42-0.6-smp, that is some old SLES10 kernel.
> 
> I'll test if the patch helps.

It fixed the failure for me.

Richard.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41929

[Bug middle-end/20548] [4.3/4.4/4.5 regression] ACATS c52103x c52104x c52104y segfault

[ebotcazou at gcc dot gnu dot org]

--- Comment #40 from ebotcazou at gcc dot gnu dot org  2009-11-04 21:49 
---
Tentatively on mainline.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|4.3.5   |4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20548

[Bug target/10127] -fstack-check let's program crash

[ebotcazou at gcc dot gnu dot org]

--- Comment #10 from ebotcazou at gcc dot gnu dot org  2009-11-04 21:46 
---
Subject: Bug 10127

Author: ebotcazou
Date: Wed Nov  4 21:45:54 2009
New Revision: 153918

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153918
Log:
PR target/10127
PR ada/20548
* config/i386/i386.md (probe_stack_range): New expander.
(logical operation peepholes): Do not split stack checking probes.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/ada/acats/norun.lst
trunk/gcc/testsuite/ada/acats/run_acats


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10127

[Bug middle-end/20548] [4.3/4.4/4.5 regression] ACATS c52103x c52104x c52104y segfault

[ebotcazou at gcc dot gnu dot org]

--- Comment #39 from ebotcazou at gcc dot gnu dot org  2009-11-04 21:46 
---
Subject: Bug 20548

Author: ebotcazou
Date: Wed Nov  4 21:45:54 2009
New Revision: 153918

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153918
Log:
PR target/10127
PR ada/20548
* config/i386/i386.md (probe_stack_range): New expander.
(logical operation peepholes): Do not split stack checking probes.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/ada/acats/norun.lst
trunk/gcc/testsuite/ada/acats/run_acats


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20548

[Bug c++/39413] static_assert and SFINAE

[jason at gcc dot gnu dot org]

--- Comment #6 from jason at gcc dot gnu dot org  2009-11-04 21:27 ---
This is not a SFINAE issue, the bug is that we shouldn't be instantiating
member_ptr in the first place in order to resolve the operator= overload.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-03-09 18:10:02 |2009-11-04 21:27:44
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39413

[Bug preprocessor/41943] include search path composition is bogus

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-11-04 21:19 ---
That is because the way you configured GCC with
--with-sysroot=/mingw/test/sysroot

Since that is true, it adds the sysroot to C:/MinGW/test/prefix/include.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41943

[Bug preprocessor/41943] New: include search path composition is bogus

[rainer at emrich-ebersheim dot de]

$prefix/include isn't searched!

$ /mingw/test/prefix/bin/gcc -v -E -o test.ii test.c
Using built-in specs.
COLLECT_GCC=C:\MinGW\test\prefix\bin\gcc.exe
COLLECT_LTO_WRAPPER=c:/mingw/test/prefix/bin/../libexec/gcc/i686-w64-mingw32/4.5.0/lto-wrapper.exe
Target: i686-w64-mingw32
Configured with: ../../../../../../src/gcc-4.5.0/configure
--prefix=/mingw/test/prefix --with-sysroot=/mingw/test/sysroot
--with-gmp=/mingw/test/prefix --with-mpfr=/mingw/test/prefix
--with-mpc=/mingw/test/prefix --with-gnu-as
--with-as=/mingw/test/prefix/bin/as.exe --with-gnu-ld
--with-ld=/mingw/test/prefix/bin/ld.exe --enable-bootstrap
--enable-threads=win32 --enable-languages=c --enable-checking=release
--disable-werror --disable-multilib --build=i686-w64-mingw32
Thread model: win32
gcc version 4.5.0 20091027 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-E' '-o' 'test.ii' '-mtune=generic'
 c:/mingw/test/prefix/bin/../libexec/gcc/i686-w64-mingw32/4.5.0/cc1.exe -E
-quiet -v -iprefix c:\mingw\test\prefix\bin\../lib/gcc/i686-w64-mingw32/4.5.0/
test.c -o test.ii -mtune=generic
ignoring nonexistent directory
"C:/MinGW/test/sysrootC:/MinGW/test/prefix/include"
ignoring duplicate directory
"c:/mingw/test/prefix/lib/gcc/../../lib/gcc/i686-w64-mingw32/4.5.0/include"
ignoring duplicate directory
"c:/mingw/test/prefix/lib/gcc/../../lib/gcc/i686-w64-mingw32/4.5.0/include-fixed"
ignoring nonexistent directory
"c:/mingw/test/prefix/lib/gcc/../../i686-w64-mingw32/include"
#include "..." search starts here:
#include <...> search starts here:
 c:\mingw\test\prefix\bin\../lib/gcc/i686-w64-mingw32/4.5.0/include
 c:\mingw\test\prefix\bin\../lib/gcc/i686-w64-mingw32/4.5.0/include-fixed
 C:/MinGW/test/sysroot/mingw/include
End of search list.
COMPILER_PATH=c:/mingw/test/prefix/bin/../libexec/gcc/i686-w64-mingw32/4.5.0/;c:/mingw/test/prefix/bin/../libexec/gcc/;c:/mingw/test/prefix/bin/../lib/gcc/i686-w64-mingw32/4.5.0/../../../../i686-w64-mingw32/bin/
LIBRARY_PATH=c:/mingw/test/prefix/bin/../lib/gcc/i686-w64-mingw32/4.5.0/;c:/mingw/test/prefix/bin/../lib/gcc/;c:/mingw/test/prefix/bin/../lib/gcc/i686-w64-mingw32/4.5.0/../../../../lib32/;c:/mingw/test/prefix/bin/../lib/gcc/i686-w64-mingw32/4.5.0/../../../../i686-w64-mingw32/lib/;c:/mingw/test/prefix/bin/../lib/gcc/i686-w64-mingw32/4.5.0/../../../;C:/MinGW/test/sysroot/mingw/lib/
COLLECT_GCC_OPTIONS='-v' '-E' '-o' 'test.ii' '-mtune=generic'

The interesting line is:
ignoring nonexistent directory
"C:/MinGW/test/sysrootC:/MinGW/test/prefix/include"

Here the sysroot path is stitched together with $prefix/include, which is
clearly wrong!

Rainer


-- 
   Summary: include search path composition is bogus
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rainer at emrich-ebersheim dot de
 GCC build triplet: *-*-mingw32
  GCC host triplet: *-*-mingw32
GCC target triplet: *-*-mingw32


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41943

[Bug c++/21514] [DR 488] templates and anonymous enum

[jason at gcc dot gnu dot org]

--- Comment #22 from jason at gcc dot gnu dot org  2009-11-04 20:40 ---
*** Bug 20589 has been marked as a duplicate of this bug. ***


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||caolanm at redhat dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21514

[Bug c++/20589] [DR 488] error: '' is/uses anonymous type'

[jason at gcc dot gnu dot org]

--- Comment #22 from jason at gcc dot gnu dot org  2009-11-04 20:40 ---
This was fixed in 4.0.2.

*** This bug has been marked as a duplicate of 21514 ***


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|SUSPENDED   |RESOLVED
 Resolution||DUPLICATE
   Target Milestone|--- |4.0.2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20589

[Bug fortran/41873] [OOP] Bogus Error: ABSTRACT INTERFACE must not be referenced...

[janus at gcc dot gnu dot org]

--- Comment #5 from janus at gcc dot gnu dot org  2009-11-04 20:39 ---
(In reply to comment #2)
> While one might not access (type)%dot_g_g as "dot_g_g" is deferred, using
> (class)%dot_g_g is valid.  (And using (type)%dot_g_g is not possible as one
> cannot use "type(abstract_t)"; thus it might be enough to relax the check.)

It might be okay for type-bound procedures. However, this check should also
catch the usage of simple abstract procedures, i.e. when adding the following
to the test case in comment #4:

print *, dot()

This is illegal of course, and is not caught without the check in
resolve_function.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41873

[Bug c++/41884] diagnostics: error vs. context

[paolo dot carlini at oracle dot com]

--- Comment #11 from paolo dot carlini at oracle dot com  2009-11-04 20:18 
---
(In reply to comment #10)
> At least that way you'll know the error is always at the top, instead of at
> some point between the end of the compile line and the next prompt.

Yes, but is this true with -Wfatal-errors? Maybe I should just take the time to
experiment a bit more, but the reason why I posted my mumblings last night, is
that it occurred to me that probably it's simply not true with -Wfatal-errors,
that is, the single error is always exactly the last printed thing, close to
the new prompt. For example, take the messages in your Comment #7, and imagine
for a moment each is 50 lines, not uncommon with templates, which one would be
more quickly informative in your ~30 lines window? That said, I agree there are
also reasons to reason: first print the error, and then all the additional
details, this strategy being very effective for short overall messages, fitting
in the window. However, I don't think all the users of GCC can agree, or in
large majority at least, about which one is best. In conclusion, my current
idea is: either have a switch to choose case by case, or give the issue a bit
more thought before changing a very old behavior.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41884

[Bug c++/27560] template function not recognized when invoked with enum defined in function

[jason at gcc dot gnu dot org]

--- Comment #10 from jason at gcc dot gnu dot org  2009-11-04 20:16 ---
In 4.5 this will compile with -std=c++0x.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27560

[Bug fortran/41873] [OOP] Bogus Error: ABSTRACT INTERFACE must not be referenced...

[janus at gcc dot gnu dot org]

--- Comment #4 from janus at gcc dot gnu dot org  2009-11-04 20:13 ---
Reduced test case:


  implicit none

  type, abstract :: inner_product_class
  contains
procedure(dot), public, nopass, deferred :: dot_g_g
  end type

  abstract interface
real function dot ()
end function
  end interface

contains

  subroutine cg (ipmin)
class(inner_product_class) :: ipmin
print *, ipmin%dot_g_g ()
  end subroutine

end


Triggers the same error message as comment #0, which, in addition to being
bogus, appears twice.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41873

[Bug c++/35067] [4.3/4.4/4.5 Regression] multiple definition of virtual thunk

[jason at gcc dot gnu dot org]

--- Comment #15 from jason at gcc dot gnu dot org  2009-11-04 20:10 ---
Fixed for 4.3.5, 4.4.3, 4.5.0.  Vincent, can you verify that it works with the
current sources?


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35067

[Bug c++/35067] [4.3/4.4/4.5 Regression] multiple definition of virtual thunk

[jason at gcc dot gnu dot org]

--- Comment #14 from jason at gcc dot gnu dot org  2009-11-04 20:08 ---
Subject: Bug 35067

Author: jason
Date: Wed Nov  4 20:08:44 2009
New Revision: 153913

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153913
Log:
PR c++/35067
* method.c (use_thunk): Check DECL_WEAK as well as
DECL_ONE_ONLY.

Added:
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/abi/thunk5.C
Modified:
branches/gcc-4_3-branch/gcc/cp/ChangeLog
branches/gcc-4_3-branch/gcc/cp/method.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35067

[Bug c++/35067] [4.3/4.4/4.5 Regression] multiple definition of virtual thunk

[jason at gcc dot gnu dot org]

--- Comment #13 from jason at gcc dot gnu dot org  2009-11-04 19:56 ---
Subject: Bug 35067

Author: jason
Date: Wed Nov  4 19:55:56 2009
New Revision: 153912

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153912
Log:
PR c++/35067
* method.c (use_thunk): Check DECL_WEAK as well as
DECL_ONE_ONLY.

Added:
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/abi/thunk5.C
Modified:
branches/gcc-4_4-branch/gcc/cp/ChangeLog
branches/gcc-4_4-branch/gcc/cp/method.c
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35067

[Bug fortran/41556] Errors in applying operator/assignment to an abstract type

[janus at gcc dot gnu dot org]

--- Comment #3 from janus at gcc dot gnu dot org  2009-11-04 19:55 ---
The commit in comment #2 contains the patchlet from comment #1 and fixes the
first of the error messages in comment #0.

At this point, the test case still triggers three error messages:

c0.f90:34.14:

operand = operand*scale   ! preferred implementation
  1
Error: Operands of binary numeric operator '*' at (1) are CLASS(object)/REAL(4)
c0.f90:35.14:

operand = operand%product(scale)  ! alternate implementation
  1
Error: ABSTRACT INTERFACE 'product_interface' must not be referenced at (1)
c0.f90:35.14:

operand = operand%product(scale)  ! alternate implementation
  1
Error: ABSTRACT INTERFACE 'product_interface' must not be referenced at (1)

The last two also appear in PR 41873.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41556

[Bug c++/41884] diagnostics: error vs. context

[bkoz at gcc dot gnu dot org]

--- Comment #10 from bkoz at gcc dot gnu dot org  2009-11-04 19:53 ---

FWIW, I think even in the case that the total message (error + context) is more
than can fit at one time on the current terminal window, it is advantageous to
have the fixed length part (error) first, and then the variable length part
(context) next.

At least that way you'll know the error is always at the top, instead of at
some point between the end of the compile line and the next prompt.

-benjamin


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41884

[Bug fortran/41937] [OOP] Error in allocating derived type allocatable components

[janus at gcc dot gnu dot org]

--- Comment #5 from janus at gcc dot gnu dot org  2009-11-04 19:46 ---
Fixed with r153911. Closing.


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41937

[Bug c/41942] __attribute__ ((visibility)) weird with functions returning pointers

[joseph at codesourcery dot com]

--- Comment #2 from joseph at codesourcery dot com  2009-11-04 19:42 ---
Subject: Re:   New: __attribute__ ((visibility)) weird with
 functions returning pointers

Visibility attributes are in the nature of storage class specifiers and so 
should be placed at the start of the declaration.  The relevant 
documentation for binding of attributes is "Attribute Syntax" in the 
manual.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41942

[Bug fortran/41937] [OOP] Error in allocating derived type allocatable components

[janus at gcc dot gnu dot org]

--- Comment #4 from janus at gcc dot gnu dot org  2009-11-04 19:41 ---
Subject: Bug 41937

Author: janus
Date: Wed Nov  4 19:41:07 2009
New Revision: 153911

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153911
Log:
2009-11-04  Tobias Burnus 
Janus Weil  

PR fortran/41556
PR fortran/41937
* interface.c (gfc_check_operator_interface): Handle CLASS arguments.
* resolve.c (resolve_allocate_expr): Handle allocatable components of
CLASS variables.


2009-11-04  Janus Weil  

PR fortran/41556
PR fortran/41937
* gfortran.dg/class_11.f03: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/class_11.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/interface.c
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41937

[Bug fortran/41556] Errors in applying operator/assignment to an abstract type

[janus at gcc dot gnu dot org]

--- Comment #2 from janus at gcc dot gnu dot org  2009-11-04 19:41 ---
Subject: Bug 41556

Author: janus
Date: Wed Nov  4 19:41:07 2009
New Revision: 153911

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153911
Log:
2009-11-04  Tobias Burnus 
Janus Weil  

PR fortran/41556
PR fortran/41937
* interface.c (gfc_check_operator_interface): Handle CLASS arguments.
* resolve.c (resolve_allocate_expr): Handle allocatable components of
CLASS variables.


2009-11-04  Janus Weil  

PR fortran/41556
PR fortran/41937
* gfortran.dg/class_11.f03: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/class_11.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/interface.c
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41556

[Bug c++/17365] [DR 218] Should ADL find non-functions?

[jason at gcc dot gnu dot org]

--- Comment #13 from jason at gcc dot gnu dot org  2009-11-04 19:39 ---
Fixed for 4.5.0.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17365

[Bug c++/15882] Check for return type of overloaded operator new too early

[jason at gcc dot gnu dot org]

--- Comment #10 from jason at gcc dot gnu dot org  2009-11-04 19:37 ---
Oops, wrong PR number on that checkin.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15882

[Bug c++/15882] Check for return type of overloaded operator new too early

[jason at gcc dot gnu dot org]

--- Comment #9 from jason at gcc dot gnu dot org  2009-11-04 19:34 ---
Subject: Bug 15882

Author: jason
Date: Wed Nov  4 19:34:25 2009
New Revision: 153909

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153909
Log:
PR c++/15882
* method.c (use_thunk): Check DECL_WEAK as well as
DECL_ONE_ONLY.

Added:
trunk/gcc/testsuite/g++.dg/abi/thunk5.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/method.c
trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15882

[Bug c++/37093] [4.2/4.3 Regression] ICE with pointer to member template parameters

[dodji at gcc dot gnu dot org]

--- Comment #26 from dodji at gcc dot gnu dot org  2009-11-04 19:24 ---
Subject: Bug 37093

Author: dodji
Date: Wed Nov  4 19:23:40 2009
New Revision: 153908

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153908
Log:
Revert "Fix PR c++/37093"

This reverts commit 153841 on gcc-4_3-branch.

Removed:
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/other/ptrmem10.C
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/other/ptrmem11.C
Modified:
branches/gcc-4_3-branch/gcc/cp/ChangeLog
branches/gcc-4_3-branch/gcc/cp/pt.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37093

[Bug c/41942] __attribute__ ((visibility)) weird with functions returning pointers

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-11-04 19:07 ---
Yes it is weird but really it should be placed either before the type.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41942

[Bug lto/41932] LTO ICE when compiling ocaml trunk (incompatible type)

[bstarynk at gcc dot gnu dot org]

--- Comment #8 from bstarynk at gcc dot gnu dot org  2009-11-04 18:45 
---
(In reply to comment #7)
> With gcc trunk rev 153897 Simon Baldwin's demo.c file
>   typedef long intnat;
>   typedef intnat value;
>   void caml_darken (value v, value *p) { }
> is passing ok.
> 

No I was wrong. It crashes also. It is important to run
  gcc-trunk -flto -O2 -c -O -fPIC PR41932-demo.c
and then
  gcc-trunk -flto -O2 -shared -o /dev/null PR41932-demo.o


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41932

[Bug lto/41932] LTO ICE when compiling ocaml trunk (incompatible type)

[bstarynk at gcc dot gnu dot org]

--- Comment #7 from bstarynk at gcc dot gnu dot org  2009-11-04 18:37 
---
With gcc trunk rev 153897 Simon Baldwin's demo.c file
  typedef long intnat;
  typedef intnat value;
  void caml_darken (value v, value *p) { }
is passing ok.

But ocaml-trunk is still crashing the gcc-trunk. And it is not related to the
incompatible type warning. This has been fixed in ocaml trunk rev 9410, and
gcc-trunk still crashes when compiling it.

It is indeed related to passing both -flto -O2 & -O to the compiler.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41932

[Bug rtl-optimization/41833] vec_splat followed by vec_splat could be improved

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2009-11-04 18:37 ---
Fixed on the trunk for 4.5.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41833

[Bug rtl-optimization/41833] vec_splat followed by vec_splat could be improved

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2009-11-04 18:36 ---
Subject: Bug 41833

Author: pinskia
Date: Wed Nov  4 18:35:57 2009
New Revision: 153906

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153906
Log:
2009-11-04  Andrew Pinski  
Trevor Smigiel 

PR rtl-opt/41833
* simplify-rtx.c (simplify_binary_operation_1): Simplify vec_select of
a vec_duplicate.

2009-11-04  Andrew Pinski  

PR rtl-opt/41833
* gcc.target/powerpc/altivec-33.c: New testcase.


Added:
trunk/gcc/testsuite/gcc.target/powerpc/altivec-33.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/simplify-rtx.c
trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41833

[Bug target/41930] [4.5 regression] cc1 SEGV compiling maxval_r16.c

[ro at CeBiTec dot Uni-Bielefeld dot DE]

--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld dot DE  2009-11-04 
18:34 ---
Subject: Re:  [4.5 regression] cc1 SEGV compiling maxval_r16.c

> Unfortunately, the problem does not reproduce in such a cross compiler,
> so I'll have to either start a native reghunt or find a way to debug the
> native compiler (maybe compiling with -g without -O2 or try the stage1
> compiler if it is also affected).

I was misled by the fact that the hg mirror of trunk hasn't been updated
in almost two months, so I've been testing the wrong sources.  With svn
trunk, I can reproduce the problem:

run -std=gnu99 -O2 maxval_r16.i
Starting program: /vol/gcc/obj/gcc-reghunt/153800/gcc/cc1 -std=gnu99 -O2
maxval_r16.i
warning: Temporarily disabling breakpoints for unloaded shared library
"/usr/lib/ld.so.1"
Breakpoint 3 at 0xfeef4b00
Breakpoint 4 at 0xfef01652
 mmaxval_r16
Analyzing compilation unit
Performing interprocedural optimizations
  <>
 Assembling functions:
 mmaxval_r16
Program received signal SIGSEGV, Segmentation fault.
simplify_replace_fn_rtx (x=0x0, old_rtx=0xfee55df0, fn=0, data=0xfee5fc08) at
/vol/gcc/src/gcc-dist/gcc/simplify-rtx.c:364
(gdb) where
#0  simplify_replace_fn_rtx (x=0x0, old_rtx=0xfee55df0, fn=0, data=0xfee5fc08)
at /vol/gcc/src/gcc-dist/gcc/simplify-rtx.c:364
#1  0x0836d367 in simplify_replace_fn_rtx (x=0xfee7f030, old_rtx=0xfee55df0,
fn=0, data=0xfee5fc08) at /vol/gcc/src/gcc-dist/gcc/simplify-rtx.c:492
#2  0x0836d367 in simplify_replace_fn_rtx (x=0xfee7f018, old_rtx=0xfee55df0,
fn=0, data=0xfee5fc08) at /vol/gcc/src/gcc-dist/gcc/simplify-rtx.c:492
#3  0x0836d367 in simplify_replace_fn_rtx (x=0xfee7f00c, old_rtx=0xfee55df0,
fn=0, data=0xfee5fc08) at /vol/gcc/src/gcc-dist/gcc/simplify-rtx.c:492
#4  0x0836d6e2 in simplify_replace_rtx (x=0xfee7f00c, old_rtx=0xfee55df0,
new_rtx=0xfee5fc08) at /vol/gcc/src/gcc-dist/gcc/simplify-rtx.c:510
#5  0x082507ef in try_replace_reg (from=0xfee55df0, to=0xfee5fc08,
insn=0xfee5369c) at /vol/gcc/src/gcc-dist/gcc/gcse.c:2278
#6  0x08250c46 in constprop_register (insn=0xfee5369c, from=0xfee55df0,
to=0xfee5fc08) at /vol/gcc/src/gcc-dist/gcc/gcse.c:2511
#7  0x08251e14 in execute_rtl_cprop () at /vol/gcc/src/gcc-dist/gcc/gcse.c:2701
#8  0x082ea4b0 in execute_one_pass (pass=0x87a3240) at
/vol/gcc/src/gcc-dist/gcc/passes.c:1518
#9  0x082ea577 in execute_pass_list (pass=0x87a3240) at
/vol/gcc/src/gcc-dist/gcc/passes.c:1567
#10 0x082ea58b in execute_pass_list (pass=0x87a38a0) at
/vol/gcc/src/gcc-dist/gcc/passes.c:1568
#11 0x083d6649 in tree_rest_of_compilation (fndecl=0xfee62000) at
/vol/gcc/src/gcc-dist/gcc/tree-optimize.c:392
#12 0x0852436c in cgraph_expand_function (node=0xfee64000) at
/vol/gcc/src/gcc-dist/gcc/cgraphunit.c:1160
#13 0x0852609d in cgraph_optimize () at
/vol/gcc/src/gcc-dist/gcc/cgraphunit.c:1219
#14 0x085263f2 in cgraph_finalize_compilation_unit () at
/vol/gcc/src/gcc-dist/gcc/cgraphunit.c:1089
#15 0x080beb4f in c_write_global_declarations () at
/vol/gcc/src/gcc-dist/gcc/c-decl.c:9489
#16 0x08381ed3 in toplev_main (argc=4, argv=0x80477bc) at
/vol/gcc/src/gcc-dist/gcc/toplev.c:1061
#17 0x08126fdf in main (argc=4, argv=0x80477bc) at
/vol/gcc/src/gcc-dist/gcc/main.c:35

simplify_replace_fn_rtx is called with x = NULL above, thus GET_MODE (x)
segfaults.  So it seems likely that the introduction of
simplify_replace_fn_rtx is the culprit.

Rainer


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41930

[Bug target/41930] [4.5 regression] cc1 SEGV compiling maxval_r16.c

[ro at gcc dot gnu dot org]

--- Comment #4 from ro at gcc dot gnu dot org  2009-11-04 18:32 ---
Richard, this may be due to your patch.


-- 

ro at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu dot
   ||org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41930

[Bug c/41942] New: __attribute__ ((visibility)) weird with functions returning pointers

[eike at sf-mail dot de]

const char * __attribute__ ((visibility ("hidden"))) foo(void)
{ return "foo"; }

const char __attribute__ ((visibility ("hidden"))) * bar(void)
{ return "bar"; }


Compile this with:

gcc -fPIC -Wl,--version-script=foobar.map -Wl,--strip-all -shared -o foobar.so
foobar.c

foo() now issues the warning "warning: ‘visibility’ attribute ignored on
non-class types" and the visibility is not applied. Placing the attribute at
that position is very unintuitive and the warning isn't particular helpful.
Also I found nothing in the documentation about this.


-- 
   Summary: __attribute__ ((visibility)) weird with functions
returning pointers
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eike at sf-mail dot de


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41942

[Bug target/41930] [4.5 regression] cc1 SEGV compiling maxval_r16.c

[ro at CeBiTec dot Uni-Bielefeld dot DE]

--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld dot DE  2009-11-04 
18:15 ---
Subject: Re:  [4.5 regression] cc1 SEGV compiling maxval_r16.c


> I'll build a cross compiler from i386-pc-solaris2.10 and see if I can
> reproduce the problem there.

Unfortunately, the problem does not reproduce in such a cross compiler,
so I'll have to either start a native reghunt or find a way to debug the
native compiler (maybe compiling with -g without -O2 or try the stage1
compiler if it is also affected).

 Rainer


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41930

[Bug c++/17365] [DR 218] Should ADL find non-functions?

[jason at gcc dot gnu dot org]

--- Comment #12 from jason at gcc dot gnu dot org  2009-11-04 18:14 ---
Subject: Bug 17365

Author: jason
Date: Wed Nov  4 18:13:57 2009
New Revision: 153905

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153905
Log:
PR c++/17365, DR 218
* name-lookup.c (add_function): Ignore non-functions.

Added:
trunk/gcc/testsuite/g++.dg/lookup/koenig6.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/name-lookup.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/lookup/koenig5.C
trunk/gcc/testsuite/g++.dg/template/crash56.C
trunk/gcc/testsuite/g++.old-deja/g++.ns/koenig5.C


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17365

[Bug target/41930] [4.5 regression] cc1 SEGV compiling maxval_r16.c

[ro at gcc dot gnu dot org]

--- Comment #2 from ro at gcc dot gnu dot org  2009-11-04 17:53 ---
Created an attachment (id=18968)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18968&action=view)
minimized testcase

Compile with gcc -std=c99 -c -O2 to produce SEGV.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41930

[Bug target/41930] [4.5 regression] cc1 SEGV compiling maxval_r16.c

[ro at CeBiTec dot Uni-Bielefeld dot DE]

--- Comment #1 from ro at CeBiTec dot Uni-Bielefeld dot DE  2009-11-04 
17:52 ---
Subject:  [4.5 regression] cc1 SEGV compiling maxval_r16.c 

Unfortunately, gdb 7.0 crashes as well, so I cannot investigate the
problem this way.  But I've been able to produce a minimized testcase,
which I'll attach.

I'll build a cross compiler from i386-pc-solaris2.10 and see if I can
reproduce the problem there.

  Rainer


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41930

[Bug target/36047] -pg does not work on large binaries and m68k

[mkuvyrkov at gcc dot gnu dot org]

--- Comment #4 from mkuvyrkov at gcc dot gnu dot org  2009-11-04 16:57 
---
It appears that 'lea' serves some compatibility purpose.  The code is there
since 1995.

Recent GLIBC defines _mcount as
void
_mcount (void)
{
  mcount_internal ((u_long)
   __builtin_extract_return_addr (__builtin_return_address
  (1)),
   (u_long)
   __builtin_extract_return_addr (__builtin_return_address
  (0)));
}
so the value of %a1 is unused.  Newlib and uClibc don't define _mcount for m68k
at all.

Andreas, I suggest simply removing the 'lea'; they seem to be no users for it.

Alternatively, for the !PIC case we may use 'lea , %a1' (no pc-relative
relocation) and for the PIC case use a longer sequence, something like: 'move.l
#@PC32, %a1\n add.l (-4, %pc), %a1'.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36047

[Bug c++/41941] bad stack allocation using inline asm

[ubizjak at gmail dot com]

--- Comment #6 from ubizjak at gmail dot com  2009-11-04 16:47 ---
This is called "red zone" and is part of x86_64 ABI. Use -mno-red-zone if you
don't like this feature for some reason.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41941

[Bug fortran/41873] [OOP] Bogus Error: ABSTRACT INTERFACE must not be referenced...

[janus at gcc dot gnu dot org]

--- Comment #3 from janus at gcc dot gnu dot org  2009-11-04 16:43 ---
(In reply to comment #0)
> Error: ABSTRACT INTERFACE 'dot' must not be referenced at (1)

The same error appears in PR 41556.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41873

[Bug fortran/41937] [OOP] Error in allocating derived type allocatable components

[janus at gcc dot gnu dot org]

--- Comment #3 from janus at gcc dot gnu dot org  2009-11-04 16:33 ---
(In reply to comment #2)
> Janus, if you want to do the honour, go ahead.

Yes, I can do it.


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |janus at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-11-04 14:33:01 |2009-11-04 16:33:35
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41937

[Bug lto/41932] LTO ICE when compiling ocaml trunk (incompatible type)

[jamborm at gcc dot gnu dot org]

--- Comment #6 from jamborm at gcc dot gnu dot org  2009-11-04 16:10 ---
(In reply to comment #4)
> This is -O vs. -O2 ICE because different IPA passes are selected
> then.  I think we have a dup for this - Martin, is it somehow easy
> to avoid the ICE?
> 

Well, it seems that calling ipa_initialize_node_params() rather than
ipa_populate_param_decls() in ipa_update_after_lto_read() should avoid
it.

Moreover, if things can get this much out of sync, I'd also call
ipa_check_create_node_params() and ipa_check_create_edge_args() at the
beginning of ipa_update_after_lto_read() too, just to be sure.

I have not tried any of the above but can prepare a patch along these
lines... unless someone else is faster :-)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41932

[Bug c++/11407] [DR 115] Function cannot be resolved

[jason at gcc dot gnu dot org]

--- Comment #16 from jason at gcc dot gnu dot org  2009-11-04 16:08 ---
Fixed for 4.5 by the patch for PR 37177.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||4.5.0
 Resolution||FIXED
   Target Milestone|--- |4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11407

[Bug c++/19092] [DR 561] template code does not ignore static functions overloads

[jason at gcc dot gnu dot org]

--- Comment #12 from jason at gcc dot gnu dot org  2009-11-04 16:05 ---
My drafting to ratify the G++ behavior was adopted at the Santa Cruz meeting,
so this is not a bug.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19092

[Bug tree-optimization/41643] [4.4 Regression] ICE (segmentation fault) for SPEC CPU2000's 176.gcc when using -fno-tree-dce

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to work|4.5.0   |4.3.4 4.5.0
Summary|ICE (segmentation fault) for|[4.4 Regression] ICE
   |SPEC CPU2000's 176.gcc when |(segmentation fault) for
   |using -fno-tree-dce |SPEC CPU2000's 176.gcc when
   ||using -fno-tree-dce
   Target Milestone|--- |4.4.3


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41643

[Bug c++/17365] [DR 218] Should ADL find non-functions?

[jason at gcc dot gnu dot org]

-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-03-03 20:48:57 |2009-11-04 15:53:37
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17365

[Bug c++/41941] bad stack allocation using inline asm

[mikpe at it dot uu dot se]

--- Comment #5 from mikpe at it dot uu dot se  2009-11-04 15:47 ---
On x86_64 there's a 128 byte area below %rsp which is free to use without first
setting up a stack frame. This is described in the x86_64 ABI document. The
Linux kernel skips this area before pushing signal handler stack frames.

Do you have a concrete example of this not working?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41941

[Bug driver/11810] gcc -pipe -ox.o -c x.c writes erroneous x.o on compile error

[nathan at gcc dot gnu dot org]

--- Comment #11 from nathan at gcc dot gnu dot org  2009-11-04 15:47 ---
Subject: Bug 11810

Author: nathan
Date: Wed Nov  4 15:47:00 2009
New Revision: 153900

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153900
Log:
PR driver/11810
* gcc.c (SWITCHES_NEED_SPACES): Define to "o".
* config/alpha/osf.h (SWITCHES_NEED_SPACES): Remove here.
* config/mips/iris.h (SWITCHES_NEED_SPACES): Remove here.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/alpha/osf.h
trunk/gcc/config/mips/iris.h
trunk/gcc/gcc.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11810

[Bug c++/41934] function parameter pack inaccessible inside lambda

[jason at gcc dot gnu dot org]

--- Comment #2 from jason at gcc dot gnu dot org  2009-11-04 15:40 ---
Yeah, this and 41933 are both that capturing a parameter pack isn't implemented
yet.

*** This bug has been marked as a duplicate of 41933 ***


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41934

[Bug c++/41933] internal compiler error: tree check: expected field_decl, have error_mark in build_lambda_object, at cp/semantics.c:5353

[jason at gcc dot gnu dot org]

--- Comment #4 from jason at gcc dot gnu dot org  2009-11-04 15:40 ---
*** Bug 41934 has been marked as a duplicate of this bug. ***


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41933

[Bug c++/41941] bad stack allocation using inline asm

[freddy77 at gmail dot com]

--- Comment #4 from freddy77 at gmail dot com  2009-11-04 15:39 ---
Oh... I forgot. I used gcc from Ubuntu 9.10 distro either gcc 4.4.1, g++ 4.4.1,
gcc 4.3.4 and g++ 4.3.4 have same issue. The issue does not occur using -Os
option (which use push instructions)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41941

[Bug c++/41941] bad stack allocation using inline asm

[freddy77 at gmail dot com]

--- Comment #3 from freddy77 at gmail dot com  2009-11-04 15:37 ---
Created an attachment (id=18967)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18967&action=view)
gcc command output


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41941

[Bug c++/41941] bad stack allocation using inline asm

[freddy77 at gmail dot com]

--- Comment #2 from freddy77 at gmail dot com  2009-11-04 15:37 ---
Created an attachment (id=18966)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18966&action=view)
output assembly


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41941

[Bug c++/41941] bad stack allocation using inline asm

[freddy77 at gmail dot com]

--- Comment #1 from freddy77 at gmail dot com  2009-11-04 15:37 ---
Created an attachment (id=18965)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18965&action=view)
source code


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41941

[Bug c++/41941] New: bad stack allocation using inline asm

[freddy77 at gmail dot com]

compiling a assembler inline code which use a log of registers and with -O2
option instructions like

movq%rbx, -40(%rsp)

are generated which are wrong cause it writes to not allocated stack which
could lead to corruption on interrupts

code
void foo(const unsigned char *p)
{

  unsigned int t0, t1, t2, t3;
  __asm__ __volatile__
  (
  ".intel_syntax noprefix;"
  "mov r8" ", " "rsi" ";"
  "mov r9" ", " "rcx" ";"

  ".att_syntax prefix;"
   : "=a" (t0), "=c" (t1), "=S" (t2), "=D" (t3)
   : "D" (p)
   : "memory", "cc"

   , "%ebx" , "%r8", "%r9", "%r10", "%r11", "%r12" , "%r13", "%r14", "%r15"

  );

}



I'll attach source code, generated code and gcc command output

freddy77


-- 
   Summary: bad stack allocation using inline asm
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: freddy77 at gmail dot com
 GCC build triplet: x86_64-linux-gnu
  GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41941

[Bug debug/41371] [4.5 Regression] -g causes compiler to hang

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2009-11-04 15:34 ---
Created an attachment (id=18964)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18964&action=view)
qmc2main.ii.bz2

Another testcase where var-tracking takes almost forever on setupUi on
x86_64-linux with -g -O2.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371

[Bug c++/39934] Union member incorrectly disallowed

[redi at gcc dot gnu dot org]

--- Comment #10 from redi at gcc dot gnu dot org  2009-11-04 15:28 ---
To be clear:  In C++0x struct A would have a deleted copy assign operator, and
union U would be allowed, but its copy assignment operator would be deleted.

IMHO C++03 is not clear whether struct A has a trivial assignment operator or
not.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39934

[Bug c++/39934] Union member incorrectly disallowed

[redi at gcc dot gnu dot org]

--- Comment #9 from redi at gcc dot gnu dot org  2009-11-04 14:41 ---
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#653
and
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#683
and
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2762

I'm still not sure what should happen though, I might ask on the std reflector.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39934

[Bug libstdc++/41938] make[1]: *** [all-target-libstdc++-v3] Error 2

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2009-11-04 14:36 
---
Are you sure using newlib is supported (and that you definitely need it)? I do
not have access to Leopard anymore but certainly the library builds fine for a
default configure, in fact the entire 4.4.x, we have plenty of successful
reports.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41938

[Bug fortran/41937] [OOP] Error in allocating derived type allocatable components

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2009-11-04 14:33 ---
Confirmed. The following - untested - should fix it. I am not sure, when I have
time to submit it. Janus, if you want to do the honour, go ahead.

Index: resolve.c
===
--- resolve.c   (revision 153896)
+++ resolve.c   (working copy)
@@ -6198,7 +6198,8 @@ check_symbols:
  sym = a->expr->symtree->n.sym;

  /* TODO - check derived type components.  */
- if (sym->ts.type == BT_DERIVED)
+ if (sym->ts.type == BT_DERIVED
+ || sym->ts.type == BT_CLASS)
continue;

  if ((ar->start[i] != NULL


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  GCC build triplet|i686-pc-linux-gnu   |
   GCC host triplet|i686-pc-linux-gnu   |
 GCC target triplet|i686-pc-linux-gnu   |
   Keywords||rejects-valid
   Last reconfirmed|-00-00 00:00:00 |2009-11-04 14:33:01
   date||
Summary|Error in allocating derived |[OOP] Error in allocating
   |type allocatable components |derived type allocatable
   ||components


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41937

[Bug fortran/41940] New: Improve error message for allocating scalar with shape

[burnus at gcc dot gnu dot org]

integer, allocatable :: a
allocate(a(4))
end

gives the - correct - error:

  Error: Syntax error in ALLOCATE statement at (1)

However, I prefer the error message of ifort:

  error #8196: An ALLOCATE shape must not be given for a scalar object.


-- 
   Summary: Improve error message for allocating scalar with shape
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41940

[Bug target/41900] call *%esp shouldn't be generated because of CPU errata

[uros at gcc dot gnu dot org]

--- Comment #3 from uros at gcc dot gnu dot org  2009-11-04 14:15 ---
Subject: Bug 41900

Author: uros
Date: Wed Nov  4 14:14:49 2009
New Revision: 153896

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153896
Log:
PR target/41900
* config/i386/i386.h (ix86_arch_indices) : New.
(TARGET_CALL_ESP): New define.
* config/i386/i386.c (initial_ix86_tune_features): Initialize
X86_ARCH_CALL_ESP.
* config/i386/i386.md 
(*call_pop_1_esp, *call_1_esp, *call_value_pop_1_esp,
*call_value_1_esp): Rename from *call_pop_1, *call_1,
*call_value_pop_1 and *call_value_1.  Depend on TARGET_CALL_ESP.
(*call_pop_1, *call_1, *call_value_pop_1, *call_value_1):
New patterns, use "lsm" as operand 1 constraint.
* config/i386/predicates.md (call_insn_operand): Depend on 
index_register_operand for !TARGET_CALL_ESP to avoid %esp register.

testsuite/ChangeLog:

PR target/41900
* gcc.target/i386/pr41900.c: New test.


Added:
branches/gcc-4_4-branch/gcc/testsuite/gcc.target/i386/pr41900.c
Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/config/i386/i386.c
branches/gcc-4_4-branch/gcc/config/i386/i386.h
branches/gcc-4_4-branch/gcc/config/i386/i386.md
branches/gcc-4_4-branch/gcc/config/i386/predicates.md
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41900

[Bug target/40835] redundant comparison instruction

[rearnsha at gcc dot gnu dot org]

--- Comment #8 from rearnsha at gcc dot gnu dot org  2009-11-04 14:10 
---
Subject: Bug 40835

Author: rearnsha
Date: Wed Nov  4 14:09:55 2009
New Revision: 153895

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153895
Log:
2009-11-04  Richard Earnshaw  

PR target/40835
* arm.md (peephole2 patterns for move and compare): New.

2009-11-04  Wei Guozhi  

PR target/40835
* gcc.target/arm/pr40835: New testcase.

Added:
trunk/gcc/testsuite/gcc.target/arm/pr40835.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.md
trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40835

[Bug lto/41932] LTO ICE when compiling ocaml trunk (incompatible type)

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2009-11-04 14:01 ---
Note that I wonder why we write/read summaries (do we?) with -flto at all.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|major   |normal


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41932

[Bug target/41939] EABI violation in accessing values below the stack.

[ramana at gcc dot gnu dot org]

-- 

ramana at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-11-04 14:01:43
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41939

[Bug target/41939] New: EABI violation in accessing values below the stack.

[ramana at gcc dot gnu dot org]

4.4.x has a problem with the floating point emulation libraries with respect to
the EABI in that they access an area below the stack pointer. 

This is fixed on trunk with
http://gcc.gnu.org/ml/gcc-patches/2009-06/msg00372.html but needs backporting
to 4.4.x and 4.3.x branches. I will do so once I've backported and regression
tested these.

cheers
Ramana


-- 
   Summary: EABI violation in accessing values below the stack.
   Product: gcc
   Version: 4.4.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: ramana at gcc dot gnu dot org
ReportedBy: ramana at gcc dot gnu dot org
GCC target triplet: arm-*-eabi


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41939

[Bug lto/41932] LTO ICE when compiling ocaml trunk (incompatible type)

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2009-11-04 14:00 ---
This is -O vs. -O2 ICE because different IPA passes are selected then.  I think
we have a dup for this - Martin, is it somehow easy to avoid the ICE?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||mjambor at suse dot cz
 Status|WAITING |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-11-04 14:00:43
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41932

[Bug libstdc++/41938] New: make[1]: *** [all-target-libstdc++-v3] Error 2

[david dot stoffel81 at googlemail dot com]

I am useing the following CFLAGS
export CFLAGS=-no-cpp-precom
with the configure command:
../configure --target=i386-elf --prefix=/usr/local/i386elfgcc --with-gnu-as
--with-gnu-ld --disable-libssp --enable-languages=c,c++,objc --with-newlib
--with-headers=../../newlib-1.9.0/newlib/libc/include --with-gmp=/opt/local
--with-mpfr=/opt/local --enable-multilib --disable-libgfortran

The result is a problem with libstdc++ on Leopard 10.5. Trying to fix this
issue sience a week with no result.

gnu_cxx::encoding_state>::do_out(__gnu_cxx::encoding_state&, const _InternT*,
const _InternT*, const _InternT*&, _ExternT*, _ExternT*, _ExternT*&) const’:
/Users/colossus/toolchains/gcc-4.4.2/build-i386-elf/i386-elf/libstdc++-v3/include/ext/codecvt_specializations.h:310:
error: expected initializer before ‘&’ token
/Users/colossus/toolchains/gcc-4.4.2/build-i386-elf/i386-elf/libstdc++-v3/include/ext/codecvt_specializations.h:336:
error: ‘iconv’ was not declared in this scope
/Users/colossus/toolchains/gcc-4.4.2/build-i386-elf/i386-elf/libstdc++-v3/include/ext/codecvt_specializations.h:336:
error: ‘__desc’ was not declared in this scope
/Users/colossus/toolchains/gcc-4.4.2/build-i386-elf/i386-elf/libstdc++-v3/include/ext/codecvt_specializations.h:337:
error: there are no arguments to ‘__iconv_adaptor’ that depend on a template
parameter, so a declaration of ‘__iconv_adaptor’ must be available
/Users/colossus/toolchains/gcc-4.4.2/build-i386-elf/i386-elf/libstdc++-v3/include/ext/codecvt_specializations.h:337:
note: (if you use ‘-fpermissive’, G++ will accept your code, but allowing the
use of an undeclared name is deprecated)
/Users/colossus/toolchains/gcc-4.4.2/build-i386-elf/i386-elf/libstdc++-v3/include/ext/codecvt_specializations.h:343:
error: ‘iconv’ was not declared in this scope
/Users/colossus/toolchains/gcc-4.4.2/build-i386-elf/i386-elf/libstdc++-v3/include/ext/codecvt_specializations.h:343:
error: ‘__desc’ was not declared in this scope
/Users/colossus/toolchains/gcc-4.4.2/build-i386-elf/i386-elf/libstdc++-v3/include/ext/codecvt_specializations.h:344:
error: there are no arguments to ‘__iconv_adaptor’ that depend on a template
parameter, so a declaration of ‘__iconv_adaptor’ must be available
/Users/colossus/toolchains/gcc-4.4.2/build-i386-elf/i386-elf/libstdc++-v3/include/ext/codecvt_specializations.h:
In member function ‘virtual std::codecvt_base::result std::codecvt<_InternT,
_ExternT, __gnu_cxx::encoding_state>::do_unshift(__gnu_cxx::encoding_state&,
_ExternT*, _ExternT*, _ExternT*&) const’:
/Users/colossus/toolchains/gcc-4.4.2/build-i386-elf/i386-elf/libstdc++-v3/include/ext/codecvt_specializations.h:377:
error: expected initializer before ‘&’ token
/Users/colossus/toolchains/gcc-4.4.2/build-i386-elf/i386-elf/libstdc++-v3/include/ext/codecvt_specializations.h:384:
error: ‘iconv’ was not declared in this scope
/Users/colossus/toolchains/gcc-4.4.2/build-i386-elf/i386-elf/libstdc++-v3/include/ext/codecvt_specializations.h:384:
error: ‘__desc’ was not declared in this scope
/Users/colossus/toolchains/gcc-4.4.2/build-i386-elf/i386-elf/libstdc++-v3/include/ext/codecvt_specializations.h:385:
error: there are no arguments to ‘__iconv_adaptor’ that depend on a template
parameter, so a declaration of ‘__iconv_adaptor’ must be available
/Users/colossus/toolchains/gcc-4.4.2/build-i386-elf/i386-elf/libstdc++-v3/include/ext/codecvt_specializations.h:
In member function ‘virtual std::codecvt_base::result std::codecvt<_InternT,
_ExternT, __gnu_cxx::encoding_state>::do_in(__gnu_cxx::encoding_state&, const
_ExternT*, const _ExternT*, const _ExternT*&, _InternT*, _InternT*, _InternT*&)
const’:
/Users/colossus/toolchains/gcc-4.4.2/build-i386-elf/i386-elf/libstdc++-v3/include/ext/codecvt_specializations.h:414:
error: expected initializer before ‘&’ token
/Users/colossus/toolchains/gcc-4.4.2/build-i386-elf/i386-elf/libstdc++-v3/include/ext/codecvt_specializations.h:440:
error: ‘iconv’ was not declared in this scope
/Users/colossus/toolchains/gcc-4.4.2/build-i386-elf/i386-elf/libstdc++-v3/include/ext/codecvt_specializations.h:440:
error: ‘__desc’ was not declared in this scope
/Users/colossus/toolchains/gcc-4.4.2/build-i386-elf/i386-elf/libstdc++-v3/include/ext/codecvt_specializations.h:441:
error: there are no arguments to ‘__iconv_adaptor’ that depend on a template
parameter, so a declaration of ‘__iconv_adaptor’ must be available
/Users/colossus/toolchains/gcc-4.4.2/build-i386-elf/i386-elf/libstdc++-v3/include/ext/codecvt_specializations.h:447:
error: ‘iconv’ was not declared in this scope
/Users/colossus/toolchains/gcc-4.4.2/build-i386-elf/i386-elf/libstdc++-v3/include/ext/codecvt_specializations.h:447:
error: ‘__desc’ was not declared in this scope
/Users/colossus/toolchains/gcc-4.4.2/build-i386-elf/i386-elf/libstdc++-v3/include/ext/codecvt_specializations.h:448:
error: there are no arguments to ‘__iconv_adaptor’ that depend on a template
parameter, so a declaration of ‘__iconv_adaptor’ must be available
make[4]: *** [i386-elf/b

[Bug driver/41564] -fdump-tree-all for lto does not work as expected

[pinskia at gmail dot com]

--- Comment #7 from pinskia at gmail dot com  2009-11-04 13:57 ---
Subject: Re:  -fdump-tree-all for lto does not work as expected



Sent from my iPhone

On Nov 4, 2009, at 1:32 AM, "rguenther at suse dot de"
 wrote:

>
>
> --- Comment #6 from rguenther at suse dot de  2009-11-04 09:32  
> ---
> Subject: Re:  -fdump-tree-all for lto does not work as
> expected
>
> On Tue, 3 Nov 2009, pinskia at gcc dot gnu dot org wrote:
>
>> --- Comment #5 from pinskia at gcc dot gnu dot org  2009-11-03  
>> 20:02 ---
>> My /tmp is small so this causes it to be filled up quickly.  Is  
>> there a simple
>> work around?
>
> No.

Actually thinking about it, setting TMPDIR env is a workaround :)


>
> Richard.
>
>
> -- 
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41564
>


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41564

Re: [Bug driver/41564] -fdump-tree-all for lto does not work as expected

[Andrew Pinski]

Sent from my iPhone

On Nov 4, 2009, at 1:32 AM, "rguenther at suse dot de" > wrote:





--- Comment #6 from rguenther at suse dot de  2009-11-04 09:32  
---

Subject: Re:  -fdump-tree-all for lto does not work as
expected

On Tue, 3 Nov 2009, pinskia at gcc dot gnu dot org wrote:

--- Comment #5 from pinskia at gcc dot gnu dot org  2009-11-03  
20:02 ---
My /tmp is small so this causes it to be filled up quickly.  Is  
there a simple

work around?


No.


Actually thinking about it, setting TMPDIR env is a workaround :)




Richard.


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41564

[Bug ada/41929] 64-bit null_pointer_deref1 gnat.dg test consumes all available memory

[rguenther at suse dot de]

--- Comment #6 from rguenther at suse dot de  2009-11-04 13:12 ---
Subject: Re:  64-bit null_pointer_deref1 gnat.dg test consumes
 all available memory

On Wed, 4 Nov 2009, ebotcazou at gcc dot gnu dot org wrote:

> --- Comment #5 from ebotcazou at gcc dot gnu dot org  2009-11-04 11:57 
> ---
> > Running target unix//-m32
> > FAIL: gnat.dg/null_pointer_deref1.adb execution test
> > 
> > the 64bit variant passes.
> > 
> > the log just states
> > 
> > raised STORAGE_ERROR : stack overflow (or erroneous memory access)
> 
> OK, thanks for the clarification.  Which kernel do you run?  Does the 
> following
> patch help?

I run 2.6.16.42-0.6-smp, that is some old SLES10 kernel.

I'll test if the patch helps.

Richard.

> Index: config/i386/linux-unwind.h
> ===
> --- config/i386/linux-unwind.h  (revision 153778)
> +++ config/i386/linux-unwind.h  (working copy)
> @@ -172,6 +172,25 @@ x86_fallback_frame_state (struct _Unwind
>fs->signal_frame = 1;
>return _URC_NO_REASON;
>  }
> +
> +#define MD_FROB_UPDATE_CONTEXT x86_frob_update_context
> +
> +/* Fix up for kernels that have vDSO, but don't have S flag in it.  */
> +
> +static void
> +x86_frob_update_context (struct _Unwind_Context *context,
> +_Unwind_FrameState *fs ATTRIBUTE_UNUSED)
> +{
> +  unsigned char *pc = context->ra;
> +
> +  /* movl $__NR_rt_sigreturn,%eax ; {int $0x80 | syscall}  */
> +  if (*(unsigned char *)(pc+0) == 0xb8
> +  && *(unsigned int *)(pc+1) == 173
> +  && (*(unsigned short *)(pc+5) == 0x80cd
> + || *(unsigned short *)(pc+5) == 0x050f))
> +_Unwind_SetSignalFrame (context, 1);
> +}
> +
>  #endif /* not glibc 2.0 */
>  #endif /* ifdef __x86_64__  */
>  #endif /* ifdef inhibit_libc  */
> 
> 
> 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41929