Hello.
I'm adding the author of IPA CP and LTO subsystem maintainer.
Martin
CC'ing Honza and Martin.
On 03/12/2019 22:43, Segher Boessenkool wrote:
On Tue, Dec 03, 2019 at 08:10:37PM +, Richard Earnshaw (lists) wrote:
On 03/12/2019 18:56, Segher Boessenkool wrote:
On Tue, Dec 03, 2019 at 09:16:43AM +, Richard Earnshaw (lists) wrote:
But we could make an "old-svn" hierarchy or similar
On Sun, Dec 1, 2019 at 7:47 PM JeanHeyd Meneide wrote:
>
> Dear GCC Community,
>
> I have a bit of a question. I recently fixed up and deployed 2
> separate implementations of a paper I am working on for C and C++
> Standardization called #embed (found here -
>
Joseph Myers :
> Eric, can Richard and I get direct write access to the gcc-conversion
> repository? Waiting for merge requests to be merged is getting in the way
> of fast iteration on incremental improvements to the conversion machinery,
> it should be possible to get multiple incremental
On Tue, Dec 3, 2019 at 11:51 PM Erick Ochoa
wrote:
>
> Hi,
>
> I am trying to use the function: `cgraph_node::get_untransformed_body` during
> the wpa stage of a SIMPLE_IPA_PASS transformation. While the execute function
I think SIMPLE_IPA_PASSes have no "WPA" stage but run at LTRANS time
(WPA
On Wed, 4 Dec 2019, Eric S. Raymond wrote:
> Joseph Myers :
> > Eric, can Richard and I get direct write access to the gcc-conversion
> > repository? Waiting for merge requests to be merged is getting in the way
> > of fast iteration on incremental improvements to the conversion machinery,
>
On Tue, 3 Dec 2019, Richard Earnshaw (lists) wrote:
> > Thanks. Do other people have comments on the list?
> >
> > I'm going to add one vendor tag that should be uncontroversial to the
> > list. /tags/gcc-1766 is a misnamed Apple tag, and there is already a
> > properly named copy with
Hi, this refers to https://gcc.gnu.org/ml/gcc/2019-11/msg00251.html
On 2019-12-04 6:30 a.m., Martin Liška wrote:
> Hello.
>
> I'm adding the author of IPA CP and LTO subsystem maintainer.
>
> Martin
On 2019-12-04 7:52 a.m., Richard Biener wrote:
> On Tue, Dec 3, 2019 at 11:51 PM Erick Ochoa
> wrote:
>>
>> Hi,
>>
>> I am trying to use the function: `cgraph_node::get_untransformed_body` during
>> the wpa stage of a SIMPLE_IPA_PASS transformation. While the execute function
>
> I think
On Tue, 3 Dec 2019, Richard Earnshaw (lists) wrote:
> On 03/12/2019 15:05, Joseph Myers wrote:
> > On Tue, 3 Dec 2019, Richard Earnshaw (lists) wrote:
> >
> > > a) Only live development branches get moved to the normal git namespace,
> > > but
> > > see d) & e) below
> >
> > Where do you
http://www.netgull.com has gcc snapshots and releases, but in the past few
weeks only the diffs are there - none of the actual source tarballs are present.
I am not sure how to get this message through to netball, but I figured you had
a better chance than I.
Thanks for GCC!
Dan Allen
Idaho
On 02/12/2019 10:54, Richard Earnshaw (lists) wrote:
> On 19/11/2019 14:56, Jason Merrill wrote:
>> On Mon, Nov 18, 2019 at 4:38 PM Richard Earnshaw (lists) <
>> richard.earns...@arm.com> wrote:
>>
>>> On 18/11/2019 20:53, Jason Merrill wrote:
On Mon, Nov 18, 2019 at 2:51 PM Segher
On Wed, Dec 04, 2019 at 06:25:21PM +, Joseph Myers wrote:
> In my current script (adjust-refs in the gcc-conversion repository;
> limited testing done based on a GCC repository conversion from last week,
> running a fresh conversion now with vendor tags kept for more testing),
> I'm using
Here is a very preliminary list of refs after postprocessing by my script,
to indicate what the ref layout would look like. We can easily change the
script if we'd like some other layout. Note that some refs here will go
away after deleting corresponding tags in SVN, while others are missing
On Wed, Dec 04, 2019 at 08:37:17PM +, Joseph Myers wrote:
> On Wed, 4 Dec 2019, Segher Boessenkool wrote:
> > And, as I said before, a release branch is a totally different animal
> > from releases (release tags). We do this correctly now, let's keep it
> > that way?
>
> By convention, a
On Wed, 4 Dec 2019, Segher Boessenkool wrote:
> > My script has a special case to use the name
> > refs/heads/releases/gcc-2.95.2.1-branch with "-branch" in there, because
> > there's also refs/tags/releases/gcc-2.95.2.1, and while technically git
> > allows you to have refs/heads/ and
‐‐‐ Original Message ‐‐‐
On Wednesday, November 27, 2019 3:19 AM, Richard Biener
wrote:
...
> > Questions:
> >
> > 1. Should we aim to provide a vectorized version of __builtin_cexpi? If
> > so, it would have
> > to be a PPC64-only vector __builtin-cexpi, right?
> >
> > 2. Or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92772
--- Comment #2 from rsandifo at gcc dot gnu.org
---
(In reply to Richard Biener from comment #1)
> Looks like cond-reduction cannot handle fully masked loops unless we'd
> somehow mask the condition operation itself?
Yeah, looks like it. We'd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92788
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |10.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92788
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92757
--- Comment #10 from Ricardo Abreu ---
> Usually CLI applications don't have as many switches as GCC with as many
> non-trivial interactions between them.
True, but I am not sure I understand your point. To me that sounds like all the
more
On 2019-12-04, 10:29:04, Thomas Schwinge wrote:
--- gcc/ada/gcc-interface/trans.c
+++ gcc/ada/gcc-interface/trans.c
@@ -1309,6 +1533,274 @@ Pragma_to_gnu (Node_Id gnat_node)
+ case Name_Copy:
+ map_kind = GOMP_MAP_FORCE_TOFROM;
+ gnu_clauses =
Bootstrap / regtest running on x86_64-unknown-linux-gnu.
Richard.
2019-12-04 Richard Biener
* tree-ssa-sccvn.c (vn_reference_lookup_3): Properly guard
empty CTOR and memset partial-def registering. Take advantage
of fancy offset analysis in memset handling.
Index:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92781
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92754
Tobias Burnus changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92754
--- Comment #4 from Tobias Burnus ---
Author: burnus
Date: Wed Dec 4 12:19:55 2019
New Revision: 278961
URL: https://gcc.gnu.org/viewcvs?rev=278961=gcc=rev
Log:
Fortran] PR92754 - fix an issue with resolving intrinsic functions
Hi!
The following optimizations also can't handle nop conversions between the
inner and outer addition/subtraction, and even -fwrapv doesn't help there,
only simplify-rtx.c is able to do something about those.
Implemented thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
ok for
On Tue, 2019-12-03 at 12:05 -0600, Segher Boessenkool wrote:
> On Tue, Dec 03, 2019 at 10:33:48PM +0900, Oleg Endo wrote:
> > On Mon, 2019-11-25 at 16:47 -0600, Segher Boessenkool wrote:
> > >
> > > > > - sh (that's sh4-linux):
> > > > >
> > > > > /home/segher/src/kernel/net/ipv4/af_inet.c: In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92780
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92793
Bug ID: 92793
Summary: Fortran Location Data for Diagnostic lacks the column
number – when passing on to ME
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Assignee: ibuclaw at gdcproject dot org
Reporter: doko at debian dot org
Target Milestone: ---
Created attachment 47415
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47415=edit
symbols diff
the current trunk 20191204 dropped two symbols from the shared phobos libr
This improves on the existing partial-def support by allowing
shadowed non-constant partial defs.
Step 1 to really support non-constant partial-defs which would
help Skia.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2019-12-04 Richard Biener
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91369
--- Comment #24 from Toni Neubert ---
Great thank you.
Hi!
In OpenMP 4.5, the gomp/teams1.f90 code was invalid and diagnosed in the
middle-end. In OpenMP 5.0, it is valid and the diagnostics in the
middle-end has been removed, but the Fortran side hasn't been adjusted
and so the middle-end ICEs on it.
The following patch just does the minimal FE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92398
--- Comment #10 from luoxhu at gcc dot gnu.org ---
Author: luoxhu
Revision: 278890
Modified property: svn:log
Modified: svn:log at Wed Dec 4 08:50:33 2019
--
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92756
Jakub Jelinek changed:
What|Removed |Added
Summary|[9/10 Regression] ICE in|[9 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92788
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92768
--- Comment #15 from Jakub Jelinek ---
For SSE2+, the code can of course use _mm_xor_si128 instead and
_mm_castsi128_ps/_mm_castps_si128, but for SSE that is not an option.
And not really sure what can be done there, the _mm_xor_ps arguments are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92772
--- Comment #3 from Andrew Stubbs ---
The GCN architecture can handle the masking, but I don't know how we'd
represent or apply that in the middle end?
I can probably implement extract_last, and that might be more efficient, but I
don't see how
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92772
--- Comment #4 from Richard Biener ---
IIRC AVX512 also implements fully masked loops so the testcase should fail
there, too, if we adjust N accordingly (to 15 or 31). Hmm, can't seem to
trigger
the fully masked support here, maybe I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92788
--- Comment #2 from Jakub Jelinek ---
So, what happens is that we have a bb like:
[local count: 7102878]:
# __result_2 = PHI <_10(3)>
*this_4(D).D.3185._M_impl.D.3135._M_finish = __result_2;
with EH and normal successor edges.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92754
--- Comment #3 from Tobias Burnus ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00153.html
Wilco Dijkstra writes:
> Hi Richard,
>
>> But what uses CMP_BRANCH after the patch? It looked like you renamed
>> all existing uses and didn't add any new ones.
>
> My next patch will be adding uses of it now I've done some benchmarking
> to decide when to turn it on.
>
>>> + &&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92782
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92756
--- Comment #4 from Jakub Jelinek ---
Author: jakub
Date: Wed Dec 4 08:47:13 2019
New Revision: 278956
URL: https://gcc.gnu.org/viewcvs?rev=278956=gcc=rev
Log:
PR fortran/92756
* trans-openmp.c (gfc_trans_omp_teams): Wrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92790
Bug ID: 92790
Summary: [OpenACC] declare device_resident - Fortran common
blocks not handled /
libgomp.oacc-fortran/declare-5.f90 fails
Product: gcc
Version:
Hi!
On 2018-12-03T10:50:44-0500, Pierre-Marie de Rodat wrote:
> Matching front-end bits to support Acc_Kernels, Acc_Parallel,
> Acc_Loop and Acc_Data.
Interesting. :-)
I have not reviewed this properly, but just stumbled over the following:
> --- gcc/ada/gcc-interface/trans.c
> +++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92768
--- Comment #14 from Richard Biener ---
So I think it's unfortunate that we break testcases like this using _mm_xor_ps
with -ffast-math since users expect the mask to not be treated as signed
zero/zero. The error here obviously lies in the use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92791
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92791
Bug ID: 92791
Summary: [10 Regression] ICE in extract_insn, at recog.c:2311
since r278645
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92786
--- Comment #3 from Jonathan Wakely ---
Yes, this is
https://gcc.gnu.org/wiki/VerboseDiagnostics#missing_static_const_definition
In C++17 the static member is implicitly 'inline' which means the declaration
with an initializer is also a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92734
--- Comment #9 from Jakub Jelinek ---
Author: jakub
Date: Wed Dec 4 09:38:48 2019
New Revision: 278958
URL: https://gcc.gnu.org/viewcvs?rev=278958=gcc=rev
Log:
PR tree-optimization/92734
* match.pd ((A +- B) - A -> +- B, (A +-
Hi,
I have another question: Why does the original email not appear at
https://gcc.gnu.org/ml/gcc-patches/2019-12/ or in my inbox? I do see
three other Ada emails posted around the same time but not this one.
On 12/4/19 10:29 AM, Thomas Schwinge wrote:
On 2018-12-03T10:50:44-0500,
Hi Tobias!
On 2019-12-04T10:39:30+0100, Tobias Burnus wrote:
> I have another question: Why does the original email not appear at
> https://gcc.gnu.org/ml/gcc-patches/2019-12/ or in my inbox? I do see
> three other Ada emails posted around the same time but not this one.
> On 12/4/19 10:29
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92772
--- Comment #5 from Richard Biener ---
And the issue is to be fixed in vect_create_epilog_for_reduction where
we create the index IV:
/* For cond reductions we want to create a new vector (INDEX_COND_EXPR)
which is updated with the
In r278410 I added code to handle VIEW_CONVERT_EXPRs between
variable-length vectors. This included support for decoding
a VECTOR_BOOLEAN_TYPE_P with subbyte elements.
However, it turns out that we were already mishandling such bool vectors
for fixed-length vectors: we treated each element as a
Hello.
As mentioned in here https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91971#c7,
we should not mangle profile data and note files unless -fprofile-dir is
used (and an absolute path is used).
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
I'll install the patch if there
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92779
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92794
Bug ID: 92794
Summary: [10 Regression] ICE in decide_about_value, at
ipa-cp.c:5186
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92789
Bug ID: 92789
Summary: Non-obvious ?: behaviour with structurally equivalent
types
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92784
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
On Tue, Dec 3, 2019 at 6:41 PM Tobias Burnus wrote:
>
> The problem here is that one gets two symbols - one inside the block and
> one outside and they do not really agree whether one has a function or a
> variable – which later gives an ICE. As sym->module was "(intrinsic)"
> and FL_VARIABLE,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92772
--- Comment #6 from Andrew Stubbs ---
(In reply to Richard Biener from comment #4)
> Btw, isn't the issue that the reduction looks at all lanes? That is,
> I think the code simply assumes that for fully masked loops at least
> one iteration is
On Wed, Dec 04, 2019 at 10:07:05AM +0800, Hongtao Liu wrote:
> Changelog
> gcc/
> PR target/92686
> * config/i386/sse.md
> (*_cmp3,
> *_cmp3,
> *_ucmp3,
> *_ucmp3): New.
> * config/i386/i386.c (ix86_print_operand): New operand substitution.
> *
On Wed, 4 Dec 2019, Jakub Jelinek wrote:
> Hi!
>
> The following optimizations also can't handle nop conversions between the
> inner and outer addition/subtraction, and even -fwrapv doesn't help there,
> only simplify-rtx.c is able to do something about those.
>
> Implemented thusly,
Jason Merrill writes:
> On 12/3/19 7:39 AM, Richard Sandiford wrote:
>> Jason Merrill writes:
>>> On 11/29/19 5:59 AM, Richard Sandiford wrote:
Ping
Richard Sandiford writes:
> This is the C++ equivalent of r277950, which prevented the
> use of the GNU vector extensions
Hello.
The patch is about missing initialization of a profile count.
Honza investigated with a new profile sanity patch he's been
preparing.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Patch is pre-approved by Honza.
Martin
gcc/ChangeLog:
2019-12-03 Martin Liska
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91971
Martin Liška changed:
What|Removed |Added
Status|REOPENED|ASSIGNED
Assignee|qinzhao at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92796
Bug ID: 92796
Summary: [10 Regression] ICE in lra_assign, at
lra-assigns.c:1646 on powerpc64le-linux-gnu
Product: gcc
Version: 10.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92791
--- Comment #2 from Jakub Jelinek ---
So:
struct S { S (void *a, bool b) : x (a), y (b) {} void *x; bool y; };
void bar (S);
void
foo (void *x)
{
S sbuf_it (x, x == nullptr);
bar (sbuf_it);
}
with -O2 -m32 -march=i686 -mtune=i586
gives the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92538
--- Comment #4 from Christoph Müllner
---
Early tests with this pass showed that a bunch of SPEC CPU2017 benchmarks
benefit from this. For example, the written-once global variable TTSize of
sjeng
is eliminated by this pass.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92773
--- Comment #6 from Charles-Antoine Couret
---
Ok with a friend we identified a bit more what is the issue.
So in fact I built (manually):
$ gcc -Wall sound/soc/codecs/tas5756m.i -o sound/soc/codecs/tas5756m.o
In that case, no output and it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92798
--- Comment #1 from Jonathan Wakely ---
-fshort-enums is an ABI-changing option, which means you should recompile the
entire toolchain including the standard libraries.
Why are you using it anyway? In C++ you can specify a fixed underlying
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92803
Bug ID: 92803
Summary: [10 Regression] error: type mismatch in
'vec_perm_expr' since r278764
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92803
--- Comment #2 from Martin Liška ---
Created attachment 47421
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47421=edit
test-case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92803
--- Comment #1 from Martin Liška ---
Created attachment 47420
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47420=edit
test-case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85463
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92801
Bug ID: 92801
Summary: Drop unused struct fields
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee:
Hi Jeff,
>> I've noticed quite significant package failures caused by the revision.
>> Would you please consider documenting this change in porting_to.html
>> (and in changes.html) for GCC 10 release?
>
> I'm not in the office right now, but figured I'd chime in. I'd estimate
> 400-500 packages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92791
--- Comment #3 from Jakub Jelinek ---
We have in the documentation:
For a named pattern, the condition may not depend on the data in
the insn being matched, but only the target-machine-type flags.
The compiler needs to test these
On Tue, Dec 3, 2019 at 5:52 PM David Malcolm wrote:
>
> On Wed, 2019-11-20 at 11:18 +0100, Richard Biener wrote:
> > On Tue, Nov 19, 2019 at 11:02 PM David Malcolm
> > wrote:
> > > > > The checker is implemented as a GCC plugin.
> > > > >
> > > > > The patch kit adds support for "in-tree"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92795
Bug ID: 92795
Summary: Another slowness issue in the demangler (on trunk)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92743
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92797
--- Comment #1 from Tim Ruehsen ---
BTW, llvm-cxxfilt does not show this behavior.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92773
--- Comment #5 from Richard Biener ---
Hmm, compilation finishes instantly for me. I tried, -O2, -Os and -O3.
Hi Tobias,
On 04.12.19 14:37, Tobias Burnus wrote:
> As reported internally by Frederik, gfortran currently passes LOCATION_COLUMN
> == 0 to the middle end. The reason for that is how parsing works – gfortran
> reads the input line by line.
>
> For internal error diagnostic (fortran/error.c),
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92794
Martin Liška changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92791
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92797
Bug ID: 92797
Summary: cplus_demangle() produces huge amount of output (on
trunk)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92591
--- Comment #6 from Roman Zhuykov ---
Patches are still testing. Arm (both 32 and 64 bit) cross compilers are OK,
and I want to test some additional scenarios for powerpc. Probably I'll post
patches next week.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92798
Bug ID: 92798
Summary: -fshort-enums can break iterators of std::map
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92799
Bug ID: 92799
Summary: ICE: in get, at cgraph.h:1339
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92803
Martin Liška changed:
What|Removed |Added
Priority|P3 |P1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92794
Martin Liška changed:
What|Removed |Added
Keywords||needs-bisection
As reported internally by Frederik, gfortran currently passes
LOCATION_COLUMN == 0 to the middle end. The reason for that is how
parsing works – gfortran reads the input line by line.
For internal error diagnostic (fortran/error.c), the column location was
corrected – but not for locations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92773
Charles-Antoine Couret changed:
What|Removed |Added
Attachment #47408|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92775
--- Comment #2 from Richard Biener ---
That means the get_array_descr_info langhook wasn't updated I guess.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92775
Richard Biener changed:
What|Removed |Added
Known to work||7.5.0
Target Milestone|---
Currently IL verification errors trigger "confused by earlier errors"
messages with a release compiler but compiling with -fchecking.
That is because those use error() before internal_error.
This precludes useful things like emergency IL dump in dump files.
Thus the following - change
1 - 100 of 232 matches
Mail list logo