[Bug c++/41292] Link error on Solaris 10 / GNU 3.4.2

[ebotcazou at gcc dot gnu dot org]

--- Comment #1 from ebotcazou at gcc dot gnu dot org  2009-09-07 07:00 
---
> We are migrating from solaris 8 to solaris 10. On Solaris 10 we are getting
> link error as mentioned in this bug #15267. Initially we were using ld 2.16.
> As the fix for the link error below is available with ld 2.18, we installed
> 2.18 on our solaris 10 box. But we are still getting the same error.

Your compiler is not configured to use GNU binutils:

/net/clpt-v490-1/export/data1/bldmstr/20090604_ceres_gcc432/src/configure
--prefix= --enable-shared --disable-static --with-system-zlib
--enable-checking=release --enable-languages=c,c++ --with-cpu=v9
--with-ld=/usr/ccs/bin/ld --without-gnu-ld --disable-gnattools --enable-tls
--with-as=/usr/ccs/bin/as --without-gnu-as

so you need to use the system as/ld instead or reconfigure and rebuild it.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug ada/41291] verify_ssa failed: Error detected around a-direct.adb:1178:4

[aoliva at gcc dot gnu dot org]

--- Comment #1 from aoliva at gcc dot gnu dot org  2009-09-07 07:03 ---
Hello, Christian,

I'm going to need an attachment with the files in gnatchop format as mentioned
in the bug report box to try to duplicate the problem with a cross compiler. 
Could you please attach it to this bug report, or send them to me by e-mail? 
Thanks in advance,


-- 


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

[Bug c/41150] segmentation fault after using __attribute__((optimize()))

[ictlpeng at gmail dot com]

--- Comment #2 from ictlpeng at gmail dot com  2009-09-07 07:08 ---
Created an attachment (id=18524)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18524&action=view)
The preprocessed file that triggers the bug 1


-- 


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

[Bug c/41150] segmentation fault after using __attribute__((optimize()))

[ictlpeng at gmail dot com]

--- Comment #3 from ictlpeng at gmail dot com  2009-09-07 07:09 ---
Created an attachment (id=18525)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18525&action=view)
preprocessed file that triggers the bug 2


-- 


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

[Bug c/41150] segmentation fault after using __attribute__((optimize()))

[ictlpeng at gmail dot com]

-- 

ictlpeng at gmail dot com changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED


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

[Bug fortran/41293] New: FGSL: Wrong code generated

[burnus at gcc dot gnu dot org]

This is with the Fortran bindings to the GNU Scientific Library,
http://www.lrz-muenchen.de/services/software/mathematik/gsl/fortran/

Compiling works OK, but the test suite shows a couple of failures with
gfortran:

Running montecarlo.exe:
 FAIL: fgsl_monte_monte_vegas_getparams
FAIL: 1 of 21 tests failed
 fgsl_monte_monte_vegas_getparams: aborting Execution
Running multimin.exe:
 FAIL: fgsl_multimin_fdfminimizer_iterate
FAIL: 1 of 12 tests failed
Running error test:
OK: All 6 tests passed
 FAIL: fgsl_interp_alloc:nofail
FAIL: 1 of 1 tests failed

The "multimin.exe" test might be a bug in the test suite as g95, ifort and
gfortran show the same error. (For g95 it is the only error, the ifort has
additionally for array.exe/poly.exe a segfault.)


-- 
   Summary: FGSL: Wrong code generated
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


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

[Bug ada/41291] verify_ssa failed: Error detected around a-direct.adb:1178:4

[ebotcazou at gcc dot gnu dot org]

--- Comment #2 from ebotcazou at gcc dot gnu dot org  2009-09-07 07:50 
---
> I'm going to need an attachment with the files in gnatchop format as mentioned
> in the bug report box to try to duplicate the problem with a cross compiler. 

You can very likely duplicate with a native --disable-bootstrap build on
i686-linux by changing the line

   ZCX_By_Default: constant Boolean := True;

to

   ZCX_By_Default: constant Boolean := False;

in ada/system-linux-x86.ads.


-- 

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

[Bug c++/41292] Link error on Solaris 10 / GNU 3.4.2

[ebotcazou at gcc dot gnu dot org]

--- Comment #3 from ebotcazou at gcc dot gnu dot org  2009-09-07 07:58 
---
> As suggested by you I then set my PATH precedence to /usr/ccs/bin
> even then I am getting the same error. 

Please verify with '-v' which 'as' is really used to assemble the problematic
files (ttimebase.o, intervalfixed.o and so on).

> We are using precompiled version of gcc 4.3.2. Is there a way where by we can
> change path for ld to bin utils? or reconfiguration and rebuild is the only
> option to set the path for ld?

This compiler was configured --without-gnu-as --without-gnu-ld so it cannot use
GNU binutils, only the system as/ld.


-- 


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

[Bug c++/41292] Link error on Solaris 10 / GNU 3.4.2

[vijay dot x dot jain at jpmchase dot com]

--- Comment #2 from vijay dot x dot jain at jpmchase dot com  2009-09-07 
07:34 ---
I have set my PATH such that path for ld preceds from binutils.
So my understanding was ld will be picked from binutils.

As suggested by you I then set my PATH precedence to /usr/ccs/bin
even then I am getting the same error. 

Could you please help me on this?
I have stuck on this error for a long time.
We are using precompiled version of gcc 4.3.2. Is there a way where by we can
change path for ld to bin utils? or reconfiguration and rebuild is the only
option to set the path for ld?


-- 

vijay dot x dot jain at jpmchase dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug fortran/29383] Fortran 2003/F95[TR15580:1999]: Floating point exception (IEEE) support

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2009-09-07 08:07 ---
Add links to some discussions to make sure it won't get lost:

http://gcc.gnu.org/ml/gcc/2008-11/msg00372.html

http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/1efc9e7a19651b81
The thread which is here and maybe also some other fort...@gcc emails by Tim
and Nick around this time:
http://gcc.gnu.org/ml/fortran/2009-08/msg00338.html


-- 


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

[Bug ada/41291] verify_ssa failed: Error detected around a-direct.adb:1178:4

[ebotcazou at gcc dot gnu dot org]

--- Comment #3 from ebotcazou at gcc dot gnu dot org  2009-09-07 08:47 
---
On i686-linux after the small change explained in comment #2.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-09-07 08:47:54
   date||


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

[Bug debug/41291] [4.5 regression] verify_ssa failed for debug insn

[ebotcazou at gcc dot gnu dot org]

-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|ada |debug
Summary|verify_ssa failed: Error|[4.5 regression] verify_ssa
   |detected around a-  |failed for debug insn
   |direct.adb:1178:4   |
   Target Milestone|--- |4.5.0


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

[Bug fortran/41222] [4.4 Regression] "-std=f95" forbids USEd functions named like f03/f08 intrisics

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P4


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

[Bug regression/41204] [4.4/4.5 regression] worse code generated compared to GCC 4.3.2

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P5


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

[Bug tree-optimization/41287] [4.4 Regression] -O1 optimisation of for loops in some cases omits essential functionality resulting in failed applications

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-09-07 09:45 ---
Works for me with g++-4.4 (Debian 4.4.1-3) 4.4.1.  But I can reproduce it with
the 4.4.1 release on both x86_64 and x86_64 with -m32.
4.4.0 seems to work, so does trunk and 4.4.2.

Thus, fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Component|c++ |tree-optimization
 GCC target triplet|i586-redhat-linux   |i?86-*-* x86_64-*-*
   Keywords||wrong-code
  Known to fail||4.4.1
  Known to work||4.3.3 4.4.0 4.4.2 4.5.0
   Priority|P3  |P1
 Resolution||FIXED
Summary|-O1 optimisation of for |[4.4 Regression] -O1
   |loops in some cases omits   |optimisation of for loops in
   |essential functionality |some cases omits essential
   |resulting in failed |functionality resulting in
   |applications|failed applications
   Target Milestone|--- |4.4.2


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

[Bug target/41288] [4.5 Regression] gcc.target/x86_64/abi/test_struct_returning.c regressions on *-apple-darwin* at -m64

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|c   |target
   Keywords||ABI, wrong-code
Summary|gcc.target/x86_64/abi/test_s|[4.5 Regression]
   |truct_returning.c   |gcc.target/x86_64/abi/test_s
   |regressions on *-apple- |truct_returning.c
   |darwin* at -m64 |regressions on *-apple-
   ||darwin* at -m64
   Target Milestone|--- |4.5.0


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

[Bug middle-end/41289] [4.5 Regression] ICE verify_ssa failed building libavformat/oggparseogm.c

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-09-07 09:47 ---
Likely a dup.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|c   |middle-end
Summary|ICE verify_ssa failed   |[4.5 Regression] ICE
   |building|verify_ssa failed building
   |libavformat/oggparseogm.c   |libavformat/oggparseogm.c
   Target Milestone|--- |4.5.0


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

[Bug middle-end/41290] [4.5 regression] C++ - libdirac don't want to compile

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-09-07 09:50 ---
Reducing.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu dot
   ||org
  Component|c++ |middle-end
   Target Milestone|--- |4.5.0


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

[Bug middle-end/41289] [4.5 Regression] ICE verify_ssa failed building libavformat/oggparseogm.c

[aoliva at gcc dot gnu dot org]

--- Comment #4 from aoliva at gcc dot gnu dot org  2009-09-07 09:55 ---
Please attach the .i (preprocessed) source file so that I can duplicate the
problem.  Thanks in advance,


-- 


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

[Bug tree-optimization/41101] [4.4/4.5 Regression] ICE in compute_antic, at tree-ssa-pre.c:2419

[rguenth at gcc dot gnu dot org]

--- Comment #22 from rguenth at gcc dot gnu dot org  2009-09-07 10:01 
---
Created an attachment (id=18526)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18526&action=view)
preprocessed libstdc++ testcase (32bit)

