--- Comment #2 from dominiq at lps dot ens dot fr 2010-06-06 08:00 ---
> Patch posted at http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00449.html
With this patch I am at stage 2, so this pr is a duplicate of pr44427 and
fixed.
*** This bug has been marked as a duplicate of 44427 ***
--- Comment #2 from dominiq at lps dot ens dot fr 2010-06-06 08:00 ---
*** Bug 44428 has been marked as a duplicate of this bug. ***
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
-
--- Comment #4 from dominiq at lps dot ens dot fr 2010-06-06 08:05 ---
> At r160335, I don't see the failure on x86_64-unknown-linux-gnu. Maybe it has
> been fixed by some middle-end changes by now. Can anyone confirm that the
> error
> is gone?
No error for the flags I have tried on x
--- Comment #2 from fabien at gcc dot gnu dot org 2010-06-06 09:35 ---
Subject: Bug 44086
Author: fabien
Date: Sun Jun 6 09:35:45 2010
New Revision: 160337
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160337
Log:
Fix PR c++/44086
Added:
trunk/gcc/testsuite/g++.dg/init/pr
This is with revision 160336.
$ cat > a.f90
subroutine foo(a,b)
real :: a(10), b(5)
a(1:5) = b
end
$ gfortran -fdump-parse-tree a.f90 | head -40
Namespace: A-H: (REAL 4) I-N: (INTEGER 4) O-Z: (REAL 4)
procedure name = foo
symtree: __convert_i4_i8 Ambig 0
symb
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44430
--- Comment #1 from dominiq at lps dot ens dot fr 2010-06-06 10:32 ---
gcc version 4.4.4 gives
Namespace: A-H: (REAL 4) I-N: (INTEGER 4) O-Z: (REAL 4)
procedure name = foo
symtree: __convert_i4_i8 Ambig 0
symbol __convert_i4_i8 (INTEGER 8)(PROCEDURE UNKN
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-06-06 10:32 ---
The problem is that statics need to be mangled, so they persist as
i.1234 instead. Really refering to a local symbol in asm is going to be
difficult with LTO (any global or other static symbol with name i will
cause
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-06-06 10:32 ---
*** Bug 44429 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #50 from dominiq at lps dot ens dot fr 2010-06-06 10:50 ---
On x86_64-apple-darwin10.3.0 between revisions 160235 and 160330 the failures
with -m32 went from
FAIL: gcc.c-torture/execute/builtins/abs-1.c compilation, -O2 -fwhopr
FAIL: gcc.c-torture/execute/builtins/memcpy-c
--- Comment #9 from redi at gcc dot gnu dot org 2010-06-06 11:17 ---
Are we sure we'll always want the "typename B::X = int" part?
Would checking for just "const char* D::foo(typename B::X)" be
preferable?
(I don't know what the convention is for this sort of check)
--
http://gcc.gn
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Known to
--- Comment #3 from segher at gcc dot gnu dot org 2010-06-06 11:39 ---
Subject: Bug 44427
Author: segher
Date: Sun Jun 6 11:38:46 2010
New Revision: 160338
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160338
Log:
gcc/ChangeLog
2010-06-06 Segher Boessenkool
PR boot
--- Comment #3 from segher at gcc dot gnu dot org 2010-06-06 11:39 ---
Subject: Bug 44428
Author: segher
Date: Sun Jun 6 11:38:46 2010
New Revision: 160338
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160338
Log:
gcc/ChangeLog
2010-06-06 Segher Boessenkool
PR boot
--- Comment #4 from segher at gcc dot gnu dot org 2010-06-06 11:40 ---
Fixed.
--
segher at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
With --enable-build-with-cxx I see
In file included from ada/b_gnatb.c:252:
ada/b_gnatb.c:5: error: previous declaration of 'void exit(int)' with 'C++'
linkage
/usr/include/stdlib.h:543: error: conflicts with new declaration with 'C'
linkage
/usr/include/stdlib.h:543: error: declaration of 'void e
Without a C++ host compiler (AC_PROG_CXX fails) bootsrap with
--enbale-build-with-cxx fails like
config.status: creating nm
config.status: creating Makefile
config.status: creating gccbug
config.status: creating ada/gcc-interface/Makefile
config.status: creating ada/Makefile
config.status: creatin
Issues to be fixed before --enable-build-with-cxx can be made the default.
--
Summary: [meta-bug] --enable-build-with-cxx issues
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: meta-bug
Severity: normal
Priority
The attached code produces the following error output
[sfili...@localhost bug18]$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/local/gnu46/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure -
--- Comment #1 from sfilippone at uniroma2 dot it 2010-06-06 12:07 ---
Created an attachment (id=20850)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20850&action=view)
test case
If the CLASS DEFAULT block is switched to use AA%CSGET() instead of A%A%CSGET()
no ICE ensues.
I am n
--- Comment #2 from dominiq at lps dot ens dot fr 2010-06-06 12:18 ---
It looks like a duplicate of the unfixed part of pr43945.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44434
--- Comment #1 from laurent at guerby dot net 2010-06-06 12:35 ---
The Ada language build issues were all adressed by my patch on june 2009 here:
http://gcc.gnu.org/ml/gcc/2009-06/msg00635.html
The patch for your problem is the gcc/ada/gcc-interface/Makefile.in change to
use -A instead
--- Comment #2 from rguenther at suse dot de 2010-06-06 12:41 ---
Subject: Re: [boot with C++] Conflicting exit declaration in
ada/b_gnatb.c
On Sun, 6 Jun 2010, laurent at guerby dot net wrote:
> --- Comment #1 from laurent at guerby dot net 2010-06-06 12:35 ---
> The Ada la
--- Comment #5 from pault at gcc dot gnu dot org 2010-06-06 12:49 ---
(In reply to comment #4)
It's fixed for me too. x86_64/FC9
I'll mark it as fixed - thanks for noting that it had gone.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from fabien at gcc dot gnu dot org 2010-06-06 12:59 ---
Fixed in 4.6.
--
fabien at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCO
--- Comment #16 from redi at gcc dot gnu dot org 2010-06-06 13:27 ---
Subject: Bug 40296
Author: redi
Date: Sun Jun 6 13:27:23 2010
New Revision: 160340
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160340
Log:
2010-06-06 Jonathan Wakely
PR libstdc++/40296
--- Comment #74 from iains at gcc dot gnu dot org 2010-06-06 13:35 ---
posted as
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00463.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43170
--- Comment #17 from redi at gcc dot gnu dot org 2010-06-06 13:36 ---
Changed for 4.6.0 but I don't think the change is appropriate for the 4.5.0
branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40296
Harmless, but distracting...
This is present is the latest sources on trunk.
gengtype: don't test undefined value after vasprintf failure
While libiberty's asprintf function does guarantee that the pointer is
set to NULL upon asprintf failure, POSIX/glibc make no such guarantee.
* gengtype.c (xasp
--- Comment #1 from jim at meyering dot net 2010-06-06 13:41 ---
Created an attachment (id=20851)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20851&action=view)
gengtype: don't test undefined value after vasprintf failure
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44435
--- Comment #51 from dominiq at lps dot ens dot fr 2010-06-06 13:46 ---
The 14 tests were fixed by revision 160258 (that has nothing to do with
darwin).
Also I see the following changes, 160257:
=== gcc tests ===
Schedule of variations:
unix/-m32
unix/-m64
Runn
--- Comment #19 from amodra at gmail dot com 2010-06-06 14:11 ---
Confirmed.
Regarding O1test.c:
Wierd set of gcc options, particularly -fno-dce and -fcaller-saves. I can't
see any sane reason why you would use those options on powerpc, unless you were
deliberately stress testing gcc..
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2010-06-06 14:16
---
> The patch for your problem is the gcc/ada/gcc-interface/Makefile.in change to
> use -A instead of -C for gnatbind.
>
> As I said in the last message of the discussion there are a few choice to make
> to do the
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2010-06-06 14:38
---
Missing '*' before the file name in the ChangeLog.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44427
--- Comment #20 from amodra at gmail dot com 2010-06-06 14:52 ---
My guess is that tc-lossings-floats.c hits an ira related problem, but I'm not
particularly familiar with that area of the compiler so won't look further
myself.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
--- Comment #21 from Kyle dot D dot Moffett at boeing dot com 2010-06-06
15:37 ---
I was trying to strip down the testcase and try to see which optimization flags
caused it. I started from -O2 and tried to see which -O2 flags (in addition to
O1) were needed to cause the problem. From
--- Comment #3 from mikpe at it dot uu dot se 2010-06-06 15:42 ---
Patch posted:
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00472.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44335
--- Comment #2 from jsm28 at gcc dot gnu dot org 2010-06-06 15:53 ---
If the libiberty maintainers won't review the xvasprintf patch, perhaps
a global reviewer could do so? That would be better than fiddling with
local checks.
http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01448.html
htt
--- Comment #3 from janus at gcc dot gnu dot org 2010-06-06 16:16 ---
(In reply to comment #2)
> It looks like a duplicate of the unfixed part of pr43945.
It is. One can reduce the test case here to something equivalent to PR 43945
comment #12, which is:
module foo_mod
type foo
con
--- Comment #13 from janus at gcc dot gnu dot org 2010-06-06 16:20 ---
The remaining issue (comment #4/#11/#12) is being tracked by PR 44434, so this
one can be closed.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from manu at gcc dot gnu dot org 2010-06-06 16:40 ---
Subject: Bug 2
Author: manu
Date: Sun Jun 6 16:40:18 2010
New Revision: 160346
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160346
Log:
2010-06-06 Manuel López-Ibáñez
PR c/2
*
--- Comment #6 from manu at gcc dot gnu dot org 2010-06-06 16:41 ---
FIXED in GCC 4.6
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--
fabien at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fabien at gcc dot gnu dot
|dot org
--- Comment #8 from dodji at gcc dot gnu dot org 2010-06-06 18:24 ---
Subject: Bug 44188
Author: dodji
Date: Sun Jun 6 18:24:27 2010
New Revision: 160347
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160347
Log:
Fix PR c++/44188
gcc/ChangeLog:
PR c++/44188
* c
--- Comment #9 from dodji at gcc dot gnu dot org 2010-06-06 18:33 ---
Hopefully properly fixed in trunk (4.6) now.
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from mikpe at it dot uu dot se 2010-06-06 19:16 ---
Patch posted:
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00481.html
I tried to use the existing stack tie instead of a full barrier, but it had no
effect at all, causing the mis-schedules to reappear. I also tried to
--- Comment #18 from michael at jarvis dot net 2010-06-06 19:32 ---
I can confirm the bug on my system (MacOS 10.6.3, Intel Core i7) with g++
4.4.2, 4.4.3 and 4.4.4.
However, I have discovered a workaround. Linking with -lpthread makes the
problem go away, both for this simple test ca
C++0x associative containers should have emplace() and emplace_hint() methods,
but those in libstdc++ do not.
--
Summary: Associative containers lack emplace() and emplace_hint()
methods.
Product: gcc
Version: 4.5.0
Status: UNCONFI
--- Comment #3 from mikpe at it dot uu dot se 2010-06-06 19:54 ---
I've looked at this, and as far as I can tell it's caused by two separate
improvements in 4.5 that are Ok individually but cause libgcc's __bswapsi2 to
call itself when combined (and certain build options are selected).
--- Comment #2 from tkoenig at gcc dot gnu dot org 2010-06-06 20:15 ---
This was between rev. 149577 (works) and rev. 149607 (does not work).
Still narrowing it down a bit.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44430
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-06-06 20:22 ---
No, the arm backend should not claim to implement bswapsi when it in fact emits
a libcall.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44392
--- Comment #52 from dominiq at lps dot ens dot fr 2010-06-06 20:23 ---
On powerpc-apple-darwin9 I see a similar improvement at revision 160335:
=== gcc tests ===
Schedule of variations:
unix/-m32
unix/-m64
Running target unix/-m32
Using /sw/share/dejagnu/baseb
--- Comment #3 from dominiq at lps dot ens dot fr 2010-06-06 20:39 ---
> This was between rev. 149577 (works) and rev. 149607 (does not work).
The only candidate I see is 149586.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44430
--- Comment #4 from tkoenig at gcc dot gnu dot org 2010-06-06 20:52 ---
I agree. Rev. 149586 is:
2009-07-13 Janus Weil
PR fortran/40646
* module.c (mio_symbol): If the symbol has formal arguments,
the formal namespace will be present.
* resolve.c (resolv
--- Comment #5 from janus at gcc dot gnu dot org 2010-06-06 21:31 ---
I'm afraid you're right. r149586 indeed seems to be the culprit. The bug goes
away when reverting a part of that commit, more precisely this one:
Index: gcc/fortran/resolve.c
==
--- Comment #7 from redi at gcc dot gnu dot org 2010-06-06 21:31 ---
Created an attachment (id=20852)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20852&action=view)
alternative patch
Based on the dates from Dave, I think this might be more accurate, and I hope
clearer. The outp
--- Comment #8 from redi at gcc dot gnu dot org 2010-06-06 21:33 ---
(In reply to comment #7)
> ...
> * gcc-3.3.3: libgcc_s.so.1
> * gcc-3.4.x, gcc-4.[0-1].x: libgcc_s.so.1
^ oops, should be 5
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=442
--- Comment #6 from janus at gcc dot gnu dot org 2010-06-06 21:45 ---
A simple way to fix this:
Index: gcc/fortran/dump-parse-tree.c
===
--- gcc/fortran/dump-parse-tree.c (revision 160347)
+++ gcc/fortran/dump-parse-t
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org
|dot org
--- Comment #7 from janus at gcc dot gnu dot org 2010-06-06 21:50 ---
(In reply to comment #5)
> The bug goes away when reverting a part of that commit
Of course simply reverting that part causes a couple of regressions, e.g.
proc_ptr_1,10,22 and others.
--
http://gcc.gnu.org/bugzi
--- Comment #1 from amodra at gmail dot com 2010-06-07 02:19 ---
First testcase in pr44364 tickles this bug on mainline too. Looks like we need
the following.
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6
--- Comment #1 from amodra at gmail dot com 2010-06-07 02:21 ---
*** This bug has been marked as a duplicate of 44067 ***
--
amodra at gmail dot com changed:
What|Removed |Added
--- Comment #2 from amodra at gmail dot com 2010-06-07 02:21 ---
*** Bug 44419 has been marked as a duplicate of this bug. ***
--
amodra at gmail dot com changed:
What|Removed |Added
-
--- Comment #2 from olafvdspek at gmail dot com 2010-06-07 03:01 ---
Would that be a problem?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39437
--- Comment #3 from gcc at breakpoint dot cc 2010-06-07 04:21 ---
Thank you Alan.
Trunk and 4.5 branch is affected, the 4.4 branch just built.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44067
--- Comment #22 from amodra at gmail dot com 2010-06-07 04:41 ---
Adding the following to config/rs6000/e500.h will likely fix the bug.
Testing..
#define HARD_REGNO_CALLER_SAVE_MODE(REGNO, NREGS, MODE) \
(TARGET_E500_DOUBLE && ((MODE) == DFmode || (MODE) == TFmode \
Wow I figured building on Linux would just work, even if not x86.
uname -a:
Linux plin 2.6.26-2-powerpc #1 Thu Feb 11 01:36:51 UTC 2010 ppc GNU/Linux
/usr/lib/gcc/powerpc-linux-gnu/4.3.2/../../../../lib/crt1.o: In function
`_start':
(.text+0x20): relocation truncated to fit: R_PPC_REL24 against
--- Comment #1 from tmsriram at gcc dot gnu dot org 2010-06-07 05:25
---
Subject: Bug 44319
Author: tmsriram
Date: Mon Jun 7 05:24:37 2010
New Revision: 160357
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160357
Log:
2010-06-06 Sriraman Tallam
PR target/44319
--- Comment #1 from adam at consulting dot net dot nz 2010-06-07 05:35
---
Example-specific workaround discovered for global register variable
pessimisation with recent versions of GCC:
void push_flag_into_global_reg_var(uint64_t a, uint64_t b) {
uint64_t flag = (a==b);
global_flag
--- Comment #23 from Kyle dot D dot Moffett at boeing dot com 2010-06-07
05:36 ---
(In reply to comment #22)
> Adding the following to config/rs6000/e500.h will likely fix the bug.
> Testing..
Oh, very nice! Thanks for the speedy assistance on this! I've got my own test
compiler bui
--- Comment #24 from Kyle dot D dot Moffett at boeing dot com 2010-06-07
05:44 ---
Hmm, unfortunately in my preliminary testing this does not seem to fix either
testcase.
Cheers,
Kyle Moffett
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
--- Comment #4 from amodra at gmail dot com 2010-06-07 06:57 ---
Actually, that's the wrong patch. The correct one stops
rs6000_split_multireg_move being called in this case, by modifying
define_mode_iterator DIFD in rs6000.md.
--
amodra at gmail dot com changed:
What
72 matches
Mail list logo
