[Bug testsuite/98156] [Coarray] alloc_comp_1.f90 tests for wrong condition

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98156 Thomas Koenig changed: What|Removed |Added Resolution|--- |FIXED Assignee|unassigned at g

[Bug fortran/83700] [Meta-bug] Fortran Coarray issues

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 ---

[Bug fortran/98201] CSQRT function gives bad resuts at runtime

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98201 Thomas Koenig changed: What|Removed |Added Target||mingw CC|

[Bug fortran/98201] CSQRT function gives bad resuts at runtime

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; sq

[Bug fortran/98201] CSQRT function gives bad resuts at runtime

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

[Bug fortran/98201] CSQRT function gives bad resuts at runtime

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 th

[Bug fortran/97920] [FINAL] -O2 segment fault due to extend derive type's member being partially allocated

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97920 Thomas Koenig changed: What|Removed |Added Resolution|--- |INVALID Status|WAITING

[Bug fortran/90207] Debugging generated tree code

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.

[Bug fortran/86551] [OOP] ICE on invalid code with select type

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86551 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #

[Bug rtl-optimization/97282] New: division done twice for modulo and divsion for 128-bit integers

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

[Bug rtl-optimization/97282] division done twice for modulo and divsion for 128-bit integers

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97282 Thomas Koenig changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill

[Bug rtl-optimization/97282] division done twice for modulo and divsion for 128-bit integers

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; __uint64_t

[Bug middle-end/89256] No optimized division by constant for __int128

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 f

[Bug target/97302] New: FreeBSD build fails with contrib/download_prerequisites with missing gmp.h

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: no

[Bug target/97302] FreeBSD build fails with contrib/download_prerequisites with missing gmp.h

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&action=edit Output from the attempt

[Bug target/97302] FreeBSD build fails with contrib/download_prerequisites with missing gmp.h

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!

[Bug bootstrap/97304] New: Boostrap failure on freebsd: ld: error: unable to find library -lc

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

[Bug bootstrap/97304] Boostrap failure on freebsd: ld: error: unable to find library -lc

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&action=edit config.log from failed attempt

[Bug bootstrap/97304] Boostrap failure on freebsd: ld: error: unable to find library -lc

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&action=edit output from compilation that failed with -lc

[Bug target/97304] Boostrap failure on freebsd: ld: error: unable to find library -lc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97304 Thomas Koenig changed: What|Removed |Added Component|bootstrap |target --- Comment #3 from Thomas Koenig

[Bug other/91084] download_prerequisites fails on OpenBSD

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91084 --- Comment #9 from Thomas Koenig --- WORKSFORME on OpenBSD 6.7.

[Bug fortran/97308] New: OpenBSD bootstrap fails with error: C++ preprocessor "/lib/cpp" fails sanity check

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 Severit

[Bug fortran/97308] OpenBSD bootstrap fails with error: C++ preprocessor "/lib/cpp" fails sanity check

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&action=edit config.log from gmp subdirectory Here it is. For what it is worth, I now tried bootstrapping with CC=cc and CX

[Bug fortran/97308] OpenBSD bootstrap fails with error: C++ preprocessor "/lib/cpp" fails sanity check

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&action=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 failur

[Bug fortran/97308] OpenBSD bootstrap fails with error: C++ preprocessor "/lib/cpp" fails sanity check

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97308 Thomas Koenig changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill

[Bug bootstrap/97308] OpenBSD bootstrap fails with error: C++ preprocessor "/lib/cpp" fails sanity check

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97308 Thomas Koenig changed: What|Removed |Added Component|fortran |bootstrap --- Comment #7 from Thomas Koe

[Bug bootstrap/97304] Boostrap failure on freebsd: ld: error: unable to find library -lc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97304 Thomas Koenig changed: What|Removed |Added Component|target |bootstrap CC|

[Bug bootstrap/97304] Boostrap failure on freebsd: ld: error: unable to find library -lc

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.

[Bug fortran/92065] [8/9/10/11 Regression] internal compiler error: in expand_expr_real_1

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 act

