[Bug driver/46516] gfortran-trunk: error: libgfortran.spec: No such file or directory

2010-11-17 Thread Joost.VandeVondele at pci dot uzh.ch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46516

--- Comment #5 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 
2010-11-17 08:02:53 UTC ---
(In reply to comment #4)
 I suppose it's the --disable-multilib, but I don't know why.

Yes, it is certainly this. The driver seems to search only in the lib directory
and not in the lib64 directory. If I copy the spec file from lib64 to lib it
works.


[Bug driver/46516] gfortran-trunk: error: libgfortran.spec: No such file or directory

2010-11-17 Thread burnus at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46516

--- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org 2010-11-17 
08:20:07 UTC ---
(In reply to comment #5)
 (In reply to comment #4)
  I suppose it's the --disable-multilib, but I don't know why.
 
 Yes, it is certainly this. The driver seems to search only in the lib 
 directory
 and not in the lib64 directory. If I copy the spec file from lib64 to lib it
 works.

What's the content of the $BUILD/gcc/multilib.h file? In particular the
multilib_raw one? Here, it is (x86-64-linux with multilib):

static const char *const multilib_raw[] = {
. !m64 !m32;,
64:../lib64 m64 !m32;,
32:../lib !m64 m32;,
NULL
};


I fear that the current multilib support assumes that the path only has a
suffix if one has multilib enabled; cf. gcc.c's for_each_path which is called
by find_a_file. It seems to search without multilib in, e.g.
 /usr/lib
and with multilib in
 /usr/lib/../lib64  for -m64
 /usr/lib/../libfor -m32
 /usr/lib/. for neither -m32 nor -m64 (does this ever happen?)

I think that was a good assumption before the 64bit support on x86-64 was
added; there, old programs (with /usr/lib) should continue to work thus the
64bit libs where placed at a non-default directory: /usr/lib64.
(For all above: Analogously for /usr/local/lib and $PREFIX/lib etc.)

Hence, I am interested how a --disable-multilib $BUILD/gcc/multilib.h looks
like.


[Bug driver/46516] Non-multilib search problem in gcc.c / gfortran error: libgfortran.spec: No such file or directory

2010-11-17 Thread burnus at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46516

Tobias Burnus burnus at gcc dot gnu.org changed:

   What|Removed |Added

 Target||x86_64-unknown-linux-gnu
   Host||x86_64-unknown-linux-gnu
   Target Milestone|--- |4.6.0
Summary|gfortran-trunk: error:  |Non-multilib search problem
   |libgfortran.spec: No such   |in gcc.c / gfortran error:
   |file or directory   |libgfortran.spec: No such
   ||file or directory
  Build||x86_64-unknown-linux-gnu


[Bug driver/46516] Non-multilib search problem in gcc.c / gfortran error: libgfortran.spec: No such file or directory

2010-11-17 Thread burnus at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46516

Tobias Burnus burnus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||joseph at codesourcery dot
   ||com

--- Comment #7 from Tobias Burnus burnus at gcc dot gnu.org 2010-11-17 
08:31:06 UTC ---
CC Joseph, who - after Alan Modra in 2005 (for PR 20425) - seems to be the only
one who has ever touched gcc.c's multilib.


[Bug driver/46516] Non-multilib search problem in gcc.c / gfortran error: libgfortran.spec: No such file or directory

2010-11-17 Thread Joost.VandeVondele at pci dot uzh.ch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46516

--- Comment #8 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 
2010-11-17 08:46:11 UTC ---
mine look like:

static const char *const multilib_raw[] = {
. !m64 !m32;,
.:../lib64 m64 !m32;,
.:../lib !m64 m32;,
NULL
};

however, I just observe that the libgomp.spec are causing no problems in my
build.


[Bug driver/46516] Non-multilib search problem in gcc.c / gfortran error: libgfortran.spec: No such file or directory

2010-11-17 Thread Joost.VandeVondele at pci dot uzh.ch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46516

--- Comment #9 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 
2010-11-17 08:50:06 UTC ---
FYI, with strace I see following things being searched for the specs:

access(/data/vondele/gcc_bench/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/,
X_OK) = 0
access(/data/vondele/gcc_bench/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/,
X_OK) = 0
access(/data/vondele/gcc_bench/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/specs,
R_OK) = -1 E
NOENT (No such file or directory)
access(/data/vondele/gcc_bench/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../x86_64-u
nknown-linux-gnu/lib/x86_64-unknown-linux-gnu/4.6.0/specs, R_OK) = -1 ENOENT
(No such file or directory)
access(/data/vondele/gcc_bench/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../x86_64-u
nknown-linux-gnu/lib/specs, R_OK) = -1 ENOENT (No such file or directory)
access(/data/vondele/gcc_bench/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/specs,
R_OK) = -1 ENOENT 
(No such file or directory)
access(/data/vondele/gcc_bench/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/,
X_OK) = 0
access(/data/vondele/gcc_bench/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/libgfortran.spec,
R _OK) = -1 ENOENT
(No such file or directory)
access(/data/vondele/gcc_bench/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../x86_64-u
   
nknown-linux-gnu/lib/x86_64-unknown-linux-gnu/4.6.0/libgfortran.spec, R_OK) =
-1 ENOENT (No such file or d   
 irectory)
access(/data/vondele/gcc_bench/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../x86_64-u
   
nknown-linux-gnu/lib/libgfortran.spec, R_OK) = -1 ENOENT (No such file or
directory)
access(/data/vondele/gcc_bench/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../x86_64-unkn
   
own-linux-gnu/4.6.0/libgfortran.spec, R_OK) = -1 ENOENT (No such file or
directory)
access(/data/vondele/gcc_bench/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../libgfortran
.spec, R_OK) = -1
ENOENT (No such file or directory)
access(/lib/x86_64-unknown-linux-gnu/4.6.0/libgfortran.spec, R_OK) = -1
ENOENT (No such file or directory  
  )
access(/lib/libgfortran.spec, R_OK)   = -1 ENOENT (No such file or directory)
access(/usr/lib/x86_64-unknown-linux-gnu/4.6.0/libgfortran.spec, R_OK) = -1
ENOENT (No such file or direc  
  tory)
access(/usr/lib/libgfortran.spec, R_OK) = -1 ENOENT (No such file or
directory)
open(libgfortran.spec, O_RDONLY)  = -1 ENOENT (No such file or directory)


[Bug driver/46516] Non-multilib search problem in gcc.c / gfortran error: libgfortran.spec: No such file or directory

2010-11-17 Thread burnus at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46516

--- Comment #10 from Tobias Burnus burnus at gcc dot gnu.org 2010-11-17 
09:27:21 UTC ---
(In reply to comment #8)
 however, I just observe that the libgomp.spec are causing no problems in my
 build.

Are they actually read? Even here, where I use multilib and the gfortran.spec
is found, I do not see that the libgomp.spec is read - at least I do not see a
line like:
  Reading specs from ... libgomp.spec
unless I explicitly pass '-specs=libgomp.spec' to the driver.

My impression is that libgomp.spec should be read if found, otherwise the
defaults are used. But seemingly, it is never read - also strace does not show
anything.


[Bug c/46517] New: Wrong result on left shift operator without optimization

2010-11-17 Thread lepinat at free dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46517

   Summary: Wrong result on left shift operator without
optimization
   Product: gcc
   Version: 4.4.4
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: lepi...@free.fr


The next samples compiled without opimisation give not the same result
in both case if it's use has constante the result is good
(the test is on intel platfom)

# gcc -o shift  shift.c
result:
constant val=0
variable val=1

# gcc -O2 -o shift  shift.c
result:
constant val=0
variable val=0


On the first case is not a shift but it's rotate

you can verify by changing the constant:
example SHIFT = 34 the the result is 

constant val=0
variable val=4


88888
#include stdio.h


#define SHIFT(4*8)



int main(int argc, char* argv[])

{

int val = SHIFT;



printf(constant val=%x\n, (1SHIFT));



printf(variable val=%x\n, (1val));

return 0;

}



88888


[Bug libstdc++/46455] resource leaks due to missing destructors for mutexes and condvars

2010-11-17 Thread redi at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46455

--- Comment #30 from Jonathan Wakely redi at gcc dot gnu.org 2010-11-17 
09:37:37 UTC ---
(In reply to comment #29)
 because __gthread_mutex_destroy returns void.

Argh, why is gthr-win32.h different here?!

Nevermind ...

 after changing the return types of the _S_destroy functions to void and
 removing the return specifiers, the test case compiles and runs fine without
 any leak.

Great, thanks very much for testing.

I'll get similar changes done to mutex and get this checked in.


[Bug driver/46516] Non-multilib search problem in gcc.c / gfortran error: libgfortran.spec: No such file or directory

2010-11-17 Thread burnus at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46516

--- Comment #11 from Tobias Burnus burnus at gcc dot gnu.org 2010-11-17 
09:40:52 UTC ---
(In reply to comment #10)
 Are they actually read?

Sorry, I tested wrongly. One needs to have both -fopenmp *and* one needs to
link. Then I also sees Read specs + strace for libgomp.spec.

I think I just will bootstrap with --disable-multilib and keep silent until I
have debugged this.


[Bug c/46460] warn for shifting more than the bits in the (promoted) type is undefined

2010-11-17 Thread sch...@linux-m68k.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46460

Andreas Schwab sch...@linux-m68k.org changed:

   What|Removed |Added

 CC||lepinat at free dot fr

--- Comment #3 from Andreas Schwab sch...@linux-m68k.org 2010-11-17 09:45:16 
UTC ---
*** Bug 46517 has been marked as a duplicate of this bug. ***


[Bug c/46517] Wrong result on left shift operator without optimization

2010-11-17 Thread sch...@linux-m68k.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46517

Andreas Schwab sch...@linux-m68k.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #1 from Andreas Schwab sch...@linux-m68k.org 2010-11-17 09:45:15 
UTC ---
.

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


[Bug tree-optimization/46312] gcc.dg/vec-scal-opt2.c fails for ARM targets.

2010-11-17 Thread irar at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46312

--- Comment #11 from irar at gcc dot gnu.org 2010-11-17 10:00:34 UTC ---
Author: irar
Date: Wed Nov 17 10:00:27 2010
New Revision: 166860

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=166860
Log:

PR tree-optimization/46312
* gcc.dg/vect/vect-scal-opt2.c: Rename to...
* gcc.dg/vect/vec-scal-opt2.c: ... this. Expect to pass only
on targets that support vector shifts with scalar shift
argument.
Remove dg-options.
* gcc.dg/vect/vect-scal-opt.c: Rename to...
* gcc.dg/vect/vec-scal-opt.c: ... this, and change likewise.
* gcc.dg/vect/vect-scal-opt1.c: Rename to...
* gcc.dg/vect/vec-scal-opt1.c: ... this, and change likewise.
* gcc.dg/vect/vect.exp: Run vec-scal-* tests with relevant
flags.
* gcc.dg/vect/vect-114.c: Expect to pass only on targets that
support misaligned data accesses.
* gcc.dg/vect/pr43432.c, gcc.dg/vect/vect-15.c: Likewise.
* gcc.dg/vect/pr43430-2.c: Remove dg-options.
* lib/target-supports.exp
(check_effective_target_vect_shift_scalar): New.


Added:
trunk/gcc/testsuite/gcc.dg/vect/vec-scal-opt.c
trunk/gcc/testsuite/gcc.dg/vect/vec-scal-opt1.c
trunk/gcc/testsuite/gcc.dg/vect/vec-scal-opt2.c
Removed:
trunk/gcc/testsuite/gcc.dg/vect/vect-scal-opt.c
trunk/gcc/testsuite/gcc.dg/vect/vect-scal-opt1.c
trunk/gcc/testsuite/gcc.dg/vect/vect-scal-opt2.c
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/pr43430-2.c
trunk/gcc/testsuite/gcc.dg/vect/pr43432.c
trunk/gcc/testsuite/gcc.dg/vect/vect-114.c
trunk/gcc/testsuite/gcc.dg/vect/vect-15.c
trunk/gcc/testsuite/gcc.dg/vect/vect.exp
trunk/gcc/testsuite/lib/target-supports.exp


[Bug testsuite/45429] [4.6 Regression] gcc.dg/vect/no-section-anchors-vect-64.c

2010-11-17 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45429

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2010-11-17 
10:20:16 UTC ---
In ia64 cross I see that only one
Alignment of access forced using peeling
message is printed (for the first loop), instead of two (for the first and
third loop).

If 163561 was ok, then then difference is most probably the change to the
testcase itself:
http://gcc.gnu.org/viewcvs/trunk/gcc/testsuite/gcc.dg/vect/no-section-anchors-vect-64.c?r1=163563r2=163562pathrev=163563

The culprit is the change of id array.

I guess we could do something like:

--- gcc/testsuite/gcc.dg/vect/no-section-anchors-vect-64.c.jj2010-11-17
11:18:22.0 +0100
+++ gcc/testsuite/gcc.dg/vect/no-section-anchors-vect-64.c2010-11-17
11:17:39.0 +0100
@@ -8,7 +8,7 @@
 int ib[N] = {0,3,6,9,12,15,18,21,24,27,30,33,36,39,42,45};
 int ia[N][4][N+1];
 int ic[N][N][3][N+1];
-int id[N][N][N+1];
+int id[N][N][N+4];

 __attribute__ ((noinline))

(at least this seems to work for both ia64 and x86_64).


[Bug testsuite/45429] [4.6 Regression] gcc.dg/vect/no-section-anchors-vect-64.c

2010-11-17 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45429

--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2010-11-17 
10:25:40 UTC ---
And the reason why it only shows up on ia64 is because it uses vectorization
factor 2 instead of 4 that is used on x86_64/i386+sse2.  With:
int id[16][16][17]
id[i][1][0+1] is actually aligned to 2 * sizeof (int), so no peeling is needed
to align it.


[Bug testsuite/45429] [4.6 Regression] gcc.dg/vect/no-section-anchors-vect-64.c

2010-11-17 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45429

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

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


[Bug tree-optimization/46498] [4.5/4.6 Regression] ICE: in eliminate_unnecessary_stmts, at tree-ssa-dce.c:1112 with -O -funsafe-math-optimizations -fno-tree-dominator-opts -fno-tree-reassoc

2010-11-17 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46498

--- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-17 
10:43:25 UTC ---
Author: rguenth
Date: Wed Nov 17 10:43:21 2010
New Revision: 166861

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=166861
Log:
2010-11-16  Richard Guenther  rguent...@suse.de

PR tree-optimization/46498
* tree-ssa-dce.c (perform_tree_ssa_dce): Compute dominator info.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-dce.c


[Bug c++/46513] Request: Warning for use of unsafe string handling functions

2010-11-17 Thread redi at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46513

--- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2010-11-17 
10:43:51 UTC ---
(In reply to comment #3)
 I know finding the replacement is not a GCC issue, but perhaps folks who 
 need
 to the *nix safe string gear can use TR24731-2 (not TR24731-1), which is POSIX
 and includes strl* and friends.

TR24731-2 does include functions from POSIX, but the only string handling ones
in n1337 are strdup and strndup, not strl* - and I might be wrong but I don't
know of any plans to add strl* to POSIX.

Besides, anything in C1x will not make it into a C++ standard for many years,
we're still trying to get C++0x finished and new features won't be added now. 
Maybe this request should be for the C front end?
Otherwise you're requesting warnings in C++ code about functions for which
there are no portable, standardised alternative available.


[Bug tree-optimization/46498] [4.5/4.6 Regression] ICE: in eliminate_unnecessary_stmts, at tree-ssa-dce.c:1112 with -O -funsafe-math-optimizations -fno-tree-dominator-opts -fno-tree-reassoc

2010-11-17 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46498

--- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-17 
10:46:40 UTC ---
Author: rguenth
Date: Wed Nov 17 10:46:36 2010
New Revision: 166862

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=166862
Log:
2010-11-17  Richard Guenther  rguent...@suse.de

PR tree-optimization/46498
* tree-ssa-dce.c (perform_tree_ssa_dce): Compute dominator info.

Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/tree-ssa-dce.c


[Bug middle-end/45838] [4.6 Regression] FAIL: libgomp.c/pr34513.c execution test

2010-11-17 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45838

--- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org 2010-11-17 
11:15:59 UTC ---
Author: jakub
Date: Wed Nov 17 11:15:55 2010
New Revision: 166863

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=166863
Log:
PR middle-end/45838
* tree-ssa-alias.c (ref_maybe_used_by_call_p_1,
call_may_clobber_ref_p_1): Return true for __sync_* and some
OpenMP builtins that act as threading barriers.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-alias.c


[Bug middle-end/45838] [4.6 Regression] FAIL: libgomp.c/pr34513.c execution test

2010-11-17 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45838

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org 2010-11-17 
11:18:18 UTC ---
Fixed.


[Bug tree-optimization/46498] [4.5/4.6 Regression] ICE: in eliminate_unnecessary_stmts, at tree-ssa-dce.c:1112 with -O -funsafe-math-optimizations -fno-tree-dominator-opts -fno-tree-reassoc

2010-11-17 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46498

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-17 
11:18:37 UTC ---
Fixed.


[Bug lto/46502] collect2 LTO marker detection is fragile wrt. to nm output format

2010-11-17 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46502

--- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-17 
11:41:11 UTC ---
The marker should be removed.


[Bug lto/46504] LTO failed on 483.xalancbmk in SPEC CPU 2006

2010-11-17 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46504

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2010.11.17 11:43:41
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-17 
11:43:41 UTC ---
Yep, I've seen this as well.  And I've caused this issue to pop up again.


[Bug c++/46513] Request: Warning for use of unsafe string handling functions

2010-11-17 Thread joseph at codesourcery dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46513

--- Comment #6 from joseph at codesourcery dot com joseph at codesourcery dot 
com 2010-11-17 11:50:16 UTC ---
On Wed, 17 Nov 2010, noloader at gmail dot com wrote:

 I stand corrected: C1X draft dated 2010-10-04 now includes the bounds checking
 interfaces. See C1X Draft,
 http://www.open-std.org/Jtc1/sc22/wg14/www/docs/n1516.pdf at
 http://www.open-std.org/Jtc1/sc22/wg14/www/projects.
 
 So in addition to [nearly ubiquitous] support for strlcpy and friends, we will
 have strcpy_s and friends.

I can't imagine glibc will want to have that set of functions in libc - I 
expect it will simply omit that optional set of interfaces and not define 
__STDC_LIB_EXT1__.  Maybe someone will write a glibc add-on putting them 
in a separate library that a handful of people might then use.

*Some* of the functions there are useful, but the notion that tmpfile (for 
example) has security issues requiring tmpfile_s is nonsense.  And the 
main utility of most of those functions is to retrofit security 
improvements to old code without understanding it.  glibc has its own 
means for such retrofitting (in particular _FORTIFY_SOURCE).  In both 
cases they are really a matter of reducing the risk from certain kinds of 
bugs rather than fixing them; to fix them, you need actually to understand 
the code and determine when you should avoid arbitrary limits and allocate 
as much memory as needed (taking care about overflow when calculating 
allocation sizes) and when you should impose limits and how you should 
handle overflow of them (quietly truncating is not generally a good 
approach); safer interfaces and _FORTIFY_SOURCE should then be used *on 
top of* proper design and calculation of allocations, to reduce the risk 
of any remaining bugs, rather than as a substitute for avoiding the 
possibility of overflow or truncation in the first place.

If you wish to enforce a coding standard disallowing certain functions in 
a particular code base, you are free to use existing GCC features such as 
#pragma GCC poison and the deprecated attribute.  That seems better to 
me than GCC embedding particular assumptions about a particular set of 
functions, when everyone will have their own preferences about what 
functions should be used and whether functions are safe in a given code 
base depends on how it uses them.


[Bug lto/46505] LTO miscompiled 416.gamess in SPEC CPU 2006

2010-11-17 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46505

--- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-17 
11:50:51 UTC ---
Hm, worked for me last time.  Re-checking with r166798.


[Bug lto/46506] LTO miscompiled 465.tonto in SPEC CPU 2006

2010-11-17 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46506

--- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-17 
11:51:23 UTC ---
Hm, worked for me last time.  Re-checking with r166798.


[Bug c/46509] -Wparentheses shouldn't warn about: A || Y foo

2010-11-17 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46509

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

   Severity|normal  |enhancement


[Bug middle-end/46510] [4.6 Regression] r166812 breaks bootstrap on x86_64-apple-darwin10

2010-11-17 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46510

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |4.6.0
Summary|r166812 breaks bootstrap on |[4.6 Regression] r166812
   |x86_64-apple-darwin10   |breaks bootstrap on
   ||x86_64-apple-darwin10


[Bug middle-end/46515] [4.6 Regression] Many libjava failures

2010-11-17 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46515

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0


[Bug driver/46516] Non-multilib search problem in gcc.c / gfortran error: libgfortran.spec: No such file or directory

2010-11-17 Thread joseph at codesourcery dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46516

--- Comment #12 from joseph at codesourcery dot com joseph at codesourcery dot 
com 2010-11-17 11:55:29 UTC ---
In http://gcc.gnu.org/ml/gcc-patches/2009-09/msg00826.html I discussed 
issues relating to finding specs in the presence of multilib paths.  I 
hope this - and Nathan Froyd's patch linked from there in particular, 
which solved the libgomp.spec issue - helps provide a roadmap for 
resolving the present issue.


[Bug lto/46505] LTO miscompiled 416.gamess in SPEC CPU 2006

2010-11-17 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46505

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.11.17 11:57:46
 Ever Confirmed|0   |1

--- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-17 
11:57:46 UTC ---
Confirmed.


[Bug testsuite/45429] [4.6 Regression] gcc.dg/vect/no-section-anchors-vect-64.c

2010-11-17 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45429

--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2010-11-17 
12:05:28 UTC ---
Author: jakub
Date: Wed Nov 17 12:05:24 2010
New Revision: 166865

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=166865
Log:
PR testsuite/45429
* gcc.dg/vect/no-section-anchors-vect-64.c: New test.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/no-section-anchors-vect-64.c


[Bug lto/46506] LTO miscompiled 465.tonto in SPEC CPU 2006

2010-11-17 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46506

--- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-17 
12:05:24 UTC ---
Tonto works for me.


[Bug c/46509] -Wparentheses shouldn't warn about: A || Y foo

2010-11-17 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46509

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2010-11-17 
12:07:43 UTC ---
Agreed, this is a terrible coding standard, I don't think we should try to
special case it.  It is much better if ()s are added.


[Bug testsuite/45429] [4.6 Regression] gcc.dg/vect/no-section-anchors-vect-64.c

2010-11-17 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45429

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2010-11-17 
12:15:48 UTC ---
Fixed.


[Bug middle-end/46515] [4.6 Regression] Many libjava failures

2010-11-17 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46515

H.J. Lu hjl.tools at gmail dot com changed:

   What|Removed |Added

 CC||rth at gcc dot gnu.org

--- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2010-11-17 12:51:20 
UTC ---
It is caused by revision 166829:

http://gcc.gnu.org/ml/gcc-cvs/2010-11/msg00718.html


[Bug middle-end/46515] [4.6 Regression] Many libjava failures

2010-11-17 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46515

--- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2010-11-17 12:53:39 
UTC ---
Failures look like

spawn [open ...]^M
FAIL: InterfaceDispatch -findirect-dispatch execution - source compiled test
UNTESTED: InterfaceDispatch -findirect-dispatch output - source compiled test


[Bug middle-end/46515] [4.6 Regression] Many libjava failures

2010-11-17 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46515

--- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2010-11-17 12:54:35 
UTC ---
It is on Linux/x86-64.


[Bug rtl-optimization/46440] [4.5/4.6 Regression] ICE: in rtl_verify_flow_info, at cfgrtl.c:2165 with -fstack-protector-all -fno-tree-dominator-opts -fno-tree-fre

2010-11-17 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46440

--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2010-11-17 
13:02:34 UTC ---
Author: jakub
Date: Wed Nov 17 13:02:31 2010
New Revision: 166867

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=166867
Log:
PR rtl-optimization/46440
* combine.c (update_cfg_for_uncondjump): When changing
an indirect jump into unconditional jump, remove BARRIERs
from bb's footer.

* gcc.dg/pr46440.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr46440.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/combine.c
trunk/gcc/testsuite/ChangeLog


[Bug rtl-optimization/46440] [4.5 Regression] ICE: in rtl_verify_flow_info, at cfgrtl.c:2165 with -fstack-protector-all -fno-tree-dominator-opts -fno-tree-fre

2010-11-17 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46440

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

  Known to work||4.6.0
Summary|[4.5/4.6 Regression] ICE:   |[4.5 Regression] ICE: in
   |in rtl_verify_flow_info, at |rtl_verify_flow_info, at
   |cfgrtl.c:2165 with  |cfgrtl.c:2165 with
   |-fstack-protector-all   |-fstack-protector-all
   |-fno-tree-dominator-opts|-fno-tree-dominator-opts
   |-fno-tree-fre   |-fno-tree-fre
  Known to fail|4.6.0   |

--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2010-11-17 
13:03:42 UTC ---
Fixed for 4.6 so far.


[Bug target/39064] libiberty md5.h needs uintptr_t

2010-11-17 Thread nightstrike at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39064

--- Comment #4 from nightstrike nightstrike at gmail dot com 2010-11-17 
13:13:44 UTC ---
*** Bug 46464 has been marked as a duplicate of this bug. ***


[Bug other/46464] libiberty pointer size assumptions for Win64 incorrect

2010-11-17 Thread nightstrike at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46464

nightstrike nightstrike at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #1 from nightstrike nightstrike at gmail dot com 2010-11-17 
13:13:44 UTC ---
Duplicate of: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39064

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


[Bug lto/46506] LTO miscompiled 465.tonto in SPEC CPU 2006

2010-11-17 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46506

--- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2010-11-17 13:19:07 
UTC ---
Created attachment 22429
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22429
The src.alt for 465.tonto

Can you try this alternate source for tonto with

-O3 -funroll-loops -ffast-math -fwhole-program -flto=jobserver
-fuse-linker-plugin


[Bug lto/46506] LTO miscompiled 465.tonto in SPEC CPU 2006

2010-11-17 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46506

--- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-17 
13:36:03 UTC ---
I have different alternate source, calling destroy_ptr_part_ instead.

But I can't parse the perl patch, so I'm not 100% sure.


[Bug rtl-optimization/45652] [4.6 Regression] gcc.dg/compat/scalar-by-value-3 FAILs with -O2 -fselective-scheduling2

2010-11-17 Thread ebotcazou at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45652

Eric Botcazou ebotcazou at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from Eric Botcazou ebotcazou at gcc dot gnu.org 2010-11-17 
14:05:45 UTC ---
P1 sounds a little overrated, it's a specialized option and an artificial test.
Only IA-64 really uses this thing, right?


[Bug rtl-optimization/45652] [4.6 Regression] gcc.dg/compat/scalar-by-value-3 FAILs with -O2 -fselective-scheduling2

2010-11-17 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45652

--- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-17 
14:08:01 UTC ---
(In reply to comment #5)
 P1 sounds a little overrated, it's a specialized option and an artificial 
 test.
 Only IA-64 really uses this thing, right?

All regressions towards the last release on primary or secondary targets
are P1 if they do not involve invalid source or checking-only problems.


[Bug rtl-optimization/45652] [4.6 Regression] gcc.dg/compat/scalar-by-value-3 FAILs with -O2 -fselective-scheduling2

2010-11-17 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45652

--- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-17 
14:08:35 UTC ---
Btw, the scheduler guys have a fix in the works already.


[Bug fortran/46518] New: internal compiler error: in vinsn_detach, at sel-sched-ir.c:1271

2010-11-17 Thread howarth at nitro dot med.uc.edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46518

   Summary: internal compiler error: in vinsn_detach, at
sel-sched-ir.c:1271
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: howa...@nitro.med.uc.edu


When using the --enable-build-with-cxx bootstrap on x86_64-apple-darwin10 with
the
patches...

http://gcc.gnu.org/ml/gcc-patches/2010-11/msg01323.html
http://gcc.gnu.org/ml/gcc-patches/2010-11/msg01803.html

a new ICE appears at -m32 for the gfortran.dg/pr42294.f  -O testcase. This
failure doesn't occur with a normal bootstrap and with the
--enable-build-with-cxx bootstrap is of the form...

Executing on host:
/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/testsuite/gfortran/../../gfortran
-B/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/testsuite/gfortran/../../
-L/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/x86_64-apple-darwin10.5.0/i386/libgfortran
/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20101116/gcc/testsuite/gfortran.dg/pr42294.f
  -O  -O2 -fselective-scheduling2 -fsel-sched-pipelining -funroll-all-loops -S 
-m32 -o pr42294.s(timeout = 300)
/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20101116/gcc/testsuite/gfortran.dg/pr42294.f:
In function 'orien':
/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20101116/gcc/testsuite/gfortran.dg/pr42294.f:39:0:
internal compiler error: in vinsn_detach, at sel-sched-ir.c:1271


[Bug middle-end/46518] internal compiler error: in vinsn_detach, at sel-sched-ir.c:1271

2010-11-17 Thread amonakov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46518

Alexander Monakov amonakov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #1 from Alexander Monakov amonakov at gcc dot gnu.org 2010-11-17 
14:51:24 UTC ---
Do you know whether this is present on x86_64-linux?


[Bug middle-end/46518] internal compiler error: in vinsn_detach, at sel-sched-ir.c:1271

2010-11-17 Thread howarth at nitro dot med.uc.edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46518

--- Comment #2 from Jack Howarth howarth at nitro dot med.uc.edu 2010-11-17 
14:52:42 UTC ---
Only occurs for -fPIC on x86_64-apple-darwin10. Adding -fno-PIC on darwin
suppresses the ICE.


[Bug target/46519] New: Missing vzeroupper

2010-11-17 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46519

   Summary: Missing vzeroupper
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: ubiz...@gmail.com


Created attachment 22430
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22430
A testcase

/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -O3 -funroll-loops -ffast-math
-mavx -Wno-multichar -S bad.c

.L531:
vmovapd %ymm0, (%rsp)
vzeroupper
callGet_Token
movlToken_Id(%rip), %eax
vmovapd (%rsp), %ymm0
cmpl$1, %eax
je  .L139
cmpl$2, %eax
je  .L541

L171:
vmovsd  (%rax), %xmm9
vsubsd  32(%rsp,%rcx,8), %xmm9, %xmm8
leal1(%rdx), %ecx
cmpl%ecx, %esi
vmovsd  %xmm8, (%rax)
jg  .L543
jmp .L531
.p2align 4,,10
.p2align 3
.L541:
leaq80(%rsp), %rsi 
movq%r12, %rdi 
callParse_Num_Term  missing vzeroupper
movl0(%r13), %esi 
movl80(%rsp), %eax 
vmovapd (%rsp), %ymm0
cmpl%eax, %esi


[Bug bootstrap/46086] fail to build gcc 4.5.2 on sparc64-portbld-freebsd9.0 - configure: error: cannot compute suffix of object files: cannot compile

2010-11-17 Thread mexas at bristol dot ac.uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46086

--- Comment #12 from Anton Shterenlikht mexas at bristol dot ac.uk 2010-11-17 
15:09:20 UTC ---
yes, GMP fails 14 tests:
http://seis.bris.ac.uk/~mexas/gmp-5.0.1-regression-test.log

I submitted a bug report to gmp-bugs.

MPFR passes all tests.

Sorry, I should've checked before.


[Bug middle-end/46518] internal compiler error: in vinsn_detach, at sel-sched-ir.c:1271

2010-11-17 Thread howarth at nitro dot med.uc.edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46518

--- Comment #3 from Jack Howarth howarth at nitro dot med.uc.edu 2010-11-17 
15:11:53 UTC ---
(In reply to comment #1)
 Do you know whether this is present on x86_64-linux?

I am unable to do a --enable-build-with-cxx bootstrap using...

http://gcc.gnu.org/ml/gcc-patches/2010-11/msg01323.html

on x86_64 Fedora10. The bootstrap still fails there with...

g++  -g -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H  -o lto1 \
lto/lto-lang.o lto/lto.o lto/lto-object.o attribs.o main.o
tree-browser.o libbackend.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a
-lcloog -lppl_c -lppl -lgmpxx -L/usr/lib -L/usr/lib -L/usr/lib -lmpc -lmpfr
-lgmp -rdynamic -ldl  -L../zlib -lz ../libcpp/libcpp.a  
../libiberty/libiberty.a ../libdecnumber/libdecnumber.a 
ld: crtbegin.o: No such file: No such file or directory
make[3]: *** [lto1] Error 1


[Bug c++/46497] [C++0x] [4.6 Regression] Defaulted vs declared move constructor vs is_convertible

2010-11-17 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46497

Paolo Carlini paolo.carlini at oracle dot com changed:

   What|Removed |Added

Summary|[C++0x] Defaulted vs|[C++0x] [4.6 Regression]
   |declared move constructor   |Defaulted vs declared move
   |vs is_convertible   |constructor vs
   ||is_convertible

--- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2010-11-17 
15:21:02 UTC ---
Barring evidence to the contrary, this is a regression: the testcase in Comment
#2 compiles with 4_5-branch.


[Bug middle-end/46518] internal compiler error: in vinsn_detach, at sel-sched-ir.c:1271

2010-11-17 Thread amonakov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46518

--- Comment #4 from Alexander Monakov amonakov at gcc dot gnu.org 2010-11-17 
15:29:33 UTC ---
(In reply to comment #2)
 Only occurs for -fPIC on x86_64-apple-darwin10. Adding -fno-PIC on darwin
 suppresses the ICE.

Is that in relation to bootstrap flags?  There's no PIC flags in the original
report.

The breakage is rather curious.  Build-with-CXX should not cause code
generation differences.  Can you please build normally-bootstrapped compiler
from the same source, build the testcase with the two compilers appending
-fdump-tree-all -fdump-rtl-all and attach the two series of dumps?


[Bug rtl-optimization/45652] [4.6 Regression] gcc.dg/compat/scalar-by-value-3 FAILs with -O2 -fselective-scheduling2

2010-11-17 Thread ebotcazou at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45652

--- Comment #8 from Eric Botcazou ebotcazou at gcc dot gnu.org 2010-11-17 
15:31:36 UTC ---
 Btw, the scheduler guys have a fix in the works already.

Then they should assign the PR to someone to avoid duplicating efforts.


[Bug driver/46516] Non-multilib search problem in gcc.c / gfortran error: libgfortran.spec: No such file or directory

2010-11-17 Thread burnus at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46516

--- Comment #13 from Tobias Burnus burnus at gcc dot gnu.org 2010-11-17 
15:32:34 UTC ---
Some debugging: While for libgfortran.spec and libgomp.spec the call to gcc.c's
find_a_file and thus to for_each_path is the same, the global variable
multilib_os_dir is NULL for libgfortran.spec and only later for libgomp.spec
(and thus too late) it is ../lib64



It is set in set_multilib_dir, which is too late:

main (int argc, char **argv)
{
  ...
// Get default setting, OK so far:
  specs_file = find_a_file (startfile_prefixes, specs, R_OK, true);


// This reads the file we want:
/* Process DRIVER_SELF_SPECS, adding any new options to the end
 of the command line.  */
  for (i = 0; i  ARRAY_SIZE (driver_self_specs); i++)
do_self_spec (driver_self_specs[i]);


// but ../lib64 is only set at:
  /* Now that we have the switches and the specs, set
 the subdirectory based on the options.  */
  set_multilib_dir ();


Frankly, I have no idea how to solve this interdependence.


[Bug middle-end/46518] internal compiler error: in vinsn_detach, at sel-sched-ir.c:1271

2010-11-17 Thread howarth at nitro dot med.uc.edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46518

--- Comment #5 from Jack Howarth howarth at nitro dot med.uc.edu 2010-11-17 
15:33:35 UTC ---
(In reply to comment #4)
 (In reply to comment #2)
  Only occurs for -fPIC on x86_64-apple-darwin10. Adding -fno-PIC on darwin
  suppresses the ICE.
 
 Is that in relation to bootstrap flags?  There's no PIC flags in the original
 report.
 

Darwin defaults to -fPIC unlike other targets.


[Bug rtl-optimization/45652] [4.6 Regression] gcc.dg/compat/scalar-by-value-3 FAILs with -O2 -fselective-scheduling2

2010-11-17 Thread amonakov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45652

Alexander Monakov amonakov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |amonakov at gcc dot gnu.org
   |gnu.org |

--- Comment #9 from Alexander Monakov amonakov at gcc dot gnu.org 2010-11-17 
15:39:57 UTC ---
(In reply to comment #8)
  Btw, the scheduler guys have a fix in the works already.
 
 Then they should assign the PR to someone to avoid duplicating efforts.

Sorry.  I'm testing the following patch.  There's no way to update
REG_BASE_VALUE from sel-sched on the fly, because it affects aliasing for
multiple MEMs (even off the code motion paths), making computed availability
sets inconsistent with new dependencies.

diff --git a/gcc/alias.c b/gcc/alias.c
index 2e0ac06..e79a780 100644
--- a/gcc/alias.c
+++ b/gcc/alias.c
@@ -1291,6 +1291,12 @@ record_set (rtx dest, const_rtx set, void *data
ATTRIBUTE_UNUSED)
   reg_seen[regno] = 1;
 }

+rtx
+get_reg_base_value (unsigned int regno)
+{
+  return VEC_index (rtx, reg_base_value, regno);
+}
+
 /* If a value is known for REGNO, return it.  */

 rtx
diff --git a/gcc/rtl.h b/gcc/rtl.h
index 3e1df2c..22721a2 100644
--- a/gcc/rtl.h
+++ b/gcc/rtl.h
@@ -2508,6 +2508,7 @@ extern rtx find_base_term (rtx);
 extern rtx gen_hard_reg_clobber (enum machine_mode, unsigned int);
 extern rtx get_reg_known_value (unsigned int);
 extern bool get_reg_known_equiv_p (unsigned int);
+extern rtx get_reg_base_value (unsigned int);

 #ifdef STACK_REGS
 extern int stack_regs_mentioned (const_rtx insn);
diff --git a/gcc/sel-sched.c b/gcc/sel-sched.c
index 70e831d..544348c 100644
--- a/gcc/sel-sched.c
+++ b/gcc/sel-sched.c
@@ -1139,6 +1139,8 @@ init_regs_for_mode (enum machine_mode mode)
 /* Can't use regs which aren't saved by
the prologue.  */
 || !TEST_HARD_REG_BIT (sel_hrd.regs_ever_used, cur_reg + i)
+|| get_reg_base_value (cur_reg + i)
 #ifdef LEAF_REGISTERS
 /* We can't use a non-leaf register if we're in a
leaf function.  */


[Bug middle-end/46518] internal compiler error: in vinsn_detach, at sel-sched-ir.c:1271

2010-11-17 Thread howarth at nitro dot med.uc.edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46518

--- Comment #6 from Jack Howarth howarth at nitro dot med.uc.edu 2010-11-17 
15:44:38 UTC ---
(In reply to comment #4)
 (In reply to comment #2)
  Only occurs for -fPIC on x86_64-apple-darwin10. Adding -fno-PIC on darwin
  suppresses the ICE.
 
 Is that in relation to bootstrap flags?  There's no PIC flags in the original
 report.
 
 The breakage is rather curious.  Build-with-CXX should not cause code
 generation differences.  Can you please build normally-bootstrapped compiler
 from the same source, build the testcase with the two compilers appending
 -fdump-tree-all -fdump-rtl-all and attach the two series of dumps?

Under x86_64 Fedora 10 using...

../gcc/configure --with-gmp=/usr --with-mpfr=/usr --with-mpc=/usr
--prefix=/home/howarth/dist --enable-languages=c,c++,fortran
--enable-build-with-cxx --disable-lto --disable-bootstrap

I get a slightly different crash (which might not be surprising since the
compiler isn't built entirely with -fPIC like on darwin).

Executing on host: /home/howarth/work/gcc/testsuite/gfortran/../../gfortran
-B/home/howarth/work/gcc/testsuite/gfortran/../../
-L/home/howarth/work/x86_64-unknown-linux-gnu/32/libgfor
tran /home/howarth/gcc/gcc/testsuite/gfortran.dg/pr42294.f   -O  -O2
-fselective-scheduling2 -fsel-sched-pipelining -funroll-all-loops -S  -m32 -o
pr42294.s(timeout = 300)
/home/howarth/gcc/gcc/testsuite/gfortran.dg/pr42294.f: In function 'orien':
/home/howarth/gcc/gcc/testsuite/gfortran.dg/pr42294.f:39:0: internal compiler
error: Segmentation fault


[Bug lto/46504] LTO failed on 483.xalancbmk in SPEC CPU 2006

2010-11-17 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46504

--- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-17 
15:47:20 UTC ---
Author: rguenth
Date: Wed Nov 17 15:47:17 2010
New Revision: 166870

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=166870
Log:
2010-11-17  Richard Guenther  rguent...@suse.de

PR lto/46504
* gimple.c (gimple_register_canonical_type): Make sure to only
make type leaders canonical types.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple.c


[Bug fortran/46520] New: libquadmath: Build also with --enable-languages=c; fails with some cross targets

2010-11-17 Thread burnus at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46520

   Summary: libquadmath: Build also with --enable-languages=c;
fails with some cross targets
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org


Seemingly, libquadmath is also build with  --enable-languages=c  only;
currently, it shouldn't.

Possibly solved by:

--- gcc/fortran/config-lang.in  (revision 166859)
+++ gcc/fortran/config-lang.in  (working copy)
@@ -30 +30 @@ compilers=f951\$(exeext)
-target_libs=target-libgfortran
+target_libs=target-libquadmath target-libgfortran



Additionally, it fails to configure at some link test with
  --enable-languages=c --target=moxie-elf
which is a pure target board.

Ian wrote in #gcc:
  according to antgreen, the libquadmath configure script expects to
  be able to link an executable


[Bug rtl-optimization/46521] New: ICE: in reset_sched_cycles_in_current_ebb, at sel-sched.c:7092 with -Os -fselective-scheduling2 -fsel-sched-pipelining -fprofile-generate -fno-early-inlining

2010-11-17 Thread zsojka at seznam dot cz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46521

   Summary: ICE: in reset_sched_cycles_in_current_ebb, at
sel-sched.c:7092 with -Os -fselective-scheduling2
-fsel-sched-pipelining -fprofile-generate
-fno-early-inlining
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


Created attachment 22431
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22431
reduced testcase

One of testcases for PR45352 fails with -fno-early-inlining:

$ gcc -Os -fselective-scheduling2 -fsel-sched-pipelining -fprofile-generate
-fno-early-inlining pr45352.i  
/mnt/svn/gcc-trunk/gcc/testsuite/gcc.dg/pr45352.c: In function 'df_md_alloc':
/mnt/svn/gcc-trunk/gcc/testsuite/gcc.dg/pr45352.c:24:1: internal compiler
error: in reset_sched_cycles_in_current_ebb, at sel-sched.c:7092
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.

The attached more reduced testcase fails the same way:
$ gcc -Os -fselective-scheduling2 -fsel-sched-pipelining -fprofile-generate
-fno-early-inlining pr46521.c 
pr46521.c: In function 'df_md_alloc':
pr46521.c:17:1: internal compiler error: in reset_sched_cycles_in_current_ebb,
at sel-sched.c:7092
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.

I verified the testcase doesn't give any warnings with -Wall -W.

Tested revisions:
r166795 - crash
4.5 r166509 - crash
4.4 r166509 - crash


[Bug lto/46504] LTO failed on 483.xalancbmk in SPEC CPU 2006

2010-11-17 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46504

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-17 
15:57:29 UTC ---
Fixed.


[Bug rtl-optimization/46522] New: ICE: in reset_sched_cycles_in_current_ebb, at sel-sched.c:7092 with -O3 -fsel-sched-pipelining -fselective-scheduling2 -funroll-loops

2010-11-17 Thread zsojka at seznam dot cz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46522

   Summary: ICE: in reset_sched_cycles_in_current_ebb, at
sel-sched.c:7092 with -O3 -fsel-sched-pipelining
-fselective-scheduling2 -funroll-loops
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


Created attachment 22432
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22432
reduced testcase (originally PR45352 comment #19)

I am sorry for the amount of compiler flags, removing any of them causes the
ICE to disappear. Even manual partial inlining, unrolling, loop unswitching,
... either removes the ICE or doesn't allow me to remove further flags.

Flags are either:
-O3 -fkeep-inline-functions -fsel-sched-pipelining -fselective-scheduling2
-funroll-loops
or
-O2 -fkeep-inline-functions -fsel-sched-pipelining -fselective-scheduling2
-funroll-loops -funswitch-loops
or
-O1 -fcse-follow-jumps -fkeep-inline-functions -fpartial-inlining
-freorder-blocks -frerun-cse-after-loop -fschedule-insns2
-fsel-sched-pipelining -fselective-scheduling2 -funroll-loops -funswitch-loops

Compiler output:
$ gcc -O3 -fkeep-inline-functions -fsel-sched-pipelining
-fselective-scheduling2 -funroll-loops pr46522.c
pr46522.c: In function 'foo2':
pr46522.c:30:1: internal compiler error: in reset_sched_cycles_in_current_ebb,
at sel-sched.c:7092
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.

Tested revisions (for the -O1 case):
r166795 - crash
r165699 - OK
4.5 - doesn't know -fpartial-inlining


[Bug c/20385] Lame parse error message for undefined type

2010-11-17 Thread bonzini at gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20385

--- Comment #9 from Paolo Bonzini bonzini at gnu dot org 2010-11-17 16:14:32 
UTC ---
Another case in which we still do not detect the unsigned type is after
declspecs:

typedef uintt16_t pid_t;
extern uintt16_t x;

I think that until this is fixed, there are still enough bad cases that it's
not worth putting it into the release notes.


[Bug rtl-optimization/45352] ICE: in reset_sched_cycles_in_current_ebb, at sel-sched.c:7058

2010-11-17 Thread zsojka at seznam dot cz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45352

Zdenek Sojka zsojka at seznam dot cz changed:

   What|Removed |Added

  Attachment #22334|0   |1
is obsolete||

--- Comment #20 from Zdenek Sojka zsojka at seznam dot cz 2010-11-17 16:15:34 
UTC ---
Comment on attachment 22334
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22334
testcase failing in r166433

Opened PR46521 and PR46522 for the new two testcases. This one wasn't really
reduced anyway. I also verified the new testcases don't give any warning with
-Wall -Wextra.

I hope this will make the situation more clear and allow this PR to be closed.


[Bug c++/46497] [C++0x] Defaulted vs declared move constructor vs is_convertible

2010-11-17 Thread jason at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46497

Jason Merrill jason at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
Summary|[C++0x] [4.6 Regression]|[C++0x] Defaulted vs
   |Defaulted vs declared move  |declared move constructor
   |constructor vs  |vs is_convertible
   |is_convertible  |

--- Comment #6 from Jason Merrill jason at gcc dot gnu.org 2010-11-17 
16:15:44 UTC ---
The difference between the user-written and =default versions is one of delayed
vs. immediate failure.  With a defaulted constructor, at declaration time we
perform overload resolution and determine that we can't move 'first', so the
pairconst move_only move constructor is deleted.  We can't do that for a
user-written constructor, so we assume that it's OK, and give an error later
when we actually try to instantiate the move constructor.

So =default makes the ill-formedness available to SFINAE (pairconst move_only
doesn't look move-constructible), whereas an explicitly written constructor
does not (it looks move-constructible but moving it causes an error).

In 4.5, move_only has an implicitly-declared copy constructor, so it is not a
move-only type.  Explicitly deleting the copy constructor produces the expected
errors.


[Bug middle-end/46510] [4.6 Regression] r166812 breaks bootstrap on x86_64-apple-darwin10

2010-11-17 Thread hubicka at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46510

Jan Hubicka hubicka at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2010.11.17 16:21:39
 Ever Confirmed|0   |1

--- Comment #5 from Jan Hubicka hubicka at gcc dot gnu.org 2010-11-17 
16:21:39 UTC ---
Can you, please, try if the following works?
Index: tree-emutls.c
===
--- tree-emutls.c   (revision 166864)
+++ tree-emutls.c   (working copy)
@@ -324,7 +324,8 @@ new_emutls_decl (tree decl)
   record_references_in_initializer (to, false);
 }

-  varpool_finalize_decl (to);
+  if (!DECL_EXTERNAL (to))
+varpool_finalize_decl (to);
   return to;
 }

We should not finalize external vars.


[Bug middle-end/46518] internal compiler error: in vinsn_detach, at sel-sched-ir.c:1271

2010-11-17 Thread howarth at nitro dot med.uc.edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46518

--- Comment #7 from Jack Howarth howarth at nitro dot med.uc.edu 2010-11-17 
16:22:20 UTC ---
Under x86_64 Fedora, when built with...

../gcc/configure --with-gmp=/usr --with-mpfr=/usr --with-mpc=/usr
--prefix=/home/howarth/dist --enable-languages=c,c++,fortran
--enable-build-with-cxx --disable-lto

I get failure...

Executing on host: /home/howarth/work/gcc/testsuite/gfortran/../../gfortran
-B/home/howarth/work/gcc/testsuite/gfortran/../../
-L/home/howarth/work/x86_64-unknown-linux-gnu/32/libgfor
tran /home/howarth/gcc/gcc/testsuite/gfortran.dg/pr42294.f   -O  -O2
-fselective-scheduling2 -fsel-sched-pipelining -funroll-all-loops -S  -m32 -o
pr42294.s(timeout = 300)
/home/howarth/gcc/gcc/testsuite/gfortran.dg/pr42294.f: In function 'orien':
/home/howarth/gcc/gcc/testsuite/gfortran.dg/pr42294.f:39:0: internal compiler
error: Segmentation fault

This backtraces as...


gdb /home/howarth/work/gcc/testsuite/gfortran/../../f951
GNU gdb Fedora (6.8-32.fc10)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type show copying
and show warranty for details.
This GDB was configured as x86_64-redhat-linux-gnu...
(gdb) r /home/howarth/gcc/gcc/testsuite/gfortran.dg/pr42294.f -ffixed-form
-quiet -dumpbase pr42294.f -m32 -mtune=generic -march=x86-64 -auxbase-strip
pr42294.s -O -O2 -version -fselective-scheduling2 -fsel-sched-pipelining
-funroll-all-loops -o pr42294.s -fintrinsic-modules-path finclude
Starting program: /home/howarth/work/gcc/f951
/home/howarth/gcc/gcc/testsuite/gfortran.dg/pr42294.f -ffixed-form -quiet
-dumpbase pr42294.f -m32 -mtune=generic -march=x86-64 -auxbase-strip pr42294.s
-O -O2 -version -fselective-scheduling2 -fsel-sched-pipelining
-funroll-all-loops -o pr42294.s -fintrinsic-modules-path finclude
GNU Fortran (GCC) version 4.6.0 20101117 (experimental)
(x86_64-unknown-linux-gnu)
compiled by GNU C version 4.6.0 20101117 (experimental), GMP version 4.2.2,
MPFR version 2.3.2, MPC version 0.8
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU Fortran (GCC) version 4.6.0 20101117 (experimental)
(x86_64-unknown-linux-gnu)
compiled by GNU C version 4.6.0 20101117 (experimental), GMP version 4.2.2,
MPFR version 2.3.2, MPC version 0.8
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096

Program received signal SIGSEGV, Segmentation fault.
vinsn_detach (vi=0x0) at ../../gcc/gcc/sel-sched-ir.c:1271
1271  gcc_assert (VINSN_COUNT (vi)  0);
Current language:  auto; currently c++
Missing separate debuginfos, use: debuginfo-install
cloog-ppl-0.15.8-2f10.x86_64 gmp-4.2.2-8.fc10.x86_64 libgcc-4.3.2-7.x86_64
libmpc-0.8-3.fc10.x86_64 libstdc++-4.3.2-7.x86_64 mpfr-2.3.2-1.fc10.x86_64
ppl-0.10.2-6.fc10.x86_64
(gdb) bt
#0  vinsn_detach (vi=0x0) at ../../gcc/gcc/sel-sched-ir.c:1271
#1  0x00823e6c in clear_expr (expr=0x7fffdcd0) at
../../gcc/gcc/sel-sched-ir.c:1864
#2  0x00839bc6 in schedule_expr_on_boundary (bnd=value optimized out,
expr_vliw=0x15173c0, seqno=-1) at ../../gcc/gcc/sel-sched.c:5435
#3  0x0083aa1c in fill_insns (scheduled_insns_tailpp=Unhandled dwarf
expression opcode 0xf2
) at ../../gcc/gcc/sel-sched.c:5576
#4  schedule_on_fences (scheduled_insns_tailpp=Unhandled dwarf expression
opcode 0xf2
) at ../../gcc/gcc/sel-sched.c:7298
#5  sel_sched_region_2 (orig_max_seqno=51) at ../../gcc/gcc/sel-sched.c:7432
#6  0x0083e30f in sel_sched_region_1 () at
../../gcc/gcc/sel-sched.c:7476
#7  sel_sched_region (rgn=value optimized out) at
../../gcc/gcc/sel-sched.c:7575
#8  0x014cd7e0 in ?? ()
#9  0x01f8 in ?? ()
#10 0x0100 in ?? ()
#11 0x014cd7f0 in ?? ()
#12 0x0200 in ?? ()
#13 0x003099a7bfc7 in _int_realloc (av=0x101010101010101, oldmem=0x1,
bytes=value optimized out) at malloc.c:5083
#14 0x003099a7cfbe in __libc_realloc (oldmem=0x14bfd90, bytes=504) at
malloc.c:3708
#15 0x005b8137 in bitmap_copy (to=0x12f6001, from=0x1f8) at
../../gcc/gcc/bitmap.c:517
#16 0x0034 in ?? ()
#17 0xfff8 in ?? ()
#18 0x in ?? ()


[Bug driver/46516] Non-multilib search problem in gcc.c / gfortran error: libgfortran.spec: No such file or directory

2010-11-17 Thread burnus at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46516

--- Comment #14 from Tobias Burnus burnus at gcc dot gnu.org 2010-11-17 
16:25:56 UTC ---
Suggested solution from Joseph on #gcc:

- get rid of the spec file (hooray!)
- Add a configure test. One needs to make sure that both the compiler supports
__float128 and the libgcc library support it.

If I read the files correctly, the latter is set via
  libgcc/config.host
There is also the adjunct file
  gcc/config.gcc

I am not 100% sure whether I understood the syntax; however, there is
t-softfp in libgcc and soft-fp/t-softfp in gcc; I do not yet quite understand
how they relate and whether that's the correct information; in any case, it is
not sufficient as t-softfp is also present for PowerPC, which has a hardware
128-bit FP type.


[Bug tree-optimization/46523] New: [4.6 Regression] ICE: error: inlined_to pointer set for noninline callers, multiple inline callers

2010-11-17 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46523

   Summary: [4.6 Regression] ICE: error: inlined_to pointer set
for noninline callers, multiple inline callers
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org
CC: hubi...@gcc.gnu.org
Target: i?86-*-linux


kdevelop4 fails to build with

./cc1plus  -quiet -m32 cppduchain.ii -O2 -std=c++0x
/usr/src/packages/BUILD/kdevelop-4.1.0/languages/cpp/cppduchain/cppduchain.cpp:839:1:
error: inlined_to pointer set for noninline callers
/usr/src/packages/BUILD/kdevelop-4.1.0/languages/cpp/cppduchain/cppduchain.cpp:839:1:
error: multiple inline callers
virtual KDevelop::AbstractType::Ptr
Cpp::shortenTypeForViewing(KDevelop::AbstractType::Ptr)::ShortenAliasExchanger::exchange(const
Ptr)/3542(2949) @0x71510b00 (asm:
_ZZN3Cpp21shortenTypeForViewingE7TypePtrIN8KDevelop12AbstractTypeEEEN21ShortenAliasExchanger8exchangeERKS3_)
(inline copy in KDevelop::AbstractType::Ptr
Cpp::shortenTypeForViewing(KDevelop::AbstractType::Ptr)/3553)
availability:local analyzed 162 time, 17 benefit (175 after inlining) 212 size,
11 benefit (270 after inlining) 36 bytes stack usage reachable body local
finalized inlinable
  called by: virtual KDevelop::AbstractType::Ptr
Cpp::shortenTypeForViewing(KDevelop::AbstractType::Ptr)::ShortenAliasExchanger::exchange(const
Ptr)/3542 (0.59 per call) (indirect_inlining) virtual
KDevelop::AbstractType::Ptr
Cpp::shortenTypeForViewing(KDevelop::AbstractType::Ptr)::ShortenAliasExchanger::_ZZN3Cpp21shortenTypeForViewingE7TypePtrIN8KDevelop12AbstractTypeEEEN21ShortenAliasExchanger8exchangeERKS3_.constprop.103(const
Ptr)/112 (0.59 per call) (inlined) (can throw external) 
  calls: virtual KDevelop::AbstractType::Ptr
Cpp::shortenTypeForViewing(KDevelop::AbstractType::Ptr)::ShortenAliasExchanger::exchange(const
Ptr)/3542 (indirect_inlining) (0.59 per call) TypePtrT::~TypePtr() [with T =
KDevelop::AbstractType]/2383 TypePtrT::~TypePtr() [with T =
KDevelop::TypeAliasType]/4390 TypePtrT::~TypePtr() [with T =
KDevelop::AbstractType]/2383 QString::~QString()/537 QString::~QString()/537
QString::~QString()/537 QString::~QString()/537 TypePtrT::~TypePtr() [with T
= KDevelop::AbstractType]/2383 TypePtrT::~TypePtr() [with T =
KDevelop::AbstractType]/2383 (0.41 per call) (can throw external)
TypePtrT::~TypePtr() [with T = KDevelop::TypeAliasType]/5307 (inlined) (0.41
per call) TypePtrT::~TypePtr() [with T = KDevelop::AbstractType]/2383 (0.17
per call) TypePtrT::~TypePtr() [with T = KDevelop::AbstractType]/2383 (0.17
per call) void KDevelop::AbstractType::setModifiers(quint64)/5473 (0.17 per
call) quint64 KDevelop::AbstractType::modifiers() const/5425 (0.17 per call)
quint64 KDevelop::AbstractType::modifiers() const/5425 (0.17 per call)
QString::~QString()/4859 (inlined) (0.10 per call) QString::~QString()/4375
(inlined) (0.10 per call) QString::~QString()/4373 (inlined) (0.10 per call)
QString::~QString()/4378 (inlined) (0.10 per call) int
Cpp::reservedIdentifierCount(QString)/3541 (0.07 per call) int
Cpp::reservedIdentifierCount(QString)/3541 (0.07 per call) int
QString::count(QChar, Qt::CaseSensitivity) const/5472 (0.24 per call)
QChar::QChar(char)/5471 (0.24 per call) int QString::count(QChar,
Qt::CaseSensitivity) const/5472 (0.24 per call) QChar::QChar(char)/5471 (0.24
per call) TypePtrT::~TypePtr() [with T = KDevelop::AbstractType]/2383 (0.35
per call) KDevelop::AbstractType::Ptr KDevelop::TypeAliasType::type()
const/5435 (0.35 per call) TypePtrU TypePtrT::cast(U*) const [with U =
KDevelop::TypeAliasType, T = KDevelop::AbstractType]/141 (inlined) (0.41 per
call) 
  References: 
  Refering this function: 
  has 6 outgoing edges for indirect calls.
/usr/src/packages/BUILD/kdevelop-4.1.0/languages/cpp/cppduchain/cppduchain.cpp:839:1:
internal compiler error: verify_cgraph_node failed
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.


[Bug tree-optimization/46523] [4.6 Regression] ICE: error: inlined_to pointer set for noninline callers, multiple inline callers

2010-11-17 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46523

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0

--- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-17 
16:28:57 UTC ---
Reducing.


[Bug middle-end/46510] [4.6 Regression] r166812 breaks bootstrap on x86_64-apple-darwin10

2010-11-17 Thread howarth at nitro dot med.uc.edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46510

--- Comment #6 from Jack Howarth howarth at nitro dot med.uc.edu 2010-11-17 
16:34:33 UTC ---
(In reply to comment #5)
 Can you, please, try if the following works?
 Index: tree-emutls.c
 ===
 --- tree-emutls.c   (revision 166864)
 +++ tree-emutls.c   (working copy)
 @@ -324,7 +324,8 @@ new_emutls_decl (tree decl)
record_references_in_initializer (to, false);
  }
 
 -  varpool_finalize_decl (to);
 +  if (!DECL_EXTERNAL (to))
 +varpool_finalize_decl (to);
return to;
  }
 
 We should not finalize external vars.

Converts the ICE to a segfault...

libtool: compile:  /sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/./gcc/xgcc
-B/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/./gcc/
-B/sw/lib/gcc4.6/x86_64-apple-darwin10.5.0/bin/
-B/sw/lib/gcc4.6/x86_64-apple-darwin10.5.0/lib/ -isystem
/sw/lib/gcc4.6/x86_64-apple-darwin10.5.0/include -isystem
/sw/lib/gcc4.6/x86_64-apple-darwin10.5.0/sys-include -DHAVE_CONFIG_H -I.
-I../../../gcc-4.6-20101117/libgomp
-I../../../gcc-4.6-20101117/libgomp/config/bsd
-I../../../gcc-4.6-20101117/libgomp/config/posix
-I../../../gcc-4.6-20101117/libgomp -Wall -pthread -Werror -g -O2 -MT loop.lo
-MD -MP -MF .deps/loop.Tpo -c ../../../gcc-4.6-20101117/libgomp/loop.c 
-fno-common -DPIC -o .libs/loop.o
../../../gcc-4.6-20101117/libgomp/barrier.c: In function 'GOMP_barrier':
../../../gcc-4.6-20101117/libgomp/barrier.c:41:1: internal compiler error:
Segmentation fault


[Bug middle-end/46518] internal compiler error: in vinsn_detach, at sel-sched-ir.c:1271

2010-11-17 Thread howarth at nitro dot med.uc.edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46518

--- Comment #8 from Jack Howarth howarth at nitro dot med.uc.edu 2010-11-17 
16:37:14 UTC ---
Backtraces as...

gdb /sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/./gcc/cc1
...
(gdb) r -quiet -v -I . -I ../../../gcc-4.6-20101117/libgomp -I
../../../gcc-4.6-20101117/libgomp/config/bsd -I
../../../gcc-4.6-20101117/libgomp/config/posix -I
../../../gcc-4.6-20101117/libgomp -iprefix
/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/../lib/gcc/x86_64-apple-darwin10.5.0/4.6.0/
-isystem /sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/./gcc/include
-isystem /sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/./gcc/include-fixed
-MD .libs/barrier.d -MF .deps/barrier.Tpo -MP -MT barrier.lo -D__DYNAMIC__
-D_REENTRANT -D HAVE_CONFIG_H -D PIC -isystem
/sw/lib/gcc4.6/x86_64-apple-darwin10.5.0/include -isystem
/sw/lib/gcc4.6/x86_64-apple-darwin10.5.0/sys-include
../../../gcc-4.6-20101117/libgomp/barrier.c -fPIC
-feliminate-unused-debug-symbols -quiet -dumpbase barrier.c
-mmacosx-version-min=10.6.5 -mtune=generic -auxbase-strip .libs/barrier.o -g
-O2 -Wall -Werror -version -fno-common -o /var/tmp//cckhMI20.s
...

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x
0x0001009e08b2 in gen_emutls_addr (decl=0x14340a8c0, d=0x7fff5fbfe650) at
../../gcc-4.6-20101117/gcc/tree-emutls.c:418
418  cdecl = cvar-decl;
(gdb) bt
#0  0x0001009e08b2 in gen_emutls_addr (decl=0x14340a8c0, d=0x7fff5fbfe650)
at ../../gcc-4.6-20101117/gcc/tree-emutls.c:418
#1  0x0001009e1181 in lower_emutls_1 (ptr=0x1434d86a8,
walk_subtrees=0x7fff5fbfdd9c, cb_data=0x7fff5fbfe5a0) at
../../gcc-4.6-20101117/gcc/tree-emutls.c:527
#2  0x000100c29101 in walk_tree_1 (tp=0x1434d86a8, func=0x1009e0d5e
lower_emutls_1, data=0x7fff5fbfe5a0, pset=0x0, lh=0) at
../../gcc-4.6-20101117/gcc/tree.c:10241
#3  0x000100c2b9b5 in walk_tree_1 (tp=0x1434d86e8, func=0x1009e0d5e
lower_emutls_1, data=0x7fff5fbfe5a0, pset=0x0, lh=0) at
../../gcc-4.6-20101117/gcc/tree.c:10490
#4  0x000100c2b9b5 in walk_tree_1 (tp=0x1434ff688, func=0x1009e0d5e
lower_emutls_1, data=0x7fff5fbfe5a0, pset=0x0, lh=0) at
../../gcc-4.6-20101117/gcc/tree.c:10490
#5  0x0001006960b8 in walk_gimple_op (stmt=0x1434ff640,
callback_op=0x1009e0d5e lower_emutls_1, wi=0x7fff5fbfe5a0) at
../../gcc-4.6-20101117/gcc/gimple.c:1361
#6  0x0001009e1468 in lower_emutls_stmt (stmt=0x1434ff640,
d=0x7fff5fbfe650) at ../../gcc-4.6-20101117/gcc/tree-emutls.c:557
#7  0x0001009e1a1f in lower_emutls_function_body (node=0x1434d7dc0) at
../../gcc-4.6-20101117/gcc/tree-emutls.c:663
#8  0x0001009e2318 in ipa_lower_emutls () at
../../gcc-4.6-20101117/gcc/tree-emutls.c:765
#9  0x00010084eed2 in execute_one_pass (pass=0x1010ab3a0) at
../../gcc-4.6-20101117/gcc/passes.c:1564
#10 0x00010084fee3 in execute_ipa_pass_list (pass=0x1010ab3a0) at
../../gcc-4.6-20101117/gcc/passes.c:1931
#11 0x000100cdf555 in ipa_passes () at
../../gcc-4.6-20101117/gcc/cgraphunit.c:1696
#12 0x000100cdf738 in cgraph_optimize () at
../../gcc-4.6-20101117/gcc/cgraphunit.c:1765
#13 0x000100cdcad5 in cgraph_finalize_compilation_unit () at
../../gcc-4.6-20101117/gcc/cgraphunit.c:1017
#14 0x000100030c41 in c_write_global_declarations () at
../../gcc-4.6-20101117/gcc/c-decl.c:9837
#15 0x000100969368 in compile_file () at
../../gcc-4.6-20101117/gcc/toplev.c:882
#16 0x00010096c470 in do_compile () at
../../gcc-4.6-20101117/gcc/toplev.c:2313
#17 0x00010096c5b8 in toplev_main (argc=54, argv=0x7fff5fbfe950) at
../../gcc-4.6-20101117/gcc/toplev.c:2374
#18 0x000100115548 in main (argc=54, argv=0x7fff5fbfe950) at
../../gcc-4.6-20101117/gcc/main.c:36


[Bug middle-end/46518] internal compiler error: in vinsn_detach, at sel-sched-ir.c:1271

2010-11-17 Thread howarth at nitro dot med.uc.edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46518

--- Comment #9 from Jack Howarth howarth at nitro dot med.uc.edu 2010-11-17 
16:38:11 UTC ---
sorry...comment 8 ended up in the wrong PR


[Bug middle-end/46510] [4.6 Regression] r166812 breaks bootstrap on x86_64-apple-darwin10

2010-11-17 Thread howarth at nitro dot med.uc.edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46510

--- Comment #7 from Jack Howarth howarth at nitro dot med.uc.edu 2010-11-17 
16:38:47 UTC ---
Backtraces as...

gdb /sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/./gcc/cc1
...
(gdb) r -quiet -v -I . -I ../../../gcc-4.6-20101117/libgomp -I
../../../gcc-4.6-20101117/libgomp/config/bsd -I
../../../gcc-4.6-20101117/libgomp/config/posix -I
../../../gcc-4.6-20101117/libgomp -iprefix
/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/../lib/gcc/x86_64-apple-darwin10.5.0/4.6.0/
-isystem /sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/./gcc/include
-isystem /sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/./gcc/include-fixed
-MD .libs/barrier.d -MF .deps/barrier.Tpo -MP -MT barrier.lo -D__DYNAMIC__
-D_REENTRANT -D HAVE_CONFIG_H -D PIC -isystem
/sw/lib/gcc4.6/x86_64-apple-darwin10.5.0/include -isystem
/sw/lib/gcc4.6/x86_64-apple-darwin10.5.0/sys-include
../../../gcc-4.6-20101117/libgomp/barrier.c -fPIC
-feliminate-unused-debug-symbols -quiet -dumpbase barrier.c
-mmacosx-version-min=10.6.5 -mtune=generic -auxbase-strip .libs/barrier.o -g
-O2 -Wall -Werror -version -fno-common -o /var/tmp//cckhMI20.s
...

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x
0x0001009e08b2 in gen_emutls_addr (decl=0x14340a8c0, d=0x7fff5fbfe650) at
../../gcc-4.6-20101117/gcc/tree-emutls.c:418
418  cdecl = cvar-decl;
(gdb) bt
#0  0x0001009e08b2 in gen_emutls_addr (decl=0x14340a8c0, d=0x7fff5fbfe650)
at ../../gcc-4.6-20101117/gcc/tree-emutls.c:418
#1  0x0001009e1181 in lower_emutls_1 (ptr=0x1434d86a8,
walk_subtrees=0x7fff5fbfdd9c, cb_data=0x7fff5fbfe5a0) at
../../gcc-4.6-20101117/gcc/tree-emutls.c:527
#2  0x000100c29101 in walk_tree_1 (tp=0x1434d86a8, func=0x1009e0d5e
lower_emutls_1, data=0x7fff5fbfe5a0, pset=0x0, lh=0) at
../../gcc-4.6-20101117/gcc/tree.c:10241
#3  0x000100c2b9b5 in walk_tree_1 (tp=0x1434d86e8, func=0x1009e0d5e
lower_emutls_1, data=0x7fff5fbfe5a0, pset=0x0, lh=0) at
../../gcc-4.6-20101117/gcc/tree.c:10490
#4  0x000100c2b9b5 in walk_tree_1 (tp=0x1434ff688, func=0x1009e0d5e
lower_emutls_1, data=0x7fff5fbfe5a0, pset=0x0, lh=0) at
../../gcc-4.6-20101117/gcc/tree.c:10490
#5  0x0001006960b8 in walk_gimple_op (stmt=0x1434ff640,
callback_op=0x1009e0d5e lower_emutls_1, wi=0x7fff5fbfe5a0) at
../../gcc-4.6-20101117/gcc/gimple.c:1361
#6  0x0001009e1468 in lower_emutls_stmt (stmt=0x1434ff640,
d=0x7fff5fbfe650) at ../../gcc-4.6-20101117/gcc/tree-emutls.c:557
#7  0x0001009e1a1f in lower_emutls_function_body (node=0x1434d7dc0) at
../../gcc-4.6-20101117/gcc/tree-emutls.c:663
#8  0x0001009e2318 in ipa_lower_emutls () at
../../gcc-4.6-20101117/gcc/tree-emutls.c:765
#9  0x00010084eed2 in execute_one_pass (pass=0x1010ab3a0) at
../../gcc-4.6-20101117/gcc/passes.c:1564
#10 0x00010084fee3 in execute_ipa_pass_list (pass=0x1010ab3a0) at
../../gcc-4.6-20101117/gcc/passes.c:1931
#11 0x000100cdf555 in ipa_passes () at
../../gcc-4.6-20101117/gcc/cgraphunit.c:1696
#12 0x000100cdf738 in cgraph_optimize () at
../../gcc-4.6-20101117/gcc/cgraphunit.c:1765
#13 0x000100cdcad5 in cgraph_finalize_compilation_unit () at
../../gcc-4.6-20101117/gcc/cgraphunit.c:1017
#14 0x000100030c41 in c_write_global_declarations () at
../../gcc-4.6-20101117/gcc/c-decl.c:9837
#15 0x000100969368 in compile_file () at
../../gcc-4.6-20101117/gcc/toplev.c:882
#16 0x00010096c470 in do_compile () at
../../gcc-4.6-20101117/gcc/toplev.c:2313
#17 0x00010096c5b8 in toplev_main (argc=54, argv=0x7fff5fbfe950) at
../../gcc-4.6-20101117/gcc/toplev.c:2374
#18 0x000100115548 in main (argc=54, argv=0x7fff5fbfe950) at
../../gcc-4.6-20101117/gcc/main.c:36


