https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112449
Richard Biener changed:
What|Removed |Added
CC||jsm28 at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112450
--- Comment #3 from JuzheZhong ---
Add cond_len pattern for VLS mode can work around this bug.
Even though COND_LEN_xxx is not eventually
Testing a patch to fix it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112444
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110779
Thomas Schwinge changed:
What|Removed |Added
CC||tschwinge at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112443
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111956
--- Comment #10 from Thomas Schwinge ---
In addition to what Maciej said (..., and similarly, I don't have any proper
knowledge about PowerPC details):
(In reply to Gaius Mulley from comment #6)
> Created attachment 56522 [details]
> Proposed f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112449
--- Comment #7 from post+gcc at ralfj dot de ---
I guess the idea is that by passing a signaling NaN to a float operation, I am
already entering unspecified behavior, so it's okay for that float operation to
violate its usual contract and return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112454
Bug ID: 112454
Summary: csinc (csel is though) is not being used when there is
matches twice
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112449
--- Comment #6 from post+gcc at ralfj dot de ---
Hm, OTOH the C standard says
> The expressions 1×x, x/1, and x are equivalent (on IEC 60559 machines, among
others).
So, it seems like when they say "The + ,- , * , and / operators provide the IE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112449
--- Comment #5 from post+gcc at ralfj dot de ---
> See
> https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-fsignaling-nans
That's unrelated. That's about whether operation on signaling NaNs can trap. I
am asking when operations can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112432
--- Comment #5 from Li Pan ---
(In reply to Li Pan from comment #4)
> (In reply to Richard Biener from comment #3)
> > Ah, yes, for lrint we have the builtins - I just looked for lceil here. So
> > yeah, where there are DEF_EXT_LIB_FLOATN_NX_BU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52339
--- Comment #10 from Andrew Pinski ---
(In reply to Jakub Jelinek from comment #7)
> Created attachment 54994 [details]
> gcc14-pr52339.patch
>
> Untested fix.
I think this might fix PR 108789 too ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108789
Andrew Pinski changed:
What|Removed |Added
Summary|__builtin_(add|mul)_overflo |__builtin_(add|mul)_overflo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109906
Andrew Pinski changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
La
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97503
--- Comment #5 from LIU Hao ---
(In reply to LIU Hao from comment #4)
> lzcnt rax, rdx
> testrdx, rdx
> mov edx, 64
> cmove rax, rdx
There is actually another missed optimization here. LZCNT sets CF if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112445
--- Comment #2 from Zdenek Sojka ---
Created attachment 56545
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56545&action=edit
testcase failing just at -O1
$ x86_64-pc-linux-gnu-gcc -O testcase2.c
testcase2.c: In function 'foo':
testcase2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97503
LIU Hao changed:
What|Removed |Added
CC||lh_mouse at 126 dot com
--- Comment #4 from LI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109843
Andrew Pinski changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108911
--- Comment #3 from Andrew Pinski ---
Note clang has a decent error message for `0xe+100` but has just as bad one for
`123_to.`
Full testcase for a few:
```
int a = 0xe+100;
int b = 123_to.;
int c = 0xe_100e+10;
```
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108911
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112423
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108911
Andrew Pinski changed:
What|Removed |Added
CC||xmh970252187 at gmail dot com
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111918
Lewis Hyatt changed:
What|Removed |Added
CC||lhyatt at gcc dot gnu.org
Sta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108678
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108026
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111893
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110807
--- Comment #13 from CVS Commits ---
The master branch has been updated by Alexandre Oliva :
https://gcc.gnu.org/g:e39b3e02c27bd771a07e385f9672ecf1a45ced77
commit r14-5260-ge39b3e02c27bd771a07e385f9672ecf1a45ced77
Author: Alexandre Oliva
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112383
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112445
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112450
--- Comment #2 from JuzheZhong ---
if (loop_vinfo
&& LOOP_VINFO_CAN_USE_PARTIAL_VECTORS_P (loop_vinfo)
&& mask_out_inactive)
{
if (cond_len_fn != IFN_LAST
&& direct_internal_fn_supported_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112445
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112453
Bug ID: 112453
Summary: : __take_of_repeat_view/__drop_of_repeat_view
should forwards __r._M_value
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112450
--- Comment #1 from JuzheZhong ---
Oh. I see we have cond_xxx pattern for VLS modes.
like V64HImdoe. But we don't support partial vectorization for VLS modes.
VLS modes are supposed to used as SIMD GNU vectorization.
As long as COND_XXX is en
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112443
--- Comment #1 from Hongtao.liu ---
The below can fix that, there's typo for 2 splitters.
@@ -17082,7 +17082,7 @@ (define_insn_and_split "*avx2_pcmp3_4"
(match_dup 4))]
UNSPEC_BLENDV))]
{
- if (INTVAL (operands[5])
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112452
Bug ID: 112452
Summary: : operator|(_Range&& __r, _Self&& __self)
should return decltype(auto)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111956
--- Comment #9 from Maciej W. Rozycki ---
Hmm, the host check for `__frexpieee128' in gcc/ will surely not do
what's intended: even if the host is `powerpc*-*-linux*', the target
will often be something else and vice versa (libgm2's host is GCC'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112451
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112451
Bug ID: 112451
Summary: gcc_build was not updated to checkout via git
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: internal-improvement
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110936
--- Comment #4 from Johel Ernesto Guerrero Peña ---
They talk about `-fno-delete-null-pointer-checks` in BUG71962.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110936
Nathaniel Shead changed:
What|Removed |Added
CC||nathanieloshead at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112450
Bug ID: 112450
Summary: RVV vectorization ICE in vect_get_loop_mask, at
tree-vect-loop.cc:11037
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112444
Sam James changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
Summa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112374
--- Comment #8 from Andrew Pinski ---
>From the dup:
The only difference between stage2-gcc/i386-expand.o and
stage3-gcc/i386-expand.o is
```
< ./stage2-gcc/i386-expand.o: file format elf64-x86-64
---
> ./stage3-gcc/i386-expand.o: file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112443
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |12.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112444
--- Comment #5 from Andrew Pinski ---
Note the 2 tmp variables need to be named the same. Otherwise fre won't merge
the 2 ".DEFERRED_INIT (1, 2, &"tmp"[0]);" .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112444
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112444
Andrew Pinski changed:
What|Removed |Added
Attachment #56543|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112444
--- Comment #2 from Andrew Pinski ---
Created attachment 56543
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56543&action=edit
little more reduced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #28 from dave.anglin at bell dot net ---
On 2023-11-08 7:07 p.m., law at gcc dot gnu.org wrote:
> Do we already have a dump for the key function? Presumably f-m-o doesn't
> trigger*that* much. And if this is triggering w/o LTO we c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #27 from dave.anglin at bell dot net ---
On 2023-11-08 7:00 p.m., John David Anglin wrote:
> On 2023-11-08 6:51 p.m., sjames at gcc dot gnu.org wrote:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
>>
>> --- Comment #23 from S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #26 from Jeffrey A. Law ---
As a compiler junkie, I tend to think compiler first until I can prove it
otherwise. I wouldn't get too hung up on aliasing issues and such at this
point.
Do we already have a dump for the key function?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #25 from Sam James ---
I am having the same thoughts. It would not be the first time Python had
something dubious, like...
* https://wiki.gentoo.org/wiki/Project:Python/Strict_aliasing ->
https://www.python.org/dev/peps/pep-3123/
* h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #24 from dave.anglin at bell dot net ---
On 2023-11-08 6:51 p.m., sjames at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
>
> --- Comment #23 from Sam James ---
> (In reply to Andrew Pinski from comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #23 from Sam James ---
(In reply to Andrew Pinski from comment #21)
> The other option to try is -fstack-reuse=none. There is definitely known
> issues with the code that coalesces stack variables together too (see PR
> 111843 for ex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #22 from John David Anglin ---
Created attachment 56542
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56542&action=edit
Preprocessed source and assembly files for Python/compile.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #21 from Andrew Pinski ---
(In reply to dave.anglin from comment #20)
> Both -fno-strict-aliasing and -fno-schedule-insns2 applied to
> compiler_visit_expr()
> work around issue.
The other option to try is -fstack-reuse=none. There
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112447
--- Comment #10 from JuzheZhong ---
(In reply to Vineet Gupta from comment #9)
> (In reply to JuzheZhong from comment #7)
> > Oh. I missed it:
> >
> > vmv.v.x v2,s0
> > vse8.v v2,0(a5)
> >
> > Leave it to me today. It should b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112447
Vineet Gupta changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112447
--- Comment #8 from JuzheZhong ---
Could you continue debug more cases ?
FAIL: gcc.c-torture/execute/pr89369.c -O2 execution test
FAIL: gcc.c-torture/execute/pr89369.c -O2 -flto -fno-use-linker-plugin
-flto-partition=none execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112447
--- Comment #7 from JuzheZhong ---
Oh. I missed it:
vmv.v.x v2,s0
vse8.v v2,0(a5)
Leave it to me today. It should be simple fix.
Thanks for report it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112447
--- Comment #6 from Vineet Gupta ---
I have debugged this by single stepped in qemu
when the test fails (first loop for offset 0, iteration 8)
The last VSETVLI is this one,
0x10a3e 0d107057 vsetvli zero,zero,e32,m2,ta,ma
0x10a42
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112447
--- Comment #5 from JuzheZhong ---
I don't think VSETVL is wrong.
vsetivlizero,8,e8,mf2,ta,ma
sd ra,120(sp)
vmv.x.s a1,v1
...
.L36:
vse8.v
...
vsetivlizero,8,e32,m2,t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112447
--- Comment #4 from Vineet Gupta ---
Created attachment 56541
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56541&action=edit
asm output nok
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112447
--- Comment #3 from Vineet Gupta ---
Created attachment 56540
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56540&action=edit
asm output ok
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112447
--- Comment #2 from Vineet Gupta ---
Created attachment 56539
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56539&action=edit
manually reduced src
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112339
--- Comment #3 from Niall Douglas ---
Thanks for the patch. I've sent it on to the originator of the bug, if they
confirm it fixes their issue to me I'll let you know.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112447
--- Comment #1 from JuzheZhong ---
Could you share more assembly ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104255
Patrick Palka changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104255
Patrick Palka changed:
What|Removed |Added
CC||fchelnokov at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112448
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
Resol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112448
--- Comment #1 from Andrew Pinski ---
Note the error message on the trunk changed to:
:4:40: error: template argument 1 is invalid
4 | constexpr bool f(auto x) requires b { return true; }
|^
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112449
--- Comment #4 from Andrew Pinski ---
And documented other parts here:
https://gcc.gnu.org/onlinedocs/gcc-13.2.0/cpp/Common-Predefined-Macros.html
specifically:
It does not indicate whether optimizations respect signaling NaN semantics (the
ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112449
--- Comment #3 from Andrew Pinski ---
GCC does document some of this on
https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Floating-point-implementation.html
but not the signaling nan part.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112449
--- Comment #2 from Andrew Pinski ---
Note mips and sh and a few other targets have the quiet bit meaning the
opposite.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112449
--- Comment #1 from Andrew Pinski ---
See
https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-fsignaling-nans
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112449
Bug ID: 112449
Summary: Arithmetic operations can produce signaling NaNs
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82524
--- Comment #22 from CVS Commits ---
The master branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:dced5ae64703507a7159972316a1dde48e5f7470
commit r14-5254-gdced5ae64703507a7159972316a1dde48e5f7470
Author: Uros Bizjak
Date: Wed N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112448
Bug ID: 112448
Summary: Constraint expression b rejected
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111311
--- Comment #16 from Vineet Gupta ---
(In reply to Patrick O'Neill from comment #8)
> Updated regression list using r14-5070-g4ea36076d66 on rv64gcv:
>
> === gcc: Unexpected fails for rv64gcv lp64d medlow ===
> FAIL: gcc.c-torture/execu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112447
Bug ID: 112447
Summary: risc-v regression: FAIL:
gcc.c-torture/execute/memset-3.c -O3
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #20 from dave.anglin at bell dot net ---
On 2023-11-08 2:07 p.m., pinskia at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
>
> --- Comment #18 from Andrew Pinski ---
> I wonder if -fno-strict-aliasing w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #19 from Jeffrey A. Law ---
f-m-o runs post-allocation, so the scope of where it's behavior can change
things is narrower. So testing with -fno-schedule-insns isn't going to be
useful, but -fno-schedule-insns2 might.
I'm a bit conc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #18 from Andrew Pinski ---
I wonder if -fno-strict-aliasing works around the issue too?
I get the feeling that `fold mem offset pass` allows the aliasing code to have
a better time with the offset and that might be expose more aliasi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8670
--- Comment #24 from Jonathan Wakely ---
Oh, but this would be an ABI break. When using the explicit instantiation
definitions in libstdc++.so allocations and deallocations will match because
both will come from the library. But if anything is inl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #17 from dave.anglin at bell dot net ---
On 2023-11-08 9:42 a.m., jeffreyalaw at gmail dot com wrote:
> I'd probably continue with the process of narrowing down what code is
> affected using the attributes. We already know the file,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112446
Bug ID: 112446
Summary: Switch -gnatyz included in -gnatyg
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112442
--- Comment #9 from Adam Andersson ---
I was sure I had tried -fno-strict-aliasing without any difference, but I
guessed I messed up somehow. Sorry about that.
Still, is it not strange that -Wall doesn't generate a warning about this then?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8670
Jonathan Wakely changed:
What|Removed |Added
Assignee|giovannibajo at gmail dot com |redi at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8670
--- Comment #22 from Jonathan Wakely ---
This bug is still present in the COW std::string, which is still supported even
though it's not the default.
There are two problems. The first is the one reported by James Kanze, that the
string contents n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112442
--- Comment #8 from Jonathan Wakely ---
The aliasing doesn't happen when writing to the array, it's when reading a
char* value from an object of type unsigned char*.
If you just passed the unsigned char* to memcpy instead of *(char**)&ptr it
wo
-5250-20231108213319-g8cf7b936d44-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231108 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112406
--- Comment #11 from Robin Dapp ---
Thanks, this is helpful.
I have a patch that I just bootstrapped and ran the testsuite with on aarch64.
Going to post it soon, maybe Richi still has a better idea how to work around
this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112406
--- Comment #10 from Tamar Christina ---
Just finished second bisect and reduce. Came out to this commit as well.
---
module brute_force
integer, parameter :: r=9
integer sudoku1(1, r)
contains
subroutine brute
integer l(r)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112442
--- Comment #7 from Xi Ruoyao ---
Note that in the "new bug" page, there is a red banner saying:
Before reporting that GCC compiles your code incorrectly, compile it with gcc
-Wall -Wextra and see whether this shows anything wrong with your cod
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112407
--- Comment #5 from Tomáš Trnka ---
(In reply to Paul Thomas from comment #4)
> Created attachment 56531 [details]
> Fix for this PR
>
> The bug comes about because the vtable is being declared in one of the
> specific procedures typebound to t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112442
Xi Ruoyao changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112444
--- Comment #1 from Sam James ---
Created attachment 56535
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56535&action=edit
reduced.i
cvise popped this out, I haven't tried to prettify it by hand at all as heading
out now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112442
--- Comment #5 from Andreas Schwab ---
warning: dereferencing type-punned pointer will break strict-aliasing rules
[-Wstrict-aliasing]
15 | test((char **)&ptr, "test!");
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111298
Jorn Wolfgang Rennecke changed:
What|Removed |Added
CC||amylaar at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #16 from Jeffrey A. Law ---
On 11/8/23 03:09, manolis.tsamis at vrull dot eu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
>
> --- Comment #15 from Manolis Tsamis ---
> (In reply to Sam James from comment #13)
>> Cre
1 - 100 of 156 matches
Mail list logo