Testcase that fails at -O2 with the patch.  The 2nd patch bootstraps and tests
ok
on the 4.4 branch.


-- 


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

[Bug middle-end/41289] [4.5 Regression] ICE verify_ssa failed building libavformat/oggparseogm.c

[t66667 at gmail dot com]

--- Comment #5 from t7 at gmail dot com  2009-09-07 10:03 ---
(In reply to comment #4)
> Please attach the .i (preprocessed) source file so that I can duplicate the
> problem.  Thanks in advance,
> 

I'd like to do that, but, I can not find the .i file all I saw was the .s file.


-- 


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

[Bug middle-end/41289] [4.5 Regression] ICE verify_ssa failed building libavformat/oggparseogm.c

[t66667 at gmail dot com]

--- Comment #6 from t7 at gmail dot com  2009-09-07 10:05 ---
with -O0 (gcc didn't ICE) libavformat-oggparseogm-s.tar.bz2
with -O3 oggparseog.ICE.s


-- 


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

[Bug middle-end/41290] [4.5 regression] C++ - libdirac don't want to compile

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-09-07 10:14 ---
Created an attachment (id=18527)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18527&action=view)
reduced testcase

Fails at -O2.


-- 


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

[Bug middle-end/41290] [4.5 regression] C++ - libdirac don't want to compile

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
 GCC target triplet|m68k-amigaos|m68k-amigaos, i?86-*-*
   Last reconfirmed|-00-00 00:00:00 |2009-09-07 10:14:48
   date||


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

[Bug tree-optimization/40759] [4.5 Regression] segfault in useless_type_conversion_p

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2009-09-07 10:22 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/40762] [4.5 Regression] CD-DCE messes up virtual SSA form

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2009-09-07 10:24 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug debug/41272] FAIL: gcc.dg/debug/dwarf2/inline2.c scan-assembler-times \(DIE \(.*?\) DW_TAG_in lined_subroutine 6

[dodji at redhat dot com]

--- Comment #5 from dodji at gcc dot gnu dot org  2009-09-07 10:26 ---
Subject: Re:  FAIL: gcc.dg/debug/dwarf2/inline2.c scan-assembler-times
 \(DIE \(.*?\) DW_TAG_in lined_subroutine 6

Le 05/09/2009 12:05, rguenth at gcc dot gnu dot org a écrit :

> They are platform dependent in that non-register operations are accounted
> according to their move cost.  Thus if at all it is
> 
>   int* a = 0;
>   a[0] = var3;
> 
> that makes the difference.  You can either increase optimization level
> or the inlining parameters.

Thanks Richard.

So, would adding __attribute__((always_inline)) to those function be
acceptable ?


-- 


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

[Bug fortran/41293] FGSL: Wrong code generated

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2009-09-07 10:29 ---
With GCC 4.4 one has only the "montecarlo.exe" and "multimin.exe" error, but
not the "error.x" error.


-- 


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

[Bug inline-asm/41294] New: "=&rm" constraints give overlapping memory addresses

[jdemeyer at cage dot ugent dot be]

In some cases in inline asm, an output parameter with no-clobber "=&rm"
constraint gets the same address as an input parameter, even when they refer to
two different C variables.  This seems to happen when the following conditions
are satisfied:

* The variables involved appear only in inline asm (as the output of one asm
statement and the input of a second).
* The output constraint is "=&rm" ("=m" works correctly).
* There are too many clobbered variables forcing some of the output parameters
into memory.

The attached testcase works for i386, x86_64, powerpc and powerpc64.  For other
targets, change the clobber list to include as much registers as possible.
Compile with gcc -O1 -save-temps -c -o bug.o bug.c

Tested with gcc -v:
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure CC=/usr/bin/gcc-4.3.4
--prefix=/home/jdemeyer/local --enable-checking=release
Thread model: posix
gcc version 4.5.0 20090904 (experimental) (GCC)


-- 
   Summary: "=&rm" constraints give overlapping memory addresses
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jdemeyer at cage dot ugent dot be


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

[Bug inline-asm/41294] "=&rm" constraints give overlapping memory addresses

[jdemeyer at cage dot ugent dot be]

--- Comment #1 from jdemeyer at cage dot ugent dot be  2009-09-07 10:49 
---
Created an attachment (id=18528)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18528&action=view)
Testcase


-- 


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

[Bug middle-end/41282] [4.5 Regression] Revision 151394 failed to compile mplayer

[jamborm at gcc dot gnu dot org]

--- Comment #5 from jamborm at gcc dot gnu dot org  2009-09-07 10:53 ---
Mine.


-- 

jamborm at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jamborm at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
  Component|c   |middle-end
   Last reconfirmed|2009-09-05 22:40:45 |2009-09-07 10:53:57
   date||


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

[Bug fortran/41219] libgfortran build warnings

[sezeroz at gmail dot com]

--- Comment #10 from sezeroz at gmail dot com  2009-09-07 11:27 ---
(In reply to comment #6)
> (In reply to comment #2)
> > Janne, I think the warning about "unix.c:750:15: warning: 
> > �statbuf.st_mode� may
> > be used uninitialized" is spurious, but can you have a look?
> 
> Yes, it's spurious, and I submitted a patch
> (http://gcc.gnu.org/ml/gcc-patches/2009-09/msg00419.html), but maybe the
> middle-end shouldn't warn about it anyway (see the reply by Richard Guenther).

The warning must be due to the inline fstat() implementation in
mingw-w64. Excerpt from stat.h:

__CRT_INLINE int __cdecl
 fstat(int _Desc,struct stat *_Stat) {
  struct _stat64 st;
  int ret=_fstat64(_Desc,&st);
  if (ret == -1) {
memset(_Stat,0,sizeof(struct stat));
return -1;
  }
 /* rest of the code */

Note that the memset() in the failure case was only recently added in our svn,
at rev. 1306, so this warning shouldn't be experienced with mingw-w64 rev.1306
or later. Older revisions didn't touch the input buffer on failure which should
be the reason for the warning.


-- 

sezeroz at gmail dot com changed:

   What|Removed |Added

 CC||sezeroz at gmail dot com


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

[Bug target/41279] [4.5 Regression] 252.eon performance regression

[jamborm at gcc dot gnu dot org]

--- Comment #4 from jamborm at gcc dot gnu dot org  2009-09-07 12:05 ---
Hm, I wonder how come we did not come across this when testing the
patch for exactly these kinds of problems in July.  Anyway, I will
have a look at it.

Nevertheless, I believe we should split this bug in two so that we can
track the SRA and VTA regressions separately.  So unless someone
objects or I realize the fix is so trivial it does not really deserve
its own PR, I'll create a new Pr for the SRA issue when I come across
something interesting.


-- 

jamborm at gcc dot gnu dot org changed:

   What|Removed |Added

 CC|mjambor at suse dot cz  |jamborm at gcc dot gnu dot
   ||org


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

[Bug c++/13795] ternary operator fails to compile with static const class members

[abotezatu at gmail dot com]

--- Comment #6 from abotezatu at gmail dot com  2009-09-07 12:13 ---
The real question is, should the ternary operator require reference to a static
const member, when it should know that this is a constant that does not require
storage, and thus reference to such a constant can be omitted? 

It could be that the behaviour is not defined in the standard, but, perhaps, it
is sensible to expect that the ternary operator behave as closely possible to a
series of if statements, when it does not specifically require otherwise?

I see 3.x working differently from 4.x. in this regard. Why is that so?


-- 

abotezatu at gmail dot com changed:

   What|Removed |Added

 CC||abotezatu at gmail dot com


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

[Bug fortran/41242] [4.5 Regression] procedure pointer rejected (related to user-defined assignment?)

[pault at gcc dot gnu dot org]

--- Comment #4 from pault at gcc dot gnu dot org  2009-09-07 12:51 ---
(In reply to comment #3)
Note what happens if the critical part is doubled up, thus:

  subroutine no_func_config (prc_lib)
type(nf_t), intent(inout), target :: prc_lib
integer :: n_in
type(string_t) :: prc_id
prc_id = "foobar"
n_in  = prc_lib% get_n_in  (1)
prc_id = "foobar"
n_in  = prc_lib% get_n_in  (2)
  end subroutine no_func_config

Three errors now appear in the order (2), (1), (2)
If the first prc_id = "foobar" is commented out, we get just (2) or if the
second is commented out, we get (1), (2).

Wierd!  I think that this will require Daniel and Janus to go back over their
patches in the period concerned or to identify the specific revision.  I will
try to do that tonight.

Paul


-- 


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

[Bug rtl-optimization/41295] New: [4.5 Regression] gfortran.dg/loc_2.f90 -O3 -g fails on SH with orphaned debug_insn

[kkojima at gcc dot gnu dot org]

After vta merge, gfortran.dg/loc_2.f90 fails on sh4-unknown-linux-gnu
for -O3 -g with

loc_2.f90:114:0: internal compiler error: in reload_combine_note_use, at
postreload.c:1097

which is the result of

postreload.c:
1097gcc_assert (regno < FIRST_PSEUDO_REGISTER);

The problematic regno 1434 came from a debug insn

(debug_insn 1346 1344 1350 3 loc_2.f90:46 (var_location:SI offset (reg:SI 1434
[ ivtmp.132 ])) -1 (nil))

which looks orphaned at postreload pass.  There are no other insns
referring to reg 1434 at that pass.


-- 
   Summary: [4.5 Regression] gfortran.dg/loc_2.f90 -O3 -g fails on
SH with orphaned debug_insn
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kkojima at gcc dot gnu dot org
GCC target triplet: sh4-unknown-linux-gnu


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

[Bug rtl-optimization/41295] [4.5 Regression] gfortran.dg/loc_2.f90 -O3 -g fails on SH with orphaned debug_insn

[kkojima at gcc dot gnu dot org]

-- 

kkojima at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P4


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

[Bug bootstrap/41245] [4.5 Regression] Bootstrap broken on I386-apple-darwin9 at revision 151373

[gerald at pfeifer dot com]

--- Comment #4 from gerald at pfeifer dot com  2009-09-07 13:10 ---
Confirming fix on i386-unknown-freebsd7.2 which had the same failure
mode.  Others will have to confirm i386-apple-darwin9, but I figured
that might be useful first confirmation.


-- 


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

[Bug bootstrap/41296] New: bootstrap fails with --with-dwarf2 trunk at 151455

[developer at sandoe-acoustics dot co dot uk]

with patch:
 http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01069.html
(which is approved, but not yet in the trunk).

dwarf2 is needed to link m64 on darwin8 ppc (ld64 barfs on stabs).

Also with the attached patch to enable compare-debug to work with dwarf on
darwin.

bootstrap fails with:

rm -f stage_current
Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1obj-checksum.o differs
warning: gcc/cc1objplus-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
Bootstrap comparison failure!
gcc/alias.o differs
gcc/alloc-pool.o differs
gcc/attribs.o differs
gcc/auto-inc-dec.o differs
gcc/bb-reorder.o differs
gcc/bitmap.o differs
gcc/bt-load.o differs
gcc/build/errors.o differs
gcc/build/gcov-iov.o differs
gcc/build/genattr.o differs
gcc/build/genattrtab.o differs
gcc/build/genautomata.o differs
gcc/build/gencheck.o differs
gcc/build/genchecksum.o differs
gcc/build/gencodes.o differs
gcc/build/genconditions.o differs
gcc/build/gencondmd.o differs
gcc/build/genconfig.o differs
gcc/build/genconstants.o differs
gcc/build/genemit.o differs
gcc/build/genextract.o differs
gcc/build/genflags.o differs
etc.

===

Looking at the stripped version of alias.o 
using otool -l xxx.o.stripped > xxx.ls

$  diff -u s2alias-ls.txt s3alias-ls.txt 
--- s2alias-ls.txt  2009-09-07 13:50:54.0 +0100
+++ s3alias-ls.txt  2009-09-07 13:51:06.0 +0100
@@ -1,11 +1,11 @@
-stage2-gcc/alias.o.stripped:
+stage3-gcc/alias.o.stripped:
 Load command 0
   cmd LC_SEGMENT
   cmdsize 668
   segname 
vmaddr 0x
vmsize 0x713e
-  fileoff 976
+  fileoff 1000
  filesize 28496
   maxprot 0x0007
  initprot 0x0007
@@ -16,9 +16,9 @@
segname __TEXT
   addr 0x
   size 0x662c
-offset 976
+offset 1000
  align 2^2 (4)
-reloff 29472
+reloff 29496
 nreloc 2489
  flags 0x8400
  reserved1 0
@@ -28,7 +28,7 @@
segname __TEXT
   addr 0x662c
   size 0x00ec
-offset 27132
+offset 27156
  align 2^2 (4)
 reloff 0
 nreloc 0
@@ -40,7 +40,7 @@
segname __TEXT
   addr 0x6718
   size 0x0214
-offset 27368
+offset 27392
  align 2^2 (4)
 reloff 0
 nreloc 0
@@ -52,9 +52,9 @@
segname __TEXT
   addr 0x6930
   size 0x03d0
-offset 27904
+offset 27928
  align 2^4 (16)
-reloff 49384
+reloff 49408
 nreloc 244
  flags 0x8408
  reserved1 0 (index into indirect symbol table)
@@ -64,9 +64,9 @@
segname __DATA
   addr 0x6d00
   size 0x00dc
-offset 28880
+offset 28904
  align 2^2 (4)
-reloff 51336
+reloff 51360
 nreloc 16
  flags 0x
  reserved1 0
@@ -76,7 +76,7 @@
segname __DATA
   addr 0x6ddc
   size 0x0008
-offset 29100
+offset 29124
  align 2^2 (4)
 reloff 0
 nreloc 0
@@ -88,9 +88,9 @@
segname __DATA
   addr 0x6de4
   size 0x00f4
-offset 29108
+offset 29132
  align 2^2 (4)
-reloff 51464
+reloff 51488
 nreloc 61
  flags 0x0007
  reserved1 61 (index into indirect symbol table)
@@ -100,7 +100,7 @@
segname __DATA
   addr 0x6ed8
   size 0x0078
-offset 29352
+offset 29376
  align 2^2 (4)
 reloff 0
 nreloc 0
@@ -122,9 +122,9 @@
 Load command 1
  cmd LC_SYMTAB
  cmdsize 24
-  symoff 52560
+  symoff 52584
nsyms 131
-  stroff 54132
+  stroff 54156
  strsize 2540
 Load command 2
 cmd LC_DYSYMTAB
@@ -141,13 +141,18 @@
 nmodtab 0
extrefsymoff 0
 nextrefsyms 0
- indirectsymoff 51952
+ indirectsymoff 51976
   nindirectsyms 152
   extreloff 0
 nextrel 0
   locreloff 0
 nlocrel 0
 Load command 3
+ cmd LC_UUID
+ cmdsize 24
+   uuid 0x3f 0x20 0x5f 0xca 0xab 0x64 0x42 0xc5
+0xb1 0x8d 0x37 0x82 0x04 0x02 0x11 0xbb
+Load command 4
 cmd LC_UNIXTHREAD
 cmdsize 176
  flavor PPC_THREAD_STATE

=

the difference appears to be the cmd LC_UUID in the stage3 object.

In all probability this is harmless?
but I've yet to find a way to strip that load command.


-- 
   Summary: bootstrap fails with --with-dwarf2 trunk at 151455
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: developer at sandoe-acoustics dot co dot uk
 GCC build triplet: powerpc-apple-darwin8
  GCC host triplet: powerpc-apple-darwin8
GCC target triplet: powerpc-apple-darwin8


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

[Bug bootstrap/41296] bootstrap fails with --with-dwarf2 trunk at 151455

[developer at sandoe-acoustics dot co dot uk]

--- Comment #1 from developer at sandoe-acoustics dot co dot uk  2009-09-07 
13:32 ---
Created an attachment (id=18529)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18529&action=view)
patch allowing compare-debug to work with dwarf mach-o

this is needed to allow any meaningful comparison with dwarf-2 debug on
darwin8/9


-- 


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

[Bug libstdc++/41280] [4.5 Regression] Revision 151352 breaks 32bit libstdc++

[paolo at gcc dot gnu dot org]

--- Comment #9 from paolo at gcc dot gnu dot org  2009-09-07 13:38 ---
Subject: Bug 41280

Author: paolo
Date: Mon Sep  7 13:38:27 2009
New Revision: 151476

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151476
Log:
2009-09-07  H.J. Lu  
Ralf Wildenhues  

PR libstdc++/41280
* configure.ac: Run "${multi_basedir}/config-ml.in" to generate
MULTISUBDIR = in subdirectory Makefiles, with ml_norecursion set.
* configure: Regenerate.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/configure
trunk/libstdc++-v3/configure.ac


-- 


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

[Bug libstdc++/41280] [4.5 Regression] Revision 151352 breaks 32bit libstdc++

[paolo dot carlini at oracle dot com]

--- Comment #10 from paolo dot carlini at oracle dot com  2009-09-07 13:45 
---
Fixed.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug bootstrap/41245] [4.5 Regression] Bootstrap broken on I386-apple-darwin9 at revision 151373

[developer at sandoe-acoustics dot co dot uk]

--- Comment #5 from developer at sandoe-acoustics dot co dot uk  2009-09-07 
13:49 ---
does this help?
http://gcc.gnu.org/ml/gcc-patches/2009-09/msg00467.html


-- 


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

[Bug middle-end/41282] [4.5 Regression] Revision 151394 failed to compile mplayer

[jamborm at gcc dot gnu dot org]

--- Comment #6 from jamborm at gcc dot gnu dot org  2009-09-07 14:30 ---
A reduced testcase is below. It fails only on x86_64 for me as does
the preprocessed source.  SRA has different inputon i586.  However,
the bug is generic and can probably be triggered on any platform.

struct S
{
  unsigned int iu;
};

union U
{
  struct S s;
  signed int is;
};

extern signed int bar ();

struct S foo (void)
{
  union U u;

  u.is = bar ();
  return u.s;
}


-- 


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

[Bug middle-end/41282] [4.5 Regression] Revision 151394 failed to compile mplayer

[jamborm at gcc dot gnu dot org]

--- Comment #7 from jamborm at gcc dot gnu dot org  2009-09-07 15:21 ---
Created an attachment (id=18530)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18530&action=view)
Proposed patch

I am currently bootstrapping and testing the attached patch to fix this.


-- 


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

[Bug fortran/41197] ICE with ALLOCATE and nonscalar STAT= variable

[tkoenig at gcc dot gnu dot org]

--- Comment #3 from tkoenig at gcc dot gnu dot org  2009-09-07 15:23 ---
Subject: Bug 41197

Author: tkoenig
Date: Mon Sep  7 15:23:15 2009
New Revision: 151480

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151480
Log:
2009-09-07  Thomas Koenig  

PR fortran/41197
* resolve_c (resolve_allocate_deallocate):  Complain
if stat or errmsg varaible is an array.

2009-09-07  Thomas Koenig  

PR fortran/41197
* gfortran.dg/allocate_alloc_opt_1.f90:  Use scalar
variables for stat and errmsg.
* gfortran.dg/deallocate_alloc_opt_1.f90:  Likewise.
* gfortran.dg/allocate_stat_2.f90:  New test.


Added:
trunk/gcc/testsuite/gfortran.dg/allocate_stat_2.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/allocate_alloc_opt_1.f90
trunk/gcc/testsuite/gfortran.dg/deallocate_alloc_opt_1.f90


-- 


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

[Bug middle-end/41282] [4.5 Regression] Revision 151394 failed to compile mplayer

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2009-09-07 15:37 ---
The patch is ok if it passes bootstrap & regtesting.


-- 


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

[Bug rtl-optimization/41295] [4.5 Regression] gfortran.dg/loc_2.f90 -O3 -g fails on SH with orphaned debug_insn

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-09-07 15:39 ---
Debug insns are always "orphaned".


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu dot
   ||org
   Target Milestone|--- |4.5.0


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

[Bug c++/41214] [4.5 regression] Null pointer dereferenced in _Unwind_SetGR()

[rth at gcc dot gnu dot org]

--- Comment #9 from rth at gcc dot gnu dot org  2009-09-07 15:42 ---
Subject: Bug 41214

Author: rth
Date: Mon Sep  7 15:41:52 2009
New Revision: 151482

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151482
Log:
PR c++/41214
* unwind-dw2.c (uw_init_context_1): Mark noinline.
* config/ia64/unwind-ia64.c (uw_init_context_1): Likewise.
* config/xtensa/unwind-dw2-xtensa.c (uw_init_context_1): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/ia64/unwind-ia64.c
trunk/gcc/config/xtensa/unwind-dw2-xtensa.c
trunk/gcc/unwind-dw2.c


-- 


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

[Bug bootstrap/41245] [4.5 Regression] Bootstrap broken on I386-apple-darwin9 at revision 151373

[howarth at nitro dot med dot uc dot edu]

--- Comment #6 from howarth at nitro dot med dot uc dot edu  2009-09-07 
15:43 ---
I believe Mike Stump told me that it is possible that darwin's strip could
re-order the sections. Is that possibility addressed in the current patches?
Current x86_64-apple-darwin10 has no problems with gcc trunk at the moment.


-- 


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

[Bug inline-asm/41294] "=&rm" constraints give overlapping memory addresses

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-09-07 15:45 ---
I think you need to mark both alternatives early-clobber, not only the register
one.  Thus "=&r&m" at least according to the manual.


-- 


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

[Bug c++/41214] [4.5 regression] Null pointer dereferenced in _Unwind_SetGR()

[rguenth at gcc dot gnu dot org]

--- Comment #10 from rguenth at gcc dot gnu dot org  2009-09-07 15:50 
---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug fortran/41297] New: [4.5 Regression] Functions are called twice

[burnus at gcc dot gnu dot org]

In the following program, the function should only be called once. However,
with GCC 4.5 the function is called twice (see dump).

MAIN__ ()
{
  struct fgsl_interp interp;
  {
struct fgsl_interp D.1347;
static integer(kind=4) C.1345 = 1;
D.1347 = fgsl_interp_alloc (&C.1345);
interp = fgsl_interp_alloc (&C.1345);
  }
}


module m
  use iso_c_binding
  type :: fgsl_interp
 type(c_ptr) :: gsl_interp
  end type fgsl_interp
contains
  function fgsl_interp_alloc(size)
integer, intent(in) :: size
type(fgsl_interp) :: fgsl_interp_alloc
logical :: double = .false.
if (double) call abort()
double = .true.
fgsl_interp_alloc%gsl_interp = c_null_ptr
  end function fgsl_interp_alloc
end module m

use m
type(fgsl_interp) :: interp
interp = fgsl_interp_alloc(1)
end


-- 
   Summary: [4.5 Regression] Functions are called twice
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
OtherBugsDependingO 41293
 nThis:


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

[Bug fortran/41297] [4.5 Regression] Functions are called twice

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-09-07 15:57 ---
Looks like a tree sharing / FE issue to me.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.5.0


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

[Bug bootstrap/41245] [4.5 Regression] Bootstrap broken on I386-apple-darwin9 at revision 151373

[dominiq at lps dot ens dot fr]

--- Comment #7 from dominiq at lps dot ens dot fr  2009-09-07 16:00 ---
> Current x86_64-apple-darwin10 has no problems with gcc trunk at the moment.

I don't know for darwin10, but for darwin9 the comparison is currently
disabled, hence cannot fail!
If it is enabled again with Iain's patch (by replacing 'strip' by 'ld' see
pr41296), the comparison succeed on x86_64-apple-darwin9.


-- 


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

[Bug fortran/41297] [4.5 Regression] Functions are called twice

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2009-09-07 16:04 ---
FAILS: gcc-trunk-x86_64-2009-08-17-r150822
WORKS: gcc-trunk-x86_64-2009-08-14-r150734

When believing the revision numbers and looking at gcc/fortran only, one find
the following patch, which presumably caused the regression:

r150817 | rguenth | 2009-08-17 00:36:13 +0200 (Mon, 17 Aug 2009) | 5 lines

2009-08-17  Richard Guenther  

* trans-expr.c (gfc_trans_scalar_assign): Replace hack with
more proper hack.


-- 

burnus 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=41297

[Bug fortran/41293] FGSL: Wrong code generated

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2009-09-07 16:05 ---
The "error.x" failure is presumably due to PR 41297.


-- 


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

[Bug fortran/41298] New: wrong-code: Default initializer ignored

[burnus at gcc dot gnu dot org]

Split off from PR 41293.

The following program should work, i.e. calling "sub" should initialize the
component "gsl_file" with a NULL pointer.


module m
use iso_c_binding
  type, public :: fgsl_file
 type(c_ptr) :: gsl_file = c_null_ptr
  end type fgsl_file
contains
  subroutine sub(file)
type(fgsl_file), intent(out) :: file
  end subroutine
end module m

use m
type(fgsl_file) :: file
call sub(file)
if(c_associated(file%gsl_file)) call abort()
end


Using the 4.5 trunk (similar dump, same result with 4.3 and 4.4):

sub (struct fgsl_file & restrict file)
{
  if (file != 0)
{
  {
struct fgsl_file D.1336;
struct fgsl_file fgsl_file.0;

D.1336 = fgsl_file.0;
*file = fgsl_file.0;
  }
}
}


-- 
   Summary: wrong-code: Default initializer ignored
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
OtherBugsDependingO 41293
 nThis:


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

[Bug fortran/41293] FGSL: Wrong code generated

[burnus at gcc dot gnu dot org]

--- Comment #3 from burnus at gcc dot gnu dot org  2009-09-07 16:24 ---
The montecarlo.exe issue is PR 41298.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn|41298   |


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

[Bug middle-end/41250] hppa has DECL_VALUE_EXPR decls appearing in the function

[jamborm at gcc dot gnu dot org]

--- Comment #1 from jamborm at gcc dot gnu dot org  2009-09-07 16:28 ---
We have discussed this in the mailing list thread that eventually lead
to http://gcc.gnu.org/ml/gcc-patches/2009-09/msg00374.html

The bottom line is that we two options:

1) Do not set DECL_VALUE_EXPR to callee copied parameters in
   gimplify_parameters() and represent the convention explicitely.  I
   have tested this preliminary by running the c testsuite (no
   bootstrap or some such thing) and so far found no ICEs or
   miscompilations.

   The drawback is that this approach will most probably mess up debug
   info and the link in between the original and actual parameter will
   get lost.  The benefit is that we would uphold the stated (but
   currently violated) rule that declarations with the DECL_VALUE_EXPR
   do not occur in the function body.

