[Bug middle-end/37248] [4.3/4.4 Regression] regression 4.3.1 -> 4.3.2-rc transformation bitfield to individual bytes

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2008-09-01 07:17 ---
Created an attachment (id=16177)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16177&action=view)
gcc43-pr37248.patch

Patch I've bootstrapped/regtested on 4 linux arches on 4.3 branch.


-- 


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

[Bug fortran/37274] [Regression 4.4 (and 4.3?)] error: type name is ambiguous.

[sfilippone at uniroma2 dot it]

--- Comment #14 from sfilippone at uniroma2 dot it  2008-09-01 08:13 ---
(In reply to comment #11)

> My point is this:
> As you said in your first comment, there is no ambiguity in your code. 
> vector is defined in only one module which is used when needed in other
> modules.
> Moreover you use private statements to prevent use associated entities from
> being exported in those modules. 
Well, the code would be legal even without the private statement, I can USE
definitions directly or indirectly as many times as I like. Or at least so I
understand.
Salvatore


-- 


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

[Bug bootstrap/37277] bootstrap failure with --with-dwarf2 on Solaris 10

[jwakely dot gcc at gmail dot com]

--- Comment #4 from jwakely dot gcc at gmail dot com  2008-09-01 08:39 
---
Yes, I realise that, but it's still documented and it was apparently harmless
with 4.2.2


-- 


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

[Bug pch/37307] [4.4 Regression]: g++.dg/pch/system-2.C

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.4.0


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

[Bug fortran/35154] Unable to reference symbols in Fortran COMMON due to .stabs format

[dominiq at lps dot ens dot fr]

--- Comment #5 from dominiq at lps dot ens dot fr  2008-09-01 09:37 ---
On i686-apple-darwin9, I have the following failures in both 32 and 64 bit
modes:

FAIL: gfortran.dg/debug/pr35154-dwarf2.f -gdwarf-2 scan-assembler DW_AT_name:
"__BLNK__"
FAIL: gfortran.dg/debug/pr35154-dwarf2.f -gdwarf-2 scan-assembler DW_AT_name:
"label"

Looking at the assembly code I see:

...
.ascii "__BLNK__\0" # DW_AT_name
.ascii "i\0"# DW_AT_name
.ascii "j\0"# DW_AT_name
.ascii "label\0"# DW_AT_name
...

I thing that changing

C { dg-final { scan-assembler "DW_AT_name: \"__BLNK__\"" } }
C { dg-final { scan-assembler "DW_AT_name: \"label\"" } }

with

C { dg-final { scan-assembler "DW_AT_name: \"__BLNK__.*\"" } }
C { dg-final { scan-assembler "DW_AT_name: \"label.*\"" } }

will fix the failures.


-- 


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

[Bug tree-optimization/37305] [4.4 Regression] ice in set_value_range, at tree-vrp.c:397

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-09-01 09:50 ---
Confirmed.


-- 

rguenth 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||ice-on-valid-code
   Last reconfirmed|-00-00 00:00:00 |2008-09-01 09:50:05
   date||


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

[Bug tree-optimization/37305] [4.4 Regression] ice in set_value_range, at tree-vrp.c:397

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-09-01 09:50 ---
Mine.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-09-01 09:50:05 |2008-09-01 09:50:29
   date||


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

[Bug bootstrap/37308] bootstrap hug on libstdc++.a

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2008-09-01 09:53 
---
Do you mean *hangs* during bootstrap?? Sorry, but it's not at all clear what is
happening exactly on your side.

David, can you follow a bit this... ?


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||dje at watson dot ibm dot
   ||com


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

[Bug bootstrap/37308] bootstrap hug on libstdc++.a

[cnstar9988 at gmail dot com]

--- Comment #2 from cnstar9988 at gmail dot com  2008-09-01 10:15 ---
(In reply to comment #1)
> Do you mean *hangs* during bootstrap?? Sorry, but it's not at all clear what 
> is
> happening exactly on your side.
> David, can you follow a bit this... ?
the bootrap stop at ./conftest for a long time.

I will "remove" TLS check code in libstdc++-v3/configure and test again.
==
  # For TLS support.  

enable_tls=no
gcc_cv_have_tls=no

  # For _Unwind_GetIPInfo.


==
conftest.c
===
__thread int a,b;
int main()
{
  return a==b;
}


-- 


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

[Bug fortran/37310] New: gfortran errors in compilation and the making for upgraded compilers

[petermorgan at grapevine dot net dot au]

My system response to the gcc -v is
[EMAIL PROTECTED] ~]$ gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-cpu=generic --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.3.0 20080428 (Red Hat 4.3.0-8) (GCC) 
[EMAIL PROTECTED] ~]$

The error message is

Running unimake to create Makefile for blsum
System name:  Linux currawong 2.6.25.14-108.fc9.x86_64 #1 SMP Mon Aug 4
13:46:35 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux
System release number translated to  2625
No i86 compiler specification--assuming gfortran (gcc 4.2x)
Makefile for blsum remade by unimake
gfortran -O3 -Wuninitialized -fno-f2c -ffast-math -fno-automatic -fno-backslash
blsum.f  ../gen_util/gen_util_lib.a ../../libraries/matrix/kinv_lib.a
../../libraries/comlib/com_lib.a  -o blsum
rm -f blsum.o
gfortran -O3 -Wuninitialized -fno-f2c -ffast-math -fno-automatic -fno-backslash
ensum.f  ../gen_util/gen_util_lib.a ../../libraries/matrix/kinv_lib.a
../../libraries/comlib/com_lib.a  -o ensum
rm -f ensum.o
gfortran -O3 -Wuninitialized -fno-f2c -ffast-math -fno-automatic -fno-backslash
tssum.f  ../gen_util/gen_util_lib.a ../../libraries/matrix/kinv_lib.a
../../libraries/comlib/com_lib.a  -o tssum
tssum.f: In function 'remove_ejmp':
tssum.f:712: internal compiler error: in set_uids_in_ptset, at
tree-ssa-structalias.c:4773
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make: *** [tssum] Error 1
Failure in make_globk -- install_software terminated
[EMAIL PROTECTED] gamit-10.34]$

First a Lot of background.
I am a numerical guy mainly working as a beta tester on largish GPS and
geodetic programs. In this case it is the MIT GPS suite GAMIT/GLOBK. I have
just recently moved from a 32 bit environment to a 64 bit environment. It hasnt
been all that easy.

The suggestion is that it is GNU rather than our GAMIT code that is at fault,
but this not a given.

I tried several options, all of which generated a second set of errors. These
options all revolved around re-building the GNU program suite
So off I go and get myself a copy of GNU4.3.1 and I attempt to build my own
gfortran rather than use the system one.  The first problems that I run into
are the interdependencies Gnu 4.3.1 requires the latest  mpfr and gmp packages.

Here is what happens
[EMAIL PROTECTED] gcc-4.3.1]$ ../gcc-4.3.1.source/configure
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether ln works... yes
checking whether ln -s works... yes
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for gnatbind... no
checking for gnatmake... no
checking whether compiler driver understands Ada... no
checking how to compare bootstrapped objects... cmp --ignore-initial=16 $$f1
$$f2
checking for correct version of gmp.h... yes
checking for correct version of mpfr.h... no
configure: error: Building GCC requires GMP 4.1+ and MPFR 2.3.0+.
Try the --with-gmp and/or --with-mpfr options to specify their locations.
Copies of these libraries' source code can be found at their respective
hosting sites as well as at ftp://gcc.gnu.org/pub/gcc/infrastructure/.
See also http://gcc.gnu.org/install/prerequisites.html for additional info.
If you obtained GMP and/or MPFR from a vendor distribution package, make
sure that you have installed both the libraries and the header files.
They may be located in separate packages.

BUT the distribution has
 gmp-4.2.2-7.fc9.x86_64.rpm  and   gmp-devel-4.2.2-7.fc9.x86_64.rpm
 mpfr-2.3.0-3.fc9.x86_64.rpm

I went and tried to update these packages as follows

[EMAIL PROTECTED] media]# cd "Fedora 9 x86_64 DVD"/Packages
[EMAIL PROTECTED] Packages]# ls *gmp*
gmp-4.2.2-7.fc9.i386.rpm  gmp-4.2.2-7.fc9.x86_64.rpm 
gmp-devel-4.2.2-7.fc9.i386.rpm  

[Bug bootstrap/37308] bootstrap hug on libstdc++.a

[cnstar9988 at gmail dot com]

--- Comment #3 from cnstar9988 at gmail dot com  2008-09-01 10:23 ---
$ oslevel -r
5100-09
with all latest AIX 5.1 patch.

=
I can compile gcc 4.2.4, works ok, and used for bootstrap gcc.
gcc 4.2.4 can't support TLS "__thread", "test.c:1: error: thread-local storage
not supported for this target"

=
when build gcc 4.3.2, both --disable-tls or not failed, *hangs* at same code.
stop at ./conftest for a long time.

Target: powerpc-ibm-aix5.1.0.0
Configured with: ../src/configure --prefix=/opt/gcc-4.3.2
--with-gmp=/opt/gcc-4.3.2 --with-mpfr=/opt/gcc-4.3.2 --with-as=/usr/bin/as
--with-ld=/usr/bin/ld --disable-nls --disable-tls --disable-shared
--disable-libgomp --enable-languages=c,c++ --enable-threads
--enable-version-specific-runtime-libs --build=powerpc-ibm-aix5.1.0.0


-- 


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

[Bug bootstrap/37308] bootstrap hangs in libstdc++

[paolo dot carlini at oracle dot com]

--- Comment #4 from paolo dot carlini at oracle dot com  2008-09-01 10:25 
---
Note that the TLS check code is used in libstdc++-v3, but it's actually part of
the general GCC config infrastructure: tls.m4. It's also used in libjava, for
example.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

Summary|bootstrap hug on libstdc++.a|bootstrap hangs in libstdc++


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

[Bug fortran/37274] [Regression 4.4 (and 4.3?)] error: type name is ambiguous.

[pault at gcc dot gnu dot org]

--- Comment #15 from pault at gcc dot gnu dot org  2008-09-01 10:27 ---
Since I am homing in on a solution, I might as well take it on.

Cheers

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pault at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-08-29 08:31:35 |2008-09-01 10:27:17
   date||


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

[Bug fortran/36374] nested module inclusion fails

[pault at gcc dot gnu dot org]

