[Bug bootstrap/39150] Configure scripts have no 64-Bit Solaris defined (only i386-solaris*).

[rob1weld at aol dot com]

--- Comment #3 from rob1weld at aol dot com  2009-02-13 08:36 ---
Here is another person who makes the same complaint (with a patch):
http://hackage.haskell.org/trac/ghc/ticket/2951


-- 


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

[Bug middle-end/39157] Code that compiles fine in 1GB of memory with 4.1.2 requires > 20GB in 4.2.* and higher

[jakub at gcc dot gnu dot org]

--- Comment #21 from jakub at gcc dot gnu dot org  2009-02-13 09:17 ---
To answer 2), I bet fwprop would suffer the same problem, but fwprop is
disabled at -O1, LICM is not.  I can try it today.


-- 


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

[Bug bootstrap/39150] Configure scripts have no 64-Bit Solaris defined (only i386-solaris*).

[rob1weld at aol dot com]

--- Comment #4 from rob1weld at aol dot com  2009-02-13 09:11 ---
Googling for "amd64-pc-solaris2.11" gives a few hits.
Googling for "x86_64-pc-solaris2.11" gives a dozen hits.
That is not many. Perhaps there is 'no such word'.


It seems there are a few others who discovered this problem:

http://osdir.com/ml/linux.debian.devel.dpkg.bugs/2006-04/msg00106.html
http://gcc.gnu.org/ml/gcc/2004-12/msg00461.html
http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?msg=47;bug=1191


Rob


-- 


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

[Bug target/39175] New: ICE while compiling qt-4.5.0-rc1

[jakub at gcc dot gnu dot org]

/* { dg-options "-O2 -m32 -fvisibility=hidden -msecure-plt -fpic" } */

__attribute__((noinline)) int
foo (int x)
{
  return x;
}

int foo (int x);

int
bar (int x)
{
  return foo (x);
}

ICEs on the
  if (DEFAULT_ABI == ABI_V4 && flag_pic)
{
  gcc_assert (!TARGET_SECURE_PLT);
  return \"b %...@plt\";
}
  else
return \"b %z1\";
assertion in sibcall_value_nonlocal_sysv.


-- 
   Summary: ICE while compiling qt-4.5.0-rc1
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
GCC target triplet: powerpc-linux


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

[Bug target/38134] [4.4 Regression] speed regression with many loop invariants

[bonzini at gnu dot org]

--- Comment #14 from bonzini at gnu dot org  2009-02-13 09:57 ---
It seems to me that it would help to have a postreload LIM pass that would
concentrate on loop-invariant memory accesses that are as cheap or cheaper than
loading back a spill.  These would be excluded from the current (non-strict)
LIM.  Is it crazy?


-- 


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

[Bug target/38134] [4.4 Regression] speed regression with many loop invariants

[steven at gcc dot gnu dot org]

--- Comment #15 from steven at gcc dot gnu dot org  2009-02-13 10:03 ---
Re. Comment #14

No, this is not crazy.  It is called postreload-gcse.  But it is a stupid pass
that doesn't handle all cases it ought to handle.


-- 


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

[Bug fortran/39171] Misleading warning for negative character length

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2009-02-13 10:34 ---
For completeness, the F2003 standard has in "4.4.4 Character type"

"The length is a type parameter; its value is greater than or equal to zero." 

and later

"If the character length parameter value evaluates to a negative value, the
length of character entities declared is zero."

Thus len=-1  is valid and equivalent to len=0.

The warning is OK in my opinion as I cannot see any reason why one would like
to have it negative at compile-time (init expression). (Maybe generated
code/preprocessor expressions, but even then a warning might be helpful.)
Whether the warning should be on by default or only with -W... is another
question.


-- 


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

[Bug target/39175] ICE while compiling qt-4.5.0-rc1

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2009-02-13 10:36 ---
The problem is in the redundant prototype after function.
First the foo FUNCTION_DECL is created, afterwards finish_function calls
c_determine_visibility on it which changes its visibility from default to
hidden.
After this make_decl_rtl is called, determines the function binds locally and
sets SYMBOL_FLAG_LOCAL|SYMBOL_FLAG_FUNCTION.  Then merge_decls is called, which
in turn clears visibility (sets it back to default) and calls make_decl_rtl to
update the flags.  At this point targetm.binds_local_p returns false, as it at
that point has default visibility, so changes DECL_RTL's flags to
SYMBOL_FLAG_FUNCTION alone.  Then finish_decl calls c_determine_visibility
again and sets it back to hidden visibility.  But nothing afterwards calls
make_decl_rtl again to update the symbol flags again.

To fix this, IMHO either c_determine_visibility and C++ determine_visibility
need to
if (((TREE_CODE (decl) == VAR_DECL && TREE_STATIC (decl))
 || TREE_CODE (decl) == FUNCTION_DECL)
&& DECL_RTL_SET_P (decl))
  make_decl_rtl (decl);
if it changed the visibility, or merge_decls/duplicate_decls would need to
determine visibility.  I'll try the former.


-- 


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

[Bug middle-end/39157] Code that compiles fine in 1GB of memory with 4.1.2 requires > 20GB in 4.2.* and higher

[rguenther at suse dot de]

--- Comment #22 from rguenther at suse dot de  2009-02-13 11:06 ---
Subject: Re:  Code that compiles fine in 1GB of memory
 with 4.1.2 requires > 20GB in 4.2.* and higher

On Thu, 12 Feb 2009, lucier at math dot purdue dot edu wrote:

> --- Comment #19 from lucier at math dot purdue dot edu  2009-02-12 20:51 
> ---
> Subject: Re:  Code that compiles fine in 1GB of
>  memory with 4.1.2 requires > 20GB in 4.2.* and higher
> 
> On Thu, 2009-02-12 at 16:52 +, rguenth at gcc dot gnu dot org wrote:
> > --- Comment #16 from rguenth at gcc dot gnu dot org  2009-02-12 16:52 
> > ---
> > Actually for PR26854 it is just one loop that is detected, covering all of
> > the function (with approx. 56000 basic blocks and one basic-block that has
> > edges to all other basic blocks in the loop).
> 
> Richard:
> 
> I'm wondering if you could look at a smaller file that's generated in a
> somewhat different way.
> 
> At
> 
> http://www.math.purdue.edu/~lucier/bugzilla/8/
> 
> there's a file _num.i.gz that I think should have smaller (nested) loops
> than the entire file, for example, from the label
> 
> ___L189__23__23_bignum_2e__2a_:
> 
> at line 50031 to just before label
> 
> ___L190__23__23_bignum_2e__2a_:
> 
> at line 50105.
> 
> Moving loop invariants out of this loop might help if it detected as a
> loop, but I don't know how to check whether it is.
> 
> Perhaps you might check and report whether this small loop is treated as
> a loop or whether, again, the entire function is the only "loop"
> detected.

Yes, there are several small loops detected for this testcase (139 in
total, including one large with the computed goto).

Btw, thanks for the smaller testcase.

Richard.


-- 


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

[Bug middle-end/39157] Code that compiles fine in 1GB of memory with 4.1.2 requires > 20GB in 4.2.* and higher

[rguenth at gcc dot gnu dot org]

--- Comment #23 from rguenth at gcc dot gnu dot org  2009-02-13 11:08 
---
Lemme close this bug as a dup of the one marked as regression.

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


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


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

[Bug tree-optimization/26854] [4.3/4.4 Regression] Inordinate compile times on large routines

[rguenth at gcc dot gnu dot org]

--- Comment #85 from rguenth at gcc dot gnu dot org  2009-02-13 11:08 
---
*** Bug 39157 has been marked as a duplicate of this bug. ***


-- 


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

[Bug libstdc++/39168] Incorrect interpretation of CHAR_MAX inside grouping string in monetary and numeric facets.

[tsyvarev at ispras dot ru]