2) The second approach is to teach gimplifier not to do the
   substitutions which can be bogus.  Once the function body has been
   gimplifed, we might set some flag in the gimplification context or,
   alternatively, I'm about to try to simply disable the substitutions
   in gimplify_var_or_parm_decl() for PARM_DECLs.

   This would mean we would need to drop the rule not allowing such
   decls in the function body.  I don't know whether it needs to be
   replaced by some weaker restriction.


-- 

jamborm at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu dot
   ||org


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

[Bug target/38182] stddef.h assumes machinee/ansi.h defines _ANSI_H_

[prlw1 at cam dot ac dot uk]

--- Comment #15 from prlw1 at cam dot ac dot uk  2009-09-07 16:47 ---
I just got stuck with this again: wondered why a NetBSD-5.99.15/i386 box with
gcc-HEAD wouldn't compile. Then remembered the #define _ANSI_H_ fix and all is
well. What is impeding this patch from being applied?


-- 


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

[Bug fortran/41293] FGSL: Wrong code generated

[burnus at gcc dot gnu dot org]

--- Comment #4 from burnus at gcc dot gnu dot org  2009-09-07 16:56 ---
Regarding multimin.exe:

The second call to unit_assert_equal_within fails. For the first, the expected
value is 30 and it succeeds.