--- Comment #3 from pault at gcc dot gnu dot org  2008-09-01 10:28 ---
(In reply to comment #2)
> Paul, do you have an idea? You are our module/interface specialist.
> 

I have started to take a look at it.

Cheers

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pault at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-05-29 21:02:28 |2008-09-01 10:28:38
   date||


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

Re: [Bug rtl-optimization/37296] Bootstrap failure due to __muldi3

[Graham Stott]

All,

From the backtrace I very doubt this is a IRA issue.

I looks to be related to the recent IPA/CGRAPG changes
so it's one for Honza to look at

Cheers
Graham

[Bug rtl-optimization/37296] Bootstrap failure due to __muldi3

[graham dot stott at btinternet dot com]

--- Comment #10 from graham dot stott at btinternet dot com  2008-09-01 
10:30 ---
Subject: Re:  Bootstrap failure due to __muldi3

All,

>From the backtrace I very doubt this is a IRA issue.

I looks to be related to the recent IPA/CGRAPG changes
so it's one for Honza to look at

Cheers
Graham


-- 


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

[Bug bootstrap/37308] bootstrap hangs in libstdc++

[cnstar9988 at gmail dot com]

--- Comment #5 from cnstar9988 at gmail dot com  2008-09-01 10:34 ---
gcc 4.2.4 doesn't support tls on AIX 5.1.
Does gcc 4.3.2 support tls on AIX 5.1? Maybe stage3 gcc can compile "__thread",
but can't run well?
why I configure with --disable-tls, gcc 4.3.2 always use and check tls?

IBM XLC 9.0 says "Only supported on AIX for POWER version 5.3 with the 5300-05
Technology Level and higher."

Thanks.

I will "remove" TLS check code in libstdc++-v3/configure and test again.
==
  # For TLS support.  

enable_tls=no
gcc_cv_have_tls=no

  # For _Unwind_GetIPInfo.


-- 

cnstar9988 at gmail dot com changed:

   What|Removed |Added

 GCC target triplet|powerpc-ibm-aix5.1.0.0  |


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

Re: [Bug bootstrap/37308] bootstrap hangs in libstdc++

[Andrew Thomas Pinski]

Sent from my iPhone

On Sep 1, 2008, at 3:25, "paolo dot carlini at oracle dot com" <[EMAIL PROTECTED] 
> wrote:





--- Comment #4 from paolo dot carlini at oracle dot com   
2008-09-01 10:25 ---
Note that the TLS check code is used in libstdc++-v3, but it's  
actually part of
the general GCC config infrastructure: tls.m4. It's also used in  
libjava, for

example.


The other thing is that _thread is emulated on targets that don't  
support it.






--

paolo dot carlini at oracle dot com changed:

  What|Removed |Added
--- 
--- 
--
   Summary|bootstrap hug on libstdc++.a|bootstrap hangs in  
libstdc++



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

[Bug bootstrap/37308] bootstrap hangs in libstdc++

[pinskia at gmail dot com]

--- Comment #6 from pinskia at gmail dot com  2008-09-01 10:43 ---
Subject: Re:  bootstrap hangs in libstdc++



Sent from my iPhone

On Sep 1, 2008, at 3:25, "paolo dot carlini at oracle dot com"
<[EMAIL PROTECTED] 
 > wrote:

>
>
> --- Comment #4 from paolo dot carlini at oracle dot com   
> 2008-09-01 10:25 ---
> Note that the TLS check code is used in libstdc++-v3, but it's  
> actually part of
> the general GCC config infrastructure: tls.m4. It's also used in  
> libjava, for
> example.

The other thing is that _thread is emulated on targets that don't  
support it.

>
>
>
> -- 
>
> paolo dot carlini at oracle dot com changed:
>
>   What|Removed |Added
> --- 
> --- 
> --
>Summary|bootstrap hug on libstdc++.a|bootstrap hangs in  
> libstdc++
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37308
>


-- 


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

[Bug tree-optimization/37305] [4.4 Regression] ice in set_value_range, at tree-vrp.c:397

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2008-09-01 11:02 ---
Grrr, this crap "overflow infinity" hits again...  we try to set the
value-range
to [-INF, -INF(OVF)].

Which is because the overflow flag is set on -2147483647 in the assert
expression
ASSERT_EXPR .

Which is because propagating constants in

  l_30_1 = 4294967295;
  l_30.0_3 = (int) l_30_1;

causes l_30.0_3 to become -1(OVF).  Duh.


-- 


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

[Bug bootstrap/37308] bootstrap hangs in libstdc++

[paolo dot carlini at oracle dot com]

--- Comment #7 from paolo dot carlini at oracle dot com  2008-09-01 11:09 
---
(In reply to comment #6)
> The other thing is that __thread is emulated on targets that don't  
> support it.

That's interesting, I didn't notice we are actually doing that, right now (I
remember some discussions...). Then, however, I'm missing more... Why we are
running the check in libstdc++-v3 and libjava two times instead of just running
it once and, if necessary, instantiating the emulation and, in case, passing
down the info to the libraries?!?


-- 


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

[Bug other/37311] New: C frontend rejects __typeof__(bitfield).

[pluto at agmk dot net]

$ cat x.c
struct { int a:1; } bf;
__typeof__(bf.a) clone;

$ g++ -x c x.c -c
x.c:2: error: 'typeof' applied to a bit-field

this testcase was extracted from gnupg-1.4.9 sources.
it works at least on gcc-3.2.3 (Red Hat Linux 3.2.3-53).


-- 
   Summary: C frontend rejects __typeof__(bitfield).
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at agmk dot net
GCC target triplet: *-gnu-linux


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

[Bug middle-end/37248] [4.3/4.4 Regression] regression 4.3.1 -> 4.3.2-rc transformation bitfield to individual bytes

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2008-09-01 11:19 ---
FWIW the patch is ok for the 4.3 branch.


-- 


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

[Bug c++/37306] code generation error

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-09-01 11:21 ---
Sorry, but we need a complete compilable testcase to reproduce the issue.
Please also make sure you are not running into PR323 (you didn't report the
architecture you see the problem).


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug tree-optimization/37312] New: -Os significantly faster than -O2 on test case

[andi-gcc at firstfloor dot org]

[component might be wrong]

The appended test case is significantly faster with -Os -funroll-all-loops
(~5%) versus -O2 -funroll-all-loops in gcc 4.4 ( gcc version 4.4.0 20080829;
that
is shortly after the IRA merge) on a Core2 (Merom) 

In earlier gcc versions they are about the same performance. The -Os
improvement
is against all earlier versions (good!) but it should be in -O2 too.

I tried -fno-tree-pre as it was suggested and it didn't make a difference.


-- 
   Summary: -Os significantly faster than -O2 on test case
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andi-gcc at firstfloor dot org
  GCC host triplet: x86_64-linux
GCC target triplet: x86-64-linux


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

[Bug tree-optimization/37312] -Os significantly faster than -O2 on test case

[andi-gcc at firstfloor dot org]

--- Comment #1 from andi-gcc at firstfloor dot org  2008-09-01 11:22 ---
Created an attachment (id=16178)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16178&action=view)
test case

checksum functions extracted from the Linux kernel.

Not preprocessed, but should compile on any x86 ISO-C system


-- 


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

[Bug bootstrap/37308] bootstrap hangs in libstdc++

[cnstar9988 at gmail dot com]

--- Comment #8 from cnstar9988 at gmail dot com  2008-09-01 11:24 ---
When I remove TLS check code in libstdc++-v3/configure, bootstrap OK!!!

Does there have anything harm when remove the TLS check code? affect only C++?
Thanks!
==
  # For TLS support.  

enable_tls=no
gcc_cv_have_tls=no

  # For _Unwind_GetIPInfo.


==
conftest.c
===
__thread int a,b;
int main()
{
  return a==b;
}


-- 


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

[Bug middle-end/37248] [4.3/4.4 Regression] regression 4.3.1 -> 4.3.2-rc transformation bitfield to individual bytes

[jakub at gcc dot gnu dot org]

--- Comment #6 from jakub at gcc dot gnu dot org  2008-09-01 11:33 ---
Subject: Bug 37248

Author: jakub
Date: Mon Sep  1 11:32:18 2008
New Revision: 139858

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139858
Log:
PR middle-end/37248
PR middle-end/36449
* fold-const.c (make_bit_field_ref): Change bitpos and bitsize
arguments to HOST_WIDE_INT.
(fold_truthop): Change first_bit and end_bit to HOST_WIDE_INT.

* g++.dg/opt/pr36449.C: New test.

Revert:
2008-06-11  Richard Guenther  <[EMAIL PROTECTED]>
PR middle-end/36449
* fold-const.c (fold_truthop): Remove code generating
BIT_FIELD_REFs of structure bases.
(fold_binary): Likewise.
(make_bit_field_ref): Remove.
(optimize_bit_field_compare): Remove.
(all_ones_mask_p): Remove.

Added:
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/opt/pr36449.C
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/fold-const.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug tree-optimization/36449] Incorrect code generated for access to a large struct

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2008-09-01 11:33 ---
Subject: Bug 36449

Author: jakub
Date: Mon Sep  1 11:32:18 2008
New Revision: 139858

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139858
Log:
PR middle-end/37248
PR middle-end/36449
* fold-const.c (make_bit_field_ref): Change bitpos and bitsize
arguments to HOST_WIDE_INT.
(fold_truthop): Change first_bit and end_bit to HOST_WIDE_INT.

* g++.dg/opt/pr36449.C: New test.

Revert:
2008-06-11  Richard Guenther  <[EMAIL PROTECTED]>
PR middle-end/36449
* fold-const.c (fold_truthop): Remove code generating
BIT_FIELD_REFs of structure bases.
(fold_binary): Likewise.
(make_bit_field_ref): Remove.
(optimize_bit_field_compare): Remove.
(all_ones_mask_p): Remove.

Added:
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/opt/pr36449.C
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/fold-const.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug tree-optimization/36449] Incorrect code generated for access to a large struct

[jakub at gcc dot gnu dot org]

--- Comment #6 from jakub at gcc dot gnu dot org  2008-09-01 11:36 ---
Subject: Bug 36449

Author: jakub
Date: Mon Sep  1 11:34:47 2008
New Revision: 139859

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139859
Log:
PR middle-end/36449
* g++.dg/opt/pr36449.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/opt/pr36449.C
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug other/37311] C frontend rejects __typeof__(bitfield).

[joseph at codesourcery dot com]

--- Comment #1 from joseph at codesourcery dot com  2008-09-01 11:59 ---
Subject: Re:   New: C frontend rejects __typeof__(bitfield).

On Mon, 1 Sep 2008, pluto at agmk dot net wrote:

> $ cat x.c
> struct { int a:1; } bf;
> __typeof__(bf.a) clone;
> 
> $ g++ -x c x.c -c
> x.c:2: error: 'typeof' applied to a bit-field
> 
> this testcase was extracted from gnupg-1.4.9 sources.
> it works at least on gcc-3.2.3 (Red Hat Linux 3.2.3-53).

If you mean to report a C bug, use component "c"; for C++, component 
"c++".  For C this is a deliberate change to reject typeof on bit-fields 
just as sizeof is rejected on bit-fields; see bug 10333.  Your example 
uses g++ and I don't know if it's a deliberate change for C++.


-- 


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

[Bug tree-optimization/37313] New: [4.4 Regression]: trunk broken for sel-sched patches

[hp at gcc dot gnu dot org]

