[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API

[hjl at lucon dot org]

--- Comment #16 from hjl at lucon dot org  2007-12-17 07:01 ---
(In reply to comment #13)
>
> 
> Now that we have ext/hash_map and ext/hash_set back (yes, SPEC2000
> eon still is broken, as it uses the removed iostream.h and other *.h

FWIW, I have 252.eon.gcc43.src.alt.tar.bz2, which works for gcc 4.x. Of course,
it isn't an offical src.alt.


-- 


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

[Bug fortran/30388] gfortran42 is slower than g77 3.4 about 10%

[steven at gcc dot gnu dot org]

--- Comment #13 from steven at gcc dot gnu dot org  2007-12-17 06:33 ---
-fipa-pta is broken iirc.


-- 


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

[Bug bootstrap/32009] [4.3 Regression] building gcc4-4.3.0-20070518 failed on OSX 10.3.9

[bonzini at gnu dot org]

--- Comment #23 from bonzini at gnu dot org  2007-12-17 06:14 ---
You're perfectly right; OTOH if I hadn't meant to fix it, I would have
unassigned it.  Sometimes people are busy, and for a build patch I usually do
more than bootstrap/regtest on one architecture.


-- 


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

[Bug fortran/30388] gfortran42 is slower than g77 3.4 about 10%

[jvdelisle at gcc dot gnu dot org]

--- Comment #12 from jvdelisle at gcc dot gnu dot org  2007-12-17 06:10 
---
Here is a twist on the test case

 gfc -O2 -m64 -ffast-math -funroll-all-loops -fipa-pta -fivopts poisson.f 
poisson.f:111.72:

  pause 
   1
Warning: Deleted feature: PAUSE statement at (1)
poisson.f: In function ‘jacobi’:
poisson.f:233: error: stmt (0x2eb4f300) marked modified after optimization
pass: 
D.1063_9 = *nn_8(D);
poisson.f:233: internal compiler error: verify_ssa failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 


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

[Bug fortran/34476] Parameters: Bogus out of bounds error in array constructor

[pault at gcc dot gnu dot org]

--- Comment #1 from pault at gcc dot gnu dot org  2007-12-17 05:41 ---
4.2 gives a second error:

   integer(1), parameter :: ARR1(len(HEX1)) = [( MSKa1(i), i=1,len(HEX1) )]
  1
Error: index in dimension 1 is out of bounds at (1)
pr34476.f90:5.44:

   integer(1), parameter :: MSKa1(len(HEX1)) =  [(1,i=1,len(HEX1))]
   1
Error: Parameter array 'mska1' at (1) cannot be automatic or assumed shape

Paul


-- 


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

[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API

[mark at codesourcery dot com]

--- Comment #15 from mark at codesourcery dot com  2007-12-17 04:34 ---
Subject: Re:  [4.3 Regression] Revision 129442 breaks
 libstc++ API

rguenther at suse dot de wrote:

> Now that we have ext/hash_map and ext/hash_set back (yes, SPEC2000
> eon still is broken, as it uses the removed iostream.h and other *.h
> headers - and it's impossible to fix without touching all of it)
> the issue isn't as pressing anymore.  Though still the question
> remains if we should break the libstdc++ API at all.

There seemed to be pretty good consensus that we shouldn't.  So far,
other than maintenance pain, I've not seen an argument for removing
things like iostream.h.  And, I think user pain should trump maintenance
pain in this case.


-- 


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

[Bug bootstrap/32009] [4.3 Regression] building gcc4-4.3.0-20070518 failed on OSX 10.3.9

[mrs at apple dot com]

--- Comment #22 from mrs at apple dot com  2007-12-17 04:10 ---
:-(


-- 


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

[Bug target/30572] [4.3 Regression] target libraries links against /libgcc_s.1.dylib instead of $(prefix)/lib/libgcc_s.1.dylib

[howarth at nitro dot med dot uc dot edu]

--- Comment #16 from howarth at nitro dot med dot uc dot edu  2007-12-17 
02:55 ---
My mistake. I had forgotten to check the contents of the binaries.

Eric,
Shouldn't this go into gcc trunk (with perhaps a TODO comment that a
cleaner approach should replace it)?


-- 


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

[Bug c++/19159] [4.0/4.1/4.2/4.3 Regression] Undefined symbol: vtable for __cxxabiv1::__vmi_class_type_info

[mmitchel at gcc dot gnu dot org]

--- Comment #39 from mmitchel at gcc dot gnu dot org  2007-12-17 02:07 
---
Downgraded to P4 based on Comment #34.


-- 

mmitchel at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P2  |P4


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

[Bug target/30572] [4.3 Regression] target libraries links against /libgcc_s.1.dylib instead of $(prefix)/lib/libgcc_s.1.dylib

[ek dot kato at gmail dot com]

--- Comment #15 from ek dot kato at gmail dot com  2007-12-17 02:02 ---
(In reply to comment #14)
> Etsushi,
>  Your last patch doesn't do the right thing for the x86_64 multilib. The
> shared libraries in...
> 
> /sw/lib/gcc4.3/lib/x86_64
> 
> ...are linked to /sw/lib/gcc4.3/lib/libgcc_s.1.dylib instead of the desired
> /sw/lib/gcc4.3/lib/x86_64/libgcc_s.1.dylib.

Since /sw/lib/gcc4.3/lib/libgcc_s.1.dylib is a binary with 2 architectures
(i386 and x86_64 in my case; see below), I think it should work and the links
are intended one, which is not related the last patch.

$ file /sw/lib/gcc4.3/lib/libgcc_s.1.dylib
/sw/lib/gcc4.3/lib/libgcc_s.1.dylib: Mach-O universal binary with 2
architectures
/sw/lib/gcc4.3/lib/libgcc_s.1.dylib (for architecture i386):Mach-O
dynamically linked shared library i386
/sw/lib/gcc4.3/lib/libgcc_s.1.dylib (for architecture x86_64):  Mach-O 64-bit
dynamically linked shared library x86_64


-- 


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

[Bug c++/19159] [4.0/4.1/4.2/4.3 Regression] Undefined symbol: vtable for __cxxabiv1::__vmi_class_type_info

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #38 from dave at hiauly1 dot hia dot nrc dot ca  2007-12-17 
02:02 ---
Subject: Re:  [4.0/4.1/4.2/4.3 Regression] Undefined symbol: vtable for
__cxxabiv1::__vmi_class_type_info

> Open regression with no activity since February 14.  Ping?

No update from my side.  I don't usually build and test the AIX
port, so I'm not aware if there's been any progress.  I was asked
by a client to work on trying to improve the C++ support in 4.x.
At the moment, they are still using 3.4.3.

Dave


-- 


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

[Bug other/34502] New: -iwithprefix does not locate DIR where -idirafter would

[kaminaga at sm dot sony dot co dot jp]

I'm assuming -iprefix + -iwithprefix would locate DIR to same place as
if specified by -idirafter, from below info gcc:

`-iwithprefix DIR'
`-iwithprefixbefore DIR'
 Append DIR to the prefix specified previously with `-iprefix', and
 add the resulting directory to the include search path.
 `-iwithprefixbefore' puts it in the same place `-I' would;
 `-iwithprefix' puts it where `-idirafter' would.


However, it didn't with gcc-4.1.2 (FC7):
(it was same with FC3, gcc-3.4.2)

$ cat test.c 
/* this should be included by system directory's include/err.h */
#include 

$ cat ./include/err.h 
#error "Choke me"

$ gcc -iprefix ./ -iwithprefix include/ -c test.c 
In file included from test.c:2:
./include/err.h:1:2: error: #error "Choke me"
$ gcc -idirafter ./include/ -c test.c 
$ 

With -idirafter -v, include search path was:
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/lib/gcc/i386-redhat-linux/4.1.2/include
 /usr/include
 ./include/
End of search list.

Whereas -iwitprefix -v, include search path was:
#include "..." search starts here:
#include <...> search starts here:
 ./include/
 /usr/local/include
 /usr/lib/gcc/i386-redhat-linux/4.1.2/include
 /usr/include

So, as opposed to the gcc info, -iwithprefix does not seem to put DIR
where -idirafter would.


-- 
   Summary: -iwithprefix does not locate DIR where -idirafter would
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kaminaga at sm dot sony dot co dot jp


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

[Bug libfortran/34427] [4.3 Regression] Revision 130708 breaks namelist input

[jvdelisle at gcc dot gnu dot org]

--- Comment #33 from jvdelisle at gcc dot gnu dot org  2007-12-17 00:51 
---
Subject: Bug 34427

Author: jvdelisle
Date: Mon Dec 17 00:51:25 2007
New Revision: 131004

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131004
Log:
2007-12-16  Jerry DeLisle  <[EMAIL PROTECTED]>

PR fortran/34427
* gfortran.dg/namelist_42.f90: Update.
* gfortran.dg/namelist_43.f90: New.

Added:
trunk/gcc/testsuite/gfortran.dg/namelist_43.f90
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/namelist_42.f90


-- 


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

[Bug libfortran/34427] [4.3 Regression] Revision 130708 breaks namelist input

[jvdelisle at gcc dot gnu dot org]

--- Comment #32 from jvdelisle at gcc dot gnu dot org  2007-12-17 00:47 
---
Subject: Bug 34427

Author: jvdelisle
Date: Mon Dec 17 00:47:14 2007
New Revision: 131003

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131003
Log:
2007-12-16  Jerry DeLisle  <[EMAIL PROTECTED]>

PR fortran/34427
* io/list_read.c (read_real): Handle intervening line ends and spaces.
(get_name): Don't push separators to saved_string.
(eat_separator): If in namelist mode eat spaces and line ends as well.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/list_read.c


-- 


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

[Bug bootstrap/34003] [4.1/4.2 Regression] gcc trunk unable to bootstrap itself; Unsatisfied symbols: ggc_free

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #38 from dave at hiauly1 dot hia dot nrc dot ca  2007-12-17 
00:05 ---
Subject: Re:  [4.1/4.2 Regression] gcc trunk unable to bootstrap itself;
Unsatisfied symbols: ggc_free

> Changed subject to avoid this bug matching in the 4.3 serious bugs query where
> it is already fixed.

Possibly, the priority and and severity should be adjusted?

Dave


-- 


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

[Bug middle-end/29215] [4.0/4.1/4.2/4.3 Regression] extra store for memcpy

[pinskia at gcc dot gnu dot org]

--- Comment #12 from pinskia at gcc dot gnu dot org  2007-12-16 23:55 
---
These are just extra stores.  This looks exactly like PR 30271.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn||30271
   GCC host triplet|i386--netbsdelf |
 GCC target triplet||i386--netbsdelf
  Known to work|3.4.0   |3.4.0 4.3.0
Summary|[4.0/4.1/4.2/4.3 Regression]|[4.0/4.1/4.2/4.3 Regression]
   |memcpy is not fully |extra store for memcpy
   |optimized any more  |


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

[Bug rtl-optimization/21676] [4.0/4.1/4.2/4.3 Regression] Optimizer regression: SciMark sparse matrix benchmark

[ubizjak at gmail dot com]

--- Comment #12 from ubizjak at gmail dot com  2007-12-16 23:49 ---
(In reply to comment #11)
> Open regression with no activity since February 14.  Ping?

Current 4.3 SVN produces (-O3 -march=pentium4):

.L8:
movl(%ebx), %eax#* ivtmp.33, tmp84
fldl(%edi,%eax,8)   #
fmull   (%ecx)  #* ivtmp.35
faddp   %st, %st(1) #,
addl$1, %edx#, i
addl$4, %ebx#, ivtmp.33
addl$8, %ecx#, ivtmp.35
cmpl%edx, %esi  # i, rowRp1
jg  .L8 #,

(+ -fno-ivopts):

.L8:
movl(%esi,%edx,4), %eax #, tmp76
fldl(%edi,%eax,8)   #* x
movl16(%ebp), %eax  # val,  <-here
fmull   (%eax,%edx,8)   #
faddp   %st, %st(1) #,
addl$1, %edx#, i
cmpl%edx, %ecx  # i, rowRp1
jg  .L8 #,

We regressed vs. 4.2 in this case; "val" is loaded inside the loop.


-- 


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

[Bug bootstrap/34003] [4.1/4.2 Regression] gcc trunk unable to bootstrap itself; Unsatisfied symbols: ggc_free

[jakub at gcc dot gnu dot org]

--- Comment #37 from jakub at gcc dot gnu dot org  2007-12-16 23:40 ---
Changed subject to avoid this bug matching in the 4.3 serious bugs query where
it is already fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.1/4.2 Regression] gcc|[4.1/4.2 Regression] gcc
   |4.3.0 unable to bootstrap   |trunk unable to bootstrap
   |itself; Unsatisfied symbols:|itself; Unsatisfied symbols:
   |ggc_free|ggc_free


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

[Bug bootstrap/32009] [4.3 Regression] building gcc4-4.3.0-20070518 failed on OSX 10.3.9

[steven at gcc dot gnu dot org]

--- Comment #21 from steven at gcc dot gnu dot org  2007-12-16 23:32 ---
P1 blocker regression for GCC 4.3, and no activity for 3 months.

PING!

Either someone at Apple or Paolo should show some activity here.  Otherwise we
might as well close this as WONTFIX, assuming it is apparently not important
enough for anyone to spend some time on.

Mark, is there a policy to downgrade bug severities if something is marked as a
P1 blocker bug, but apparently nobody thinks it is important enough to fix it
quickly?


-- 


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

[Bug other/25028] TImode-to-floating conversions broken

[ubizjak at gmail dot com]

--- Comment #11 from ubizjak at gmail dot com  2007-12-16 23:27 ---
*** Bug 34473 has been marked as a duplicate of this bug. ***


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 CC||james at albanarts dot com


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

[Bug target/34473] casting negative __int128_t to float/double rounds to nearest multiple of 2048

[ubizjak at gmail dot com]

--- Comment #6 from ubizjak at gmail dot com  2007-12-16 23:27 ---
... to close as duplicate of PR 25028.

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


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug target/34473] casting negative __int128_t to float/double rounds to nearest multiple of 2048

[ubizjak at gmail dot com]

--- Comment #5 from ubizjak at gmail dot com  2007-12-16 23:27 ---
Reopened ...


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|WONTFIX |


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

[Bug c++/31780] [4.2/4.3 regression] ICE with incompatible types for ?: with "complex type" conversion

[steven at gcc dot gnu dot org]

--- Comment #15 from steven at gcc dot gnu dot org  2007-12-16 23:26 ---
P1 regression and >2.5 months without activity.

PING!


-- 


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

[Bug debug/26364] [4.0/4.1/4.2/4.3 regression] [no unit-at-a-time mode] Uninlined function is marked as inlined

[steven at gcc dot gnu dot org]

--- Comment #10 from steven at gcc dot gnu dot org  2007-12-16 23:24 ---
Could this be fixed by rejecting -finline-functions-called-once if
-fno-unit-at-a-time is given?  A patch to do this should be quite trivial.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug target/34025] Warning when compiling with -m64 -ffast-math on Intel Darwin

[uros at gcc dot gnu dot org]

--- Comment #17 from uros at gcc dot gnu dot org  2007-12-16 23:22 ---
Subject: Bug 34025

Author: uros
Date: Sun Dec 16 23:22:30 2007
New Revision: 130998

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130998
Log:
PR target/34025
* config/i386/t-crtpc: Add $(MULTILIB_CFLAGS).
* config/i386/t-crtfm: Likewise.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/t-crtfm
trunk/gcc/config/i386/t-crtpc


-- 


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

[Bug c++/27177] [4.0/4.1/4.2/4.3 Regression] ICE in build_simple_base_path, at cp/class.c:474

[steven at gcc dot gnu dot org]

--- Comment #14 from steven at gcc dot gnu dot org  2007-12-16 23:21 ---
Ping!


-- 


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

[Bug c++/29469] [DR 224] [4.1/4.2/4.3 Regression] error: non-template 'pair' used as template

[steven at gcc dot gnu dot org]

--- Comment #8 from steven at gcc dot gnu dot org  2007-12-16 23:20 ---
Waiting for DR -> SUSPENDED.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED


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

[Bug c++/29607] [DR 224] [4.1/4.2/4.3 Regression] dependent name with base classes

[steven at gcc dot gnu dot org]

--- Comment #12 from steven at gcc dot gnu dot org  2007-12-16 23:19 ---
If we are waiting for a DR, this PR should be SUSPENDED, not WAITING.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED


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

[Bug preprocessor/30363] [4.0/4.1/4.2/4.3 Regression] Support for -traditional-cpp is incomplete in current gcc relative to gcc 2.95.3

[steven at gcc dot gnu dot org]

--- Comment #4 from steven at gcc dot gnu dot org  2007-12-16 23:18 ---
Open regression with no activity since February 14.  Ping?


-- 


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

[Bug tree-optimization/29484] [4.0/4.1/4.2/4.3 Regression] tree-inline.c bug with local static vars

[steven at gcc dot gnu dot org]

--- Comment #4 from steven at gcc dot gnu dot org  2007-12-16 23:18 ---
Open regression with no activity since February 14.  Ping?


-- 


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

[Bug middle-end/29215] [4.0/4.1/4.2/4.3 Regression] memcpy is not fully optimized any more

[steven at gcc dot gnu dot org]

--- Comment #11 from steven at gcc dot gnu dot org  2007-12-16 23:18 ---
Open regression with no activity since February 14.  Ping?


-- 


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

[Bug debug/27017] [4.0/4.1/4.2/4.3 Regression] Debug information for static local class members are not emitted

[steven at gcc dot gnu dot org]

--- Comment #11 from steven at gcc dot gnu dot org  2007-12-16 23:18 ---
Open regression with no activity since February 14.  Ping?


-- 


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

[Bug c++/26965] [4.0/4.1/4.2/4.3 Regression] Unnecessary debug info for unused consts in C++

[steven at gcc dot gnu dot org]

--- Comment #13 from steven at gcc dot gnu dot org  2007-12-16 23:18 ---
Open regression with no activity since February 14.  Ping?


-- 


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

[Bug c++/26266] [4.0/4.1/4.2/4.3 regression] Trouble with static const data members in template classes

[steven at gcc dot gnu dot org]

--- Comment #19 from steven at gcc dot gnu dot org  2007-12-16 23:18 ---
Open regression with no activity since February 14.  Ping?


-- 


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

[Bug tree-optimization/23821] [4.0/4.1/4.2/4.3 Regression] DOM and VRP creating harder to optimize code

[steven at gcc dot gnu dot org]

--- Comment #12 from steven at gcc dot gnu dot org  2007-12-16 23:17 ---
Open regression with no activity since February 14.  Ping?


-- 


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

[Bug middle-end/22141] [4.0/4.1/4.2/4.3 Regression] Missing optimization when storing structures

[steven at gcc dot gnu dot org]

--- Comment #6 from steven at gcc dot gnu dot org  2007-12-16 23:17 ---
Open regression with no activity since February 14.  Ping?


-- 


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

[Bug rtl-optimization/21676] [4.0/4.1/4.2/4.3 Regression] Optimizer regression: SciMark sparse matrix benchmark

[steven at gcc dot gnu dot org]

--- Comment #11 from steven at gcc dot gnu dot org  2007-12-16 23:17 ---
Open regression with no activity since February 14.  Ping?


-- 


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

[Bug c++/19159] [4.0/4.1/4.2/4.3 Regression] Undefined symbol: vtable for __cxxabiv1::__vmi_class_type_info

[steven at gcc dot gnu dot org]

--- Comment #37 from steven at gcc dot gnu dot org  2007-12-16 23:17 ---
Open regression with no activity since February 14.  Ping?


-- 


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

[Bug middle-end/18071] [4.0/4.1/4.2/4.3 Regression] -Winline does not respect -fno-default-inline

[steven at gcc dot gnu dot org]

--- Comment #28 from steven at gcc dot gnu dot org  2007-12-16 23:16 ---
Open regression with no activity since February 14.  Ping?


-- 


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

[Bug ada/34446] gnatprep evaluating "not" operator at incorrect precidence

[bdavis at gcc dot gnu dot org]

--- Comment #4 from bdavis at gcc dot gnu dot org  2007-12-16 23:05 ---
re-opened pending additional comments.


-- 

bdavis at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||bdavis at gcc dot gnu dot
   ||org
 Status|RESOLVED|UNCONFIRMED
 Resolution|FIXED   |


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

[Bug target/34384] Poor code generated when passing returned struct as a parameter

[sandmann at daimi dot au dot dk]

--- Comment #3 from sandmann at daimi dot au dot dk  2007-12-16 22:29 
---
[EMAIL PROTECTED] ~]$ gcc -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --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 --with-cpu=generic
--host=i386-redhat-linux
Thread model: posix
gcc version 4.1.2 20070925 (Red Hat 4.1.2-33)


-- 


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

[Bug bootstrap/34003] [4.1/4.2 Regression] gcc 4.3.0 unable to bootstrap itself; Unsatisfied symbols: ggc_free

[danglin at gcc dot gnu dot org]

--- Comment #36 from danglin at gcc dot gnu dot org  2007-12-16 22:23 
---
4.1 is also broken.


-- 

danglin at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.2 Regression] gcc 4.3.0  |[4.1/4.2 Regression] gcc
   |unable to bootstrap itself; |4.3.0 unable to bootstrap
   |Unsatisfied symbols:|itself; Unsatisfied symbols:
   |ggc_free|ggc_free


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

[Bug fortran/34495] [4.3 Regression] accepts invalid initialization expressions with -std=f95

[burnus at gcc dot gnu dot org]

--- Comment #4 from burnus at gcc dot gnu dot org  2007-12-16 22:14 ---
(From update of attachment 14779)
Still to do: Adding/Re-adding an error for:
  Error: PARAMETER PI used before its definition is complete


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #14779|0   |1
is obsolete||


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

[Bug fortran/34495] [4.3 Regression] accepts invalid initialization expressions with -std=f95

[burnus at gcc dot gnu dot org]

--- Comment #3 from burnus at gcc dot gnu dot org  2007-12-16 22:13 ---
Subject: Bug 34495

Author: burnus
Date: Sun Dec 16 22:12:55 2007
New Revision: 130994

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130994
Log:
2007-12-16  Tobias Burnus  <[EMAIL PROTECTED]>

PR fortran/34495
* intrinsic.c (add_functions): Mark float and sngl as STD_GNU.
(gfc_intrinsic_func_interface): Reject REAL, DBLE and CMPLX
in initialization expressions for -std=f95.

2007-12-16  Tobias Burnus  <[EMAIL PROTECTED]>

PR fortran/34495
* gfortran.dg/initialization_16.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/initialization_16.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/intrinsic.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug tree-optimization/34330] -ftree-parallelize-loops=4 ICE with the vectorizer also

[rakdver at gcc dot gnu dot org]

-- 

rakdver at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rakdver at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-12-10 00:23:44 |2007-12-16 22:07:18
   date||


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

[Bug c++/33943] [4.3 Regression] ICE with partial specialization on vararg template template parameter

[pcarlini at suse dot de]

--- Comment #7 from pcarlini at suse dot de  2007-12-16 21:57 ---
(In reply to comment #6)
  Also another thing is that
> we have some ODR violations in libstdc++ that the libstdc++ folks have not
> replied to me about yet.

Because such a thing doesn't exist. If the user wants to experiment (note,
experiment, we are talking about experimental implementations, I think the
announcement is pretty clear about that) with some library features that will
be likely available in the next C++ standard, he can compile with -std=c++0x.
Then he will be in the realm of another language, not the same as C++03. ODR
between what? Between a language and a different (eminently experimental)
language? By the way, the real library for the next standard will be something
very different (we haven't yet started on it), will badly break ABI, API and
everything imaginable.


-- 


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

[Bug fortran/34305] ICE with array(real) declaration

[tkoenig at gcc dot gnu dot org]

--- Comment #3 from tkoenig at gcc dot gnu dot org  2007-12-16 21:55 ---
Fixed on trunk.

Closing.


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug target/30572] [4.3 Regression] target libraries links against /libgcc_s.1.dylib instead of $(prefix)/lib/libgcc_s.1.dylib

[howarth at nitro dot med dot uc dot edu]

--- Comment #14 from howarth at nitro dot med dot uc dot edu  2007-12-16 
21:52 ---
Etsushi,
 Your last patch doesn't do the right thing for the x86_64 multilib. The
shared libraries in...

/sw/lib/gcc4.3/lib/x86_64

...are linked to /sw/lib/gcc4.3/lib/libgcc_s.1.dylib instead of the desired
/sw/lib/gcc4.3/lib/x86_64/libgcc_s.1.dylib.


-- 


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

[Bug c++/34488] [4.3 regression] ICE on invalid friend declaration

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2007-12-16 21:30 ---
I guess this is caused by r123312.


-- 


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

[Bug c++/33943] [4.3 Regression] ICE with partial specialization on vararg template template parameter

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2007-12-16 21:27 ---
(In reply to comment #5)
> I disagree with Andrew's Comment #4.  Once we implement a feature in the
> compiler, users should reasonably expect it to be correct.  We cannot
> simultaneously say "Look, we have exciting new C++0x features!" and "Oh, you
> found a bug?  That's not very serious, since it's just a new C++0x feature."

I seriously disagree, this is not a regression in that code never was supported
before and really C++0x support should not block the release just because
people feel this is an important feature of 4.3.0.  Also another thing is that
we have some ODR violations in libstdc++ that the libstdc++ folks have not
replied to me about yet.

See http://gcc.gnu.org/ml/libstdc++/2007-08/msg00032.html and some others.


-- 


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

[Bug target/34497] failures on i686-apple-darwin9 in sse4 testcases

[howarth at nitro dot med dot uc dot edu]

--- Comment #5 from howarth at nitro dot med dot uc dot edu  2007-12-16 
21:27 ---
Filed as Radar Problem ID: 5650346.


-- 


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

[Bug target/34501] The vector cost model does not seem suited for Intel Core2Duo

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
   Severity|normal  |enhancement
  Component|tree-optimization   |target


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

[Bug c++/33943] [4.3 Regression] ICE with partial specialization on vararg template template parameter

[mmitchel at gcc dot gnu dot org]

--- Comment #5 from mmitchel at gcc dot gnu dot org  2007-12-16 21:11 
---
I disagree with Andrew's Comment #4.  Once we implement a feature in the
compiler, users should reasonably expect it to be correct.  We cannot
simultaneously say "Look, we have exciting new C++0x features!" and "Oh, you
found a bug?  That's not very serious, since it's just a new C++0x feature."

Thus, I've upgraded this to P1.


-- 

mmitchel at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P2  |P1


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

[Bug fortran/34305] ICE with array(real) declaration

[tkoenig at gcc dot gnu dot org]

--- Comment #2 from tkoenig at gcc dot gnu dot org  2007-12-16 21:09 ---
Subject: Bug 34305

Author: tkoenig
Date: Sun Dec 16 21:09:34 2007
New Revision: 130993

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130993
Log:
2007-12-16  Thomas Koenig  <[EMAIL PROTECTED]>

PR fortran/34305
* resolve.c (compare_bound):  If either of the types of
the arguments isn't INTEGER, return CMP_UNKNOWN.

2007-12-16  Thomas Koenig  <[EMAIL PROTECTED]>

PR fortran/34305
* gfortran.dg/real_dimension_1.f:  New test case.


Added:
trunk/gcc/testsuite/gfortran.dg/real_dimension_1.f
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug tree-optimization/34501] New: The vector cost model does not seem suited for Intel Core2Duo

[dominiq at lps dot ens dot fr]

For the induct.f90 test case from the polyhedron test suite, I get the
following timings (revision 130990):

[ibook-dhum] lin/source% time gfc -O3 -ffast-math -funroll-loops induct.f90
11.226u 0.496s 0:12.42 94.2%0+0k 0+54io 15pf+0w
[ibook-dhum] lin/source% time a.out > tmp
91.148u 0.092s 1:31.27 99.9%0+0k 0+9io 12pf+0w
[ibook-dhum] lin/source% time gfc -O3 -ffast-math -funroll-loops --param
min-vect-loop-bound=1 induct.f90
11.205u 0.492s 0:11.84 98.7%0+0k 0+27io 0pf+0w
[ibook-dhum] lin/source% time a.out > tmp
91.145u 0.096s 1:31.24 99.9%0+0k 0+4io 0pf+0w
[ibook-dhum] lin/source% time gfc -O3 -ffast-math -funroll-loops --param
min-vect-loop-bound=2 induct.f90
11.101u 0.491s 0:11.78 98.3%0+0k 0+17io 0pf+0w
[ibook-dhum] lin/source% time a.out > tmp
73.596u 0.054s 1:13.65 99.9%0+0k 0+9io 0pf+0w

Am I correct to understand that for this revisions -O3 implies
vectorization+cost_model?
If yes, it seems that the cost model should be tuned for the Intel Core2Duo.


-- 
   Summary: The vector cost model does not seem suited for Intel
Core2Duo
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
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=34501

[Bug fortran/34246] gfortran.dg/bind_c_usage_16.f03 doesn't work

[burnus at gcc dot gnu dot org]

--- Comment #15 from burnus at gcc dot gnu dot org  2007-12-16 20:37 ---
FIXED on the trunk (4.3.0). Please open a new bug if there are new/remaining
problems.

The Bind(C) ENTRY part of this PR is now tracked as PR 34500.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug fortran/34500] New: Bind(C): Character returning function with ENTRY gives ICE