For the second one, one does 13 loops with fgsl_multimin_fdfminimizer_iterate
with status == 0 and a minimum of mmin_fmin of 3.5e-317 (unchanged). After the
loop there is a check whether this number matches (within 1e-5) the number 30
which fails:

fgsl_multimin_fdfminimizer_iterate 3.00D+01
3.511692129834245077-317 1.0D-05

I currently assume that it is a test bug, FGSL or GSL bug.


-- 


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

[1252342595.25812] READ THIS: comp.lang.perl.moderated registration

[comp.lang.perl.moderated registration]

Your article will not appear in the comp.lang.perl.moderated newsgroup
until you register.  Registration instructions follow.



Every post to the comp.lang.perl.moderated (also known as clpmod)
newsgroup consumes the time and effort of readers all over the world who
pay for their Internet access just as you do.  Each post also takes up
the time of a team of volunteer moderators who must review each
submission to determine whether it is appropriate for the group.  That's
ok, because mutual support is what USENET is all about.  But it only
works if posters check out other resources first!

To benefit everyone, Nathan Torkington  came up with a
handy checklist.  If you have a question about Perl and run it against
this checklist, you are more likely to find at least one answer.
Learning to research Perl questions is useful because Usenet is not a
free helpdesk--there is no guarantee anyone will answer your question at
all!  It would be much easier to grep the docs and FAQs first.