Build is broken on trunk, worked with revision 139848, for revision
139854 I see:
gcc -c  -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes \
-Wcast-qual -Wold-style-definition -Wc++-compat -Wmissing-format-attribute
-fno-common  -DHAVE_CONFIG_H -I. -I. -I/tmp/\
hpautotest-gcc1/gcc/gcc -I/tmp/hpautotest-gcc1/gcc/gcc/.
-I/tmp/hpautotest-gcc1/gcc/gcc/../include -I/tmp/hpautotest-gc\
c1/gcc/gcc/../libcpp/include -I/tmp/hpautotest-gcc1/cris-elf/gccobj/./gmp
-I/tmp/hpautotest-gcc1/gcc/gmp -I/tmp/hpautot\
est-gcc1/cris-elf/gccobj/./mpfr -I/tmp/hpautotest-gcc1/gcc/mpfr 
-I/tmp/hpautotest-gcc1/gcc/gcc/../libdecnumber -I/tmp/\
hpautotest-gcc1/gcc/gcc/../libdecnumber/dpd -I../libdecnumber 
/tmp/hpautotest-gcc1/gcc/gcc/sched-vis.c -o sched-vis.o
/tmp/hpautotest-gcc1/gcc/gcc/sched-vis.c: In function 'print_exp':
/tmp/hpautotest-gcc1/gcc/gcc/sched-vis.c:381: warning: implicit declaration of
function 'print_pattern'
/tmp/hpautotest-gcc1/gcc/gcc/sched-vis.c:414: warning: implicit declaration of
function 'print_value'
/tmp/hpautotest-gcc1/gcc/gcc/sched-vis.c: At top level:
/tmp/hpautotest-gcc1/gcc/gcc/sched-vis.c:428: warning: no previous prototype
for 'print_value'
/tmp/hpautotest-gcc1/gcc/gcc/sched-vis.c:428: warning: conflicting types for
'print_value'
/tmp/hpautotest-gcc1/gcc/gcc/sched-vis.c:414: warning: previous implicit
declaration of 'print_value' was here
/tmp/hpautotest-gcc1/gcc/gcc/sched-vis.c:535: warning: no previous prototype
for 'print_pattern'
/tmp/hpautotest-gcc1/gcc/gcc/sched-vis.c:535: warning: conflicting types for
'print_pattern'
/tmp/hpautotest-gcc1/gcc/gcc/sched-vis.c:381: warning: previous implicit
declaration of 'print_pattern' was here
/tmp/hpautotest-gcc1/gcc/gcc/sched-vis.c:645: warning: no previous prototype
for 'print_insn'
...
gcc -c  -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes \
-Wcast-qual -Wold-style-definition -Wc++-compat -Wmissing-format-attribute
-fno-common  -DHAVE_CONFIG_H -I. -I. -I/tmp/\
hpautotest-gcc1/gcc/gcc -I/tmp/hpautotest-gcc1/gcc/gcc/.
-I/tmp/hpautotest-gcc1/gcc/gcc/../include -I/tmp/hpautotest-gc\
c1/gcc/gcc/../libcpp/include -I/tmp/hpautotest-gcc1/cris-elf/gccobj/./gmp
-I/tmp/hpautotest-gcc1/gcc/gmp -I/tmp/hpautot\
est-gcc1/cris-elf/gccobj/./mpfr -I/tmp/hpautotest-gcc1/gcc/mpfr 
-I/tmp/hpautotest-gcc1/gcc/gcc/../libdecnumber -I/tmp/\
hpautotest-gcc1/gcc/gcc/../libdecnumber/dpd -I../libdecnumber 
/tmp/hpautotest-gcc1/gcc/gcc/sel-sched-dump.c -o sel-sch\
ed-dump.o
In file included from /tmp/hpautotest-gcc1/gcc/gcc/sel-sched-dump.c:37:
/tmp/hpautotest-gcc1/gcc/gcc/sel-sched-ir.h:93: error: expected
specifier-qualifier-list before 'ds_t'
/tmp/hpautotest-gcc1/gcc/gcc/sel-sched-ir.h:137: error: expected
specifier-qualifier-list before 'ds_t'
/tmp/hpautotest-gcc1/gcc/gcc/sel-sched-ir.h:239: error: expected
specifier-qualifier-list before 'deps_t'
/tmp/hpautotest-gcc1/gcc/gcc/sel-sched-ir.h:280: error: expected
specifier-qualifier-list before 'deps_t'
/tmp/hpautotest-gcc1/gcc/gcc/sel-sched-ir.h:369: error: expected '=', ',', ';',
'asm' or '__attribute__' before 'sched_\
lists_pool'
/tmp/hpautotest-gcc1/gcc/gcc/sel-sched-ir.h: In function '_list_alloc':
/tmp/hpautotest-gcc1/gcc/gcc/sel-sched-ir.h:374: warning: implicit declaration
of function 'pool_alloc'
/tmp/hpautotest-gcc1/gcc/gcc/sel-sched-ir.h:374: error: 'sched_lists_pool'
undeclared (first use in this function)
/tmp/hpautotest-gcc1/gcc/gcc/sel-sched-ir.h:374: error: (Each undeclared
identifier is reported only once
/tmp/hpautotest-gcc1/gcc/gcc/sel-sched-ir.h:374: error: for each function it
appears in.)
(pruned)

CC to committer of broken patch.


[EMAIL PROTECTED]@ of patches in suspect revision range CC:ed.


-- 
   Summary: [4.4 Regression]: trunk broken for sel-sched patches
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hp at gcc dot gnu dot org
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: cris-axis-elf


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

[Bug c++/37146] [4.4 Regression] Invalid types with COND_EXPR

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2008-09-01 12:40 ---
This is a C++ FE bug.  Shorter testcase:
enum E { E0 = 0, E1 = 'E' };

struct S
{
  E s0 : 8;
  enum E foo (bool, E);
};

E S::foo (bool a, E b)
{
  return a ? s0 : b;
}

The bug is IMHO in build_conditional_expr.  One of:
  arg2_type = unlowered_expr_type (arg2);
  arg3_type = unlowered_expr_type (arg3);