[burnus at gcc dot gnu dot org]

Test case:

function test() bind(C)
  use iso_c_binding
  implicit none
  character(len=1,kind=c_char) :: test, bar
entry bar() bind(C)
end function test

ICE occurs if either test() or bar() or both are bind(c).

The ENTRY fix needs to go into build_entry_thunks:
  if (thunk_sym->attr.function)
{
  if (gfc_return_by_reference (ns->proc_name))
{
This branch is entered as the master function,  proc_name, is is_bind_c ==
false, but it fails currently if (thunk_sym->attr.is_bind_c &&
thunk_sym->ts.type == BT_CHARACTER).

The proper tree should looks more or less as follows:

test2 ()
{
  character(kind=1) tmp[1:1];
  integer(kind=4) len;
  master.0.test2 (0, &tmp, len);
  return tmp[1];

That is test() itself returns a scalar character, but master.0.test2 takes the
string as argument, which allows to combine bind(C) with non-bind(C) functions
and allows for different string lengths of ENTRY and function (cf. PR 34421).


-- 
   Summary: Bind(C): Character returning function with ENTRY gives
ICE
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
OtherBugsDependingO 32630
 nThis:


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

[Bug rtl-optimization/32283] Missed induction variable optimization

[rakdver at gcc dot gnu dot org]

--- Comment #17 from rakdver at gcc dot gnu dot org  2007-12-16 20:29 
---
A possible way how to solve the problem:
http://gcc.gnu.org/ml/gcc-patches/2007-12/msg00769.html


-- 


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

[Bug fortran/34246] gfortran.dg/bind_c_usage_16.f03 doesn't work

[burnus at gcc dot gnu dot org]

--- Comment #14 from burnus at gcc dot gnu dot org  2007-12-16 20:24 ---
Subject: Bug 34246

Author: burnus
Date: Sun Dec 16 20:24:32 2007
New Revision: 130991

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130991
Log:
2007-12-16  Tobias Burnus  <[EMAIL PROTECTED]>

PR fortran/34246
* trans-types.c (gfc_init_types): Change build_type_variant
to build_qualified_type.
(gfc_sym_type): Return gfc_character1_type_node for
character-returning bind(C) functions.
* trans-expr.c (gfc_conv_function_call): Do not set
se->string_length for character-returning bind(c) functions.
(gfc_trans_string_copy,gfc_trans_scalar_assign):
 Support also single characters.

2007-12-16  Tobias Burnus  <[EMAIL PROTECTED]>

PR fortran/34246
* gfortran.dg/bind_c_usage_16.f03: Extend test.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-expr.c
trunk/gcc/fortran/trans-types.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/bind_c_usage_16.f03


-- 


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

[Bug target/34497] failures on i686-apple-darwin9 in sse4 testcases

[howarth at nitro dot med dot uc dot edu]

--- Comment #4 from howarth at nitro dot med dot uc dot edu  2007-12-16 
20:24 ---
Created an attachment (id=14783)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14783&action=view)
assembly file from sse3_1-insertps-2.c testcase on i686-apple-darwin9


-- 


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

[Bug target/34497] failures on i686-apple-darwin9 in sse4 testcases

[howarth at nitro dot med dot uc dot edu]

--- Comment #3 from howarth at nitro dot med dot uc dot edu  2007-12-16 
20:23 ---
Created an attachment (id=14782)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14782&action=view)
preprocessed source file from sse3_1-insertps-2.c testcase on
i686-apple-darwin9


-- 


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

[Bug libstdc++/34498] FAIL: 22_locale/global_templates/standard_facet_hierarchies.cc execution test

[pcarlini at suse dot de]

--- Comment #3 from pcarlini at suse dot de  2007-12-16 20:22 ---
Already noticed here:

  http://gcc.gnu.org/ml/libstdc++/2007-12/msg00059.html

I'm adding Benjamin in CC.


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 CC||bkoz at redhat dot com
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-12-16 20:22:24
   date||


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

[Bug libstdc++/34498] FAIL: 22_locale/global_templates/standard_facet_hierarchies.cc execution test

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca  2007-12-16 
20:06 ---
Subject: Re:  FAIL: 22_locale/global_templates/standard_facet_hierarchies.cc
execution test

> Exactly the same for cris-elf.

There's probably a missing check for named locales.

Dave


-- 


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

[Bug testsuite/34499] New: FAIL: g++.dg/ext/visibility/namespace2.C (test for excess errors)

[danglin at gcc dot gnu dot org]

Executing on host: /mnt/gnu/gcc/objdir/gcc/testsuite/g++/../../g++
-B/mnt/gnu/gc
c/objdir/gcc/testsuite/g++/../../
/mnt/gnu/gcc/gcc/gcc/testsuite/g++.dg/ext/visi
bility/namespace2.C  -nostdinc++
-I/mnt/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/lib
stdc++-v3/include/hppa2.0w-hp-hpux11.11
-I/mnt/gnu/gcc/objdir/hppa2.0w-hp-hpux11
.11/libstdc++-v3/include -I/mnt/gnu/gcc/gcc/libstdc++-v3/libsupc++
-I/mnt/gnu/gc
c/gcc/libstdc++-v3/include/backward
-I/mnt/gnu/gcc/gcc/libstdc++-v3/testsuite/ut
il -fmessage-length=0  -fvisibility=hidden  -S  -o namespace2.s(timeout =
30
0)
/mnt/gnu/gcc/gcc/gcc/testsuite/g++.dg/ext/visibility/namespace2.C: In member
fun
ction 'void Test::test()':
/mnt/gnu/gcc/gcc/gcc/testsuite/g++.dg/ext/visibility/namespace2.C:20: warning:
v
isibility attribute not supported in this configuration; ignored
output is:
/mnt/gnu/gcc/gcc/gcc/testsuite/g++.dg/ext/visibility/namespace2.C: In member
fun
ction 'void Test::test()':
/mnt/gnu/gcc/gcc/gcc/testsuite/g++.dg/ext/visibility/namespace2.C:20: warning:
v
isibility attribute not supported in this configuration; ignored

FAIL: g++.dg/ext/visibility/namespace2.C (test for excess errors)
Excess errors:
/mnt/gnu/gcc/gcc/gcc/testsuite/g++.dg/ext/visibility/namespace2.C:20: warning:
v
isibility attribute not supported in this configuration; ignored


-- 
   Summary: FAIL: g++.dg/ext/visibility/namespace2.C (test for
excess errors)
   Product: gcc
   Version: 4.2.3
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: hppa2.0w-hp-hpux11.11
  GCC host triplet: hppa2.0w-hp-hpux11.11
GCC target triplet: hppa2.0w-hp-hpux11.11


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

[Bug libstdc++/34498] FAIL: 22_locale/global_templates/standard_facet_hierarchies.cc execution test

[hp at gcc dot gnu dot org]

--- Comment #1 from hp at gcc dot gnu dot org  2007-12-16 19:45 ---
Exactly the same for cris-elf.


-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

 GCC target triplet|hppa2.0w-hp-hpux11.11   |hppa2.0w-hp-hpux11.11, cris-
   ||elf


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

[Bug fortran/21881] ICE instead of error for large arrays in derived types

[tkoenig at gcc dot gnu dot org]

--- Comment #6 from tkoenig at gcc dot gnu dot org  2007-12-16 19:38 ---
I'll do this.


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |tkoenig at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-10-01 10:52:19 |2007-12-16 19:38:41
   date||


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

[Bug libstdc++/34498] New: FAIL: 22_locale/global_templates/standard_facet_hierarchies.cc execution test

[danglin at gcc dot gnu dot org]

Executing on host: /mnt/gnu/gcc/objdir/./gcc/g++ -shared-libgcc
-B/mnt/gnu/gcc/o
bjdir/./gcc -nostdinc++
-L/mnt/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3
/src -L/mnt/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/src/.libs
-B/opt/g
nu/gcc/gcc-4.2.3/hppa2.0w-hp-hpux11.11/bin/
-B/opt/gnu/gcc/gcc-4.2.3/hppa2.0w-hp
-hpux11.11/lib/ -isystem /opt/gnu/gcc/gcc-4.2.3/hppa2.0w-hp-hpux11.11/include
-i
system /opt/gnu/gcc/gcc-4.2.3/hppa2.0w-hp-hpux11.11/sys-include -g -O2
-D_GLIBCX
X_ASSERT -fmessage-length=0 -g -O2 -DLOCALEDIR="." -nostdinc++
-I/mnt/gnu/gcc/ob
jdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/hppa2.0w-hp-hpux11.11
-I/mnt/gnu
/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include
-I/mnt/gnu/gcc/gcc/libstd
c++-v3/libsupc++ -I/mnt/gnu/gcc/gcc/libstdc++-v3/include/backward
-I/mnt/gnu/gcc
/gcc/libstdc++-v3/testsuite/util
/mnt/gnu/gcc/gcc/libstdc++-v3/testsuite/22_loca
le/global_templates/standard_facet_hierarchies.cc-include bits/stdc++.h
./li
btestc++.a  -lm   -o ./standard_facet_hierarchies.exe(timeout = 600)
PASS: 22_locale/global_templates/standard_facet_hierarchies.cc (test for excess
errors)
Setting LD_LIBRARY_PATH to
:/mnt/gnu/gcc/objdir/gcc:/mnt/gnu/gcc/objdir/hppa2.0w
-hp-hpux11.11/./libstdc++-v3/src/.libs::/mnt/gnu/gcc/objdir/gcc:/mnt/gnu/gcc/obj
dir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/src/.libs
terminate called after throwing an instance of 'std::runtime_error'
  what():  locale::facet::_S_create_c_locale name not valid
FAIL: 22_locale/global_templates/standard_facet_hierarchies.cc execution test


-- 
   Summary: FAIL:
22_locale/global_templates/standard_facet_hierarchies.cc
execution test
   Product: gcc
   Version: 4.2.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
 GCC build triplet: hppa2.0w-hp-hpux11.11
  GCC host triplet: hppa2.0w-hp-hpux11.11
GCC target triplet: hppa2.0w-hp-hpux11.11


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

[Bug ada/15605] invalid program not detected, RM 8.3(22), 8.5.4(6)

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
   Target Milestone|4.0.0   |---


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

[Bug tree-optimization/31081] [4.3 Regression] Inliner messes up SSA for abnormals

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |blocker


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

Fix PR 34305 - ICE on invalid real array bound

[Thomas Koenig]

Hello world,

this straightforward patch removes an unneeded ICE when
we already had emitted a perfectly valid error message.

OK for trunk?

Thomas

2007-12-16  Thomas Koenig  <[EMAIL PROTECTED]>

PR fortran/34305
* resolve.c (compare_bound):  If either of the types of
the arguments isn't INTEGER, return CMP_UNKNOWN.

2007-12-16  Thomas Koenig  <[EMAIL PROTECTED]>

PR fortran/34305
* gfortran.dg/real_dimension_1.f:  New test case.
Index: resolve.c
===
--- resolve.c	(revision 130913)
+++ resolve.c	(working copy)
@@ -3147,8 +3147,11 @@ compare_bound (gfc_expr *a, gfc_expr *b)
   || b == NULL || b->expr_type != EXPR_CONSTANT)
 return CMP_UNKNOWN;
 