--- Comment #7 from tsyvarev at ispras dot ru  2009-02-13 11:21 ---
(In reply to comment #4)
> 
> I'm not sure I understand your rationale or I agree that this is a bug. IIUC,
> string(1, CHAR_MAX) indicates that groups may be of arbitrary length, which
> includes "123,456" This behavior is the same regardless of whether char is
> a signed or unsigned type.

"Arbitrary length" is not quite correct here - "123,456" violates grouping,
given with string(1, CHAR_MAX). Standard use term "unlimited length", which
means(as I understand) that all other digits should incorporate in only one
group - only "123456" is correct.

(In reply to comment #6)
>Actually, libstdc++ stores 123456, which is indeed fine, and sets failbit |
>eofbit, failbit exactly because of the issue discussed here.

The thing is that, according to the standard, CHAR_MAX should be treats similar
as -1. But implementation treats string(1, -1) as no grouping at all, and stops
read, when has encountered symbol ','. So only "123" is accumulated.
This behaviour seems correct for me (though standard treats only string() as no
grouping at all, 22.2.2.1.2, p8).
So with string(1, CHAR_MAX) only "123" should be accumulated, not "123,456".

In other words, test is passed when CHAR_MAX is replaced with -1. Inside
grouping string, CHAR_MAX means same as -1(according to the standard). So test
should be passed with original text.

The same is about the second test.


-- 


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

[Bug libstdc++/39168] Incorrect interpretation of CHAR_MAX inside grouping string in monetary and numeric facets.

[paolo dot carlini at oracle dot com]

--- Comment #8 from paolo dot carlini at oracle dot com  2009-02-13 11:31 
---
(In reply to comment #7)
  Standard use term "unlimited length", which
> means(as I understand) that all other digits should incorporate in only one
> group - only "123456" is correct.

I don't read that anywhere in the Standard.

> The thing is that, according to the standard, CHAR_MAX should be treats 
> similar
> as -1. But implementation treats string(1, -1) as no grouping at all, and 
> stops
> read, when has encountered symbol ','. So only "123" is accumulated.
> This behaviour seems correct for me (though standard treats only string() as 
> no
> grouping at all, 22.2.2.1.2, p8).
> So with string(1, CHAR_MAX) only "123" should be accumulated, not "123,456".

No, no, it is not correct, it is a bug in the current implementation. See where
bool discard is defined, in Stage 2. (1, -1) (or (1, CHAR_MAX)) are not
special, are normal groupings, that must be enforced.


-- 


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

[Bug target/39175] ICE while compiling qt-4.5.0-rc1

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2009-02-13 11:33 ---
Created an attachment (id=17292)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17292&action=view)
gcc44-pr39175.patch

Patch I'm going to bootstrap/regtest.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug libstdc++/39168] Incorrect interpretation of CHAR_MAX inside grouping string in monetary and numeric facets.

[paolo dot carlini at oracle dot com]

--- Comment #9 from paolo dot carlini at oracle dot com  2009-02-13 11:39 
---
In other terms, as usual about those matters, Martin is right ;) Only he has
got a wrong data point about libstdc++, he believes we are setting eofbit.

Thanks anyway for pointing our attention to this CHAR_MAX issue, I'm going to
fix it together with the bool discard thing (and its consequences).


-- 


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

[Bug libfortran/39176] New: [4.4 Regression] -static and -fopenmp and io causes segfault

[jv244 at cam dot ac dot uk]

I noticed this running mixed mpi/openmp on a system that required an executable
without dynamics libraries. Don't know if the Fortran IO is supposed to be
thread safe (i.e. serialized thread safe), but this seems to work without
-static. It also appears to work with 4.3.1 but not 4.4 (trunk)

> cat test.f90
!$OMP PARALLEL
!$OMP CRITICAL
 write(6,*) "Hello world"
!$OMP END CRITICAL
!$OMP END PARALLEL
 write(6,*) "Done!"
END

> gfortran -static -fopenmp test.f90
> ./a.out
Segmentation fault
> gdb ./a.out
GNU gdb 6.4
Copyright 2005 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-suse-linux"...Using host libthread_db
library"/lib64/libthread_db.so.1".

(gdb) run
Starting program: /data/vondele/omptest/a.out

Program received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) bt
#0  0x in ?? ()
#1  0x0040642f in get_external_unit (n=6, do_create=1)
at /data/vondele/gcc_trunk/gcc/libgfortran/../gcc/gthr-posix.h:704
#2  0x00404c01 in data_transfer_init (dtp=0x7fff047208c0, read_flag=0)
at /data/vondele/gcc_trunk/gcc/libgfortran/io/transfer.c:1828
#3  0x004003d6 in MAIN__.omp_fn.0 ()
#4  0x0040032c in MAIN__ ()
#5  0x0040042c in main (argc=1, argv=0x7fff04720fa8)
at /data/vondele/gcc_trunk/gcc/libgfortran/fmain.c:21
(gdb)


-- 
   Summary: [4.4 Regression] -static and -fopenmp and io causes
segfault
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug libfortran/39176] [4.4 Regression] -static and -fopenmp and io causes segfault

[jv244 at cam dot ac dot uk]

--- Comment #1 from jv244 at cam dot ac dot uk  2009-02-13 11:42 ---
adding Jakub


-- 

jv244 at cam dot ac dot uk changed:

   What|Removed |Added

 CC||jakub at redhat dot com
  Known to fail||4.4.0
  Known to work||4.3.1


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

[Bug libfortran/39176] [4.4 Regression] -static and -fopenmp and io causes segfault

[jv244 at cam dot ac dot uk]

-- 

jv244 at cam dot ac dot uk changed:

   What|Removed |Added

   Target Milestone|--- |4.4.0


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

[Bug libfortran/39176] [4.4 Regression] -static and -fopenmp and io causes segfault

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2009-02-13 11:50 ---
This has been repeated many times.  Don't use -static for threaded programs, it
is really bad idea, and if you really have to, you need to link the whole
libpthread.a in (-Wl,--whole-archive -lpthread -Wl,--no-whole-archive),
otherwise if it works, it is by pure luck.
This certainly isn't a regression.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID
   Target Milestone|4.4.0   |---


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

[Bug libfortran/39176] [4.4 Regression] -static and -fopenmp and io causes segfault

[jv244 at cam dot ac dot uk]

--- Comment #3 from jv244 at cam dot ac dot uk  2009-02-13 12:19 ---
(In reply to comment #2)
> This has been repeated many times.  Don't use -static for threaded programs, 
> it
> is really bad idea, and if you really have to, you need to link the whole
> libpthread.a in (-Wl,--whole-archive -lpthread -Wl,--no-whole-archive),
> otherwise if it works, it is by pure luck.
> This certainly isn't a regression.
> 

Thanks for your reply, this was unknown to me, and I think for many occassional
omp users. Do you think this could be documented near the -fopenmp flag (I can
write something if you wish). Or could one have gcc warn if both -fopenmp and
-static are present ?


-- 


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

[Bug libfortran/39176] [4.4 Regression] -static and -fopenmp and io causes segfault

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2009-02-13 12:35 ---
It is glibc specific, on the other hand it isn't particularly -fopenmp related.
I guess easiest will be if glibc stops shipping libpthread.a.


-- 


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

[Bug target/39175] ICE while compiling qt-4.5.0-rc1

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-02-13 12:44 ---
This also ICEs on the 4.3 branch.


-- 


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

[Bug fortran/36703] ICE (segfault) in reduce_binary0 (arith.c:1778)

[pault at gcc dot gnu dot org]

--- Comment #3 from pault at gcc dot gnu dot org  2009-02-13 12:53 ---
The patch for 36703 also fixes this fellow.

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|2009-02-12 09:19:21 |2009-02-13 12:53:35
   date||


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

[Bug c/35444] [4.2/4.3/4.4 regression] ICE with invalid function declaration

[jsm28 at gcc dot gnu dot org]

--- Comment #4 from jsm28 at gcc dot gnu dot org  2009-02-13 13:11 ---
Subject: Bug 35444

Author: jsm28
Date: Fri Feb 13 13:10:52 2009
New Revision: 144155

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144155
Log:
PR c/35444
* c-parser.c (c_parser_parms_list_declarator): Discard pending
sizes on syntax error after some arguments have been parsed.

testsuite:
* gcc.dg/noncompile/pr35444-1.c, gcc.dg/noncompile/pr35444-2.c:
New tests.

Added:
branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/noncompile/pr35444-1.c
branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/noncompile/pr35444-2.c
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/c-parser.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug c/35444] [4.2 regression] ICE with invalid function declaration

[jsm28 at gcc dot gnu dot org]

--- Comment #5 from jsm28 at gcc dot gnu dot org  2009-02-13 13:12 ---
Fixed for 4.4.0 and 4.3.4.  Not planning to work on a backport to 4.2.


-- 

jsm28 at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|jsm28 at gcc dot gnu dot org|unassigned at gcc dot gnu
   ||dot org
 Status|ASSIGNED|NEW
  Known to fail||4.2.4 4.3.3
  Known to work||4.3.4 4.4.0
Summary|[4.2/4.3/4.4 regression] ICE|[4.2 regression] ICE with
   |with invalid function   |invalid function declaration
   |declaration |


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

[Bug libstdc++/39168] Incorrect interpretation of CHAR_MAX inside grouping string in monetary and numeric facets.

[tsyvarev at ispras dot ru]

