https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87979
Bug ID: 87979
Summary: ICE in compute_split_row at modulo-sched.c:2393
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87962
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Version|8.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87967
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Version|8.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87978
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87978
--- Comment #2 from Andrew Pinski ---
Warning: In the above example, be aware that a register (for example r0) can be
call-clobbered by subsequent code, including function calls and library calls
for arithmetic operators on other variables (for e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87978
--- Comment #3 from Andrew Pinski ---
https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc/Local-Register-Variables.html#Local-Register-Variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87978
--- Comment #4 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #3)
> https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc/Local-Register-Variables.
> html#Local-Register-Variables
I should say it had that warning already in 8.2.0.
And 8.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87974
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2018-11-12
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87824
--- Comment #7 from rguenther at suse dot de ---
On Sun, 11 Nov 2018, johannespfau at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87824
>
> Johannes Pfau changed:
>
>What|Removed |Ad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87974
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
Target Milest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87978
--- Comment #5 from Andrew Pinski ---
The old documentation contained slightly different wording but was trying to
warn you about this case:
As for global register variables, it's recommended that you choose a register
which is normally saved and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87977
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87974
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87968
Richard Biener changed:
What|Removed |Added
Priority|P3 |P4
Target Milestone|9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87966
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87980
Bug ID: 87980
Summary: ICE in gfc_conv_descriptor_data_get, at
fortran/trans-array.c for assignment on polymorphic
variable
Product: gcc
Version: 9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87980
--- Comment #1 from Jürgen Reuter ---
There might be a relationship for 80774 which is at (almost) the same position,
but for coarray objects than for polymorphics. As this started from version 7
on, maybe the implementation for polymorphics brok
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85925
--- Comment #10 from Segher Boessenkool ---
I get this:
alpha 100.905%
arm 100.072%
c6x 100.000%
csky 100.063%
h8300 100.000%
i386 100.000%
microblaze 100.001%
mips
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87717
Uroš Bizjak changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87718
--- Comment #1 from Uroš Bizjak ---
*** Bug 87717 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87980
Jürgen Reuter changed:
What|Removed |Added
Summary|ICE in |ICE in
|gfc_conv_descr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87981
Bug ID: 87981
Summary: ICE: Segmentation fault (in add_phi_arg)
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85727
Arseny Solokha changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87718
--- Comment #2 from Uroš Bizjak ---
Following testcase:
--cut here--
typedef int V __attribute__((vector_size (8)));
void foo (int x, int y)
{
register int a __asm ("xmm1");
register int b __asm ("xmm2");
register V c __asm ("xmm3");
a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87978
--- Comment #6 from linzj ---
Thanks for the reply.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78444
--- Comment #2 from Iain Sandoe ---
Thanks, that confirms my expectation that this could/would affect other
targets.
I had previously posted the fragment below for review - and will update that
thread shortly.
diff --git a/gcc/config/i386/i386.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78444
--- Comment #3 from Uroš Bizjak ---
(In reply to Iain Sandoe from comment #2)
> I had previously posted the fragment below for review - and will update that
> thread shortly.
But still - why doesn't expand_call update crtl->preferred_stack_update
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87982
Bug ID: 87982
Summary: No error for std::generate_n(ptr, ptr, f)
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85925
--- Comment #11 from Eric Botcazou ---
> I get this:
>
>alpha 100.905%
> arm 100.072%
> c6x 100.000%
> csky 100.063%
>h8300 100.000%
> i386 100.000%
> microblaze 100.001%
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85925
--- Comment #12 from Segher Boessenkool ---
Yes, that is already running... Still has over an hour to go.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87976
Alexander Monakov changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87983
Bug ID: 87983
Summary: Feature: Add a warning when case labels from a
different enum than the one in switch(EXPR) are used
Product: gcc
Version: unknown
Status: UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87981
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
Bug ID: 87984
Summary: [7/8/9 Regression] wrong code for local reg var input
to asm
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
--- Comment #1 from Andrew Pinski ---
I dont think this is a bug. The warning in the manual talks about the call
case even.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78444
--- Comment #4 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #3)
> (In reply to Iain Sandoe from comment #2)
> > I had previously posted the fragment below for review - and will update that
> > thread shortly.
> But still - why doesn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87978
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
Alexander Monakov changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
--- Comment #4 from Andrew Pinski ---
(In reply to Alexander Monakov from comment #3)
> Reopening - please read the testcase in detail. Neither the 'a' nor the 'd'
> input are clobbered in the original code, which uses a temporary ('t') as
> reco
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87982
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87982
--- Comment #2 from Jonathan Wakely ---
std::fill_n has the same problem (in both overloads of __fill_n_a).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
Andrew Pinski changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
--- Comment #6 from Andrew Pinski ---
The old documentation had the following:
Stores into local register variables may be deleted when they appear to be dead
according to dataflow analysis. References to local register variables may be
deleted o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54005
--- Comment #37 from Jonathan Wakely ---
(In reply to Hans-Peter Nilsson from comment #36)
> Either I goofed on the ChangeLog markup
I think it's because you use "PR libstdc++-v3/n" not "PR libstdc++/n"
> As the tests I wrote have no be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87985
Bug ID: 87985
Summary: Compile-time and memory hog w/ -O1
-ftree-slp-vectorize
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: compile-time-hog, mem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78444
--- Comment #5 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #4)
> So, what we want to achieve here?
AFAICS, the compiler figures out that the called function requires only 64bit
alignment and lowers the alignment requirements at the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78444
--- Comment #6 from Iain Sandoe ---
(In reply to Uroš Bizjak from comment #5)
> (In reply to Uroš Bizjak from comment #4)
> > So, what we want to achieve here?
> AFAICS, the compiler figures out that the called function requires only
> 64bit alig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87983
--- Comment #1 from Ævar Arnfjörð Bjarmason ---
FYI: I filed a bug with clang for the same feature:
https://bugs.llvm.org/show_bug.cgi?id=39635
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
Alexander Monakov changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78444
--- Comment #7 from Uroš Bizjak ---
(In reply to Iain Sandoe from comment #6)
> for sysV5 psABI targets, the call site requirement is 64 for m32 and 126/256
> for m64.
sysV5 requires 128bit alignment at the call site, but on linux no runtime
mech
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78444
--- Comment #8 from Iain Sandoe ---
(In reply to Uroš Bizjak from comment #7)
> (In reply to Iain Sandoe from comment #6)
> > for sysV5 psABI targets, the call site requirement is 64 for m32 and 126/256
> > for m64.
> sysV5 requires 128bit alignm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87881
--- Comment #4 from Paul Thomas ---
Hi Dominique,
I am just back from a business trip to the US. I will attend to this bug asap.
Thanks
Paul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87986
Bug ID: 87986
Summary: Assembler errors w/ -masm=intel
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: assemble-failure
Severity: normal
Priority: P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52869
Umesh Kalappa changed:
What|Removed |Added
CC||umesh.kalappa0 at gmail dot com
--- Comm
Hi Jason /Nathan ,
We are able to fix the below issue and would like to hear any comments
/ suggestions will be appreciated.
Thank you
~Umesh
On Mon, Nov 12, 2018 at 5:07 PM umesh.kalappa0 at gmail dot com
wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52869
>
> Umesh Kalappa changed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878
--- Comment #53 from Alexandre Oliva ---
https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00930.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87985
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87985
--- Comment #2 from Richard Biener ---
It's split_constant_offset creating the large tree...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52869
--- Comment #9 from Jonathan Wakely ---
Please send the patch to gcc-patc...@gcc.gnu.org for review.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87830
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78444
--- Comment #9 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #8)
> (In reply to Uroš Bizjak from comment #7)
> > (In reply to Iain Sandoe from comment #6)
> > > for sysV5 psABI targets, the call site requirement is 64 for m32 and
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87985
--- Comment #3 from Richard Biener ---
diff --git a/gcc/tree-data-ref.c b/gcc/tree-data-ref.c
index 6019c6168bf..d60d389fa0a 100644
--- a/gcc/tree-data-ref.c
+++ b/gcc/tree-data-ref.c
@@ -682,7 +684,8 @@ split_constant_offset_1 (tree type, tree o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78444
--- Comment #10 from Uroš Bizjak ---
BTW: probably related to this PR, I have seen following kludge in
i386/darwin.h:
#define STACK_BOUNDARY \
((profile_flag || TARGET_64BIT_MS_ABI) ? 128 : BITS_PER_WORD)
It looks that profile_flag is there d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87769
Mateusz Zych changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78444
--- Comment #11 from Iain Sandoe ---
(In reply to Uroš Bizjak from comment #10)
> BTW: probably related to this PR, I have seen following kludge in
> i386/darwin.h:
>
> #define STACK_BOUNDARY \
> ((profile_flag || TARGET_64BIT_MS_ABI) ? 128 :
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81824
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69502
--- Comment #5 from Sven ---
(In reply to sandra from comment #4)
> Fixed on trunk.
It's good thing that the documentation reflects the behavior of gcc.
But on the other hand, having the align attribute work in both directions is a
bad idea, I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #3 from Wil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87963
--- Comment #1 from Jonathan Wakely ---
Author: redi
Date: Mon Nov 12 15:25:40 2018
New Revision: 266032
URL: https://gcc.gnu.org/viewcvs?rev=266032&root=gcc&view=rev
Log:
PR libstdc++/87963 fix build for 64-bit mingw
PR libstdc++/87963
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87987
Bug ID: 87987
Summary: Missed optimization with ranged-for loop on a
constexpr array
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87963
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87987
Jonathan Wakely changed:
What|Removed |Added
Keywords||missed-optimization
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87988
Bug ID: 87988
Summary: [9 regression] Streaming of ABSTRACT_ORIGIN is
expensive
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priorit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87977
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #4 from Segher Boessenkool ---
(In reply to Wilco from comment #3)
> IRA costing doesn't consider the possibility of a simple move being
> removeable.
Not always, yeah (only if you have matching constraints, which are silly to
have f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86004
--- Comment #9 from Jan Hubicka ---
I wonder if we can close this based on fact that it only reproduces on
sufficiently old binutils and we simply can't support incremental linking on
these?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87899
Peter Bergner changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87815
--- Comment #1 from Renlin Li ---
Author: renlin
Date: Mon Nov 12 16:47:24 2018
New Revision: 266033
URL: https://gcc.gnu.org/viewcvs?rev=266033&root=gcc&view=rev
Log:
[PR87815]Don't generate shift sequence for load replacement in DSE when the
m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
--- Comment #8 from Alexander Monakov ---
Executable testcase suitable for bisecting, aborts with -O2 -m32
__attribute__((weak))
int f(long long x[])
{
int o=0, i;
for (i=0; i<3; i++) {
register int a asm("eax");
a = x[0]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87815
Renlin Li changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87989
Bug ID: 87989
Summary: Calling operator T() invokes wrong conversion operator
overload
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87989
Matthias Kretz changed:
What|Removed |Added
Known to work||7.3.0
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87990
Bug ID: 87990
Summary: using Base::operator= wrongly introduces user-declared
move assignment operator
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87990
Tomáš Ženčák changed:
What|Removed |Added
CC||tomas.zencak at seznam dot cz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87921
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87918
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87881
--- Comment #5 from Dominique d'Humieres ---
Related to/duplicate of pr87945?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87945
Dominique d'Humieres changed:
What|Removed |Added
Keywords||ice-on-valid-code
Sta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87918
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|2018-11-07 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #5 from Wilco ---
(In reply to Segher Boessenkool from comment #4)
> (In reply to Wilco from comment #3)
> > IRA costing doesn't consider the possibility of a simple move being
> > removeable.
>
> Not always, yeah (only if you have m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #6 from Richard Earnshaw ---
(In reply to Wilco from comment #5)
> (In reply to Segher Boessenkool from comment #4)
> > (In reply to Wilco from comment #3)
> > > IRA costing doesn't consider the possibility of a simple move being
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68717
--- Comment #10 from Dominique d'Humieres ---
The warnings are gone between revisions r265814 and r265942.
From comment 1
> As discussed in the other related PR, those are real issues -
> Fortran frontend should not declare one function with m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78492
G. Steinmetz changed:
What|Removed |Added
CC||gs...@t-online.de
--- Comment #4 from G.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68649
--- Comment #24 from Dominique d'Humieres ---
The warnings are gone between revisions r265814 and r265942.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #7 from Wilco ---
(In reply to Richard Earnshaw from comment #6)
> (In reply to Wilco from comment #5)
> > (In reply to Segher Boessenkool from comment #4)
> > > (In reply to Wilco from comment #3)
> > > > IRA costing doesn't consider
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79738
--- Comment #3 from Martin Sebor ---
Correct: r255469 didn't change the semantics of either of the two attributes
(it just rejects declarations that use both).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87991
Bug ID: 87991
Summary: ICE in gfc_constructor_append_expr, at
fortran/constructor.c:135
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87992
Bug ID: 87992
Summary: ICE in resolve_fl_variable, at fortran/resolve.c:12314
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81824
--- Comment #13 from Martin Sebor ---
Author: msebor
Date: Mon Nov 12 18:02:41 2018
New Revision: 266034
URL: https://gcc.gnu.org/viewcvs?rev=266034&root=gcc&view=rev
Log:
PR c/81824 - Warn for missing attributes with function aliases
gcc/tests
1 - 100 of 147 matches
Mail list logo
