https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106095
--- Comment #1 from Antoni ---
Created attachment 53212
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53212=edit
patch fixing the bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106110
--- Comment #1 from Ted Lyngmo ---
Sorry, the helper variable template should be:
```
template
static constexpr bool is_foo_call_ambiguous_v =
is_foo_call_ambiguous::value;
```
It gives the same result: https://godbolt.org/z/bKbn8Gre7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106102
--- Comment #6 from Sergei Trofimovich ---
Also found a closely related jit build failure, but there is used
directly.
Proposed the change to move before poisoning step as:
https://gcc.gnu.org/pipermail/gcc-patches/2022-June/597379.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106102
--- Comment #5 from CVS Commits ---
The master branch has been updated by Sergei Trofimovich :
https://gcc.gnu.org/g:3b21c21f3f5726823e19728fdd1571a14aae0fb3
commit r13-1311-g3b21c21f3f5726823e19728fdd1571a14aae0fb3
Author: Sergei Trofimovich
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106105
seurer at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106105
--- Comment #2 from seurer at gcc dot gnu.org ---
The last round of tests I ran still showed this failing but I will check with
the latest commit.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106109
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106109
--- Comment #4 from Philip Deegan ---
as a minimal reproducer
`
template
class G
{
public:
auto static F() { return 1; }
};
int main()
{
auto fn = [](auto const& f) -> void { f(); };
fn(G::F);
return 0;
}
`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106109
--- Comment #3 from Philip Deegan ---
a bit more testing on our end, I think the issue stems from the lack of & on
GridYee::JxToMoments
https://github.com/PHAREHUB/PHARE/blob/master/tests/core/data/electrons/test_electrons.cpp#L519
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106110
Bug ID: 106110
Summary: Expected ambiguity but it resolves fine
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106109
--- Comment #2 from Philip Deegan ---
Created attachment 53211
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53211=edit
preprocessed source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106109
--- Comment #1 from Andrew Pinski ---
> ccCpGiQv.out is uploaded here:
Can you attach it? You might need to compress it too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106109
Bug ID: 106109
Summary: Internal compiler error
Product: gcc
Version: 12.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104430
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106089
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||kaiserkarl31 at yahoo dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106108
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89197
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97899
--- Comment #12 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:508231d54405ac9f120cf30c28cd6eb10ceded30
commit r13-1303-g508231d54405ac9f120cf30c28cd6eb10ceded30
Author: Marek Polacek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89197
--- Comment #6 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:508231d54405ac9f120cf30c28cd6eb10ceded30
commit r13-1303-g508231d54405ac9f120cf30c28cd6eb10ceded30
Author: Marek Polacek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106105
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106108
Bug ID: 106108
Summary: gfortran gives warning about unitilialized variable
for string with both allocatable length and size
Product: gcc
Version: 11.3.1
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106107
Bug ID: 106107
Summary: dynamic_cast fail within constant expression
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106106
Bug ID: 106106
Summary: SRA scalarizes structure copies
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106101
--- Comment #3 from Segher Boessenkool ---
STRICT_LOW_PART is required to contain a SUBREG though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106102
--- Comment #4 from Sergei Trofimovich ---
Posted my naive attempt:
https://gcc.gnu.org/pipermail/gcc-patches/2022-June/597353.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106081
--- Comment #4 from Jan Hubicka ---
Thanks! It seems that imagemagick has quite few loops that inovlve consuming
shorts and producing doubles. Also it would be nice to do something about
__builtin_convertvector so it does not produce stupid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106064
--- Comment #13 from Alex Coplan ---
(In reply to Richard Earnshaw from comment #12)
> (In reply to Alex Coplan from comment #11)
> > (In reply to Jakub Jelinek from comment #8)
> > > The IMHO UB case is for a != b when one address is at the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106064
--- Comment #12 from Richard Earnshaw ---
(In reply to Alex Coplan from comment #11)
> (In reply to Jakub Jelinek from comment #8)
> > The IMHO UB case is for a != b when one address is at the start of one
> > object and the other address is at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836
--- Comment #32 from qinzhao at gcc dot gnu.org ---
(In reply to James Y Knight from comment #31)
> It doesn't make sense to have a mode in which `int array[0]` is accepted but
> is not a flex array.
>
> Either that should be a compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105740
--- Comment #9 from Martin Liška ---
(In reply to luoxhu from comment #8)
> (In reply to rguent...@suse.de from comment #6)
> > On Tue, 21 Jun 2022, jakub at gcc dot gnu.org wrote:
> >
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105740
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106090
Martin Liška changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106070
--- Comment #11 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:00063459f683adcd92ada8325984e6b10e9f7a95
commit r13-1299-g00063459f683adcd92ada8325984e6b10e9f7a95
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102464
--- Comment #17 from jbeulich at suse dot com ---
Largely the same is actually true for the RNDSCALEPH test added for the PR
here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106022
--- Comment #14 from H.J. Lu ---
(In reply to rguent...@suse.de from comment #13)
> On Fri, 24 Jun 2022, hjl.tools at gmail dot com wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106022
> >
> > --- Comment #12 from H.J. Lu ---
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106105
Bug ID: 106105
Summary: new test case gcc.dg/torture/pr106070.c in
r13-1243-gb36a1c964f9975 fails for 32 bits
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106104
jbeulich at suse dot com changed:
What|Removed |Added
Target||i?86-*-*
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106104
Bug ID: 106104
Summary: PR 87007 testcase fails with 32-bit compiler
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106053
--- Comment #2 from Richard Biener ---
It works with -mavx or when 'foo' is early inlined (using always-inline).
Working:
u.1_8 = u;
_9 = (long long unsigned int) u.1_8;
u64_0_10 = _9 | 23725760132;
_18 = u64_0_10 * 3095179400;
_50
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102464
jbeulich at suse dot com changed:
What|Removed |Added
CC||jbeulich at suse dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106064
--- Comment #11 from Alex Coplan ---
(In reply to Jakub Jelinek from comment #8)
> The IMHO UB case is for a != b when one address is at the start of one
> object and the other address is at the end of another one
Just to dig a little deeper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106102
--- Comment #3 from Sergei Trofimovich ---
Aha, that makes sense.
In this case include chain is:
- c++tools/resolver.cc
-> c++tools/resolver.h
-> libcody/cody.hh
-> libstdc++-v3/include/memory
->
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106103
Bug ID: 106103
Summary: ICE in binds_to_current_def_p when source object files
are compiled with -flto -Os
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106102
--- Comment #2 from Richard Biener ---
The failure can only happen if system headers are included after gcc posioning.
All system headers need to be included from system.h for this reason.
I think gcc/cp/mapper-resolver.cc needs to arrange the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106100
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106099
Richard Biener changed:
What|Removed |Added
Summary|ICE in execute_todo, at |[13 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106096
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106091
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |11.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106088
Richard Biener changed:
What|Removed |Added
Resolution|--- |MOVED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106081
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106064
--- Comment #10 from Jakub Jelinek ---
IMHO it is.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106064
--- Comment #9 from Alex Coplan ---
So if f is UB, I suppose the question is whether the codegen for g is correct?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106102
Bug ID: 106102
Summary: gcc/cp/mapper-resolver.cc fails to build against musl:
musl-1.2.3-dev/include/sched.h:84:7: error: attempt to
use poisoned "calloc"
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106056
--- Comment #2 from Paul Iannetta ---
Right now, I can't pinpoint a test-case within the official gcc testsuite, and
the list of targets which define TARGET_ASM_FINAL_POSTSCAN_INSN is limited to:
mips, avr and m68k. From my understanding the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106102
--- Comment #1 from Sam James ---
See also bug 104799.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106070
--- Comment #10 from Richard Earnshaw ---
the testcase in the committed patch, that is.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106096
Xi Ruoyao changed:
What|Removed |Added
Known to work|12.1.0 |
--- Comment #4 from Xi Ruoyao ---
Remove
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106096
Xi Ruoyao changed:
What|Removed |Added
Build|loongarch64-linux-gnu |
Summary|[13 regression] ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106096
--- Comment #2 from Xi Ruoyao ---
Created attachment 53208
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53208=edit
reduced testcase
It looks like a LoongArch code generation issue, not really related to the
changes in r13-911.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105039
hs.naveen2u at gmail dot com changed:
What|Removed |Added
CC||hs.naveen2u at gmail dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103035
Bug 103035 depends on bug 106070, which changed state.
Bug 106070 Summary: [13 Regression] Wrong code with -O1 since
r13-469-g9a53101caadae1b5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106070
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106070
Richard Earnshaw changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106101
Richard Biener changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106101
--- Comment #1 from Richard Biener ---
Created attachment 53207
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53207=edit
reduced testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106101
Richard Biener changed:
What|Removed |Added
Keywords||ice-on-valid-code
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106101
Bug ID: 106101
Summary: [12/13 Regression] ICE in reg_bitfield_target_p
Product: gcc
Version: 12.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106099
--- Comment #3 from Andrew Pinski ---
(In reply to Martin Liška from comment #2)
> Started with r13-1204-gd68d366425369649.
Since -funreachable-traps is a new option, is this a regression then?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106053
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=106036
Martin Liška changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106081
Martin Liška changed:
What|Removed |Added
Blocks||26163
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106099
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106082
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |13.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106099
--- Comment #1 from Zdenek Sojka ---
A simple C testcase:
$ cat testcase.c
void
foo (void)
{
for (unsigned i = 0; i < sizeof (foo); i++)
;
}
$ x86_64-pc-linux-gnu-gcc -O -fsanitize=unreachable
-fsanitize-undefined-trap-on-error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105956
Martin Liška changed:
What|Removed |Added
CC||nyh at math dot technion.ac.il
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106087
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106022
--- Comment #13 from rguenther at suse dot de ---
On Fri, 24 Jun 2022, hjl.tools at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106022
>
> --- Comment #12 from H.J. Lu ---
> (In reply to Richard Biener from comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106073
Martin Liška changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106048
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106097
--- Comment #9 from chenglulu ---
Created attachment 53206
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53206=edit
use LU52I_B and LU32I_B instead of hard coding those long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106053
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2022-06-27
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106056
Martin Liška changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106050
Martin Liška changed:
What|Removed |Added
Summary|ICE in reject_statement, at |ICE in reject_statement, at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106097
--- Comment #8 from chenglulu ---
> You can reuse LU32I_B and LU52I_B instead of hard coding those long
> constants :).
I have fixed it, thanks！:)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106097
--- Comment #7 from Xi Ruoyao ---
(In reply to chenglulu from comment #6)
> Created attachment 53205 [details]
> 0001-Fix-bug-for-PR16097.patch
You can reuse LU32I_B and LU52I_B instead of hard coding those long constants
:).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100096
Sascha Wilde changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106097
--- Comment #6 from chenglulu ---
Created attachment 53205
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53205=edit
0001-Fix-bug-for-PR16097.patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106096
--- Comment #1 from Xi Ruoyao ---
Stage 1 GCC generates some very strange code for stage 2 GCC, jumping to
"0x2000":
.L747:
beqz$r12,.L750
lu12i.w $r13,8192>>12 # 0x2000
ld.d$r5,$r26,8
add.d $r3,$r3,$r13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106100
Bug ID: 106100
Summary: where
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94026
--- Comment #12 from CVS Commits ---
The master branch has been updated by Roger Sayle :
https://gcc.gnu.org/g:f3f73e86ec8613f176db3e52bbfbfbb9636cb714
commit r13-1281-gf3f73e86ec8613f176db3e52bbfbfbb9636cb714
Author: Roger Sayle
Date: Mon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7061
--- Comment #11 from CVS Commits ---
The master branch has been updated by Roger Sayle :
https://gcc.gnu.org/g:64d4f27a0ce47e97867512bda7fa5683acf8a134
commit r13-1282-g64d4f27a0ce47e97867512bda7fa5683acf8a134
Author: Roger Sayle
Date: Mon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106099
Bug ID: 106099
Summary: ICE in execute_todo, at passes.cc:2134
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
90 matches
Mail list logo
