https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102435
Andrew Pinski changed:
What|Removed |Added
Known to fail|9.4.1 |9.3.0
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99689
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78685
Andrew Pinski changed:
What|Removed |Added
CC||lukas.graetz@tu-darmstadt.d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114144
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112325
--- Comment #14 from Hongtao Liu ---
(In reply to rguent...@suse.de from comment #13)
> On Tue, 27 Feb 2024, liuhongt at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112325
> >
> > --- Comment #11 from Hongtao Liu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99689
--- Comment #7 from Andrew Pinski ---
GCC 9.3.0 says:
/app/example.cpp:19:18: missed: can't use a fully-masked loop because the
target doesn't have the appropriate masked load or store.
/app/example.cpp:19:18: note: vect_model_load_cost: alig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114144
Bug ID: 114144
Summary: Variables optimized out by -Og
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109254
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99092
Andrew Pinski changed:
What|Removed |Added
See Also||https://github.com/llvm/llv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99092
--- Comment #15 from Andrew Pinski ---
(In reply to Iain Sandoe from comment #14)
> (In reply to Andrew Pinski from comment #13)
> > Did the LLVM assembler get fixed?
>
> not as of xcode 13.0 (I don't know if anyone filed a radar tho) - since th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114130
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-02-28
Target|riscv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114143
Bug ID: 114143
Summary: Non-thumb arm32 code in thumb multilib for libgcc and
in -mthumb build
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114134
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114134
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
Summary|Extra mov instr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113960
--- Comment #12 from mfarca ---
I've applied the above patch directly to
`/usr/include/c++/12/bits/stl_algobase.h` under my fedora 36 env with gcc
12.2.1 and it solved the problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114141
--- Comment #2 from Jerry DeLisle ---
It looks like the 'selector' in this case is an expr.
The expr must be a pointer object or a 'designator'
A designator must be:
R901
designator
object-name
array-element
array-section
coindexed-named-obj
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114141
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114140
--- Comment #14 from Andrew Pinski ---
(In reply to g.peterhoff from comment #13)
> > The cppreference page is wrong.
> But then *all* of your implementations for fmin/fmax (float, double, long
> double, std::floatN_t) would be wrong, because th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114140
--- Comment #13 from g.peterh...@t-online.de ---
> The cppreference page is wrong.
But then *all* of your implementations for fmin/fmax (float, double, long
double, std::floatN_t) would be wrong, because they give exactly the results as
described
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99837
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
--- Comment #3 from kargl a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99837
kargl at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114140
Andrew Pinski changed:
What|Removed |Added
See Also||https://sourceware.org/bugz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114140
--- Comment #11 from Andrew Pinski ---
And see https://sourceware.org/bugzilla/show_bug.cgi?id=26045 .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114140
--- Comment #10 from Andrew Pinski ---
(In reply to g.peterhoff from comment #7)
> I think there is a misunderstanding. The problem is that std::fmin/std::fmax
> and quadmath fminq/fmaxq give different results when only *one* argument is
> signa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114140
Andrew Pinski changed:
What|Removed |Added
See Also||https://sourceware.org/bugz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114103
--- Comment #9 from dave.anglin at bell dot net ---
On 2024-02-27 9:32 a.m., redi at gcc dot gnu.org wrote:
> Patch posted:
> https://gcc.gnu.org/pipermail/gcc-patches/2024-February/646619.html
Caused build error:
libtool: compile: /home/dave/g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114140
--- Comment #8 from Andrew Pinski ---
(In reply to g.peterhoff from comment #7)
> I think there is a misunderstanding. The problem is that std::fmin/std::fmax
> and quadmath fminq/fmaxq give different results when only *one* argument is
> signal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114140
--- Comment #7 from g.peterh...@t-online.de ---
I think there is a misunderstanding. The problem is that std::fmin/std::fmax
and quadmath fminq/fmaxq give different results when only *one* argument is
signaling_NaN.
The standard (https://en.cppre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50597
g.peterh...@t-online.de changed:
What|Removed |Added
CC||g.peterh...@t-online.de
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87161
FeRD changed:
What|Removed |Added
CC||ferdnyc at gmail dot com
--- Comment #7 from FeRD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114013
--- Comment #4 from GCC Commits ---
The master branch has been updated by Nathaniel Shead :
https://gcc.gnu.org/g:615b62aada6cc42759e5c43e196dab6c524925d6
commit r14-9201-g615b62aada6cc42759e5c43e196dab6c524925d6
Author: Nathaniel Shead
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113970
--- Comment #5 from GCC Commits ---
The master branch has been updated by Nathaniel Shead :
https://gcc.gnu.org/g:615b62aada6cc42759e5c43e196dab6c524925d6
commit r14-9201-g615b62aada6cc42759e5c43e196dab6c524925d6
Author: Nathaniel Shead
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80755
--- Comment #6 from Lewis Hyatt ---
(In reply to Sam James from comment #5)
> Thank you Lewis!
>
> Would you mind pinging this again?
>
> I've just started hitting this on glibc systems too as we added a wrapper to
> a libbsd header (which I'm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #39 from Tom Tromey ---
(In reply to Lukas Grätz from comment #36)
> > #2 0x004011d2 in baz (a=a@entry=42, b=b@entry=43, c=c@entry=44,
> > d=,
> > e=, f= > reading variable: value has been optimized out>, g=48, h=49) at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80755
--- Comment #5 from Sam James ---
Thank you Lewis!
Would you mind pinging this again?
I've just started hitting this on glibc systems too as we added a wrapper to a
libbsd header (which I'm probably going to have to drop for now).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114142
--- Comment #1 from Andrew Pinski ---
>In 13.2 this is a rejects-valid.
It might be only ICEing when checking is turned on which it is for the trunk
(normally).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114142
Bug ID: 114142
Summary: [coroutines]: internal compiler error: tree check:
expected record_type or union_type or qual_union_type,
have reference_type in lookup_base, at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114140
--- Comment #6 from Andrew Pinski ---
So with `-fsignaling-nans` we don't constant fold fmin*/fmax* any more.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114140
--- Comment #5 from Jakub Jelinek ---
At least on the godbolt link, if I add -fsignaling-nans option, it prints
inf/inf/nan/nan for both types.
So, in that case it looks like a non-bug to me.
fmaxq/fminq get the same behavior regardless of the o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114140
Andrew Pinski changed:
What|Removed |Added
Summary|quadmath fminq/fmaxq with |fmin/fmax with
|signa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114140
Andrew Pinski changed:
What|Removed |Added
Component|libquadmath |middle-end
--- Comment #3 from Andrew P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111802
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110483
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66487
--- Comment #27 from Eric Gallager ---
(In reply to Alexander Monakov from comment #26)
> RFC patch for detecting lifetime-dse issues via Valgrind (rather than MSan):
> https://inbox.sourceware.org/gcc-patches/20231024141124.210708-1-exactl...@is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114140
--- Comment #2 from Joseph S. Myers ---
Returning a quiet NaN when either argument is a signaling NaN is correct at
least for C (fmin/fmax correspond to IEEE 754-2008 operations, *not* the new
IEEE 754-2019 operations which are
fminimum/fmaximum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111802
--- Comment #3 from GCC Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:939439a90f234f9e70d30240bf5c227eebe2b43f
commit r14-9199-g939439a90f234f9e70d30240bf5c227eebe2b43f
Author: David Malcolm
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110483
--- Comment #3 from GCC Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:939439a90f234f9e70d30240bf5c227eebe2b43f
commit r14-9199-g939439a90f234f9e70d30240bf5c227eebe2b43f
Author: David Malcolm
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114140
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114141
Bug ID: 114141
Summary: ASSOCIATE and complex part ref when associate target
is a function
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114140
Bug ID: 114140
Summary: quadmath fminq/fmaxq with signaling_NaN not work
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112868
Peter Bergner changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114103
--- Comment #8 from dave.anglin at bell dot net ---
On 2024-02-27 9:32 a.m., redi at gcc dot gnu.org wrote:
> Patch posted:
> https://gcc.gnu.org/pipermail/gcc-patches/2024-February/646619.html
Will test on hppa64-hp-hpux11.11 on my next build.
ith-ld=/usr/bin/riscv64-unknown-linux-gnu-ld
--with-as=/usr/bin/riscv64-unknown-linux-gnu-as --disable-multilib
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-9189-20240227001746-g1e2a3b278d7-checking-yes-rtl-df-extra-riscv64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240227 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94083
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-02-27
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114131
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94083
Andrew Pinski changed:
What|Removed |Added
CC||g.peterh...@t-online.de
--- Comment #1 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113742
--- Comment #4 from Zdenek Sojka ---
I can confirm the supplied testcase no longer fails.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114138
Patrick Palka changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114131
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
--- Comment #1 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98877
Richard Sandiford changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114137
--- Comment #5 from Sam James ---
I also now believe I've seen this on sparc with ncurses with
-fharden-control-flow-redundancy...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114137
--- Comment #4 from Sam James ---
I have another testcase where it works with -save-temps or the GC params.
bibtexu-3.71_p20210325:
```
# i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -DUNIX -DKPATHSEA
-DU_DISABLE_RENAMING=1 -I/usr/include -DUT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106146
--- Comment #3 from Andrew Pinski ---
So I see svadd_z directly emits the instruction, not leaving any way to
optimize away the _z part before hand.
I am not sure how to fix this though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114041
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114041
--- Comment #8 from Jakub Jelinek ---
Ah, but
unsigned a[24], b[24];
enum E { E0 = 0, E1 = 1, E42 = 42, E56 = 56 };
__attribute__((noipa)) unsigned
foo (enum E x)
{
for (int i = 0; i < 24; ++i)
a[i] = i;
unsigned e;
if (x >= E42)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114137
--- Comment #3 from Sam James ---
==16482== Command: /usr/libexec/gcc/i686-pc-linux-gnu/14/cc1 -quiet -I . -I
./src -D PACKAGE_NAME="lua5.4" -D PACKAGE_TARNAME="lua" -D
PACKAGE_VERSION="5.4.6" -D PACKAGE_STRING="lua5.4\ 5.4.6" -D
PACKAGE_BUGREPO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114137
--- Comment #2 from Sam James ---
The bug is very reproducible with the original command, but...
I can't reproduce it with the preprocessed source or with -save-temps on the
original command line, but pinskia suggested I try --param=ggc-min-exp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #38 from Lukas Grätz ---
(In reply to Jakub Jelinek from comment #37)
> Nowhere, just run and when it stops due to abort, just up several times
> until reaching the appropriate frame.
I see, this gives me:
(gdb) frame 4
#4 0x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114041
--- Comment #7 from Jakub Jelinek ---
There is just INTEGER_TYPE test in all graphite*, so
2024-02-27 Jakub Jelinek
PR tree-optimization/114041
* graphite-sese-to-poly.cc (add_conditions_to_domain): Handle
BITINT_TYPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114138
Bug ID: 114138
Summary: [c++2b] ICE on valid code using `auto(expr)`
DECAY-COPY
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114135
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114137
--- Comment #1 from Sam James ---
Created attachment 57553
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57553&action=edit
lvm.i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114137
Bug ID: 114137
Summary: ICE when building lua-5.4.6 with
-fharden-control-flow-redundancy on x86 (error:
invalid rtl sharing found in the insn)
Product: gcc
Vers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113871
--- Comment #8 from GCC Commits ---
The master branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:15d1dae0d4d1be88d28ad7578a60fd3e36de36d8
commit r14-9198-g15d1dae0d4d1be88d28ad7578a60fd3e36de36d8
Author: Uros Bizjak
Date: Tue F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113768
Gaius Mulley changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114136
Andrew Pinski changed:
What|Removed |Added
Keywords||testsuite-fail
--- Comment #1 from Andr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114136
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114136
Bug ID: 114136
Summary: wrong code for c23 fully anonymous arg lists on arm
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #37 from Jakub Jelinek ---
Nowhere, just run and when it stops due to abort, just up several times until
reaching the appropriate frame.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #36 from Lukas Grätz ---
(In reply to Jakub Jelinek from comment #35)
> If I hand edit the gcc trunk + PR114116 patch assembly, add to bar
> + .cfi_undefined 3
> + .cfi_undefined 12
> + .cfi_undefined 13
> + .cfi_undef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114041
--- Comment #6 from Jakub Jelinek ---
unsigned a[24], b[24];
__attribute__((noipa)) unsigned
foo (unsigned char x)
{
for (int i = 0; i < 24; ++i)
a[i] = i;
unsigned e = __builtin_stdc_bit_ceil (x);
for (int i = 0; i < 24; ++i)
b[i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114135
Bug ID: 114135
Summary: Diagnostic missing useful information for ranges code
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114041
--- Comment #5 from Jakub Jelinek ---
Reduced testcase:
unsigned a[24], b[24];
__attribute__((noipa)) unsigned
foo (unsigned _BitInt(4) x)
{
for (int i = 0; i < 24; ++i)
a[i] = i;
unsigned e = __builtin_stdc_bit_ceil (x);
for (int i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114013
--- Comment #3 from Enrico Seiler ---
For -O0 and -O1, this also does not link:
template int value;
template <> inline int value<1>;
void bar(int) { bar(value<1>); }
https://godbolt.org/z/Wxv7PE8ob
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101443
Rafi Wiener changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #14 from Rafi Wiener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114133
--- Comment #3 from Gaius Mulley ---
At a guess the problem was the ZTyped constant (1 and 5). Now the gimple IR
shows these constants as integers:
$ cat callingc10.mod.095i.comdats
PROC _M2_callingc10_init (INTEGER argc, PROC * argv, PROC * e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114134
Bug ID: 114134
Summary: Extra mov instructions for simple function compared
with GCC13
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114133
--- Comment #2 from Gaius Mulley ---
Created attachment 57552
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57552&action=edit
Query proposed fix
Does this patch fix the problem?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114121
--- Comment #14 from Jakub Jelinek ---
Tried
__attribute__((noipa)) unsigned long
foo (unsigned long x)
{
unsigned long y[128], z = 0, w = 0;
y[127] = x;
__builtin_memset (&y, 0, 127 * sizeof (long));
for (unsigned long i = 0; i < 128;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114133
Gaius Mulley changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799
--- Comment #31 from Peter Bergner ---
(In reply to Jakub Jelinek from comment #30)
> Either tree parmdef = ssa_default_def (cfun, parm) is NULL, or has_zero_uses
> (parmdef).
> Not sure if has_zero_uses will work properly after some bbs are con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110411
Jeevitha changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110320
Jeevitha changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106907
Jeevitha changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89863
Bug 89863 depends on bug 106907, which changed state.
Bug 106907 Summary: gcc/config/rs6000/rs6000.cc:23155: strange expression ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106907
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114026
Gaius Mulley changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114133
Bug ID: 114133
Summary: problem passing a string pointer to a C function on
solaris 32 bit and 64 bit
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113960
--- Comment #11 from Jonathan Wakely ---
--- a/libstdc++-v3/include/bits/stl_algobase.h
+++ b/libstdc++-v3/include/bits/stl_algobase.h
@@ -1824,11 +1824,14 @@ _GLIBCXX_BEGIN_NAMESPACE_ALGO
}
#if __cpp_lib_three_way_comparison
- // Iter p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113960
--- Comment #10 from Jonathan Wakely ---
Oh I already defined a __is_memcmp_ordered_with trait, which does the same-size
check. I think that's what should be used here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113960
--- Comment #9 from Stefan Schulze Frielinghaus
---
(In reply to Jonathan Wakely from comment #7)
> We can't use memcmp if the sizes are different. We don't want to use the
> min, we want to guard that code with the sizes being the same, then w
1 - 100 of 173 matches
Mail list logo