calls returns a different type from TREE_TYPE (argX), as that's bitfield
COMPONENT_REF.  Neither of the types are void and neither is class type, so
nothing is converted first and we reach:
  /* [expr.cond]

 If the second and third operands are lvalues and have the same
 type, the result is of that type and is an lvalue.  */
  if (real_lvalue_p (arg2)
  && real_lvalue_p (arg3)
  && same_type_p (arg2_type, arg3_type))
{
  result_type = arg2_type;
  goto valid_operands;
}
where arg2_type is the same as arg3_type, but TREE_TYPE (arg2) != TREE_TYPE
(arg3), not even useless type conversion, and at valid_operands we build it
right away as COND_EXPR.  Can x ? bitfield : val be even considered as valid
lvalue by C++ standard (I mean e.g. bitfield can have different number of bits
from val)?  If we don't shortcut here, force_rvalue is called on both arguments
and that will call the needed convert_bitfield_to_declared_type somewhere.
E.g.:
--- call.c.jj2008-08-29 18:23:10.0 +0200
+++ call.c2008-09-01 14:27:24.0 +0200
@@ -3596,7 +3596,9 @@ build_conditional_expr (tree arg1, tree 
  type, the result is of that type and is an lvalue.  */
   if (real_lvalue_p (arg2)
   && real_lvalue_p (arg3)
-  && same_type_p (arg2_type, arg3_type))
+  && same_type_p (arg2_type, arg3_type)
+  && is_bitfield_expr_with_lowered_type (arg2) == NULL_TREE
+  && is_bitfield_expr_with_lowered_type (arg3) == NULL_TREE)
 {
   result_type = arg2_type;
   goto valid_operands;
cures this testcase, but I'm not sure if it is correct from C++ standard POV.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jason at gcc dot gnu dot org


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

[Bug other/37311] C frontend rejects __typeof__(bitfield).

[pluto at agmk dot net]

--- Comment #2 from pluto at agmk dot net  2008-09-01 12:58 ---
(In reply to comment #1)
> Subject: Re:   New: C frontend rejects __typeof__(bitfield).
> 
> On Mon, 1 Sep 2008, pluto at agmk dot net wrote:
> 
> > $ cat x.c
> > struct { int a:1; } bf;
> > __typeof__(bf.a) clone;
> > 
> > $ g++ -x c x.c -c
> > x.c:2: error: 'typeof' applied to a bit-field
> > 
> > this testcase was extracted from gnupg-1.4.9 sources.
> > it works at least on gcc-3.2.3 (Red Hat Linux 3.2.3-53).
> 
> If you mean to report a C bug, use component "c"; for C++, component 
> "c++".  For C this is a deliberate change to reject typeof on bit-fields 
> just as sizeof is rejected on bit-fields; see bug 10333.

ok, i found the right solution:
http://lists.gnupg.org/pipermail/gnupg-devel/2008-April/024344.html

> Your example uses g++ and I don't know if it's a deliberate change for C++.

i used the 'g++ -x c' which means C.


-- 

pluto at agmk dot net changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX


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

[Bug rtl-optimization/37296] Bootstrap failure due to __muldi3

[ebotcazou at gcc dot gnu dot org]

--- Comment #11 from ebotcazou at gcc dot gnu dot org  2008-09-01 12:59 
---
> It is not fixed on FreeBSD.  I sometimes also see
> 
> checking for i386-unknown-freebsd8.0-gcc... /usr/home/kargl/gcc/obj/./gcc/xgcc
> -B/usr/home/kargl/gcc/obj/./gcc/
> -B/usr/home/kargl/work/i386-unknown-freebsd8.0/bin/
> -B/usr/home/kargl/work/i386-unknown-freebsd8.0/lib/ -isystem
> /usr/home/kargl/work/i386-unknown-freebsd8.0/include -isystem
> /usr/home/kargl/work/i386-unknown-freebsd8.0/sys-include
> checking for suffix of object files... configure: error: in
> `/usr/home/kargl/gcc/obj/i386-unknown-freebsd8.0/libgcc':
> configure: error: cannot compute suffix of object files: cannot compile
> See `config.log' for more details.
> gmake[2]: *** [configure-stage2-target-libgcc] Error 1
> gmake[2]: Leaving directory `/usr/home/kargl/gcc/obj'
> gmake[1]: *** [stage2-bubble] Error 2
> gmake[1]: Leaving directory `/usr/home/kargl/gcc/obj'
> gmake: *** [bootstrap] Error 2

Yes, I got that on Linux too at rev 139835.  Everybody was rushing patches so
there might be multiple issues on top of each other.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

   Last reconfirmed|2008-08-31 06:42:28 |2008-09-01 12:59:53
   date||


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

[Bug rtl-optimization/37296] Bootstrap failure due to __muldi3

[ebotcazou at gcc dot gnu dot org]

--- Comment #12 from ebotcazou at gcc dot gnu dot org  2008-09-01 13:02 
---
> From the backtrace I very doubt this is a IRA issue.

The backtrace is for another problem, the _muldi3 issue is a miscompilation of
gimple.c:gimple_build_asm_vec by the new regalloc/reload.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

   Last reconfirmed|2008-09-01 12:59:53 |2008-09-01 13:02:39
   date||


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

[Bug rtl-optimization/37296] Bootstrap failure due to __muldi3

[ebotcazou at gcc dot gnu dot org]

-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |NEW
   Last reconfirmed|2008-09-01 13:02:39 |2008-09-01 13:03:01
   date||


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

[Bug rtl-optimization/37296] [4.4 Regression] Bootstrap failure due to __muldi3

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||wrong-code
Summary|Bootstrap failure due to|[4.4 Regression] Bootstrap
   |__muldi3|failure due to __muldi3
   Target Milestone|--- |4.4.0


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

[Bug bootstrap/37277] bootstrap failure with --with-dwarf2 on Solaris 10

[ebotcazou at gcc dot gnu dot org]

--- Comment #5 from ebotcazou at gcc dot gnu dot org  2008-09-01 13:18 
---
> Yes, I realise that, but it's still documented and it was apparently harmless
> with 4.2.2

It's still documented because it's still useful on platforms that don't default
to DWARF-2, which is not the case of Solaris anymore.


-- 


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

[Bug tree-optimization/37305] [4.4 Regression] ice in set_value_range, at tree-vrp.c:397

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2008-09-01 13:40 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||4.3.2
 Resolution||FIXED


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

[Bug rtl-optimization/37296] [4.4 Regression] Bootstrap failure compiling libgcc

[ebotcazou at gcc dot gnu dot org]

--- Comment #13 from ebotcazou at gcc dot gnu dot org  2008-09-01 13:40 
---
Reconfirmed with failure mode from comment #4 on i586-linux at r139863.

I'm going to investigate.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

   Last reconfirmed|2008-09-01 13:03:01 |2008-09-01 13:40:06
   date||
Summary|[4.4 Regression] Bootstrap  |[4.4 Regression] Bootstrap
   |failure due to __muldi3 |failure compiling libgcc
   Target Milestone|4.4.0   |---


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

[Bug tree-optimization/37305] [4.4 Regression] ice in set_value_range, at tree-vrp.c:397

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2008-09-01 13:41 ---
Subject: Bug 37305

Author: rguenth
Date: Mon Sep  1 13:39:42 2008
New Revision: 139864

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139864
Log:
2008-09-01  Richard Guenther  <[EMAIL PROTECTED]>

PR tree-optimization/37305
* tree-ssa-ccp.c (ccp_fold): Do not set TREE_OVERFLOW on
the result of constant conversions.
(fold_gimple_assign): Likewise.

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

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr37305.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-ccp.c


-- 


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

[Bug tree-optimization/37312] -Os significantly faster than -O2 on test case

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-09-01 13:42 ---
Uh, well.  The code ist mostly inline assembly which doesn't give GCC much
freedom to do something.  I guess -O2 simply optimizes "too much" around the
asm.  Try not using inline assembly instead.


-- 


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

[Bug rtl-optimization/37296] [4.4 Regression] Bootstrap failure compiling libgcc

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.4.0


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

[Bug fortran/37193] [4.3/4.4 Regression] "USE mod, ONLY: i, i=>j" does not import "i"

[domob at gcc dot gnu dot org]

--- Comment #1 from domob at gcc dot gnu dot org  2008-09-01 13:44 ---
Subject: Bug 37193

Author: domob
Date: Mon Sep  1 13:43:10 2008
New Revision: 139866

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139866
Log:
2008-09-01  Daniel Kraft  <[EMAIL PROTECTED]>

PR fortran/37193
* module.c (read_module): Initialize use_only flag on used symbols.

2008-09-01  Daniel Kraft  <[EMAIL PROTECTED]>

PR fortran/37193
* gfortran.dg/use_rename_4.f90: New test.
* gfortran.dg/use_rename_5.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/use_rename_4.f90
trunk/gcc/testsuite/gfortran.dg/use_rename_5.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/module.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug tree-optimization/37095] [4.4 regression] Trouble with covariant return

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2008-09-01 13:50 ---
The problem is that cgraph_node_for_asm assumes that once it has been called
once, no new cgraph nodes will be created.  But that's not true, at least C++
lang_hooks.callgraph.emit_associated_thunks (decl) adds new cgraph nodes (for
the thunks).  So, either cgraph_create_node should keep populating
assembler_name_hash once that hash table is created, or there should be a
cgraph function which can be called for the late cgraph nodes to get registered
into
the assembler_name_hash.


-- 


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

[Bug bootstrap/36908] [4.4 Regression] bootstrap forever with BOOT_CFLAGS="-O2 -ftree-loop-distribution"

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P1  |P2


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

[Bug fortran/37310] gfortran errors in compilation and the making for upgraded compilers

[jvdelisle at gcc dot gnu dot org]

--- Comment #1 from jvdelisle at gcc dot gnu dot org  2008-09-01 14:00 
---
Try seeing if you need to install mpfr-devel and gmp-devel packages for your
distribution.  This will install the headers needed for those libraries.

Also, make sure you are building in a separate directory away from the source
tree for gcc.

The aforementioned are probably the most common problems I have seen. 


-- 


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

[Bug target/35397] Problem handling denormalized numbers under AIX

[efernandez at physiomics-plc dot com]

--- Comment #4 from efernandez at physiomics-plc dot com  2008-09-01 14:09 
---
Thanks David. Would that be worth it to make it appear in the regression list?
How can it be added to that bug list?


-- 


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

[Bug tree-optimization/37312] -Os significantly faster than -O2 on test case

[andi-gcc at firstfloor dot org]

--- Comment #3 from andi-gcc at firstfloor dot org  2008-09-01 14:20 ---
Thanks for the us^whelpful comment. If you can suggest a way to do carry
preserving addition without inline assembler that would be fine, otherwise not.

-Os seems to do something that improves it at least (and that is new in 4.4,
4.3 didn't do that)

I suppose -O2 does something more that makes it then worse again. 

I merely filled it because I thought it would be interesting to fix that
something to not pessimize code.




-- 


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

[Bug tree-optimization/37312] -Os significantly faster than -O2 on test case

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2008-09-01 14:36 ---
Well, now -Os -funroll-all-loops doesn't do any unrolling anymore while it did
before.  With -O2 you get what you ask for - unrolled loops.

-funroll-all-loops isn't really a flag to be used in general.


-- 


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

[Bug target/36904] [4.4 Regression] vector context sensitive keyword vs macros

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2008-09-01 15:38 ---
Created an attachment (id=16179)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16179&action=view)
gcc44-pr36904.patch

Updated patch, apparently all other problems can be fixed just by never
expanding the conditional keywords to self.  This will make preprocessing them
tiny bit slower (as the macro_to_expand hook might be called several times on
it), but means we handle right even the cases where cpp_get_token is called
with
a conditional macro token in some inner context where following tokens aren't
seen yet (e.g. macro args, etc.).

I don't have any altivec.h codebase around, could one of you test this on
something larger?  Thanks.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #15990|0   |1
is obsolete||
 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED


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

[Bug c++/37314] New: seg violation

[w dot doeringer at fh-worms dot de]

seg violation of compiler - previous versions compiled ok!


-- 
   Summary: seg violation
   Product: gcc
   Version: 4.1.3
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: w dot doeringer at fh-worms dot de


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

[Bug c++/37314] seg violation

[w dot doeringer at fh-worms dot de]

--- Comment #1 from w dot doeringer at fh-worms dot de  2008-09-01 15:41 
---
Created an attachment (id=16180)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16180&action=view)
the ii file

the file you requested in your instructions on how to submit a bug report


-- 


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

[Bug tree-optimization/36511] [4.4 Regression] ice for legal code with -O2

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2008-09-01 15:46 ---
Works on the trunk for me.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WORKSFORME


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

[Bug c++/37314] seg violation

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-09-01 15:49 ---
Created an attachment (id=16181)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16181&action=view)
unincluded testcase


-- 


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

[Bug c++/37314] seg violation

[paolo dot carlini at oracle dot com]

--- Comment #3 from paolo dot carlini at oracle dot com  2008-09-01 15:50 
---
Note, 4_1-branch is closed. I would suggest first trying a newer compiler on
your code, e.g., 4.3.2.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

   Severity|blocker |normal
Summary|seg violation   |seg violation


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

[Bug c++/37314] [4.2/4.3/4.4 Regression] seg violation

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2008-09-01 15:53 ---
Confirmed.

Program received signal SIGSEGV, Segmentation fault.
0x00cd5495 in strip_array_types (type=0x0)
at /space/rguenther/src/svn/trunk/gcc/tree.c:5755
5755  while (TREE_CODE (type) == ARRAY_TYPE)
(gdb) up
#1  0x005ad26d in cp_type_quals (type=0x0)
at /space/rguenther/src/svn/trunk/gcc/cp/typeck.c:7108
7108  type = strip_array_types (CONST_CAST_TREE(type));
(gdb) 
#2  0x00585fb8 in original_type (t=0x0)
at /space/rguenther/src/svn/trunk/gcc/cp/typeck.c:236
236   int quals = cp_type_quals (t);
(gdb) 
#3  0x00589136 in merge_types (t1=0x7fd7237a0900, t2=0x0)
at /space/rguenther/src/svn/trunk/gcc/cp/typeck.c:602
602   if (original_type (t1) == original_type (t2))
(gdb) 
#4  0x005895ee in merge_types (t1=0x7fd7237a0a80, t2=0x7fd723765a80)
at /space/rguenther/src/svn/trunk/gcc/cp/typeck.c:628
628 tree target = merge_types (TREE_TYPE (t1), TREE_TYPE (t2));
(gdb) call debug_tree (t1)
  chain >
unsigned DI
size  constant 64>
unit size  constant 8>
align 64 symtab 0 alias set -1 canonical type 0x7fd723fdf240>
(gdb) call debug_tree (t2)
 
chain >


