https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23872
--- Comment #9 from Andrew Pinski ---
Created attachment 57968
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57968=edit
Patch set that I will be submitting once GCC 15 opens up
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114732
--- Comment #6 from HaoChen Gui ---
(In reply to Segher Boessenkool from comment #3)
> 1001, 0101, 0011 I mean of course.
>
> In some ways CCmode models this better than CCFPmode, but we do not actually
> model
> the SO bit (bit 3) at all in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114735
--- Comment #6 from Andrew Pinski ---
(In reply to Gejoe from comment #4)
> Thanks Andrew for the info.
>
> So, does this mean that every program which was compiled earlier with one
> step (ie. gcc --coverage srcfile.c) of gcc/g++ will have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114735
--- Comment #5 from Gejoe ---
my previous message is after seeing this change :
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114735
--- Comment #4 from Gejoe ---
Thanks Andrew for the info.
So, does this mean that every program which was compiled earlier with one step
(ie. gcc --coverage srcfile.c) of gcc/g++ will have to be split to 2 steps
using -c option first and then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114744
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
Ever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114700
--- Comment #20 from Hu Lin ---
Created attachment 57967
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57967=edit
A new version
When I tested this patch, I met another question. g++.dg/ubsan/vla-1.C will
raise a ICE without (TREE_TYPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23872
--- Comment #8 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #7)
> With the example in PR 86698 with the patches I will be posting, gcc now
> does:
> ```
> ;; Function f (null)
> ;; enabled by -tree-original
>
>
> {
> int x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23872
--- Comment #7 from Andrew Pinski ---
With the example in PR 86698 with the patches I will be posting, gcc now does:
```
;; Function f (null)
;; enabled by -tree-original
{
int x = z++ , y;
DECL_EXPR;
return x;
}
```
I am still
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86698
--- Comment #5 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #4)
> The semicolon comes from print_declaration So this is just a dup of bug
> 23872 in the end.
>
> *** This bug has been marked as a duplicate of bug 23872 ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23872
Andrew Pinski changed:
What|Removed |Added
CC||rearnsha at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86698
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114748
--- Comment #5 from Arsen Arsenović ---
hm, that's odd, my local machine can also regenerate to Cristophes version also
today.. I wonder why it did not back then.. what should we do about it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114729
Vineet Gupta changed:
What|Removed |Added
Last reconfirmed|2024-04-15 00:00:00 |2024-4-16
--- Comment #9 from Vineet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114748
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114749
Bug ID: 114749
Summary: [14] RISC-V rv64gcv ICE: in vectorizable_load, at
tree-vect-stmts.cc
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114748
Andrew Pinski changed:
What|Removed |Added
Version|unknown |14.0
Summary|libcpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114748
--- Comment #2 from Andrew Pinski ---
So I went back to the gcc 9.1.0 release and aclocal there didn't change and
didn't have the include for override.m4 . I am trying to figure out where this
changed ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112364
Peter Damianov changed:
What|Removed |Added
CC||peter0x44 at disroot dot org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114618
--- Comment #6 from Jerry DeLisle ---
Created attachment 57965
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57965=edit
Preliminary patch to fix several issues.
The attached patch is very preliminary and appears to fix the X format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114748
--- Comment #1 from Andrew Pinski ---
The last time aclocal.m4 had an include for override.m4 was
r9-3776-g22e052725189a4 . Are you sure you are using the correct
autoconf/automake version?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114745
--- Comment #3 from GCC Commits ---
The master branch has been updated by Gaius Mulley :
https://gcc.gnu.org/g:eadd05d5601063bd0c7ef6c3606b4eeb856d57d7
commit r14-9998-geadd05d5601063bd0c7ef6c3606b4eeb856d57d7
Author: Gaius Mulley
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114748
Bug ID: 114748
Summary: libcpp aclocal.m4 and configure incorrectly
regenerated
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: minor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114747
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114747
Bug ID: 114747
Summary: [RISC-V RVV] Wrong SEW set for mixed-size intrinsics
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108383
Peter Damianov changed:
What|Removed |Added
CC||peter0x44 at disroot dot org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #30 from GCC Commits ---
The master branch has been updated by Tamar Christina :
https://gcc.gnu.org/g:f438acf7ce2e6cb862cf62f2543c36639e2af233
commit r14-9997-gf438acf7ce2e6cb862cf62f2543c36639e2af233
Author: Tamar Christina
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114330
--- Comment #5 from Andrew Pinski ---
The most annoying part of this is the struct compiler is initialized by
*/lang-specs.h and it looks like I missed one and the error message is not so
obvious where the issue is.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114739
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114741
--- Comment #6 from Tamar Christina ---
and the exact armv9-a cost model you quoted, also does the right codegen.
https://godbolt.org/z/obafoT6cj
There is just an inexplicable penalty being applied to the r->r alternative.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114741
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97304
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104707
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=114739
--- Comment #4 from anlauf at gcc dot gnu.org ---
Reduced testcase:
program main
implicit complex(z)
z2%re = 1.
z2%im = 2.
end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113793
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |14.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208
--- Comment #33 from Jakub Jelinek ---
It regresses
g++.dg/coroutines/torture/co-await-16-template-traits.C
g++.dg/cpp0x/pr89403.C
g++.dg/tree-ssa/pr46228.C
g++.dg/torture/pr104601.C
g++.dg/torture/pr89303.C
g++.dg/torture/pr91606.C
on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114745
--- Comment #2 from Gaius Mulley ---
Created attachment 57964
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57964=edit
Proposed fix
Here is a proposed patch and the example test run:
$ gm2 -fiso -c -I. -I../ Dictionary.mod -fsources
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114741
--- Comment #4 from Andrew Pinski ---
(In reply to Wilco from comment #2)
> It looks like the underlying bug is '^' being incorrectly treated like '?'
> in record_reg_classes (which is never used during reload). Fixing that
> results in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114050
--- Comment #18 from Andrew Pinski ---
(In reply to Vincent Lefèvre from comment #17)
> (In reply to Jonathan Wakely from comment #13)
> > -fexcess-precision does affect constants.
>
> Indeed, and this is a bug, as -fexcess-precision=fast was
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114050
--- Comment #17 from Vincent Lefèvre ---
(In reply to Jonathan Wakely from comment #13)
> -fexcess-precision does affect constants.
Indeed, and this is a bug, as -fexcess-precision=fast was not meant to make
general programs less accurate (but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114746
Bug ID: 114746
Summary: With FLT_EVAL_METHOD = 2, -fexcess-precision=fast
reduces the precision of floating-point constants
Product: gcc
Version: 14.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114050
--- Comment #16 from Vincent Lefèvre ---
(In reply to Jakub Jelinek from comment #15)
> There is no bug, the compiler implements what the standard says for the
> FLT_EVAL_METHOD == 2 case.
I agree. I meant this *invalid* bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114723
--- Comment #2 from Halalaluyafail3 ---
(In reply to Richard Biener from comment #1)
> This seems to be fixed recently?
I just tested the code on godbolt again, and it doesn't seem to generate an ICE
anymore. However, it does seem to generate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114467
--- Comment #4 from anlauf at gcc dot gnu.org ---
(In reply to thomas from comment #3)
> (In reply to anlauf from comment #1)
> > Can you attached a self-contained reproducer?
> >
> > The traceback looks familiar. Are you by chance using an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114050
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114050
--- Comment #14 from Vincent Lefèvre ---
This bug is about "double/float constant evaluation" (and it has been marked as
a duplicate of a bug precisely on this subject), not about the rules that are
applied *after* this evaluation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114739
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Keywords||ice-on-valid-code,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113793
--- Comment #6 from GCC Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:48024a99e3c2ae522d0026eedd591390506b68ca
commit r14-9996-g48024a99e3c2ae522d0026eedd591390506b68ca
Author: Harald Anlauf
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114741
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-04-16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114738
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-04-16
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114732
--- Comment #5 from Segher Boessenkool ---
(Or, at-most-one-hot, that is!)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114732
--- Comment #4 from Segher Boessenkool ---
(In reply to Segher Boessenkool from comment #3)
> -- Bit 0 is all-true, bit 2 is all-false, like in the vcmp* insns.
(And bits 1 and 3 are set to zeroes for those insns. So it is all one-hot
there
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208
--- Comment #32 from Jakub Jelinek ---
Created attachment 57963
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57963=edit
gcc14-pr113208.patch
Ah, I shouldn't call expand_or_defer* in that function, that has been called
already earlier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114741
--- Comment #2 from Wilco ---
It looks like the underlying bug is '^' being incorrectly treated like '?' in
record_reg_classes (which is never used during reload). Fixing that results in
the expected code being generated in all cases. It looks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114743
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
Assignee|unassigned at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92880
Andrew Pinski changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57585
--- Comment #4 from Jonathan Wakely ---
Created attachment 57961
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57961=edit
Add --enable-clocale=ieee_1003.1-2008
This is an initial prototype of a new clocale model.
The wide string info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92880
--- Comment #6 from GCC Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:8eddd87da2dd01c841f9742f973f65ebe0a88e71
commit r14-9994-g8eddd87da2dd01c841f9742f973f65ebe0a88e71
Author: Andrew Pinski
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208
--- Comment #31 from Jakub Jelinek ---
Created attachment 57960
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57960=edit
gcc14-pr113208.patch
Here is my attempt to optimize it in the C++ FE.
The ICE is gone and for pr113208_0.C compiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114739
--- Comment #2 from David Binderman ---
Created attachment 57959
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57959=edit
F90 source code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114050
--- Comment #13 from Jonathan Wakely ---
-fexcess-precision does affect constants.
With -fexcess-precision=standard, assignments and casts discard excess
precision which may otherwise be present in arithmetic expressions and
constants. With
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114741
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114739
kargls at comcast dot net changed:
What|Removed |Added
CC||kargls at comcast dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113790
Andreas Schwab changed:
What|Removed |Added
CC||sch...@linux-m68k.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114255
Andreas Schwab changed:
What|Removed |Added
Resolution|FIXED |DUPLICATE
--- Comment #2 from Andreas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114745
Gaius Mulley changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114740
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114740
Vincent Lefèvre changed:
What|Removed |Added
CC||vincent-gcc at vinc17 dot net
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114745
Bug ID: 114745
Summary: const cast causes ICE
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: modula2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114050
Vincent Lefèvre changed:
What|Removed |Added
CC||vincent-gcc at vinc17 dot net
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114744
--- Comment #1 from seurer at gcc dot gnu.org ---
also gcc 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99731
vvinayag at arm dot com changed:
What|Removed |Added
CC||vvinayag at arm dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114729
--- Comment #8 from Jeffrey A. Law ---
I didn't even notice you had that testcase attached!
I haven't done a deep dive, but the first thing that jumps out is the number of
instructions in the ready queue, most likely because of the addressing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114744
Bug ID: 114744
Summary: test case gcc.target/powerpc/builtins-6-p9-runnable.c
fails
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114729
--- Comment #7 from Jeffrey A. Law ---
Yes, there are different algorithms. I looked at them a while back when we
first noticed the problems with spilling and x264. There was very little
difference for specint when we varied the algorithms.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114732
--- Comment #3 from Segher Boessenkool ---
1001, 0101, 0011 I mean of course.
In some ways CCmode models this better than CCFPmode, but we do not actually
model
the SO bit (bit 3) at all in CCmode. It is a nice feature of CCmode (that we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114743
Filip Kastl changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114743
Bug ID: 114743
Summary: ICE in build_check_stmt at asan.cc:2707 while
compiling gcc.dg/ubsan/pr112709-2.c with
-fsanitize=address
Product: gcc
Version: 14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114742
--- Comment #2 from Jonathan Wakely ---
Mathias noted that still fails with -mcpu=power7
Checking for _ARCH_PWR8 or __POWER8_VECTOR__ instead works.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114742
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114742
Bug ID: 114742
Summary: invalid use of '__ieee128' in
and
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114734
--- Comment #4 from Robin Dapp ---
Ok, it looks like we do 5 iterations with the last one being length-masked to
length 2 and then in the "live extraction" phase use "iteration 6".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114736
--- Comment #11 from prathamesh3492 at gcc dot gnu.org ---
Hi Richard,
Thanks for the quick fix! I verified it now compiles the test-case with -O3
-mcpu=neoverse-v2. I suppose this will need backporting to gcc-13 branch. The
test compiles OK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57585
--- Comment #3 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #2)
> Separately, it would be good to provide a libintl-based implementation of
> std::messages, for targets where that's not part of glibc.
Although the POSIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114734
--- Comment #3 from Robin Dapp ---
> probably -fwhole-program is enough, -flto not needed(?)
Yes, -fwhole-program is sufficient.
>
> # vectp_g.248_1401 = PHI
> ...
> _1411 = .SELECT_VL (ivtmp_1409, POLY_INT_CST [2, 2]);
> ..
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114741
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92875
Andrew Pinski changed:
What|Removed |Added
CC||gnu.ojxq8 at dralias dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114740
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114050
Andrew Pinski changed:
What|Removed |Added
Resolution|INVALID |DUPLICATE
--- Comment #11 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92875
Andrew Pinski changed:
What|Removed |Added
CC||sjh at schilling dot dk
--- Comment #12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114735
--- Comment #3 from Andrew Pinski ---
The "fix" was to how to build to be able to use gcov. Basically you build to an
object file first and then link the object file to get the old behavior and the
behavior that gcov expects.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114740
--- Comment #1 from Jonathan Wakely ---
See the first item at https://gcc.gnu.org/gcc-13/changes.html#cxx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114741
Bug ID: 114741
Summary: [14 regression] aarch64 sve: unnecessary fmov for
scalar int bit operations
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114731
--- Comment #21 from Alejandro Colomar ---
It would be interesting to learn why MSVC gets it right. Maybe there's a
deterministic way to avoid this warning. Although maybe it's just that they're
doing heuristics.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114731
--- Comment #20 from Alejandro Colomar ---
H, I like the _Generic() to assert the type. Thanks!
With that, I find it more acceptable. At least I don't need to use GNU
extensions, and the cast is coupled with the verification of the type.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114740
Bug ID: 114740
Summary: i686-linux-gnu-g++ does not interpret floating point
literals as double
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114731
--- Comment #19 from Martin Uecker ---
It would still work for other arguments that are used in the active branch, but
not arguments you may not use in active branch or other subexpressions not used
in the active branch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114731
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #18
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92840
--- Comment #5 from Thomas Schwinge ---
As determined during patch review, there's still an unresolved issue:
On 2024-04-16T17:12:17+0800, Chung-Lin Tang wrote:
> If we continue to use k->refcount itself as the flag holder of map type, I
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92840
Thomas Schwinge changed:
What|Removed |Added
CC||cltang at gcc dot gnu.org
--- Comment
1 - 100 of 163 matches
Mail list logo