[Bug c++/46269] [trans-mem] internal compiler error in expand_block_tm of trans-mem.c

2010-11-17 Thread aldyh at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46269

Aldy Hernandez aldyh at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #7 from Aldy Hernandez aldyh at gcc dot gnu.org 2010-11-17 
16:43:02 UTC ---
Fixed on branch in aforementioned threads.


[Bug c++/46497] [C++0x] Defaulted vs declared move constructor vs is_convertible

2010-11-17 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46497

--- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com 2010-11-17 
16:44:21 UTC ---
Ok, I'm still digesting all of this (and in the meanwhile we also realized that
likely we have problems in the specs of std::is_convertible itself, in the
library). Something still puzzling me is that, if I use the user-defined move
constructor, I *cannot* trigger errors, *ever*. Is it possible that we have an
accepts-invalid lurking somewhere?


[Bug rtl-optimization/45352] ICE: in reset_sched_cycles_in_current_ebb, at sel-sched.c:7058

2010-11-17 Thread abel at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45352

--- Comment #21 from Andrey Belevantsev abel at gcc dot gnu.org 2010-11-17 
16:47:00 UTC ---
(In reply to comment #20)
 Comment on attachment 22334 [details]
 testcase failing in r166433
 
 Opened PR46521 and PR46522 for the new two testcases. This one wasn't really
 reduced anyway. I also verified the new testcases don't give any warning with
 -Wall -Wextra.
 
 I hope this will make the situation more clear and allow this PR to be closed.

I'm looking at this testcase now, it is not too big.  The problem seems indeed
be a bit different from other test cases.  I don't yet have a solution.


[Bug bootstrap/41337] [LTO] Parallel build failure

2010-11-17 Thread rwild at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41337

Ralf Wildenhues rwild at gcc dot gnu.org changed:

   What|Removed |Added

 CC||rwild at gcc dot gnu.org

--- Comment #3 from Ralf Wildenhues rwild at gcc dot gnu.org 2010-11-17 
16:52:03 UTC ---
If you encounter parallel build failures, please post exact revision that was
built, configure command line, build system type, number of processors on the
box, N argument in 'make -jN', and ideally also the likelihood (in precent)
that the build fails, if it is not deterministic.  Please also post the last
300 or so lines of build output, and maybe check whether it always fails in the
same spot.

It is not too hard to pinpoint parallel build failures but only if there is
enough data available.


[Bug target/46524] New: Code size regression due to not reusing immediate operands of moves

2010-11-17 Thread hubicka at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46524

   Summary: Code size regression due to not reusing immediate
operands of moves
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hubi...@gcc.gnu.org


Created attachment 22433
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22433
preprocessed testcase

this is another CSiBE module.  The testcase is storing a lot of zeros and ones
into many places.  GCC 4.3 keep 0 in ebp and does:

 f29:   f3 0f 5c 84 24 e8 00subss  0xe8(%rsp),%xmm0
 f30:   00 00 
 f32:   8b 84 24 0c 01 00 00mov0x10c(%rsp),%eax
 f39:   c7 84 24 80 00 00 00movl   $0x3f80,0x80(%rsp)
 f40:   00 00 80 3f 
 f44:   89 ac 24 84 00 00 00mov%ebp,0x84(%rsp)
 f4b:   89 ac 24 88 00 00 00mov%ebp,0x88(%rsp)
 f52:   89 ac 24 8c 00 00 00mov%ebp,0x8c(%rsp)
 f59:   89 44 24 40 mov%eax,0x40(%rsp)
 f5d:   89 44 24 54 mov%eax,0x54(%rsp)
 f61:   89 ac 24 90 00 00 00mov%ebp,0x90(%rsp)
 f68:   c7 84 24 94 00 00 00movl   $0x3f80,0x94(%rsp)
 f6f:   00 00 80 3f 
 f73:   89 ac 24 98 00 00 00mov%ebp,0x98(%rsp)
 f7a:   89 ac 24 9c 00 00 00mov%ebp,0x9c(%rsp)
 f81:   f3 0f 59 05 00 00 00mulss  0x0(%rip),%xmm0# f89
main+0xf89
 f88:   00 
 f89:   89 ac 24 a0 00 00 00mov%ebp,0xa0(%rsp)
 f90:   89 ac 24 a4 00 00 00mov%ebp,0xa4(%rsp)
 f97:   c7 84 24 a8 00 00 00movl   $0x3f80,0xa8(%rsp)
 f9e:   00 00 80 3f 
 fa2:   89 ac 24 ac 00 00 00mov%ebp,0xac(%rsp)
 fa9:   89 ac 24 b0 00 00 00mov%ebp,0xb0(%rsp)
 fb0:   89 ac 24 b4 00 00 00mov%ebp,0xb4(%rsp)
 fb7:   89 ac 24 b8 00 00 00mov%ebp,0xb8(%rsp)
 fbe:   c7 84 24 bc 00 00 00movl   $0x3f80,0xbc(%rsp)
 fc5:   00 00 80 3f 
 fc9:   89 6c 24 44 mov%ebp,0x44(%rsp)
 fcd:   89 6c 24 48 mov%ebp,0x48(%rsp)
 fd1:   89 6c 24 4c mov%ebp,0x4c(%rsp)
 fd5:   89 6c 24 50 mov%ebp,0x50(%rsp)
 fd9:   89 6c 24 58 mov%ebp,0x58(%rsp)
 fdd:   89 6c 24 5c mov%ebp,0x5c(%rsp)
 fe1:   89 6c 24 60 mov%ebp,0x60(%rsp)
 fe5:   89 6c 24 64 mov%ebp,0x64(%rsp)
 fe9:   f3 0f 11 44 24 68   movss  %xmm0,0x68(%rsp)
 fef:   89 6c 24 6c mov%ebp,0x6c(%rsp)
 ff3:   89 6c 24 70 mov%ebp,0x70(%rsp)
 ff7:   89 6c 24 74 mov%ebp,0x74(%rsp)
 ffb:   89 6c 24 78 mov%ebp,0x78(%rsp)
 fff:   c7 44 24 7c 00 00 80movl   $0x3f80,0x7c(%rsp)
1006:   3f 

Mainline uses stores:

13a1:   f3 0f 5c 8c 24 dc 00subss  0xdc(%rsp),%xmm1
13a8:   00 00 
13aa:   49 03 44 24 40  add0x40(%r12),%rax
13af:   f3 0f 11 40 2c  movss  %xmm0,0x2c(%rax)
13b4:   c7 40 20 00 00 00 00movl   $0x0,0x20(%rax)
13bb:   c7 40 24 00 00 00 00movl   $0x0,0x24(%rax)
13c2:   c7 40 28 00 00 00 00movl   $0x0,0x28(%rax)
13c9:   8b 84 24 f8 00 00 00mov0xf8(%rsp),%eax
13d0:   f3 0f 11 44 24 40   movss  %xmm0,0x40(%rsp)
13d6:   f3 0f 59 0d 00 00 00mulss  0x0(%rip),%xmm1# 13de
main+0x13de
13dd:   00 
13de:   f3 0f 11 44 24 54   movss  %xmm0,0x54(%rsp)
13e4:   f3 0f 11 44 24 68   movss  %xmm0,0x68(%rsp)
13ea:   c7 44 24 44 00 00 00movl   $0x0,0x44(%rsp)
13f1:   00 
13f2:   89 84 24 80 00 00 00mov%eax,0x80(%rsp)
13f9:   f3 0f 11 44 24 7c   movss  %xmm0,0x7c(%rsp)
13ff:   89 84 24 94 00 00 00mov%eax,0x94(%rsp)
1406:   c7 44 24 48 00 00 00movl   $0x0,0x48(%rsp)
140d:   00 
140e:   c7 44 24 4c 00 00 00movl   $0x0,0x4c(%rsp)
1415:   00 
1416:   c7 44 24 50 00 00 00movl   $0x0,0x50(%rsp)
141d:   00 
141e:   c7 44 24 58 00 00 00movl   $0x0,0x58(%rsp)
1425:   00 
1426:   c7 44 24 5c 00 00 00movl   $0x0,0x5c(%rsp)
142d:   00 
142e:   c7 44 24 60 00 00 00movl   $0x0,0x60(%rsp)
1435:   00 
1436:   c7 44 24 64 00 00 00movl   $0x0,0x64(%rsp)
143d:   00 
143e:   c7 44 24 6c 00 00 00movl   $0x0,0x6c(%rsp)
1445:   00 
1446:   c7 44 24 70 00 00 00movl   $0x0,0x70(%rsp)
144d:   00 
144e:   c7 44 24 74 00 00 00movl   $0x0,0x74(%rsp)
1455:   00 
1456:   c7 

[Bug lto/46525] New: [4.6 Regression] Failed to bootstrap-lto

2010-11-17 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46525

   Summary: [4.6 Regression] Failed to bootstrap-lto
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com


On Linux/x86-64, revision 166867] failed with bootstrap-lto:

