https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106723
--- Comment #1 from Richard Biener ---
I wonder if the generator should simply skip mode combinations when a mode
attribute fails to expand? That could be also used as "conditional iteration"
using a mode attribute expanding to "".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106724
--- Comment #3 from Richard Biener ---
we usually define logical-op-non-short-circuit based on branch cost
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99888
--- Comment #10 from Kewen Lin ---
By searching the history of this feature, I found its initial versions only
proposed to place nops after the function entry, such as: v2[1], then it's
requested to be more generic to handle some "exploited atomi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106725
Richard Biener changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99888
--- Comment #11 from Kewen Lin ---
Oops, the reference links in #c10 are:
[1] https://gcc.gnu.org/pipermail/gcc-patches/2016-September/458210.html
[2] https://gcc.gnu.org/pipermail/gcc-patches/2016-September/458287.html
[3] https://gcc.gnu.org/p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106727
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106723
--- Comment #2 from Jakub Jelinek ---
I think better would be to error out (or just warn) if we see a valid mode/code
attribute which doesn't handle the corresponding mode/code.
For the PR106721, that would diagnose all but the last issue where
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106731
Bug ID: 106731
Summary: ICE on automatic array of derived type with DTIO
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106731
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106459
Paul Hua changed:
What|Removed |Added
CC||paul.hua.gm at gmail dot com
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106646
--- Comment #4 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:365202625d2f2d6694dba889ca67498fefb59c68
commit r13-2167-g365202625d2f2d6694dba889ca67498fefb59c68
Author: Jakub Jelinek
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106701
rdapp at gcc dot gnu.org changed:
What|Removed |Added
Target|s390|s390 x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106732
Bug ID: 106732
Summary: lock cannot be generated in a special case
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106721
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:846e5c009e360f0c4fe58ff0d3aee03ebe3ca1a9
commit r13-2168-g846e5c009e360f0c4fe58ff0d3aee03ebe3ca1a9
Author: Jakub Jelinek
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106646
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98940
Bug 98940 depends on bug 106646, which changed state.
Bug 106646 Summary: [C++23] P2437R1 - Support for #warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106646
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106726
Martin Liška changed:
What|Removed |Added
CC||matmal01 at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106731
--- Comment #2 from federico ---
For the sake of completeness, fixed-size does not cause an ICE:
type(t) :: fixed(5) ! works
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069
vincent at systemli dot org changed:
What|Removed |Added
CC||vincent at systemli dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106701
--- Comment #2 from Richard Biener ---
I'd say all single-operation magic shouldn't happen in match.pd, this really
looks like something for RTL expansion to decide. For example some targets
might have instructions that can either do cst - a or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66995
--- Comment #2 from Jonathan Wakely ---
(In reply to Andrew Pinski from comment #1)
> So this is DR317.
And the new rule first appeared in C++11.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106729
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66995
Jonathan Wakely changed:
What|Removed |Added
CC||whh8b at obs dot cr
--- Comment #3 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66995
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed|2021-08-04 00:00:00 |2022-8-24
--- Comment #4 from Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106101
--- Comment #19 from Segher Boessenkool ---
(In reply to Andreas Krebbel from comment #18)
> (In reply to Segher Boessenkool from comment #17)
> ...
> > Yes, but that says the high 48 bits of the hardware reg are untouched, which
> > is not true
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106701
--- Comment #3 from rdapp at gcc dot gnu.org ---
I though expand (or combine) were independent of value range. What would be the
proper place for it then?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103629
--- Comment #22 from Mathieu Malaterre ---
Created attachment 53501
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53501&action=edit
working save-temps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103629
--- Comment #23 from Mathieu Malaterre ---
Created attachment 53502
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53502&action=edit
non-working save-temps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103629
--- Comment #24 from Mathieu Malaterre ---
I have change the openvdb.cc code into:
% cat openvdb.cc
#include "Tree.h"
static std::string do_segfault() { return Tree::treeType(); }
#ifdef VIS
__attribute__((visibility("default")))
#endif
void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103629
--- Comment #25 from Mathieu Malaterre ---
Looks like there is an easy fix (work-around?):
% cat Tree.h
#pragma once
#include
#include
class
#ifdef VIS
__attribute__((visibility("default")))
#endif
Tree {
public:
static const std::string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103629
--- Comment #26 from Mathieu Malaterre ---
This may be related to:
* https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62280
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106729
--- Comment #2 from Will Hawkins ---
Thanks for the feedback, Jonathan. Sorry for the duplicate.
Will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66995
--- Comment #5 from Will Hawkins ---
Not sure that I will have any success, but I'd like to give fixing this issue a
try. I will keep you posted.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106589
--- Comment #6 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:219d9f61a241d370b7933aecae56ce0905465830
commit r12-8711-g219d9f61a241d370b7933aecae56ce0905465830
Author: Jonathan Wake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106589
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106733
Bug ID: 106733
Summary: bpf: facilitate constant propagation of function
addresses
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106733
--- Comment #1 from CVS Commits ---
The master branch has been updated by Jose E. Marchesi :
https://gcc.gnu.org/g:6d1f144b3e6e3761375bea657718f58fb720fb44
commit r13-2173-g6d1f144b3e6e3761375bea657718f58fb720fb44
Author: Jose E. Marchesi
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106734
Bug ID: 106734
Summary: [requires] std::same_as in compound requirements
doesn't produce expected result
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Sever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106733
--- Comment #2 from Jose E. Marchesi ---
Urgh I obviously meant bpf-unknown-none.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106734
--- Comment #1 from jakob at schmutz dot co.uk ---
> but instead it returns
>
> ```
> IS SAME
> REQUIRES SAME
> CONVERTIBLE
> ```
whoops this was supposed to be
```
AS SAME
IS SAME
CONVERTIBLE
```
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106733
Jose E. Marchesi changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106734
--- Comment #2 from jakob at schmutz dot co.uk ---
Created attachment 53503
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53503&action=edit
preprocessed file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106701
--- Comment #4 from rguenther at suse dot de ---
On Wed, 24 Aug 2022, rdapp at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106701
>
> --- Comment #3 from rdapp at gcc dot gnu.org ---
> I though expand (or combine) wer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106734
--- Comment #3 from Jonathan Wakely ---
(In reply to jakob from comment #0)
> Bar bar;
> constexpr bool same = requires
> {
> { bar } -> std::same_as;
This is false. The type of decltype((bar)) is Bar&.
So I think GCC is co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106734
--- Comment #4 from jakob at schmutz dot co.uk ---
(In reply to Jonathan Wakely from comment #3)
> (In reply to jakob from comment #0)
> > Bar bar;
> > constexpr bool same = requires
> > {
> > { bar } -> std::same_as;
>
> Thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106734
--- Comment #5 from jakob at schmutz dot co.uk ---
oh I see `std::same_as` is false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106734
jakob at schmutz dot co.uk changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106652
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106734
--- Comment #7 from Jonathan Wakely ---
decltype(bar) and decltype((bar)) are not the same type.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106669
Hannes Hauswedell changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106652
Jakub Jelinek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91213
Andrew Pinski changed:
What|Removed |Added
CC||jens.seifert at de dot ibm.com
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106701
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91213
Andrew Pinski changed:
What|Removed |Added
Assignee|pinskia at gcc dot gnu.org |unassigned at gcc dot
gnu.org
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106723
--- Comment #3 from Richard Earnshaw ---
I think we should error if the name matches some iteration values, but not
others. If is valid in the assembler output 'as-is' then it's bad form
to have an attribute that overloads this - and the fix i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106724
--- Comment #4 from Andrew Pinski ---
(In reply to Richard Biener from comment #3)
> we usually define logical-op-non-short-circuit based on branch cost
Right, I think this definition was copied from the MIPS backend even which is
wrong there t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106728
--- Comment #1 from Andrew Pinski ---
> g++ -std=c++11 iterate.cpp -o "Z:\28sec\out.exe"
Does `g++ -c -std=c++11 iterate.cpp -o "\\machine_name\d\performance
testing\t.o" ` work?
Also if it is failing like this, it is not a problem with GCC r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106725
--- Comment #2 from Daniel Thornburgh ---
(In reply to Richard Biener from comment #1)
> If GCC, with LTO, would partition the program into two LTRANS partitions,
> one containing main and bar and one containing foo then applying this
> optimiza
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106652
--- Comment #3 from Jakub Jelinek ---
Testcase for the already implemented features:
// P1467R9 - Extended floating-point types and standard names.
// { dg-do compile { target c++23 } }
// { dg-options "" }
namespace std
{
#ifdef __STDCPP_FLO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102146
Segher Boessenkool changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106652
--- Comment #4 from joseph at codesourcery dot com ---
Regarding mangling: I expect this change should fix bug 85518.
General: I expect some glibc header changes might be appropriate, where
they currently assume __FloatN keywords aren't suppor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106731
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106718
--- Comment #2 from Navid Rahimi ---
Thanks for clarifying it. I was able to fix a bug somewhere else with your
explanation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106718
Navid Rahimi changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103694
--- Comment #8 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:55d8c5409325001c89c35c3d04d425dec9127146
commit r13-2177-g55d8c5409325001c89c35c3d04d425dec9127146
Author: Harald Anlauf
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106600
--- Comment #3 from CVS Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:cb2daf5acce003300ee948a89860c0d13ebcae79
commit r13-2178-gcb2daf5acce003300ee948a89860c0d13ebcae79
Author: Andrew Pinski
Date: Fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106601
--- Comment #4 from CVS Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:e5e6983c3da53729e58a32af1d531ea74b3dbf5d
commit r13-2179-ge5e6983c3da53729e58a32af1d531ea74b3dbf5d
Author: Andrew Pinski
Date: Fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106690
--- Comment #3 from CVS Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:dec5faa2b2f0d311daa6defd4b4f3c1965748ddf
commit r13-2180-gdec5faa2b2f0d311daa6defd4b4f3c1965748ddf
Author: Andrew Pinski
Date: Fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106690
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106600
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106601
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106516
--- Comment #8 from Peter Bergner ---
(In reply to Kewen Lin from comment #7)
> In this patch, I mainly
> followed the existing practice vect_int_mult (there are also some similar
> effective targets describing target vector support capability).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106731
--- Comment #4 from federico ---
The TREE_STATIC assert should be valid according to what reported in the
implementation at report https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48298
But, I can't tell what that means.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106586
--- Comment #14 from CVS Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:2c721ea9473ad7615bb47b66509097bd254bb839
commit r13-2188-g2c721ea9473ad7615bb47b66509097bd254bb839
Author: Andrew Pinski
Date: M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106588
--- Comment #3 from CVS Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:df5204ddd4b8e3a2d02bb3ad5bcdb9d636b02537
commit r13-2190-gdf5204ddd4b8e3a2d02bb3ad5bcdb9d636b02537
Author: Andrew Pinski
Date: Mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106632
--- Comment #2 from CVS Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:df5204ddd4b8e3a2d02bb3ad5bcdb9d636b02537
commit r13-2190-gdf5204ddd4b8e3a2d02bb3ad5bcdb9d636b02537
Author: Andrew Pinski
Date: Mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106586
Andrew Pinski changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106632
Andrew Pinski changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106588
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106731
--- Comment #5 from Steve Kargl ---
On Wed, Aug 24, 2022 at 07:10:20PM +, federico.perini at gmail dot com
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106731
>
> --- Comment #4 from federico ---
> The TREE_STATIC assert should be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105012
--- Comment #17 from anlauf at gcc dot gnu.org ---
(In reply to Richard Biener from comment #11)
> (In reply to Richard Biener from comment #10)
> > likely triggered by the INTENT(out), it looks like gfortran fails to
> > properly
> > name-looku
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105012
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=100736
--- Comment #6 from Segher Boessenkool ---
There are so many things here, it's hard to start. Two big things:
Firstly, this is not floating point at all, so -ffinite-math-only should not
make any difference. We currently abuse CCFP (in a non-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106735
Bug ID: 106735
Summary: tens of thousands of errors in C++ library
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libst
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106735
Marek Polacek changed:
What|Removed |Added
Last reconfirmed||2022-08-24
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106735
--- Comment #2 from seurer at gcc dot gnu.org ---
It it causing so many error messages that emails to the gcc test results list
from my autotesters are being rejected as they are 3.9MB in size.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106735
Marek Polacek changed:
What|Removed |Added
CC||jwakely.gcc at gmail dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106735
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106735
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106459
--- Comment #7 from CVS Commits ---
The master branch has been updated by Chenghua Xu :
https://gcc.gnu.org/g:b169b67d7dafe2b786f87c31d6b2efc603fd880c
commit r13-2195-gb169b67d7dafe2b786f87c31d6b2efc603fd880c
Author: Chenghua Xu
Date: Wed A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106459
--- Comment #8 from CVS Commits ---
The releases/gcc-12 branch has been updated by Chenghua Xu
:
https://gcc.gnu.org/g:ce753c2792363f1b4cfe2ac56b2da562b34151f3
commit r12-8713-gce753c2792363f1b4cfe2ac56b2da562b34151f3
Author: Chenghua Xu
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106728
--- Comment #2 from John Smith ---
(In reply to Andrew Pinski from comment #1)
> > g++ -std=c++11 iterate.cpp -o "Z:\28sec\out.exe"
>
>
> Does `g++ -c -std=c++11 iterate.cpp -o "\\machine_name\d\performance
> testing\t.o" ` work?
>
> Also if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106728
--- Comment #3 from John Smith ---
Please ignore the different machine names in the output I posted above, I
forgot to change it in both appearances. I attempted to change it to
"machine_name" to avoid confusion but missed it in one spot and I d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106728
--- Comment #4 from Andrew Pinski ---
Try the following:
g++ -std=c++11 iterate.cpp S -o "Z:\28sec\out.s"
If this works, then you should report it to binutils.
Though I suspect it is https://sourceware.org/bugzilla/show_bug.cgi?id=25713
which w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106728
--- Comment #5 from John Smith ---
(In reply to Andrew Pinski from comment #4)
> Try the following:
> g++ -std=c++11 iterate.cpp S -o "Z:\28sec\out.s"
>
> If this works, then you should report it to binutils.
> Though I suspect it is https://so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106728
--- Comment #6 from Andrew Pinski ---
I had a typo, it should have been -S rather than just S.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106725
--- Comment #3 from rguenther at suse dot de ---
On Wed, 24 Aug 2022, dthorn at google dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106725
>
> --- Comment #2 from Daniel Thornburgh ---
> (In reply to Richard Biener from comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106736
Bug ID: 106736
Summary: [13 Regression] ICE in gen_movxo, at
config/rs6000/mma.md:333
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-on-valid-cod
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106736
Arseny Solokha changed:
What|Removed |Added
Keywords|ice-on-valid-code |ice-on-invalid-code
--- Comment #1 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106737
Bug ID: 106737
Summary: [13 Regression] ICE: verify_ssa failed (error: stmt
with wrong VUSE)
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-on-va
1 - 100 of 102 matches
Mail list logo
