[Bug rtl-optimization/87871] [9 Regression] testcases fail after r265398 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #12 from Segher Boessenkool ---
(In reply to Segher Boessenkool from comment #11)
> (In reply to Wilco from comment #8)
> > mov r4, r0
> > cmp r4, #0
>
> Why does it copy r0 to r4 and then compare r4? On more modern machines it
> is faster to compare r0 itself, and it would allow shrink-wrapping to work
> fine here
We get this in combine:
Trying 2 -> 7:
2: r112:SI=r116:SI
REG_DEAD r116:SI
7: cc:CC=cmp(r112:SI,0)
Successfully matched this instruction:
(parallel [
(set (reg:CC 100 cc)
(compare:CC (reg:SI 116)
(const_int 0 [0])))
(set (reg/v:SI 112 [ a ])
(reg:SI 116))
])
(that's *movsi_compare0).
This is preceded by
(insn 50 3 7 2 (set (reg:SI 116)
(reg:SI 0 r0 [ a ])) "ira-shrinkwrap-prep-1.c":14:1 179
{*arm_movsi_insn}
(nil))
And it stays that way until IRA, which does
Disposition:
0:r111 l0 03:r112 l0 41:r113 l0 22:r114 l0 3
5:r116 l0 44:r117 l0 0
If r116 had been allocated hard reg 0 all would be fine (and we know r116
dies in insn 7 already, there is a REG_DEAD note on it).
[Bug rtl-optimization/87871] [9 Regression] testcases fail after r265398 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #11 from Segher Boessenkool ---
(In reply to Wilco from comment #8)
> push{r4, lr}
> mov r4, r0
> cmp r4, #0
Why does it copy r0 to r4 and then compare r4? On more modern machines it
is faster to compare r0 itself, and it would allow shrink-wrapping to work
fine here (well, need to move the assignment to r4 down to the block where
it is used, but something will certainly do that, and it is one of the
shrink-wrapping improvements I want to do for GCC 10).
> It seems shrinkwrapping is more random, sometimes it's done as expected,
> sometimes it is not. It was more consistent on older GCC's.
Shrink-wrapping is very predictable. But no block where a non-volatile
register is used or set will get shrink-wrapped. This limitation has
existed since forever.
[Bug rtl-optimization/80960] [7/8/9 Regression] Huge memory use when compiling a very large test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80960 --- Comment #19 from Segher Boessenkool --- (In reply to rguent...@suse.de from comment #18) > Hmm, so if we'd have numbered stmts in an EBB we could check the > distance between set and use and not combine when that gets too big? Yeah. Or we could even not make a LOG_LINK in the first place between statements that are too far apart. > > Combine also makes garbage for every try, and none of that is cleaned > > up during combine. Maybe we should change that? (I can try next week). > > Not sure how easy that is but yes, it might help quite a bit due > to less churn on the cache. Just ggc_free()ing the "toplevel" > RTX of failed attempts might already help a bit. It's of course > kind-of a hack then but with an appropriate comment it would be > fine I guess (recursively ggc_free()ing might run into sharing > issues so that probably won't work). combine does not change anything *between* combination attempts, and all attempts go via the same function (try_combine), so calling gcc_collect should be fine. Manually gcc_free'ing things would be a hack alright.
[Bug rtl-optimization/87763] [9 Regression] aarch64 target testcases fail after r265398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763 --- Comment #41 from Segher Boessenkool --- Seeing that the code in your examples can be expressed as a bitfield insert requires that combine sees that only the low 8 bits of reg 93 can be non-zero, by the way. It usually does not know this. It could in this case if it was combining insn 6 as well. Did it try that before? What happened?
[Bug rtl-optimization/87763] [9 Regression] aarch64 target testcases fail after r265398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763 --- Comment #40 from Segher Boessenkool --- You'll get much better results if you don't use insv in your machine description; writing it with the input and output separate (and then using a "0" constraint) is much friendlier to the optimisers.
[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to t.sprodowski from comment #0)
> Following calculation of the complex number leads to a wrong imaginary part:
>
>
> #include
> #include
> #include
>
> int main(int argc, char *argv[])
> {
> std::complex val = std::complex(-1.8425031517782417e-07,
> -0.0);
> std::complex testExp = std::pow(val, 0.5);
> std::cout << "textExp: " << std::setprecision(30) << testExp << std::endl;
> return 0;
> }
>
> Result is:
> (2.6283607659835830609796003783e-20,-0.000429243887758258178214548772544),
> but it should be
> (2.628360765983583e-20, 0.0004292438877582582), obtained from Visual Studio,
> MATLAB and Octave.
>
What version of Octave. I get
>> z = complex(-1.8425031517782417e-07, -0.0)
z = -0.0018425 - 0.000i
>> z**0.5
ans = 2.6284e-20 - 4.2924e-04i
which agrees with clang++ version 7.0.1 (and apparently g++
which I haven't tested).
[Bug fortran/84382] add command-line options -std=gnu2003 and -std=gnu2008 for gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84382
--- Comment #6 from Steve Kargl ---
On Fri, Apr 05, 2019 at 11:15:30PM +, sgk at troutmask dot
apl.washington.edu wrote:
>
> We could add
>
> #define GFC_STD_OPT_GNU03 (GFC_STD_OPT_F03 | GFC_STD_GNU)
> #define GFC_STD_OPT_GNU08 (GFC_STD_OPT_F08 | GFC_STD_GNU)
> #define GFC_STD_OPT_GNU18 (GFC_STD_OPT_F18 | GFC_STD_GNU)
>
Against my better judgment.
%cat a.f90
program foo
integer :: i = z'1234' ! Nonstandard initialization
print *, i
end program foo
% gfcx -o z a.f90 && ./z
4660
% gfcx -o z -std=f2003 a.f90 && ./z
a.f90:2:17:
2 |integer :: i = z'1234' ! Nonstandard initialization
| 1
Error: GNU Extension: BOZ literal at (1) outside a DATA statement and outside
INT/REAL/DBLE/CMPLX
% gfcx -o z -std=gnu2003 a.f90 && ./z
4660
Index: gcc/fortran/libgfortran.h
===
--- gcc/fortran/libgfortran.h (revision 270181)
+++ gcc/fortran/libgfortran.h (working copy)
@@ -46,6 +46,10 @@ along with GCC; see the file COPYING3. If not see
#define GFC_STD_OPT_F18((GFC_STD_OPT_F08 | GFC_STD_F2018) \
& (~GFC_STD_F2018_DEL))
+#define GFC_STD_OPT_GNU03 (GFC_STD_OPT_F03 | GFC_STD_GNU)
+#define GFC_STD_OPT_GNU08 (GFC_STD_OPT_F08 | GFC_STD_GNU)
+#define GFC_STD_OPT_GNU18 (GFC_STD_OPT_F18 | GFC_STD_GNU)
+
/* Bitmasks for the various FPE that can be enabled. These need to be
straight integers
e.g., 8 instead of (1<<3), because they will be included in Fortran source.
*/
#define GFC_FPE_INVALID 1
Index: gcc/fortran/lang.opt
===
--- gcc/fortran/lang.opt(revision 270181)
+++ gcc/fortran/lang.opt(working copy)
@@ -826,6 +826,18 @@ std=gnu
Fortran
Conform to nothing in particular.
+std=gnu2003
+Fortran
+Conform to the ISO Fortran 2003 standard with GNU Fortran extensions.
+
+std=gnu2008
+Fortran
+Conform to the ISO Fortran 2008 standard with GNU Fortran extensions.
+
+std=gnu2018
+Fortran
+Conform to the ISO Fortran 2018 standard with GNU Fortran extensions.
+
std=legacy
Fortran
Accept extensions to support legacy code.
Index: gcc/fortran/options.c
===
--- gcc/fortran/options.c (revision 270181)
+++ gcc/fortran/options.c (working copy)
@@ -778,6 +778,31 @@ gfc_handle_option (size_t scode, const char *arg, HOST
set_default_std_flags ();
break;
+case OPT_std_gnu2003:
+ gfc_option.allow_std = GFC_STD_OPT_GNU03;
+ gfc_option.warn_std = GFC_STD_F95_OBS;
+ gfc_option.max_identifier_length = 63;
+ warn_ampersand = 1;
+ warn_tabs = 1;
+ break;
+
+case OPT_std_gnu2008:
+ gfc_option.allow_std = GFC_STD_OPT_GNU08;
+ gfc_option.warn_std = GFC_STD_F95_OBS | GFC_STD_F2008_OBS;
+ gfc_option.max_identifier_length = 63;
+ warn_ampersand = 1;
+ warn_tabs = 1;
+ break;
+
+case OPT_std_gnu2018:
+ gfc_option.allow_std = GFC_STD_OPT_GNU18;
+ gfc_option.warn_std = GFC_STD_F95_OBS | GFC_STD_F2008_OBS
+ | GFC_STD_F2018_OBS;
+ gfc_option.max_identifier_length = 63;
+ warn_ampersand = 1;
+ warn_tabs = 1;
+ break;
+
case OPT_std_legacy:
set_default_std_flags ();
gfc_option.warn_std = 0;
Index: gcc/fortran/invoke.texi
===
--- gcc/fortran/invoke.texi (revision 270181)
+++ gcc/fortran/invoke.texi (working copy)
@@ -492,23 +492,28 @@ representation of the translated Fortran code, produce
@item -std=@var{std}
@opindex @code{std=}@var{std} option
-Specify the standard to which the program is expected to conform,
-which may be one of @samp{f95}, @samp{f2003}, @samp{f2008},
-@samp{f2018}, @samp{gnu}, or @samp{legacy}. The default value for
-@var{std} is @samp{gnu}, which specifies a superset of the latest
-Fortran standard that includes all of the extensions supported by GNU
-Fortran, although warnings will be given for obsolete extensions not
+Specify the standard to which the program is expected to conform
+which may be one of @samp{f95}, @samp{f2003}, @samp{f2008}, @samp{f2018},
+@samp{gnu}, @samp{gnu2003}, @samp{gnu2008}, @samp{gnu2018},or @samp{legacy}.
+The default value for @var{std} is @samp{gnu}, which specifies a superset
+of the latest Fortran standard that includes all of the extensions supported
+by GNU Fortran, although warnings will be given for obsolete extensions not
recommended for use in new code. The @samp{legacy} value is
equivalent but without the warnings for obsolete extensions, and may
-be useful for old non-standard programs. The @samp{f95},
+be useful for old nonstandard programs. The @samp{f95},
@samp{f2003}, @samp{f2008}, and @samp{f2018} values specify strict
conformance to the Fortran 95, Fortran 2003,
[Bug target/89993] New: Inconsistent incoming stack boundary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89993
Bug ID: 89993
Summary: Inconsistent incoming stack boundary
Product: gcc
Version: 8.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: ubizjak at gmail dot com
Target Milestone: ---
Target: i386,x86-64
It looks like the default incoming stack isn't a constant:
[hjl@gnu-cfl-1 tmp]$ cat a.c
int tst2Foo(int*, int*, int);
int tst1Foo(int* pSrc, int* pDst, int len)
{
return tst2Foo(pSrc, pDst, len);
}
[hjl@gnu-cfl-1 tmp]$ gcc -mstackrealign -S -O2 a.c
[hjl@gnu-cfl-1 tmp]$ cat a.s
.file "a.c"
.text
.p2align 4,,15
.globl tst1Foo
.type tst1Foo, @function
tst1Foo:
.LFB0:
.cfi_startproc
jmp tst2Foo
.cfi_endproc
.LFE0:
.size tst1Foo, .-tst1Foo
.ident "GCC: (GNU) 8.3.1 20190311 (Red Hat 8.3.1-3)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-cfl-1 tmp]$ gcc -mstackrealign -S -O2 a.c -mincoming-stack-boundary=3
[hjl@gnu-cfl-1 tmp]$ cat a.s
.file "a.c"
.text
.p2align 4,,15
.globl tst1Foo
.type tst1Foo, @function
tst1Foo:
.LFB0:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
andq$-16, %rsp
calltst2Foo
leave
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE0:
.size tst1Foo, .-tst1Foo
.ident "GCC: (GNU) 8.3.1 20190311 (Red Hat 8.3.1-3)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-cfl-1 tmp]$ cat b.c
#include
int tst2Foo(int*, int*, int, __m128*);
int tst1Foo(int* pSrc, int* pDst, int len)
{
__m128 x;
return tst2Foo(pSrc, pDst, len, );
}
[hjl@gnu-cfl-1 tmp]$ gcc -mstackrealign -S -O2 b.c -mincoming-stack-boundary=4
[hjl@gnu-cfl-1 tmp]$ cat b.s
.file "b.c"
.text
.p2align 4,,15
.globl tst1Foo
.type tst1Foo, @function
tst1Foo:
.LFB526:
.cfi_startproc
subq$24, %rsp
.cfi_def_cfa_offset 32
movq%rsp, %rcx
calltst2Foo
addq$24, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE526:
.size tst1Foo, .-tst1Foo
.ident "GCC: (GNU) 8.3.1 20190311 (Red Hat 8.3.1-3)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-cfl-1 tmp]$
[Bug libstdc++/89986] [9 Regression] missing export for directory_iterator::increment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89986 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Jonathan Wakely --- Fixed.
[Bug libstdc++/87431] valueless_by_exception() should unconditionally return false if all the constructors are noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87431 Jonathan Wakely changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #20 from Jonathan Wakely --- And fixed, again.
[Bug c/89950] attribute aligned ignored with attribute vector_size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89950 Martin Sebor changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=89968 --- Comment #2 from Martin Sebor --- Yes, unlike in pr89968, in this case the order of the attributes matters. When aligned comes after vector_size the former is respected.
[Bug c/89968] attribute packed fails to reduce char vector member alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89968
--- Comment #4 from Martin Sebor ---
The alignment is respected for members of other types than char so the order of
the attributes doesn't seem to matter here (it does matter in pr89950):
$ cat pr89968-2.c && gcc -S -O2 -Wall -fdump-tree-optimized=/dev/stdout
pr89968-2.c
struct S
{
char c;
__attribute__ ((aligned (64), packed, vector_size (1024))) int v; // okay
};
int f (void) { return sizeof (struct S); }// 1088
int g (void) { return __alignof__ (struct S); } // 64
__attribute__ ((aligned (64), vector_size (1024))) int v1;
int h1 (void) { return __alignof__ (v1); }// 1024
__attribute__ ((vector_size (1024), aligned (64))) int v2;
int h2 (void) { return __alignof__ (v2); }// 64
;; Function f (f, funcdef_no=0, decl_uid=1909, cgraph_uid=1, symbol_order=0)
f ()
{
[local count: 1073741824]:
return 1088;
}
;; Function g (g, funcdef_no=1, decl_uid=1912, cgraph_uid=2, symbol_order=1)
g ()
{
[local count: 1073741824]:
return 64;
}
;; Function h1 (h1, funcdef_no=2, decl_uid=1916, cgraph_uid=3, symbol_order=3)
h1 ()
{
[local count: 1073741824]:
return 1024;
}
;; Function h2 (h2, funcdef_no=5, decl_uid=1920, cgraph_uid=4, symbol_order=5)
h2 ()
{
[local count: 1073741824]:
return 64;
}
[Bug fortran/84382] add command-line options -std=gnu2003 and -std=gnu2008 for gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84382 --- Comment #5 from Steve Kargl --- On Fri, Apr 05, 2019 at 10:24:15AM +, janus at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84382 > > --- Comment #4 from janus at gcc dot gnu.org --- > (In reply to kargl from comment #3) > > How do you propose to enforce a certain standard and allow > > GNU extensions? For example, -std=gnu2003 would enforce > > Fortran 2003, but allow GNU extensions. The problem is that > > gfortran allows several extensions that violate the > > standard. > > The idea is that -std=gnu2003 would allow 2003 features plus GNU extensions, > but reject any 2008 and 2018 features (like submodules and coarrays). > I see. It seems counter-intuitive to me for someone to want, for example, -std=gnu2003, which accepts the garbage that GFC_STD_GNU permits, F2003 conformance, and suppresses F2008 and F2018. I would rather have gfortran encourage programmers to write standard conforming code. In any event, looking at fortran/libgfortran.h, we have #define GFC_STD_OPT_F95 (GFC_STD_F77 | GFC_STD_F95 | GFC_STD_F95_OBS \ | GFC_STD_F2008_OBS | GFC_STD_F2018_OBS \ | GFC_STD_F2018_DEL) #define GFC_STD_OPT_F03 (GFC_STD_OPT_F95 | GFC_STD_F2003) #define GFC_STD_OPT_F08 (GFC_STD_OPT_F03 | GFC_STD_F2008) #define GFC_STD_OPT_F18 ((GFC_STD_OPT_F08 | GFC_STD_F2018) \ & (~GFC_STD_F2018_DEL)) We could add #define GFC_STD_OPT_GNU03 (GFC_STD_OPT_F03 | GFC_STD_GNU) #define GFC_STD_OPT_GNU08 (GFC_STD_OPT_F08 | GFC_STD_GNU) #define GFC_STD_OPT_GNU18 (GFC_STD_OPT_F18 | GFC_STD_GNU) then in options.c (gfc_handle_options) the case statements would be case OPT_std_gnu2003: gfc_option.allow_std = GFC_STD_OPT_GNU03; gfc_option.warn_std = GFC_STD_F95_OBS; gfc_option.max_identifier_length = 63; warn_ampersand = 1; warn_tabs = 1; break; case OPT_std_gnu2008: gfc_option.allow_std = GFC_STD_OPT_GNU08; gfc_option.warn_std = GFC_STD_F95_OBS | GFC_STD_F2008_OBS; gfc_option.max_identifier_length = 63; warn_ampersand = 1; warn_tabs = 1; break; case OPT_std_gnu2018: gfc_option.allow_std = GFC_STD_OPT_F18; gfc_option.warn_std=GFC_STD_F95_OBS|GFC_STD_F2008_OBS|GFC_STD_F2018_OBS; gfc_option.max_identifier_length = 63; warn_ampersand = 1; warn_tabs = 1; break; then finally lang.opt (and of course documentation would add) std=gnu2003 Fortran Conform to the ISO Fortran 2003 standard with GNU Fortran extensions. std=gnu2008 Fortran Conform to the ISO Fortran 2008 standard with GNU Fortran extensions. std=gnu2018 Fortran Conform to the ISO Fortran 2018 standard with GNU Fortran extensions.
[Bug fortran/89981] [8/9 Regression] gfortran -pedantic rejects code in 8.3.1 that is accepted with 8.3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89981 Thomas Koenig changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org
[Bug rtl-optimization/87763] [9 Regression] aarch64 target testcases fail after r265398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
Jeffrey A. Law changed:
What|Removed |Added
CC||segher at kernel dot
crashing.org
--- Comment #39 from Jeffrey A. Law ---
One option here is to actually throttle back combining for stuff like this
(ud_dce dump):
(insn 2 4 3 2 (set (reg/v:DI 92 [ a ])
(reg:DI 0 x0 [ a ])) "j.c":18:1 47 {*movdi_aarch64}
(expr_list:REG_DEAD (reg:DI 0 x0 [ a ])
(nil)))
(note 3 2 6 2 NOTE_INSN_FUNCTION_BEG)
(insn 6 3 7 2 (set (reg:DI 93)
(const_int 3 [0x3])) "j.c":21:10 47 {*movdi_aarch64}
(nil))
(insn 7 6 13 2 (set (zero_extract:DI (reg/v:DI 92 [ a ])
(const_int 8 [0x8])
(const_int 0 [0]))
(reg:DI 93)) "j.c":21:10 764 {*insv_regdi}
(expr_list:REG_DEAD (reg:DI 93)
(nil)))
(insn 13 7 14 2 (set (reg/i:DI 0 x0)
(reg/v:DI 92 [ a ])) "j.c":22:1 47 {*movdi_aarch64}
(expr_list:REG_DEAD (reg/v:DI 92 [ a ])
(nil)))
We've actually got an RMW insn when combine starts. But...
Trying 17, 7 -> 13:
17: r92:DI=r95:DI
REG_DEAD r95:DI
7: zero_extract(r92:DI,0x8,0)=r93:DI
REG_DEAD r93:DI
13: x0:DI=r92:DI
REG_DEAD r92:DI
Failed to match this instruction:
(set (reg/i:DI 0 x0)
(ior:DI (and:DI (reg:DI 95)
(const_int -256 [0xff00]))
(reg:DI 93)))
We've torn the damn thing apart via expand_field_assignment. Worse yet, that
naturally splits and results in:
Successfully matched this instruction:
(set (reg/v:DI 92 [ a ])
(and:DI (reg:DI 95)
(const_int -256 [0xff00])))
Successfully matched this instruction:
(set (reg/i:DI 0 x0)
(ior:DI (reg/v:DI 92 [ a ])
(reg:DI 93)))
allowing combination of insns 17, 7 and 13
original costs 4 + 4 + 4 = 12
replacement costs 4 + 4 = 8
So we think the split is cheaper.And at this point we've lost. We won't do
further combinations into the second insn (destination is a hard reg and source
isn't a reg). Costing could clearly be improved here. Two copies and a zero
extract are cheaper than two logicals -- largely because the copies often go
away. But we can't know that at this point.
We could throttle attempts to combine into insn 13 if the source is not a
register and that was moderately successful. But it seems to me like we're
better off making try_combine smarter.
It's not hard at all to see something like
(set (reg/i:DI 0 x0)
(ior:DI (and:DI (reg:DI 95)
(const_int -256 [0xff00]))
(reg:DI 93)))
And realize that with a copy we can turn this into a RMW. In the case where
the destination is a hard register we can do something like this
(set (reg 95) (ior (and (reg 95) ...)))
(set (reg 0) (reg 95))
Of course that assumes reg95 dies, but that's easy enough to check. And that
has a good shot at being identified as a bitfield insertion.
Another example:
(set (reg 92))
(ior:DI (and:DI (reg 0)
(const_int -256 [0xff00]))
(reg:DI 93)))
I'm not sure this happens anymore, but it can be addressed in a similar way,
but with a copy before the insn, so
(set (reg 92) (reg 0))
(set (reg 92) (ior (and (reg 92) ...)))
Which again can often be identified as a bitfield insertion.
The all pseudo case can be handled with similar transformations.
This is actually pretty easy to wire into try_combine (rather than
make_field_assignment) just before we do splitting. If we wanted to be really
thorough, we can look at make_field_assignment and create a routine that
handles all the cases found there.
So we identify the cases we want to handle, use subst to make the change so
that it looks like an RMW (subst eventually calls make_field_assignment).
Assuming recognition succeeds, then we emit the copy before/after I3 and let
normal processing continue. If recognition fails we can undo_all and return.
That also seems to handle the combine_bfi regression (though I haven't tested
on Steve's more thorough tests).
It doesn't handle the lsl_ar_sbfix case, but AFAICT that was failing at 265398
as well.
Note this doesn't require major surgery in make_field_extraction or its friends
which is kind of nice given the way they're called out of subst.
Thoughts?
[Bug middle-end/89992] New: Vectorizer is very sensitive to function calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89992
Bug ID: 89992
Summary: Vectorizer is very sensitive to function calls
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
Target Milestone: ---
[hjl@gnu-cfl-1 xxx]$ cat x.c
static __inline unsigned int
__get_cpuid_max (unsigned int __ext, unsigned int *__sig)
{
unsigned int __eax, __ebx, __ecx, __edx;
__asm__ ("cpuid\n\t" : "=a" (__eax), "=b" (__ebx), "=c" (__ecx), "=d" (__edx)
: "0" (__ext));
if (__sig)
*__sig = __ebx;
return __eax;
}
static __inline int
__get_cpuid_count (unsigned int __leaf, unsigned int __subleaf,
unsigned int *__eax, unsigned int *__ebx,
unsigned int *__ecx, unsigned int *__edx)
{
unsigned int __ext = __leaf & 0x8000;
unsigned int __maxlevel = __get_cpuid_max (__ext, 0);
if (__maxlevel == 0 || __maxlevel < __leaf)
return 0;
__asm__ ("cpuid\n\t" : "=a" (*__eax), "=b" (*__ebx), "=c" (*__ecx), "=d"
(*__edx) : "0" (__leaf), "2" (__subleaf));
return 1;
}
static int
avx512f_os_support (void)
{
unsigned int eax, edx;
unsigned int ecx = 0x0;
unsigned int mask = 0x2 | 0x4 | 0x20 | 0x40 | 0x80;
__asm__ ("xgetbv" : "=a" (eax), "=d" (edx) : "c" (ecx));
return ((eax & mask) == mask);
}
int foo (void);
extern void abort (void);
static void do_test (void);
int
main ()
{
unsigned int eax, ebx, ecx, edx;
#ifndef WORK
if (!__get_cpuid_count (7, 0, , , , ))
return 0;
#endif
if (foo () && avx512f_os_support ())
{
do_test ();
return 0;
}
return 0;
}
float a[16] = {-0.1f, -3.2f, -6.3f, -9.4f,
-12.5f, -15.6f, -18.7f, -21.8f,
24.9f, 27.1f, 30.2f, 33.3f,
36.4f, 39.5f, 42.6f, 45.7f};
float b[16] = {-1.2f, 3.4f, -5.6f, 7.8f,
-9.0f, 1.0f, -2.0f, 3.0f,
-4.0f, -5.0f, 6.0f, 7.0f,
-8.0f, -9.0f, 10.0f, 11.0f};
float r[16];
static void
do_test (void)
{
int i;
for (i = 0; i < 16; i++)
r[i] = a[i] * __builtin_copysignf (1.0f, b[i]);
for (i = 0; i < 16; i++)
if (r[i] != a[i] * __builtin_copysignf (1.0f, b[i]))
abort ();
}
[hjl@gnu-cfl-1 xxx]$ make
/export/build/gnu/tools-build/gcc-wip-debug/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/tools-build/gcc-wip-debug/build-x86_64-linux/gcc/ -mavx512f
-mavx512vl -O2 -ftree-vectorize -fdump-tree-vect-details -S x.c
[hjl@gnu-cfl-1 xxx]$ grep vectorized x.c.158t.vect
x.c:45:1: note: vectorized 0 loops in function.
[hjl@gnu-cfl-1 xxx]$
/export/build/gnu/tools-build/gcc-wip-debug/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/tools-build/gcc-wip-debug/build-x86_64-linux/gcc/ -mavx512f
-mavx512vl -O2 -ftree-vectorize -fdump-tree-vect-details -S x.c -DWORK
[hjl@gnu-cfl-1 xxx]$ grep vectorized x.c.158t.vect
x.c:83:10: missed: not vectorized: control flow in loop.
x.c:79:3: note: === vect_mark_stmts_to_be_vectorized ===
x.c:79:3: optimized: loop vectorized using 64 byte vectors
x.c:45:1: note: vectorized 1 loops in function.
[hjl@gnu-cfl-1 xxx]$
Vectorizer doesn't kick in when there are a couple function calls.
[Bug c++/87145] [7/8 Regression] Implicit conversion to scoped enum fails: "error: taking address of temporary/rvalue"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87145 Marek Polacek changed: What|Removed |Added Summary|[7/8/9 Regression] Implicit |[7/8 Regression] Implicit |conversion to scoped enum |conversion to scoped enum |fails: "error: taking |fails: "error: taking |address of |address of |temporary/rvalue" |temporary/rvalue" --- Comment #10 from Marek Polacek --- Fixed on trunk so far.
[Bug c++/87145] [7/8/9 Regression] Implicit conversion to scoped enum fails: "error: taking address of temporary/rvalue"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87145 --- Comment #9 from Marek Polacek --- Author: mpolacek Date: Fri Apr 5 21:22:40 2019 New Revision: 270178 URL: https://gcc.gnu.org/viewcvs?rev=270178=gcc=rev Log: PR c++/87145 - bogus error converting class type in template arg list. * pt.c (convert_nontype_argument): Don't call build_converted_constant_expr if it could involve calling a conversion function with a instantiation-dependent constructor as its argument. * g++.dg/cpp0x/constexpr-conv3.C: New test. * g++.dg/cpp0x/constexpr-conv4.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-conv3.C trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-conv4.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/89925] [9 Regression] Wrong array bounds from ALLOCATE with SOURCE or MOLD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89925 --- Comment #2 from Neil Carlson --- Right, when I said it failed on 8, I had misunderstood my colleague; he had only tried 9.
[Bug c++/89980] [9 Regression] pointer initialization with empty string folded to zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89980 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Component|bootstrap |c++ Resolution|--- |FIXED Summary|[9 Regression] bootstrap|[9 Regression] pointer |failed |initialization with empty ||string folded to zero --- Comment #11 from Martin Sebor --- Fixed in r270177.
[Bug libstdc++/89991] Complex numbers: Calculation of imaginary part is not correct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991 --- Comment #1 from t.sprodowski at web dot de --- Created attachment 46095 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46095=edit Source file Source file to illustrate this bug.
[Bug bootstrap/89980] [9 Regression] bootstrap failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89980 --- Comment #10 from Martin Sebor --- Author: msebor Date: Fri Apr 5 19:49:38 2019 New Revision: 270177 URL: https://gcc.gnu.org/viewcvs?rev=270177=gcc=rev Log: PR bootstrap/89980 - pointer initialization with empty string folded to zero gcc/cp/ChangeLog: PR bootstrap/89980 * decl.c (reshape_init_array_1): Avoid treating empty strings as zeros in array initializers. Use trivial_type_p () instead of TYPE_HAS_TRIVIAL_DFLT(). gcc/testsuite/ChangeLog: PR bootstrap/89980 * g++.dg/init/array52.C: New test. Added: trunk/gcc/testsuite/g++.dg/init/array52.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/89991] New: Complex numbers: Calculation of imaginary part is not correct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89991
Bug ID: 89991
Summary: Complex numbers: Calculation of imaginary part is not
correct
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: t.sprodowski at web dot de
Target Milestone: ---
Following calculation of the complex number leads to a wrong imaginary part:
#include
#include
#include
int main(int argc, char *argv[])
{
std::complex val = std::complex(-1.8425031517782417e-07,
-0.0);
std::complex testExp = std::pow(val, 0.5);
std::cout << "textExp: " << std::setprecision(30) << testExp << std::endl;
return 0;
}
Result is:
(2.6283607659835830609796003783e-20,-0.000429243887758258178214548772544), but
it should be
(2.628360765983583e-20, 0.0004292438877582582), obtained from Visual Studio,
MATLAB and Octave.
Compilation was done with gnu 8.2.0 and 7.3.0 on Ubuntu 18.04:
g++ -c -pipe -g -std=gnu++1y -Wall -W -D_REENTRANT -fPIC
-DQT_DEPRECATED_WARNINGS -DQT_QML_DEBUG -DQT_CORE_LIB -I../testPrecision -I.
-isystem /usr/include/x86_64-linux-gnu/qt5 -isystem
/usr/include/x86_64-linux-gnu/qt5/QtCore -I.
-I/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -o main.o
../testPrecision/main.cpp
[Bug fortran/89981] [8/9 Regression] gfortran -pedantic rejects code in 8.3.1 that is accepted with 8.3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89981 --- Comment #3 from Thomas Koenig --- Reduced test case: program main call bar(i) end program main subroutine foo entry bar(i) end subroutine foo
[Bug c/89990] request warning: Use of out of scope compound literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89990 Andrew Pinski changed: What|Removed |Added Depends on||88058 --- Comment #3 from Andrew Pinski --- PR 88058. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88058 [Bug 88058] gcc fails to detect use of out of scope variable ?
[Bug fortran/55591] strict-aliasing & Fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55591 --- Comment #11 from tkoenig at netcologne dot de --- Am 05.04.19 um 18:20 schrieb dominiq at lps dot ens.fr: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55591 > > --- Comment #10 from Dominique d'Humieres --- >> Testing the updated patch > > The patch retested cleanly, but so far does not show a noticeable compilation > speed up (pr55585 being fixed since some time). > >> Ugh, this looks like a very bad idea. -fstrict-aliasing is very picky >> about type punning and, the last time I looked, the Fortran front-end >> wasn't particularly careful about it. Having a safe optimization mode >> wrt it is generally helpful. > > If there is no further feedback, I'll close the PR as WONTFIX. It might actually make more sense to set the default to "no" (if that isn't already happening by default, I haven't checked).
[Bug c++/89923] printf format check and char8_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89923
--- Comment #4 from Tom Honermann ---
(In reply to Florian Weimer from comment #3)
> But the precedent with wchar_t is that the type of the format string
> determines the type of the %s arguments. I'm not sure if that's a good
> precedent, but it's what we have today.
That matches Microsoft's documented behavior
(https://docs.microsoft.com/en-us/cpp/c-runtime-library/format-specification-syntax-printf-and-wprintf-functions?view=vs-2019),
but it runs contrary to the C standard (C11 7.29.2.1) and glibc behavior.
To be clear, the position I'm suggesting is that we add support for something
like these:
printf("%U8s", u8"text");
printf("%U8c", u8'x');
wprintf(L"%U8s", u8"text");
wprintf(L"%U8c", u8'x');
printf("%U16s", u"text");
printf("%U16c", u'x');
wprintf(L"%U16s", u"text");
wprintf(L"%U16c", u'x');
printf("%U32s", U"text");
printf("%U32c", U'x');
wprintf(L"%U32s", U"text");
wprintf(L"%U32c", U'x');
[Bug c/89990] request warning: Use of out of bound compound initialised struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89990 --- Comment #2 from Andrew Pinski --- https://gcc.gnu.org/gcc-9/porting_to.html -fsantizier=address is able to find these uses after escaping the scope.
[Bug c/89990] request warning: Use of out of bound compound initialised struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89990 --- Comment #1 from Eric Blake --- Other references to compound initializers going out of scope and causing problems: https://stackoverflow.com/questions/47691857/lifetime-of-a-compound-literal https://wiki.sei.cmu.edu/confluence/display/c/DCL21-C.+Understand+the+storage+of+compound+literals Having the compiler flag the programmer's use of undefined behavior, especially where the use-after-free SEEMS to work because an earlier version of the compiler deferred cleanup of the stack space until the function exited (even though it was entitled to do so as soon as the conditional's scope ended), would be handy.
[Bug c/89990] New: request warning: Use of out of bound compound initialised struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89990
Bug ID: 89990
Summary: request warning: Use of out of bound compound
initialised struct
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dgilbert at redhat dot com
Target Milestone: ---
gcc version 9.0.1 20190312 (Red Hat 9.0.1-0.10) (GCC)
on Fedora 30, x86-64
We tripped over code like this in qemu which seems obvious enough that a
warning would be nice:
int foo(mytype *ptr)
{
if (!ptr) {
ptr = &(mytype) { };
}
if (ptr->p)
}
which worked OK on gcc 8, but seg'd on gcc 9 because ptr->p contained rubbish
since the compiler had noticed that the &() { }; went out of scope at the end
of the if.
So a warning would be nice if:
a) A pointer is initialised to point to an initialiser like that
b) That goes out of scope
c) The pointer is then unconditionally used.
The original qemu code is:
https://git.qemu.org/?p=qemu.git;a=blob;f=tests/libqos/qgraph.c;h=122efc1b7b8413bc69d81f2906c89f06eccd994a;hb=HEAD#l75
75 static void add_edge(const char *source, const char *dest,
76 QOSEdgeType type, QOSGraphEdgeOptions *opts)
77 {
78 char *key;
79 QOSGraphEdgeList *list = g_hash_table_lookup(edge_table, source);
80
81 if (!list) {
82 list = g_new0(QOSGraphEdgeList, 1);
83 key = g_strdup(source);
84 g_hash_table_insert(edge_table, key, list);
85 }
86
87 if (!opts) {
88 opts = &(QOSGraphEdgeOptions) { };
89 }
90
91 QOSGraphEdge *edge = g_new0(QOSGraphEdge, 1);
92 edge->type = type;
93 edge->dest = g_strdup(dest);
94 edge->edge_name = g_strdup(opts->edge_name ?: dest);
95 edge->arg = g_memdup(opts->arg, opts->size_arg);
[Bug c++/89989] New: missed devirtualization opportunity on final function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89989
Bug ID: 89989
Summary: missed devirtualization opportunity on final function
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: barry.revzin at gmail dot com
Target Milestone: ---
Example:
struct Base {
virtual int foo() { return 0; }
int bar() { return foo(); }
};
struct Derived : Base {
int foo() override final { return 1; }
};
int call_foo(Derived& d) { return d.foo(); }
int call_bar(Derived& d) { return d.bar(); }
For call_foo, the devirtualization happens:
call_foo(Derived&):
mov eax, 1
ret
For call_bar, gcc emits a branch to check whether 'd' is in fact a Derived:
call_bar(Derived&):
mov rax, QWORD PTR [rdi]
mov rax, QWORD PTR [rax]
cmp rax, OFFSET FLAT:Derived::foo()
jne .L6
mov eax, 1
ret
.L6:
jmp rax
But Derived::foo() is final, so there can't be any other valid behavior besides
simply returning 1.
Notably, if you add "int bar() { return foo(); }" to Derived as well, then
call_bar also just emits "mov eax, 1".
[Bug libstdc++/89986] [9 Regression] missing export for directory_iterator::increment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89986 --- Comment #1 from Jonathan Wakely --- Author: redi Date: Fri Apr 5 16:56:27 2019 New Revision: 270174 URL: https://gcc.gnu.org/viewcvs?rev=270174=gcc=rev Log: PR libstdc++/89986 export directory_iterator::increment PR libstdc++/89986 * config/abi/pre/gnu.ver: Add missing exports. * testsuite/27_io/filesystem/iterators/directory_iterator.cc: Test increment member. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config/abi/pre/gnu.ver trunk/libstdc++-v3/testsuite/27_io/filesystem/iterators/directory_iterator.cc
[Bug libstdc++/87431] valueless_by_exception() should unconditionally return false if all the constructors are noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87431 --- Comment #19 from Jonathan Wakely --- Author: redi Date: Fri Apr 5 16:56:09 2019 New Revision: 270170 URL: https://gcc.gnu.org/viewcvs?rev=270170=gcc=rev Log: PR libstdc++/87431 re-adjust never-valueless optimizations Avoid creating arbitrarily large objects on the stack when emplacing trivially copyable objects into a variant. Currently we provide the strong exception-safety guarantee for all trivially copyable types, by constructing a second variant and then doing a non-throwing move assignment from the temporary. This patch restricts that behaviour to trivially copyable types that are no larger than 256 bytes. For larger types the object will be emplaced directly into the variant, and if its initialization throws then the variant becomes valueless. Also implement Antony Polukhin's suggestion to whitelist specific types that are not trivially copyable but can be efficiently move-assigned. Emplacing those types will never cause a variant to become valueless. The whitelisted types are: std::shared_ptr, std::weak_ptr, std::unique_ptr, std::function, and std::any. Additionally, std::basic_string, std::vector, and __gnu_debug::vector are whitelisted if their allocator traits give them a non-throwing move assignment operator. Specifically, this means std::string is whitelisted, but std::pmr::string is not. As part of this patch, additional if-constexpr branches are added for the cases where the initialization is known to be non-throwing (so the overhead of the try-catch block can be avoided) and where a scalar is being produced by a potentially-throwing conversion operator (so that the overhead of constructing and move-assigning a variant is avoided). These changes should have no semantic effect, just better codegen. PR libstdc++/87431 (again) * include/bits/basic_string.h (__variant::_Never_valueless_alt): Define partial specialization for basic_string. * include/bits/shared_ptr.h (_Never_valueless_alt): Likewise for shared_ptr and weak_ptr. * include/bits/std_function.h (_Never_valueless_alt): Likewise for function. * include/bits/stl_vector.h (_Never_valueless_alt): Likewise for vector. * include/bits/unique_ptr.h (_Never_valueless_alt): Likewise for unique_ptr. * include/debug/vector (_Never_valueless_alt): Likewise for debug vector. * include/std/any (_Never_valueless_alt): Define explicit specialization for any. * include/std/variant (_Never_valueless_alt): Define primary template. (__never_valueless): Use _Never_valueless_alt instead of is_trivially_copyable. (variant::emplace(Args&&...)): Add special case for non-throwing initializations to avoid try-catch overhead. Add special case for scalars produced by potentially-throwing conversions. Use _Never_valueless_alt instead of is_trivially_copyable for the remaining strong exception-safety cases. (variant::emplace(initializer_list, Args&&...)): Likewise. * testsuite/20_util/variant/87431.cc: Run both test functions. * testsuite/20_util/variant/exception_safety.cc: New test. * testsuite/20_util/variant/run.cc: Use pmr::string instead of string, so the variant becomes valueless. Added: trunk/libstdc++-v3/testsuite/20_util/variant/exception_safety.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/basic_string.h trunk/libstdc++-v3/include/bits/shared_ptr.h trunk/libstdc++-v3/include/bits/std_function.h trunk/libstdc++-v3/include/bits/stl_vector.h trunk/libstdc++-v3/include/bits/unique_ptr.h trunk/libstdc++-v3/include/debug/vector trunk/libstdc++-v3/include/std/any trunk/libstdc++-v3/include/std/variant trunk/libstdc++-v3/testsuite/20_util/variant/87431.cc trunk/libstdc++-v3/testsuite/20_util/variant/run.cc
[Bug middle-end/89922] Loop on fixed size array is not unrolled and poorly optimized at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89922 --- Comment #4 from Antony Polukhin --- > Was the testcase just an artificial one or does it appear (in this > isolated form!) in a real application/benchmark? I was not investigating a particular benchmark or real world application at first. My guess is that heuristic will affect cryptography (initializing big arrays with magic constants) and math (matrix multiplication with identity matrix for example). I've tried to check the validity of the guess. The very first attempt succeeded. Hash computation for a constant string is not well optimized: https://godbolt.org/z/iKi0pb The heuristic may notice that the string is a local variable and may force the loop unrolling. Hash computations on a constant variable is a common case in libstdc++ when working with unordered maps and sets. There's definitely some room for improvement for cases when a local variable is used in the loop only.
[Bug bootstrap/89980] [9 Regression] bootstrap failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89980 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #9 from Martin Sebor --- Patch: https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00221.html
[Bug bootstrap/89980] [9 Regression] bootstrap failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89980 Dominique d'Humieres changed: What|Removed |Added CC||seurer at gcc dot gnu.org --- Comment #8 from Dominique d'Humieres --- *** Bug 89988 has been marked as a duplicate of this bug. ***
[Bug other/89988] [9 regression] bootstrap build fails with segfault starting with r270155
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89988 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Dominique d'Humieres --- Dup. *** This bug has been marked as a duplicate of bug 89980 ***
[Bug other/89988] New: [9 regression] bootstrap build fails with segfault starting with r270155
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89988 Bug ID: 89988 Summary: [9 regression] bootstrap build fails with segfault starting with r270155 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- . . . make[3]: Entering directory `/home/seurer/gcc/build/gcc-trunk-bootstrap/gcc' build/gengtype \ -S /home/seurer/gcc/gcc-trunk-bootstrap/gcc -I gtyp-input.list -w tmp-gtype.state make[3]: *** [s-gtype] Segmentation fault make[3]: Leaving directory `/home/seurer/gcc/build/gcc-trunk-bootstrap/gcc' make[2]: *** [all-stage2-gcc] Error 2 . . .
[Bug bootstrap/89980] [9 Regression] bootstrap failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89980 --- Comment #7 from Andreas Schwab --- It fails everywhere.
[Bug bootstrap/89980] [9 Regression] bootstrap failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89980 --- Comment #6 from H.J. Lu --- (In reply to Martin Sebor from comment #5) > Thanks for the small test case. > > The affected x86 targets are presumably limited to i386. My x86_64 > bootstrap was successful. It also failed on x86-64 with --prefix=/usr/9.0.1 --enable-clocale=gnu --with-system-zlib --enable-shared --enable-cet --with-demangler-in-ld --with-fpmath=sse
[Bug fortran/55591] strict-aliasing & Fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55591 --- Comment #10 from Dominique d'Humieres --- > Testing the updated patch The patch retested cleanly, but so far does not show a noticeable compilation speed up (pr55585 being fixed since some time). > Ugh, this looks like a very bad idea. -fstrict-aliasing is very picky > about type punning and, the last time I looked, the Fortran front-end > wasn't particularly careful about it. Having a safe optimization mode > wrt it is generally helpful. If there is no further feedback, I'll close the PR as WONTFIX.
[Bug bootstrap/89980] [9 Regression] bootstrap failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89980 --- Comment #5 from Martin Sebor --- Thanks for the small test case. The affected x86 targets are presumably limited to i386. My x86_64 bootstrap was successful.
[Bug c/89985] [9 Regression] Stray notes from OPT_Waddress_of_packed_member with -w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89985 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from David Malcolm --- Should be fixed by r270169.
[Bug c/89985] [9 Regression] Stray notes from OPT_Waddress_of_packed_member with -w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89985 --- Comment #1 from David Malcolm --- Author: dmalcolm Date: Fri Apr 5 15:15:37 2019 New Revision: 270169 URL: https://gcc.gnu.org/viewcvs?rev=270169=gcc=rev Log: Guard notes for -Waddress-of-packed-member on warning emission (PR c/89985) gcc/c-family/ChangeLog: PR c/89985 * c-warn.c (check_address_or_pointer_of_packed_member): Add auto_diagnostic_group. Guard inform calls by result of warning_at call. gcc/testsuite/ChangeLog: PR c/89985 * c-c++-common/pr89985.c: New test. Added: trunk/gcc/testsuite/c-c++-common/pr89985.c Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-warn.c trunk/gcc/testsuite/ChangeLog
[Bug c/71598] Wrong optimization with aliasing enums
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71598 --- Comment #16 from Christophe Lyon --- Author: clyon Date: Fri Apr 5 15:10:12 2019 New Revision: 270168 URL: https://gcc.gnu.org/viewcvs?rev=270168=gcc=rev Log: [testsuite] PR71598: Fix testcases again 2019-04-05 Christophe Lyon PR c/71598 * gcc.dg/torture/pr71598-1.c: dg-prune arm linker messages about size of enums. * gcc.dg/torture/pr71598-2.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/torture/pr71598-1.c trunk/gcc/testsuite/gcc.dg/torture/pr71598-2.c
[Bug c++/89973] [9 Regression] ICE in check_address_or_pointer_of_packed_member, at c-family/c-warn.c:2769
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89973 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Marek Polacek --- Fixed.
[Bug c++/89973] [9 Regression] ICE in check_address_or_pointer_of_packed_member, at c-family/c-warn.c:2769
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89973 --- Comment #2 from Marek Polacek --- Author: mpolacek Date: Fri Apr 5 14:56:53 2019 New Revision: 270166 URL: https://gcc.gnu.org/viewcvs?rev=270166=gcc=rev Log: PR c++/89973 - -Waddress-of-packed-member ICE with invalid conversion. * c-warn.c (check_address_or_pointer_of_packed_member): Check the type of RHS. * g++.dg/warn/Waddress-of-packed-member2.C: New test. Added: trunk/gcc/testsuite/g++.dg/warn/Waddress-of-packed-member2.C Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-warn.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/89987] New: ICE on GCC trunk and GCC 8 on arm-none-linux-gnueabihf target with “-O1” option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89987 Bug ID: 89987 Summary: ICE on GCC trunk and GCC 8 on arm-none-linux-gnueabihf target with “-O1” option Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: srinath.parvathaneni at arm dot com Target Milestone: --- ICE on GCC trunk and latest GCC 8 on arm-none-linux-gnueabihf with “-O1” option. $cat test.f90 recursive subroutine e k = transfer (transfer (e, e), 1) end $arm-none-linux-gnueabihf-gfortran test.f90 -O1 -S during GIMPLE pass: ccp ../../test.f90:3:0: 3 | end | internal compiler error: in fold_convert_loc, at fold-const.c:2552 0x438231 fold_convert_loc(unsigned int, tree_node*, tree_node*) /tmp/dgboter/bbs/moonshot-dsg-20-armhf--armhf/buildbot/native-glibc-arm-none-linux-gnueabihf/build/src/gcc/gcc/fold-const.c:2552 0x78dfb5 evaluate_stmt /tmp/dgboter/bbs/moonshot-dsg-20-armhf--armhf/buildbot/native-glibc-arm-none-linux-gnueabihf/build/src/gcc/gcc/tree-ssa-ccp.c:1997 0x78eea1 visit_assignment /tmp/dgboter/bbs/moonshot-dsg-20-armhf--armhf/buildbot/native-glibc-arm-none-linux-gnueabihf/build/src/gcc/gcc/tree-ssa-ccp.c:2352 0x7f905b ssa_propagation_engine::simulate_stmt(gimple*) /tmp/dgboter/bbs/moonshot-dsg-20-armhf--armhf/buildbot/native-glibc-arm-none-linux-gnueabihf/build/src/gcc/gcc/tree-ssa-propagate.c:230 0x7f927d ssa_propagation_engine::simulate_block(basic_block_def*) /tmp/dgboter/bbs/moonshot-dsg-20-armhf--armhf/buildbot/native-glibc-arm-none-linux-gnueabihf/build/src/gcc/gcc/tree-ssa-propagate.c:337 0x7fa33b ssa_propagation_engine::ssa_propagate() /tmp/dgboter/bbs/moonshot-dsg-20-armhf--armhf/buildbot/native-glibc-arm-none-linux-gnueabihf/build/src/gcc/gcc/tree-ssa-propagate.c:802 0x787197 do_ssa_ccp /tmp/dgboter/bbs/moonshot-dsg-20-armhf--armhf/buildbot/native-glibc-arm-none-linux-gnueabihf/build/src/gcc/gcc/tree-ssa-ccp.c:2471 0x787197 execute /tmp/dgboter/bbs/moonshot-dsg-20-armhf--armhf/buildbot/native-glibc-arm-none-linux-gnueabihf/build/src/gcc/gcc/tree-ssa-ccp.c:2515
[Bug ipa/89893] Segmentation fault always occurs when node app is generated by gcc-8-branch@268745
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89893 --- Comment #30 from 康 珊 --- (In reply to Martin Liška from comment #29) > > Thanks for your reminder. Currently I found there were 3 ways to solve the > > issue. > > 1.Remove “enable-lto” in configure and open “fno-strict-aliasing”. > > 2.Add “__attribute__((noipa))” to the uv_unref(uv_handle_t*) function. > > 3.Add “__attribute__((noinline))” to the uv_unref(uv_handle_t*) function. > > Maybe the first solution is a more reliable one in contrast to the other two > > solutions. As solution 2 and 3 are more likely a workaround. Do you have any > > suggestions? > > It's always needed to use -fno-strict-aliasing as mentioned here: > https://github.com/nodejs/node/issues/27054 > > and the using --enable-lto should be fine. But if using "--enable-lto" and "-fno-strict-aliasing", the issue cannot be solved. In order to solve the issue, besides those options, “__attribute__((noipa))” has to be added to the uv_unref(uv_handle_t*) function. So you recommend this solution, right?
[Bug gcov-profile/89961] When "--intermediate-format" is used "--preserve-paths"/"--hash-filenames" is ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89961 --- Comment #7 from Martin Liška --- I take it base. Makes sense to behave exactly as for non-intermediate format mode.
[Bug gcov-profile/89961] When "--intermediate-format" is used "--preserve-paths"/"--hash-filenames" is ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89961 --- Comment #6 from Martin Liška --- (In reply to Cristian Morales Vega from comment #5) > OK, trying to catch you here, from my gcc-8.3.1. > So with gcc 9 "--intermediate-format" is gone and we now have > "--json-format" (keeping the "-i" version)? > > The "--intermediate-format" documentation used to say "can be used by lcov > or other tools". I guess the lcov devs know about this, but aren't the devs > of "other tools" going to be cross? I mean, I was suggesting to cmake to use > "--intermediate-format" > (https://gitlab.kitware.com/cmake/cmake/issues/19124#note_554428)... now > they would need to support two formats to be able to support different gcov > versions. > > > In any case I'm unsure how "current_working_directory" or "data_file" help > with the cmake case. The problem is that cmake is going to call gcov once > and it's going to create > > /tmp/error.cpp.gcda.gcov.json.gz > > with whatever contents, based on what > CMakeFiles/.dir/src/error.cpp.gcda says. > > Then it's going to call gcov again, it's going to overwrite/destroy the > /tmp/error.cpp.gcda.gcov.json.gz file created one second ago, and in its > place is going to create a new > > /tmp/error.cpp.gcda.gcov.json.gz > > file based on what test/CMakeFiles/.dir/error.cpp.gcda > says. > > So all the information contained on > CMakeFiles/.dir/src/error.cpp.gcda gets lost. > > > Sure, cmake could put the files in different directories to avoid Well, if cmake is overwriting the content, then it should be fixed on cmake side. > overwriting them, but it doesn't. And if cmake could do "-x -i" I would end > up with two files: > > /tmp/error.cpp.gcda##3626990101906c77dbd16dea3f1aab07.gcov.json.gz > /tmp/error.cpp.gcda##39f7c940c3bc30bbedebd034d8c16a68.gcov.json.gz > > and so no information would be lost. This is a workaround and I don't like it much.
[Bug ipa/89893] Segmentation fault always occurs when node app is generated by gcc-8-branch@268745
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89893 --- Comment #29 from Martin Liška --- > Thanks for your reminder. Currently I found there were 3 ways to solve the > issue. > 1.Remove “enable-lto” in configure and open “fno-strict-aliasing”. > 2.Add “__attribute__((noipa))” to the uv_unref(uv_handle_t*) function. > 3.Add “__attribute__((noinline))” to the uv_unref(uv_handle_t*) function. > Maybe the first solution is a more reliable one in contrast to the other two > solutions. As solution 2 and 3 are more likely a workaround. Do you have any > suggestions? It's always needed to use -fno-strict-aliasing as mentioned here: https://github.com/nodejs/node/issues/27054 and the using --enable-lto should be fine.
[Bug gcov-profile/89961] When "--intermediate-format" is used "--preserve-paths"/"--hash-filenames" is ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89961 --- Comment #5 from Cristian Morales Vega --- OK, trying to catch you here, from my gcc-8.3.1. So with gcc 9 "--intermediate-format" is gone and we now have "--json-format" (keeping the "-i" version)? The "--intermediate-format" documentation used to say "can be used by lcov or other tools". I guess the lcov devs know about this, but aren't the devs of "other tools" going to be cross? I mean, I was suggesting to cmake to use "--intermediate-format" (https://gitlab.kitware.com/cmake/cmake/issues/19124#note_554428)... now they would need to support two formats to be able to support different gcov versions. In any case I'm unsure how "current_working_directory" or "data_file" help with the cmake case. The problem is that cmake is going to call gcov once and it's going to create /tmp/error.cpp.gcda.gcov.json.gz with whatever contents, based on what CMakeFiles/.dir/src/error.cpp.gcda says. Then it's going to call gcov again, it's going to overwrite/destroy the /tmp/error.cpp.gcda.gcov.json.gz file created one second ago, and in its place is going to create a new /tmp/error.cpp.gcda.gcov.json.gz file based on what test/CMakeFiles/.dir/error.cpp.gcda says. So all the information contained on CMakeFiles/.dir/src/error.cpp.gcda gets lost. Sure, cmake could put the files in different directories to avoid overwriting them, but it doesn't. And if cmake could do "-x -i" I would end up with two files: /tmp/error.cpp.gcda##3626990101906c77dbd16dea3f1aab07.gcov.json.gz /tmp/error.cpp.gcda##39f7c940c3bc30bbedebd034d8c16a68.gcov.json.gz and so no information would be lost.
[Bug libstdc++/89986] [9 Regression] missing export for directory_iterator::increment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89986 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-04-05 Version|unknown |9.0 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Target Milestone|--- |9.0 Ever confirmed|0 |1
[Bug libstdc++/89986] New: [9 Regression] missing export for directory_iterator::increment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89986
Bug ID: 89986
Summary: [9 Regression] missing export for
directory_iterator::increment
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: link-failure
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
#include
int main()
{
std::error_code ec;
std::filesystem::directory_iterator it("/", ec);
it.increment(ec);
}
Using GCC 8 and linking to libstdc++fs.a this works, but using GCC 9 it
doesn't:
/usr/bin/ld: /tmp/ccC5CJow.o: in function `main':
/tmp/dir.cc:7: undefined reference to
`std::filesystem::__cxx11::directory_iterator::increment(std::error_code&)'
collect2: error: ld returned 1 exit status
I forgot to export that symbol after moving the definitions to libstdc++.so
(and apparently never tested it!)
[Bug ipa/89893] Segmentation fault always occurs when node app is generated by gcc-8-branch@268745
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89893
--- Comment #28 from 康 珊 ---
(In reply to Martin Liška from comment #27)
> (In reply to 康 珊 from comment #26)
> > I found the previous build log is like "g++ -o
> > /builddir/build/BUILD/node-v10.15.3/out/Release/cctest -pthread -rdynamic
> > -m64
> > -Wl,--whole-archive,/builddir/build/BUILD/node-v10.15.3/out/Release/obj.
> > target/deps/uv/libuv.a -Wl,--no-whole-archive -Wl,-z,noexecstack
> > -Wl,--whole-archive
> > /builddir/build/BUILD/node-v10.15.3/out/Release/obj.target/deps/v8/gypfiles/
> > libv8_base.a -Wl,--no-whole-archive -Wl,-z,relro -Wl,-z,now -Wl,-T
> > /builddir/build/BUILD/node-v10.15.3/src/large_pages/ld.implicit.script
> > -pthread -flto=4 -fuse-linker-plugin -ffat-lto-objects -fno-lto
> > -Wl,--start-group
> > /builddir/build/BUILD/node-v10.15.3/out/Release/obj.target/cctest/test/
> > cctest/node_test_fixture.o...", you mean link options like "-flto=4
> > -ffat-lto-objects -fno-lto" are not accurate and "-fno-lto" will not take
> > effect, right?
>
> It will take effect, but you defined that only in LDFLAGS.
> Anyway, please don't use --enable-lto with {LD,C,CXX}FLAGS="${LDFLAGS}
> -fno-lto"!
Thanks for your reminder. Currently I found there were 3 ways to solve the
issue.
1.Remove “enable-lto” in configure and open “fno-strict-aliasing”.
2.Add “__attribute__((noipa))” to the uv_unref(uv_handle_t*) function.
3.Add “__attribute__((noinline))” to the uv_unref(uv_handle_t*) function.
Maybe the first solution is a more reliable one in contrast to the other two
solutions. As solution 2 and 3 are more likely a workaround. Do you have any
suggestions?
[Bug gcov-profile/89961] When "--intermediate-format" is used "--preserve-paths"/"--hash-filenames" is ignored
"blocks": 2,
"blocks_executed": 0,
"demangled_name": "foo",
"end_column": 1,
"end_line": 4,
"execution_count": 0,
"name": "foo",
"start_column": 5,
"start_line": 1
}
],
"lines": [
{
"branches": [],
"count": 0,
"function_name": "foo",
"line_number": 1,
"unexecuted_block": true
},
{
"branches": [],
"count": 0,
"function_name": "foo",
"line_number": 3,
"unexecuted_block": true
}
]
}
],
"format_version": "1",
"gcc_version": "9.0.1 20190405 (experimental)"
}
Which should help you with uniq mapping now.
Patch candidate:
diff --git a/gcc/gcov.c b/gcc/gcov.c
index 1d576552a45..1fc37a07c34 100644
--- a/gcc/gcov.c
+++ b/gcc/gcov.c
@@ -1421,6 +1421,7 @@ generate_results (const char *file_name)
if (bbg_cwd != NULL)
root->set ("current_working_directory", new json::string (bbg_cwd));
+ root->set ("data_file", new json::string (file_name));
json::array *json_files = new json::array ();
root->set ("files", json_files);
[Bug c/89985] New: [9 Regression] Stray notes from OPT_Waddress_of_packed_member with -w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89985
Bug ID: 89985
Summary: [9 Regression] Stray notes from
OPT_Waddress_of_packed_member with -w
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Given the following source:
typedef unsigned char uint8_t;
typedef unsigned short int uint16_t;
typedef unsigned int uint32_t;
struct a {
uint8_t f0;
uint8_t f1;
uint16_t f2;
} __attribute__((packed));
struct b {
uint16_t f0;
};
void
test (struct a *p)
{
struct b *q= (struct b *)p;
}
when compiled with -w, gcc 9 emits just these stray notes:
rhbz1696441.c: In function ‘test’:
../../src/rhbz1696441.c:5:8: note: defined here
5 | struct a {
|^
rhbz1696441.c:11:8: note: defined here
11 | struct b {
|^
(from downstream report https://bugzilla.redhat.com/show_bug.cgi?id=1696441 )
The notes are followups to -Waddress-of-packed-member warnings, which aren't
being properly guarded by emission of that warning in c-family/c-warn.c:
2776 warning_at (location, OPT_Waddress_of_packed_member,
2777 "converting a packed %qT pointer (alignment
%d) "
2778 "to a %qT pointer (alignment %d) may result
in an "
2779 "unaligned pointer value",
2780 rhstype, rhs_align, type, type_align);
2781 tree decl = TYPE_STUB_DECL (rhstype);
2782 if (decl)
2783inform (DECL_SOURCE_LOCATION (decl), "defined here");
2784 decl = TYPE_STUB_DECL (type);
2785 if (decl)
2786inform (DECL_SOURCE_LOCATION (decl), "defined here");
which is normally guarded by:
2886warn_for_address_or_pointer_of_packed_member (tree type, tree rhs)
2887{
2888 if (!warn_address_of_packed_member)
2889return;
but the "-w" sidesteps this (via diagnostic_report_warnings_p).
Appears to be new with gcc 9.
I'm working on a fix.
[Bug target/89929] __attribute__((target("avx512bw"))) doesn't work on non avx512bw systems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89929 --- Comment #12 from H.J. Lu --- (In reply to Martin Liška from comment #11) > Agree with Nick, one should be able to have clones with specific AVX512 > flavors. > I can prepare patch for it, only issues is the priority as I already > mentioned. > Priorities are used to choose processors for multi-versioned functions. Please see how to use avx512XXX to distinguish: const wide_int_bitmask PTA_SKYLAKE_AVX512 = PTA_SKYLAKE | PTA_AVX512F const wide_int_bitmask PTA_CASCADELAKE = PTA_SKYLAKE_AVX512 | PTA_AVX512VNNI; const wide_int_bitmask PTA_CANNONLAKE = PTA_SKYLAKE | PTA_AVX512F const wide_int_bitmask PTA_ICELAKE_CLIENT = PTA_CANNONLAKE | PTA_AVX512VNNI const wide_int_bitmask PTA_ICELAKE_SERVER = PTA_ICELAKE_CLIENT | PTA_PCONFIG const wide_int_bitmask PTA_KNL = PTA_BROADWELL | PTA_AVX512PF | PTA_AVX512ER const wide_int_bitmask PTA_KNM = PTA_KNL | PTA_AVX5124VNNIW
[Bug rtl-optimization/89984] New: Extra register move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89984
Bug ID: 89984
Summary: Extra register move
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
Target Milestone: ---
Target: x86-64,i386
[hjl@gnu-cfl-1 xxx]$ cat x.i
float
check_f_pos (float x, float y)
{
return x * __builtin_copysignf (1.0f, y);
}
[hjl@gnu-cfl-1 xxx]$ cat x.i
float
check_f_pos (float x, float y)
{
return x * __builtin_copysignf (1.0f, y);
}
[hjl@gnu-cfl-1 xxx]$ make
/export/build/gnu/tools-build/gcc-wip-debug/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/tools-build/gcc-wip-debug/build-x86_64-linux/gcc/ -mavx2
-O2 -S x.i
[hjl@gnu-cfl-1 xxx]$ cat x.s
.file "x.i"
.text
.p2align 4
.globl check_f_pos
.type check_f_pos, @function
check_f_pos:
.LFB0:
.cfi_startproc
vandps .LC0(%rip), %xmm1, %xmm1
vxorps %xmm0, %xmm1, %xmm1
^^^ Why not just do
vxorps %xmm0, %xmm1, %xmm0
vmovaps %xmm1, %xmm0
ret
.cfi_endproc
.LFE0:
.size check_f_pos, .-check_f_pos
.section.rodata.cst16,"aM",@progbits,16
.align 16
.LC0:
.long 2147483648
.long 0
.long 0
.long 0
.ident "GCC: (GNU) 9.0.1 20190403 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-cfl-1 xxx]$
[Bug debug/89905] gcc generates wrong debug information at -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89905 --- Comment #4 from Richard Biener --- Author: rguenth Date: Fri Apr 5 11:55:45 2019 New Revision: 270165 URL: https://gcc.gnu.org/viewcvs?rev=270165=gcc=rev Log: 2019-04-05 Richard Biener PR debug/89892 PR debug/89905 * tree-cfgcleanup.c (remove_forwarder_block): Always move debug bind stmts but reset them if they are not valid at the destination. * gcc.dg/guality/pr89892.c: New testcase. * gcc.dg/guality/pr89905.c: Likewise. * gcc.dg/guality/loop-1.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/guality/loop-1.c trunk/gcc/testsuite/gcc.dg/guality/pr89892.c trunk/gcc/testsuite/gcc.dg/guality/pr89905.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-cfgcleanup.c
[Bug debug/89892] gcc generates wrong debug information at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89892 --- Comment #6 from Richard Biener --- Author: rguenth Date: Fri Apr 5 11:55:45 2019 New Revision: 270165 URL: https://gcc.gnu.org/viewcvs?rev=270165=gcc=rev Log: 2019-04-05 Richard Biener PR debug/89892 PR debug/89905 * tree-cfgcleanup.c (remove_forwarder_block): Always move debug bind stmts but reset them if they are not valid at the destination. * gcc.dg/guality/pr89892.c: New testcase. * gcc.dg/guality/pr89905.c: Likewise. * gcc.dg/guality/loop-1.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/guality/loop-1.c trunk/gcc/testsuite/gcc.dg/guality/pr89892.c trunk/gcc/testsuite/gcc.dg/guality/pr89905.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-cfgcleanup.c
[Bug debug/89983] New: Missing debug info for final loop IV value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89983
Bug ID: 89983
Summary: Missing debug info for final loop IV value
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
For
void foo(int n)
{
if (n == 0)
return;
int i = 0;
do
{
++i;
}
while (i < n);
__asm__ volatile ("" : : "g" (i) : "memory");
}
int main() { foo(5); return 0; }
if you compile this with optimization but final-value replacement disabled
(-fno-tree-scev-cprop or simply when using -Og) gdb only prints
for i when breaking at the inline asm. It is actually
the 'ret' instruction that is associated with that line (and line
association in the loop is generally weird, with no assembly instruction
associated with the loop condition...).
.debug_loc shows
0002 v000 v001 views at for:
0009 0010 (DW_OP_reg0 (rax))
that's just for the add if I deciper correctly. The issue might be that
we have
[local count: 1073741824]:
# i_1 = PHI <[t.c:5:7] 0(2), [t.c:8:7] i_4(3)>
# DEBUG i => i_1
[t.c:6:3] # DEBUG BEGIN_STMT
[t.c:8:7] # DEBUG BEGIN_STMT
[t.c:8:7] i_4 = i_1 + 1;
[t.c:8:7] # DEBUG i => i_4
[t.c:10:3] if (n_3(D) > i_4)
goto ; [89.00%]
else
goto ; [11.00%]
[local count: 118111601]:
[t.c:11:3] # DEBUG BEGIN_STMT
[t.c:11:3] __asm__ __volatile__("" : : "g" i_4 : "memory");
thus refer to the value before and after the increment (but we have
only one instruction). Still there's the compare and branch to have
the new value (in same register) plus of course the ret.
Note the RTL seems to reflect things correctly at var-tracking time
but then var-tracking has
(note 41 21 42 (var_location i (nil)) NOTE_INSN_VAR_LOCATION)
(note 42 41 24 (var_location n (reg:SI 5 di [ n ])) NOTE_INSN_VAR_LOCATION)
between the asm and the simple-return. Somehow the asm itself has
a REG_DEAD note on ax (well, it's the last use). Using a nop in the
asm "fixes" the debug experience.
This will be gcc.dg/guality/loop-1.c (but with a nop).
The testcase as in the testsuite also fails at -O3 because of unknown reasons.
[Bug bootstrap/89980] [9 Regression] bootstrap failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89980 Richard Biener changed: What|Removed |Added CC||ro at gcc dot gnu.org --- Comment #4 from Richard Biener --- *** Bug 89982 has been marked as a duplicate of this bug. ***
[Bug bootstrap/89982] [9 regression] SEGV in stage2 gengtype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89982 Richard Biener changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Richard Biener --- . *** This bug has been marked as a duplicate of bug 89980 ***
[Bug bootstrap/89982] [9 regression] SEGV in stage2 gengtype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89982 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-04-05 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Duplicate of pr89980?
[Bug ipa/89975] Compile-time hog w/ large values of --param uninlined-function-insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89975 --- Comment #3 from Jan Hubicka --- Well, the parameter says that average function prologue+epilogue overhead is 20 instructions. Inliner thus thinks it is very cool to deeply recursively inline. The resulting inline decision is pretty wide tree so the recursion depth limits hits relatively late. Also the recursive inlining limit is applied by counting of number of inlining of a function to itself, while here the tree has multiple functions on it. So I would say it is a consequence of instance value of uninlined-function-insns.
[Bug bootstrap/89982] [9 regression] SEGV in stage2 gengtype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89982 Rainer Orth changed: What|Removed |Added Target Milestone|--- |9.0
[Bug bootstrap/89982] New: [9 regression] SEGV in stage2 gengtype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89982 Bug ID: 89982 Summary: [9 regression] SEGV in stage2 gengtype Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org Target Milestone: --- Target: i386-pc-solaris2.11, sparc-sun-solaris2.11, x86_64-pc-linux-gnu, x86_64-apple-darwin11.4.2 Between 20190404 (r270144) and 20490405 (r270162), bootstrap started to fail on many targets: during stage2 gengtype SEGVs: build/gengtype \ -S /vol/gcc/src/hg/trunk/local/gcc -I gtyp-input.list -w tmp-gtype.state make[3]: *** [Makefile:2642: s-gtype] Segmentation Fault On Linux/x86_64, I see Program received signal SIGSEGV, Segmentation fault. 0x77cf7cfa in __strlen_sse2 () from /lib64/libc.so.6 (gdb) where #0 0x77cf7cfa in __strlen_sse2 () from /lib64/libc.so.6 #1 0x004076c5 in adjust_field_type(type*, options*) () #2 0x00407c29 in create_field_at(pair*, type*, char const*, options*, fileloc*) () #3 0x0040f379 in type(options**, bool) () #4 0x00410137 in parse_file(char const*) () #5 0x0040416b in main () (gdb) up #1 0x004076c5 in adjust_field_type(type*, options*) () Starting a reghunt as we speak since the obvious candidate patch didn't cause it.
[Bug fortran/55591] strict-aliasing & Fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55591 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #9 from Eric Botcazou --- Ugh, this looks like a very bad idea. -fstrict-aliasing is very picky about type punning and, the last time I looked, the Fortran front-end wasn't particularly careful about it. Having a safe optimization mode wrt it is generally helpful.
[Bug rtl-optimization/87871] [9 Regression] testcases fail after r265398 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871 Richard Earnshaw changed: What|Removed |Added CC||rearnsha at gcc dot gnu.org --- Comment #10 from Richard Earnshaw --- I wonder if this could be picked up in the post-reload CSE pass? (ie rewriting the CBZ to use the incoming hard reg?)
[Bug rtl-optimization/87871] [9 Regression] testcases fail after r265398 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #9 from Richard Earnshaw ---
(In reply to Wilco from comment #8)
> (In reply to Segher Boessenkool from comment #5)
> > The first one just needs an xfail. I don't know if it should be *-*-* there
> > or only arm*-*-* should be added.
> >
> > The other two need some debugging by someone who knows the target and/or
> > these tests.
>
> The previous code for Arm was:
>
> cbz r0, .L5
> push{r4, lr}
> mov r4, r0
> bl foo
> movwr2, #:lower16:.LANCHOR0
> movtr2, #:upper16:.LANCHOR0
> add r4, r4, r0
> str r4, [r2]
> pop {r4, pc}
> .L5:
> movsr0, #1
> bx lr
>
> Now it fails to shrinkwrap:
>
> push{r4, lr}
> mov r4, r0
> cmp r4, #0
> moveq r0, #1
> beq .L3
> bl foo
> ldr r2, .L7
> add r3, r4, r0
> str r3, [r2]
> .L3:
> pop {r4, lr}
> bx lr
>
> It seems shrinkwrapping is more random, sometimes it's done as expected,
> sometimes it is not. It was more consistent on older GCC's.
This looks like another fallout of not allowing combine to merge with hard
regs. Previously the CBZ could be moved outside of the prologue because it
operated directly on the incoming hard reg. Now it only sees the value after
the copy into the pseudo, which is a call-saved reg because it's live over the
call.
[Bug ipa/89893] Segmentation fault always occurs when node app is generated by gcc-8-branch@268745
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89893
--- Comment #27 from Martin Liška ---
(In reply to 康 珊 from comment #26)
> I found the previous build log is like "g++ -o
> /builddir/build/BUILD/node-v10.15.3/out/Release/cctest -pthread -rdynamic
> -m64
> -Wl,--whole-archive,/builddir/build/BUILD/node-v10.15.3/out/Release/obj.
> target/deps/uv/libuv.a -Wl,--no-whole-archive -Wl,-z,noexecstack
> -Wl,--whole-archive
> /builddir/build/BUILD/node-v10.15.3/out/Release/obj.target/deps/v8/gypfiles/
> libv8_base.a -Wl,--no-whole-archive -Wl,-z,relro -Wl,-z,now -Wl,-T
> /builddir/build/BUILD/node-v10.15.3/src/large_pages/ld.implicit.script
> -pthread -flto=4 -fuse-linker-plugin -ffat-lto-objects -fno-lto
> -Wl,--start-group
> /builddir/build/BUILD/node-v10.15.3/out/Release/obj.target/cctest/test/
> cctest/node_test_fixture.o...", you mean link options like "-flto=4
> -ffat-lto-objects -fno-lto" are not accurate and "-fno-lto" will not take
> effect, right?
It will take effect, but you defined that only in LDFLAGS.
Anyway, please don't use --enable-lto with {LD,C,CXX}FLAGS="${LDFLAGS}
-fno-lto"!
[Bug fortran/89981] [8/9 Regression] gfortran -pedantic rejects code in 8.3.1 that is accepted with 8.3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89981 Richard Biener changed: What|Removed |Added Priority|P3 |P4
[Bug rtl-optimization/89944] [7/8/9 Regression] ICE in mark_jump_label_1, at jump.c:1152
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89944 Eric Botcazou changed: What|Removed |Added Status|NEW |RESOLVED CC||ebotcazou at gcc dot gnu.org Resolution|--- |WONTFIX --- Comment #2 from Eric Botcazou --- -- Built-in Function: void __builtin_longjmp (intptr_t *BUF, int VAL) This function restores the stack context in BUF, saved by a previous call to `__builtin_setjmp'. After `__builtin_longjmp' is finished, the program resumes execution as if the matching `__builtin_setjmp' returns the value VAL, which must be 1. Because `__builtin_longjmp' depends on the function return mechanism to restore the stack context, it cannot be called from the same function calling `__builtin_setjmp' to initialize BUF. It can only be called from a function called (directly or indirectly) from the function calling `__builtin_setjmp'.
[Bug fortran/84382] add command-line options -std=gnu2003 and -std=gnu2008 for gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84382 --- Comment #4 from janus at gcc dot gnu.org --- (In reply to kargl from comment #3) > How do you propose to enforce a certain standard and allow > GNU extensions? For example, -std=gnu2003 would enforce > Fortran 2003, but allow GNU extensions. The problem is that > gfortran allows several extensions that violate the > standard. The idea is that -std=gnu2003 would allow 2003 features plus GNU extensions, but reject any 2008 and 2018 features (like submodules and coarrays). > gfortran even allows extensions that aren't caught by the -std > options and are not document! That's a separate issue and discussion, not related to this PR. Ideally all extensions should be caught and documented, of course. > I think it will becomes a endless discussion on what should > and should not be covered under -std=gnu2003. I don't see that. We already have a more-or-less complete classification of what is a 2003 or 2008 feature and what is a non-std extension. My proposal would simply introduce new options corresponding to different combinations of feature classes. > What we have > now seems to be the most reasonable approach (with the > available man power to address problem). Either a user > wants GNU Fortran (ie., -std=gnu, the default behavior) or > a user wants a stricter adherence to a particular standard. I have not really thought about how to implement this PR. I assumed it would be easy to modify/extend gfc_notify_std & friends to accomomdate some new feature levels. At some point I just had the idea for this PR and I wanted to write it down for the future to think about and evaluate the idea. I haven't started an implementation because it's not high priority for me. If it's simply not needed or there is consensus that it's not worth the effort, then I'm willing to discuss and possibly close this PR, but certainly not due to someone yelling WTF. Also I don't see what's wrong about letting it hang in bugzilla until it becomes a priority/necessity for someone.
[Bug libstdc++/89979] subtract_with_carry_engine incorrect carry flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89979 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-05 Ever confirmed|0 |1 --- Comment #2 from Jonathan Wakely --- (In reply to Christoph Conrads from comment #1) > There is no attachment with the preprocessed code demonstrating the problem > because the this code is 1.2 MB large. That's OK in this case as you code doesn't depend on anything except standard library headers.
[Bug tree-optimization/89499] [7/8/9 Regression] ICE in expand_UNIQUE, at internal-fn.c:2605
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89499 --- Comment #5 from Thomas Schwinge --- Created attachment 46094 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46094=edit [WIP] [PR89499] CIF_OPENACC_ROUTINE_MISMATCH (In reply to Thomas Schwinge from comment #4) > Unless there is an OpenACC 'bind' clause involved (also 'nohost' clause?) > (which are not yet implemented, so not relevant in this discussion), it is > permissible (and worthwhile for the usual reasons) to inline such functions > into one another, given proper nesting of OpenACC levels of parallelism. > The latter is enforced by construction, by detecting improper caller/callee > combinations (for example, trying to call a 'gang' routine from a 'vector' > context). > > By construction, 'IFN_UNIQUE' etc. can only appear in 'oacc function' > functions. > > There are 'oacc function' functions that do not contain 'IFN_UNIQUE' etc. > (for example, 'seq' functions, such as math library functions), but which > might still benefit from inlining. And, in particular, also the C++ 'acc_on_device' forwarding function with correctly typed argument. (See 'openacc.h'.) > I suppose it is fine to do inlining if the outer function will then be > handled by 'oaccdevlow'. > > And, I suppose it will be reasonable to forbid inlining of 'oacc function' > functions into non-'oacc function' functions ..., and this breaks said 'acc_on_device' case... :-/ This is: the '#pragma acc routine' 'inline' function 'acc_on_device' is regularely called from non-'#pragma acc routine' functions. It becomes worse if the C++ forwarding function with correctly typed argument is actually marked 'always_inline' -- as it probably should be? So, this has to be permitted. > because in that case you're > not applying any OpenACC parallelism anyway, at least for a backportable ICE > fix, then later possibly more logic added to allow that. > > That will probably be reasonably simple to implement; I'll give it some > further thought, and testing. Attaching my WIP patch for that, anyway. But, as discussed, it seems that it'll have to be a bit more elaborate: do allow such inlining after all. I'm still pondering how to best do that. (a) Clean up the unexpected stuff at the place where it currently ICEs (by refactoring stuff currently done in 'oaccdevlow'?). (b) When the problematic inlining happens, tag the inlined-into function such that 'oaccdevlow' will then clean it up in there. (c) Go as far as cloning the '#pragma acc routine' functions early, so that the "host" function doesn't get the OpenACC magic applied, but only the "OMP" one does. (If this has other benefits maybe, by not cluttering the "hose" code with OpenACC magic?) Option (b) would be something similar to what Jakub had suggested: (In reply to Jakub Jelinek from comment #3) > Or it is inlinable, but we need some cleanup, in that case perhaps have some > cfun->* flag that would be initially set to whether the function has > oacc_get_fn_attrib and would be ored into functions into which those > functions were inlined, and then the oaccdevlower pass would clean that > stuff up or whatever. I think I'll look into that option first, try to locate the places where such processing is to happen, and leave option (c) for later.
[Bug ipa/89893] Segmentation fault always occurs when node app is generated by gcc-8-branch@268745
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89893 --- Comment #26 from 康 珊 --- I found the previous build log is like "g++ -o /builddir/build/BUILD/node-v10.15.3/out/Release/cctest -pthread -rdynamic -m64 -Wl,--whole-archive,/builddir/build/BUILD/node-v10.15.3/out/Release/obj.target/deps/uv/libuv.a -Wl,--no-whole-archive -Wl,-z,noexecstack -Wl,--whole-archive /builddir/build/BUILD/node-v10.15.3/out/Release/obj.target/deps/v8/gypfiles/libv8_base.a -Wl,--no-whole-archive -Wl,-z,relro -Wl,-z,now -Wl,-T /builddir/build/BUILD/node-v10.15.3/src/large_pages/ld.implicit.script -pthread -flto=4 -fuse-linker-plugin -ffat-lto-objects -fno-lto -Wl,--start-group /builddir/build/BUILD/node-v10.15.3/out/Release/obj.target/cctest/test/cctest/node_test_fixture.o...", you mean link options like "-flto=4 -ffat-lto-objects -fno-lto" are not accurate and "-fno-lto" will not take effect, right?
[Bug web/89964] Remove the "First, you must pick a product on which to enter a bug:" page
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89964 --- Comment #4 from Jonathan Wakely --- Yes, it seems like overkill to split them. I just want submitting GCC bugs (which is more common by two orders of magnitude) to require fewer clicks.
[Bug ipa/89975] Compile-time hog w/ large values of --param uninlined-function-insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89975 Richard Biener changed: What|Removed |Added CC||hubicka at gcc dot gnu.org, ||marxin at gcc dot gnu.org Component|middle-end |ipa --- Comment #2 from Richard Biener --- I think the param merely makes inlining a call cheaper (adds to the function overhead when not inlined). So I would guess it causes more inlining. But then the testcase is small so there does seem to be a genuine bug in the inliner?
[Bug middle-end/89972] [8/9 Regression] ICE in expand_call, at calls.c:4229
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89972 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Component|c |middle-end
[Bug preprocessor/89971] [8/9 Regression] ICE: unspellable token PADDING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89971 Richard Biener changed: What|Removed |Added Keywords||diagnostic Priority|P3 |P2
[Bug tree-optimization/89963] [GRAPHITE] Compile-time hog when compiling gcc/testsuite/gcc.dg/autopar/uns-outer-6.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89963 --- Comment #2 from Richard Biener --- Actually it does - just compile-time isn't linear in the max operations :/ --param max-isl-operations compile-time 10 0.36s 11 2.62s 12 5.35s 13 15.57s 14 30.16s 20 138.96 IIRC I've "tuned" the default so we don't hit the timeout for SPEC 2006 (and that didn't cause any compile-time issues). From looking at the source the number of operations are more related to memory use (allocations trigger one "operations"), the only other "operation" is isl_tab_pivot. The time hog is finishing cut_to_integer_lexmin (which eventually calls isl_tab_pivot multiple times). It seems that when isl_tab_pivot is the driving hog the limit is too high but when it is allocation it works well enough. It looks like ISL should have two different limits, one for memory use and one for time since they are not really comparable. Also looks like (on this testcase at least) ISL-Imath is a lot slower than ISL-gmp (by nearly a factor of 10!).
[Bug ipa/89893] Segmentation fault always occurs when node app is generated by gcc-8-branch@268745
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89893 --- Comment #25 from 康 珊 --- OK. Then I will remove "enable-lto" in configure and try "-O3" with "-fno-strict-aliasing" to see whether it can solve the issue.
[Bug target/89945] [7/8/9 Regression] ICE in gen_lowpart_general, at rtlhooks.c:63
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89945 Uroš Bizjak changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com --- Comment #2 from Uroš Bizjak --- Created attachment 46093 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46093=edit Proposed patch We allow SYMBOL_REF and LABEL_REF RTXes in x86_64_zext_immediate_operand for certain code models. gen_lowpart doesn't know what to do with these references, so we have to convert them from DImode to SImode by hand.
[Bug fortran/89981] [8/9 Regression] gfortran -pedantic rejects code in 8.3.1 that is accepted with 8.3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89981 --- Comment #2 from Dominique d'Humieres --- Without -pedantic I get the following warnings sadmvnt.f:80:15: 80 | INFORM = MVNNIT( N, CORREL, LOWER, UPPER, INFIN, INFIS, D, E ) | 1 Warning: More actual than formal arguments in procedure call at (1) sadmvnt.f:1432:15: 1432 | INFORM = MVTNIT( N, NU, CORREL, LOWER, UPPER, INFIN, INFIS, D, E ) | 1 Warning: Type mismatch in argument 'w' at (1); passed INTEGER(4) to REAL(8) [-Wargument-mismatch] As documented -pedantic turns the warnings into errors. The change occurred between revisions r269635 (2019-03-13, no warning) and r269895 (2019-03-24, warnings), likely r269895 (pr78865) for trunk (9.0) and r270032 for 8.3.1. This seems related to the line 1505 ENTRY MVTNIT( N, NUIN, CORREL, LOWER, UPPER, INFIN, INFIS, D, E ) conflicting with the line 1468 DOUBLE PRECISION FUNCTION FNCMVT(N, W) Note that the line 80 seems wrong: it should be the same as line 1432.
[Bug c/89968] attribute packed fails to reduce char vector member alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89968 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-05 Ever confirmed|0 |1 --- Comment #3 from Richard Biener --- vector_size needs to honor user-alignment I guess.
[Bug target/89965] [8/9 Regression] wrong code with -O -mtune=nano-x2 -fcaller-saves -fexpensive-optimizations -fno-tree-dce -fno-tree-ter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89965 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug ipa/89893] Segmentation fault always occurs when node app is generated by gcc-8-branch@268745
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89893
--- Comment #24 from Martin Liška ---
(In reply to 康 珊 from comment #23)
> (In reply to Martin Liška from comment #22)
> > (In reply to 康 珊 from comment #21)
> > > All of the experiments were did in according to the build steps I just
> > > gave
> > > to you.
> >
> > I'm sorry, but I would like to know whether you are talking about LTO builds
> > (w/ --enable-lto in configure) or not? You tried both, so I'm curious which
> > have you used?
> It is configured with "--enable-lto" and LDFLAGS="${LDFLAGS} -fno-lto", I'm
> not sure whether lto takes effect or not. Do you need me remove "enable-lto"
> in configure and try the experiments?
Using "--enable-lto" and LDFLAGS="${LDFLAGS} -fno-lto" is wrong. It will use
LTO because one can't stop usage LTO bytecode by linker option. There's no
assembly that linked would be able to link.
[Bug tree-optimization/89963] [GRAPHITE] Compile-time hog when compiling gcc/testsuite/gcc.dg/autopar/uns-outer-6.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89963 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-05 CC||grosser at gcc dot gnu.org, ||rguenth at gcc dot gnu.org, ||spop at gcc dot gnu.org Summary|Compile-time hog when |[GRAPHITE] Compile-time hog |compiling |when compiling |gcc/testsuite/gcc.dg/autopa |gcc/testsuite/gcc.dg/autopa |r/uns-outer-6.c |r/uns-outer-6.c Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed. It looks like isl_ctx_set_max_operations doesn't properly constrain it here :/
[Bug fortran/89981] [8/9 Regression] gfortran -pedantic rejects code in 8.3.1 that is accepted with 8.3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89981 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-05 CC||marxin at gcc dot gnu.org Target Milestone|--- |8.4 Ever confirmed|0 |1 Known to fail||9.0 --- Comment #1 from Martin Liška --- Confirmed, started with r269895.
[Bug translation/89936] wrong punctuation in tree-profile.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89936 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Martin Liška --- Fixed on trunk, not planning to backport.
[Bug bootstrap/89980] [9 Regression] bootstrap failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89980
Martin Liška changed:
What|Removed |Added
Keywords||wrong-code
Priority|P3 |P1
Known to work||8.3.0
Known to fail||9.0
--- Comment #3 from Martin Liška ---
There's a reduced test-case:
$ cat test.C
static const char *const rtx_format[1] = { "" };
int main(int argc, char **argv)
{
if (rtx_format[0] == 0)
__builtin_abort ();
return 0;
}
$ g++ /tmp/test.C && ./a.out
Aborted (core dumped)
[Bug translation/89936] wrong punctuation in tree-profile.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89936 --- Comment #4 from Martin Liška --- Author: marxin Date: Fri Apr 5 09:04:41 2019 New Revision: 270164 URL: https://gcc.gnu.org/viewcvs?rev=270164=gcc=rev Log: Fix ChangeLog entries. contrib/ChangeLog: 2019-04-03 Martin Liska PR translation/89936 * check-internal-format-escaping.py: Properly detect wrong apostrophes. gcc/ChangeLog: 2019-04-03 Martin Liska PR translation/89936 * collect-utils.c (collect_execute): Use %< and %>, or %qs in order to wrap keywords or arguments. * collect2.c (main): Likewise. (scan_prog_file): Likewise. (scan_libraries): Likewise. * common/config/riscv/riscv-common.c (riscv_subset_list::parsing_subset_version): Likewise. (riscv_subset_list::parse_std_ext): Likewise. * config/aarch64/aarch64.c (aarch64_override_options_internal): Likewise. * config/arm/arm.c (arm_option_override): Likewise. * config/cris/cris.c (cris_print_operand): Likewise. * config/darwin-c.c (darwin_pragma_options): Likewise. (darwin_pragma_unused): Likewise. (darwin_pragma_ms_struct): Likewise. * config/ft32/ft32.c (ft32_print_operand): Likewise. * config/i386/i386.c (print_reg): Likewise. (ix86_print_operand): Likewise. * config/i386/xm-djgpp.h: Likewise. * config/iq2000/iq2000.c (iq2000_print_operand): Likewise. * config/m32c/m32c.c (m32c_option_override): Likewise. * config/msp430/msp430.c (msp430_option_override): Likewise. * config/nds32/nds32.c (nds32_option_override): Likewise. * config/nvptx/mkoffload.c (main): Likewise. * config/rx/rx.c (rx_print_operand): Likewise. (valid_psw_flag): Likewise. * config/vms/vms-c.c (vms_pragma_member_alignment): Likewise. (vms_pragma_nomember_alignment): Likewise. (vms_pragma_extern_model): Likewise. * lto-wrapper.c (compile_offload_image): Likewise. * omp-offload.c (oacc_parse_default_dims): Likewise. * symtab.c (symtab_node::verify_base): Likewise. * tlink.c (recompile_files): Likewise. (start_tweaking): Likewise. * tree-profile.c (parse_profile_filter): Likewise. gcc/objc/ChangeLog: 2019-04-03 Martin Liska PR translation/89936 * objc-act.c (objc_add_property_declaration): Use %< and %>, or %qs in order to wrap keywords or arguments. (objc_add_synthesize_declaration_for_property): Likewise. Modified: trunk/contrib/ChangeLog trunk/gcc/ChangeLog trunk/gcc/objc/ChangeLog
[Bug target/89935] [Arm] Return from interrupt on Cortex-R52 must use eret instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89935 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- (In reply to Martin Liška from comment #1) > Author: marxin > Date: Fri Apr 5 08:37:44 2019 > New Revision: 270163 > > URL: https://gcc.gnu.org/viewcvs?rev=270163=gcc=rev > Log: > Remove usage of apostrophes in error and warning messages (PR > translation/89935). > > 2019-04-05 Martin Liska > > PR translation/89935 > * check-internal-format-escaping.py: Properly detect wrong > apostrophes. > 2019-04-05 Martin Liska > > PR translation/89935 > * collect-utils.c (collect_execute): Use %< and %>, or %qs in > order to wrap keywords or arguments. > * collect2.c (main): Likewise. > (scan_prog_file): Likewise. > (scan_libraries): Likewise. > * common/config/riscv/riscv-common.c > (riscv_subset_list::parsing_subset_version): Likewise. > (riscv_subset_list::parse_std_ext): Likewise. > * config/aarch64/aarch64.c (aarch64_override_options_internal): > Likewise. > * config/arm/arm.c (arm_option_override): Likewise. > * config/cris/cris.c (cris_print_operand): Likewise. > * config/darwin-c.c (darwin_pragma_options): Likewise. > (darwin_pragma_unused): Likewise. > (darwin_pragma_ms_struct): Likewise. > * config/ft32/ft32.c (ft32_print_operand): Likewise. > * config/i386/i386.c (print_reg): Likewise. > (ix86_print_operand): Likewise. > * config/i386/xm-djgpp.h: Likewise. > * config/iq2000/iq2000.c (iq2000_print_operand): Likewise. > * config/m32c/m32c.c (m32c_option_override): Likewise. > * config/msp430/msp430.c (msp430_option_override): Likewise. > * config/nds32/nds32.c (nds32_option_override): Likewise. > * config/nvptx/mkoffload.c (main): Likewise. > * config/rx/rx.c (rx_print_operand): Likewise. > (valid_psw_flag): Likewise. > * config/vms/vms-c.c (vms_pragma_member_alignment): Likewise. > (vms_pragma_nomember_alignment): Likewise. > (vms_pragma_extern_model): Likewise. > * lto-wrapper.c (compile_offload_image): Likewise. > * omp-offload.c (oacc_parse_default_dims): Likewise. > * symtab.c (symtab_node::verify_base): Likewise. > * tlink.c (recompile_files): Likewise. > (start_tweaking): Likewise. > * tree-profile.c (parse_profile_filter): Likewise. > 2019-04-05 Martin Liska > > PR translation/89935 > * objc-act.c (objc_add_property_declaration): Use %< and %>, or %qs in > order to wrap keywords or arguments. > (objc_add_synthesize_declaration_for_property): Likewise. > > Modified: > trunk/contrib/ChangeLog > trunk/contrib/check-internal-format-escaping.py > trunk/gcc/ChangeLog > trunk/gcc/collect-utils.c > trunk/gcc/collect2.c > trunk/gcc/common/config/riscv/riscv-common.c > trunk/gcc/config/aarch64/aarch64.c > trunk/gcc/config/arm/arm.c > trunk/gcc/config/cris/cris.c > trunk/gcc/config/darwin-c.c > trunk/gcc/config/ft32/ft32.c > trunk/gcc/config/i386/i386.c > trunk/gcc/config/i386/xm-djgpp.h > trunk/gcc/config/iq2000/iq2000.c > trunk/gcc/config/m32c/m32c.c > trunk/gcc/config/msp430/msp430.c > trunk/gcc/config/nds32/nds32.c > trunk/gcc/config/nvptx/mkoffload.c > trunk/gcc/config/rx/rx.c > trunk/gcc/config/vms/vms-c.c > trunk/gcc/lto-wrapper.c > trunk/gcc/objc/ChangeLog > trunk/gcc/objc/objc-act.c > trunk/gcc/omp-offload.c > trunk/gcc/symtab.c > trunk/gcc/tlink.c > trunk/gcc/tree-profile.c Sorry for wrong commit entry, itb elongs to PR89935.
[Bug c++/89962] likely/unlikely attributes don't work on a compound-statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89962 Richard Biener changed: What|Removed |Added Keywords|wrong-code |diagnostic, ||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-05 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed. Wouldn't call it wrong-code though ;)
[Bug c/89950] attribute aligned ignored with attribute vector_size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89950 Richard Biener changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-05 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Does it depend on the order of the aligned/vector_size attributes? I would guess aligned after vector_size "works"?
[Bug c/89946] [8/9 Regression] ICE in assemble_start_function, at varasm.c:1871
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89946 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |8.4
[Bug rtl-optimization/89944] [7/8/9 Regression] ICE in mark_jump_label_1, at jump.c:1152
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89944 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-05 Component|middle-end |rtl-optimization Known to work||4.3.6 Target Milestone|--- |7.5 Ever confirmed|0 |1 Known to fail||4.8.5, 7.4.0, 8.3.0 --- Comment #1 from Richard Biener --- Confirmed.