http://gcc.gnu.org/ml/gcc-regression/2010-11/msg00229.html

Revision 166855 is OK.


[Bug middle-end/46518] internal compiler error: in vinsn_detach, at sel-sched-ir.c:1271

2010-11-17 Thread amonakov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46518

Alexander Monakov amonakov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2010.11.17 18:18:14
 AssignedTo|unassigned at gcc dot   |amonakov at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #10 from Alexander Monakov amonakov at gcc dot gnu.org 2010-11-17 
18:18:14 UTC ---
Thanks.

diff --git a/gcc/sel-sched-ir.c b/gcc/sel-sched-ir.c
index e169276..71c02c4 100644
--- a/gcc/sel-sched-ir.c
+++ b/gcc/sel-sched-ir.c
@@ -1595,7 +1595,7 @@ static void
 init_expr (expr_t expr, vinsn_t vi, int spec, int use, int priority,
   int sched_times, int orig_bb_index, ds_t spec_done_ds,
   ds_t spec_to_check_ds, int orig_sched_cycle,
-  VEC(expr_history_def, heap) *history, bool target_available,
+  VEC(expr_history_def, heap) *history, signed char target_available,
bool was_substituted, bool was_renamed, bool needs_spec_check_p,
bool cant_move)
 {


[Bug target/46519] Missing vzeroupper

2010-11-17 Thread ubizjak at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46519

--- Comment #1 from Uros Bizjak ubizjak at gmail dot com 2010-11-17 18:42:29 
UTC ---
Does the patch at [1] also fix this test?

[1] http://gcc.gnu.org/ml/gcc-patches/2010-11/msg01802.html


[Bug target/46519] Missing vzeroupper

2010-11-17 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46519

--- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2010-11-17 18:49:14 
UTC ---
(In reply to comment #1)
 Does the patch at [1] also fix this test?
 
 [1] http://gcc.gnu.org/ml/gcc-patches/2010-11/msg01802.html

No, that is for a different case.


[Bug lto/46525] [4.6 Regression] Failed to bootstrap-lto

2010-11-17 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46525

--- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2010-11-17 18:56:09 
UTC ---
Revision 166872 gave:

http://gcc.gnu.org/ml/gcc-regression/2010-11/msg00230.html

xgcc: internal compiler error: Segmentation fault (program lto1)
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
lto-wrapper: /export/gnu/import/svn/gcc-test/bld/./prev-gcc/xgcc returned 4
exit status
lto-wrapper failedcollect2: ld returned 1 exit status
make[6]: *** [jc1] Error 1
make[6]: *** Waiting for unfinished jobs
xgcc: internal compiler error: Segmentation fault (program lto1)


[Bug target/40171] GCC does not pass -mtune and -march options to assembler!

2010-11-17 Thread mahatma at eu dot by
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40171

--- Comment #6 from Dzianis Kahanovich mahatma at eu dot by 2010-11-17 
19:15:10 UTC ---
Created attachment 22434
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22434
atune.patch

Yes, I read maillist archives. But I don't know current state of process and
may suggest own solution (best for me). Sorry if not actual.

I pass only native march|mtune|Wa,-mtune - driver-i386.c -mtune results set
are more compatible with GAS -mtune. And host_detect_local_cpu changed to
process astune parameter and few (atom  generic) incompatible keywords.

There are only linux64.h changed. Others - likewise if somebody find this
useful.

patch produced on 5.0, but used on 4.5.


[Bug middle-end/46518] internal compiler error: in vinsn_detach, at sel-sched-ir.c:1271

2010-11-17 Thread howarth at nitro dot med.uc.edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46518

--- Comment #11 from Jack Howarth howarth at nitro dot med.uc.edu 2010-11-17 
19:26:31 UTC ---
(In reply to comment #10)
 Thanks.
 
 diff --git a/gcc/sel-sched-ir.c b/gcc/sel-sched-ir.c
 index e169276..71c02c4 100644
 --- a/gcc/sel-sched-ir.c
 +++ b/gcc/sel-sched-ir.c
 @@ -1595,7 +1595,7 @@ static void
  init_expr (expr_t expr, vinsn_t vi, int spec, int use, int priority,
int sched_times, int orig_bb_index, ds_t spec_done_ds,
ds_t spec_to_check_ds, int orig_sched_cycle,
 -  VEC(expr_history_def, heap) *history, bool target_available,
 +  VEC(expr_history_def, heap) *history, signed char target_available,
 bool was_substituted, bool was_renamed, bool needs_spec_check_p,
 bool cant_move)
  {

I can confirm that this eliminates the ICE (segfault) during the compilation of
gfortran.dg/pr42294.f on x86_64 Fedora10. Will test x86_64-apple-darwin10 next.


[Bug rtl-optimization/46514] 128-bit shifts on x86_64 generate silly code unless the shift amount is constant

2010-11-17 Thread ubizjak at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46514

Uros Bizjak ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.11.17 19:51:24
 Ever Confirmed|0   |1

--- Comment #1 from Uros Bizjak ubizjak at gmail dot com 2010-11-17 19:51:24 
UTC ---
This is how doubleword (TImode on x86_64 and DImode on x86_32 targets) shifts
are handled. Doubleword instructions are expanded to final instruction sequence
late after register allocation pass, so earlier optimization passes know that
they are processing SHIFT expressions and optimize them as shifts.

The expansion detects constant count operand and emits special sequence, but
for sure it can't detect limited set of possible count operands, and emits
universal sequence in this case.

That said, doubleword operation code is not the most optimized code around, on
the grounds that it is usually not used in performance critical part of the
application. Just try to avoid it as much as possible.


[Bug lto/46525] [4.6 Regression] Failed to bootstrap-lto

2010-11-17 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46525

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0


[Bug debug/39104] stabs debug info fails on IRIX 5.3

2010-11-17 Thread ro at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39104

Rainer Orth ro at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #5 from Rainer Orth ro at gcc dot gnu.org 2010-11-17 20:32:57 UTC 
---
Fixed for binutils 2.21.


[Bug middle-end/46518] internal compiler error: in vinsn_detach, at sel-sched-ir.c:1271

2010-11-17 Thread howarth at nitro dot med.uc.edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46518

--- Comment #12 from Jack Howarth howarth at nitro dot med.uc.edu 2010-11-17 
20:34:15 UTC ---
I can also confirm that the patch in Comment 10 eliminates the ICE in compiling
gfortran.dg/pr42294.f  -O on x86_64-apple-darwin10 (bootstrapped with
--enable-build-with-cxx) as well. Thanks.


[Bug bootstrap/41337] [LTO] Parallel build failure

2010-11-17 Thread dmitrij.ledkov at ubuntu dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41337

--- Comment #4 from Dima dmitrij.ledkov at ubuntu dot com 2010-11-17 21:02:58 
UTC ---
(In reply to comment #3)
 If you encounter parallel build failures, please post exact revision that was
 built, configure command line, build system type, number of processors on the
 box, N argument in 'make -jN', and ideally also the likelihood (in precent)
 that the build fails, if it is not deterministic.  Please also post the last
 300 or so lines of build output, and maybe check whether it always fails in 
 the
 same spot.
 

I'm building a cross-compiler: build/host = gnu-linux; target =
i686-w64-mingw32. I've been using gcc-4.4 branch this whole week (will test
again with trunk when I have time). It is fully deterministic (100% fail rate
at the same spot) when I supply --with-build-libsubdir pointing to the
$prefix/$target-triplet/lib. But the mentioned value for --with-build-libsubdir
option is bogus and doesn't make sense.

 It is not too hard to pinpoint parallel build failures but only if there is
 enough data available.

I no longer believe my error was to do with parallel make, it was the error
between the keyboard and the chair =) in other words pilot error.

If someone else will come across with

 make[1]: *** No rule to make target `build/gencondmd', needed by `s-condmd'

Check your config and make sure it is sane =)


[Bug middle-end/45505] [4.6 Regression] gfortran.dg/pr25923.f90

2010-11-17 Thread howarth at nitro dot med.uc.edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45505

--- Comment #14 from Jack Howarth howarth at nitro dot med.uc.edu 2010-11-17 
21:16:40 UTC ---
Interestingly, on x86_64-apple-darwin10, when using a --enable-build-with-cxx
bootstrap, these tests change to...

XPASS: gfortran.dg/pr25923.f90  -O  PR45505 (test for warnings, line 13)
XPASS: gfortran.dg/pr25923.f90  -O  PR45505 (test for bogus messages, line 22)

I don't see the same behavior with a --enable-build-with-cxx bootstrap on
x86_64 Fedora10 however.


[Bug c++/46526] New: VTable Problem?

2010-11-17 Thread nate.knight at numerica dot us
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46526

   Summary: VTable Problem?
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nate.kni...@numerica.us


Created attachment 22435
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22435
Preprocessed output

Both asserts should pass, but one fails.

Command: g++-mp-4.6 -std=c++0x -v -g3 -save-temps -Wall expose_bug.cpp -o
expose_bug

Command output:

Using built-in specs.
COLLECT_GCC=g++-mp-4.6
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin10/4.6.0/lto-wrapper
Target: x86_64-apple-darwin10
Configured with: ../gcc-4.6-20101113/configure --prefix=/opt/local
--build=x86_64-apple-darwin10 --enable-languages=c,c++,objc,obj-c++
--libdir=/opt/local/lib/gcc46 --includedir=/opt/local/include/gcc46
--infodir=/opt/local/share/info --mandir=/opt/local/share/man
--datarootdir=/opt/local/share/gcc-4.6 --with-local-prefix=/opt/local
--with-system-zlib --disable-nls --program-suffix=-mp-4.6
--with-gxx-include-dir=/opt/local/include/gcc46/c++/ --with-gmp=/opt/local
--with-mpfr=/opt/local --with-mpc=/opt/local --enable-stage1-checking
--disable-multilib --enable-fully-dynamic-string
Thread model: posix
gcc version 4.6.0 20101113 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.5' '-std=c++0x' '-v' '-g3'
'-save-temps' '-Wall' '-o' 'expose_bug' '-shared-libgcc' '-mtune=generic'
 /opt/local/libexec/gcc/x86_64-apple-darwin10/4.6.0/cc1plus -E -quiet -v -dD
-D__DYNAMIC__ expose_bug.cpp -fPIC -mmacosx-version-min=10.6.5 -mtune=generic
-std=c++0x -Wall -g3 -fworking-directory -fpch-preprocess -o expose_bug.ii
ignoring nonexistent directory
/opt/local/lib/gcc46/gcc/x86_64-apple-darwin10/4.6.0/../../../../../x86_64-apple-darwin10/include
#include ... search starts here:
#include ... search starts here:
 /opt/local/include/gcc46/c++/
 /opt/local/include/gcc46/c++//x86_64-apple-darwin10
 /opt/local/include/gcc46/c++//backward
 /opt/local/lib/gcc46/gcc/x86_64-apple-darwin10/4.6.0/include
 /opt/local/include
 /opt/local/lib/gcc46/gcc/x86_64-apple-darwin10/4.6.0/include-fixed
 /usr/include
 /System/Library/Frameworks
 /Library/Frameworks
End of search list.
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.5' '-std=c++0x' '-v' '-g3'
'-save-temps' '-Wall' '-o' 'expose_bug' '-shared-libgcc' '-mtune=generic'
 /opt/local/libexec/gcc/x86_64-apple-darwin10/4.6.0/cc1plus -fpreprocessed
expose_bug.ii -fPIC -quiet -dumpbase expose_bug.cpp -mmacosx-version-min=10.6.5
-mtune=generic -auxbase expose_bug -g3 -Wall -std=c++0x -version -o
expose_bug.s
GNU C++ (GCC) version 4.6.0 20101113 (experimental) (x86_64-apple-darwin10)
compiled by GNU C version 4.6.0 20101113 (experimental), GMP version 5.0.1,
MPFR version 3.0.0-p8, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C++ (GCC) version 4.6.0 20101113 (experimental) (x86_64-apple-darwin10)
compiled by GNU C version 4.6.0 20101113 (experimental), GMP version 5.0.1,
MPFR version 3.0.0-p8, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 4b970d796b9f2164104727f632078674
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.5' '-std=c++0x' '-v' '-g3'
'-save-temps' '-Wall' '-o' 'expose_bug' '-shared-libgcc' '-mtune=generic'
 as -arch x86_64 -force_cpusubtype_ALL -o expose_bug.o expose_bug.s
COMPILER_PATH=/opt/local/libexec/gcc/x86_64-apple-darwin10/4.6.0/:/opt/local/libexec/gcc/x86_64-apple-darwin10/4.6.0/:/opt/local/libexec/gcc/x86_64-apple-darwin10/:/opt/local/lib/gcc46/gcc/x86_64-apple-darwin10/4.6.0/:/opt/local/lib/gcc46/gcc/x86_64-apple-darwin10/
LIBRARY_PATH=/opt/local/lib/gcc46/gcc/x86_64-apple-darwin10/4.6.0/:/opt/local/lib/gcc46/gcc/x86_64-apple-darwin10/4.6.0/../../../:/usr/lib/
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.5' '-std=c++0x' '-v' '-g3'
'-save-temps' '-Wall' '-o' 'expose_bug' '-shared-libgcc' '-mtune=generic'
 /opt/local/libexec/gcc/x86_64-apple-darwin10/4.6.0/collect2 -dynamic -arch
x86_64 -macosx_version_min 10.6.5 -weak_reference_mismatches non-weak -o
expose_bug -lcrt1.10.5.o -L/opt/local/lib/gcc46/gcc/x86_64-apple-darwin10/4.6.0
-L/opt/local/lib/gcc46/gcc/x86_64-apple-darwin10/4.6.0/../../.. expose_bug.o
-lstdc++ -lgcc_ext.10.5 -lgcc -no_compact_unwind -lSystem
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.5' '-std=c++0x' '-v' '-g3'
'-save-temps' '-Wall' '-o' 'expose_bug' '-shared-libgcc' '-mtune=generic'


[Bug c/46076] [4.6 regression] constant propagation and compile-time math no longer happening versus 4.4 and 4.5

2010-11-17 Thread matt at use dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46076

--- Comment #11 from Matt Hargett matt at use dot net 2010-11-17 21:37:43 UTC 
---
Given that int foo() and int foo(void) are not varargs functions, shouldn't
GCC mainline be able to optimize this?


[Bug middle-end/46510] [4.6 Regression] r166812 breaks bootstrap on x86_64-apple-darwin10

2010-11-17 Thread dominiq at lps dot ens.fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46510

--- Comment #8 from Dominique d'Humieres dominiq at lps dot ens.fr 2010-11-17 
21:39:08 UTC ---
As I said in pr46511, removing the assert fixes the bootstrap and does not seem
to introduce any regression (finishing regtesting):

--- /opt/gcc/_clean/gcc/varpool.c2010-11-16 19:21:22.0 +0100
+++ /opt/gcc/work/gcc/varpool.c2010-11-17 10:59:15.0 +0100
@@ -335,7 +335,7 @@ decide_is_variable_needed (struct varpoo
   if (node-force_output)
 return true;

-  gcc_assert (!DECL_EXTERNAL (decl));
+  /* gcc_assert (!DECL_EXTERNAL (decl)); */

   /* Externally visible variables must be output.  The exception is
  COMDAT variables that must be output only when they are needed.  */


[Bug middle-end/42371] dead code not eliminated during folding with whole-program

2010-11-17 Thread matt at use dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42371

--- Comment #5 from Matt Hargett matt at use dot net 2010-11-17 21:43:13 UTC 
---
GCC 4.6.0.20101116 still shows this problem, but also introduces new problems
on top of it. Let me know if I should file a new bug for the regressions.
Either way, is there any update on this enhancement getting into 4.6? Thanks!


  1   2   >