https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992
--- Comment #20 from Thomas Koenig ---
(In reply to Iain Sandoe from comment #16)
> (In reply to Thomas Koenig from comment #14)
> NOTE: I have been discussing the non-running of mod_term_funcs with my
> "downstream" and Apple folks. The conse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106576
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|NEW
--- Comment #3 from Thomas Koenig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106576
--- Comment #6 from Thomas Koenig ---
> I hope that you are well and that the lack of time is for a good cause?
Hi Paul,
yes, I'm well, and the lack of time is indeed for a good cause :-)
> I have just returned to my finalizer patch. With it
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
Consider
typedef struct coord {
double x, y, z;
} coord;
void foo(coord *from, coord *to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108227
Thomas Koenig changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #1 from
: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
Our soft-float routines, which are used for the basic float128 arithmetic
(__addtf3, __subtf3, etc) are much slower than they need to be.
Michael S has some routines which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108279
--- Comment #1 from Thomas Koenig ---
Created attachment 54183
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54183&action=edit
Example patch with Michael S's code just pasted over the libgcc implementation,
for a test
A benchmarks: Just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108279
--- Comment #3 from Thomas Koenig ---
(In reply to Jakub Jelinek from comment #2)
> From what I can see, they are certainly not portable.
> E.g. the relying on __int128 rules out various arches (basically all 32-bit
> arches,
> ia32, powerpc 32-
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
#include
void
foo (double res[4], double a, double b)
{
static const int rm[4]
= { FE_DOWNWARD, FE_TONEAREST
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
--- Comment #46 from Thomas Koenig ---
Fortran gets this right:
$ cat set_rounding_mode.f90
module x
implicit none
integer, parameter :: wp = selected_real_kind(15)
contains
subroutine foo(a,b,c)
use ieee_arithmetic
real(kind=wp),
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
Thomas Koenig changed:
What|Removed |Added
Blocks||105105
--- Comment #47 from Thomas Koeni
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
The program
module sk1
implicit none
type char
character :: ch
end type char
interface read (formatted)
module procedure read_formatted
end interface read
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105456
Thomas Koenig changed:
What|Removed |Added
Blocks||105361
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105101
--- Comment #14 from Thomas Koenig ---
@Michael: Now that gcc 12 is out of the door, I would suggest we try to get
your code into the gcc tree for gcc 13.
It should follow the gcc style guidelines, which is quite trivial to do:
Comments should
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
I thought I would give the new gcc92 machine a spin and tried
bootstrapping gcc on it.
Configure was
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106271
--- Comment #2 from Thomas Koenig ---
(In reply to Andrew Pinski from comment #1)
> I suspect configure is not detecting multi-arch correctly or
> --disable-multilib interacting with multi-arch support which causes things
> to be broken.
> OR mu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106331
Thomas Koenig changed:
What|Removed |Added
Keywords||needs-bisection
--- Comment #2 from Tho
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
The following two functions do the same thing:
int foo(int x)
{
switch (x) {
case 1: return 1;
case 2: return 2;
case 3: return 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101301
--- Comment #1 from Thomas Koenig ---
Here's the assembly for the switch statement with -O3:
cmpl$5, %edi
je .L6
jle .L18
movl$8, %eax
cmpl$8, %edi
je .L1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101301
Thomas Koenig changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101301
--- Comment #4 from Thomas Koenig ---
(In reply to Segher Boessenkool from comment #3)
> What CPU is in your Power system, and what -mcpu= did you compile with?
> What is the ABI you are using? (That last one doesn't seem to matter in
> this pa
at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101301
--- Comment #6 from Thomas Koenig ---
If I create a foo3 function with
int foo3 (int n)
{
if (__builtin_expect_with_probability (n >= 5, 1, 0.55))
{
if (__builtin_expect_with_probability (n >= 7, 1, 0.33/0.55))
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101301
--- Comment #8 from Thomas Koenig ---
(In reply to Segher Boessenkool from comment #7)
> Yeah :-) Of course in your testing the nine named cases have the same
> probability,
> which is not very true in practice (but is there any better guess p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100227
Thomas Koenig changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101199
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101199
Thomas Koenig changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100352
Thomas Koenig changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100371
Bug 100371 depends on bug 100352, which changed state.
Bug 100352 Summary: [11/12 Regression] libgomp.fortran/async_io_1.f90 -O0
execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100352
What|Removed
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110842
Thomas Koenig changed:
What|Removed |Added
Target Milestone|--- |14.0
Keywords|
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=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=110888
Thomas Koenig changed:
What|Removed |Added
Component|middle-end |fortran
--- Comment #4 from Thomas Koen
: 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=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
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 #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
-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=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
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=90608
Thomas Koenig changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #7
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116394
Thomas Koenig changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
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
dot gnu.org |tkoenig at gcc dot
gnu.org
Last reconfirmed||2024-09-09
Status|UNCONFIRMED |ASSIGNED
--- Comment #1 from Thomas Koenig ---
Confirmed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116653
Thomas Koenig changed:
What|Removed |Added
Blocks||116025
--- Comment #3 from Thomas Koeni
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=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
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=98577
Thomas Koenig changed:
What|Removed |Added
Resolution|WONTFIX |INVALID
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
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
|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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30409
Thomas Koenig changed:
What|Removed |Added
Depends on||21046
--- Comment #9 from Thomas Koenig
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=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=112113
Thomas Koenig changed:
What|Removed |Added
CC||hubicka 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=112112
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=111921
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
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
Summary|[11/12/13/14 Regression]|[11/12/13/14 Regression]
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=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=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=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 #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=105834
Thomas Koenig changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
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=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=111956
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
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=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=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
||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
|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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110390
Thomas Koenig changed:
What|Removed |Added
URL||https://gcc.gnu.org/bugzill
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];
-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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110479
Thomas Koenig changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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
||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
|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=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 +
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
|ASSIGNED
Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
Last reconfirmed||2024-07-21
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=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
-
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
|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
Keywords||ice-on-invalid-code
Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
||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
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
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=116886
Thomas Koenig changed:
What|Removed |Added
Keywords||wrong-code
CC|
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
3501 - 3600 of 3756 matches
Mail list logo
