https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97308
Thomas Koenig changed:
What|Removed |Added
Component|fortran |bootstrap
--- Comment #7 from Thomas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97304
Thomas Koenig changed:
What|Removed |Added
Component|target |bootstrap
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92422
Thomas Koenig changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97302
--- Comment #3 from Thomas Koenig ---
Comment on attachment 49313
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49313
configure.ac patch
Seems to work, at least the compilation is proceeding now.
Thanks for the quick fix!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97302
Bug ID: 97302
Summary: FreeBSD build fails with
contrib/download_prerequisites with missing gmp.h
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97302
--- Comment #1 from Thomas Koenig ---
Created attachment 49311
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49311=edit
Output from the attempt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89256
--- Comment #2 from Thomas Koenig ---
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97282#c1 for one
example how this could be done for small integers (base 10 in that
case). The solution with the precomputed tables is probably not feasible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97304
--- Comment #2 from Thomas Koenig ---
Created attachment 49316
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49316=edit
output from compilation that failed with -lc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97304
Thomas Koenig changed:
What|Removed |Added
Component|bootstrap |target
--- Comment #3 from Thomas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97304
--- Comment #1 from Thomas Koenig ---
Created attachment 49315
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49315=edit
config.log from failed attempt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97304
Bug ID: 97304
Summary: Boostrap failure on freebsd: ld: error: unable to find
library -lc
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91084
--- Comment #9 from Thomas Koenig ---
WORKSFORME on OpenBSD 6.7.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97308
Bug ID: 97308
Summary: OpenBSD bootstrap fails with error: C++ preprocessor
"/lib/cpp" fails sanity check
Product: gcc
Version: 11.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97454
Thomas Koenig changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97454
Bug ID: 97454
Summary: Decls for Fortran library procedures
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97459
Bug ID: 97459
Summary: __uint128_t remainder for division by 3
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97459
--- Comment #5 from Thomas Koenig ---
OK, so here is a benchmark with its function names corrected. It also
includes one version (_v5) which is a bit faster.
(Note I increased the number of iterations to get more accuracy out
of the cycle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97459
--- Comment #4 from Thomas Koenig ---
Here's a complete program for benchmarks on x86_64, using Jakub's
functions (so they are indeed correct):
#include
#include
#include
#include
#include
#include
unsigned r3_128u_v2 (__uint128_t n)
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95104
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95037
--- Comment #5 from Thomas Koenig ---
Fixed in 10.2, 9.4 and 11.1 will have it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95119
--- Comment #13 from Thomas Koenig ---
(In reply to Bill Long from comment #12)
> Original submitter asking which GCC version(s) have / will have the fix.
10.2 already has been released with the fix. 9.4 and 11.1 will have it in when
they are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97491
Bug ID: 97491
Summary: Wrong restriction for VALUE arguments of pure
procedures
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97308
Thomas Koenig changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97308
--- Comment #4 from Thomas Koenig ---
Created attachment 49320
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49320=edit
config.log from failing libgomp
OK, so that one isn't a bug.
I hope you don't mind if I put in the next failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97308
--- Comment #2 from Thomas Koenig ---
Created attachment 49319
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49319=edit
config.log from gmp subdirectory
Here it is.
For what it is worth, I now tried bootstrapping with CC=cc and CXX=c++,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97282
Bug ID: 97282
Summary: division done twice for modulo and divsion for 128-bit
integers
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97282
Thomas Koenig changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97282
--- Comment #1 from Thomas Koenig ---
And here is a version which uses two 64-bit numbers for calculation of he
sum of decimal digits as a benchmark for the division and modulo:
unsigned long digsum3 (myint x)
{
unsigned long ret;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97527
--- Comment #3 from Thomas Koenig ---
Created attachment 49421
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49421=edit
config.log from the main build directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97527
--- Comment #1 from Thomas Koenig ---
Created attachment 49419
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49419=edit
Preprocessed source of gimple-match.ii (compressed)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97527
--- Comment #2 from Thomas Koenig ---
Created attachment 49420
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49420=edit
Resulting assember file (which is incomplete)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97527
--- Comment #6 from Thomas Koenig ---
The machine is gcc220.fsffrance.org ; if anybody has an account there
and wants to peek into /home/tkoenig to look into more details, be my
guest.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97527
--- Comment #5 from Thomas Koenig ---
Created attachment 49422
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49422=edit
Generated gimple-match.c
All the temporary files were generated by manually adding -save-temps
to the Makefile in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97527
Bug ID: 97527
Summary: OpenBSD bootstrap fails with error: C++ preprocessor
"/lib/cpp" fails sanity check
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97527
Thomas Koenig changed:
What|Removed |Added
Target||x86_64-unknown-openbsd6.8
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97527
--- Comment #8 from Thomas Koenig ---
The *.s file generated with -save-temps is attached, but it
is truncated for a reason that I do not understand.
The binutils is indeed self-compiled from source (because the LLVM
linker cannot handle gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97527
--- Comment #9 from Thomas Koenig ---
Created attachment 49423
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49423=edit
config.log from libgomp using binutils compiled with gcc 8.4.0
Using the binutils compiled with gcc 8.4 now leads to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97459
--- Comment #10 from Thomas Koenig ---
There are a couple of more constants for this could be tried.
Base 7:
static unsigned
rem_7_v2 (mytype n)
{
unsigned long a, b, c, d;
a = n & MASK_48;
b = (n >> 48) & MASK_48;
c = n >> 96;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97530
Thomas Koenig changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88076
Bug 88076 depends on bug 97530, which changed state.
Bug 97530 Summary: Segmentation fault compiling coarray program with option
-fcoarray=shared (not with -fcoarray={lib,single})
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97530
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97459
Thomas Koenig changed:
What|Removed |Added
Attachment #49438|divisiontable.dat |divisiontable.txt
filename|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97530
--- Comment #3 from Thomas Koenig ---
A little bit more reduced.
module types
type local_model_state
real, allocatable :: ps(:,:) ! Surface pressure
end type local_model_state
contains
function int_mult(ms, ifactor)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97459
--- Comment #11 from Thomas Koenig ---
Created attachment 49438
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49438=edit
Numbers a, b so that 2^b ≡ 1 mod a up to b=64, larger b taken if several
solutions exist
Here is the promised table
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97459
--- Comment #12 from Thomas Koenig ---
(In reply to Thomas Koenig from comment #11)
> Created attachment 49438 [details]
> Numbers a, b so that 2^b ≡ 1 mod a up to b=64, larger b taken if several
> solutions exist
>
A quick check that all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97530
Thomas Koenig changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98552
--- Comment #2 from Thomas Koenig ---
(In reply to Tobias Schlüter from comment #1)
> There's a typo in the example, /= instead of !=. Fixed example below:
The disease of a Fortran programmer writing C, I guess :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
--- Comment #22 from Thomas Koenig ---
Hi Toon,
it took some time, but we finally figured out that it is actually
a bug in your program that is causing problems.
It has (shortened)
nxglobal = 72;
This sets the coarray nxglobal to 72 on every
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98016
Thomas Koenig changed:
What|Removed |Added
Last reconfirmed||2020-11-26
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98156
Thomas Koenig changed:
What|Removed |Added
Resolution|--- |FIXED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83700
Bug 83700 depends on bug 98156, which changed state.
Bug 98156 Summary: [Coarray] alloc_comp_1.f90 tests for wrong condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98156
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98129
Bug ID: 98129
Summary: Failure on reading big chunk of /dev/urandom
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97459
--- Comment #26 from Thomas Koenig ---
Yep, it's implemented and works great.
For a simple "sum of digits" program in base ten, it's an acceleration
by more than a factor of two.
Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98129
Thomas Koenig changed:
What|Removed |Added
Target||x86_64-pc-linux-gnu
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98129
--- Comment #10 from Thomas Koenig ---
(In reply to anlauf from comment #9)
> The patch seems to regtest ok, but certainly needs some wider testing.
Actually, I think the bug is in io/unix.c:raw_read. That should take
care of repeating the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98156
Bug ID: 98156
Summary: [Coarray] alloc_comp_1.f90 tests for wrong condition
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98201
--- Comment #8 from Thomas Koenig ---
(In reply to dpozar from comment #6)
> Thomas,
> I am running that code in code blocks with MS visual C++ 2010, but I can't
> find the output - no console screen, and no output file that I can find.
What if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98201
Thomas Koenig changed:
What|Removed |Added
Target||mingw
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98201
--- Comment #5 from Thomas Koenig ---
What is the output of
#include
#include
int main()
{
_Complex float z, sq, sq2;
int n;
float a;
a = -1.;
for (n = 1; n < 10; n++)
{
a = a * 10;
z = a + _Complex_I * 1.0;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98201
--- Comment #10 from Thomas Koenig ---
I don't have a working mingw system myself, but I dusted off my cygwin
system for this, using their cross-compiler to mingw.
With
$ x86_64-w64-mingw32-gfortran.exe -static -static-libgfortran csqrt.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
--- Comment #26 from Thomas Koenig ---
After 00c2e5d1c15c67fc2c9d9ed86bfa1f5aa13848cc ,
the segfault for too many images is now also fixed,
and your program runs as expected.
I'd say an important milestone has been reached :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95293
--- Comment #11 from Thomas Koenig ---
(In reply to Dominique d'Humieres from comment #10)
> Could this PR be closed as INVALID?
Yes, I think so.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98129
--- Comment #2 from Thomas Koenig ---
The problem seems to be related to an early return from the read system call:
strace -e trace=open,read,close ./a.out
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\v\2\0\0\0\0\0"...,
832) = 832
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98129
--- Comment #3 from Thomas Koenig ---
The problem seems to be that we assume that a short read is always
an EOF, in read_block_direct:
if (unlikely ((ssize_t) nbytes != have_read_record))
{
/* Short read, e.g. if we hit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26183
Thomas Koenig changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98053
Bug ID: 98053
Summary: Add Fortran tests for behavior from environment
variables
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98076
Thomas Koenig changed:
What|Removed |Added
Version|unknown |11.0
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98076
Bug ID: 98076
Summary: Increase speed of integer I/O
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97920
Thomas Koenig changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90207
--- Comment #5 from Thomas Koenig ---
https://gcc.gnu.org/pipermail/gcc-patches/2020-December/561720.html
allows debugging of the generated variables.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86551
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97304
--- Comment #8 from Thomas Koenig ---
(In reply to Andreas Tobler from comment #7)
> Any news on this? Or can we close this PR?
Neither. As far as I can determine, this still fails.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98408
Bug ID: 98408
Summary: Character lengths for allocatable character arrays
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065
--- Comment #13 from Thomas Koenig ---
(In reply to Gabor from comment #10)
> Good to know that gfortran has come to an end. It means, for example, that
> i will not rely on the openacc implementation either. Or openmp5.
Those two fields are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93114
--- Comment #3 from Thomas Koenig ---
Probably a better idea:
If the span can be shown at compile-time to be a multiple of
the size of the component, we need not create the temporaray array
and instead set the strides of the descriptor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
Thomas Koenig changed:
What|Removed |Added
Status|REOPENED|NEW
--- Comment #5 from Thomas Koenig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
--- Comment #4 from Thomas Koenig ---
(In reply to Thomas Koenig from comment #3)
> Simplified test case:
>
> program main
> type foo
> real, allocatable, dimension(:) :: a[:]
> end type foo
> type (foo) :: x
> sync all
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
Thomas Koenig changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #6 from Thomas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97459
--- Comment #14 from Thomas Koenig ---
Created attachment 49520
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49520=edit
Numbers a, b so that 2^b ≡ 1 mod a up to b=64, larger b taken if several
solutions exist, plus the multiplicative
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
--- Comment #3 from Thomas Koenig ---
Simplified test case:
program main
type foo
real, allocatable, dimension(:) :: a[:]
end type foo
type (foo) :: x
sync all
allocate (x%a(10)[*])
end program main
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
Thomas Koenig changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97770
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97459
--- Comment #16 from Thomas Koenig ---
(In reply to Jakub Jelinek from comment #15)
> I plan to work on this early in stage3.
> And we really shouldn't use any tables, GCC should figure it all out.
> So, for double-word modulo by constant that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97459
--- Comment #17 from Thomas Koenig ---
To be compilable, my previous code lacks
typedef __uint128_t mytype;
> #define ONE ((__uint128_t) 1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97756
Bug ID: 97756
Summary: Inefficient handling of 128-bit arguments
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38592
Thomas Koenig changed:
What|Removed |Added
Last reconfirmed|2017-08-15 00:00:00 |2020-11-11
--- Comment #10 from Thomas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30398
Thomas Koenig changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21046
Thomas Koenig changed:
What|Removed |Added
Last reconfirmed|2014-12-25 00:00:00 |2020-11-11
--- Comment #6 from Thomas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97799
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97799
Thomas Koenig changed:
What|Removed |Added
Target Milestone|--- |10.3
Summary|Passing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
--- Comment #14 from Thomas Koenig ---
(In reply to Thomas Koenig from comment #13)
> (In reply to Thomas Koenig from comment #12)
> > Reduced test case:
> >
> > program main
> > type global_model_state
> > real, allocatable :: ps(:)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
--- Comment #16 from Thomas Koenig ---
program random_weather
implicit none
type global_model_state
real, allocatable :: ps(:,:) [:,:]
end type global_model_state
integer :: nxslab, nyslab
type(global_model_state) :: ms_full
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
--- Comment #15 from Thomas Koenig ---
Next reduced test-case:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
--- Comment #13 from Thomas Koenig ---
(In reply to Thomas Koenig from comment #12)
> Reduced test case:
>
> program main
> type global_model_state
> real, allocatable :: ps(:) [:]
> end type global_model_state
> type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
--- Comment #17 from Thomas Koenig ---
A bit more reduced (no derived types necessary):
program random_weather
implicit none
real, allocatable :: ps(:,:) [:,:]
integer :: nxslab, nyslab
integer :: npx
integer :: i, j
real,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
Thomas Koenig changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #12 from Thomas Koenig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97756
--- Comment #1 from Thomas Koenig ---
Actually, it was on a Ryzen 1700 (for the -march=native).
I'm at odds with architecture names...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97759
Thomas Koenig changed:
What|Removed |Added
Keywords||missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97738
--- Comment #5 from Thomas Koenig ---
(In reply to Jakub Jelinek from comment #4)
> What about a version that still sets lowest_bit to value & -value; rather
> than 1 < ctz?
I think this would be ideal, or close to it.
> Also, I'm not sure you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
Thomas Koenig changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #18 from Thomas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
Thomas Koenig changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #21 from Thomas Koenig
1 - 100 of 336 matches
Mail list logo
