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
||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)
> >
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.
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
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
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
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/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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111652
Thomas Koenig changed:
What|Removed |Added
CC||carll at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90608
Thomas Koenig changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment
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
-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
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
: 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110888
Thomas Koenig changed:
What|Removed |Added
Component|fortran |middle-end
--- Comment #3 from Thomas
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
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://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
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
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
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=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=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=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|
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
Created attachment 54497
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54497=edit
Assembly code generated by test case
Looking a bit more at the c
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
Two related test cases (which do the same, but are handled differently).
This is code for calculating a Jacobian, a frequent task in solving
non-linear systems of equations
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
Code sometimes contains manual unrolling. For example, the BLAS
reference implementation, subroutine DSCAL, has
IF (INCX.EQ.1) THEN
*
*code for increment
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
For the code (reduced from embench)
struct {
unsigned int table[4][100];
} * _nettle_aes_decrypt_T;
unsigned int _nettle_aes_decrypt_w1;
void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108710
--- Comment #1 from Thomas Koenig ---
Actually, register allocation is OK for an architecture with destructive shifts
only.
nhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
In the code
#include
#include
#include
uint64_t foo (uint64_t x)
{
x = x | (x >> 1);
x = x | (x >
: enhancement
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
In the Fortran front end, we could sometimes reverse loops at runtime if
dependency analysis shows that either
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108592
--- Comment #2 from Thomas Koenig ---
(In reply to anlauf from comment #1)
> @Thomas: do you remember the reason you chose the "_now" version?
I'm not sure any more. It's been a few years :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103506
--- Comment #12 from Thomas Koenig ---
(In reply to anlauf from comment #11)
> (In reply to Jerry DeLisle from comment #8)
> > Doing the search in bugzilla, 137 bugs are marked as ic-on-invalid-code. I
> > suggest we make all of these P5 or
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
A meta-bug to hang Fortran 2023 support PRs on.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108279
--- Comment #14 from Thomas Koenig ---
Seems that libquadmath is not built on that particular Linux/CPU variant,
for whatever reason. At last I cannot find any '*quadmath* files
in the build directory.
/proc/cpuinfo tells me that
processor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108279
--- Comment #13 from Thomas Koenig ---
I tried compiling your tests on Apple silicon using Asahi Linux, but
without success. A first step was rather easy; replacing __float128 by
_Float128 was required. I then bootstrapped gcc on that machine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108279
--- Comment #10 from Thomas Koenig ---
What we would need for incorporation into gcc is to have several
functions, which would then called depending on which floating point
options are in force at the time of invocation.
So, let's go through
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108279
--- Comment #9 from Thomas Koenig ---
Created attachment 54273
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54273=edit
matmul_r16.i
Here is matmul_r16.i from a relatively recent trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108279
--- Comment #6 from Thomas Koenig ---
(In reply to Michael_S from comment #5)
> Hi Thomas
> Are you in or out?
Depends a bit on what exactly you want to do, and if there is
a chance that what you want to do will be incorporated into gcc.
If
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89204
Thomas Koenig changed:
What|Removed |Added
Resolution|INVALID |DUPLICATE
--- Comment #8 from Thomas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31756
Thomas Koenig changed:
What|Removed |Added
CC||mehdi.chinoune at hotmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108329
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|tkoenig at gcc
||2023-01-07
Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
Status|UNCONFIRMED |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108329
--- Comment #2 from Thomas Koenig ---
(In reply to Thomas Koenig from comment #1)
> As long as PR 36678
That should be PR 34678 .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108329
Thomas Koenig changed:
What|Removed |Added
Version|unknown |13.0
Depends on|
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
Split from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678#c47 .
The test case
$ cat y.f90
module y
implicit none
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
--- Comment #49 from Thomas Koenig ---
(In reply to Thomas Koenig from comment #48)
> Clang gets this right, even without the pragma;
The "even without the pragma" part is wrong.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
--- Comment #48 from Thomas Koenig ---
Clang gets this right, even without the pragma; the original test case is
compiled to
pushq %r14
pushq %rbx
subq$24, %rsp
movq%rsi, %r14
movq%rdi,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
Thomas Koenig changed:
What|Removed |Added
Blocks||105105
--- Comment #47 from Thomas
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),
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=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
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=edit
Example patch with Michael S's code just pasted over the libgcc implementation,
for a test
A benchmarks: Just
: 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=108227
Thomas Koenig changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #1
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
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
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=107317
Thomas Koenig changed:
What|Removed |Added
Priority|P2 |P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107317
--- Comment #3 from Thomas Koenig ---
As this is invalid code (and in Fortran), should this actually be P2?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41453
--- Comment #16 from Thomas Koenig ---
(In reply to Mikael Morin from comment #15)
> Status update:
A lot of progress :-)
> (In reply to Thomas Koenig from comment #5)
> > Still missing: To clobber
> >
> > - variables passed by reference to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104265
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
The code from PR 103109
#include
void Long_multiplication( uint64_t multiplicand[],
uint64_t multiplier
1 - 100 of 3578 matches
Mail list logo