+  /* If either of the types isn't INTEGER, we must have
+ raised an error earlier.  */
+
   if (a->ts.type != BT_INTEGER || b->ts.type != BT_INTEGER)
-gfc_internal_error ("compare_bound(): Bad expression");
+return CMP_UNKNOWN;
 
   i = mpz_cmp (a->value.integer, b->value.integer);
 
! { dg-do compile }
! PR 34305 - make sure there's an error message for specifying a
  program test
  parameter (datasize = 1000) 
  dimension idata (datasize)  ! { dg-error "must be of INTEGER type|must have constant shape" }
  idata (1) = -1
  end

[Bug target/34497] failures on i686-apple-darwin9 in sse4 testcases

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2007-12-16 19:23 ---
This might be a bug in Apple's assembler.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|c   |target


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

[Bug tree-optimization/31081] [4.3 Regression] Inliner messes up SSA for abnormals

[ebotcazou at gcc dot gnu dot org]

--- Comment #11 from ebotcazou at gcc dot gnu dot org  2007-12-16 18:12 
---
Ada testcase at http://gcc.gnu.org/ml/gcc/2007-12/msg00470.html


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu dot
   ||org


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

[Bug middle-end/34130] [4.1/4.2 Regression] the builtin abs() gives wrong result when used in some expression