There is also the added benefit that the Perl documentation and FAQs
were created and reviewed by respected Perl experts.  This means that
the answer or answers you find will almost certainly be not only
correct, but the best possible answer (they may even outline several
solutions).

So, please consider the following:

1. comp.lang.perl.moderated is for questions on the Perl language.  If
   you're interested in reading the group's charter, please go to

http://www.plover.com/clpm/charter>

   Don't forget that there is also an unmoderated group for discussion
   of the Perl language, comp.lang.perl.misc, for topics that do not
   fall within the bounds of clpmod's charter.

   Try comp.infosystems.www.authoring.cgi for questions on the CGI part
   of CGI scripts.  The two leading blocks of reusable code for CGI
   purposes are CGI.pm, at

ftp://genome.wi.mit.edu/pub/software/WWW/cgi_docs.html>

http://www.cpan.org/modules/by-module/CGI/>

   and cgi-lib.pl, at

http://www.bio.cam.ac.uk/cgi-lib/>

   You might also want to check out libwww-perl at

http://www.linpro.no/lwp/>

http://www.cpan.org/modules/by-module/LWP/>

   If you are having problems with a CGI script, look through

http://www.cpan.org/doc/FAQs/cgi/idiots-guide.html>

2. Are you using the following?

#!/usr/bin/perl -w
use diagnostics;
use strict;

   "-w" turns on all sorts of warnings about probable errors (see the
   perldiag manpage), "use diagnostics" causes the "-w" warnings to be
   explained in greater detail (with the explanations from the perldiag
   manpage), and "use strict" generates compile and run-time errors for
   certain unsafe variable, reference and subroutine constructs (see the
   strict manpage)

3. Have you read the Perl FAQ?  Many questions on sockets programming,
   an important and common problem with Solaris, text manipulation and
   the jargon of perl are answered in the FAQ.  As well as being posted
   regularly to comp.lang.perl.misc, the FAQ is on the web at:

http://www.cpan.org/doc/FAQs/FAQ/html/>
 
4. Have you read the man pages?  Here are some subjects and the man
   pages to look in:

Objects perltoot, perlref, perlmod, perlobj, perltie
Data Structures perlreftut, perlref, perllol, perldsc
Modules perlmod, perlsub, perlmodinstall
Regexps perlre, perlfunc, perlop
http://www.cpan.org/doc/FMTEYEWTK/>
(not a man-page but still useful)
Moving to perl5 perltrap, perl
Linking w/C perlxstut, perlxs, perlcall, perlguts, perlembed

   The man page for "perltoc" provides a crude table of contents for the
   perl man page set.

5. Have you tried archives of Usenet?  http://groups.google.com/>
   maintains an archive of postings to Usenet dating from March, 1995.
   Be sure to include "Perl" in your search.

6. Are you checking the return values from the functions built in to
   perl?  Most of the file and system functions set $! and have return
   values that you can test thus:

open(PASSWD, "http://www.perl.com/>?  This is a great
   online reference, with documentation, pointers to modules in the
   Comprehensive Perl Archive Network (CPAN), articles on the inner
   workings of many bits of Perl, and more.

7.5. Have you checked to see if a Perl module satisfies your needs?
   Many reusable modules are available for immediate download and use.
   See http://www.cpan.org/modules/00modlist.long.html> for details.

8. The latest version of the "Camel Book" ("Programming Perl"),
   updated for version 5.6, is available from your bookstore or from
   http://www.ora.com/>.

   Another excellent dead tree resource is the first and only periodical
   devoted to Perl, The Perl Journal.  In fact, several moderators have
   even contributed to TPJ.  Find it on the web at

[Bug middle-end/41282] [4.5 Regression] Revision 151394 failed to compile mplayer

[jamborm at gcc dot gnu dot org]

--- Comment #9 from jamborm at gcc dot gnu dot org  2009-09-07 17:08 ---
Subject: Bug 41282

Author: jamborm
Date: Mon Sep  7 17:08:12 2009
New Revision: 151484

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151484
Log:
2009-09-07  Martin Jambor  

PR middle-end/41282
* tree-sra.c (create_artificial_child_access): Return NULL if
build_ref_for_offset fails.
(propagate_subacesses_accross_link): Allow build_ref_for_offset
and create_artificial_child_access to fail.

* testsuite/gcc.c-torture/compile/pr41282.c: New test.



Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr41282.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-sra.c


-- 


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

[Bug middle-end/41282] [4.5 Regression] Revision 151394 failed to compile mplayer

[jamborm at gcc dot gnu dot org]

--- Comment #10 from jamborm at gcc dot gnu dot org  2009-09-07 17:14 
---
Fixed.


-- 

jamborm at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug target/38182] stddef.h assumes machinee/ansi.h defines _ANSI_H_

[joseph at codesourcery dot com]

--- Comment #16 from joseph at codesourcery dot com  2009-09-07 17:24 
---
Subject: Re:  stddef.h assumes machinee/ansi.h defines
 _ANSI_H_

On Mon, 7 Sep 2009, prlw1 at cam dot ac dot uk wrote:

> I just got stuck with this again: wondered why a NetBSD-5.99.15/i386 box with
> gcc-HEAD wouldn't compile. Then remembered the #define _ANSI_H_ fix and all is
> well. What is impeding this patch from being applied?

I don't recall seeing weekly pings of it; presumably no maintainer in a 
relevant area picked up review of it the first and only time it was posted 
and noone made maintainers aware of the continued need for review by 
pinging it until it gets reviewed.


-- 


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

[Bug c/41299] New: code size regression (from 4.3) with -Os and -mregparm=3

[rmh at gcc dot gnu dot org]

$ gcc-4.3 -c -Os -mregparm=3 -m32 test.c && objcopy -O binary test.o test.raw
&&  du -b test.raw
66  test.raw

$ gcc-4.4 -c -Os -mregparm=3 -m32 test.c && objcopy -O binary test.o test.raw
&&  du -b test.raw
70  test.raw


-- 
   Summary: code size regression (from 4.3) with -Os and -mregparm=3
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rmh at gcc dot gnu dot org


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

[Bug c/41299] code size regression (from 4.3) with -Os and -mregparm=3

[rmh at gcc dot gnu dot org]

--- Comment #1 from rmh at gcc dot gnu dot org  2009-09-07 18:40 ---
Created an attachment (id=18531)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18531&action=view)
test case


-- 


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

[Bug rtl-optimization/40861] [4.4 Regression] ICE in simplify_subreg, at simplify-rtx.c:4981

[reichelt at gcc dot gnu dot org]

--- Comment #6 from reichelt at gcc dot gnu dot org  2009-09-07 19:15 
---
Fixed for GCC 4.5.0.

Uros, are you going to backport the fix to the 4.4 branch?


-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||uros at gcc dot gnu dot org
Summary|[4.4/4.5 Regression] ICE in |[4.4 Regression] ICE in
   |simplify_subreg, at |simplify_subreg, at
   |simplify-rtx.c:4981 |simplify-rtx.c:4981
   Target Milestone|4.5.0   |4.4.2


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

[Bug target/40454] [4.4 regression] zlib is about 20% slower when compiled with GCC 4.4.1

[ami_stuff at o2 dot pl]

--- Comment #15 from ami_stuff at o2 dot pl  2009-09-07 19:22 ---
GCC 4.4.2 - GCC 4.4.2 (20090825).
GCC 4.5.0 - GCC 4.5.0 (20090827).

Here are the results:

cputime minigzip_340_O1 testa.tif - 33.917
cputime minigzip_340_O2 testa.tif - 30.868
cputime minigzip_340_O3 testa.tif - 31.304

cputime minigzip_442_O1 testa.tif - 39.261
cputime minigzip_442_O2 testa.tif - 37.704
cputime minigzip_442_O3 testa.tif - 41.666

cputime minigzip_450_O1 testa.tif - 41.128
cputime minigzip_450_O2 testa.tif - 37.587
cputime minigzip_450_O3 testa.tif - 37.663


-- 


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

[Bug inline-asm/41294] "=&rm" constraints give overlapping memory addresses

[jdemeyer at cage dot ugent dot be]

