[Bug target/88055] New: ICE in extract_insn, at recog.c:2305 on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88055
Bug ID: 88055
Summary: ICE in extract_insn, at recog.c:2305 on ppc64le
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: segher at gcc dot gnu.org
Target Milestone: ---
Following is causing ICE:
$ cat ice.i
int a;
void b() {
__builtin_sinh(a);
__builtin_sinhf(a);
__builtin_sinhl(a);
}
$ ppc64le-linux-gnu-gcc -fno-tree-dce -fno-tree-forwprop -Ofast ice.i
ice.i: In function ‘b’:
ice.i:6:1: error: unrecognizable insn:
6 | }
| ^
(insn 11 10 12 2 (set (reg:DI 135)
(unlt:DI (reg:CCFP 134)
(const_int 0 [0]))) -1
(nil))
during RTL pass: vregs
ice.i:6:1: internal compiler error: in extract_insn, at recog.c:2305
0x574aef _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/rtl-error.c:108
0x574b0b _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/rtl-error.c:116
0x573ff8 extract_insn(rtx_insn*)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/recog.c:2305
0x7c2e1f instantiate_virtual_regs_in_insn
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/function.c:1605
0x7c2e1f instantiate_virtual_regs
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/function.c:1975
0x7c2e1f execute
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/function.c:2024
[Bug target/88055] ICE in extract_insn, at recog.c:2305 on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88055 Martin Liška changed: What|Removed |Added Target||ppc64le-linux-gnu Last reconfirmed||2018-11-16 Host||x86_64-pc-linux-gnu Target Milestone|--- |9.0
[Bug sanitizer/88054] Sanitizer triggers on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88054 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-11-16 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Target Milestone|--- |8.3 Ever confirmed|0 |1 Known to fail||8.2.0 --- Comment #1 from Martin Liška --- Confirmed with -m32.
[Bug lto/88004] [9 Regression] lto1: error: node differs from node->decl->decl_with_vis.symtab_node
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88004 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-11-16 Assignee|hubicka at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- I've worked with Honza on a patch that I'll send soon to mailing list.
[Bug rtl-optimization/88033] [9 Regression] ICE on valid code at -O2 and -O3 on x86-64-linux-gnu: in remove_some_program_points_and_update_live_ranges, at lra-lives.c:1179
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88033 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-11-16 CC||marxin at gcc dot gnu.org Target Milestone|--- |9.0 Summary|ICE on valid code at -O2|[9 Regression] ICE on valid |and -O3 on |code at -O2 and -O3 on |x86-64-linux-gnu: in|x86-64-linux-gnu: in |remove_some_program_points_ |remove_some_program_points_ |and_update_live_ranges, at |and_update_live_ranges, at |lra-lives.c:1179|lra-lives.c:1179 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, started with r266086.
[Bug tree-optimization/88015] [9 Regression] ICE in dump_printf_loc, at dumpfile.c:1287
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88015 Martin Liška changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #7 from Martin Liška --- I can confirm the ICEs are gone.
[Bug sanitizer/88054] Sanitizer triggers on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88054 --- Comment #2 from Jakub Jelinek --- Apparently i?86 glibc has two fopen entrypoints: 192: 000657d035 FUNCGLOBAL DEFAULT 13 fopen@@GLIBC_2.1 193: 0011ec90 144 FUNCGLOBAL DEFAULT 13 fopen@GLIBC_2.0 and libsanitizer intercepts just fopen rather than both and during interception calls the unversioned one returned by dlsym, which is the fopen@GLIBC_2.0. If it wants to intercept fopen on this platform, it needs to probably intercept both and do symbol versioning, or if it doesn't want to bother with the old one at least should make sure to use dlvsym in this case.
[Bug bootstrap/81397] mistakes in .opt files not detected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81397 --- Comment #5 from Martin Liška --- (In reply to Eric Gallager from comment #4) > (In reply to Martin Liška from comment #3) > > As we're staying with Awk, for now I'm planning to work on that. > > Missing the word "not" in there? Yes, I was writing faster that thinking :)
[Bug ipa/87706] Inlined functions trigger invalid -Wmissing-profile warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87706 Martin Liška changed: What|Removed |Added Assignee|marxin at gcc dot gnu.org |hubicka at ucw dot cz --- Comment #4 from Martin Liška --- Assigning to Honza after we discussed that.
[Bug c/88056] New: gcc/config/i386/host-mingw32.c:170: use of out of scope pointer ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88056
Bug ID: 88056
Summary: gcc/config/i386/host-mingw32.c:170: use of out of
scope pointer ?
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
trunk/gcc/config/i386/host-mingw32.c:166] ->
[trunk/gcc/config/i386/host-mingw32.c:162] ->
[trunk/gcc/config/i386/host-mingw32.c:170]: (error) Using pointer to local
variable 'local_object_name' that is out of scope.
Source code is
if (version_info.dwMajorVersion > 4)
{
char local_object_name [sizeof (OBJECT_NAME_FMT)
+ sizeof (DWORD) * 2];
snprintf (local_object_name, sizeof (local_object_name),
OBJECT_NAME_FMT "%lx", GetCurrentProcessId());
object_name = local_object_name;
}
mmap_handle = CreateFileMappingA ((HANDLE) _get_osfhandle (fd), NULL,
PAGE_WRITECOPY | SEC_COMMIT, 0, 0,
object_name);
If the if ever triggers, object_name will be pointing at an out
of scope object.
[Bug sanitizer/88054] Sanitizer triggers on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88054
--- Comment #3 from Martin Liška ---
The problem looks very similar to:
3537 #if SANITIZER_INTERCEPT_REALPATH
3538 INTERCEPTOR(char *, realpath, const char *path, char *resolved_path) {
3539void *ctx;
3540COMMON_INTERCEPTOR_ENTER(ctx, realpath, path, resolved_path);
3541if (path) COMMON_INTERCEPTOR_READ_RANGE(ctx, path, REAL(strlen)(path)
+ 1);
3542
3543// Workaround a bug in glibc where dlsym(RTLD_NEXT, ...) returns the
oldest
3544// version of a versioned symbol. For realpath(), this gives us
something
3545// (called __old_realpath) that does not handle NULL in the second
argument.
3546// Handle it as part of the interceptor.
3547char *allocated_path = nullptr;
3548if (!resolved_path)
3549 allocated_path = resolved_path = (char *)WRAP(malloc)(path_max +
1);
3550
3551char *res = REAL(realpath)(path, resolved_path);
3552if (allocated_path && !res) WRAP(free)(allocated_path);
3553if (res) COMMON_INTERCEPTOR_WRITE_RANGE(ctx, res, REAL(strlen)(res) +
1);
3554return res;
3555 }
3556 #define INIT_REALPATH COMMON_INTERCEPT_FUNCTION(realpath);
3557 #else
3558 #define INIT_REALPATH
3559 #endif
[Bug other/88056] gcc/config/i386/host-mingw32.c:170: use of out of scope pointer ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88056 David Binderman changed: What|Removed |Added CC||dannysmith at gcc dot gnu.org --- Comment #1 from David Binderman --- Adding original author from svn blame.
[Bug sanitizer/88054] Sanitizer triggers on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88054 --- Comment #4 from Jakub Jelinek --- The comment is bogus, that is the symbol versioning design, the only way how to stay ABI compatible even with the binaries that were written before the new symbol version has been introduced. For symbols with more than one symbol version, one needs to use dlvsym, unless the oldest symbol version is desired.
[Bug tree-optimization/88044] [9 regression] gfortran.dg/transfer_intrinsic_3.f90 hangs after r266171
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88044 Richard Biener changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P1 Target Milestone|--- |9.0
[Bug target/88055] ICE in extract_insn, at recog.c:2305 on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88055 --- Comment #1 from Segher Boessenkool --- It does not fail for me.
[Bug preprocessor/82335] Incorrect _Pragma expansion in complex macro expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82335
--- Comment #1 from pskocik at gmail dot com ---
This problem still persists in gcc 7.3.0. It appears pasting a macro containing
`_Pragma`s into
another macro is what's causing the displacement of the generated `#pragma`s.
I've cleaned up the example to make it clearer:
#define PRAGMA(...) _Pragma(#__VA_ARGS__)
#define PASTE(Expr) Expr
#define PUSH_IGN(X) PRAGMA(GCC diagnostic push) PRAGMA(GCC diagnostic
ignored X)
#define POP() PRAGMA(GCC diagnostic pop)
#define SIGNED_EH(X) \
({ PUSH_IGN("-Wtype-limits") \
_Bool SIGNED_EH = ((__typeof(X))-1 < 0); \
POP() \
SIGNED_EH; })
int main();
{
unsigned x;
SIGNED_EH(x); //OK; #pragmas generated around the
assignment:
#if 0 //generated:
({
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wtype-limits"
_Bool SIGNED_EH = ((__typeof(x))-1 < 0);
#pragma GCC diagnostic pop
SIGNED_EH; });
#endif
PASTE(SIGNED_EH(x)); //OOPS generates:
#if 0 //generated:
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wtype-limits"
#pragma GCC diagnostic pop
({ _Bool SIGNED_EH = ((__typeof(x))-1 < 0); SIGNED_EH;
});
#endif
}
Clang's preprocessor generates correct code even for the `PASTE(SIGNED_EH(x))`
case.
[Bug middle-end/88056] gcc/config/i386/host-mingw32.c:170: use of out of scope pointer ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88056 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-11-16 Component|other |middle-end Ever confirmed|0 |1
[Bug target/88055] ICE in extract_insn, at recog.c:2305 on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88055 --- Comment #2 from Martin Liška --- $ ppc64le-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/home/marxin/BIG/bin/ppc64le/dev/shm/buildbot/install/gcc/bin/ppc64le-linux-gnu-gcc COLLECT_LTO_WRAPPER=/home/marxin/BIG/bin/ppc64le/dev/shm/buildbot/install/gcc/bin/../libexec/gcc/ppc64le-linux-gnu/9.0.0/lto-wrapper Target: ppc64le-linux-gnu Configured with: /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/configure --enable-languages=c,c++,fortran --disable-bootstrap --disable-libsanitizer --disable-multilib --enable-checking=release --prefix=/dev/shm/buildbot/install/gcc --target=ppc64le-linux-gnu --with-as=/usr/bin/powerpc64le-suse-linux-as Thread model: posix gcc version 9.0.0 20181115 (experimental) 17a6cd1e22ad392b8dbdfa2db2fcb8311f299b55 (GCC) $ /usr/bin/powerpc64le-suse-linux-as -v GNU assembler version 2.31 (powerpc64le-suse-linux) using BFD version (GNU Binutils; openSUSE Tumbleweed) 2.31
[Bug testsuite/88053] [9 regression] g++.dg/lto/pr54625-1.C fails with r266194
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88053 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-11-16 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |9.0 Ever confirmed|0 |1
[Bug testsuite/88053] [9 regression] g++.dg/lto/pr54625-1.C fails with r266194
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88053 --- Comment #1 from Richard Biener --- Author: rguenth Date: Fri Nov 16 09:27:36 2018 New Revision: 266202 URL: https://gcc.gnu.org/viewcvs?rev=266202&root=gcc&view=rev Log: 2018-11-16 Richard Biener PR testsuite/88053 * g++.dg/lto/pr54625-1_0.c: Add -w. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/lto/pr54625-1_0.c
[Bug testsuite/88053] [9 regression] g++.dg/lto/pr54625-1.C fails with r266194
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88053 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Richard Biener --- Fixed by adding -w.
[Bug c++/88050] Add a warning for breaking the "Rule of Three"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88050 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-11-16 Ever confirmed|0 |1
[Bug fortran/88048] [8/9 Regression] ICE in check_data_variable, at fortran/resolve.c:15491
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88048 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |8.3
[Bug other/88057] New: libdecnumber/decCommon.c:479: use of out of scope variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88057
Bug ID: 88057
Summary: libdecnumber/decCommon.c:479: use of out of scope
variable
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
trunk/libdecnumber/decCommon.c:479] -> [trunk/libdecnumber/decCommon.c:471] ->
[trunk/libdecnumber/decCommon.c:483]: (error) Using pointer to local variable
'buffer' that is out of scope.
svn blame says
128350 janis uByte buffer[ROUNDUP(DECPMAX+3, 4)]; /* [+3 allows
uInt padding] */
128350 janis uByte *s=umsd;/* source */
128350 janis uByte *t=buffer; /* safe target */
128350 janis uByte *tlsd=buffer+(ulsd-umsd)+shift; /* target LSD
*/
128350 janis /* printf("folddown shift=%ld\n", (LI)shift); */
145274bje for (; s<=ulsd; s+=4, t+=4) UBFROMUI(t, UBTOUI(s));
145274bje for (t=tlsd-shift+1; t<=tlsd; t+=4) UBFROMUI(t, 0);
/* pad 0s */
128350 janis num->exponent-=shift;
128350 janis umsd=buffer;
128350 janis ulsd=tlsd;
128350 janis }
128350 janis } /* fold-down? */
128350 janis length=ulsd-umsd+1; /* recalculate length
*/
[Bug tree-optimization/88011] [9 regression] r266028 causes a bunch of go failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88011
--- Comment #9 from Richard Biener ---
Thanks for the testcase!
--- a/test.go.115t.dom2 2018-11-16 10:45:27.663896672 +0100
+++ b/test.go.115t.dom2 2018-11-16 10:46:47.945357195 +0100
@@ -13937,7 +13937,7 @@
LKUP STMT _27 = aWord_58 trunc_div_expr bWord_60
2>>> STMT _27 = aWord_58 trunc_div_expr bWord_60
0>>> COPY iftmp.324_13 = _27
-pushing new range for iftmp.324_13: [0, +INF]
+pushing new range for iftmp.324_13: UNDEFINED
LKUP STMT bWord_60 eq_expr 18446744073709551615
FIND: 0
COPY iftmp.324_13 = _27
that's where things start to differ.
Doh. Simple mass-change error:
@@ -1882,7 +1873,7 @@ extract_range_from_binary_expr_1 (value_
TYPE_OVERFLOW_UNDEFINED (expr_type),
extra_range_p, extra_min, extra_max))
{
- set_value_range_to_varying (vr);
+ vr->set_undefined ();
return;
}
set_value_range (vr, VR_RANGE,
[Bug rtl-optimization/86438] [8 Regression] wrong code at -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86438 Andrew Stubbs changed: What|Removed |Added CC||ams at gcc dot gnu.org --- Comment #9 from Andrew Stubbs --- The testcase is undefined for targets that have no 128-bit type (i.e. long long is 64-bit, and __int128 doesn't exist). For (not yet in tree) GCN port I get "warning: right shift count >= width of type [-Wshift-count-overflow]", and then the execution test aborts.
[Bug c/88058] New: gcc fails to detect use of out of scope variable ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88058
Bug ID: 88058
Summary: gcc fails to detect use of out of scope variable ?
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
Generalising from bugs # 88056 and # 88057,
for the following code, gcc says nothing:
extern void g( char *);
void f( int n, char * p1)
{
char * p2;
p2 = p1;
if (n >= 0)
{
char buf[ 10];
p2 = buf;
}
g( p2); // Bang !
}
$ ~/gcc/results/bin/gcc -c -O2 -Wall -Wextra nov16a.cc
$
[Bug target/86487] [7/8/9 Regression] insn does not satisfy its constraints on arm big-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86487 --- Comment #5 from avieira at gcc dot gnu.org --- I can confirm the ICE no longer occurs, but I am not entirely convinced the issue was "fixed" by this. I fear the underlying fault is still there, it is simply hidden now.
[Bug debug/87039] [8/9 Regression] DW_OP_fbreg used without a frame base on a C++ code w/ -fopenmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87039 Jakub Jelinek changed: What|Removed |Added Attachment #45006|0 |1 is obsolete|| --- Comment #4 from Jakub Jelinek --- Created attachment 45020 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45020&action=edit gcc9-pr87039.patch Unfortunately the previous patch only fixed the pr78363-1.C testcase and not -2.C or -3.C. The problem is that r253335 only tweaked parallel regions (and later I've copied that to host teams), not others (task, target). There is another thing I've noticed. Because OMP expansion works from leaf regions to outer regions, for parallel/task/target nested in another parallel/task/target/host teams DECL_CONTEXT would be set incorrectly, pointing at the ultimate containing function (the user function), rather than the immediate parent. And, after fixing that I've noticed dwarf2out.c needs tweaking too, because it handles just one decl_function_context, doesn't work recursively.
[Bug sanitizer/88054] Sanitizer triggers on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88054 Martin Liška changed: What|Removed |Added See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=14932 --- Comment #5 from Martin Liška --- The issue with dlvsym is that one can't request a default version (without knowing ABI version), so e.g. dlvsym(h, "fopen", ""). I believe root problem is this glibc PR I just linked. The problem is default version is not returned. I wrote a script that lists all function names for which interceptor is called (GetRealFunctionAddress) and I compared that to symbols in glibc that have multiple interface versions. And the result is not good: $ readelf --syms --wide /lib64/libc.so.6 | ./check-symver.py ['glob64@@GLIBC_2.27', 'glob64@GLIBC_2.2.5'] ['glob@@GLIBC_2.27', 'glob@GLIBC_2.2.5'] ['sched_getaffinity@@GLIBC_2.3.4', 'sched_getaffinity@GLIBC_2.3.3'] ['realpath@@GLIBC_2.3', 'realpath@GLIBC_2.2.5'] ['fmemopen@@GLIBC_2.22', 'fmemopen@GLIBC_2.2.5'] ['memcpy@@GLIBC_2.14', 'memcpy@GLIBC_2.2.5'] $ readelf --syms --wide /lib/libc.so.6 | ./check-symver.py ['scandir64@@GLIBC_2.2', 'scandir64@GLIBC_2.1'] ['glob64@@GLIBC_2.27', 'glob64@GLIBC_2.1', 'glob64@GLIBC_2.2'] ['getpwent_r@@GLIBC_2.1.2', 'getpwent_r@GLIBC_2.0'] ['getpwuid_r@@GLIBC_2.1.2', 'getpwuid_r@GLIBC_2.0'] ['getgrnam_r@@GLIBC_2.1.2', 'getgrnam_r@GLIBC_2.0'] ['shmctl@@GLIBC_2.2', 'shmctl@GLIBC_2.0'] ['getgrent_r@@GLIBC_2.1.2', 'getgrent_r@GLIBC_2.0'] ['glob@@GLIBC_2.27', 'glob@GLIBC_2.0'] ['__lxstat64@@GLIBC_2.2', '__lxstat64@GLIBC_2.1'] ['fclose@@GLIBC_2.1', 'fclose@GLIBC_2.0'] ['gethostbyaddr_r@@GLIBC_2.1.2', 'gethostbyaddr_r@GLIBC_2.0'] ['realpath@@GLIBC_2.3', 'realpath@GLIBC_2.0'] ['gethostbyname_r@@GLIBC_2.1.2', 'gethostbyname_r@GLIBC_2.0'] ['getpwnam_r@@GLIBC_2.1.2', 'getpwnam_r@GLIBC_2.0'] ['readdir64@@GLIBC_2.2', 'readdir64@GLIBC_2.1'] ['__xstat64@@GLIBC_2.2', '__xstat64@GLIBC_2.1'] ['gethostbyname2_r@@GLIBC_2.1.2', 'gethostbyname2_r@GLIBC_2.0'] ['getgrgid_r@@GLIBC_2.1.2', 'getgrgid_r@GLIBC_2.0'] ['fopen@@GLIBC_2.1', 'fopen@GLIBC_2.0'] ['fmemopen@@GLIBC_2.22', 'fmemopen@GLIBC_2.2'] ['readdir64_r@@GLIBC_2.2', 'readdir64_r@GLIBC_2.1'] ['fopencookie@@GLIBC_2.2', 'fopencookie@GLIBC_2.0'] ['gethostent_r@@GLIBC_2.1.2', 'gethostent_r@GLIBC_2.0'] ['fdopen@@GLIBC_2.1', 'fdopen@GLIBC_2.0'] ['sched_getaffinity@@GLIBC_2.3.4', 'sched_getaffinity@GLIBC_2.3.3']
[Bug lto/84044] Spurious -Wodr warning with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84044
Arnaud Giersch changed:
What|Removed |Added
CC||arnaud.giersch at free dot fr
--- Comment #9 from Arnaud Giersch ---
Hi,
A similar warning appeared recently with a gcc9 snapshot with a slightly
modified code. The main difference seems to be the enum declaration. By
"recently", I mean late october or early november (2018).
a.cpp
=
struct B {
enum class E { V0, V1 };
virtual ~B();
E e;
};
B b;
int main() {}
b.cpp
=
struct B {
enum class E { V0, V1 };
virtual ~B();
E e;
};
B::~B() = default;
=
$ g++ -O2 -flto a.cpp b.cpp
a.cpp:2:14: warning: type 'E' violates the C++ One Definition Rule [-Wodr]
2 | enum class E { V0, V1 };
| ^
a.cpp:2:14: note: an enum with different values is defined in another
translation unit
a.cpp:4:11: warning: '__dt_del ' violates the C++ One Definition Rule [-Wodr]
4 | virtual ~B();
| ^
b.cpp:1:8: note: '__dt_del ' was previously declared here
1 | struct B {
|^
a.cpp:4:11: warning: '__dt_comp ' violates the C++ One Definition Rule [-Wodr]
4 | virtual ~B();
| ^
b.cpp:1:8: note: '__dt_comp ' was previously declared here
1 | struct B {
|^
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc-snapshot/libexec/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 20181110-2'
--with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++
--prefix=/usr/lib/gcc-snapshot --with-gcc-major-version-only --program-prefix=
--enable-shared --enable-linker-build-id --disable-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-plugin --with-system-zlib
--with-target-system-zlib --enable-objc-gc=auto --enable-multiarch
--disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --enable-checking=yes
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 9.0.0 20181110 (experimental) [trunk revision 266003] (Debian
20181110-2)
Regards,
Arnaud Giersch
[Bug c/88058] gcc fails to detect use of out of scope variable ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88058
Richard Biener changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-11-16
Ever confirmed|0 |1
Severity|normal |enhancement
--- Comment #1 from Richard Biener ---
Confirmed. There's nothing that can easily help - points-to analysis is
closest. With it's help and the clobber present one could warn, but I fear
the false positive rate would be quite high. Note that g() may not actually
touch *p2. Note the path n>=0 may never be taken at runtime.
This may be something to sanitize instead?
f (int n, char * p1)
{
int n_5(D) = n;
# PT = nonlocal null
char * p1_3(D) = p1;
char buf[10];
char * p2;
:
if (n_5(D) >= 0)
goto ; [INV]
else
goto ; [INV]
:
buf ={v} {CLOBBER};
:
# PT = nonlocal null { D.1967 } (escaped)
# p2_1 = PHI
# USE = nonlocal { D.1967 } (escaped)
# CLB = nonlocal { D.1967 } (escaped)
g (p2_1);
[Bug c++/88050] Add a warning for breaking the "Rule of Three"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88050
--- Comment #2 from Jonathan Wakely ---
Your example doesn't even compile, the destructor is private.
GCC now has -Wdeprecated-copy which warns for this fixed example:
struct Type
{
~Type()
{}
};
int main()
{
Type t;
Type tt = t;
t = tt;
}
r.cc: In function 'int main()':
r.cc:10:13: warning: implicitly-declared 'constexpr Type::Type(const Type&)' is
deprecated [-Wdeprecated-copy]
10 | Type tt = t;
| ^
r.cc:3:5: note: because 'Type' has user-provided 'Type::~Type()'
3 | ~Type()
| ^
r.cc:11:7: warning: implicitly-declared 'constexpr Type& Type::operator=(const
Type&)' is deprecated [-Wdeprecated-copy]
11 | t = tt;
| ^~
r.cc:3:5: note: because 'Type' has user-provided 'Type::~Type()'
3 | ~Type()
| ^
These warnings are given unless the copy constructor and copy assignment
operator are user-declared, which is pretty close to what you're requesting.
The warnings are only issued if the implicitly-declared special member
functions are actually used (because if they're never used then it doesn't
matter if they're defined or not).
I think this bug can be closed.
[Bug c++/87521] [C++][ABI] Tail padding not reused for non POD struct with defaulted/deleted special member function as per Itanium ABI on x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87521 --- Comment #6 from Jonathan Wakely --- Yes, on IRC Bruno already pointed out the problem with the comment 3 example. That doesn't change my mind, I still think it would be madness for an defaulted-on-first-declaration trivial destructor to change the type's layout.
[Bug debug/88046] [9 Regression] ICE in add_data_member_location_attribute at gcc/dwarf2out.c:19237 since r261885
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88046 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- 19236 /* Calculate the address of the offset. */ 19237 offset = tree_to_shwi (BINFO_VPTR_FIELD (decl)); 19238 gcc_assert (offset < 0); #1 0x013c98ad in tree_to_shwi (t=0x0) at ../../gcc/tree.c:7084 #2 0x009e4056 in add_data_member_location_attribute ( die=>, decl=, ctx=0x7fffce80) at ../../gcc/dwarf2out.c:19237 #3 0x009f3195 in gen_inheritance_die (binfo=, access=, type=, context_die=>) at ../../gcc/dwarf2out.c:24511 #4 0x009f44d1 in gen_member_die (type=, context_die=>) at ../../gcc/dwarf2out.c:24982 #5 0x009f4eb9 in gen_struct_or_union_type_die (type=, context_die=>, usage=DINFO_USAGE_DIR_USE) at ../../gcc/dwarf2out.c:25155 #6 0x009f599a in gen_tagged_type_die (type=, context_die=>, usage=DINFO_USAGE_DIR_USE) at ../../gcc/dwarf2out.c:25356 #7 0x009f62f1 in gen_type_die_with_usage (type=, context_die=>, usage=DINFO_USAGE_DIR_USE) at ../../gcc/dwarf2out.c:25551 #8 0x009f668e in gen_type_die (type=, context_die=>) at ../../gcc/dwarf2out.c:25605 #9 0x009d1c3e in modified_type_die (type=, cv_quals=0, reverse=false, context_die=>) at ../../gcc/dwarf2out.c:13368 #10 0x009ea658 in add_type_attribute ( object_die=>, type=, cv_quals=0, reverse=false, context_die=>) at ../../gcc/dwarf2out.c:21532 #11 0x009f0985 in gen_variable_die (decl=, origin=, context_die=>) at ../../gcc/dwarf2out.c:23774 #12 0x009f880d in gen_decl_die (decl=, origin=, ctx=0x0, context_die=>) at ../../gcc/dwarf2out.c:26297 #13 0x009f6d86 in process_scope_var (stmt=, decl=, origin=, context_die=>) at ../../gcc/dwarf2out.c:25758 #14 0x009f6e0f in decls_for_scope (stmt=, context_die=>, recurse=true) at ../../gcc/dwarf2out.c:25784 #15 0x009f1d75 in gen_lexical_block_die (stmt=, context_die=>) at ../../gcc/dwarf2out.c:24111 #16 0x009f6944 in gen_block_die (stmt=, context_die=>) at ../../gcc/dwarf2out.c:25690 #17 0x009f6f8c in decls_for_scope (stmt=, context_die=>, recurse=true) at ../../gcc/dwarf2out.c:25813 #18 0x009ef14e in gen_subprogram_die (decl=, context_die=) at ../../gcc/dwarf2out.c:23259 #19 0x009f841e in gen_decl_die (decl=, origin=, ctx=0x0, context_die=) at ../../gcc/dwarf2out.c:26214 #20 0x009f9b35 in dwarf2out_decl (decl=) at ../../gcc/dwarf2out.c:26782 #21 0x009f9b91 in dwarf2out_function_decl (decl=) at ../../gcc/dwarf2out.c:26797 #22 0x00ab7ea0 in rest_of_handle_final () at ../../gcc/final.c:4681 Bet the type is pruned and then re-added later or something similar.
[Bug c++/87521] [C++][ABI] Tail padding not reused for non POD struct with defaulted/deleted special member function as per Itanium ABI on x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87521 --- Comment #7 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #6) > Yes, on IRC Bruno already pointed out the problem with the comment 3 > example. That doesn't change my mind, I still think it would be madness for > an defaulted-on-first-declaration trivial destructor to change the type's > layout. Which is what Daveed says in the github issue.
[Bug rtl-optimization/87485] [9 Regression] Compile time hog w/ -O2 -fschedule-insns -fno-guess-branch-probability -fno-isolate-erroneous-paths-dereference -fno-omit-frame-pointer -fno-split-wide-type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87485 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Can't reproduce either: /opt/notnfs/gcc-bisect/obj/gcc/cc1.264727 -quiet -O2 -fschedule-insns -fno-guess-branch-probability -fno-isolate-erroneous-paths-dereference -fno-omit-frame-pointer -fno-split-wide-types -fno-tree-ccp -fno-tree-sra pr87485.c pr87485.c: In function ‘c8’: pr87485.c:19:23: warning: division by zero [-Wdiv-by-zero] 19 | *xh += fl < (e4 / 0); | ^ finishes instantly.
[Bug tree-optimization/87025] [9 Regression] ICE in add_record, at optinfo-emit-json.cc:175
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87025 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-11-16 CC||jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r263626.
[Bug c++/87989] [8/9 Regression] Calling operator T() invokes wrong conversion operator overload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87989 --- Comment #7 from Nathan Sidwell --- Author: nathan Date: Fri Nov 16 11:51:51 2018 New Revision: 266204 URL: https://gcc.gnu.org/viewcvs?rev=266204&root=gcc&view=rev Log: [PR c++/86246] ICE tsubst explicit operator call https://gcc.gnu.org/ml/gcc-patches/2018-11/msg01405.html PR c++/86246 PR c++/87989 * typeck.c (finish_class_member_access_expr): Conversion operator to dependent type is dependent. * g++.dg/template/pr86246.C: New. * g++.dg/template/pr87989.C: New. Modified: branches/gcc-8-branch/gcc/cp/ChangeLog branches/gcc-8-branch/gcc/cp/typeck.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug c++/86246] [8/9 Regression] Template dispatching error inside a template function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86246 --- Comment #10 from Nathan Sidwell --- Author: nathan Date: Fri Nov 16 11:51:51 2018 New Revision: 266204 URL: https://gcc.gnu.org/viewcvs?rev=266204&root=gcc&view=rev Log: [PR c++/86246] ICE tsubst explicit operator call https://gcc.gnu.org/ml/gcc-patches/2018-11/msg01405.html PR c++/86246 PR c++/87989 * typeck.c (finish_class_member_access_expr): Conversion operator to dependent type is dependent. * g++.dg/template/pr86246.C: New. * g++.dg/template/pr87989.C: New. Modified: branches/gcc-8-branch/gcc/cp/ChangeLog branches/gcc-8-branch/gcc/cp/typeck.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug c++/86246] [8/9 Regression] Template dispatching error inside a template function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86246 Nathan Sidwell changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Nathan Sidwell --- Fixed gcc-8 r266204.
[Bug tree-optimization/87025] [9 Regression] ICE in add_record, at optinfo-emit-json.cc:175
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87025 --- Comment #2 from Jakub Jelinek --- I think the note in question is from: if (dump_enabled_p ()) dump_printf_loc (MSG_NOTE, vect_location, "-->vectorizing phi: %G", phi); and the failed assertion is that m_scopes is empty. David, can you please have a look?
[Bug rtl-optimization/87918] [9 Regression] ICE in simplify_binary_operation, at simplify-rtx.c:2153 since r264688
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87918 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Fixed.
[Bug tree-optimization/88011] [9 regression] r266028 causes a bunch of go failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88011 --- Comment #10 from Richard Biener --- Author: rguenth Date: Fri Nov 16 12:20:05 2018 New Revision: 266205 URL: https://gcc.gnu.org/viewcvs?rev=266205&root=gcc&view=rev Log: 2018-11-16 Richard Biener PR tree-optimization/88011 * tree-vrp.c (extract_range_from_binary_expr): Fix error in replacing set_value_range_to_undefined and set_value_range_to_varying with method calls. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vrp.c
[Bug tree-optimization/88011] [9 regression] r266028 causes a bunch of go failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88011 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Richard Biener --- Fixed.
[Bug testsuite/88053] [9 regression] g++.dg/lto/pr54625-1.C fails with r266194
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88053 --- Comment #3 from Richard Biener --- Author: rguenth Date: Fri Nov 16 12:22:48 2018 New Revision: 266206 URL: https://gcc.gnu.org/viewcvs?rev=266206&root=gcc&view=rev Log: 2018-11-16 Richard Biener PR testsuite/88053 * g++.dg/lto/pr54625-2_0.c: Add -w. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/lto/pr54625-2_0.c
[Bug c++/88050] Add a warning for breaking the "Rule of Three"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88050 --- Comment #3 from Daniel Gutson --- It is not the same and doesn't cover important cases: for example, the opposite one, there is a nontrivial copy ctor implementation but there is no nontrivial dtor. Or even between the special ctors, or there is move ctor but no move assignment (and viceversa).
[Bug rtl-optimization/87485] [9 Regression] Compile time hog w/ -O2 -fschedule-insns -fno-guess-branch-probability -fno-isolate-erroneous-paths-dereference -fno-omit-frame-pointer -fno-split-wide-type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87485 --- Comment #6 from Arseny Solokha --- There must be something wrong w/ the way I configure gcc, then. It takes indefinite time compiling the testcase only at -O2 or -Os and finishes instantly at any other optimization level. But it also finishes instantly when I add -fstack-protector or -fno-stack-protector - strangely, either of them. What additional info should I provide? config.status, maybe?
[Bug lto/88004] [9 Regression] lto1: error: node differs from node->decl->decl_with_vis.symtab_node
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88004 --- Comment #3 from Martin Liška --- Author: marxin Date: Fri Nov 16 12:49:32 2018 New Revision: 266207 URL: https://gcc.gnu.org/viewcvs?rev=266207&root=gcc&view=rev Log: Fix ICE in lto_symtab_merge_symbols_1 (PR lto/88004). 2018-11-16 Martin Liska PR lto/88004 * lto-symtab.c (lto_symtab_merge_symbols_1): Do not call lto_symtab_symbol_p as it does checking of transparent alias. These needs to be also merged in the function. Modified: trunk/gcc/lto/ChangeLog trunk/gcc/lto/lto-symtab.c
[Bug gcov-profile/88045] Call to std::accumulate causes gcov to crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88045 Martin Liška changed: What|Removed |Added Known to work||9.0 Known to fail|9.0 | --- Comment #2 from Martin Liška --- So the problem is that on gcc-8 branch there's missing commit r261728 that fixes location of lambdas. What happens is that a lambda ends on a line before where it starts. So for gcc-8 branch a workaround would be needed.
[Bug rtl-optimization/87485] [9 Regression] Compile time hog w/ -O2 -fschedule-insns -fno-guess-branch-probability -fno-isolate-erroneous-paths-dereference -fno-omit-frame-pointer -fno-split-wide-type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87485 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #7 from Alexander Monakov --- It appears you are building via portage and thus have Gentoo patches applied?
[Bug rtl-optimization/88033] [9 Regression] ICE on valid code at -O2 and -O3 on x86-64-linux-gnu: in remove_some_program_points_and_update_live_ranges, at lra-lives.c:1179
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88033 Peter Bergner changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot gnu.org --- Comment #2 from Peter Bergner --- Mine
[Bug ipa/87706] Inlined functions trigger invalid -Wmissing-profile warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87706 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #5 from Eric Gallager --- (In reply to Martin Liška from comment #4) > Assigning to Honza after we discussed that. So, this is kind of off-topic, but I've been wondering for a while, so: How exactly did Honza get the "Honza" nickname, anyways? I don't see how either "Jan" or "Hubicka" would easily transform to "Honza"...
[Bug debug/88046] [9 Regression] ICE in add_data_member_location_attribute at gcc/dwarf2out.c:19237 since r261885
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88046 --- Comment #2 from rguenther at suse dot de --- On Fri, 16 Nov 2018, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88046 > > Jakub Jelinek changed: > >What|Removed |Added > > CC||jakub at gcc dot gnu.org > > --- Comment #1 from Jakub Jelinek --- > 19236 /* Calculate the address of the offset. */ > 19237 offset = tree_to_shwi (BINFO_VPTR_FIELD (decl)); > 19238 gcc_assert (offset < 0); Yeah... > #1 0x013c98ad in tree_to_shwi (t=0x0) at ../../gcc/tree.c:7084 > #2 0x009e4056 in add_data_member_location_attribute ( > die= DW_TAG_structure_type>>, decl=, > ctx=0x7fffce80) at ../../gcc/dwarf2out.c:19237 > #3 0x009f3195 in gen_inheritance_die (binfo= 0x7fffefa81000>, access=, > type=, > context_die= >) at ../../gcc/dwarf2out.c:24511 > #4 0x009f44d1 in gen_member_die (type= b>, > context_die= >) at ../../gcc/dwarf2out.c:24982 > #5 0x009f4eb9 in gen_struct_or_union_type_die (type= 0x7fffefe7a3f0 b>, > context_die= >, usage=DINFO_USAGE_DIR_USE) > at ../../gcc/dwarf2out.c:25155 > #6 0x009f599a in gen_tagged_type_die (type= 0x7fffefe7a3f0 > b>, > context_die= >, usage=DINFO_USAGE_DIR_USE) > at ../../gcc/dwarf2out.c:25356 > #7 0x009f62f1 in gen_type_die_with_usage (type= 0x7fffefe7a3f0 b>, > context_die= >, usage=DINFO_USAGE_DIR_USE) > at ../../gcc/dwarf2out.c:25551 > #8 0x009f668e in gen_type_die (type=, > context_die= >) at ../../gcc/dwarf2out.c:25605 > #9 0x009d1c3e in modified_type_die (type= b>, cv_quals=0, reverse=false, > context_die= >) at ../../gcc/dwarf2out.c:13368 > #10 0x009ea658 in add_type_attribute ( > object_die= >, type= 0x7fffefe7a3f0 > b>, > cv_quals=0, reverse=false, context_die= DW_TAG_lexical_block >) > at ../../gcc/dwarf2out.c:21532 The issue is this frame though - we shouldn't generate any type DIEs late or at least, if we are forced to, tune down extremely the fanciness of that (no inheritance or type fields, etc.). See the linked bug about -g0 at compile and -g at link-time. Given we _do_ re-create some types late (the variably-modified ones because the dwarf/gdb support isn't there yet for the fancy way), it's not easy to simply early return or ICE.
[Bug ipa/87706] Inlined functions trigger invalid -Wmissing-profile warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87706 --- Comment #6 from Martin Liška --- (In reply to Eric Gallager from comment #5) > (In reply to Martin Liška from comment #4) > > Assigning to Honza after we discussed that. > > So, this is kind of off-topic, but I've been wondering for a while, so: How > exactly did Honza get the "Honza" nickname, anyways? I don't see how either > "Jan" or "Hubicka" would easily transform to "Honza"... https://en.wikipedia.org/wiki/Honza
[Bug lto/88004] [9 Regression] lto1: error: node differs from node->decl->decl_with_vis.symtab_node
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88004 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Martin Liška --- Fixed.
[Bug rtl-optimization/87485] [9 Regression] Compile time hog w/ -O2 -fschedule-insns -fno-guess-branch-probability -fno-isolate-erroneous-paths-dereference -fno-omit-frame-pointer -fno-split-wide-type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87485 --- Comment #8 from Arseny Solokha --- (In reply to Alexander Monakov from comment #7) > It appears you are building via portage and thus have Gentoo patches applied? Yes, I build weekly snapshots via Portage for convenience. But I use modified toolchain.eclass, and of course never apply Gentoo patches to them. My snapshots are vanilla. Gentoo's unpatched toolchain.eclass adds custom branding, among other things, which can be seen in -v output from my system compiler (compare it w/ the one from snapshot in comment 3): % gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-unknown-linux-gnu/8.2.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-8.2.0-r4/work/gcc-8.2.0/configure --host=x86_64-unknown-linux-gnu --build=x86_64-unknown-linux-gnu --prefix=/usr --bindir=/usr/x86_64-unknown-linux-gnu/gcc-bin/8.2.0 --includedir=/usr/lib/gcc/x86_64-unknown-linux-gnu/8.2.0/include --datadir=/usr/share/gcc-data/x86_64-unknown-linux-gnu/8.2.0 --mandir=/usr/share/gcc-data/x86_64-unknown-linux-gnu/8.2.0/man --infodir=/usr/share/gcc-data/x86_64-unknown-linux-gnu/8.2.0/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-unknown-linux-gnu/8.2.0/include/g++-v8 --with-python-dir=/share/gcc-data/x86_64-unknown-linux-gnu/8.2.0/python --enable-languages=c,c++ --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --disable-nls --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo Hardened 8.2.0-r4 p1.5' --enable-esp --enable-libstdcxx-time --disable-libstdcxx-pch --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --disable-multilib --with-multilib-list=m64 --disable-altivec --disable-fixed-point --enable-targets=all --enable-libgomp --disable-libmudflap --disable-libssp --disable-libmpx --disable-systemtap --enable-vtable-verify --enable-libvtv --disable-libquadmath --enable-lto --with-isl --disable-isl-version-check --disable-libsanitizer --enable-default-pie --enable-default-ssp Thread model: posix gcc version 8.2.0 (Gentoo Hardened 8.2.0-r4 p1.5) On the last line here you can see custom branding (Gentoo Hardened) and the Gentoo patchset verson (1.5).
[Bug libstdc++/87618] [9 Regression] Missing symbol for std::__cxx11::basic_stringbuf, std::allocator >::basic_stringbuf()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87618 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Assuming this is fixed then.
[Bug libstdc++/87618] [9 Regression] Missing symbol for std::__cxx11::basic_stringbuf, std::allocator >::basic_stringbuf()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87618 --- Comment #6 from Jonathan Wakely --- Yes, I forgot to close it.
[Bug lto/84044] Spurious -Wodr warning with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84044 --- Comment #10 from Martin Liška --- > Thread model: posix > gcc version 9.0.0 20181110 (experimental) [trunk revision 266003] (Debian > 20181110-2) > > Regards, > Arnaud Giersch The warning appeared again on trunk in r265875 Author: hubicka * ipa-devirt.c (odr_types_equivalent_p): Expect constants than const decls in TREE_VALUE of enum. (dump_type_inheritance_graph): Improve duplicate dumping. (free_enum_values): New. (build_type_inheritance_graph): Use it. * tree.c (free_lang_data_in_type): Free TYPE_VALUES of enums which are not main variants or not ODR types. (verify_type_variant): Expect variants to have no TYPE_VALUES.
[Bug other/88057] libdecnumber/decCommon.c:479: use of out of scope variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88057 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-11-16 CC||marxin at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Interesting, what tool have you used to detect that? That should be detected by use-after-scope in ASAN.
[Bug debug/83941] Debug info generated with -flto contains useless forwarders
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83941 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Richard Biener --- Not going to backport.
[Bug gcov-profile/88045] Call to std::accumulate causes gcov to crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88045 --- Comment #3 from Sergio Losilla --- I see, thanks. Well then, I guess I'll stick to the workaround. Good to know it is already fixed in version 9.
[Bug gcov-profile/88045] Call to std::accumulate causes gcov to crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88045 --- Comment #4 from Martin Liška --- (In reply to Sergio Losilla from comment #3) > I see, thanks. Well then, I guess I'll stick to the workaround. Good to know > it is already fixed in version 9. Thanks. Next GCC 8.3 will have a workaround, so you won't be forced to update to GCC 9.1. Anyway, thanks for the bug report.
[Bug target/83479] Register spilling in AVX code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83479 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Known to work||9.0 Resolution|--- |FIXED --- Comment #10 from Richard Biener --- GCC 9 doens't spill anymore.
[Bug tree-optimization/88011] [9 regression] r266028 causes a bunch of go failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88011 --- Comment #12 from Ian Lance Taylor --- Thanks!
[Bug middle-end/83215] C++: struct with char-array assumed to alias with everything
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83215
Richard Biener changed:
What|Removed |Added
Keywords||alias, missed-optimization
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2018-11-16
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #3 from Richard Biener ---
So in the end it is
tree
component_uses_parent_alias_set_from (const_tree t)
{
...
if (get_alias_set (TREE_TYPE (TREE_OPERAND (t, 0))) == 0)
found = t;
that causes this. The above is required for may_alias annotated types
(so history tells me, but the testcase added for the change doesn't fail
when removing the above). Today we handle may_alias via
reference_alias_ptr_type_1 running into a dereference and checking the
pointer for a ref-all type.
[Bug c/88058] gcc fails to detect use of out of scope variable ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88058
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #2 from Martin Liška ---
ASAN can help in run-time:
$ cat pr88058.c
void g( char *a)
{
*a = 'x';
}
void f( int n, char * p1)
{
char * p2;
p2 = p1;
if (n >= 0)
{
char buf[ 10];
p2 = buf;
}
g( p2); // Bang !
}
int main()
{
f(0, 0);
return 0;
}
$ gcc pr88058.c -fsanitize=address && ./a.out
=
==31750==ERROR: AddressSanitizer: stack-use-after-scope on address
0x7fffdb80 at pc 0x00401182 bp 0x7fffdb10 sp 0x7fffdb08
WRITE of size 1 at 0x7fffdb80 thread T0
#0 0x401181 in g (/home/marxin/Programming/testcases/a.out+0x401181)
#1 0x401254 in f (/home/marxin/Programming/testcases/a.out+0x401254)
#2 0x4012ba in main (/home/marxin/Programming/testcases/a.out+0x4012ba)
#3 0x76c71fea in __libc_start_main ../csu/libc-start.c:308
#4 0x401099 in _start (/home/marxin/Programming/testcases/a.out+0x401099)
Address 0x7fffdb80 is located in stack of thread T0 at offset 32 in frame
#0 0x40119b in f (/home/marxin/Programming/testcases/a.out+0x40119b)
This frame has 1 object(s):
[32, 42) 'buf' <== Memory access at offset 32 is inside this variable
HINT: this may be a false positive if your program uses some custom stack
unwind mechanism or swapcontext
(longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-use-after-scope
(/home/marxin/Programming/testcases/a.out+0x401181) in g
Shadow bytes around the buggy address:
0x10007fff7b20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007fff7b30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007fff7b40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007fff7b50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007fff7b60: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
=>0x10007fff7b70:[f8]f8 f2 f2 f3 f3 f3 f3 00 00 00 00 00 00 00 00
0x10007fff7b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007fff7b90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007fff7ba0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007fff7bb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007fff7bc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user:f7
Container overflow: fc
Array cookie:ac
Intra object redzone:bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone:cb
==31750==ABORTING
[Bug middle-end/88059] New: Spurious stringop-overflow warning with strlen, malloc and strncpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88059
Bug ID: 88059
Summary: Spurious stringop-overflow warning with strlen, malloc
and strncpy
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: listes at defendingthemusic dot fr
Target Milestone: ---
The following combination of `strlen`, `malloc` and `strncpy` results in a
spurious warning when compiling with optimisation (at least -O2):
```
$ cat bug.c
#include
#include
#include
char* copy_name (const char* src)
{
size_t len = strlen(src) + 1;
char* dest = malloc(len);
if (dest)
strncpy(dest, src, len);
return dest;
}
int main (void)
{
const char* name = "Name";
char* copy = copy_name(name);
printf("%s\n", copy);
return 0;
}
$ gcc -O2 bug.c
bug.c: In function ‘copy_name’:
bug.c:10:3: warning: ‘strncpy’ specified bound depends on the length of the
source argument [-Wstringop-overflow=]
strncpy(dest, src, len);
^~~
bug.c:7:15: note: length computed here
size_t len = strlen(src) + 1;
^~~
```
This is actually safe since the result of `strlen` is used for both `malloc`
and `strncpy`.
[Bug tree-optimization/87546] [9 Regression] Gcc miscompiles at -O3 on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87546 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
[Bug libstdc++/87855] std::optional only copy-constructible if T is trivially copy-constructible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87855 --- Comment #6 from fiesh at zefix dot tv --- Again, fixes the issue for me with clang!
[Bug c++/87269] [9 Regression] ICE in tsubst_copy, at cp/pt.c:15475 starting from r261802
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87269 --- Comment #8 from Nathan Sidwell --- Author: nathan Date: Fri Nov 16 15:01:55 2018 New Revision: 266210 URL: https://gcc.gnu.org/viewcvs?rev=266210&root=gcc&view=rev Log: [PR c++/87269] Mark string operator overload in template defn. https://gcc.gnu.org/ml/gcc-patches/2018-11/msg01458.html PR c++/87269 * parser.c (lookup_literal_operator): Mark overload for keeping when inside template. Refactor. * g++.dg/lookup/pr87269.C: New. Added: trunk/gcc/testsuite/g++.dg/lookup/pr87269.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
[Bug c++/87269] [9 Regression] ICE in tsubst_copy, at cp/pt.c:15475 starting from r261802
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87269 Nathan Sidwell changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Nathan Sidwell --- Fixed trunk. 87814 is different.
[Bug go/88060] New: ../../../gcc-8.2.0/libgo/go/syscall/libcall_linux_utimesnano.go:17:18: error: reference to undefined name ‘_AT_FDCWD’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88060
Bug ID: 88060
Summary: ../../../gcc-8.2.0/libgo/go/syscall/libcall_linux_utim
esnano.go:17:18: error: reference to undefined name
‘_AT_FDCWD’
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: mfe at live dot de
CC: cmang at google dot com
Target Milestone: ---
Created attachment 45021
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45021&action=edit
libgo config log
Configure:
gcc-compiled8# ../gcc-8.2.0/configure CC=/opt/gcc-7.1/bin/gcc
CXX=/opt/gcc-7.1/bin/g++ --enable-languages=c,c++,go --prefix=/opt/gcc-8.2/
--with-cpu=v7 --with-mpc=/usr/local --with-mpfr=/usr/local
--with-gmp=/usr/local --with-isl=/usr/local/ --disable-libstdcxx-pch
--disable-linux-futex --disable-libsanitizer --enable-__cxa_atexit
--with-system-zlib --enable-nls --enable-clocale=gnu --enable-debug
--disable-doc --disable-libcilkrts --disable-libitm
System:Sparc
Error:
libtool: compile: /backup/gcc-compiled8/./gcc/gccgo
-B/backup/gcc-compiled8/./gcc/ -B/opt/gcc-8.2/sparc-unknown-linux-gnu/bin/
-B/opt/gcc-8.2/sparc-unknown-linux-gnu/lib/ -isystem
/opt/gcc-8.2/sparc-unknown-linux-gnu/include -isystem
/opt/gcc-8.2/sparc-unknown-linux-gnu/sys-include -O2 -g -I . -c
-fgo-pkgpath=syscall ../../../gcc-8.2.0/libgo/go/syscall/dirent.go
../../../gcc-8.2.0/libgo/go/syscall/endian_big.go
../../../gcc-8.2.0/libgo/go/syscall/env_unix.go
../../../gcc-8.2.0/libgo/go/syscall/errstr_linux.go
../../../gcc-8.2.0/libgo/go/syscall/exec_linux.go
../../../gcc-8.2.0/libgo/go/syscall/exec_unix.go
../../../gcc-8.2.0/libgo/go/syscall/libcall_linux.go
../../../gcc-8.2.0/libgo/go/syscall/libcall_linux_utimesnano.go
../../../gcc-8.2.0/libgo/go/syscall/libcall_posix.go
../../../gcc-8.2.0/libgo/go/syscall/libcall_posix_largefile.go
../../../gcc-8.2.0/libgo/go/syscall/libcall_support.go
../../../gcc-8.2.0/libgo/go/syscall/libcall_uname.go
../../../gcc-8.2.0/libgo/go/syscall/libcall_wait4.go
../../../gcc-8.2.0/libgo/go/syscall/lsf_linux.go
../../../gcc-8.2.0/libgo/go/syscall/msan0.go
../../../gcc-8.2.0/libgo/go/syscall/net.go
../../../gcc-8.2.0/libgo/go/syscall/netlink_linux.go
../../../gcc-8.2.0/libgo/go/syscall/setuidgid_linux.go
../../../gcc-8.2.0/libgo/go/syscall/sleep_select.go
../../../gcc-8.2.0/libgo/go/syscall/sockcmsg_linux.go
../../../gcc-8.2.0/libgo/go/syscall/sockcmsg_unix.go
../../../gcc-8.2.0/libgo/go/syscall/socket.go
../../../gcc-8.2.0/libgo/go/syscall/socket_linux.go
../../../gcc-8.2.0/libgo/go/syscall/socket_linux_type.go
../../../gcc-8.2.0/libgo/go/syscall/socket_posix.go
../../../gcc-8.2.0/libgo/go/syscall/str.go
../../../gcc-8.2.0/libgo/go/syscall/syscall.go
../../../gcc-8.2.0/libgo/go/syscall/syscall_errno.go
../../../gcc-8.2.0/libgo/go/syscall/syscall_linux.go
../../../gcc-8.2.0/libgo/go/syscall/syscall_unix.go
../../../gcc-8.2.0/libgo/go/syscall/timestruct.go libcalls.go sysinfo.go
syscall_arch.go epoll.go -fPIC -o .libs/syscall.o
../../../gcc-8.2.0/libgo/go/syscall/libcall_linux_utimesnano.go:17:18: error:
reference to undefined name ‘_AT_FDCWD’
err = utimensat(_AT_FDCWD, path, (*[2]Timespec)(unsafe.Pointer(&ts[0])), 0)
^
../../../gcc-8.2.0/libgo/go/syscall/socket_linux.go:173:22: error: reference to
undefined name ‘SizeofIPv6MTUInfo’
vallen := Socklen_t(SizeofIPv6MTUInfo)
^
../../../gcc-8.2.0/libgo/go/syscall/socket_linux.go:171:50: error: use of
undefined type ‘IPv6MTUInfo’
func GetsockoptIPv6MTUInfo(fd, level, opt int) (*IPv6MTUInfo, error) {
^
../../../gcc-8.2.0/libgo/go/syscall/socket_linux.go:171:50: error: use of
undefined type ‘IPv6MTUInfo’
make[4]: *** [Makefile:3324: syscall.lo] Error 1
make[4]: Leaving directory
'/c/backup/gcc-compiled8/sparc-unknown-linux-gnu/libgo'
make[3]: *** [Makefile:2690: all-recursive] Error 1
make[3]: Leaving directory
'/c/backup/gcc-compiled8/sparc-unknown-linux-gnu/libgo'
make[2]: *** [Makefile:1415: all] Error 2
make[2]: Leaving directory
'/c/backup/gcc-compiled8/sparc-unknown-linux-gnu/libgo'
make[1]: *** [Makefile:19279: all-target-libgo] Error 2
[Bug fortran/88052] Format contravening f2008 constraint C1002 permitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88052 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P5 Status|UNCONFIRMED |NEW Last reconfirmed||2018-11-16 CC||jvdelisle at gcc dot gnu.org Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #1 from Dominique d'Humieres --- Confirmed from at least 4.8 up to trunk (9.0). The missing comma is diagnosed at compile time for print "(AF9.6)", 'pi =',4*atan(1.0) or print 10, 'pi =',4*atan(1.0) 10 format(AF9.6) AFAIU for print fmt, 'pi =',4*atan(1.0) the parsing of fmt is done at run time without provision for standard checking. This is related to pr28397 and pr35844, both rotting since a very long time.
[Bug go/88060] ../../../gcc-8.2.0/libgo/go/syscall/libcall_linux_utimesnano.go:17:18: error: reference to undefined name ‘_AT_FDCWD’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88060 --- Comment #1 from Ian Lance Taylor --- Can you attach the contents of sparc-unknown-linux-gnu/libgo/gen-sysinfo.go from your build directory? Does the C header file on your system define AT_FDCWD? (It normally comes from .) If not, why not? Where is it defined?
[Bug tree-optimization/88015] [9 Regression] ICE in dump_printf_loc, at dumpfile.c:1287
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88015 --- Comment #8 from David Malcolm --- Thanks!
[Bug c++/88061] New: section attributes of variable templates are ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88061
Bug ID: 88061
Summary: section attributes of variable templates are ignored
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: henrik-public at gmx dot net
Target Milestone: ---
When providing a variable template with a section attribute its instantiations
do not appear in the specified section:
==
template
[[gnu::section(".my_data")]] const unsigned g_my_data {x};
template const unsigned g_my_data<0xf0f0f0f0>;
==
$ g++-7 -c main.cpp -o main.o -std=c++14
$ objdump main.o --full-content
main.o: Format elf64-x86-64
Section .group:
0100 0500
Section .rodata._Z9g_my_dataILj4042322160EE:
f0f0f0f0
Section .comment:
00474343 3a202855 62756e74 7520372e .GCC: (Ubuntu 7.
0010 332e302d 32337562 756e7475 327e3136 3.0-23ubuntu2~16
0020 2e30342e 796f726b 30292037 2e332e30 .04.york0) 7.3.0
0030 00 .
[Bug tree-optimization/87546] [9 Regression] Gcc miscompiles at -O3 on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87546
--- Comment #5 from Jakub Jelinek ---
So, I think the bug is in vect_look_through_possible_promotion, which doesn't
do what it claims to do is that what it returns can be cast to unprom->type and
then promoted to final precision and that it is the same as the original cast
sequence.
Here we have:
_39 = (long int) iftmp.0_19;
in the loop and
_4 = _2 >> a.4_3;
iftmp.0_19 = (signed char) _4;
before the loop, with
int _4;
signed char iftmp.0_19;
long int _39;
and we return _4 and unprom is { _4, int, vect_external_def, NULL }
(NULL caster because this is already outside of the loop).
(long int) (int) _4 is not equivalent to (long int) (signed char) (int) _4
though, so we should have returned iftmp.0_19 in this case and unprom {
iftmp.0_19, signed char, vect_external_def, caster }.
[Bug c++/86747] [8/9 Regression] rejects-valid with redundant friend declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86747 Alexandre Oliva changed: What|Removed |Added Status|NEW |ASSIGNED CC||aoliva at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot gnu.org --- Comment #4 from Alexandre Oliva --- Created attachment 45022 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45022&action=edit candidate patch When entering the context of the declaration to look up a similar member, we're entering the context of the A template rather than of the A instantiation, because context hasn't been tsubsted yet. The declaration within the A template obviously won't match the substituted A scope in the nested template parm declaration.
[Bug go/88060] ../../../gcc-8.2.0/libgo/go/syscall/libcall_linux_utimesnano.go:17:18: error: reference to undefined name ‘_AT_FDCWD’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88060 martin changed: What|Removed |Added CC||mfe at live dot de --- Comment #2 from martin --- Created attachment 45023 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45023&action=edit gen-sysinfo.go (In reply to Ian Lance Taylor from comment #1) > Can you attach the contents of sparc-unknown-linux-gnu/libgo/gen-sysinfo.go > from your build directory? > > Does the C header file on your system define AT_FDCWD? (It > normally comes from .) If not, why not? Where is it > defined? I found the file in /usr/include/fcntl.h which does not define AT_FDCWD. The content of it: /* Copyright (C) 1991,1992,1994-2001,2003 Free Software Foundation, Inc. This file is part of the GNU C Library. The GNU C Library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. The GNU C Library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public License along with the GNU C Library; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. */ /* * POSIX Standard: 6.5 File Control Operations */ #ifndef _FCNTL_H #define _FCNTL_H1 #include /* This must be early so can define types winningly. */ __BEGIN_DECLS /* Get the definitions of O_*, F_*, FD_*: all the numbers and flag bits for `open', `fcntl', et al. */ #include /* For XPG all symbols from should also be available. */ #ifdef __USE_XOPEN # include #endif #ifdef __USE_MISC # ifndef R_OK /* Verbatim from . Ugh. */ /* Values for the second argument to access. These may be OR'd together. */ # define R_OK 4 /* Test for read permission. */ # define W_OK 2 /* Test for write permission. */ # define X_OK 1 /* Test for execute permission. */ # define F_OK 0 /* Test for existence. */ # endif #endif /* Use misc. */ /* XPG wants the following symbols. */ #ifdef __USE_XOPEN /* has the same definitions. */ # define SEEK_SET 0 /* Seek from beginning of file. */ # define SEEK_CUR 1 /* Seek from current position. */ # define SEEK_END 2 /* Seek from end of file. */ #endif /* XPG */ /* Do the file control operation described by CMD on FD. The remaining arguments are interpreted depending on CMD. This function is a cancellation point and therefore not marked with __THROW. */ extern int fcntl (int __fd, int __cmd, ...); /* Open FILE and return a new file descriptor for it, or -1 on error. OFLAG determines the type of access used. If O_CREAT is on OFLAG, the third argument is taken as a `mode_t', the mode of the created file. This function is a cancellation point and therefore not marked with __THROW. */ #ifndef __USE_FILE_OFFSET64 extern int open (__const char *__file, int __oflag, ...); #else # ifdef __REDIRECT extern int __REDIRECT (open, (__const char *__file, int __oflag, ...), open64); # else # define open open64 # endif #endif #ifdef __USE_LARGEFILE64 extern int open64 (__const char *__file, int __oflag, ...); #endif /* Create and open FILE, with mode MODE. This takes an `int' MODE argument because that is what `mode_t' will be widened to. This function is a cancellation point and therefore not marked with __THROW. */ #ifndef __USE_FILE_OFFSET64 extern int creat (__const char *__file, __mode_t __mode); #else # ifdef __REDIRECT extern int __REDIRECT (creat, (__const char *__file, __mode_t __mode), creat64); # else # define creat creat64 # endif #endif #ifdef __USE_LARGEFILE64 extern int creat64 (__const char *__file, __mode_t __mode); #endif #if !defined F_LOCK && (defined __USE_MISC || (defined __USE_XOPEN_EXTENDED \ && !defined __USE_POSIX)) /* NOTE: These declarations also appear in ; be sure to keep both files consistent. Some systems have them there and some here, and some software depends on the macros being defined without including both. */ /* `lockf' is a simpler interface to the locking facilities of `fcntl'. LEN is always relative to the current file position. The CMD argument is one of the following. */ # define F_ULOCK 0 /* Unlock a previously locked region. */ # define F_LOCK 1 /* Lock a region for exclusive use. */ # define F_TLOCK 2
[Bug c/88062] New: tgmath with fadd vs faddl done wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88062
Bug ID: 88062
Summary: tgmath with fadd vs faddl done wrong
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: tydeman at tybor dot com
Target Milestone: ---
/*
* Type generic wrong for faddl()
* 64-bit Fedora Linux 29 on Intel i5
* gcc 8.2.1-5
*/
/* Tell implementation that we want FP extensions */
#define __STDC_WANT_IEC_60559_BFP_EXT__ 1
#include
#include
#include
#include
int main(void){
float specific, generic;
specific = (faddl)(INFINITY,-LDBL_MAX); /* inf */
generic = fadd( INFINITY,-LDBL_MAX); /* nan */
(void)printf("specific=%f, generic=%f\n", specific, generic);
return 0;
}
[Bug go/88060] ../../../gcc-8.2.0/libgo/go/syscall/libcall_linux_utimesnano.go:17:18: error: reference to undefined name ‘_AT_FDCWD’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88060 --- Comment #3 from martin --- Created attachment 45024 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45024&action=edit /usr/include/bits/fcntl.h I found also: /usr/include/asm-sparc/fcntl.h /usr/include/asm/fcntl.h /usr/include/asm-generic/fcntl.h /usr/include/asm-sparc64/fcntl.h /usr/include/linux/fcntl.h /usr/include/bits/fcntl.h /usr/include/fcntl.h /usr/include/sys/fcntl.h Attache is the content of /usr/include/bits/fcntl.h
[Bug go/88060] ../../../gcc-8.2.0/libgo/go/syscall/libcall_linux_utimesnano.go:17:18: error: reference to undefined name ‘_AT_FDCWD’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88060 --- Comment #4 from martin --- Created attachment 45025 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45025&action=edit /usr/include/linux/fcntl.h I found the AT_FDCWD in the file /usr/include/linux/fcntl.h
[Bug tree-optimization/87546] [9 Regression] Gcc miscompiles at -O3 on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87546 --- Comment #6 from Jakub Jelinek --- Created attachment 45026 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45026&action=edit gcc9-pr87546.patch Untested fix.
[Bug libbacktrace/88063] New: Libbacktrace leak on dwarf read failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88063
Bug ID: 88063
Summary: Libbacktrace leak on dwarf read failure
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libbacktrace
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
CC: ian at gcc dot gnu.org
Target Milestone: ---
I noticed in build_address_map that we allocate a struct unit:
...
u = ((struct unit *)
backtrace_alloc (state, sizeof *u, error_callback, data));
...
and deallocate it if find_address_ranges fails:
...
if (!find_address_ranges (state, base_address, &unit_buf,
dwarf_str, dwarf_str_size,
dwarf_ranges, dwarf_ranges_size,
is_bigendian, error_callback, data,
u, addrs, altlink))
{
free_abbrevs (state, &u->abbrevs, error_callback, data);
backtrace_free (state, u, sizeof *u, error_callback, data);
goto fail;
}
...
However, the allocation and deallocation is done in a loop over units, so if
find_address_ranges succeeds for the first unit, but fails for the second, then
only the first struct unit is freed, and the second struct unit is leaked.
[Bug libbacktrace/88063] Libbacktrace leak on dwarf read failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88063 --- Comment #1 from Tom de Vries --- Created attachment 45027 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45027&action=edit Detection patch Output: ... $ ./btest 2>&1 | sed 's%/.*/%%' alloc at state.c:66: addr: 0x7f9addf62000, size: 72, allocs: 1 alloc at backtrace.c:118: addr: 0x7f9addf61000, size: 4096, allocs: 2 free at backtrace.c:123: addr: 0x7f9addf61000, size: 4096, allocs: 1 alloc at elf.c:2952: addr: 0x7f9addf61000, size: 24, allocs: 2 alloc at elf.c:622: addr: 0x7f9addf57000, size: 5160, allocs: 3 alloc at elf.c:836: addr: 0x7f9addf58428, size: 73, allocs: 4 free at elf.c:861: addr: 0x7f9addf58428, size: 73, allocs: 3 alloc at dwarf.c:1074: addr: 0x7f9addf58428, size: 32, allocs: 4 alloc at dwarf.c:1116: addr: 0x7f9addf58478, size: 56, allocs: 5 alloc at dwarf.c:1481: addr: 0x7f9addf584b0, size: 120, allocs: 6 alloc at dwarf.c:1074: addr: 0x7f9addf586a8, size: 160, allocs: 7 alloc at dwarf.c:1116: addr: 0x7f9addf58748, size: 40, allocs: 8 alloc at dwarf.c:1116: addr: 0x7f9addf58770, size: 24, allocs: 9 alloc at dwarf.c:1116: addr: 0x7f9addf58788, size: 24, allocs: 10 alloc at dwarf.c:1116: addr: 0x7f9addf587a0, size: 8, allocs: 11 alloc at dwarf.c:1116: addr: 0x7f9addf587a8, size: 48, allocs: 12 alloc at dwarf.c:1481: addr: 0x7f9addf587d8, size: 120, allocs: 13 free at dwarf.c:646: addr: 0x7f9addf58748, size: 40, allocs: 12 free at dwarf.c:646: addr: 0x7f9addf58770, size: 24, allocs: 11 free at dwarf.c:646: addr: 0x7f9addf58788, size: 24, allocs: 10 free at dwarf.c:646: addr: 0x7f9addf587a0, size: 8, allocs: 9 free at dwarf.c:646: addr: 0x7f9addf587a8, size: 48, allocs: 8 free at dwarf.c:649: addr: 0x7f9addf586a8, size: 160, allocs: 7 free at dwarf.c:1510: addr: 0x7f9addf587d8, size: 120, allocs: 6 free at dwarf.c:649: addr: (nil), size: 0, allocs: 6 free at dwarf.c:646: addr: 0x7f9addf58478, size: 56, allocs: 5 free at dwarf.c:649: addr: 0x7f9addf58428, size: 32, allocs: 4 Expected 3 allocs, but have: 4 ... This is the struct unit alloc without corresponding free: ... alloc at dwarf.c:1481: addr: 0x7f9addf584b0, size: 120, allocs: 6 ...
[Bug libbacktrace/88063] Libbacktrace leak on dwarf read failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88063 --- Comment #2 from Tom de Vries --- (In reply to Tom de Vries from comment #0) > However, the allocation and deallocation is done in a loop over units, so if > find_address_ranges succeeds for the first unit, but fails for the second, > then only the first struct unit is freed, and the second struct unit is > leaked. Sorry, that should be the other way around: "then only the second struct unit is freed, and the first struct unit is leaked. "
[Bug tree-optimization/87025] [9 Regression] ICE in add_record, at optinfo-emit-json.cc:175
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87025 David Malcolm changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot gnu.org --- Comment #3 from David Malcolm --- Thanks; I can reproduce it too; am investigating.
[Bug other/88057] libdecnumber/decCommon.c:479: use of out of scope variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88057 --- Comment #2 from David Binderman --- (In reply to Martin Liška from comment #1) > Interesting, what tool have you used to detect that? cppcheck, available from sourceforge. I find compile time warnings are usually preferred to runtime errors. At very least, runtime errors are dependent on test suite coverage, which can be sparse at times.
[Bug d/88040] gdc silently ignores -ffile-prefix-map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88040 --- Comment #1 from Iain Buclaw --- I don't suppose this could make use of the existing -fmodule-file= option, which translates a module name to a different file path?
[Bug tree-optimization/88064] New: [9 Regression] Incorrect vectorizer over_widening pattern handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88064
Bug ID: 88064
Summary: [9 Regression] Incorrect vectorizer over_widening
pattern handling
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
Something I've discovered by code inspection:
int a[64], b[64], c[64];
void
foo ()
{
int i;
for (i = 0; i < 64; i++)
{
long long d = a[i];
long long e = b[i];
d += e;
c[i] = d;
}
}
with -O3 -fno-tree-forwprop -fno-tree-vrp might introduce UB into the source
where there was none.
In *.ifcvt we have:
_1 = a[i_14];
d_7 = (long long int) _1;
_2 = b[i_14];
e_8 = (long long int) _2;
d_9 = d_7 + e_8;
_3 = (int) d_9;
c[i_14] = _3;
suppose int is 32-bit, long long 64-bit and a[i] is always INT_MAX and b[i] 1.
The original program doesn't invoke UB, because the addition is done in long
long int type. Now, GCC 9 vectorizes this as:
vector(4) int vect__1.6;
vector(4) int vect__2.9;
vector(4) signed int vect_patt_25.10;
vector(4) int vect_patt_23.11;
vect__1.6_19 = MEM[(int *)vectp_a.4_21];
vect__2.9_16 = MEM[(int *)vectp_b.7_18];
vect_patt_25.10_13 = vect__1.6_19 + vect__2.9_16;
vect_patt_23.11_12 = VIEW_CONVERT_EXPR(vect_patt_25.10_13);
MEM[(int *)vectp_c.12_5] = vect_patt_23.11_12;
The VCE is weird, why do we have special vectors of signed int vs. int?
But, more importantly, of course the addition in this case needs to be done in
in vector(4) unsigned int type, because we've demoted it from the original
(unless we can prove e.g. through ranges that undefined behavior will not be
triggered).
[Bug tree-optimization/88064] [9 Regression] Incorrect vectorizer over_widening pattern handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88064 Jakub Jelinek changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org Target Milestone|--- |9.0 --- Comment #1 from Jakub Jelinek --- Introduced probably with r262333 or so.
[Bug testsuite/88041] gdc.test tests should include that prefix in test names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88041
Iain Buclaw changed:
What|Removed |Added
CC||ibuclaw at gdcproject dot org
--- Comment #1 from Iain Buclaw ---
(In reply to Rainer Orth from comment #0)
> Created attachment 45010 [details]
> proposed patch
>
> The gdc.test tests currently omit that prefix from the test names and are
> thus
> not in line with GCC and DejaGnu conventions.
>
> I've started working on this. In a first attempt, I tried to fix
> gdc-test.exp,
> generating the preprocessed tests in a gdc.test subdir. However, that turned
> out to be pretty intrusive and finally fell apart when I noticed that several
> of the tests assume the current names due to something like
>
> // REQUIRED_ARGS: -lib -Icompilable/imports
>
> Of course, I could also insert gdc.test/ there during preprocessing, but this
> seems like a loosing battle.
>
> Instead, I took a different route: simply create a symlink from gdc.test to .
> so both the prefixed and unprefixed names work.
>
> The resulting patch is almost trivial and works with just two exceptions:
>
> dc.test/compilable/line.d:17:5: error: static assert
> ("gdc.test/compilable/line.d" == "compilable/line.d") is false
> compiler exited with status 1
> PASS: gdc.test/compilable/line.d (test for excess errors)
> FAIL: gdc.test/compilable/line.d output-exists line.o
>
> gdc.test/runnable/testkeyword.d:9:1: error: static assert (getCalleeFile()
> == "runnable/imports/testkwd_file.d") is false
> compiler exited with status 1
> PASS: gdc.test/runnable/testkeyword.d (test for excess errors)
> UNRESOLVED: gdc.test/runnable/testkeyword.d compilation failed to produce
> executable
>
> This is where gdc support for -ffile-prefix-map (PR d/88040) would come in
> quite handy.
>
Would changing the working directory to gdc.test to run the build commands not
have the same effect?
> I'm attaching the current patch, which also contains two minor issues I
> discovered during the first implementation of the patch: two files have
> EXTRA_SOURCES: lines with absolute pathnames, which cannot be right.
Yes, that is indeed wrong. I will just say that upstream have their own test
runner program for running the D2 test-suite, the dejagnu scripts we have try
to make a best effort in imitating it, hence the conversion/preprocessing it.
[Bug c/88065] New: [9 Regression] ICE in -Wsizeof-pointer-memaccess on an invalid strncpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88065
Bug ID: 88065
Summary: [9 Regression] ICE in -Wsizeof-pointer-memaccess on an
invalid strncpy
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
GCC 9 fails with an ICE on the following test case:
$ cat u.c && gcc -S -Wall u.c
struct B { struct A { char b[4]; } a; };
void f (struct B *p)
{
__builtin_strncpy (q->a.b, "123", sizeof p->a.b);
}
u.c: In function ‘f’:
u.c:5:22: error: ‘q’ undeclared (first use in this function)
5 | __builtin_strncpy (q->a.b, "123", sizeof p->a.b);
| ^
u.c:5:22: note: each undeclared identifier is reported only once for each
function it appears in
u.c:5:3: internal compiler error: tree check: expected class ‘type’, have
‘exceptional’ (error_mark) in sizeof_pointer_memaccess_warning, at
c-family/c-warn.c:816
5 | __builtin_strncpy (q->a.b, "123", sizeof p->a.b);
| ^
0x152375e tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
/ssd/src/gcc/git-svn/gcc/tree.c:9710
0x7f5a7d tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
/ssd/src/gcc/git-svn/gcc/tree.h:3277
0x96505b sizeof_pointer_memaccess_warning(unsigned int*, tree_node*,
vec*, tree_node**, bool (*)(tree_node*,
tree_node*))
/ssd/src/gcc/git-svn/gcc/c-family/c-warn.c:816
0x88f12a c_parser_postfix_expression_after_primary
/ssd/src/gcc/git-svn/gcc/c/c-parser.c:9331
0x88e1f9 c_parser_postfix_expression
/ssd/src/gcc/git-svn/gcc/c/c-parser.c:9029
0x8881b6 c_parser_unary_expression
/ssd/src/gcc/git-svn/gcc/c/c-parser.c:7292
0x8876bc c_parser_cast_expression
/ssd/src/gcc/git-svn/gcc/c/c-parser.c:7133
0x885dac c_parser_binary_expression
/ssd/src/gcc/git-svn/gcc/c/c-parser.c:6936
0x8855a8 c_parser_conditional_expression
/ssd/src/gcc/git-svn/gcc/c/c-parser.c:6670
0x8852b8 c_parser_expr_no_commas
/ssd/src/gcc/git-svn/gcc/c/c-parser.c:6587
0x88f917 c_parser_expression
/ssd/src/gcc/git-svn/gcc/c/c-parser.c:9486
0x88fb6c c_parser_expression_conv
/ssd/src/gcc/git-svn/gcc/c/c-parser.c:9519
0x882a63 c_parser_statement_after_labels
/ssd/src/gcc/git-svn/gcc/c/c-parser.c:5565
0x881b61 c_parser_compound_statement_nostart
/ssd/src/gcc/git-svn/gcc/c/c-parser.c:5103
0x88154f c_parser_compound_statement
/ssd/src/gcc/git-svn/gcc/c/c-parser.c:4937
0x87bfc2 c_parser_declaration_or_fndef
/ssd/src/gcc/git-svn/gcc/c/c-parser.c:2350
0x87a64e c_parser_external_declaration
/ssd/src/gcc/git-svn/gcc/c/c-parser.c:1652
0x87a1a7 c_parser_translation_unit
/ssd/src/gcc/git-svn/gcc/c/c-parser.c:1532
0x8b1adf c_parse_file()
/ssd/src/gcc/git-svn/gcc/c/c-parser.c:19609
0x93166f c_common_parse_file()
/ssd/src/gcc/git-svn/gcc/c-family/c-opts.c:1151
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c/88065] [9 Regression] ICE in -Wsizeof-pointer-memaccess on an invalid strncpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88065 Martin Sebor changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2018-11-16 Known to work||8.2.0 Target Milestone|--- |9.0 Ever confirmed|0 |1 Known to fail||9.0 --- Comment #1 from Martin Sebor --- Bisection points to r261515 as the commit that introduced the ICE: r261515 | msebor | 2018-06-12 13:14:31 -0400 (Tue, 12 Jun 2018) | 19 lines PR c/85931 - -Wsizeof-pointer-memaccess for strncpy with size of source gcc/c-family/ChangeLog: PR c/85931 * c-warn.c (sizeof_pointer_memaccess_warning): Avoid warning when sizeof source and destination yields the same value. gcc/ChangeLog: PR c/85931 * fold-const.c (operand_equal_p): Handle SAVE_EXPR. gcc/testsuite/ChangeLog: PR c/85931 * gcc.dg/Wstringop-truncation-3.c: New test.
[Bug c/88065] [9 Regression] ICE in -Wsizeof-pointer-memaccess on an invalid strncpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88065 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org
[Bug middle-end/88032] [9 Regression] ICE in operand_subword_force, at emit-rtl.c:1793
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88032 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Fri Nov 16 16:40:53 2018 New Revision: 266216 URL: https://gcc.gnu.org/viewcvs?rev=266216&root=gcc&view=rev Log: PR middle-end/88032 * optabs.c (expand_binop): For op0_mode use GET_MODE (op0), unless it is VOIDmode, in which case use int_mode. Similarly for op1_mode. Modified: trunk/gcc/ChangeLog trunk/gcc/optabs.c
[Bug middle-end/87854] [9 Regression] gcc.c-torture/compile/pr46534.c ICE for 16-bit size_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87854 --- Comment #9 from Jakub Jelinek --- Author: jakub Date: Fri Nov 16 16:41:54 2018 New Revision: 266217 URL: https://gcc.gnu.org/viewcvs?rev=266217&root=gcc&view=rev Log: PR middle-end/87854 * c-common.c (fix_string_type): Reject string literals larger than TYPE_MAX_VALUE (ssizetype) bytes. Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c
[Bug target/88051] internal compiler error: in add_clobbers, at config/i386/sync.md:1762
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88051 --- Comment #3 from uros at gcc dot gnu.org --- Author: uros Date: Fri Nov 16 16:42:16 2018 New Revision: 266218 URL: https://gcc.gnu.org/viewcvs?rev=266218&root=gcc&view=rev Log: PR target/88051 * config/i386/i386.md (floatunsdidf2): Allow only 64bit AVX512F targets. * config/i386/sse.md (UNSPEC_MOVDI_TO_SSE): New UNSPEC. (movdi_to_sse): Rewrite using UNSPEC_MOVDI_TO_SSE unspec. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md trunk/gcc/config/i386/sse.md