[belyshev at depni dot sinp dot msu dot ru]

--- Comment #7 from belyshev at depni dot sinp dot msu dot ru  2007-12-16 
18:08 ---
Fixed on active branches.


-- 

belyshev at depni dot sinp dot msu dot ru changed:

   What|Removed |Added

 CC||belyshev at depni dot sinp
   ||dot msu dot ru
 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug c/34497] failures on i686-apple-darwin9 in sse4 testcases

[howarth at nitro dot med dot uc dot edu]

--- Comment #1 from howarth at nitro dot med dot uc dot edu  2007-12-16 
17:19 ---
These same make check failures occur at both -m32 and -m64..


-- 


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

[Bug c/34497] New: failures on i686-apple-darwin9 in sse4 testcases

[howarth at nitro dot med dot uc dot edu]

On i686-apple-darwin9, we are seeing failures in the following sse4 related
test cases...

FAIL: gcc.target/i386/sse4_1-blendvpd.c (test for excess errors)
WARNING: gcc.target/i386/sse4_1-blendvpd.c compilation failed to produce
executable
FAIL: gcc.target/i386/sse4_1-blendvps.c (test for excess errors)
WARNING: gcc.target/i386/sse4_1-blendvps.c compilation failed to produce
executable
FAIL: gcc.target/i386/sse4_1-insertps-1.c (test for excess errors)
WARNING: gcc.target/i386/sse4_1-insertps-1.c compilation failed to produce
executable
FAIL: gcc.target/i386/sse4_1-insertps-2.c (test for excess errors)
WARNING: gcc.target/i386/sse4_1-insertps-2.c compilation failed to produce
executable
FAIL: gcc.target/i386/sse4_1-pblendvb.c (test for excess errors)
WARNING: gcc.target/i386/sse4_1-pblendvb.c compilation failed to produce
executable
FAIL: gcc.target/i386/sse4_2-popcntl.c (test for excess errors)
WARNING: gcc.target/i386/sse4_2-popcntl.c compilation failed to produce
executable
FAIL: gcc.target/i386/sse4_2-popcntq.c (test for excess errors)
WARNING: gcc.target/i386/sse4_2-popcntq.c compilation failed to produce
executable

