https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111715
--- Comment #1 from Richard Biener ---
Created attachment 56068
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56068=edit
preprocessed source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111714
--- Comment #3 from Carlos Galvez ---
Thanks for the quick response! Unfortunately we are stuck on GCC 9 for reasons
so I'll try to shuffle the code around a bit to make it work :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111717
--- Comment #1 from 康桓瑋 ---
#include
namespace std {
constexpr size_t dynamic_extent = -1;
template
class extents { };
template
using dextents = decltype([](index_sequence) {
return extents{};
}(make_index_sequence{}));
// this works
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111716
Andrew Pinski changed:
What|Removed |Added
Target|riscv64-linux-gnu |riscv64-linux-gnu
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111717
Andrew Pinski changed:
What|Removed |Added
Keywords||c++-lambda
--- Comment #2 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111714
--- Comment #2 from Andrew Pinski ---
>From IV-OPTs dup:
inv_expr 3: (-() _13 - () ) - -1
inv_expr 4: -() _13 - ()
That is totally bogus (that was even in GCC 8)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111663
Sergei Trofimovich changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |slyfox at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111714
--- Comment #1 from Richard Biener ---
looks like a bug in GCC 9.x, note that's EOL and thus will receive no fixes.
You can try to bisect where it was fixed since GCC 10.1 seems to work. There
might be a duplicate fixed bugreport for this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110368
--- Comment #7 from Sam James ---
That said, I suppose we should do better here with -Wstrict-aliasing. No level
detects it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111716
Bug ID: 111716
Summary: call site parameter not matching with formal parameter
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111714
Andrew Pinski changed:
What|Removed |Added
Keywords||wrong-code
--- Comment #4 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111643
--- Comment #9 from Lukas Grätz ---
Thanks for everything, it seemed to be a misunderstanding from my side anyway
and the documentation fix should help others.
I am sorry for being silent, I was sick for a few days. As for my original
problem,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111716
--- Comment #1 from Andrew Pinski ---
(In reply to King Lok Chung from comment #0)
> I also find that the type of the parameter is not propagated correctly. For
> example, an array type is propagated as a pointer type. Should I open
> another
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111663
--- Comment #2 from CVS Commits ---
The master branch has been updated by Sergei Trofimovich :
https://gcc.gnu.org/g:2551e10038a70901f30b2168e6e3af4536748f3c
commit r14-4439-g2551e10038a70901f30b2168e6e3af4536748f3c
Author: Sergei Trofimovich
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111715
Bug ID: 111715
Summary: Missed optimization in FRE because of weak TBAA
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111672
--- Comment #13 from Hanke Zhang ---
(In reply to Andrew Pinski from comment #12)
> (In reply to Hanke Zhang from comment #11)
> > But I have never seen this '_FORTIFY_SOURCE' before. So I'm a confused as
> > well. And when I try gcc@11.4 built
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110957
--- Comment #2 from anlauf at gcc dot gnu.org ---
Created attachment 56071
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56071=edit
Patch to fix mixed up parsing of fpe options
The attached patch fixes the mixup and adds the possibility
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111643
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111716
--- Comment #4 from Andrew Pinski ---
Short testcase:
```
struct f
{
int a[10];
int b[10];
int c;
int d[10];
int e[10];
};
void g(int a[10], int b[10], int e, int i[10], int j[10]);
void h(void *a1)
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111694
--- Comment #4 from Andrew Macleod ---
(In reply to Richard Biener from comment #3)
> Looks like some frange / relation mistake then.
l_3(D) [frange] double [-Inf, +Inf]
Equivalence set : [l_3(D), r_4(D)]
:
_1 = __builtin_signbit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109279
--- Comment #18 from Vineet Gupta ---
(In reply to Vineet Gupta from comment #17)
> (In reply to Vineet Gupta from comment #16)
> > > Which is what this produces:
> > > ```
> > > long long f(void)
> > > {
> > > unsigned t = 16843009;
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109279
--- Comment #19 from Vineet Gupta ---
FWIW with today's change, splitter is now hidden from IRA, but we are still
getting the extraneous mv.
2023-10-06 c1bc7513b1d7 RISC-V: const: hide mvconst splitter from IRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111715
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=111716
--- Comment #3 from King Lok Chung ---
(In reply to Andrew Pinski from comment #1)
> (In reply to King Lok Chung from comment #0)
> > I also find that the type of the parameter is not propagated correctly. For
> > example, an array type is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111643
--- Comment #12 from Andrew Pinski ---
Gcc does have tail call optimization which should allow the instrumentation
with less overhead. Though tail call optimization happens at -O2 and above only
(by default).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111717
Bug ID: 111717
Summary: syntax error When CTAD encounters complex alias
template
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111634
--- Comment #2 from CVS Commits ---
The master branch has been updated by Pan Li :
https://gcc.gnu.org/g:a809a556dc0792a34fca7b754ff96ea3ea7d1e7f
commit r14-4443-ga809a556dc0792a34fca7b754ff96ea3ea7d1e7f
Author: Pan Li
Date: Sat Oct 7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111643
--- Comment #14 from Lukas Grätz ---
(In reply to Andrew Pinski from comment #13)
> (In reply to Andrew Pinski from comment #12)
> > Gcc does have tail call optimization which should allow the instrumentation
> > with less overhead. Though
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111643
--- Comment #11 from Lukas Grätz ---
(In reply to Alexander Monakov from comment #10)
> (In reply to Lukas Grätz from comment #9)
> > I also wondered whether
> >
> > int bar_alias (void) { return bar_original(); }
> >
> > could be a portable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111643
--- Comment #13 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #12)
> Gcc does have tail call optimization which should allow the instrumentation
> with less overhead. Though tail call optimization happens at -O2 and above
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
Mathieu Malaterre changed:
What|Removed |Added
Attachment #56065|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
--- Comment #14 from Mathieu Malaterre ---
(In reply to Xi Ruoyao from comment #12)
> (In reply to Mathieu Malaterre from comment #10)
> > I could not reduce to a single *.cc file. The function needs to be in an alt
> > file 'foo.cc'.
>
> Can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
Mathieu Malaterre changed:
What|Removed |Added
Attachment #55816|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111702
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111701
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111711
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111711
--- Comment #2 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> It was introduced by r14-2667-gceae1400cf24f329393e96dd9720 .
>
> We have:
> long int x;
> int _3;
> _Bool _5;
> _3 = 0 / 0;
> _5 = _3 == 822920;
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111260
Andrew Pinski changed:
What|Removed |Added
Component|target |middle-end
Summary|arm: ice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111260
Andrew Pinski changed:
What|Removed |Added
Target|arm-linux-gnueabihf |arm-*-* aarch64-*-*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111260
--- Comment #6 from Andrew Pinski ---
*** Bug 111711 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111711
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111260
--- Comment #8 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #7)
> Better reduced testcase:
> ```
> long f(int a)
> {
> int b = 822920;
> int t = a == b;
> return t * (long)b;
> }
> ```
Here is one that ICEs on both arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111712
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109088
--- Comment #14 from Richard Biener ---
Sorry for the delay - but this looks exactly like Robins transform to COND_ADD,
no? But sure, the current code doesn't handle a reduction path through
multiple stmts but when if-conversion would convert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111709
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |13.3
--- Comment #9 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111677
--- Comment #2 from Gianfranco ---
Thanks, Debian syncs the branch fixes from time to time,
last time was up to
* Update to git 20230913 from the gcc-13 branch.
Indeed, I requested to sync again sources.
thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111699
--- Comment #6 from CVS Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:e77428a9a336f57e3efe3eff95f2b491d7e9be14
commit r14-4432-ge77428a9a336f57e3efe3eff95f2b491d7e9be14
Author: Andrew Pinski
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111699
Andrew Pinski changed:
What|Removed |Added
Target Milestone|14.0|13.3
Known to work|13.2.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111711
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Keywords|needs-bisection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111260
--- Comment #7 from Andrew Pinski ---
Better reduced testcase:
```
long f(int a)
{
int b = 822920;
int t = a == b;
return t * (long)b;
}
```
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111713
Bug ID: 111713
Summary: libstdc++ accepts regular expression
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111712
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104255
Patrick Palka changed:
What|Removed |Added
CC||hewillk at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111713
--- Comment #1 from 康桓瑋 ---
The "+*" part is not valid.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111713
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111708
--- Comment #3 from Kirill Frolov ---
Looks like example demonstrates undefined behaviour. This article
(https://wiki.sei.cmu.edu/confluence/display/c/DCL36-C.+Do+not+declare+an+identifier+with+conflicting+linkage+classifications)
contains
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111708
--- Comment #4 from Kirill Frolov ---
With updated source ICC still gives an error.
MSVC works from my point of view correcly, same as Clang.
Lets see to a C-standard
(https://files.lhmouse.com/standards/ISO%20C%20N2176.pdf),
section 6.2.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111708
--- Comment #5 from Kirill Frolov ---
C standard states,that:
6.2.2 Linkages of identifiers
7) If, within a translation unit, the same identifier appears with both
internal and external linkage, the behavior is undefined.
So, I think only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111685
--- Comment #12 from Fedor Chelnokov ---
Related discussion: https://stackoverflow.com/q/77224270/7325599
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111714
Bug ID: 111714
Summary: Strange behavior when casting std::size_t to bool, UB
or compiler bug?
Product: gcc
Version: 9.4.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111700
David Malcolm changed:
What|Removed |Added
Last reconfirmed||2023-10-06
Ever confirmed|0
61 matches
Mail list logo
