Compare the log file of the test runs from my lto bootstrap:
http://gcc.gnu.org/ml/gcc-testresults/2012-11/msg00832.html
to that of a normal x86_64 bootstrap:
http://gcc.gnu.org/ml/gcc-testresults/2012-11/msg00790.html
What log files, if any, would be helpful to hunt this down ?
--
Toon
Hello!
Compare the log file of the test runs from my lto bootstrap:
http://gcc.gnu.org/ml/gcc-testresults/2012-11/msg00832.html
Platform: x86_64-unknown-linux-gnu
configure flags: ... --with-arch=native --with-tune=native
to that of a normal x86_64 bootstrap:
I can not see my error here and am wondering what the issue is.
Obviously, if you have 32-bit object files in your build tree, you're using a
32-bit compiler. Which very likely means that you didn't set CC and CXX.
--
Eric Botcazou
On 11/10/2012 01:08 PM, Uros Bizjak wrote:
You have AVX capable machine, and --with-arch=native enables 256 bit
vectorization behind your back.
OK, I will make that more explicit with march=corei7-avx in my next runs.
So the lto bootstrap is a red herring in this regard - good to know.
On 11/10/2012 04:45 AM, NightStrike wrote:
Making c99 the default for gcc would be a great candidate for this.
IIUC, gcc without -std=c99 will compile for c89. And if I read the
manual correctly, it's because c99 isn't finished yet. gcc 5.0 should
have a complete c99.
Should in what sense?
On Fri, 9 Nov 2012, NightStrike wrote:
Making c99 the default for gcc would be a great candidate for this.
IIUC, gcc without -std=c99 will compile for c89. And if I read the
manual correctly, it's because c99 isn't finished yet. gcc 5.0 should
have a complete c99.
The reason gnu99 is not
Eric wrote:
Any pointers at all as to the error of my ways ?
http://gcc.gnu.org/install/specific.html#sparc64-x-solaris2
You're up against three factors here. First, the sparc64 platform ABI
specifies 32-bit executables unless the user specifically asks for
64-bit. I'm really unclear on why
Eric wrote:
Any pointers at all as to the error of my ways ?
http://gcc.gnu.org/install/specific.html#sparc64-x-solaris2
You're up against three factors here. First, the sparc64 platform ABI
specifies 32-bit executables unless the user specifically asks for
64-bit. I'm really unclear
On 10/11/2012 3:51 PM, Dennis Clarke wrote:
Eric wrote:
Any pointers at all as to the error of my ways ?
http://gcc.gnu.org/install/specific.html#sparc64-x-solaris2
You're up against three factors here. First, the sparc64 platform ABI
specifies 32-bit executables unless the user specifically
On 10 November 2012 20:51, Dennis Clarke wrote:
So 32-bit gcc works just fine. However I need a pile of libs all over the
place ( gmp, mpfr, mpc, etc etc ) for this to work
No you don't. If you put gmp, mpfr and mpc in the GCC source tree, or
install them with --disable-shared, then you
On 10/11/2012 4:54 PM, Jonathan Wakely wrote:
On 10 November 2012 20:51, Dennis Clarke wrote:
So 32-bit gcc works just fine. However I need a pile of libs all over the
place ( gmp, mpfr, mpc, etc etc ) for this to work
No you don't. If you put gmp, mpfr and mpc in the GCC source tree, or
On 10 November 2012 22:08, Ryan Johnson wrote:
You know, somehow I'd missed that gcc would build the numerical libs for you
if they were in tree... I'd only heard about the host tools (binutils,
etc.). Does it do the same for all deps (e.g. readline) as well?
No.
The
Snapshot gcc-4.7-20121110 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.7-20121110/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.7 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Sat, Nov 10, 2012 at 6:20 AM, Andrew Haley a...@redhat.com wrote:
On 11/10/2012 04:45 AM, NightStrike wrote:
Making c99 the default for gcc would be a great candidate for this.
IIUC, gcc without -std=c99 will compile for c89. And if I read the
manual correctly, it's because c99 isn't
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55260
Bug #: 55260
Summary: [4.8 Regression] ICE: in ipa_get_parm_lattices, at
ipa-cp.c:263 with -O2 -fno-inline -fipa-cp-clone
Classification: Unclassified
Product: gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55258
--- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2012-11-10 08:52:22
UTC ---
Created attachment 28651
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28651
Something like this
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55261
Bug #: 55261
Summary: [C++0x] ICE (SIGSEGV) when inheriting implicit
constructor
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55247
--- Comment #7 from Uros Bizjak ubizjak at gmail dot com 2012-11-10 09:15:32
UTC ---
(In reply to comment #2)
(define_insn *movti_internal_rex64
[(set (match_operand:TI 0 nonimmediate_operand =!r ,!o ,x,x ,m)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55262
Bug #: 55262
Summary: [C++0x] g++.dg/cpp0x/inh-ctor10.C ICEs with -g
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55247
--- Comment #8 from Uros Bizjak ubizjak at gmail dot com 2012-11-10 09:22:03
UTC ---
(In reply to comment #3)
There are 2 issues here:
1. Should we use
movdqu(%eax), %xmm0# 19*movti_internal_rex64/4[length =
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55263
Bug #: 55263
Summary: [4.8 Regression] ICE: pre_and_rev_post_order_compute,
at cfganal.c:875 with -O -fgcse-after-reload
-fnon-call-exceptions
Classification: Unclassified
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55247
--- Comment #9 from uros at gcc dot gnu.org 2012-11-10 11:28:17 UTC ---
Author: uros
Date: Sat Nov 10 11:28:12 2012
New Revision: 193388
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193388
Log:
PR target/55247
*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55247
Uros Bizjak ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55247
--- Comment #11 from Uros Bizjak ubizjak at gmail dot com 2012-11-10 11:55:55
UTC ---
~/gcc-build/gcc/cc1 -O2 -mx32 -maddress-mode=long pr55247.c
results in following sequence:
movdqu (%eax), %xmm0
movdqa %xmm0,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15184
--- Comment #21 from Uros Bizjak ubizjak at gmail dot com 2012-11-10 12:15:14
UTC ---
(In reply to comment #20)
Please can the RMs have a new look at this.
This is tuning decision, and I see Intel folks in the CC. I see no problem in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54716
Marc Glisse glisse at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15184
--- Comment #22 from Mikael Pettersson mikpe at it dot uu.se 2012-11-10
13:36:46 UTC ---
Created attachment 28655
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28655
another test case
I'm using a construct similar to the 'f1'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55264
Bug #: 55264
Summary: [4.6/4.7/4.8 Regression] ICE: in
ipa_make_edge_direct_to_target, at ipa-prop.c:2141
with -O2 -fno-early-inlining -fno-weak
Classification:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30162
--- Comment #26 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-11-10
14:38:03 UTC ---
Is this caused by
http://gcc.gnu.org/viewcvs?view=revisionrevision=180701
?
Maybe we need to remember if we have a special file after all, or
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55266
Bug #: 55266
Summary: vector expansion: 36 movs for 4 adds
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55264
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55267
Bug #: 55267
Summary: double operation giving different results depending on
context and optimization level
Classification: Unclassified
Product: gcc
Version: 4.7.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55267
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Severity|major |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55263
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55202
--- Comment #5 from Andrew Pinski pinskia at gcc dot gnu.org 2012-11-10
18:32:27 UTC ---
Author: pinskia
Date: Sat Nov 10 18:32:23 2012
New Revision: 193393
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193393
Log:
2012-11-10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55202
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55247
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Status|NEW |UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55247
--- Comment #13 from H.J. Lu hjl.tools at gmail dot com 2012-11-10 19:11:03
UTC ---
(In reply to comment #12)
(In reply to comment #11)
~/gcc-build/gcc/cc1 -O2 -mx32 -maddress-mode=long pr55247.c
results in following sequence:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55247
--- Comment #14 from Uros Bizjak ubizjak at gmail dot com 2012-11-10 19:41:31
UTC ---
(In reply to comment #13)
With this fix, we don't need to change *movti_internal_rex64
since it generates redundant load/store.
True, IIRC this was
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30162
--- Comment #27 from Janne Blomqvist jb at gcc dot gnu.org 2012-11-10
20:21:41 UTC ---
(In reply to comment #26)
Is this caused by
http://gcc.gnu.org/viewcvs?view=revisionrevision=180701
?
Maybe we need to remember if we
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55252
--- Comment #3 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-11-10
22:58:16 UTC ---
Hum, I am not sure why the macro unwinder avoids unwinding if the macro comes
from a system-header. If a warning message comes from a system-header, then
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55252
--- Comment #4 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-11-10
23:10:32 UTC ---
On the other hand, let's consider:
pr55252.c:
#define bar 256
#include pr55252.h
pr55252.h:
#pragma GCC system_header
signed char foo = bar;
In this
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55200
Chris Lundquist clundquist at bluebox dot net changed:
What|Removed |Added
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55252
--- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-10
23:20:36 UTC ---
(In reply to comment #4)
On the other hand, this is a very contrived testcase. I
wouldn't expect in normal code that the expansion point to be in a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55263
Steven Bosscher steven at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55268
Bug #: 55268
Summary: gcc4.8 mingw-w64 Wrong stdcall import symbols
generated after rev 193204
Classification: Unclassified
Product: gcc
Version: 4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55269
Bug #: 55269
Summary: Rename tree_node complex field to avoid conflict with
C99 complex type
Classification: Unclassified
Product: gcc
Version: 4.7.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55269
--- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-11-11
06:21:55 UTC ---
In 4.8, GCC is now written in C++ rather than C, so I don't think it matter
anymore as there is no macro define in C++ for complex.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55014
Mikael Pettersson mikpe at it dot uu.se changed:
What|Removed |Added
CC|mikpe at it dot uu.se |
---
Ed Smith-Rowland 3dw...@verizon.net ha scritto:
Paolo?
... carte blanche to Jason! (but I have a little lexer tweak pending... ;)
Paolo
On Fri, Nov 09, 2012 at 09:36:53PM +0100, Tobias Burnus wrote:
* I still have to do an all-language bootstrap and regtesting,
though the latter is probably pointless as there is currently not a
single -fasan test case.
--- gcc/asan.c.orig 2012-11-09 21:26:26.0 +0100
+++ gcc/asan.c
Hello!
Attached patch disparages riF-o alternative of *movti_internal_rex64
insn, as described by Vlad in comment #2 [1]
The core of the problem however is, that gcc is unable to detect
zero-extended address as offsetable. H.J. will propose a patch for
this [2].
2012-11-10 Vladimir Makarov
Jakub Jelinek wrote:
--- gcc/asan.c.orig 2012-11-09 21:26:26.0 +0100
+++ gcc/asan.c 2012-11-09 21:26:00.0 +0100
@@ -1362,6 +1362,8 @@ transform_statements (void)
instrument_assignment (i);
else if (is_gimple_call (s))
maybe_instrument_call
I wrote:
after the dicsussion on c.l.f, it become clear that passing a DO loop
variable to an INTENT(OUT) or INTENT(INOUT) dummy argument is an error.
The attached patch throws an error for both cases.
I chose to issue the errors as a front-end pass because we cannot check
for formal arguments
On 9 November 2012 22:09, Jason Merrill wrote:
Now that G++ uses the value of __cplusplus specified by the standard, we
don't need the other macro anymore.
OK for trunk, or should I save it for the next stage 1?
Jason
I'd been thinking about suggesting that change just the other day - do
A few more testsuite fixes to address failures on AIX. The only
really interesting one is g++.dg/other/anon5.C where Undefined is
capitalized in the AIX error message.
Thanks, David
* c-c++-common/scal-to-vec2.c: Ignore non-standard ABI message.
*
Il 10/11/2012 07:44, H.J. Lu ha scritto:
Hi,
In
(insn 19 17 20 2 (set (reg:TI 85 [ *_15 ])
(mem:TI (zero_extend:DI (reg:SI 82)) [0 *_15+0 S16 A32])) x.i:29 61
{*movti_internal_rex64}
(expr_list:REG_DEAD (reg:SI 82)
(expr_list:REG_EQUIV (mem/c:TI (plus:DI (reg/f:DI
Il 10/11/2012 05:30, Andrew Pinski ha scritto:
Hi,
The problem here is that set PLUGIN_LD_SUFFIX to ld-new which is not
the final installed binary name. This patch fixes the problem by
changing if we got ld-new to just ld.
Note this issue has been around since 4.6 but not many people test
Tobias Burnus wrote:
So untested:
Thanks for the patch! It fixed the problem half way: It fixes the
second issue I had (fail10.ii,
http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00791.html ).
However, it didn't fix the original problem: As the call for strlen
directly returns, it never
On Fri, 9 Nov 2012 22:51:45 +0530, Siddhesh wrote:
I had reckoned that the behaviour could be reverted to what was before
while I figure out a way to get the warning in place for both cases,
i.e. with tree-vrp (where max_loop_iterations now causes the loop to
be folded away in -O2) and this
In the patch I installed for PR rtl-optimization/54315:
http://gcc.gnu.org/ml/gcc-patches/2012-10/msg00745.html
the special code dealing with BLKmode in registers at the beginning of
store_field is disabled for CALL_EXPR:
/* If we are storing into an unaligned field of an aligned union that
---
You've been invited by Claudiu Zissulescu to use Google Talk.
If you already have a Google account, login to Gmail and accept this chat
invitation:
Tested as described in the covering note. OK to install?
Richard
gcc/
* combine.c (make_extraction): Handle TRUNCATEd INNERs.
OK, thanks.
--
Eric Botcazou
Tested as described in the covering note. OK to install?
Richard
gcc/
* expr.h (adjust_address_1): Add a size parameter.
(adjust_address, adjust_address_nv, adjust_bitfield_address)
(adjust_bitfield_address_nv): Adjust accordingly.
Tested as described in the covering note. OK to install?
Richard
gcc/
* expmed.c (narrow_bit_field_mem): New function.
(store_bit_field_using_insv, store_bit_field_1, store_fixed_bit_field)
(extract_bit_field_1): Use it.
This looks better now, thanks.
--
Eric
On Sat, Nov 10, 2012 at 6:46 AM, Paolo Bonzini bonz...@gnu.org wrote:
Il 10/11/2012 05:30, Andrew Pinski ha scritto:
Hi,
The problem here is that set PLUGIN_LD_SUFFIX to ld-new which is not
the final installed binary name. This patch fixes the problem by
changing if we got ld-new to just
On Sat, Nov 10, 2012 at 3:43 AM, Uros Bizjak ubiz...@gmail.com wrote:
Hello!
Attached patch disparages riF-o alternative of *movti_internal_rex64
insn, as described by Vlad in comment #2 [1]
The core of the problem however is, that gcc is unable to detect
zero-extended address as
This patch fixes a bug comparing struct field types in the reflect
package. Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline and 4.7 branch.
Ian
diff -r 8b1f2a35ded1 libgo/go/reflect/type.go
--- a/libgo/go/reflect/type.go Tue Nov 06 10:44:51 2012 -0800
+++
On Sat, Nov 10, 2012 at 10:38:55AM -0800, H.J. Lu wrote:
On Sat, Nov 10, 2012 at 6:41 AM, Paolo Bonzini bonz...@gnu.org wrote:
Il 10/11/2012 07:44, H.J. Lu ha scritto:
Hi,
In
(insn 19 17 20 2 (set (reg:TI 85 [ *_15 ])
(mem:TI (zero_extend:DI (reg:SI 82)) [0 *_15+0 S16 A32]))
On Sat, Nov 10, 2012 at 3:00 PM, Thomas Koenig wrote:
I wrote:
after the dicsussion on c.l.f, it become clear that passing a DO loop
variable to an INTENT(OUT) or INTENT(INOUT) dummy argument is an error.
The attached patch throws an error for both cases.
But should we really isse an error
Hello,
This is another ICE in pre_and_rev_post_order_compute, called from
alias.c after register allocation.
The problem is that purge_all_dead_edges can make basic blocks
unreachable. Before my patch of r190602, alias.c handled unreachable
blocks (resulting in missed disambiguations). Now that
This patch continues my series of copy-edits to the GCC user
documentation. Here I've fixed a number of problems in extend.texi with
confusion between which and that, as I previously did for invoke.texi.
Committed as obvious since there are no changes to content, just grammar.
-Sandra
The demangler change was handling the tags in the wrong place; I'm
writing them out with unqualified names, so the demangler should expect
them in the same place.
Tested x86_64-pc-linux-gnu, applied to trunk.
commit 75eef303e5494f27a6d9bbef68aaf3200978a8f1
Author: Jason Merrill
As mentioned in http://gcc.gnu.org/wiki/Cxx11AbiCompatibility, C++11
changes the return type of complex::real and imag, leading to a binary
incompatibility between C++98 and C++11 code if the functions are used
without inlining. This patch adds an ABI tag to the C++11 variants so
that they
I've checked in this patch to fix various problems with hyphenated
phrases in extend.texi. This exactly parallels similar copy edits I
made earlier this year to invoke.texi. To recap, in phrases like
64-bit types, 64-bit is a compound adjective phrase that immediately
precedes a noun and
I've checked in this patch to consistently use bit-field in
extend.texi instead of bitfield or bit field. Bit-field is listed
in the GCC Coding Conventions as the preferred terminology, for
consistency with the C and C++ standards.
-Sandra
2012-11-10 Sandra Loosemore
I found this suspicious looking line in cp/parser.c () while looking at
__thread and thread_local.
Look at the patterns of the if blocks above the line in question to verify.
Built and tested on x86_64-linux.
Ed
2012-11-11 Ed Smith-Rowland 3dw...@verizon.net
* parser.c
77 matches
Mail list logo