The actual failures in gcc.log look like...

Executing on host:
/sw/src/fink.build/gcc43-4.2.999-20071214/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc43-4.2.999-20071214/darwin_obj
dir/gcc/
/sw/src/fink.build/gcc43-4.2.999-20071214/gcc-4.3-20071214/gcc/testsuite/gcc.target/i386/sse4_1-insertps-2.c
  -O2 -msse4.1 -fno-
show-column  -lm   -m32 -o ./sse4_1-insertps-2.exe(timeout = 300)
:161:suffix or operands invalid for `insertps'
:164:suffix or operands invalid for `insertps'
:167:suffix or operands invalid for `insertps'
:168:suffix or operands invalid for `insertps'
compiler exited with status 1
output is:
:161:suffix or operands invalid for `insertps'
:164:suffix or operands invalid for `insertps'
:167:suffix or operands invalid for `insertps'
:168:suffix or operands invalid for `insertps'

FAIL: gcc.target/i386/sse4_1-insertps-2.c (test for excess errors)
Excess errors:
:161:suffix or operands invalid for `insertps'
:164:suffix or operands invalid for `insertps'
:167:suffix or operands invalid for `insertps'
:168:suffix or operands invalid for `insertps'

WARNING: gcc.target/i386/sse4_1-insertps-2.c compilation failed to produce
executable