[Bug fortran/98408] New: Character lengths for allocatable character arrays

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 Component:

[Bug fortran/93114] Use span passing components of derived types

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 according

[Bug fortran/91648] [9/10/11 Regression] ICE in generate_finalization_wrapper, at fortran/class.c:2009

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91648 Thomas Koenig changed: What|Removed |Added Blocks||37336 See Also|

[Bug rtl-optimization/97756] Inefficient handling of 128-bit arguments

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97756 Thomas Koenig changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill

[Bug target/98438] Rather bad optimization of midpoint implementation for __int128 (and other types)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98438 Thomas Koenig changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED

[Bug fortran/88624] [Coarray] Rejects allocatable coarray passed as a dummy argument

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88624 Thomas Koenig changed: What|Removed |Added Keywords|rejects-valid |ice-on-valid-code CC|

[Bug target/98438] Rather bad optimization of midpoint implementation for __int128 (and other types)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98438 --- Comment #3 from Thomas Koenig --- Could you simply post the complete C++ source code that you used in the original example? This has the advantages of a) making it easier to modify (for a non-C++-person such as me) and b) of conforming to the

[Bug rtl-optimization/98438] Rather bad optimization of midpoint implementation for __int128 (and other types)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98438 Thomas Koenig changed: What|Removed |Added Status|WAITING |NEW Severity|normal

[Bug tree-optimization/98552] New: Make more use of __builtin_undefined for assuring that variables do not change

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98552 Bug ID: 98552 Summary: Make more use of __builtin_undefined for assuring that variables do not change Product: gcc Version: unknown Status: UNCONFIRMED Severity

[Bug tree-optimization/98552] Make more use of __builtin_undefined for assuring that variables do not change

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98552 Thomas Koenig changed: What|Removed |Added Version|unknown |11.0 Keywords|

[Bug tree-optimization/98552] Make more use of __builtin_undefined for assuring that variables do not change

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 :-)

[Bug fortran/98577] Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98577 Thomas Koenig changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED

[Bug fortran/82480] KIND array returned by STAT too small for many values on CygWin platforms (and probably others)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82480 --- Comment #4 from Thomas Koenig --- (In reply to Janne Blomqvist from comment #3) > Actually, libgfortran already has a version of stat with integer(kind=int64) > arguments. If you compile with -fdefault-integer-8 you get that one, and the > ex

[Bug tree-optimization/98552] Make more use of __builtin_undefined for assuring that variables do not change

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98552 --- Comment #4 from Thomas Koenig --- Yes, I think that translating a DO loop into something like int i; for (i=0; i

[Bug fortran/98701] I compiled a program with gfortran on Mac (Big Sur, version 11.1) and g77 on Windows 10. I get two very different results for identical input files with the results from the one c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98701 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #

[Bug fortran/67430] reallocate lhs with overloaded assignment operators causes memory error and wrong size

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67430 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #

[Bug fortran/66910] allocatable character in derived type gives segfault

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66910 Thomas Koenig changed: What|Removed |Added Resolution|--- |INVALID Status|NEW

[Bug fortran/68241] [meta-bug] [F03] Deferred-length character

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68241 Bug 68241 depends on bug 66910, which changed state. Bug 66910 Summary: allocatable character in derived type gives segfault https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66910 What|Removed |Added ---

[Bug fortran/48786] [OOP] Generic ambiguity check too strict for polymorphic dummies

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48786 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org S

[Bug fortran/97345] FE passes do_subscript leaks gmp memory

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97345 Thomas Koenig changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org E

[Bug fortran/97031] the content of a comment line breaks compilation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97031 Thomas Koenig changed: What|Removed |Added Status|WAITING |RESOLVED CC|

[Bug fortran/96843] gfortran rejects as shape mismatch rank one logical array arguments

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96843 Thomas Koenig changed: What|Removed |Added Status|WAITING |RESOLVED CC|

[Bug fortran/96386] Internal compiler error in ASSOCIATE

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96386 Thomas Koenig changed: What|Removed |Added Resolution|--- |FIXED CC|

