[Bug fortran/39861] New: Internal Error with INTRINSIC in module

[dominiq at lps dot ens dot fr]

At revision 146606 the following code

module vector_calculus
  intrinsic :: dot_product, sqrt

contains

  function len(r)
real, dimension(:), intent(in) :: r
real :: len
len = sqrt(dot_product(r,r))
  end function len

end module vector_calculus
end

gives

pr36192_mod_red.f90:12.26:

end module vector_calculus
  1
Internal Error at (1):
write_symbol(): bad module symbol 'x'

This code has been extracted from a larger one that did not give this error at
revision 146282.
I suspect revision 146554.


-- 
   Summary: Internal Error with INTRINSIC in module
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr


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

[Bug middle-end/39857] segfault on include/linux/parport_pc.h:199

[ubizjak at gmail dot com]

--- Comment #2 from ubizjak at gmail dot com  2009-04-23 06:49 ---
Please report this bug to Debian first:

For Debian GNU/Linux specific bug reporting instructions,
see .


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug middle-end/39641] Compiling Linux 2.6.28.6 ends with a segfault on net/core/skbuff.c

[lasse-gccbug-2009 at mail dot plastictree dot net]

--- Comment #5 from lasse-gccbug-2009 at mail dot plastictree dot net  
2009-04-23 06:42 ---
(In reply to comment #4)
> Can you give the output of gcc -v?
> 

Using built-in specs.
Target: i686-pc-linux-gnu
Configured with:
/package/host/localhost/sepbuilt/gcc41-4.1.2-01-03/src/unpack/gcc-4.1.2/configure
--prefix=/package/host/localhost/sepbuilt/gcc41-4.1.2-01-03/prefix
--libexecdir=/package/host/localhost/sepbuilt/gcc41-4.1.2-01-03/prefix/libexec
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --enable-checking --disable-werror --enable-bootstrap
--enable-languages=c,c++
Thread model: posix
gcc version 4.1.2

By the way, this gcc was compiled roughly following the instructions from the
HLFS project. In particular, this includes the following patches:

http://www.linuxfromscratch.org/patches/hlfs/svn/gcc-4.1.2-fstack_protector-1.patch
http://www.linuxfromscratch.org/patches/hlfs/svn/gcc-4.1.2-strncat_chk-1.patch
http://www.linuxfromscratch.org/patches/hlfs/svn/gcc-4.1.2-fortify_source-2.patch
http://www.linuxfromscratch.org/patches/hlfs/svn/gcc-4.1.2-fpie-2.patch
http://www.linuxfromscratch.org/patches/hlfs/svn/gcc-4.1.2-DW_CFA_val-1.patch
http://www.linuxfromscratch.org/patches/hlfs/svn/gcc-4.1.2-Wno_overlength_strings-1.patch
http://www.linuxfromscratch.org/patches/hlfs/svn/gcc-4.1.2-PR26864-1.patch
http://www.linuxfromscratch.org/patches/hlfs/svn/gcc-4.1.2-texinfo_fix-1.patch

I can go and try to reproduce with a vanilla gcc, if that helps.


-- 


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

[Bug libstdc++/39491] [4.4/4.5 regression] symbol __signb...@glibcxx_3.4 in libstdc++ not exported anymore

[jakub at gcc dot gnu dot org]

--- Comment #21 from jakub at gcc dot gnu dot org  2009-04-23 06:28 ---
Created an attachment (id=17682)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17682&action=view)
glibc-no-long-double-math.patch

I agree that even for __NO_LONG_DOUBLE_MATH we should provide *l prototypes
(certainly for __USE_ISOC99, not sure about __USE_MISC alone), just redirecting
to the non-l functions, though tgmath.h nor signbit/finite/... macros which
just use sizeof obviously can stay as is.
This patch is totally untested...


-- 


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

[Bug c/39662] segmentation failed on correctly compiled mixed C and C++ code

[pavel dot petrovic at gmail dot com]

--- Comment #4 from pavel dot petrovic at gmail dot com  2009-04-23 06:06 
---
Thanks! it works. I was confused by this document:
ftp://ftp.freepascal.org/pub/fpc/docs-pdf/CinFreePascal.pdf which seems to
claim the opposite.


-- 

pavel dot petrovic at gmail dot com changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org


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

[Bug middle-end/39852] GCC 4.4.0 builds a broken glibc 2.8

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2009-04-23 06:03 ---
GCC 4.4.0 compiled glibc 2.10 works just fine for me on x86_64, i586, i686,
powerpc and powerpc64.

