https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118359
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118499
--- Comment #15 from Thomas Koenig ---
(In reply to kargls from comment #14)
> (In reply to anlauf from comment #13)
> > (In reply to kargls from comment #12)
> > > (In reply to Thomas Koenig from comment #9)
> > > > Question is, what should we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118499
--- Comment #9 from Thomas Koenig ---
Question is, what should we permit...
For 'normal' operations, only unsigned op unsigned is permitted,
so unsigned**unsigned is obviously ok.
What about (integer|real|complex)**unsigned?
What about unsign
||2025-01-16
Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
Status|UNCONFIRMED |ASSIGNED
--- Comment #8 from Thomas Koenig ---
So, let's do this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118499
--- Comment #3 from Thomas Koenig ---
(In reply to kargls from comment #2)
> Not Thomas, but ...
>
> https://j3-fortran.org/doc/year/24/24-116.txt
>
> The exponentiation operator ** shall not be applied to UNSIGNED values.
That was something
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118432
Thomas Koenig changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118432
--- Comment #2 from Thomas Koenig ---
Simple and obvious fix:
diff --git a/gcc/fortran/frontend-passes.cc b/gcc/fortran/frontend-passes.cc
index 3a3328d4450..6ee6ce4c3ff 100644
--- a/gcc/fortran/frontend-passes.cc
+++ b/gcc/fortran/frontend-pas
|unassigned at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
Ever confirmed|0 |1
Status|UNCONFIRMED |ASSIGNED
--- Comment #1 from Thomas Koenig ---
Mine.
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
Turning gfc_code.ext into a struct is wasteful of memory, but it
can be used to find problems where the compiler depends on
accidental
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116732
Bug 116732 depends on bug 116025, which changed state.
Bug 116025 Summary: Experimental implementation of unsigned integers for Fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116025
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116025
Thomas Koenig changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118359
Thomas Koenig changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
-fc-prototypes does not generate a prototype for ISO_Fortran_binding_3.f90.
It also does not handle CFI_cdesc_t.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118337
--- Comment #7 from Thomas Koenig ---
(In reply to anlauf from comment #6)
> It is clear that one cannot have 2-way compatibility.
>
> But I wish we could have a limited version of backward-compatibility,
> i.e. trying to consume older module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118337
--- Comment #1 from Thomas Koenig ---
Probably safest to bump the module version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118336
--- Comment #1 from Thomas Koenig ---
This is for
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/ig25/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../trunk/configure --pre
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
-freport-bug does not work as advertised for Fortran:
$ cat z1.F90
#define N 1
program p
type t
character :: a
integer :: b
integer :: c(t(N))
end type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117225
Thomas Koenig changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116025
Bug 116025 depends on bug 117225, which changed state.
Bug 117225 Summary: ICE with -funsigned in gfc_match_sym_complex_part
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117225
What|Removed |Added
-
|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
Keywords||ice-on-invalid-code
Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
The test case
program main
unsigned, parameter :: u = 7u
print *,mod(-(u+1u),u)
end program main
ICEs:
gfortran -funsigned unsigned_38.f90
f951: interner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116886
Thomas Koenig changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116886
--- Comment #2 from Thomas Koenig ---
The behavior for simplification is correct, as far as I understand:
$ cat mv2.f90
program memain
integer, dimension(0,0), parameter :: empty = reshape([(0,i=1,0)],[0,0])
print *,maxval(empty)
print *,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116885
Thomas Koenig changed:
What|Removed |Added
Keywords|ABI |
--- Comment #5 from Thomas Koenig ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116885
--- Comment #4 from Thomas Koenig ---
(In reply to Jaroslav Fojtík from comment #3)
> It seems to me that this problem has something to do with memcpy optimised
> for AVX, that newly requests everything to be alligned.
As shown by the valgrind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116886
Thomas Koenig changed:
What|Removed |Added
Keywords||wrong-code
CC|
Priority: P3
Component: libfortran
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
If I read J3/23-007 16.9.138 correctly, the following program should
print the minimum integer value, twice, but it prints nothing
||tkoenig at gcc dot gnu.org
Last reconfirmed||2024-09-29
Ever confirmed|0 |1
--- Comment #1 from Thomas Koenig ---
I checked your program with current trunk and with the Ubuntu-supplied
gcc 11.4.0, plus clang 14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116025
--- Comment #2 from Thomas Koenig ---
(In reply to Jerry DeLisle from comment #1)
> Thomas, shall we close this one?
It's not yet complete. A few intrinsics are still missing, and
I also want to get C interop up and running.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116025
Bug 116025 depends on bug 116653, which changed state.
Bug 116653 Summary: new test case gfortran.dg/unsigned_21.f90 from
r15-3526-g113a6da9bf91c5 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116653
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116653
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116653
Thomas Koenig changed:
What|Removed |Added
Blocks||116025
--- Comment #3 from Thomas Koeni
dot gnu.org |tkoenig at gcc dot
gnu.org
Last reconfirmed||2024-09-09
Status|UNCONFIRMED |ASSIGNED
--- Comment #1 from Thomas Koenig ---
Confirmed.
Severity: normal
Priority: P3
Component: libfortran
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
Since https://gcc.gnu.org/g:affd24bfc62203db9f9937c0d6cf8f1f75b80d72 ,
generated files in libfortran are no longer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116394
Thomas Koenig changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
Just looked at simplify.cc:compute_dot_product, and this has
case BT_COMPLEX:
if (conj_a && a->ts.type == BT_COMPLEX)
c = gfc_simpli
|ASSIGNED
Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
Last reconfirmed||2024-07-21
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
https://j3-fortran.org/doc/year/24/24-116.txt has a proposal,
accepted by J3, to implement unsigned integers for Fortran.
I'l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82450
--- Comment #7 from Thomas Koenig ---
If you're looking at this, could you also look at Fortran's way
of handling things, for example the test cases
subroutine foo(a)
implicit none
real, dimension(:,:), contiguous, intent(out) :: a
a = a +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97304
--- Comment #15 from Thomas Koenig ---
(In reply to Andrew Pinski from comment #14)
> (In reply to Jonathan Wakely from comment #10)
> > If --with-as=/usr/local/bin/as --with-ld=/usr/local/bin/ld is required then
> > it needs to be documented at
|normal |enhancement
Ever confirmed|0 |1
CC||tkoenig at gcc dot gnu.org
Last reconfirmed||2024-01-07
Status|UNCONFIRMED |NEW
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110390
Thomas Koenig changed:
What|Removed |Added
URL||https://gcc.gnu.org/bugzill
|1
Status|UNCONFIRMED |NEW
CC||tkoenig at gcc dot gnu.org
Severity|normal |enhancement
--- Comment #2 from Thomas Koenig ---
It would make sense to have it, I guess. If
||tkoenig at gcc dot gnu.org
Status|UNCONFIRMED |WAITING
Last reconfirmed||2023-11-13
--- Comment #5 from Thomas Koenig ---
(In reply to Hongtao.liu from comment #4)
> (In reply to anlauf from comment #3)
> > (In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97756
--- Comment #15 from Thomas Koenig ---
(In reply to CVS Commits from comment #14)
> Admittedly a single "mov" isn't much of a saving on modern architectures,
> but as demonstrated by the PR, people still track the number of them.
Thanks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110390
--- Comment #3 from Thomas Koenig ---
Fixed by r14-3414-g0cfc9c953d0221:
0cfc9c953d0221ec3971a25e6509ebe1041f142e is the first new commit
commit 0cfc9c953d0221ec3971a25e6509ebe1041f142e
Author: Andrew MacLeod
Date: Thu Aug 17 12:34:59 2023 -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110390
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111956
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97756
--- Comment #13 from Thomas Koenig ---
(In reply to Patrick Palka from comment #3)
> Perhaps related to this PR: On x86_64, the following basic wrapper around
> int128 addition
>
> __uint128_t f(__uint128_t x, __uint128_t y) { return x + y; }
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105558
--- Comment #8 from Thomas Koenig ---
(In reply to Andrew Pinski from comment #6)
> Would be interesting to find what patch broke this and what patch fixed the
> -mtune=generic case.
It is not easy bisecting with old compilers - compilation iss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105834
Thomas Koenig changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110903
--- Comment #6 from Thomas Koenig ---
The original regression was caused by r12-4526-gd8edfadfc7a979 .
d8edfadfc7a9795b65177a50ce44fd348858e844 is the first bad commit
commit d8edfadfc7a9795b65177a50ce44fd348858e844
Author: Aldy Hernandez
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110903
Thomas Koenig changed:
What|Removed |Added
Summary|[12/13/14 Regression] Dead |[12/13 Regression] Dead
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110903
--- Comment #3 from Thomas Koenig ---
The code from comment#2 and from comment#3 no longer calls foo
with current trunk, r14-5108-g751fc7bcdcdf25 .
Now, to see which commit fixed it...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110116
Thomas Koenig changed:
What|Removed |Added
Summary|[12/13/14 Regression] ICE |[12/13 Regression] ICE on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110116
--- Comment #2 from Thomas Koenig ---
Looks like this has been fixed in the meantime:
tkoenig@gcc188:~> gcc -O3 small.c
small.c: In function 'main':
small.c:6:21: warning: iteration 2147483646 invokes undefined behavior
[-Waggressive-loop-opti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111921
Thomas Koenig changed:
What|Removed |Added
Summary|[11/12/13/14 Regression]|[11/12/13/14 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112112
Thomas Koenig changed:
What|Removed |Added
Last reconfirmed||2023-11-01
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111921
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112276
Thomas Koenig changed:
What|Removed |Added
CC||liuhongt at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112112
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112113
--- Comment #3 from Thomas Koenig ---
(In reply to Thomas Koenig from comment #2)
> According to bisection, f5fb9ff2396fd41fdd2e6d35a412e936d2d42f75
> is the first bad commit.
Or, if anybody wants a link,
https://gcc.gnu.org/git/?p=gcc.git;a=co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112113
Thomas Koenig changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111917
--- Comment #5 from Thomas Koenig ---
> It does not ICE with aa90195, for which the original test case ICEs,
> so it is something else (although probably related).
.. or at least it does not ICE with checking disabled (to be exact).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111917
--- Comment #4 from Thomas Koenig ---
(In reply to Andrew Pinski from comment #3)
> If someone is worried about uninitialized variables or an executed infinite
> loop, this also ICEs at -O3:
> ```
> long t;
> long a() {
> long b = t, c = t;
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30409
Thomas Koenig changed:
What|Removed |Added
Depends on||21046
--- Comment #9 from Thomas Koenig
|on x86_64-linux-gnu (the|at -O1 and above on
|generated code hangs) |x86_64-linux-gnu (the
||generated code hangs)
CC||tkoenig at gcc dot gnu.org
Keywords
at gcc dot gnu.org
--- Comment #1 from Thomas Koenig ---
Works for 4.8.5, must be a not-so-recent regression.
Note that with gcc (GCC) 11.3.1 20221121 (Red Hat 11.3.1-4) on POWER,
the error is different:
x.c: In function ‘main’:
x.c:15:5: internal compiler error: in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111652
Thomas Koenig changed:
What|Removed |Added
CC||carll at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90608
Thomas Koenig changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #7
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
The code
#define SWAP(i,j) do { \
if (v[i] > v[j]) { \
tmp_v = v[i]; v[i] = v[j]; v[j] = tmp_v;\
tmp_p = a[i]; a[i] = a[j]; a[j] = tm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106271
--- Comment #7 from Thomas Koenig ---
(In reply to Thomas Schwinge from comment #6)
> I noticed recent commit r14-3387-g47f95bc4be4eb14730ab3eaaaf8f6e71fda47690
> "RISC-V: Add multiarch support on riscv-linux-gnu" -- but can't tell
> off-hand wh
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
I just noticed that gcc will optimize away multiplying a floating
point number with 1.0, but will not do for an addition with 0.0.
Example, with -O3,
double add0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111096
--- Comment #9 from Thomas Koenig ---
(In reply to Richard Earnshaw from comment #8)
> (In reply to Thomas Koenig from comment #7)
> > Would it make sense to document this somewhere? Or did I just miss it? :-)
>
> Possibly, but I've no idea wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111096
--- Comment #7 from Thomas Koenig ---
(In reply to Richard Earnshaw from comment #5)
> This was a deliberate design choice. Although the frame chain is not set up
> by code that omits the frame pointer, the chain of frames that are set up by
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111096
--- Comment #3 from Thomas Koenig ---
(In reply to Andrew Pinski from comment #2)
> See https://gcc.gnu.org/pipermail/gcc-patches/2016-September/456662.html
>
> I think this is by design of the ABI ...
The workaround mentioned in the thread do
: enhancement
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
The code, by Kent Dickey posted to comp.arch
typedef unsigned int u32;
typedef unsigned long long u64;
u64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110888
Thomas Koenig changed:
What|Removed |Added
Component|middle-end |fortran
--- Comment #4 from Thomas Koen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110888
Thomas Koenig changed:
What|Removed |Added
Component|fortran |middle-end
--- Comment #3 from Thomas K
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110842
--- Comment #3 from Thomas Koenig ---
(In reply to Jakub Jelinek from comment #2)
> Why a regression?
It worked before (if only by accident), hence I put "Regression" there.
> libgomp has no support for loop iterators larger than 64-bit unsign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110842
Thomas Koenig changed:
What|Removed |Added
Target Milestone|--- |14.0
Keywords|
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
gfortran with a reasonably current trunk gives wrong
results for omp parallel:
$ cat dynamic.f90
program main
||tkoenig at gcc dot gnu.org
--- Comment #7 from Thomas Koenig ---
Just stumbled across this.
A maybe simpler testcase:
typedef struct
{
unsigned long x: 42;
unsigned b: 1;
unsigned long y: 42;
} myfield;
typedef struct
{
unsigned long x: 7;
unsigned b: 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97756
--- Comment #12 from Thomas Koenig ---
(In reply to Andrew Pinski from comment #11)
> This seems to be improved on trunk ...
gcc is down to 37 instructions now for the original test case with -O3.
icc, which appears to be best, has 33, see https
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110479
Thomas Koenig changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
Putting this provisionally into tree-optimization, although there may
be other aspects.
Consider
unsigned int foo
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
May be related to / a dup of PR110240.
The function
unsigned int bar(unsigned int a)
{
return 1u << (((a >> 10) & 3) + 3);
}
is compiled, with a relativ
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
void swap (unsigned int * restrict a, unsigned int * restrict b)
{
if (a[b[0]] > a[b[1]])
{
unsigned int tmp = b[0];
b[0] = b[1];
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98577
Thomas Koenig changed:
What|Removed |Added
Resolution|WONTFIX |INVALID
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
There are lots of useful builtin functions in gcc which Fortran currently
does not have access to. Just think of checking for integer overflow,
which gcc offers as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109075
Thomas Koenig changed:
What|Removed |Added
Known to work||12.2.0
--- Comment #7 from Thomas Koeni
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109075
--- Comment #5 from Thomas Koenig ---
Might be invalid code, see
https://gcc.gnu.org/pipermail/fortran/2023-March/059062.html
That appears to be a problem with widely used old-style linear congruential
random number generators, which expect ov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109075
Thomas Koenig changed:
What|Removed |Added
Keywords||needs-bisection
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109075
--- Comment #3 from Thomas Koenig ---
Created attachment 54619
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54619&action=edit
Compressed input file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109075
--- Comment #2 from Thomas Koenig ---
Created attachment 54618
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54618&action=edit
Header file needed for compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109075
--- Comment #1 from Thomas Koenig ---
Created attachment 54617
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54617&action=edit
rnflow.f90
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
rnflow from the pb11 Polyhedron benchmark hangs at -O3 with recent trunk,
gcc-Version 13.0.1 20230308 (experimental) [master revision
e87559d202d:f4e6da6e8ac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109019
Thomas Koenig changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
Looks like a general RTL issue, I see this on POWER, RV64 and ARM64 (the
latter two on godbolt).
[tkoenig@gcc135 ~]$ cat c.c
long foo (long b, long c)
{
return b + c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108863
Thomas Koenig changed:
What|Removed |Added
Severity|normal |enhancement
Keywords|
1 - 100 of 3619 matches
Mail list logo