[Bug fortran/94660] Wrong subroutine called at runtime than the one called in the source code with deferred subroutines

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94660 Thomas Koenig changed: What|Removed |Added Status|NEW |WAITING CC|

[Bug fortran/93925] Invalid memory reference upon call of a routine taking a procedure pointer as argument

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93925 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org S

[Bug fortran/93925] Invalid memory reference upon call of a routine taking a procedure pointer as argument

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93925 Thomas Koenig changed: What|Removed |Added Ever confirmed|0 |1 Resolution|INVALID

[Bug fortran/20585] [meta-bug] Fortran 2003 support

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20585 Bug 20585 depends on bug 93925, which changed state. Bug 93925 Summary: Invalid memory reference upon call of a routine taking a procedure pointer as argument https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93925 What|Removed

[Bug fortran/93924] ICE in gfc_class_len_get at trans_expr.c:231 with function returning a procedure pointer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93924 Thomas Koenig changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #5

[Bug fortran/93924] ICE in gfc_class_len_get at trans_expr.c:231 with function returning a procedure pointer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93924 --- Comment #6 from Thomas Koenig --- This actually segfaults at runtime.

[Bug fortran/93924] [OOP] ICE with procedure pointer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93924 Thomas Koenig changed: What|Removed |Added Summary|[OOP] segfault with |[OOP] ICE with procedure

[Bug fortran/94408] Spurious error: ‘rw_nl_grid’ must be a module procedure or an external procedure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94408 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org Resol

[Bug fortran/67539] Segmentation fault with elemental defined assignment and scalar function at the RHS

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67539 Thomas Koenig changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug fortran/93524] [ISO C Binding][F2018] CFI_allocate – elem_size mishandled + sm wrongly set?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93524 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #

[Bug fortran/83927] Type-Bound Procedure on element of Derived Type PARAMETER Array

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83927 Thomas Koenig changed: What|Removed |Added Status|WAITING |ASSIGNED CC|

[Bug fortran/98903] New: [Coarray, F2018] Implement TEAM_NUMBER in image-selector-spec

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98903 Bug ID: 98903 Summary: [Coarray, F2018] Implement TEAM_NUMBER in image-selector-spec Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal P

[Bug tree-optimization/99199] New: [9/10/11 Regression] Very large boolean expression leads to quite a few return statements

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99199 Bug ID: 99199 Summary: [9/10/11 Regression] Very large boolean expression leads to quite a few return statements Product: gcc Version: unknown Status: UNCONFIRMED

[Bug tree-optimization/99199] [9/10/11 Regression] Very large boolean expression leads to quite a few return statements

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99199 Thomas Koenig changed: What|Removed |Added Version|unknown |11.0 Target Milestone|---

[Bug rtl-optimization/100622] New: Conversion to smaller unsigned type in loop

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100622 Bug ID: 100622 Summary: Conversion to smaller unsigned type in loop Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Compone

[Bug rtl-optimization/100622] Conversion to smaller unsigned type in loop

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100622 Thomas Koenig changed: What|Removed |Added Status|UNCONFIRMED |SUSPENDED Last reconfirmed|

[Bug rtl-optimization/100622] Conversion to smaller unsigned type in loop

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100622 Thomas Koenig changed: What|Removed |Added Status|SUSPENDED |UNCONFIRMED Ever confirmed|1

[Bug rtl-optimization/100622] Conversion to smaller unsigned type in loop

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100622 --- Comment #4 from Thomas Koenig --- Yes, the masking should be only performed at the end. However, the inner loop could be further simplified to label: lwzu r8,4(r10) add r3,r8,r3 bdnz label without the need to do anything with

[Bug target/79173] add-with-carry and subtract-with-borrow support (x86_64 and others)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79173 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org Last reconf

[Bug fortran/100989] Bogus internal VOLATILE attribute for ASYNCHRONOUS

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100989 Thomas Koenig changed: What|Removed |Added Last reconfirmed||2021-06-09 Ever confirmed|0

[Bug fortran/100989] Bogus internal VOLATILE attribute for ASYNCHRONOUS

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100989 Thomas Koenig changed: What|Removed |Added Severity|normal |enhancement

