Re: gdb doesn't get argc right
* Don Viszneki: > I'm using standard Ubuntu releases of gcc (5.4.0) and gdb (7.11.1) and I > have a very simple to reproduce issue on x86-64. > > I think I've included all the necessary information in this paste: > > https://gist.github.com/hdon/3f96a8a6b67e078e0213660ec6245677 This is likely a limitation of the debugging information format you requested, which cannot represent some of the optimizations GCC performed on the object code. (I'm not sure how many people read the gcc-bugs mailing list. It's usually used to distribute notifications from Bugzilla, the bug tracking tool.)
[Bug tree-optimization/80443] [7 Regression] ICE on valid code at -O2 on x86_64-linux-gnu: in set_value_range, at tree-vrp.c:367
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80443 Marc Glisse changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2017-04-17 Version|unknown |7.0.1 Summary|ICE on valid code at -O2 on |[7 Regression] ICE on valid |x86_64-linux-gnu: in|code at -O2 on |set_value_range, at |x86_64-linux-gnu: in |tree-vrp.c:367 |set_value_range, at ||tree-vrp.c:367 Ever confirmed|0 |1 --- Comment #1 from Marc Glisse --- Something to do with the handling of overflow in VRP?
[Bug sanitizer/80444] New: -fcompare-debug failures with -fsanitize-coverage=trace-pc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80444
Bug ID: 80444
Summary: -fcompare-debug failures with
-fsanitize-coverage=trace-pc
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: trippels at gcc dot gnu.org
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
Target Milestone: ---
% cat system_keyring.i
void foo() {
int a = 0;
}
% gcc --save-temps -fcompare-debug -O2 -fsanitize-coverage=trace-pc -c
system_keyring.i
gcc: error: system_keyring.i: -fcompare-debug failure
% diff -u system_keyring.gkd system_keyring.gk.gkd
--- system_keyring.gkd 2017-04-17 12:07:15.192708236 +0200
+++ system_keyring.gk.gkd 2017-04-17 12:07:15.216708050 +0200
@@ -9,7 +9,7 @@
(note # 0 0 NOTE_INSN_PROLOGUE_END)
(note # 0 0 NOTE_INSN_FUNCTION_BEG)
(call_insn/j:TI # 0 0 2 (call (mem:QI (symbol_ref:DI
("__sanitizer_cov_trace_pc") [flags 0x41] ) [ __builtin___sanitizer_cov_trace_pc S1
A8])
-(const_int 0 [0])) "system_keyring.i":3# {*sibcall}
+(const_int 0 [0])) "system_keyring.i":2# {*sibcall}
(expr_list:REG_CALL_DECL (symbol_ref:DI ("__sanitizer_cov_trace_pc")
[flags 0x41] )
(expr_list:REG_EH_REGION (const_int 0 [0])
(nil)))
[Bug tree-optimization/80426] [7 Regression] Wrong constant folding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80426 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #4 from Eric Botcazou --- This looks related to PR tree-opt/79666. Investigating.
[Bug c++/80445] New: /usr/include/c++/6.3.1/cstdio:124:11: error: ‘::gets’ has not been declared using ::gets;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80445 Bug ID: 80445 Summary: /usr/include/c++/6.3.1/cstdio:124:11: error: ‘::gets’ has not been declaredusing ::gets; Product: gcc Version: 6.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: anton.kochkov at gmail dot com Target Milestone: --- In file included from /usr/include/c++/6.3.1/ext/string_conversions.h:43:0, from /usr/include/c++/6.3.1/bits/basic_string.h:5402, from /usr/include/c++/6.3.1/string:52, from /usr/include/qt5/QtCore/qbytearray.h:52, from /usr/include/qt5/QtCore/qstring.h:49, from /usr/include/qt5/QtCore/qobject.h:47, from /usr/include/qt5/QtCore/qabstractanimation.h:43, from /usr/include/qt5/QtCore/QtCore:4, from /usr/include/qt5/QtGui/QtGuiDepends:3, from /usr/include/qt5/QtGui/QtGui:3, /usr/include/c++/6.3.1/cstdio: At global scope: /usr/include/c++/6.3.1/cstdio:124:11: error: ‘::gets’ has not been declared using ::gets; ^~~~ /usr/include/c++/6.3.1/cstdio:137:11: error: ‘::sprintf’ has not been declared using ::sprintf; ^~~ /usr/include/c++/6.3.1/cstdio:175:11: error: ‘::snprintf’ has not been declared using ::snprintf; ^~~~ /usr/include/c++/6.3.1/cstdio:185:22: error: ‘__gnu_cxx::snprintf’ has not been declared using ::__gnu_cxx::snprintf; ^~~~
[Bug c++/80445] /usr/include/c++/6.3.1/cstdio:124:11: error: ‘::gets’ has not been declared using ::gets;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80445 --- Comment #1 from Anton Kochkov --- Forgot to mention command line: g++ -c -pipe -m32 -O2 -std=gnu++11 -D_REENTRANT -Wall -W -fPIC -D__IDP__ -D__QT__ -D__EA64__ -D__LINUX__ -DQT_NO_DEBUG -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -I. -I../../ida-6.95-sdk/include -isystem /usr/include/qt5 -isystem /usr/include/qt5/QtWidgets -isystem /usr/include/qt5/QtGui -isystem /usr/include/qt5/QtCore -I. -I/usr/lib64/qt5/mkspecs/linux-g++ -o p64/collabreate.o collabreate.cpp
[Bug c++/80445] /usr/include/c++/6.3.1/cstdio:124:11: error: ‘::gets’ has not been declared using ::gets;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80445 Markus Trippelsdorf changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #2 from Markus Trippelsdorf --- Almost certainly not a gcc bug. Please attach collabreate.ii.
[Bug c++/80445] /usr/include/c++/6.3.1/cstdio:124:11: error: ‘::gets’ has not been declared using ::gets;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80445
--- Comment #3 from Markus Trippelsdorf ---
(In reply to Markus Trippelsdorf from comment #2)
> Almost certainly not a gcc bug.
QT must be doing something weird like:
namespace std {
#include
}
[Bug c++/80445] /usr/include/c++/6.3.1/cstdio:124:11: error: ‘::gets’ has not been declared using ::gets;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80445 --- Comment #4 from Anton Kochkov --- here is /usr/include/qt5/QtCore/qbytearray.h: #ifndef QBYTEARRAY_H #define QBYTEARRAY_H #include #include #include #include #include #include #include// <-- line 52 #include Seem no namespace tricks
[Bug c++/80445] /usr/include/c++/6.3.1/cstdio:124:11: error: ‘::gets’ has not been declared using ::gets;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80445 --- Comment #5 from Anton Kochkov --- Created attachment 41205 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41205&action=edit preprocessed file output of g++ -c -pipe -m32 -O2 -std=gnu++11 -D_REENTRANT -Wall -W -fPIC -D__IDP__ -D__QT__ -D__EA64__ -D__LINUX__ -DQT_NO_DEBUG -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -I. -I../../ida-6.95-sdk/include -isystem /usr/include/qt5 -isystem /usr/include/qt5/QtWidgets -isystem /usr/include/qt5/QtGui -isystem /usr/include/qt5/QtCore -I. -I/usr/lib64/qt5/mkspecs/linux-g++ -E collabreate.cpp > collabreate.ii
[Bug c++/80445] /usr/include/c++/6.3.1/cstdio:124:11: error: ‘::gets’ has not been declared using ::gets;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80445 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #6 from Markus Trippelsdorf --- Well, somewhere you'll find: #define gets dont_use_gets_ etc. This is the cause of the issue.
[Bug c++/80445] /usr/include/c++/6.3.1/cstdio:124:11: error: ‘::gets’ has not been declared using ::gets;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80445 Anton Kochkov changed: What|Removed |Added Resolution|INVALID |FIXED --- Comment #7 from Anton Kochkov --- Thanks you right, that is defined in pro.h from IDA...
[Bug c++/80445] /usr/include/c++/6.3.1/cstdio:124:11: error: ‘::gets’ has not been declared using ::gets;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80445 Markus Trippelsdorf changed: What|Removed |Added Resolution|FIXED |INVALID
[Bug c++/80445] /usr/include/c++/6.3.1/cstdio:124:11: error: ‘::gets’ has not been declared using ::gets;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80445 --- Comment #8 from graham.stott at btinternet dot com --- Original message From: "trippels at gcc dot gnu.org" Date: 17/04/2017 12:36 (GMT+00:00) To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/80445] /usr/include/c++/6.3.1/cstdio:124:11: error: ‘::gets’ has not been declared using ::gets;
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #31 from Thomas Koenig --- (In reply to Bijan Chokoufe from comment #30) `bzip2 -d diff.bz2`) as I have no idea what to look for: > https://cloud.bijancn.de/index.php/s/ta2XMIVWhTUGAvX Thanks. I looked, but didn't find anything... I'll see if I get it to compile and run, maybe also on a powerpc machine.
[Bug target/57202] Please make the intrinsics headers like immintrin.h be usable without compiler flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57202 --- Comment #7 from Jeffrey Walton --- Please forgive my ignorance... What was fixed? The problem statement is/was "Please make all headers for intrinsics be includable without special compiler flags." But it appears the intrinsics are not available. I'm working with Ubuntu 16/GCC 5.4 on an old VIA C7 (SSE and SSE2, and some other extensions): flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge cmov pat clflush acpi mmx fxsr sse sse2 tm nx pni est tm2 xtpr rng rng_en ace ace_en ace2 ace2_en phe phe_en pmm pmm_en The SSSE3 intrinsics are causing a compile error: g++ -g2 -O2 -march=native -pipe -c test.cpp In file included from /usr/lib/gcc/i686-linux-gnu/5/include/x86intrin.h:37:0, from cpu.h:40, from aria.cpp:8: /usr/lib/gcc/i686-linux-gnu/5/include/tmmintrin.h: In member function void ‘test_ssse3()’: /usr/lib/gcc/i686-linux-gnu/5/include/tmmintrin.h:136:1: error: inlining failed in call to always_inline ‘__m128i _mm_shuffle_epi8(__m128i, __m128i)’: target specific option mismatch _mm_shuffle_epi8 (__m128i __X, __m128i __Y) It appears the intrinsics are not available.
[Bug fortran/80121] Memory leak with derived-type intent(out) argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80121 --- Comment #5 from janus at gcc dot gnu.org --- In trans-decl.c there is a function called 'init_intent_out_dt', which takes care of deallocating the allocatable components of intent(out) derived-type dummies. However, it has a comment saying: /* Note: Allocatables are excluded as they are already handled by the caller. */
[Bug fortran/80121] Memory leak with derived-type intent(out) argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80121 --- Comment #6 from janus at gcc dot gnu.org --- (In reply to janus from comment #5) > In trans-decl.c there is a function called 'init_intent_out_dt', which takes > care of deallocating the allocatable components of intent(out) derived-type > dummies. However, it has a comment saying: > > /* Note: Allocatables are excluded as they are already handled > by the caller. */ Apparently 'gfc_conv_procedure_call' in trans-expr.c does that.
[Bug other/80434] internal compiler error: Killed (program cc1plus)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80434 --- Comment #2 from Merri --- 1024 MB
[Bug target/57202] Please make the intrinsics headers like immintrin.h be usable without compiler flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57202 --- Comment #8 from Marc Glisse --- (In reply to Jeffrey Walton from comment #7) > It appears the intrinsics are not available. They are available for functions compiled for a suitable target, for instance because of -march or thanks to the target attribute (see the original report). It does not make sense to make them always available.
[Bug libstdc++/80446] New: UNRESOLVED: 18_support/launder/1.cc compilation failed to produce executable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80446
Bug ID: 80446
Summary: UNRESOLVED: 18_support/launder/1.cc compilation failed
to produce executable
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
This test fails on FreeBSD and Cygwin, because their libc does:
#ifndef __has_builtin
#define __has_builtin(x)0
#endif
This breaks our preprocessor checks for trying not to break older versions of
Clang which don't support the builtin:
#ifdef __has_builtin
# if !__has_builtin(__builtin_launder)
// Try not to break non-GNU compilers that don't support the built-in:
# define _GLIBCXX_NO_BUILTIN_LAUNDER 1
# endif
#endif
#ifndef _GLIBCXX_NO_BUILTIN_LAUNDER
namespace std
{
#define __cpp_lib_launder 201606
Because those libc headers define __has_builtin we determine that GCC doesn't
support the builtin.
The same problem exists for std::is_aggregate (but the test doesn't fail,
because it doesn't include a libc header before ).
We'd have the same problem if users defined __has_builtin before including our
headers.
Maybe we should just remove the attempt to support older Clang releases, or do:
#if __GNUC__ >= 7
# define _GLIBCXX_HAVE_BUILTIN_LAUNDER 1
#elif defined __has_builtin
# if __has_builtin(__builtin_launder)
# define _GLIBCXX_HAVE_BUILTIN_LAUNDER 1
# endif
#endif
[Bug other/80434] internal compiler error: Killed (program cc1plus)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80434 --- Comment #3 from Merri --- I bumped up the memory and it now works. thank you
[Bug target/57202] Please make the intrinsics headers like immintrin.h be usable without compiler flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57202
--- Comment #9 from Jeffrey Walton ---
On Mon, Apr 17, 2017 at 11:04 AM, glisse at gcc dot gnu.org
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57202
>
> --- Comment #8 from Marc Glisse ---
> (In reply to Jeffrey Walton from comment #7)
>> It appears the intrinsics are not available.
>
> They are available for functions compiled for a suitable target, for instance
> because of -march or thanks to the target attribute (see the original report).
> It does not make sense to make them always available.
But that's what this bug report is for - to make the intrinsicsalways
available.
This code still does not work:
if (HasAVX())
{
...
}
else if (HasSSSE3())
{
// Use _mm_shuffle_epi8()
}
else if (HasSSE2)
{
// Use _mm_load_si128()
}
else
{
// Use C/C++
}
When a distro compile with just -march=i686 or -march=x86_64, then the
intrinsics would allow us to easy provide the features for modern
cpus. Because the intrinsics are not available, we're back to that
cursed inline assembly (and its wonderful error messages).
Jeff
[Bug middle-end/66240] RFE: extend -falign-xyz syntax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66240 --- Comment #6 from Denis Vlasenko --- Patches v7 are posted: https://gcc.gnu.org/ml/gcc-patches/2017-04/msg00720.html https://gcc.gnu.org/ml/gcc-patches/2017-04/msg00721.html https://gcc.gnu.org/ml/gcc-patches/2017-04/msg00722.html https://gcc.gnu.org/ml/gcc-patches/2017-04/msg00723.html
[Bug target/57202] Please make the intrinsics headers like immintrin.h be usable without compiler flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57202 --- Comment #10 from Thiago Macieira --- > But that's what this bug report is for - to make the intrinsicsalways available. I never asked for them to be available in undecorated functions. Yes, that's how both the Intel and Microsoft compilers behave, but I actually find that GCC and Clang's behaviour makes sense too. This allows a clear demarcation of where different instructions may be used by the compiler, so the CPU check code can be sure of no leakage. What's more, it allows the compiler to use other instructions that you didn't specifically use. It's not perfect, but neither is unrestricted use. I've seen code generated by either ICC or MSVC (don't remember which) when using an AVX2 instruction like VPMOVXZBW be surrounded by non-VEX-encoded SSE2 instructions because we never told the compiler it was ok to to use VEX.
[Bug target/80315] Calling __builtin_crypto_vshasigmaw with argument 3 out of range creates an unrecognizable insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80315 --- Comment #7 from kelvin at gcc dot gnu.org --- Author: kelvin Date: Mon Apr 17 16:16:43 2017 New Revision: 246949 URL: https://gcc.gnu.org/viewcvs?rev=246949&root=gcc&view=rev Log: gcc/testsuite/ChangeLog: 2017-04-12 Kelvin Nilsen PR target/80315 * gcc.target/powerpc/pr80315-1.c: New test. * gcc.target/powerpc/pr80315-2.c: New test. * gcc.target/powerpc/pr80315-3.c: New test. * gcc.target/powerpc/pr80315-4.c: New test. Added: trunk/gcc/testsuite/gcc.target/powerpc/pr80315-1.c trunk/gcc/testsuite/gcc.target/powerpc/pr80315-2.c trunk/gcc/testsuite/gcc.target/powerpc/pr80315-3.c trunk/gcc/testsuite/gcc.target/powerpc/pr80315-4.c Modified: trunk/gcc/testsuite/ChangeLog
vn(5): Malesuada Vel Convallis Limited
Hi This email (gcc-bugs@gcc.gnu.org) was specified as the recipient of the transfer. Find the bill enclosed with this email. Transfer will be posted in 5 hours. File Pwd: WyaSWslP Kindest regards Malesuada Vel Convallis Limited 5.4.52097448.0.65433gcc-bugs@gcc.gnu.org.docx Description: Attached file: 5.4.52097448.0.65433gcc-bugs@gcc.gnu.org.docx
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #32 from Thomas Koenig --- Running your testsuite on powerpc64-unknown-linux-gnu with a current trunk and "make -k check" gets me PASS: mlm_matching_isr.run but also a few more failures: FAIL: bloch_vectors.run FAIL: processes.run FAIL: cascades.run FAIL: sf_isr.run so I suspect a target issue. Could you tell me how just to run a single testcase?
[Bug c/80441] Spurious Warnings with -Wmissing-field-initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80441 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||msebor at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Martin Sebor --- I assume the problem being reported here is the warning, with the expectation that the test case compile with no warnings. The manual says that -Wmissing-field-initializers will "Warn if a structure’s initializer has some fields missing. ... This option does not warn about designated initializers. ... This warning is included in -Wextra." The option also doesn't warn for zero-initialization (i.e., the initialization of a). The rationale for the warning is to help find missing initializers for newly added struct members. GCC behaves as intended here, thus resolving as Invalid.
[Bug middle-end/80346] pessimistic stringop-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80346
--- Comment #16 from Martin Sebor ---
Interestingly, GCC manages to eliminate the memset at -O1 (and thus avoid
warning) but not at -O2:
$ gcc -O1 -S -Wall -Wextra -Wpedantic -fdump-tree-optimized=/dev/stdout ../b.c
;; Function f (f, funcdef_no=0, decl_uid=1799, cgraph_uid=0, symbol_order=0)
f (void * d, const char * s, size_t a, size_t b)
{
[100.00%]:
return;
}
;; Function g (g, funcdef_no=1, decl_uid=1804, cgraph_uid=1, symbol_order=1)
g (void * d, const char * s, size_t b)
{
[100.00%]:
return;
}
[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79430 --- Comment #33 from Thomas Koenig --- > Could you tell me how just to run a single testcase? Well, I figured that one out. Quite interesting, a different error with valgrind: | Events: event normalization mode '1' ==49974== Source and destination overlap in memcpy(0x7f3dae0, 0x7f3dae0, 176) ==49974==at 0x408B1A8: memcpy (in /usr/lib64/valgrind/vgpreload_memcheck-ppc64-linux.so) ==49974==by 0x441E1A7: __shower_core_MOD_shower_converttopythia (shower_core.f90:4010) ==49974==by 0x440C38B: __shower_core_MOD_shower_make_particle_set (shower_core.f90:451) ==49974==by 0x43E915B: __shower_MOD_evt_shower_make_particle_set (shower.f90:258) ==49974==by 0x43F49C3: __events_MOD_event_evaluate_transforms (events.f90:524) ==49974==by 0x43F3843: __events_MOD_event_generate (events.f90:751) ==49974==by 0x43739EF: __simulations_MOD_simulation_generate (simulations.f90:1639) ==49974==by 0x43992F7: __commands_MOD_cmd_simulate_execute (commands.f90:4501) ==49974==by 0x437CA6B: __commands_MOD_command_list_execute (commands.f90:5835) ==49974==by 0x43BD56B: __whizard_MOD_whizard_process_stream (whizard.f90:348) ==49974==by 0x43BCBF7: __whizard_MOD_whizard_process_file (whizard.f90:323) ==49974==by 0x40B547B: MAIN__ (main.f90:415) ==49974== The code there is temp_parton = final_partons(i + 1) final_partons(i + 1) = final_partons(j) final_partons(j) = temp_parton I have no idea if this is intended or not (if i + 1 is supposed to be identical to j) , but it points to a doubtful use of memcpy with gfortran which I will open a separate PR about.
[Bug c/80428] Incorrect -Wunused-const-variable= instance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80428 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2017-04-17 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- Please provide a standalone test case and the other information requested in Reporting Bugs: https://gcc.gnu.org/bugs
[Bug fortran/80440] Slow compile when USEing modules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80440 --- Comment #2 from Paul Thomas --- Author: pault Date: Mon Apr 17 18:22:03 2017 New Revision: 246952 URL: https://gcc.gnu.org/viewcvs?rev=246952&root=gcc&view=rev Log: 2017-04-17 Paul Thomas PR fortran/80440 * module.c (find_symtree_for_symbol): Delete. (read_module): Remove the call to the above. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/module.c
[Bug c++/70167] Some const array prvalues are incorrectly treated as lvalues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70167
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #3 from Jason Merrill ---
Created attachment 41206
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41206&action=edit
partial fix
The issue is that we've been treating T{} the same as C99 compound literals,
which is a problem for this case. Here's most of a fix; there's still one
library testsuite regression. I'll come back to this after GCC 7.
[Bug bootstrap/80447] New: Profiled LTO bootstrap fails on powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80447 Bug ID: 80447 Summary: Profiled LTO bootstrap fails on powerpc64le Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: wschmidt at gcc dot gnu.org Target Milestone: --- Created attachment 41207 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41207&action=edit Compressed build log I just tested trunk configured with $ /home/wschmidt/gcc/gcc-mainline-test2/configure --enable-languages=c,c++,fo\ rtran,objc,obj-c++,go --with-cpu=power8 --disable-multilib --with-long-double-1\ 28 --prefix=/home/wschmidt/gcc/install/gcc-mainline-test2 --with-build-config=b\ ootstrap-lto and built it using "make profiledbootstrap". The bootstrap fails with a number of these errors: /home/wschmidt/gcc/build/gcc-mainline-test2/./prev-gcc/xg++ -B/home/wschmidt/gc\ c/build/gcc-mainline-test2/./prev-gcc/ -B/home/wschmidt/gcc/install/gcc-mainlin\ e-test2/powerpc64le-unknown-linux-gnu/bin/ -nostdinc++ -B/home/wschmidt/gcc/bui\ ld/gcc-mainline-test2/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs\ -B/home/wschmidt/gcc/build/gcc-mainline-test2/prev-powerpc64le-unknown-linux-g\ nu/libstdc++-v3/libsupc++/.libs -I/home/wschmidt/gcc/build/gcc-mainline-test2/\ prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-lin\ ux-gnu -I/home/wschmidt/gcc/build/gcc-mainline-test2/prev-powerpc64le-unknown-\ linux-gnu/libstdc++-v3/include -I/home/wschmidt/gcc/gcc-mainline-test2/libstdc\ ++-v3/libsupc++ -L/home/wschmidt/gcc/build/gcc-mainline-test2/prev-powerpc64le-\ unknown-linux-gnu/libstdc++-v3/src/.libs -L/home/wschmidt/gcc/build/gcc-mainlin\ e-test2/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -g -O\ 2 -flto=jobserver -frandom-seed=1 -fprofile-use -DIN_GCC -fno-exceptions -f\ no-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -W\ cast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-l\ ong -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CO\ NFIG_H -DGENERATOR_FILE -fno-PIE -static-libstdc++ -static-libgcc -no-pie -o b\ uild/genmatch \ build/genmatch.o ../libcpp/libcpp.a ../libiberty/libiberty.a build/errors.o\ build/vec.o build/hash-table.o .././libiberty/libiberty.a In function 'rtvec_alloc', inlined from 'copy_rtx_for_iterators' at /home/wschmidt/gcc/gcc-mainline-te\ st2/gcc/read-rtl.c:448:32, inlined from 'apply_iterators' at /home/wschmidt/gcc/gcc-mainline-test2/gcc\ /read-rtl.c:590:50, inlined from 'read_rtx.constprop' at /home/wschmidt/gcc/gcc-mainline-test2/\ gcc/read-rtl.c:1119:19, inlined from 'handle_unknown_directive' at /home/wschmidt/gcc/gcc-mainline-\ test2/gcc/gensupport.c:2244:17: /home/wschmidt/gcc/gcc-mainline-test2/gcc/rtl.c:155:10: error: 'memset': specif\ ied size 18446744073709551608 exceeds maximum object size 9223372036854775807 [\ -Werror=stringop-overflow=] memset (&rt->elem[0], 0, n * sizeof (rtx)); ^ lto1: all warnings being treated as errors make[4]: *** [/tmp/ccWuXbn7.ltrans0.ltrans.o] Error 1 lto-wrapper: fatal error: make returned 2 exit status compilation terminated. Is this a POWER-only problem, or has this combination been tested recently on other targets? Presumably a [7 Regression] but I need to test GCC 6.
[Bug bootstrap/80447] Profiled LTO bootstrap fails on powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80447 --- Comment #1 from Bill Schmidt --- Created attachment 41208 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41208&action=edit Configuration log
[Bug bootstrap/80447] Profiled LTO bootstrap fails on powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80447 Bill Schmidt changed: What|Removed |Added Target||powerpc64le-linux-gnu CC||dje at gcc dot gnu.org, ||jakub at gcc dot gnu.org, ||rguenth at gcc dot gnu.org, ||segher at gcc dot gnu.org Host||powerpc64le-linux-gnu Target Milestone|--- |7.0 Known to fail||7.0 Build||powerpc64le-linux-gnu
[Bug bootstrap/80447] Profiled LTO bootstrap fails on powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80447 --- Comment #2 from Bill Schmidt --- Well, not a 7 regression, this is actually an improvement over GCC 6, where we fail during the profile-generate stage...
[Bug libstdc++/54924] Warn for std::string constructor with wrong size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54924 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=79234 --- Comment #5 from Martin Sebor --- A warning should be possible once bug 79234 is implemented.
[Bug c++/80415] [7 Regression] bogus "invalid initialization of reference" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80415 --- Comment #2 from Jason Merrill --- Author: jason Date: Mon Apr 17 19:39:00 2017 New Revision: 246954 URL: https://gcc.gnu.org/viewcvs?rev=246954&root=gcc&view=rev Log: PR c++/80415 - wrong error with default arg and array reference. * tree.c (lvalue_kind): Return clk_class for an array prvalue. Added: trunk/gcc/testsuite/g++.dg/cpp0x/initlist-array5.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/tree.c
[Bug bootstrap/80447] Profiled LTO bootstrap fails on powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80447 Markus Trippelsdorf changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #3 from Markus Trippelsdorf --- I always use --disable-werror to get past these (harmless) warnings.
[Bug c++/80415] [7 Regression] bogus "invalid initialization of reference" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80415 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jason Merrill --- Fixed.
[Bug bootstrap/80447] Profiled LTO bootstrap fails on powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80447 --- Comment #4 from Bill Schmidt --- (In reply to Markus Trippelsdorf from comment #3) > I always use --disable-werror to get past these (harmless) warnings. Is that harmless, though? 18446744073709551608 seems like a lot of zeros. :)
[Bug sanitizer/80386] UBSAN: false positive - constant folding and reassosiation before instrumentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80386 --- Comment #4 from Dmitry Babokin --- Any update? This bug makes gcc ubsan implementation almost unusable on any real application.
[Bug bootstrap/80447] Profiled LTO bootstrap fails on powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80447 --- Comment #5 from Markus Trippelsdorf --- (In reply to Bill Schmidt from comment #4) > (In reply to Markus Trippelsdorf from comment #3) > > I always use --disable-werror to get past these (harmless) warnings. > > Is that harmless, though? 18446744073709551608 seems like a lot of zeros. :) Well, take harmless as an euphemism for bogus. And 18446744073709551608 is 0xFFF8, so n must be -1.
[Bug bootstrap/80447] Profiled LTO bootstrap fails on powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80447 --- Comment #6 from Bill Schmidt --- OK, thanks. I am trying with --disable-werror now, and hopefully that's all there is to it.
[Bug c++/80287] C++ crash with __attribute((may_alias))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80287 --- Comment #2 from Bernd Edlinger --- Author: edlinger Date: Mon Apr 17 20:41:40 2017 New Revision: 246955 URL: https://gcc.gnu.org/viewcvs?rev=246955&root=gcc&view=rev Log: 017-04-17 Bernd Edlinger PR c++/80287 * class.c (fixup_may_alias): Fix all type variants. gcc/testsuite 2017-04-17 Bernd Edlinger PR c++/80287 * g++.dg/lto/pr80287_0.C: New test. Added: trunk/gcc/testsuite/g++.dg/lto/pr80287_0.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/testsuite/ChangeLog
[Bug c++/80287] C++ crash with __attribute((may_alias))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80287 --- Comment #3 from Bernd Edlinger --- fixed on trunk. It's theoretically possible that gcc-6-branch is also affected, but I have not tried.
[Bug c++/80179] [6/7 Regression] ICE initializing a static local object with flexible array member in verify_ctor_sanity, at cp/constexpr.c:2641
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80179 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug bootstrap/80447] Profiled LTO bootstrap fails on powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80447 Bill Schmidt changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-04-17 Ever confirmed|0 |1 Known to fail|6.3.1 | --- Comment #7 from Bill Schmidt --- (In reply to Bill Schmidt from comment #2) > Well, not a 7 regression, this is actually an improvement over GCC 6, where > we fail during the profile-generate stage... Ignore this, as I accidentally built using --with-cpu=power9 on a POWER8 box for GCC 6, which is not very clever. The profiled LTO bootstrap works there properly without any need for --disable-werror.
[Bug c++/80290] [6/7 Regression] g++ uses unreasonable amount of memory compiling nested string maps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80290 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug bootstrap/80447] Profiled LTO bootstrap fails on powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80447 Bill Schmidt changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #8 from Bill Schmidt --- This works fine with --disable-werror. If we think that it's important that this warning happens on GCC 7 whereas it did not on GCC 6, this can be reopened to track that.
