[Bug middle-end/78540] [6 Regression] ICE: in df_refs_verify, at df-scan.c:4062 with -O -march=core2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78540 --- Comment #9 from Jakub Jelinek --- Created attachment 40342 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40342&action=edit gcc6-pr78540-test.patch Oops, forgot in 6.x and earlier -Wno-psabi doesn't work for ppc*. Does this fix the issue? If so, I'll commit it soon (to 6.x only, trunk doesn't need it).
[Bug bootstrap/78817] stage2 bootstrap failure in vec.h:1613:5: error: argument 1 null where non-null expected after r243661
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78817 --- Comment #3 from Segher Boessenkool --- It is a warning (as well as a bootstrap comparison error) on powerpc64-linux. You tested on powerpc64le-linux, different animal.
[Bug bootstrap/78817] stage2 bootstrap failure in vec.h:1613:5: error: argument 1 null where non-null expected after r243661
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78817 Andreas Schwab changed: What|Removed |Added Host|powerpc64le-*-linux | --- Comment #4 from Andreas Schwab --- Also broken on aarch64.
[Bug go/78763] go1: internal compiler error: in do_get_backend, at go/gofrontend/expressions.cc:8352
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78763 Martin Liška changed: What|Removed |Added Status|WAITING |NEW Known to fail||6.2.0, 7.0 --- Comment #7 from Martin Liška --- I can confirm that it also happens with GCC 6.2 and trunk (I don't have any other version of go), with following back-trace: go1: internal compiler error: in do_get_backend, at go/gofrontend/expressions.cc:9029 0x6b8c30 Builtin_call_expression::do_get_backend(Translate_context*) ../../gcc/go/gofrontend/expressions.cc:9029 0x6b18f5 Expression::comparison(Translate_context*, Type*, Operator, Expression*, Expression*, Location) ../../gcc/go/gofrontend/expressions.cc:6389 0x6b2040 Binary_expression::do_get_backend(Translate_context*) ../../gcc/go/gofrontend/expressions.cc:5863 0x71b551 If_statement::do_get_backend(Translate_context*) ../../gcc/go/gofrontend/statements.cc:3155 0x6ec168 Block::get_backend(Translate_context*) ../../gcc/go/gofrontend/gogo.cc:5984 0x71b4dc Block_statement::do_get_backend(Translate_context*) ../../gcc/go/gofrontend/statements.cc:1831 0x6ec168 Block::get_backend(Translate_context*) ../../gcc/go/gofrontend/gogo.cc:5984 0x71b4dc Block_statement::do_get_backend(Translate_context*) ../../gcc/go/gofrontend/statements.cc:1831 0x6ec168 Block::get_backend(Translate_context*) ../../gcc/go/gofrontend/gogo.cc:5984 0x71b4dc Block_statement::do_get_backend(Translate_context*) ../../gcc/go/gofrontend/statements.cc:1831 0x6ec168 Block::get_backend(Translate_context*) ../../gcc/go/gofrontend/gogo.cc:5984 0x71b4dc Block_statement::do_get_backend(Translate_context*) ../../gcc/go/gofrontend/statements.cc:1831 0x6ec168 Block::get_backend(Translate_context*) ../../gcc/go/gofrontend/gogo.cc:5984 0x6ecb45 Function::build(Gogo*, Named_object*) ../../gcc/go/gofrontend/gogo.cc:5589 0x6ed1bf Named_object::get_backend(Gogo*, std::vector >&, std::vector >&, std::vector >&) ../../gcc/go/gofrontend/gogo.cc:7335 0x6f505a Gogo::write_globals() ../../gcc/go/gofrontend/gogo.cc:1307 However I can't reduce a test-case.
[Bug rtl-optimization/78812] Wrong code generation due to hoisting memory load across function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78812 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Doesn't seem to be a recent regression, at least already r187763 is doing that.
[Bug fortran/78798] [cleanup] some int-valued functions should be bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78798 janus at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #3 from janus at gcc dot gnu.org --- There are actually several more functions that should be bool in interface.c (compare_parameter & friends) ...
[Bug bootstrap/78817] stage2 bootstrap failure in vec.h:1613:5: error: argument 1 null where non-null expected after r243661
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78817 --- Comment #5 from Andreas Schwab --- Also broken on ia64.
[Bug middle-end/22141] [5/6/7 Regression] Missing optimization when storing structures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22141
--- Comment #40 from etienne_lorrain at yahoo dot fr ---
Following my comment No 17, the optimisation could also be done for reads - we
still have (https://gcc.godbolt.org/ -O2 -m32) that:
struct S
{
char a;
char b;
char c;
char d;
} u, v;
void fct (void) {
u.a = v.a;
u.b = v.b;
u.c = v.c;
u.d = v.d;
}
compiled into:
fct():
movzbl v, %eax
movb%al, u
movzbl v+1, %eax
movb%al, u+1
movzbl v+2, %eax
movb%al, u+2
movzbl v+3, %eax
movb%al, u+3
ret
Same if fct() contains "u = (struct S) {v.a, v.b, v.c, v.d};"
Where a single read32 / write32 could be used...
Having fct() only do "u = v;" is compiled with a single read32 / write32.
I do not know if it is important enough, if it needs another bugzilla number...
Thanks.
[Bug bootstrap/78817] stage2 bootstrap failure in vec.h:1613:5: error: argument 1 null where non-null expected after r243661
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78817 Markus Trippelsdorf changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #6 from Markus Trippelsdorf --- There are also many new (bogus?) warnings during PGO/-O3 bootstrap.
[Bug middle-end/22141] [5/6/7 Regression] Missing optimization when storing structures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22141
--- Comment #41 from ktkachov at gcc dot gnu.org ---
(In reply to etienne_lorrain from comment #40)
> Following my comment No 17, the optimisation could also be done for reads -
> we still have (https://gcc.godbolt.org/ -O2 -m32) that:
> struct S
> {
> char a;
> char b;
> char c;
> char d;
> } u, v;
>
> void fct (void) {
> u.a = v.a;
> u.b = v.b;
> u.c = v.c;
> u.d = v.d;
> }
>
> compiled into:
> fct():
> movzbl v, %eax
> movb%al, u
> movzbl v+1, %eax
> movb%al, u+1
> movzbl v+2, %eax
> movb%al, u+2
> movzbl v+3, %eax
> movb%al, u+3
> ret
>
> Same if fct() contains "u = (struct S) {v.a, v.b, v.c, v.d};"
> Where a single read32 / write32 could be used...
>
> Having fct() only do "u = v;" is compiled with a single read32 / write32.
> I do not know if it is important enough, if it needs another bugzilla
> number...
> Thanks.
Yeah, I separate bugzilla entry would be good here
[Bug debug/59161] GDB pretty printers: iterator->reference not printed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59161
--- Comment #6 from Jonathan Wakely ---
That seems quite arbitrary and inconsistent. In other contexts if I return a
gdb.Value it gets stringified as expected, e.g the
StdListPrinter._iterator.__next__ method does:
return ('[%d]' % count, val)
where val is a gdb.Value, but gdb automatically converts that to a string via
something like: "%s = %s" % ('[%d]' % count, val) and so the gdb.Value is
converted properly.
But when a gdb.Value is returned directly the simplified form is used.
Returning gdb.Value directly is a documented part of the API:
https://sourceware.org/gdb/onlinedocs/gdb/Pretty-Printing-API.html
> Otherwise, if this method returns an instance of gdb.Value, then gdb prints
> this value.
And I can't see what possible use it is to print { ref = } for this object,
ever.
Paul's change is intended to suppress the address in his example at
https://sourceware.org/ml/gdb/2009-11/msg00105.html but by the reasoning above
he should have made his pretty-printer do:
return str(self.val['whybother']['contents'])
Also, in his case he was getting the address *and* the string contents, but in
this reference example we *only* print the address, not the value. Suppressing
the address in that case seems undesirable.
[Bug tree-optimization/78819] New: [7 Regression] Wrong code with VRP caused by register assertions along default switch labels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78819
Bug ID: 78819
Summary: [7 Regression] Wrong code with VRP caused by register
assertions along default switch labels
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: ppalka at gcc dot gnu.org
Target Milestone: ---
Started with r238761, following test-case behaves wrongly:
$ cat /tmp/testcase.c
#include
#include
int main(unsigned argc, char **argv)
{
if (argc <= 0)
return 0;
if (argc > 3)
return 0;
switch (argc)
{
case 1:
case 3:
fprintf (stderr, "value: %d\n", argc);
break;
case 2:
fprintf (stderr, "value: %d\n", argc);
break;
default:
abort();
}
return 1;
}
$ ./xgcc -B. /tmp/testcase.c -O0 -fdump-tree-optimized && ./a.out 1 1
value: 3
$ ./xgcc -B. /tmp/testcase.c -O2 -fdump-tree-optimized && ./a.out 1 1
value: 1
This miscompilation is detected by Python-2.7.12 package, that fails in
test_epoll test-case.
Thanks,
Martin
[Bug debug/59161] GDB pretty printers: iterator->reference not printed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59161
--- Comment #7 from Jonathan Wakely ---
This behaviour effectively means pretty printers for generic C++ types must
never return gdb.Value from to_string() because they have no idea if GDB's
default stringification will be sane. An optional can't just return the T,
and Wrapper can't just return the X.
If the only case that's a problem is for reference members, then it seems
sensible to ignore the options.addressprint setting for references. Printing
{ref = } instead of {ref = @0x7fffd73c} seems like it's never useful.
[Bug tree-optimization/78819] [7 Regression] Wrong code with VRP caused by register assertions along default switch labels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78819 Martin Liška changed: What|Removed |Added Target Milestone|--- |7.0
[Bug tree-optimization/78819] [7 Regression] Wrong code with VRP caused by register assertions along default switch labels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78819 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-12-15 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug tree-optimization/78819] [7 Regression] Wrong code with VRP caused by register assertions along default switch labels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78819 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- Let me have a look.
[Bug c/78821] New: GCC7: Copying whole 32 bits structure field by field not optimised into copying whole 32 bits at once
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78821
Bug ID: 78821
Summary: GCC7: Copying whole 32 bits structure field by field
not optimised into copying whole 32 bits at once
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: etienne_lorrain at yahoo dot fr
Target Milestone: ---
Compiling (ia32, -O2) a function to copy whole structure is optimised on GCC7
pre-release (g++ (GCC-Explorer-Build) 7.0.0 20161113 (experimental)):
struct S
{
char a, b, c, d;
} u, v;
void fct (void) {
u = v;
}
leads to:
fct():
movlv, %eax
movl%eax, u
ret
But other ways to copy the structure are not optimised, both:
void fct (void) {
u = (struct S){v.a, v.b, v.c, v.d};
}
and:
void fct (void) {
u.a = v.a;
u.b = v.b;
u.c = v.c;
u.d = v.d;
}
leads to:
movzbl v, %eax
movb%al, u
movzbl v+1, %eax
movb%al, u+1
movzbl v+2, %eax
movb%al, u+2
movzbl v+3, %eax
movb%al, u+3
[Bug middle-end/22141] [5/6/7 Regression] Missing optimization when storing structures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22141 --- Comment #42 from etienne_lorrain at yahoo dot fr --- Separate Bug 78821 has been successfully created following comment 41
[Bug tree-optimization/24177] function returning structure produce very long/slow assembly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24177 etienne_lorrain at yahoo dot fr changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from etienne_lorrain at yahoo dot fr --- Closing, code generated by g++ (GCC-Explorer-Build) 7.0.0 20161113 (experimental) from the source is now: fct2(): subl$40, %esp leal12(%esp), %eax movl$1, 12(%esp) movl$2, 16(%esp) movl$3, 20(%esp) movl$4, 24(%esp) pushl %eax callfct3(str*) addl$44, %esp ret
[Bug tree-optimization/14295] [tree-ssa] copy propagation for aggregates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14295 Bug 14295 depends on bug 24177, which changed state. Bug 24177 Summary: function returning structure produce very long/slow assembly https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24177 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug debug/59161] GDB pretty printers: iterator->reference not printed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59161
--- Comment #8 from Pedro Alves ---
Sounds like Paul's original patch may have introduced an undesired conflation.
AFAICS, options.addressprint's exists to implement "set print address on/off",
which had for original motivation, from the manual:
You can use @samp{set print address off} to eliminate all machine
dependent displays from the @value{GDBN} interface. For example, with
@code{print address off}, you should get the same text for backtraces on
all machines---whether or not they involve pointer arguments.
[1] https://sourceware.org/gdb/current/onlinedocs/gdb/Print-Settings.html
With that in mind, skipping the address on references seems to make as much
sense as skipping it on pointers.
Let's also take a look at what happens if you bypass the printer, with /r:
(gdb) set print address on
(gdb) p /r it
$2 = {_M_current = 0x614c20}
(gdb) p /r it._M_current
$3 = (C *) 0x614c20
(gdb) p /r *it._M_current
$4 = {ref = @0x7fffd908}
(gdb) p /r it._M_current.ref
$5 = (int &) @0x7fffd908: 1
(gdb) set print address off
(gdb) p /r it
$6 = {_M_current = }
(gdb) p /r it._M_current
$7 = (C *)
(gdb) p /r *it._M_current
$8 = {ref = }
(gdb) p /r it._M_current.ref
$9 = (int &) 1
Particularly, note how:
(gdb) p /r *it._M_current
$4 = {ref = @0x7fffd908}
doesn't print the value of the reference field, while if you print it directly,
it's printed:
(gdb) p /r it._M_current.ref
$5 = (int &) @0x7fffd908: 1
I wonder whether we should change gdb to print it, like:
(gdb) p /r *it._M_current
$1 = {ref = (int &) @0x7fffd908: 1}
and then with "print address off", you'd get:
(gdb) p /r *it._M_current
$1 = {ref = (int &) 1}
But that question should be answered independently from the pretty printer
question. I.e., what do people that debug C++ programs would find the most
useful default behavior to be, without pretty printers in the picture. (Not
enough C++ references in GDB's own codebase yet for me to have a clear opinion
yet. :-) )
[Bug rtl-optimization/78812] [5/6/7 Regression] Wrong code generation due to hoisting memory load across function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78812
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2016-12-15
Target Milestone|--- |5.5
Summary|Wrong code generation due |[5/6/7 Regression] Wrong
|to hoisting memory load |code generation due to
|across function call|hoisting memory load across
||function call
Ever confirmed|0 |1
--- Comment #2 from Jakub Jelinek ---
But in the end it actually is a regression that started r166555 (previously it
has been latent).
Slightly adjusted testcase:
struct T
{
bool a;
T () : a (false) {}
~T () { if (!a) __builtin_abort (); }
};
__attribute__((noinline))
void
test (T &x)
{
x.a = true;
}
int
main ()
{
T T;
test (T);
}
[Bug debug/59161] GDB pretty printers: iterator->reference not printed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59161
--- Comment #9 from Pedro Alves ---
> Sounds like Paul's original patch may have introduced an undesired
> conflation. AFAICS, options.addressprint's exists to implement "set print
> address on/off", which had for original motivation, from the manual:
> Let's also take a look at what happens if you bypass the printer, with /r:
> (gdb) set print address off
> (gdb) p /r it
> $6 = {_M_current = }
> (gdb) p /r it._M_current
> $7 = (C *)
> (gdb) p /r *it._M_current
> $8 = {ref = }
> (gdb) p /r it._M_current.ref
> $9 = (int &) 1
BTW, from the above, we can tell that the original problem with the printer is
not restricted to references (as per the subject). Note above we skipped
printing the addresses of pointers, as expected due to "set print address off".
So if we tweak the original test to make "ref" a pointer instead:
#include
class C {
public:
int *ref;
C(int *ref_):ref(ref_) {}
};
int main() {
int *d(nullptr);
std::vector vec({d});
for (auto it=vec.begin();it!=vec.end();++it) {
it->ref; // line 11
__attribute__((unused)) C *gdb_stub(&*it);
}
}
we get the same odd result:
(gdb) p it
$1 = {ref = }
[Bug middle-end/39456] Functions/variables of a file in different named sections
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39456
etienne_lorrain at yahoo dot fr changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #5 from etienne_lorrain at yahoo dot fr ---
Fixed (string concat into __attribute__((section("pre" "fix"))) ) on g++
(GCC-Explorer-Build) 7.0.0 20161113 (experimental), result of:
void fct2 (void) __attribute__((__section__("sect1_" "fct2")));
void fct2 (void) { return; }
is:
.sectionsect1_fct2,"ax",@progbits
.p2align 4,,15
.globl fct2()
.type fct2(), @function
fct2():
.LFB0:
.file 1 "/tmp/gcc-explorer-compiler1161115-73-1xzfvi6/example.cpp"
.loc 1 2 0
.cfi_startproc
.loc 1 2 0
rep ret
[Bug middle-end/77484] [6/7 Regression] Static branch predictor causes ~6-8% regression of SPEC2000 GAP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484 --- Comment #12 from wilco at gcc dot gnu.org --- (In reply to wilco from comment #10) > (In reply to Jan Hubicka from comment #9) > > Created attachment 40217 [details] > > predict > > > > Hi, > > here is patch adding the polymorphic case, too. > > > > Honza > > Looks good - gap still improves by 12%, SPECINT2k by 0.5%, SPECFP2k flat. So > that fixes this issue. I also ran SPEC2006 which didn't show any differences.(In reply to Martin Liška from comment #11) > I'm planning to run SPEC benchmarks late this week to find a proper value > for the new predictor. Any news on that? I ran SPEC2006 as well with the suggested values, and this didn't show any differences.
[Bug middle-end/48888] Creating a copy variable simplify assembly - i686-pc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4 etienne_lorrain at yahoo dot fr changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from etienne_lorrain at yahoo dot fr --- Problem no more visible in g++ (GCC-Explorer-Build) 7.0.0 20161113 (experimental), indirect function call not un-necessarily copied to %edx before calling *edx, closing.
[Bug bootstrap/78817] stage2 bootstrap failure in vec.h:1613:5: error: argument 1 null where non-null expected after r243661
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78817 Franz Sirl changed: What|Removed |Added CC||sirl at gcc dot gnu.org --- Comment #7 from Franz Sirl --- And on x86_64 a profiledbootstrap with --enable-checking=yes fails like this: ../../gcc/gengtype.c: In function 'const char* get_file_srcdir_relative_path(const input_file*)': ../../gcc/gengtype.c:1760:14: error: argument 1 null where non-null expected [-Werror=nonnull] if (strlen (f) > srcdir_len ~~~^~~ In file included from /home/fsirl/rpmbuild/BUILD/gcc-7.0.0-r243686/obj-x86_64-suse-linux/prev-x86_64-suse-linux/libstdc++-v3/include/cstring:42:0, from ../../gcc/system.h:235, from ../../gcc/gengtype.c:26: /usr/include/string.h:394:15: note: in a call to function 'size_t strlen(const char*)' declared here extern size_t strlen (const char *__s) ^~ ../../gcc/gengtype.c:1762:18: error: argument 1 null where non-null expected [-Werror=nonnull] && strncmp (f, srcdir, srcdir_len) == 0) ^~~ In file included from /home/fsirl/rpmbuild/BUILD/gcc-7.0.0-r243686/obj-x86_64-suse-linux/prev-x86_64-suse-linux/libstdc++-v3/include/cstring:42:0, from ../../gcc/system.h:235, from ../../gcc/gengtype.c:26: /usr/include/string.h:143:12: note: in a call to function 'int strncmp(const char*, const char*, size_t)' declared here extern int strncmp (const char *__s1, const char *__s2, size_t __n) ^~~ cc1plus: all warnings being treated as errors Makefile:2596: recipe for target 'build/gengtype.o' failed make[3]: *** [build/gengtype.o] Error 1 make[3]: *** Waiting for unfinished jobs rm fsf-funding.pod gcov.pod cpp.pod gfdl.pod gpl.pod gccgo.pod gfortran.pod gcc.pod gcov-tool.pod make[3]: Leaving directory '/home/fsirl/rpmbuild/BUILD/gcc-7.0.0-r243686/obj-x86_64-suse-linux/gcc' Makefile:4728: recipe for target 'all-stagefeedback-gcc' failed make[2]: *** [all-stagefeedback-gcc] Error 2 make[2]: Leaving directory '/home/fsirl/rpmbuild/BUILD/gcc-7.0.0-r243686/obj-x86_64-suse-linux' Makefile:24232: recipe for target 'stagefeedback-bubble' failed make[1]: *** [stagefeedback-bubble] Error 2 make[1]: Leaving directory '/home/fsirl/rpmbuild/BUILD/gcc-7.0.0-r243686/obj-x86_64-suse-linux' Makefile:24251: recipe for target 'profiledbootstrap' failed make: *** [profiledbootstrap] Error 2
[Bug fortran/78800] [OOP] ICE in compare_parameter, at fortran/interface.c:2246
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78800 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |janus at gcc dot gnu.org
[Bug fortran/78797] It is time perhaps to implement -std=f2015
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78797 --- Comment #6 from janus at gcc dot gnu.org --- (In reply to paul.richard.tho...@gmail.com from comment #5) > I do apologise, it seems that Mr Reid did not do his usual update. We > will have to work from the draft standard itself. Ok. Btw, the draft version of the F15 standard linked from the gfortran wiki is: http://j3-fortran.org/doc/year/15/15-007.pdf (from December 2014). Is this the last version, or this there a more recent one?
[Bug fortran/78797] It is time perhaps to implement -std=f2015
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78797 --- Comment #7 from janus at gcc dot gnu.org --- (In reply to janus from comment #6) > Ok. Btw, the draft version of the F15 standard linked from the gfortran wiki > is: > > http://j3-fortran.org/doc/year/15/15-007.pdf > > (from December 2014). Is this the last version, or this there a more recent > one? Answering that myself, I just found: http://j3-fortran.org/doc/year/16/16-007r1.pdf
[Bug debug/59161] GDB pretty printers: iterator->reference not printed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59161 --- Comment #10 from Jonathan Wakely --- Author: redi Date: Thu Dec 15 13:25:22 2016 New Revision: 243690 URL: https://gcc.gnu.org/viewcvs?rev=243690&root=gcc&view=rev Log: PR59161 make pretty printers always return strings PR libstdc++/59161 * python/libstdcxx/v6/printers.py (StdListIteratorPrinter.to_string) (StdSlistIteratorPrinter.to_string, StdVectorIteratorPrinter.to_string) (StdRbtreeIteratorPrinter.to_string, StdDequeIteratorPrinter.to_string) (StdDebugIteratorPrinter.to_string): Return string instead of gdb.Value. * testsuite/libstdc++-prettyprinters/59161.cc: New test. Added: trunk/libstdc++-v3/testsuite/libstdc++-prettyprinters/59161.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/python/libstdcxx/v6/printers.py
[Bug debug/59161] GDB pretty printers: iterator->reference not printed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59161
--- Comment #11 from Jonathan Wakely ---
I've forced the relevant printers to convert to a string explicitly, so now you
always get the address, which seems better than {ref = }
So I think the libstdc++ part is fixed, do we want a GDB bug to consider
changing how reference members are displayed? (I think printing the value as
well as the address makes sense).
[Bug libstdc++/59161] GDB pretty printers: iterator->reference not printed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59161 --- Comment #12 from Pedro Alves --- > So I think the libstdc++ part is fixed, Thanks. TBC, given the pointer example in comment #9, I think GDB's implicit use of options.addressprint=off for pretty printers is a clear GDB bug. I think GDB should change here, somehow. > do we want a GDB bug to consider > changing how reference members are displayed? (I think printing the value as > well as the address makes sense). Given we don't auto-deref pointers in structs either, I'm a bit undecided. But filing a bug might be good, to see if others have opinions. I'll take care of it.
[Bug fortran/78800] [OOP] ICE in compare_parameter, at fortran/interface.c:2246
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78800 janus at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |7.0 --- Comment #2 from janus at gcc dot gnu.org --- Fixed with r243691. Closing.
[Bug fortran/78800] [OOP] ICE in compare_parameter, at fortran/interface.c:2246
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78800 --- Comment #1 from janus at gcc dot gnu.org --- Author: janus Date: Thu Dec 15 14:07:51 2016 New Revision: 243691 URL: https://gcc.gnu.org/viewcvs?rev=243691&root=gcc&view=rev Log: 2016-12-15 Janus Weil PR fortran/78800 * interface.c (compare_allocatable): Avoid additional errors on bad class declarations. (compare_parameter): Put the result of gfc_expr_attr into a variable, in order to avoid calling it multiple times. Exit early on bad class declarations to avoid ICE. 2016-12-15 Janus Weil PR fortran/78800 * gfortran.dg/unlimited_polymorphic_27.f90: New test case. Added: trunk/gcc/testsuite/gfortran.dg/unlimited_polymorphic_27.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/interface.c trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/59170] pretty printers: end iterator invalid pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59170 --- Comment #16 from Jonathan Wakely --- Author: redi Date: Thu Dec 15 14:13:36 2016 New Revision: 243692 URL: https://gcc.gnu.org/viewcvs?rev=243692&root=gcc&view=rev Log: PR59170 make pretty printers check for singular iterators PR libstdc++/59170 * python/libstdcxx/v6/printers.py (StdListIteratorPrinter.to_string) (StdSlistIteratorPrinter.to_string, StdVectorIteratorPrinter.to_string) (StdRbtreeIteratorPrinter.to_string) (StdDequeIteratorPrinter.to_string): Add check for value-initialized iterators. * testsuite/libstdc++-prettyprinters/simple.cc: Test them. * testsuite/libstdc++-prettyprinters/simple11.cc: Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/python/libstdcxx/v6/printers.py trunk/libstdc++-v3/testsuite/libstdc++-prettyprinters/simple.cc trunk/libstdc++-v3/testsuite/libstdc++-prettyprinters/simple11.cc
[Bug fortran/78800] [OOP] ICE in compare_parameter, at fortran/interface.c:2246
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78800 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from janus at gcc dot gnu.org --- Closing for real.
[Bug target/59874] Missing builtin (__builtin_clzs) when compiling with g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59874 --- Comment #15 from Allan Jensen --- Yes, the patch works and it also evaluates at compile time.
[Bug libstdc++/59170] pretty printers: end iterator invalid pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59170 --- Comment #17 from Jonathan Wakely --- I've added some more checks for non-debug iterators. The only thing remaining is to add checks for debug iterators to detect when they are past-the-end.
[Bug bootstrap/78817] stage2 bootstrap failure in vec.h:1613:5: error: argument 1 null where non-null expected after r243661
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78817
--- Comment #8 from Markus Trippelsdorf ---
trippels@gcc2-power8 linux % cat sm_ftl.i
int sm_read_sector_zone;
int *sm_read_sector_buffer = &sm_read_sector_zone;
int sm_read_sector() {
__builtin_memset(sm_read_sector_buffer, 0, 1);
again:
if (sm_read_sector_zone)
if (!sm_read_sector_buffer)
return 0;
goto again;
}
void sm_init_zone() {
sm_read_sector();
sm_read_sector();
}
trippels@gcc2-power8 linux % gcc -c -Wall -O2 sm_ftl.i
trippels@gcc2-power8 linux % gcc -c -Wall -O3 sm_ftl.i
sm_ftl.i: In function ‘sm_init_zone’:
sm_ftl.i:4:3: warning: argument 1 null where non-null expected [-Wnonnull]
__builtin_memset(sm_read_sector_buffer, 0, 1);
^
sm_ftl.i:4:3: note: in a call to built-in function ‘__builtin_memset’
[Bug bootstrap/78817] stage2 bootstrap failure in vec.h:1613:5: error: argument 1 null where non-null expected after r243661
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78817 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #9 from Jakub Jelinek --- I think that proves the warning is done in a bad place, a warning with so many false positives is something that will push users away from gcc (or in the better case they'll just disable it). I think much better would be to warn soon after IPA, say after ccp2 pass, where we have already propagated constants after inlining, but where optimizations like jump threading have not been performed yet. Or move the warning out of -Wall, ideally out of -Wextra too. Or have 2 levels, one where it warns after ccp2 (and which is enabled in -Wall or -Wextra), and another one where it instead warns late, but has known high false positive rate.
[Bug bootstrap/78817] stage2 bootstrap failure in vec.h:1613:5: error: argument 1 null where non-null expected after r243661
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78817
--- Comment #10 from Jakub Jelinek ---
Note, users that want this to be diagnosed reliably already can use
-fsanitize={returns-,}nonnull-attribute
So I think it is better to warn only about the obvious cases with very low
false positive rate, and leave the rest to the runtime. Because there is
really nothing wrong on the testcases from profiledbootstrap (which is meant to
be supported without --disable-werror), and more importantly it is hard to
figure out what actually might be wrong and how to work around the false
positives.
The
PR bootstrap/78817
* vec.h (vec::quick_grow_cleared): Assert
postcondition.
( vec::safe_grow_cleared): Ditto.
patch looks like alchemy, slows things actually down (and will not help with
--disable-checking anyway).
[Bug target/77834] [7 Regression] ICE: in make_decl_rtl, at varasm.c:1311 with -O -ftree-pre -mstringop-strategy=libcall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77834 --- Comment #14 from Jakub Jelinek --- Author: jakub Date: Thu Dec 15 15:11:05 2016 New Revision: 243693 URL: https://gcc.gnu.org/viewcvs?rev=243693&root=gcc&view=rev Log: PR middle-end/78540 * gcc.dg/pr78540.c: Add -w to dg-options. PR target/77834 * gcc.dg/pr77834.c: Add -w to dg-options. Modified: branches/gcc-6-branch/gcc/testsuite/ChangeLog branches/gcc-6-branch/gcc/testsuite/gcc.dg/pr77834.c branches/gcc-6-branch/gcc/testsuite/gcc.dg/pr78540.c
[Bug middle-end/78540] [6 Regression] ICE: in df_refs_verify, at df-scan.c:4062 with -O -march=core2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78540 --- Comment #10 from Jakub Jelinek --- Author: jakub Date: Thu Dec 15 15:11:05 2016 New Revision: 243693 URL: https://gcc.gnu.org/viewcvs?rev=243693&root=gcc&view=rev Log: PR middle-end/78540 * gcc.dg/pr78540.c: Add -w to dg-options. PR target/77834 * gcc.dg/pr77834.c: Add -w to dg-options. Modified: branches/gcc-6-branch/gcc/testsuite/ChangeLog branches/gcc-6-branch/gcc/testsuite/gcc.dg/pr77834.c branches/gcc-6-branch/gcc/testsuite/gcc.dg/pr78540.c
[Bug target/71321] [6/7 Regression] x86: worse code for uint8_t % 10 and / 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71321 Bernd Schmidt changed: What|Removed |Added CC||bernds at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |bernds at gcc dot gnu.org --- Comment #4 from Bernd Schmidt --- I have some ideas. Investigating...
[Bug bootstrap/78817] stage2 bootstrap failure in vec.h:1613:5: error: argument 1 null where non-null expected after r243661
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78817
--- Comment #11 from Jakub Jelinek ---
Looking at the gengtype.c case, I think it is quite common case.
static inline const char*
get_input_file_name (const input_file *inpf)
{
if (inpf)
return inpf->inpname;
return NULL;
}
const char *
get_file_srcdir_relative_path (const input_file *inpf)
{
const char *f = get_input_file_name (inpf);
if (strlen (f) > srcdir_len
Of course, if somebody calls get_file_srcdir_relative_path with NULL argument,
it will mean UB in strlen, but that still does not mean that strlen is ever
called with NULL. The conditional in the first function might be just because
it is used in multiple places, in some where it allows NULL arguments, in
others where it doesn't.
Warning about if you ever hit this spot in the source, it will be always UB is
sometimes useful. But that is not the case here, the same source location is
represented by 2 or more calls and it is just one of those that the optimizers
can't prove is unreachable, but the user can know is impossible. Strlen would
segfault anyway if it was ever true.
[Bug rtl-optimization/78812] [5/6/7 Regression] Wrong code generation due to hoisting memory load across function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78812 --- Comment #3 from Jakub Jelinek --- The problem is that the hoisting code seems to assume the hoisting would be performed at the end of a bb, but that is not what insert_insn_end_basic_block will then actually do. But by the time insert_insn_end_basic_block is called, it is too late to punt or find another bb to hoist it to. compute_transp only analyzes transparency across the whole bb (to my surprise, it considers all calls as potentially clobbering MEMs, not just non-const/pure functions). So I think we want to have some predicate for what insert_insn_end_basic_block does to emit before the end of bb while searching for which bb to hoist to, and if that predicate is true, if it is a CALL (non-const/pure?) then not consider that bb for expressions containing MEMs (dunno if jumps could clobber MEMs too). Or just check for this and occrs_to_hoist.release (); if it happens in the if (hoistable > 1 && dbg_cnt (hoist_insn)) block or so?
[Bug go/78763] go1: internal compiler error: in do_get_backend, at go/gofrontend/expressions.cc:8352
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78763
--- Comment #8 from Ian Lance Taylor ---
Here is a test case that recreates the problem.
package p
import (
"unsafe"
)
func F() int {
if unsafe.Sizeof(0) == 8 {
return 8
}
return 0
}
[Bug fortran/78822] New: [cleanup] replace static char buffers by std:string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78822 Bug ID: 78822 Summary: [cleanup] replace static char buffers by std:string Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: janus at gcc dot gnu.org Target Milestone: --- Several functions in interface.c use static-size char buffers for constructing error messages, e.g.: * gfc_compare_interfaces * gfc_check_result_characteristics * gfc_check_dummy_characteristics# * ... It would be more efficient to replace those by std::string, in order to allocate the memory dynamically as needed (and only if needed at all).
[Bug preprocessor/78811] [7 Regression] raw-string-6.c testsuite failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78811 --- Comment #4 from David Malcolm --- Author: dmalcolm Date: Thu Dec 15 18:05:05 2016 New Revision: 243721 URL: https://gcc.gnu.org/viewcvs?rev=243721&root=gcc&view=rev Log: Fix use-after-free lexing unterminated raw strings (PR preprocessor/78811) gcc/ChangeLog: PR preprocessor/78680 PR preprocessor/78811 * input.c (struct selftest::lexer_test): Add field m_implicitly_expect_EOF. (selftest::lexer_error_sink): New class. (selftest::lexer_error_sink::s_singleton): New global. (selftest::lexer_test::lexer_test): Initialize new field "m_implicitly_expect_EOF". (selftest::lexer_test::~lexer_test): Conditionalize the check for the EOF token on the new field. (selftest::test_lexer_string_locations_raw_string_unterminated): New function. (selftest::input_c_tests): Call the new test. libcpp/ChangeLog: PR preprocessor/78680 PR preprocessor/78811 * lex.c (_cpp_lex_direct): Only determine the end-location of the token and build a range for non-reserved start locations. Do not do it for EOF tokens. Modified: trunk/gcc/ChangeLog trunk/gcc/input.c trunk/libcpp/ChangeLog trunk/libcpp/lex.c
[Bug preprocessor/78680] [7 Regression] ICE in get_substring_ranges_for_loc, at input.c:1398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78680 --- Comment #7 from David Malcolm --- Author: dmalcolm Date: Thu Dec 15 18:05:05 2016 New Revision: 243721 URL: https://gcc.gnu.org/viewcvs?rev=243721&root=gcc&view=rev Log: Fix use-after-free lexing unterminated raw strings (PR preprocessor/78811) gcc/ChangeLog: PR preprocessor/78680 PR preprocessor/78811 * input.c (struct selftest::lexer_test): Add field m_implicitly_expect_EOF. (selftest::lexer_error_sink): New class. (selftest::lexer_error_sink::s_singleton): New global. (selftest::lexer_test::lexer_test): Initialize new field "m_implicitly_expect_EOF". (selftest::lexer_test::~lexer_test): Conditionalize the check for the EOF token on the new field. (selftest::test_lexer_string_locations_raw_string_unterminated): New function. (selftest::input_c_tests): Call the new test. libcpp/ChangeLog: PR preprocessor/78680 PR preprocessor/78811 * lex.c (_cpp_lex_direct): Only determine the end-location of the token and build a range for non-reserved start locations. Do not do it for EOF tokens. Modified: trunk/gcc/ChangeLog trunk/gcc/input.c trunk/libcpp/ChangeLog trunk/libcpp/lex.c
[Bug preprocessor/78811] [7 Regression] raw-string-6.c testsuite failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78811 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from David Malcolm --- Sorry for the breakage; should be fixed by r243721. Marking as resolved.
[Bug middle-end/78540] [6 Regression] ICE: in df_refs_verify, at df-scan.c:4062 with -O -march=core2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78540 Bill Seurer changed: What|Removed |Added CC||seurer at linux dot vnet.ibm.com --- Comment #11 from Bill Seurer --- I just verified that with r243693 it works on power. Thanks!
[Bug tree-optimization/78819] [7 Regression] Wrong code with VRP caused by register assertions along default switch labels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78819
--- Comment #3 from Marek Polacek ---
Run-time testcase:
__attribute__((noinline, noclone)) void
foo (int argc)
{
if (argc <= 0 || argc > 3)
return;
switch (argc)
{
case 1:
case 3:
if (argc != 3)
__builtin_abort ();
break;
case 2:
asm ("");
break;
default:
__builtin_abort ();
}
}
int
main (void)
{
foo (3);
}
[Bug fortran/78718] ICE in gfc_get_symbol_decl, at fortran/trans-decl.c:1427
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78718 --- Comment #3 from Jim MacArthur --- It looks to me like the assertion failure is because the symbol in the argument expression doesn't have the attr.referenced bit set. resolve_actual_arglist replaces the symtree in the 'z' expression when it finds the 'z' in the parent namespace: e->symtree = parent_st; /* Point to the right thing. */ But this new symtree's symbol doesn't have attr.referenced set, unlike the symtree it's replacing. You can copy the old referenced bit across to make it work, but I've no idea yet what the correct solution is.
[Bug driver/78787] O Color, Where Art Thou? (with -flto)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78787 David Malcolm changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org --- Comment #3 from David Malcolm --- Created attachment 40343 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40343&action=edit Hack to debug diagnostic-color.c
[Bug driver/78787] O Color, Where Art Thou? (with -flto)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78787 --- Comment #4 from David Malcolm --- (In reply to David Malcolm from comment #3) > Created attachment 40343 [details] > Hack to debug diagnostic-color.c $ ./xgcc -B. -O2 -Wall -Wextra -flto /home/david/coding-3/gcc-git-clean/src/z.c should_colorize: true (isatty (stderr)) should_colorize: true (isatty (stderr)) /home/david/coding-3/gcc-git-clean/src/z.c: In function ‘main’: /home/david/coding-3/gcc-git-clean/src/z.c:3:27: warning: unused parameter ‘argv’ [-Wunused-parameter] int main (int argc, char *argv[]) ^~~~ should_colorize: false (!isatty (stderr)) should_colorize: false (!isatty (stderr)) should_colorize: false (!isatty (stderr)) should_colorize: false (!isatty (stderr)) /home/david/coding-3/gcc-git-clean/src/z.c: In function ‘main’: /home/david/coding-3/gcc-git-clean/src/z.c:5:3: warning: ‘__builtin_strcpy’ writing 4 bytes into a region of size 1 overflows the destination [-Wstringop-overflow=] __builtin_strcpy (d, argc < 3 ? "123" : "456789"); ^ So it appears that lto's stderr is not directly connected to a tty, and hence there's no colorization by default.
[Bug target/78658] powerpc64le: ICE with -mcpu=power9 -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78658 Michael Meissner changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Michael Meissner --- Fixed in subversion id 243320.
[Bug target/78639] [7 Regression] Power9 bad code generation for cactusADM benchmark
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78639 Michael Meissner changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Michael Meissner --- Fixed in subversion id 243206.
[Bug tree-optimization/77485] Missed dead store elimination of aggregate store followed by partial stores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77485
--- Comment #10 from Jeffrey A. Law ---
[0.00%]:
MEM[(char[170] *)& + 30B] = {};
.buf[0] = 48;
[ ... ]
[Bug target/78823] New: Poor code on PowerPC when moving SFmode values between GPRs and vector registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78823 Bug ID: 78823 Summary: Poor code on PowerPC when moving SFmode values between GPRs and vector registers Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: meissner at gcc dot gnu.org Target Milestone: --- Created attachment 40344 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40344&action=edit Sample test file. The code for moving SFmode values between GPRs and vector registers can be improved in ISA 2.07 (-mcpu=power8) and ISA 3.0 (-mcpu=power9). Right now, using a simple test case with a union, -mcpu=power8 generates a store and load to move a SFmode value from a vector register to a general purpose register. However, some code does generate the appropriate moves. Going the other way, seems to generate the appropriate instructions. Using the same simple test case on -mcpu=power9, store/load is used in both cases.
[Bug c++/77829] Bad fix-it for nested-name-specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77829 David Malcolm changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org --- Comment #1 from David Malcolm --- Has some similarities with PR c++/78656.
[Bug c++/77585] g++ incorrectly decides that member function is called without object in generic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77585 --- Comment #3 from Nathan Sidwell --- Author: nathan Date: Thu Dec 15 19:50:25 2016 New Revision: 243723 URL: https://gcc.gnu.org/viewcvs?rev=243723&root=gcc&view=rev Log: PR c++/77585 * pt.c (instantiate_decl): Push to class scope lambda resides within when instantiating a generic lambda function. PR c++/77585 * g++.dg/cpp1y/pr77585.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp1y/pr77585.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug c++/77585] g++ incorrectly decides that member function is called without object in generic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77585 Nathan Sidwell changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Nathan Sidwell --- Fixed on trunk
[Bug fortran/78662] [F03] Incorrect parsing of quotes in the char-literal-constant of the DT data descriptor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78662 --- Comment #2 from Jerry DeLisle --- Status. This is one of those where I was looking at the solution and did not see it for a while. Then it pops into view. The strings are stored with the double quotes and passed that way to the write routines. For these strings we have a special write function that removes them as the string is written. We need to do likewise as we build the iotype format string. Patch is in the works.
[Bug c++/64380] Missed optimization: smarter dead store elimination in dtors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64380
--- Comment #1 from Jeffrey A. Law ---
So the missed dead stores are due to DSE's inability to walk through the loop
in ReleaseAll. As a result stores occurring prior to that loop can't be
discovered as dead.
For reference, here's an example that's already been partially DSE'd:
;; basic block 2, loop depth 0
;;pred: ENTRY
# .MEM_3 = VDEF <.MEM_1(D)>
f_2(D)->D.2321.b0 = 192;
# .MEM_4 = VDEF <.MEM_3>
f_2(D)->m1 = 42;
# .MEM_18 = VDEF <.MEM_4>
f_2(D)->m1 = 1;
# .MEM_19 = VDEF <.MEM_18>
f_2(D)->m2 = 2;
# VUSE <.MEM_19>
n_8 = f_2(D)->nodes;
if (n_8 == 0B)
goto ; [7.50%]
else
goto ; [92.50%]
;;succ: 4
;;3
;; basic block 3, loop depth 1
;;pred: 3
;;2
# n_12 = PHI
# .MEM_21 = PHI <.MEM_20(3), .MEM_19(2)>
# VUSE <.MEM_21>
t_10 = n_12->next;
# .MEM_20 = VDEF <.MEM_21>
operator delete (n_12, 16);
if (t_10 == 0B)
goto ; [7.50%]
else
goto ; [92.50%]
;;succ: 4
;;3
;; basic block 4, loop depth 0
;;pred: 3
;;2
# .MEM_14 = PHI <.MEM_20(3), .MEM_19(2)>
# .MEM_7 = VDEF <.MEM_14>
MEM[(struct &)f_2(D)] ={v} {CLOBBER};
# .MEM_5 = VDEF <.MEM_7>
operator delete (f_2(D), 32);
# VUSE <.MEM_5>
return;
;;succ: EXIT
}
We'd like to discover the stores in bb2 as dead. Let's look at f2->m2 = 2
first. MEM_19 is used by the PHI in BB3. So we'd have to walk through the
loop following the memory objects, eventually hoping to get to BB4 where we
discover the object dies.
DSE gets very careful walking through loops and thus is unable to handle this
particular case.
[Bug middle-end/61912] Missed (partial) dead store elimination for structures on GIMPLE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61912
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #2 from Jeffrey A. Law ---
So testing this with my improvements to DSE, we discover that the first 12
bytes and the last 4 bytes of the CONSTRUCTOR assignment are dead. Leaving
just 4 bytes to be handled by the CONSTRUCTOR assignment.Prior to DSE this
looked like:
info = {};
info.prec = prec_11(D);
[ ... more explicit assignments ... ]
With the DSE improvements it turns into;
MEM[(char[4] *)&info + 12B] = {};
info.prec = prec_11(D);
[ more explicit assignment follow. ]
Note how we turned the full CONSTRUCTOR into one that starts at byte offset 12
and just writes 4 bytes.
We could have started the CONSTRUCTOR at byte 13 instead of byte 12, as the
first 8 single bit fields are assigned explicitly. The code detects this
properly, but explicitly avoids trimming to an odd start byte so as not to
totally muck up alignments.
[Bug middle-end/61912] Missed (partial) dead store elimination for structures on GIMPLE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61912 Jeffrey A. Law changed: What|Removed |Added CC||petschy at gmail dot com --- Comment #3 from Jeffrey A. Law --- *** Bug 77485 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/77485] Missed dead store elimination of aggregate store followed by partial stores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77485 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #11 from Jeffrey A. Law --- This is effectively the same as 61912 and fixed by the same change under development. We'll track via 61912, but expect to use the testcase from this BZ as well as 61912 in the testsuite. *** This bug has been marked as a duplicate of bug 61912 ***
[Bug fortran/78798] [cleanup] some int-valued functions should be bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78798 --- Comment #4 from janus at gcc dot gnu.org --- Author: janus Date: Thu Dec 15 20:54:18 2016 New Revision: 243726 URL: https://gcc.gnu.org/viewcvs?rev=243726&root=gcc&view=rev Log: 2016-12-15 Janus Weil PR fortran/78798 * gfortran.h (gfc_compare_derived_types,gfc_compare_types, gfc_compare_interfaces,gfc_has_vector_subscript): Return bool instead of int. * interface.c (compare_components): Ditto. (gfc_compare_union_types): Rename to compare_union_types, declare as static, return bool. (gfc_compare_derived_types): Return bool instead of int. (gfc_compare_types): Ditto. (compare_type): Ditto. (compare_rank): Ditto. (compare_type_rank): Ditto. (compare_type_rank_if): Ditto. (count_types_test): Ditto. (generic_correspondence): Ditto. (gfc_compare_interfaces): Ditto. (check_interface0): Ditto. (check_interface1): Ditto. (compare_allocatable): Ditto. (compare_parameter): Ditto. (gfc_has_vector_subscript): Ditto. (compare_actual_formal): Ditto. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/interface.c
[Bug bootstrap/78817] stage2 bootstrap failure in vec.h:1613:5: error: argument 1 null where non-null expected after r243661
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78817 --- Comment #12 from Martin Sebor --- (In reply to Segher Boessenkool from comment #3) > It is a warning (as well as a bootstrap comparison error) on powerpc64-linux. > You tested on powerpc64le-linux, different animal. I missed that. But I'm not able to reproduce the bootstrap comparison error even on powerpc64-linux (on POWER8). With the warning fixed my bootstrap just completed.
[Bug c++/78771] [5/6/7 Regression] ICE when using inherited constructors (instantiate_template_1 in gcc/cp/pt.c:17391)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78771 --- Comment #2 from Nathan Sidwell --- Created attachment 40345 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40345&action=edit simpler testcase the deletedness of the template ctor is a red herring. Also the templatedness of the base class. This testcase ices in the same way -- we end up looking for a clone during the middle of instantiating the non-clone origin.
[Bug tree-optimization/36602] memset should be optimized into an empty CONSTRUCTOR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36602 Bug 36602 depends on bug 16427, which changed state. Bug 16427 Summary: dead memset not optimized away https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16427 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/16427] dead memset not optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16427 Jeffrey A. Law changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #6 from Jeffrey A. Law --- Both cases compile down to simple returns at the tree level now. I did not bother to bisect precisely which changes are responsible for fixing this BZ.
[Bug bootstrap/78817] stage2 bootstrap failure in vec.h:1613:5: error: argument 1 null where non-null expected after r243661
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78817 --- Comment #13 from Martin Sebor --- (In reply to Franz Sirl from comment #7) > And on x86_64 a profiledbootstrap with --enable-checking=yes fails like this: I have just confirmed this by doing the same. My profiledbootstrap shows the following warnings: DiagnosticCount UniqueFiles -Wformat-length= 321 -Wimplicit-fallthrough= 58 114 -Wmaybe-uninitialized1065 -Wnonnull1764 With the following unique -Wnonnull instances: cc1plus: warning: argument 1 null where non-null expected [-Wnonnull] /opt/notnfs/msebor/src/gcc/trunk/gcc/gengtype.c:1760 /opt/notnfs/msebor/src/gcc/trunk/gcc/gengtype.c:1762 /opt/notnfs/msebor/src/gcc/trunk/gcc/gengtype-parse.c:951 /opt/notnfs/msebor/src/gcc/trunk/gcc/gengtype-parse.c:952 /opt/notnfs/msebor/src/gcc/trunk/gcc/vec.h:1613 The -Wnonnull warnings all look justified to me (as best I can tell), but also easily avoidable.
[Bug tree-optimization/78154] memcpy et al can be assumed to return non-null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78154 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #5 from Jeffrey A. Law --- Fixed by a commit last month.
[Bug c++/77573] bogus wide string literals in diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77573
David Malcolm changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org
--- Comment #1 from David Malcolm ---
http://en.cppreference.com/w/cpp/language/escape says:
"Hexadecimal escape sequences have no length limit and terminate at the first
character that is not a valid hexadecimal digit."
These are 4-byte wchars, so the value fits.
emit_numeric_escape is called twice, once with 0x12345678, then with 0 for the
implicit terminator.
(gdb) p tbuf
$45 = {text = 0x23e77f0 "xV4\022", asize = 256, len = 8}
(gdb) p tbuf->text[0]
$37 = 120 'x'
(gdb) p tbuf->text[1]
$38 = 86 'V'
(gdb) p tbuf->text[2]
$39 = 52 '4'
(gdb) p tbuf->text[3]
$40 = 18 '\022'
Note that "xV4\022" is 0x12345678:
(gdb) p /x tbuf->text[0]
$46 = 0x78
(gdb) p /x tbuf->text[1]
$47 = 0x56
(gdb) p /x tbuf->text[2]
$48 = 0x34
(gdb) p /x tbuf->text[3]
$49 = 0x12
...and then the terminator:
(gdb) p tbuf->text[4]
$41 = 0 '\000'
(gdb) p tbuf->text[5]
$42 = 0 '\000'
(gdb) p tbuf->text[6]
$43 = 0 '\000'
(gdb) p tbuf->text[7]
$44 = 0 '\000'
So I think that the sequence that's printed is valid.
If I'm reading the following right, internally it's stored as a conversion of a
one-byte-per-char array string to a wchar_t:
(gdb) call debug_tree(t)
unit size
align 32 symtab 0 alias set -1 canonical type 0x718d5690 precision
32 min max >
readonly constant
arg 0
unsigned DI
size
unit size
align 64 symtab 0 alias set -1 canonical type 0x71a17f18>
readonly constant
arg 0
readonly constant
arg 0
readonly constant static "xV4\022\000\000\000\000"
(gdb) call debug_tree((tree)0x71a2b560)
unit size
align 32 symtab 0 alias set -1 canonical type 0x71a17bd0
precision 32 min max
pointer_to_this >
DI
size
unit size
align 32 symtab 0 alias set -1 canonical type 0x71a17e70
domain
type_6 DI size unit size
align 64 symtab 0 alias set -1 canonical type 0x71a17c78
precision 64 min max >
pointer_to_this >
readonly constant static "xV4\022\000\000\000\000">
The title of this bug is "bogus wide string literals in diagnostics", but the
diagnostic contains a regular string literal, not a wide string literal.
Perhaps we should be printing it as something like;
L"\x12345678\x00"
or somesuch, for such cases.
FWIW, compare with this:
z.C:1:23: error: invalid conversion from ‘const wchar_t*’ to ‘wchar_t’
[-fpermissive]
constexpr wchar_t s = L"pqrstuvw";
^~~
z.C:1:23: error: ‘(wchar_t)((const
wchar_t*)"p\000\000\000q\000\000\000r\000\000\000s\000\000\000t\000\000\000u\000\000\000v\000\000\000w\000\000\000\000\000\000")’
is not a constant expression
[Bug c/71110] label "caseN" should be warned about
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71110 David Malcolm changed: What|Removed |Added Status|NEW |RESOLVED CC||dmalcolm at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from David Malcolm --- Thanks for filing this bug. We already issue a warning for this within -Wall, via -Wunused-label (since sometime at or before gcc 4.4, I think): test.c: In function ‘main’: test.c:18:3: warning: label ‘case2’ defined but not used [-Wunused-label] case2: ^ I think that if the user accidentally omits the space between the "case" and the value, they're unlikely to also have a reference to that label name. Marking this one as resolved. Feel free to reopen if I'm missing something here.
[Bug bootstrap/78817] stage2 bootstrap failure in vec.h:1613:5: error: argument 1 null where non-null expected after r243661
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78817 John David Anglin changed: What|Removed |Added CC||danglin at gcc dot gnu.org --- Comment #14 from John David Anglin --- Also seen on hppa-unknownlinux-gnu.
[Bug rtl-optimization/29858] regmove has been silently disabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29858 Bug 29858 depends on bug 30119, which changed state. Bug 30119 Summary: libjava testsuite output is erratic and unhelpful https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30119 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX
[Bug other/29842] [meta-bug] outstanding patches / issues from STMicroelectronics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29842 Bug 29842 depends on bug 30119, which changed state. Bug 30119 Summary: libjava testsuite output is erratic and unhelpful https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30119 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX
[Bug testsuite/30119] libjava testsuite output is erratic and unhelpful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30119 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution|--- |WONTFIX --- Comment #11 from Jeffrey A. Law --- libjava is dead.
[Bug target/30026] useless stack movement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30026 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #3 from Jeffrey A. Law --- Fixed, but I have no idea when.
[Bug fortran/78798] [cleanup] some int-valued functions should be bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78798 --- Comment #5 from janus at gcc dot gnu.org --- Looking through gfortran.h, some more candidates which could be converted: int gfc_at_end (void); int gfc_at_eof (void); int gfc_at_bol (void); int gfc_at_eol (void); int gfc_check_include (void); int gfc_define_undef_line (void); int gfc_wide_is_printable (gfc_char_t); int gfc_wide_is_digit (gfc_char_t); int gfc_wide_fits_in_byte (gfc_char_t); int gfc_generic_intrinsic (const char *); int gfc_specific_intrinsic (const char *); int gfc_intrinsic_actual_ok (const char *, const bool); int gfc_has_vector_index (gfc_expr *); int gfc_numeric_ts (gfc_typespec *); int gfc_impure_variable (gfc_symbol *); int gfc_pure (gfc_symbol *); int gfc_implicit_pure (gfc_symbol *); int gfc_elemental (gfc_symbol *); int gfc_compare_array_spec (gfc_array_spec *, gfc_array_spec *); int gfc_constant_ac (gfc_expr *); int gfc_expanded_ac (gfc_expr *); int gfc_check_digit (char, int);
[Bug c/78824] New: multiple add should in my opinion be optimized to multiplication
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78824
Bug ID: 78824
Summary: multiple add should in my opinion be optimized to
multiplication
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pj at hugeone dot co.uk
Target Milestone: ---
Hi
Example (-O3)
volatile uint16_t y;
uint8_t nvx8;
int main(void) {
y = nvx8 + nvx8 + nvx8 + nvx8 + nvx8 + nvx8 + nvx8 + nvx8 + nvx8 + nvx8
+ nvx8 + nvx8 + nvx8 + nvx8 + nvx8 + nvx8;
}
translated to:
y = nvx8 + nvx8 + nvx8 + nvx8 + nvx8 + nvx8 + nvx8 + nvx8 + nvx8 + nvx8
+ nvx8 + nvx8 + nvx8 + nvx8 + nvx8 + nvx8;
94: 80 91 00 01 lds r24, 0x0100
98: 28 2f mov r18, r24
9a: 30 e0 ldi r19, 0x00 ; 0
9c: c9 01 movwr24, r18
9e: 88 0f add r24, r24
a0: 99 1f adc r25, r25
a2: 88 0f add r24, r24
a4: 99 1f adc r25, r25
a6: 82 0f add r24, r18
a8: 93 1f adc r25, r19
aa: 82 0f add r24, r18
ac: 93 1f adc r25, r19
ae: 82 0f add r24, r18
b0: 93 1f adc r25, r19
b2: 82 0f add r24, r18
b4: 93 1f adc r25, r19
b6: 82 0f add r24, r18
b8: 93 1f adc r25, r19
ba: 82 0f add r24, r18
bc: 93 1f adc r25, r19
be: 82 0f add r24, r18
c0: 93 1f adc r25, r19
c2: 82 0f add r24, r18
c4: 93 1f adc r25, r19
c6: 82 0f add r24, r18
c8: 93 1f adc r25, r19
ca: 82 0f add r24, r18
cc: 93 1f adc r25, r19
ce: 82 0f add r24, r18
d0: 93 1f adc r25, r19
d2: 82 0f add r24, r18
d4: 93 1f adc r25, r19
d6: 90 93 02 01 sts 0x0102, r25
da: 80 93 01 01 sts 0x0101, r24
It should be optimized to multiplication I think.
[Bug target/78823] Poor code on PowerPC when moving SFmode values between GPRs and vector registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78823 Michael Meissner changed: What|Removed |Added Target||powerpc64-linux-gnu, ||powerpc64le-linux-gnu Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-12-15 Known to work||4.8.5 Host||powerpc64-linux-gnu, ||powerpc64le-linux-gnu Ever confirmed|0 |1 Build||powerpc64-linux-gnu, ||powerpc64le-linux-gnu --- Comment #1 from Michael Meissner --- This has been a bug since GCC 4.9. GCC 4.8 generated the correct code with -mcpu=power8.
[Bug middle-end/78824] multiple add should in my opinion be optimized to multiplication
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78824 --- Comment #1 from Andrew Pinski --- Works for me on aarch64-linux-gnu with GCC 5.4 and above: main: adrpx1, nvx8 adrpx2, y mov w0, 0 ldrbw1, [x1, #:lo12:nvx8] lsl w1, w1, 4 strhw1, [x2, #:lo12:y] ret
[Bug c++/78825] New: missing error for template partial specialization using template alias type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78825
Bug ID: 78825
Summary: missing error for template partial specialization
using template alias type
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mattia.bonaducci at gmail dot com
Target Milestone: ---
With GCC 5.1 it was possible to compile such code without errors of warnings.
---
template
struct C;
template
using first = T;
template
struct C> // OK only in 5.1
{
};
int main ()
{
}
---
Before and after 5.1 it yields "partial specialization 'C' does not
specialize any template arguments". By that I assume it was regression fixed in
next version. Now by slightly modifying this code we can still compile it
without any warnings or errors.
---
template
struct C;
template
using first = T1;
template
using second = T2;
template
struct C> // OK on 5.1+
{
};
template
struct C> // OK on 5.1+
{
};
int main ()
{
//C> dummy; // error: ambiguous template instantiation
for 'struct C'
}
---
First error we get is when we try to use it. It looks like there is no way of
explicitly pointing to one of this specializations. This problem showed up with
GCC 5 and is still in 6 and 7 snapshot.
Here's how I checked different compiler versions (-std=c++14 -O0 -Wall -Wextra)
https://godbolt.org/g/1uV80Z
[Bug middle-end/78824] multiple add should in my opinion be optimized to multiplication
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78824 --- Comment #2 from Piotr --- avr-gcc actually
[Bug target/78764] CPU type option discarded on 32-bit powerpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78764 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #1 from Segher Boessenkool --- This should have been fixed on trunk in r238639, please confirm. 4.8 (and 4.9) are no longer supported.
[Bug c++/78825] missing error for template partial specialization using template alias type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78825 --- Comment #1 from Maciej Załucki --- My first thought was that it's bug introduced with N3651 support (C++14 variable templates) to GCC 5 and partially fixed in GCC 5.2.
[Bug target/71216] [4.9/5/6/7 Regression] Incorrect PPC assembly due to inserted .machine pseudo-op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71216 Segher Boessenkool changed: What|Removed |Added CC||rin at NetBSD dot org --- Comment #6 from Segher Boessenkool --- *** Bug 78764 has been marked as a duplicate of this bug. ***
[Bug target/78764] CPU type option discarded on 32-bit powerpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78764 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Segher Boessenkool --- Actually, fixed on 5 and 6 as well. This is a dup of PR71216. Please reopen that one if it does not work. *** This bug has been marked as a duplicate of bug 71216 ***
[Bug fortran/78822] [cleanup] replace static char buffers by std:string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78822 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-12-15 Assignee|unassigned at gcc dot gnu.org |janus at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/78826] New: jump bypasses non-POD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78826
Bug ID: 78826
Summary: jump bypasses non-POD
Product: gcc
Version: 6.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: aurzenligl at gmail dot com
Target Milestone: ---
Compiler seems to break c++98 and c++03 standards by allowing to jump over
non-POD automatic local variable declaration.
// jump_bypasses_non_pod.cpp
struct empty {};
struct non_pod_in_cpp03 : public empty {};
void should_not_compile() {
goto label;
non_pod_in_cpp03 x;
label:
(void)x;
}
If I get the standard right, non-aggregates (types with bases or
private/protected non-static data members) are non-PODs and jumping over them
is illegal:
(C++03 6.7 §3) [stmt.dcl]
(C++03 8.5.1 §1) [dcl.init.aggr]
(C++03 9 §4) [class]
I'd expect that -pedantic compilation would at least issue a warning instead of
compiling ill-formed program silently:
$ g++-6 -Wall -Wextra -std=c++98 -g -pedantic -c jump_bypasses_non_pod.cpp
Problem happens with both kinds of jumps:
- goto to label
- switch to case
Problem reproduces with both std flags:
- -std=c++98
- -std=c++03
Problem reproduces on a wide range of gcc releases:
- gcc version 4.9.4 (Ubuntu 4.9.4-2ubuntu1~14.04.1)
- gcc version 5.4.1 20160904 (Ubuntu 5.4.1-2ubuntu1~14.04)
- gcc version 6.2.0 20160901 (Ubuntu 6.2.0-3ubuntu11~14.04)
[Bug c++/78826] jump bypasses non-POD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78826 --- Comment #1 from Andrew Pinski --- Note there might be a rule about non trivial constructors in there too.
[Bug go/78763] go1: internal compiler error: in do_get_backend, at go/gofrontend/expressions.cc:8352
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78763 --- Comment #9 from ian at gcc dot gnu.org --- Author: ian Date: Thu Dec 15 22:47:43 2016 New Revision: 243729 URL: https://gcc.gnu.org/viewcvs?rev=243729&root=gcc&view=rev Log: PR go/78763 compiler: call determine_types even for constant expressions We need to call determine_types even for constant expressions, since a constant expression may include code like unsafe.Sizeof(0). Something needs to determine the type of the untyped 0, and that should be the determine_types pass. Implementing that triggered a compiler crash on test/const1.go because it permitted some erroneous constants to make it all the way to the backend. Catch that case by checking whether we get a constant overflow error, and marking the expression invalid if we do. This is a good change in any case, as previously we reported the same constant overflow error multiple times, and now we only report it once. Fixes GCC PR 78763. Reviewed-on: https://go-review.googlesource.com/34496 Modified: trunk/gcc/go/gofrontend/MERGE trunk/gcc/go/gofrontend/expressions.cc trunk/gcc/go/gofrontend/expressions.h
[Bug fortran/78827] New: Compiling gfortran.dg/charlen_03.f90 and gfortran.dg/charlen_10.f90 cause internal compiler error (regression)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78827
Bug ID: 78827
Summary: Compiling gfortran.dg/charlen_03.f90 and
gfortran.dg/charlen_10.f90 cause internal compiler
error (regression)
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: physiker at toast2 dot net
Target Milestone: ---
There are to two regressions while running the gfortran.dg testsuite:
(See https://gcc.gnu.org/ml/gcc-testresults/2016-12/msg01567.html)
FAIL: gfortran.dg/charlen_03.f90 -O 1 blank line(s) in output
FAIL: gfortran.dg/charlen_03.f90 -O (internal compiler error)
FAIL: gfortran.dg/charlen_10.f90 -O 1 blank line(s) in output
FAIL: gfortran.dg/charlen_10.f90 -O (internal compiler error)
LANG=C gfortran-7 -v -o charlen_03 charlen_03.f90
Driving: gfortran-7 -v -o charlen_03 charlen_03.f90
-mmacosx-version-min=10.11.6 -asm_macosx_version_min=10.11 -l gfortran
-shared-libgcc
Using built-in specs.
COLLECT_GCC=gfortran-7
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/lto-wrapper
Target: x86_64-apple-darwin15.6.0
Configured with: ../gcc/configure --enable-languages=c,c++,fortran,lto
--with-gmp=/sw --with-libiconv-prefix=/sw --with-isl=/sw --with-mpc=/sw
--with-system-zlib --program-suffix=-7
Thread model: posix
gcc version 7.0.0 20161215 (experimental) [trunk revision 243680] (GCC)
COLLECT_GCC_OPTIONS='-v' '-o' 'charlen_03' '-mmacosx-version-min=10.11.6'
'-asm_macosx_version_min=10.11' '-shared-libgcc' '-mtune=core2'
/usr/local/libexec/gcc/x86_64-apple-darwin15.6.0/7.0.0/f951 charlen_03.f90
-fPIC -quiet -dumpbase charlen_03.f90 -mmacosx-version-min=10.11.6 -mtune=core2
-auxbase charlen_03 -version -fintrinsic-modules-path
/usr/local/lib/gcc/x86_64-apple-darwin15.6.0/7.0.0/finclude -o
/var/folders/97/4qnhjhtn25s86s9hkz0h37_mgn/T//cc0FKK10.s
GNU Fortran (GCC) version 7.0.0 20161215 (experimental) [trunk revision 243680]
(x86_64-apple-darwin15.6.0)
compiled by GNU C version 7.0.0 20161215 (experimental) [trunk revision
243680], GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version
0.15
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU Fortran2008 (GCC) version 7.0.0 20161215 (experimental) [trunk revision
243680] (x86_64-apple-darwin15.6.0)
compiled by GNU C version 7.0.0 20161215 (experimental) [trunk revision
243680], GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version
0.15
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
charlen_03.f90:5:39:
character(:), allocatable :: x(n) ! { dg-error "must have a deferred
shape" }
1
Error: Allocatable component of structure at (1) must have a deferred shape
f951: internal compiler error: Segmentation fault: 11
f951: internal compiler error: Abort trap: 6
gfortran-7: internal compiler error: Abort trap: 6 (program f951)
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
gfortran version 6.2.0:
LANG=C gfortran-fsf-6 -o charlen_03 charlen_03.f90
charlen_03.f90:5:39:
character(:), allocatable :: x(n) ! { dg-error "must have a deferred
shape" }
1
Error: Allocatable component of structure at (1) must have a deferred shape
(null):0: confused by earlier errors, bailing out
[Bug fortran/78746] charlen_15.f90, charlen_03, charlen_10 ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78746 Dominique d'Humieres changed: What|Removed |Added CC||physiker at toast2 dot net --- Comment #4 from Dominique d'Humieres --- *** Bug 78827 has been marked as a duplicate of this bug. ***
[Bug fortran/78827] Compiling gfortran.dg/charlen_03.f90 and gfortran.dg/charlen_10.f90 cause internal compiler error (regression)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78827 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Dominique d'Humieres --- Duplicate of pr78746. *** This bug has been marked as a duplicate of bug 78746 ***
