[Bug rtl-optimization/79003] [7 Regression] r238991 breaks ODR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79003 --- Comment #4 from Martin Liška --- Just to document, I see another Werror in LTO bootstrap: ../../gcc/predict.c: In function ‘set_even_probabilities’: ../../gcc/predict.c:798:8: error: ‘e’ may be used uninitialized in this function [-Werror=maybe-uninitialized] edge e; ^ Where LIM does following transformation: [15.14%]: _1 = &bb_23(D)->succs; if (_1 == 0B) goto ; [0.04%] else goto ; [99.96%] [15.13%]: _79 = MEM[(struct vec * *)bb_23(D) + 8B]; e_lsm.1284_111 = e; e_lsm.1285_130 = 0; goto ; [100.00%] [0.04%]: _ZL12ei_container13edge_iterator.isra.19.part.20 (); [99.96%]: # nedges_90 = PHI # _93 = PHI <_94(14), 0(35)> # e_lsm.1284_2 = PHI # e_lsm.1285_15 = PHI if (_79 != 0B) goto ; [70.00%] else goto ; [30.00%] I guess it's a false positive.
[Bug tree-optimization/79007] [7 regression] gcc.dg/tree-ssa/dse-points-to.c fails starting with r244067
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79007 ktkachov at gcc dot gnu.org changed: What|Removed |Added Target|powerpc*-*-*|powerpc*-*-*, aarch64*, ||arm*, x86* Last reconfirmed|2017-01-05 00:00:00 |2017-1-6 CC||ktkachov at gcc dot gnu.org --- Comment #3 from ktkachov at gcc dot gnu.org --- Also see this on arm and aarch64
[Bug tree-optimization/78899] [7 Regression] Vestorized loop with optmized mask stores motion is completely deleted after r242520.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78899 Jakub Jelinek changed: What|Removed |Added Attachment #40458|0 |1 is obsolete|| --- Comment #6 from Jakub Jelinek --- Created attachment 40470 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40470&action=edit gcc7-pr78899.patch Updated patch that fixes the ICE.
[Bug target/57583] large switches with jump tables are horribly broken on m68k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57583 --- Comment #11 from John Paul Adrian Glaubitz --- Ok, the patch does indeed work. Tested by compiling the offending source code file in mednafen which currently fails to build from source [1]: Without "-mlong-jump-table-offsets", I get: (sid-m68k-sbuild)root@ikarus:/tmp/mednafen-0.9.39.2+dfsg/src/hw_cpu/m68k# g++-7 -c -std=c++11 m68k.cpp -o m68k.o -I../../../include -DMSB_FIRST -DSIZEOF_DOUBLE=8 (...) /tmp/cclNgtni.s:2848: Error: Adjusted signed .word (0x22374) overflows: `switch'-statement too large. /tmp/cclNgtni.s:2848: Error: Adjusted signed .word (0x22374) overflows: `switch'-statement too large. /tmp/cclNgtni.s:2848: Error: Adjusted signed .word (0x22374) overflows: `switch'-statement too large. /tmp/cclNgtni.s:2848: Error: Adjusted signed .word (0x22374) overflows: `switch'-statement too large. /tmp/cclNgtni.s:2848: Error: Adjusted signed .word (0x22374) overflows: `switch'-statement too large. /tmp/cclNgtni.s:2848: Error: Adjusted signed .word (0x22374) overflows: `switch'-statement too large. /tmp/cclNgtni.s:2848: Error: Adjusted signed .word (0x2237a) overflows: `switch'-statement too large. /tmp/cclNgtni.s:2848: Error: Adjusted signed .word (0x2237a) overflows: `switch'-statement too large. /tmp/cclNgtni.s:2848: Error: Adjusted signed .word (0x2237a) overflows: `switch'-statement too large. /tmp/cclNgtni.s:2848: Error: Adjusted signed .word (0x2237a) overflows: `switch'-statement too large. /tmp/cclNgtni.s:2848: Error: Adjusted signed .word (0x2237a) overflows: `switch'-statement too large. /tmp/cclNgtni.s:2848: Error: Adjusted signed .word (0x2237a) overflows: `switch'-statement too large. /tmp/cclNgtni.s:2848: Error: Adjusted signed .word (0x2237a) overflows: `switch'-statement too large. /tmp/cclNgtni.s:2848: Error: Adjusted signed .word (0x2237a) overflows: `switch'-statement too large. (sid-m68k-sbuild)root@ikarus:/tmp/mednafen-0.9.39.2+dfsg/src/hw_cpu/m68k# With the option set, it works: (sid-m68k-sbuild)root@ikarus:/tmp/mednafen-0.9.39.2+dfsg/src/hw_cpu/m68k# g++-7 -c -std=c++11 m68k.cpp -mlong-jump-table-offsets -o m68k.o -I../../../include -DMSB_FIRST -DSIZEOF_DOUBLE=8 (sid-m68k-sbuild)root@ikarus:/tmp/mednafen-0.9.39.2+dfsg/src/hw_cpu/m68k# ls -l total 4100 -rw-r--r-- 1 glaubitz glaubitz 21029 Jul 31 19:22 gen.cpp -rw-r--r-- 1 glaubitz glaubitz 41754 Aug 23 05:26 m68k.cpp -rw-r--r-- 1 glaubitz glaubitz 11780 Aug 22 22:13 m68k.h -rw-r--r-- 1 root root 3242396 Jan 6 10:18 m68k.o -rw-r--r-- 1 glaubitz glaubitz 868437 Jul 31 19:22 m68k_instr.inc (sid-m68k-sbuild)root@ikarus:/tmp/mednafen-0.9.39.2+dfsg/src/hw_cpu/m68k# Anything that speaks against applying this patch against gcc-7 and gcc-6? > [1] > https://buildd.debian.org/status/fetch.php?pkg=mednafen&arch=m68k&ver=0.9.39.2%2Bdfsg-1&stamp=1482769622
[Bug target/57583] large switches with jump tables are horribly broken on m68k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57583 --- Comment #12 from Mikael Pettersson --- Thanks for testing, I'll submit it for gcc-7 shortly.
[Bug c++/79013] New: Inconsistent auto diagnostic in member declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79013
Bug ID: 79013
Summary: Inconsistent auto diagnostic in member declarations
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
CC: inadgob at yahoo dot com, jakub at gcc dot gnu.org,
jason at gcc dot gnu.org, lhyatt at gmail dot com,
marxin at gcc dot gnu.org, rs2740 at gmail dot com,
unassigned at gcc dot gnu.org, webrown.cpp at gmail dot com
Depends on: 78693
Blocks: 79009
Target Milestone: ---
+++ This bug was initially created as a clone of Bug #78693 +++
Multiple unresolved unclear issues from the above PR:
struct A
{
auto foo(), bar();
};
auto A::foo() { return 1; }
auto A::bar() { return 2; }
Is this valid or not? Both g++ and clang++ accept it.
[dcl.spec.auto]/7 says only:
"If the init-declarator-list contains more than one init-declarator, they shall
all form declarations of variables."
which presumably doesn't apply to analogical member-declarator-list and
member-declarator, but should it?
Another similar testcase:
struct B
{
static auto const a = 5, foo(), bar();
};
auto const B::foo() { return 1; }
auto const B::bar() { return 2; }
Another issue:
struct C
{
static auto const a = 5, b = 6L;
};
clang++ rejects this, g++ doesn't:
pr78693-5.C:3:10: error: 'auto' deduced as 'int' in declaration of 'a' and
deduced as 'long' in declaration of 'b'
static auto const a = 5, b = 6L;
The question is if [dcl.spec.auto]/7 further sentence:
"The type of each declared variable is determined by placeholder type deduction
(7.1.7.4.1), and if the type that replaces the placeholder type is not the same
in each deduction, the program is ill-formed."
applies just to the init-declarator-list or also to member-declarator-list.
Consistency and common sense would suggest that we should reject it like
clang++ does, does the C++ standard need to be changed for that though?
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78693
[Bug 78693] [6 Regression] Bogus 'inconsistent deduction for ‘auto’' error when
having a dependent initializer and a nondependent one in the same declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79009
[Bug 79009] Missing 'inconsistent deduction for ‘auto’' error when having a
dependent initializer and a nondependent one in the same declaration
[Bug target/57583] large switches with jump tables are horribly broken on m68k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57583 --- Comment #13 from John Paul Adrian Glaubitz --- (In reply to Mikael Pettersson from comment #12) > Thanks for testing, I'll submit it for gcc-7 shortly. Ah, awesome, thanks! Would also be cool to have this backported to the gcc-6 branch if possible.
[Bug fortran/78672] Gfortran test suite failures with a sanitized compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78672 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- So fixed?
[Bug fortran/78672] Gfortran test suite failures with a sanitized compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78672 --- Comment #6 from vehre at gcc dot gnu.org --- Well, obviously not: - see depends on - run gfortran with leak check (take care not to drown in the reports) and address those leaks. - then do the same for the testcases themself (the work upto now just addressed the issues at compile time, still pending is runtime!)
[Bug tree-optimization/78887] [7 Regression] Failure to build aarch64 allmodconfig Linux kernel 4.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78887 --- Comment #3 from Jakub Jelinek --- Ping, any progress? Is the module built with -fsanitize=kernel-address? I don't see any cpu_device_id struct in the kernel, so the message is just weird. There is module_cpu_feature_match though which uses MODULE_DEVICE_TABLE. Perhaps the sanitization adds the odr byte into that section? Though, not sure how that would happen, because the odr byte is only created in asan_add_global which is called when asan_protect_global is true, which should not be the case for variables with user sections. In any case, please attach the preprocessed source.
[Bug tree-optimization/79014] New: Absent vectorization with memory loads
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79014
Bug ID: 79014
Summary: Absent vectorization with memory loads
Product: gcc
Version: 6.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jkb at sanger dot ac.uk
Target Milestone: ---
I have some code which vectorises using icc to some success, but fails to
vectorise in gcc (and clang too). The noddy example is as follows:
#define NX 32
typedef unsigned int uint32_t;
typedef unsigned short uint16_t;
typedef unsigned char uint8_t;
int bar(uint32_t *s3, uint32_t *in, int in_size, uint8_t *out, int out_size) {
const uint32_t mask = (1u << 12)-1;
int i;
uint32_t R[NX] = {0};
for (i = 0; i < out_size; i+= NX) {
int z;
#pragma omp simd aligned(in, out: 32)
for (z = 0; z < NX; z++) {
R[z] *= in[i+z];
out[i+z] = s3[R[z] & mask];
}
}
return 0;
}
This is called from a second file containing a main function to test it:
#include
typedef unsigned int uint32_t;
typedef unsigned short uint16_t;
typedef unsigned char uint8_t;
#define BS (1013*1047)
uint32_t s3[1<<12];
uint32_t in[BS];
uint8_t out[BS];
extern int bar(uint32_t *s3, uint32_t *in, int in_size, uint8_t *out, int
out_size);
int main(void) {
int i;
for (i = 0; i < (1<<12); i++)
s3[i] = (rand() << 16) ^ rand();
for (i = 0; i < BS; i++)
in[i] = (rand() << 16) ^ rand();
for (i = 0; i < 1; i++)
bar(s3, in, BS, out, BS);
return 0;
}
(The omp pragma there is purely for icc, it seems to make little difference to
gcc.) Some benchmarks:
gcc-6.1.0: 33743262303 cycles, 97919071795 instructions
icc-15.0.0: 21561762894 cycles, 58128430729 instructions
clang-3.8.0: 36884730520 cycles, 92597500495 instructions
Compilation is via "gcc -g -O3 -fopenmp -march=native a.c b.c" and the host is
a Xeon E5-2660 (@2.2Ghz) with avx but not avx2 support (so realistically this
can be vectorised using SSE4 only as it's integer maths). This also means it
isn't using the gather instructions, but loading from memory to sse4 registers.
icc -S confirms this, with a lot of xmm register usage.
icc with -qopt-report=5 dumps out:
LOOP BEGIN at a.c(14,14)
remark #15389: vectorization support: reference R has unaligned access
[ a.c(15,13) ]
remark #15389: vectorization support: reference R has unaligned access
[ a.c(15,13) ]
remark #15389: vectorization support: reference in has unaligned access
[ a.c(15,13) ]
remark #15389: vectorization support: reference out has unaligned access
[ a.c(16,13) ]
remark #15389: vectorization support: reference R has unaligned access
[ a.c(16,13) ]
remark #15381: vectorization support: unaligned access used inside loop
body [ a.c(16,13) ]
remark #15399: vectorization support: unroll factor set to 2
remark #15301: OpenMP SIMD LOOP WAS VECTORIZED
remark #15448: unmasked aligned unit stride loads: 2
remark #15449: unmasked aligned unit stride stores: 2
remark #15458: masked indexed (or gather) loads: 1
remark #15475: --- begin vector loop cost summary ---
remark #15476: scalar loop cost: 17
remark #15477: vector loop cost: 4.500
remark #15478: estimated potential speedup: 3.770
remark #15479: lightweight vector operations: 12
remark #15488: --- end vector loop cost summary ---
remark #25015: Estimate of max trip count of loop=2
LOOP END
I've no idea why it thinks those are unaligned, but it vectorised it anyway.
Gcc -fopt-info-vec-missed reports:
a.c:11:5: note: failed: evolution of base is not affine.
a.c:11:5: note: bad data references.
a.c:15:18: note: not vectorized: not suitable for gather load _28 = *_27;
a.c:15:18: note: bad data references.
a.c:11:5: note: not vectorized: no vectype for stmt: R = {};
scalar_type: uint32_t[32]
a.c:11:5: note: not vectorized: not enough data-refs in basic block.
a.c:19:12: note: not vectorized: not enough data-refs in basic block.
a.c:13:9: note: not vectorized: not enough data-refs in basic block.
a.c:16:22: note: not consecutive access _28 = *_27;
a.c:16:22: note: not vectorized: no grouped stores in basic block.
a.c:11:5: note: not vectorized: not enough data-refs in basic block.
Adding __attribute__((aligned(32))) to the R[] definition didn't help.
I've explored up to gcc 7 via the online tool at https://godbolt.org/ and can
confirm the lack of vectorisation still, although that seems to show clang
gains vectorisation too.
[Bug libstdc++/78991] std::sort and std::unique can not use std::function with clang++ -std=c++14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78991 --- Comment #5 from Jonathan Wakely --- Author: redi Date: Fri Jan 6 12:33:58 2017 New Revision: 244150 URL: https://gcc.gnu.org/viewcvs?rev=244150&root=gcc&view=rev Log: PR78991 make __gnu_cxx::__ops constructors explicit PR libstdc++/78991 * include/bits/predefined_ops.h (_Iter_comp_iter, _Iter_comp_val) (_Val_comp_iter, _Iter_equals_val, _Iter_pred, _Iter_comp_to_val) (_Iter_comp_to_iter, _Iter_negate): Make constructors explicit and move function objects. (__iter_comp_iter, __iter_comp_val, __val_comp_iter, __pred_iter) (__iter_comp_val, __iter_comp_iter, __negate): Move function objects. * testsuite/25_algorithms/sort/78991.cc: New test. Added: trunk/libstdc++-v3/testsuite/25_algorithms/sort/78991.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/predefined_ops.h
[Bug tree-optimization/78887] [7 Regression] Failure to build aarch64 allmodconfig Linux kernel 4.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78887 --- Comment #4 from ktkachov at gcc dot gnu.org --- Created attachment 40471 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40471&action=edit Preprocessed source The command used to compile that file is: aarch64-none-linux-gnu-gcc -Wp,-MD,arch/arm64/crypto/.sha1-ce-glue.o.d -nostdinc -isystem /arm/pdtl/builds/fsf-trunk.1182/installed/rhe6x86_64/aarch64-none-linux-gnu/bin/../lib/gcc/aarch64-none-linux-gnu/7.0.0/include -I./arch/arm64/include -I./arch/arm64/include/generated/uapi -I./arch/arm64/include/generated -I./include -I./arch/arm64/include/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/kconfig.h -D__KERNEL__ -mbig-endian -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -std=gnu89 -fno-PIE -mgeneral-regs-only -DCONFIG_AS_LSE=1 -fno-asynchronous-unwind-tables -mpc-relative-literal-loads -fno-delete-null-pointer-checks -Wno-frame-address -O2 --param=allow-store-data-races=0 -fno-reorder-blocks -fno-ipa-cp-clone -fno-partial-inlining -fno-stack-protector -Wno-unused-but-set-variable -Wno-unused-const-variable -fno-omit-frame-pointer -fno-optimize-sibling-calls -fno-var-tracking-assignments -pg -fno-inline-functions-called-once -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fconserve-stack -Werror=implicit-int -Werror=strict-prototypes -Werror=date-time -Werror=incompatible-pointer-types -DCC_HAVE_ASM_GOTO -DMODULE -mcmodel=large -DKBUILD_BASENAME='"sha1_ce_glue"' -DKBUILD_MODNAME='"sha1_ce"' -c I'm still working on untangling what the kernel build system does with the object files to generate that error...
[Bug middle-end/77484] [6/7 Regression] Static branch predictor causes ~6-8% regression of SPEC2000 GAP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484 --- Comment #20 from Jan Hubicka --- Hi, it turns out that Martin added another column to his statistics script which I have misinterpretted. https://gcc.opensuse.org/SPEC/CINT/sb-terbium-head-64/recent.html also shows interesting reaction to the change. I will update the probabilities to correct values one by one and let us see how benchmarks react. Is changing one a day enough for periodic testers to catch up? The hitrates on spec2k6 combined with spec v6 is as follows. It means that indirect call should have 14%, call 67% and polymorphic call should have oposite outcime and 59% The statistic samples are quite small and dominated by one use, so we may diverge from those values if it seem to make sense. Honza COMBINED HEURISTICS BRANCHES (REL) BR. HITRATE HITRATE COVERAGE COVERAGE (REL) loop guard with recursion 13 0.0% 92.31% 85.06% / 85.06% 66724402676.67G 0.4% Fortran loop preheader 42 0.0% 97.62% 97.78% / 99.07%14487181.45M 0.0% loop iv compare71 0.1% 78.87% 49.26% / 63.89% 163168352 163.17M 0.0% loop exit with recursion 85 0.1% 75.29% 84.89% / 86.96% 98737414359.87G 0.6% extra loop exit98 0.1% 71.43% 31.39% / 76.96% 312263024 312.26M 0.0% recursive call121 0.1% 64.46% 37.55% / 82.78% 531996473 532.00M 0.0% Fortran repeated allocation/deallocation 392 0.4% 100.00% 100.00% / 100.00%630 630.00 0.0% guess loop iv compare 402 0.4% 90.05% 95.82% / 96.04% 56831517715.68G 0.3% indirect call 425 0.4% 52.00% 14.06% / 91.41% 38153329633.82G 0.2% Fortran zero-sized array 549 0.6% 99.64% 100.00% / 100.00% 20794317 20.79M 0.0% const return 651 0.7% 94.93% 84.04% / 93.18% 10677746531.07G 0.1% null return 716 0.7% 92.18% 91.83% / 93.39% 34213219563.42G 0.2% negative return 734 0.8% 97.14% 64.62% / 65.01% 47448863154.74G 0.3% continue 773 0.8% 66.11% 79.71% / 87.43%29089649102 29.09G 1.6% polymorphic call 803 0.8% 43.59% 59.05% / 86.63% 38285550303.83G 0.2% Fortran fail alloc944 1.0% 100.00% 100.00% / 100.00% 167691 167.69K 0.0% Fortran overflow 1237 1.3% 100.00% 100.00% / 100.00% 55197159 55.20M 0.0% loop guard 1861 1.9% 48.90% 69.86% / 84.62%17979028127 17.98G 1.0% noreturn call3769 3.9% 99.95% 100.00% / 100.00% 81750534258.18G 0.5% loop exit5017 5.2% 83.50% 90.01% / 91.68% 143815212145 143.82G 8.1% opcode values positive (on trees)5763 6.0% 66.23% 60.41% / 86.25%43349211449 43.35G 2.4% loop iterations 6276 6.6% 99.94% 78.54% / 78.54% 662671304506 662.67G 37.3% early return (on trees) 9512 9.9% 61.02% 58.05% / 85.82%56222551226 56.22G 3.2% pointer (on trees) 10969 11.5% 63.29% 75.18% / 89.33%23318221976 23.32G 1.3% opcode values nonequal (on trees) 11633 12.2% 63.23% 74.53% / 85.23% 118246028039 118.25G 6.7% guessed loop iterations 13631 14.2% 96.54% 92.61% / 93.12% 417886815060 417.89G 23.5% call20747 21.7% 54.47% 67.24% / 92.56%50096613362 50.10G 2.8%
[Bug debug/79015] New: ICE in get_insn_template in gcc/final.c:2081
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79015
Bug ID: 79015
Summary: ICE in get_insn_template in gcc/final.c:2081
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
All releases I have (4.5.0) ICE in following code:
$ cat /tmp/ice.c
int
foo (int x, int y)
{
int z = x + y;
return x * y;
}
__attribute__((optimize ("no-var-tracking"))) int
bar (int x, int y)
{
int z = x + y;
return x * y;
}
$ ./xgcc -B. /tmp/ice.c -g -O
/tmp/ice.c: In function ‘bar’:
/tmp/ice.c:13:1: internal compiler error: in get_insn_template, at final.c:2081
}
^
0x8df156 get_insn_template(int, rtx_def*)
../../gcc/final.c:2081
0x8e171a final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
../../gcc/final.c:2982
0x8e27d2 final(rtx_insn*, _IO_FILE*, int)
../../gcc/final.c:2046
0x8e2f89 rest_of_handle_final
../../gcc/final.c:4475
0x8e2f89 execute
../../gcc/final.c:4548
[Bug libstdc++/78991] std::sort and std::unique can not use std::function with clang++ -std=c++14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78991 --- Comment #6 from Jonathan Wakely --- Author: redi Date: Fri Jan 6 13:20:05 2017 New Revision: 244152 URL: https://gcc.gnu.org/viewcvs?rev=244152&root=gcc&view=rev Log: PR78991 make __gnu_cxx::__ops constructors explicit PR libstdc++/78991 * include/bits/predefined_ops.h (_Iter_comp_iter, _Iter_comp_val) (_Val_comp_iter, _Iter_equals_val, _Iter_pred, _Iter_comp_to_val) (_Iter_comp_to_iter, _Iter_negate): Make constructors explicit. * testsuite/25_algorithms/sort/78991.cc: New test. Added: branches/gcc-6-branch/libstdc++-v3/testsuite/25_algorithms/sort/78991.cc Modified: branches/gcc-6-branch/libstdc++-v3/ChangeLog branches/gcc-6-branch/libstdc++-v3/include/bits/predefined_ops.h
[Bug libstdc++/78956] std::thread doesn't fully meet LWG 2097 requirement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78956 --- Comment #3 from Jonathan Wakely --- Author: redi Date: Fri Jan 6 13:20:10 2017 New Revision: 244153 URL: https://gcc.gnu.org/viewcvs?rev=244153&root=gcc&view=rev Log: Add deleted std::thread(const thread&&) constructor Backport from mainline 2017-01-03 Jonathan Wakely PR libstdc++/78956 * include/std/thread (thread(const thread&&)): Add deleted constructor. * testsuite/30_threads/thread/cons/lwg2097.cc: New test. Added: branches/gcc-6-branch/libstdc++-v3/testsuite/30_threads/thread/cons/lwg2097.cc Modified: branches/gcc-6-branch/libstdc++-v3/ChangeLog branches/gcc-6-branch/libstdc++-v3/include/std/thread
[Bug libstdc++/63829] _Lock_policy used in thread.cc can cause incompatibilities with binaries using different -mcpu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63829 --- Comment #8 from Richard Earnshaw --- From a discussion on IRC: What's the general story on lock policies? Are environments supposed to support all three? (if possible) no. it's something only used in std::shared_ptr, and generally entirely invisible to users What's supposed to happen if one (can't be supported)? most people will only ever use the default one, which gets chosen according to the target _S_single always works, it just isn't thread-safe But that's surely bogus if detected dynamically if _S_atomic doesn't work for a given target then users should not try to use it (ie based on the CPU architecture _S_single is only ever the default if gcc is built with --disable-threads Ok, so we can ignore that one, then yeah but seems that mutex and atomic can't be a compile time choice; it must be selected at configure time based on the base architecture used at that point yes (or you have to ensure every translation unit in the program uses the same choice) (including the libstdc++.so linked to) But we can't guarantee that if you use the __GCC_HAVE_SYNC_COMPARE_AND_SWAP_ macros since those are dependent on certain patterns being enabled in the back-end of the compiler, and that's dependent on the architecture. yep I think it would be better to move the _atomic _mutex check into configure and create a new macro based on the result of a test performed then at least then a build of the library would always work with code compiled with that compiler agreed (even if it isn't quite as efficient if you normally have a later rev of the architecture) OK, I'll put that in the PR so IIUC, if gcc is configured for armv7 (and so chooses the _S_atomic policy) and then somebody builds their code with -mcpu=armv5 they will need to link to libatomic to get the necessary atomic ops if that's correct, it seems fine to me. when this lock policy stuff was invented we didn't have libatomic, and so some arches simply didn't have atomics, period Yes, provided the compiler correctly falls back into the library code in that case. now we can punt to libatomic, so can use _S_atomic for any arch with a libatomic implementation It would be a bit odd-ball to build for ARMv5 if your library is v7 anyway (you'd still need a v7 device to run it on) yep So I won't loose too much sleep over that combination people seem to do that though maybe just for testing, I don't know Probably for that ok, so not a real case we need to support good Not performant, anyway Do you mind if I just paste the above directly into the PR?
[Bug rtl-optimization/79003] [7 Regression] r238991 breaks ODR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79003
--- Comment #5 from Martin Liška ---
Author: marxin
Date: Fri Jan 6 13:56:48 2017
New Revision: 244155
URL: https://gcc.gnu.org/viewcvs?rev=244155&root=gcc&view=rev
Log:
Fix lto-bootstrap (PR bootstrap/79003).
2017-01-06 Martin Liska
PR bootstrap/79003
* lra-constraints.c: Rename invariant to lra_invariant.
* predict.c (set_even_probabilities): Initialize e to NULL.
2017-01-06 Martin Liska
PR bootstrap/79003
* Makefile.in: Add -fno-lto to {C,CPP,LD}FLAGS.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-constraints.c
trunk/gcc/predict.c
trunk/libdecnumber/ChangeLog
trunk/libdecnumber/Makefile.in
[Bug rtl-optimization/79003] [7 Regression] r238991 breaks ODR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79003 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Martin Liška --- Fixed.
[Bug tree-optimization/78887] [7 Regression] Failure to build aarch64 allmodconfig Linux kernel 4.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78887 --- Comment #5 from Jakub Jelinek --- Those options don't include -fsanitize=kernel-address, so no idea where that earlier mentioned _GLOBAL__sub_D_65535_0___odr_asan.__mod_cpu__cpu_feature_match_SHA1_device_table comes from. But, even with -fsanitize=kernel-address added to the option there is no *__odr_asan* symbol. cpu_feature_match_SHA1 is 4 bytes long regardless of that option.
[Bug tree-optimization/78887] [7 Regression] Failure to build aarch64 allmodconfig Linux kernel 4.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78887 --- Comment #6 from ktkachov at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #5) > Those options don't include -fsanitize=kernel-address, so no idea where that > earlier mentioned > _GLOBAL__sub_D_65535_0___odr_asan. > __mod_cpu__cpu_feature_match_SHA1_device_table > comes from. But, even with -fsanitize=kernel-address added to the option > there is no *__odr_asan* symbol. > cpu_feature_match_SHA1 is 4 bytes long regardless of that option. Sorry, I posted the wrong command line (I was playing with different combinations). The proper command line is: aarch64-none-linux-gnu-gcc -Wp,-MD,arch/arm64/crypto/.sha1-ce-glue.o.d -nostdinc -isystem /arm/pdtl/builds/fsf-trunk.1182/installed/rhe6x86_64/aarch64-none-linux-gnu/bin/../lib/gcc/aarch64-none-linux-gnu/7.0.0/include -I./arch/arm64/include -I./arch/arm64/include/generated/uapi -I./arch/arm64/include/generated -I./include -I./arch/arm64/include/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/kconfig.h -D__KERNEL__ -mbig-endian -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -std=gnu89 -fno-PIE -mgeneral-regs-only -DCONFIG_AS_LSE=1 -fno-asynchronous-unwind-tables -mpc-relative-literal-loads -fno-delete-null-pointer-checks -Wno-frame-address -O2 --param=allow-store-data-races=0 -fno-reorder-blocks -fno-ipa-cp-clone -fno-partial-inlining -fno-stack-protector -Wno-unused-but-set-variable -Wno-unused-const-variable -fno-omit-frame-pointer -fno-optimize-sibling-calls -fno-var-tracking-assignments -pg -fno-inline-functions-called-once -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fconserve-stack -Werror=implicit-int -Werror=strict-prototypes -Werror=date-time -Werror=incompatible-pointer-types -DCC_HAVE_ASM_GOTO -fsanitize=kernel-address -fasan-shadow-offset=0xdf90 --param asan-stack=1 --param asan-globals=1 --param asan-instrumentation-with-call-threshold=0 -fsanitize-coverage=trace-pc -DMODULE -mcmodel=large -DKBUILD_BASENAME='"sha1_ce_glue"' -DKBUILD_MODNAME='"sha1_ce"' -c which does include -fsanitize=kernel-address
[Bug tree-optimization/79007] [7 regression] gcc.dg/tree-ssa/dse-points-to.c fails starting with r244067
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79007 Rainer Orth changed: What|Removed |Added Target|powerpc*-*-*, aarch64*, |powerpc*-*-*, aarch64*, |arm*, x86* |arm*, x86*, sparc* CC||ro at gcc dot gnu.org Host|powerpc*-*-*| Target Milestone|--- |7.0 Build|powerpc*-*-*| --- Comment #4 from Rainer Orth --- Same on sparc.
[Bug libstdc++/78991] std::sort and std::unique can not use std::function with clang++ -std=c++14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78991 --- Comment #7 from Jonathan Wakely --- Author: redi Date: Fri Jan 6 14:04:26 2017 New Revision: 244157 URL: https://gcc.gnu.org/viewcvs?rev=244157&root=gcc&view=rev Log: PR78991 make __gnu_cxx::__ops constructors explicit PR libstdc++/78991 * include/bits/predefined_ops.h (_Iter_comp_iter, _Iter_comp_val) (_Val_comp_iter, _Iter_equals_val, _Iter_pred, _Iter_comp_to_val) (_Iter_comp_to_iter, _Iter_negate): Make constructors explicit. * testsuite/25_algorithms/sort/78991.cc: New test. Added: branches/gcc-5-branch/libstdc++-v3/testsuite/25_algorithms/sort/78991.cc Modified: branches/gcc-5-branch/libstdc++-v3/ChangeLog branches/gcc-5-branch/libstdc++-v3/include/bits/predefined_ops.h
[Bug libstdc++/78956] std::thread doesn't fully meet LWG 2097 requirement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78956 --- Comment #4 from Jonathan Wakely --- Author: redi Date: Fri Jan 6 14:04:33 2017 New Revision: 244158 URL: https://gcc.gnu.org/viewcvs?rev=244158&root=gcc&view=rev Log: Add deleted std::thread(const thread&&) constructor Backport from mainline 2017-01-03 Jonathan Wakely PR libstdc++/78956 * include/std/thread (thread(const thread&&)): Add deleted constructor. * testsuite/30_threads/thread/cons/lwg2097.cc: New test. Added: branches/gcc-5-branch/libstdc++-v3/testsuite/30_threads/thread/cons/lwg2097.cc Modified: branches/gcc-5-branch/libstdc++-v3/ChangeLog branches/gcc-5-branch/libstdc++-v3/include/std/thread
[Bug libstdc++/78991] std::sort and std::unique can not use std::function with clang++ -std=c++14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78991 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.5 --- Comment #8 from Jonathan Wakely --- I've added a workaround to the libstdc++ code, which will be included in the gcc 5.5, 6.4 and 7.1 releases. You'll need the updated libstdc++ headers to be able to compile this code with clang, e.g. by requesting the Ubuntu GCC maintainers to include this patch in their gcc builds.
[Bug libstdc++/78956] std::thread doesn't fully meet LWG 2097 requirement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78956 Jonathan Wakely changed: What|Removed |Added Version|unknown |5.4.0 Target Milestone|--- |5.5 Known to fail||5.4.0, 6.3.0, 7.0 --- Comment #5 from Jonathan Wakely --- Fixed for 5.5 and 6.4
[Bug libstdc++/78956] std::thread doesn't fully meet LWG 2097 requirement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78956 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Jonathan Wakely --- .
[Bug target/78041] Wrong code on ARMv7 with -mthumb -mfpu=neon-fp16 -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78041 --- Comment #18 from wilco at gcc dot gnu.org --- Author: wilco Date: Fri Jan 6 14:26:06 2017 New Revision: 244161 URL: https://gcc.gnu.org/viewcvs?rev=244161&root=gcc&view=rev Log: With -fpu=neon DI mode shifts are expanded after reload. DI mode registers can either fully or partially overlap on both ARM and Thumb-2. However the shift expansion code can only deal with the full overlap case, and generates incorrect code for partial overlaps. The fix is to add new variants that support either full overlap or no overlap. Backport from mainline 2016-10-25 Wilco Dijkstra gcc/ PR target/78041 * config/arm/neon.md (ashldi3_neon): Add "r 0 i" and "&r r i" variants. Remove partial overlap check for shift by 1. (ashldi3_neon): Likewise. testsuite/ * gcc.target/arm/pr78041.c: New test. Added: branches/gcc-6-branch/gcc/testsuite/gcc.target/arm/pr78041.c Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/config/arm/neon.md branches/gcc-6-branch/gcc/testsuite/ChangeLog
[Bug go/78978] [7 regression] runtime/pprof FAILs on Solaris 2/x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78978 --- Comment #4 from Rainer Orth --- Author: ro Date: Fri Jan 6 14:33:47 2017 New Revision: 244162 URL: https://gcc.gnu.org/viewcvs?rev=244162&root=gcc&view=rev Log: Build libgo with -Wa,-nH if possible (PR go/78978) [non-libgo parts] libstdc++-v3: PR go/78978 * acinclude.m4 (GLIBCXX_CHECK_ASSEMBLER_HWCAP): Remove. * configure.ac: Call GCC_CHECK_ASSEMBLER_HWCAP instead of GLIBCXX_CHECK_ASSEMBLER_HWCAP. * fragment.am (CONFIG_CXXFLAGS): Use HWCAP_CFLAGS instead of HWCAP_FLAGS. * aclocal.m4: Regenerate. * configure: Regenerate. * Makefile.in, doc/Makefile.in, include/Makefile.in, libsupc++/Makefile.in, po/Makefile.in, python/Makefile.in, src/Makefile.in, src/c++11/Makefile.in, src/c++98/Makefile.in, src/filesystem/Makefile.in, testsuite/Makefile.in: Regenerate. config: PR go/78978 * hwcaps.m4 (GCC_CHECK_ASSEMBLER_HWCAP): New macro. Modified: trunk/config/ChangeLog trunk/config/hwcaps.m4 trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/Makefile.in trunk/libstdc++-v3/acinclude.m4 trunk/libstdc++-v3/aclocal.m4 trunk/libstdc++-v3/configure (contents, props changed) trunk/libstdc++-v3/configure.ac trunk/libstdc++-v3/doc/Makefile.in trunk/libstdc++-v3/fragment.am trunk/libstdc++-v3/include/Makefile.in trunk/libstdc++-v3/libsupc++/Makefile.in trunk/libstdc++-v3/po/Makefile.in trunk/libstdc++-v3/python/Makefile.in trunk/libstdc++-v3/src/Makefile.in trunk/libstdc++-v3/src/c++11/Makefile.in trunk/libstdc++-v3/src/c++98/Makefile.in trunk/libstdc++-v3/src/filesystem/Makefile.in trunk/libstdc++-v3/testsuite/Makefile.in
[Bug sanitizer/78887] [7 Regression] Failure to build aarch64 allmodconfig Linux kernel 4.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78887 Jakub Jelinek changed: What|Removed |Added CC||dodji at gcc dot gnu.org, ||dvyukov at gcc dot gnu.org, ||kcc at gcc dot gnu.org Component|tree-optimization |sanitizer --- Comment #7 from Jakub Jelinek --- Ah, ok, I'd say this is a kernel bug. scripts/mod/file2alias.c (handle_moddevtable) has: /* All our symbols are of form __moddevice_table. */ name = strstr(symname, "__mod_"); so the __odr_asan.__mod_cpu__cpu_feature_match_SHA1_device_table symbol is also recognized as a device table (which is wrong). I bet _GLOBAL__sub_D_65535_0___odr_asan.__mod_cpu__cpu_feature_match_SHA1_device_table or _GLOBAL__sub_D_65535_0___mod_cpu__cpu_feature_match_SHA1_device_table could trigger it too. Dunno what is the rationale behind accepting there, perhaps accepting only empty prefix or _ prefix would be better. On the gcc side, we could work around this by adding: if (flag_sanitize & SANITIZE_KERNEL_ADDRESS) return false; to asan_needs_odr_indicator_p, that assumes the kernel never wants ODR verification (as it is written in C, that might be very likely).
[Bug rtl-optimization/78911] [5/6/7 Regression] Infinite loop at -O2/O3 optimization levels while trying to compile server.c from Wine-2.0-rc2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78911
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
||uros at gcc dot gnu.org
--- Comment #7 from Jakub Jelinek ---
Slightly cleaned up testcase:
/* PR rtl-optimization/78911 */
/* { dg-do compile } */
/* { dg-options "-O3 -fPIC -fno-strict-aliasing -fno-omit-frame-pointer" } */
/* { dg-additional-options "-fPIC" { target fpic } } */
/* { dg-additional-options "-march=pentium-m" { target ia32 } } */
int a, b, d, e;
long long *c;
static int
foo (long long *x)
{
return __sync_val_compare_and_swap (x, b, a);
}
void
bar (void)
{
if (!c)
return;
e = foo (&c[d]);
}
Started hanging with r216281.
[Bug middle-end/78605] bogus -Wformat-length=1 with %f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78605 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Martin Sebor --- Fixed.
[Bug middle-end/78605] bogus -Wformat-length=1 with %f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78605 --- Comment #3 from Martin Sebor --- Author: msebor Date: Fri Jan 6 15:45:42 2017 New Revision: 244164 URL: https://gcc.gnu.org/viewcvs?rev=244164&root=gcc&view=rev Log: PR middle-end/78605 - bogus -Wformat-length=1 with %f gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/pr78605.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr78605.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug go/78978] [7 regression] runtime/pprof FAILs on Solaris 2/x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78978 --- Comment #5 from ian at gcc dot gnu.org --- Author: ian Date: Fri Jan 6 16:04:01 2017 New Revision: 244165 URL: https://gcc.gnu.org/viewcvs?rev=244165&root=gcc&view=rev Log: PR go/78978 libgo: build with -Wa,-nH if possible on Solaris By default the Solaris assembler records the required hardware capability in the object file. This means that the AES hashing code breaks on systems that do not support AES, even though the code uses a runtime check to only actually invoke the AES instructions on systems that support it. An earlier fix for the problem only fixed the shared library, not the static libgo.a. Fix the problem for real by using an assembler option to not record the hardware capability. For GCC PR 78978. Patch by Rainer Orth. Reviewed-on: https://go-review.googlesource.com/34910 Modified: trunk/gcc/go/gofrontend/MERGE trunk/libgo/Makefile.am trunk/libgo/Makefile.in trunk/libgo/configure trunk/libgo/configure.ac trunk/libgo/testsuite/Makefile.in
[Bug go/78978] [7 regression] runtime/pprof FAILs on Solaris 2/x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78978 Ian Lance Taylor changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||ian at airs dot com Resolution|--- |FIXED --- Comment #6 from Ian Lance Taylor --- Should be fixed.
[Bug target/57583] large switches with jump tables are horribly broken on m68k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57583 --- Comment #14 from Mikael Pettersson --- Patch submitted: https://gcc.gnu.org/ml/gcc-patches/2017-01/msg00419.html
[Bug middle-end/79016] New: missing -Wstringop-overflow= overflowing allocated buffers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79016
Bug ID: 79016
Summary: missing -Wstringop-overflow= overflowing allocated
buffers
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The -Wstringop-overflow warning correctly detects the buffer overflow in the
fauto() and funnamed() functions below but misses all the other instances of it
in the rest of the functions.
$ cat b.c && gcc -O2 -S -Wall -Wextra -Wpedantic b.c
void f (void*);
void fauto (void)
{
char d[3];
f (__builtin_memset (d, 0, 5));
}
void funnamed (void)
{
f (__builtin_memset ((char[3]){ 0 }, 1, 5));
}
void falloca (void)
{
char *d = __builtin_alloca (3);
f (__builtin_memset (d, 0, 5));
}
void fmalloc (void)
{
char *d = __builtin_malloc (3);
f (__builtin_memset (d, 0, 5));
}
void fvla (unsigned n)
{
if (n > 3)
n = 3;
char d [n];
f (__builtin_memset (d, 0, 5));
}
b.c: In function ‘fauto’:
b.c:7:3: warning: ‘__builtin_memset’ writing 5 bytes into a region of size 3
overflows the destination [-Wstringop-overflow=]
f (__builtin_memset (d, 0, 5));
^~
b.c: In function ‘funnamed’:
b.c:12:3: warning: ‘__builtin_memset’ writing 5 bytes into a region of size 3
overflows the destination [-Wstringop-overflow=]
f (__builtin_memset ((char[3]){ 0 }, 1, 5));
^~~
[Bug middle-end/77484] [6/7 Regression] Static branch predictor causes ~6-8% regression of SPEC2000 GAP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484 --- Comment #21 from Jan Hubicka --- Author: hubicka Date: Fri Jan 6 16:10:09 2017 New Revision: 244167 URL: https://gcc.gnu.org/viewcvs?rev=244167&root=gcc&view=rev Log: PR middle-end/77484 * predict.def (PRED_POLYMORPHIC_CALL): Set to 58 * predict.c (tree_estimate_probability_bb): Reverse direction of polymorphic call predictor. Modified: trunk/gcc/ChangeLog trunk/gcc/predict.c trunk/gcc/predict.def
[Bug tree-optimization/78529] [7 Regression] gcc.c-torture/execute/builtins/strcat-chk.c failed with lto/O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78529 Renlin Li changed: What|Removed |Added CC||renlin at gcc dot gnu.org --- Comment #22 from Renlin Li --- (In reply to James Greenhalgh from comment #19) > That would be an error: > > /tmp/ccpefK3l.ltrans0.ltrans.o: In function `memset': > :(.text+0x4a0): multiple definition of `memset' > .../aarch64-none-elf/lib/libc.a(lib_a-memset.o): > .../newlib/libc/machine/aarch64/memset.S:90: first defined here > > Were it not for the flag added to resolve PR55994 > -Wl,--allow-multiple-definition . > > So, in my opinion, the testcase is broken and could always have failed in > this way. The combination of register allocation, LTO and order the linker > sees symbols explains why this is hard to reproduce. I had exactly the same errors and issues today. I reduced it to a minimum test case. Please check the new attachment The build command line is: aarch64-none-elf-gcc -O2 -specs=aem-ve.specs -Wl,--allow-multiple-definition -lm -flto main.c memset.c -o new.exe The expected output should be "A A A 2" 80001038 : 80001038: a9bf7bfdstp x29, x30, [sp,#-16]! 8000103c: 9123adrpx3, 80025000 <__global_locale+0x68> 80001040: 52800044mov w4, #0x2// #2 80001044: 91060060add x0, x3, #0x180 80001048: 910003fdmov x29, sp 8000104c: b9018064str w4, [x3,#384] 80001050: d2800402mov x2, #0x20 // #32 80001054: 52800821mov w1, #0x41 // #65 80001058: 91002000add x0, x0, #0x8 # At this function entry, x4 is not saved. Because LTO thinks the local memset # implementation will not clobber it. However, the libc version of memeset is # linked in the final binary. The implementation there will clobber x4. This # will cause run-time data corruption, which is shown here. 8000105c: 94000a39bl 80003940 80001060: a8c17bfdldp x29, x30, [sp],#16 80001064: 52800823mov w3, #0x41 // #65 80001068: 9080adrpx0, 80011000 <__swbuf_r+0x70> 8000106c: 2a0303e2mov w2, w3 80001070: 2a0303e1mov w1, w3 80001074: 91152000add x0, x0, #0x548 80001078: 140015c0b 80006778 8000107c: .inst 0x ; undefined This is mentioned above. But allow me to ask again: "aarch64-none-elf-gcc -O2 main.c memset.c -o new.o -specs=aem-ve.specs -lm -flto" will give the "multiple definition of `memset'" error while "aarch64-none-elf-gcc -O2 main.c memset.c -o new.o -specs=aem-ve.specs -lm" won't. Should them behavior the same? By adding "-Wl,--allow-multiple-definition" do fix this erro. But why it's the test case that is broken instead of the lto pass?
[Bug tree-optimization/78529] [7 Regression] gcc.c-torture/execute/builtins/strcat-chk.c failed with lto/O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78529 --- Comment #24 from Renlin Li --- Created attachment 40473 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40473&action=edit memset.c
[Bug tree-optimization/78529] [7 Regression] gcc.c-torture/execute/builtins/strcat-chk.c failed with lto/O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78529 --- Comment #23 from Renlin Li --- Created attachment 40472 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40472&action=edit test case
[Bug tree-optimization/78529] [7 Regression] gcc.c-torture/execute/builtins/strcat-chk.c failed with lto/O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78529 --- Comment #25 from Renlin Li --- Created attachment 40474 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40474&action=edit reduced objdump assembler file
[Bug libstdc++/78968] conflict between gnu's __cxa_thread_atexit and LLVM's/FreeBSD's implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78968 --- Comment #17 from Jonathan Wakely --- Author: redi Date: Fri Jan 6 17:06:24 2017 New Revision: 244169 URL: https://gcc.gnu.org/viewcvs?rev=244169&root=gcc&view=rev Log: Check for __cxa_thread_atexit for freebsd crosses PR libstdc++/78968 * crossconfig.m4: Check for __cxa_thread_atexit on *-*-freebsd*. * configure: Regenerate. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/configure trunk/libstdc++-v3/crossconfig.m4
[Bug rtl-optimization/78911] [5/6/7 Regression] Infinite loop at -O2/O3 optimization levels while trying to compile server.c from Wine-2.0-rc2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78911 --- Comment #8 from Uroš Bizjak --- (In reply to Martin Liška from comment #6) > Created attachment 40409 [details] > head -n70 tc.i.274r.reload > > So the problem is older than r221983. Why do you think so? Reverting r221983 one-liner, introduced in PR65710 as a performance fix for earlier patch, allows me to compile the testcase. (In reply to Jakub Jelinek from comment #7) > Started hanging with r216281. Referred commit allowed atomic_compare_and_swapdi_doubleword pattern to directly use %ebx, which was not allowed before pseudo PIC reg was introduced. Mentioned pattern pushes i686 register pressure to the limit, it is somehow problematic for RA to handle, but RA managed to do correct reg allocation up to r221983.
[Bug tree-optimization/79006] [6/7 Regression] Invalid transformation in tree-dominators pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79006 Bill Schmidt changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Bill Schmidt --- Hm, no, this isn't invalid code at all. Sorry for the noise. I need to get back with the guy that reported this to me and see what's going on. I think he lost the original problem when reducing the test case.
[Bug c/16351] NULL dereference warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351 --- Comment #49 from Jon Grant --- (In reply to Martin Sebor from comment #48) > Send a check to Manuel ;) The feature is available under the > -Wnull-dereference option (see comment 31). Unfortunately, due to false > positives, the option was removed from -Wall in a subsequent commit > (r226751) and has to be enabled explicitly. > > The similar -Wnonnull option that was just recently enhanced to detect > related problems is in -Wall, and it seems to me that it would make sense to > treat both of these options the same: i.e., enable both with -Wall. To do > that, the former option might need to be tweaked to reduce its false > positive rate. At the same time, the -Wnonnull option still has a high rate > of false negatives and so it could stand to be enhanced to do a better job. > The challenge is striking the right balance between the two rates that is > acceptable to everyone. Thank you for your reply. -Werror=null-dereference doesn't seem to be in my compiler: gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609 Is it just in GCC6 branch? -Wnonnull is present though. Re the feature, I think it can't be that hard to check per function can it...?
[Bug c++/78966] Unjustified variadic template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78966 Ville Voutilainen changed: What|Removed |Added CC||jason at redhat dot com, ||ville.voutilainen at gmail dot com --- Comment #3 from Ville Voutilainen --- Jason, care to look at this? There have been suggestions along the lines that [temp.inst]/6 might mean that the template may or may not get instantiated, so I'm not sure whether there's a conformance issue here. There certainly might be a QoI issue nonetheless.
[Bug c++/78966] Unjustified variadic template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78966 --- Comment #4 from Ville Voutilainen --- Note that clang also triggers the static_assert, so there might be something deeper going on here. :)
[Bug libstdc++/79017] New: Old PowerMac G5, MacPorts GCC 5.4, C++11 and "std::log2 has not been declared"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79017
Bug ID: 79017
Summary: Old PowerMac G5, MacPorts GCC 5.4, C++11 and
"std::log2 has not been declared"
Product: gcc
Version: 5.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: noloader at gmail dot com
Target Milestone: ---
I'm working on a PowerMac G5. It runs OS X 10.5.8. It has MacPorts installed
for updated gear.
The program:
$ cat test.cxx
#include
int main(int argc, char* argv[])
{
double d = std::log2(2.3456789f);
return 0;
}
Results:
$ /opt/local/bin/g++-mp-5 -std=c++11 test.cxx -o test.exe
test.cxx: In function 'int main(int, char**)':
test.cxx:4:16: error: 'log2' is not a member of 'std'
double d = std::log2(2.3456789f);
^
test.cxx:4:16: note: suggested alternative:
In file included from /usr/include/math.h:26:0,
from /opt/local/include/gcc5/c++/cmath:44,
from test.cxx:1:
/usr/include/architecture/ppc/math.h:431:15: note: 'log2'
extern double log2( double );
^
Compiler:
$ /opt/local/bin/g++-mp-5 --version
g++-mp-5 (MacPorts gcc5 5.4.0_0) 5.4.0
Copyright (C) 2015 Free Software Foundation, Inc.
...
***
From JW offlist:
#include
int main() {
typedef double_t my_double_t;
typedef float_t my_float_t;
acosh(0.0);
acoshf(0.0f);
acoshl(0.0l);
asinh(0.0);
asinhf(0.0f);
asinhl(0.0l);
atanh(0.0);
atanhf(0.0f);
atanhl(0.0l);
cbrt(0.0);
cbrtf(0.0f);
cbrtl(0.0l);
copysign(0.0, 0.0);
copysignf(0.0f, 0.0f);
copysignl(0.0l, 0.0l);
erf(0.0);
erff(0.0f);
erfl(0.0l);
erfc(0.0);
erfcf(0.0f);
erfcl(0.0l);
exp2(0.0);
exp2f(0.0f);
exp2l(0.0l);
expm1(0.0);
expm1f(0.0f);
expm1l(0.0l);
fdim(0.0, 0.0);
fdimf(0.0f, 0.0f);
fdiml(0.0l, 0.0l);
fma(0.0, 0.0, 0.0);
fmaf(0.0f, 0.0f, 0.0f);
fmal(0.0l, 0.0l, 0.0l);
fmax(0.0, 0.0);
fmaxf(0.0f, 0.0f);
fmaxl(0.0l, 0.0l);
fmin(0.0, 0.0);
fminf(0.0f, 0.0f);
fminl(0.0l, 0.0l);
hypot(0.0, 0.0);
hypotf(0.0f, 0.0f);
hypotl(0.0l, 0.0l);
ilogb(0.0);
ilogbf(0.0f);
ilogbl(0.0l);
lgamma(0.0);
lgammaf(0.0f);
lgammal(0.0l);
llrint(0.0);
llrintf(0.0f);
llrintl(0.0l);
llround(0.0);
llroundf(0.0f);
llroundl(0.0l);
log1p(0.0);
log1pf(0.0f);
log1pl(0.0l);
log2(0.0);
log2f(0.0f);
log2l(0.0l);
logb(0.0);
logbf(0.0f);
logbl(0.0l);
lrint(0.0);
lrintf(0.0f);
lrintl(0.0l);
lround(0.0);
lroundf(0.0f);
lroundl(0.0l);
nan(0);
nanf(0);
nanl(0);
nearbyint(0.0);
nearbyintf(0.0f);
nearbyintl(0.0l);
nextafter(0.0, 0.0);
nextafterf(0.0f, 0.0f);
nextafterl(0.0l, 0.0l);
nexttoward(0.0, 0.0);
nexttowardf(0.0f, 0.0f);
nexttowardl(0.0l, 0.0l);
remainder(0.0, 0.0);
remainderf(0.0f, 0.0f);
remainderl(0.0l, 0.0l);
remquo(0.0, 0.0, 0);
remquof(0.0f, 0.0f, 0);
remquol(0.0l, 0.0l, 0);
rint(0.0);
rintf(0.0f);
rintl(0.0l);
round(0.0);
roundf(0.0f);
roundl(0.0l);
scalbln(0.0, 0l);
scalblnf(0.0f, 0l);
scalblnl(0.0l, 0l);
scalbn(0.0, 0);
scalbnf(0.0f, 0);
scalbnl(0.0l, 0);
tgamma(0.0);
tgammaf(0.0f);
tgammal(0.0l);
trunc(0.0);
truncf(0.0f);
truncl(0.0l);
return 0;
}
Results in:
$ /opt/local/bin/g++-mp-5 -std=c++11 test.cxx -o test.exe
test.cxx: In function 'int main()':
test.cxx:53:21: error: 'llrint' was not declared in this scope
llrint(0.0);
^
test.cxx:54:23: error: 'llrintf' was not declared in this scope
llrintf(0.0f);
^
test.cxx:55:23: error: 'llrintl' was not declared in this scope
llrintl(0.0l);
^
test.cxx:56:22: error: 'llround' was not declared in this scope
llround(0.0);
^
test.cxx:57:24: error: 'llroundf' was not declared in this scope
llroundf(0.0f);
^
test.cxx:58:24: error: 'llroundl' was not declared in this scope
llroundl(0.0
[Bug libstdc++/79017] Old PowerMac G5, MacPorts GCC 5.4, C++11 and "std::log2 has not been declared"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79017 --- Comment #1 from Jeffrey Walton --- Also see Issue 53226 in the MacPorts issue tracker. "gcc5 @5.4: error: 'std::log2' has not been declared", https://trac.macports.org/ticket/53226.
[Bug c++/78966] Unjustified variadic template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78966
Richard Smith changed:
What|Removed |Added
CC||richard-gccbugzilla@metafoo
||.co.uk
--- Comment #5 from Richard Smith ---
The vari in f is a non-deduced context because the corresponding argument
is an overloaded function that cannot be resolved. The pack T can't be deduced,
so it is inferred to be an empty pack.
Here's another case that needs the above rules in order to work:
template struct X {};
template struct vari { vari(void(*)(X)); };
template void f(vari);
template void g(X);
void h() { f(g); } // 'f' is equivalent to 'f<>'; T is an empty pack
[Bug rtl-optimization/78911] [5/6/7 Regression] Infinite loop at -O2/O3 optimization levels while trying to compile server.c from Wine-2.0-rc2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78911 --- Comment #9 from Jakub Jelinek --- At least for me it hangs already in that r216281: timeout 20 /opt/notnfs/gcc-bisect/obj/gcc/cc1.216281 -quiet -O3 -march=pentium-m -m32 -fPIC -fno-strict-aliasing -fno-omit-frame-pointer pr78911.c; echo $? 124 -bash-4.3$ timeout 20 /opt/notnfs/gcc-bisect/obj/gcc/cc1.216280 -quiet -O3 -march=pentium-m -m32 -fPIC -fno-strict-aliasing -fno-omit-frame-pointer pr78911.c; echo $? 0 (the latter is instant, fraction of a second).
[Bug c++/78966] Unjustified variadic template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78966 Eelis changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #6 from Eelis --- Ah, thanks for the explanation! That makes sense. I guess that to avoid this problem, one should adhere to a rule along the lines of: "If you're about to write a function like template R f(X); then if f is potentially overloaded, and X cannot be instantiated with an empty pack, you better write f as: template R f(X) because otherwise calls to those other fs may end up requiring X to be instantiable with an empty pack." I now use this workaround for my operator<< for std::variant. Closing.
[Bug libstdc++/79017] Old PowerMac G5, MacPorts GCC 5.4, C++11 and "std::log2 has not been declared"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79017 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-01-06 Ever confirmed|0 |1 --- Comment #2 from Jonathan Wakely --- (In reply to Jeffrey Walton from comment #0) > test.cxx:53:21: error: 'llrint' was not declared in this scope >llrint(0.0); > ^ > test.cxx:54:23: error: 'llrintf' was not declared in this scope >llrintf(0.0f); >^ > test.cxx:55:23: error: 'llrintl' was not declared in this scope >llrintl(0.0l); >^ > test.cxx:56:22: error: 'llround' was not declared in this scope >llround(0.0); > ^ > test.cxx:57:24: error: 'llroundf' was not declared in this scope >llroundf(0.0f); > ^ > test.cxx:58:24: error: 'llroundl' was not declared in this scope >llroundl(0.0l); > ^ Because these six functions are missing we treat all C99 math functions as missing. We could split the checks into two pieces, so we check for these separately, which would allow the rest of the C99 math library to be imported into namespace std. But OS X 10.5.8 is pretty old, and this might not be worth doing if it doesn't affect current versions of OS x.
[Bug libstdc++/79017] Old PowerMac G5, MacPorts GCC 5.4, C++11 and "std::log2 has not been declared"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79017 --- Comment #3 from Jonathan Wakely --- Jeffrey, could you please add the output of '/opt/local/bin/g++-mp-5 -dumpmachine' to the Target field of this bug report? Thanks.
[Bug libstdc++/79017] Old PowerMac G5, MacPorts GCC 5.4, C++11 and "std::log2 has not been declared"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79017 --- Comment #4 from Jeffrey Walton --- (In reply to Jonathan Wakely from comment #3) > Jeffrey, could you please add the output of '/opt/local/bin/g++-mp-5 > -dumpmachine' to the Target field of this bug report? Thanks. $ /opt/local/bin/g++-mp-5 -dumpmachine ppc-apple-darwin9 If it matters, the machine is 32-bit by default: $ getconf LONG_BIT 32 But its capable of 64-bit code with -m64 or -arch ppc64.
[Bug libstdc++/79017] Old PowerMac G5, MacPorts GCC 5.4, C++11 and "std::log2 has not been declared"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79017 --- Comment #5 from Jeffrey Walton --- (In reply to Jonathan Wakely from comment #2) > (In reply to Jeffrey Walton from comment #0) > ... ^ > > Because these six functions are missing we treat all C99 math functions as > missing. We could split the checks into two pieces, so we check for these > separately, which would allow the rest of the C99 math library to be > imported into namespace std. > > But OS X 10.5.8 is pretty old, and this might not be worth doing if it > doesn't affect current versions of OS x. The issue seems to affect Android as well: http://stackoverflow.com/q/22922961. I am not sure if its the exact same issue however. Splitting the checks may benefit more than an ancient PowerMac. For what its worth, I keep the antique hardware around for testing on the PowerPC, which is big-endian. Otherwise it would be retired.
[Bug middle-end/71905] bogus -Wlarger-than=N and -Wframe-larger-than= -Wstack-usage= warnings on small objects with large N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71905 Eric Gallager changed: What|Removed |Added CC||egall at gwmail dot gwu.edu --- Comment #3 from Eric Gallager --- (In reply to Martin Sebor from comment #2) > To get around the INT_MAX limit the -Walloc-size-larger-than accepts numbers > with suffixes like KB and MB. Other options that accept sizes should > probably accept the same suffixes for consistency.
[Bug libstdc++/79017] Old PowerMac G5, MacPorts GCC 5.4, C++11 and "std::log2 has not been declared"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79017 Eric Gallager changed: What|Removed |Added CC||egall at gwmail dot gwu.edu --- Comment #6 from Eric Gallager --- (In reply to Jonathan Wakely from comment #2) > (In reply to Jeffrey Walton from comment #0) > > test.cxx:53:21: error: 'llrint' was not declared in this scope > >llrint(0.0); > > ^ > > test.cxx:54:23: error: 'llrintf' was not declared in this scope > >llrintf(0.0f); > >^ > > test.cxx:55:23: error: 'llrintl' was not declared in this scope > >llrintl(0.0l); > >^ > > test.cxx:56:22: error: 'llround' was not declared in this scope > >llround(0.0); > > ^ > > test.cxx:57:24: error: 'llroundf' was not declared in this scope > >llroundf(0.0f); > > ^ > > test.cxx:58:24: error: 'llroundl' was not declared in this scope > >llroundl(0.0l); > > ^ > > Because these six functions are missing we treat all C99 math functions as > missing. We could split the checks into two pieces, so we check for these > separately, which would allow the rest of the C99 math library to be > imported into namespace std. > > But OS X 10.5.8 is pretty old, and this might not be worth doing if it > doesn't affect current versions of OS x. 10.5.8 is what I'm still on, too. Iain Sandoe has been committing patches targeting 10.4 and 10.5 recently, as well. I'd say it's worth doing.
[Bug target/57583] large switches with jump tables are horribly broken on m68k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57583 --- Comment #15 from Jeffrey A. Law --- Author: law Date: Fri Jan 6 21:21:02 2017 New Revision: 244184 URL: https://gcc.gnu.org/viewcvs?rev=244184&root=gcc&view=rev Log: 2017-01-06 Mikael Pettersson PR target/57583 * config/m68k/m68k.opt (LONG_JUMP_TABLE_OFFSETS): New option. * config/m68k/linux.h (ASM_RETURN_CASE_JUMP): Handle TARGET_LONG_JUMP_TABLE_OFFSETS. * config/m68k/m68kelf.h (ASM_RETURN_CASE_JUMP): Likewise. * config/m68k/netbsd-elf.h (ASM_RETURN_CASE_JUMP): Likewise. * config/m68k/m68k.h (CASE_VECTOR_MODE): Likewise. (ASM_OUTPUT_ADDR_DIFF_ELF): Likewise. * config/m68k/m68k.md (tablejump expander): Likewise. (*tablejump_pcrel_hi): Renamed from unnamed insn, reject TARGET_LONG_JUMP_TABLE_OFFSETS. (*tablejump_pcrel_si): New insn, handle TARGET_LONG_JUMP_TABLE_OFFSETS. * doc/invoke.texi (M68K options): Add -mlong-jump-table-offsets. Modified: trunk/gcc/ChangeLog trunk/gcc/config/m68k/linux.h trunk/gcc/config/m68k/m68k.h trunk/gcc/config/m68k/m68k.md trunk/gcc/config/m68k/m68k.opt trunk/gcc/config/m68k/m68kelf.h trunk/gcc/config/m68k/netbsd-elf.h trunk/gcc/doc/invoke.texi
[Bug target/57583] large switches with jump tables are horribly broken on m68k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57583 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #16 from Jeffrey A. Law --- Fixed on the trunk. No current plans to backport to release branches.
[Bug target/71695] m68k: long long multiplication broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71695 --- Comment #4 from Jeffrey A. Law --- Martin, No idea what might be going on here. Could you compile yourr testcase with "-fdump-tree-all-blocks-details -dap" on whatever system exhibits this problem and attach the slew of debugging dumps to this BZ. A compressed tarball would be fine.
[Bug preprocessor/13498] CPP include search path documentation is incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13498 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |sandra at gcc dot gnu.org --- Comment #3 from sandra at gcc dot gnu.org --- The search path reported by -v for various versions/targets of CPP I have installed here doesn't look like what was reported from the previous discussion on this ticket back in 2003. I think the best way to correct/robustify/future-proof this documentation is to tell users to use -v, instead of hard-coding a directory list in the CPP manual. (Maybe as a future enhancement it would be friendlier to have a new -print-include-path option specifically to get this information, instead of having to dig through the -v output.) I also confirmed that the "paragraph about dirs appearing twice" is inaccurate per current behavior, and will take that out as part of the rewrite.
[Bug c++/72803] [7 Regression] ICE on invalid code in linemap_position_for_loc_and_offset, at libcpp/line-map.c:891
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72803 David Malcolm changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot gnu.org --- Comment #7 from David Malcolm --- (In reply to Aldy Hernandez from comment #6) [...] > That should still be line 1 and column 511. Why is it line 4 and column > 127? Something smells fishy. Something is going wrong with the linemaps. I'm investigating.
[Bug other/79018] New: translatable string typo in params.def:1105
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79018 Bug ID: 79018 Summary: translatable string typo in params.def:1105 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: fmarchal at perso dot be Target Milestone: --- The message "Maximum number of constant stores to merge in thestore merging pass" lacks a space in "the store" I presume. Message found in ftp://gcc.gnu.org/pub/gcc/snapshots/7-20170101/gcc-7-20170101.tar.bz2 proposed to translators.
[Bug pch/78970] GCC crashes if input file is dash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78970 --- Comment #7 from joseph at codesourcery dot com --- This change causes a regression testing glibc. glibc uses "gcc -E -x c-header -", which now results in an error "cannot use '-' as input filename for a precompiled header". But that use with -E is not creating a precompiled header, so should not result in an error.
[Bug libstdc++/79017] Old PowerMac G5, MacPorts GCC 5.4, C++11 and "std::log2 has not been declared"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79017 --- Comment #7 from Jeffrey Walton --- (In reply to Jeffrey Walton from comment #5) > (In reply to Jonathan Wakely from comment #2) > ... > > But OS X 10.5.8 is pretty old, and this might not be worth doing if it > > doesn't affect current versions of OS x. > > The issue seems to affect Android as well: > http://stackoverflow.com/q/22922961. I am not sure if its the exact same > issue however. > > Splitting the checks may benefit more than an ancient PowerMac. > > For what its worth, I keep the antique hardware around for testing on the > PowerPC, which is big-endian. Otherwise it would be retired. Wow, this is a surprising statistic (for me)... OS X 10.5 makes up 29.1% of the MacPorts downloads. Its the largest percentage for the OS group. Confer, http://stats.macports.neverpanic.de/os_statistics#osx_version. Also, according to https://trac.macports.org/ticket/53226#comment:5, the issue affects both PPC and Intel machines. So it affects 100% of the architectures (even though PPC makes up less than 2%). I wonder how many Homebrew or Fink users (et al) have similar statistics.
[Bug c++/78948] [C++17] constexpr if instantiating too eagerly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78948 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Target Milestone|--- |7.0 --- Comment #4 from Jason Merrill --- I seem to remember some discussion in Oulu about why it wouldn't work to call discarded statements unevaluated, but I don't remember the reasoning. I suppose it's that we say a few things about unevaluated operands that we don't want to apply: prohibiting lambdas, and allowing bare non-static data members (DR 850). The former is easy to handle; the latter doesn't seem worth worrying much about.
[Bug libstdc++/79017] Old PowerMac G5, MacPorts GCC 5.4, C++11 and "std::log2 has not been declared"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79017 --- Comment #8 from Jeffrey Walton --- > Wow, this is a surprising statistic (for me)... OS X 10.5 makes up 29.1% of > the MacPorts downloads. Its the largest percentage for the OS group. Confer, > http://stats.macports.neverpanic.de/os_statistics#osx_version. > > Also, according to https://trac.macports.org/ticket/53226#comment:5, the > issue affects both PPC and Intel machines. So it affects 100% of the > architectures (even though PPC makes up less than 2%). > > I wonder how many Homebrew or Fink users (et al) have similar statistics. My bad... I misread the statistic because both OS X 10.11 and 10.5 use green (thanks CL). According to the statistic, OS X 10.5 appears to account for 5% for the group.
[Bug libstdc++/79017] Old PowerMac G5, MacPorts GCC 5.4, C++11 and "std::log2 has not been declared"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79017 --- Comment #9 from Jeffrey Walton --- (In reply to Jonathan Wakely from comment #2) > (In reply to Jeffrey Walton from comment #0) > > test.cxx:53:21: error: 'llrint' was not declared in this scope > >llrint(0.0); > > ^ > > test.cxx:54:23: error: 'llrintf' was not declared in this scope > >llrintf(0.0f); > >^ > > test.cxx:55:23: error: 'llrintl' was not declared in this scope > >llrintl(0.0l); > >^ > > test.cxx:56:22: error: 'llround' was not declared in this scope > >llround(0.0); > > ^ > > test.cxx:57:24: error: 'llroundf' was not declared in this scope > >llroundf(0.0f); > > ^ > > test.cxx:58:24: error: 'llroundl' was not declared in this scope > >llroundl(0.0l); > > ^ > > Because these six functions are missing we treat all C99 math functions as > missing. We could split the checks into two pieces, so we check for these > separately, which would allow the rest of the C99 math library to be > imported into namespace std. This patch for libc++ may be useful to you for OS X 10.6 and below (thanks to KC): https://github.com/jeremyhu/libcxx/commit/720feba4874d4ca3131753dc31af127e3c509c36
[Bug c/16351] NULL dereference warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351 --- Comment #50 from Martin Sebor --- Yes, -Wnull-dereference is only in GCC 6 and later. -Wnonnull is in 5 and prior but it does only a superficial job of checking (it only detects null pointer constants). in GCC 7, -Wnonnull does a better job (but it's still far from perfect). Null pointer checking (and everything else) is always done per function. The challenge isn't in implementing it but rather in striking the right balance between the stages of compilation at which the checking is done. When done early early we may miss instances that could be exposed by later stages (optimizations). When done late we start flagging instances introduced by the earlier transformations that didn't appear in the original source code (and that may never be executed). It's a delicate balance between false negatives and false positives.
[Bug tree-optimization/78529] [7 Regression] gcc.c-torture/execute/builtins/strcat-chk.c failed with lto/O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78529 --- Comment #26 from Jim Wilson --- I can reproduce the problem with this new reduced testcase. I don't have knowledge of all of the details how the gcc implementation of LTO works, but my understanding goes something like this. The testcase is defining memset. Memset is a reserved identifier (ISO C section 7.1.3). So the testcase is violating the ISO C standard. The memset definition in the input source is LTO optimized, which means it gets turned into an LTO symbol that is not immediately visible to the linker. The linker sees the startfiles first, and then the LTO optimized files. The crt0.o file has a reference to memset. The linker can't use the LTO optimized memset to satisfy this reference, because it is still a special LTO symbol not a normal symbol. So it pulls in memset from the C library to satisfy the reference. The linker then looks at the LTO optimized files, calls the compiler to convert them from LTO symbols into normal symbols, and then discovers that it has two memset functions, and because --allow-multiple-definitions is given, it arbitrarily discards one instead of giving an error. Since the memset from libc.a was already linked in, I don't think it has much choice, and has to drop the new one from LTO. The main function was LTO optimized expecting that it would call the LTO optimized memset function, which uses a restricted register set, thus allowing main to use normally call clobbered registers across the memset call. However, if the linker drops the LTO optimized memset, then we get a call to the library memset, which clobbers all call clobbered regs, and the main function fails. The problem is primarily with the testcase, and secondarily with how LTO works. If the LTO link converted the LTO symbols into normal symbols before trying to resolve unsatisfied symbols from crt0.o, that would appear to solve the problem. This would require changes to the linker, changes that may or may not be reasonable. If crt0.o didn't call memset, that would solve the problem, but that isn't a very reasonable solution. There may also be issues with other standard library functions and/or other start files. If the newlib C library was built as a shared library that would appear to solve the problem, as the LTO symbol would override the shared library symbol, but that isn't a reasonable solution for an embedded target. The easy solution is to stop running this test on embedded targets that don't have a shared C library.