#0  0x00cd5495 in strip_array_types (type=0x0)
at /space/rguenther/src/svn/trunk/gcc/tree.c:5755
#1  0x005ad26d in cp_type_quals (type=0x0)
at /space/rguenther/src/svn/trunk/gcc/cp/typeck.c:7108
#2  0x00585fb8 in original_type (t=0x0)
at /space/rguenther/src/svn/trunk/gcc/cp/typeck.c:236
#3  0x00589136 in merge_types (t1=0x7fd7237a0900, t2=0x0)
at /space/rguenther/src/svn/trunk/gcc/cp/typeck.c:602
#4  0x005895ee in merge_types (t1=0x7fd7237a0a80, t2=0x7fd723765a80)
at /space/rguenther/src/svn/trunk/gcc/cp/typeck.c:628
#5  0x00589d73 in merge_types (t1=0x7fd7237a0b40, t2=0x7fd72376c300)
at /space/rguenther/src/svn/trunk/gcc/cp/typeck.c:675
#6  0x0058a454 in merge_types (t1=0x7fd7237a0b40, t2=0x7fd72376c300)
at /space/rguenther/src/svn/trunk/gcc/cp/typeck.c:723
#7  0x0042f5ca in duplicate_decls (newdecl=0x7fd72377b400, 
olddecl=0x7fd72376a500, newdecl_is_friend=0 '\0')
at /space/rguenther/src/svn/trunk/gcc/cp/decl.c:1703
#8  0x0044cb25 in grokfndecl (ctype=0x7fd7237650c0, 
type=0x7fd7237a0cc0, declarator=0x7fd72530e780, parms=0x7fd72379e360, 
orig_declarator=0x7fd72530e780, virtualp=0, flags=NO_SPECIAL, quals=0, 
raises=0x0, check=1, friendp=0, publicp=1, inlinep=0, sfk=sfk_none, 
funcdef_flag=1 '\001', template_count=1, in_namespace=0x0, 
attrlist=0x7fff2d43db28)
at /space/rguenther/src/svn/trunk/gcc/cp/decl.c:6802
#9  0x004568e2 in grokdeclarator (declarator=0x1746bf0, 
declspecs=0x7fff2d43dd00, decl_context=NORMAL, initialized=1, 
attrlist=0x7fff2d43db28)
at /space/rguenther/src/svn/trunk/gcc/cp/decl.c:9255
#10 0x0046900f in start_function (declspecs=0x7fff2d43dd00, 
declarator=0x1746c70, attrs=0x0)
at /space/rguenther/src/svn/trunk/gcc/cp/decl.c:11698
#11 0x005717a4 in
cp_parser_function_definition_from_specifiers_and_declarator
(parser=0x7fd724a137d0, decl_specifiers=0x7fff2d43dd00, attributes=0x0, 
declarator=0x1746c70)
at /space/rguenther/src/svn/trunk/gcc/cp/parser.c:17336
#12 0x00568b31 in cp_parser_init_declarator (parser=0x7fd724a137d0, 
decl_specifiers=0x7fff2d43dd00, checks=0x0, 
function_definition_allowed_p=1 '\001', member_p=0 '\0', 
declares_class_or_enum=0, function_definition_p=0x7fff2d43dcff "\001")
at /space/rguenther/src/svn/trunk/gcc/cp/parser.c:12584
#13 0x005721f8 in cp_parser_single_declaration (parser=0x7fd724a137d0, 
checks=0x0, member_p=0 '\0', explicit_specialization_p=0 '\0', 
friend_p=0x7fff2d43ddb7 "")
at /space/rguenther/src/svn/trunk/gcc/cp/parser.c:17682
#14 0x00571b94 in cp_parser_template_declaration_after_export (
parser=0x7fd724a137d0, member_p=0 '\0')
---Type  to continue, or q  to quit---
at /space/rguenther/src/svn/trunk/gcc/cp/parser.c:17535
#15 0x0056434a in cp_parser_template_declaration (
parser=0x7fd724a137d0, member_p=0 '\0')
at /space/rguenther/src/svn/trunk/gcc/cp/parser.c:9488
#16 0x005624fd in cp_parser_declaration (parser=0x7fd724a137d0)
at /space/rguenther/src/svn/trunk/gcc/cp/parser.c:7884
#17 0x00562298 in cp_parser_declaration_seq_opt (parser=0x7fd724a137d0)
at /space/rguenther/src/svn/trunk/gcc/cp/parser.c:7815
#18 0x00567fd9 in cp_parser_namespace_body (parser=0x7fd724a137d0)
at /space/rguenther/src/svn/trunk/gcc/cp/parser.c:12028
#19 0x00567f9f in cp_parser_namespace_definition (
parser=0x7fd724a137d0)
at /space/rguenther/src/svn/trunk/gcc/cp/parser.c:12007
#20 0x005625c5 in cp_parser_declaration (parser=0x7fd724a137d0)
at /space/rguenther/src/svn/trunk/gcc/cp/parser.c:7912
#21 0x00562298 in cp_

[Bug c++/37314] [4.2/4.3/4.4 Regression] seg violation

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2008-09-01 15:56 ---
Reducing.


-- 


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

[Bug c++/37314] [4.2/4.3/4.4 Regression] seg violation

[paolo dot carlini at oracle dot com]

--- Comment #6 from paolo dot carlini at oracle dot com  2008-09-01 16:01 
---
Thanks Richard.


-- 


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

[Bug c++/37314] [4.2/4.3/4.4 Regression] seg violation

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2008-09-01 16:02 ---
Reduced testcase:

template 
class Cdeque {
typedef T *pointer;
class iterator {
typedef typename Cdeque::pointer pointer;
pointer operator->();
};
};
template  T* Cdeque::iterator::operator->() { }


-- 


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

[Bug tree-optimization/37313] [4.4 Regression]: trunk broken for sel-sched patches

[hp at gcc dot gnu dot org]

--- Comment #1 from hp at gcc dot gnu dot org  2008-09-01 16:02 ---
Confirmed with 139863 that build works again.


-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug c++/37314] [4.2/4.3/4.4 Regression] seg violation

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2008-09-01 16:03 ---
Which I guess is invalid because the definition of Cdeque is not complete
at the time we bind iterator::pointer to Cdeque::pointer.


-- 


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

[Bug c++/37314] [4.2/4.3/4.4 Regression] seg violation

[rguenth at gcc dot gnu dot org]

--- Comment #9 from rguenth at gcc dot gnu dot org  2008-09-01 16:05 ---
Though EDG accepts it (but of course nothing is instantiated here).


-- 


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

[Bug c++/37314] [4.2/4.3/4.4 Regression] seg violation

[w dot doeringer at fh-worms dot de]

--- Comment #10 from w dot doeringer at fh-worms dot de  2008-09-01 16:14 
---
Subject: Re:  [4.2/4.3/4.4 Regression] seg violation

Hi,
thanks for taking the time to look at my problem.
I did try with version 4.2 and fared no better.
Versions up to 4.0.x compile ok.
Let me know if I can be of further assistance as I am quite stuck at the 
moment.
Best regards, wdoeringer

On Mon, 1 Sep 2008, rguenth at gcc dot gnu dot org wrote:

>
>
> --- Comment #9 from rguenth at gcc dot gnu dot org  2008-09-01 16:05 
> ---
> Though EDG accepts it (but of course nothing is instantiated here).
>
>
>


-- 


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

[Bug target/37315] New: [4.4 Regression]: gcc.c-torture/execute/931018-1.c int-compare.c ieee/inf-2.c mzero6.c

[hp at gcc dot gnu dot org]

With revision 139521 this test passed.
>From revision 139525 and on, these tests have failed.

At revision 139842 the FAILs are as follows:
Running
/tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.c-torture/execute/execute.exp ...
FAIL: gcc.c-torture/execute/931018-1.c compilation,  -O3 -fomit-frame-pointer 
(internal compiler error)
FAIL: gcc.c-torture/execute/931018-1.c compilation,  -O3 -g  (internal compiler
error)
FAIL: gcc.c-torture/execute/int-compare.c compilation,  -O2  (internal compiler
error)
FAIL: gcc.c-torture/execute/int-compare.c compilation,  -Os  (internal compiler
error)
Running
/tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.c-torture/execute/ieee/ieee.exp ...
FAIL: gcc.c-torture/execute/ieee/inf-2.c compilation,  -O3 -fomit-frame-pointer
 (internal compiler error)
FAIL: gcc.c-torture/execute/ieee/inf-2.c compilation,  -O3 -g  (internal
compiler error)
FAIL: gcc.c-torture/execute/ieee/mzero6.c compilation,  -O3
-fomit-frame-pointer  (internal compiler error)
FAIL: gcc.c-torture/execute/ieee/mzero6.c compilation,  -O3
-fomit-frame-pointer -funroll-loops  (internal compiler error)
FAIL: gcc.c-torture/execute/ieee/mzero6.c compilation,  -O3
-fomit-frame-pointer -funroll-all-loops -finline-functions  (internal compiler
error)
FAIL: gcc.c-torture/execute/ieee/mzero6.c compilation,  -O3 -g  (internal
compiler error)

Originally, with revision 139525 they were as follows:

Running
/tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.c-torture/execute/builtins/builtins.exp
...
Running
/tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.c-torture/execute/execute.exp ...
FAIL: gcc.c-torture/execute/2223-1.c compilation,  -O2  (internal compiler
error)
FAIL: gcc.c-torture/execute/2223-1.c compilation,  -Os  (internal compiler
error)
FAIL: gcc.c-torture/execute/931018-1.c compilation,  -O2  (internal compiler
error)
FAIL: gcc.c-torture/execute/931018-1.c compilation,  -O3 -fomit-frame-pointer 
(internal compiler error)
FAIL: gcc.c-torture/execute/931018-1.c compilation,  -O3 -g  (internal compiler
error)
FAIL: gcc.c-torture/execute/931018-1.c compilation,  -Os  (internal compiler
error)
FAIL: gcc.c-torture/execute/cvt-1.c compilation,  -O2  (internal compiler
error)
FAIL: gcc.c-torture/execute/cvt-1.c compilation,  -Os  (internal compiler
error)
FAIL: gcc.c-torture/execute/int-compare.c compilation,  -O2  (internal compiler
error)
FAIL: gcc.c-torture/execute/int-compare.c compilation,  -Os  (internal compiler
error)
Running
/tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.c-torture/execute/ieee/ieee.exp ...
FAIL: gcc.c-torture/execute/ieee/inf-2.c compilation,  -O2  (internal compiler
error)
FAIL: gcc.c-torture/execute/ieee/inf-2.c compilation,  -O3 -fomit-frame-pointer
 (internal compiler error)
FAIL: gcc.c-torture/execute/ieee/inf-2.c compilation,  -O3 -g  (internal
compiler error)
FAIL: gcc.c-torture/execute/ieee/inf-2.c compilation,  -Os  (internal compiler
error)
FAIL: gcc.c-torture/execute/ieee/mzero6.c compilation,  -O2  (internal compiler
error)
FAIL: gcc.c-torture/execute/ieee/mzero6.c compilation,  -O3
-fomit-frame-pointer  (internal compiler error)
FAIL: gcc.c-torture/execute/ieee/mzero6.c compilation,  -O3
-fomit-frame-pointer -funroll-loops  (internal compiler err\
or)
FAIL: gcc.c-torture/execute/ieee/mzero6.c compilation,  -O3
-fomit-frame-pointer -funroll-all-loops -finline-functions \
 (internal compiler error)
FAIL: gcc.c-torture/execute/ieee/mzero6.c compilation,  -O3 -g  (internal
compiler error)
FAIL: gcc.c-torture/execute/ieee/mzero6.c compilation,  -Os  (internal compiler
error)

At revision 139842 the message in the logfile is:

Executing on host: /tmp/hpautotest-gcc1/cris-elf/gccobj/gcc/xgcc
-B/tmp/hpautotest-gcc1/cris-elf/gccobj/gcc/
/tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.c-torture/execute/931018-1.c  -w 
-O3 -fomit-frame-pointer-isystem
/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./newlib/targ-include -isystem
/tmp/hpautotest-gcc1/gcc/newlib/libc/include
-B/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./libgloss/cris/
-L/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./libgloss/cris
-L/tmp/hpautotest-gcc1/gcc/libgloss/cris 
-B/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./newlib/
-L/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./newlib -sim3  -lm   -o
/tmp/hpautotest-gcc1/cris-elf/gccobj/gcc/testsuite/gcc/931018-1.x3(timeout
= 300)
/tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.c-torture/execute/931018-1.c: In
function 'T.1':^M
/tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.c-torture/execute/931018-1.c:16:
internal compiler error: CRIS-port assertion failed: cfun->machine->return_type
!= CRIS_RETINSN_JUMP || on_stack^M