--- Comment #10 from tsyvarev at ispras dot ru  2009-02-13 13:41 ---
(In reply to comment #8)
> (In reply to comment #7)
>   Standard use term "unlimited length", which
> > means(as I understand) that all other digits should incorporate in only one
> > group - only "123456" is correct.
> 
> I don't read that anywhere in the Standard.

Could you clarify this a bit?
Do you mean that when reading "123,456" with string(1, -1), failbit shouldn't
be set?


-- 


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

[Bug libstdc++/39168] Incorrect interpretation of CHAR_MAX inside grouping string in monetary and numeric facets.

[paolo dot carlini at oracle dot com]

--- Comment #11 from paolo dot carlini at oracle dot com  2009-02-13 13:43 
---
(In reply to comment #10)
> Do you mean that when reading "123,456" with string(1, -1), failbit shouldn't
> be set?

Right, as Martin said. 


-- 


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

[Bug libgomp/39176] -static and -fopenmp and io causes segfault

[jv244 at cam dot ac dot uk]

--- Comment #5 from jv244 at cam dot ac dot uk  2009-02-13 14:01 ---
(In reply to comment #4)
> It is glibc specific, on the other hand it isn't particularly -fopenmp 
> related.
> I guess easiest will be if glibc stops shipping libpthread.a.

but if -fopenmp automatically adds -lpthread maybe it should do it in the
'proper' way if -static is also on the command line (eventually bailing out if
libpthread.a can not be found)? 

Note, e.g. a warning is produced for similar issues already, e.g. I see:

/home/u1/vondele/gcc_trunk/build/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.0/../../../../lib64/libgfortran.a(getlog.o):
In function `_gfortran_getlog':
/home/u1/vondele/gcc_trunk/gcc/libgfortran/intrinsics/getlog.c:82: warning:
Using 'getpwuid' in statically linked applications requires at runtime the
shared libraries from the glibc version used for linking

let me reopen the bug, removing the regression marker, and as an enhancement. I
think that a warning, or adding -lpthread in the 'proper' way if -static will
save many other users from loosing time on this one.


-- 

jv244 at cam dot ac dot uk changed:

   What|Removed |Added

   Severity|normal  |enhancement
 Status|RESOLVED|UNCONFIRMED
  Component|libfortran  |libgomp
 Resolution|INVALID |
Summary|[4.4 Regression] -static and|-static and -fopenmp and io
   |-fopenmp and io causes  |causes segfault
   |segfault|


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

[Bug target/39162] Gcc doesn't warn __m256 when -mavx isn't used

[hjl at gcc dot gnu dot org]

--- Comment #3 from hjl at gcc dot gnu dot org  2009-02-13 14:34 ---
Subject: Bug 39162

Author: hjl
Date: Fri Feb 13 14:34:00 2009
New Revision: 144157

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

2009-02-13  H.J. Lu  

PR target/39162
* config/i386/i386.c (type_natural_mode): Add a new argument.
Return the original mode and warn ABI change if vector size
is 32byte.
(function_arg_advance): Updated.
(function_arg): Likewise.
(ix86_function_value): Likewise.
(ix86_return_in_memory): Likewise.
(ix86_sol10_return_in_memory): Likewise.
(ix86_gimplify_va_arg): Likewise.
(function_arg_32): Don't warn ABX ABI change here.
(function_arg_64): Likewise.

gcc/testsuite/

2009-02-13  H.J. Lu  

PR target/39162
* gcc.target/i386/pr39162.c: New.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr39162.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug target/39152] [4.4 regression] Revision 144098 breaks 416.gamess in SPEC CPU 2006

[hjl at gcc dot gnu dot org]

--- Comment #21 from hjl at gcc dot gnu dot org  2009-02-13 14:37 ---
Subject: Bug 39152

Author: hjl
Date: Fri Feb 13 14:37:11 2009
New Revision: 144158

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

2009-02-13  H.J. Lu  

PR target/39152
* config/i386/i386.md: Restrict the new peephole2 to move
between the general purpose registers.

gcc/testsuite/

2009-02-13  H.J. Lu  

PR target/39152
* gfortran.dg/gomp/pr39152.f90: New.

Added:
trunk/gcc/testsuite/gfortran.dg/gomp/pr39152.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/39178] New: Generate main() rather than using a main in libgfortran/fmain.c

[burnus at gcc dot gnu dot org]

Topic brought up on #gfortran by Janne.

There are some potential issues in using main.c in a library; thus one should
have only link a "main()" if the *.o files don't have a "main".

See also:
http://groups.google.com/group/comp.os.linux.development.apps/browse_thread/thread/e35b2224a7dc27bf/
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/7d483c59db0bb6f/


The solution of SUN is to generate for PROGRAM not only a "MAIN_" but also a
main() which does the initialization and calls then MAIN_. ("MAIN_" should be
present for backward compatibility.)

I think we could do likewise, especially as the code is rather short
(libgfortran/fmain.c):

main (int argc, char *argv[]) {
  store_exe_path (argv[0]);
  set_args (argc, argv);
  MAIN__ (); /* The Fortran PROGRAM */
  return 0;
}

Intel's solution is to link "for_main-o", but that is not as elegant as for
"ifort *.o" one needs to specify "-nofor-main" if there is a non-fortran C
library.

 * * *

Independent of all, I think one should document the gfortran_init() functions
to make the full library functions available even if the "main()" program is
written in C. Besides
  store_exe_path (argv[0]);
  set_args (argc, argv);
(which should be combined to one function) one also has
  _gfortran_set_options()

 * * *

Marked as depending on the array descriptor stuff as with the ABI break one can
get also rid of fmain.c's main(). It might also help with -fwhole-program (cf.
PR fortran/26682) as a "main()" shouldn't be optimized away ;-)


-- 
   Summary: Generate main() rather than using a main in
libgfortran/fmain.c
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
 BugsThisDependsOn: 36825


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

[Bug fortran/39178] Generate main() rather than using a main in libgfortran/fmain.c

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2009-02-13 14:57 ---
s/MAIN_/MAIN__/g

 * * *

> Intel's solution is to link "for_main-o", but that is not as elegant as for
> "ifort *.o" one needs to specify "-nofor-main" if there is a non-fortran C

The last line should read: 'if there is a non-fortran "main()"'.

  * * *

Regarding MAIN__:
- gdb assumes that this is the main function for Fortran programs; as gfortran
now sets "main_program_symbol" this might be not an issue.
- For stepping through the code, having a separate MAIN_ avoids that the user
enters libgfortran for the initialization, which can be a bit confusing.


-- 


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

[Bug libstdc++/39168] Incorrect interpretation of CHAR_MAX inside grouping string in monetary and numeric facets.

[tsyvarev at ispras dot ru]

--- Comment #12 from tsyvarev at ispras dot ru  2009-02-13 15:04 ---
Let's consider the following situation (seems lifelike to me). Suppose one
needs a representation of numbers in which only the last 3 digits are separated
from all other digits (grouped), like "1234,567" or "1234567,890". Other
separators shouldn't appear.

Grouping string "\003" doesn't fit for this purpose as it separates all
3-digits groups: "1,234,567".
Before this PR, I thought that "\003\177" is sufficient for this purpose. But,
as I understand now, the representations like "12,34,567" are acceptable in
this case, which is not what I would like to have.

Could you suggest which grouping string should be used to do such number
representation? Or is this unachievable?

I investigated locale support in POSIX, such number representation is achieved
there with "\003\177". It seems strange for me that similar mechanism is not
work with C++ locales.


-- 


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

[Bug libstdc++/39168] Incorrect interpretation of CHAR_MAX inside grouping string in monetary and numeric facets.

[paolo dot carlini at oracle dot com]

--- Comment #13 from paolo dot carlini at oracle dot com  2009-02-13 15:11 
---
(In reply to comment #12)
> Could you suggest which grouping string should be used to do such number
> representation? Or is this unachievable?

Actually \003\176 seems perfectly practical to me. In particular considering
the actual size of real numbers.

> I investigated locale support in POSIX, such number representation is achieved
> there with "\003\177". It seems strange for me that similar mechanism is not
> work with C++ locales.

POSIX seems a good point, probably you should have mentioned it much earlier.
Let's hear Martin again, then. Certainly, however, I'm concerned about having a
behavior different from all the other implementations mentioned by Martin.


-- 


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

[Bug fortran/39178] Generate main() rather than using a main in libgfortran/fmain.c

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2009-02-13 15:11 ---
Note: Moving main() to f951 will break programs which assume that MAIN__ will
be called, compile e.g. the following program with gcc:
---
#include 
int MAIN__( int argc, char* argv[] )
{printf("argc is %i:0 %s\n", argc,argv[0]);
 printf("argc is %i:1 %s\n", argc,argv[1]);
return(0);}
---
and link it with gfortran. If you run it, MAIN__ will be executed and by some
magic the arguments are passed to MAIN__.  (That the arguments are available is
a complete puzzle to me.) -- Found in c.l.f thread linked above.


-- 


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

[Bug libstdc++/39168] Incorrect interpretation of CHAR_MAX inside grouping string in monetary and numeric facets.

[paolo dot carlini at oracle dot com]

--- Comment #14 from paolo dot carlini at oracle dot com  2009-02-13 15:21 
---
If I understand correctly, in order to implement the POSIX behavior for C++,
assuming we want it, the Standard should be clarified to explain that values <=
0 or CHAR_MAX are different in that do no admit repetitions, thus saying
explicitly that such group is effectively the last, arbitrarily long, one.

I must say, that is what we would do when formatting anyway.


-- 


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

[Bug tree-optimization/36054] bad code generation with -ftree-vectorize

[d dot g dot gorbachev at gmail dot com]

--- Comment #21 from d dot g dot gorbachev at gmail dot com  2009-02-13 
15:25 ---
Created an attachment (id=17293)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17293&action=view)
precompiled source

The same issue with GCC 4.3.3 (i686-pc-linux-gnu).

C source:
http://svn.savannah.gnu.org/viewvc/*checkout*/trunk/kqemu.c?root=qemu&revision=6338&content-type=text%2Fplain

cc1 -O3 -march=pentium4 kqemu.c

Offending asm code:

kqemu_cpu_exec:
...
movl8(%ebp), %ebx
...
.L96:
movdqa  (%ebx), %xmm0  // segmentation fault


-- 


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

[Bug libstdc++/39168] Incorrect interpretation of CHAR_MAX inside grouping string in monetary and numeric facets.

[tsyvarev at ispras dot ru]

--- Comment #15 from tsyvarev at ispras dot ru  2009-02-13 15:38 ---
(In reply to comment #14)
> If I understand correctly, in order to implement the POSIX behavior for C++,
> assuming we want it, the Standard should be clarified to explain that values 
> <=
> 0 or CHAR_MAX are different in that do no admit repetitions, thus saying
> explicitly that such group is effectively the last, arbitrarily long, one.

Yes, I meen exactly this.
Also, current implementation follows this strategy - accroding to the tests,
and according to it's source code.

So it is strange for me, that the standard for num_get<>::do_get() say, that
only string() is indicator of no grouping at all.
While string(1,-1) and string(1,CHAR_MAX) also force number representation to
have only one group.


-- 


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

[Bug tree-optimization/26854] [4.3/4.4 Regression] Inordinate compile times on large routines

[lucier at math dot purdue dot edu]

--- Comment #86 from lucier at math dot purdue dot edu  2009-02-13 15:40 
---
Subject: Re:  [4.3/4.4 Regression] Inordinate
 compile times on large routines

It's unfortunate that the discussion from 39157 will be somewhat hard to
find now that that bug is closed.

Steven wrote in a comment for 39157:

It's not like there will not be any loop invariant code motion
(LICM) at all anymore if the RTL LICM pass is disabled.  There
is an LICM pass on GIMPLE, and there is also PRE for GIMPLE (and
lazy code motion for RTL but I think it disables itself for your
test case).

The RTL LICM pass mostly cleans up after expand, i.e. moves
things that are not exposed in GIMPLE. This is mostly just
address calculations.


The loop in _num.i that I mentioned in

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39157#c19

is the loop in PR 33928 that is no longer fully optimized after Paolo
(and you, I guess, your name is on the patch) added PRE and disabled
some optimizations in CSE, and what is no longer optimized in that loop
are address calculations.  I don't know whether those address
calculations fall under LICM, the only point I'm trying to make right
now is that address calculations are no longer optimized as much as they
were before 

http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118475

and address calculations are an important class of calculations to
optimize.


-- 


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

[Bug c++/39179] New: Wrong code in c++ for const members initialized in external file

[ktietz at gcc dot gnu dot org]

It seems so that for optimization levels one or higher, gcc produces wrong code
for the two test files below.
If I compile the same test with -O or -Os everything works fine.
On taking a look into produced assembly, it seems that it wrongly assumes the
assert alway have to raise.

File 1: t1.cpp
  //class.h
  struct K {
   static const unsigned k;
  };

  #include 

  int main() {
   assert ( K::k == 1 );
   return 1;
  }

File 2: t2.cpp
  struct K {
   static const unsigned k;
  };

  //class.cpp
  const unsigned K::k = 1;

Then compile both file g++ -o tst t1.cpp t2.cpp -O2


-- 
   Summary: Wrong code in c++ for const members initialized in
external file
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ktietz at gcc dot gnu dot org
GCC target triplet: x86_64-pc-mingw32


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

[Bug libstdc++/39168] Incorrect interpretation of CHAR_MAX inside grouping string in monetary and numeric facets.

[paolo dot carlini at oracle dot com]

--- Comment #16 from paolo dot carlini at oracle dot com  2009-02-13 15:49 
---
(In reply to comment #15)
> (In reply to comment #14)
> > If I understand correctly, in order to implement the POSIX behavior for C++,
> > assuming we want it, the Standard should be clarified to explain that 
> > values <=
> > 0 or CHAR_MAX are different in that do no admit repetitions, thus saying
> > explicitly that such group is effectively the last, arbitrarily long, one.
> 
> Yes, I meen exactly this.
> Also, current implementation follows this strategy - according to the tests,
> and according to it's source code.

Yes, I know that ;) And I also know that implementing the exact behaviour you
want would be trivial and would bring consistency between signed and unsigned
char platforms. Probably we want to implement it anyway in v3, but that doesn't
mean by itself that it's obviously the only meaningful interpretation of the
standard if so many other implementations differ, as pointed out by Martin. 

Thus let's be clear about that with Martin and probably at the same time also
take actions to open a DR for C++0x.


-- 


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

[Bug target/39082] union with long double doesn't follow x86-64 psABI

[hjl dot tools at gmail dot com]

--- Comment #6 from hjl dot tools at gmail dot com  2009-02-13 15:51 ---
I checked gcc 3.4.6. The bug is there.


-- 


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

[Bug libgcj/38685] classmap.db is zero bytes long in 64 bit directory

[rob1weld at aol dot com]

--- Comment #8 from rob1weld at aol dot com  2009-02-13 15:55 ---
In revision 144149 we have this:

# gcc/xgcc -v
Using built-in specs.
Target: i386-pc-solaris2.11
Configured with: ../gcc_trunk/configure --build=i386-pc-solaris2.11
--target=i386-pc-solaris2.11
--enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --enable-shared
--disable-static --enable-multilib --enable-decimal-float
--with-long-double-128 --with-included-gettext --enable-stage1-checking
--enable-checking=release --with-tune=k8 --with-cpu=k8 --with-arch=k8
--with-gnu-as --with-as=/usr/local/bin/as --with-gnu-ld
--with-ld=/usr/local/bin/ld --with-gmp=/usr/local --with-mpfr=/usr/local
--without-ppl
Thread model: posix
gcc version 4.4.0 20090213 (experimental) [trunk revision 144149] (GCC) 


# gmake
...
./gcj-dbtool -n classmap.db || touch classmap.db
/bin/sh: line 1: 20225: Memory fault(coredump)
cp classpath/tools/tools.zip libgcj-tools-4.4.0.jar
[CTRL-C]
#


My fix:

/usr/local/bin/gcj-dbtool -n classmap.db || touch classmap.db


Result:

# ls -lrtA /usr/share/src/gcc_build/i386-pc-solaris2.11/amd64/libjava | tail
-rwxr-xr-x   1 root root4223 Feb 13 07:15 gnative2ascii
-rwxr-xr-x   1 root root4191 Feb 13 07:15 gorbd
-rwxr-xr-x   1 root root4191 Feb 13 07:15 grmid
-rwxr-xr-x   1 root root4211 Feb 13 07:15 gserialver
-rwxr-xr-x   1 root root4211 Feb 13 07:15 gtnameserv
drwxr-xr-x   2 root root  89 Feb 13 07:15 .libs
-rwxr-xr-x   1 root root4221 Feb 13 07:15 gc-analyze
-rw-r--r--   1 root root 1166776 Feb 13 07:15 libgcj-tools-4.4.0.jar
-rw---   1 root root 74276701 Feb 13 07:19 core
-rw-r--r--   1 root root 1441792 Feb 13 07:20 classmap.db


Rob


-- 


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

[Bug target/36222] x86 fails to optimize out __v4si -> __m128i move

[hjl dot tools at gmail dot com]

--- Comment #10 from hjl dot tools at gmail dot com  2009-02-13 15:57 
---
Fixed. Gcc 4.4.0 revision 144128 generates:

foo2:
movd%edi, %xmm0
movd%esi, %xmm1
movd%edx, %xmm2
punpckldq   %xmm0, %xmm1
movd%ecx, %xmm0
punpckldq   %xmm2, %xmm0
punpcklqdq  %xmm1, %xmm0
ret
.size   foo2, .-foo2


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

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


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

[Bug target/30961] [4.2 regression] redundant reg/mem stores/moves

[hjl dot tools at gmail dot com]

--- Comment #37 from hjl dot tools at gmail dot com  2009-02-13 16:00 
---
Gcc 4.4.0 revision 144128 generates:

.globl convert
.type   convert, @function
convert:
movl%edi, -4(%rsp)
movss   -4(%rsp), %xmm0
ret
.size   convert, .-convert
.p2align 4,,15
.globl load
.type   load, @function
load:
movzwl  (%rdi), %eax
ret
.size   load, .-load


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

  Known to work|3.4.6 4.3.0 |3.4.6 4.3.0 4.4.0


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

[Bug tree-optimization/33928] [4.3/4.4 Regression] 30% performance slowdown in floating-point code caused by r118475

[bonzini at gnu dot org]

--- Comment #44 from bonzini at gnu dot org  2009-02-13 16:05 ---
A simplified (local, noncascading) fwprop not using UD chains would not be hard
to do...  Basically, at -O1 use FOR_EACH_BB/FOR_EACH_BB_INSN instead of walking
the uses, keep a (regno, insn) map of pseudos (cleared at the beginning of
every basic block), and use that info instead of UD chains in
use_killed_between...


-- 


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

[Bug tree-optimization/33928] [4.3/4.4 Regression] 30% performance slowdown in floating-point code caused by r118475

[lucier at math dot purdue dot edu]

--- Comment #45 from lucier at math dot purdue dot edu  2009-02-13 16:09 
---
Subject: Re:  [4.3/4.4 Regression] 30%
 performance slowdown in floating-point code caused by  r118475

On Fri, 2009-02-13 at 16:05 +, bonzini at gnu dot org wrote:
> --- Comment #44 from bonzini at gnu dot org  2009-02-13 16:05 ---
> A simplified (local, noncascading) fwprop not using UD chains would not be 
> hard
> to do...  Basically, at -O1 use FOR_EACH_BB/FOR_EACH_BB_INSN instead of 
> walking
> the uses, keep a (regno, insn) map of pseudos (cleared at the beginning of
> every basic block), and use that info instead of UD chains in
> use_killed_between...

As noted in comment 42, enabling FWPROP on this test case does not fix
the performance problem.


-- 


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

[Bug tree-optimization/33928] [4.3/4.4 Regression] 30% performance slowdown in floating-point code caused by r118475

[bonzini at gnu dot org]

--- Comment #46 from bonzini at gnu dot org  2009-02-13 16:32 ---
Regarding your comment in bug 26854:

> address calculations are no longer optimized as much as they
> were before 

Sometimes, actually, they are optimized better.  It depends on the case.

In comment #42, also, you talked about -O1, where fwprop is not enabled.  So
I'm failing to understand if the problem is at the tree or RTL level for this
bug.

My comment was related to something said in PR39517, i.e. that chains are very
expensive and a reason why fwprop should not be enabled at -O1.  Following up
on my comment, alternatively, fwprop could compute its own dataflow instead of
using UD chains, since it only cares by design about uses with a single
definition.  This looks much better.

You would use something like df_chain_create_bb and
df_chain_create_bb_process_use, with code like the following (cfr.
df_chain_create_bb_process_use):

  /* Do not want to go through this for an uninitialized var.  */
  int count = DF_DEFS_COUNT (regno);
  if (count)
{
  if (top_flag == (DF_REF_FLAGS (use) & DF_REF_AT_TOP))
{
  unsigned int first_index = DF_DEFS_BEGIN (uregno);
  unsigned int last_index = first_index + count - 1;

  /* Uninitialized?  Exit.  */
  bmp_iter_set_init (&bi, local_rd, first_index, &def_index);
  if (!bmp_iter_set (&bi, &def_index) || def_index >
last_index)
continue;

  /* 2 or more defs for this use, exit.  */
  bmp_iter_next (&(ITER), &(BITNUM)))
  if (!bmp_iter_set (&bi, &def_index) || def_index >
last_index)
SET_BIT (can_fwprop, DF_REF_ID (use));
}
}

With this change there would be no reason not to run fwprop at -O1.


-- 


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

[Bug target/39082] union with long double doesn't follow x86-64 psABI

[mmitchel at gcc dot gnu dot org]

--- Comment #7 from mmitchel at gcc dot gnu dot org  2009-02-13 16:41 
---
In that case, this isn't a high-priority bug.  That doesn't mean that it can't
be fixed before 4.4; that's up to the x86 maintainers.  But, it shouldn't block
the release.


-- 

mmitchel at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P5


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

[Bug libgcj/39180] New: New String constructors need to be implemented in local copy of java.lang.String

[gnu_andrew at member dot fsf dot org]

http://builder.classpath.org/japi/classpath-libgcj.html#err_missing_java_lang

Classpath now has two new constructors from 1.6 that take a
java.nio.charset.Charset.  We need to provide these in gcj too.


-- 
   Summary: New String constructors need to be implemented in local
copy of java.lang.String
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gnu_andrew at member dot fsf dot org


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

[Bug tree-optimization/26854] [4.3/4.4 Regression] Inordinate compile times on large routines

[bonzini at gnu dot org]

--- Comment #87 from bonzini at gnu dot org  2009-02-13 16:54 ---
Subject: Re:  [4.3/4.4 Regression] Inordinate
 compile times on large routines

> It's unfortunate that the discussion from 39157 will be somewhat hard to
> find now that that bug is closed.

Well, the patch there is not lost, I suppose Jakub will finish it and
post it.

The problem is that -O1 was never meant to give "very fast" code.  You
are using it only because our throttling of expensive passes is
insufficient.  Fixing that has two sides, as done in PR39157's
discussion: 1) disabling more passes at -O1, 2) establishing some
parameters to throttle down passes at -O2.

Ultimately, the goal should be that you can use -O2.

Paolo


-- 


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

[Bug target/39162] Gcc doesn't warn __m256 when -mavx isn't used

[hjl dot tools at gmail dot com]

--- Comment #4 from hjl dot tools at gmail dot com  2009-02-13 16:58 ---
Fixed.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/26854] [4.3/4.4 Regression] Inordinate compile times on large routines

[jakub at gcc dot gnu dot org]

--- Comment #88 from jakub at gcc dot gnu dot org  2009-02-13 17:06 ---
The patch in PR39157 is IMHO finished and has been bootstrapped/regtested on
x86_64-linux and i686-linux.  I haven't posted it looked like Richard, Zdenek
and Steven prefer some other solution for it.  If this isn't solved for 4.4
soon, I'm going to post that patch.


-- 


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

[Bug tree-optimization/33928] [4.3/4.4 Regression] 30% performance slowdown in floating-point code caused by r118475

[lucier at math dot purdue dot edu]

--- Comment #47 from lucier at math dot purdue dot edu  2009-02-13 17:22 
---
Subject: Re:  [4.3/4.4 Regression] 30%
 performance slowdown in floating-point code caused by  r118475

On Fri, 2009-02-13 at 16:32 +, bonzini at gnu dot org wrote:
> 
> 
> --- Comment #46 from bonzini at gnu dot org  2009-02-13 16:32 ---
> Regarding your comment in bug 26854:
> 
> > address calculations are no longer optimized as much as they
> > were before 
> 
> Sometimes, actually, they are optimized better.  It depends on the case.

Yes.  I don't see why the optimizations in CSE, which were relatively
cheap and which were effective for this case, needed to be disabled when
FWPROP was added without, evidently, understanding why FWPROP does not
do what CSE was already doing.

> In comment #42, also, you talked about -O1, where fwprop is not enabled.  So
> I'm failing to understand if the problem is at the tree or RTL level for this
> bug.

When I add -fforward-propagate to the command line, then the assembly
code changes in some ways, but the performance problem remains the same.

Brad


-- 


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

[Bug target/39152] [4.4 regression] Revision 144098 breaks 416.gamess in SPEC CPU 2006

[hjl dot tools at gmail dot com]

--- Comment #22 from hjl dot tools at gmail dot com  2009-02-13 17:23 
---
Fixed.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED


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

[Bug target/39181] New: [4.4 Regression] complex int arguments cause ICE

[pinskia at gcc dot gnu dot org]

Small testcase:
_Complex int bar(_Complex int z)
{
  return z;
}

--- CUT ---
This causes some testsuite failures on spu-elf.
t.c: In function ‘bar’:
t.c:9: internal compiler error: in spu_expand_mov, at config/spu/spu.c:4117
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: [4.4 Regression] complex int arguments cause ICE
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
GCC target triplet: spu-elf


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

[Bug target/39181] [4.4 Regression] complex int arguments cause ICE

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.4.0


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

[Bug tree-optimization/26854] [4.3/4.4 Regression] Inordinate compile times on large routines

[lucier at math dot purdue dot edu]

--- Comment #89 from lucier at math dot purdue dot edu  2009-02-13 17:30 
---
Subject: Re:  [4.3/4.4 Regression] Inordinate
 compile times on large routines

On Fri, 2009-02-13 at 17:06 +, jakub at gcc dot gnu dot org wrote:
> 
> 
> --- Comment #88 from jakub at gcc dot gnu dot org  2009-02-13 17:06 
> ---
> The patch in PR39157 is IMHO finished and has been bootstrapped/regtested on
> x86_64-linux and i686-linux.  I haven't posted it looked like Richard, Zdenek
> and Steven prefer some other solution for it.  If this isn't solved for 4.4
> soon, I'm going to post that patch.

I have to leave town within the hour and I may not be able to look at
this properly until Wednesday or so, but it would be interesting to me
to know how large (how many nodes?) are the 139 loops in _num.i referred
to in

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39157#c19

This information may suggest how large the default parameters should be
for -O1 and -O2.  (For example, if all the non-whole-function loops have
< 2000 instructions, then 5000 might be a reasonable limit for -O1
loops.)


-- 


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

[Bug target/39181] [4.4 Regression] complex int arguments cause ICE

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-02-13 17:31 ---
It started to ICE between revision 142828 and revision 144107 (a little over
two months worth).


-- 


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

[Bug target/39149] Typo in i386.c

[hjl dot tools at gmail dot com]

--- Comment #3 from hjl dot tools at gmail dot com  2009-02-13 17:31 ---
(In reply to comment #2)
> See the comment:
> 
> "... Remove this code in GCC 3.2 or later."
> 

But given the bogus warning message, we may never remove it :-).


-- 


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

[Bug tree-optimization/26854] [4.3/4.4 Regression] Inordinate compile times on large routines

[lucier at math dot purdue dot edu]

--- Comment #90 from lucier at math dot purdue dot edu  2009-02-13 17:37 
---
Subject: Re:  [4.3/4.4 Regression] Inordinate
 compile times on large routines

On Fri, 2009-02-13 at 16:54 +, bonzini at gnu dot org wrote:
> 
> 
> --- Comment #87 from bonzini at gnu dot org  2009-02-13 16:54 ---

> The problem is that -O1 was never meant to give "very fast" code.

I'm not looking for "very fast" code, I'm looking for code that doesn't
get > 30% slower from one SVN revision number to the next.

> You
> are using it only because our throttling of expensive passes is
> insufficient.

I am using -O1 because code of this type compiled with -O2 runs
significantly more slowly than code of this type compiled with -O1. I
have never used -O2 on this type of code.

> Fixing that has two sides, as done in PR39157's
> discussion: 1) disabling more passes at -O1, 2) establishing some
> parameters to throttle down passes at -O2.

I don't see that (1) and (2) form the main strategy to fix "that", it
seems that understanding the existing optimizations that are being
disabled in preference for new ones is a good start.  And generally
ensuring that -O1 code doesn't get significantly slower while compile
times get significantly higher.


-- 


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

[Bug tree-optimization/26854] [4.3/4.4 Regression] Inordinate compile times on large routines

[lucier at math dot purdue dot edu]

--- Comment #91 from lucier at math dot purdue dot edu  2009-02-13 17:43 
---
Subject: Re:  [4.3/4.4 Regression] Inordinate
 compile times on large routines

On Fri, 2009-02-13 at 17:37 +, lucier at math dot purdue dot edu
wrote:
> --- Comment #90 from lucier at math dot purdue dot edu  2009-02-13 17:37 
> ---
> Subject: Re:  [4.3/4.4 Regression] Inordinate
>  compile times on large routines
> 
> On Fri, 2009-02-13 at 16:54 +, bonzini at gnu dot org wrote:
> > 
> > 
> > --- Comment #87 from bonzini at gnu dot org  2009-02-13 16:54 ---
> 
> > The problem is that -O1 was never meant to give "very fast" code.
> 
> I'm not looking for "very fast" code, I'm looking for code that doesn't
> get > 30% slower from one SVN revision number to the next.

Sorry, this comment refers to PR 33928, not this PR.


-- 


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

[Bug target/39149] Typo in i386.c

[hjl dot tools at gmail dot com]

--- Comment #4 from hjl dot tools at gmail dot com  2009-02-13 17:44 ---
A patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00657.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2009-
   ||02/msg00657.html
   Target Milestone|4.4.0   |4.3.4
Version|4.4.0   |4.3.3


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

[Bug libgcj/39180] New String constructors need to be implemented in local copy of java.lang.String

[gnu_andrew at member dot fsf dot org]

--- Comment #1 from gnu_andrew at member dot fsf dot org  2009-02-13 17:45 
---
Created an attachment (id=17294)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17294&action=view)
Preliminary patch, has issues with the returned string reading from the wrong
memory location

Preliminary implementation.  The method works as expected, but for some reason
the returned string is not pointing to the characters.


-- 


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

[Bug target/39149] Typo in i386.c

[hjl at gcc dot gnu dot org]

--- Comment #5 from hjl at gcc dot gnu dot org  2009-02-13 17:48 ---
Subject: Bug 39149

Author: hjl
Date: Fri Feb 13 17:48:20 2009
New Revision: 144160

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144160
Log:
2009-02-13  H.J. Lu  

PR target/39149
* config/i386/i386.c (override_options): Correct warning
messages for -malign-loops,  -malign-jumps and
-malign-functions.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c


-- 


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

[Bug libgcj/39180] New String constructors need to be implemented in local copy of java.lang.String

[tromey at gcc dot gnu dot org]

--- Comment #2 from tromey at gcc dot gnu dot org  2009-02-13 17:54 ---
This line looks fishy:

+ boffset = cbuf->position();

boffset is a byte offset from the start of 'data' to the first character.
So, you probably need to multiply by sizeof(jchar) and also add in
the size of the array header.


-- 


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

[Bug c/39182] New: ICE in gen_add2_insn, at optabs.c:4884

[joel at gcc dot gnu dot org]

We get this error multiple places in the RTEMS code base.  

m32c-rtems4.10-gcc --pipe  -mcpu=m32cm --pipe -DHAVE_CONFIG_H   -I..
-I../../../lib/include -D__RTEMS_INSIDE__  -Wall
-Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -fasm -g
-O2  -mcpu=m32cm -MT src/libsapi_a-ioregisterdriver.o -MD -MP -MF
src/.deps/libsapi_a-ioregisterdriver.Tpo -c -o src/libsapi_a-ioregisterdriver.o
`test -f 'src/ioregisterdriver.c' || echo
'../../../../../rtems/cpukit/sapi/'`src/ioregisterdriver.c
../../../../../rtems/cpukit/sapi/src/ioregisterdriver.c: In function
'rtems_io_register_driver':
../../../../../rtems/cpukit/sapi/src/ioregisterdriver.c:92: internal compiler
error: in gen_add2_insn, at optabs.c:4884


-- 
   Summary: ICE in gen_add2_insn, at optabs.c:4884
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joel at gcc dot gnu dot org
GCC target triplet: m32c-rtems


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

[Bug c/39182] ICE in gen_add2_insn, at optabs.c:4884

[joel at gcc dot gnu dot org]

--- Comment #1 from joel at gcc dot gnu dot org  2009-02-13 18:50 ---
Created an attachment (id=17295)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17295&action=view)
preprocessed test case


-- 


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

[Bug c/39182] ICE in gen_add2_insn, at optabs.c:4884

[joel at gcc dot gnu dot org]

--- Comment #2 from joel at gcc dot gnu dot org  2009-02-13 18:52 ---
WORKS: m32c-rtems4.10-gcc -mcpu=m32cm j.c -c
FAILS: m32c-rtems4.10-gcc -mcpu=m32cm j.c -O1 -c
FAILS: m32c-rtems4.10-gcc -mcpu=m32cm j.c -O2 -c


-- 

joel at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|target  |c


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

[Bug c++/39070] [4.3/4.4 regression] ICE with typeof() (... and __decltype)

[jason at gcc dot gnu dot org]

--- Comment #7 from jason at gcc dot gnu dot org  2009-02-13 19:14 ---
Subject: Bug 39070

Author: jason
Date: Fri Feb 13 19:14:07 2009
New Revision: 144161

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144161
Log:
PR c++/39070
* semantics.c (finish_call_expr): Change koenig_p parm to int.
If -1, don't set KOENIG_LOOKUP_P but do keep hidden candidates.
* cp-tree.h: Adjust prototype.
* pt.c (tsubst_copy_and_build) [CALL_EXPR]: Pass -1.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/decltype16.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/pt.c
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug target/39137] [4.4 Regression] -mpreferred-stack-boundary=2 causes lots of dynamic realign

[jakub at gcc dot gnu dot org]

--- Comment #19 from jakub at gcc dot gnu dot org  2009-02-13 19:15 ---
Created an attachment (id=17296)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17296&action=view)
Unsuccessful attempt to avoid stack realignment for DImode and for DFmode at
-Os

Just for the record, here is an unsuccessful attempt to avoid stack realignment
just because of DImode for -m32 or because of DFmode at -m32 -Os.  This patch
unfortunately caused a handful regressions, like 20020220-1.c.


-- 


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

[Bug target/39181] [4.4 Regression] complex int arguments cause ICE

[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=39181

[Bug other/39183] New: valgrind find problems in "as"

[dcb314 at hotmail dot com]

I just tried to compile the Linux kernel 2.6.28.5
with the GNU C compiler version 4.4 snapshot 20090206,
using the valgrind debugging tool.

The compiler said
 as --gdwarf2 -V -Qy --64 -o arch/x86/ia32/ia32entry.o ia32entry.s
==4085== Conditional jump or move depends on uninitialised value(s)
==4085==at 0x41D56E: (within /usr/bin/as)
==4085==by 0x405DC4: (within /usr/bin/as)
==4085==by 0x5976585: (below main) (in /lib64/libc-2.9.so)

File ia32entry.s attached.

$ as -v
GNU assembler version 2.19 (x86_64-suse-linux) using BFD version (GNU Binutils;
openSUSE 11.1) 2.19


-- 
   Summary: valgrind find problems in "as"
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
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=39183

[Bug tree-optimization/33928] [4.3/4.4 Regression] 30% performance slowdown in floating-point code caused by r118475

[bonzini at gnu dot org]

--- Comment #48 from bonzini at gnu dot org  2009-02-13 20:09 ---
Subject: Re:  [4.3/4.4 Regression] 30% 
performance slowdown in floating-point code caused by r118475

> Yes.  I don't see why the optimizations in CSE, which were relatively
> cheap and which were effective for this case, needed to be disabled when
> FWPROP was added without, evidently, understanding why FWPROP does not
> do what CSE was already doing.

Just to mention it, fwprop saved 3% of compile time.  That's not
"cheap".  It was also tested with SPEC and Nullstone on several
architectures.


-- 


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

[Bug other/39183] valgrind find problems in "as"

[dcb314 at hotmail dot com]

--- Comment #1 from dcb314 at hotmail dot com  2009-02-13 20:10 ---
Created an attachment (id=17297)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17297&action=view)
pre-processed assembly language code


-- 


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

[Bug other/39183] valgrind find problems in "as"

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2009-02-13 20:11 ---
As is not part of GCC project, report it to binutils project,
http://sourceware.org/bugzilla/


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug libgomp/39176] -static and -fopenmp and io causes segfault

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2009-02-13 20:18 ---
Not a gcc bug so closing as invalid.  That warning comes from glibc anyways.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug other/39183] valgrind find problems in "as"

[hjl dot tools at gmail dot com]

--- Comment #3 from hjl dot tools at gmail dot com  2009-02-13 20:19 ---
FWIW, I can't reproduce it with the current binutils in CVS.


-- 


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

[Bug target/39182] ICE in gen_add2_insn, at optabs.c:4884

[dj at redhat dot com]

--- Comment #3 from dj at redhat dot com  2009-02-13 20:28 ---
Fails with m32c-elf in 4.3.4 also.
Note: does NOT fail in 4.4/trunk


-- 

dj at redhat dot com changed:

   What|Removed |Added

 CC||dj at redhat dot com
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-02-13 20:28:57
   date||


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

[Bug c/39184] New: ICE in tree_low_cst, at tree.c:4976

[joel at gcc dot gnu dot org]

ICE at -O1 and -02.  Target specific error message at -O0.  But even that would
be more helpful if it told what the actual limit was.

$ avr-rtems4.10-gcc   -mmcu=avr25 -O2 j.c -c
../../../../../rtems/cpukit/telnetd/des.c: In function 'des_init':
../../../../../rtems/cpukit/telnetd/des.c:274: internal compiler error: in
tree_low_cst, at tree.c:4976
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

$  avr-rtems4.10-gcc   -mmcu=avr25 -O0 j.c -c
../../../../../rtems/cpukit/telnetd/des.c:87: error: size of variable 'des_f'
is too large


-- 
   Summary: ICE in tree_low_cst, at tree.c:4976
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joel at gcc dot gnu dot org
GCC target triplet: avr-rtems4.10


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

[Bug c/39184] ICE in tree_low_cst, at tree.c:4976

[joel at gcc dot gnu dot org]

--- Comment #1 from joel at gcc dot gnu dot org  2009-02-13 20:54 ---
Created an attachment (id=17298)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17298&action=view)
preprocessed test case


-- 


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

[Bug libgomp/39176] -static and -fopenmp and io causes segfault

[jv244 at cam dot ac dot uk]

--- Comment #7 from jv244 at cam dot ac dot uk  2009-02-13 21:00 ---
(In reply to comment #6)
> Not a gcc bug so closing as invalid.  

The gcc  'bug' is that -fopenmp -static should link to pthreads as 
-Wl,--whole-archive -lpthread -Wl,--no-whole-archive, if that is required, or
error out if that is not possible. 

The current way of just adding -lpthread and hoping it is correct (even in the
presence of -static) is leading to wrong code.


-- 

jv244 at cam dot ac dot uk changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug libgomp/39176] -static and -fopenmp and io causes segfault

[jakub at gcc dot gnu dot org]

--- Comment #8 from jakub at gcc dot gnu dot org  2009-02-13 21:10 ---
This is not a gcc bug, glibc either should not ship libpthread.a at all or
mv libpthread.a libpthreadx.a; gcc -r -nostdlib -o libpthread.a --whole-archive
libpthreadx.a; rm libpthreadx.a
I'll try the latter in Fedora soon.
In any case, users really shouldn't use -static except for a few system
recovery tools, see
http://people.redhat.com/drepper/no_static_linking.html


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug fortran/36528] Cray pointer to function mishandled

[pault at gcc dot gnu dot org]

--- Comment #3 from pault at gcc dot gnu dot org  2009-02-13 21:12 ---
Subject: Bug 36528

Author: pault
Date: Fri Feb 13 21:12:34 2009
New Revision: 144164

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144164
Log:
2009-02-13  Paul Thomas  

PR fortran/36703
PR fortran/36528
* trans-expr.c (gfc_conv_function_val): Stabilize Cray-pointer
function references to ensure that a valid expression is used.
(gfc_conv_function_call): Pass Cray pointers to procedures.

2009-02-13  Paul Thomas  

PR fortran/36528
* gfortran.dg/cray_pointers_8.f90: New test.

PR fortran/36703
* gfortran.dg/cray_pointers_9.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/cray_pointers_8.f90
trunk/gcc/testsuite/gfortran.dg/cray_pointers_9.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-expr.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/36703] ICE (segfault) in reduce_binary0 (arith.c:1778)

[pault at gcc dot gnu dot org]

--- Comment #4 from pault at gcc dot gnu dot org  2009-02-13 21:12 ---
Subject: Bug 36703

Author: pault
Date: Fri Feb 13 21:12:34 2009
New Revision: 144164

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144164
Log:
2009-02-13  Paul Thomas  

PR fortran/36703
PR fortran/36528
* trans-expr.c (gfc_conv_function_val): Stabilize Cray-pointer
function references to ensure that a valid expression is used.
(gfc_conv_function_call): Pass Cray pointers to procedures.

2009-02-13  Paul Thomas  

PR fortran/36528
* gfortran.dg/cray_pointers_8.f90: New test.

PR fortran/36703
* gfortran.dg/cray_pointers_9.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/cray_pointers_8.f90
trunk/gcc/testsuite/gfortran.dg/cray_pointers_9.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-expr.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c/39185] New: ICE in gen_rtx_SUBREG, at emit-rtl.c:773

[joel at gcc dot gnu dot org]

$ h8300-rtems4.10-gcc -O1 -msx -c j.c
../../../../../rtems/cpukit/libnetworking/netinet/in_cksum.c: In function
'in_cksum':
../../../../../rtems/cpukit/libnetworking/netinet/in_cksum.c:118: internal
compiler error: in gen_rtx_SUBREG, at emit-rtl.c:773
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Fails at -O2, -O1.
Works at -O0.


-- 
   Summary: ICE in gen_rtx_SUBREG, at emit-rtl.c:773
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joel at gcc dot gnu dot org
GCC target triplet: h8300-rtems


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

[Bug c/39185] ICE in gen_rtx_SUBREG, at emit-rtl.c:773

[joel at gcc dot gnu dot org]

--- Comment #1 from joel at gcc dot gnu dot org  2009-02-13 21:17 ---
Created an attachment (id=17299)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17299&action=view)
preprocessed test case


-- 


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

[Bug target/39185] ICE in gen_rtx_SUBREG, at emit-rtl.c:773

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2009-02-13 21:20 ---
Most likely related to PR 33163 and PR 32739.


-- 


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

[Bug c++/39070] [4.3/4.4 regression] ICE with typeof() (... and __decltype)

[jason at gcc dot gnu dot org]

--- Comment #8 from jason at gcc dot gnu dot org  2009-02-13 21:53 ---
Subject: Bug 39070

Author: jason
Date: Fri Feb 13 21:53:38 2009
New Revision: 144166

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144166
Log:
PR c++/39070
* semantics.c (finish_call_expr): Change koenig_p parm to int.
If -1, don't set KOENIG_LOOKUP_P but do keep hidden candidates.
* cp-tree.h: Adjust prototype.
* pt.c (tsubst_copy_and_build) [CALL_EXPR]: Pass -1.

Added:
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/cpp0x/decltype16.C
  - copied unchanged from r144161,
trunk/gcc/testsuite/g++.dg/cpp0x/decltype16.C
Modified:
branches/gcc-4_3-branch/gcc/cp/ChangeLog
branches/gcc-4_3-branch/gcc/cp/cp-tree.h
branches/gcc-4_3-branch/gcc/cp/pt.c
branches/gcc-4_3-branch/gcc/cp/semantics.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug rtl-optimization/38034] Unnecssary register move

[hjl dot tools at gmail dot com]

--- Comment #2 from hjl dot tools at gmail dot com  2009-02-13 21:58 ---
A patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00674.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||sje at cup dot hp dot com
URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2009-
   ||02/msg00674.html


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

[Bug target/38056] Missed tail calls on ia64

[sje at gcc dot gnu dot org]

--- Comment #4 from sje at gcc dot gnu dot org  2009-02-13 21:59 ---
Subject: Bug 38056

Author: sje
Date: Fri Feb 13 21:59:32 2009
New Revision: 144168

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144168
Log:
PR target/38056
* config/ia64/ia64.c (ia64_function_ok_for_sibcall): Check
TARGET_CONST_GP.
* gcc.target/ia64/sibcall-opt-1.c: New test.
* gcc.target/ia64/sibcall-opt-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/ia64/sibcall-opt-1.c
trunk/gcc/testsuite/gcc.target/ia64/sibcall-opt-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/ia64/ia64.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/38259] Add version number to .mod file

[burnus at gcc dot gnu dot org]

--- Comment #5 from burnus at gcc dot gnu dot org  2009-02-13 22:16 ---
Subject: Bug 38259

Author: burnus
Date: Fri Feb 13 22:16:20 2009
New Revision: 144169

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144169
Log:
2009-02-13  Mikael Morin  

PR fortran/38259
* module.c (gfc_dump_module,gfc_use_module): Add module
version number.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/module.c


-- 


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

[Bug fortran/38259] Add version number to .mod file

[burnus at gcc dot gnu dot org]

--- Comment #6 from burnus at gcc dot gnu dot org  2009-02-13 22:17 ---
FIXED on the trunk (4.4.0).


-- 

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

[Bug bootstrap/39186] New: Configury incorrect for 64-bit Targets on Solaris

[rob1weld at aol dot com]

I decided to re-build binutils and try the Target "x86_64-pc-solaris2.11"
that is suggested to be available to us in this post:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39150#c1

The attempt with Sun's Linker did not work so I tried with Binutils.


# isainfo -k
amd64

# uname -a
SunOS opensolaris 5.11 snv_106 i86pc i386 i86pc

# gcc/xgcc -v
Using built-in specs.
Target: x86_64-pc-solaris2.11
Configured with: ../gcc_trunk/configure 
--build=i386-pc-solaris2.11 --target=x86_64-pc-solaris2.11 
--enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --enable-shared
--disable-static --enable-multilib --enable-decimal-float
--with-long-double-128 --with-included-gettext --enable-stage1-checking 
--enable-checking=release --with-tune=k8 --with-cpu=k8 --with-arch=k8 
--with-gnu-as --with-as=/usr/local/bin/as --with-gnu-ld 
--with-ld=/usr/local/bin/ld --with-gmp=/usr/local --with-mpfr=/usr/local
--without-ppl 
Thread model: posix
gcc version 4.4.0 20090213 (experimental) [trunk revision 144162] (GCC) 

# as --version
GNU assembler (GNU Binutils) 2.19.1

# ld --version
GNU ld (GNU Binutils) 2.19.1


The Build breaks here:

# gmake
...
cp gcj gcj-cross
gmake[2]: Leaving directory `/usr/share/src/gcc_build/gcc'
Configuring in ./gnattools
configure: creating cache ./config.cache
checking for a BSD-compatible install... /usr/bin/ginstall -c
checking build system type... i386-pc-solaris2.11
checking host system type... i386-pc-solaris2.11
checking target system type... x86_64-pc-solaris2.11
checking whether ln -s works... yes
checking for i386-pc-solaris2.11-gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... 
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
updating cache ./config.cache
configure: creating ./config.status
config.status: creating Makefile
Checking multilib configuration for libgcc...
Configuring in x86_64-pc-solaris2.11/libgcc
configure: creating cache ./config.cache
checking for --enable-version-specific-runtime-libs... no
checking for a BSD-compatible install... /usr/bin/ginstall -c
checking for gawk... gawk
checking build system type... i386-pc-solaris2.11
checking host system type... x86_64-pc-solaris2.11
checking for x86_64-pc-solaris2.11-ar...
/usr/local/x86_64-pc-solaris2.11/bin/ar
checking for x86_64-pc-solaris2.11-lipo... x86_64-pc-solaris2.11-lipo
checking for x86_64-pc-solaris2.11-nm... /usr/share/src/gcc_build/./gcc/nm
checking for x86_64-pc-solaris2.11-ranlib...
/usr/local/x86_64-pc-solaris2.11/bin/ranlib
checking for x86_64-pc-solaris2.11-strip...
/usr/local/x86_64-pc-solaris2.11/bin/strip
checking whether ln -s works... yes
checking for x86_64-pc-solaris2.11-gcc... /usr/share/src/gcc_build/./gcc/xgcc
-B/usr/share/src/gcc_build/./gcc/ -B/usr/local/x86_64-pc-solaris2.11/bin/
-B/usr/local/x86_64-pc-solaris2.11/lib/ -isystem
/usr/local/x86_64-pc-solaris2.11/include -isystem
/usr/local/x86_64-pc-solaris2.11/sys-include
checking for suffix of object files... configure: error: in
`/usr/share/src/gcc_build/x86_64-pc-solaris2.11/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
gmake[1]: *** [configure-target-libgcc] Error 1
gmake[1]: Leaving directory `/usr/share/src/gcc_build'
gmake: *** [all] Error 2
...


The ../gcc_build/x86_64-pc-solaris2.11/libgcc/config.log file says:

...
xgcc: '-V' must come at the start of the command line
configure:2396: $? = 1
configure:2415: /usr/share/src/gcc_build/./gcc/xgcc
-B/usr/share/src/gcc_build/./gcc/ -B/usr/local/x86_64-pc-solaris2.11/bin/
-B/usr/local/x86_64-pc-solaris2.11/lib/ -isystem
/usr/local/x86_64-pc-solaris2.11/include -isystem
/usr/local/x86_64-pc-solaris2.11/sys-include -o conftest -g -O2 conftest.c 
>&5
/var/tmp//ccMDaqTx.s: Assembler messages:
/var/tmp//ccMDaqTx.s:35: Error: cannot represent relocation type BFD_RELOC_64
/var/tmp//ccMDaqTx.s:36: Error: cannot represent relocation type BFD_RELOC_64
/var/tmp//ccMDaqTx.s:44: Error: cannot represent relocation type BFD_RELOC_64
/var/tmp//ccMDaqTx.s:45: Error: cannot represent relocation type BFD_RELOC_64
/var/tmp//ccMDaqTx.s:123: Error: cannot represent relocation type BFD_RELOC_64
configure:2418: $? = 1
configure:2590: checking for suffix of object files
...


The command being used is:
/usr/share/src/gcc_build/./gcc/xgcc -B/usr/share/src/gcc_build/./gcc/
-B/usr/local/x86_64-pc-solaris2.11/bin/ -B/usr/local/x86_64-pc-solaris2.11/lib/
-isystem /usr/local/x86_64-pc-solaris2.11/include -isystem
/usr/local/x86_64-pc-solaris2.11/sys-include -o conftest -g -O2 conftest.c


--

If I change that by adding "-v --save-temps" and using it on a 'hello world'.c
I get:


# 

[Bug target/39186] Configury incorrect for 64-bit Targets on Solaris

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-02-13 23:54 ---
the -X86_64 option is not being passed to as which is a bug in the specs.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|bootstrap   |target


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

[Bug c++/39187] New: G++ doesn't use string literal in inline function

[hjl dot tools at gmail dot com]

[...@gnu-6 936]$ cat x.cc
#include "foo.h"

const char *
x (void)
{
  return f ();
}
[...@gnu-6 936]$ cat y.cc
#include 
#include "foo.h"

extern const char *x (void);

int
main ()
{
  printf ("%p, %p\n", x (), f ());
  return 0;
}
[...@gnu-6 936]$ cat foo.h
inline const char *
f ()
{
  static const char *p = "Itanium C++ ABI";
  return p;
}
[...@gnu-6 936]$ cat x.s
.file   "x.cc"
.section.text._Z1fv,"axG",@progbits,_Z1fv,comdat
.p2align 4,,15
.weak   _Z1fv
.type   _Z1fv, @function
_Z1fv:
movq_ZZ1fvE1p(%rip), %rax
ret
.size   _Z1fv, .-_Z1fv
.text
.p2align 4,,15
.globl _Z1xv
.type   _Z1xv, @function
_Z1xv:
movq_ZZ1fvE1p(%rip), %rax
ret
.size   _Z1xv, .-_Z1xv
.weak   _ZZ1fvE1p
.section.rodata.str1.1,"aMS",@progbits,1
.LC0:
.string "Itanium C++ ABI"

Both x.s and y.s have a string:

.string "Itanium C++ ABI"

It should be put in string literal as specified in C++ ABI:

http://www.codesourcery.com/public/cxx-abi/abi.html#mangling

so that only one copy will be in the executable/DSO.


-- 
   Summary: G++ doesn't use string literal in inline function
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


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

[Bug c++/39187] G++ doesn't use string literal in inline function

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-02-14 00:11 ---
Except the C++ standard has a defect against this area, see PR 12056 which is
still opened the last time I looked.

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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/12056] [DR 397] string literal in extern inline function not unique

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2009-02-14 00:11 ---
*** Bug 39187 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug c++/39188] New: G++ doesn't handle static anonymous union right

[hjl dot tools at gmail dot com]

-- 
   Summary: G++ doesn't handle static anonymous union right
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


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

[Bug c++/39188] G++ doesn't handle static anonymous union right

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2009-02-14 00:38 ---
[...@gnu-6 936]$ cat x.cc
#include "foo.h"

int *
x (void)
{
  return f ();
}
[...@gnu-6 936]$ cat y.cc
#include 
#include "foo.h"

extern int *x (void);

int
main ()
{
  printf ("%p, %p\n", x (), f ());
  return 0;
}
[...@gnu-6 936]$ cat foo.h
inline int *
f ()
{
  static union 
{
  const char *p;
  int i;
};
  return &i;
}
[...@gnu-6 936]$  g++ x.cc y.cc -O2
[...@gnu-6 936]$ ./a.out 
0x600a38, 0x600a40
[...@gnu-6 936]$ nm x.o | c++filt 
 W f()
 T x()
 b f()::p
 U __gxx_personality_v0

f()::p should be global and linkonce.


-- 


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