--- Comment #3 from jdemeyer at cage dot ugent dot be  2009-09-07 19:30 
---
(In reply to comment #2)
> I think you need to mark both alternatives early-clobber, not only the 
> register
> one.  Thus "=&r&m" at least according to the manual.

That doesn't seem to change anything.  It looks to me like the parser only
checks for the presence of at least one "&", since it even accepts "=&&r&&m&&"
(maybe that's another bug?).  On the other hand, using "=&m" as constraint
gives an error
bug.c:141:2: error: '&' constraint used with no register class

According to http://gcc.gnu.org/onlinedocs/gcc/Multi_002dAlternative.html,
the constraint "=&rm" counts as ONE alternative, since alternatives are
seperated by commas.  This is one alternative, allowing both a register or
memory location.


-- 


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

[Bug middle-end/41289] [4.5 Regression] ICE verify_ssa failed building libavformat/oggparseogm.c

[aoliva at gcc dot gnu dot org]

--- Comment #7 from aoliva at gcc dot gnu dot org  2009-09-07 19:41 ---
If you compiled with -save-temps, then the .i file must be somewhere.  We'll
also need the command line to duplicate the problem, and knowing the command
line might help finding out where the .i file might have ended up.


-- 


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

[Bug c++/41300] New: verify_ssa failed with -g -O3

[dcb314 at hotmail dot com]

I just tried to compile the Suse Linux package yakuake-2.9.6
with the gcc 4.5 mainline snapshot 20090903
and the compiler said

/usr/src/packages/BUILD/yakuake-2.9.6/app/tabbar.cpp: In member function 'int
TabBar::drawButton(int, int, int, QPainter&)':
/usr/src/packages/BUILD/yakuake-2.9.6/app/tabbar.cpp:333:5: error: expected an
SSA_NAME object
/usr/src/packages/BUILD/yakuake-2.9.6/app/tabbar.cpp:333:5: error: in statement
# DEBUG D.119521 => sessionId
/usr/src/packages/BUILD/yakuake-2.9.6/app/tabbar.cpp:333:5: internal compiler
error: verify_ssa failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Preprocessed source attached. Flags -g -O3 required.


-- 
   Summary: verify_ssa failed with -g -O3
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dcb314 at hotmail dot com
  GCC host triplet: x86_64-suse-linux


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

[Bug c++/41300] verify_ssa failed with -g -O3

[dcb314 at hotmail dot com]

--- Comment #1 from dcb314 at hotmail dot com  2009-09-07 19:47 ---
Created an attachment (id=18532)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18532&action=view)
gzipped C++ source code


-- 


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

[Bug ada/41286] a warning about renamed function result is possibly confusing

[bauhaus at futureapps dot de]

--- Comment #1 from bauhaus at futureapps dot de  2009-09-07 19:37 ---
"Line" should be "Text", sorry.


-- 


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

[Bug c/41301] New: ice in propagate_subacesses_accross_link

[dcb314 at hotmail dot com]

I just tried to compile the Suse Linux package zvbi-0.2.33
with the gcc 4.5 mainline snapshot 20090903
and the compiler said

exp-txt.c: In function 'print_char':
exp-txt.c:684:1: internal compiler error: in propagate_subacesses_accross_link,
at tree-sra.c:1563
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Preprocessed source attached. Flag -O2 required.

Minor cosmetic problem: It will be better English to rename
propagate_subacesses_accross_link
to be propagate_subaccesses_across_link


-- 
   Summary: ice in propagate_subacesses_accross_link
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dcb314 at hotmail dot com


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

[Bug c/41301] ice in propagate_subacesses_accross_link

[dcb314 at hotmail dot com]

--- Comment #1 from dcb314 at hotmail dot com  2009-09-07 20:12 ---
Created an attachment (id=18533)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18533&action=view)
C source code


-- 


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

[Bug rtl-optimization/40861] [4.4 Regression] ICE in simplify_subreg, at simplify-rtx.c:4981

[uros at gcc dot gnu dot org]

--- Comment #7 from uros at gcc dot gnu dot org  2009-09-07 20:26 ---
Subject: Bug 40861

Author: uros
Date: Mon Sep  7 20:25:52 2009
New Revision: 151489

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151489
Log:
Backport from mainline:
2009-08-27  Uros Bizjak  

PR rtl-optimization/40861
* simplify-rtx.c (simplify_subreg): Do not call simplify_gen_subreg to
extract word from a multi-word subreg for negative byte positions.

testsuite/ChangeLog:

Backport from mainline:
2009-08-27  Uros Bizjak  

PR rtl-optimization/40861
* gcc.dg/pr40861.c: New test.


Added:
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr40861.c
Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/simplify-rtx.c
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug rtl-optimization/40861] [4.4 Regression] ICE in simplify_subreg, at simplify-rtx.c:4981

[ubizjak at gmail dot com]

--- Comment #8 from ubizjak at gmail dot com  2009-09-07 20:27 ---
Thanks for the reminder, I forgot on this patch...

Fixed.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug fortran/41297] [4.5 Regression] Functions are called twice

[rguenther at suse dot de]

--- Comment #3 from rguenther at suse dot de  2009-09-07 20:45 ---
Subject: Re:  [4.5 Regression] Functions are called
 twice

On Mon, 7 Sep 2009, burnus at gcc dot gnu dot org wrote:

> --- Comment #2 from burnus at gcc dot gnu dot org  2009-09-07 16:04 
> ---
> FAILS: gcc-trunk-x86_64-2009-08-17-r150822
> WORKS: gcc-trunk-x86_64-2009-08-14-r150734
> 
> When believing the revision numbers and looking at gcc/fortran only, one find
> the following patch, which presumably caused the regression:
> 
> r150817 | rguenth | 2009-08-17 00:36:13 +0200 (Mon, 17 Aug 2009) | 5 lines
> 
> 2009-08-17  Richard Guenther  
> 
> * trans-expr.c (gfc_trans_scalar_assign): Replace hack with
> more proper hack.

Impossible!

Richard.


-- 


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

[Bug fortran/41297] [4.5 Regression] Functions are called twice

[burnus at gcc dot gnu dot org]

--- Comment #4 from burnus at gcc dot gnu dot org  2009-09-07 21:12 ---
(In reply to comment #3)
> > r150817 | rguenth | 2009-08-17 00:36:13 +0200 (Mon, 17 Aug 2009) | 5 lines
> Impossible!

I am not sure whether it is impossible or just extremely unlikely, but
reverting that patch does not help :-)

> Looks like a tree sharing / FE issue to me.
Likely. None of the other checkins looks as if they could have been the cause.


-- 


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

[Bug fortran/41297] [4.5 Regression] Functions are called twice

[rguenther at suse dot de]

--- Comment #5 from rguenther at suse dot de  2009-09-07 21:21 ---
Subject: Re:  [4.5 Regression] Functions are called
 twice

On Mon, 7 Sep 2009, burnus at gcc dot gnu dot org wrote:

> --- Comment #4 from burnus at gcc dot gnu dot org  2009-09-07 21:12 
> ---
> (In reply to comment #3)
> > > r150817 | rguenth | 2009-08-17 00:36:13 +0200 (Mon, 17 Aug 2009) | 5 lines
> > Impossible!
> 
> I am not sure whether it is impossible or just extremely unlikely, but
> reverting that patch does not help :-)
> 
> > Looks like a tree sharing / FE issue to me.
> Likely. None of the other checkins looks as if they could have been the cause.

Ah, can you check/commit

+  gfc_add_block_to_block (&block, &lse->pre);
+  gfc_add_block_to_block (&block, &rse->pre);
+  tmp = gfc_evaluate_now (rse->expr, &block);
+  tmp = fold_build1 (VIEW_CONVERT_EXPR, TREE_TYPE (lse->expr), 
rse->expr);

tmp

?

Richard.


-- 


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

[Bug middle-end/41268] [4.5 Regression] bootstrap is broken after r151350 (expand from tuples)

[matz at gcc dot gnu dot org]

--- Comment #1 from matz at gcc dot gnu dot org  2009-09-07 21:23 ---
Hmm, so the ia64 backend relies on REG_POINTER for correctness, instead of
just for optimization (like e.g. ppc)?  I'm not sure that's a good idea.
In any case with finding the testcase (thanks) I should be able to reproduce
and fix this.


-- 

matz at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |matz at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-09-07 21:23:08
   date||


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

[Bug rtl-optimization/41295] [4.5 Regression] gfortran.dg/loc_2.f90 -O3 -g fails on SH with orphaned debug_insn

[kkojima at gcc dot gnu dot org]

--- Comment #2 from kkojima at gcc dot gnu dot org  2009-09-07 21:27 ---
Ah, then it seems that reload_combine_note_use or its caller should
take account of debug insns.


-- 


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

[Bug c/41302] New: Cast of return value from uint32 to pointer cannot be optimized by a jump to called rtn.

[dferbas at etech dot cz]

Called fn returns value in d0 (non pointer), but findZipEntry should return
value in a0 (address register). So in that case optimization cannot be done by
simply jumping to the called fn.

typedef u_int32_t   w_word;
typedef struct *z_zipEntry;

z_zipEntry findZipEntry(z_zipFile dir, w_byte *name) {

return (z_zipEntry) ht_read(dir->ht, (w_word)name);
}


findZipEntry:
move.l 4(%sp),%a0
move.l 8(%a0),4(%sp)

jra ht_read

There should be:
jbsr ht_read
move.l %d0,%a0
rts


-- 
   Summary: Cast of return value from uint32 to pointer cannot be
optimized by a jump to called rtn.
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dferbas at etech dot cz


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

[Bug c++/41207] The resulting 64-bit binary doesn't get recognized as proper binary by windows vista x64

[t66667 at gmail dot com]

--- Comment #1 from t7 at gmail dot com  2009-09-07 23:46 ---
Just found out yesterday afternoon that the binary dll does work correctly.


-- 

t7 at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug fortran/40812] Files > 2GB are incorrectly handled on mingw

[jvdelisle at gcc dot gnu dot org]

--- Comment #11 from jvdelisle at gcc dot gnu dot org  2009-09-07 23:58 
---
I worked on some of the current large file defines in libgfortran.  Show me a
patch of what you want to do.  It should be OK.  A patch is worth a thousand
words.


-- 


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

[Bug fortran/41219] libgfortran build warnings

[jvdelisle at gcc dot gnu dot org]

--- Comment #11 from jvdelisle at gcc dot gnu dot org  2009-09-08 00:59 
---
Subject: Bug 41219

Author: jvdelisle
Date: Tue Sep  8 00:59:05 2009
New Revision: 151495

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151495
Log:
2009-09-07  Jerry DeLisle  

PR libgfortran/41192
* io/list_read.c (eat_line): Enable eat_line to function on
internal units.

PR libgfortran/41219
* io/list_read.c (nml_read_obj): Replace GFC_DTYPE_UNKNOWN with
BT_NULL to get rid of warning.

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


-- 


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

