https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118530
Tobias Burnus changed:
What|Removed |Added
Depends on||112810
--- Comment #3 from Tobias Burnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118321
--- Comment #5 from Tobias Burnus ---
> Fixed the main Fortran issue.
And now also the 'this' pointer issue for C++.
* * *
Still to do:
* Possibly add more test cases, e.g., static member function in C++ or ...
* Check whether we want/have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118530
--- Comment #2 from Tobias Burnus ---
Related variant, again by waffl3x, which fails with both GCC and Clang,
but works when changing the base-functions 'auto' to 'int'.
For GCC, the error is [SIC!]:
: In substitution of 'template auto base(T)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118496
--- Comment #4 from Tobias Burnus ---
Too many open tabs → the last comment, comment 3, was supposed to go to PR
118530.
Sorry for the spam :-/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118530
--- Comment #1 from Tobias Burnus ---
Clang-19 -fopenmp prints for this also an error:
foo.C:4:29: error: variant in '#pragma omp declare variant' with type
'' is incompatible with type 'void ()'
4 | #pragma omp declare variant(variant)
mat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118496
--- Comment #3 from Tobias Burnus ---
Clang-19 -fopenmp prints for this also an error:
foo.C:4:29: error: variant in '#pragma omp declare variant' with type
'' is incompatible with type 'void ()'
4 | #pragma omp declare variant(variant)
mat
Keywords: openmp, rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, waffl3x at protonmail dot com
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118488
--- Comment #1 from Tobias Burnus ---
> Cf. discussion at OpenMP spec Issue […]
Got that wrong; the correct OpenMP spec issue number is: 4446.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118321
--- Comment #3 from Tobias Burnus ---
Fixed the main Fortran issue.
Still to do:
* Fix C++ issue ('this' pointer), comment 1
* For Fortran, we may want to check for ENTRY master functions ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118441
Tobias Burnus changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118441
--- Comment #5 from Tobias Burnus ---
>if (sym->formal_ns
> + && sym->attr.proc != PROC_INTRINSIC // temporary hack
I am afraid that this might break
/usr/include/finclude/math-vector-fortran.h
which contains lines like:
!GCC$
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118496
--- Comment #1 from Tobias Burnus ---
Variant — for GCC, you need to switch to 'gcc (trunk)':
https://godbolt.org/z/Yce7rqdrW
ty: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
Trying the following with GCC 15 still keeps the loop:
void f() {
#pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118486
Tobias Burnus changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
ds: openmp, rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
Cf. discussion at OpenMP spec Issue 4371.
The following code compiles with clan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118478
--- Comment #3 from Tobias Burnus ---
> I don't believe we should do two copy constructors for target,
> one on the host and one on the device.
My understanding is that the (first)privatization happens twice.
I am not saying that the implementa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118486
Tobias Burnus changed:
What|Removed |Added
Keywords||rejects-valid
--- Comment #2 from Tobia
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118486
--- Comment #1 from Tobias Burnus ---
For the first case,
omp_declare_variant_finalize_one's
8550variant = finish_call_expr (variant, &args,
/*disallow_virtual=*/false,
has
(gdb) p debug(variant)
TARGET_EXPR
But after
8555 var
NCONFIRMED
Keywords: diagnostic, openmp
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
GCC [12 to mainline
-valid-code
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: tschwinge at gcc dot gnu.org
Target Milestone: ---
Target: nvptx
Created attachment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118478
--- Comment #1 from Tobias Burnus ---
Same Issue with C++ and the copy constructor.
It seems as, technically, there are two new copies + assignments with
!$omp target firstprivate(x)
[Cf. OpenMP Spec Pull Req. 4435] - Namely: one when creat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118479
--- Comment #1 from Tobias Burnus ---
We also need to handle implicit mapping with INTENT(IN) – in which case it
should decay a 'from' should decay to 'release' on map exiting.
oduct: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: diagnostic, openmp
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
: openmp, wrong-code
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
While OpenMP 4.5 has:
"2.15.3.4 firstprivate Clause"
...
"If th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118471
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118418
--- Comment #2 from Tobias Burnus ---
For GCN, when the assert occurs as follows.
As code = LT it looks indeed closely related
to STORE_FLAG_VALUE == 1 vs -1.
(gdb) p debug_rtx(reg0_val)
(const_int -1 [0x])
(gdb) p debug_rt
gcc dot gnu.org
CC: ams at gcc dot gnu.org, rsandifo at gcc dot gnu.org
Target Milestone: ---
Target: gcn
Since the commit
r15-6777-g06c4cf398947b5 rtl: Remove invalid compare simplification
[PR117186]
the GCC build fails with the following ICE during the self test at
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
OpenMP (up to 6.0) has a rather broad restriction:
[C++] Directives may not appear in constexpr functions or in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118321
--- Comment #1 from Tobias Burnus ---
The same problem exists for C++:
D.3055 = __builtin_omp_get_mapped_ptr (a, D.3054);
t::f (&s, D.3055, b, c);
//-
struct t {
void f(int *x, int *y, int *z);
#pragma
us: UNCONFIRMED
Keywords: openmp, wrong-code
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: parras at gcc dot gnu.org
Target Milestone: --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115271
--- Comment #2 from Tobias Burnus ---
The same issue occurs in the same file when an INTERFACE is involved:
module m
interface
integer function f ()
end
integer function g ()
!$omp declare variant(f) match(construct={dispatch})
end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115271
--- Comment #1 from Tobias Burnus ---
Testcase (already in the tree):
libgomp/testsuite/libgomp.fortran/declare-variant-2.f90
libgomp/testsuite/libgomp.fortran/declare-variant-2-aux.f90
...
+! Test XFAILed due to https://gcc.gnu.org/PR115271
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106692
--- Comment #13 from Tobias Burnus ---
> What do others think?
I am a bit unsure. Cray pointers are weird and it is not quite clear how they
are used in real world code.
Your modification causes a missed optimization for code like:
var = N
sion: 15.0
Status: UNCONFIRMED
Keywords: openmp, rejects-valid
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: sandra at gcc d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358
--- Comment #19 from Tobias Burnus ---
(In reply to Rainer Orth from comment #18)
> This patch broke Solaris bootstrap when linking libgdruntime.la (both sparc
> and x86, most likely almost everywhere) in stage 1 already:
See also patch submissi
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: sandra at gcc dot gnu.org
Target Milestone: ---
The doc/generic.texi lacks entries for the following
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118080
--- Comment #2 from Tobias Burnus ---
> CLASS and DT were excepted because IMO there is no clear existing definition
how to handle these.
Then there should be a compile-time error ("SORRY").
Fortran (the spec) is quite open in terms of how it
Keywords: ice-on-valid-code, wrong-code
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
ONE.f90 is an interesting issue, for:
call f(a)
call f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26154
--- Comment #38 from Tobias Burnus ---
Regarding gfortran, besides generic manual updates there, I wonder whether
https://gcc.gnu.org/onlinedocs/gfortran/OpenMP-Modules-OMP_005fLIB-and-OMP_005fLIB_005fKINDS.html
should be moved to libgomp.texi by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82250
--- Comment #13 from Tobias Burnus ---
I think the example was something like:
#include
void bogus_fn();
void f()
{
if (!acc_on_device (acc_device_host))
bogus_fn();
}
And I do recall that the re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82250
--- Comment #11 from Tobias Burnus ---
> Not the whole commit, but only one small hunk of it was reverted
Which is enough to prevent the folding when the compiler has not been
configured for offloading. If I recall correctly: before your commit,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82250
Tobias Burnus changed:
What|Removed |Added
Status|RESOLVED|NEW
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117803
Tobias Burnus changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
, rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
https://godbolt.org/z/zjKshK35K - the example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117657
Tobias Burnus changed:
What|Removed |Added
Target Milestone|--- |15.0
--- Comment #5 from Tobias Burnus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117657
--- Comment #4 from Tobias Burnus ---
(In reply to Robin Dapp from comment #3)
> Is there a way to test it short of a cross compile?
I guess not - but compiling shouldn't be difficult as no libraries are needed.
Otherwise, I use for a full cr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117657
Tobias Burnus changed:
What|Removed |Added
CC||rdapp at gcc dot gnu.org
--- Comment #2
Keywords: build, ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: ams at gcc dot gnu.org
Target Milestone: ---
Target: gcn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107067
Tobias Burnus changed:
What|Removed |Added
Keywords||diagnostic,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113905
--- Comment #5 from Tobias Burnus ---
I have asked at OpenMP.org's lang mailing list. Alex replied:
> This should be invalid (or so was the intent) as the
> construct set doesn’t match.
Thus, it seems as if GCC handles it correctly :-)
(Or at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113905
--- Comment #3 from Tobias Burnus ---
I bet that the spec writers ment the following (i.e. with the text written in
brackets):
“If a procedure is determined to be a function variant through more than one
declare variant directive [for a given b
||burnus at gcc dot gnu.org
Resolution|--- |DUPLICATE
--- Comment #1 from Tobias Burnus ---
Should be the same as PR113724
*** This bug has been marked as a duplicate of bug 113724 ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113724
Tobias Burnus changed:
What|Removed |Added
CC||Bert.Wesarg at googlemail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117361
--- Comment #4 from Tobias Burnus ---
BTW: In PR115203 it was solved differently compared to the proposal, i.e. by
setting disable_event_localization
See
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=2dbb1c124c1e585dc413132d7a8d4be62c6b7baa
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: build
Severity: normal
Priority: P3
Component: bootstrap
Assignee: dmalcolm at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
Tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117247
--- Comment #1 from Tobias Burnus ---
Follow up note: the following all fails (on nvptx with -Og, -Os, -O1 or
higher); the first two are nearly identical on dump level:
- omp loop
- omp simd
- omp for simd
while the following works:
- o
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: openmp, wrong-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
nostics: bulletproof
opening of SARIF output)
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: translation
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28614
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment
us: UNCONFIRMED
Keywords: diagnostic, openmp
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
It would be useful to add #include hints when using omp_… w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116786
--- Comment #1 from Tobias Burnus ---
Variant: move 'x' into the function via 'static int x' inside the main
function.
-valid-code, openmp
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
The following code fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116661
--- Comment #6 from Tobias Burnus ---
> FAIL: gfortran.dg/gomp/interop-1.f90
That's a known issue – there is a parsing issue that was (usually) hidden by
the not properly initialized variable.
Now it is exposed as consistent FAIL, which is muc
: missed-optimization
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
Target: x86-64
Found at https://www.darpa.mil/attachments/MOCHA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116535
--- Comment #9 from Tobias Burnus ---
(In reply to Jan Hubicka from comment #7)
> We treat first partition somewhat specially in other code too, so I
> guess we could a test if the streamed partition is first one instad of
> relying on free to h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116535
--- Comment #4 from Tobias Burnus ---
(In reply to Richard Biener from comment #3)
> The forked processes may not write to any "global" data because forking
> makes that data not global ... instead any such "global" data has to be
> computed bef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116535
--- Comment #2 from Tobias Burnus ---
Namely, the following seems to be problematic if the code is run concurrently.
The FORK part is actually quite old r207515 (Feb 2014) as is the following code
with flag_wpa, which was added in r217489 (No
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116535
--- Comment #1 from Tobias Burnus ---
I have problems reproducing it fully reliably – and my impression is that a
global variable is not atomically set.
The difference between -flto=1 and -flto=2 with -flto-partition=max is rather
small. In eit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116269
--- Comment #1 from Tobias Burnus ---
Note regarding the compile-time optimization:
Currently, gcc/gimple-fold.cc's gimple_fold_builtin_acc_on_device only handles:
unsigned val_host = GOMP_DEVICE_HOST;
unsigned val_dev = GOMP_DEVICE_NONE;
, openacc
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
For C, both __builtin_acc_on_device and acc_on_device is defined,
permitting compile-time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115140
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment
D
Keywords: missed-optimization, openacc
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: cltang at gcc dot gnu.org, tschwinge at gcc dot gnu.or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115637
Tobias Burnus changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115637
--- Comment #2 from Tobias Burnus ---
Patch:
https://gcc.gnu.org/pipermail/gcc-patches/2024-July/658737.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115559
Tobias Burnus changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115577
--- Comment #1 from Tobias Burnus ---
>From the other issue, now fixed:
(B) Issues found when writing a testcase:
* COMMON blocks: Using map(a,b,c) instead of map(/mycommon/) fails with:
error: undefined symbol: mycommon_
TESTCASE: atta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116107
Tobias Burnus changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
NCONFIRMED
Keywords: openmp, wrong-code
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
See also PR 1155
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112779
--- Comment #1 from Tobias Burnus ---
See also PR 107067 for a Fortran ICE with metadirectives (OG12 branch).
See https://gcc.gnu.org/pipermail/gcc-patches/2024-July/657841.html for
"[PATCH v3 00/12] Metadirective support + "declare variant"
sion: 15.0
Status: UNCONFIRMED
Keywords: openacc, openmp, rejects-valid
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115574
--- Comment #2 from Tobias Burnus ---
> #pragma declare target link(a,b)
as Thomas pointed out (cf. comment 1), an 'omp' is missing.
It also lacks, e.g. '#pragma omp target enter data map(a, b)' to be valid.
Still, the real issue is '!is_globa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115637
--- Comment #1 from Tobias Burnus ---
Created attachment 58512
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58512&action=edit
WIP patch - shows the location but fails as DECL_P is not a is_gimple_stmt
The attached patch handles
MEM [
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115559
--- Comment #7 from Tobias Burnus ---
(In reply to Tobias Burnus from comment #6)
> FOLLOW-UP ISSUES:
> * VARIABLE not AVAILABLE on the device:
PR115637 - is an analysis of the 'arr2' issue.
tatus: UNCONFIRMED
Keywords: openmp, wrong-code
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
Cr
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
The following doesn't make sense on multiple ways:
(A)
-
find_forall_index (gfc_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115559
--- Comment #6 from Tobias Burnus ---
Fortran patch:
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655386.html
FOLLOW-UP ISSUES:
* OFFSET issues with LINK clause:
arr = [(i, i=1,N)]
map(arr(10:N)
and then in a device func
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115559
--- Comment #5 from Tobias Burnus ---
Created attachment 58478
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58478&action=edit
COMMON block testcase
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
Using map(/common/) is rejected in gfortran but is valid:
10 |!$omp target enter data map(/mycommon
Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
C variant for the issue PR 115559.
[Nested functions are a GNU extension - thus, we may decide not to fix this.]
Nonetheless, the following compiles but fails during device LTO:
foo.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115559
--- Comment #4 from Tobias Burnus ---
NOTE to self: This code now adds the attribute unconditionally. For COMMON and
MODULE it makes sense; but for programm/subroutine/function, it needs to be
rechecked whether that variable is actually used.
A
dot gnu.org |burnus at gcc dot
gnu.org
Last reconfirmed||2024-06-20
Status|UNCONFIRMED |ASSIGNED
--- Comment #3 from Tobias Burnus ---
Created attachment 58472
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58472&acti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115559
--- Comment #2 from Tobias Burnus ---
For C, it is actually handled in the FE for
tree at1 = lookup_attribute ("omp declare target", DECL_ATTRIBUTES (t));
tree at2 = lookup_attribute ("omp declare target link",
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115559
--- Comment #1 from Tobias Burnus ---
Looks as if offload_vars is empty in case of Fortran; the variables are tagged
as 'declare variant link' in the FE but varpool_node::get_create has:
if ((flag_openacc || flag_openmp)
&& lookup_attri
rds: openmp, rejects-valid, wrong-code
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
A C version of t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115551
--- Comment #6 from Tobias Burnus ---
Crossref: New Bug 11 is for the range analysis to deduce from 'x << a' that
'a' must be nonnegative.
on
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: aldyh at gcc dot gnu.org
Target Milestone: ---
Stumbled over this when looking at PR 115551.
C has for the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115551
--- Comment #3 from Tobias Burnus ---
As we want to have a >= 0, I tried to convey it differently for the example in
comment 0:
(a) __attribute__((assume(ch >= 0)));
(b) 'unsigned ch' (instead of 'int ch')
but it didn't help. Thus, it looks a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115551
--- Comment #2 from Tobias Burnus ---
> Thus we need some range info to do this optimization.
Good point.
It seems as if for c1 << (c2 * a + c3), C requires a >= -c3/c2 (read as float
division; c2 ≠ 0)
And the suggested optimization requires
ormal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
It looks as if a 'gfc_free_expr (list->expr)' is missing before
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: pinskia at gcc dot gnu.org
Target Mi
1 - 100 of 3866 matches
Mail list logo
