https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84563
torvald at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
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=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=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=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're c
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=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
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=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 #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=65033
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=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=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=70638
--- Comment #1 from torvald at gcc dot gnu.org ---
Created attachment 38244
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38244=edit
test case
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
torvald at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59218
torvald at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63472
torvald at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60908
torvald at gcc dot gnu.org changed:
What|Removed |Added
CC||spear at cse dot lehigh.edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63550
--- Comment #2 from torvald at gcc dot gnu.org ---
Created attachment 37422
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37422=edit
Test case part 2/3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69018
torvald at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60908
--- Comment #4 from torvald at gcc dot gnu.org ---
Still happens with r232693.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63550
--- Comment #3 from torvald at gcc dot gnu.org ---
Created attachment 37423
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37423=edit
Test case part 3/3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53991
--- Comment #9 from torvald at gcc dot gnu.org ---
Still fails with r232693.
This seems to be another case of difficult ordering between TM passes and other
passes. It makes sense that we don't inline tm_pure because we must not loose
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57855
torvald at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63550
--- Comment #1 from torvald at gcc dot gnu.org ---
Created attachment 37421
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37421=edit
Test case part 1/3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57348
torvald at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63550
torvald at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69310
--- Comment #14 from torvald at gcc dot gnu.org ---
Author: torvald
Date: Wed Jan 20 17:47:03 2016
New Revision: 232628
URL: https://gcc.gnu.org/viewcvs?rev=232628=gcc=rev
Log:
libstdc++: Darwin does not support weak refs without definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69310
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 #11 from torvald at gcc dot gnu.org ---
(In reply to Jack Howarth from comment #10)
> It is unclear if the changes in r232454, to avoid the explicit linkage on
> libitm, can ever be made darwin-friendly. On darwin, every
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69310
--- Comment #7 from torvald at gcc dot gnu.org ---
Does this patch fix the issue on Darwin?
https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01452.html
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
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 #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
Target Milestone|--- |6.0
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=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
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++ std h
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.
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=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 is a problem her
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=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
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=edit
test case
In the attached case, the compiler seems to assume that in main_thread, ptr
st
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
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=edit
test case
The attached test c
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=67281
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=59767
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 the specification
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 #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 to mean
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 easier route to fixing any
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). That's perhaps
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 C11 S7.17.7.4-2 (C++11 S29.6.4-21
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 model
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
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.gnu.org/onlinedocs/gcc/_005f_005fsync
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 barriers
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 generated is
using
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 consume-to-acquire promotion
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])
__transaction_atomic {
lbl_196
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=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
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=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=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=56801
torvald at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC
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=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_acquire for now?
I
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 so by allowing
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 best way
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: 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=32804action=edit
test case
See attached test case. I'm not quite sure how we need
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
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, ... and needs to also
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_consume
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
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=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=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_pure
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:
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
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=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 rather than atomic
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=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.
OTOH, it would
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=52839
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
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=gccview=revrev=185358
Log:
libitm: Fix lost wake-up in serial lock
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=gccview=revrev=185360
Log:
libitm: Fix lost wake-up in serial lock
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=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=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=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])
x[i] += data
1 - 100 of 121 matches
Mail list logo
