http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60465
Mike Frysinger changed:
What|Removed |Added
CC||vapier at gentoo dot org
--- Comment #2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60558
Mike Frysinger changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60558
Bug ID: 60558
Summary: building glibc-2.19 w/gcc-4.8.x on ia64 produces bad
ld.so
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Prio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60465
devurandom at gmx dot net changed:
What|Removed |Added
Target||ia64-unknown-linux-gnu
Kn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55383
--- Comment #12 from Magnus Reftel ---
Any suggestions on how to progress with this one?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60504
--- Comment #8 from Mikael Pettersson ---
(In reply to Mikael Pettersson from comment #5)
> Sorry, no joy. With Eric's suggested patch I still got:
Correction: Eric's suggested patch does work. In my previous attempt I applied
his patch and onl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60559
Bug ID: 60559
Summary: g++.dg/vect/pr60023.cc fails with -fno-tree-dce (ICE)
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57521
--- Comment #7 from Richard Biener ---
Author: rguenth
Date: Tue Mar 18 08:46:21 2014
New Revision: 208632
URL: http://gcc.gnu.org/viewcvs?rev=208632&root=gcc&view=rev
Log:
2014-03-18 Richard Biener
Backport from mainline
2013-08-27
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57656
--- Comment #7 from Richard Biener ---
Author: rguenth
Date: Tue Mar 18 08:46:21 2014
New Revision: 208632
URL: http://gcc.gnu.org/viewcvs?rev=208632&root=gcc&view=rev
Log:
2014-03-18 Richard Biener
Backport from mainline
2013-08-27
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57517
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57521
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57517
--- Comment #7 from Richard Biener ---
Author: rguenth
Date: Tue Mar 18 08:46:21 2014
New Revision: 208632
URL: http://gcc.gnu.org/viewcvs?rev=208632&root=gcc&view=rev
Log:
2014-03-18 Richard Biener
Backport from mainline
2013-08-27
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57656
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60560
Bug ID: 60560
Summary: Problem allocating character array with assumed length
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60561
Bug ID: 60561
Summary: ICE in gimplify_var_or_parm_decl, at gimplify.c:1721
for gfortran.dg/associate_1.f03
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Sever
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60557
--- Comment #6 from Tobias Burnus ---
(In reply to Jakub Jelinek from comment #5)
> This should hopefully fix it.
Looks good to me. For the testcase of comment 1, it also gives the expected
run-time diagnostic:
test.f90:19: runtime error: signed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60561
Richard Biener changed:
What|Removed |Added
Keywords||accepts-invalid,
|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60561
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60561
--- Comment #3 from Dominique d'Humieres ---
> So it should be rejected without -std=f2003?
Compiling the code with -std=f2003 -fall-intrinsics gives the ICE (without
-fall-intrinsics there is a link error
Undefined symbols for architecture x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60561
--- Comment #4 from Dominique d'Humieres ---
The ICE is in the following subroutine
SUBROUTINE test_char (n)
INTEGER, INTENT(IN) :: n
CHARACTER(LEN=n) :: str
str = "foobar"
ASSOCIATE (my => str)
END ASSOCIATE
END SUBROUT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60562
Bug ID: 60562
Summary: ’4.9 Regression] FAIL:
gcc.target/i386/excess-precision-3.c execution test on
x86_64-apple-darwin13
Product: gcc
Version: 4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60039
--- Comment #8 from Nick Hudson ---
On 03/18/14 02:34, kkojima at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60039
>
> --- Comment #7 from Kazumoto Kojima ---
> Ugh, then this is an old problem and we've missed to give a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60563
Bug ID: 60563
Summary: FAIL: g++.dg/ext/sync-4.C on *-apple-darwin*
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: targe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128
Rainer Orth changed:
What|Removed |Added
Status|RESOLVED|REOPENED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60553
--- Comment #5 from Richard Biener ---
next_variant->type_name->type->next_variant->type-name->decl_original_type->type_name->decl_context->next_variant->type_context->next_variant->next_variant->next_variant->type_fields->type->...
it's walking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60465
--- Comment #4 from Andreas Schwab ---
How about showing the previous ~20 insns here.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60504
--- Comment #9 from Eric Botcazou ---
> Correction: Eric's suggested patch does work. In my previous attempt I
> applied his patch and only did an incremental rebuild, and that didn't
> resolve all testsuite regressions. Now I've done a clean bu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57522
--- Comment #6 from Dominique d'Humieres ---
Any reason why tho PR is not closed as fixed?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57522
--- Comment #7 from Dominique d'Humieres ---
*** Bug 58339 has been marked as a duplicate of this bug. ***
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58339
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57522
Paul Thomas changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58941
--- Comment #8 from Richard Biener ---
Author: rguenth
Date: Tue Mar 18 10:58:22 2014
New Revision: 208640
URL: http://gcc.gnu.org/viewcvs?rev=208640&root=gcc&view=rev
Log:
2014-03-18 Richard Biener
Backport from mainline
2013-11-05
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60419
--- Comment #8 from Jakub Jelinek ---
FYI, since r208573 the reduced ppc64 testcase no longer reproduces, but the #c0
still does.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128
--- Comment #15 from Dominique d'Humieres ---
What is the output of
write(*,"(en15.1)") 9.4905
end
? If it is 9.4, it means that your snprintf is not rounding to nearest but to
zero.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60561
Tobias Burnus changed:
What|Removed |Added
Keywords|accepts-invalid,|ice-on-valid-code
|ice-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60553
--- Comment #6 from Richard Biener ---
Another idea would be (many next-variant walks in the call stack)
Index: lto/lto-tree.h
===
--- lto/lto-tree.h (revision 208615)
+++ lto/l
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58941
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128
--- Comment #16 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #15 from Dominique d'Humieres ---
> What is the output of
>
> write(*,"(en15.1)") 9.4905
> end
>
> ? If it is 9.4, it means that your snprintf is not rounding to neares
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128
--- Comment #17 from Dominique d'Humieres ---
Could your repeat the test for
write(*,"(en15.1)") 9.4905_8
end
write(*,"(en15.1)") 9.4905_10
end
and
write(*,"(en15.1)") 9.4905_16
end
?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60325
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60325
--- Comment #4 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #3)
> Thus fixed?
Hard to say, but the testsuite failure is gone and we have no testcase...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60504
--- Comment #10 from Mikael Pettersson ---
(In reply to Eric Botcazou from comment #9)
> That's good news, thanks. Did you do a testsuite run for all languages?
Sorry, didn't have time for that -- the repeated 4.9 builds and tests caused
other b
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55896
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60133
--- Comment #2 from Jakub Jelinek ---
Hasn't this been fixed by r208383 and r208384 ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58721
--- Comment #23 from Jakub Jelinek ---
Author: jakub
Date: Tue Mar 18 11:31:04 2014
New Revision: 208641
URL: http://gcc.gnu.org/viewcvs?rev=208641&root=gcc&view=rev
Log:
PR ipa/58721
gcc/
* internal-fn.c: Include diagnostic-core.h.
(
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55896
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59487
Bug 59487 depends on bug 58721, which changed state.
Bug 58721 Summary: [4.9 Regression] The subroutine perdida is no longer inlined
in fatigue.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58721
What|Removed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58721
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60315
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #8 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60562
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |4.9.0
Summary|’4.9 Regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55896
--- Comment #3 from sworddragon2 at aol dot com ---
> why aren't you using strlen???
Because of this bug (if it should be still valid):
https://bugs.launchpad.net/ubuntu/+source/gcc-4.7/+bug/1035321
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128
--- Comment #18 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #17 from Dominique d'Humieres ---
> Could your repeat the test for
>
> write(*,"(en15.1)") 9.4905_8
> end
9.5E+00
> write(*,"(en15.1)") 9.4905_10
> end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55896
--- Comment #4 from Jakub Jelinek ---
(In reply to sworddragon2 from comment #3)
> > why aren't you using strlen???
>
> Because of this bug (if it should be still valid):
> https://bugs.launchpad.net/ubuntu/+source/gcc-4.7/+bug/1035321
That is a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128
--- Comment #19 from Dominique d'Humieres ---
> > write(*,"(en15.1)") 9.4905_16
> > end
>
> 9.4E+00
So the test fails due to a bug in the rounding of real(16) in your lib. Do you
have any idea about how the tests for real(16) can be s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60564
Bug ID: 60564
Summary: [C++11] The std::packaged_task constructor taking a
reference to a functor does not copy its argument.
Product: gcc
Version: 4.8.0
Status: UNCONFIRM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55383
--- Comment #13 from Manuel López-Ibáñez ---
(In reply to Magnus Reftel from comment #12)
> Any suggestions on how to progress with this one?
Looking at the testcases modified by the patch, I don't know why there is no
test for volatile (which is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60459
Raghu changed:
What|Removed |Added
Severity|normal |critical
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60438
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
--- Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60564
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60562
Dominique d'Humieres changed:
What|Removed |Added
Target|x86_64-apple-darwin1* |
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60438
--- Comment #38 from Dominique d'Humieres ---
> Hi, this seems to have created a new regression:
>
> FAIL: gcc.target/i386/excess-precision-3.c execution test
pr60562
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128
--- Comment #20 from Jerry DeLisle ---
We can xfail the test case if we are certain of the problem.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60564
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |4.8.3
Summary|[C++11] The
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128
--- Comment #21 from Dominique d'Humieres ---
> We can xfail the test case if we are certain of the problem.
What I don't see is how to xfail only some tests for real(16). Anyway, Rainer
could open a new PR for the solaris issue and close this on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60565
Bug ID: 60565
Summary: Bogus not-in-scope error
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: u
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128
--- Comment #22 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #19 from Dominique d'Humieres ---
>> > write(*,"(en15.1)") 9.4905_16
>> > end
>>
>> 9.4E+00
>
> So the test fails due to a bug in the rounding of real(16) in yo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60565
--- Comment #1 from patrick at parcs dot ath.cx ---
Er, sorry, the call to "foo ()" within main ought to be "B::foo ()".
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128
--- Comment #23 from Dominique d'Humieres ---
> I'm not sure that's the problem: AFAICS snprintf is only used by
> io/write_float.def (output_float:734) to print the exponent, the rest is
> handled by quadmath_snprintf.
The failing tests assume r
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60565
--- Comment #2 from Jonathan Wakely ---
(In reply to patrick from comment #0)
> $ g++ -c exc.C
> exc.C:8:26: warning: declaration of ‘void B::foo()’ with C language linkage
> [enabled by default]
> extern "C" void foo ();
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60565
--- Comment #3 from Jonathan Wakely ---
(In reply to patrick from comment #1)
> Er, sorry, the call to "foo ()" within main ought to be "B::foo ()".
OK, in that case you need to fix the declaration of B::foo() if you want to
call it. I think G++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60559
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60559
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55896
--- Comment #5 from Marek Polacek ---
(In reply to Jakub Jelinek from comment #2)
> you could just use w_strlen (contents_1 + 1) and the warning could go away.
This causes that two warnings are emitted :(. If strlen can't be used (ugh),
then e.g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60565
--- Comment #4 from patrick at parcs dot ath.cx ---
(In reply to Jonathan Wakely from comment #3)
> (In reply to patrick from comment #1)
> > Er, sorry, the call to "foo ()" within main ought to be "B::foo ()".
>
> OK, in that case you need to fix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60459
--- Comment #4 from Ramana Radhakrishnan ---
(In reply to Raghu from comment #3)
> (In reply to Andrew Pinski from comment #1)
> > Can you try a newer version than GCC 4.2.1?
> >
> > Also can you provide the exact options you compiled your source
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59543
--- Comment #8 from Richard Biener ---
I think 2) is the issue, so does
Index: lto-streamer-in.c
===
--- lto-streamer-in.c (revision 208642)
+++ lto-streamer-in.c (working copy)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60562
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59543
--- Comment #9 from Richard Biener ---
I'm doing a LTO profiledbootstrap with this - Markus, can you check if this
fixes your problem?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59487
Richard Biener changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60535
--- Comment #6 from Jakub Jelinek ---
Author: jakub
Date: Tue Mar 18 14:56:23 2014
New Revision: 208651
URL: http://gcc.gnu.org/viewcvs?rev=208651&root=gcc&view=rev
Log:
PR sanitizer/60535
* ubsan.c (ubsan_type_descriptor, ubsan_create_da
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60535
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60557
--- Comment #7 from Jakub Jelinek ---
Author: jakub
Date: Tue Mar 18 15:05:30 2014
New Revision: 208652
URL: http://gcc.gnu.org/viewcvs?rev=208652&root=gcc&view=rev
Log:
PR sanitizer/60557
* ubsan.c (ubsan_instrument_unreachable): Call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60557
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60438
--- Comment #39 from linzj ---
(In reply to Richard Henderson from comment #35)
thanks for the fix.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60562
Richard Henderson changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigne
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60553
--- Comment #7 from Martin Liška ---
Patches helped me!
First one was sufficient for my simplified case (~800 files), but it was
necessary to add second one for chromium.
Will you add this changes to mainline or should I create a patch?
Thanks,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60507
--- Comment #4 from janus at gcc dot gnu.org ---
(In reply to janus from comment #3)
> The patch in comment #2 ICEs on this extended test case:
Here is a better patch which works on comment 2:
Index: gcc/fortran/interface.c
=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60550
janus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||ice-on-valid-code
S
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60562
--- Comment #4 from Jakub Jelinek ---
BTW, it is actually 4 tests in excess-precision-3.c that fail now:
if ((float)i1 != 0x1.0p30f)
abort ();
if ((float)u1 != 0x1.0p31f)
abort ();
if ((float)ll1 != 0x1.0p62f)
abort ();
...
if
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60565
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57703
--- Comment #4 from Martin Liška ---
Hm, it looks that there's an usage of top-level function chromium binary:
/tmp/cckAZyDK.ltrans26.ltrans.o:cckAZyDK.ltrans26.o:function
sandbox::Die::ExitGroup(): error: undefined reference to 'SyscallAsm'
/tmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60566
Bug ID: 60566
Summary: [4.9 Regression] r208573 miscompiles kdelibs
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60305
--- Comment #3 from Paolo Carlini ---
Let's add the testcase to mainline and close this.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60564
--- Comment #3 from Jonathan Wakely ---
Author: redi
Date: Tue Mar 18 16:30:28 2014
New Revision: 208655
URL: http://gcc.gnu.org/viewcvs?rev=208655&root=gcc&view=rev
Log:
PR libstdc++/60564
* include/std/future (__future_base::_Task_state
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60564
--- Comment #4 from Jonathan Wakely ---
Author: redi
Date: Tue Mar 18 16:31:38 2014
New Revision: 208656
URL: http://gcc.gnu.org/viewcvs?rev=208656&root=gcc&view=rev
Log:
PR libstdc++/60564
* include/std/future (__future_base::_Task_state
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60564
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Known to work|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57485
Marek Polacek changed:
What|Removed |Added
Component|c |middle-end
--- Comment #2 from Marek Pola
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60223
--- Comment #2 from Paolo Carlini ---
Marek, are you sure about r180707 ?!? It's supposed to be only about command
line options names... Please confirm and in case CC Jason.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57485
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60528
--- Comment #1 from Steve Ellcey ---
An additional data point, If I build a MIPS cross compiler as a 32 bit x86
object then it does the right thing, if I build the cross compiler as a 64 bit
object then I get incorrect results. The 4.8.1 compiler
1 - 100 of 175 matches
Mail list logo
