https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114820
Bug ID: 114820
Summary: Gcov 11.4.0 .gcda:stamp mismatch with notes file
Product: gcc
Version: 11.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114821
Bug ID: 114821
Summary: _M_realloc_append should use memcpy instead of loop to
copy data when possible
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114676
--- Comment #17 from GCC Commits ---
The master branch has been updated by Andreas Krebbel :
https://gcc.gnu.org/g:42189f21b22c43ac8ab46edf5f6a7b4d99bc86a5
commit r14-10087-g42189f21b22c43ac8ab46edf5f6a7b4d99bc86a5
Author: Andreas Krebbel
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114799
--- Comment #8 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:18e8e55487238237f37f621668fdee316624981a
commit r14-10088-g18e8e55487238237f37f621668fdee316624981a
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114799
Richard Biener changed:
What|Removed |Added
Priority|P1 |P2
Summary|[14 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114820
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114751
--- Comment #4 from Andrew Pinski ---
*** Bug 114820 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114821
--- Comment #1 from Jonathan Wakely ---
Using memcpy on any std::pair is undefined behaviour because it's not trivially
copyable.
That's not because it has a copy constructor, its copy constructor is defaulted
and so trivial if the data member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114416
--- Comment #12 from Eric Botcazou ---
Rainer, what's your take on this? Should we proceed and change the ABI on
Solaris for GCC 14?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114821
--- Comment #2 from Jan Hubicka ---
What I am shooting for is to optimize it later in loop distribution. We can
recognize memcpy loop if we can figure out that source and destination memory
are different.
We can help here with restrict, but I w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105359
Kewen Lin changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102597
--- Comment #4 from GCC Commits ---
The master branch has been updated by Paul Thomas :
https://gcc.gnu.org/g:ca00bf02dcc37f9ff1028ca1d90e8b8d95d69683
commit r14-10089-gca00bf02dcc37f9ff1028ca1d90e8b8d95d69683
Author: Paul Thomas
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114739
Paul Thomas changed:
What|Removed |Added
Summary|[14 Regression] ice in |Ensure no IMPLICIT type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114822
Bug ID: 114822
Summary: ldist should produce memcpy/memset/memmove histograms
based on loop information converted
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112407
Paul Thomas changed:
What|Removed |Added
Summary|[13/14 Regression] Fix for |[13 Regression] Fix for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110987
Paul Thomas changed:
What|Removed |Added
Summary|[13/14 Regression] |[13 Regression]
|Segmen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106999
Paul Thomas changed:
What|Removed |Added
Summary|[11/12/13/14 Regression]|[11/12/13 Regression] ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71703
Paul Thomas changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114823
Bug ID: 114823
Summary: Missed optimization of redundant loops
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-opti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114824
Bug ID: 114824
Summary: gcc doesn't respect
__attribute__((zero_call_used_regs("used"))) when
performing a tail call optimization
Product: gcc
Version: 14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114821
--- Comment #3 from Jonathan Wakely ---
(In reply to Jan Hubicka from comment #2)
> This seems to do the trick, but for some reason I get memmove
What's the second overload for, and why does it depend on _GLIBCXX_HOSTED?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114751
--- Comment #5 from Gejoe ---
(In reply to Gejoe from comment #2)
> For me, it is like this (just keeping the sample filenames as such but the
> values are real ones shown while checking with gcov-dump) :
>
> $gcov-dump ./obj-dir-path/src-file.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114821
--- Comment #4 from Jonathan Wakely ---
(In reply to Jan Hubicka from comment #2)
> --- a/libstdc++-v3/include/bits/stl_uninitialized.h
> +++ b/libstdc++-v3/include/bits/stl_uninitialized.h
> @@ -1130,7 +1130,58 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114821
--- Comment #5 from Jonathan Wakely ---
If the problem is simply that the __restrict qualifiers are not present because
we go through the generic function taking iterators, then we can just add:
--- a/libstdc++-v3/include/bits/stl_uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114416
--- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #12 from Eric Botcazou ---
> Rainer, what's your take on this? Should we proceed and change the ABI on
> Solaris for GCC 14?
I think so, yes:
* Binary compatibility wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114816
--- Comment #1 from Joseph S. Myers ---
Note that it's not possible to define a function with such parameters ("After
adjustment, the parameters in a parameter type list in a function declarator
that is part of a definition of that function shal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114821
--- Comment #6 from Jan Hubicka ---
Thanks. I though the relocate_a only cares about the fact if the pointed-to
type can be bitwise copied. It would be nice to early produce memcpy from
libstdc++ for std::pair, so the second patch makes sense t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114810
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114821
--- Comment #7 from Jonathan Wakely ---
Created attachment 58014
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58014&action=edit
Make std::pair relocatable and simplify __relocate_a
Does this help?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114821
--- Comment #8 from Jan Hubicka ---
I had wrong noexcept specifier. This version works, but I still need to inline
relocate_object_a into the loop
diff --git a/libstdc++-v3/include/bits/stl_uninitialized.h
b/libstdc++-v3/include/bits/stl_unini
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114821
--- Comment #9 from Jan Hubicka ---
Your patch gives me error compiling testcase
jh@ryzen3:/tmp> ~/trunk-install/bin/g++ -O3 ~/t.C
In file included from /home/jh/trunk-install/include/c++/14.0.1/vector:65,
from /home/jh/t.C:1:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114821
--- Comment #10 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #7)
> Created attachment 58014 [details]
> Make std::pair relocatable and simplify __relocate_a
>
> Does this help?
Oh hang on, that patch is wrong. I'll fix it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114810
--- Comment #14 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #13)
> Created attachment 58013 [details]
> gcc14-pr114810.patch
>
> So like this? Tried hard to reduce the testcase, but it didn't progress at
> all, so at least tri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114821
Jonathan Wakely changed:
What|Removed |Added
Attachment #58014|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114825
Bug ID: 114825
Summary: Compiler error using gfortran and OpenMP
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111475
Rainer Orth changed:
What|Removed |Added
Summary|Many C++ analyzer tests |[14 regression] Many C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114790
--- Comment #12 from Sam James ---
Created attachment 58017
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58017&action=edit
tracing_imp.cpp.ii-reduced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114790
--- Comment #13 from Sam James ---
Created attachment 58018
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58018&action=edit
tracing_copy_imp.cpp.ii-reduced
Attached another attempt...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114825
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101666
--- Comment #9 from GCC Commits ---
The releases/gcc-11 branch has been updated by Iain D Sandoe
:
https://gcc.gnu.org/g:87431b4a81e9dc5988509399704a7352800c6a77
commit r11-11339-g87431b4a81e9dc5988509399704a7352800c6a77
Author: Iain Sandoe
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101666
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114825
--- Comment #2 from Tobias Burnus ---
The difference between the failing program and a working program
(pointer-assignment in 'sub' comment out) is:
failing:
'type' in gfc_omp_clause_default_ctor is '
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114825
--- Comment #3 from Jakub Jelinek ---
Yes, and the reason for that is that while in
subroutine pr114825(b)
type t
real, allocatable :: m(:)
end type t
type(t), allocatable, target :: b(:)
type(t), pointer :: d
!$omp parallel privat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114826
Bug ID: 114826
Summary: Bogus -Warray-bounds warning for 32-byte array with
certain march flags
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114826
Andrew Pinski changed:
What|Removed |Added
Component|c |tree-optimization
Blocks|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114823
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114821
Jonathan Wakely changed:
What|Removed |Added
Attachment #58015|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114826
--- Comment #2 from Richard Biener ---
Rather store merging I guess.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114795
Patrick Palka changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736
--- Comment #33 from GCC Commits ---
The releases/gcc-12 branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:61d1962e7c3c32da6962d9cb20f6fd996501f3f2
commit r12-10387-g61d1962e7c3c32da6962d9cb20f6fd996501f3f2
Author: Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736
--- Comment #34 from GCC Commits ---
The releases/gcc-12 branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:e89b5ed62a5a06fb8918ffa1616f0f37c8d359c3
commit r12-10388-ge89b5ed62a5a06fb8918ffa1616f0f37c8d359c3
Author: Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736
--- Comment #36 from GCC Commits ---
The releases/gcc-12 branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:48fd1c5791b47717dcd4fa5615bc07cf54e964a7
commit r12-10390-g48fd1c5791b47717dcd4fa5615bc07cf54e964a7
Author: Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736
--- Comment #35 from GCC Commits ---
The releases/gcc-12 branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:d6c62e4fb9a6d395599b7c78c831bace4bc7ff8f
commit r12-10389-gd6c62e4fb9a6d395599b7c78c831bace4bc7ff8f
Author: Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111475
Rainer Orth changed:
What|Removed |Added
Last reconfirmed||2024-04-23
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114827
Bug ID: 114827
Summary: Valgrind reports errors with class(*) assignment
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114827
--- Comment #1 from Neil Carlson ---
I should add that I get the same results with gcc versions going back to at
least gcc 11.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114826
Andrew Pinski changed:
What|Removed |Added
Summary|Bogus -Warray-bounds|[13 Regression] Bogus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114826
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114795
--- Comment #8 from GCC Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:4f9401d1a802325e5dfa2db841945e1a9c59a980
commit r14-10096-g4f9401d1a802325e5dfa2db841945e1a9c59a980
Author: Patrick Palka
Date:
ompression algorithms: zlib
gcc version 14.0.1 20240423 (experimental) (GCC)
[577] %
[577] % gcctk -c -O1 -ftree-pre -fselective-scheduling -fsel-sched-pipelining
-fschedule-insns small.c
during RTL pass: sched1
small.c: In function ‘f’:
small.c:14:1: internal compiler error: Segmentation f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114795
--- Comment #9 from Patrick Palka ---
The "invalid conversion in return statement" error should hopefully be fixed
now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103496
--- Comment #6 from GCC Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:0bf94da59feab2c72a02c91df310a36d33dfd1f7
commit r14-10097-g0bf94da59feab2c72a02c91df310a36d33dfd1f7
Author: Harald Anlauf
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103496
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114817
--- Comment #1 from Arthur O'Dwyer ---
Yes, vector reallocation has analogous trouble with types that are "trivial,
but not trivially copy constructible."
https://godbolt.org/z/Psboqf3MP
(libc++ happens to sidestep this pitfall *on Clang 15+,*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114820
--- Comment #2 from Gejoe ---
(In reply to Andrew Pinski from comment #1)
> .
>
> *** This bug has been marked as a duplicate of bug 114751 ***
OK, looks like that bug is not being looked at for further replies. Let me know
if any info is soug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114828
H.J. Lu changed:
What|Removed |Added
Ever confirmed|0 |1
Version|unknown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114828
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
--- Comment #2 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98426
Matt Thompson changed:
What|Removed |Added
CC||matthew.thompson at nasa dot
gov
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114810
--- Comment #15 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:628c2221d38715a64f828e3635317293d150e001
commit r14-10099-g628c2221d38715a64f828e3635317293d150e001
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114810
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84849
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113300
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114829
Bug ID: 114829
Summary: No fcsel produced for f16
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98426
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98477
--- Comment #5 from Andrew Pinski ---
So adding the `r` alternative to *cmov_insn (GPF) works kinda of but then
we seem to have a register allocation issue.
Even this still causes FPREGS from being chosen:
```
void
foo (int a, double *b)
{
dou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114830
Bug ID: 114830
Summary: c++filt stack overflows in rust demangler
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: dem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114830
--- Comment #1 from Alan Modra ---
Created attachment 58020
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58020&action=edit
asan report summary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114830
--- Comment #2 from Alan Modra ---
Created attachment 58021
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58021&action=edit
c++filt crash binaries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114831
Bug ID: 114831
Summary: typeof doesn't evaluate expression when it has
variably modified type in some cases
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Seve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114723
--- Comment #4 from Andrew Pinski ---
(In reply to Halalaluyafail3 from comment #3)
> Just tested on godbolt again
Oh this is with `-g -std=c23`, godbolt has an implicit -g.
Anyways here is the ICE:
: In function 'main':
:11:1: error: 'TYPE_C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114723
--- Comment #3 from Halalaluyafail3 ---
Just tested on godbolt again and it cause an ICE, so perhaps something was
changed to cause an ICE again. Also upon thinking about the implications of
these types being compatible they probably shouldn't b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114723
Andrew Pinski changed:
What|Removed |Added
Depends on||114014
--- Comment #5 from Andrew Pinsk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98426
Jerry DeLisle changed:
What|Removed |Added
Last reconfirmed||2024-04-24
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114723
--- Comment #6 from Halalaluyafail3 ---
(In reply to Andrew Pinski from comment #4)
> Oh this is with `-g -std=c23`, godbolt has an implicit -g.
I was not aware of this, thanks for letting me know. Do you know of any way to
disable it? Also it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114723
--- Comment #7 from Andrew Pinski ---
(In reply to Halalaluyafail3 from comment #6)
> (In reply to Andrew Pinski from comment #4)
> > Oh this is with `-g -std=c23`, godbolt has an implicit -g.
>
> I was not aware of this, thanks for letting me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98426
--- Comment #8 from Jerry DeLisle ---
Martin or Matt,
Can you test the following variation to see if you get better results.
return st;
}
retval = NULL;
if (c <= 0)
retval = find_symbol (st->left, name, module, generic);
del: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.1 20240423 (experimental) (GCC)
[516] %
[516] % gcctk -c -O2 -fno-tree-loop-if-convert
-fno-tree-loop-distribute-patterns -ftree-vectorize small.c
small.c: In function ‘e’:
small.c:2:6: error: dominator of 6 should be 13, not 5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114827
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114832
Andrew Pinski changed:
What|Removed |Added
Summary|ICE at -O{2,3} with |[14 Regression] ICE at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114832
--- Comment #2 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> Confirmed. ICE does not happen with -fno-checking so adding ice-checking.
Also GCC 13.2.0 didn't ICE with -fchecking either.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114817
Jiang An changed:
What|Removed |Added
CC||de34 at live dot cn
--- Comment #2 from Jian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114832
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114830
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #3 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114751
--- Comment #6 from Richard Biener ---
I have no idea why the values differ but I suspect the copying since we seem to
use the file modification time at some point. As a workaround I would suggest
to binary-patch one of the file to make the sta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114833
Bug ID: 114833
Summary: --suggest-attribute=returns_nonnull misdiagnoses
functions with __attribute__((nonnull))
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98477
--- Comment #6 from Andrew Pinski ---
here is a testcase for the fcsel usage for integer:
```
void
foo (int a, double *b)
{
double t = a ? 1.0 : 200.0;
register double tt __asm__("x0");
tt = t;
asm("":"+r"(tt));
*b = tt;
}
```
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98477
--- Comment #7 from Andrew Pinski ---
here is a testcase for the fcsel usage for integer cmov:
```
void
foo (int a, int *b)
{
int t = a ? 11 : 22;
register int tt __asm__("s0");
tt = t;
asm("":"+w"(tt));
*b = tt;
}
```
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114787
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=98477
--- Comment #8 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #7)
> here is a testcase for the fcsel usage for integer cmov:
A slightly better example where there is no use of inline-asm or forcing to
specific registers:
```
#def
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98477
--- Comment #9 from Andrew Pinski ---
Created attachment 58022
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58022&action=edit
Patch which I tested
I still need to add the testcases and finish up the commit message and
changelogs. I will
1 - 100 of 101 matches
Mail list logo
