http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56419
Bug #: 56419
Summary: [4.8 regression] transactions in for-loops disappear
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: norm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54893
--- Comment #3 from torvald at gcc dot gnu.org 2012-10-11 19:54:11 UTC ---
I agree with Michael. Accesses to volative vars are disallowed in safe code,
but relaxed transactions can run unsafe code (after going irrevocable). The
test case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53991
--- Comment #7 from torvald at gcc dot gnu.org ---
A piece of code is tm_pure if, roughly, it doesn't need any instrumentation
(e.g., in contrast to memory loads/stores). In the test case, I suppose that
the compiler detects that it is tm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57643
torvald at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51031
--- Comment #5 from torvald at gcc dot gnu.org 2011-11-09 12:28:28 UTC ---
The weak alias issue has been resolved in rev 181182. The TLS thingy in 181163.
Regarding the vector loads/stores and your assembler not knowing about .cfi, I
don't
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53008
torvald at gcc dot gnu.org changed:
What|Removed |Added
CC||torvald at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52558
--- Comment #20 from torvald at gcc dot gnu.org 2012-05-31 20:23:51 UTC ---
(In reply to comment #19)
> Fixed on mainline. I doubt this will be fixed on 4.7, as this is too
> intrusive-- unless one of the RMs really wants it on 4.7.
OT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49581
torvald at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51771
--- Comment #3 from torvald at gcc dot gnu.org 2012-01-31 13:20:32 UTC ---
Created attachment 26532
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26532
test for false returns-twice warning
Attached a test that triggers a false warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51771
torvald at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51752
--- Comment #6 from torvald at gcc dot gnu.org 2012-02-09 18:40:49 UTC ---
(In reply to comment #4)
> But isn't with
>
> __transaction_atomic
> {
> for (i = 0; i < 10; i++)
> if (x[i]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52526
torvald at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52526
--- Comment #1 from torvald at gcc dot gnu.org 2012-03-10 17:46:12 UTC ---
Patrick, I posted a fix to gcc-patches. Please have a look if you can.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52558
torvald at gcc dot gnu.org changed:
What|Removed |Added
Component|tree-optimization |c++
--- Comment #12 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52526
--- Comment #3 from torvald at gcc dot gnu.org 2012-03-13 22:01:41 UTC ---
Author: torvald
Date: Tue Mar 13 22:01:34 2012
New Revision: 185358
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185358
Log:
libitm: Fix lost wake-up i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52526
--- Comment #4 from torvald at gcc dot gnu.org 2012-03-13 22:11:52 UTC ---
Author: torvald
Date: Tue Mar 13 22:11:46 2012
New Revision: 185360
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185360
Log:
libitm: Fix lost wake-up i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52526
torvald at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839
torvald at gcc dot gnu.org changed:
What|Removed |Added
CC||torvald at gcc dot gnu.org
Severity: minor
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: torvald at gcc dot gnu.org
CC: aldyh at gcc dot gnu.org
Accesses to volatiles are disallowed in transaction-safe code. The following
should produce an error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59218
torvald at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48023
torvald at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47611
torvald at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47747
torvald at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51752
Bug #: 51752
Summary: trans-mem: publication safety violated
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51752
torvald at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51771
Bug #: 51771
Summary: trans-mem: abnormal edges get lost or corrupted
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51771
--- Comment #1 from torvald at gcc dot gnu.org 2012-01-05 23:48:36 UTC ---
Author: torvald
Date: Thu Jan 5 23:48:30 2012
New Revision: 182937
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182937
Log:
Mark transaction begin as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51774
torvald at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51752
torvald at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.8.0
--- Comment #2 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51173
torvald at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51124
torvald at gcc dot gnu.org changed:
What|Removed |Added
CC||torvald at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48625
torvald at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51124
torvald at gcc dot gnu.org changed:
What|Removed |Added
CC||rth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51855
Bug #: 51855
Summary: improve calculation of stack bottom in libitm's
undolog
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
S
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51855
torvald at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
Status
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51855
--- Comment #2 from torvald at gcc dot gnu.org 2012-01-13 23:45:12 UTC ---
Author: torvald
Date: Fri Jan 13 23:45:06 2012
New Revision: 183172
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183172
Log:
libitm: Filter out undo wri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70490
torvald at gcc dot gnu.org changed:
What|Removed |Added
CC||torvald at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84563
torvald at gcc dot gnu.org changed:
What|Removed |Added
CC||torvald at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84563
torvald at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48076
--- Comment #7 from torvald at gcc dot gnu.org 2012-11-28 14:29:47 UTC ---
(In reply to comment #6)
> There seems to be a similar bug in code generated for function static
> variables.
> The fast-path load is a plain load ra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51771
torvald at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
torvald at gcc dot gnu.org changed:
What|Removed |Added
CC||torvald at gcc dot
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: torvald at gcc dot gnu.org
Target Milestone: ---
The attached test case shows two issues with transaction_wrap:
1) If the original function is not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70638
--- Comment #1 from torvald at gcc dot gnu.org ---
Created attachment 38244
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38244&action=edit
test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70638
--- Comment #3 from torvald at gcc dot gnu.org ---
(In reply to Hillel Avni from comment #2)
> On gcc-linaro-4.9-2014.11, I must declare the wrapper as pure.
But using that version the wrapper was indeed used and not the original
funct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71133
--- Comment #2 from torvald at gcc dot gnu.org ---
I think it's easiest to disable the TM support on less-than-32b targets.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78158
--- Comment #19 from torvald at gcc dot gnu.org ---
(In reply to Dmitry Vyukov from comment #8)
> We need to modify tsan runtime to ignore (zero) __ATOMIC_HLE_ACQUIRE/RELEASE
> bits, right? It's only an optimization and we can p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26461
--- Comment #15 from torvald at gcc dot gnu.org ---
From a ISO C/C++ conformance perspective, this is not a bug:
* Pre-C11/C++11, threading was basically undefined.
* Starting with C11 and C++11, "threads of execution" (as they'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80640
torvald at gcc dot gnu.org changed:
What|Removed |Added
CC||torvald at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744
--- Comment #15 from torvald at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #14)
> Looking at that patchset, I just want to say that the use of TLS in libgcc
> is very much undesirable, it affects every program even when not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744
--- Comment #21 from torvald at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #17)
> (In reply to torvald from comment #15)
> > > Similarly, the 64 recursive locks in libc, again, significant amount of
> > > mem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744
--- Comment #28 from torvald at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #20)
> (In reply to Gleb Natapov from comment #19)
> > (In reply to Jakub Jelinek from comment #18)
> > > (In reply to Gleb Natapo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53991
--- Comment #12 from torvald at gcc dot gnu.org ---
Thanks for reporting that you are affected as well. Regarding your question
about bumping the priority, one problem for the TM support in general has been
to be able to judge how many users are
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: torvald at gcc dot gnu.org
Created attachment 32804
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32804&action=edit
test case
See attached test case. I'm not quite sure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61199
torvald at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #6 from torvald at gcc dot gnu.org ---
(In reply to torvald from comment #5)
> (In reply to Matthew Wahab from comment #0)
> > while a __sync full
> > barrier should block all movement
> > (https://gcc.g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #5 from torvald at gcc dot gnu.org ---
(In reply to Matthew Wahab from comment #0)
> The __sync builtins are implemented by expanding them to the equivalent
> __atomic builtins, using MEMMODEL_SEQ_CST for those that are full ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #21 from torvald at gcc dot gnu.org ---
(In reply to Andrew Haley from comment #20)
> (In reply to mwahab from comment #19)
> > (In reply to Andrew Haley from comment #18)
> >
> > It looks inconsistent with C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #22 from torvald at gcc dot gnu.org ---
(In reply to James Greenhalgh from comment #12)
> There are two problems here, one of which concerns me more in the real
> world, and both of which rely on races if you are in the C/C++11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #24 from torvald at gcc dot gnu.org ---
I think we need to at least clarify the documentation of __atomic, probably
also of __sync; we might also have to change the implementation of __sync
builtins on some archs.
First, I think the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #32 from torvald at gcc dot gnu.org ---
(In reply to James Greenhalgh from comment #28)
> (In reply to torvald from comment #24)
> > 3) We could do something just on ARM (and scan other arcs for similar
> > issues).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #37 from torvald at gcc dot gnu.org ---
(In reply to James Greenhalgh from comment #35)
> (In reply to torvald from comment #32)
> > (In reply to James Greenhalgh from comment #28)
> > > This also gives us an easi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #38 from torvald at gcc dot gnu.org ---
(In reply to Andrew Macleod from comment #34)
> > However, I guess some people relying on data races in their programs could
> > (mis?)understand the __sync_lock_release semantics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51617
torvald at gcc dot gnu.org changed:
What|Removed |Added
CC||torvald at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #49 from torvald at gcc dot gnu.org ---
(In reply to James Greenhalgh from comment #43)
> (In reply to torvald from comment #37)
> > (In reply to James Greenhalgh from comment #35)
> > > So by the strict letter of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
torvald at gcc dot gnu.org changed:
What|Removed |Added
CC||rth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
--- Comment #12 from torvald at gcc dot gnu.org ---
(In reply to algrant from comment #11)
> Where do you get that this is racy if the access to data is not atomic?
In threadB(), you do:
f = flag.load(std::memory_order_cons
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60272
--- Comment #2 from torvald at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #1)
> So, either we'd need to change this function, so that it sets oldval to
> NULL_RTX
> first, and passes ..., &oldval, mem, expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66453
torvald at gcc dot gnu.org changed:
What|Removed |Added
CC||torvald at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66453
torvald at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52482
torvald at gcc dot gnu.org changed:
What|Removed |Added
CC||torvald at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53113
torvald at gcc dot gnu.org changed:
What|Removed |Added
CC||torvald at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56801
torvald at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61594
torvald at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52695
--- Comment #8 from torvald at gcc dot gnu.org ---
Can this bug be closed? It sounds as if this has been fixed in 4.8 already;
given that TM is experimental, backporting the fix is probably not worth it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52482
--- Comment #11 from torvald at gcc dot gnu.org ---
Thanks for confirming. However, that fails before libitm, for which you should
file a separate bug report. Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61594
--- Comment #6 from torvald at gcc dot gnu.org ---
We can keep it open, but my guess is that it would need some volunteer to
actively drive the backporting process. I.e., with a patch and testing. Given
that TM is experimental, I think
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61594
torvald at gcc dot gnu.org changed:
What|Removed |Added
Version|5.0 |4.9.1
--- Comment #7 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63472
--- Comment #6 from torvald at gcc dot gnu.org ---
(In reply to ak from comment #4)
> copy_bbs:
>
> (illegal code due to goto into transaction?)
>
> g_56[];
> fn1() {
> int *p_79;
> if (g_56[7])
> __transac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64930
--- Comment #5 from torvald at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #3)
> Created attachment 34731 [details]
> gcc5-pr64930.patch
>
> Thus I'm proposing this untested patch.
I think expecting the c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64930
--- Comment #12 from torvald at gcc dot gnu.org ---
(In reply to Alan Modra from comment #9)
> My point was that if you write a testcase that specifically tests for
> consume and get acquire code then that is a fail. The code genera
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
--- Comment #17 from torvald at gcc dot gnu.org ---
(In reply to Andrew Macleod from comment #15)
> So have we concluded that we should promote memory_order_consume to
> memory_order_acquire for now?
I also think that this is the be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
--- Comment #20 from torvald at gcc dot gnu.org ---
(In reply to jos...@codesourcery.com from comment #19)
> * carries_dependency is about increasing optimization, not decreasing it.
> If it affects when barriers are added, it does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
--- Comment #21 from torvald at gcc dot gnu.org ---
(In reply to torvald from comment #17)
> (In reply to Andrew Macleod from comment #15)
> > So have we concluded that we should promote memory_order_consume to
> > memory_order_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61393
--- Comment #9 from torvald at gcc dot gnu.org ---
Alex, can you confirm that this is fixed?
Priority: P3
Component: libitm
Assignee: unassigned at gcc dot gnu.org
Reporter: torvald at gcc dot gnu.org
Target Milestone: ---
Created attachment 36860
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36860&action=edit
test case
The attached te
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68591
torvald at gcc dot gnu.org changed:
What|Removed |Added
CC||rth at gcc dot gnu.org
Assignee: unassigned at gcc dot gnu.org
Reporter: torvald at gcc dot gnu.org
Target Milestone: ---
Created attachment 36871
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36871&action=edit
test case
In the attached case, the compiler seems to assume that in main_thre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68122
--- Comment #9 from torvald at gcc dot gnu.org ---
Marek, just skipping handling of internal functions is not correct I think. In
the worst case, it should treat them as txn-unsafe, unless they are considered
txn-pure. Do we have some idea of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68616
--- Comment #2 from torvald at gcc dot gnu.org ---
I basically don't know anything about IPA, so I'll just assume that by
"barrier" you mean conditions prohibiting transformations. I'm also not sure
whether just CSE i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68122
--- Comment #11 from torvald at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #10)
> There are lots of internal functions in GCC 6 (older versions had fewer).
> Many of them are ECF_CONST, which is also treated like txn_pure,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68591
--- Comment #3 from torvald at gcc dot gnu.org ---
This might be related to bug 68616.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68921
--- Comment #3 from torvald at gcc dot gnu.org ---
LGTM, thanks. Would be nice to backport this.
IRMED
Severity: normal
Priority: P3
Component: libitm
Assignee: unassigned at gcc dot gnu.org
Reporter: torvald at gcc dot gnu.org
Target Milestone: ---
If a tests sets an option (eg, // { dg-options "-fgnu-tm" }), then the include
paths for C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69310
--- Comment #2 from torvald at gcc dot gnu.org ---
(In reply to İsmail Dönmez from comment #1)
> r232454 also breaks bootstrap for mingw-w64:
>
> libtool: compile: x86_64-w64-mingw32-c++
> -L/havana/mingw-w64-6.0.0/x86_64-w64-ming
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61199
torvald at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61199
torvald at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |6.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69310
--- Comment #4 from torvald at gcc dot gnu.org ---
(In reply to İsmail Dönmez from comment #3)
> (In reply to torvald from comment #2)
> > (In reply to İsmail Dönmez from comment #1)
> > > r232454 also breaks boots
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69312
torvald at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69310
--- Comment #6 from torvald at gcc dot gnu.org ---
(In reply to Jack Howarth from comment #5)
> (In reply to torvald from comment #4)
>
> > See https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01203.html
> > (Not linked to this bu
1 - 100 of 121 matches
Mail list logo
