http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43829
Mikael Morin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43829
--- Comment #50 from Mikael Morin 2011-11-04
01:07:42 UTC ---
I didn't want to flood this PR with commit logs, so here are all the
patches/revisions relevant to this PR:
patch revision
===
01 180842
02 180843
03 180844
0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50880
--- Comment #25 from Paolo Carlini 2011-11-04
00:53:29 UTC ---
By the way, if isn't clear already, I would be *really* curious to know which
specific targets by now can't just enable the builtins, eg, their libc doesn't
provide the C99 complex fu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50880
--- Comment #24 from Paolo Carlini 2011-11-04
00:51:49 UTC ---
Thanks Richard for double checking!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43829
--- Comment #49 from Mikael Morin 2011-11-04
00:45:52 UTC ---
Author: mikael
Date: Fri Nov 4 00:45:48 2011
New Revision: 180922
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180922
Log:
PR fortran/43829
* gfortran.dg/function_op
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43829
--- Comment #48 from Mikael Morin 2011-11-04
00:31:23 UTC ---
Author: mikael
Date: Fri Nov 4 00:31:19 2011
New Revision: 180920
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180920
Log:
PR fortran/43829
* trans-array.c (gfc_conv
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50880
--- Comment #23 from Richard B. Kreckel 2011-11-03
23:57:55 UTC ---
(In reply to comment #16)
> Well, I guess this would be most of it:
>
> template
> std::complex<_Tp>
> __complex_acosh(const std::complex<_Tp>& __z)
> {
> re
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50933
Tobias Burnus changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50933
--- Comment #2 from Tobias Burnus 2011-11-03
22:36:19 UTC ---
Author: burnus
Date: Thu Nov 3 22:36:11 2011
New Revision: 180879
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180879
Log:
2011-11-03 Tobias Burnus
PR fortran/50
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50960
--- Comment #18 from Tobias Burnus 2011-11-03
22:32:42 UTC ---
Author: burnus
Date: Thu Nov 3 22:32:37 2011
New Revision: 180878
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180878
Log:
2011-11-03 Tobias Burnus
PR fortran/5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50987
austinenglish at gmail dot com changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #3 fro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50989
--- Comment #2 from David S. Miller 2011-11-03
21:53:54 UTC ---
Can you multiarch a 64-bit sparc build from 32-bit rtems?
Probably not... but if that were possible you'd need to
check host_address like we do for Linux.
So, change looks fine as-i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50975
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50989
--- Comment #1 from Joel Sherrill 2011-11-03 21:07:21
UTC ---
Created attachment 25710
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25710
Proposed solution
With this change, the RTEMS configure process finished and RTEMS is currently
buil
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50976
--- Comment #12 from Ed Smith-Rowland <3dw4rd at verizon dot net> 2011-11-03
21:05:37 UTC ---
It could well be a mingw-w64 problem (there are two separate projects mingw and
mingw-w64 - http://mingw-w64.sourceforge.net/ you want the latter). I re
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50989
Bug #: 50989
Summary: sparc libgcc2 __udivmoddi4 has undefined reference to
.umul
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50987
--- Comment #2 from Andrew Pinski 2011-11-03
20:56:56 UTC ---
Also I bet the alignment between x86 and PPC are different which makes the
other "bug" invalid too.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50987
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982
--- Comment #10 from David Edelsohn 2011-11-03
20:49:52 UTC ---
Actually, my previous successful bootstrap was for rev 180770. I happened to
catch you in the middle of your checkins, but before the libgcc changes.
http://gcc.gnu.org/ml/gcc-test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50988
Kyle Moffett changed:
What|Removed |Added
Target||powerpc-linux-gnuspe
Host|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982
--- Comment #9 from David Edelsohn 2011-11-03 20:36:28
UTC ---
Okay, I will try. I think that something about the reorganization is causing a
C header file to be interpreted as a C++ header. Something missing extern "C".
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50988
Bug #: 50988
Summary: gcc.target/powerpc/altivec-34.c: Test build failure on
non-AltiVec targets
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCO
t gcc/glibc/etc. versions
they had.
Bug is present in, at least:
gcc-4.0.0
gcc-4.1.0
gcc-4.2.0
gcc-4.6.1
trunk 4.7.0 20111103
reduced testcase:
[austin@gcc1-power7 tests]$ cat generated.i
typedef int BOOL, *PBOOL, *LPBOOL;
typedef int INT, *PINT, *LPINT;
typedef struct _CACHE_DESCRIPTOR {
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50984
Uros Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50976
--- Comment #11 from Daniel Krügler
2011-11-03 19:44:02 UTC ---
(In reply to comment #4)
> I can't imagine how this could be target dependent though.
I have a bit more information now: If I'm using the 32-bit version from
http://www.equation.com
e:
Fine. I'm running Solaris and Linux/x64 bootstraps with that patch now.
> In file included from /farm/dje/src/src/libstdc++-v3/src/atomic.cc:28:0:
> /tmp/2003/powerpc-ibm-aix5.3.0.0/pthread/libstdc++-v3/include/mutex: In
> cons
> tructor 'constexpr std::once_flag::once_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982
--- Comment #7 from David Edelsohn 2011-11-03 19:28:16
UTC ---
It's better. It now finds gthr-posix.h. But now it fails with a C++ failure:
In file included from /farm/dje/src/src/libstdc++-v3/src/atomic.cc:28:0:
/tmp/20111103/powerp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50981
--- Comment #3 from Mikael Morin 2011-11-03
19:19:51 UTC ---
(In reply to comment #2)
> Unless I made a mistake with building those versions, the regression is caused
> by:
>
> Rev. 161472 (PR fortran/43841 and PR 43843).
> http://gcc.gnu.org/vi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50890
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot
|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50968
Ramana Radhakrishnan changed:
What|Removed |Added
CC||ramana at gcc dot gnu.org
--- Comm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50977
--- Comment #2 from Jakub Jelinek 2011-11-03
18:50:42 UTC ---
Without a small self-contained reproducer hard to do anything about it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32534
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50985
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50628
Dominique d'Humieres changed:
What|Removed |Added
CC||danglin at gcc dot gnu.org
--- Com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50986
Bug #: 50986
Summary: weak static data members with constant initializers
emitted in .rodata, leading to segfault on startup
Classification: Unclassified
Product: gcc
Version: 4.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50985
Bug #: 50985
Summary: FAIL: gfortran.fortran-torture/execute/entry_4.f90
execution, at -O2 and above
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32534
Richard Smith changed:
What|Removed |Added
CC||richard-gccbugzilla at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982
--- Comment #6 from Paolo Bonzini 2011-11-03 18:27:23
UTC ---
> Paolo's suggestion probably was not well thought through.
Yes, it assumed that the patch would be tested by maintainers...
The patch looks good.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50978
Rainer Orth changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
URL|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-11-03 18:22:16 UTC ---
> --- Comment #4 from David Edelsohn 2011-11-03
> 18:11:40 UTC ---
> The failure is config/gthr-posix.h is not found in the search path when
> building libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50598
--- Comment #7 from Iain Sandoe 2011-11-03 18:22:05
UTC ---
$ more ../gcc-live-trunk/libgomp/testsuite/libgomp.c++/pr24455-1.C
// { dg-do compile }
// { dg-require-effective-target tls }
extern int i;
#pragma omp threadprivate (i)
int i;
===
i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50978
--- Comment #7 from Rainer Orth 2011-11-03 18:19:57 UTC
---
Author: ro
Date: Thu Nov 3 18:19:54 2011
New Revision: 180839
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180839
Log:
Restore arm-eabi bootstrap (PR target/50978)
PR tar
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982
--- Comment #4 from David Edelsohn 2011-11-03 18:11:40
UTC ---
The failure is config/gthr-posix.h is not found in the search path when
building libstdc++ during bootstrap.
Paolo's suggestion probably was not well thought through.
I tried editin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50984
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Component|tr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50984
Bug #: 50984
Summary: Boolean return value expression clears register too
often
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50983
Bug #: 50983
Summary: [4.7 Regression] incorrect DW_LNS_negate_stmt
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Prio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50934
--- Comment #3 from simon at pushface dot org 2011-11-03 17:34:01 UTC ---
(In reply to comment #1)
> It seems to me that this new approach is a remarkably non-Ada way of
> addressing
> the problem; the original design is precisely the way that it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982
Rainer Orth changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|ro at CeBiTec d
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982
--- Comment #3 from Rainer Orth 2011-11-03 17:25:59 UTC
---
Created attachment 25709
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25709
proposed patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50857
Michael Matz changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50857
--- Comment #4 from Michael Matz 2011-11-03 17:17:11
UTC ---
Author: matz
Date: Thu Nov 3 17:17:07 2011
New Revision: 180833
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180833
Log:
libcpp/
PR bootstrap/50857
* configure.ac: Ch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50981
Tobias Burnus changed:
What|Removed |Added
Target Milestone|--- |4.4.7
--- Comment #2 from Tobias Burnus
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50979
--- Comment #6 from Joel Sherrill 2011-11-03 17:06:52
UTC ---
(In reply to comment #5)
> Created attachment 25707 [details]
> Tentative fix
That seems to have done the trick enough to complete the build of gcc.
Please commit it.
Thanks.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50906
--- Comment #11 from Kyle Moffett 2011-11-03
16:48:43 UTC ---
Ok, I'm running a "bootstrap-lean" + "make check" by way of a full Debian GCC
package build with this patch added. The first build will just do
C/C++/ObjC/ObjC++/Fortran; if that work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50978
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-11-03 16:46:23 UTC ---
Thanks for the confirmation. I'll submit the patch now.
Rainer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50978
--- Comment #5 from Matthew Gretton-Dann
2011-11-03 16:43:41 UTC ---
(In reply to comment #3)
> I think I found it: an incredibly stupid error. The contents of arm/t-bpabi
> was moved to libgcc, with the exception of EXTRA_HEADERS. I missed tha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50981
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #1 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50978
--- Comment #4 from Rainer Orth 2011-11-03 16:21:34 UTC
---
Created attachment 25708
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25708
proposed patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50978
Rainer Orth changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50979
Eric Botcazou changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50979
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50979
--- Comment #4 from Eric Botcazou 2011-11-03
16:06:42 UTC ---
Probably everywhere but Solaris.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50978
--- Comment #2 from Matthew Gretton-Dann
2011-11-03 15:45:57 UTC ---
(In reply to comment #1)
> > Current SVN fails to build libgcc for an arm-none-eabi target because it
> > can't
> > find unwind-arm-common.h:
> >
> > In file included from
> >
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50979
--- Comment #3 from Joel Sherrill 2011-11-03 15:32:12
UTC ---
(In reply to comment #2)
> Are you sure this was introduced by my libgcc series? I'd like to avoid
> hunting down unrelated issues.
No. I just know it is the next breakage in the sp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50978
--- Comment #1 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-11-03 15:27:19 UTC ---
> Current SVN fails to build libgcc for an arm-none-eabi target because it can't
> find unwind-arm-common.h:
>
> In file included from
> /work/upstream-checkouts/gc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50882
--- Comment #10 from Graham Reed 2011-11-03 15:23:45
UTC ---
Created attachment 25706
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25706
Fix wrong mode in call_value_indirect_aix32
(In reply to comment #9)
And that 'DI' was the key (but
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50079
Richard Guenther changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50079
--- Comment #8 from Richard Guenther 2011-11-03
15:17:08 UTC ---
Author: rguenth
Date: Thu Nov 3 15:16:57 2011
New Revision: 180829
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180829
Log:
2011-11-03 Richard Guenther
PR middle-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50040
--- Comment #8 from Richard Guenther 2011-11-03
15:14:38 UTC ---
Patch doesn't apply to the 4.6 branch. Don't hold your breath.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982
Rainer Orth changed:
What|Removed |Added
CC||bonzini at gnu dot org, ro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44965
Richard Guenther changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50974
kargl at gcc dot gnu.org changed:
What|Removed |Added
Known to work|4.5.4, 4.6.3|
Summary|[4.7 regres
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50979
Rainer Orth changed:
What|Removed |Added
CC||davem at davemloft dot net,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50982
Bug #: 50982
Summary: gthr reorganization breakage
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50974
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
K
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50882
--- Comment #9 from Graham Reed 2011-11-03 14:50:48
UTC ---
(In reply to comment #8)
If I compile the testcase of comment #6 with -fdump-final-insns, there are no
"...:DI" instructions in the output from 4.6.1, or 4.6.2 with rs6000.md from
befor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44965
--- Comment #6 from Richard Guenther 2011-11-03
14:46:40 UTC ---
Author: rguenth
Date: Thu Nov 3 14:46:26 2011
New Revision: 180827
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180827
Log:
2011-11-03 Richard Guenther
PR lto/449
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50960
--- Comment #17 from Richard Guenther 2011-11-03
14:34:02 UTC ---
(In reply to comment #16)
> (In reply to comment #11)
> > (In reply to comment #9)
> > > FAIL: gfortran.dg/extends_type_of_1.f03 -O0 (internal compiler error)
> > > FAIL: gfortra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50960
--- Comment #16 from Richard Guenther 2011-11-03
14:29:29 UTC ---
(In reply to comment #11)
> (In reply to comment #9)
> > FAIL: gfortran.dg/extends_type_of_1.f03 -O0 (internal compiler error)
> > FAIL: gfortran.dg/extends_type_of_3.f90 -O (i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50960
--- Comment #15 from Tobias Burnus 2011-11-03
14:23:59 UTC ---
(In reply to comment #14)
> Yes, that should work iff Fortran does not allow parameter initializers
> that require runtime init (like / foo() /, thus a function call result).
No, For
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50980
Bug #: 50980
Summary: arm-rtems multilib not matching for -mfpu=vfp
-mfloat-abi=soft
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50981
Bug #: 50981
Summary: [4.4/4.5/4.6/4.7 Regression] Wrong-code for
scalarizing ELEMENTAL call with absent OPTIONAL
argument
Classification: Unclassified
Product: gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50960
--- Comment #14 from Richard Guenther 2011-11-03
14:17:52 UTC ---
(In reply to comment #13)
> Patch for the issue of comment 5: Constants (PARAMETER) which are exists as
> global static variables were not marked as TREE_READONLY.
>
> With the pa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50960
--- Comment #13 from Tobias Burnus 2011-11-03
14:03:40 UTC ---
Patch for the issue of comment 5: Constants (PARAMETER) which are exists as
global static variables were not marked as TREE_READONLY.
With the patch below (not regtested), the functi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50976
--- Comment #10 from Daniel Krügler
2011-11-03 13:58:53 UTC ---
(In reply to comment #8)
I just send a corresponding email to the support address of this page. In
addition I removed my previous gcc installation completely and installed it
freshly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50979
--- Comment #1 from Joel Sherrill 2011-11-03 13:56:07
UTC ---
Created attachment 25704
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25704
Preprocessed source for failure case
Preprocessed source code which trips issue. It can be reproduc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50979
Bug #: 50979
Summary: sparc mcpu=v8 libgcc2 "mul32" not enabled for "smul"
or "umul"
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50976
--- Comment #9 from Ed Smith-Rowland <3dw4rd at verizon dot net> 2011-11-03
13:47:15 UTC ---
This may well happen if perhaps 'unsigned long long int' doesn't map to
long_long_unsigned_type_node for this target.
Daniel, just for fun, and as a poss
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50970
--- Comment #3 from Eric Millbrandt
2011-11-03 13:30:15 UTC ---
We found the problem in an implementation of a hierarchical state machine from
Practical Statecharts in C/C++ (CMP Books, 2002). The supplied example is a
condensed reproduction of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50976
--- Comment #8 from Jonathan Wakely 2011-11-03
13:23:24 UTC ---
(In reply to comment #6)
> http://www.equation.com/servlet/equation.cmd?fa=fortran
That page implies those binaries contain some source modifications, but it's
not clear what they a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48217
Richard Guenther changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48217
--- Comment #4 from Richard Guenther 2011-11-03
13:13:39 UTC ---
Author: rguenth
Date: Thu Nov 3 13:13:33 2011
New Revision: 180822
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180822
Log:
2011-11-03 Richard Guenther
PR lto/482
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50976
--- Comment #7 from Daniel Krügler
2011-11-03 13:06:12 UTC ---
(In reply to comment #6)
> (In reply to comment #4)
> > gcc version 4.7.0 20111031 (experimental) (GCC)
>
> This difference shouldn't be essential, should it?
(Sorry, my reply conf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50976
--- Comment #6 from Daniel Krügler
2011-11-03 13:04:57 UTC ---
(In reply to comment #4)
> gcc version 4.7.0 20111031 (experimental) (GCC)
This difference shouldn't be essential, should it?
> I wonder if the testsuite was run when the gcc was b
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50906
--- Comment #10 from Alan Modra 2011-11-03 12:59:10
UTC ---
Please test out these patches. bootstrap and regression tests with -Os in
BOOT_CFLAGS on spe would be ideal. I'll be running a powerpc-linux regression
test, but can't do that for spe.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50906
--- Comment #9 from Alan Modra 2011-11-03 12:55:29
UTC ---
Created attachment 25703
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25703
gcc-4.6 fix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50906
--- Comment #8 from Alan Modra 2011-11-03 12:54:32
UTC ---
Created attachment 25702
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25702
Proposed mainline fix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50976
--- Comment #5 from Jonathan Wakely 2011-11-03
12:54:03 UTC ---
(In reply to comment #4)
> Your test case runs like a charm on x86_64-unknown-linux-gnu.
I can confirm that, using the 4.7-20111029 snapshot
> I can't imagine how this could be ta
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50976
--- Comment #4 from Ed Smith-Rowland <3dw4rd at verizon dot net> 2011-11-03
12:47:41 UTC ---
I wonder if the testsuite was run when the gcc was built.
It should have raised a boatload of flags there.
Your test case runs like a charm on x86_64-unk
1 - 100 of 124 matches
Mail list logo
