https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107948
--- Comment #3 from Geoffrey ---
(In reply to CVS Commits from comment #1)
> The master branch has been updated by David Malcolm :
>
> https://gcc.gnu.org/g:0b737090a69624dea5318c380620283f0321a92e
>
> commit r13-4456-g0b737090a69624dea5318c38
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107953
--- Comment #4 from Ondřej Majerech ---
It seems that the core of PR 57 is that `A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107953
--- Comment #3 from Andrew Pinski ---
I wonder if this is still an ambiguous part of the C++ grammar and all.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107953
--- Comment #2 from Andrew Pinski ---
Even template defaults has issues:
template y; }>
int t = 0;
Which is why I Pointed to PR 57.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107851
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107874
--- Comment #23 from Jerry DeLisle ---
John,
Your original case in Comment 1 now gives:
$ gfc original.f90
$ ./a.out
tstuff
fstuff
T
tstuff
fstuff
F
So I think it is OK, Harald's test case has function calls embedded in the
print sta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107874
--- Comment #22 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:36a4ee406b95ae24a59b8b3f8ebe29af6fd5261e
commit r13-4473-g36a4ee406b95ae24a59b8b3f8ebe29af6fd5261e
Author: Harald Anlauf
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107851
--- Comment #1 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:f5758fe5b430ef3447fbab947fcea32a1d995f36
commit r13-4471-gf5758fe5b430ef3447fbab947fcea32a1d995f36
Author: David Malcolm
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107874
--- Comment #21 from john.harper at vuw dot ac.nz ---
I now have a new test case that avoids the possibility of recursive I/O
by tstuff and fstuff doing internal writes to two different character
variables. It still reveals the merge problem. It
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107874
--- Comment #20 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #19)
> I don't recall having seen a mentioning in the standard of the order of
> evaluation of different function (or subroutine) arguments. Do you?
The closest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107950
--- Comment #5 from Andrew Pinski ---
It might be the case the object files were unused in the archive so they are
not linked in the LTO front-end but now with using LTO partial linking, they
are pulled in always.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107874
--- Comment #19 from anlauf at gcc dot gnu.org ---
(In reply to john.harper from comment #18)
> An interesting problem! But I thought my original test case did not have
> recursive I/O because tstuff and fstuff each print something in the
> sta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107954
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99576
Iain Sandoe changed:
What|Removed |Added
Target Milestone|--- |10.5
--- Comment #15 from Iain Sandoe ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107874
--- Comment #18 from john.harper at vuw dot ac.nz ---
An interesting problem! But I thought my original test case did not have
recursive I/O because tstuff and fstuff each print something in the
statement
y = merge(tstuff(),fstuff(),x(i))
b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107953
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88434
Andrew Pinski changed:
What|Removed |Added
Status|SUSPENDED |NEW
--- Comment #5 from Andrew Pinski -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107874
--- Comment #17 from anlauf at gcc dot gnu.org ---
(In reply to Jerry DeLisle from comment #16)
> (In reply to anlauf from comment #15)
> --- snip ---
> > Can you please verify?
>
> Yes, this fixes the test case.
OK, thanks for confirming.
> H
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107874
--- Comment #16 from Jerry DeLisle ---
(In reply to anlauf from comment #15)
--- snip ---
> Can you please verify?
Yes, this fixes the test case. However if the orginal test case is valid
fortran we probably need to fix something else. Paul Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107954
Bug ID: 107954
Summary: Support -std=c23/gnu23 as aliases of -std=c2x/gnu2x
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107950
--- Comment #4 from Jonathan Wakely ---
The vtable will only be emitted in the TU containing the key function, which is
that get_text function defined in the front end.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103081
Patrick Palka changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107950
--- Comment #3 from Martin Liška ---
(In reply to Richard Biener from comment #2)
> I wonder why the linker complains? Isn't this like
>
> t.h
>
> class X { foo (); bar (); baz (); };
>
> and splitting the foo/bar/baz implementations to thre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107078
--- Comment #18 from Martin Liška ---
> This issue is about compiler issue on linking firebird binary linked with
> LTO.
Good, so it's isql command that crashes:
make gpre
make[2]: Entering directory '/tmp/firebird-4.0.2/gen'
rm -f metadata.fd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107078
--- Comment #17 from Tomasz Kłoczko ---
> /tmp/firebird-4.0.2/gen/Release/firebird/bin/isql -q -i
> /tmp/firebird-4.0.2/src/dbs/metadata.sql
> can't format message 17:0 -- message file /usr/local/firebird/firebird.msg
> not found
> Unable to com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107078
--- Comment #16 from Martin Liška ---
(In reply to Tomasz Kłoczko from comment #15)
> (In reply to Martin Liška from comment #14)
> > Can you please provide the exact steps on how to configure the project with
> > the corresponding options and r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107874
--- Comment #15 from anlauf at gcc dot gnu.org ---
Created attachment 54006
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54006&action=edit
Modified testcase
I found that I get a hang on my system when I specify -fopenmp.
It appears that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107828
--- Comment #2 from Martin Jambor ---
I don't see any correctness issue here. It is true that when IPA-SRA
needs to create a temporary SSA_NAME for an assignment with
VIEW_CONVERT_EXPR (that is the only statement that extra_stmts can
contain at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107953
Bug ID: 107953
Summary: Greater-than operator misparsed inside a lambda
expression used as a template argument
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107951
--- Comment #8 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #7)
>
> Because after all those years, you don't really know if it is just glibc
> (which likely doesn't do that anymore), but many other programs in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107951
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107078
--- Comment #15 from Tomasz Kłoczko ---
(In reply to Martin Liška from comment #14)
> Can you please provide the exact steps on how to configure the project with
> the corresponding options and run the crashing command? I would like to
> attach
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107951
--- Comment #6 from qinzhao at gcc dot gnu.org ---
after reading the history, my understanding is:
this gcc extension is added as a workaround to build glibc since glibc source
code has such usage of flexible array members;
my question is: why
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107951
Siddhesh Poyarekar changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77650
Siddhesh Poyarekar changed:
What|Removed |Added
CC||siddhesh at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107023
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107949
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2022-12-02
Component|target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107951
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107951
--- Comment #3 from Andrew Pinski ---
r0-44662-g2984fe64968ad7 added that documentation.
PR 15749 shows that at one point there was code floating around (glibc?) that
uses the extension (_G_iconv_t).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107767
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107951
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
CC||qinzhao at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107767
--- Comment #11 from Jakub Jelinek ---
(In reply to Martin Liška from comment #7)
> However, the CFG is not collapsed and thus it fails due to:
>
> bool
> bit_test_cluster::is_beneficial (unsigned count, unsigned uniq)
> {
> return (((uniq ==
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107767
--- Comment #10 from Richard Biener ---
Looks like a general CFG optimization if we have N forwarders to a PHI with the
same value then we can merge them to one (it's enough to have a single
forwarder which we can use as the remaining one even).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107767
--- Comment #9 from Jakub Jelinek ---
Indeed, comparing that to
int firewall3(const uint8_t *restrict data) {
const uint16_t dst_port = *((const uint16_t *)data + 32);
switch (dst_port) {
case 15: return 1;
case 23: return 1;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107767
--- Comment #8 from Коренберг Марк ---
Okay, but why switch-case is not handled using fast implementation using masks
(when difference between smallest and biggest integer <=64 ?
See the first function in my first message where it works as expe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107767
Martin Liška changed:
What|Removed |Added
Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107950
--- Comment #2 from Richard Biener ---
I wonder why the linker complains? Isn't this like
t.h
class X { foo (); bar (); baz (); };
and splitting the foo/bar/baz implementations to three TUs and then linking
two of them partially?
That is, i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107767
--- Comment #6 from Martin Liška ---
> this code should not be treated as if-else-if-else-if.
Why? It's an equivalent representation as all ifs have a return statement. One
another equivalent representation is:
switch (dst_port)
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107767
--- Comment #5 from Коренберг Марк ---
Not only -s problem. I think -O3 in gcc 12.2 will run faster than -O3 in gcc 13
(for this case). this code should not be treated as if-else-if-else-if. gcc 12
does its job right.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107938
Jakub Jelinek changed:
What|Removed |Added
Summary|[11/12/13 Regression] ICE |[11/12/13 Regression] ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107622
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107951
Richard Biener changed:
What|Removed |Added
Keywords||accepts-invalid
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107946
--- Comment #4 from Richard Biener ---
The data found for other machines/flags is also rather inconclusive with ups
and downs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107767
--- Comment #4 from Martin Liška ---
So the optimization is enabled after r13-1184-g57424087e82db140 where we newly
convert if-else-if series to switch, that's later converted by switch
conversion pass to the array lookup.
Now the question is w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107939
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107622
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|marxin at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105221
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107952
Bug ID: 107952
Summary: tree-object-size: inconsistent size for flexible
arrays nested in structs
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107833
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106739
Martin Liška changed:
What|Removed |Added
Resolution|--- |INVALID
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107078
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #14 from Martin Lišk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107951
Bug ID: 107951
Summary: Invalid flexible array use not detected in nested
structs by the C frontend
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106462
--- Comment #5 from CVS Commits ---
The master branch has been updated by Vladimir Makarov :
https://gcc.gnu.org/g:70596a0fb2a2ec072e1e97e37616e05041dfa4e5
commit r13-4466-g70596a0fb2a2ec072e1e97e37616e05041dfa4e5
Author: Vladimir N. Makarov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107833
--- Comment #13 from rguenther at suse dot de ---
On Fri, 2 Dec 2022, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107833
>
> --- Comment #12 from Jakub Jelinek ---
> So, do we whack-a-mole in this case some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106048
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P4
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107586
Martin Liška changed:
What|Removed |Added
Resolution|--- |INVALID
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106739
--- Comment #3 from Jakub Jelinek ---
Can't reproduce this, neither with 10, 11, 12 nor 2022-08-25ish trunk nor
current trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107551
Martin Liška changed:
What|Removed |Added
Target Milestone|--- |12.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107698
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106558
--- Comment #21 from Martin Liška ---
*** Bug 107698 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106805
--- Comment #4 from Jakub Jelinek ---
That said, perhaps for now committing the patch without the pr106805.c testcase
and work incrementally on the other issues might be a good idea.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107747
Martin Liška changed:
What|Removed |Added
Resolution|--- |INVALID
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106805
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107950
--- Comment #1 from Martin Liška ---
Oh, the function has 2 different definitions in C and C++ FE:
gcc/c/c-objc-common.cc:range_label_for_type_mismatch::get_text (unsigned
/*range_idx*/) const
gcc/cp/error.cc:range_label_for_type_mismatch::get_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107950
Martin Liška changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org
Last recon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107950
Bug ID: 107950
Summary: partial LTO linking of libbackend.a:
gcc/gcc-rich-location.cc:207: undefined reference to
`range_label_for_type_mismatch::get_text(unsigned int)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107046
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107837
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107949
--- Comment #1 from Jens Seifert ---
hash2 is only provided to show how the code should look like (without rlwinm).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84469
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106577
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
St
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107833
--- Comment #12 from Jakub Jelinek ---
So, do we whack-a-mole in this case some more and try harder in
mark_ssa_maybe_undefs
by basically repeating the CCP4 UNDEFINED propagation, or invent some new stmt
or marking that IVOPTS could use before t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107396
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2022-12-02
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107903
Martin Liška changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106577
--- Comment #4 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:b3237a2c6847993f92218b65f96ece9831a8bfb0
commit r13-4462-gb3237a2c6847993f92218b65f96ece9831a8bfb0
Author: Jakub Jelinek
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107934
Martin Liška changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84469
--- Comment #9 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:f13305518558f20ef2d460a74eb29dad5fce1350
commit r13-4461-gf13305518558f20ef2d460a74eb29dad5fce1350
Author: Jakub Jelinek
Date: Fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84469
--- Comment #8 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:ee4f25999f6832a1c5060b9277222c03d852709a
commit r13-4460-gee4f25999f6832a1c5060b9277222c03d852709a
Author: Jakub Jelinek
Date: Fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107920
--- Comment #14 from prathamesh3492 at gcc dot gnu.org ---
Posted patch:
https://gcc.gnu.org/pipermail/gcc-patches/2022-December/607714.html
Thanks,
Prathamesh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107499
--- Comment #3 from Martin Liška ---
> I'll wait for more
> LNT results before investigating. See
> https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=465.70.0
Apparently, the numbers are good again now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107833
--- Comment #11 from Richard Biener ---
(In reply to Andrew Pinski from comment #10)
> (In reply to Jakub Jelinek from comment #9)
> > Wasn't this discussed in the past in other PRs? Whether uninitialized vars
> > mean anything or anything but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107949
Bug ID: 107949
Summary: PPC: Unnecessary rlwinm after lbzx
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
92 matches
Mail list logo