-- 
   Summary: failures on i686-apple-darwin9 in sse4 testcases
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: howarth at nitro dot med dot uc dot edu
 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=34497

[Bug bootstrap/34494] -V option should be compatible with -B at least, possible others as well

[schwab at suse dot de]

--- Comment #4 from schwab at suse dot de  2007-12-16 17:02 ---
This has nothing to do with the topic of this bug.


-- 

schwab at suse dot de changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug middle-end/26061] error and warning count

[ismail at pardus dot org dot tr]

--- Comment #19 from ismail at pardus dot org dot tr  2007-12-16 16:55 
---
Hi,

(In reply to comment #18)
> * My original patch modified several testsuite files:
> http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01190.html, I guess you would 
> need
> something equivalent.

I added a flag to disable this to testsuite files (-fno-show-error-count)

> * Joseph pointed that: 
> "A human readable message can't just be passed to fprintf like that, you 
> need to arrange for it to be extracted for translation and translated into 
> the user's language.  Calling existing diagnostic functions does that, 
> otherwise the string needs surrounding with _()."

True, I'll fix.

> * Also he suggested:
> "this change to output should perhaps be off by 
> default, with a new option to enable it people wanting this style can put 
> in their Makefiles."

I really don't want to make it default off as it's really useful. I hope to fix
the patch and make it default on for gcc 4.4 at least.

Thanks for the suggestions,
ismail


-- 


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

[Bug middle-end/26061] error and warning count

[manu at gcc dot gnu dot org]

--- Comment #18 from manu at gcc dot gnu dot org  2007-12-16 16:51 ---
Ismail,

I am pretty sure that this won't be accepted for GCC 4.3, since it is not a
regression fix. Actually, I am unsure it would be accepted at all following the
comments to my original patch.

Nevertheless, if you want to take the risk of wasting your time, some advice:

* My original patch modified several testsuite files:
http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01190.html, I guess you would need
something equivalent.

* Joseph pointed that: 
"A human readable message can't just be passed to fprintf like that, you 
need to arrange for it to be extracted for translation and translated into 
the user's language.  Calling existing diagnostic functions does that, 
otherwise the string needs surrounding with _()."

* Also he suggested:
"this change to output should perhaps be off by 
default, with a new option to enable it people wanting this style can put 
in their Makefiles."

Good luck!


-- 


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

[Bug target/34473] casting negative __int128_t to float/double rounds to nearest multiple of 2048

[joseph at codesourcery dot com]

--- Comment #4 from joseph at codesourcery dot com  2007-12-16 16:44 ---
Subject: Re:  casting negative __int128_t to float/double
 rounds to nearest multiple of 2048

On Sun, 16 Dec 2007, ubizjak at gmail dot com wrote:

> This works OK for 4.3.0, beacuse 4.3 branch implements 128bit TFmode floating
> point mode and _floatdi{s,d}f function is changed to use this mode.

I think the fix was actually

2005-12-15  Joseph S. Myers  <[EMAIL PROTECTED]>

PR other/25028
* libgcc2.h (SF_SIZE, DF_SIZE, XF_SIZE, TF_SIZE): Define.
* libgcc2.c (__floatdixf, __floatundixf, __floatditf,
__floatunditf): Use #error if type sizes don't match requirements
of implementation.
(__floatdisf, __floatdidf): Unify.  Possibly use XFmode or TFmode
as wider floating-point type.  Use #error if type sizes don't
match requirements of implementation.  Avoid overflow in computing
Wtype_MAXp1_F * Wtype_MAXp1_F.  When special casing conversion,
shift one more bit.  Cast 1 to DWtype or UDWtype for shifting.
(__floatundisf, __floatundidf): Likewise.
* config/ia64/hpux.h (XF_SIZE, TF_SIZE): Define.
* config/ia64/ia64.c (ia64_init_libfuncs): Use
_U_Qfcnvfxt_quad_to_quad and _U_Qfcnvxf_quad_to_quad for
TFmode-TImode conversions.
* doc/tm.texi (SF_SIZE, DF_SIZE, XF_SIZE, TF_SIZE): Document.

(which is in 4.2) and that this is a duplicate of that bug.  If software 
TFmode is being used internally in conversions for narrower modes, that's 
a bug caused by x86_64 not defining WIDEST_HARDWARE_FP_SIZE.


-- 


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

[Bug middle-end/26061] error and warning count

[ismail at pardus dot org dot tr]

--- Comment #17 from ismail at pardus dot org dot tr  2007-12-16 16:14 
---
Created an attachment (id=14781)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14781&action=view)
Fix typo in the last patch


-- 

ismail at pardus dot org dot tr changed:

   What|Removed |Added

  Attachment #14780|0   |1
is obsolete||


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

[Bug middle-end/26061] error and warning count

[ismail at pardus dot org dot tr]

--- Comment #16 from ismail at pardus dot org dot tr  2007-12-16 16:12 
---
Created an attachment (id=14780)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14780&action=view)
Unbreak lib{gomp,stdc++,ffi} tests


-- 

ismail at pardus dot org dot tr changed:

   What|Removed |Added

  Attachment #14769|0   |1
is obsolete||


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

[Bug target/34473] casting negative __int128_t to float/double rounds to nearest multiple of 2048

[ubizjak at gmail dot com]

