https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108495
Dmitry Antipov changed:
What|Removed |Added
CC||dantipov at cloudlinux dot com
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108495
--- Comment #4 from Jakub Jelinek ---
Why? You shouldn't use the builtins directly, they are implementation detail
for implementing the intrinsics and the intrinsics don't suffer ever from this
problem
because they ensure the correct target opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108495
--- Comment #5 from Dmitry Antipov ---
# cat t-rand.c
#include
#include
int main(int argc, char *argv[]) {
uint64_t v;
__rndr(&v);
return 0;
}
# gcc t-rand.c
In file included from t-rand.c:2:
/usr/lib/gcc/aarch64-redhat-linux/12/incl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108495
--- Comment #6 from Jakub Jelinek ---
That message indeed could at least print the diff between the target options of
the caller and callee as a follow-up note.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108495
--- Comment #7 from ktkachov at gcc dot gnu.org ---
Yes, GCC could be more helpful here. The intrinsics and their use is documented
in the ACLE document:
https://github.com/ARM-software/acle/blob/main/main/acle.md#random-number-generation-intrins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108511
Martin Liška changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
Su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108511
Martin Liška changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108449
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
See
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87512
--- Comment #4 from Guo Youtao ---
Created attachment 54340
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54340&action=edit
the preprocessed file generated by g++-11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87512
--- Comment #5 from Guo Youtao ---
This bug can still be triggered in gcc-11 and gcc-12.
Here are the codes (the preprocessed file is attached)
```
#include
#include
template
constexpr auto is_pointer_v = std::is_pointer::value;
template
a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108514
Martin Liška changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108508
Martin Liška changed:
What|Removed |Added
Ever confirmed|0 |1
Keywords|needs-bisection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108536
Bug ID: 108536
Summary: Difference when using requires and enable_if with
class constructor
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84764
Daniel Lundin changed:
What|Removed |Added
CC||daniel.lundin.mail at gmail
dot co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108527
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108498
--- Comment #25 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:617be7ba436bcbf9d7b883968c6b3c011206b56c
commit r13-5342-g617be7ba436bcbf9d7b883968c6b3c011206b56c
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108511
--- Comment #3 from Richard Biener ---
Hmm,
make check-g++ RUNTESTFLAGS="--target_board=unix/\{,-m32\} lto.exp=pr88049_0.C"
works just fine for me?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108523
--- Comment #10 from Richard Biener ---
We don't converge:
Predication says _347 and _346 are equal on edge 108 -> 20
Setting value number of g_6_lsm.126_456 to _346 (changed)
Iterating to 25 BB20
...
Setting value number of g_6_lsm.126_456 to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93090
--- Comment #6 from Jonathan Wakely ---
Can this be closed now?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108511
--- Comment #4 from Martin Liška ---
Yeah, the test is normally run with -r argument, so just run it with;
g++ /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/lto/pr88049_0.C -flto
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/lto/pr88049
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108537
Bug ID: 108537
Summary: constexpr UB pointer dereference compiles if the
dereferenced value is not used
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108498
Jakub Jelinek changed:
What|Removed |Added
Summary|[11/12/13 Regression] ppc64 |[11/12 Regression] ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84764
--- Comment #4 from Jonathan Wakely ---
(In reply to Daniel Lundin from comment #3)
> gcc behaves just like required too, since `__int128` ought to be one of the
> extended integer types and it is signed.
But it's not an extended integer type, s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108536
--- Comment #1 from Jonathan Wakely ---
This is not a bug, you've just transformed your working code to use a
requires-clause incorrectly.
This works fine:
template >
requires (!std::derived_from)
&& std::construct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93090
--- Comment #7 from John Paul Adrian Glaubitz ---
(In reply to Jonathan Wakely from comment #6)
> Can this be closed now?
Yes.
I think there is still some money in the Bountysource campaign, not sure what
will happen with it. I'll contact them
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108523
--- Comment #11 from Richard Biener ---
So the issue is that we oscillate between recognizing the PHI as degenerate
because of an equivalence recorded on the non-backedge(!) to the backedge value
which in turn changes because of this change:
Va
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108536
--- Comment #2 from hr.jonas.hansen at gmail dot com ---
I can see that, and that would work. But it really seems like a work-around? Is
there a reason for the difference in behavior?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93090
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108536
--- Comment #3 from Jonathan Wakely ---
Because a requires-clause is not just different syntax for enable_if, it works
differently. Different things are different.
If you want exactly the same behaviour as your enable_if version (which you
did
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108538
Bug ID: 108538
Summary: unexpected -Wnarrowing errors in -fpermissive mode
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108511
Richard Biener changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108511
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108538
--- Comment #1 from Andreas Schwab ---
It depends on the selected C++ standard. C++11 does not allow narrowing
conversions unconditionally.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108523
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108538
--- Comment #2 from Stas Sergeev ---
(In reply to Andreas Schwab from comment #1)
> It depends on the selected C++ standard. C++11 does not allow narrowing
> conversions unconditionally.
Yes, I am not disputing that.
But I used -fpermissive mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108523
--- Comment #13 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:c29d85359add807200a1a851026b4e4a9d6b714c
commit r13-5348-gc29d85359add807200a1a851026b4e4a9d6b714c
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108523
--- Comment #14 from Richard Biener ---
Fixed, but I'll see if somebody comes up with a reduced testcase.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107952
--- Comment #12 from Siddhesh Poyarekar ---
(In reply to qinzhao from comment #7)
> (In reply to Richard Biener from comment #1)
> > GCC considered this as a flex-array.
>
> do you mean for the following example:
>
> typedef struct {
> char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104234
Patrick Palka changed:
What|Removed |Added
Ever confirmed|0 |1
Assignee|unassigned at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107792
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108539
Bug ID: 108539
Summary: Wrong register usage for -m16 -masm=intel -march=i386
on asm volatile
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108539
--- Comment #1 from arheik at dnainternet dot net ---
Reproduced with these:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108539
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108503
--- Comment #3 from Jakub Jelinek ---
Created attachment 54341
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54341&action=edit
gcc13-pr108503.patch
This hack works around it, by pretending the VAR_DECLs don't have
DECL_VALUE_EXPR between
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108525
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:9d4c00cdaccc3decd07740e817387ce844ef3ac9
commit r13-5372-g9d4c00cdaccc3decd07740e817387ce844ef3ac9
Author: Jakub Jelinek
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108525
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105549
--- Comment #6 from CVS Commits ---
The releases/gcc-10 branch has been updated by Christophe Lyon
:
https://gcc.gnu.org/g:fea013065580084578b1b78d8f727c0323f2a9a0
commit r10-11174-gfea013065580084578b1b78d8f727c0323f2a9a0
Author: Christophe L
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105549
--- Comment #7 from CVS Commits ---
The releases/gcc-11 branch has been updated by Christophe Lyon
:
https://gcc.gnu.org/g:d7f8b1c54bd054d214a73d4b534d599365f8658b
commit r11-10485-gd7f8b1c54bd054d214a73d4b534d599365f8658b
Author: Christophe L
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105549
--- Comment #8 from CVS Commits ---
The releases/gcc-12 branch has been updated by Christophe Lyon
:
https://gcc.gnu.org/g:f593bfa059fbd2c145d8dd2bae4860959e9e55fe
commit r12-9067-gf593bfa059fbd2c145d8dd2bae4860959e9e55fe
Author: Christophe Ly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108538
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2023-01-25
Status|UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105549
Christophe Lyon changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107424
--- Comment #10 from Tobias Burnus ---
> now filed as PR middle-end/108459.
This has been fixed to mainline. Cross ref: also about collapsed loops but
otherwise unrelated: PR middle-end/108435 (loop-var with function nesting
issue)
* * *
Pat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107952
--- Comment #13 from Qing Zhao ---
> On Jan 25, 2023, at 2:32 AM, rguenther at suse dot de
> wrote:
>>
>> A little confused here:
>>when the structure with a trailing flexible-array member is a middle
>> field of
>>an outer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108182
--- Comment #19 from CVS Commits ---
The master branch has been updated by Iain D Sandoe :
https://gcc.gnu.org/g:80cf2c5e8f496bed9c6facf55f9ae31d0d90fd28
commit r13-5373-g80cf2c5e8f496bed9c6facf55f9ae31d0d90fd28
Author: Iain Sandoe
Date: Mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102343
--- Comment #4 from CVS Commits ---
The master branch has been updated by Iain D Sandoe :
https://gcc.gnu.org/g:80cf2c5e8f496bed9c6facf55f9ae31d0d90fd28
commit r13-5373-g80cf2c5e8f496bed9c6facf55f9ae31d0d90fd28
Author: Iain Sandoe
Date: Mon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102343
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108182
Iain Sandoe changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108540
Bug ID: 108540
Summary: [13 Regression] Frange miscompilation of ruby since
r13-3261
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108540
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107952
--- Comment #14 from Siddhesh Poyarekar ---
(In reply to Qing Zhao from comment #13)
> >
> > The first is handled by the function just fine,
>
> No, even the first case is not recognized by the current
> “array_ref_flexible_size_p”, it’s not b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108519
--- Comment #1 from Alexander Monakov ---
We diverge in sched1 due to extra calls to advance_one_cycle when scheduling a
BB that is empty apart from one debug insn. The following patch adds a hexdump
of automaton state to make the problem eviden
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105549
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107952
--- Comment #15 from Qing Zhao ---
> On Jan 25, 2023, at 11:12 AM, siddhesh at gcc dot gnu.org
> wrote:
>>
>>> The first is handled by the function just fine,
>>
>> No, even the first case is not recognized by the current
>> “array_ref_flexi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108541
Bug ID: 108541
Summary: ASAN since GCC 9 missed a stack-buffer-overflow
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108536
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87512
--- Comment #6 from Andrew Pinski ---
(In reply to Guo Youtao from comment #5)
> This bug can still be triggered in gcc-11 and gcc-12.
That is unrelated bug. Most likely an issue with pointer to member functions
which is might have some known is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108523
--- Comment #15 from David Binderman ---
(In reply to Richard Biener from comment #14)
> Fixed, but I'll see if somebody comes up with a reduced testcase.
I have a reduction running with cvise.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87512
--- Comment #7 from Guo Youtao ---
(In reply to Andrew Pinski from comment #6)
> (In reply to Guo Youtao from comment #5)
> > This bug can still be triggered in gcc-11 and gcc-12.
>
> That is unrelated bug. Most likely an issue with pointer to m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108523
--- Comment #16 from David Binderman ---
cvise produces:
int g_149, g_167, g_481;
main() {
int *l_1478 = &g_149;
*l_1478 ^= g_167;
lbl_1481:
for (;;) {
g_481 = 1;
for (; g_481; g_481 += 1) {
g_167 ^= *l_1478;
if (g_149
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108538
--- Comment #4 from Stas Sergeev ---
(In reply to Jonathan Wakely from comment #3)
> It seems like you might be expecting more from -fpermissive than it actually
> provides. It only affects a very limited set of diagnostics, and isn't a
> genera
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108524
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108507
David Malcolm changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10
--- Comment #2 from Richard Earnshaw ---
If the testcase is built with -march=armv8.1-m.main+mve.fp then the useless
stack adjustments go away. I think that's because V4SFmode is not a supported
vector mode for integer MVE - see arm_vector_mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108542
Bug ID: 108542
Summary: [13 Regression] ICE in instantiate_type, at
cp/class.cc:8833
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108543
Bug ID: 108543
Summary: ICE in build_call_expr_loc_array, at tree.cc:10686
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108544
Bug ID: 108544
Summary: ICE in check_host_association, at
fortran/resolve.cc:6135
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10
--- Comment #3 from Richard Earnshaw ---
Given that the hard-float ABI essentially requires V4SF as a type, it might be
better to consider this mode supported unconditionally in this case, and
although that might make the compiler try some point
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108545
Bug ID: 108545
Summary: [13 Regression] ICE in install_var_field, at
omp-low.cc:799
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87512
--- Comment #8 from Jonathan Wakely ---
Yes please
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108546
Bug ID: 108546
Summary: [11/12/13 Regression] ICE in expand_expr_real_1, at
expr.cc:10910
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108531
--- Comment #5 from Keith Thompson ---
FYI, I've sent an email to the C standard editors (the addresses at
the top of the N3054 draft) suggesting that imaginary number support
should be optional even if __STDC_IEC_559_COMPLEX__ and
__STDC_IEC_60
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102760
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102760
--- Comment #7 from Andrew Pinski ---
(In reply to David Binderman from comment #6)
> I see very similar for this legal C code:
That seems like a different issue, please file it seperately.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99435
Georg-Johann Lay changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108547
Bug ID: 108547
Summary: ice in decompose, at wide-int.h:984 for -O2 with -Wall
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102760
--- Comment #8 from David Binderman ---
(In reply to Andrew Pinski from comment #7)
> (In reply to David Binderman from comment #6)
> > I see very similar for this legal C code:
>
> That seems like a different issue, please file it seperately.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108543
Marek Polacek changed:
What|Removed |Added
Last reconfirmed||2023-01-25
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100962
Georg-Johann Lay changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108547
--- Comment #1 from Andrew Pinski ---
Here is the full backtrace:
0xc7c58b wi::int_traits >
>::decompose(long*, unsigned int, generic_wide_int > const&)
/home/apinski/src/upstream-gcc/gcc/gcc/wide-int.h:984
0xc7c7a4 wide_int_ref_storage:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108547
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105753
User99627 changed:
What|Removed |Added
CC||user99627 at gmx dot com
--- Comment #10 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108547
--- Comment #3 from Andrew Pinski ---
Here is a slightly better testcase that does not depend on implicit conversion
from a function pointer to an integer.
int li_4, li_5, us_8;
unsigned char func_7_ptr_13, func_7_uc_14;
long t;
int func_7_uc_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108543
--- Comment #2 from Marek Polacek ---
struct _Bit_iterator_base {
long _M_p;
friend bool operator<(_Bit_iterator_base __x, _Bit_iterator_base __y) {
return &__x._M_p - &__y._M_p;
}
};
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108547
--- Comment #4 from Andrew Pinski ---
I suspect it is trying to simplifying:
((NOT (us_8.1_2 != 0)))
OR ((func_7_ptr_13.8_9 != 0) AND (_8 != 0) AND (func_7_ptr_13.8_9 & 1)
AND (NOT (_49 != 0)) AND (NOT (prephitmp_37 != 0)))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108543
--- Comment #3 from Marek Polacek ---
Started with r255404.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108543
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108527
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Known to work||7.5.0
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105753
--- Comment #11 from User99627 ---
I can also tell the bug occurs regardless of the -flto flag is present or not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108528
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot
gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108528
--- Comment #4 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:9fb9da3d38513d320bfea72050f7a59688595e0b
commit r13-5374-g9fb9da3d38513d320bfea72050f7a59688595e0b
Author: Steve Kargl
Date: Wed
1 - 100 of 134 matches
Mail list logo