[Bug fortran/41192] NAMELIST input with just a comment ("&NAME ! comment \") fails

[jvdelisle at gcc dot gnu dot org]

--- Comment #11 from jvdelisle at gcc dot gnu dot org  2009-09-08 00:59 
---
Subject: Bug 41192

Author: jvdelisle
Date: Tue Sep  8 00:59:05 2009
New Revision: 151495

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151495
Log:
2009-09-07  Jerry DeLisle  

PR libgfortran/41192
* io/list_read.c (eat_line): Enable eat_line to function on
internal units.

PR libgfortran/41219
* io/list_read.c (nml_read_obj): Replace GFC_DTYPE_UNKNOWN with
BT_NULL to get rid of warning.

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


-- 


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

[Bug fortran/41192] NAMELIST input with just a comment ("&NAME ! comment \") fails

[jvdelisle at gcc dot gnu dot org]

--- Comment #12 from jvdelisle at gcc dot gnu dot org  2009-09-08 01:19 
---
Subject: Bug 41192

Author: jvdelisle
Date: Tue Sep  8 01:18:48 2009
New Revision: 151496

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151496
Log:
2009-09-07  Jerry DeLisle  

PR libgfortran/41192
* gfortran.dg/namelist_59.f90: New test.

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


-- 


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

[Bug target/41288] [4.5 Regression] gcc.target/x86_64/abi/test_struct_returning.c regressions on *-apple-darwin* at -m64

[howarth at nitro dot med dot uc dot edu]

--- Comment #3 from howarth at nitro dot med dot uc dot edu  2009-09-08 
02:59 ---
A regression hunt shows that r147824 passes all of
gcc.target/x86_64/abi/test_struct_returning.c's execution tests but r147829
fails...

FAIL: gcc.target/x86_64/abi/test_struct_returning.c execution,  -O3
-fomit-frame-pointer 
FAIL: gcc.target/x86_64/abi/test_struct_returning.c execution,  -O3
-fomit-frame-pointer -funroll-loops 
FAIL: gcc.target/x86_64/abi/test_struct_returning.c execution,  -O3
-fomit-frame-pointer -funroll-all-loops -finline-functions 
FAIL: gcc.target/x86_64/abi/test_struct_returning.c execution,  -O3 -g 

which suggests that r147829 is the cause.

Author: irar
Date: Sun May 24 08:44:56 2009
New Revision: 147829

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147829
Log:

* doc/passes.texi (Tree-SSA passes): Document SLP pass.
* tree-pass.h (pass_slp_vectorize): New pass.
* params.h (SLP_MAX_INSNS_IN_BB): Define.
* timevar.def (TV_TREE_SLP_VECTORIZATION): Define.
* tree-vectorizer.c (timevar.h): Include.
(user_vect_verbosity_level): Declare.
(vect_location): Fix comment.
(vect_set_verbosity_level): Update user_vect_verbosity_level
instead of vect_verbosity_level.
(vect_set_dump_settings): Add an argument. Ignore user defined
verbosity if dump flags require higher level of verbosity. Print to
stderr only for loop vectorization.
(vectorize_loops): Update call to vect_set_dump_settings.
(execute_vect_slp): New function.
(gate_vect_slp): Likewise.
(struct gimple_opt_pass pass_slp_vectorize): New.
* tree-vectorizer.h (struct _bb_vec_info): Define along macros to
access its members.
(vec_info_for_bb): New function.
(struct _stmt_vec_info): Add bb_vinfo and a macro for its access.
(VECTORIZATION_ENABLED): New macro.
(SLP_ENABLED, SLP_DISABLED): Likewise.
(vect_is_simple_use): Add bb_vec_info argument.
(new_stmt_vec_info, vect_analyze_data_ref_dependences,
vect_analyze_data_refs_alignment, vect_verify_datarefs_alignment,
vect_analyze_data_ref_accesses, vect_analyze_data_refs,
vect_schedule_slp, vect_analyze_slp): Likewise.
(vect_analyze_stmt): Add slp_tree argument.
(find_bb_location): Declare.
(vect_slp_analyze_bb, vect_slp_transform_bb): Likewise.
* tree-vect-loop.c (new_loop_vec_info): Adjust function calls.
(vect_analyze_loop_operations, vect_analyze_loop,
get_initial_def_for_induction, vect_create_epilog_for_reduction,
vect_finalize_reduction, vectorizable_reduction,
vectorizable_live_operation, vect_transform_loop): Likewise.
* tree-data-ref.c (dr_analyze_innermost): Update comment,
skip evolution analysis if analyzing a basic block.
(dr_analyze_indices): Likewise.
(initialize_data_dependence_relation): Skip the test whether the
object is invariant for basic blocks.
(compute_all_dependences): Skip dependence analysis for data
references in basic blocks.
(find_data_references_in_stmt): Don't fail in case of invariant
access in basic block.
(find_data_references_in_bb): New function.
(find_data_references_in_loop): Move code to
find_data_references_in_bband add a call to it.
(compute_data_dependences_for_bb): New function.
* tree-data-ref.h (compute_data_dependences_for_bb): Declare.
* tree-vect-data-refs.c (vect_check_interleaving): Adjust to the case
that STEP is 0.
(vect_analyze_data_ref_dependence): Check for interleaving in case of
unknown dependence in basic block and fail in case of dependence in
basic block.
(vect_analyze_data_ref_dependences): Add bb_vinfo argument, get data
dependence instances from either loop or basic block vectorization
info.
(vect_compute_data_ref_alignment): Check if it is loop vectorization
before calling nested_in_vect_loop_p.
(vect_compute_data_refs_alignment): Add bb_vinfo argument, get data
dependence instances from either loop or basic block vectorization
info.
(vect_verify_datarefs_alignment): Likewise.
(vect_enhance_data_refs_alignment): Adjust function calls.
(vect_analyze_data_refs_alignment): Likewise.
(vect_analyze_group_access): Fix printing. Skip different checks if
DR_STEP is 0. Keep strided stores either in loop or basic block
vectorization data structure. Fix indentation.
(vect_analyze_data_ref_access): Fix comments, allow zero step in
basic blocks.
(vect_analyze_data_ref_accesses): Add bb_vinfo argument, get data
dependence instances from either loop or basic block vectorization
info.
(vect_analyze_data_refs): Update comment. Call
compute_data_depend

[Bug target/41288] [4.5 Regression] gcc.target/x86_64/abi/test_struct_returning.c regressions on *-apple-darwin* at -m64

[howarth at nitro dot med dot uc dot edu]

--- Comment #4 from howarth at nitro dot med dot uc dot edu  2009-09-08 
03:04 ---
Created an attachment (id=18534)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18534&action=view)
preprocessed source for gcc.target/x86_64/abi/test_struct_returning.c
compilation,  -O3 -fomit-frame-pointer

/sw/src/fink.build/gcc45-4.4.999-20090524/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc45-4.4.999-20090524/darwin_objdir/gcc/
/sw/src/fink.build/gcc45-4.4.999-20090524/gcc-4.5-20090524/gcc/testsuite/gcc.target/x86_64/abi/test_struct_returning.c
/sw/src/fink.build/gcc45-4.4.999-20090524/gcc-4.5-20090524/gcc/testsuite/gcc.target/x86_64/abi/asm-support-darwin.s
 -w  -O3 -fomit-frame-pointer --save-temps  -W -Wall -Wno-abi  -lm   -o
/sw/src/fink.build/gcc45-4.4.999-20090524/darwin_objdir/gcc/testsuite/gcc/test_struct_returning.x3


-- 


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

[Bug target/41288] [4.5 Regression] gcc.target/x86_64/abi/test_struct_returning.c regressions on *-apple-darwin* at -m64

[howarth at nitro dot med dot uc dot edu]

--- Comment #5 from howarth at nitro dot med dot uc dot edu  2009-09-08 
03:05 ---
Created an attachment (id=18535)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18535&action=view)
assembly file from gcc.target/x86_64/abi/test_struct_returning.c compilation, 
-O3 -fomit-frame-pointer under r147829

/sw/src/fink.build/gcc45-4.4.999-20090524/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc45-4.4.999-20090524/darwin_objdir/gcc/
/sw/src/fink.build/gcc45-4.4.999-20090524/gcc-4.5-20090524/gcc/testsuite/gcc.target/x86_64/abi/test_struct_returning.c
/sw/src/fink.build/gcc45-4.4.999-20090524/gcc-4.5-20090524/gcc/testsuite/gcc.target/x86_64/abi/asm-support-darwin.s
 -w  -O3 -fomit-frame-pointer --save-temps  -W -Wall -Wno-abi  -lm   -o
/sw/src/fink.build/gcc45-4.4.999-20090524/darwin_objdir/gcc/testsuite/gcc/test_struct_returning.x3


-- 


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

[Bug target/41288] [4.5 Regression] gcc.target/x86_64/abi/test_struct_returning.c regressions on *-apple-darwin* at -m64

[howarth at nitro dot med dot uc dot edu]

--- Comment #6 from howarth at nitro dot med dot uc dot edu  2009-09-08 
03:09 ---
Created an attachment (id=18536)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18536&action=view)
assembly file from gcc.target/x86_64/abi/test_struct_returning.c compilation, 
-O3 -fomit-frame-pointer under r147824

/sw/src/fink.build/gcc45-4.4.999-20090523/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc45-4.4.999-20090523/darwin_objdir/gcc/
/sw/src/fink.build/gcc45-4.4.999-20090523/gcc-4.5-20090523/gcc/testsuite/gcc.target/x86_64/abi/test_struct_returning.c
/sw/src/fink.build/gcc45-4.4.999-20090523/gcc-4.5-20090523/gcc/testsuite/gcc.target/x86_64/abi/asm-support-darwin.s
 -w  -O3 -fomit-frame-pointer --save-temps -W -Wall -Wno-abi  -lm   -o
/sw/src/fink.build/gcc45-4.4.999-20090523/darwin_objdir/gcc/testsuite/gcc/test_struct_returning.x3


-- 


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

[Bug target/41288] [4.5 Regression] gcc.target/x86_64/abi/test_struct_returning.c regressions on *-apple-darwin* at -m64

[howarth at nitro dot med dot uc dot edu]

