http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56078
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56081
janus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||ice-on-invalid-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49069
--- Comment #12 from Jakub Jelinek 2013-01-23
08:37:39 UTC ---
Author: jakub
Date: Wed Jan 23 08:37:16 2013
New Revision: 195398
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195398
Log:
PR target/49069
* config/arm/a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56052
--- Comment #8 from Jakub Jelinek 2013-01-23
08:44:00 UTC ---
Author: jakub
Date: Wed Jan 23 08:43:50 2013
New Revision: 195399
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195399
Log:
PR fortran/56052
* trans-decl.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #21 from Iain Sandoe 2013-01-23 08:44:45
UTC ---
(In reply to comment #20)
> crttme.o comes from libgcc/config/darwin-crt-tm.c, which has:
>
> /* Provide dummy functions to satisfy linkage for versions of the Darwin
>to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49069
Jakub Jelinek changed:
What|Removed |Added
Known to work||4.8.0
Summary|[4.6/4.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56052
Jakub Jelinek changed:
What|Removed |Added
Summary|[4.7/4.8 Regression] [OOP] |[4.7 Regression] [OOP] ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56081
--- Comment #4 from janus at gcc dot gnu.org 2013-01-23 09:09:56 UTC ---
On the 4.6 branch, one finds the following check in resolve.c (resolve_select,
line 7426):
if (case_expr->rank != 0)
{
gfc_error ("Argument of SELECT st
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56081
--- Comment #5 from janus at gcc dot gnu.org 2013-01-23 09:13:19 UTC ---
In ChangeLog-2011 I see the following commit:
2011-12-11 Paul Thomas
Tobias Burnus
PR fortran/41539
PR fortran/43214
PR fortran/43969
P
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56081
--- Comment #6 from janus at gcc dot gnu.org 2013-01-23 09:21:02 UTC ---
The obvious fix is certainly to re-insert that piece of code:
Index: gcc/fortran/resolve.c
===
--- gc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56079
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P4
Status|UNCONFIRME
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56081
--- Comment #7 from janus at gcc dot gnu.org 2013-01-23 09:52:30 UTC ---
(In reply to comment #6)
> Will check for regressions now.
Unfortunately it seems to trigger a large number of regressions in the
testsuite, e.g. on:
FAIL: gfortr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #23 from Dominique d'Humieres
2013-01-23 09:56:13 UTC ---
(In reply to comment #21)
> ... I don't have darwin11 or 12 (yet) - but should do soon.
The test also fails on darwin10 unless the patch in comment #7 is applied.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56081
--- Comment #8 from janus at gcc dot gnu.org 2013-01-23 10:00:31 UTC ---
(In reply to comment #7)
> FAIL: gfortran.dg/class_allocate_10.f03 -O0 (test for excess errors)
> FAIL: gfortran.dg/class_allocate_8.f03 -O0 (test for excess errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53964
--- Comment #7 from Anton Shterenlikht 2013-01-23
10:14:52 UTC ---
a great miracle happened here:
# pkg info -xo gcc-4.6
gcc-4.6.4.20121123: lang/gcc46
#
I didn't have to do anything extra to get it build.
However, I'm getting th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56075
--- Comment #1 from rajendiran 2013-01-23
10:31:45 UTC ---
Created attachment 29254
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29254
C Source code without preprocced
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55889
Andrey Belevantsev changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56075
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55989
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #25 from Kostya Serebryany 2013-01-23
12:21:51 UTC ---
So, what is our decision?
Are we just doing
- static const uptr kHighMemEnd = 0x0fffUL;
+ static const uptr kHighMemEnd = 0x3fffUL;
, leavin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #26 from Jakub Jelinek 2013-01-23
12:26:30 UTC ---
(In reply to comment #25)
> So, what is our decision?
>
> Are we just doing
> - static const uptr kHighMemEnd = 0x0fffUL;
> + static const uptr kHighMemEnd
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55992
Paolo Carlini changed:
What|Removed |Added
CC||dodji at gcc dot gnu.org
--- Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56013
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55828
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #27 from Kostya Serebryany 2013-01-23
12:51:40 UTC ---
>> BTW, I wonder why clang generates larger and slower code with ADD instead of
>> OR
I did not investigate. I noticed that the code size with OR is smaller than
with ADD.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #28 from Jakub Jelinek 2013-01-23
13:05:57 UTC ---
Why doesn't it error for unlimited stack say on x86_64? If the stack mapping
size is unlimited, it also potentially overlaps with the shadow memory. If you
have a growsdown m
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56081
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assig
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #29 from Kostya Serebryany 2013-01-23
13:19:30 UTC ---
>> Why doesn't it error for unlimited stack say on x86_64?
Because on x86_64 the stack is still high enough (we are lucky).
Note: I would not generally care about unlim
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55797
Jan Hubicka changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #30 from Jakub Jelinek 2013-01-23
13:30:19 UTC ---
What I mean, is a stack PROT_GROWSDOWN RLIM_INFINITY RLIMIT_STACK mapping is
defined to be a mapping from the top of that mapping down to the first mapping
of something else be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #31 from Kostya Serebryany 2013-01-23
13:32:11 UTC ---
I've committed an upstream change
http://llvm.org/viewvc/llvm-project?view=rev&revision=173260 that makes
kHighMemEnd dynamic.
Hopefully, it will simplify further changes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #24 from Iain Sandoe 2013-01-23 13:33:15
UTC ---
(In reply to comment #23)
> (In reply to comment #21)
> > ... I don't have darwin11 or 12 (yet) - but should do soon.
>
> The test also fails on darwin10 unless the patch in c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #32 from Jakub Jelinek 2013-01-23
13:33:45 UTC ---
I take it back, seems it is because the kernel mmaps the shared libraries in
that range in this case. So indeed, you probably need a dynamic mapping, sorry
for the noise. All
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55797
--- Comment #6 from Jan Hubicka 2013-01-23
13:38:16 UTC ---
The patch in Comment #4 should not have any effect (and indeed the test does
not fire for me on the testcase). can_early_inline predicate already test that
the callee is in SSA f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #33 from Jakub Jelinek 2013-01-23
13:40:57 UTC ---
(In reply to comment #31)
> I've committed an upstream change
> http://llvm.org/viewvc/llvm-project?view=rev&revision=173260 that makes
> kHighMemEnd dynamic.
> Hopefully, i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55797
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #34 from Kostya Serebryany 2013-01-23
13:50:31 UTC ---
> Do you really want to make kHighMemEnd dynamic always? Shouldn't it be
> dynamic
> only when needed (i.e. for configurations like ppc64 which now require it)?
If we m
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55797
--- Comment #8 from Jan Hubicka 2013-01-23
13:56:44 UTC ---
This is not really issue with early inliner confused with function not being in
SSA form. But for aid of esra, we can do that at expense of increasing of peak
memory use - the SS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56082
Bug #: 56082
Summary: FAIL: gfortran.dg/bind_c_bool_1.f90 -O (test for
errors, line 18) on powerpc-apple-darwin9 with -m32
Classification: Unclassified
Product: gcc
V
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56074
--- Comment #4 from Rainer Orth 2013-01-23 13:59:18 UTC
---
Indeed, thanks for the superfast fix.
Rainer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55797
--- Comment #9 from Jan Hubicka 2013-01-23
14:00:23 UTC ---
Just for record, I do not recall any issues with early inliner being run in
parallel with into-SSA. As a simple inliner working in topological order, it
really does not care about
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #25 from Aldy Hernandez 2013-01-23
14:11:53 UTC ---
> looks like (yet another) permutation of what works/doesn't with "ELF-style
> weak
> linking" I don't have darwin11 or 12 (yet) - but should do soon.
>
FWIW, I reproduced
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55797
--- Comment #10 from Jan Hubicka 2013-01-23
14:19:51 UTC ---
I am testing the following patch. It is a side case where we save function body
but the function we save the body of becomes unnecesary as a result of dead
block removal during i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56078
Jakub Jelinek changed:
What|Removed |Added
CC||jsm28 at gcc dot gnu.org
--- Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56078
--- Comment #5 from Jakub Jelinek 2013-01-23
14:32:31 UTC ---
--- gcc/c/c-typeck.c.jj2013-01-11 09:02:31.0 +0100
+++ gcc/c/c-typeck.c2013-01-23 15:24:50.839173887 +0100
@@ -7574,7 +7574,9 @@ set_nonincremental_init_from_str
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54222
--- Comment #9 from Georg-Johann Lay 2013-01-23
15:13:56 UTC ---
Author: gjl
Date: Wed Jan 23 15:13:51 2013
New Revision: 195407
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195407
Log:
PR target/54222
* config/avr/s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56083
Bug #: 56083
Summary: Vectorizer uses xor/movlps/movhps rather than movups
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: mi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56084
Bug #: 56084
Summary: poor error recovery for missing ";"
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56084
Manuel López-Ibáñez changed:
What|Removed |Added
Keywords||diagnostic
--- Comment #1 from Man
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56085
Bug #: 56085
Summary: Unsafe negation in C++03 pow(complex,int)
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56083
Uros Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56083
Marc Glisse changed:
What|Removed |Added
CC||glisse at gcc dot gnu.org
--- Com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56083
--- Comment #3 from Uros Bizjak 2013-01-23 16:23:47
UTC ---
(In reply to comment #2)
> Uros, I completely agree, but note that the PR also mentions this line:
>
> xorps%xmm0, %xmm0
>
> which appears rather useless since the low
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56047
Richard Biener changed:
What|Removed |Added
Priority|P3 |P4
Target Milestone|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56084
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
William J. Schmidt changed:
What|Removed |Added
CC||wschmidt at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56056
Richard Biener changed:
What|Removed |Added
Keywords||error-recovery,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56061
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56077
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56076
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56075
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56074
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56056
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742
Jakub Jelinek changed:
What|Removed |Added
CC||crrodriguez at opensuse dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56068
Richard Biener changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #26 from Jack Howarth 2013-01-23
16:44:51 UTC ---
Iain,
The initial comments from the darwin linker developer were...
That test case is dying because a.out contains its own copy of
__cxa_allocate_exception which just re
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56085
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Status|U
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56081
Richard Biener changed:
What|Removed |Added
Priority|P3 |P5
Target Milestone|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #27 from Jack Howarth 2013-01-23
16:48:19 UTC ---
(In reply to comment #25)
> FWIW, I reproduced the problem on Darwin10 (x86_64-apple-darwin10.8.0).
> Mac OS X 10.6.8.
What Xcode do you have installed? Is it 3.2.6 or one
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54402
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #30 from R
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56063
--- Comment #8 from Richard Biener 2013-01-23
16:52:13 UTC ---
ISTR old bugzilla had a reconfirm-now-like style. As long as one would be
able to eventually re-set the reconfirmed date back if it was changed in
error the default should be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56062
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56084
--- Comment #3 from Manuel López-Ibáñez 2013-01-23
17:02:02 UTC ---
> (Separately, I'm investigating whether there's some way to reduce the output
> when an invalid ostream operation is done, because the sheer number of
> overloads of operator<<
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56084
--- Comment #4 from Manuel López-Ibáñez 2013-01-23
17:05:14 UTC ---
BTW, what is the difference between deduction and substitution?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56084
--- Comment #5 from Manuel López-Ibáñez 2013-01-23
17:10:58 UTC ---
Of course, the color output makes much easier to spot the "note:". And the use
of a common prefix "note: candidate function..." or "note: candidate
template..." also makes easie
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56084
--- Comment #6 from Marc Glisse 2013-01-23 17:17:53
UTC ---
(In reply to comment #5)
> Of course, the color output makes much easier to spot the "note:".
Er, not here, bold black (the color they chose for "note:") on a black
background
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56084
--- Comment #7 from Manuel López-Ibáñez 2013-01-23
17:31:21 UTC ---
Strange. In the GCC farm and without any customization, clang uses gray for the
note. I have seen presentations where it also uses this color scheme. I don't
know if they have s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #28 from Jack Howarth 2013-01-23
17:32:34 UTC ---
Iain,
The ELF style weak ref issue appears to be red herring. I find that both
darwin10 with Xcode 4.2 (whose build of libitm has a config.h with
HAVE_ELF_STYLE_WEAKREF und
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55679
Jack Howarth changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56084
--- Comment #8 from Jonathan Wakely 2013-01-23
17:44:24 UTC ---
(In reply to comment #4)
> BTW, what is the difference between deduction and substitution?
Some template arguments are deduced from the function arguments, and those
argume
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56078
--- Comment #6 from joseph at codesourcery dot com 2013-01-23 17:53:16 UTC ---
I think taking the highest array index seen (determining the array bounds
so that none of the initializers for a flexible array will ever be outside
the bounds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55927
Martin Jambor changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot |jamborm at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #29 from Dominique d'Humieres
2013-01-23 18:30:37 UTC ---
(In reply to comment #27)
> > FWIW, I reproduced the problem on Darwin10 (x86_64-apple-darwin10.8.0).
> > Mac OS X 10.6.8.
>
> What Xcode do you have installed? Is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56086
Bug #: 56086
Summary: when compiling C code with -std=gnu99 macro
__STDC_UTF_16__ is defined
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #30 from Jack Howarth 2013-01-23
19:32:22 UTC ---
Created attachment 29256
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29256
test case demonstrating need for weak symbols in crttme.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #31 from Jack Howarth 2013-01-23
19:41:52 UTC ---
I believe the attached testcase, weak_symbol.tar.bz2, demonstrates that the
solution on darwin is to mark the duplicate symbols in crttme.o as weak.
Consider the following test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56087
Bug #: 56087
Summary: [m68k] gcc miscompiles pari (multiplication)
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #32 from Iain Sandoe 2013-01-23 19:59:40
UTC ---
(In reply to comment #31)
> solution on darwin is to mark the duplicate symbols in crttme.o as weak.
seems reasonable - can you try that?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56087
Thorsten Glaser changed:
What|Removed |Added
Keywords||wrong-code
Target|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #33 from Iain Sandoe 2013-01-23 20:14:26
UTC ---
(In reply to comment #32)
> (In reply to comment #31)
>
> > solution on darwin is to mark the duplicate symbols in crttme.o as weak.
>
> seems reasonable - can you try that?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56047
--- Comment #15 from Jürgen Reuter 2013-01-23
20:26:48 UTC ---
Am 23/1/13 5:25 PM, schrieb rguenth at gcc dot gnu.org:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56047
>
> Richard Biener changed:
>
> What|Removed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #34 from Iain Sandoe 2013-01-23 20:35:47
UTC ---
(In reply to comment #24)
> However, in this case, the references *are* present on the link line (lstdc++)
> but also a duplicate in crttme.o
> since -lstdc++ is on the li
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56088
Bug #: 56088
Summary: LTO error: error: inlining failed in call to
always_inline ‘vswprintf’: recursive inlining
Classification: Unclassified
Product: gcc
Version: 4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56088
--- Comment #1 from Václav Zeman 2013-01-23
20:45:10 UTC ---
Created attachment 29259
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29259
output log
eric --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
--with-gmp=/usr --with-mpc=/usr --with-mpfr=/usr --with-cloog=/usr GNAT=gnatgcc
--enable-bootstrap LD=ld.gold
Thread model: posix
gcc version 4.8.0 20130123 (experimental) [trunk revision 195409] (wilx/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56086
--- Comment #1 from joseph at codesourcery dot com 2013-01-23 20:47:49 UTC ---
Why do you think this is a bug? GCC meets the semantics of that macro
(that char16_t values are UTF-16 encoded), and gnu99 mode enables u""
strings.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56088
--- Comment #3 from Andrew Pinski 2013-01-23
20:49:23 UTC ---
Can you provide the preprocessed source that was used to generate timehelper.o?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56088
--- Comment #4 from Václav Zeman 2013-01-23
20:53:52 UTC ---
Created attachment 29260
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29260
preprocessed source of timehelper.cxx
Here is the preprocessed source.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56089
Bug #: 56089
Summary: Instruction Scheduling error
Classification: Unclassified
Product: gcc
Version: 3.3.2
Status: UNCONFIRMED
Severity: critical
Priority
1 - 100 of 131 matches
Mail list logo
