https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109728
--- Comment #2 from Fabio Alemagna ---
Yes, clang handles this case correctly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109722
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109722
--- Comment #4 from CVS Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:6fe385eac6ff8ecddb6cbdff2c706b27b5137006
commit r14-488-g6fe385eac6ff8ecddb6cbdff2c706b27b5137006
Author: Andrew Pinski
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109691
--- Comment #4 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #2)
> gcc.dg/pr81192.c might need a similar thing now too but I am not 100% sure.
> pr81192.c should really be a Gimple testcase but gimple testcases were not
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105576
--- Comment #6 from Fangrui Song ---
(In reply to Hongtao.liu from comment #4)
> constraint "i" + "%p0"?
>
> asm (".pushsection .xxx,\"aw\"; .dc.a %p0; .popsection" :: "i"(addr)); //
> supported on aarch64 and riscv
> asm (".pushsection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109662
--- Comment #8 from Jerry DeLisle ---
A side comment. We have a runtime function called "notify_std". Every time I
try to use it I struggle as it is not intuitively obvious how it works. We
ought to provide some better documentation on using it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109658
Jason Merrill changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109645
Jason Merrill changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109658
--- Comment #8 from Jason Merrill ---
*** Bug 109723 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109723
Jason Merrill changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109658
Jason Merrill changed:
What|Removed |Added
Resolution|--- |FIXED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109658
--- Comment #6 from CVS Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:6f18f344338b370031e75924eed2bdd1ce5c8dba
commit r14-487-g6f18f344338b370031e75924eed2bdd1ce5c8dba
Author: Jason Merrill
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109722
Andrew Pinski changed:
What|Removed |Added
Keywords||patch
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109732
--- Comment #14 from Andrew Pinski ---
Figured out a C testcase:
```
[[gnu::noipa]]
_Bool f3(_Bool a)
{
if (a==0)
return 0;
else
return a;
}
```
Still need: `-fdisable-tree-fre1` though because fre is able to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109723
Jason Merrill changed:
What|Removed |Added
Last reconfirmed||2023-05-04
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97122
--- Comment #6 from Ian Harvey ---
A module procedure is defined by a module subprogram (F2018 15.2.2.2p3). A
module subprogram (or any subprogram) is a syntax element (a piece of source
code), equivalent to /module-subprogram/ (see the first
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52339
--- Comment #9 from Jason Merrill ---
(In reply to Jakub Jelinek from comment #5)
> in main it doesn't, as the nop is stripped and the COMPONENT_REF is
> TREE_READONLY and !TREE_SIDE_EFFECTS.
> tree.cc (save_expr) documents that:
>Constants,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109732
Andrew Pinski changed:
What|Removed |Added
Keywords||patch
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100918
--- Comment #9 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #8)
> (In reply to Christian Prochaska from comment #7)
> > Since the commit above the following test fails. Is this correct?
>
> >
> > class T1 { };
> > class T2 {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100918
--- Comment #8 from Andrew Pinski ---
(In reply to Christian Prochaska from comment #7)
> Since the commit above the following test fails. Is this correct?
>
> class T1 { };
> class T2 { };
>
> template
> class A { };
>
> class B : A { };
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109742
--- Comment #1 from Andrew Pinski ---
bug 109017 comment #1 looks like an exact dup of this testcase too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100918
Christian Prochaska changed:
What|Removed |Added
CC||christian.prochaska@genode-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109742
Bug ID: 109742
Summary: ICE on unexpanded NTTP pack
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109690
--- Comment #5 from Uroš Bizjak ---
Created attachment 55002
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55002=edit
Patch that introduces mulv2si3
The compiled code with -march=znver1 is now the same as without the flag:
loop:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109732
--- Comment #12 from Sergei Trofimovich ---
(In reply to Andrew Pinski from comment #11)
> Created attachment 54999 [details]
> Patch which needs a message/changelog
I confirm the patch fixes real test failures on nlohmann_json-3.11.2 as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109741
--- Comment #14 from Jonathan Wakely ---
Libstdc++ doesn't work on "every possible architecture", just the ones GCC
supports.
I am 100% confident that alignas(void*) is wrong for every architecture GCC
supports, and I'm pretty confident
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109656
--- Comment #5 from seurer at gcc dot gnu.org ---
make -k check
RUNTESTFLAGS="conformance.exp=26_numerics/random/random_device/cons/token.cc"
This is from powerpc64le-unknown-linux-gnu/libstdc++-v3/testsuite/libstdc++.log
Setting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109730
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109666
Andrew Pinski changed:
What|Removed |Added
CC||tocic at protonmail dot ch
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109728
--- Comment #1 from Andrew Pinski ---
Oh this might be an ambiguity with ObjC++ parsing part.
[a b] is how you call an object-C method after all.
Is clang able to handle this case too?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109741
--- Comment #13 from Janez Zemva ---
@Jonathan Wakely
I asked ChatGPT about this:
What is the most common size of a cache line?
The most common size of a cache line is 64 bytes. This size is used by most
modern CPUs because it strikes a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109716
--- Comment #3 from Andrew Pinski ---
The warning comes from:
[local count: 64057779]:
util_format_unswizzle_4f (_swizzled, _42, 64B);
goto ; [100.00%]
Jump threading and having util_format_description declared as const causes a
null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97122
--- Comment #5 from kargl at gcc dot gnu.org ---
(In reply to Paul Thomas from comment #3)
>
> I have marked this as "waiting" pending a contrary interpretation.
>
> Cheers
>
Paul,
I asked on the J3 mailing list about the code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109716
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |UNCONFIRMED
Ever confirmed|1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109714
--- Comment #4 from Andrew Pinski ---
What options are being used to compile this?
I cannot reproduce it on the trunk ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109716
--- Comment #2 from David Heidelberg (okias) ---
Created attachment 55001
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55001=edit
r300_state_derived.c.i.gz
Appending requested file. Thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109714
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |UNCONFIRMED
Ever confirmed|1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109714
--- Comment #3 from David Heidelberg (okias) ---
Created attachment 55000
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55000=edit
draw_draw_llvm.c.i.gz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109741
--- Comment #12 from Jakub Jelinek ---
(In reply to Jonathan Wakely from comment #11)
> > Perhaps it should at configure time check if such alignment is possible and
> > otherwise simply don't align it beyond mutex natural alignment?
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109733
Uroš Bizjak changed:
What|Removed |Added
Target Milestone|--- |14.0
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109733
--- Comment #4 from CVS Commits ---
The master branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:8cac23781753bd8a016507dc9b21ec563e1d9b49
commit r14-485-g8cac23781753bd8a016507dc9b21ec563e1d9b49
Author: Uros Bizjak
Date: Thu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109741
--- Comment #11 from Jonathan Wakely ---
(In reply to Jakub Jelinek from comment #9)
> I think it intentionally uses 64 rather than the controversial macros.
It's been there since before we had those macros. I think using the destructive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109741
--- Comment #10 from Jonathan Wakely ---
(In reply to Janez Zemva from comment #0)
> This line:
>
> struct alignas(64) M : __gnu_cxx::__mutex { };
>
> has been an eyesore for me for a number of years. I propose to change it
That belongs on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109738
--- Comment #1 from Andrew Pinski ---
clang has the same behavior as GCC .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109741
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109741
--- Comment #8 from Janez Zemva ---
Here is the compile error:
../../../../../gcc-13.1.0/libstdc++-v3/src/c++11/shared_ptr.cc: In function
'__gnu_cxx::__mutex& __gnu_internal::get_mutex(unsigned char)':
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109741
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-05-04
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109741
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109741
--- Comment #5 from Janez Zemva ---
This line has been patched out by djgpp builds for a long time now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109740
--- Comment #2 from Paul Smith ---
What I'm trying to say is that it's not useful (to me) for GCC to warn about
code that I could maybe write in the future but didn't actually write, and
which if I did write it would generate a compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97122
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109741
--- Comment #4 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Janez Zemva from comment #1)
> > alternatively, the line could be changed into:
> >
> > struct alignas(void*) M : __gnu_cxx::__mutex { };
> >
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109741
--- Comment #3 from Andrew Pinski ---
(In reply to Janez Zemva from comment #1)
> alternatively, the line could be changed into:
>
> struct alignas(void*) M : __gnu_cxx::__mutex { };
>
> since this was probably meant with the magic number 64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109741
--- Comment #2 from Andrew Pinski ---
I think it should really be either __GCC_DESTRUCTIVE_SIZE or
__GCC_CONSTRUCTIVE_SIZE (I always forgot which one it really).
>some targets do not support this alignment.
Which targets don't support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109741
--- Comment #1 from Janez Zemva ---
alternatively, the line could be changed into:
struct alignas(void*) M : __gnu_cxx::__mutex { };
since this was probably meant with the magic number 64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109741
Bug ID: 109741
Summary: alignas(64) in libstdc++-v3/src/c++11/shared_ptr.cc
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109729
Gaius Mulley changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109729
--- Comment #3 from CVS Commits ---
The master branch has been updated by Gaius Mulley :
https://gcc.gnu.org/g:ac7c9954ece9a75c5e7c3b76a4800f2432002487
commit r14-484-gac7c9954ece9a75c5e7c3b76a4800f2432002487
Author: Gaius Mulley
Date: Thu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109732
--- Comment #11 from Andrew Pinski ---
Created attachment 54999
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54999=edit
Patch which needs a message/changelog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52339
--- Comment #8 from joseph at codesourcery dot com ---
I think it's valid C99, yes: the VLA size should be evaluated exactly
once, when the declaration is passed in the order of execution.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109740
--- Comment #1 from Andrew Pinski ---
The warning is specifically designed this way and even is documented to warn.
https://gcc.gnu.org/onlinedocs/gcc-13.1.0/gcc/C_002b_002b-Dialect-Options.html#index-Woverloaded-virtual
It is designed this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109701
--- Comment #7 from Jakub Jelinek ---
That is not that surprising. As mentioned in the linked in PR99928, that
behavior is there only in OpenMP 5.0 and wasn't like that in OpenMP 4.5 and
earlier; in OpenMP 4.5
you really need separate target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109740
Bug ID: 109740
Summary: -Woverloaded-virtual is too aggressive
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109732
--- Comment #10 from Andrew Pinski ---
Created attachment 54998
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54998=edit
Gimple testcase that fails at runtime too
-O1 -fgimple -fdisable-tree-ethread -fdisable-tree-fre1
The thing is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109733
Uroš Bizjak changed:
What|Removed |Added
Attachment #54996|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109733
Uroš Bizjak changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
--- Comment #22 from Andrew Macleod ---
OK, I've finished with my analysis. There are multiple vectors of attack here,
and we should do them all. Some where already on my radar for this release
anyway, but this gives a nice tidy place to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
--- Comment #21 from David Binderman ---
Two cases, depending on the text of the warning:
$ fgrep warning: mk.out | fgrep Wstack | fgrep -v "might be unbounded" | fgrep
"usage is" | sort -rnk 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101780
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109701
--- Comment #6 from tommelt ---
Thank you.
Interestingly, I tried your suggestion:
"!$omp target teams distribute parallel do simd if(target:is_GPU)
reduction(max:max_diff) collapse(2)"
It works for gfortran v 12.2.0
but it does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
--- Comment #20 from David Binderman ---
(In reply to Jakub Jelinek from comment #17)
> Or just try to check for functions with largest stack usages in cc1plus?
> Doing that on the trunk gives:
> objdump -dr cc1plus | grep
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109739
Bug ID: 109739
Summary: bogus warning due to -Wmissing-field-initializers in
C++20 with designated initializers on struct with
empty base class
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109733
--- Comment #1 from Uroš Bizjak ---
The patched compiler just happens to trigger the existing problem where:
(insn 188 416 379 18 (parallel [
(set (reg:SI 72 k4 [orig:121 _114 ] [121])
(ashift:SI (reg:SI 70 k2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109738
Bug ID: 109738
Summary: C++20 implicit conversion is used during spaceship
operator resolution instead of class's operator< for
classes without spaceship operator
Product:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109703
Andrew Pinski changed:
What|Removed |Added
CC||enrico.seiler+gccbugs@outlo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109737
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109737
Bug ID: 109737
Summary: [13/14] Hitting unreachable code when using
std::string::assign with iterators
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #44 from qinzhao at gcc dot gnu.org ---
(In reply to Martin Uecker from comment #43)
> works with the bounds checking code? Does it also interact with the object
> size pass?
both array-bounds sanitizer and object size pass are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66005
Thomas Schwinge changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tschwinge at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #43 from Martin Uecker ---
Yes, this is great! I am also looking forward to your patch! It seems it works
with the bounds checking code? Does it also interact with the object size
pass?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109666
--- Comment #9 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jason Merrill
:
https://gcc.gnu.org/g:13a269a015f888a0001af7b9ab564fadbee4a808
commit r12-9511-g13a269a015f888a0001af7b9ab564fadbee4a808
Author: Jason Merrill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109666
Jason Merrill changed:
What|Removed |Added
Resolution|FIXED |---
Summary|[13/14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109732
--- Comment #9 from Martin Liška ---
I've got a C++ reduced test-case:
$ cat x.ii
template struct is_same;
template using enable_if_t = _Tp;
template struct reverse_iterator {
_Iterator current;
typedef _Iterator iterator_type;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109729
Gaius Mulley changed:
What|Removed |Added
CC||gaius at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109736
Bug ID: 109736
Summary: GCC Static Analyzer evaluates `e == d + 1` to be
UNKNOWN with the fact that `e == d`, e is a pointer,
and d is an array
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109063
Geoffrey changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109735
Martin Liška 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=109735
Bug ID: 109735
Summary: [14 Regression] ICE in vectorizable_store, at
tree-vect-stmts.cc:8529 since r14-322-g821ef93976e750
Product: gcc
Version: 14.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52339
--- Comment #7 from Jakub Jelinek ---
Created attachment 54994
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54994=edit
gcc14-pr52339.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109734
--- Comment #3 from Andrew Pinski ---
Also you read the assembly incorrectly. Aarch64 gcc is producing the simd cnt
instruction to do the popcount and not the scalar instruction. Arm(32) is doing
the call. I am not 100% sure but you should try
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109717
--- Comment #9 from Paul Smith ---
> Now they're issued even when the "problem" is in a system header.
Oh interesting: I have been in the habit of including all my 3rdparty library
headers using -isystem to avoid worrying about warnings/errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109734
--- Comment #2 from Andrew Pinski ---
Oh cssc feature support is only in gcc 13 and above too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109720
--- Comment #6 from Paul Smith ---
I'm happy to provide the source for DynamicBitSet (it's basically a union of a
uint64_t and a boost::dynamic_bitset so that if you have <=64 bits you use the
uint64_t and if you have >64 bits you use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109734
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53929
--- Comment #18 from LIU Hao ---
Would it make any sense to have GAS be more permissive about such labels,
1. unconditionally? or
2. when input is from a pipe? or
3. when a special option is in effect e.g. `--output-from-gcc`?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109734
Bug ID: 109734
Summary: ARM64 support for __builtin_popcountll
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98823
Peter Bergner changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109733
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2023-05-04
Summary|ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109733
Bug ID: 109733
Summary: ICE in extract_insn, at recog.cc:2791 since
r14-475-g508f082829af68
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106484
--- Comment #4 from rsaxvc at gmail dot com ---
Benchmarking shows the speedup to be highly variable depending on CPU core as
well as __aeabi_uldivmod() implementation, and somewhat on numerator.
The best __aeabi_uldivmod()s I've seen do use
1 - 100 of 221 matches
Mail list logo