and similar for the other mentioned FAILs.
It's either a generally uninitialized cfun->machine (use before initialization)
or a port-specific bug.  I (temporarily) specify the PR as target and assign
this bug to myself and investigate.

Author of patches in suspect revision range CC:ed.


-- 
   Summary: [4.4 Regression]: gcc.c-torture/execute/931018-1.c  int-
   

[Bug c++/37314] [4.2/4.3/4.4 Regression] seg violation

[w dot doeringer at fh-worms dot de]

--- Comment #11 from w dot doeringer at fh-worms dot de  2008-09-01 16:39 
---
Subject: Re:  [4.2/4.3/4.4 Regression] seg violation

Hi,
I have added some substance to the reduced testcase, so that now actual 
code is generated. You find it in the attached file.
It compiles well under g++ 4.0.1 (Apple Inc. Build 5456)
but crashes under
4.2.1 (Ubuntu 4.2.1-5ubuntu4) and under 4.1.3
Best regards, wd.doeringer

On Mon, 1 Sep 2008, rguenth at gcc dot gnu dot org wrote:

>
>
> --- Comment #9 from rguenth at gcc dot gnu dot org  2008-09-01 16:05 
> ---
> Though EDG accepts it (but of course nothing is instantiated here).
>
>
>


--- Comment #12 from w dot doeringer at fh-worms dot de  2008-09-01 16:39 
---
Created an attachment (id=16182)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16182&action=view)


-- 


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

[Bug rtl-optimization/37296] [4.4 Regression] Bootstrap failure compiling libgcc

[sgk at troutmask dot apl dot washington dot edu]

--- Comment #14 from sgk at troutmask dot apl dot washington dot edu  
2008-09-01 16:56 ---
Subject: Re:  Bootstrap failure due to __muldi3

On Mon, Sep 01, 2008 at 10:30:27AM -, graham dot stott at btinternet dot
com wrote:
> 
> --- Comment #10 from graham dot stott at btinternet dot com  2008-09-01 
> 10:30 ---
> 
> From the backtrace I very doubt this is a IRA issue.
> 
> I looks to be related to the recent IPA/CGRAPG changes
> so it's one for Honza to look at
> 

While Vlad's IRA patches may not be directly responsible, the
evidence shows that if I revert Vlad's patches my tree then
builds.  I'll put Vlad's stuff back into my tree and see
if I can locate if it is one of Honza's patches.


-- 


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

[Bug middle-end/37293] [4.4 Regression] r139762 breaks libstdc++ build on darwin

[howarth at nitro dot med dot uc dot edu]

--- Comment #12 from howarth at nitro dot med dot uc dot edu  2008-09-01 
16:57 ---
Does the fact that linux seems to be immune to this problem suggest that the
Darwin linker is too restrictive with regard to weak symbols? Would it make
sense to create a testcase and submit a
radar bug report requesting that the darwin linker become more flexible with
weak symbols?


-- 


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

[Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above

[danglin at gcc dot gnu dot org]

--- Comment #28 from danglin at gcc dot gnu dot org  2008-09-01 17:40 
---
On hppa64-hp-hpux11.11, the test still fails at certain optimizations:

FAIL: gcc.c-torture/execute/20040709-1.c execution,  -O0 
FAIL: gcc.c-torture/execute/20040709-1.c execution,  -O1 

# ./xgcc -B./ -v
Reading specs from ./specs
Target: hppa64-hp-hpux11.11
Configured with: ../gcc/configure --with-gnu-as --with-as=/opt/gnu64/bin/as
--with-ld=/usr/ccs/bin/ld --enable-shared --disable-nls
--with-local-prefix=/opt/gnu64 --prefix=/opt/gnu64/gcc/gcc-4.4.0
--build=hppa64-hp-hpux11.11 --enable-threads=posix --disable-libmudflap
--with-gmp=/opt/gnu64/gcc/gcc-4.4.0 --enable-languages=c++
Thread model: posix
gcc version 4.4.0 20080831 (experimental) [trunk revision 139820] (GCC) 


-- 


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

[Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #29 from dave at hiauly1 dot hia dot nrc dot ca  2008-09-01 
18:17 ---
Subject: Re:  [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c
execution at -O2 and above

> On hppa64-hp-hpux11.11, the test still fails at certain optimizations:
> 
> FAIL: gcc.c-torture/execute/20040709-1.c execution,  -O0 
> FAIL: gcc.c-torture/execute/20040709-1.c execution,  -O1 

I'm also seeing the following two fails which appear at first sight to
be related:

FAIL: gcc.c-torture/execute/920908-2.c execution,  -O0 
FAIL: gcc.c-torture/execute/920908-2.c execution,  -O1 

Dave


-- 


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

[Bug inline-asm/37195] unrelated variables get the same memory address in inline assembly

[jdemeyer at cage dot ugent dot be]

--- Comment #2 from jdemeyer at cage dot ugent dot be  2008-09-01 18:18 
---
Created an attachment (id=16183)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16183&action=view)
Better and simpler test case

The second test case, asmtest2.i exhibits the bug on even more versions of gcc.
 To run the testcase, do
gcc -O1 -save-temps asmtest2.i -o asmtest2

Consider the following piece of inline assembly (the second one of asmtest2.i):
asm("# ASM 2\n"
"movl %5, %2\n"
"movl %4, %0\n"
"movl %0, %1\n"
"movl %3, %0\n"
: "=&a" (c0), "=&rm" (c1), "=&rm" (c2)
: "rm" (b0), "rm" (b1), "0" (b2)
: "cc", "%esi", "%edi", "%edx"
);

gcc 4.3.2 compiles this as
movl %eax, -40(%ebp)
movl -24(%ebp), %eax
movl %eax, -44(%ebp)
movl -40(%ebp), %eax

Note that %2 and %3 are both stored in -40(%ebp).  I think this is a bug.

I have tried this with the following versions of gcc, all of which have the
bug: 3.4.6, 4.0.3, 4.1.2, 4.2.4, 4.3.1, 4.3.2


-- 

jdemeyer at cage dot ugent dot be changed:

   What|Removed |Added

  Attachment #16123|0   |1
is obsolete||


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

[Bug inline-asm/37195] unrelated variables get the same memory address in inline assembly

[jdemeyer at cage dot ugent dot be]

-- 

jdemeyer at cage dot ugent dot be changed:

   What|Removed |Added

   Severity|normal  |major


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

[Bug middle-end/37316] New: [4.4 Regression] Small structs are not passed correctly on hppa64-*-*

[danglin at gcc dot gnu dot org]

Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/te
st/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/execute/931004-1.c  -w  -O0   -lm  
-
o /test/gnu/gcc/objdir/gcc/testsuite/gcc/931004-1.x0(timeout = 300)
PASS: gcc.c-torture/execute/931004-1.c compilation,  -O0 
Setting LD_LIBRARY_PATH to :/test/gnu/gcc/objdir/gcc::/test/gnu/gcc/objdir/gcc
FAIL: gcc.c-torture/execute/931004-1.c execution,  -O0


-- 
   Summary: [4.4 Regression] Small structs are not passed correctly
on hppa64-*-*
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
 GCC build triplet: hppa64-hp-hpux11.11
  GCC host triplet: hppa64-hp-hpux11.11
GCC target triplet: hppa64-hp-hpux11.11


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

[Bug testsuite/36332] [4.4 Regression] FAIL: gcc.dg/torture/type-generic-1.c execution test on powerpc-*

[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 |
URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2008-
   ||09/msg00036.html
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-05-28 07:57:44 |2008-09-01 18:23:13
   date||


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

[Bug middle-end/37316] [4.4 Regression] Small structs are not passed correctly on hppa64-*-*

[danglin at gcc dot gnu dot org]

--- Comment #1 from danglin at gcc dot gnu dot org  2008-09-01 18:28 ---
gcc.c-torture/execute/931004-3.c, gcc.c-torture/execute/931004-7.c and
gcc.c-torture/execute/931005-1.c also fail.  These fails appear related.


-- 


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

[Bug fortran/37317] New: gfortran generates incorrect lbound and ubound

[rosinskijm at ornl dot gov]

The following self-contained code should print the same for the bounds of xxx
and yyy (0:12). Instead it prints

 bounds of yyy=   0  12
 bounds of xxx=   1  13

% gfortran --version
GNU Fortran (GCC) 4.2.3 (Ubuntu 4.2.3-2ubuntu7)

This causes the current version of the Community Atmosphere Model (CAM), and
WRF 2.2.1 to fail. The code sample works as expected with PGI, XLF, and ifort.

This is my first bugzilla report. Apologies in advance if I missed any required
steps in reporting this bug.

To build and run:

% gfortran main.f90
% ./a.out



program main
  implicit none
  real, target :: yyy(0:12)
  data yyy/1.,2.,3.,4.,5.,6.,7.,8.,9.,10.,11.,12.,13./
  real, pointer :: xxx(:)
  xxx => yyy
  write(6,*)'bounds of yyy=',lbound(yyy), ubound(yyy)
  write(6,*)'bounds of xxx=',lbound(xxx), ubound(xxx)
end program main


-- 
   Summary: gfortran generates incorrect lbound and ubound
   Product: gcc
   Version: 4.2.3
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rosinskijm at ornl dot gov
 GCC build triplet: i686-pc-linux
  GCC host triplet: i686-pc-linux
GCC target triplet: i686-pc-linux


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

[Bug fortran/37317] gfortran generates incorrect lbound and ubound

[kargl at gcc dot gnu dot org]

--- Comment #1 from kargl at gcc dot gnu dot org  2008-09-01 19:02 ---
The correct result is given by both 4.3.2 and 4.4.0.  You 
may want to upgrade to a newer version of the compiler
because few if any patches will make it back to the 4.2 branch.

troutmask:sgk[204] ./z
 bounds of yyy=   0  12
 bounds of xxx=   1  13
troutmask:sgk[205] gfortran43 -o z j.f90
troutmask:sgk[206] ./z
 bounds of yyy=   0  12
 bounds of xxx=   0  12
troutmask:sgk[207] ~/work/4x/bin/gfortran -o z j.f90
troutmask:sgk[208] ./z
 bounds of yyy=   0  12
 bounds of xxx=   0  12


-- 


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

[Bug tree-optimization/37095] [4.4 regression] Trouble with covariant return

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2008-09-01 19:03 ---
Created an attachment (id=16184)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16184&action=view)
gcc44-pr37095.patch

Patch I'm going to bootstrap now.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug middle-end/37318] New: [4.4 Regression] gcc.dg/compat//scalar-by-value-4_x.c:72: ICE: in emit_group_store, at expr.c:2084

[danglin at gcc dot gnu dot org]

Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/  
-
DSKIP_DECIMAL_FLOAT -c  -o c_compat_x_tst.o
/test/gnu/gcc/gcc/gcc/testsuite/gcc.
dg/compat//scalar-by-value-4_x.c(timeout = 300)
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/compat//scalar-by-value-4_x.c: In
functio
n 'checkcc':
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/compat//scalar-by-value-4_x.c:72:
interna
l compiler error: in emit_group_store, at expr.c:2084

Breakpoint 1, emit_group_store (orig_dst=0x83fffddea380, 
src=0x83fffddd0290, type=0x0, ssize=2) at ../../gcc/gcc/expr.c:1916
1916  enum machine_mode m = GET_MODE (orig_dst);
(gdb) bt
#0  emit_group_store (orig_dst=0x83fffddea380, src=0x83fffddd0290, 
type=0x0, ssize=2) at ../../gcc/gcc/expr.c:1916
#1  0x405e22b0 in assign_parm_remove_parallels (
data=0x83fffdff19c0) at ../../gcc/gcc/function.c:2433
#2  0x405e44d4 in assign_parm_setup_stack (all=0x83fffdff1968, 
parm=0x83fffdfb3b40, data=0x83fffdff19c0)
at ../../gcc/gcc/function.c:2845
#3  0x405e5b5c in assign_parms (fndecl=0x83fffdfa0f00)
at ../../gcc/gcc/function.c:3054
#4  0x405ecec4 in expand_function_start (subr=0x83fffdfa0f00)
at ../../gcc/gcc/function.c:4313
#5  0x40df06c8 in gimple_expand_cfg ()
at ../../gcc/gcc/cfgexpand.c:2300
#6  0x4073ed20 in execute_one_pass (pass=0x80010004ab78)
at ../../gcc/gcc/passes.c:1277
#7  0x4073f29c in execute_pass_list (pass=0x80010004ab78)
at ../../gcc/gcc/passes.c:1325
#8  0x40962824 in tree_rest_of_compilation (fndecl=0x83fffdfa0f00)
at ../../gcc/gcc/tree-optimize.c:418
#9  0x40cc7480 in cgraph_expand_function (node=0x83fffdfbb000)
at ../../gcc/gcc/cgraphunit.c:1039
#10 0x40cc7c64 in cgraph_output_in_order ()
at ../../gcc/gcc/cgraphunit.c:1190
---Type  to continue, or q  to quit---
#11 0x40cc82dc in cgraph_optimize ()
at ../../gcc/gcc/cgraphunit.c:1301
#12 0x401cc1b4 in c_write_global_declarations ()
at ../../gcc/gcc/c-decl.c:8080
#13 0x40891ad4 in compile_file () at ../../gcc/gcc/toplev.c:979
#14 0x4089586c in do_compile () at ../../gcc/gcc/toplev.c:2181
#15 0x40895988 in toplev_main (argc=16, argv=0x83fffdff0620)
at ../../gcc/gcc/toplev.c:2213
#16 0x402c5ae8 in main (argc=-2147482625, argv=0x83fffddd0290)
at ../../gcc/gcc/main.c:35