--- Comment #3 from ubizjak at gmail dot com  2007-12-16 16:02 ---
>From libgcc2.c, __floatdisf():

  /* Protect against double-rounding error.
 Represent any low-order bits, that might be truncated by a bit that
 won't be lost.  The bit can go in anywhere below the rounding position
 of the SFmode.  A fixed mask and bit position handles all usual
 configurations.  It doesn't handle the case of 128-bit DImode, however. 
*/

Please note that "di" in fact represents TImode for 64bit x86_64. I guess that
__floatdidf() also can't handle 128bit DImode values properly.

This works OK for 4.3.0, beacuse 4.3 branch implements 128bit TFmode floating
point mode and _floatdi{s,d}f function is changed to use this mode.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to work||4.3.0
 Resolution||WONTFIX


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

[Bug middle-end/34226] [4.3 Regression][frv] ICE in default_secondary_reload, at targhooks.c:612

[rask at gcc dot gnu dot org]

--- Comment #10 from rask at gcc dot gnu dot org  2007-12-16 15:18 ---
> That is not a regression   Just an already existing failure.
OK, looks like an intermittent failure which happens about one out of four
times.


-- 


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

[Bug fortran/34495] [4.3 Regression] accepts invalid initialization expressions with -std=f95

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2007-12-16 15:14 ---
Created an attachment (id=14779)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14779&action=view)
Patch - only for the REAL()/CMPLX() diagnostics


-- 


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

[Bug fortran/34495] [4.3 Regression] accepts invalid initialization expressions with -std=f95

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2007-12-16 14:35 ---
Confirm. Though other compilers have better error messages than 4.2 had. (These
are all shown by default, i.e. none of the compilers below accepts it.)

NAG f95:
  Error: PARAMETER PI used before its definition is complete
g95:
  Error: PARAMETER value is used before being defined at (1)
ifort:
  Error: A PARAMETER must not be defined in terms of itself.   [PI]
(sunf95 and openf95 have also not a good message.)

I think for -std=f95 one needs another error. NAG f95 prints:
  Error: The REAL function is not permitted in an initialisation expression

I am also not sure whether I would call the following a regression:
> Error: TRANSFER intrinsic not implemented for initialization at (1)


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-12-16 14:35:24
   date||


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

[Bug ada/15605] invalid program not detected, RM 8.3(22)

[ludovic at ludovic-brenta dot org]

--- Comment #4 from ludovic at ludovic-brenta dot org  2007-12-16 14:04 
---
As of 4.2.2, only the first of the two errors is detected.  Reopening.  The
second error violates 8.5.4(6): "A name that denotes a formal parameter of the
subprogram_specification is not allowed within the callable_entity_name." and
is not diagnosed.

GCC 4.1.2:

gnatmake -gnat05 pak1
gcc-4.1 -c -gnat05 pak1.ads
pak1.ads:8:15: formal parameter "list" cannot be used before end of
specification

GCC 4.2.2:

gnatmake -gnat05 pak1
gcc-4.2 -c -gnat05 pak1.ads
pak1.ads:8:15: formal parameter "list" cannot be used before end of
specification


-- 

ludovic at ludovic-brenta dot org changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


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

[Bug bootstrap/34494] -V option should be compatible with -B at least, possible others as well

[mmokrejs at ribosome dot natur dot cuni dot cz]

--- Comment #3 from mmokrejs at ribosome dot natur dot cuni dot cz  
2007-12-16 14:00 ---
??? But how is the bootstrap supposed to continue? Or was it caused by another
error which I have overlooked? I am sorry then. :(


-- 

mmokrejs at ribosome dot natur dot cuni dot cz changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug ada/34496] New: [4.2 regression] prefixed notation allows changing the value of a constant

[ludovic at ludovic-brenta dot org]

with text_io;
procedure test1 is
   package pak3 is

  type T1 is tagged record
 x0: integer;
  end record;

  procedure p1 (x1: access T1; val: integer);

  x2: aliased constant T1 := (x0 => 3);
  x3: access constant T1 := x2'access;

   end pak3;

   package body pak3 is
  procedure p1 (x1: access T1; val: integer) is
  begin
 x1.x0 := val;
  end p1;
   end pak3;

