[Bug middle-end/82658] Suboptimal codegen on AVR when right-shifting 8-bit unsigned integers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82658 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-10-24 Component|target |middle-end Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Ok. So the issue is a FE one after all. With the C FE we have volatile unsigned char val; unsigned char local = val; local = local >> 1; val = local; while the C++ FE preserves the widening from the integer promotion rules: <; <> 1)) >; <; and nothing in the middle-end shortens the right-shift operation.
[Bug tree-optimization/82691] new test case gfortran.dg/graphite/pr82672.f90 fails with ICE starting with its introduction in r254009
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82691 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Richard Biener --- Oops. Forgot to apply the patch.
[Bug tree-optimization/82672] [8 Regression][GRAPHITE] ICE in verify_gimple_in_cfg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82672 --- Comment #3 from Richard Biener --- Author: rguenth Date: Tue Oct 24 07:02:48 2017 New Revision: 254036 URL: https://gcc.gnu.org/viewcvs?rev=254036&root=gcc&view=rev Log: 2017-10-23 Richard Biener PR tree-optimization/82672 * graphite-isl-ast-to-gimple.c (graphite_copy_stmts_from_block): Fold the stmt if we propagated into it. * gfortran.dg/graphite/pr82672.f90: New testcase. Modified: trunk/gcc/graphite-isl-ast-to-gimple.c
[Bug middle-end/82569] [8 regression] failure in 177.mesa cpu2000 test case after r253530
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82569 --- Comment #12 from Eric Botcazou --- Author: ebotcazou Date: Tue Oct 24 07:26:52 2017 New Revision: 254037 URL: https://gcc.gnu.org/viewcvs?rev=254037&root=gcc&view=rev Log: PR middle-end/82569 * tree-outof-ssa.h (always_initialized_rtx_for_ssa_name_p): Delete. * expr.c (expand_expr_real_1) : Revert latest change. * loop-iv.c (iv_get_reaching_def): Likewise. * cfgexpand.c (expand_one_ssa_partition): Initialize the RTX if the variable is promoted and the partition contains undefined values. Modified: trunk/gcc/ChangeLog trunk/gcc/cfgexpand.c trunk/gcc/expr.c trunk/gcc/loop-iv.c trunk/gcc/tree-outof-ssa.h
[Bug middle-end/82569] [8 regression] failure in 177.mesa cpu2000 test case after r253530
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82569 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #13 from Eric Botcazou --- Thanks for reporting the problem and analyzing it.
[Bug c/82679] Uses of typedefs of arrays of _Atomic-qualified types are rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82679 Richard Biener changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2017-10-24 Ever confirmed|0 |1
[Bug web/82686] Debian sid powerpc64-unknown-linux-gnu 4.13.0-1-powerpc64 bootstrap breaks in stage3 with unexpected requirement for bdw-gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82686
Richard Biener changed:
What|Removed |Added
Keywords||documentation
Status|UNCONFIRMED |NEW
Last reconfirmed||2017-10-24
CC||doko at gcc dot gnu.org
Component|bootstrap |web
Ever confirmed|0 |1
--- Comment #3 from Richard Biener ---
--enable-objc-gc requires you to provide boehm-gc yourself now. Quoting the
installation instructions:
@item --enable-objc-gc
Specify that an additional variant of the GNU Objective-C runtime library
is built, using an external build of the Boehm-Demers-Weiser garbage
collector (@uref{http://www.hboehm.info/gc/}). This library needs to be
available for each multilib variant, unless configured with
@option{--enable-objc-gc=@samp{auto}} in which case the build of the
additional runtime library is skipped when not available and the build
continues.
This change should have been mentioned in gcc-7/changes.html but it doesn't
seem to be.
Otherwise it's behaving as expected (thus not a bug).
Matthias, can you amend changes.html?
[Bug lto/82687] [8 regression] g++.dg/asan/default-options-1.C fails starting with r253914
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82687 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.0
[Bug target/82692] [8 Regression] Ordered comparisons used for unordered built-ins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82692 Richard Biener changed: What|Removed |Added Keywords||wrong-code Target Milestone|--- |8.0
[Bug tree-optimization/82694] New: [8 regression] Linux kernel miscompiled since r250765
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82694 Bug ID: 82694 Summary: [8 regression] Linux kernel miscompiled since r250765 Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: trippels at gcc dot gnu.org CC: amker at gcc dot gnu.org Target Milestone: --- Since r250765 the Linux kernel gets miscompiled when built with -O3. It hangs very early during boot waiting for an interrupt that never occurs (hlt in early_fixup_exception()). I haven't looked deeper yet, so sorry no testcase.
[Bug tree-optimization/82689] merging writes of different types to the same location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82689 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2017-10-24 CC||rguenth at gcc dot gnu.org Blocks||33315 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- We don't currently optimize this (RTL crossjumping does to the extent you are seeing). On GIMPLE there's no semantically equivalent code doing an unconditional store (you'd lose at least some TBAA). There's a related bug, PR33315, about sinking and commoning stores. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33315 [Bug 33315] stores not commoned by sinking
[Bug middle-end/82694] [8 regression] Linux kernel miscompiled since r250765
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82694 Richard Biener changed: What|Removed |Added Component|tree-optimization |middle-end Target Milestone|--- |8.0
[Bug rtl-optimization/82692] [8 Regression] Ordered comparisons used for unordered built-ins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82692 Uroš Bizjak changed: What|Removed |Added CC||segher at gcc dot gnu.org Component|target |rtl-optimization --- Comment #2 from Uroš Bizjak --- This is the problem in the combine pass. It is substituting non-trapping compare with trapping via SELECT_CC_MODE. This particular problem happens in line 6788: --cut here-- /* If this machine has CC modes other than CCmode, check to see if we need to use a different CC mode here. */ if (GET_MODE_CLASS (GET_MODE (op0)) == MODE_CC) compare_mode = GET_MODE (op0); else if (inner_compare && GET_MODE_CLASS (GET_MODE (inner_compare)) == MODE_CC && new_code == old_code && op0 == XEXP (inner_compare, 0) && op1 == XEXP (inner_compare, 1)) compare_mode = GET_MODE (inner_compare); else compare_mode = SELECT_CC_MODE (new_code, op0, op1); --cut here-- New compare mode should NOT change trapping of the compare insn.
[Bug middle-end/82694] [8 regression] Linux kernel miscompiled since r250765
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82694 --- Comment #1 from amker at gcc dot gnu.org --- Sorry for the breakage. As I mentioned when committing the patch, it's kind of an experiment and we can always revert it. I can revert it now, but a test case for further investigation would be highly appreciated. As for the patch, it doesn't change behavior when !flag_wrapv. I assume the difference comes from explicitly specified -fwrapv option. Described by fwrapv document: fwrapv Common Report Var(flag_wrapv) Optimization Assume signed arithmetic overflow wraps around. It indicates wrap behavior for signed arithmetic overflow. This is not accurate before this patch, because apparently it also covers wrap behavior for pointer/memory_object. Unfortunately, it's not always the case because there are lots of code ignoring possible pointer wrap when fwrapv is specified. I can see GCC has the inconsistency issue here, unfortunately no easy way out. Last question is, does the code in kernel really depends on wrapping pointer arithmetic overflow behavior. The code itself can be fixed if not. Anyway, it's hard to tell without a test case. Hi richi, any comment before I revert the patch? Thanks.
[Bug c++/60336] empty struct value is passed differently in C and C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60336 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug c/82679] Uses of typedefs of arrays of _Atomic-qualified types are rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82679 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug middle-end/82694] [8 regression] Linux kernel miscompiled since r250765
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82694 --- Comment #2 from Markus Trippelsdorf --- I would not revert without a testcase. Give me a few hours...
[Bug middle-end/82694] [8 regression] Linux kernel miscompiled since r250765
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82694 --- Comment #3 from amker at gcc dot gnu.org --- (In reply to Markus Trippelsdorf from comment #2) > I would not revert without a testcase. Give me a few hours... Thanks very much for helping!
[Bug middle-end/82694] [8 regression] Linux kernel miscompiled since r250765
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82694 --- Comment #4 from Markus Trippelsdorf --- Created attachment 42456 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42456&action=edit unreduced testcase The unreduced testcase is attached. % /home/trippels/gcc_bad/usr/local/bin/gcc -fno-strict-overflow -O3 -S vsprintf.i vs. % /home/trippels/gcc_good/usr/local/bin/gcc -fno-strict-overflow -O3 -S vsprintf.i % diff -u vsprintf_good.s vsprintf_bad.s --- vsprintf_good.s 2017-10-24 10:57:50.797502298 +0200 +++ vsprintf_bad.s 2017-10-24 10:57:34.977480296 +0200 @@ -5711,7 +5711,6 @@ pushq %r14 .cfi_def_cfa_offset 24 .cfi_offset 14, -24 - movq%rsi, %r15 pushq %r13 .cfi_def_cfa_offset 32 .cfi_offset 13, -32 @@ -5722,67 +5721,55 @@ pushq %rbp .cfi_def_cfa_offset 48 .cfi_offset 6, -48 - leaq2147483647(%rdi), %rbp pushq %rbx .cfi_def_cfa_offset 56 .cfi_offset 3, -56 - movq%rdx, %r12 - movq%rdi, %rbx + leaq2147483647(%rdi), %r12 subq$40, %rsp .cfi_def_cfa_offset 96 - cmpq%rbp, %rdi - movq$0, 24(%rsp) - jbe .L846 cmpb$0, (%rsi) - movq%rdi, %rax - movq$-1, %rbp - notq%rax - movq%rax, (%rsp) - je .L847 + movq$0, 24(%rsp) + je .L925 + movq%rsi, %r14 + movq%rdx, %rbp + movq%rdi, %rbx .p2align 4,,10 .p2align 3 -.L925: +.L922: leaq24(%rsp), %rsi - movq%r15, %rdi + movq%r14, %rdi callformat_decode movzbl 24(%rsp), %edx movslq %eax, %rcx - leaq(%r15,%rcx), %r14 + leaq(%r14,%rcx), %r15 cmpb$7, %dl - ja .L848 - jmp *.L850(,%rdx,8) + ja .L847 + jmp *.L849(,%rdx,8) .section.rodata .align 8 .align 4 ... etc.
[Bug middle-end/82694] [8 regression] Linux kernel miscompiled since r250765
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82694 --- Comment #5 from Markus Trippelsdorf --- Created attachment 42457 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42457&action=edit assembly bad
[Bug middle-end/82694] [8 regression] Linux kernel miscompiled since r250765
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82694 --- Comment #6 from Markus Trippelsdorf --- Created attachment 42458 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42458&action=edit assembly good
[Bug other/82696] New: "File not found"-Message if source exists, but doesnt have .c extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82696 Bug ID: 82696 Summary: "File not found"-Message if source exists, but doesnt have .c extension Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: slohm...@uni-wuppertal.de Target Milestone: --- Created attachment 42459 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42459&action=edit Hello World-Source with .c-Extension A student tried to compile his sourcefile named "hello" (instead of the correct "hello.c") and got the message that his file could not be found. I could reproduce the issue: Files without extension should be passed to the linker iirc, but GCC seems to do some detection on it and throws a "file not found" if it contains c-code (or isnt an object-file?) I think the message is very irritating as the file does exist. Please change this to a more appropriate message like "'hello' is not an object-file". --- Steps to reproduce: 1. Take any working c-sourcecode (for example the provided "hello.c" and remove the '.c'-extension. 2. compile it with "gcc hello" -> you get a error message that the file could not be found and a "fatal error: no input files"
[Bug c/82695] New: gnu gcc (4.8 - 7.1) cannot parse some system headers in macOS (10.12)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82695
Bug ID: 82695
Summary: gnu gcc (4.8 - 7.1) cannot parse some system headers
in macOS (10.12)
Product: gcc
Version: 4.8.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: drikosev at gmail dot com
Target Milestone: ---
Hi,
gnu gcc cannot parse some system headers in macOS (10.12)
. One bug is this:
$ cat framework-1.c
#include
int main(){
return 0;
}
$ gcc framework-1.c
In file included from
/System/Library/Frameworks/CoreGraphics.framework/Headers/CGContext.h:18:0,
from
/System/Library/Frameworks/CoreGraphics.framework/Headers/CGBitmapContext.h:9,
from
/System/Library/Frameworks/CoreGraphics.framework/Headers/CoreGraphics.h:11,
from
/System/Library/Frameworks/ApplicationServices.framework/Headers/ApplicationServices.h:35,
from
/System/Library/Frameworks/Carbon.framework/Headers/Carbon.h:24,
from framework-1.c:1:
/System/Library/Frameworks/CoreGraphics.framework/Headers/CGFont.h:53:1:
error:initializer element is not constant
static const CGFontIndex kCGGlyphMax = kCGFontIndexMax;
The error is issued in gcc/c/c-typeck.c by the following fragment (7 lines):
else if (require_constant
&& !initializer_constant_valid_p (inside_init,
TREE_TYPE (inside_init)))
{
error_init ("initializer element is not constant");
inside_init = error_mark_node;
}
Is there a workaround that would allow gcc to accept such an initialisation?
Ev. Drikos
[Bug other/82543] libbacktrace does not retrieve function names on 64 bit windows (using mingw)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82543
--- Comment #2 from Antony Polukhin ---
The error is within `fileline_initialize` function in `libbacktrace/fileline.c`
If the `backtrace_state*` constructed using the `backtrace_create_state` call
with first parameter set to 0, then filename is detected in
`fileline_initialize` function, which has no means to retrieve file name on
Windows OS:
switch (pass)
{
case 0:
filename = state->filename;
break;
case 1:
filename = getexecname ();
break;
case 2:
filename = "/proc/self/exe";
break;
case 3:
filename = "/proc/curproc/file";
break;
case 4:
snprintf (buf, sizeof (buf), "/proc/%ld/object/a.out",
(long) getpid ());
filename = buf;
break;
default:
abort ();
}
[Bug c/82695] gnu gcc (4.8 - 7.1) cannot parse some system headers in macOS (10.12)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82695 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Marek Polacek --- I think this is a valid request (though not a bug), as discussed in the other BZ. You can use e.g. enums to statically initialize variables. *** This bug has been marked as a duplicate of bug 69960 ***
[Bug c/69960] "initializer element is not constant"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69960 Marek Polacek changed: What|Removed |Added CC||drikosev at gmail dot com --- Comment #16 from Marek Polacek --- *** Bug 82695 has been marked as a duplicate of this bug. ***
[Bug other/82696] "File not found"-Message if source exists, but doesnt have .c extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82696 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Richard Biener --- Well, GCC treats unsuffixed inputs as linker input. You need to specify -x c for example.
[Bug other/82696] "File not found"-Message if source exists, but doesnt have .c extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82696 slohm...@uni-wuppertal.de changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #2 from slohm...@uni-wuppertal.de --- Yes, i know about "-x c". My Problem is that GCC states that the file "hello" could not be found while it happily exists in the filesystem. So this is a "wrong error message"-Bug.
[Bug other/21823] MAXPATHLEN usage in [gcc]/fixincludes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21823 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #3 from Eric Gallager --- (In reply to Alfred M. Szmidt from comment #2) > Created attachment 9857 [details] > Don't use arbitrary limits. > > The following fixes fixincludes. > > fixincludes/ChangeLog > 2005-09-16 Alfred M. Szmidt > > * fixincl.c (quoted_file_exists): Use xmalloc to allocate memory > for FNAME. > (create_file): Use xmalloc to allocate memory for FNAME. > > * server.c (server_setup): Use dynamic allocation for BUFF. Please send this patch to the gcc-patches mailing list for review, if it still applies
[Bug target/82680] Use cmpXXss and cmpXXsd for setcc boolean compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82680 --- Comment #2 from Peter Cordes --- gcc's sequence is *probably* good, as long as it uses xor / comisd / setcc and not comisd / setcc / movzx (which gcc often likes to do for integer setcc). (u)comisd and cmpeqsd both run on the FP add unit. Agner Fog doesn't list the latency. (It's hard to measure, because you'd need to construct a round-trip back to FP.) XOR-zeroing is as cheap as a NOP on Intel SnB-family, but uses an execution port on AMD, so gcc's sequence is the same front-end uops but fewer unfused-domain uops for the execution units on SnB. Also, the xor-zeroing is off the critical path on all CPUs. (But ucomisd latency is probably as high as cmpeqsd + movd). Hmm, AMD bdver* and Ryzen take 2 uops for comisd, so for tune=generic it's probably worth thinking about using ICC's sequence. ICC's sequence is especially good if you're doing something with the integer result that can optimize away the NEG. (e.g. use it with AND instead of a CMOV to conditionally zero something, or AND it with another condition). Or if you're storing the boolean result to memory, psrld $31, %xmm0 or PAND, then movd directly to memory without going through integer regs. comisd doesn't destroy either of its args, but cmpeqsd does (without AVX). If you want both x and y afterwards (e.g. if they weren't equal, or you care about -0.0 and +0.0 being different even though they compare equal), then comisd is a win. So I think we need to look at the choices given some more surrounding code. I'll hopefully look at this some more soon.
[Bug other/32184] Library makefiles are not created properly. Re-configuring and creating warnings.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32184 Eric Gallager changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #2 from Eric Gallager --- (In reply to Eric Gallager from comment #1) > > As far as 1 goes, libjava has been removed so that part is no longer > relevant. For 2, which configure script prints that warning? No response; closing.
[Bug other/43445] Toplevel Makefile needs to export ABI variants of LD_LIBRARY_PATH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43445 Eric Gallager changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #3 from Eric Gallager --- (In reply to Eric Gallager from comment #2) > > Is this still needed now that gcj-dbtool has been removed? No response so I guess not.
[Bug tree-optimization/82697] New: Wrong optimization with aliasing and "if"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82697
Bug ID: 82697
Summary: Wrong optimization with aliasing and "if"
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ch3root at openwall dot com
Target Milestone: ---
A testcase is simplified from
https://stackoverflow.com/questions/46592132/is-this-use-of-the-effective-type-rule-strictly-conforming
:
--
#include
#include
__attribute__((__noinline__))
void test(int *pi, long *pl, int f)
{
*pl = 0;
*pi = 1;
if (f)
*pl = 2;
}
int main(void)
{
void *p = malloc(10);
test(p, p, 0);
printf("%d\n", *(int *)p);
}
--
Results:
--
$ gcc -std=c11 -pedantic -Wall -Wextra test.c && ./a.out
1
$ gcc -std=c11 -pedantic -Wall -Wextra -O3 test.c && ./a.out
0
--
gcc version: gcc (GCC) 8.0.0 20171024 (experimental)
[Bug target/71233] [ARM, AArch64] missing AdvSIMD intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71233
James Greenhalgh changed:
What|Removed |Added
CC||jgreenhalgh at gcc dot gnu.org
--- Comment #15 from James Greenhalgh ---
(In reply to Christophe Lyon from comment #6)
> I used the perl script and intrinsics list to build several subsets:
>
> # List of duplicates: (a few intrinsics are listed twice
> # with different prototypes, it's likely a bug in the documentation,
> # not sure where to report this?)
> perl neon_intrinsics.pl < intrinsics.txt |awk '{print $3;}' |sort |uniq -c
> |sort -n| grep -v '^ *1 '
2 vqrdmlah_laneq_s16
2 vqrdmlah_lane_s16
2 vqrdmlahq_laneq_s16
2 vqrdmlahq_lane_s16
2 vqrdmlsh_laneq_s16
2 vqrdmlsh_lane_s16
2 vqrdmlshq_laneq_s16
2 vqrdmlshq_lane_s16
These are bugs s16 should be s32 for all of these. I've fixed them for the next
spec release.
2 vreinterpretq_u64_p64
2 vreinterpret_u64_p64
These are just duplicates. I've fixed them for the next spec release.
2 vshll_high_n_s16
2 vshll_high_n_s32
2 vshll_high_n_s8
2 vshll_high_n_u16
2 vshll_high_n_u32
2 vshll_high_n_u8
2 vshll_n_s16
2 vshll_n_s32
2 vshll_n_s8
2 vshll_n_u16
2 vshll_n_u32
2 vshll_n_u8
These are all attempts to encode that two different instructions can be
generated depending on whether the 'n' parameter is equal to the number of bits
in the vector lane. For example,
vshll_n_s16 (int8x8_t a, __builtin_constant_p(n))
Generates SSHLL if 0 <= n < 16, and SHLL if n == 16.
I agree that having two entries for these can be confusing, but you can think
of them as "false positives" for now. I'll think about how I could improve the
documentation to allow us to give this information without duplicating the
prototypes.
[Bug middle-end/82694] [8 regression] Linux kernel miscompiled since r250765
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82694
--- Comment #7 from amker at gcc dot gnu.org ---
I didn't go through all the differences, but below is an example of using
wrapping behavior for pointers:
int vsnprintf(char *buf, size_t size, const char *fmt, va_list args)
{
unsigned long long num;
char *str, *end;
struct printf_spec spec = {0};
//...
str = buf;
end = buf + size;
if (end < buf) {
end = ((void *)-1);
size = end - buf;
}
//...
}
int vsprintf(char *buf, const char *fmt, va_list args)
{
return vsnprintf(buf, ((int)(~0U>>1)), fmt, args);
}
So vsnprintf get 0x7fff as the second argument, the comparison between end
and buf gets folded with undefined overflow behavior assumption.
[Bug rtl-optimization/82628] [8 Regression] wrong code at -Os on x86_64-linux-gnu in the 32-bit mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82628 --- Comment #18 from Jakub Jelinek --- Author: jakub Date: Tue Oct 24 10:44:56 2017 New Revision: 254039 URL: https://gcc.gnu.org/viewcvs?rev=254039&root=gcc&view=rev Log: PR target/82628 * config/i386/i386.md (addcarry, subborrow): Change patterns to better describe from which operation the CF is computed. (addcarry_0, subborrow_0): New patterns. * config/i386/i386.c (ix86_expand_builtin) : Pass one LTU with [DT]Imode and another one with [SD]Imode. If arg0 is 0, use _0 suffixed expanders instead of emitting a comparison before it. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.md
[Bug other/82696] "File not found"-Message if source exists, but doesnt have .c extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82696 Jonathan Wakely changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |WAITING Last reconfirmed||2017-10-24 Ever confirmed|0 |1 --- Comment #3 from Jonathan Wakely --- I can't reproduce this: mp$ gcc hello hello: file not recognized: File format not recognized collect2: error: ld returned 1 exit status You're missing the necessary information for us to understand the report: https://gcc.gnu.org/bugs/ N.B. GCC 4.9.2 is unsupported, bugs will only be fixed in supported releases (currently the GCC 6 and GCC 7 series).
[Bug tree-optimization/82697] [6/7/8 Regression] Wrong optimization with aliasing and "if"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82697
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Status|UNCONFIRMED |NEW
Known to work||4.2.4
Keywords||wrong-code
Last reconfirmed||2017-10-24
Ever confirmed|0 |1
Summary|Wrong optimization with |[6/7/8 Regression] Wrong
|aliasing and "if" |optimization with aliasing
||and "if"
Target Milestone|--- |6.5
Known to fail||4.3.5, 4.8.5, 7.2.1, 8.0
--- Comment #1 from Richard Biener ---
This is a bug in conditional store elimination happening with -O1+ and
-fstrict-aliasing:
test (int * pi, long int * pl, int f)
{
long int cstore_10;
[100.00%]:
*pi_5(D) = 1;
if (f_7(D) != 0)
goto ; [54.00%]
else
goto ; [46.00%]
[46.00%]:
[100.00%]:
# cstore_10 = PHI <0(3), 2(2)>
*pl_3(D) = cstore_10;
so it sank a store across another store.
[Bug target/82659] Unnecessary ENDBR in static/local functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82659 --- Comment #2 from hjl at gcc dot gnu.org --- Author: hjl Date: Tue Oct 24 10:52:50 2017 New Revision: 254040 URL: https://gcc.gnu.org/viewcvs?rev=254040&root=gcc&view=rev Log: i386: Don't insert ENDBR at function entrance when called directly There is no need to insert ENDBR instruction at function entrance if function is only called directly. gcc/ PR target/82659 * config/i386/i386.c (rest_of_insert_endbranch): Don't insert ENDBR instruction at function entrance if function is only called directly. gcc/testsuite/ PR target/82659 * gcc.target/i386/cet-label-2.c: New test. * gcc.target/i386/cet-sjlj-4.c: Likewise. * gcc.target/i386/cet-sjlj-5.c: Likewise. * gcc.target/i386/cet-switch-3.c: Likewise. * gcc.target/i386/pr82659-1.c: Likewise. * gcc.target/i386/pr82659-2.c: Likewise. * gcc.target/i386/pr82659-3.c: Likewise. * gcc.target/i386/pr82659-4.c: Likewise. * gcc.target/i386/pr82659-5.c: Likewise. * gcc.target/i386/pr82659-6.c: Likewise. Added: trunk/gcc/testsuite/gcc.target/i386/cet-label-2.c trunk/gcc/testsuite/gcc.target/i386/cet-sjlj-4.c trunk/gcc/testsuite/gcc.target/i386/cet-sjlj-5.c trunk/gcc/testsuite/gcc.target/i386/cet-switch-3.c trunk/gcc/testsuite/gcc.target/i386/pr82659-1.c trunk/gcc/testsuite/gcc.target/i386/pr82659-2.c trunk/gcc/testsuite/gcc.target/i386/pr82659-3.c trunk/gcc/testsuite/gcc.target/i386/pr82659-4.c trunk/gcc/testsuite/gcc.target/i386/pr82659-5.c trunk/gcc/testsuite/gcc.target/i386/pr82659-6.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug ipa/82698] New: Spurious warning __builtin_memset at O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82698
Bug ID: 82698
Summary: Spurious warning __builtin_memset at O3
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: paulg at chiark dot greenend.org.uk
CC: marxin at gcc dot gnu.org
Target Milestone: ---
With the following code fragment
#include
void foo(std::vector & bar)
{
bar.resize(bar.size() - 1);
}
compiled with
g++ -c -O3 -Wall -Wextra test.cpp
the following is produced
cc1plus: warning: ‘void* __builtin_memset(void*, int, long unsigned int)’:
specified size 18446744073709551612 exceeds maximum object size
9223372036854775807 -Wstringop-overflow=]
Since the compiler cannot know if the user has arranged to never pass a
argument which would produce this problem this seems like overreach on the part
of the compiler.
[Bug tree-optimization/82697] [6/7/8 Regression] Wrong optimization with aliasing and "if"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82697 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- So cselim transforms *pi = 1; if (f) *pl = 2; into *pi = 1; if (!f) tem = *pl; else tem = 2; *pl = tem; that is of course only valid in case we can validly load from *pl which we can't in this case. Given there's no check for validity here there's nothing else than using alias-set zero for the load ... We also have to avoid changing the dynamic type of the object which means the store _also_ has to use alias-set zero. I have a fix.
[Bug tree-optimization/82697] [6/7/8 Regression] Wrong optimization with aliasing and "if"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82697 --- Comment #3 from Richard Biener --- Created attachment 42460 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42460&action=edit untested patch
[Bug target/82659] Unnecessary ENDBR in static/local functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82659 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from H.J. Lu --- Fixed.
[Bug target/81652] [meta-bug] -fcf-protection=full -mcet bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81652 Bug 81652 depends on bug 82659, which changed state. Bug 82659 Summary: Unnecessary ENDBR in static/local functions https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82659 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug rtl-optimization/82692] [8 Regression] Ordered comparisons used for unordered built-ins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82692 --- Comment #3 from Segher Boessenkool --- The combine output you showed is _not_ succeeding though? "matched" just means the rtx was recog()'ed; not that it was actually replaced.
[Bug target/81769] Unnecessary stack realign with -mavx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81769 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |8.0 --- Comment #2 from H.J. Lu --- Fixed.
[Bug other/82696] "File not found"-Message if source exists, but doesnt have .c extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82696 --- Comment #4 from slohm...@uni-wuppertal.de --- Ok, have confirmed that it works fine with GCC 5/6/7, so it has obviously been fixed. Didn't find a bugreport so i assumed it would be still there in newer versions too...by bad. Keep up the good work!
[Bug other/82696] "File not found"-Message if source exists, but doesnt have .c extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82696 Jonathan Wakely changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME --- Comment #5 from Jonathan Wakely --- FWIW I get the same behaviour for every version I tried, back to 4.3
[Bug rtl-optimization/82683] Combine: GCC generates bad code with -tune=thunderx2t99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82683 Wilco changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-10-24 CC||segher at gcc dot gnu.org, ||wilco at gcc dot gnu.org Component|target |rtl-optimization Summary|GCC generates bad code with |Combine: GCC generates bad |-tune=thunderx2t99 |code with ||-tune=thunderx2t99 Ever confirmed|0 |1 --- Comment #1 from Wilco --- Combine seems to do the correct thing at first, creating a ldrsw but it then invents a spurious REG_DEAD for r83: Successfully matched this instruction: (set (reg:DI 83 [ _26 ]) (sign_extend:DI (mem:SI (plus:DI (mult:DI (reg:DI 83 [ _26 ]) (const_int 4 [0x4])) (reg/f:DI 76 [ _4 ])) [8 *_7+0 S4 A32]))) Successfully matched this instruction: (set (reg/v:SI 82 [ pD.3023 ]) (subreg:SI (reg:DI 83 [ _26 ]) 0)) allowing combination of insns 19, 20 and 21 original costs 8 + 20 + 4 = 32 replacement costs 28 + 4 = 32 deferring rescan insn with uid = 21. deferring deletion of insn with uid = 19. modifying insn i220: r83:DI=sign_extend([r83:DI*0x4+r76:DI]) REG_DEAD r76:DI deferring rescan insn with uid = 20. modifying insn i321: r82:SI=r83:DI#0 ** all good so far, both r82/r83 are live REG_DEAD r83:DI *** OOPS REG_DEAD r83:DI REG_DEAD r83:DI deferring rescan insn with uid = 21. The REG_DEAD r83 incorrect as both r82 and r83 are still live. I think it may be due to this earlier combine: Trying 18 -> 19: Successfully matched this instruction: (set (reg/f:DI 78 [ _7 ]) (plus:DI (ashift:DI (reg:DI 83 [ _26 ]) (const_int 2 [0x2])) (reg/f:DI 76 [ _4 ]))) allowing combination of insns 18 and 19 original costs 4 + 4 = 8 replacement cost 8 deferring deletion of insn with uid = 18. modifying insn i319: r78:DI=r83:DI<<0x2+r76:DI REG_DEAD r83:DI REG_DEAD r76:DI deferring rescan insn with uid = 19. So I guess the bug is that when combining multiple instructions, dead notes aren't removed if later instructions assign the the same register.
[Bug libstdc++/82685] basic_string_view operator""sv(const char*, size_t) should be noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82685 --- Comment #5 from Jonathan Wakely --- (In reply to Pavel I. Kryukov from comment #3) > It seems that Clang-Tidy simply checks whether `noexcept` is specified, is > it a Clang-Tidy problem then? I would say so, yes. Not every function without noexcept will throw for all input arguments. Obviously a constexpr function that just invokes a constexpr constructor that just sets two trivial member variables can't throw, under any circumstances, ever. I'll add 'noexcept' to those functions anyway, as it doesn't hurt.
[Bug libstdc++/82685] basic_string_view operator""sv(const char*, size_t) should be noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82685 --- Comment #6 from Jonathan Wakely --- Author: redi Date: Tue Oct 24 11:28:40 2017 New Revision: 254041 URL: https://gcc.gnu.org/viewcvs?rev=254041&root=gcc&view=rev Log: PR libstdc++/82685 add 'noexcept' to string_view literals PR libstdc++/82685 * include/experimental/string_view (operator""sv): Add noexcept. * include/std/string_view (operator""sv): Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/experimental/string_view trunk/libstdc++-v3/include/std/string_view
[Bug libstdc++/82685] basic_string_view operator""sv(const char*, size_t) should be noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82685 Pavel I. Kryukov changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Pavel I. Kryukov --- Thank you, Jonathan. I'll report the same bug to LLVM libc++ and to Clang-Tidy.
[Bug libstdc++/82685] basic_string_view operator""sv(const char*, size_t) should be noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82685 Jonathan Wakely changed: What|Removed |Added Status|RESOLVED|ASSIGNED Resolution|FIXED |--- --- Comment #8 from Jonathan Wakely --- I still plan to fix it on the gcc-7-branch so I'll close it then.
[Bug c++/82657] when using a template function pointer as a non-type template parameters, the template function will not be defined in some situation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82657 --- Comment #2 from Jonathan Wakely --- I'm pretty sure this is a dup of another bug I confirmed recently.
[Bug rtl-optimization/82683] Combine: GCC generates bad code with -tune=thunderx2t99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82683 --- Comment #2 from Segher Boessenkool --- At the start of combine you have insn_cost 4 for18: r91:DI=r83:DI<<0x2 REG_DEAD r83:DI Is that death note not correct?
[Bug rtl-optimization/82683] Combine: GCC generates bad code with -tune=thunderx2t99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82683 --- Comment #3 from Segher Boessenkool --- Ah. So we start with insn_cost 4 for18: r91:DI=r83:DI<<0x2 REG_DEAD r83:DI insn_cost 4 for19: r78:DI=r76:DI+r91:DI REG_DEAD r91:DI REG_DEAD r76:DI insn_cost 20 for20: r82:SI=[r78:DI] REG_DEAD r78:DI insn_cost 4 for21: r83:DI=sign_extend(r82:SI) and first 18,19 are combined, and then 19,20,21. Both 19 and 21 set r83, it is dead after 19, but that note is put on 21.
[Bug rtl-optimization/82683] Combine: GCC generates bad code with -tune=thunderx2t99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82683 --- Comment #4 from Wilco --- (In reply to Segher Boessenkool from comment #3) > Ah. So we start with > > insn_cost 4 for18: r91:DI=r83:DI<<0x2 > REG_DEAD r83:DI > insn_cost 4 for19: r78:DI=r76:DI+r91:DI > REG_DEAD r91:DI > REG_DEAD r76:DI > insn_cost 20 for20: r82:SI=[r78:DI] > REG_DEAD r78:DI > insn_cost 4 for21: r83:DI=sign_extend(r82:SI) > > and first 18,19 are combined, and then 19,20,21. Both 19 and 21 set > r83, it is dead after 19, but that note is put on 21. Yes, it doesn't show intermediate stages but I guess before merging 18+19+20 with 21 we have: r82:SI=MEM([r83:DI*0x4+r76:DI]) REG_DEAD r83 r83:DI=sign_extend r82:SI This is correct. However when it merges these, it swaps r82 for r83 on the load, and now the REG_DEAD in the load needs to be removed as it is no longer valid: r83:DI=sign_extend([r83:DI*0x4+r76:DI]) ***REG_DEAD r83***
[Bug lto/82575] [8 Regression] lto debugobj references __gnu_lto_slim, ld test liblto-17 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82575 --- Comment #10 from Alan Modra --- Author: amodra Date: Tue Oct 24 12:45:01 2017 New Revision: 254042 URL: https://gcc.gnu.org/viewcvs?rev=254042&root=gcc&view=rev Log: PR82687, g++.dg/asan/default-options-1.C fails with PR82575 fix The problem with making discarded symbols hidden is that the non-default visibility is sticky. When symbols other than the __gnu_lto ones are discarded that turns out to be a bad idea. PR lto/82687 PR lto/82575 * simple-object-elf.c (simple_object_elf_copy_lto_debug_sections): Only make __gnu_lto symbols hidden. Delete outdated comment. Silence ISO C warning. Modified: trunk/libiberty/ChangeLog trunk/libiberty/simple-object-elf.c
[Bug lto/82687] [8 regression] g++.dg/asan/default-options-1.C fails starting with r253914
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82687 --- Comment #2 from Alan Modra --- Author: amodra Date: Tue Oct 24 12:45:01 2017 New Revision: 254042 URL: https://gcc.gnu.org/viewcvs?rev=254042&root=gcc&view=rev Log: PR82687, g++.dg/asan/default-options-1.C fails with PR82575 fix The problem with making discarded symbols hidden is that the non-default visibility is sticky. When symbols other than the __gnu_lto ones are discarded that turns out to be a bad idea. PR lto/82687 PR lto/82575 * simple-object-elf.c (simple_object_elf_copy_lto_debug_sections): Only make __gnu_lto symbols hidden. Delete outdated comment. Silence ISO C warning. Modified: trunk/libiberty/ChangeLog trunk/libiberty/simple-object-elf.c
[Bug rtl-optimization/82683] Combine: GCC generates bad code with -tune=thunderx2t99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82683 --- Comment #5 from Segher Boessenkool --- Oh, it does show the intermediate results: Trying 18 -> 19: Successfully matched this instruction: (set (reg/f:DI 78 [ _7 ]) (plus:DI (ashift:DI (reg:DI 83 [ _26 ]) (const_int 2 [0x2])) (reg/f:DI 76 [ _4 ]))) allowing combination of insns 18 and 19 original costs 4 + 4 = 8 replacement cost 8 deferring deletion of insn with uid = 18. modifying insn i319: r78:DI=r83:DI<<0x2+r76:DI REG_DEAD r83:DI REG_DEAD r76:DI deferring rescan insn with uid = 19. (How do you dump things? You forgot a -all?)
[Bug lto/82687] [8 regression] g++.dg/asan/default-options-1.C fails starting with r253914
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82687 Alan Modra changed: What|Removed |Added Status|NEW |RESOLVED Blocks||82575 Resolution|--- |FIXED --- Comment #3 from Alan Modra --- Fixed Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82575 [Bug 82575] [8 Regression] lto debugobj references __gnu_lto_slim, ld test liblto-17 fails
[Bug lto/82575] [8 Regression] lto debugobj references __gnu_lto_slim, ld test liblto-17 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82575 Bug 82575 depends on bug 82687, which changed state. Bug 82687 Summary: [8 regression] g++.dg/asan/default-options-1.C fails starting with r253914 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82687 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug rtl-optimization/82683] Combine: GCC generates bad code with -tune=thunderx2t99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82683 --- Comment #6 from Wilco --- (In reply to Segher Boessenkool from comment #5) > Oh, it does show the intermediate results: > > Trying 18 -> 19: > Successfully matched this instruction: > (set (reg/f:DI 78 [ _7 ]) > (plus:DI (ashift:DI (reg:DI 83 [ _26 ]) > (const_int 2 [0x2])) > (reg/f:DI 76 [ _4 ]))) > allowing combination of insns 18 and 19 > original costs 4 + 4 = 8 > replacement cost 8 > deferring deletion of insn with uid = 18. > modifying insn i319: r78:DI=r83:DI<<0x2+r76:DI > REG_DEAD r83:DI > REG_DEAD r76:DI > deferring rescan insn with uid = 19. > > (How do you dump things? You forgot a -all?) Yes, but this is all it shows for the bit that goes wrong: allowing combination of insns 19, 20 and 21 original costs 8 + 20 + 4 = 32 replacement costs 28 + 4 = 32 deferring rescan insn with uid = 21. deferring deletion of insn with uid = 19. modifying insn i220: r83:DI=sign_extend([r83:DI*0x4+r76:DI]) REG_DEAD r76:DI deferring rescan insn with uid = 20. modifying insn i321: r82:SI=r83:DI#0 REG_DEAD r83:DI REG_DEAD r83:DI REG_DEAD r83:DI deferring rescan insn with uid = 21. I guess it would be good if it shows the instructions it's trying to combine in this part, because it's impossible to follow when the instructions involved have been changed already...
[Bug rtl-optimization/82683] Combine: GCC generates bad code with -tune=thunderx2t99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82683 --- Comment #7 from Segher Boessenkool --- Yes, it requires to look back a bit (the info always is in this dump file though!) The alternative would be to dump even more info, grow the log files by a factor two or so.
[Bug target/82699] New: ENDBR isn't generated at function entrance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82699
Bug ID: 82699
Summary: ENDBR isn't generated at function entrance
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: igor.v.tsimbalist at intel dot com
Blocks: 81652
Target Milestone: ---
[hjl@gnu-tools-1 xxx]$ cat x.i
extern int bar (int);
int
foo (int i)
{
return bar (i);
}
[hjl@gnu-tools-1 xxx]$ make
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -fcf-protection -mcet -O2
-mfentry -pg -S x.i
[hjl@gnu-tools-1 xxx]$ cat x.s
.file "x.i"
.text
.p2align 4,,15
.globl foo
.type foo, @function
foo:
.LFB0:
.cfi_startproc
1: call__fentry__
endbr64 <<<<<<<<<<<<<<<< Wrong place.
subq$8, %rsp
.cfi_def_cfa_offset 16
addq$8, %rsp
.cfi_def_cfa_offset 8
jmp bar
.cfi_endproc
.LFE0:
.size foo, .-foo
.ident "GCC: (GNU) 8.0.0 20171024 (experimental)"
.section.note.GNU-stack,"",@progbits
.section.note.gnu.property,"a"
.align 8
.long1f - 0f
.long4f - 1f
.long5
0:
.string "GNU"
1:
.align 8
.long0xc002
.long3f - 2f
2:
.long0x3
3:
.align 8
4:
[hjl@gnu-tools-1 xxx]$
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81652
[Bug 81652] [meta-bug] -fcf-protection=full -mcet bugs
[Bug rtl-optimization/82683] Combine: GCC generates bad code with -tune=thunderx2t99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82683 --- Comment #8 from Wilco --- (In reply to Segher Boessenkool from comment #7) > Yes, it requires to look back a bit (the info always is in this dump > file though!) > > The alternative would be to dump even more info, grow the log files > by a factor two or so. Well if the size of the dump is an issue, I guess all the failed to match cases could be omitted and moved to a different option. Also you could keep the dump a similar size size by emitting less defer/delete notes. Eg. this would make understanding the output easier: Combining insns 19, 20, 21 (old cost 8 + 20 + 4 = 32): 19: r78:DI=r83:DI<<0x2+r76:DI REG_DEAD r83:DI REG_DEAD r76:DI 20: ... 21: ... into (new cost 28 + 4 = 32): 19: (defer deletion) 20: r83:DI=sign_extend([r83:DI*0x4+r76:DI]) 21: r82:SI=r83:DI#0 REG_DEAD r83:DI (defer rescan)
[Bug ada/82639] Legal program rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82639 Victor Porton changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #3 from Victor Porton --- They say it is NOT an error in the compiler: https://groups.google.com/d/msg/comp.lang.ada/IFjnioG1a28/Qcw5sIyUAgAJ
[Bug target/82674] ICE with -fstack-clash-protection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82674 --- Comment #1 from Peter Bergner --- That offset is too large to fit in the stdu immed field, so it really shouldn't have been accepted by the rs6000_legitim*_ functions.
[Bug rtl-optimization/82692] [8 Regression] Ordered comparisons used for unordered built-ins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82692
--- Comment #4 from Uroš Bizjak ---
(In reply to Segher Boessenkool from comment #3)
> The combine output you showed is _not_ succeeding though? "matched"
> just means the rtx was recog()'ed; not that it was actually replaced.
FAOD, this is the sequence before combine:
--cut here--
(insn 7 6 8 2 (set (reg:CCFPU 17 flags)
(compare:CCFPU (reg:DF 95)
(reg/v:DF 91 [ x ]))) "pr82692.c":9 52 {*cmpiudf}
(expr_list:REG_DEAD (reg:DF 95)
(expr_list:REG_EQUAL (compare:CCFPU (const_double:DF 0.0 [0x0.0p+0])
(reg/v:DF 91 [ x ]))
(nil
(insn 8 7 9 2 (set (reg:QI 94)
(unlt:QI (reg:CCFPU 17 flags)
(const_int 0 [0]))) "pr82692.c":9 664 {*setcc_qi}
(expr_list:REG_DEAD (reg:CCFPU 17 flags)
(nil)))
(insn 9 8 10 2 (set (reg:CCZ 17 flags)
(compare:CCZ (reg:QI 94)
(const_int 0 [0]))) "pr82692.c":9 1 {*cmpqi_ccno_1}
(expr_list:REG_DEAD (reg:QI 94)
(nil)))
(jump_insn 10 9 32 2 (set (pc)
(if_then_else (eq (reg:CCZ 17 flags)
(const_int 0 [0]))
(label_ref:DI 34)
(pc))) "pr82692.c":9 668 {*jcc}
(expr_list:REG_DEAD (reg:CCZ 17 flags)
(int_list:REG_BR_PROB 182536112 (nil)))
-> 34)
--cut here--
which is converted by combine pass to:
--cut here--
(note 7 6 8 2 NOTE_INSN_DELETED)
(note 8 7 9 2 NOTE_INSN_DELETED)
(insn 9 8 10 2 (set (reg:CCFP 17 flags)
(compare:CCFP (reg:DF 95)
(reg/v:DF 91 [ x ]))) "pr82692.c":9 50 {*cmpidf}
(expr_list:REG_DEAD (reg:DF 95)
(nil)))
(jump_insn 10 9 32 2 (set (pc)
(if_then_else (ge (reg:CCFP 17 flags)
(const_int 0 [0]))
(label_ref:DI 34)
(pc))) "pr82692.c":9 668 {*jcc}
(expr_list:REG_DEAD (reg:CCZ 17 flags)
(int_list:REG_BR_PROB 182536112 (nil)))
-> 34)
--cut here--
UNLT compare (CCFPUmode) has been converted to GE compare (CCFPmode). This is
not correct as far as traps are concerned, since UNLT doesn't trap on qNaN,
while GE does.
[Bug c++/82307] unscoped enum-base incorrect cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82307 --- Comment #7 from paolo at gcc dot gnu.org --- Author: paolo Date: Tue Oct 24 13:49:13 2017 New Revision: 254046 URL: https://gcc.gnu.org/viewcvs?rev=254046&root=gcc&view=rev Log: /cp 2017-10-24 Mukesh Kapoor Paolo Carlini PR c++/82307 * cvt.c (type_promotes_to): Implement C++17, 7.6/4, about unscoped enumeration type whose underlying type is fixed. /testsuite 2017-10-24 Mukesh Kapoor Paolo Carlini PR c++/82307 * g++.dg/cpp0x/enum35.C: New. * g++.dg/cpp0x/enum36.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/cpp0x/enum35.C trunk/gcc/testsuite/g++.dg/cpp0x/enum36.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cvt.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/82697] [6/7 Regression] Wrong optimization with aliasing and "if"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82697 Richard Biener changed: What|Removed |Added Known to work||8.0 Summary|[6/7/8 Regression] Wrong|[6/7 Regression] Wrong |optimization with aliasing |optimization with aliasing |and "if"|and "if" --- Comment #4 from Richard Biener --- Fixed on trunk sofar.
[Bug tree-optimization/82697] [6/7 Regression] Wrong optimization with aliasing and "if"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82697 --- Comment #5 from Richard Biener --- Author: rguenth Date: Tue Oct 24 13:51:45 2017 New Revision: 254047 URL: https://gcc.gnu.org/viewcvs?rev=254047&root=gcc&view=rev Log: 2017-10-24 Richard Biener PR tree-optimization/82697 * tree-ssa-phiopt.c (cond_store_replacement): Use alias-set zero for conditional load and unconditional store. * gcc.dg/torture/pr82697.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr82697.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-phiopt.c
[Bug c++/82307] unscoped enum-base incorrect cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82307 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Assignee|mukesh.kapoor at oracle dot com|unassigned at gcc dot gnu.org Target Milestone|--- |8.0 --- Comment #8 from Paolo Carlini --- Fixed.
[Bug rtl-optimization/82683] Combine: GCC generates bad code with -tune=thunderx2t99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82683 --- Comment #9 from Segher Boessenkool --- The "failed to match" messages are hugely important (in fact, I want it to print more: _why_ did combination fail, in all the cases where it is not because of recog). The "deferring deletion" messages are not from combine (from df, instead). Yes they are annoying, much more so in other passes.
[Bug target/82651] After r253879 GCC 8.0 can't build cross compiler for mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82651 Nicolai Josuttis changed: What|Removed |Added CC||nico at josuttis dot de --- Comment #2 from Nicolai Josuttis --- same problem when trying to build gcc-8-20171022.tar.xz on CygWin with Win64.
[Bug middle-end/78809] Inline strcmp with small constant strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809 --- Comment #10 from Qing Zhao --- >> From the data, we can see the inlined version of strcmp (by glibc) is much >> slower than the direct call to strcmp. (this is for size 2) >> I am using GCC farm machine gcc116: > > This result doesn't make sense - it looks like GCC is moving the strcmp call > in > the 2nd case as a loop invariant, so you're just measuring a loop with just a > subtract and orr instruction… Yes, Wilco is right here. -ftree-loop-im moves the call to strcmp out of the loop. in order to avoid this issue, I changed the options to -O -fno-tree-loop-im and checked the assembly of the routine “cmp2” for the INLINED and Non-INLINED version. Inlined version: cmp2: mov x4, x0 mov w2, 51712 movkw2, 0x3b9a, lsl 16 mov w0, 0 mov w3, 102 b .L3 .L2: neg w1, w1 orr w0, w0, w1 subsw2, w2, #1 beq .L5 .L3: ldrbw1, [x4] subsw1, w3, w1 bne .L2 ldrbw1, [x4, 1] neg w1, w1 b .L2 .L5: ret Non-inlined version: cmp2: stp x29, x30, [sp, -48]! add x29, sp, 0 stp x19, x20, [sp, 16] stp x21, x22, [sp, 32] mov x22, x0 mov w19, 51712 movkw19, 0x3b9a, lsl 16 mov w20, 0 adrpx21, .LC0 add x21, x21, :lo12:.LC0 .L2: mov x1, x21 mov x0, x22 bl strcmp orr w20, w20, w0 subsw19, w19, #1 bne .L2 mov w0, w20 ldp x19, x20, [sp, 16] ldp x21, x22, [sp, 32] ldp x29, x30, [sp], 48 ret Then, the run-time performance data is: qinzhao@gcc116:~/Bugs/78809/const_cmp/perf$ sh t_p /home/qinzhao/Install/latest/bin/gcc -O -fno-tree-loop-im t_p_1.c t_p.c -DINLINED inlined version 34.73user 0.00system 0:34.73elapsed 99%CPU (0avgtext+0avgdata 360maxresident)k 0inputs+0outputs (0major+135minor)pagefaults 0swaps /home/qinzhao/Install/latest/bin/gcc -O -fno-tree-loop-im t_p_1.c t_p.c non-inlined version 138.79user 0.00system 2:18.77elapsed 100%CPU (0avgtext+0avgdata 356maxresident)k 0inputs+0outputs (0major+135minor)pagefaults 0swaps Yes, looks like that the inlined version is much faster than the non-inlined version on aarch64 platform.
[Bug tree-optimization/82700] New: ICE in printf-return-value with -fexec-charset=EBCDIC-US: converting to execution character set: Invalid or incomplete multibyte or wide character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82700
Bug ID: 82700
Summary: ICE in printf-return-value with
-fexec-charset=EBCDIC-US: converting to execution
character set: Invalid or incomplete multibyte or wide
character
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The following ICE came up in a discussion Re: [RFC] New pragma exec_charset
(https://gcc.gnu.org/ml/gcc-patches/2017-10/msg01672.html). The program is
expected to compile with the same output as with -fexec-charset=IBM1047.
$ cat c.c && gcc -Wall -O2 -fexec-charset=EBCDIC-US c.c
int main (void)
{
char d[5];
int n = __builtin_sprintf (d, "i=%i", 12345);
if (n != 7)
__builtin_abort ();
}
c.c: In function ‘main’:
c.c:5:34: warning: too many arguments for format [-Wformat-extra-args]
int n = __builtin_sprintf (d, "i=%i", 12345);
^~
during GIMPLE pass: printf-return-value
c.c:10:0: internal compiler error: converting to execution character set:
Invalid or incomplete multibyte or wide character
0x82fe9f c_cpp_error(cpp_reader*, int, int, rich_location*, char const*,
__va_list_tag (*) [1])
/ssd/src/gcc/svn/gcc/c-family/c-common.c:6075
0x1905da0 cpp_diagnostic_at
/ssd/src/gcc/svn/libcpp/errors.c:60
0x1905e72 cpp_diagnostic
/ssd/src/gcc/svn/libcpp/errors.c:91
0x1905f27 cpp_error(cpp_reader*, int, char const*, ...)
/ssd/src/gcc/svn/libcpp/errors.c:104
0x19067c0 cpp_errno(cpp_reader*, int, char const*)
/ssd/src/gcc/svn/libcpp/errors.c:300
0x18fa3c6 cpp_host_to_exec_charset(cpp_reader*, unsigned int)
/ssd/src/gcc/svn/libcpp/charset.c:798
0x82feeb c_common_to_target_charset(long)
/ssd/src/gcc/svn/gcc/c-family/c-common.c:6093
0x17de7a9 init_target_to_host_charmap
/ssd/src/gcc/svn/gcc/gimple-ssa-sprintf.c:319
0x17e68a8 execute
/ssd/src/gcc/svn/gcc/gimple-ssa-sprintf.c:3990
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug middle-end/78809] Inline strcmp with small constant strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809 --- Comment #11 from Qing Zhao --- (In reply to Wilco from comment #9) > str(n)cmp with a constant string can be changed into memcmp if the string has > a > known alignment or is an array of known size. We should check the common cases > are implemented. Please provide an example in which a str(n)cmp with a constant string can be changed into memcmp. (From my understanding, for the strcmp (p, “fish”), since we don’t know what will be in the string pointed by “p”, and there might be NULL_terminator in any of the place of p, we have to compare each char in “p” one by one, do I miss anything here?)
[Bug target/82674] ICE with -fstack-clash-protection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82674 --- Comment #2 from Jeffrey A. Law --- Right, but it's the expander to allocate dynamic space that's creating the bogus RTL. It's a trivial fix that I just need to run through some testing.
[Bug target/82641] Unable to enable crc32 for a certain function with target attribute on ARM (aarch32)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82641 --- Comment #2 from Richard Earnshaw --- ARMv8-a is the only architecture variant where the CRC extension is optional. In later variants it is enabled by default; in earlier versions of the architecture it doesn't exist. Your report lacks a testcase we can use to examine this more fully.
[Bug web/82686] Debian sid powerpc64-unknown-linux-gnu 4.13.0-1-powerpc64 bootstrap breaks in stage3 with unexpected requirement for bdw-gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82686 --- Comment #4 from Dennis Clarke --- So this is not at all clear about how to continue. I did install the new requirement or at least the "undocumented" dependency from the Debian pkg tree : nix:~# apt-get install libgc-dev Reading package lists... Done Building dependency tree Reading state information... Done The following additional packages will be installed: libgc1c2 The following NEW packages will be installed: libgc-dev libgc1c2 0 upgraded, 2 newly installed, 0 to remove and 14 not upgraded. Need to get 569 kB of archives. After this operation, 1,553 kB of additional disk space will be used. Do you want to continue? [Y/n] . . . However the bootstrap still fails in the stage3 phase : . . . checking whether the target supports thread-local storage... yes checking if the type of bitfields matters... yes checking for bdw garbage collector... checking for system boehm-gc... configure: error: system bdw-gc required but not found gmake[1]: *** [Makefile:22695: configure-target-libobjc] Error 1 gmake[1]: Leaving directory '/usr/local/build/gcc-7.2.0_linux_4.13.0-1-powerpc64.003' gmake: *** [Makefile:941: all] Error 2 Command exited with non-zero status 2 nix_$ nix_$ cat stage_current stage3 So what exactly is needed in order to get past this? Documented or otherwise?
[Bug target/82641] Unable to enable crc32 for a certain function with target attribute on ARM (aarch32)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82641
--- Comment #3 from Yichao Yu ---
> ARMv8-a is the only architecture variant where the CRC extension is optional
Not really. There's also armv8-r and armv8-m. Also, I believe code compiled for
armv7-a can run on armv8-a hardware and can also optionally enable armv8
features including CRC extension. I was hoping that GCC can be smart enough to
enable the correct armv8 variant automatically.
Test case is just
```
#include
#pragma GCC push_options
#pragma GCC target("armv8-a+crc")
__attribute__((target("armv8-a+crc"))) uint32_t crc32cw(uint32_t crc, uint32_t
val)
{
uint32_t res;
/* asm(".arch armv8-a"); */
/* asm(".arch_extension crc"); */
asm("crc32cw %0, %1, %2" : "=r"(res) : "r"(crc), "r"(val));
/* asm(".arch armv7-a"); */
return res;
}
#pragma GCC pop_options
```
Compiled with either armv7-a or armv8-a march.
[Bug middle-end/78809] Inline strcmp with small constant strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809 --- Comment #12 from Richard Earnshaw --- (In reply to Qing Zhao from comment #7) > on the other hand, memcmp will NOT early stop, it will compare exactly N > bytes of both buffers. As a result, the compiler can compare multiple bytes > at one time. > That's not entirely correct. Notionally memcmp needs to return a value representing the relative difference of the first different byte in the compared areas of memory; any later bytes are irrelevant. Yes the compiler can compare multiple bytes at the same time and it does not have to worry about page faulting, but it does have to keep track of where the first difference occurs. Of course, the compiler can see how the result is used to optimize things further; a simple equality test will allow the compiler to generate a simpler sequence that could access all bytes and accumulate the overall result.
[Bug ipa/82698] Spurious warning __builtin_memset at O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82698
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRMED |RESOLVED
Resolution|--- |DUPLICATE
--- Comment #1 from Martin Sebor ---
I believe this is a dupe of bug 80641. The invalid memset is introduced by the
loop distribution pass. I would expect it to be possible to detect these cases
and either avoid inserting such invalid calls or replace them with
__builtin_unreachable. That should not only eliminate these false positives
but also improve the quality of the generated code.
foo (struct vector & bar)
{
int * __first;
long unsigned int _1;
int * _5;
int * _6;
long int _7;
long int _8;
long int _9;
long int _10;
long unsigned int _11;
long unsigned int _20;
int * _21;
long int __pos.12_22;
int * _23;
long int _24;
long int _27;
[100.00%] [count: INV]:
_5 = MEM[(int * *)bar_3(D)];
_6 = MEM[(int * *)bar_3(D) + 8B];
_7 = (long int) _6;
_8 = (long int) _5;
_9 = _7 - _8;
_10 = _9 /[ex] 4;
_11 = (long unsigned int) _10;
_1 = _11 + 18446744073709551615;
if (_1 > _11)
goto ; [33.00%]
else
goto ; [67.00%]
[16.50%] [count: INV]:
_23 = bar_3(D)->D.15765._M_impl._M_end_of_storage;
_24 = (long int) _23;
_27 = _24 - _7;
if (_27 == -4)
goto ; [67.00%]
else
goto ; [33.00%]
[11.06%] [count: INV]:
__builtin_memset (_6, 0, 18446744073709551612);
__first_28 = _6 + 18446744073709551612;
bar_3(D)->D.15765._M_impl._M_finish = __first_28;
goto ; [100.00%]
[5.45%] [count: INV]:
std::__throw_length_error ("vector::_M_default_append");
[33.50%] [count: INV]:
_20 = _1 * 4;
_21 = _5 + _20;
__pos.12_22 = (long int) _21;
if (_7 != __pos.12_22)
goto ; [66.00%]
else
goto ; [34.00%]
[22.11%] [count: INV]:
MEM[(int * *)bar_3(D) + 8B] = _21;
[100.00%] [count: INV]:
return;
}
*** This bug has been marked as a duplicate of bug 80641 ***
[Bug tree-optimization/80641] [7/8 Regression] Warning with std::vector resize in loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80641 Martin Sebor changed: What|Removed |Added CC||paulg at chiark dot greenend.org.u ||k --- Comment #4 from Martin Sebor --- *** Bug 82698 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/82677] Many projects (linux, coreutils, GMP, gcrypt, openSSL, etc) are misusing asm(divq/divl) etc, potentially resulting in faulty/unintended optimisations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82677 infinity0 at pwned dot gg changed: What|Removed |Added Attachment #42439|0 |1 is obsolete|| Attachment #42440|0 |1 is obsolete|| --- Comment #8 from infinity0 at pwned dot gg --- Created attachment 42461 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42461&action=edit More specific and thorough test case
[Bug middle-end/82569] [8 regression] failure in 177.mesa cpu2000 test case after r253530
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82569 --- Comment #14 from seurer at gcc dot gnu.org --- I tried the original full 177.mesa benchmark and it works fine after your patch. Thanks!
[Bug tree-optimization/57359] wrong code for union access at -O3 on x86_64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359
Alexander Cherepanov changed:
What|Removed |Added
CC||ch3root at openwall dot com
--- Comment #12 from Alexander Cherepanov ---
Still reproducible if the number of iterations is changed to 3.
I've also converted the testcase to allocated memory:
--
#include
#include
__attribute__((__noinline__,__noclone__))
void test(int *pi, long *pl, int k, int *pa)
{
for (int i = 0; i < 3; i++) {
pl[k] = // something that doesn't change but have to be calculated
*pa; // something that potentially can be changed by assignment to *pi
*pi = 0;
}
}
int main(void)
{
int *pi = malloc(10);
int a = 1;
test(pi, (void *)pi, 0, &a);
printf("%d\n", *pi);
}
--
Results:
--
$ gcc -std=c11 -pedantic -Wall -Wextra test.c && ./a.out
0
$ gcc -std=c11 -pedantic -Wall -Wextra -O3 test.c && ./a.out
1
--
gcc version: gcc (GCC) 8.0.0 20171024 (experimental)
[Bug web/82686] Debian sid powerpc64-unknown-linux-gnu 4.13.0-1-powerpc64 bootstrap breaks in stage3 with unexpected requirement for bdw-gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82686
--- Comment #5 from Jonathan Wakely ---
(In reply to Richard Biener from comment #3)
> --enable-objc-gc requires you to provide boehm-gc yourself now. Quoting the
> installation instructions:
>
> @item --enable-objc-gc
> Specify that an additional variant of the GNU Objective-C runtime library
> is built, using an external build of the Boehm-Demers-Weiser garbage
> collector (@uref{http://www.hboehm.info/gc/}). This library needs to be
> available for each multilib variant,
^
Did you do that?
[Bug rtl-optimization/82677] Many projects (linux, coreutils, GMP, gcrypt, openSSL, etc) are misusing asm(divq/divl) etc, potentially resulting in faulty/unintended optimisations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82677
--- Comment #9 from infinity0 at pwned dot gg ---
(In reply to rguent...@suse.de from comment #7)
> [..]
>
> You still have to mark stmts with side-effects as volatile.
>
> Conditional side-effects are tricky to get correct of course.
I think with the current asm() syntax and semantics, the only way to get this
correct in the C source code, is by using __volatile__. It is not possible to
even *express* "conditional side-effects" using the current syntax. To
demonstrate:
The "explicit zero check" that I mentioned in the first post does not actually
work, see the newer udiv.c test that I just attached. I think that is correct
behaviour from GCC as well.
AIUI, asm() without volatile, says to GCC: "this code will *never* cause side
effects under *any circumstance*, it depends only on its declared
inputs/outputs/clobbers". Under this assumption, it is correct to optimise
| if(d) { asm(d); ... } ...
into
| asm(d); if(d) { ... }
as long as the outputs to asm(d) don't clobber the inputs to if(d) or any
else-branches - I assume other parts of the optimiser will already check that.
However, it is *not* correct to perform the above, when the asm(d) has
conditional side-effects depending on d, that the if(d) checks for. But there
is no way to express this conditional-side-effect using the current asm()
syntax. So GCC will happily go ahead and perform the optimisation, since it
believes asm(d) will never have any side effects.
So, the pre-optimised code "looks correct", it's explicitly checking d, but
will in fact cause the types of unintended optimisations that we're looking at
here. The only way to avoid this is to use "volatile".
In conclusion: whilst making the optimiser more strict for this case as you
suggested, would fix this specific instance, I believe that it is not "the
proper fix" for GCC. A proper fix would have to involve changing the
*semantics* of a asm(div) call so that GCC understands that it has "side
effects depending on the divisor and n1[1]". Otherwise, more sophisticated
optimisations added to GCC in the future might make this issue come back.
If that is not done, then it would be necessary to fix these 20 projects's C
source code to properly express __volatile__. Actually this is probably
necessary regardless of any GCC fixes - from some quick searches it seems that
asm() semantics is not standardised, and also these projects might want to
support older GCC that has the existing semantics.
[1] it can also raise DE when n1 >= divisor.
[Bug inline-asm/82701] New: RFE: x86: double word operands in inline assembly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82701
Bug ID: 82701
Summary: RFE: x86: double word operands in inline assembly
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: hpa at zytor dot com
Target Milestone: ---
x86 inline assembly currently has no sensible way to use doubleword operands
(long long on x86-32, __int128 on x86-64) without restricting them to the d:a
register pair via the "A" constraint, and hard-coding the register names. It
would be highly desirable to have a clean way to emit into the assembly code
the upper half of a doublewidth operand (register or memory) without
artificially constraining code generation.
In some ways, this is similar to the "H" modifier, except it would be +4 for
memory operands on 32 bits. I'm calling it U below.
For an artificial example:
uint64_t a, b;
/* a += b; */
asm("add %1,%0; adc %U1,%U0" : "+rm,r" (a) : "ri,m" (b) : "cc");
For a register: print the high register of the pair.
For a memory operand: print the address + the word size
For an immediate: print the value >> (word size*8)
[Bug target/82699] ENDBR isn't generated at function entrance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82699 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-10-24 Target Milestone|--- |8.0 Ever confirmed|0 |1 --- Comment #1 from H.J. Lu --- A patch is posted at https://gcc.gnu.org/ml/gcc-patches/2017-10/msg01725.html
[Bug preprocessor/78497] compiling with -save-temps adds -Wimplicit-fallthrough warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78497
Mark Wielaard changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
--- Comment #6 from Mark Wielaard ---
Confirmed, this confused me a bit.
Take t.c:
int main (int argc, char **argv)
{
int a;
switch (argc)
{
case 1:
a = 1;
break;
case 2:
a = 2;
/* FALLTHROUGH */
case 3:
a = 3;
break;
}
return a;
}
$ gcc -Werror -Wimplicit-fallthrough t.c
is fine, but...
$ gcc --save-temps -Werror -Wimplicit-fallthrough t.c
t.c: In function ‘main’:
t.c:10:9: error: this statement may fall through
[-Werror=implicit-fallthrough=]
a = 2;
~~^~~
t.c:12:5: note: here
case 3:
^~~~
cc1: all warnings being treated as errors
[Bug middle-end/78809] Inline strcmp with small constant strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809 --- Comment #13 from Qing Zhao --- (In reply to Richard Earnshaw from comment 12) > That's not entirely correct. Notionally memcmp needs to return a value > representing the relative difference of the first different byte in the > compared areas of memory; any later bytes are irrelevant. Yes the compiler > can > compare multiple bytes at the same time and it does not have to worry about > page faulting, but it does have to keep track of where the first difference > occurs. > > Of course, the compiler can see how the result is used to optimize things > further; a simple equality test will allow the compiler to generate a simpler > sequence that could access all bytes and accumulate the overall result. Yes. this should be the reason why currently in GCC, only when the result of memcpy is compared to zero, it is optimized by “strlen” pass and “expand” pass.
[Bug inline-asm/82701] RFE: x86: double word operands in inline assembly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82701
--- Comment #1 from H. Peter Anvin ---
I just stumbled onto this technique somewhat by accident:
union dw {
uint64_t q;
uint32_t l[2];
};
union dw aa, bb;
aa.q = a;
bb.q = b;
asm("add %2,%0; adc %3,%1"
[Bug gcov-profile/82702] New: gcov intermediate format is creating multiple 'gcov' files, it was creating a single file up to GCC 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82702
Bug ID: 82702
Summary: gcov intermediate format is creating multiple 'gcov'
files, it was creating a single file up to GCC 6
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: mcastelluccio at mozilla dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Running "gcov -i file.gcno" was generating a single file ("file.gcno.gcov")
with info about all the files included in file.cpp.
Now, it is creating multiple "gcov" files, one for each included file.
[Bug inline-asm/82701] RFE: x86: double word operands in inline assembly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82701 --- Comment #2 from H. Peter Anvin --- (continued) : "+rm,r" (aa.l[0]), "+rm,r" (aa.l[1]) : "ri,m" (bb.l[0]), "ri,m" (bb.l)); a = aa.q; b = bb.q; If this is something that works by intent and not by accident I'm perfectly happy with this solution as it appears to generate good code.
[Bug preprocessor/78497] compiling with -save-temps adds -Wimplicit-fallthrough warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78497 --- Comment #7 from Mark Wielaard --- The workaround is to use gcc -C --save-temps ... to pass-through all comments to the temp files. Maybe -C should be the default with --save-temps?
[Bug rtl-optimization/82692] [8 Regression] Ordered comparisons used for unordered built-ins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82692 --- Comment #5 from Segher Boessenkool --- The combination 8 -> 9 (where the GE is introduced) does not call SELECT_CC_MODE at all.
[Bug gcov-profile/82614] GCOV crashes while parsing gcda file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82614 --- Comment #8 from Marco Castelluccio --- Created attachment 42462 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42462&action=edit Archive with GCNO and GCDA file generated with GCC 6 This is an archive containing the GCNO and GCDA files generated with GCC 6. We are going to test 7 next.