(gdb) p bytepos
$1 = 0
(gdb) p debug_rtx (src)
(parallel:CQI [
(expr_list:REG_DEP_TRUE (reg:DI 26 %r26 [ x ])
(const_int 0 [0x0]))
])
$2 = void
(gdb) p dest_size
$3 = 2
(gdb) p tmp_size
$4 = 8


-- 
   Summary: [4.4 Regression] gcc.dg/compat//scalar-by-value-
4_x.c:72: ICE: in emit_group_store, at expr.c:2084
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
 GCC build triplet: hppa64-hp-hpux11.11
  GCC host triplet: hppa64-hp-hpux11.11
GCC target triplet: hppa64-hp-hpux11.11


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

[Bug middle-end/37318] [4.4 Regression] gcc.dg/compat//scalar-by-value-4_x.c:72: ICE: in emit_group_store, at expr.c:2084

[danglin at gcc dot gnu dot org]

--- Comment #1 from danglin at gcc dot gnu dot org  2008-09-01 19:08 ---
Also,

(gdb) p debug_rtx (orig_dst)
(concat:CQI (reg:QI 95)
(reg:QI 96))


-- 


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

[Bug fortran/37319] New: [4.4 Regression] FAIL: gfortran.dg/function_kinds_5.f90

[dominiq at lps dot ens dot fr]

Between revisions 139588 (working) and 139622 (broken), the test
gfortran.dg/function_kinds_5.f90 started to fail: the expected error is no
longer emitted:

[ibook-dhum] f90/bug% gfc -c
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/function_kinds_5.f90
[ibook-dhum] f90/bug% gfortran -c
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/function_kinds_5.f90
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/function_kinds_5.f90:8.6:

real (bad_kind(0d0)) function foo () ! { dg-error "must be an intrinsic or" }
 1
Error: Function 'bad_kind' in initialization expression at (1) must be an
intrinsic or a specification function

where gfortran is 4.3.2.

I have reported it and other regressions which appeared at this time in comment
#9 of pr37243.


-- 
   Summary: [4.4 Regression] FAIL: gfortran.dg/function_kinds_5.f90
   Product: gcc
   Version: 4.4.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
 GCC build triplet: i686-apple-darwin9
  GCC host triplet: i686-apple-darwin9
GCC target triplet: i686-apple-darwin9


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

[Bug c++/37234] [c++0x] =default definition outside template class fails

[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|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-09-01 19:34:49
   date||


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

[Bug c++/37288] ICE using auto as function return type or parameter

[jason at gcc dot gnu dot org]

--- Comment #3 from jason at gcc dot gnu dot org  2008-09-01 19:35 ---
Fixed.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/37006] explicitly deleted inline function gives warning "used but never defined"

[jason at gcc dot gnu dot org]

--- Comment #4 from jason at gcc dot gnu dot org  2008-09-01 19:35 ---
Fixed.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/37317] gfortran generates incorrect lbound and ubound

[rosinskijm at ornl dot gov]

--- Comment #2 from rosinskijm at ornl dot gov  2008-09-01 19:36 ---
Thank you for the quick response. Glad the bug is fixed in newer releases. Feel
free to close the bug, or is the reporter supposed to do that?


-- 


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

[Bug middle-end/37320] New: [4.4 Regression] gcc.dg/compat execute test fails

[danglin at gcc dot gnu dot org]

FAIL: gcc.dg/compat/struct-by-value-1 c_compat_x_tst.o-c_compat_y_tst.o execute 
FAIL: gcc.dg/compat/struct-by-value-2 c_compat_x_tst.o-c_compat_y_tst.o execute 
FAIL: gcc.dg/compat/struct-by-value-3 c_compat_x_tst.o-c_compat_y_tst.o execute 
FAIL: gcc.dg/compat/struct-by-value-4 c_compat_x_tst.o-c_compat_y_tst.o execute 
FAIL: gcc.dg/compat/struct-by-value-5a c_compat_x_tst.o-c_compat_y_tst.o
execute
FAIL: gcc.dg/compat/struct-layout-1 c_compat_x_tst.o-c_compat_y_tst.o execute 
FAIL: gcc.dg/compat/struct-return-2 c_compat_x_tst.o-c_compat_y_tst.o execute 
FAIL: gcc.dg/compat/struct-return-3 c_compat_x_tst.o-c_compat_y_tst.o execute 
FAIL: gcc.dg/compat/union-by-value-1 c_compat_x_tst.o-c_compat_y_tst.o execute 
FAIL: gcc.dg/compat/union-return-1 c_compat_x_tst.o-c_compat_y_tst.o execute 
FAIL: tmpdir-gcc.dg-struct-layout-1/t001 c_compat_x_tst.o-c_compat_y_tst.o
execute 
FAIL: tmpdir-gcc.dg-struct-layout-1/t002 c_compat_x_tst.o-c_compat_y_tst.o
execute 
FAIL: tmpdir-gcc.dg-struct-layout-1/t003 c_compat_x_tst.o-c_compat_y_tst.o
execute 
FAIL: tmpdir-gcc.dg-struct-layout-1/t004 c_compat_x_tst.o-c_compat_y_tst.o
execute 
FAIL: tmpdir-gcc.dg-struct-layout-1/t007 c_compat_x_tst.o-c_compat_y_tst.o
execute 
FAIL: tmpdir-gcc.dg-struct-layout-1/t024 c_compat_x_tst.o-c_compat_y_tst.o
execute 
FAIL: tmpdir-gcc.dg-struct-layout-1/t025 c_compat_x_tst.o-c_compat_y_tst.o
execute 
FAIL: tmpdir-gcc.dg-struct-layout-1/t026 c_compat_x_tst.o-c_compat_y_tst.o
execute 
FAIL: tmpdir-gcc.dg-struct-layout-1/t028 c_compat_x_tst.o-c_compat_y_tst.o
execute


-- 
   Summary: [4.4 Regression] gcc.dg/compat execute test fails
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
 GCC build triplet: hppa64-hp-hpux11.11
  GCC host triplet: hppa64-hp-hpux11.11
GCC target triplet: hppa64-hp-hpux11.11


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

[Bug debug/37321] New: FAIL: gcc.dg/debug/dwarf2/dwarf-die3.c scan-assembler-not DW_AT_inline

[danglin at gcc dot gnu dot org]

Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/te
st/gnu/gcc/gcc/gcc/testsuite/gcc.dg/debug/dwarf2/dwarf-die3.c   -O0 -gdwarf-2
-d
A -S  -o dwarf-die3.s(timeout = 300)
PASS: gcc.dg/debug/dwarf2/dwarf-die3.c (test for excess errors)
FAIL: gcc.dg/debug/dwarf2/dwarf-die3.c scan-assembler-not DW_AT_inline


-- 
   Summary: FAIL: gcc.dg/debug/dwarf2/dwarf-die3.c scan-assembler-
not DW_AT_inline
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
 GCC build triplet: hppa64-hp-hpux11.11
  GCC host triplet: hppa64-hp-hpux11.11
GCC target triplet: hppa64-hp-hpux11.11


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

[Bug debug/37322] New: FAIL: gfortran.dg/debug/pr35154-dwarf2.f

[dominiq at lps dot ens dot fr]

On 686-apple-darwin9 between revisions 139622 (working or not implemented) and
139843 (broken) I have the following failures:

FAIL: gfortran.dg/debug/pr35154-dwarf2.f -gdwarf-2 scan-assembler DW_AT_name:
"__BLNK__"
FAIL: gfortran.dg/debug/pr35154-dwarf2.f -gdwarf-2 scan-assembler DW_AT_name:
"label"

looking at the assembly code I see:

.indirect_symbol ___BLNK__
.indirect_symbol _label_

but no 'DW_AT_name:'.

Note tha my comment #5 in pr35154 is invalid.