begin
   text_io.put_line(integer'image(pak3.x2.x0));
   pak3.x2.p1(5); -- line 25
   text_io.put_line(integer'image(pak3.x2.x0));
   pak3.x3.all.p1(7); -- line 27
-- pak3.x3.p1(7);   -- this one is detected
   text_io.put_line(integer'image(pak3.x2.x0));
end test1;

GCC 4.1.2:

$ gnatmake -gnat05 test1
gcc-4.1 -c -gnat05 test1.adb
test1.adb:25:08: expected an access type with designated type "T1" defined at
line 5
test1.adb:25:08: found type "T1" defined at line 5
test1.adb:27:12: expected an access type with designated type "T1" defined at
line 5
test1.adb:27:12: found type "T1" defined at line 5

The error messages are not very good (they should say something like "found
type "constant T1"") but the program is indeed illegal.

GCC 4.2.2:

$ gnatmake -gnat05 test1
gcc-4.2 -c -gnat05 test1.adb
gnatbind -x test1.ali
gnatlink test1.ali
$ ./test1
 3
 5
 7


-- 
   Summary: [4.2 regression] prefixed notation allows changing the
value of a constant
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ludovic at ludovic-brenta dot org


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

[Bug middle-end/34400] [4.3 regression] bad interaction between DF and SJLJ exceptions

[zadeck at naturalbridge dot com]

--- Comment #29 from zadeck at naturalbridge dot com  2007-12-16 13:56 
---
Subject: Re:  [4.3 regression] bad interaction between
 DF and SJLJ exceptions

steven at gcc dot gnu dot org wrote:
> --- Comment #28 from steven at gcc dot gnu dot org  2007-12-16 12:01 
> ---
> Created an attachment (id=14778)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14778&action=view)
>  --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14778&action=view)
> Change worklist solver to double queue algorithm
>
> I re-read Cooper, Harvey and Kennedy, who wrote a nice paper about various 
> work
> list based dataflow solvers.
>
> The attached patch modifies df_worklist_dataflow to a double queue algorithm,
> while retaining the property that basic blocks are added to the queue in RPO
> order.  This approach gives me a speedup comparable to (but slightly less 
> than)
> the hybrid search algorithm.  This is not really surprising because the double
> queue work list algorithm also completes full iterations over the CFG before
> considering the second queue.
>
> Seongbae, what are your ideas about the double queue approach (or maybe other
> algorithms suggested by Harvey)?
>
>
>   
The bottom line here is that all of these are heuristics.  There are no
tight time bounds here.  Each of these will have good cases and each
will have bad case.  So the only way that anyone can talk about best is
in term of the set of graphs they used to measure output.

Seongbae chose a technique that tends to work very well if the programs
are "normal" and the expense that fully connected programs are quite
bad.  The class of techniques that were used in hybrid search and that
you are looking at tend to do better for bad graphs but will be a little
slower on the "normal" cases.

If you can come up with some fast heuristic test to distinguish the
difference cases you can select between them.  Of course you only have
to do the tests once per function because the chances that optimization
will change the heuristic are vanishingly small.  This gives you a
little more room in terms of implementation cost. 

I think that I would vote for the "any bad back edges" plan to
distinguish the two because i think that Seonbae's technique was
designed to work well on that class of graphs.  But Seonbae may have
other thoughts especially if his technique requires only shallow maximum
nesting to really shine. 

Kenny


-- 


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

[Bug middle-end/34226] [4.3 Regression][frv] ICE in default_secondary_reload, at targhooks.c:612

[rask at gcc dot gnu dot org]

--- Comment #9 from rask at gcc dot gnu dot org  2007-12-16 13:39 ---
> That is not a regression   Just an already existing failure.

Unmodified trunk revision 130944 doesn't have it:
diff -u build/arm-unknown-elf-results-unpatched/summary
build/arm-unknown-elf-results-patched/summary
--- build/arm-unknown-elf-results-unpatched/summary 2007-12-15
02:26:10.0 +0100
+++ build/arm-unknown-elf-results-patched/summary   2007-12-16
04:17:59.0 +0100
@@ -17,6 +17,9 @@
 FAIL: gcc.dg/memcpy-1.c scan-tree-dump-times optimized "nasty_local" 0
 FAIL: gcc.dg/pr30957-1.c scan-rtl-dump loop2_unroll "Expanding Accumulator"
 FAIL: gcc.dg/var-expand1.c scan-rtl-dump loop2_unroll "Expanding Accumulator"
+FAIL: gcc.dg/struct/wo_prof_malloc_size_var.c (internal compiler error)
+FAIL: gcc.dg/struct/wo_prof_malloc_size_var.c (test for excess errors)
+UNRESOLVED: gcc.dg/struct/wo_prof_malloc_size_var.c compilation failed to
produce executable
 FAIL: gcc.dg/struct/wo_prof_single_str_global.c execution test
 FAIL: gcc.dg/struct/wo_prof_single_str_local.c execution test
 FAIL: gcc.dg/struct/wo_prof_single_str_pointer.c execution test


-- 


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

[Bug target/34025] Warning when compiling with -m64 -ffast-math on Intel Darwin

[dominiq at lps dot ens dot fr]

--- Comment #16 from dominiq at lps dot ens dot fr  2007-12-16 13:38 ---
The patch in comment #14 fix the problem for me. Thanks Jack for the debugging
and the patch.


-- 


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

[Bug fortran/34495] New: [4.3 Regression] accepts invalid initialization expressions with -std=f95

[tkoenig at gcc dot gnu dot org]

Adapted from a test case from c.l.f, from James van Buskirk
:
$ cat foo.f90 
program main
   integer, parameter :: ipi = 1078530011
   real pi
   parameter(pi=transfer(ipi,pi))
   real, parameter :: z = transfer(ipi,z)
   real, parameter :: y = real(1,kind(y))

   write(*,*) pi, z, y
end
$ gfortran -std=f95 -pedantic foo.f90 
$ ./a.out
   3.1415927   3.1415927  1. 

JvB's explanation:

# the second
# and third treat transfer as a specification inquiry even thought
# that is not permitted even in f03, and the fourth has that pesky
# REAL intrinsic, which is not an elemental function of type integer
# or character.

gfortran 4.2 still generates some error messages:

$ gfortran-4.2 foo.f90 
foo.f90:4.29:

   parameter(pi=transfer(ipi,pi))
1
Error: Parameter 'pi' at (1) has not been declared or is a variable, which does
not reduce to a constant expression
foo.f90:5.35:

   real, parameter :: z = transfer(ipi,z)
  1
Error: TRANSFER intrinsic not implemented for initialization at (1)


-- 
   Summary: [4.3 Regression] accepts invalid initialization
expressions with -std=f95
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: accepts-invalid, diagnostic
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot org


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

[Bug bootstrap/34494] -V option should be compatible with -B at least, possible others as well

[schwab at suse dot de]

--- Comment #2 from schwab at suse dot de  2007-12-16 13:31 ---
This test will always fail with gcc because -V requires an argument, but this
is ok because it's only there to provide some information about the compiler in
the log file, but is otherwise ignored.


-- 

schwab at suse dot de changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug tree-optimization/34445] [4.3 Regression] internal compiler error: in cost_for_stmt, at tree-vect-transform.c:98

[dorit at gcc dot gnu dot org]

--- Comment #4 from dorit at gcc dot gnu dot org  2007-12-16 13:06 ---
testing this patch: 

*** tree-vect-transform.c   (revision 130987)
--- tree-vect-transform.c   (working copy)
*** vect_estimate_min_profitable_iters (loop
*** 197,214 
factor = 1;

for (si = bsi_start (bb); !bsi_end_p (si); bsi_next (&si))
! {
!   tree stmt = bsi_stmt (si);
!   stmt_vec_info stmt_info = vinfo_for_stmt (stmt);
!   if (!STMT_VINFO_RELEVANT_P (stmt_info)
!   && !STMT_VINFO_LIVE_P (stmt_info))
! continue;
!   scalar_single_iter_cost += cost_for_stmt (stmt) * factor;
!   vec_inside_cost += STMT_VINFO_INSIDE_OF_LOOP_COST (stmt_info) *
factor;
  /* FIXME: for stmts in the inner-loop in outer-loop vectorization,
 some of the "outside" costs are generated inside the outer-loop. 
*/
!   vec_outside_cost += STMT_VINFO_OUTSIDE_OF_LOOP_COST (stmt_info);
! }
  }

/* Add additional cost for the peeled instructions in prologue and epilogue
--- 197,215 
factor = 1;

for (si = bsi_start (bb); !bsi_end_p (si); bsi_next (&si))
!   {
! tree stmt = bsi_stmt (si);
! stmt_vec_info stmt_info = vinfo_for_stmt (stmt);
! /* Skip stmts that are not vectorized inside the loop.  */
! if (!STMT_VINFO_RELEVANT_P (stmt_info)
! && STMT_VINFO_DEF_TYPE (stmt_info) != vect_reduction_def)
!   continue;
! scalar_single_iter_cost += cost_for_stmt (stmt) * factor;
! vec_inside_cost += STMT_VINFO_INSIDE_OF_LOOP_COST (stmt_info) *
factor;
  /* FIXME: for stmts in the inner-loop in outer-loop vectorization,
 some of the "outside" costs are generated inside the outer-loop. 
*/
! vec_outside_cost += STMT_VINFO_OUTSIDE_OF_LOOP_COST (stmt_info);
!   }
  }

/* Add additional cost for the peeled instructions in prologue and epilogue


(It fixes both testcases)


-- 


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

[Bug target/30192] [arm] Wrong sp value on exit after calling __floatdidf or __floatundidf

[John dot Tytgat at aaug dot net]

--- Comment #7 from John dot Tytgat at aaug dot net  2007-12-16 13:04 
---
Indeed fixed thanks.


-- 

John dot Tytgat at aaug dot net changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/34226] [4.3 Regression][frv] ICE in default_secondary_reload, at targhooks.c:612

[pinskia at gmail dot com]

--- Comment #8 from pinskia at gmail dot com  2007-12-16 13:00 ---
Subject: Re:  [4.3 Regression][frv] ICE in default_secondary_reload, at
targhooks.c:612

On 16 Dec 2007 12:55:21 -, rask at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
> The patch in comment #6 has one testsuite regression on arm-unknown-elf:
> FAIL: gcc.dg/struct/wo_prof_malloc_size_var.c (internal compiler error)
> FAIL: gcc.dg/struct/wo_prof_malloc_size_var.c (test for excess errors)

That is not a regression   Just an already existing failure.

-- Pinski


-- 


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

[Bug bootstrap/34474] find from BusyBox v1.2.2 does not support logical OR (-o argument)

[pinskia at gcc dot gnu dot org]

--- Comment #13 from pinskia at gcc dot gnu dot org  2007-12-16 12:58 
---
Well it is we assume a lot of things are POSIX support so I don't see why we
have to document find here really.  Yes we document we need a POSIX shell but
that is because a semi common target (Solaris)'s /bin/sh is not POSIX
compatible.  It is not common to find a non POSIX compatible find (or one that
does not support the find options).

The main reason why I don't want to see two finds is because find is actually
can be expensive.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||WONTFIX


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

[Bug middle-end/34226] [4.3 Regression][frv] ICE in default_secondary_reload, at targhooks.c:612

[rask at gcc dot gnu dot org]

--- Comment #7 from rask at gcc dot gnu dot org  2007-12-16 12:55 ---
It's the dataflow merge (125624) that broke it. Revision 125623 with 130333 on
top is fine, but 125624 with 125851 (so it builds) and 130333 on top fails.
The patch in comment #6 has one testsuite regression on arm-unknown-elf:
FAIL: gcc.dg/struct/wo_prof_malloc_size_var.c (internal compiler error)
FAIL: gcc.dg/struct/wo_prof_malloc_size_var.c (test for excess errors)


-- 


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

[Bug middle-end/34400] [4.3 regression] bad interaction between DF and SJLJ exceptions

[steven at gcc dot gnu dot org]

--- Comment #28 from steven at gcc dot gnu dot org  2007-12-16 12:01 ---
Created an attachment (id=14778)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14778&action=view)
Change worklist solver to double queue algorithm

I re-read Cooper, Harvey and Kennedy, who wrote a nice paper about various work
list based dataflow solvers.

The attached patch modifies df_worklist_dataflow to a double queue algorithm,
while retaining the property that basic blocks are added to the queue in RPO
order.  This approach gives me a speedup comparable to (but slightly less than)
the hybrid search algorithm.  This is not really surprising because the double
queue work list algorithm also completes full iterations over the CFG before
considering the second queue.

Seongbae, what are your ideas about the double queue approach (or maybe other
algorithms suggested by Harvey)?


-- 


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

[Bug fortran/34396] Length of substrings defined by expressions not correctly computed in constructors

[pault at gcc dot gnu dot org]

--- Comment #7 from pault at gcc dot gnu dot org  2007-12-16 11:45 ---
OK then, I'll give it a try!

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|2007-12-09 06:20:24 |2007-12-16 11:45:31
   date||


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