https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104583
Marek Polacek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105056
--- Comment #2 from Andrew Pinski ---
Since we require C++11, why don't we use NSDMI instead and then if another
constructor gets added you don't need to change that constructor also?
e.g.
diff --git a/gcc/tree-predcom.cc b/gcc/tree-predcom.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104308
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104308
David Malcolm changed:
What|Removed |Added
Keywords||patch
--- Comment #5 from David
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105056
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105046
--- Comment #7 from Elliott M ---
Guess I have to go for the visible use:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/include/asm/xen/hypercall.h
Substantial amounts of the _hypercall#() macro definitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105055
--- Comment #2 from CVS Commits ---
The master branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:bdd7b679e8497c07e25726f6ab6429e4c4d429c7
commit r12-7820-gbdd7b679e8497c07e25726f6ab6429e4c4d429c7
Author: H.J. Lu
Date: Fri Mar 25
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104583
--- Comment #4 from Marek Polacek ---
Candidate fix:
--- a/gcc/cp/init.cc
+++ b/gcc/cp/init.cc
@@ -679,10 +679,10 @@ get_nsdmi (tree member, bool in_ctor, tsubst_flags_t
complain)
if (simple_target)
init = TARGET_EXPR_INITIAL (init);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105057
David Malcolm changed:
What|Removed |Added
Last reconfirmed||2022-03-25
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95188
David Malcolm changed:
What|Removed |Added
Summary|analyzer-unsafe-call-within |State explosion on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104583
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105059
Bug ID: 105059
Summary: Inconsistency between paren- and brace-initialization
of a union with anonymous struct
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105058
Bug ID: 105058
Summary: Incorrect register constraint in KL patterns
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105003
Jason Merrill changed:
What|Removed |Added
Priority|P3 |P1
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104882
Christophe Lyon changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104882
--- Comment #4 from CVS Commits ---
The master branch has been updated by Christophe Lyon :
https://gcc.gnu.org/g:3ab5c8cd03d92bf4ec41e351820349d92fbc40c4
commit r12-7818-g3ab5c8cd03d92bf4ec41e351820349d92fbc40c4
Author: Christophe Lyon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103455
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.1 20220325 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105053
Martin Liška changed:
What|Removed |Added
Keywords|needs-bisection |
--- Comment #9 from Martin Liška ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105053
--- Comment #8 from Marc Glisse ---
Thank you.
I originally noticed the problem with 11.2.0-18 (Debian), so I believe this
will be needed on that branch as well. 10.3.0 looked ok...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104971
--- Comment #7 from CVS Commits ---
The master branch has been updated by Vladimir Makarov :
https://gcc.gnu.org/g:25725506b85f478076770942d76799c54310c696
commit r12-7817-g25725506b85f478076770942d76799c54310c696
Author: Vladimir N. Makarov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104860
David Malcolm changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104964
--- Comment #14 from Jakub Jelinek ---
Thus I'd say fix up acl instead.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104964
--- Comment #13 from Siddhesh Poyarekar ---
It's not really a regression AFAICT, it's only more visible with __bdos because
non-constant offsets don't stop it. Also the problem is only with subobjects
(hence limited to _FORTIFY_SOURCE > 1 for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104049
--- Comment #13 from Tamar Christina ---
That said, I'll wait for Richard S to respond, but I don't think this is a P1
any longer, we know why it can't be done during reload and neither sequences
are really significantly better/worse.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104049
--- Comment #12 from Tamar Christina ---
(In reply to Jakub Jelinek from comment #10)
> Could we fix this up in postreload or later?
> (insn 35 18 21 2 (set (reg:SI 0 x0 [125])
> (reg:SI 32 v0 [117])) "pr104049.c":16:33 52
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105055
H.J. Lu changed:
What|Removed |Added
CC|hjl at gcc dot gnu.org |hjl.tools at gmail dot
com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105056
Martin Liška changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104049
--- Comment #11 from Tamar Christina ---
(In reply to Jakub Jelinek from comment #9)
> Perhaps the r12-2288-g8695bf78dad1a42636 change wasn't a good idea?
I think it's still a good idea as it fixes a bigger problem (unneeded SIMD
partial
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105056
Martin Liška changed:
What|Removed |Added
Target Milestone|--- |12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105056
Bug ID: 105056
Summary: [12 Regression] runtime error: load of value
3132799674, which is not a valid value for type
'ref_step_type' since r12-7795-g85b4d881327e31
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102772
--- Comment #25 from Jakub Jelinek ---
Ah, sorry, my fault apparently.
pushl %ebx
movl%gs:0, %ebx
addl$s@ntpoff, %ebx
popl%ebx
ret
of course doesn't make sense, because when it is a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105053
Richard Biener changed:
What|Removed |Added
Known to work||12.0
--- Comment #7 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105054
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105053
--- Comment #6 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:fe705dce2e1e3e4e5e0c69d7f9adaf7f2777cdc8
commit r12-7816-gfe705dce2e1e3e4e5e0c69d7f9adaf7f2777cdc8
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104964
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104944
Marek Polacek changed:
What|Removed |Added
Summary|[9/10/11/12 Regression] |[9/10/11 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104944
--- Comment #4 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:d0b938a7612fb7acf1f181da9577235c83ede59e
commit r12-7815-gd0b938a7612fb7acf1f181da9577235c83ede59e
Author: Marek Polacek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102772
--- Comment #22 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #20 from Jakub Jelinek ---
> Note, for ntpoff the listed instructions are:
> movl %gs:0,%eax
> leal x@ntpoff(%eax),%eax
> rather than addl. But certainly this one was
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102772
--- Comment #27 from Jakub Jelinek ---
But then we are back at figuring out what exactly is wrong with the
libgomp.fortran/pointer2.f90 testcase.
Can you perhaps upload the failing binary and corresponding *.o file?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104049
--- Comment #10 from Jakub Jelinek ---
Anyway, a difference at *.combine time is:
(insn 19 18 22 2 (set (reg:SI 103 [ _35 ])
(vec_select:SI (reg:V4SI 121)
(parallel [
(const_int 0 [0])
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105042
Thomas Schwinge changed:
What|Removed |Added
CC||tschwinge at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104964
Martin Liška changed:
What|Removed |Added
Priority|P3 |P1
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105055
Bug ID: 105055
Summary: pr95483-1.c makes incorrect assumption of SSE2 being
enabled.
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102772
--- Comment #29 from Jakub Jelinek ---
Ok, that looks like a linker bug:
movaps %xmm7, thr.1@ntpoff(%ebx)
...
movaps %xmm7, thr.1@ntpoff+16(%ebx)
...
movl%eax, thr.1@ntpoff+32(%ebx)
in assembly correctly turned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105054
martin changed:
What|Removed |Added
CC||mscfd at gmx dot net
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105050
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105022
David Malcolm changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105053
--- Comment #5 from Richard Biener ---
Err, no - the reduction epilogue is simply incomplete:
[local count: 202926872]:
# prephitmp_27 = PHI
# vect__26.72_63 = PHI
_64 = .REDUC_MAX (vect__26.72_63);
if (prephitmp_27 !=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105050
--- Comment #4 from Jonathan Wakely ---
N.B. GCC 9 showed this instead of the "" part:
x.ii:15:7: error: expression
'(((expected*)this)->expected::has_value() ? ((&
__x)->expected::has_value() ? ({...}) : ({...})) : ((&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105050
--- Comment #3 from Jonathan Wakely ---
I think just "note: neither branch of ‘if’ is a valid ‘constexpr’ body" without
the "because ..." and the following notes would be good enough.
It tells the user to look at the 'if' body, not the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102772
--- Comment #28 from Rainer Orth ---
Created attachment 52688
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52688=edit
32-bit i386-pc-solaris2.11 pointer2.{exe,o,s}
pointer2.f90 executable etc. as of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102772
--- Comment #26 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #25 from Jakub Jelinek ---
> Ah, sorry, my fault apparently.
> pushl %ebx
> movl%gs:0, %ebx
> addl$s@ntpoff, %ebx
> popl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105022
--- Comment #1 from David Malcolm ---
https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-malloc-function-attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102772
--- Comment #24 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #23 from Jakub Jelinek ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #21)
>> The linker isn't a factor here: both ld and gld 2.38 produce the same
>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105054
Bug ID: 105054
Summary: Using one kind of pointer functions causes the
compiler to hang
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102772
--- Comment #23 from Jakub Jelinek ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #21)
> > --- Comment #19 from Jakub Jelinek ---
> > If it is the linker, you can always objdump -dr the binary to see what is in
> > there after
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105042
--- Comment #6 from CVS Commits ---
The master branch has been updated by Tom de Vries :
https://gcc.gnu.org/g:8570cce7c705f2ec3ffaeb8e47d58af22a075ebd
commit r12-7814-g8570cce7c705f2ec3ffaeb8e47d58af22a075ebd
Author: Tom de Vries
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105053
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=102772
--- Comment #21 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #19 from Jakub Jelinek ---
> If it is the linker, you can always objdump -dr the binary to see what is in
> there after linking. s@ntpoff in my understanding is a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105053
--- Comment #3 from Richard Biener ---
(In reply to Richard Biener from comment #2)
> (In reply to Richard Biener from comment #1)
> > It also reproduces with n == 16 for me - can you produce a testcase with a
> > static initializer that's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105049
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105049
--- Comment #3 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:0b0fc52b0412cc1608f4f0edb8a0ab2495619c4e
commit r12-7813-g0b0fc52b0412cc1608f4f0edb8a0ab2495619c4e
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104049
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105051
--- Comment #4 from Godmar Back ---
Don't let perfect be the enemy of good. IMO, the detection doesn't need to be
perfect in the sense of not having false negatives. All 3 bug reports of the
calloc implementations you broke called malloc +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105053
--- Comment #2 from Richard Biener ---
(In reply to Richard Biener from comment #1)
> It also reproduces with n == 16 for me - can you produce a testcase with a
> static initializer that's known to fail please?
And n == 4, but std::cout <<
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105053
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2022-03-25
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105053
Bug ID: 105053
Summary: Wrong loop count for scalar code from vectorizer
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103691
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103691
--- Comment #10 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:45e955b0a936eafc9838cdc00dcc31b3799b321b
commit r12-7811-g45e955b0a936eafc9838cdc00dcc31b3799b321b
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105050
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2022-03-25
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103533
--- Comment #7 from CVS Commits ---
The master branch has been updated by Tobias Burnus :
https://gcc.gnu.org/g:748f36a48b506f52e10bcdeb750a7fe9c30c26f3
commit r12-7810-g748f36a48b506f52e10bcdeb750a7fe9c30c26f3
Author: Tobias Burnus
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100756
--- Comment #3 from Richard Biener ---
(In reply to rdapp from comment #2)
> I did not get back to this until now. The patch works, of course and a
> testsuite run looks good so far. I assume we're too late in the cycle to
> still get this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100756
--- Comment #2 from rdapp at linux dot ibm.com ---
I did not get back to this until now. The patch works, of course and a
testsuite run looks good so far. I assume we're too late in the cycle to still
get this in, right?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105042
--- Comment #5 from Tom de Vries ---
(In reply to Richard Biener from comment #1)
> Doesn't whatever driver/library API we use from libgomp to invoke workloads
> report actual errors? Maybe we need to improve there.
This:
...
libgomp:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105042
--- Comment #4 from Tom de Vries ---
https://gcc.gnu.org/pipermail/gcc-patches/2022-March/592275.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105030
--- Comment #8 from rguenther at suse dot de ---
On Fri, 25 Mar 2022, guihaoc at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105030
>
> --- Comment #7 from HaoChen Gui ---
> The original case comes from a Fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105051
--- Comment #3 from Richard Biener ---
It's more of a QOI issue, we have similar (old) bugs where we pattern-match a
memcpy loop to memcpy inside memcpy (PR56888). The difficulty is to reliably
detect whether we're in a place where emitting a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105049
--- Comment #2 from Richard Biener ---
We have
return VIEW_CONVERT_EXPR( VEC_PERM_EXPR < {<<< Unknown tree:
compound_literal_expr
V D.1984 = { 0 }; >>>, { 0 }} , {<<< Unknown tree:
compound_literal_expr
V D.1985 = { 0 }; >>>,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105030
--- Comment #7 from HaoChen Gui ---
The original case comes from a Fortran program. I rewrote it with C. As the
arguments are passed by reference in Fortran (by default), the problem is
common. But I am not sure if it has a large performance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104964
--- Comment #11 from Siddhesh Poyarekar ---
(In reply to Siddhesh Poyarekar from comment #10)
> OK, I have a representative reproducer, which TBH is not too different from
> the one you posted, just that it succeeds with __builtin_object_size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104964
Siddhesh Poyarekar changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #10 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103775
--- Comment #9 from Eric Botcazou ---
> This untested patch seems to work.
This looks sensible to me, maybe move the new code up to before the constraint
check since it is always run.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105049
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105030
--- Comment #6 from rguenther at suse dot de ---
On Fri, 25 Mar 2022, guihaoc at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105030
>
> --- Comment #5 from HaoChen Gui ---
> (In reply to Richard Biener from comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105042
--- Comment #3 from Tom de Vries ---
(In reply to Tom de Vries from comment #2)
> (In reply to Richard Biener from comment #1)
> > Doesn't whatever driver/library API we use from libgomp to invoke workloads
> > report actual errors? Maybe we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105030
--- Comment #5 from HaoChen Gui ---
(In reply to Richard Biener from comment #4)
> something like
>
> void *bar (void *x)
> {
> *(double *)x = 1.;
> }
>
> void foo(int n)
> {
>double atemp;
>pthread_create (..., bar, );
>for
87 matches
Mail list logo
