https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112669
--- Comment #2 from GCC Commits ---
The master branch has been updated by Thomas Schwinge :
https://gcc.gnu.org/g:297fe5c166f1d920da6d5ef9c7e02846b0148575
commit r14-5884-g297fe5c166f1d920da6d5ef9c7e02846b0148575
Author: Thomas Schwinge
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109269
Richard Sandiford changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112729
Bug ID: 112729
Summary: gcc.target/i386/apx-interrupt-1.c etc. FAIL
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112729
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112729
--- Comment #1 from Rainer Orth ---
Created attachment 56695
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56695&action=edit
64-bit i386-pc-solaris2.11 assembler output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
--- Comment #16 from Jakub Jelinek ---
oris 2,2,0 is a noop group_ending_nop.
Anyway, that oris 2,2,0 nor the li 28, 0 scheduling don't change anything and
I've
narrowed it down (- bad, + working) to the
--- cp/call.s 2023-11-27 14:24:12.61661
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112716
--- Comment #7 from uecker at gcc dot gnu.org ---
(In reply to rguent...@suse.de from comment #6)
> On Mon, 27 Nov 2023, muecker at gwdg dot de wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112716
> >
> > --- Comment #5 from Martin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112730
Bug ID: 112730
Summary: Wrong code generated with Address Sanitizer for a call
to a callback in contained subroutine, mapping not
executable
Product: gcc
Version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87875
Andrew Pinski changed:
What|Removed |Added
CC||bardeau at iram dot fr
--- Comment #12 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110157
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112730
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87875
Andrew Pinski changed:
What|Removed |Added
CC||trnka at scm dot com
--- Comment #13 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87875
--- Comment #14 from Andrew Pinski ---
(In reply to Martin Liška from comment #11)
> Unassigning as it's quite rare situation and one can use
> detect_stack_use_after_return=false to handle such error.
Well it might be rare in c but not as rare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
--- Comment #17 from Jakub Jelinek ---
And under a debugger I can see exactly that happening. With the bad version of
splice_viable on the 16th call of splice_viable, I see
the code path in which r10 in the last hunk's spot where the addi r10,r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112669
Thomas Schwinge changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
--- Comment #18 from Jakub Jelinek ---
Created attachment 56697
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56697&action=edit
pr111601.ii.xz
Preprocessed source, compile with
./cc1plus -quiet -fpreprocessed -O2 -fprofile-generate -fno-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
--- Comment #19 from Jakub Jelinek ---
When using current trunk (r14-5889), I can see it even in x86_64-linux ->
powerpc64le-linux cross-compiler.
diff -U300 pr111601.s{1,2}
will show
std 9,0(10)
mr 10,9
+ addi 10,10,96
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
--- Comment #20 from Jakub Jelinek ---
Manolis/Jeff, how does the pass prove that it found and adjusted all the uses
of the register rather than just some (or the first one) as apparently happens
on this testcase?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111754
--- Comment #12 from GCC Commits ---
The master branch has been updated by Prathamesh Kulkarni
:
https://gcc.gnu.org/g:2065438db4ac13af7e0de2f934959413647f74a7
commit r14-5890-g2065438db4ac13af7e0de2f934959413647f74a7
Author: Prathamesh Kulkar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111754
prathamesh3492 at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Res
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112583
Patrick O'Neill changed:
What|Removed |Added
Attachment #56659|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112689
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112597
Patrick O'Neill changed:
What|Removed |Added
Attachment #56660|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112583
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111298
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112727
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112597
--- Comment #10 from Patrick O'Neill ---
See Andrew's comment on pr112583 - the new failures when comparing with the
previous report are already tracked and appear on other architectures.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112598
Patrick O'Neill changed:
What|Removed |Added
Attachment #56661|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112689
--- Comment #3 from Andrew Pinski ---
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/638104.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112653
--- Comment #15 from Jan Hubicka ---
Thanks a lot for working on this! I think it is quite importnat part of
the puzzle of making libstdc++ vector working reasonably well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112689
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112701
Lewis Hyatt changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112599
Patrick O'Neill changed:
What|Removed |Added
Attachment #56662|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112701
--- Comment #5 from Andrew Pinski ---
(In reply to Lewis Hyatt from comment #4)
> Here is the fix. Not sure if it needs to wait for GCC 15 by now, but I can
> submit it with the testcase.
Bugs can be fixed during stage 3 (just no new __major__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112721
--- Comment #2 from Martin Jambor ---
I have proposed a fix on the mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/638318.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112711
--- Comment #6 from Martin Jambor ---
I have proposed a fix on the mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/638318.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112731
Bug ID: 112731
Summary: [14 regression] Excess errors for
c-c++-common/builtin-classify-type-1.c after
r14-5615-g509b470dcee979
Product: gcc
Version: 14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112731
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112725
Andrew Pinski changed:
What|Removed |Added
CC||seurer at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
--- Comment #21 from Jakub Jelinek ---
Reduced testcase (though, just the function in question, not a runable
testcase):
struct tree_base
{
int code:16;
};
struct saved_scope
{
void *pad[14];
int x_processing_template_decl;
};
extern struc
ra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231127 (experimental) (GCC)
ls --disable-bootstrap
--src=../../gcc --enable-multilib --with-abi=lp64d --with-arch=rv64imafdc
--with-tune=rocket --with-isa-spec=20191213 'CFLAGS_FOR_TARGET=-O2
-mcmodel=medlow' 'CXXFLAGS_FOR_TARGET=-O2-mcmodel=medlow'
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231127 (experimental) (gc9d691a7daa)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112733
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112733
--- Comment #1 from Andrew Pinski ---
multiple_of_p is one big source of bugs ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112733
--- Comment #2 from Andrew Pinski ---
I linked PR 100499, not that it caused the issue here but talks about the
issues in multiple_of_p .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
--- Comment #22 from Jakub Jelinek ---
Full executable testcase:
struct tree_base
{
int code:16;
};
struct saved_scope
{
void *pad[14];
int x_processing_template_decl;
};
struct saved_scope *scope_chain;
struct z_candidate
{
tree_base *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112733
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100651
anlauf at gcc dot gnu.org changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
es=c,c++,fortran,lto
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231127 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
--- Comment #23 from Jakub Jelinek ---
Looking around, seems do_analysis properly finds out both uses of the %r10 +=
96 - the store of %r5 later in the same bb and store of %r9 earlier in the same
bb (at the start of it), and continues because b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
--- Comment #24 from Jakub Jelinek ---
As the pass seems to work on one basic block at the time (everything from
analysis to actual changes), I wonder if e.g. get_uses shouldn't punt if it
sees (non-DEBUG_INSN!) uses in other basic block but the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
--- Comment #51 from Sam James ---
manolis, did you have a chance to look at the remaining pass issue? You'll need
to revert Dave's commit locally which made the issue latent for building
Python.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112712
--- Comment #2 from Mikael Pettersson ---
It appears the test case comes from https://github.com/dxx-rebirth/dxx-rebirth/
(a port of the old Descent game engine).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112735
Bug ID: 112735
Summary: [14 regression] gcc.dg/tree-prof/time-profiler-3.c
fails after r14-5666-g41aacdea55c5d7
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112735
--- Comment #1 from Andrew Pinski ---
Testing a fix. And this is a dup.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112735
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112689
Andrew Pinski changed:
What|Removed |Added
CC||seurer at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112656
Indu Bhagat changed:
What|Removed |Added
CC||ibhagat at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112656
--- Comment #5 from Indu Bhagat ---
The reason for the noted difference in BTF for BPF vs non-BPF target is:
On non-BPF targets, BTF is emitted in early_finish. On BPF target however,
-mco-re is default, and hence, BTF is emitted in late finish
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111703
--- Comment #10 from GCC Commits ---
The releases/gcc-12 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:6a31302a6c8bec9af3c93f736c2b1a76e9a530e2
commit r12-10016-g6a31302a6c8bec9af3c93f736c2b1a76e9a530e2
Author: Patrick Palka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111703
--- Comment #11 from GCC Commits ---
The releases/gcc-12 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:c9cb7e3d75d494a6591887a99d0d3f7f7a307b2e
commit r12-10017-gc9cb7e3d75d494a6591887a99d0d3f7f7a307b2e
Author: Patrick Palka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112269
--- Comment #15 from GCC Commits ---
The releases/gcc-12 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:6a31302a6c8bec9af3c93f736c2b1a76e9a530e2
commit r12-10016-g6a31302a6c8bec9af3c93f736c2b1a76e9a530e2
Author: Patrick Palka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107939
--- Comment #12 from GCC Commits ---
The releases/gcc-12 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:c9cb7e3d75d494a6591887a99d0d3f7f7a307b2e
commit r12-10017-gc9cb7e3d75d494a6591887a99d0d3f7f7a307b2e
Author: Patrick Palka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111705
Patrick Palka changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109077
David Malcolm changed:
What|Removed |Added
Blocks||107646
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109077
--- Comment #2 from David Malcolm ---
PLUGIN_ANALYZER_INIT was added in r11-5583-g66dde7bc64b75d, so presumably this
affects GCC 11 onwards.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112633
Patrick Palka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112736
Bug ID: 112736
Summary: vectorizer is introducing out of bounds memory access
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112736
Andrew Pinski changed:
What|Removed |Added
Summary|vectorizer is introducing |[14 Regression] vectorizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110279
--- Comment #3 from Andrew Pinski ---
(In reply to GCC Commits from comment #2)
> gcc/testsuite/ChangeLog:
>
> * gcc.dg/pr110279-1.c: New test.
This testcase fails on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112689
--- Comment #6 from GCC Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:cd2519a6f857539262398f3ff63b53de173e2a88
commit r14-5892-gcd2519a6f857539262398f3ff63b53de173e2a88
Author: Andrew Pinski
Date: Mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112689
Andrew Pinski changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112737
Bug ID: 112737
Summary: [14 Regression] g++.dg/modules/xtreme-header-2_b.C
-std=c++2b (test for excess errors)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112454
--- Comment #5 from GCC Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:d29d27bde5df89e5357e0a33a71bb49125bd1655
commit r14-5893-gd29d27bde5df89e5357e0a33a71bb49125bd1655
Author: Andrew Pinski
Date: Su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110279
--- Comment #4 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #3)
> (In reply to GCC Commits from comment #2)
> > gcc/testsuite/ChangeLog:
> >
> > * gcc.dg/pr110279-1.c: New test.
>
> This testcase fails on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112738
Bug ID: 112738
Summary: forwprop4 introduces invalid wide signed Boolean
values
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111668
--- Comment #9 from Krister Walfridsson ---
I opened PR 112738 for the issue mentioned in comment 8.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112738
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Summary|forwprop4 i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #50 from joseph at codesourcery dot com ---
Qualifiers on function parameter types do not affect type compatibility or
composite type (see 6.7.6.3#14). I think they're only actually of
significance in the definition; in a declarati
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112738
--- Comment #2 from Andrew Pinski ---
This is what I will be testing:
```
/* (nop_outer_cast)-(inner_cast)var -> -(outer_cast)(var)
if var is smaller in precision.
This is always safe for both doing the negative in signed or unsigned
as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112739
Bug ID: 112739
Summary: variable 'a' is uninitialized when used within its own
initialization
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112739
Yiming Xiang changed:
What|Removed |Added
Summary|variable 'a' is |Not emitting warning when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97598
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112739
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91225
Andrew Pinski changed:
What|Removed |Added
CC||kxiang at umich dot edu
--- Comment #5 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91225
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Keywords|diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112710
Ian Lance Taylor changed:
What|Removed |Added
CC||ian at airs dot com
--- Comment #2 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112737
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112701
Lewis Hyatt changed:
What|Removed |Added
Keywords||patch
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112708
--- Comment #10 from Bruno Haible ---
(In reply to Jakub Jelinek from comment #9)
> var-tracking is very compile time intensive,
> so it would significantly slow down -O0 compilation.
Indeed, these are the timings of "time make" that I observe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112707
--- Comment #9 from HaoChen Gui ---
(In reply to Segher Boessenkool from comment #8)
> Yeah, it tested for ISA 2.04 before. That was an attempt at including 476
> probably?
>
> We really should have a TARGET_FCTID, on for TARGET_POWERPC64 or f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112734
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112713
--- Comment #1 from GCC Commits ---
The master branch has been updated by Pan Li :
https://gcc.gnu.org/g:9c16ca93641ad460a576a9ed7daf2aadf596193c
commit r14-5897-g9c16ca93641ad460a576a9ed7daf2aadf596193c
Author: Juzhe-Zhong
Date: Mon Nov 27
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112707
--- Comment #10 from Kewen Lin ---
(In reply to HaoChen Gui from comment #9)
> (In reply to Segher Boessenkool from comment #8)
> > Yeah, it tested for ISA 2.04 before. That was an attempt at including 476
> > probably?
> >
> > We really shoul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112701
--- Comment #7 from GCC Commits ---
The master branch has been updated by Lewis Hyatt :
https://gcc.gnu.org/g:ce52f1f7074d96c4d9ce63b1169c11087757e926
commit r14-5898-gce52f1f7074d96c4d9ce63b1169c11087757e926
Author: Lewis Hyatt
Date: Mon N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112701
Lewis Hyatt changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112729
--- Comment #2 from Hongyu Wang ---
The cfi scan fails was caused by -fno-omit-frame-pointer which force push the
frame pointer first and the cfi info become different. By default we have
-fomit-frame-pointer on linux, but not other targets. I'd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112598
--- Comment #17 from Li Pan ---
(In reply to Robin Dapp from comment #15)
> Does the =m fix your issue? Or is the code gen different then and we're
> just lucky? For my problem it doesn't help because we still don't recognize
> an alias betwee
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112729
--- Comment #3 from Hongyu Wang ---
Created attachment 56703
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56703&action=edit
A patch
Hi Rainer, can you help verify if the change make these test pass on
solaris/FreeBSD?
This error happens when using macro and template.
GCC Version: gcc version 12.3.0 (Ubuntu 12.3.0-1ubuntu1~22.04)
OS: ubuntu 22.04 (x64)
Compile Command:
g++-12 ./testmacro.cc --std=c++20
In fact, this error exisits from g++11 to g++13. I also test it on clang and
msvc, but it cannot be reproduce
101 - 200 of 214 matches
Mail list logo