Anyway, if you say GCC 4.3.3 compiled glibc 2.8 works and 4.4.0 compiled
doesn't, then please do a binary search between 4.3.3 and 4.4.0 compiled
objects to find out on which CU it matters (say configure glibc with CC=gcc
CXX=g++,
then point PATH env var. to wher eyou have gcc 4.4.0 unpacked, build glibc,
verify your testcase breaks, then in the build tree
for i in [a-l]*/*.os; do mv ${i}{,.4.4}; done
change PATH to point to 4.3.3 gcc, make, see whether your testcase breaks or
not and depending on that continue with either half of the [a-l]* or [m-z]*
objects, etc.


-- 


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

[Bug c++/39860] extremely long compile time

[pletzer at txcorp dot com]

--- Comment #1 from pletzer at txcorp dot com  2009-04-23 04:38 ---
Created an attachment (id=17681)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17681&action=view)
source code reproducing problem

I apologize but I cannot produce *.i files with -save-temps:

[plet...@localhost test]$ g++ -c -save-temps cxxps.cpp
[plet...@localhost test]$ ls
ccps_base.h  cxxps.cpp  cxxps.o  f77name.h
ccps.h   cxxps.hcxxps.tmp.localhost.localdomain.10206.s  multiarray.h


 so I'm sending the source and headers as a bz2 compressed file. To reproduce
the problem of very long compile time, type

tar xvfj cxxps.bz2
g++ -c -O cxxps.cpp


-- 


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

[Bug c++/39860] New: extremely long compile time

[pletzer at txcorp dot com]

The attached code takes 20 mins to compile on a Linux/Fedora 9 box when using
-O optimization, but only 21 seconds when using -O0

[plet...@quartic cxxps]$ time g++ -O -ftime-report -fmem-report -c cxxps.cpp >&
stat.txt

real21m41.494s
user16m24.774s
sys 0m19.713s

[plet...@quartic cxxps]$ time g++ -O0 -ftime-report -fmem-report -c cxxps.cpp
>& stat.txt

real0m21.391s
user0m17.666s
sys 0m2.453s


-- 
   Summary: extremely long compile time
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pletzer at txcorp dot com
 GCC build triplet: Configured with: ../configure --prefix=/usr --
mandir=/usr/share/
  GCC host triplet: Linux quartic.txcorp.com 2.6.25.14-108.fc9.x86_64 #1 SMP
Mon Aug
GCC target triplet: x86_64-redhat-linux


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

[Bug inline-asm/39847] 16 symbolic register names generates error: more than 30 operands in 'asm'

[d at teklibre dot com]

--- Comment #21 from d at teklibre dot com  2009-04-23 03:44 ---
(In reply to comment #20)
> It successfully compiles, links, and runs my project (ScreamingRabbitCode) at
> -O3 -mtune=core2 w/o the asm code in 17.397s. gcc 4.3.2 takes 17.865s. (both
> are best case times over several runs and well within margin of error) 

To be clear, the timing above was for compiling and linking using the patched
gcc 4.4 vs gcc 4.3.2. 


-- 


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

[Bug inline-asm/39847] 16 symbolic register names generates error: more than 30 operands in 'asm'

[d at teklibre dot com]

--- Comment #20 from d at teklibre dot com  2009-04-23 03:29 ---
I got gcc 4.4 built with the 1 line patch.

It assembles my 24 operand function just fine (which had several errors in the
asm that I couldn't detect without assembling it - pushed out to my repo now -
it even gets through a few loops with my as yet unfinished test code). Yea! 

Optimal register allocation (w/wo REX prefixes) is an issue (but that was why I
was writing this as inline asm in the first place, that is easy to fix)

It successfully compiles, links, and runs my project (ScreamingRabbitCode) at
-O3 -mtune=core2 w/o the asm code in 17.397s. gcc 4.3.2 takes 17.865s. (both
are best case times over several runs and well within margin of error) 

This is obviously not a particularly good test (I suspect the bottleneck is
libtool). I will try it and out of the box 4.4 on some bigger stuff tomorrow
(suggestions? The biggest thing I ever build is ardour), and figure out how to
run the gcc testsuite as well.


-- 


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

[Bug fortran/38439] I/O PD edit descriptor inconsistency

[kargl at gcc dot gnu dot org]

--- Comment #9 from kargl at gcc dot gnu dot org  2009-04-23 02:52 ---
(In reply to comment #8)
> Getting back to this.  We have a problem of choices here.  In format 
> statements
> such as:
>   WRITE (*,'(1PD24.15E4)') 1.0d0
> 
> Currently gfortran allows an extension of an optional comma separating format
> specifiers.  This results in the format string above being seen as:
>   '(1PD24.15,E4)'
> 
> The error message given in the original post is from the missing period after
> the E4.
> 
> We could choose to allow the optional comma only with -std=legacy and then
> these misleading situations would not occur.  I am leaning in favour of this
> more restrictive approach. Any opinions?
> 

Conforming to the Standard is always good.  I vote for -std=legacy.


-- 


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

[Bug fortran/38439] I/O PD edit descriptor inconsistency

[jvdelisle at gcc dot gnu dot org]

--- Comment #8 from jvdelisle at gcc dot gnu dot org  2009-04-23 01:51 
---
Getting back to this.  We have a problem of choices here.  In format statements
such as:
  WRITE (*,'(1PD24.15E4)') 1.0d0

Currently gfortran allows an extension of an optional comma separating format
specifiers.  This results in the format string above being seen as:
  '(1PD24.15,E4)'

The error message given in the original post is from the missing period after
the E4.

We could choose to allow the optional comma only with -std=legacy and then
these misleading situations would not occur.  I am leaning in favour of this
more restrictive approach. Any opinions?


-- 


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

[Bug middle-end/39852] GCC 4.4.0 builds a broken glibc 2.8

[sega01 at go-beyond dot org]

--- Comment #4 from sega01 at go-beyond dot org  2009-04-23 01:10 ---
(In reply to comment #3)
> It might be better if you use gdb instead of using ltrace because those two
> programs don't give enough information on what is going on.  This could be
> still a bug in Lua or even in glibc itself but without a testcase to figure 
> out
> what is going wrong it is hard to debug.
> 

I can give gdb a try, but will let this sit for tonight first. For clarity,
nothing on my system is compiled with GCC 4.4.0 except glibc 2.8 for when I
test. Lua, xz, vi, nano, and all of the programs that segfault only segfault
when I use the GCC 4.4.0 compiled glibc 2.8; if I use glibc 2.8 built with GCC
4.3.3 they run just fine. I don't think this is a bug in any of those programs.
I think this could be a glibc bug, but I'm leaning on GCC since GCC 4.3.3
builds a clean glibc.

Thanks,
Teran


-- 


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

[Bug middle-end/39852] GCC 4.4.0 builds a broken glibc 2.8

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2009-04-23 00:57 ---
It might be better if you use gdb instead of using ltrace because those two
programs don't give enough information on what is going on.  This could be
still a bug in Lua or even in glibc itself but without a testcase to figure out
what is going wrong it is hard to debug.


-- 


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

[Bug middle-end/39852] GCC 4.4.0 builds a broken glibc 2.8

[sega01 at go-beyond dot org]

--- Comment #2 from sega01 at go-beyond dot org  2009-04-23 00:55 ---
(In reply to comment #1)
> There is not enough information here.  Do you have a source to a program which
> fails with the new glibc compiled with 4.4?
> 

Thank you for the quick response.

The sources for the applications I listed are readily available (I can link to
them directly if need be), but I did find a single readline test source that
segfaults. xz, less, and Lua also segfault. Lua managed to get to a printf
before segfaulting, so I thought it might give a more useful l/strace if
needed. http://tiswww.case.edu/php/chet/readline/rl.c is the readline test
source that segfaults.

Thanks,
Teran

PS: Should I have filled out the bug report differently? Is it acceptable to
change the status back to new after responding?


-- 

sega01 at go-beyond dot org changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED


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

[Bug target/38571] [arm] -mthumb generates unnecessary padding between functions

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2009-04-23 00:45 ---
The reason why this happens is because FUNCTION_BOUNDARY is defined as just 32
for both arm and thumb mode.


-- 


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

[Bug c++/39859] New: C++: Duplicated and unhelpful error for "c:n"

[ian at airs dot com]

When I compile this erroneous C++ program

namespace n { const int c = 1; }
int foo() { return n:c; }

I get this:

foo.cc: In function ‘int foo()’:
foo.cc:2: error: expected primary-expression before ‘:’ token
foo.cc:2: error: expected ‘;’ before ‘:’ token
foo.cc:2: error: expected primary-expression before ‘:’ token
foo.cc:2: error: expected ‘;’ before ‘:’ token

The duplicated error messages are useless; I think that is a bug.

Even if that bug is fixed, this error message could be better.  The error is
using a single colon instead of two colons.  "expected primary-expression" is
not helpful to the user.  Firstly, as in PR 39858, what is missing is an
expression, not a primary-expression.  Secondly, the colon is clearly out of
place; if we found an expression, we would still fail.  In this case, we
actually know that we just saw a NAMESPACE_DECL.  We can give a better error
message in this context.


-- 
   Summary: C++: Duplicated and unhelpful error for "c:n"
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ian at airs dot com


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

[Bug testsuite/39781] Fail: g++.dg/cpp/_Pragma1.C, gcc.dg/cpp/_Pragma6.c

[jingyu at gcc dot gnu dot org]

--- Comment #4 from jingyu at gcc dot gnu dot org  2009-04-23 00:34 ---
Add HANDLE_PRAGMA_PACK_PUSH_POP to arm.
Tests are done for both gcc trunk and gcc-4.4.
These two failures become pass.
Patch was submitted to trunk and gcc-4.4.


-- 

jingyu at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug testsuite/39781] Fail: g++.dg/cpp/_Pragma1.C, gcc.dg/cpp/_Pragma6.c

[jingyu at gcc dot gnu dot org]

--- Comment #3 from jingyu at gcc dot gnu dot org  2009-04-23 00:31 ---
Subject: Bug 39781

Author: jingyu
Date: Thu Apr 23 00:31:13 2009
New Revision: 146634

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146634
Log:
PR testsuite/39781
* config/arm/arm.h: Define HANDLE_PRAGMA_PACK_PUSH_POP.


Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/config/arm/arm.h


-- 


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

[Bug c++/39858] New: C++: "expected primary-expression" error could be more useful

[ian at airs dot com]

For this erroneous C++ test case:

extern void f(char**);
int main(int argc, char** argv) { f(argv[]); }

g++ reports

foo.cc: In function ‘int main(int, char**)’:
foo.cc:2: error: expected primary-expression before ‘]’ token

This is pretty good, but I question the use of the term "primary-expression". 
Primary-expression is slightly technical for this error, and, more improtantly,
what is missing is not a primary-expression; it is any expression at all.

Aside from avoiding the term "primary-expression", we can do better in this
specific case.  We actually know that we just saw '[' and that we are looking
for an array subscript.  We could say "missing subscript".  In other words,
let's take advantage of the fact that we have a recursive descent parser to put
more context into our error messages.

Finally, I'll note in passing that if I use -fshow-column I get the exact right
position, and in that case the phrase "before ']' token" is not very useful.


-- 
   Summary: C++: "expected primary-expression" error could be more
useful
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ian at airs dot com


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

[Bug middle-end/39857] segfault on include/linux/parport_pc.h:199

[strictlymike at gmail dot com]

--- Comment #1 from strictlymike at gmail dot com  2009-04-23 00:23 ---
Created an attachment (id=17680)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17680&action=view)
Preprocessed source as stored by gcc after segfault

Sorry, forgot to attach this, in a hurry.  Cheers.


-- 


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

[Bug c/39857] New: segfault on include/linux/parport_pc.h:199

[strictlymike at gmail dot com]

I had gcc segfault compiling the 2.6.18 Linux Kernel retrieved from
http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.18.tar.bz2.

The special details of my kernel configuration (-O0 and -ggdb3) probably play
into this, since I've never seen this error compiling Linux 2.6.18 before.

- Mike (strictlym...@gmail.com)

1., 2., 3. GCC version, system type, GCC config options:
$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --with-tune=i686
--enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)

4. Exact command-line
Indeterminate, but here is the scenario:
Linux 2.6.18 Kbuild:
Debug flags:
AFLAGS_MODULE += -ggdb2
CFLAGS_MODULE += -ggdb2
AFLAGS_KERNEL += -ggdb3
CFLAGS_KERNEL += -ggdb3
Optimizations disabled:
# Commented out CFLAGS += -Os and CFLAGS += -O2
CFLAGS += -O0

Probably failed on:
  CCdrivers/parport/parport_pc.o

5. Compiler output:
include/linux/parport_pc.h: In function ‘parport_pc_frob_control’:
include/linux/parport_pc.h:199: internal compiler error: Segmentation
fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see .
Preprocessed source stored into /tmp/ccN4mj5p.out file, please attach
this to your bugreport.

6. Preprocessed file
(Attached)


-- 
   Summary: segfault on include/linux/parport_pc.h:199
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: strictlymike at gmail dot com
 GCC build triplet: i486-linux-gnu
  GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu


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

[Bug preprocessor/38987] Including a precompiled header from another header causes invalid assembly to be generated

[pinskia at gcc dot gnu dot org]

--- Comment #8 from pinskia at gcc dot gnu dot org  2009-04-23 00:11 ---
*** Bug 39854 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ryancacophony at gmail dot
   ||com


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

[Bug c++/39854] Segfault with a pointer of array of pointers

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2009-04-23 00:11 ---


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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/39854] Segfault with a pointer of array of pointers

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|blocker |normal


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

[Bug middle-end/39852] GCC 4.4.0 builds a broken glibc 2.8

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-04-23 00:09 ---
There is not enough information here.  Do you have a source to a program which
fails with the new glibc compiled with 4.4?


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|major   |normal
 Status|UNCONFIRMED |WAITING
  Component|c   |middle-end


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

[Bug testsuite/39781] Fail: g++.dg/cpp/_Pragma1.C, gcc.dg/cpp/_Pragma6.c

[jingyu at gcc dot gnu dot org]

--- Comment #2 from jingyu at gcc dot gnu dot org  2009-04-23 00:05 ---
Subject: Bug 39781

Author: jingyu
Date: Thu Apr 23 00:05:03 2009
New Revision: 146629

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146629
Log:
PR testsuite/39781
* config/arm/arm.h: Define HANDLE_PRAGMA_PACK_PUSH_POP.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.h


-- 


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

[Bug bootstrap/39849] stage1 compiler segfault during `make profiledbootstrap'

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|blocker |normal


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

[Bug c++/39822] ICE: Segmentation fault -- with function template default template arguments in c++0x mode

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2009-04-22 23:55 ---


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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/35828] [C++0x] ICE on default template template parameter in template function

[pinskia at gcc dot gnu dot org]

--- Comment #7 from pinskia at gcc dot gnu dot org  2009-04-22 23:55 ---
*** Bug 39822 has been marked as a duplicate of this bug. ***


-- 


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

[Bug middle-end/39832] program built by x86_64-pc-mingw32-gcc run crash, maybe for _Unwind_SjLj_Unregister,

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-04-22 23:53 ---
Can you try this again, there were some Exceptions handling issues recently.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
  Component|libstdc++   |middle-end
   Keywords||wrong-code


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

[Bug c/39662] segmentation failed on correctly compiled mixed C and C++ code

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2009-04-22 23:41 ---
#ifdef __cplusplus
#define EXPORTCALL __attribute__((stdcall)) 
#else
#define EXPORTCALL 
#endif


Is wrong, you need to use the same ABI for the function on both sides of the
call, that is either use stdcall on both sides (C and C++) or don't use it at
all.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID
Summary|segmentation failed on  |segmentation failed on
   |correctly compiled mixed C  |correctly compiled mixed C
   |and C++ code|and C++ code


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

[Bug middle-end/39641] Compiling Linux 2.6.28.6 ends with a segfault on net/core/skbuff.c

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2009-04-22 23:39 ---
Can you give the output of gcc -v?


-- 


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

[Bug gcov-profile/39609] hidden symbol `__gcov_init' in /usr/lib64/gcc-lib/x86_64-suse-linux/3.3.3/libgcc.a(_gcov.oS) is referenced by DSO

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-04-22 23:34 ---
How is the libraries build?  While linking do you use -fprofile-arcs
-ftest-coverage?


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug libstdc++/39491] [4.4/4.5 regression] symbol __signb...@glibcxx_3.4 in libstdc++ not exported anymore

[joseph at codesourcery dot com]

--- Comment #20 from joseph at codesourcery dot com  2009-04-22 23:34 
---
Subject: Re:  [4.4/4.5 regression] symbol __signb...@glibcxx_3.4
 in libstdc++ not exported anymore

On Wed, 22 Apr 2009, dave at hiauly1 dot hia dot nrc dot ca wrote:

> >  From glibc's perspective there is no such thing as having double
> > and long double with the same size, there is only a configuration
> > where double exists and all the long double functions alias to their
> > double equivalents. The hppa port sets long-double-fcts = no in glibc
> > and this causes all the aliases to be created, otherwise you'd never
> > be able to link anything that used `l' ending math functions. Defining
> > __NO_LONG_DOUBLE_MATH is just another step in the right direction to
> > avoid using long double functions, and use the double functions instead.
> 
> My concern is that this may remove the `l' ending math functions
> completely and their declarations.  Unless the ABI is bumped, this
> may break existing code.  It not at all clear to me that this is
> compatible with C99.

Correct, removing these declarations (as glibc does on these platforms - I 
think SH is the only one affected not in ports) is not conforming to C99, 
whereas having the types the same width (but distinct types at the C 
language level) with the declarations present does conform.  This is on my 
list of C standards issues in glibc, but I think it (and some other 
issues) may be deliberate on the part of the glibc maintainers.

glibc does provide the functions on affected platforms, it just doesn't 
provide the required header declarations of them in math.h and complex.h.


-- 


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

[Bug gcov-profile/39609] hidden symbol `__gcov_init' in /usr/lib64/gcc-lib/x86_64-suse-linux/3.3.3/libgcc.a(_gcov.oS) is referenced by DSO

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|major   |normal


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

[Bug c/39606] expression statements lose excess precision

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-04-22 23:33 ---
Confirmed.


-- 

pinskia 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-04-22 23:33:15
   date||


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

[Bug target/39549] Nonoptimal byte load. mov (%rdi),%al better then movzbl (%rdi),%eax

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-04-22 23:32 ---
Confirmed.


-- 

pinskia 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-04-22 23:32:48
   date||


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

[Bug other/39851] gcc -Q --help=target does not list extensions selected by -march=

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-04-22 23:29 ---
Confirmed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|enhancement |trivial
 Status|UNCONFIRMED |NEW
  Component|driver  |other
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-04-22 23:29:02
   date||


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

[Bug target/37784] inefficient code for double compare double yielding double

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-04-22 23:25 ---
Fixed in 4.5.0:
cmpltsd %xmm0, %xmm1
movsd   .LC1(%rip), %xmm2
xorpd   %xmm0, %xmm0
andpd   %xmm1, %xmm2
orpd%xmm2, %xmm0
ret


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug c/31499] rejects vector int a[] = {1,1,1,1,1};

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2009-04-22 23:23 ---
Fixed.


-- 

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=31499

[Bug c/31499] rejects vector int a[] = {1,1,1,1,1};

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2009-04-22 23:23 ---
Subject: Bug 31499

Author: pinskia
Date: Wed Apr 22 23:22:53 2009
New Revision: 146628

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146628
Log:
2009-04-22  Andrew Pinski  

PR C/31499
* c-typeck.c (process_init_element): Treat VECTOR_TYPE like ARRAY_TYPE
and RECORD_TYPE/UNION_TYPE.  When outputing the actual element and the
value is a VECTOR_CST, the element type is the element type of the
vector.

2009-04-22  Andrew Pinski  

PR C/31499
* gcc.dg/vector-init-1.c: New testcase.
* gcc.dg/vector-init-2.c: New testcase.


Added:
trunk/gcc/testsuite/gcc.dg/vector-init-1.c
trunk/gcc/testsuite/gcc.dg/vector-init-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-typeck.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug target/38571] [arm] -mthumb generates unnecessary padding between functions

[ramana at gcc dot gnu dot org]

-- 

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-04-22 23:09:35
   date||


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

[Bug tree-optimization/24694] Address taken and addressable variables and call clobber

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2009-04-22 23:09 ---
This problem is harder than what is mentioned, I am going to close this as
won't fix.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX


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

[Bug libstdc++/39491] [4.4/4.5 regression] symbol __signb...@glibcxx_3.4 in libstdc++ not exported anymore

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #19 from dave at hiauly1 dot hia dot nrc dot ca  2009-04-22 
23:06 ---
Subject: Re:  [4.4/4.5 regression] symbol __signb...@glibcxx_3.4 in libstdc++
not exported anymore

> Perhaps I wasn't as clear as I should have been. The glibc port for
> hppa has always been configured never to build any long double code,
> and has always assumed that long double is not a distinct type.

However, it appears to provide weak aliases for the `l' ending math
functions.

>  From glibc's perspective there is no such thing as having double
> and long double with the same size, there is only a configuration
> where double exists and all the long double functions alias to their
> double equivalents. The hppa port sets long-double-fcts = no in glibc
> and this causes all the aliases to be created, otherwise you'd never
> be able to link anything that used `l' ending math functions. Defining
> __NO_LONG_DOUBLE_MATH is just another step in the right direction to
> avoid using long double functions, and use the double functions instead.

My concern is that this may remove the `l' ending math functions
completely and their declarations.  Unless the ABI is bumped, this
may break existing code.  It not at all clear to me that this is
compatible with C99.

See for example
http://www.cygwin.com/ml/libc-alpha/2005-03/msg00172.html

Dave


-- 


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

[Bug target/23451] Redundant reloading from stack frame on i386

[pinskia at gcc dot gnu dot org]

--- Comment #19 from pinskia at gcc dot gnu dot org  2009-04-22 23:06 
---
Fixed in 4.3.0 by the new register allocator (IRA).


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
   Keywords||ra
 Resolution||FIXED
   Target Milestone|--- |4.3.0


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

[Bug libstdc++/39491] [4.4/4.5 regression] symbol __signb...@glibcxx_3.4 in libstdc++ not exported anymore

[carlos at codesourcery dot com]

--- Comment #18 from carlos at codesourcery dot com  2009-04-22 22:42 
---
Subject: Re:  [4.4/4.5 regression] symbol __signb...@glibcxx_3.4
 in libstdc++ not exported anymore

>> * Original submitter is incorrect, there has never been a
>> __signb...@glibcxx_3.4 symbol, and there should not be one now?
> 
> The symbol is present in libstdc++.so.6.0.9 and libstdc++.so.6.0.10,
> but not in libstdc++.so.6.0.8 or libstdc++.so.6.0.11.

If that's the case, then libstdc++ is to blame, and Benjamin's
hackish patch should be reviewed and checked in.

>> * I have changed the glibc hppa-linux-gnu port to define 
>> __NO_LONG_DOUBLE_MATH,
>> and therefore the signbit macro, even in the abscense of optimization, will
>> always return a valid signbit function based on the type size.
> 
> I'm not convinced this is a good idea at this point.  As far as I know,
> it is ok to have the same size for double and long double.  However,
> they are distinct types.

Perhaps I wasn't as clear as I should have been. The glibc port for
hppa has always been configured never to build any long double code,
and has always assumed that long double is not a distinct type.
 From glibc's perspective there is no such thing as having double
and long double with the same size, there is only a configuration
where double exists and all the long double functions alias to their
double equivalents. The hppa port sets long-double-fcts = no in glibc
and this causes all the aliases to be created, otherwise you'd never
be able to link anything that used `l' ending math functions. Defining
__NO_LONG_DOUBLE_MATH is just another step in the right direction to
avoid using long double functions, and use the double functions instead.

The upside is that, if and when, long double on hppa becomes the 128-bit
quad long double, we can just follow the tried-and-tested procedure to
migrate the glibc math routines.

Cheers,
Carlos.


-- 


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

[Bug tree-optimization/21997] vectorization inhibited by gcc's choice to view an integer as a boolean

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2009-04-22 22:41 ---
Hmm, I think there is a regression here in 4.3 and above (since
tuplicafication) in that we don't vectorize even the ?2:1 loop.


-- 


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

[Bug bootstrap/38892] gcc 4.4.0 20090104 - natVMVirtualMachine.cc:903: error: request for member 'frame_type' in ...

[dave dot korn dot cygwin at gmail dot com]

--- Comment #9 from dave dot korn dot cygwin at gmail dot com  2009-04-22 
22:38 ---
Created an attachment (id=17679)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17679&action=view)
Part two of fix

This renames the DEBUG macro to __GCJ_DEBUG throughout.  It fixed the build in
my tree where I had a whole bunch of local patches, now testing it in a clean
tree with the extraneous changes removed.


-- 


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

[Bug rtl-optimization/14237] suboptimal comparison between long and long long

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2009-04-22 22:20 ---
We now get:
foo:
movl$1, %eax
movlg+4, %edx
testl   %edx, %edx
jne .L3
movl4(%esp), %edx
cmplg, %edx
jb  .L3
ret
.p2align 2,,3
.L3:
xorl%eax, %eax
ret

Fixed and has been fixed since 4.3.0.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.3.0


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

[Bug tree-optimization/15158] Unnecessary register moves

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2009-04-22 22:10 ---
Fixed in at least 4.3.2.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.3.2


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

[Bug c/39855] [4.3 Regression] Shift optimization discards operands' side effects

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2009-04-22 22:06 ---
Fixed so far for 4.4.1 and 4.5.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail|4.1.2 4.3.3 4.4.0 4.5.0 |4.1.2 4.3.3 4.4.0
  Known to work|3.4.6 4.0.1 |3.4.6 4.0.1 4.4.1 4.5.0
Summary|[4.3/4.4/4.5 Regression]|[4.3 Regression] Shift
   |Shift optimization discards |optimization discards
   |operands' side effects  |operands' side effects
   Target Milestone|--- |4.3.4


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

[Bug target/39856] [4.4 Regression] ICE in subst_stack_regs_pat, at reg-stack.c:1386

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2009-04-22 22:05 ---
ICEs since http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143757


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-04-22 22:05:27
   date||


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

[Bug c/39855] [4.3/4.4/4.5 Regression] Shift optimization discards operands' side effects

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2009-04-22 22:03 ---
Subject: Bug 39855

Author: jakub
Date: Wed Apr 22 22:02:54 2009
New Revision: 146622

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146622
Log:
PR c/39855
* fold-const.c (fold_binary) : When optimizing
into 0, use omit_one_operand.

* gcc.dg/torture/pr39855.c: New test.

Added:
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/torture/pr39855.c
  - copied unchanged from r146617,
trunk/gcc/testsuite/gcc.dg/torture/pr39855.c
Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/fold-const.c
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug tree-optimization/18842] Weak optimization on global references

[pinskia at gcc dot gnu dot org]

--- Comment #10 from pinskia at gcc dot gnu dot org  2009-04-22 22:02 
---
Fixed in 4.4.0 and above.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.4.0


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

[Bug c/39855] [4.3/4.4/4.5 Regression] Shift optimization discards operands' side effects

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2009-04-22 21:58 ---
Subject: Bug 39855

Author: jakub
Date: Wed Apr 22 21:57:52 2009
New Revision: 146617

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146617
Log:
PR c/39855
* fold-const.c (fold_binary) : When optimizing
into 0, use omit_one_operand.

* gcc.dg/torture/pr39855.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr39855.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug tree-optimization/36188] missed CCP

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2009-04-22 21:56 ---
This also happens in 189.lucas where it prevents propagating constant 1 array
strides to the access.


-- 


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

[Bug tree-optimization/30187] accessing an element via a "pointer" on a vector does not cause vec_extract to be used (non constant index)

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-04-22 21:56 ---
Confirmed.


-- 

pinskia 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-04-22 21:56:33
   date||


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

[Bug fortran/39782] [4.3/4.4 Regression] IO depends on uninitialised value

[jb at gcc dot gnu dot org]

--- Comment #8 from jb at gcc dot gnu dot org  2009-04-22 21:37 ---
Having a shot at backporting, assigning to myself.


-- 

jb at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jb at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-04-16 18:37:09 |2009-04-22 21:37:24
   date||


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

[Bug tree-optimization/32226] Missed optimization caused by copy loop header (yes a weird case)

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2009-04-22 21:32 ---
Actually this comes down to:
int f(int a, int c)
{
  if (a) return a*c;
  return 0;
}

It might be faster to use the branch rather than the multiple, I don't know and
I think it depends on the target.


-- 


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

[Bug tree-optimization/19719] missed optimization on boolean operation with boolean arguments

[pinskia at gcc dot gnu dot org]

--- Comment #12 from pinskia at gcc dot gnu dot org  2009-04-22 21:25 
---
On the trunk we get:
f:
cmpb$1, 4(%esp)
sbbl%eax, %eax
notl%eax
andb8(%esp), %al
ret

With the default arguments on i686-linux-gnu.

With -march=i686:
f:
xorl%eax, %eax
cmpb$0, 4(%esp)
cmovne  8(%esp), %eax
ret
With -march=i386:
movb8(%esp), %al
cmpb$0, 4(%esp)
jne .L2
xorl%eax, %eax
.L2:
ret

So Fixed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.4.0


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

[Bug c++/39854] Segfault with a pointer of array of pointers

[ryancacophony at gmail dot com]

--- Comment #3 from ryancacophony at gmail dot com  2009-04-22 21:20 ---
(In reply to comment #2)
> This is likely because a PCH is used and is not included from the main .cpp
> file (but Melody.h).  Try using -include note.h on the commandline to use 
> PCHs.
> Including a PCH from not the toplevel source is not supported.
> 

Yeah, using that include thing worked..I still don't understand exactly
why- where was I using a PCH? (I just looked up the term when you responded)


-- 


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

[Bug rtl-optimization/17838] spills are not re-used

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2009-04-22 21:17 ---
I think this was fixed for GCC 4.4.0 with the IRA but I can't test right now
since the preprocessed source uses builtin functions which are no longer exist
in 4.4.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||ra


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

[Bug c++/16269] g++ doesn't reuse stack space

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2009-04-22 21:12 ---
This has been fixed for awhile now, since at least 4.3.0.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.3.0


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

[Bug target/39856] [4.4 Regression] ICE in subst_stack_regs_pat, at reg-stack.c:1386

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-04-22 21:08 ---
Created an attachment (id=17678)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17678&action=view)
reduced testcase


-- 


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

[Bug target/39856] New: [4.4 Regression] ICE in subst_stack_regs_pat, at reg-stack.c:1386

[rguenth at gcc dot gnu dot org]

SPEC CPU 2006 453.povray ICEs compiling super.cpp with

> g++-4.4 -S -O3 -fomit-frame-pointer -msse3 -m32 -march=i586 super.ii
super.cpp: In function 'void pov::Superellipsoid_Normal(double*, pov::OBJECT*,
pov::INTERSECTION*)':
super.cpp:515: internal compiler error: in subst_stack_regs_pat, at
reg-stack.c:1386
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: [4.4 Regression] ICE in subst_stack_regs_pat, at reg-
stack.c:1386
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
GCC target triplet: i?86-*-*


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

[Bug tree-optimization/15452] [tree-ssa] Optimize cascaded a = a == 0;

[pinskia at gcc dot gnu dot org]

--- Comment #8 from pinskia at gcc dot gnu dot org  2009-04-22 21:05 ---
This has been fixed for a while now, at least since 4.4.0.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.4.0


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

[Bug c/37724] "initialization from incompatible pointer type" does not say which field is being initialized

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2009-04-22 20:58 ---
With the patch we have issues with %< and %> not being converted to quotes, I
am going to unassign myself for now.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|pinskia at gcc dot gnu dot  |unassigned at gcc dot gnu
   |org |dot org
 Status|ASSIGNED|NEW


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

[Bug tree-optimization/39839] [4.3/4.4/4.5 regression] loop invariant motion causes stack spill

[vmakarov at redhat dot com]

--- Comment #3 from vmakarov at redhat dot com  2009-04-22 20:37 ---
Actually YARA did not have a rematerialization as IRA.  Reload has a primitive
rematerialization of constant values.

Although about 5 years I did implemented a register pressure relief through
rematerialization which is close to Simpson's thesis.  It was reported on the
2nd GCC summit.  I had a mixed feeling about this: wrong register pressure
calculation (because we have not cover classes at that time), small improvement
but a few additional percents to compilation time.

Probably it is time to return to this and make it optional or default which
will eat a chunk of your recent 5% compilation time improvement :)  I'll try to
include this in my plans.


-- 


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

[Bug c/39855] [4.3/4.4/4.5 Regression] Shift optimization discards operands' side effects

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2009-04-22 20:20 ---
Argh, attached wrong version of the patch, the arguments to omit_one_operand of
course need to be swapped.  Sorry.


-- 


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

[Bug c/39855] [4.3/4.4/4.5 Regression] Shift optimization discards operands' side effects

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2009-04-22 20:17 ---
Created an attachment (id=17677)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17677&action=view)
gcc45-pr39855.patch

Fix I'm going to bootstrap/regtest.


-- 


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

[Bug rtl-optimization/39762] [4.4 Regression] IRA ICE with -msoft-float

[vmakarov at gcc dot gnu dot org]

--- Comment #6 from vmakarov at gcc dot gnu dot org  2009-04-22 20:16 
---
Subject: Bug 39762

Author: vmakarov
Date: Wed Apr 22 20:16:13 2009
New Revision: 146612

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146612
Log:
2009-04-22  Vladimir Makarov  

PR rtl-optimization/39762
* ira-int.h (ira_register_move_cost, ira_may_move_in_cost,
ira_may_move_out_cost): Add comments about way of their usage.
(ira_get_register_move_cost, ira_get_may_move_cost): New functions.

* ira-conflicts.c (process_regs_for_copy): Use function
ira_get_register_move_cost instead of global
ira_register_move_cost.

* ira-color.c (update_copy_costs, calculate_allocno_spill_cost,
color_pass, move_spill_restore, update_curr_costs): Ditto.

* ira-lives.c (process_single_reg_class_operands): Ditto.

* ira-emit.c (emit_move_list): Ditto.

* ira-costs.c (copy_cost): Don't call ira_init_register_move_cost.
(record_reg_classes): Ditto.  Use functions
ira_get_register_move_cost and ira_get_may_move_cost instead of
global vars ira_register_move_cost, ira_may_move_out_cost and
ira_may_move_in_cost.
(record_address_regs): Don't call ira_init_register_move_cost.
Use function ira_get_may_move_cost instead of global
ira_may_move_in_cost.
(process_bb_node_for_hard_reg_moves): Use function
ira_get_register_move_cost instead of global ira_register_move_cost.
(ira_costs): Don't call ira_init_register_move_cost.


Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/ira-color.c
branches/gcc-4_4-branch/gcc/ira-conflicts.c
branches/gcc-4_4-branch/gcc/ira-costs.c
branches/gcc-4_4-branch/gcc/ira-emit.c
branches/gcc-4_4-branch/gcc/ira-int.h
branches/gcc-4_4-branch/gcc/ira-lives.c


-- 


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

[Bug middle-end/39824] [4.5 Regression] ice in fold-const.c

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2009-04-22 19:55 ---
Subject: Bug 39824

Author: rguenth
Date: Wed Apr 22 19:55:24 2009
New Revision: 146611

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146611
Log:
2009-04-22  Richard Guenther  

PR tree-optimization/39824
* tree-ssa-ccp.c (fold_const_aggregate_ref): For INDIRECT_REFs
make sure the types are compatible.

* gcc.c-torture/compile/pr39824.c: New testcase.

Added:
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr39824.c
Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
branches/gcc-4_4-branch/gcc/tree-ssa-ccp.c


-- 


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

[Bug middle-end/39824] [4.5 Regression] ice in fold-const.c

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2009-04-22 19:55 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|4.5.0   |4.4.1


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

[Bug inline-asm/39847] 16 symbolic register names generates error: more than 30 operands in 'asm'

[d at teklibre dot com]

--- Comment #19 from d at teklibre dot com  2009-04-22 19:48 ---
@Andrew: I agree with Jakub's point too, but don't believe merely doubling the
number of operands will hurt much. Am trying it against 4.3.2... it's building
as I write. 

When I figure out how to safely build 4.4 I will look at its code quality and
fiddle in the same ways.

I don't understand how using named register variables would help except for
making this slightly easier to write in C + snippets of asm. symbolic assembly,
and using the occasional complex memory-addressing instruction helps a lot. I
will think on it.

@H.J: I will provide an example when I get the spare brain cells. It will pay
for me to test against 4.4 first, however. 

I very much appreciate all the attention paid to this today. I am going away to
hack for a while while my cpu glows from building gcc.


-- 


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

[Bug c++/39854] Segfault with a pointer of array of pointers

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-04-22 19:36 ---
This is likely because a PCH is used and is not included from the main .cpp
file (but Melody.h).  Try using -include note.h on the commandline to use PCHs.
Including a PCH from not the toplevel source is not supported.


-- 


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

[Bug libstdc++/39491] [4.4/4.5 regression] symbol __signb...@glibcxx_3.4 in libstdc++ not exported anymore

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #17 from dave at hiauly1 dot hia dot nrc dot ca  2009-04-22 
19:32 ---
Subject: Re:  [4.4/4.5 regression] symbol __signb...@glibcxx_3.4 in libstdc++
not exported anymore

> * Original submitter is incorrect, there has never been a
> __signb...@glibcxx_3.4 symbol, and there should not be one now?

The symbol is present in libstdc++.so.6.0.9 and libstdc++.so.6.0.10,
but not in libstdc++.so.6.0.8 or libstdc++.so.6.0.11.

> * I have changed the glibc hppa-linux-gnu port to define 
> __NO_LONG_DOUBLE_MATH,
> and therefore the signbit macro, even in the abscense of optimization, will
> always return a valid signbit function based on the type size.

I'm not convinced this is a good idea at this point.  As far as I know,
it is ok to have the same size for double and long double.  However,
they are distinct types.

Dave


-- 


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

[Bug c++/39639] no diagnostic for ill-formed pack expansion

[dodji at gcc dot gnu dot org]

--- Comment #5 from dodji at gcc dot gnu dot org  2009-04-22 19:21 ---
Fixed in 4.3, 4.4 and 4.5.


-- 

dodji at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/39639] no diagnostic for ill-formed pack expansion

[dodji at gcc dot gnu dot org]

--- Comment #4 from dodji at gcc dot gnu dot org  2009-04-22 19:17 ---
Subject: Bug 39639

Author: dodji
Date: Wed Apr 22 19:17:18 2009
New Revision: 146610

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146610
Log:
2009-04-22  Dodji Seketeli  

gcc/cp/ChangeLog:
PR c++/39639
* parser.c (cp_parser_template_argument_list): Display an error
when an ellipsis is not preceded by a parameter pack. Also, warn
about variadic templates usage without -std=c++0x.

gcc/testsuite/ChangeLog:
PR c++/39639
* g++.dg/cpp0x/pr39639.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr39639.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/39639] no diagnostic for ill-formed pack expansion

[dodji at gcc dot gnu dot org]

--- Comment #3 from dodji at gcc dot gnu dot org  2009-04-22 19:16 ---
Subject: Bug 39639

Author: dodji
Date: Wed Apr 22 19:16:13 2009
New Revision: 146609

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146609
Log:
2009-04-22  Dodji Seketeli  

gcc/cp/ChangeLog:
PR c++/39639
* parser.c (cp_parser_template_argument_list): Display an error
when an ellipsis is not preceded by a parameter pack. Also, warn
about variadic templates usage without -std=c++0x.

gcc/testsuite/ChangeLog:
PR c++/39639
* g++.dg/cpp0x/pr39639.C: New test.


Added:
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/cpp0x/pr39639.C
Modified:
branches/gcc-4_4-branch/gcc/cp/ChangeLog
branches/gcc-4_4-branch/gcc/cp/parser.c
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/39639] no diagnostic for ill-formed pack expansion

[dodji at gcc dot gnu dot org]

--- Comment #2 from dodji at gcc dot gnu dot org  2009-04-22 19:13 ---
Subject: Bug 39639

Author: dodji
Date: Wed Apr 22 19:13:40 2009
New Revision: 146608

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146608
Log:
2009-04-22  Dodji Seketeli  

gcc/cp/ChangeLog:
PR c++/39639
* parser.c (cp_parser_template_argument_list): Display an error
when an ellipsis is not preceded by a parameter pack. Also, warn
about variadic templates usage without -std=c++0x.

gcc/testsuite/ChangeLog:
PR c++/39639
* g++.dg/cpp0x/pr39639.C: New test.


Added:
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/cpp0x/pr39639.C
Modified:
branches/gcc-4_3-branch/gcc/cp/ChangeLog
branches/gcc-4_3-branch/gcc/cp/parser.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug c/39855] [4.3/4.4/4.5 Regression] Shift optimization discards operands' side effects

[jakub at gcc dot gnu dot org]

-- 

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|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
  Known to fail||4.1.2 4.3.3 4.4.0 4.5.0
  Known to work||3.4.6 4.0.1
   Last reconfirmed|-00-00 00:00:00 |2009-04-22 19:09:52
   date||
Summary|Shift optimization discards |[4.3/4.4/4.5 Regression]
   |operands' side effects  |Shift optimization discards
   ||operands' side effects


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

[Bug inline-asm/39847] 16 symbolic register names generates error: more than 30 operands in 'asm'

[hjl dot tools at gmail dot com]

--- Comment #18 from hjl dot tools at gmail dot com  2009-04-22 19:03 
---
(In reply to comment #6)
> Pinska: Actually, no. I started with the intrinsics and looked hard at what 
> the
> code scheduler was doing before settling on rewriting this in inline 
> assembly. 
> 
> The intrinsics have several problems that effect the code quality in this 
> case.
> 

Please provide an example to show code quality problems with intrinsics.
I will take a look.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||hjl dot tools at gmail dot
   ||com


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

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

[gcc at breakpoint dot cc]

--- Comment #3 from gcc at breakpoint dot cc  2009-04-22 18:41 ---
Wasn't 

# echo 'int main(void) { return 0; }' > file.c

not enough or did you overlook that part? 

The -E output is pretty much the same, it is:

$ cat test.i 
# 1 "test.c"
# 1 ""
# 1 ""
# 1 "test.c"
int main(void)
{
 return 0;
}


---
The -S output (I guess you meant that) would be:

$ m68k-linux-gnu-gcc -o test.S test.c -static -pg -S && cat test.S 
#NO_APP
.file   "test.c"
.text
.align  2
.globl  main
.type   main, @function
main:
link.w %fp,#0
.data
.align  2
.LP2:
.long   0
.text
lea (.LP2,%pc),%a1
jbsr _mcount
clr.l %d0
unlk %fp
rts
.size   main, .-main
.ident  "GCC: (Sourcery G++ Lite 4.3-43) 4.3.2"
.section.note.GNU-stack,"",@progbits
 

And my rec for the fix was to get rid of the lea before the branch to the
_mcount call. However someone might need it, I'm not sure.


-- 


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

[Bug inline-asm/39847] 16 symbolic register names generates error: more than 30 operands in 'asm'

[aph at gcc dot gnu dot org]

--- Comment #17 from aph at gcc dot gnu dot org  2009-04-22 18:40 ---
I agree with Jakub's point.

David, can you try instead of register operands using named register variables
instead?  I think that may work, unless there is some other limit of which I'm
unaware.


-- 


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

[Bug c/39855] New: Shift optimization discards operands' side effects

[foo at mailinator dot com]

#include 
int foo() {
puts("Hello world");
return 0;
}
int main() {
foo() << 30 << 2;
return (unsigned)foo() >> 16 >> 16;
}

% gcc test.c
% ./a.out
%


-- 
   Summary: Shift optimization discards operands' side effects
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: foo at mailinator dot com


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

[Bug libstdc++/39491] [4.4/4.5 regression] symbol __signb...@glibcxx_3.4 in libstdc++ not exported anymore

[carlos at codesourcery dot com]

--- Comment #16 from carlos at codesourcery dot com  2009-04-22 18:33 
---
So what is required to close this issue?

* Original submitter is incorrect, there has never been a
__signb...@glibcxx_3.4 symbol, and there should not be one now?

* glibc on hppa-linux-gnu has never had a __signbitl symbol.

* I have changed the glibc hppa-linux-gnu port to define __NO_LONG_DOUBLE_MATH,
and therefore the signbit macro, even in the abscense of optimization, will
always return a valid signbit function based on the type size.


-- 


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

[Bug inline-asm/39847] 16 symbolic register names generates error: more than 30 operands in 'asm'

[d at teklibre dot com]

--- Comment #16 from d at teklibre dot com  2009-04-22 18:30 ---
@Jakub/Andrew:

max_recog_operands =
MIN(FIRST_PSEUDO_REGISTER*2,SOME_SANE_VALUE_DERIVED_FROM_SMASHING_THE_STACK_ON_IA64)
; // ?

I certainly am not in a position to make a one line change to gcc and test it
on ia64 or other insane architectures like vmx,intel avx, etc, etc... I also
somehow doubt that a human could deal with 668 registers (a code generator
might)

this human, at least, copes with 32 registers just fine.


-- 


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

[Bug inline-asm/39847] 16 symbolic register names generates error: more than 30 operands in 'asm'

[pinskia at gcc dot gnu dot org]

--- Comment #15 from pinskia at gcc dot gnu dot org  2009-04-22 18:03 
---
(In reply to comment #13)
> That old huh? Given that I/O operands take two virtual regs... methinks that
> the history of this is more of an x86ism... 
> 
> and symbolic register parameters date back to gcc 3.1

They date back to 1.0 :).  And x86 was not the first target that GCC
implemented (m68k was definitely early on).  So the argument about it being an
x86ism is wrong.  And really increasing the limit will not help in really
because the bigger the inline-asm, the more likely the program will not work.


-- 


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

[Bug inline-asm/39847] 16 symbolic register names generates error: more than 30 operands in 'asm'

[d at teklibre dot com]

--- Comment #14 from d at teklibre dot com  2009-04-22 18:00 ---
@Jakub:

I'm going to build this thing today. (once I figure out the best way, and I
figure it will take a while, even so) Are there any specific tests I should run
to check for performance issues? I expect any stack overflows to show up
quickly. :)

Admittedly, in this case (x86_64) we're only talking about doubling the number
of registers available, not the extreme ia64 case... 


-- 


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

[Bug inline-asm/39847] 16 symbolic register names generates error: more than 30 operands in 'asm'

[d at teklibre dot com]

--- Comment #13 from d at teklibre dot com  2009-04-22 17:55 ---
@Andrew
>I suspect the reason the limit is 30 is that when that code was written the
>largest register set was 32 registers, 2 of which were reserved to the
>implementation.  Inline asm hasn't kept up with the hardware.

That old huh? Given that I/O operands take two virtual regs... methinks that
the history of this is more of an x86ism... 

and symbolic register parameters date back to gcc 3.1


-- 


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

[Bug inline-asm/39847] 16 symbolic register names generates error: more than 30 operands in 'asm'

[jakub at gcc dot gnu dot org]

--- Comment #12 from jakub at gcc dot gnu dot org  2009-04-22 17:51 ---
That's not going to fly very well e.g. on ia64:
config/ia64/ia64.h:#define FIRST_PSEUDO_REGISTER 334
then we have automatic arrays like:
char operands_match[MAX_RECOG_OPERANDS][MAX_RECOG_OPERANDS];
etc., many of them are cleared quite often, so such a change could sometimes
lead to overflowing stack and definitely to a noticeable slowdown.
Or struct recog_data contains many MAX_RECOG_OPERANDS sized arrays in it.
Or e.g.:
extern struct operand_alternative
recog_op_alt[MAX_RECOG_OPERANDS][MAX_RECOG_ALTERNATIVES];
where operand_alternative struct is pretty large.
Many functions also iterate from 0 to MAX_RECOG_OPERANDS.


-- 


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

[Bug inline-asm/39847] 16 symbolic register names generates error: more than 30 operands in 'asm'

[aph at gcc dot gnu dot org]

--- Comment #11 from aph at gcc dot gnu dot org  2009-04-22 17:47 ---
I suspect the reason the limit is 30 is that when that code was written the
largest register set was 32 registers, 2 of which were reserved to the
implementation.  Inline asm hasn't kept up with the hardware.


-- 


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

[Bug inline-asm/39847] 16 symbolic register names generates error: more than 30 operands in 'asm'

[aph at redhat dot com]

--- Comment #10 from aph at redhat dot com  2009-04-22 17:33 ---
Subject: Re:  16 symbolic register names generates error:
 more than 30 operands in 'asm'


> 0) I will build gcc-4.4 and try that. I will also make the 1 line patch to it
> to try increasing the number of asm params, and try that. I would prefer that
> someone with more guts inside the guts of gcc do the latter, I fear I would
> rapidly end up over my head. Is it a magic number or just a stupid default?

Try

max_recog_operands = FIRST_PSEUDO_REGISTER*2


-- 


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

[Bug c++/39854] Segfault with a pointer of array of pointers

[ryancacophony at gmail dot com]

--- Comment #1 from ryancacophony at gmail dot com  2009-04-22 17:31 ---
Created an attachment (id=17676)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17676&action=view)
ii file as requested


-- 


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

[Bug inline-asm/39847] 16 symbolic register names generates error: more than 30 operands in 'asm'

[d at teklibre dot com]

--- Comment #9 from d at teklibre dot com  2009-04-22 17:24 ---
Pinskia:

It is going to take me a long time to address these issues piecemeal, so...

0) I will build gcc-4.4 and try that. I will also make the 1 line patch to it
to try increasing the number of asm params, and try that. I would prefer that
someone with more guts inside the guts of gcc do the latter, I fear I would
rapidly end up over my head. Is it a magic number or just a stupid default?

re 1) I am using -mtune=core2 -O3 which is correct. 

I note, that in looking at the generated code today, without that and with -O2,
using the non-sse version (just doubles), -O2 generates the following code
sequence for

left [0] += icoeff * filter->buffer [data_index];
left [1] += icoeff * filter->buffer [data_index+1];

 - where left[0] and icoeff are doubles, filter->buffer[data_index] is a float

movss  (%r11),%xmm0
cvtps2pd %xmm0,%xmm0; cvtss2sd would be more correct and faster on most x86_64
arches prior to the k10 and core2.
... mult and add elided, second line elided ... 

(-O3 -mtune will do a cvtss2sd (%r9), %xmm0 which is better)

converting this into the SSE2 equivalent can't be expressed in the intrinsics
(requires an explicit, separate, load & cast). Doing it as inline assembly
ended up generating extra leas, would not get scheduled well, and stuff like
that. 

... like I said, it will take me a while to discuss this piecemeal and going to
0) is the right thing. 


-- 


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

[Bug c++/33979] support for char16_t, char32_t

[paolo dot carlini at oracle dot com]

--- Comment #15 from paolo dot carlini at oracle dot com  2009-04-22 17:23 
---
In order to make progress on the locale bits while following the usual
strategies of v3, we need some support from the underlying glibc, not
forthcoming, AFAIK...


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||paolo dot carlini at oracle
   ||dot com


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

[Bug c/39808] warn_unused_result fails to produce warning

[sandmann at daimi dot au dot dk]

--- Comment #3 from sandmann at daimi dot au dot dk  2009-04-22 17:03 
---
Why not? If not using the return value is a bug, then it's also a bug if it
isn't used after being passed through a statement expression.


-- 


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

[Bug middle-end/39794] [4.4/4.5 Regression] Miscompile with -O2 -funroll-loops

[alexey dot zaytsev at gmail dot com]

--- Comment #8 from alexey dot zaytsev at gmail dot com  2009-04-22 16:57 
---
Created an attachment (id=17675)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17675&action=view)
The gcc 4.3.3 testcase.

Sorry, wrong file.


-- 

alexey dot zaytsev at gmail dot com changed:

   What|Removed |Added

  Attachment #17674|0   |1
is obsolete||


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

[Bug fortran/39850] Too strict checking for procedures as actual argument

[janus at gcc dot gnu dot org]

-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||janus at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-04-22 16:55:59
   date||


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