https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113317
--- Comment #5 from jules at gcc dot gnu.org ---
Hi,
Unfortunately I no longer have access to any PowerPC machines, which limits my
ability to help with this somewhat. I guess it's *something* like a
CONVERT_EXPR/NOP_EXPR in an unexpected place
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113317
jules at gcc dot gnu.org changed:
What|Removed |Added
CC||jules at gcc dot gnu.org
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jules at gcc dot gnu.org
Target Milestone: ---
Created attachment 57037
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57037=edit
Test case
The attached file fails to comp
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: jules at gcc dot gnu.org
Target Milestone: ---
The patch (approved and soon to be committed) to support "lvalue" parsing for
C++ has a c
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: jules at gcc dot gnu.org
Target Milestone: ---
The following test:
libgomp/testsuite/libgomp.c++/baseptrs-4.C
partly depends on the following in-review patches:
https
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: jules at gcc dot gnu.org
Target Milestone: ---
According to e.g. OpenMP 5.2, "5.8.2 Mapper Identifiers and mapper Modifiers":
"A structure type T has a predefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108624
jules at gcc dot gnu.org changed:
What|Removed |Added
CC||jules at gcc dot gnu.org
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jules at gcc dot gnu.org
Target Milestone: ---
Since revision 2b8453c401b699ed93c085d0413ab4b5030bcdb8 I am seeing several
OpenMP tests fail with misaligned access errors:
PASS -> F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95590
--- Comment #1 from jules at gcc dot gnu.org ---
In discussion:
https://gcc.gnu.org/pipermail/gcc-patches/2020-June/548679.html
https://gcc.gnu.org/pipermail/gcc-patches/2020-July/550623.html
https://gcc.gnu.org/pipermail/gcc-patches/2020-July
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95270
--- Comment #2 from jules at gcc dot gnu.org ---
TBH I've suspected problems with misuse of the bias for attach/detach before,
but I've not come up with a test case. I'll have a look.
Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92929
--- Comment #7 from jules at gcc dot gnu.org ---
Test case & further discussion in:
https://gcc.gnu.org/pipermail/gcc-patches/2020-June/547424.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93025
jules at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93030
--- Comment #1 from jules at gcc dot gnu.org ---
Thanks for the report -- there's a fix for this on the og9 branch, but I'm not
sure if I've posted that upstream (the GCN worker-partitioning patches were
separated out from the deep-copy patches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92929
--- Comment #6 from jules at gcc dot gnu.org ---
Apologies for breakage. This part of the patch was originally from the og9
patch supporting Fortran polymorphic class pointers posted at
https://gcc.gnu.org/ml/gcc-patches/2019-07/msg00752.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92881
--- Comment #1 from jules at gcc dot gnu.org ---
Author: jules
Date: Fri Dec 13 23:14:15 2019
New Revision: 279388
URL: https://gcc.gnu.org/viewcvs?rev=279388=gcc=rev
Log:
Fix potential race condition in OpenACC "exit data"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92843
--- Comment #12 from jules at gcc dot gnu.org ---
For an adaptation of the refcount checking code as alluded to above -- see
PR92848.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92848
--- Comment #6 from jules at gcc dot gnu.org ---
Created attachment 47479
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47479=edit
Regressions with rc checking enabled
These are the OpenACC tests that regress with refcount check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92848
jules at gcc dot gnu.org changed:
What|Removed |Added
Attachment #47451|0 |1
is obsolete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92848
--- Comment #5 from jules at gcc dot gnu.org ---
Created attachment 47478
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47478=edit
Refcount checking for current trunk
Hi,
This is a merge of the refcount checking patch to current tr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92848
--- Comment #4 from jules at gcc dot gnu.org ---
(In reply to Thomas Schwinge from comment #3)
> (In reply to jules from comment #2)
> > Again, please don't change this code under the feet of the refcount overhaul
> > patc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92843
--- Comment #9 from jules at gcc dot gnu.org ---
FWIW, I wrote this at the time wrt. the refcounting changes (some parts refer
to a previous iteration of the manual deep copy patches)...
Writing a couple of new attach/detach tests, I realised
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92843
--- Comment #8 from jules at gcc dot gnu.org ---
(In reply to Thomas Schwinge from comment #7)
> We first need to establish a stable baseline, with test cases, and then (or,
> as part of that) merge the several independent pieces of t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92854
--- Comment #6 from jules at gcc dot gnu.org ---
Created attachment 47453
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47453=edit
Patch for acc_map_data-device_already-3.c problem
This patch fixes the acc_map_data-device_already-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92848
--- Comment #2 from jules at gcc dot gnu.org ---
Again, please don't change this code under the feet of the refcount overhaul
patch! Using the (currently OpenMP-specific) GOMP_MAP_VARS_ENTER_DATA is going
to end up mighty confusing from OpenACC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92843
--- Comment #6 from jules at gcc dot gnu.org ---
Please don't start making changes to the reference-counting code that is being
replaced by my overhaul patch. The existing code was rewritten for a reason --
that being, I hit various problems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92854
--- Comment #5 from jules at gcc dot gnu.org ---
Huh, yes, I missed that line in the spec (about existing mappings). I'll have a
look at the test case you mentioned.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92840
--- Comment #2 from jules at gcc dot gnu.org ---
I think that looks OK, thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92854
--- Comment #2 from jules at gcc dot gnu.org ---
For strictly-paired acc_map_data/acc_unmap_data calls that don't interfere with
other mappings -- no, probably not. But (like I guess you noticed too) the
existing code feels wrong (or at least
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92843
--- Comment #2 from jules at gcc dot gnu.org ---
I don't think your example is valid, but I'm not sure it will be fail in quite
the right way with the current version of my refcount overhaul patch. Actually
I think the acc_map_data implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91985
jules at gcc dot gnu.org changed:
What|Removed |Added
CC||jules at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92511
--- Comment #2 from jules at gcc dot gnu.org ---
Author: jules
Date: Wed Nov 20 17:51:09 2019
New Revision: 278514
URL: https://gcc.gnu.org/viewcvs?rev=278514=gcc=rev
Log:
OpenACC "present" subarrays: runtime API return value and unmap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92503
--- Comment #1 from jules at gcc dot gnu.org ---
FWIW, I don't think we should do this implicit unmapping, particularly since it
implies an expensive device-to-host-address lookup.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71959
--- Comment #11 from jules at gcc dot gnu.org ---
Author: jules
Date: Thu Jan 10 12:32:03 2019
New Revision: 267806
URL: https://gcc.gnu.org/viewcvs?rev=267806=gcc=rev
Log:
Add testcase from PR71959
libgomp/
PR lto/71959
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71959
jules at gcc dot gnu.org changed:
What|Removed |Added
CC||jules at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86336
--- Comment #3 from jules at gcc dot gnu.org ---
Author: jules
Date: Wed Sep 12 15:21:19 2018
New Revision: 264244
URL: https://gcc.gnu.org/viewcvs?rev=264244=gcc=rev
Log:
[OpenACC] C++ reference mapping
2018-09-09 Cesar Philippidis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86757
jules at gcc dot gnu.org changed:
What|Removed |Added
CC||jules at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65742
--- Comment #5 from jules at gcc dot gnu.org ---
Author: jules
Date: Thu May 28 09:29:19 2015
New Revision: 223801
URL: https://gcc.gnu.org/viewcvs?rev=223801root=gccview=rev
Log:
PR libgomp/65742
gcc/
* builtins.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65742
--- Comment #6 from jules at gcc dot gnu.org ---
Author: jules
Date: Thu May 28 09:38:40 2015
New Revision: 223802
URL: https://gcc.gnu.org/viewcvs?rev=223802root=gccview=rev
Log:
PR libgomp/65742
gcc/
* builtins.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65904
jules at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49423
--- Comment #26 from jules at gcc dot gnu.org ---
The testcase I previously had for this bug no longer reproduces since LRA was
enabled by default on ARM. So, it's possible the bug is now dormant, or indeed
fixed. The difference in the postreload
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: jules at gcc dot gnu.org
Compiling code using packed structures with a single non-zero-sized element and
a zero-sized array can lead to segfaults due
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57717
jules at gcc dot gnu.org changed:
What|Removed |Added
CC||jules at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49423
jules at gcc dot gnu.org changed:
What|Removed |Added
CC||jules at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57159
Bug #: 57159
Summary: Latent bug in RTL GCSE/PRE
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: minor
Priority:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57159
--- Comment #1 from jules at gcc dot gnu.org 2013-05-03 11:56:53 UTC ---
Created attachment 30019
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30019
patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57159
--- Comment #4 from jules at gcc dot gnu.org 2013-05-03 19:56:33 UTC ---
Created attachment 30029
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30029
Before/after dumps
Here are some before/after dumps taken from the out-of-tree
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57159
--- Comment #5 from jules at gcc dot gnu.org 2013-05-03 20:05:19 UTC ---
Actually the last paragraph might not make sense -- insn 16/17's *operands* are
not available at the end of the BB, but only if the REG_EQUAL note contents
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54622
jules at gcc dot gnu.org changed:
What|Removed |Added
CC||jules at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47918
--- Comment #12 from jules at gcc dot gnu.org 2011-11-01 18:38:45 UTC ---
Author: jules
Date: Tue Nov 1 18:38:42 2011
New Revision: 180740
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=180740
Log:
PR rtl-optimization/47918
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47918
--- Comment #11 from jules at gcc dot gnu.org 2011-10-28 10:48:36 UTC ---
Author: jules
Date: Fri Oct 28 10:48:32 2011
New Revision: 180611
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=180611
Log:
PR rtl-optimization/47918
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580
jules at gcc dot gnu.org changed:
What|Removed |Added
CC||jules at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580
--- Comment #13 from jules at gcc dot gnu.org 2011-10-05 13:05:47 UTC ---
Coming to think of it, if _Sat were allowed on plain integers too, a _Flagged
_Sat int could also be queried for saturation using a similar mechanism, like:
int foo (_Sat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42575
jules at gcc dot gnu.org changed:
What|Removed |Added
Status|RESOLVED|REOPENED
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45932
--- Comment #2 from jules at gcc dot gnu.org 2010-10-08 16:17:58 UTC ---
Could you be more specific about testsuite options, etc. needed to observe this
apparent regression? I haven't been able to reproduce it using default options,
nor
54 matches
Mail list logo