-- 
   Summary: FAIL: gfortran.dg/debug/pr35154-dwarf2.f
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
 GCC build triplet: i686-apple-darwin9
  GCC host triplet: i686-apple-darwin9
GCC target triplet: i686-apple-darwin9


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

[Bug middle-end/37323] New: [4.4 Regression] __builtin_apply failures

[danglin at gcc dot gnu dot org]

FAIL: gcc.dg/builtin-apply2.c execution test
FAIL: gcc.dg/builtin-apply3.c execution test
FAIL: gcc.dg/builtin-apply4.c execution test


-- 
   Summary: [4.4 Regression] __builtin_apply failures
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
 GCC build triplet: hppa64-hp-hpux11.11
  GCC host triplet: hppa64-hp-hpux11.11
GCC target triplet: hppa64-hp-hpux11.11


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

[Bug middle-end/37323] [4.4 Regression] __builtin_apply failures

[danglin at gcc dot gnu dot org]

--- Comment #1 from danglin at gcc dot gnu dot org  2008-09-01 19:52 ---
Also,
FAIL: gcc.dg/builtin-return-1.c execution test


-- 


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

[Bug preprocessor/37324] New: FAIL: gcc.dg/utf-array.c (test for errors)

[danglin at gcc dot gnu dot org]

Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/te
st/gnu/gcc/gcc/gcc/testsuite/gcc.dg/utf-array.c   -std=gnu99 -S  -o utf-array.s 
   (timeout = 300)
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/utf-array.c:12: error: char-array
initial
ized from wide string
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/utf-array.c:13: error: char-array
initial
ized from wide string
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/utf-array.c:14: error: char-array
initial
ized from wide string
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/utf-array.c:16: error: wide character
arr
ay initialized from non-wide string
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/utf-array.c:18: error: wide character
arr
ay initialized from incompatible wide string
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/utf-array.c:19: error: wide character
arr
ay initialized from incompatible wide string
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/utf-array.c:21: warning:
initializer-stri
ng for array of chars is too long
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/utf-array.c:22: warning:
initializer-stri
ng for array of chars is too long
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/utf-array.c:27: error: wide character
arr
ay initialized from non-wide string
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/utf-array.c:28: error: wide character
arr
ay initialized from incompatible wide string
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/utf-array.c:32: warning:
initializer-stri
ng for array of chars is too long
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/utf-array.c:33: warning:
initializer-stri
ng for array of chars is too long
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/utf-array.c:38: error: wide character
arr
ay initialized from non-wide string
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/utf-array.c:39: error: wide character
arr
ay initialized from incompatible wide string
compiler exited with status 1
output is:
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/utf-array.c:12: error: char-array
initial
ized from wide string
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/utf-array.c:13: error: char-array
initial
ized from wide string
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/utf-array.c:14: error: char-array
initial
ized from wide string
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/utf-array.c:16: error: wide character
arr
ay initialized from non-wide string
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/utf-array.c:18: error: wide character
arr
ay initialized from incompatible wide string
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/utf-array.c:19: error: wide character
arr
ay initialized from incompatible wide string
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/utf-array.c:21: warning:
initializer-stri
ng for array of chars is too long
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/utf-array.c:22: warning:
initializer-stri
ng for array of chars is too long
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/utf-array.c:27: error: wide character
arr
ay initialized from non-wide string
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/utf-array.c:28: error: wide character
arr
ay initialized from incompatible wide string
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/utf-array.c:32: warning:
initializer-stri
ng for array of chars is too long
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/utf-array.c:33: warning:
initializer-stri
ng for array of chars is too long
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/utf-array.c:38: error: wide character
arr
ay initialized from non-wide string
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/utf-array.c:39: error: wide character
arr
ay initialized from incompatible wide string

PASS: gcc.dg/utf-array.c  (test for errors, line 12)
PASS: gcc.dg/utf-array.c  (test for errors, line 13)
PASS: gcc.dg/utf-array.c  (test for errors, line 14)
PASS: gcc.dg/utf-array.c  (test for errors, line 16)
PASS: gcc.dg/utf-array.c  (test for errors, line 18)
PASS: gcc.dg/utf-array.c  (test for errors, line 19)
PASS: gcc.dg/utf-array.c  (test for warnings, line 21)
PASS: gcc.dg/utf-array.c  (test for warnings, line 22)
PASS: gcc.dg/utf-array.c  (test for errors, line 27)
PASS: gcc.dg/utf-array.c  (test for errors, line 28)
FAIL: gcc.dg/utf-array.c  (test for errors, line 30)
PASS: gcc.dg/utf-array.c  (test for warnings, line 32)
PASS: gcc.dg/utf-array.c  (test for warnings, line 33)
PASS: gcc.dg/utf-array.c  (test for errors, line 38)
PASS: gcc.dg/utf-array.c  (test for errors, line 39)
FAIL: gcc.dg/utf-array.c  (test for errors, line 40)
PASS: gcc.dg/utf-array.c (test for excess errors)


-- 
   Summary: FAIL: gcc.dg/utf-array.c  (test for errors)
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
 GCC build triplet: hppa64-hp-hpux11.11
  GCC host triplet: hppa64-hp-hpux11.11
GCC target triplet: hppa64-hp-hpux11.11


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

[Bug testsuite/37325] New: Visibility test fails

[danglin at gcc dot gnu dot org]

FAIL: gcc.dg/visibility-14.c scan-hidden hidden[ \t_]*foo
FAIL: gcc.dg/visibility-15.c scan-hidden hidden[ \t_]*foo
FAIL: gcc.dg/visibility-16.c scan-hidden hidden[ \t_]*foo
FAIL: gcc.dg/visibility-17.c scan-hidden hidden[ \t_]*foo
FAIL: gcc.dg/visibility-18.c scan-hidden hidden[ \t_]*foo
FAIL: gcc.dg/visibility-19.c scan-hidden hidden[ \t_]*foo


-- 
   Summary: Visibility test fails
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
 GCC build triplet: hppa64-hp-hpux11.11
  GCC host triplet: hppa64-hp-hpux11.11
GCC target triplet: hppa64-hp-hpux11.11


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

[Bug pch/37307] [4.4 Regression]: g++.dg/pch/system-2.C

[hp at gcc dot gnu dot org]

--- Comment #2 from hp at gcc dot gnu dot org  2008-09-01 20:15 ---
Actually ... failing: 139762.  So, rguenth is no longer a suspect.


-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

 CC|rguenth at gcc dot gnu dot  |
   |org |


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

[Bug middle-end/37316] [4.4 Regression] Small structs are not passed correctly on hppa64-*-*

[danglin at gcc dot gnu dot org]

--- Comment #2 from danglin at gcc dot gnu dot org  2008-09-01 20:19 ---
Also, these seem related:

FAIL: gcc.dg/torture/pr30665-2.c  -O0  execution test
FAIL: gcc.dg/torture/pr30665-2.c  -O1  execution test
FAIL: gcc.dg/torture/pr30665-2.c  -O2  execution test
FAIL: gcc.dg/torture/pr30665-2.c  -O3 -fomit-frame-pointer  execution test
FAIL: gcc.dg/torture/pr30665-2.c  -O3 -g  execution test
FAIL: gcc.dg/torture/pr30665-2.c  -Os  execution test


-- 


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

[Bug testsuite/37326] New: AIL: gcc.dg/tree-ssa/ssa-store-ccp-3.c scan-tree-dump-times optimized "conststaticvariable" 1

[danglin at gcc dot gnu dot org]

Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/te
st/gnu/gcc/gcc/gcc/testsuite/gcc.dg/tree-ssa/ssa-store-ccp-3.c   -O2
-fno-common
 -fdump-tree-optimized -S  -o ssa-store-ccp-3.s(timeout = 300)
PASS: gcc.dg/tree-ssa/ssa-store-ccp-3.c (test for excess errors)
FAIL: gcc.dg/tree-ssa/ssa-store-ccp-3.c scan-tree-dump-times optimized
"conststa
ticvariable" 1

# less ssa-store-ccp-3.c.123t.optimized

;; Function f (f)

Analyzing Edge Insertions.
f ()
{
:
  return 0;

}


-- 
   Summary: AIL: gcc.dg/tree-ssa/ssa-store-ccp-3.c scan-tree-dump-
times optimized "conststaticvariable" 1
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
 GCC build triplet: hppa64-hp-hpux11.11
  GCC host triplet: hppa64-hp-hpux11.11
GCC target triplet: hppa64-hp-hpux11.11


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

[Bug middle-end/37248] [4.4 Regression] regression 4.3.1 -> 4.3.2-rc transformation bitfield to individual bytes

[etienne_lorrain at yahoo dot fr]

--- Comment #7 from etienne_lorrain at yahoo dot fr  2008-09-01 20:29 
---
Patch works for me, thanks.


-- 


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

Re: [Bug tree-optimization/37312] -Os significantly faster than -O2 on test case

[Andrew Thomas Pinski]

This is mostly because of extra register moves that IRA some times  
introduces. There is another bug about Inline-asm and the return  
register.


Sent from my iPhone

On Sep 1, 2008, at 7:36, "rguenth at gcc dot gnu dot org" <[EMAIL PROTECTED] 
> wrote:





--- Comment #4 from rguenth at gcc dot gnu dot org  2008-09-01  
14:36 ---
Well, now -Os -funroll-all-loops doesn't do any unrolling anymore  
while it did

before.  With -O2 you get what you ask for - unrolled loops.

-funroll-all-loops isn't really a flag to be used in general.


--


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

[Bug middle-end/37318] [4.4 Regression] gcc.dg/compat//scalar-by-value-4_x.c:72: ICE: in emit_group_store, at expr.c:2084

[joseph at codesourcery dot com]

--- Comment #2 from joseph at codesourcery dot com  2008-09-01 20:40 ---
Subject: Re:  [4.4 Regression] gcc.dg/compat//scalar-by-value-4_x.c:72:
 ICE: in emit_group_store, at expr.c:2084

Someone needs to review HJ's patch

http://gcc.gnu.org/ml/gcc-patches/2008-08/msg01078.html

that fixes such a failure at least for IA64 (the failure is seen on 
several targets).


-- 


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

[Bug tree-optimization/37312] -Os significantly faster than -O2 on test case wiht -funroll-all-loops

[pinskia at gmail dot com]

--- Comment #5 from pinskia at gmail dot com  2008-09-01 20:41 ---
Subject: Re:  -Os significantly faster than -O2 on test case

This is mostly because of extra register moves that IRA some times  
introduces. There is another bug about Inline-asm and the return  
register.

Sent from my iPhone

On Sep 1, 2008, at 7:36, "rguenth at gcc dot gnu dot org"
<[EMAIL PROTECTED] 
 > wrote:

>
>
> --- Comment #4 from rguenth at gcc dot gnu dot org  2008-09-01  
> 14:36 ---
> Well, now -Os -funroll-all-loops doesn't do any unrolling anymore  
> while it did
> before.  With -O2 you get what you ask for - unrolled loops.
>
> -funroll-all-loops isn't really a flag to be used in general.
>
>
> -- 
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37312
>


-- 


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