https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109788
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
Version|13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109790
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109791
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109773
--- Comment #2 from CVS Commits ---
The master branch has been updated by Kito Cheng :
https://gcc.gnu.org/g:69f3914414a303f0e2c8246e08925f90c207846c
commit r14-647-g69f3914414a303f0e2c8246e08925f90c207846c
Author: Juzhe-Zhong
Date: Tue May
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93178
Jiu Fu Guo changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106708
--- Comment #3 from Jiu Fu Guo ---
With the trunk, for
*arg++ = 0x98765432ULL;
*arg++ = 0x7cdeab55ULL;
are expected.
For *arg++ = 0x6543ULL; lis+xoris are not committed to the trunk
yet.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109756
--- Comment #10 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:39d6d4256d16d676f8b9031c4d1d115ddf4ad76b
commit r14-650-g39d6d4256d16d676f8b9031c4d1d115ddf4ad76b
Author: Jakub Jelinek
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99195
--- Comment #11 from CVS Commits ---
The master branch has been updated by Kyrylo Tkachov :
https://gcc.gnu.org/g:d1e7f9993084b87e6676a5ccef3c8b7f807a6013
commit r14-651-gd1e7f9993084b87e6676a5ccef3c8b7f807a6013
Author: Kyrylo Tkachov
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99195
--- Comment #12 from CVS Commits ---
The master branch has been updated by Kyrylo Tkachov :
https://gcc.gnu.org/g:c8977cf5f2daa9fecfc5d67a737506d0d31c578a
commit r14-653-gc8977cf5f2daa9fecfc5d67a737506d0d31c578a
Author: Kyrylo Tkachov
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109670
--- Comment #12 from Thomas Neumann ---
Created attachment 55037
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55037&action=edit
radix sort fix
I could reproduce the problem, the radix sort did not behave correctly when we
ran out of bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99195
--- Comment #13 from CVS Commits ---
The master branch has been updated by Kyrylo Tkachov :
https://gcc.gnu.org/g:3ed5677bb61b334a2d01c769859cdd3279e12a07
commit r14-654-g3ed5677bb61b334a2d01c769859cdd3279e12a07
Author: Kyrylo Tkachov
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108157
--- Comment #2 from simon at pushface dot org ---
Still present in 13.1.0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109759
--- Comment #2 from Martin Jambor ---
Likely a duplicate of PR 109788.
I'll close the bug as such if it does not manifest itself over the weekend
ubsan bootstrap.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109788
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:395a75593ef87a68a04111bb08243b5d9a811f45
commit r14-656-g395a75593ef87a68a04111bb08243b5d9a811f45
Author: Jakub Jelinek
Date: We
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109788
--- Comment #6 from Jakub Jelinek ---
What remains is some Fortran FE change. The function seems to be called with 6
arguments that the runtime actually expects, so there is some chance that it
works, but
some of the arguments have incompatible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109009
--- Comment #6 from Surya Kumari Jangala ---
Continuing with the analysis of the test cases specified in comment 5, here are
some findings:
After graph colouring, when we do improve_allocation(), we find that in the
failing test case, the hard_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109393
--- Comment #4 from manolis.tsamis at vrull dot eu ---
(In reply to Richard Biener from comment #3)
> It's probably a mismatch of GENERIC/GIMPLE folding. In this case it's
> pointer_int_sum prematurely distributing the multiplication:
>
> /* Re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97700
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109796
Bug ID: 109796
Summary: 548.exchange2_r compiled with -O2 -flto regressed by
5% on aarch64 between r14-135-gd06e9264b0192c and
r14-192-g636e2273aec555
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109797
Bug ID: 109797
Summary: 456.hmmer compiled with -O2 -flto regressed by 15% on
AMD zen3 between r14-487-g6f18f344338b37 and
r14-540-gb7fe38c14e5f1b
Product: gcc
V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109797
--- Comment #1 from Andrew Pinski ---
Maybe:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=919642fa4b2bc4c32910336dd200d53766801c80
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
--- Comment #33 from Jakub Jelinek ---
That would indeed simplify things and auto_vec member would be unnecessary, nor
any of the length/allocated members etc. All we'd need is just a pointer and
small size buffer (and is_small check would be p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109797
Martin Jambor changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109798
Bug ID: 109798
Summary: Gnat Bug Detected
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
Assignee: unas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109799
Bug ID: 109799
Summary: *= used in a declaration when trying to do default
argument with a pointer type could give a better error
message
Product: gcc
Version: 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109799
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109800
Bug ID: 109800
Summary: [11/12/13/14 Regression] arm: ICE (segfault) loading
double with -mpure-code -mbig-endian
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109801
Bug ID: 109801
Summary: -Wmaybe-uninitialized warning with -O1 on move
constructor
Product: gcc
Version: 12.1.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109801
--- Comment #1 from Andrew Pinski ---
Note in GCC 13 and above we give an extra warning too:
: In function 'int main()':
:30:49: warning: moving a temporary object prevents copy elision
[-Wpessimizing-move]
30 | table container(std::move(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109801
--- Comment #2 from Scott Zhong ---
Constructing a container and then moving it to a second container causes this
warning to popup. In this case, container1 is not temporary.
int main()
{
table container1;
// (... do something with cont
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109802
Bug ID: 109802
Summary: [regression] during IPA pass: analyzer: internal
compiler error (using dubious flexible arrays in
unions)
Product: gcc
Version: 13.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109802
--- Comment #1 from Alejandro Colomar ---
Please use this:
Reported-by: Alejandro Colomar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109802
--- Comment #2 from Alejandro Colomar ---
Here's a simplified version that will cause the same internal compiler error.
This one will probably cause less brain damage to readers,
as it has significantly less magic.
$ cat flexi2.c
#include
#i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107888
--- Comment #9 from Andrew Pinski ---
By the way this does show up in GCC itself.
in worse_state in ipa-pure-const.cc where it does MAX of bools
and for x86's internal_min_issue_delay in insn-automata.cc
The below is the similar code to what is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109802
--- Comment #3 from Alejandro Colomar ---
Hmm, I should have used offsetof(3) in a few placed to avoid issues due to
padding, but I was lucky :).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109797
--- Comment #3 from Uroš Bizjak ---
(In reply to Andrew Pinski from comment #1)
> Maybe:
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;
> h=919642fa4b2bc4c32910336dd200d53766801c80
Is this with -msse4? In case of TARGET_SSE4_1 the revision just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109802
--- Comment #4 from Alejandro Colomar ---
(In reply to Alejandro Colomar from comment #3)
> Hmm, I should have used offsetof(3) in a few placed to avoid issues due to
> padding, but I was lucky :).
Oh, no, I didn't need it. I got it right. Ne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109788
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109788
--- Comment #8 from Jakub Jelinek ---
That feels like ABI incompatible change.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109788
--- Comment #9 from Jakub Jelinek ---
Of course, if libgfortran plans to bump soname for GCC 14, that would be ok,
but not ok otherwise (you could e.g. keep the old symbol as is and add a
differently named entrypoint that used the new prototype)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109624
--- Comment #1 from CVS Commits ---
The master branch has been updated by Bernhard Reutner-Fischer
:
https://gcc.gnu.org/g:39f7c0963a9c009e6c9b98e95dbba31cccb07329
commit r14-664-g39f7c0963a9c009e6c9b98e95dbba31cccb07329
Author: Bernhard Reutn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107888
Andrew Pinski changed:
What|Removed |Added
Attachment #55026|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109751
--- Comment #21 from Patrick Palka ---
(In reply to Luke Dalessandro from comment #15)
> 3. A fix for this issue in boost and the iterator_interface is to use a
> constrained member function rather than attempting to use a constrained
> friend f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109803
Bug ID: 109803
Summary: [12 Regression] ICE with type defined in lambda inside
generic lambda inside function template
Product: gcc
Version: 12.3.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109803
Andrew Pinski changed:
What|Removed |Added
Keywords||ice-on-valid-code
Target Milestone|--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109803
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109241
Marek Polacek changed:
What|Removed |Added
Resolution|FIXED |---
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109241
Marek Polacek changed:
What|Removed |Added
CC||rs2740 at gmail dot com
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109803
Marek Polacek changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92658
--- Comment #26 from CVS Commits ---
The master branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:608e7f3ab47fe746279c552c3574147aa3d8ee76
commit r14-666-g608e7f3ab47fe746279c552c3574147aa3d8ee76
Author: Uros Bizjak
Date: Wed Ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109738
--- Comment #2 from Jonathan Wakely ---
(In reply to Scott Zhong from comment #0)
> The debugger showed during resolution of spaceship operator, the implicit
> conversion to const char* for StringWrapper is selected instead of
> StringWrapper::o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109804
Bug ID: 109804
Summary: internal compiler error in gimple-ssa-warn-access.cc
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109804
--- Comment #1 from Christian Prochaska
---
Created attachment 55043
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55043&action=edit
test.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109774
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=109804
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109804
--- Comment #3 from Marek Polacek ---
Started with r11-6507
commit fd64f348a6b40621dc2bcc743f5fdfb31ed0894c
Author: Martin Sebor
Date: Wed Jan 6 13:36:18 2021 -0700
PR c++/98305 spurious -Wmismatched-new-delete on template instance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109804
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed|2023-05-10 00:00:00 |
Ever confirmed|1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109804
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109804
--- Comment #5 from Andrew Pinski ---
Created attachment 55044
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55044&action=edit
reduced as much as I could get it for the trunk (note GCC 11 fails still too)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109804
--- Comment #6 from Andrew Pinski ---
Note the ICE moved from maybe_emit_free_warning in expand.c in GCC 11 to
new_delete_mismatch_p in gimple-ssa-warn-access.cc in GCC 12+.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109804
--- Comment #7 from Andrew Pinski ---
I am suspecting the `unnamed enum` is causing the ICE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109804
--- Comment #8 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #7)
> I am suspecting the `unnamed enum` is causing the ICE.
I mean the local unnamed enums is what is exposing the ICE. Naming either of
them and the ICE goes away.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109788
--- Comment #10 from anlauf at gcc dot gnu.org ---
Can you tell whether you see other intrinsics with bad FUNCTION_TYPE?
E.g. if we have a similar issue with pack_char or pack_s_char?
In that case I have a vague idea why it happens, but do not y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109788
--- Comment #11 from Jakub Jelinek ---
If you e.g. put breakpoint on the spot I changed and stopon the testcase with
-Os when t == global_trees[TI_VOID_LIST_NODE] you can then see in e->callee the
FUNCTION_TYPE with just 5 arguments.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109804
--- Comment #9 from Marek Polacek ---
Right. Local unnamed enums are of the DEMANGLE_COMPONENT_UNNAMED_TYPE type,
but those don't have their subtrees filed as per cplus_demangle_fill_component.
So I think we can't do *newc.u.s_binary.left when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109680
--- Comment #9 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:4c2ffb02fd4104d77c5d907662f04434dc4c3fe8
commit r14-669-g4c2ffb02fd4104d77c5d907662f04434dc4c3fe8
Author: Marek Polacek
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109680
Marek Polacek changed:
What|Removed |Added
Summary|[13/14 Regression] |[13 Regression]
|is_c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109772
--- Comment #4 from Jonathan Wakely ---
There's another problem which is that hh_mm_ss>>
fails to compile:
/home/jwakely/gcc/13/include/c++/13.0.1/chrono: In instantiation of 'class
std::chrono::hh_mm_ss > >':
hms.cc:12:63: required from here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87726
Sergio Durigan Junior changed:
What|Removed |Added
CC||sergiodj at sergiodj dot net
---
x27;m convinced it's something else.
I've compiled gcc (GCC) 14.0.0 20230510 from the master branch
(608e7f3ab47fe746279c552c3574147aa3d8ee76), and I still can reproduce the
problem.
A simple reproducer for the problem follows:
$ echo 'int main(){}' > foo.c $ ~/gcc/install/b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109805
--- Comment #1 from Sergio Durigan Junior ---
The formatting for the example snippet got messed up. Here's a fixed version:
$ echo 'int main(){}' > foo.c
$ ~/gcc/install/bin/gcc -c foo.c -O2 -g -flto=auto -ffat-lto-objects
-fdebug-prefix-map=`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109806
Bug ID: 109806
Summary: 13.1.0 cc1plus stack smashing crash with C array of
complex structs
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109806
--- Comment #1 from Andrew Pinski ---
>it's 1.6MB, so it was impossible to attach them here uncompressed
Can you try to compress it and attach it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87726
--- Comment #4 from Andrew Pinski ---
*** Bug 109805 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109805
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109805
Andrew Pinski changed:
What|Removed |Added
Resolution|DUPLICATE |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
--- Comment #34 from Aldy Hernandez ---
Excellent ideas!
For that matter, we may get away with defaulting to 3 sub-ranges and always
resizing as needed (up to MAX). Needing more than 3 sub-ranges is so rare
(less than 0.5% of the time), that t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
--- Comment #35 from Aldy Hernandez ---
We could also tweak the number of sub-ranges. 8 (??) also sounds good for a
few percent less in performance drop, if we care.
p.s. I did try the auto_vec thing for a 25% loss in VRP performance, even whe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109797
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-*
--- Comment #4 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109807
Bug ID: 109807
Summary: [14 Regression] sse2-mmx-pmaddwd.c met ICE after
commit gcc-14-666-g608e7f3ab47 with march=cascadelake
Product: gcc
Version: 14.0
Status: UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109800
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |11.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109804
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109805
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109806
Richard Biener changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109807
--- Comment #1 from Haochen Jiang ---
I further checked the reason, V2SI should never dropped into that function
because we have no pattern under V2SI.
I suppose it is because -march=cascadelake will open SSE4.1, with the new
pattern, it wrongl
85 matches
Mail list logo