--- Comment #7 from howarth at nitro dot med dot uc dot edu  2009-09-08 
03:12 ---
The diff between the test_struct_returning.c test case as compiled with -O3
-fomit-frame-pointer under r147824 vs r147829 is...

--- r147824 2009-09-07 23:11:08.0 -0400
+++ r147829 2009-09-07 23:10:45.0 -0400
@@ -73,13 +73,10 @@
 .globl _f_600
 _f_600:
 LFB573:
-   movl$0x4228, %eax
-   movl%eax, -24(%rsp)
-   movl%eax, -20(%rsp)
-   movl%eax, -16(%rsp)
-   movl%eax, -12(%rsp)
+   movaps  LC4(%rip), %xmm0
+   movaps  %xmm0, -24(%rsp)
+   movqLC5(%rip), %xmm0
movq-16(%rsp), %xmm1
-   movq-24(%rsp), %xmm0
ret
 LFE573:
.align 4,0x90
@@ -365,7 +362,7 @@
 .globl _f_101
 _f_101:
 LFB536:
-   movsd   LC4(%rip), %xmm0
+   movsd   LC6(%rip), %xmm0
ret
 LFE536:
.align 4,0x90
@@ -495,7 +492,7 @@
ret
 LFE521:
.cstring
-LC7:
+LC9:
.ascii "failed in test %d\12\0"
.text
.align 4,0x90
@@ -541,7 +538,7 @@
.align 4,0x90
 L52:
movq___stde...@gotpcrel(%rip), %rax
-   leaqLC7(%rip), %rsi
+   leaqLC9(%rip), %rsi
movq(%rax), %rdi
xorl%eax, %eax
call_fprintf
@@ -645,7 +642,7 @@
je  L92
 L91:
movq___stde...@gotpcrel(%rip), %rax
-   leaqLC7(%rip), %rsi
+   leaqLC9(%rip), %rsi
movq(%rax), %rdi
xorl%eax, %eax
call_fprintf
@@ -670,7 +667,7 @@
.align 4,0x90
 L92:
movq_xmm_r...@gotpcrel(%rip), %rax
-   movsd   LC4(%rip), %xmm0
+   movsd   LC6(%rip), %xmm0
ucomisd (%rax), %xmm0
jne L87
jp  L87
@@ -719,7 +716,7 @@
 LCFI6:
movq%r15, -8(%rsp)
 LCFI7:
-# 172
"/sw/src/fink.build/gcc45-4.4.999-20090523/gcc-4.5-20090523/gcc/testsuite/gcc.target/x86_64/abi/test_struct_returning.c"
1
+# 172
"/sw/src/fink.build/gcc45-4.4.999-20090524/gcc-4.5-20090524/gcc/testsuite/gcc.target/x86_64/abi/test_struct_returning.c"
1
xor %rax, %rax
xor %rbx, %rbx
xor %rcx, %rcx
@@ -823,7 +820,7 @@
.align 4,0x90
 L133:
movq___stde...@gotpcrel(%rip), %rax
-   leaqLC7(%rip), %rsi
+   leaqLC9(%rip), %rsi
movq(%rax), %rdi
xorl%eax, %eax
call_fprintf
@@ -883,7 +880,7 @@
.align 4,0x90
 L99:
movq_xmm_r...@gotpcrel(%rip), %rax
-   movsd   LC4(%rip), %xmm0
+   movsd   LC6(%rip), %xmm0
ucomisd (%rax), %xmm0
jp  L119
je  L138
@@ -930,7 +927,7 @@
.align 4,0x90
 L139:
movq_xmm_r...@gotpcrel(%rip), %rax
-   movsd   LC4(%rip), %xmm0
+   movsd   LC6(%rip), %xmm0
ucomisd (%rax), %xmm0
jne L117
jp  L117
@@ -1927,8 +1924,8 @@
 .comm _fregs,448,5
 .comm _num_iregs,4,2
 .comm _num_fregs,4,2
-.comm _current_test,4,2
-.comm _struct_addr,8,3
+.comm _current_test,4,4
+.comm _struct_addr,8,4
.literal4
.align 2
 LC0:
@@ -1941,8 +1938,19 @@
 LC3:
.long   0
.long   1078296576
-   .align 3
+   .literal16
+   .align 4
 LC4:
+   .long   1109917696
+   .long   1109917696
+   .long   1109917696
+   .long   1109917696
+   .literal8
+   .align 3
+LC5:
+   .quad   4767060206681587712
+   .align 3
+LC6:
.long   0
.long   1078263808
.section
__TEXT,__eh_frame,coalesced,no_toc+strip_static_syms+live_support


-- 


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

[Bug target/41288] [4.5 Regression] gcc.target/x86_64/abi/test_struct_returning.c regressions on *-apple-darwin* at -m64

[howarth at nitro dot med dot uc dot edu]

--- Comment #8 from howarth at nitro dot med dot uc dot edu  2009-09-08 
03:17 ---
Attempting to obtain a backtrace for test_struct_returning.x3 built with -O3
-fomit-frame-pointer under r147829, I can only get...

[MacPro:gcc/testsuite/gcc] root# gdb ./test_struct_returning.x3
GNU gdb 6.3.50-20050815 (Apple version gdb-1344) (Fri Jul  3 01:19:56 UTC 2009)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared
libraries ... done

(gdb) r
Starting program:
/sw/src/fink.build/gcc45-4.4.999-20090524/darwin_objdir/gcc/testsuite/gcc/test_struct_returning.x3
 
limit: stacksize: Can't remove limit (Invalid argument)
Reading symbols for shared libraries ++. done

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x
0x00011807 in f_600 ()
(gdb) bt
#0  0x00011807 in f_600 ()
#1  0x0001376d in snapshot_ret ()
Previous frame inner to this frame (gdb could not unwind past this frame)
(gdb) 


-- 


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

[Bug target/41288] [4.5 Regression] gcc.target/x86_64/abi/test_struct_returning.c regressions on *-apple-darwin* at -m64

[irar at il dot ibm dot com]

--- Comment #9 from irar at il dot ibm dot com  2009-09-08 05:51 ---
Looks related to PR 39907.


-- 


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

[Bug debug/41291] [4.5 regression] verify_ssa failed for debug insn

[laurent at guerby dot net]

--- Comment #4 from laurent at guerby dot net  2009-09-08 06:13 ---
I see it on arm-linux too. It ICEs at -O1 and -O2 but works at -O0.

a-direct.adb: In function 'Ada.Directories.Start_Search':
a-direct.adb:1178:4: error: expected an SSA_NAME object
a-direct.adb:1178:4: error: in statement
# DEBUG ada__directories__start_search__TTS840bSP1___L => L839b
+===GNAT BUG DETECTED======+
| 4.5.0 20090907 (experimental) [trunk revision 151474]
(armv5tel-unknown-linux-gnueabi) GCC error:|
| verify_ssa failed|
| Error detected around a-direct.adb:1178:4|


-- 

laurent at guerby dot net changed:

   What|Removed |Added

 CC||laurent at guerby dot net


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

[Bug middle-end/41289] [4.5 Regression] ICE verify_ssa failed building libavformat/oggparseogm.c

[t66667 at gmail dot com]

--- Comment #8 from t7 at gmail dot com  2009-09-08 06:24 ---
ccache x86_64-w64-mingw32-gcc -DHAVE_AV_CONFIG_H -I.
-I"/home/slack/vlc/x86_64/ffmpeg"
-I/home/slack/local/xmingw-4.5-trunk-w64-sjlj/x86_64-w64-mingw32/include/directx
-I/home/slack/local/k8-sse3-master/w64-xmingw-4.5-trunk-w64-sjlj/include
-I/home/slack/local/k8-sse3-master/w64-xmingw-4.5-trunk-w64-sjlj/include/freetype2
-DPTW32_STATIC_LIB -D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200112
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -DPTW32_STATIC_LIB -pipe 
-static-libgcc
-I/home/slack/local/k8-sse3-master/w64-xmingw-4.5-trunk-w64-sjlj/include
-march=k8 -std=c99 -fno-common -fomit-frame-pointer
-I/home/slack/local/k8-sse3-master/w64-xmingw-4.5-trunk-w64-sjlj/include/schroedinger-1.0
-I/home/slack/local/k8-sse3-master/w64-xmingw-4.5-trunk-w64-sjlj/include/liboil-0.3
-g3 -Wdeclaration-after-statement -Wall -Wno-switch -Wdisabled-optimization
-Wpointer-arith -Wredundant-decls -Wno-pointer-sign -Wcast-qual -Wwrite-strings
-Wtype-limits -Wundef -O3 -fno-math-errno -fno-signed-zeros -fno-tree-vectorize
-MMD -MF libavformat/oggparseogm.d -MT libavformat/oggparseogm.o -c
-save-temps -o libavformat/oggparseogm.o libavformat/oggparseogm.c
libavformat/oggparseogm.c: In function 'ogm_header':
libavformat/oggparseogm.c:34:1: error: expected an SSA_NAME object
libavformat/oggparseogm.c:34:1: error: in statement
# DEBUG default_len => ((const struct unaligned_32 *) p + -4)->l
libavformat/oggparseogm.c:34:1: internal compiler error: verify_ssa failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[1]: *** [libavformat/oggparseogm.o] Error 1
make[1]: Leaving directory `/home/slack/vlc/x86_64/ffmpeg'


-- 


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

[Bug target/41288] [4.5 Regression] gcc.target/x86_64/abi/test_struct_returning.c regressions on *-apple-darwin* at -m64

[ubizjak at gmail dot com]

--- Comment #10 from ubizjak at gmail dot com  2009-09-08 06:56 ---
What happens if you change either of these to movups:

+   movaps  LC4(%rip), %xmm0
+   movaps  %xmm0, -24(%rsp)

My bet is on the second one, -24(%rsp) is not 16byte aligned.


-- 


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