[Bug c++/81074] [7/8 Regression] Nested template specialization causes segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81074 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-06-13 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Target Milestone|--- |7.2 Summary|[7 regression] Nested |[7/8 Regression] Nested |template specialization |template specialization |causes segmentation fault |causes segmentation fault Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r238785.
[Bug sanitizer/81079] -static-libasan/libtsan/libubsan does not take effect unless -fsanitize=address/thread/undefined is also specified when linking object files using gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81079 --- Comment #2 from d25fe0be@ --- Thank you for your explanation. I missed 'When the -fsanitize=address option is used to link a program' in the documentation as I was reading. Sorry for the noise.
[Bug middle-end/81052] ICE in verify_dominators, at dominance.c:1184
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81052 Martin Liška changed: What|Removed |Added Status|WAITING |NEW Known to fail||7.1.0, 8.0 --- Comment #4 from Martin Liška --- I see, thanks for that.
[Bug sanitizer/81079] -static-libasan/libtsan/libubsan does not take effect unless -fsanitize=address/thread/undefined is also specified when linking object files using gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81079
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #1 from Martin Liška ---
(In reply to d25fe0be@ from comment #0)
> When object files (compiled separately) are linked together using GCC, even
> if -static-libxsan is specifed, the corresponding libraries seems not to be
> linked, resulting in undefined references to __ubsan_xxx / ... .
>
> It seems that -static-libxsan is suppressed by the absence of -fsanitize=xxx.
>
> lsan seems not to suffer from this though.
>
Hi.
It's documented pretty well:
```
-static-libasan
When the -fsanitize=address option is used to link a program, the GCC driver
automatically links against libasan. If libasan is available as a shared
library, and the -static option is not used, then this links against the shared
version of libasan. The -static-libasan option directs the GCC driver to link
libasan statically, without necessarily linking other libraries statically.
```
Thus one needs to use -fsanitize=x in linking. I also verified and liblsan
behaves the same. Problem is that liblasan does not contain a symbol that will
cause an unresolved symbol. But:
$ cat pr81079.cpp
#include
const int &f() {
return {};
}
int main() {
int *a = (int*)malloc (123);
f();
}
$ g++ pr81079.cpp -std=c++11 -c -fsanitize=leak
$ g++ pr81079.o -std=c++11 && ./a.out
[no output]
while:
$ g++ pr81079.o -std=c++11 -fsanitize=leak && ./a.out
=
==7875==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 123 byte(s) in 1 object(s) allocated from:
#0 0x2aeb4c5d15a6 in malloc (/usr/lib64/liblsan.so.0+0xd5a6)
#1 0x40062a in main (/home/marxin/Programming/testcases/a.out+0x40062a)
#2 0x2aeb4dd39469 in __libc_start_main (/lib64/libc.so.6+0x20469)
SUMMARY: LeakSanitizer: 123 byte(s) leaked in 1 allocation(s).
That said, I'm closing that as invalid.
[Bug testsuite/80759] gcc.target/x86_64/abi/ms-sysv FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80759 Daniel Santos changed: What|Removed |Added Attachment #41543|0 |1 is obsolete|| --- Comment #38 from Daniel Santos --- Created attachment 41543 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41543&action=edit proposed fix v5 addendum (only partially tested) I've only run check on RUNTESTFLAGS="ms-sysv.exp" so far and I have a full regression test running right now, but I *think* this is correct. I'm presuming that using .hidden is a no-no as well, at least from what I can tell it's elf-specific, but I'm not sure what else to do with it other than #ifdef __ELF__. (I googled 'hidden elf' and got a lot of interesting fiction...) So I'm sorry to just ask you to see if it blows up on Solaris & Darwin w/o gas. I'm also unsure about my changes to libtgcc/config.host as I just don't have a broad understanding of all of the *nix platforms out there. Feedback greatly appreciated! Thanks, Daniel --- Comment #39 from Daniel Santos --- Created attachment 41544 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41544&action=edit proposed fix v5 addendum (only partially tested) remove fix stray carriage return...
[Bug testsuite/80759] gcc.target/x86_64/abi/ms-sysv FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80759 --- Comment #38 from Daniel Santos --- Created attachment 41543 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41543&action=edit proposed fix v5 addendum (only partially tested) I've only run check on RUNTESTFLAGS="ms-sysv.exp" so far and I have a full regression test running right now, but I *think* this is correct. I'm presuming that using .hidden is a no-no as well, at least from what I can tell it's elf-specific, but I'm not sure what else to do with it other than #ifdef __ELF__. (I googled 'hidden elf' and got a lot of interesting fiction...) So I'm sorry to just ask you to see if it blows up on Solaris & Darwin w/o gas. I'm also unsure about my changes to libtgcc/config.host as I just don't have a broad understanding of all of the *nix platforms out there. Feedback greatly appreciated! Thanks, Daniel
[Bug c++/81067] [8 regression] g++.dg/template/nontype10.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81067 David Edelsohn changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-06-12 CC||dje at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from David Edelsohn --- This seems to be failing on all 32 bit targets (IA-32, powerpc -m32, AIX -m32).
[Bug c++/81078] New: dynamic_cast to virtual base produces the wrong answer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81078
Bug ID: 81078
Summary: dynamic_cast to virtual base produces the wrong answer
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
(This was found by the same fuzzer as
https://bugs.llvm.org/show_bug.cgi?id=33425 --- except in this case Clang gets
the right answer and GCC gets it wrong.)
#include
struct Class2 { virtual ~Class2() {} };
struct Class3 { virtual ~Class3() {} };
struct Class4 : protected virtual Class3, public Class2 {};
struct Class8 : public virtual Class3, public Class4 {};
int main() {
Class8 c8;
Class2 *c2 = static_cast(&c8);
Class3 *c3 = static_cast(&c8);
printf("cast Class3 to Class2: %p\n", dynamic_cast(c3));
printf("cast Class2 to Class3: %p\n", dynamic_cast(c2));
}
Clang and GCC disagree about this code: Clang makes both dynamic_casts succeed,
and GCC makes them both fail (that is, return nullptr). I believe that Clang is
correct and GCC is wrong, because this case is covered by N4618
[expr.dynamic.cast] 5.2.7 /(8.2):
> If C is the class type to which T points or refers, the runtime check
> logically executes as follows:
>
> (8.1) If, in the most derived object pointed (referred) to by v, v points
> (refers) to a public base class subobject of a C object, and if only one
> object of type C is derived from the subobject pointed (referred) to by v the
> result points (refers) to that C object.
>
> (8.2) Otherwise, if v points (refers) to a public base class subobject of the
> most derived object, and the type of the most derived object has a base
> class, of type C, that is unambiguous and public, the result points (refers)
> to the C subobject of the most derived object.
>
> (8.3) Otherwise, the runtime check fails.
MSVC seems to agree with me and with Clang.
[Bug testsuite/80759] gcc.target/x86_64/abi/ms-sysv FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80759 --- Comment #37 from Daniel Santos --- (In reply to Daniel Santos from comment #36) > tutor! :) This is assembly with cpp, so the gas .macro could be replaced > with a cpp macro, but is that acceptable considering that it would result in > multiple instructions on the same line delimited by semicolons instead of > "\n\t"? So should I just copy & paste the instructions and be done with it? I forgot to note that even though the gas .macro takes an argument for base offset, in all uses that offset is 0x60.
[Bug testsuite/80759] gcc.target/x86_64/abi/ms-sysv FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80759
--- Comment #36 from Daniel Santos ---
Thank you for all of your work on this. The .cfi directives shouldn't be *too*
critical -- I've barely scratched the surface of learning DWARF and, iirc, the
last time I stepped through these stubs in gdb it still wasn't always able to
determine the call frame correctly (although I could be thinking of stepping
through the assembly code in the test program). I suppose this can be an issue
for somebody debugging Wine code at some future date, but I have no qualms with
removing it for now, and possibly redoing it later in more portable way (and
that actually provides the debugger with everything it needs).
Also, you *had* mentioned this linking problem in the past and I apologize for
loosing track of it. I have not actually done a thorough study of ABIs used in
other *nix operating systems, but my guess would be that all 64-bit platforms
that GCC supports use the SystemV ABI except for Windows (Cygwin & MinGW)?
This is a question outside of my expertise, so please let me know if the below
solution amenable.
I should also note that while this optimization isn't meant for Windows and
would likely almost never appear in code built for windows (unless somebody is
trying to link to objects/libs built on for *nix), support on Windows is
explicitly disabled due to the SEH unwind emit code not supporting
REG_CFA_EXPRESSION, which it requires. So we don't need the stubs on Windows
anyway.
diff --git a/libgcc/config.host b/libgcc/config.host
index 7711abf2704..f0f0d6c0916 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -1355,6 +1355,14 @@ esac
case ${host} in
i[34567]86-*-* | x86_64-*-*)
case ${host} in
+ *-*-cygwin* | *-*-mingw*)
+ ;;
+ *)
+ tmake_file="${tmake_file} i386/t-msabi"
+ ;;
+ esac
+
+ case ${host} in
*-musl*)
tmake_file="${tmake_file} i386/t-cpuinfo-static"
;;
@@ -1365,11 +1373,12 @@ i[34567]86-*-* | x86_64-*-*)
;;
esac
+
case ${host} in
i[34567]86-*-linux* | x86_64-*-linux* | \
i[34567]86-*-kfreebsd*-gnu | x86_64-*-kfreebsd*-gnu | \
i[34567]86-*-gnu*)
- tmake_file="${tmake_file} t-tls i386/t-linux i386/t-msabi
t-slibgcc-libgcc"
+ tmake_file="${tmake_file} t-tls i386/t-linux t-slibgcc-libgcc"
if test "$libgcc_cv_cfi" = "yes"; then
tmake_file="${tmake_file} t-stack i386/t-stack-i386"
fi
As for the stubs, I don't think there's a real need to stay tied to gas
extensions -- truth be told, this was my first actual non-inline, x86 assembly
code I have written (last time I did assembly prior was on a Motorola
6502/6510), so I'm sorry to have forced you to become my unwitting tutor! :)
This is assembly with cpp, so the gas .macro could be replaced with a cpp
macro, but is that acceptable considering that it would result in multiple
instructions on the same line delimited by semicolons instead of "\n\t"? So
should I just copy & paste the instructions and be done with it?
Thanks,
Daniel
[Bug fortran/52473] CSHIFT slow - inline it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52473 --- Comment #12 from Thomas Koenig --- Created attachment 41542 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41542&action=edit Test case which still fails
[Bug fortran/52473] CSHIFT slow - inline it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52473 --- Comment #11 from Thomas Koenig --- Created attachment 41541 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41541&action=edit Patch for the library, not yet quite correct This is a patch which brings a dramatic speedup for any cshift with dim>1, but it also causes a regression for a test case which I will attach next.
[Bug libstdc++/81076] __byte_operand is not SFINAE-friendly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81076 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-06-12 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Target Milestone|--- |7.2 Ever confirmed|0 |1
[Bug c++/80265] __builtin_{memcmp,memchr,strlen} are not usable in constexpr functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265
--- Comment #19 from palves at gcc dot gnu.org ---
Author: palves
Date: Mon Jun 12 22:22:39 2017
New Revision: 249137
URL: https://gcc.gnu.org/viewcvs?rev=249137&root=gcc&view=rev
Log:
Finish implementing P0426R1 "Constexpr for std::char_traits" for C++17
As discussed in PR c++/80265 ("__builtin_{memcmp,memchr,strlen} are
not usable in constexpr functions"), use __builtin_constant_p to tell
whether we can defer to a constexpr algorithm.
I used __always_inline__ just to be thorough. It isn't really really
necessary as far as I could determine.
Changes like these:
if (__n == 0)
return 0;
- return wmemcmp(__s1, __s2, __n);
+ else
+return wmemcmp(__s1, __s2, __n);
are necessary otherwise G++ complains that we're calling a
non-constexpr function, which looks like a a manifestation of PR67026
to me.
libstdc++-v3:
2017-06-12 Pedro Alves
* doc/xml/manual/status_cxx2017.xml: Update C++17 constexpr
char_traits status.
* doc/html/*: Regenerate.
* include/bits/char_traits.h (_GLIBCXX_ALWAYS_INLINE): Define if
not already defined.
(__cpp_lib_constexpr_char_traits): Uncomment.
(__constant_string_p, __constant_char_array_p): New.
(std::char_traits, std::char_traits): Add
_GLIBCXX17_CONSTEXPR on compare, length and find and use
__constant_string_p, __constant_char_array_p and
__builtin_constant_p to defer to __gnu_cxx::char_traits at compile
time.
* testsuite/21_strings/char_traits/requirements/
constexpr_functions_c++17.cc: Uncomment
__cpp_lib_constexpr_char_traits tests. Uncomment
test_compare, test_length, test_find,
test_compare, test_length and test_find
static_assert tests.
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/doc/xml/manual/status_cxx2017.xml
trunk/libstdc++-v3/include/bits/char_traits.h
trunk/libstdc++-v3/testsuite/21_strings/char_traits/requirements/constexpr_functions_c++17.cc
[Bug c/81077] linker constants are randomized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81077 Grégory Mounié changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #3 from Grégory Mounié --- Output due to the randomization of the virtual address space The use of -fno-pie -no-pie at compile and link time solve the "bug".
[Bug c/81077] linker constants are randomized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81077 --- Comment #2 from Grégory Mounié --- Yes ! It correct my problem. I should have found it alone. Sorry for the inconvenience and thanks for lightning speed answer. Grégory Le 12/06/2017 à 23:02, pinskia at gcc dot gnu.org a écrit : > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81077 > > Andrew Pinski changed: > >What|Removed |Added > > Status|UNCONFIRMED |WAITING >Last reconfirmed||2017-06-12 > Ever confirmed|0 |1 > > --- Comment #1 from Andrew Pinski --- > -fPIE is default for the compiler you are using so they are definitely going > to > be randomized. > > Use -fno-pie -no-pie when compiling if you want non-random virtual addresses. >
[Bug c/81077] linker constants are randomized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81077 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2017-06-12 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- -fPIE is default for the compiler you are using so they are definitely going to be randomized. Use -fno-pie -no-pie when compiling if you want non-random virtual addresses.
[Bug c/81077] New: linker constants are randomized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81077
Bug ID: 81077
Summary: linker constants are randomized
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gregory.mounie at imag dot fr
Target Milestone: ---
Created attachment 41540
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41540&action=edit
printf of two linker constants using & and [] notations
When compiling with linker constants, the constants values does not have the
given values but looks randomized. They change values at each execution.
Theses constants have really only an address but no values. The symbol table of
the executable is still correct according to objdump.
Code of my test file (testld.c (the .i file is in attachment)
#include
extern unsigned char liloo;
extern unsigned char lilootab[];
static void * spa = & liloo;
static void * sta = lilootab;
int main() {
void * pa = & liloo;
void * ta = lilootab;
printf("%p %p %p %p\n", spa, sta, pa, ta);
return 0;
}
Command line of compilation:
gcc -v -save-temps -Wl,--defsym=liloo=0x100 -Wl,--defsym=lilootab=0x200
testld.c -o testld
Output of the compilation:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 6.3.0-18'
--with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-6 --program-prefix=x86_64-linux-gnu- --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--with-target-system-zlib --enable-objc-gc=auto --enable-multiarch
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 6.3.0 20170516 (Debian 6.3.0-18)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'testld' '-mtune=generic'
'-march=x86-64'
/usr/lib/gcc/x86_64-linux-gnu/6/cc1 -E -quiet -v -imultiarch x86_64-linux-gnu
testld.c -mtune=generic -march=x86-64 -fpch-preprocess -o testld.i
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/6/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-linux-gnu/6/include
/usr/local/include
/usr/lib/gcc/x86_64-linux-gnu/6/include-fixed
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'testld' '-mtune=generic'
'-march=x86-64'
/usr/lib/gcc/x86_64-linux-gnu/6/cc1 -fpreprocessed testld.i -quiet -dumpbase
testld.c -mtune=generic -march=x86-64 -auxbase testld -version -o testld.s
GNU C11 (Debian 6.3.0-18) version 6.3.0 20170516 (x86_64-linux-gnu)
compiled by GNU C version 6.3.0 20170516, GMP version 6.1.2, MPFR
version 3.1.5, MPC version 1.0.3, isl version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C11 (Debian 6.3.0-18) version 6.3.0 20170516 (x86_64-linux-gnu)
compiled by GNU C version 6.3.0 20170516, GMP version 6.1.2, MPFR
version 3.1.5, MPC version 1.0.3, isl version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 0fe3e671dc62e01e15c40cc5df58cb5f
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'testld' '-mtune=generic'
'-march=x86-64'
as -v --64 -o testld.o testld.s
Version de l'assembleur GNU 2.28 (x86_64-linux-gnu) utilisant la version BFD
(GNU Binutils for Debian) 2.28
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/6/:/usr/lib/gcc/x86_64-linux-gnu/6/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/6/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/6/:/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/6/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/6/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o
[Bug fortran/80983] [F03] memory leak when calling procedure-pointer component with allocatable result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80983 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 libstdc++/81076] New: __byte_operand is not SFINAE-friendly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81076
Bug ID: 81076
Summary: __byte_operand is not SFINAE-friendly
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
Because the primary template is left undefined, the cv specializations of
__byte_operand causes a hard error for nonintegral types:
#include
template void to_integer(...);
using t = decltype(to_integer(std::byte{}));
using t = void;
[Bug target/81075] [avr] Move jump-tables out of .text
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81075 Georg-Johann Lay changed: What|Removed |Added Keywords||missed-optimization Target||avr Priority|P3 |P4 Assignee|unassigned at gcc dot gnu.org |gjl at gcc dot gnu.org
[Bug target/81075] New: [avr] Move jump-tables out of .text
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81075 Bug ID: 81075 Summary: [avr] Move jump-tables out of .text Product: gcc Version: 6.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: gjl at gcc dot gnu.org Target Milestone: --- Since PR71151 has been fixed (v6.2), we have JUMP_TABLES_IN_TEXT_SECTION. This means that branches that cross such tables have larger branch offsets than before that fix. Hence resurrect jump tables that are not in .text.
[Bug target/80968] stack frame reference allowed in delay slot of return instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80968 --- Comment #10 from davem at gcc dot gnu.org --- Author: davem Date: Mon Jun 12 19:32:49 2017 New Revision: 249135 URL: https://gcc.gnu.org/viewcvs?rev=249135&root=gcc&view=rev Log: More refinements to fixing sparc's PR target/80968. PR target/80968 * config/sparc/sparc.md (return expander): Emit frame blockage if function uses alloca. Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/config/sparc/sparc.md
[Bug target/80968] stack frame reference allowed in delay slot of return instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80968 --- Comment #9 from davem at gcc dot gnu.org --- Author: davem Date: Mon Jun 12 19:30:45 2017 New Revision: 249134 URL: https://gcc.gnu.org/viewcvs?rev=249134&root=gcc&view=rev Log: More refinements to fixing sparc's PR target/80968. gcc/ PR target/80968 * config/sparc/sparc.md (return expander): Emit frame blockage if function uses alloca. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sparc/sparc.md
[Bug c++/81074] New: [7 regression] Nested template specialization causes segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81074
Bug ID: 81074
Summary: [7 regression] Nested template specialization causes
segmentation fault
Product: gcc
Version: 7.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jan at ypmania dot nl
Target Milestone: ---
Created attachment 41539
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41539&action=edit
Source file causing the segfault
The attached test.cpp defines a partially specialized template inside of a
template, i.e. as
template
struct Outer {
template
struct Inner {};
template
struct Inner { ... };
};
and causes a segmentation fault while trying to resolve constexpr's inside
Inner. The problem goes away if I flatten the structure, moving the inner
templates into the global namespace.
This is possibly related / duplicate of #55639; however, the code compiled fine
under GCC 6 and 5 (compiler explorer verifies this).
GCC Output: ---
$ gcc -v -save-temps test.cpp
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --disable-multilib --disable-werror
--enable-checking=release
Thread model: posix
gcc version 7.1.1 20170516 (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/cc1plus -E -quiet -v -D_GNU_SOURCE
test.cpp -mtune=generic -march=x86-64 -fpch-preprocess -o test.ii
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../include/c++/7.1.1
/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../include/c++/7.1.1/x86_64-pc-linux-gnu
/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../include/c++/7.1.1/backward
/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/include
/usr/local/include
/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/include-fixed
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/cc1plus -fpreprocessed test.ii -quiet
-dumpbase test.cpp -mtune=generic -march=x86-64 -auxbase test -version -o
test.s
GNU C++14 (GCC) version 7.1.1 20170516 (x86_64-pc-linux-gnu)
compiled by GNU C version 7.1.1 20170516, GMP version 6.1.2, MPFR
version 3.1.5-p2, MPC version 1.0.3, isl version isl-0.18-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++14 (GCC) version 7.1.1 20170516 (x86_64-pc-linux-gnu)
compiled by GNU C version 7.1.1 20170516, GMP version 6.1.2, MPFR
version 3.1.5-p2, MPC version 1.0.3, isl version isl-0.18-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 74aace2f6deb87bb86dbfd7a28ebe524
test.cpp: In substitution of ‘template struct Outer::Varint<_fieldIdx, unsigned char, field> [with
unsigned char _fieldIdx = 1; uint8_t Msg::* field = &Msg::a]’:
test.cpp:5:30: required from ‘constexpr const uint8_t
HighestMaxFieldIdx::Varint<1, unsigned char, &Msg::a>
>::maxFieldIdx’
test.cpp:25:95: required from here
test.cpp:5:30: internal compiler error: Segmentation fault
static constexpr uint8_t maxFieldIdx = T::fieldIdx;
^~~
[Bug tree-optimization/81063] [8 Regression] wrong code at -O1 and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81063 Martin Jambor changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Martin Jambor --- Hi, this is a duplicate on the issue I was working on last week (sorry for the breakage). I have just posted patches to address this issue to the mailing list: - https://gcc.gnu.org/ml/gcc-patches/2017-06/msg00833.html - https://gcc.gnu.org/ml/gcc-patches/2017-06/msg00834.html *** This bug has been marked as a duplicate of bug 80803 ***
[Bug other/80803] libgo appears to be miscompiled on powerpc64le since r247497
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80803 Martin Jambor changed: What|Removed |Added CC||su at cs dot ucdavis.edu --- Comment #31 from Martin Jambor --- *** Bug 81063 has been marked as a duplicate of this bug. ***
[Bug other/80803] libgo appears to be miscompiled on powerpc64le since r247497
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80803 --- Comment #30 from Martin Jambor --- I have posted the following two patches to fix this issue to the mailing list. The second one also includes two simple C testcases: - https://gcc.gnu.org/ml/gcc-patches/2017-06/msg00833.html - https://gcc.gnu.org/ml/gcc-patches/2017-06/msg00834.html
[Bug libstdc++/55917] Impossible to find/debug unhandled exceptions in an std::thread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55917 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |8.0 --- Comment #17 from Jonathan Wakely --- Fixed for GCC 8.
[Bug libstdc++/55917] Impossible to find/debug unhandled exceptions in an std::thread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55917 --- Comment #16 from Jonathan Wakely --- Author: redi Date: Mon Jun 12 16:37:28 2017 New Revision: 249130 URL: https://gcc.gnu.org/viewcvs?rev=249130&root=gcc&view=rev Log: PR libstdc++/55917 do not handle exceptions in std::thread PR libstdc++/55917 * src/c++11/thread.cc (execute_native_thread_routine): Remove try-block so that exceptions propagate out of the thread and terminate is called by the exception-handling runtime. (execute_native_thread_routine_compat): Likewise. * testsuite/30_threads/thread/cons/terminate.cc: New. Added: trunk/libstdc++-v3/testsuite/30_threads/thread/cons/terminate.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/src/c++11/thread.cc
[Bug c/81050] ICE with -fexec-charset=utf-16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81050 --- Comment #2 from joseph at codesourcery dot com --- That's not a valid execution character set (unless char is at least 16 bits, which doesn't currently apply to any GCC target). "The basic character set shall be present and each character shall be encoded as a single byte." and "A byte with all bits zero shall be interpreted as a null character independent of shift state. Such a byte shall not occur as part of any other multibyte character.". It would be reasonable to reject any attempt to set the execution character set to UTF-16, UTF-32 or any other character sets where any member of the basic character set is mapped to more than one byte, or that use the zero byte as part of another character.
[Bug c++/81073] [5/6/7/8 Regression] link failure as C++ misses to instanciate some objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81073 Jonathan Wakely changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #2 from Jonathan Wakely --- r217662 is correct (i.e. defines the variable), r217663 gives an ICE, which persists until r217748 which compiles it again but fails to define the variable. commit da7981e061ae97c7f83ed4ace5cf725e6fe0cffb Author: jason Date: Wed Nov 19 03:03:39 2014 + * constexpr.c (cxx_eval_statement_list): Handle statement-expressions. (potential_constant_expression_1): Handle STMT_EXPR. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@217748 138bc75d-0d04-0410-961f-82ee72b054a4
[Bug testsuite/80759] gcc.target/x86_64/abi/ms-sysv FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80759
--- Comment #35 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> In all cases, I get link errors:
>
> Excess errors:
> Undefined first referenced
> symbol in file
> __resms64f_12 /var/tmp//ccRVJueb.o
> __resms64f_13 /var/tmp//ccRVJueb.o
> __resms64f_14 /var/tmp//ccRVJueb.o
> __resms64f_15 /var/tmp//ccRVJueb.o
> __resms64f_16 /var/tmp//ccRVJueb.o
> __resms64f_17 /var/tmp//ccRVJueb.o
> __savms64f_12 /var/tmp//ccRVJueb.o
> __savms64f_13 /var/tmp//ccRVJueb.o
> __savms64f_14 /var/tmp//ccRVJueb.o
> __savms64f_15 /var/tmp//ccRVJueb.o
> __savms64f_16 /var/tmp//ccRVJueb.o
> __savms64f_17 /var/tmp//ccRVJueb.o
> __resms64fx_12 /var/tmp//ccRVJueb.o
> __resms64fx_13 /var/tmp//ccRVJueb.o
> __resms64fx_14 /var/tmp//ccRVJueb.o
> __resms64fx_15 /var/tmp//ccRVJueb.o
> __resms64fx_16 /var/tmp//ccRVJueb.o
> __resms64fx_17 /var/tmp//ccRVJueb.o
> ld: fatal: symbol referencing errors
I've found what's going on here: those functions are from
libgcc/config/i386/{res, sav}ms64*.S. However,
t-msabi which controls their build is only included for Linux/x86_64
targets, not for Solaris (or Darwin).
If I do this with /bin/as, I get all sorts of assembler errors:
Assembler:
"/var/tmp//ccPz3Pub.s", line 1 : Illegal mnemonic
Near line: ".macro SSE_SAVE off=0"
"/var/tmp//ccPz3Pub.s", line 1 : Syntax error
Near line: ".macro SSE_SAVE off=0"
"/var/tmp//ccPz3Pub.s", line 1 : Syntax error
Near line: ".macro SSE_SAVE off=0"
"/var/tmp//ccPz3Pub.s", line 2 : Syntax error
Near line: " movaps %xmm15,(\off - 0x90)(%rax)"
"/var/tmp//ccPz3Pub.s", line 3 : Syntax error
Near line: " movaps %xmm14,(\off - 0x80)(%rax)"
"/var/tmp//ccPz3Pub.s", line 4 : Syntax error
Near line: " movaps %xmm13,(\off - 0x70)(%rax)"
"/var/tmp//ccPz3Pub.s", line 5 : Syntax error
Near line: " movaps %xmm12,(\off - 0x60)(%rax)"
"/var/tmp//ccPz3Pub.s", line 6 : Syntax error
Near line: " movaps %xmm11,(\off - 0x50)(%rax)"
"/var/tmp//ccPz3Pub.s", line 7 : Syntax error
"/var/tmp//ccPz3Pub.s", line 8 : Syntax error
Near line: " movaps %xmm9, (\off - 0x30)(%rax)"
"/var/tmp//ccPz3Pub.s", line 9 : Syntax error
Near line: " movaps %xmm8, (\off - 0x20)(%rax)"
"/var/tmp//ccPz3Pub.s", line 10 : Syntax error
Near line: " movaps %xmm7, (\off - 0x10)(%rax)"
"/var/tmp//ccPz3Pub.s", line 11 : Syntax error
Near line: " movaps %xmm6, \off(%rax)"
"/var/tmp//ccPz3Pub.s", line 12 : Illegal mnemonic
Near line: ".endm"
"/var/tmp//ccPz3Pub.s", line 12 : Syntax error
Near line: ".endm"
"/var/tmp//ccPz3Pub.s", line 13 : Illegal mnemonic
Near line: ".macro SSE_RESTORE off=0"
"/var/tmp//ccPz3Pub.s", line 13 : Syntax error
Near line: ".macro SSE_RESTORE off=0"
"/var/tmp//ccPz3Pub.s", line 13 : Syntax error
Near line: ".macro SSE_RESTORE off=0"
"/var/tmp//ccPz3Pub.s", line 14 : Syntax error
Near line: " movaps (\off - 0x90)(%rsi), %xmm15"
"/var/tmp//ccPz3Pub.s", line 15 : Syntax error
Near line: " movaps (\off - 0x80)(%rsi), %xmm14"
"/var/tmp//ccPz3Pub.s", line 16 : Syntax error
Near line: " movaps (\off - 0x70)(%rsi), %xmm13"
"/var/tmp//ccPz3Pub.s", line 17 : Syntax error
Near line: " movaps (\off - 0x60)(%rsi), %xmm12"
"/var/tmp//ccPz3Pub.s", line 18 : Syntax error
Near line: " movaps (\off - 0x50)(%rsi), %xmm11"
"/var/tmp//ccPz3Pub.s", line 19 : Syntax error
Near line: " movaps (\off - 0x40)(%rsi), %xmm10"
"/var/tmp//ccPz3Pub.s", line 20 : Syntax error
Near line: " movaps (\off - 0x30)(%rsi), %xmm9"
"/var/tmp//ccPz3Pub.s", line 21 : Syntax error
Near line: " movaps (\off - 0x20)(%rsi), %xmm8"
"/var/tmp//ccPz3Pub.s", line 22 : Syntax error
Near line: " movaps (\off - 0x10)(%rsi), %xmm7"
"/var/tmp//ccPz3Pub.s", line 23 : Syntax error
Near line: " movaps \off(%rsi), %xmm6"
"/var/tmp//ccPz3Pub.s", line 24 : Illegal mnemonic
Near line: ".endm"
"/var/tmp//ccPz3Pub.s", line 24 : Syntax error
Near line: ".endm"
"/var/tmp//ccPz3Pub.s", line 41 : Illegal mnemonic
Near line: " SSE_SAVE off=0x60"
Too many errors - Goodbye
make[2]: *** [/vol/gcc/src/hg/trunk/local/libgcc/shared-object.mk:36:
savms64_s.o] Error 1
make[2]: Leaving directory
'/var/gcc/regressio
[Bug c++/81073] [5/6/7/8 Regression] link failure as C++ misses to instanciate some objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81073
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2017-06-12
Known to work||4.9.4
Summary|link failure as C++ misses |[5/6/7/8 Regression] link
|to instanciate some objects |failure as C++ misses to
||instanciate some objects
Ever confirmed|0 |1
Known to fail||5.4.0, 6.3.0, 7.1.0, 8.0
--- Comment #1 from Jonathan Wakely ---
C++98 version that compiles fine with versions before 5.1.0
struct test { const int *addr; };
const test* setup()
{
static const test atest =
{
({ static const int inner = 123; &inner; })
};
return &atest;
}
int main(){}
[Bug middle-end/77926] Add __builtin_iszero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77926 tnfchris at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2017-06-12 Resolution|FIXED |--- Ever confirmed|0 |1 --- Comment #3 from tnfchris at gcc dot gnu.org --- Patch has been reverted to due to late expansion issues and PowerPC failures.
[Bug middle-end/77925] Add __builtin_issubnormal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77925 tnfchris at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2017-06-12 Resolution|FIXED |--- Ever confirmed|0 |1 --- Comment #3 from tnfchris at gcc dot gnu.org --- Patch has been reverted to due to late expansion issues and PowerPC failures.
[Bug middle-end/81052] ICE in verify_dominators, at dominance.c:1184
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81052 --- Comment #3 from ryan.burn at gmail dot com --- The only other gcc I have installed is g++ (GCC) 7.0.1 20170408 (experimental) Copyright (C) 2017 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. I attached the preprocessed output from that compiler as well if it helps.
[Bug middle-end/81052] ICE in verify_dominators, at dominance.c:1184
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81052 --- Comment #2 from ryan.burn at gmail dot com --- Created attachment 41538 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41538&action=edit old compiler preprocessed
[Bug sanitizer/81021] stack-use-after-scope false positive error with exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81021 --- Comment #4 from Martin Liška --- Created attachment 41537 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41537&action=edit Untested patch
[Bug c++/81073] New: link failure as C++ misses to instanciate some objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81073
Bug ID: 81073
Summary: link failure as C++ misses to instanciate some objects
Product: gcc
Version: 7.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
$ g++ struct.cpp -Os -save-temps
the following C++ test case struct.cpp:
struct test { const int *addr; };
const test* setup()
{
static constexpr test atest =
{
({ static const int inner = 123; &inner; })
};
return &atest;
}
int main(){}
This gives a linker error:
struct.o:(.rodata+0x0): undefined reference to `setup()::inner'
"atest" is initialized as expected with a reference to _ZZ5setupvE5inner, but
that object is never instanciated, resulting in a link failure.
Seeing this with v7.1 on and for x86_64-linux-gnu, also on trunk (future v8).
[Bug sanitizer/81023] False positiv stack-use-after-scope (worked with GCC 6, fails with GCC 7)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81023 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Martin Liška --- Dup. *** This bug has been marked as a duplicate of bug 81021 ***
[Bug sanitizer/81021] stack-use-after-scope false positive error with exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81021 Martin Liška changed: What|Removed |Added CC||d.frey at gmx dot de --- Comment #3 from Martin Liška --- *** Bug 81023 has been marked as a duplicate of this bug. ***
[Bug target/81072] [avr] Support some XMEGA devices with flash seen in RAM address space.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81072 Georg-Johann Lay changed: What|Removed |Added Target Milestone|--- |8.0
[Bug target/81072] [avr] Support some XMEGA devices with flash seen in RAM address space.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81072 Georg-Johann Lay changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Georg-Johann Lay --- Added in v8 and will need https://sourceware.org/bugzilla/show_bug.cgi?id=21472 for configure to pass.
[Bug target/81072] [avr] Support some XMEGA devices with flash seen in RAM address space.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81072 --- Comment #1 from Georg-Johann Lay --- Author: gjl Date: Mon Jun 12 12:52:30 2017 New Revision: 249124 URL: https://gcc.gnu.org/viewcvs?rev=249124&root=gcc&view=rev Log: gcc/ Support multilibs and devices that see flash in RAM address range. PR target/81072 * config/avr/avr-arch.h (avr_arch_id) : New enum. (avr_mcu_t) : New field. (avr_device_specific_features) : New enum. * config/avr/avr.h (AVR_SHORT_CALLS): New define. (AVR_HAVE_JMP_CALL): Don't set if AVR_SHORT_CALLS. (AVR_TINY_PM_OFFSET): Remove macro. * config/avr/avr.opt (-mshort-calls): New option. * config/avr/gen-avr-mmcu-specs.c (print_mcu) [*self_spec]: Add / remove -mshort-calls depending on AVR_ISA_RCALL. * config/avr/avr-c.c (avr_cpu_cpp_builtins) <__AVR_SHORT_CALLS__>: Built-in define if AVR_SHORT_CALLS. <__AVR_HAVE_JMP_CALL__>: Use AVR_HAVE_JMP_CALL as condition instead of avr_arch->have_jmp_call. <__AVR_PM_BASE_ADDRESS__>: Built-in define if avr_arch->flash_pm_offset. [AVR_TINY] <__AVR_TINY_PM_BASE_ADDRESS__>: Use avr_arch->flash_pm_offset to define. * config/avr/avr-devices.c (avr_arch_types): Add initializers for new field flash_pm_offset. Add entry for avrxmega3. (avr_texinfo): Add entry for avrxmega3. * config/avr/avr-mcus.def: Add entries for: avrxmega3, attiny212, attiny214, attiny412, attiny414, attiny416, attiny417, attiny814, attiny816, attiny817, attiny1614, attiny1616, attiny1617, attiny3214, attiny3216, attiny3217. * config/avr/avr.c (avr_assemble_integer)[AVR_TINY]: Use avr_arch->flash_pm_offset instead of AVR_TINY_PM_OFFSET. (avr_print_operand_address) [AVR_TINY]: Same. (avr_asm_init_sections) : Only patch callback if avr_arch->flash_pm_offset = 0. (avr_asm_named_section) : Skip setting it for rodata if avr_arch->flash_pm_offset != 0. (avr_encode_section_info) [AVR_TINY]: Adjust comment. * config/avr/genmultilib.awk (dir_rcall, opt_rcall): New vars. (opts) [AVR_ISA_RCALL]: Append opt_rcall. (m_options): Append opt_rcall. (m_dirnames): Append dir_rcall. * config/avr/t-multilib: Regenerate. * configure.ac [target=avr]: Check whether avrxmega3 default linker description file works as needed. * configure: Regenerate. * doc/avr-mmcu.texi: Regenerate. * doc/invoke.texi (AVR Options) <-mshort-calls>: Document it. <__AVR_ARCH__>: Document avrxmega3 and 103. <__AVR_HAVE_JMP_CALL__>: Adjust documentation. <__AVR_SHORT_CALLS__>: Document it. <__AVR_PM_BASE_ADDRESS__>: Document it. * doc/extend.texi (AVR Options) <-mshort-calls>: Document it. (AVR Variable Attributes) : Document this is not needed for avrxmega3. (AVR Named Address Spaces) <__flash>: Dito. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr-arch.h trunk/gcc/config/avr/avr-c.c trunk/gcc/config/avr/avr-devices.c trunk/gcc/config/avr/avr-mcus.def trunk/gcc/config/avr/avr.c trunk/gcc/config/avr/avr.h trunk/gcc/config/avr/avr.opt trunk/gcc/config/avr/gen-avr-mmcu-specs.c trunk/gcc/config/avr/genmultilib.awk trunk/gcc/config/avr/t-multilib trunk/gcc/configure trunk/gcc/configure.ac trunk/gcc/doc/avr-mmcu.texi trunk/gcc/doc/extend.texi trunk/gcc/doc/invoke.texi
[Bug target/81072] New: [avr] Support some XMEGA devices with flash seen in RAM address space.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81072 Bug ID: 81072 Summary: [avr] Support some XMEGA devices with flash seen in RAM address space. Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: gjl at gcc dot gnu.org Target Milestone: ---
[Bug target/81072] [avr] Support some XMEGA devices with flash seen in RAM address space.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81072 Georg-Johann Lay changed: What|Removed |Added Target||avr Priority|P3 |P4 Assignee|unassigned at gcc dot gnu.org |gjl at gcc dot gnu.org
[Bug other/80909] auto-profile.c possible mismatching parentheses in MACRO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80909 Martin Liška changed: What|Removed |Added Known to work||8.0 --- Comment #3 from Martin Liška --- Fixed on trunk.
[Bug libstdc++/81064] [8 Regression] Inline namespace regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81064 --- Comment #5 from Jonathan Wakely --- Maybe we could take this opportunity to get rid of most of the __8 namespaces and only have std::__8 and __gnu_cxx::__8, rather than std::__8 and numerous std::xxx::__8 namespaces. That would simplify the code, as the correct placement of __GLIBCXX_BEGIN_NAMESPACE_VERSION and _GLIBCXX_END_NAMESPACE_VERSION is a constant source of bugs.
[Bug libstdc++/81064] [8 Regression] Inline namespace regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81064
--- Comment #4 from Jonathan Wakely ---
We have this structure in libstdc++:
namespace std
{
inline namespace __8 { }
inline namespace literals {
inline namespace chrono_literals { inline namespace __8 { } }
inline namespace complex_literals { inline namespace __8 { } }
inline namespace string_literals { inline namespace __8 { } }
inline namespace string_view_literals { inline namespace __8 { } }
}
}
The innermost __8 namespaces conflict with std::__8 so we'll need to remove
them. Maybe we can change to:
namespace std
{
inline namespace __8 {
inline namespace literals {
inline namespace chrono_literals { }
inline namespace complex_literals { }
inline namespace string_literals { }
inline namespace string_view_literals { }
}
}
}
[Bug sanitizer/81040] asan false negative if parameter of a global function passed by reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81040 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #3 from Martin Liška --- As mentioned by Richard, currently ASAN is able to protect function variables that live on stack. In your case the function foo is called with constant that is then assigned a stack slot which we don't instrument with red zones.
[Bug libstdc++/81064] [8 Regression] Inline namespace regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81064 Nathan Sidwell changed: What|Removed |Added Keywords|rejects-valid | Status|ASSIGNED|NEW Component|c++ |libstdc++ Assignee|nathan at gcc dot gnu.org |unassigned at gcc dot gnu.org
[Bug tree-optimization/81041] [8 regression] test case gcc.dg/pr78582.c fails with ICE starting with r249058
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81041 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Martin Liška --- Fixed.
[Bug tree-optimization/81041] [8 regression] test case gcc.dg/pr78582.c fails with ICE starting with r249058
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81041 --- Comment #4 from Martin Liška --- Author: marxin Date: Mon Jun 12 11:56:32 2017 New Revision: 249120 URL: https://gcc.gnu.org/viewcvs?rev=249120&root=gcc&view=rev Log: Create an extra BB in profile-generate (PR tree-optimization/81041). 2017-06-12 Martin Liska PR tree-optimization/81041 * tree-profile.c (gimple_gen_ic_func_profiler): Create an extra BB in profile-generate (gimple_gen_time_profiler): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-profile.c
[Bug tree-optimization/81003] [8 Regression] ICE: tree check: expected ssa_name, have integer_cst in optimize_range_tests_to_bit_test, at tree-ssa-reassoc.c:2782
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81003 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Fixed.
[Bug sanitizer/81066] sanitizer_stoptheworld_linux_libcdep.cc:276:22: error: aggregate ‘sigaltstack handler_stack’ has incomplete type and cannot be defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81066 --- Comment #4 from joseph at codesourcery dot com --- Using stack_t instead of struct sigaltstack is correct. However, the type declaration should be obtained from . Nothing outside of glibc should ever include headers or define glibc's __need_* macros; those are purely implementation details, not public interfaces, and are liable to change incompatibly at any time.
[Bug bootstrap/80897] [8 regression] gnat bootstrap broken on SPARC64/Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80897 --- Comment #8 from Eric Botcazou --- Author: ebotcazou Date: Mon Jun 12 11:28:33 2017 New Revision: 249119 URL: https://gcc.gnu.org/viewcvs?rev=249119&root=gcc&view=rev Log: PR bootstrap/80897 * exp_ch3.adb (Make_Predefined_Primitive_Specs): Use Positive index. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/exp_ch3.adb
[Bug c++/81060] [8 Regression] ICE with un-expanded parameter pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81060 Nathan Sidwell changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org
[Bug c++/81064] [8 Regression] Inline namespace regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81064
Nathan Sidwell changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #3 from Nathan Sidwell ---
Thanks for the reduced testcase. This is caused by:
2017-05-26 Nathan Sidwell
Implement DR2061
* name-lookup.c (push_inline_namespaces): New.
(push_namespace): Look inside inline namespaces.
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#2061
I think I've implemented it correctly, and that the testcase is ill-formed.
Perhaps we could check whenever creating a new namepace that it doesn't cause
an ambiguity within the 'local' inline namespace tree. (though, such an
ambiguity could occur on declaring any new name, not just a namespace).
2061. Inline namespace after simplifications
Section: 7.3.1 [namespace.def] Status: CD4 Submitter: Richard Smith
Date: 2014-12-18
[Adopted at the February, 2016 meeting.]
After the resolution of issue 1795, 7.3.1 [namespace.def] paragraph 3 now says:
In a named-namespace-definition, the identifier is the name of the
namespace. If the identifier, when looked up (3.4.1 [basic.lookup.unqual]),
refers to a namespace-name (but not a namespace-alias) introduced in the
declarative region in which the named-namespace-definition appears, the
namespace-definition extends the previously-declared namespace. Otherwise, the
identifier is introduced as a namespace-name into the declarative region in
which the named-namespace-definition appears.
This appears to break code like the following:
namespace A {
inline namespace b {
namespace C {
template void f();
}
}
}
namespace A {
namespace C {
template<> void f() { }
}
}
because (by definition of “declarative region”) C cannot be used as an
unqualified name to refer to A::b::C within A if its declarative region is
A::b.
Proposed resolution (September, 2015):
Change 7.3.1 [namespace.def] paragraph 3 as follows:
In a named-namespace-definition, the identifier is the name of the
namespace. If the identifier, when looked up (3.4.1 [basic.lookup.unqual]),
refers to a namespace-name (but not a namespace-alias) that was introduced in
the declarative region namespace in which the named-namespace-definition
appears or that was introduced in a member of the inline namespace set of that
namespace, the namespace-definition extends the previously-declared namespace.
Otherwise, the identifier is introduced as a namespace-name into the
declarative region in which the named-namespace-definition appears.
[Bug c/81071] New: __builtin_ia32_movddup has been dropped on 4.8 -> 4.9 release transition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81071 Bug ID: 81071 Summary: __builtin_ia32_movddup has been dropped on 4.8 -> 4.9 release transition Product: gcc Version: 4.9.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: oder at eleks dot com Target Milestone: --- x86 SSE3 built-in function v2df __builtin_ia32_movddup(v2df) has disappeared with 4.9 releases. Also, as of 5.4 release (MinGW) another function - __builtin_ia32_loadss() - is still in manuals but the compiler does not recognize it.
[Bug ada/81070] [7/8 Regression] build failure for s-intrr.adb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81070 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Eric Botcazou --- .
[Bug ada/81070] [7/8 Regression] build failure for s-intrr.adb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81070
--- Comment #5 from Eric Botcazou ---
Author: ebotcazou
Date: Mon Jun 12 10:49:17 2017
New Revision: 249116
URL: https://gcc.gnu.org/viewcvs?rev=249116&root=gcc&view=rev
Log:
PR ada/81070
* s-interr-hwint.adb: Reinstate.
* gcc-interface/Makefile.in (RTEMS): Use it again.
Added:
branches/gcc-7-branch/gcc/ada/s-interr-hwint.adb (props changed)
- copied unchanged from r249112,
branches/gcc-6-branch/gcc/ada/s-interr-hwint.adb
Modified:
branches/gcc-7-branch/gcc/ada/ChangeLog
branches/gcc-7-branch/gcc/ada/gcc-interface/Makefile.in
Propchange: branches/gcc-7-branch/gcc/ada/s-interr-hwint.adb
('svn:mergeinfo' added)
[Bug ada/81070] [7/8 Regression] build failure for s-intrr.adb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81070
--- Comment #4 from Eric Botcazou ---
Author: ebotcazou
Date: Mon Jun 12 10:47:36 2017
New Revision: 249115
URL: https://gcc.gnu.org/viewcvs?rev=249115&root=gcc&view=rev
Log:
PR ada/81070
* s-interr-hwint.adb: Reinstate.
* gcc-interface/Makefile.in (RTEMS): Use it again.
Added:
trunk/gcc/ada/s-interr-hwint.adb (props changed)
- copied unchanged from r249113,
branches/gcc-6-branch/gcc/ada/s-interr-hwint.adb
Modified:
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/gcc-interface/Makefile.in
Propchange: trunk/gcc/ada/s-interr-hwint.adb
('svn:mergeinfo' added)
[Bug tree-optimization/81003] [8 Regression] ICE: tree check: expected ssa_name, have integer_cst in optimize_range_tests_to_bit_test, at tree-ssa-reassoc.c:2782
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81003 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Mon Jun 12 10:45:52 2017 New Revision: 249114 URL: https://gcc.gnu.org/viewcvs?rev=249114&root=gcc&view=rev Log: PR tree-optimization/81003 * tree-ssa-reassoc.c (force_into_ssa_name): New function. (update_range_test): Use it instead of force_gimple_operand_gsi. * gcc.c-torture/compile/pr81003.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr81003.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-reassoc.c
[Bug tree-optimization/66623] Unsafe FP math reduction used in strict math mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66623 Bug 66623 depends on bug 81053, which changed state. Bug 81053 Summary: ICE on valid code at -O3 on x86_64-linux-gnu: in as_a, at is-a.h:192 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81053 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/81053] ICE on valid code at -O3 on x86_64-linux-gnu: in as_a, at is-a.h:192
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81053 --- Comment #5 from Richard Biener --- Author: rguenth Date: Mon Jun 12 10:42:57 2017 New Revision: 249113 URL: https://gcc.gnu.org/viewcvs?rev=249113&root=gcc&view=rev Log: 2017-06-12 Richard Biener PR tree-optimization/81053 * tree-vect-loop.c (vect_is_simple_reduction): Handle PHI with backedge value not defined in loop. Simplify def stmt compute. * gcc.dg/torture/pr81053.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr81053.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-loop.c
[Bug tree-optimization/81053] ICE on valid code at -O3 on x86_64-linux-gnu: in as_a, at is-a.h:192
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81053 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Richard Biener --- Fixed.
[Bug ada/81070] [7/8 Regression] build failure for s-intrr.adb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81070 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #3 from Eric Botcazou --- Fixing.
[Bug ada/81070] [7/8 Regression] build failure for s-intrr.adb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81070 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-06-12 CC||ebotcazou at gcc dot gnu.org Summary|[7/8 Regression] Cannot |[7/8 Regression] build |build s-intrr.adb |failure for s-intrr.adb Ever confirmed|0 |1
[Bug ada/81070] [7/8 Regression] Cannot build s-intrr.adb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81070 --- Comment #2 from Eric Botcazou --- Introduced by: 2016-10-13 Ed Falis * i-vxinco.adb, i-vxinco.ads: New files. * impunit.adb: add i-vxinco.ads. * s-interr-vxworks.adb: add hook for user interrupt connection routine. 2016-10-13 Ed Falis * s-interr-hwint.adb, s-interr-vxworks.adb: Rename s-interr-hwint.adb to s-interr-vxworks.adb.
[Bug ada/81070] [7/8 Regression] Cannot build s-intrr.adb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81070 Richard Biener changed: What|Removed |Added Keywords||build Priority|P3 |P4 Target Milestone|--- |7.2 Summary|Cannot build s-intrr.adb|[7/8 Regression] Cannot ||build s-intrr.adb
[Bug testsuite/80759] gcc.target/x86_64/abi/ms-sysv FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80759 --- Comment #34 from ro at CeBiTec dot Uni-Bielefeld.DE --- One more data point: I tried to run the ms-sysv.exp tests on x86_64-apple-darwin and failed initially: FAIL: gcc.target/x86_64/abi/ms-sysv/ms-sysv.c -O2 "-DGEN_ARGS=-p0" (test for excess errors) Excess errors: /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/ms-sysv.c:168:Unknown pseudo-op: .global /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/ms-sysv.c:168:Rest of line ignored. 1st junk character valued 100 (d). /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/do-test.S:51:Unknown pseudo-op: .global /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/do-test.S:51:Rest of line ignored. 1st junk character valued 114 (r). /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/do-test.S:73:Unknown pseudo-op: .global /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/do-test.S:73:Rest of line ignored. 1st junk character valued 109 (m). /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/do-test.S:96:Unknown pseudo-op: .global /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/do-test.S:96:Rest of line ignored. 1st junk character valued 100 (d). /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/do-test.S:97:Unknown pseudo-op: .cfi_startproc /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/do-test.S:107:Unknown pseudo-op: .global /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/do-test.S:107:Rest of line ignored. 1st junk character valued 100 (d). /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/do-test.S:116:Unknown pseudo-op: .cfi_endproc There are two issues here: while gas understands .global, the Darwin as does not. However, globl is common to both (as can e.g. be seen in libffi/src/x86/sysv.S), so using it makes the test more portable. The .cfi_* pseudo-ops are another matter: the same file has this comment /* Sadly, OSX cctools-as doesn't understand .cfi directives at all. */ so if frame info is really necessary, it would have to be hand-coded as in those files. It seems that it's not, though: just commenting .cfi_startproc and .cfi_endproc still lets the tests still PASS on x86_64-pc-linux-gnu. Older Solaris/x86 assemblers have the same issue, btw. I cannot right now test the patched tests on Darwin, but will have to do so later tonight at home. Rainer diff --git a/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/do-test.S b/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/do-test.S --- a/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/do-test.S +++ b/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/do-test.S @@ -34,7 +34,7 @@ see the files COPYING3 and COPYING.RUNTI # endif # define FUNC(fn) \ - .global fn; \ + .globl fn; \ ELFFN_BEGIN(fn);\ fn: @@ -94,7 +94,7 @@ FUNC_END(mem_to_regs) # NOTE: Not MT safe FUNC(do_test_unaligned) - .cfi_startproc + #.cfi_startproc # The below alignment checks are to verify correctness of the test # its self. @@ -113,7 +113,7 @@ FUNC(do_test_aligned) L0: popf jmp do_test_body -.cfi_endproc +#.cfi_endproc FUNC_END(do_test_aligned) FUNC_END(do_test_unaligned) diff --git a/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/ms-sysv.c b/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/ms-sysv.c --- a/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/ms-sysv.c +++ b/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/ms-sysv.c @@ -156,7 +156,7 @@ static const char *argv0; #endif #define FUNC_BEGIN(fn) \ - " .global " fn "\n" \ + " .globl " fn "\n"\ ELFFN_BEGIN(fn) \ fn ":\n" #define FUNC_END(fn) ELFFN_END(fn)
[Bug c++/81045] [7/8 Regression] return type deduction causes dependent types?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81045 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-06-12 Ever confirmed|0 |1
[Bug c++/81064] [8 Regression] Inline namespace regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81064
--- Comment #2 from Jonathan Wakely ---
EDG warns for that code:
"ns.cc", line 9: warning: a redeclaration of inline namespace "n1::in" must be
declared inline
namespace in { }
^
But trunk still rejects it even with that change:
namespace n1 {
inline namespace in { }
inline namespace n2 {
inline namespace in { }
}
}
namespace n1 {
inline namespace in { }
}
ns.cc:9:20: error: conflicting declaration of namespace ‘n1::in’
inline namespace in { }
^~
ns.cc:2:20: note: previous declaration of namespace ‘n1::in’ here
inline namespace in { }
^~
[Bug c++/81064] [8 Regression] Inline namespace regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81064
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2017-06-12
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely ---
Confirmed:
namespace n1 {
inline namespace in { }
inline namespace n2 {
inline namespace in { }
}
}
namespace n1 {
namespace in { }
}
ns.cc:9:13: error: conflicting declaration of namespace ‘n1::in’
namespace in { }
^~
ns.cc:2:20: note: previous declaration of namespace ‘n1::in’ here
inline namespace in { }
^~
Aside: do we really want to translate "namespace" in diagnostics?
[Bug c++/81067] [8 regression] g++.dg/template/nontype10.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81067 Renlin Li changed: What|Removed |Added CC||renlin at gcc dot gnu.org --- Comment #1 from Renlin Li --- I confirm I noticed the same regressions on arm targets.
[Bug ada/81070] Cannot build s-intrr.adb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81070 --- Comment #1 from Sebastian Huber --- The native GNAT is: gnat --version GNAT 7.1.1 20170530 [gcc-7-branch revision 248621]
[Bug ada/81070] New: Cannot build s-intrr.adb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81070 Bug ID: 81070 Summary: Cannot build s-intrr.adb Product: gcc Version: 7.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: sebastian.hu...@embedded-brains.de Target Milestone: --- On GCC 7.1 branch (34df49547806512c6e1549a58048f161f5fa42bc) I get the following error while building the Ada run-time support: make[5]: 's-inmaop.o' is up to date. /build/git-build/b-gcc-git-arm-rtems4.12/./gcc/xgcc -B/build/git-build/b-gcc-git-arm-rtems4.12/./gcc/ -nostdinc -B/build/git-build/b-gcc-git-arm-rtems4.12/arm-rtems4.12/newlib/ -isystem /build/git-build/b-gcc-git-arm-rtems4.12/arm-rtems4.12/newlib/targ-include -isystem /home/EB/sebastian_h/archive/gcc-git/newlib/libc/include -B/opt/rtems-4.12/arm-rtems4.12/bin/ -B/opt/rtems-4.12/arm-rtems4.12/lib/ -isystem /opt/rtems-4.12/arm-rtems4.12/include -isystem /opt/rtems-4.12/arm-rtems4.12/sys-include-c -g -O2 -W -Wall -gnatpg -nostdinc s-interr.adb -o s-interr.o s-interr.adb:206:06: subprogram "Interrupt_Connect" has wrong convention s-interr.adb:206:06: does not match "Interrupt_Connector" declared at line 199 s-interr.adb:206:06: probable missing pragma Convention for "Interrupt_Connector" ../gcc-interface/Makefile:296: recipe for target 's-interr.o' failed make[5]: *** [s-interr.o] Error 1 make[5]: Leaving directory '/build/git-build/b-gcc-git-arm-rtems4.12/gcc/ada/rts' gcc-interface/Makefile:2791: recipe for target 'gnatlib' failed make[4]: *** [gnatlib] Error 2 Configure command line: configure --target=arm-rtems4.12 --with-newlib --disable-nls --disable-lto --disable-plugin --enable-languages=c,c++,ada
[Bug libstdc++/81056] [7/8 Regression] FAIL: 17_intro/names.cc (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81056
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2017-06-12
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely ---
(In reply to John David Anglin from comment #0)
> These errors are caused by following header issues on hpux:
>
> /mnt/gnu/gcc/objdir/./gcc/include-fixed/sys/types.h:
>typedef struct _physadr { intptr_t r[1]; } *physadr;
>
> /mnt/gnu/gcc/objdir/./gcc/include-fixed/stdlib.h:
> _NAMESPACE_STD_START
> inline int abs(int d) { return (d>0)?d:-d; }
> _NAMESPACE_STD_END
>
> Probably, the use of `r' and `d' in the above circumstances is not a
> problem. So, I think the test should be adjusted as on AIX. See attached
> fix.
It's a problem because it means some valid C++ programs that include
won't compile, but only programs that use 'r' and 'd' as macros, which is
insane. So simply adjusting the test is fine.
The patch is OK for trunk - thanks.
[Bug c++/81047] thread local storage static class members of class type cannot be initialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81047 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Jonathan Wakely --- https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b98-Thread-Local-Edits.html > The storage for an object of thread storage duration shall be statically > initialized before the first statement of the thread startup function. An > object of thread storage duration shall not require dynamic initialization. So you can't use __thread for objects that require dynamic initialization. (In reply to Jason Vas Dias from comment #0) > Incidentally, the error is very confusing - it first claims that it > is an error to attempt to initialize the TLS variable dynamically, and > then issues a 'note:' that C++11 supports dynamic initialization of > TLS objects - but it doesn't ? Yes it does, but __thread is not part of C++11. thread_local is part of C++11, and supports what you're trying to do. __thread and thread_local are not the same thing.
[Bug target/81069] New: nvptx offloading: "-O1" execution test of "libgomp.oacc-fortran/nested-function-1.f90" timeout/FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81069 Bug ID: 81069 Summary: nvptx offloading: "-O1" execution test of "libgomp.oacc-fortran/nested-function-1.f90" timeout/FAIL Product: gcc Version: 7.0 Status: UNCONFIRMED Keywords: openacc Severity: major Priority: P3 Component: target Assignee: tschwinge at gcc dot gnu.org Reporter: tschwinge at gcc dot gnu.org Target Milestone: --- Merging trunk r239357 (part of the PR72772 "Missed SCEV after pass reordering@236440" changes) into gomp-4-branch r240825, there is a regression with nvptx offloading, such that (only) the "-O1" execution test of "libgomp.oacc-fortran/nested-function-1.f90" FAILs, running into a "WARNING: program timed out".
[Bug testsuite/80759] gcc.target/x86_64/abi/ms-sysv FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80759 --- Comment #33 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #32 from Daniel Santos --- > Created attachment 41533 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41533&action=edit > 41532: proposed fix v5 I've given this one a whirl (with Solaris/x86 /bin/as only so far), and we're getting closer: right now, the only ms-sysv tests failing are FAIL: gcc.target/x86_64/abi/ms-sysv/ms-sysv.c -mcall-ms2sysv-xlogues -O0 -g3 "-DGEN_ARGS=-p0\ --omit-rbp-clobbers" (test for excess errors) FAIL: gcc.target/x86_64/abi/ms-sysv/ms-sysv.c -mcall-ms2sysv-xlogues -O0 -g3 "-DGEN_ARGS=-p1\ --omit-rbp-clobbers" (test for excess errors) FAIL: gcc.target/x86_64/abi/ms-sysv/ms-sysv.c -mcall-ms2sysv-xlogues -O0 -g3 "-DGEN_ARGS=-p5\ --omit-rbp-clobbers" (test for excess errors) FAIL: gcc.target/x86_64/abi/ms-sysv/ms-sysv.c -mcall-ms2sysv-xlogues -O2 "-DGEN_ARGS=-p0\ --omit-rbp-clobbers" (test for excess errors) FAIL: gcc.target/x86_64/abi/ms-sysv/ms-sysv.c -mcall-ms2sysv-xlogues -O2 "-DGEN_ARGS=-p1\ --omit-rbp-clobbers" (test for excess errors) FAIL: gcc.target/x86_64/abi/ms-sysv/ms-sysv.c -mcall-ms2sysv-xlogues -O2 "-DGEN_ARGS=-p5\ --omit-rbp-clobbers" (test for excess errors) In all cases, I get link errors: Excess errors: Undefined first referenced symbol in file __resms64f_12 /var/tmp//ccRVJueb.o __resms64f_13 /var/tmp//ccRVJueb.o __resms64f_14 /var/tmp//ccRVJueb.o __resms64f_15 /var/tmp//ccRVJueb.o __resms64f_16 /var/tmp//ccRVJueb.o __resms64f_17 /var/tmp//ccRVJueb.o __savms64f_12 /var/tmp//ccRVJueb.o __savms64f_13 /var/tmp//ccRVJueb.o __savms64f_14 /var/tmp//ccRVJueb.o __savms64f_15 /var/tmp//ccRVJueb.o __savms64f_16 /var/tmp//ccRVJueb.o __savms64f_17 /var/tmp//ccRVJueb.o __resms64fx_12 /var/tmp//ccRVJueb.o __resms64fx_13 /var/tmp//ccRVJueb.o __resms64fx_14 /var/tmp//ccRVJueb.o __resms64fx_15 /var/tmp//ccRVJueb.o __resms64fx_16 /var/tmp//ccRVJueb.o __resms64fx_17 /var/tmp//ccRVJueb.o ld: fatal: symbol referencing errors Rainer
[Bug sanitizer/81068] New: Sanitizer memory leak in codecvt_utf8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81068
Bug ID: 81068
Summary: Sanitizer memory leak in codecvt_utf8
Product: gcc
Version: 5.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: piotr.stachura at delphi dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
Simple string conversion application compiled with -fsanitize=undefined results
in runtime_error and memory leak.
Code:
--
#include
#include
#include
int main()
{
const uint8_t input_data[] = { 0x22, 0x44, 0xC2, 0x80, 0xC5, 0x96, 0xCD,
0x8B };
std::wstring_convert, char16_t> converter;
std::u16string output_string = converter.from_bytes((const
char*)&input_data[0], (const char*)&input_data[7]);
return 0;
}
--
Compilation command:
g++ -fsanitize=address -fsanitize=undefined -std=c++11 1.cpp -o 1
Run results:
/usr/include/c++/5/bits/locale_conv.h:68:48: runtime error: member call on
address 0x6030efe0 which does not point to an object of type
'__codecvt_abstract_base'
0x6030efe0: note: object is of type 'std::codecvt_utf8'
01 00 80 21 20 3b b7 eb 54 56 00 00 00 00 00 00 be be be be ff ff 10 00 00
00 00 00 00 00 00 00
^~~
vptr for 'std::codecvt_utf8'
/usr/include/c++/5/bits/codecvt.h:220:36: runtime error: member call on address
0x6030efe0 which does not point to an object of type
'__codecvt_abstract_base'
0x6030efe0: note: object is of type 'std::codecvt_utf8'
01 00 80 21 20 3b b7 eb 54 56 00 00 00 00 00 00 be be be be ff ff 10 00 00
00 00 00 00 00 00 00
^~~
vptr for 'std::codecvt_utf8'
/usr/include/c++/5/bits/codecvt.h:202:32: runtime error: member call on address
0x6030efe0 which does not point to an object of type
'__codecvt_abstract_base'
0x6030efe0: note: object is of type 'std::codecvt_utf8'
01 00 80 21 20 3b b7 eb 54 56 00 00 00 00 00 00 be be be be ff ff 10 00 00
00 00 00 00 00 00 00
^~~
vptr for 'std::codecvt_utf8'
=
==7612==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 384 byte(s) in 6 object(s) allocated from:
#0 0x7fe5ef1ac911 in realloc
(/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98911)
#1 0x7fe5eee1e093 (/usr/lib/x86_64-linux-gnu/libstdc++.so.6+0x92093)
SUMMARY: AddressSanitizer: 384 byte(s) leaked in 6 allocation(s).
Notes:
- issue also visible on gcc 6.2.0
- without -fsanitize=undefined, no errors and no memory leak.
[Bug sanitizer/81065] UBSAN: false positive as a result of distribution involving different types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81065 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- Oh, and I think it's fine to always distribute CST * (x * CST1 + CST2) in case x * CST1 and CST2 have the same sign. So the previous fix was incomplete and we now hit /* If we were able to eliminate our operation from the first side, apply our operation to the second side and reform the PLUS. */ if (t1 != 0 && (TREE_CODE (t1) != code || code == MULT_EXPR)) return fold_build2 (tcode, ctype, fold_convert (ctype, t1), op1); where the code immediately following it is correct: /* The last case is if we are a multiply. In that case, we can apply the distributive law to commute the multiply and addition if the multiplication of the constants doesn't overflow and overflow is defined. With undefined overflow op0 * c might overflow, while (op0 + orig_op1) * c doesn't. */ if (code == MULT_EXPR && TYPE_OVERFLOW_WRAPS (ctype)) return fold_build2 (tcode, ctype, fold_build2 (code, ctype, fold_convert (ctype, op0), fold_convert (ctype, c)), op1); Mine. Testing Index: gcc/fold-const.c === --- gcc/fold-const.c(revision 249112) +++ gcc/fold-const.c(working copy) @@ -6243,7 +6243,7 @@ extract_muldiv_1 (tree t, tree c, enum t /* If we were able to eliminate our operation from the first side, apply our operation to the second side and reform the PLUS. */ - if (t1 != 0 && (TREE_CODE (t1) != code || code == MULT_EXPR)) + if (t1 != 0 && TREE_CODE (t1) != code) return fold_build2 (tcode, ctype, fold_convert (ctype, t1), op1); /* The last case is if we are a multiply. In that case, we can
[Bug c++/81067] New: [8 regression] g++.dg/template/nontype10.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81067 Bug ID: 81067 Summary: [8 regression] g++.dg/template/nontype10.C FAILs Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: jason at gcc dot gnu.org Target Milestone: --- Between 20170609 (r249050) and 20170610 (r249098), the g++.dg/template/nontype10.C testcase started to regress: FAIL: g++.dg/template/nontype10.C -std=c++11 (test for excess errors) FAIL: g++.dg/template/nontype10.C -std=c++14 (test for excess errors) FAIL: g++.dg/template/nontype10.C -std=c++98 (test for excess errors) I'm seeing it on i386-pc-solaris2.12 and sparc-sun-solaris2.12 (32-bit only), but according to gcc-testresults many more targets are affected. Excess errors: /vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/template/nontype10.C:5:28: warning: converting to non-pointer type 'int' from NULL [-Wconversion-null] /vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/template/nontype10.C:5:28: warning: converting to non-pointer type 'int' from NULL [-Wconversion-null] /vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/template/nontype10.C:5:28: warning: converting to non-pointer type 'int' from NULL [-Wconversion-null] The warning moved from l.8, where it's expected, to l.5. Rainer
[Bug c++/81067] [8 regression] g++.dg/template/nontype10.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81067 Rainer Orth changed: What|Removed |Added Target Milestone|--- |8.0
[Bug sanitizer/81065] UBSAN: false positive as a result of distribution involving different types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81065
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Status|UNCONFIRMED |NEW
Last reconfirmed||2017-06-12
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
Thanks for reporting these bugs, they are all latent wrong-code even w/o UBSAN.
.original w/o ubsan:
;; Function foo (null)
;; enabled by -tree-original
{
return (int) x * 14165900 + -77663775;
}
and as usual, it's extract_muldiv ...
(gdb) p debug_generic_expr (op0)
(int) x * 1652 + -9057
$1 = void
(gdb) p debug_generic_expr (op1)
8575
turning that into
(int) x * 14165900 + -77663775
it really means that this kind of distribution is never safe unless we rewrite
the inner multiplication into unsigned arithmetic (given the cast of x we
do have an idea about the value range of the other operand so we could
handle some cases -- but I'd rather not do that in extract_muldiv but
in a match.pd pattern).
I'd love to say bye-bye to extract_muldiv in it's current state...
[Bug sanitizer/81040] asan false negative if parameter of a global function passed by reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81040 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-06-12 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- (In reply to Richard Biener from comment #1) > Likely instrumentation simply is missing > >goo((int*)&a); > > given 'a' lives on the stack. With static foo and IPA CP applied it > eventually > sees a address-taken constant pool reference. Yes, with -O2 and static function, const prop creates clone of foo, where variable 'a' lives on stack. Write in goo is checked, but it points to a valid shadow memory (stack). I'm investigating more.
[Bug c++/81064] [8 Regression] Inline namespace regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81064 Richard Biener changed: What|Removed |Added Keywords||rejects-valid Target Milestone|--- |8.0 Summary|Inline namespace regression |[8 Regression] Inline ||namespace regression
[Bug c++/81061] [7/8 Regression] ICE modifying read-only variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81061 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |7.2
[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556 --- Comment #42 from ro at CeBiTec dot Uni-Bielefeld.DE --- Just for the record: at r249012 (i.e. before the patches causing PR bootstrap/81033), I managed to successfully bootstrap x86_64-apple-darwin16.6.0, x86_64-apple-darwin11.4.2, and i386-apple-darwin11.4.2. Thanks. Rainer
[Bug c++/81060] [8 Regression] ICE with un-expanded parameter pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81060 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |8.0
[Bug c++/81057] [5/6/7/8 Regression] ICE with broken default template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81057 Richard Biener changed: What|Removed |Added Keywords||error-recovery Priority|P3 |P4 Target Milestone|--- |5.5
[Bug c++/81055] [5/6/7/8 Regression] ICE with invalid initializer for array new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81055 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |5.5
[Bug libstdc++/81056] [7/8 Regression] FAIL: 17_intro/names.cc (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81056 Richard Biener changed: What|Removed |Added Target Milestone|--- |7.2 Summary|[7,8 Regression] FAIL: |[7/8 Regression] FAIL: |17_intro/names.cc (test for |17_intro/names.cc (test for |excess errors) |excess errors)
[Bug c++/81054] [7/8 Regression] ICE with volatile variable in constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81054 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |7.2
[Bug c++/81051] lambda capture of this in initialization list with virtual inheritance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81051 Richard Biener changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2017-06-12 Ever confirmed|0 |1 Known to fail||7.1.1, 8.0 --- Comment #1 from Richard Biener --- Confirmed.
[Bug fortran/81048] [6/7/8 Regression] incorrect derived type initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81048 Richard Biener changed: What|Removed |Added Target Milestone|--- |6.4
[Bug c++/81045] [7/8 Regression] return type deduction causes dependent types?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81045 Richard Biener changed: What|Removed |Added Keywords||rejects-valid Target Milestone|--- |7.2 Summary|[7 Regression] return type |[7/8 Regression] return |deduction causes dependent |type deduction causes |types? |dependent types?
[Bug middle-end/81046] [8 Regression] FAIL: gcc.dg/pr28796-2.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81046 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.0