[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

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, %rb

[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

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.

[Bug fortran/108329] New: IEEE_SET_ROUNDING_MODE ineffective with common subexpression elimination

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108329 Bug ID: 108329 Summary: IEEE_SET_ROUNDING_MODE ineffective with common subexpression elimination Product: gcc Version: unknown Status: UNCONFIRMED Severity: no

[Bug fortran/108329] IEEE_SET_ROUNDING_MODE ineffective with common subexpression elimination

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108329 Thomas Koenig changed: What|Removed |Added Version|unknown |13.0 Depends on|

[Bug fortran/108329] IEEE_SET_ROUNDING_MODE ineffective with common subexpression elimination

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 .

[Bug fortran/108329] IEEE_SET_ROUNDING_MODE ineffective with common subexpression elimination

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108329 Thomas Koenig changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed|

[Bug fortran/108329] IEEE_SET_ROUNDING_MODE ineffective with common subexpression elimination

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108329 Thomas Koenig changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|tkoenig at gcc d

[Bug tree-optimization/31756] -floop-interchange is not working on some fortran loops

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31756 Thomas Koenig changed: What|Removed |Added CC||mehdi.chinoune at hotmail dot com --- C

[Bug other/89204] -floop-interchange has no effect on Fortran code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89204 Thomas Koenig changed: What|Removed |Added Resolution|INVALID |DUPLICATE --- Comment #8 from Thomas Koe

[Bug libgcc/108279] Improved speed for float128 routines

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 yo

[Bug libgcc/108279] Improved speed for float128 routines

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&action=edit matmul_r16.i Here is matmul_r16.i from a relatively recent trunk.

[Bug libgcc/108279] Improved speed for float128 routines

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 th

[Bug libgcc/108279] Improved speed for float128 routines

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 a

[Bug libgcc/108279] Improved speed for float128 routines

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

[Bug fortran/108577] New: [meta-bug] Fortran 2023 support

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108577 Bug ID: 108577 Summary: [meta-bug] Fortran 2023 support Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran

[Bug fortran/103506] [10/11/12/13 Regression] ICE in gfc_free_namespace, at fortran/symbol.c:4039 since r10-2798-ge68a35ae4a65d2b3

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 Won

[Bug fortran/108592] In IF statements -Winteger-division is repeated 4 times

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 :-)

[Bug fortran/108665] New: Depenency checking: Run-time loop reversal instead of creating a temporary

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108665 Bug ID: 108665 Summary: Depenency checking: Run-time loop reversal instead of creating a temporary Product: gcc Version: unknown Status: UNCONFIRMED Severity:

[Bug tree-optimization/108710] New: Recognizing "rounding down to the nearest power of two"

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108710 Bug ID: 108710 Summary: Recognizing "rounding down to the nearest power of two" Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: enhancement

[Bug tree-optimization/108710] Recognizing "rounding down to the nearest power of two"

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.

[Bug rtl-optimization/108826] New: Inefficient address generation on POWER and RISC-V

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108826 Bug ID: 108826 Summary: Inefficient address generation on POWER and RISC-V Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3

[Bug tree-optimization/108839] New: Option for rerolling loops

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108839 Bug ID: 108839 Summary: Option for rerolling loops Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: tree-optimiza

[Bug tree-optimization/108844] New: sincos opportunity missed

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108844 Bug ID: 108844 Summary: sincos opportunity missed Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: tree-optimization

[Bug tree-optimization/108863] New: Unrolling could use range information

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108863 Bug ID: 108863 Summary: Unrolling could use range information Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-op

[Bug tree-optimization/108863] Unrolling could use range information

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108863 Thomas Koenig changed: What|Removed |Added Severity|normal |enhancement Keywords|

[Bug rtl-optimization/109019] New: Failure to optimize b + c -1

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109019 Bug ID: 109019 Summary: Failure to optimize b + c -1 Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: rtl-optimiz

[Bug rtl-optimization/109019] Failure to optimize b + c -1

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109019 Thomas Koenig changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

<    1   2   3   4   5   6   >