[Bug tree-optimization/88259] New: vectorization failure for a typical loop for getting max value and index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88259
Bug ID: 88259
Summary: vectorization failure for a typical loop for getting
max value and index
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jiangning.liu at amperecomputing dot com
Target Milestone: ---
GCC -O3 can't vectorize the following typical loop for getting max value and
index from an array.
void test_vec(int *data, int n) {
int best_i, best = 0;
for (int i = 0; i < n; i++) {
if (data[i] > best) {
best = data[i];
best_i = i;
}
}
data[best_i] = data[0];
data[0] = best;
}
The code generated in the kernel loop is as below,
.L4:
ldr w4, [x0, x2, lsl 2]
cmp w3, w4
cselw6, w4, w3, lt
cselw5, w2, w5, lt
add x2, x2, 1
mov w3, w6
cmp w1, w2
bgt .L4
If n is a constant like 1024, gcc -O3 still fails to vectorize it.
If we only get the max value and keep only one statement in the if statement
inside the loop,
void test_vec(int *data, int n) {
int best = 0;
for (int i = 0; i < n; i++) {
if (data[i] > best) {
best = data[i];
}
}
data[0] = best;
}
"gcc -O3" can do vectorization and the kernel loop is like below,
.L4:
ldr q1, [x2], 16
smaxv0.4s, v0.4s, v1.4s
cmp x2, x3
bne .L4
[Bug c++/81896] omp target enter data not recognized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81896 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- For OpenMP 4.5 it is unclear to me if what you want is allowed or not and, especially for map on a target region, what it is supposed to do, if the base of a mapped array section is a non-static data member. OpenMP 5.0 allows arbitrary lvalue expressions as bases of array sections in map/to/from and has exact rules for pointer attachments etc., so that case is clearer, but even GCC 9 doesn't yet implement that.
[Bug target/88152] optimize SSE & AVX char compares with subsequent movmskb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88152
--- Comment #5 from Matthias Kretz ---
> -fno-signed-zeros isn't a guarantee the operand will not be -0.0 and having
> x < 0.0 behave differently based on whether x is -0.0 or 0.0 (with
> -fno-signed-zeros quite randomly) is IMHO very bad.
I agree this isn't obviously correct. But I stared long and hard at the manpage
before writing that comment. From the manpage:
> Allow optimizations for floating-point arithmetic that ignore the signedness
> of zero. IEEE arithmetic specifies the behavior of distinct +0.0 and -0.0
> values, which then prohibits simplification of expressions such as x+0.0 or
> 0.0*x (even with -ffinite-math-only). This option implies that the sign of a
> zero result isn't significant.
1. The movmsk(x<0) => movmsk(x) transformation is an "optimization for
floating-point arithmetic that ignores the signedness of zero" - except that
it's not really an arithmetic operation. But then again -ffinite-math-only
turns isnan(x) into false ("Allow optimizations for floating-point arithmetic
that assume that arguments and results are not NaNs")
2. I based my argument mostly on this part, though: "This option implies that
the sign of a zero result isn't significant". I interpret it as "if the result
of f() is zero, it's sign is not significant in the expression f()<0".
Consequently, we can assume the sign to be positive.
Feel free to disagree. I just wanted to explain how I read the GCC
documentation on -fno-signed-zeros. If that's not the intended reading, I'd be
happy to help clarify the documentation.
[Bug lto/87988] [9 regression] Streaming of ABSTRACT_ORIGIN is expensive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87988 --- Comment #10 from rguenther at suse dot de --- On Wed, 28 Nov 2018, hubicka at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87988 > > --- Comment #9 from Jan Hubicka --- > We still have: >/* When not generating debug info we can eliminate info on unused > > variables. */ > >else if (!flag_auto_profile && debug_info_level == DINFO_LEVEL_NONE > > && !optinfo_wants_inlining_info_p ()) > > > can we do better here? I think we can do better in the earlier loop over BLOCK_VARS if we make sure to not call remove_unused_scope_block_p before early debug generation. For example we should be able to elide else if (TREE_CODE (*t) == TYPE_DECL || debug_info_level == DINFO_LEVEL_NORMAL || debug_info_level == DINFO_LEVEL_VERBOSE) ; completely. Likewise /* Debug info of nested function refers to the block of the function. We might stil call it even if all statements of function it was nested into was elliminated. TODO: We can actually look into cgraph to see if function will be output to file. */ if (TREE_CODE (*t) == FUNCTION_DECL) unused = false; should not be necessary - that is, after early debug BLOCK_VARS only needs to retain used decls (decls we want to annotate with locations later). The code you quote above is a bit weird indeed.
[Bug tree-optimization/88259] vectorization failure for a typical loop for getting max value and index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88259
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Keywords||missed-optimization
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-11-29
CC||ktkachov at gcc dot gnu.org,
||rsandifo at gcc dot gnu.org
Blocks||53947
Ever confirmed|0 |1
--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed.
Trying to find just the index (not the max value) vectorises as well:
void test_vec(int *data, int n) {
int best_i, best = 0;
for (int i = 0; i < n; i++) {
if (data[i] > best) {
//best = data[i];
best_i = i;
}
}
data[best_i] = data[0];
data[0] = best;
}
-O3:
.L4:
ldr q1, [x2], 16
mov v3.16b, v2.16b
add v2.4s, v2.4s, v4.4s
cmlev1.4s, v1.4s, #0
cmp x2, x3
bif v0.16b, v3.16b, v1.16b
bne .L4
smaxv s0, v0.4s
and w3, w1, -4
umovw2, v0.s[0]
cmn w2, #1
cselw2, w2, wzr, ne
tst x1, 3
beq .L2
.L3:
But their combination seems like it's throwing the machinery off. I'm guessing
the index-finding needs some if-conversion and masking to happen in the
vectoriser
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug tree-optimization/88223] [8 Regression] Wrong code for intrinsic memmove
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88223
--- Comment #11 from rguenther at suse dot de ---
On Wed, 28 Nov 2018, joseph at codesourcery dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88223
>
> --- Comment #10 from joseph at codesourcery dot com dot com> ---
> On Wed, 28 Nov 2018, rguenth at gcc dot gnu.org wrote:
>
> > Hmm, OTOH the C standard specifies that the store to u.b.b makes it the
> > u.b the active member and it makes the old contents undefined. That
> > would mean when loading u.a.b after the store we cannot rely on the
> > exact value we get but at least the bits touched by u.b.b should be
> > up-to-date (which is enough to show breakage). I thought about
> > using
>
> In my view, storing to u.b.b should be equivalent to loading u.b (a
> type-punning operation if u.a was previously the active member), storing
> the new value of u.b.b in a copy of the loaded value of u.b, and storing
> that result back in u.b (making u.b the active member of u). (So if bits
> set in u.a are not padding in u.b, and not part of the space occupied by
> u.b.b, they should be preserved.)
OK, that's convenient enough to support for the compiler. Unfortunately
that means my testcases become valid and we still miscompile them...
Now, for type-punning to be valid the union has to be visible in the
access, but this visibility can be lost in the middle-end given
the middle-end implements sth more conservative.
Still that a store is a punning access makes the following valid?
union u { struct { int i; int j; } x; struct { float f; float g; } y; };
union u A;
float foo (union u *B)
{
u->x.i = 0;
A.y.g = 1.0;
return u->y.f;
}
is this valid punning of u->x.i to u->y.f (int->float) because the
actual type-punning is implicitely done via A.y.g = 1.0? Of course the
constraint is that B points to A.
We certainly happily re-order the store and load via u.
[Bug sanitizer/88260] New: c++ code instrumented with address sanitizer crashes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88260
Bug ID: 88260
Summary: c++ code instrumented with address sanitizer crashes
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: mirhet.saracevic at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
Target: i686-elf
Created attachment 45117
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45117&action=edit
objectdump of the c++ code
Following C++ code compiled with GCC 6.3.0 and option -fsanitize=address
crashes.
int increment(int &x) {
++x;
return 0;
}
int main(void)
{
int x = 0;
increment(x);
return 0;
}
Objectdump of the code attached.
The execution crahes on following line:
994:c7 83 00 00 00 20 f1movl $0xf1f1f1f1,0x2000(%ebx)
[Bug c++/87750] [8/9 Regression] Failed compilation / parsing of template member call after 'using' declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87750 Alexandre Oliva changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot gnu.org --- Comment #6 from Alexandre Oliva --- Created attachment 45118 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45118&action=edit candidate patch
[Bug tree-optimization/88259] vectorization failure for a typical loop for getting max value and index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88259
Ramana Radhakrishnan changed:
What|Removed |Added
CC||ramana at gcc dot gnu.org
--- Comment #2 from Ramana Radhakrishnan ---
(In reply to ktkachov from comment #1)
> Confirmed.
> Trying to find just the index (not the max value) vectorises as well:
> void test_vec(int *data, int n) {
> int best_i, best = 0;
>
> for (int i = 0; i < n; i++) {
> if (data[i] > best) {
> //best = data[i];
> best_i = i;
> }
> }
>
> data[best_i] = data[0];
> data[0] = best;
> }
>
>
> -O3:
> .L4:
> ldr q1, [x2], 16
> mov v3.16b, v2.16b
> add v2.4s, v2.4s, v4.4s
> cmlev1.4s, v1.4s, #0
> cmp x2, x3
> bif v0.16b, v3.16b, v1.16b
> bne .L4
> smaxv s0, v0.4s
> and w3, w1, -4
> umovw2, v0.s[0]
> cmn w2, #1
> cselw2, w2, wzr, ne
> tst x1, 3
> beq .L2
> .L3:
>
> But their combination seems like it's throwing the machinery off. I'm
> guessing the index-finding needs some if-conversion and masking to happen in
> the vectoriser
ISTR there is some limit in if conversion around the vectorizer where it only
works on very simple if-blocks. But this is from memory and it's a bit fuzzy
now.
[Bug target/88236] [avr] Invalid code generated for __memx char pointer deference for avr5 arch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88236 Senthil Kumar Selvaraj changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |saaadhu at gcc dot gnu.org --- Comment #2 from Senthil Kumar Selvaraj --- Created attachment 45119 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45119&action=edit Bug fix patch If reload choses r30 (or r31) as operand 0 of xload_8, the lpmx constraint alternative ends up generating wrong code, as avrt_out_xload would emit lpm r30, Z sbrc , 7 ld r30, Z r30 gets clobbered by LPM, and LD with Z will therefore not work correctly. This happens even though operand 0 is marked as early clobber in the insn, presumably because of the hard coded (reg:HI REG_Z). If (reg:HI REG_Z) is replaced with (match_operand:HI 2 "register_operand" "z,z") then reload does respect the early clobber, but fails with "unable to find register to spill in pointer class POINTER_REGS_Z", probably because the xload8_A hardcodes REG_Z as the third operand. Adding a clobber for REG_Z prevents reload from assigning r30 as the output operand, even though REG_Z isn't technically clobbered. One other way to fix this would be to add a new register constraint that tells reload to use any register other than REG_Z. It likely won't make any difference in code gen, as REG_Z would have been clobbered by xload8_A anyway.
[Bug fortran/88247] [8/9 Regression] ICE in get_array_ctor_var_strlen, at fortran/trans-array.c:2068
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88247 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |8.3
[Bug driver/47785] GCC with -flto does not pass -Wa options to the assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47785 --- Comment #13 from Richard Biener --- Note the proposed solution only works for uniform -Wa options across all TUs participating in the optimizing link. Otherwise partitioning can merge parts of TUs with different flags and there is (IIRC) no way to annotate parts of an assembly file with different assembler flags. Supporting non-uniform -Wa flags would require either adjusting partitioning according to flags (disliked by some folks but also would help in other cases), or emitting multiple object files (assembler files) from a single LTRANS CU. Note there's the question if it is valid to inline across -Wa flag differences as well. For the specific case of -Wa,-msse2avx target maintainers might consider adding a -msse2avx compiler flag triggering the assembler flag via specs processing.
[Bug tree-optimization/88243] [9 Regression] ice in vect_create_epilog_for_reduction, at tree-vect-loop.c:4689
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88243 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-11-29 Component|c |tree-optimization Version|8.0 |9.0 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |9.0 Summary|ice in |[9 Regression] ice in |vect_create_epilog_for_redu |vect_create_epilog_for_redu |ction, at |ction, at |tree-vect-loop.c:4689 |tree-vect-loop.c:4689 Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- Confirmed, mine.
[Bug rtl-optimization/88253] Inlining of function incorrectly deletes volatile register access when using XOR in avr-gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88253 --- Comment #1 from Richard Biener --- Note GCC 5 is out of support, please see if you can reproduce this with a newer version (GCC 7 and up).
[Bug ipa/88256] [7/8/9 Regression] ICE: Segmentation fault (in make_ssa_name_fn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88256 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-11-29 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |7.4 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- I will have a look.
[Bug preprocessor/88257] [9 Regression] ICE in linemap_position_for_line_and_column, at libcpp/line-map.c:842
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88257 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.0
[Bug sanitizer/88260] c++ code instrumented with address sanitizer crashes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88260 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-11-29 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Can't reproduce. Can you please provide the full compiler command-line plus the output when appending -v? Note that GCC 6 is no longer maintained.
[Bug tree-optimization/88259] vectorization failure for a typical loop for getting max value and index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88259 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #3 from Richard Biener --- The vectorizer does not like [local count: 955630224]: # best_i_25 = PHI # best_26 = PHI # i_27 = PHI _1 = (long unsigned int) i_27; _2 = _1 * 4; _3 = data_18(D) + _2; _4 = *_3; best_i_11 = _4 <= best_26 ? best_i_25 : i_27; best_13 = MAX_EXPR <_4, best_26>; i_20 = i_27 + 1; if (n_17(D) > i_20) because for the best MAX reduction we have an additional use of the reduction value in the index reduction. This combination isn't magically supported even though in isolation both cases are. t.c:4:5: note: Analyze phi: best_26 = PHI t.c:4:5: missed: reduction used in loop. t.c:4:5: missed: Unknown def-use cycle pattern. t.c:4:5: note: Analyze phi: best_i_25 = PHI t.c:4:5: note: detected reduction: need to swap operands: best_i_11 = _4 > best_26 ? i_27 : best_i_25; t.c:4:5: note: Detected reduction. if we'd been lucky and had analyzed best_i_25 before best_26 then we could probably special-case the case of "reduction used in loop" when that appears in other reductions. In general that's of course still not valid I think. Alternatively the reduction operation could be combined somehow via pattern detection.
[Bug c++/88258] [9 Regression] Infinite loop emitting diagnostics in the C++ front-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88258 Richard Biener changed: What|Removed |Added Keywords||diagnostic Target Milestone|--- |9.0
[Bug ipa/88256] [7/8/9 Regression] ICE: Segmentation fault (in make_ssa_name_fn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88256 --- Comment #2 from Martin Liška --- I see it fixed on trunk since r257620.
[Bug ipa/88256] [7/8/9 Regression] ICE: Segmentation fault (in make_ssa_name_fn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88256 --- Comment #3 from Martin Liška --- And appeared on trunk before that in r235817.
[Bug c++/88258] [9 Regression] Infinite loop emitting diagnostics in the C++ front-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88258 --- Comment #1 from Jonathan Wakely --- Created attachment 45120 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45120&action=edit preprocessed source to reproduce diagnostic loop Confirmed, here is a reproducer I found the other day.
[Bug c++/88258] [9 Regression] Infinite loop emitting diagnostics in the C++ front-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88258 Jonathan Wakely changed: What|Removed |Added Keywords|openmp | Status|UNCONFIRMED |NEW Last reconfirmed||2018-11-29 Ever confirmed|0 |1 --- Comment #2 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #1) > Confirmed, here is a reproducer I found the other day. This needs -std=gnu++17 to compile.
[Bug fortran/85953] [7/8 Regression] ICE in fold_convert_loc, at fold-const.c:2370
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85953 Martin Liška changed: What|Removed |Added Known to work||9.0 Summary|[7/8/9 Regression] ICE in |[7/8 Regression] ICE in |fold_convert_loc, at|fold_convert_loc, at |fold-const.c:2370 |fold-const.c:2370 Known to fail|9.0 | --- Comment #5 from Martin Liška --- Fixed on trunk in r264486.
[Bug ipa/88256] [7/8/9 Regression] ICE: Segmentation fault (in make_ssa_name_fn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88256 --- Comment #4 from Arseny Solokha --- But the fix seems to be specific to C front-end and does not cover C++? This time it's not (only) my mistake in the way I configure gcc: https://gcc.godbolt.org/z/2xRIE_
[Bug c++/88256] [7/8/9 Regression] ICE: Segmentation fault (in make_ssa_name_fn), C++ FE missing DECL_EXPRs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88256
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|NEW
Component|ipa |c++
Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot
gnu.org
Summary|[7/8/9 Regression] ICE: |[7/8/9 Regression] ICE:
|Segmentation fault (in |Segmentation fault (in
|make_ssa_name_fn) |make_ssa_name_fn), C++ FE
||missing DECL_EXPRs
--- Comment #5 from Richard Biener ---
Program received signal SIGSEGV, Segmentation fault.
0x0174d104 in make_ssa_name_fn (fn=0x769e6160, var=,
stmt=, version=0)
at /space/rguenther/src/gcc-sccvn/gcc/tree-ssanames.c:268
268 gcc_assert (VAR_P (var)
we are remapping a released SSA name referenced from TYPE_SIZE of
int[0:(sizetype) D.2308][0:(sizetype) D.2307]
Thus this is a FE issue where we lack a DECL_EXPR for the type used in
some memory reference:
(gdb) p debug_gimple_stmt (stmt)
# VUSE <.MEM_6(D)>
_5 = MEM[(int[0:(sizetype) D.2308][0:(sizetype) D.2307] *)foo.2_4][0]{lb: 0 sz:
_3 * 4}[0];
static void f2 (int arg) { res = ((int (*)[arg][b]) foo)[0][0][0]; }
is in .original
;; Function void f2(int) (null)
;; enabled by -tree-original
<) + 1) *
((sizetype) (SAVE_EXPR <(ssizetype) arg + -1>) + 1);, (int[0:(sizetype)
(SAVE_EXPR <(ssizetype) arg + -1>)][0:(sizetype) (SAVE_EXPR <(ssizetype) b +
-1>)] *) foo;))[0][0]) >;
there's no DECL_EXPR so size expressions are not properly unshared. IIRC
there's a duplicate PR where I ran into a similar issue. I'm probably
thinking of PR86216 which sadly also has no attention from FE maintainers.
Anyway, C++ FE bug.
[Bug c++/88256] [7/8/9 Regression] ICE: Segmentation fault (in make_ssa_name_fn), C++ FE missing DECL_EXPRs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88256 --- Comment #6 from Richard Biener --- (In reply to Arseny Solokha from comment #4) > But the fix seems to be specific to C front-end and does not cover C++? Yeah, I can reproduce with the C++ FE which probably needs a similar fix.
[Bug target/88224] Wrong Cortex-R7 and Cortex-R8 FPU configuration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88224 --- Comment #2 from avieira at gcc dot gnu.org --- Author: avieira Date: Thu Nov 29 10:20:13 2018 New Revision: 266612 URL: https://gcc.gnu.org/viewcvs?rev=266612&root=gcc&view=rev Log: [PATCH] [Arm] Fix fpu configurations for Cortex-R7 and Cortex-R8 gcc/ChangeLog: 2018-11-29 Andre Vieira PR target/88224 * config/arm/arm-cpus.in (armv7-r): Add FP16conv configurations. (cortex-r7, cortex-r8): Update default and add new configuration. * doc/invoke.texi (armv7-r): Add two new vfp options. (nofp.dp): Add cortex-r7 and cortex-r8 to the list of targets that support this option. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm-cpus.in trunk/gcc/doc/invoke.texi
[Bug c++/88261] New: [9 Regression] ICE: verify_gimple failed (error: non-trivial conversion at assignment)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88261 Bug ID: 88261 Summary: [9 Regression] ICE: verify_gimple failed (error: non-trivial conversion at assignment) Product: gcc Version: 9.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- g++-9.0.0-alpha20181125 snapshot (r266441) ICEs when compiling gcc/testsuite/gcc.dg/array-6.c or gcc/testsuite/gcc.dg/array-14.c: % g++-9.0.0-alpha20181125 -c gcc/testsuite/gcc.dg/array-6.c gcc/testsuite/gcc.dg/array-6.c: In function 'void foo()': gcc/testsuite/gcc.dg/array-6.c:12:6: error: non-trivial conversion at assignment 12 | void foo() | ^~~ char[] char[2] c.s = "c"; gcc/testsuite/gcc.dg/array-6.c:12:6: error: non-trivial conversion at assignment char[] char[2] d.s = "d"; gcc/testsuite/gcc.dg/array-6.c:12:6: error: non-trivial conversion at assignment char[] char[2] e.s = "e"; gcc/testsuite/gcc.dg/array-6.c:12:6: internal compiler error: verify_gimple failed 0xf44c0d verify_gimple_in_seq(gimple*) /var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/gcc/tree-cfg.c:5082 0xca20d6 gimplify_body(tree_node*, bool) /var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/gcc/gimplify.c:13636 0xca22d7 gimplify_function_tree(tree_node*) /var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/gcc/gimplify.c:13726 0xb0dc17 cgraph_node::analyze() /var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/gcc/cgraphunit.c:667 0xb1087f analyze_functions /var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/gcc/cgraphunit.c:1126 0xb11452 symbol_table::finalize_compilation_unit() /var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181125/work/gcc-9-20181125/gcc/cgraphunit.c:2835
[Bug rtl-optimization/88253] Inlining of function incorrectly deletes volatile register access when using XOR in avr-gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88253 --- Comment #2 from William Westfield --- I did say that it still happens with 8.1... However, the 5.4.0 version is the latest version supported by the vendor.
[Bug c++/88221] Only restricted set of balanced token sequences allowed for attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88221 Bruno De Fraine changed: What|Removed |Added CC||bruno-gcc at defraine dot net --- Comment #2 from Bruno De Fraine --- Also see bug #88086.
[Bug preprocessor/88257] [9 Regression] ICE in linemap_position_for_line_and_column, at libcpp/line-map.c:842
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88257 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- I can't reproduce, but looks very similar to PR87721.
[Bug preprocessor/88257] [9 Regression] ICE in linemap_position_for_line_and_column, at libcpp/line-map.c:842
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88257
--- Comment #2 from Arseny Solokha ---
(In reply to Martin Liška from comment #1)
> I can't reproduce, but looks very similar to PR87721.
https://gcc.godbolt.org/z/o14PZF
> GNU C++14 (GCC-Explorer-Build) version 9.0.0 20181128 (experimental)
> (x86_64-linux-gnu)
> compiled by GNU C version 7.3.0, GMP version 6.1.0, MPFR version 3.1.4, MPC
> version 1.0.3, isl version isl-0.18-GMP
> GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
> Compiler executable checksum: 33df48a4c30aa2336d636e4b7d79bc23
> : In function 'void test(const char*)':
> :6:37: internal compiler error: in
> linemap_position_for_line_and_column, at libcpp/line-map.c:842
> 6 | printf ("size: %" PRIu32 "\n", msg); /* { dg-warning "expects
> argument of type" } */
> | ^
This revision is even newer that mine.
[Bug middle-end/88246] Abort signal terminated program collect2 - munmap_chunk(): invalid pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88246 --- Comment #2 from Martin Liška --- I can confirm that in openSUSE build service, but I have very limited access to a s390x machine. I checked the patch and I don't see any obvious error. Can you please debug that?
[Bug middle-end/88246] Abort signal terminated program collect2 - munmap_chunk(): invalid pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88246 --- Comment #3 from Martin Liška --- Created attachment 45121 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45121&action=edit Clean up patch The patch is only cosmetic, should not affect generated code.
[Bug driver/88262] New: gcc uses crt1.o in place of Scrt1.o when the main function is in a PIC shared lib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88262 Bug ID: 88262 Summary: gcc uses crt1.o in place of Scrt1.o when the main function is in a PIC shared lib Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: stephen.kim at oracle dot com Target Milestone: --- I am not yet certain that this is a gcc bug or user's fault. That's why I am filing a bug here to get other engineers' thoughts. I have a non-PIC app.o, which does not have the main function but a set of functions, variables, etc. Besides, I have a PIC shared library, say, libmain.so, which has the main function. Having a "PIE" is not mandatory, so I just linked the two like this: gcc -o app.x -L. -lmain -fuse-ld=gold -Wl,-rpath=$PWD app.o Running app.x gives me a segmentation fault when the glibc is sufficiently new--the patch that triggers this issue is created this year--and the platform is arm64. The reason is when gcc invokes gold, gcc gives it crt1.o rather than Scrt1.o. Multiple experts confirmed that Scrt1.o should be given in this case. I am wondering if this is a gcc bug that should be fixed in the gcc driver. Or, would it be claimed that the users (e.g. myself) should have used "-pie" to link them although making a PIE is not mandatory from my perspective? Regarding severity, as a C and C++ programmer, I personally have not placed main inside a shared library. I haven't yet faced at work any pure C/C++ code that has the main inside a PIC shared library. This might not be highly common in the C and C++ worlds. However, Go tools always do this with a certain combination of buildmode. I would expect this situation happens more there.
[Bug tree-optimization/88243] [9 Regression] ice in vect_create_epilog_for_reduction, at tree-vect-loop.c:4689
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88243
--- Comment #3 from Richard Biener ---
So we are arriving here with a vect_nested_cycle def from the pattern_def
sequence but the code only expects to be called with the last stmt of a
reduction pattern.
t.c:5:5: note: Analyze phi: e_25 = PHI <_48(4), e_14(10)>
t.c:5:5: note: detected nested cycle: e_14 = e_25 / 2;
t.c:5:5: note: Detected vectorizable nested cycle.
here the division is the pattern
patt_17 = e_25 < 0 ? 1 : 0;
patt_16 = e_25 + patt_17;
patt_22 = patt_16 >> 1;
t.c:5:5: note: === vect_pattern_recog ===
t.c:5:5: note: vect_recog_divmod_pattern: detected: e_14 = e_25 / 2;
t.c:5:5: note: divmod pattern recognized: patt_22 = patt_16 >> 1;
and the def type is transfered to all stmts in the pattern def sequence
for some reason. The new way of setting/initializing pattern stmts is
a bit twisted so it looks like re-adjusting all pattern-def-seq stmts
to vect_internal_def is the way to go (and works for the testcase).
Similar for inductions.
Testing the following.
diff --git a/gcc/tree-vect-patterns.c b/gcc/tree-vect-patterns.c
index 2b56d85afc5..39b6f822d19 100644
--- a/gcc/tree-vect-patterns.c
+++ b/gcc/tree-vect-patterns.c
@@ -4723,7 +4723,15 @@ vect_mark_pattern_stmts (stmt_vec_info orig_stmt_info,
gimple *pattern_stmt,
if (def_seq)
for (gimple_stmt_iterator si = gsi_start (def_seq);
!gsi_end_p (si); gsi_next (&si))
- vect_init_pattern_stmt (gsi_stmt (si), orig_stmt_info, pattern_vectype);
+ {
+ stmt_vec_info pattern_stmt_info
+ = vect_init_pattern_stmt (gsi_stmt (si),
+ orig_stmt_info, pattern_vectype);
+ /* Stmts in the def sequence are not vectorizable cycle or
+ induction defs, instead they should all be vect_internal_def
+ feeding the main pattern stmt which retains this def type. */
+ STMT_VINFO_DEF_TYPE (pattern_stmt_info) = vect_internal_def;
+ }
if (orig_pattern_stmt)
{
[Bug c++/88263] New: ICE in coverage_begin_function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88263
Bug ID: 88263
Summary: ICE in coverage_begin_function
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: csaba_22 at yahoo dot co.uk
Target Milestone: ---
Created attachment 45122
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45122&action=edit
preprocessor output from -save-temps
$ cat ../logger/src/logger2.cc
#include
namespace log {
class Logstream {
public:
private:
/// The logging stream
static thread_local std::ostringstream os_;
};
}
namespace log {
thread_local std::ostringstream Logstream::os_;
}
$ g++-99 -v -save-temps --coverage -std=c++11 -o logger2.o
../logger/src/logger2.cc
Using built-in specs.
COLLECT_GCC=g++-99
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../trunk/configure --program-suffix=-99
--enable-version-specific-runtime-libs --enable-languages=c,c++,lto :
(reconfigured) ../trunk/configure --program-suffix=-99
--enable-version-specific-runtime-libs --enable-languages=c,c++,lto :
(reconfigured) ../trunk/configure --program-suffix=-99
--enable-version-specific-runtime-libs --enable-languages=c,c++,lto --no-create
--no-recursion
Thread model: posix
gcc version 9.0.0 20181128 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-coverage' '-std=c++11' '-o'
'logger2.o' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
/usr/local/libexec/gcc/x86_64-pc-linux-gnu/9.0.0/cc1plus -E -quiet -v
-imultiarch x86_64-linux-gnu -D_GNU_SOURCE ../logger/src/logger2.cc
-mtune=generic -march=x86-64 -std=c++11 -fpch-preprocess -o logger2.ii
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/local/lib/gcc/x86_64-pc-linux-gnu/9.0.0/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/lib/gcc/x86_64-pc-linux-gnu/9.0.0/include/c++
/usr/local/lib/gcc/x86_64-pc-linux-gnu/9.0.0/include/c++/x86_64-pc-linux-gnu
/usr/local/lib/gcc/x86_64-pc-linux-gnu/9.0.0/include/c++/backward
/usr/local/lib/gcc/x86_64-pc-linux-gnu/9.0.0/include
/usr/local/include
/usr/local/lib/gcc/x86_64-pc-linux-gnu/9.0.0/include-fixed
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-coverage' '-std=c++11' '-o'
'logger2.o' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
/usr/local/libexec/gcc/x86_64-pc-linux-gnu/9.0.0/cc1plus -fpreprocessed
logger2.ii -quiet -dumpbase logger2.cc -mtune=generic -march=x86-64 -auxbase
logger2 -std=c++11 -version -fprofile-arcs -ftest-coverage -o logger2.s
GNU C++11 (GCC) version 9.0.0 20181128 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 9.0.0 20181128 (experimental), GMP version
6.1.2, MPFR version 4.0.1, MPC version 1.1.0, isl version isl-0.19-GMP
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C++11 (GCC) version 9.0.0 20181128 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 9.0.0 20181128 (experimental), GMP version
6.1.2, MPFR version 4.0.1, MPC version 1.1.0, isl version isl-0.19-GMP
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 2adabd62ad077780728d20aedfb60f9c
during IPA pass: profile
../logger/src/logger2.cc: In function ‘void __tls_init()’:
../logger/src/logger2.cc:19:1: internal compiler error: in
coverage_begin_function, at coverage.c:643
19 | }
| ^
0x6b87d4 coverage_begin_function(unsigned int, unsigned int)
../../trunk/gcc/vec.h:845
0xe66993 branch_prob()
../../trunk/gcc/profile.c:1182
0xfd25f5 tree_profiling
../../trunk/gcc/tree-profile.c:772
0xfd25f5 execute
../../trunk/gcc/tree-profile.c:876
[Bug c++/87750] [8/9 Regression] Failed compilation / parsing of template member call after 'using' declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87750 Alexandre Oliva changed: What|Removed |Added Attachment #45118|0 |1 is obsolete|| --- Comment #7 from Alexandre Oliva --- Created attachment 45123 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45123&action=edit improved candidate patch The earlier patch was too simple, it failed to build libstdc++-v3.
[Bug driver/88262] gcc uses crt1.o in place of Scrt1.o when the main function is in a PIC shared lib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88262 --- Comment #1 from Andreas Schwab --- >From the gcc driver's point of view this is just a normal link since it does not know where main is defined.
[Bug libstdc++/88119] std::alignment_of returns wrong value (__alignof instead of alignof).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88119 --- Comment #1 from Jonathan Wakely --- Author: redi Date: Thu Nov 29 12:32:57 2018 New Revision: 266613 URL: https://gcc.gnu.org/viewcvs?rev=266613&root=gcc&view=rev Log: PR libstdc++/88119 use alignof in std::alignment_of, not __alignof__ Now that __alignof__ and alignof sometimes disagree it matters which one we use. The standard says that std::alignment_of::value equals alignof(T), so we need to use that. Change the only uses of alignment_of to use __alignof__ to avoid a change in alignment. PR libstdc++/88119 * include/ext/aligned_buffer.h (__aligned_membuf): Add comment. (__aligned_buffer): Use __alignof__ instead of std::alignment_of. * include/std/type_traits (alignment_of): Use alignof instead of __alignof__. * testsuite/20_util/alignment_of/value.cc: Fix test to check values match alignof not __alignof__, as required by the standard. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/ext/aligned_buffer.h trunk/libstdc++-v3/include/std/type_traits trunk/libstdc++-v3/testsuite/20_util/alignment_of/value.cc
[Bug libstdc++/88119] std::alignment_of returns wrong value (__alignof instead of alignof).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88119 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-11-29 Known to work||7.3.0 Target Milestone|--- |8.3 Ever confirmed|0 |1 Known to fail||8.1.0, 8.2.0 --- Comment #2 from Jonathan Wakely --- Fixed on trunk so far.
[Bug libstdc++/88125] Erroneous duplicate "basic_stringbuf" symbol entry in libstdc++ gnu.ver file.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88125 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org --- Comment #3 from Jonathan Wakely --- Yes, I think we can just remove the 3.4.6 pattern. It's not doing anything. My checker script finds this issue: $ echo _ZNKSt15basic_stringbufIwSt11char_traitsIwESaIwEE3strEv | ../../scripts/symverck.py config/abi/pre/gnu.ver Symbol matches: _ZNKSt15basic_stringbufIwSt11char_traitsIwESaIwEE3strEv std::basic_stringbuf, std::allocator >::str() const GLIBCXX_3.4_ZNKSt15basic_stringbufIwSt11char_traitsIwESaIwEE3strEv (line 359) GLIBCXX_3.4.6 _ZNKSt15basic_stringbufIwSt11char_traitsIwESaIwEE3strEv (line 1152) But I just tend to only use it for finding problems with specific symbols, not a sweep over the whole ABI. I should try doing that.
[Bug c++/87531] [8/9 Regression] assignment operator does nothing if performed as a call via operator=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87531 --- Comment #5 from Nathan Sidwell --- Author: nathan Date: Thu Nov 29 12:50:45 2018 New Revision: 266614 URL: https://gcc.gnu.org/viewcvs?rev=266614&root=gcc&view=rev Log: [PR c++/87531] operator= lookup in templates https://gcc.gnu.org/ml/gcc-patches/2018-11/msg02301.html PR c++/87531 * class.c (finish_struct): In a template, add artificial using decl for operator=. * g++.dg/lookup/pr87531.C: New. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/lookup/pr87531.C Modified: branches/gcc-8-branch/gcc/cp/ChangeLog branches/gcc-8-branch/gcc/cp/class.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug c++/87531] [8/9 Regression] assignment operator does nothing if performed as a call via operator=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87531 Nathan Sidwell changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Nathan Sidwell --- Fixed trunk & gcc-8. Raised issue with CWG, for standardese, but I don't expect that to come back with needing a change.
[Bug target/88234] UBsan and runtime error: signed integer overflow using unsigned vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88234 --- Comment #8 from Jeffrey Walton --- (In reply to Segher Boessenkool from comment #4) > This is documented in the ELFv2 ABI, linked from > https://gcc.gnu.org/readings.html . > > ... > (The vec_vsx_st doesn't have to do with the problem btw. Not that it is > good or anything ;-) ) Yeah, I tried to convert to the C/C++ pointer dereference pattern several times as shown in the literature. I.e., this: byte x[16]; uint8x16_p cc = (uint8x16_p)c; *(uint8x16_p*) &x[0] = cc; Instead of this: byte x[16]; vec_vsx_st((uint8x16_p)c, 0, x); It breaks a lot of our self tests for certain versions of a particular compiler. I narrowed it down to the loads but I could not take it further and develop a reduced case. I don't have the skill to untangle what is happening in ppc asm at -O3. If you want to see something really obscene, then take a look at https://github.com/weidai11/cryptopp/blob/master/ppc_simd.h#L251 . (If you are talking about something else that is wrong or bad, then please point it out.)
[Bug tree-optimization/88243] [9 Regression] ice in vect_create_epilog_for_reduction, at tree-vect-loop.c:4689
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88243 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener --- Fixed.
[Bug tree-optimization/88243] [9 Regression] ice in vect_create_epilog_for_reduction, at tree-vect-loop.c:4689
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88243 --- Comment #5 from Richard Biener --- Author: rguenth Date: Thu Nov 29 13:33:59 2018 New Revision: 266615 URL: https://gcc.gnu.org/viewcvs?rev=266615&root=gcc&view=rev Log: 2018-11-29 Richard Biener PR tree-optimization/88243 * tree-vect-patterns.c (vect_mark_pattern_stmts): Set the def type of all pattern-sequence stmts to vect_internal_def. * gcc.dg/torture/pr88243.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr88243.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-patterns.c
[Bug driver/88262] gcc uses crt1.o in place of Scrt1.o when the main function is in a PIC shared lib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88262 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Richard Biener --- I think this is a user error indeed.
[Bug gcov-profile/88263] ICE in coverage_begin_function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88263 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-11-29 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Mine.
[Bug c++/88261] [9 Regression] ICE: verify_gimple failed (error: non-trivial conversion at assignment)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88261
Richard Biener changed:
What|Removed |Added
Keywords||accepts-invalid
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-11-29
Target Milestone|--- |9.0
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
Confirmed. GCC 8 diagnoses it as
array-6.c: In function ‘void foo()’:
array-6.c:15:14: error: invalid use of array with unspecified bounds
struct str c = { 2, "c" }; /* { dg-error "(non-static)|(near
initialization)" } */
^
array-6.c:15:14: error: invalid use of array with unspecified bounds
array-6.c:16:14: error: invalid use of array with unspecified bounds
struct str d = (struct str) { 2, "d" }; /* { dg-error "(non-static)|(near
initialization)" } */
^
array-6.c:16:14: error: invalid use of array with unspecified bounds
array-6.c:17:14: error: invalid use of array with unspecified bounds
struct str e = (struct str) { d.len, "e" }; /* { dg-error
"(non-static)|(initialization)" } */
^
array-6.c:17:14: error: invalid use of array with unspecified bounds
[Bug middle-end/88246] Abort signal terminated program collect2 - munmap_chunk(): invalid pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88246 --- Comment #4 from Martin Liška --- I see segfault in driver in: Thread 2.1 "collect2" received signal SIGABRT, Aborted. [Switching to process 11687] 0x03fffbd4192e in raise () from /lib64/libc.so.6 (gdb) bt #0 0x03fffbd4192e in raise () from /lib64/libc.so.6 #1 0x03fffbd2391c in abort () from /lib64/libc.so.6 #2 0x03fffbd85d00 in __libc_message () from /lib64/libc.so.6 #3 0x03fffbd8cbe0 in malloc_printerr () from /lib64/libc.so.6 #4 0x03fffbd9131c in free_check () from /lib64/libc.so.6 #5 0x0101005c in find_a_file (pprefix=pprefix@entry=0x10ca7e0 , name=, name@entry=0x1089f78 "real-ld", mode=mode@entry=1) at ../../gcc/file-find.c:104 #6 0x0100514a in main (argc=, argv=) at ../../gcc/collect2.c:1141 (gdb) frame 5 #5 0x0101005c in find_a_file (pprefix=pprefix@entry=0x10ca7e0 , name=, name@entry=0x1089f78 "real-ld", mode=mode@entry=1) at ../../gcc/file-find.c:104 104 free (temp); xgcc: fatal error: Killed signal terminated program collect2 It would be handy to run that in valgrind (which I don't have access to). Can you Andreas please do that?
[Bug preprocessor/88257] [9 Regression] ICE in linemap_position_for_line_and_column, at libcpp/line-map.c:842
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88257 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Can't reproduce either. Can you reproduce with -save-temps? If yes, can you attach preprocessed source, so that we are looking for the exact same tokens?
[Bug target/88234] UBsan and runtime error: signed integer overflow using unsigned vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88234 --- Comment #9 from Segher Boessenkool --- (In reply to Jeffrey Walton from comment #8) > Yeah, I tried to convert to the C/C++ pointer dereference pattern several > times as shown in the literature. I.e., this: > > byte x[16]; > uint8x16_p cc = (uint8x16_p)c; > *(uint8x16_p*) &x[0] = cc; That is the preferred way, in general. > Instead of this: > > byte x[16]; > vec_vsx_st((uint8x16_p)c, 0, x); > > It breaks a lot of our self tests for certain versions of a particular > compiler. Yeah, no doubt :-( But vec_vsx_st isn't even ABI. If it doesn't work well on some maintained GCC version, please tell me, or open a PR even. > I narrowed it down to the loads but I could not take it further > and develop a reduced case. I don't have the skill to untangle what is > happening in ppc asm at -O3. It seems the vec_add itself is handled incorrectly. We'll figure it out :-) > If you want to see something really obscene, then take a look at > https://github.com/weidai11/cryptopp/blob/master/ppc_simd.h#L251 . Heh. Well you have it nicely abstracted away to this one function :-) > (If you are talking about something else that is wrong or bad, then please > point it out.) Loads and stores should preferably be written as just assignments. That way, the compiler can figure out what is best to use for the selected ABI and CPU.
[Bug c++/87750] [8/9 Regression] Failed compilation / parsing of template member call after 'using' declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87750
--- Comment #8 from Alexandre Oliva ---
Created attachment 45124
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45124&action=edit
fix on top of the improved candidate patch
This patchlet fixes the regressions in g++.dg/template/using{3,15,39,44}.C
[Bug preprocessor/88257] [9 Regression] ICE in linemap_position_for_line_and_column, at libcpp/line-map.c:842
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88257 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-11-29 Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from David Malcolm --- Thanks for filing this. I'm able to reproduce it (with r266459 fwiw) and am investigating.
[Bug c++/87750] [8/9 Regression] Failed compilation / parsing of template member call after 'using' declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87750
--- Comment #9 from Alexandre Oliva ---
err... using{39,44}.C in g++.dg/lookup, actually. and using44.C is still
broken, sorry
[Bug c++/88261] [9 Regression] ICE: verify_gimple failed (error: non-trivial conversion at assignment)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88261 --- Comment #2 from Jakub Jelinek --- Started with r264147.
[Bug target/88096] wrong inline AVX512F optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88096 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #2 from Alexander Monakov --- This is very likely this Binutils bug (as incorrectly encodes displacement): https://sourceware.org/bugzilla/show_bug.cgi?id=23465 (so should works fine with binutils 2.29 or 2.31) In GCC this was reported as PR 86735 and dups.
[Bug c++/87750] [8/9 Regression] Failed compilation / parsing of template member call after 'using' declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87750 --- Comment #10 from Alexandre Oliva --- ... and it looks like lookup/using44.C really wants the USING_DECL from lookup_member; the function overloads are not template dependent, and as a result we perform overload resolution only among them, leaving out the function decl we should select through the using decl. Ugh. I guess this simple, hackish approach won't work. I'll have to either figure out a way to indicate in the returned using decl (before the change) that some other overload is a template, or return the entire overload and adjust places that don't like that, or use an alternate lookup where we want to get the overloads, or just to tell whether there's any template among them. ugh :-/ but first, some sleep :-)
[Bug target/88234] UBsan and runtime error: signed integer overflow using unsigned vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88234 --- Comment #10 from Jakub Jelinek --- Author: jakub Date: Thu Nov 29 14:23:21 2018 New Revision: 266619 URL: https://gcc.gnu.org/viewcvs?rev=266619&root=gcc&view=rev Log: PR target/88234 * config/rs6000/rs6000.c (rs6000_gimple_fold_builtin): For vec_add and vec_sub builtins, perform PLUS_EXPR or MINUS_EXPR in unsigned_type_for instead of vector integral type where overflow doesn't wrap. * gcc.dg/ubsan/pr88234.c: New test. Added: trunk/gcc/testsuite/gcc.dg/ubsan/pr88234.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c trunk/gcc/testsuite/ChangeLog
[Bug target/88234] UBsan and runtime error: signed integer overflow using unsigned vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88234 --- Comment #11 from Jakub Jelinek --- Fixed on the trunk so far, queued for backports.
[Bug target/88152] optimize SSE & AVX char compares with subsequent movmskb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88152 --- Comment #6 from Jakub Jelinek --- Author: jakub Date: Thu Nov 29 14:32:00 2018 New Revision: 266620 URL: https://gcc.gnu.org/viewcvs?rev=266620&root=gcc&view=rev Log: PR target/88152 * tree.h (build_uniform_cst, uniform_integer_cst_p): Declare. * tree.c (build_uniform_cst, uniform_integer_cst_p): New functions. * match.pd (define_predicates): Add uniform_integer_cst_p. (cmp @0 INTEGER_CST@1, cmp (convert?@2 @0) INTEGER_CST@1): Adjust so that it works also for vector comparisons with uniform constants with INTEGER_CST element. * g++.dg/tree-ssa/pr88152-1.C: New test. * g++.dg/tree-ssa/pr88152-2.C: New test. Added: trunk/gcc/testsuite/g++.dg/tree-ssa/pr88152-1.C trunk/gcc/testsuite/g++.dg/tree-ssa/pr88152-2.C Modified: trunk/gcc/ChangeLog trunk/gcc/match.pd trunk/gcc/testsuite/ChangeLog trunk/gcc/tree.c trunk/gcc/tree.h
[Bug target/54700] Optimize away x<0 as mask argument of a blend.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54700 --- Comment #8 from Jakub Jelinek --- Author: jakub Date: Thu Nov 29 14:33:27 2018 New Revision: 266621 URL: https://gcc.gnu.org/viewcvs?rev=266621&root=gcc&view=rev Log: PR target/54700 * config/i386/sse.md (ssebytemode): Add V16SI, V8SI and V4SI entries. (ssefltmodesuffix, ssefltvecmode): New define_mode_attrs. (*_blendv_lt, *_blendv_ltint, *_pblendvb_lt): New define_insns. * g++.target/i386/sse4_1-pr54700-1.C: New test. * g++.target/i386/sse4_1-pr54700-2.C: New test. * g++.target/i386/avx-pr54700-1.C: New test. * g++.target/i386/avx-pr54700-2.C: New test. * g++.target/i386/avx2-pr54700-1.C: New test. * g++.target/i386/avx2-pr54700-2.C: New test. * g++.target/i386/sse4_1-check.h: New file. * g++.target/i386/avx-check.h: New file. * g++.target/i386/avx2-check.h: New file. * g++.target/i386/m128-check.h: New file. * g++.target/i386/m256-check.h: New file. * g++.target/i386/avx-os-support.h: New file. Added: trunk/gcc/testsuite/g++.target/i386/avx-check.h trunk/gcc/testsuite/g++.target/i386/avx-os-support.h trunk/gcc/testsuite/g++.target/i386/avx-pr54700-1.C trunk/gcc/testsuite/g++.target/i386/avx-pr54700-2.C trunk/gcc/testsuite/g++.target/i386/avx2-check.h trunk/gcc/testsuite/g++.target/i386/avx2-pr54700-1.C trunk/gcc/testsuite/g++.target/i386/avx2-pr54700-2.C trunk/gcc/testsuite/g++.target/i386/m128-check.h trunk/gcc/testsuite/g++.target/i386/m256-check.h trunk/gcc/testsuite/g++.target/i386/sse4_1-check.h trunk/gcc/testsuite/g++.target/i386/sse4_1-pr54700-1.C trunk/gcc/testsuite/g++.target/i386/sse4_1-pr54700-2.C Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/sse.md trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/88240] Potential optimization bug: invalid pre-load of floating-point value could cause SIGFPE-underflow if value is integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88240 --- Comment #9 from Florian Weimer --- (In reply to Thomas De Schampheleire from comment #6) > (In reply to Florian Weimer from comment #5) > > This is QEMU with TCG, right? It could be an i387 emulation bug. > > I don't think so. Isn't it so that KVM and TCG are mutually exclusive > choices? > We see the problem if we pass --enable-kvm and don't see the problem if we > don't pass that flag. From my limited understanding of qemu, not paying the > flag means that the default TCG emulation is used. Am I wrong? Right, my mistake.
[Bug target/54700] Optimize away x<0 as mask argument of a blend.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54700 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Jakub Jelinek --- Fixed.
Re: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54589
Hi All,
We are able to fix the subjected issue with the peephole patterns
(target specific) in the md file (attached the patch pr54589.patch).
While testing the fix ,we end up with some of the C constructs like
Testcase 1:
#include
struct param {
int a, b, c, d;
__m128i array[256];
};
void func(struct param p, unsigned char *src, int *dst)
{
__m128i x = p.array[*src];
*dst = _mm_cvtsi128_si32(x);
}
compiles with -O2 for x86-64 and asm looks like
func:
movzbl (%rdi), %eax
addq$1, %rax
salq$4, %rax
movl8(%rsp,%rax), %eax
movl%eax, (%rsi)
ret
Testcase 2:
#include
struct param {
int a, b, c, d;
__m128i array[256];
};
struct param *p1;
void func(unsigned char *src, int *dst)
{
__m128i x = p1->array[*src];
*dst = _mm_cvtsi128_si32(x);
}
compiles with -O2 on x86-64 :
func:
movzbl (%rdi), %eax
addq$1, %rax
salq$4, %rax
addqp1(%rip), %rax
movl(%rax), %eax
movl%eax, (%rsi)
ret
So, we are thinking to extend our fix with few more peephole patterns
in the md file.
OR it’s better to handle all C constructs in combiner/fwprop pass
,please let us know your suggestions or comments on this ,that guides
us in the right direction.
Thank you
~Umesh
On Fri, Nov 23, 2018 at 3:56 PM Umesh Kalappa wrote:
>
> Hi Richard,
>
> for the subjected issue , we found few suggestions to handle the issue like
>
> 1. be more conservative(target specific) and defining the peephole in
> the md file to handle the patterns like add,shl and movl to "shlq and
> movl"
> 2. like you mentioned in fwprop/combiner .
>
> we would like to know your inputs /suggestions before we go ahead with
> the patch.
>
> Thank you
> ~Umesh
pr54589.patch
Description: Binary data
[Bug libstdc++/88264] New: Support glibc-style tunables for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88264 Bug ID: 88264 Summary: Support glibc-style tunables for Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Target Milestone: --- "Tunables are a feature in the GNU C Library that allows application authors and distribution maintainers to alter the runtime library behavior to match their workload." https://www.gnu.org/software/libc/manual/html_node/Tunables.html We should support them in libstdc++ too. The resource types in are obvious candidates, but there might be others too (default std::async launch policy?). Possible tunables: For monotonic_buffer_resource: the initial buffer size and growth factor. For the pool resources: the supported pool sizes, if/when empty chunks are released to the upstream resource, the default max_blocks_per_chunk and default largest_required_pool_block, initial number of blocks per chunk (in _M_alloc_pools). For the pool resources it would also be possible to tune some of those numbers per-resource by inventing an __extended_pool_options type that goes beyond the two params that std::pmr::pool_options controls.
[Bug fortran/88265] New: [9 Regression] gfortran.dg/simd-builtins-1.f90 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88265 Bug ID: 88265 Summary: [9 Regression] gfortran.dg/simd-builtins-1.f90 fails Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: janus at gcc dot gnu.org Target Milestone: --- When regtesting the current trunk on x86_64-linux-gnu, I see the following failures: FAIL: gfortran.dg/simd-builtins-1.f90 -O scan-assembler call.*_ZGVbN4v_sinf FAIL: gfortran.dg/simd-builtins-6.f90 -O scan-assembler call.*_ZGVbN4v_sinf Both test cases expect the assembly to contain a call to "_ZGVbN4v_sinf", but what I see on my system is a call to "_ZGVdN8v_sinf".
[Bug libstdc++/88264] Support glibc-style tunables for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88264 --- Comment #1 from Jonathan Wakely --- I forgot to list the growth factor for pool resource too (currently hardcoded to 2 in __pool_resource::_Pool::replenish())
[Bug fortran/88265] [9 Regression] gfortran.dg/simd-builtins-1.f90 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88265 janus at gcc dot gnu.org changed: What|Removed |Added CC||mliska at suse dot cz Target Milestone|--- |9.0 --- Comment #1 from janus at gcc dot gnu.org --- The test case was added in (In reply to janus from comment #0) > Both test cases expect the assembly to contain a call to "_ZGVbN4v_sinf", > but what I see on my system is a call to "_ZGVdN8v_sinf". Those tests were added in r266509. Martin, do you understand how this comes about?
[Bug middle-end/88246] Abort signal terminated program collect2 - munmap_chunk(): invalid pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88246 Martin Liška changed: What|Removed |Added CC||law at gcc dot gnu.org --- Comment #5 from Martin Liška --- Jeff can also see the problem, there's a valgrind backtrace from him: ==56970== ==56970== Invalid write of size 1 ==56970==at 0x1010E18: find_a_file(path_prefix*, char const*, int) (in /home/nfs/law/jenkins/workspace/s390x-linux-gnu/obj/gcc/gcc/collect2) ==56970==by 0x1005E31: main (in /home/nfs/law/jenkins/workspace/s390x-linux-gnu/obj/gcc/gcc/collect2) ==56970== Address 0x4ad08ef is 0 bytes after a block of size 31 alloc'd ==56970==at 0x4831090: malloc (vg_replace_malloc.c:299) ==56970==by 0x10806DF: xmalloc (in /home/nfs/law/jenkins/workspace/s390x-linux-gnu/obj/gcc/gcc/collect2) ==56970==by 0x1010DEF: find_a_file(path_prefix*, char const*, int) (in /home/nfs/law/jenkins/workspace/s390x-linux-gnu/obj/gcc/gcc/collect2) ==56970==by 0x1005E31: main (in /home/nfs/law/jenkins/workspace/s390x-linux-gnu/obj/gcc/gcc/collect2) ==56970== ==56970== Invalid write of size 1 ==56970==at 0x1010E30: find_a_file(path_prefix*, char const*, int) (in /home/nfs/law/jenkins/workspace/s390x-linux-gnu/obj/gcc/gcc/collect2) ==56970==by 0x1005E31: main (in /home/nfs/law/jenkins/workspace/s390x-linux-gnu/obj/gcc/gcc/collect2) ==56970== Address 0x4ad08fb is 12 bytes after a block of size 31 alloc'd ==56970==at 0x4831090: malloc (vg_replace_malloc.c:299) ==56970==by 0x10806DF: xmalloc (in /home/nfs/law/jenkins/workspace/s390x-linux-gnu/obj/gcc/gcc/collect2) ==56970==by 0x1010DEF: find_a_file(path_prefix*, char const*, int) (in /home/nfs/law/jenkins/workspace/s390x-linux-gnu/obj/gcc/gcc/collect2) ==56970==by 0x1005E31: main (in /home/nfs/law/jenkins/workspace/s390x-linux-gnu/obj/gcc/gcc/collect2) ==56970== ==56970== Syscall param stat(file_name) points to unaddressable byte(s) ==56970==at 0x49FBD90: _xstat (in /usr/lib64/libc-2.26.so) ==56970==by 0x1010E3D: find_a_file(path_prefix*, char const*, int) (in /home/nfs/law/jenkins/workspace/s390x-linux-gnu/obj/gcc/gcc/collect2) ==56970==by 0x1005E31: main (in /home/nfs/law/jenkins/workspace/s390x-linux-gnu/obj/gcc/gcc/collect2) ==56970== Address 0x4ad08fb is 12 bytes after a block of size 31 alloc'd ==56970==at 0x4831090: malloc (vg_replace_malloc.c:299) ==56970==by 0x10806DF: xmalloc (in /home/nfs/law/jenkins/workspace/s390x-linux-gnu/obj/gcc/gcc/collect2) ==56970==by 0x1010DEF: find_a_file(path_prefix*, char const*, int) (in /home/nfs/law/jenkins/workspace/s390x-linux-gnu/obj/gcc/gcc/collect2) ==56970==by 0x1005E31: main (in /home/nfs/law/jenkins/workspace/s390x-linux-gnu/obj/gcc/gcc/collect2) ==56970== valgrind: m_mallocfree.c:307 (get_bszB_as_is): Assertion 'bszB_lo == bszB_hi' failed. valgrind: Heap block lo/hi size mismatch: lo = 96, hi = 3417228689894289267. This is probably caused by your program erroneously writing past the end of a heap block and corrupting heap metadata. If you fix any invalid writes reported by Memcheck, this assertion failure will probably go away. Please try that before reporting this as a bug. host stacktrace: ==56970==at 0x8000521BC: ??? (in /usr/lib64/valgrind/memcheck-s390x-linux) ==56970==by 0x80005206D: ??? (in /usr/lib64/valgrind/memcheck-s390x-linux) sched status: running_tid=1 Thread 1: status = VgTs_Runnable (lwpid 56970) ==56970==at 0x4832522: free (vg_replace_malloc.c:530) ==56970==by 0x1010E95: find_a_file(path_prefix*, char const*, int) (in /home/nfs/law/jenkins/workspace/s390x-linux-gnu/obj/gcc/gcc/collect2) ==56970==by 0x1005E31: main (in /home/nfs/law/jenkins/workspace/s390x-linux-gnu/obj/gcc/gcc/collect2) client stack range: [0x1FFEFFD000 0x1FFF000FFF] client SP: 0x1FFEFFF010 valgrind stack range: [0x1002BA2000 0x1002CA1FFF] top usage: 9784 of 1048576
[Bug c++/88266] New: nonsense warning about parentheses for comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88266
Bug ID: 88266
Summary: nonsense warning about parentheses for comparison
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jason.kraftch...@cd-adapco.com
Target Milestone: ---
For this code compiled with -Wall:
bool xnor( bool a, bool b, bool c, bool d )
{ return a != b != c != d; }
I get these warnings:
/tmp/xnor.cc: In function ‘bool xnor(bool, bool, bool, bool)’:
/tmp/xnor.cc:2:14: warning: suggest parentheses around comparison in operand
of ‘!=’ [-Wparentheses]
{ return a != b != c != d; }
~~^~~~
/tmp/xnor.cc:2:19: warning: suggest parentheses around comparison in operand
of ‘!=’ [-Wparentheses]
{ return a != b != c != d; }
~~~^~~~
The order of evaluation of these comparisons doesn't matter, so parentheses add
nothing. One could even argue that adding them would be detrimental because it
gives the false impression that the order matters.
[Bug middle-end/88246] Abort signal terminated program collect2 - munmap_chunk(): invalid pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88246 --- Comment #6 from Martin Liška --- Using cross-compiler I see following difference before and after my patch: _Z11find_a_fileP11path_prefixPKci: .LFB265: stmg%r7,%r15,56(%r15) .LCFI0: l %r12,8(%r2) lgr %r8,%r2 lgr %r2,%r3 lhi %r0,0 lghi%r1,0 ahi %r12,1 larl%r7,_ZL5debug srst%r1,%r2 jo .-4 sgr %r1,%r3 aghi%r15,-304 .LCFI1: ar %r12,%r1 cli 0(%r7),0 lgr %r10,%r3 lgr %r9,%r4 jne .L31 lgfr%r2,%r12 brasl %r14,xmalloc cli 0(%r10),47 lgr %r12,%r2 je .L32 .L6: lg %r11,0(%r8) ltgr%r11,%r11 je .L12 .L14: - lgr %r5,%r12 lg %r1,0(%r11) lhi %r0,0 + lgr %r5,%r10 + mvst%r12,%r1 + jo .-4 + lgr %r1,%r12 la %r4,160(%r15) lgr %r3,%r12 - mvst%r5,%r1 - jo .-4 - lgr %r1,%r10 lghi%r2,1 - mvst%r5,%r1 + mvst%r1,%r5 jo .-4 brasl %r14,__xstat ltr %r2,%r2 jl .L13 llill %r1,61440
[Bug target/54589] struct offset add should be folded into address calculation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54589
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
||segher at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek ---
Note, in other cases combine is sucessful. E.g. consider:
struct S { int a, b, c, d; };
struct T { struct S e[16]; struct S f[1024]; } t;
int
foo (unsigned long x)
{
return t.f[x + 5].a;
}
int
bar (struct T *x, unsigned long y)
{
return x->f[y + 5].b;
}
On x86_64-linux with -O2, we have before combine in both cases
(idx + 21) << 4 and in foo combine says:
Trying 7, 8 -> 10:
7: {r87:DI=r91:DI+0x15;clobber flags:CC;}
REG_DEAD r91:DI
REG_UNUSED flags:CC
8: {r88:DI=r87:DI<<0x4;clobber flags:CC;}
REG_DEAD r87:DI
REG_UNUSED flags:CC
10: r90:SI=[r88:DI+`t']
REG_DEAD r88:DI
Failed to match this instruction:
(set (reg:SI 90 [ t.f[_1].a ])
(mem:SI (plus:DI (mult:DI (reg:DI 91)
(const_int 16 [0x10]))
(const:DI (plus:DI (symbol_ref:DI ("t") [flags 0x2] )
(const_int 336 [0x150] [1 t.f[_1].a+0 S4 A32]))
Successfully matched this instruction:
(set (reg:DI 88)
(ashift:DI (reg:DI 91)
(const_int 4 [0x4])))
Successfully matched this instruction:
(set (reg:SI 90 [ t.f[_1].a ])
(mem:SI (plus:DI (reg:DI 88)
(const:DI (plus:DI (symbol_ref:DI ("t") [flags 0x2] )
(const_int 336 [0x150] [1 t.f[_1].a+0 S4 A32]))
and it is merged the way we want:
salq$4, %rdi
movlt+336(%rdi), %eax
while in bar:
Failed to match this instruction:
(set (reg:SI 91 [ x_4(D)->f[_1].b ])
(mem:SI (plus:DI (plus:DI (mult:DI (reg:DI 93)
(const_int 16 [0x10]))
(reg:DI 92))
(const_int 340 [0x154])) [1 x_4(D)->f[_1].b+0 S4 A32]))
Failed to match this instruction:
(set (reg:DI 88)
(plus:DI (ashift:DI (reg:DI 93)
(const_int 4 [0x4]))
(reg:DI 92)))
and it is not merged:
addq$21, %rsi
salq$4, %rsi
movl4(%rsi,%rdi), %eax
when it could be:
salq$4, %rsi
movl340(%rsi,%rdi), %eax
It isn't x86 specific though, e.g. on powerpc64-linux we end up with:
addi 4,4,21
sldi 4,4,4
add 4,3,4
lwa 3,4(4)
for bar, where I guess:
sldi 4,4,4
add 4,3,4
lwa 3,340(4)
would work too.
[Bug middle-end/88246] Abort signal terminated program collect2 - munmap_chunk(): invalid pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88246 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #7 from Jeffrey A. Law --- Removing -gtoggle from the compilation of find-file.c got me a bit more info: ==57496== ==57496== Invalid write of size 1 ==57496==at 0x1010E18: find_a_file(path_prefix*, char const*, int) (file-find.c:81) ==57496==by 0x1005E31: main (in /home/nfs/law/jenkins/workspace/s390x-linux-gnu/obj/gcc/gcc/collect2) ==57496== Address 0x4ad08ef is 0 bytes after a block of size 31 alloc'd ==57496==at 0x4831090: malloc (vg_replace_malloc.c:299) ==57496==by 0x10806DF: xmalloc (in /home/nfs/law/jenkins/workspace/s390x-linux-gnu/obj/gcc/gcc/collect2) ==57496==by 0x1010DEF: find_a_file(path_prefix*, char const*, int) (file-find.c:47) ==57496==by 0x1005E31: main (in /home/nfs/law/jenkins/workspace/s390x-linux-gnu/obj/gcc/gcc/collect2) ==57496== ==57496== Invalid write of size 1 ==57496==at 0x1010E30: find_a_file(path_prefix*, char const*, int) (file-find.c:82) ==57496==by 0x1005E31: main (in /home/nfs/law/jenkins/workspace/s390x-linux-gnu/obj/gcc/gcc/collect2) ==57496== Address 0x4ad08fb is 12 bytes after a block of size 31 alloc'd ==57496==at 0x4831090: malloc (vg_replace_malloc.c:299) ==57496==by 0x10806DF: xmalloc (in /home/nfs/law/jenkins/workspace/s390x-linux-gnu/obj/gcc/gcc/collect2) ==57496==by 0x1010DEF: find_a_file(path_prefix*, char const*, int) (file-find.c:47) ==57496==by 0x1005E31: main (in /home/nfs/law/jenkins/workspace/s390x-linux-gnu/obj/gcc/gcc/collect2) ==57496== ==57496== Syscall param stat(file_name) points to unaddressable byte(s) ==57496==at 0x49FBD90: _xstat (in /usr/lib64/libc-2.26.so) ==57496==by 0x1010E3D: stat (stat.h:451) ==57496==by 0x1010E3D: find_a_file(path_prefix*, char const*, int) (file-find.c:84) ==57496==by 0x1005E31: main (in /home/nfs/law/jenkins/workspace/s390x-linux-gnu/obj/gcc/gcc/collect2) ==57496== Address 0x4ad08fb is 12 bytes after a block of size 31 alloc'd ==57496==at 0x4831090: malloc (vg_replace_malloc.c:299) ==57496==by 0x10806DF: xmalloc (in /home/nfs/law/jenkins/workspace/s390x-linux-gnu/obj/gcc/gcc/collect2) ==57496==by 0x1010DEF: find_a_file(path_prefix*, char const*, int) (file-find.c:47) ==57496==by 0x1005E31: main (in /home/nfs/law/jenkins/workspace/s390x-linux-gnu/obj/gcc/gcc/collect2) ==57496==
[Bug fortran/88265] [9 Regression] gfortran.dg/simd-builtins-1.f90 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88265 --- Comment #2 from janus at gcc dot gnu.org --- (In reply to janus from comment #0) > Both test cases expect the assembly to contain a call to "_ZGVbN4v_sinf", > but what I see on my system is a call to "_ZGVdN8v_sinf". That was on a haswell machine. On a skylake CPU I even see: call_ZGVeN16v_sinf So apparently I get broader vector calls than expected. Note that this seems to happen only when configuring with --with-arch=... (e.g. haswell or skylake-avx512 ).
[Bug middle-end/88246] Abort signal terminated program collect2 - munmap_chunk(): invalid pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88246 --- Comment #8 from Martin Liška --- I found it, will send patch soon.
[Bug target/88207] [9 regression] gcc.target/i386/pr22076.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88207 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #5 from Jeffrey A. Law --- Fixed by Vlad's patch on the trunk.
[Bug c++/88261] [9 Regression] ICE: verify_gimple failed (error: non-trivial conversion at assignment)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88261
--- Comment #3 from Martin Sebor ---
The ICE only affects C++. G++ 8 and prior accept the code with just a pedantic
warning:
$ cat pr88261.C && gcc -O2 -S -Wall -Wextra -Wpedantic pr88261.C
struct str { int len; char s[]; };
void foo()
{
struct str c = { 2, "c" };
}
pr88261.C:1:30: warning: ISO C++ forbids flexible array member ‘s’ [-Wpedantic]
struct str { int len; char s[]; };
^
pr88261.C: In function ‘void foo()’:
pr88261.C:5:27: warning: initialization of a flexible array member [-Wpedantic]
struct str c = { 2, "c" };
^
pr88261.C:5:14: warning: unused variable ‘c’ [-Wunused-variable]
struct str c = { 2, "c" };
^
But G++ rejects the code if it's changed like below so the C++ front-end should
probably reject it regardless of whether or not the struct is used.
int foo()
{
struct str c = { 2, "c" };
return c.s[0];
}
pr88261.C:1:30: warning: ISO C++ forbids flexible array member ‘s’ [-Wpedantic]
struct str { int len; char s[]; };
^
pr88261.C: In function ‘int foo()’:
pr88261.C:5:27: warning: initialization of a flexible array member [-Wpedantic]
struct str c = { 2, "c" };
^
pr88261.C:5:14: error: invalid use of array with unspecified bounds
struct str c = { 2, "c" };
^
pr88261.C:5:14: error: invalid use of array with unspecified bounds
The again, G++ 5 accepts the modified example above with -fpermissive:
pr88261.C:5:27: warning: initializer-string for array of chars is too long
[-fpermissive]
struct str c = { 2, "c" };
^
[Bug ipa/87957] [9 Regression] ICE tree check: expected tree that contains ‘decl minimal’ structure, have ‘identifier_node’ in warn_odr, at ipa-devirt.c:1051 since r265519
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87957 --- Comment #13 from Dominique d'Humieres --- > Seen on i386-pc-solaris2.11 and sparc-sun-solaris2.11 (32 and 64-bit, > gcc-testresults > reports also on aarch64-suse-linux-gnu, arm-unknown-linux-gnueabihf, > s390x-ibm-linux-gnu default Also seen on darwin.
[Bug ipa/88231] aligned functions laid down inefficiently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88231 Andi Kleen changed: What|Removed |Added CC||andi-gcc at firstfloor dot org --- Comment #4 from Andi Kleen --- I'm not sure it's a good idea to do this. Often the goal is not to get the absolute smallest code, but to get code that minimizes cache line usage. This is important for "frontend bound" code like gcc itself often is. It would be rather better to use an algorithm like Petis-Hansen or the one in hfsort (see https://research.fb.com/wp-content/uploads/2017/01/cgo2017-hfsort-final1.pdf) to lay out the code based on expected call order to minimize foot print. For best result would need profile feedback of course, but it might already do a reasonable job based on static call frequencies.
[Bug c++/87539] [8 Regression] internal compiler error when compiling project with Os optimization flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87539 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com Summary|[8/9 Regression] internal |[8 Regression] internal |compiler error when |compiler error when |compiling project with Os |compiling project with Os |optimization flag |optimization flag --- Comment #5 from Jeffrey A. Law --- Agreed that it's fixed on the trunk. Removing -9 regression marker.
[Bug middle-end/86680] possible gcc optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86680
--- Comment #11 from Florian La Roche
---
Below my current code that disables optimization for this one function and thus
generates ok code length.
best regards,
Florian La Roche
#if __GNUC__ > 4
#define __gcc_no_ivopts __attribute__ ((optimize("no-ivopts")))
#else
#define __gcc_no_ivopts
#endif
extern unsigned long __bss_start[], __bss_end[];
void __gcc_no_ivopts clear_bss(void)
{
unsigned long *bss = __bss_start;
#if 1
while (bss < __bss_end)
*bss++ = 0UL;
#else
unsigned long i, end = (__bss_end - __bss_start) * sizeof(unsigned long);
for (i = 0; i < end; i += sizeof(unsigned long))
*bss++ = 0UL;
#endif
}
[Bug target/54589] struct offset add should be folded into address calculation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54589
--- Comment #6 from Jakub Jelinek ---
--- gcc/combine.c.jj2018-11-21 19:57:26.229726485 +0100
+++ gcc/combine.c 2018-11-29 17:57:48.069423874 +0100
@@ -4945,7 +4945,7 @@ find_split_point (rtx *loc, rtx_insn *in
}
/* If we have a PLUS whose second operand is a constant and the
-address is not valid, perhaps will can split it up using
+address is not valid, perhaps we can split it up using
the machine-specific way to split large constants. We use
the first pseudo-reg (one of the virtual regs) as a placeholder;
it will not remain in the result. */
@@ -4960,7 +4960,7 @@ find_split_point (rtx *loc, rtx_insn *in
/* This should have produced two insns, each of which sets our
placeholder. If the source of the second is a valid address,
-we can make put both sources together and make a split point
+we can put both sources together and make a split point
in the middle. */
if (seq
@@ -5001,14 +5001,45 @@ find_split_point (rtx *loc, rtx_insn *in
}
}
+ /* If that didn't work and we have a nested plus, like:
+((REG1 * CONST1) + REG2) + CONST2 and (REG1 + REG2) + CONST2
+is valid address, try to split (REG1 * CONST1). */
+ if (GET_CODE (XEXP (XEXP (x, 0), 0)) == PLUS
+ && !OBJECT_P (XEXP (XEXP (XEXP (x, 0), 0), 0))
+ && OBJECT_P (XEXP (XEXP (XEXP (x, 0), 0), 1)))
+ {
+ rtx tem = XEXP (XEXP (XEXP (x, 0), 0), 0);
+ XEXP (XEXP (XEXP (x, 0), 0), 0) = reg;
+ if (memory_address_addr_space_p (GET_MODE (x), XEXP (x, 0),
+ MEM_ADDR_SPACE (x)))
+ {
+ XEXP (XEXP (XEXP (x, 0), 0), 0) = tem;
+ return &XEXP (XEXP (XEXP (x, 0), 0), 0);
+ }
+ XEXP (XEXP (XEXP (x, 0), 0), 0) = tem;
+ }
+ else if (GET_CODE (XEXP (XEXP (x, 0), 0)) == PLUS
+ && OBJECT_P (XEXP (XEXP (XEXP (x, 0), 0), 0))
+ && !OBJECT_P (XEXP (XEXP (XEXP (x, 0), 0), 1)))
+ {
+ rtx tem = XEXP (XEXP (XEXP (x, 0), 0), 1);
+ XEXP (XEXP (XEXP (x, 0), 0), 1) = reg;
+ if (memory_address_addr_space_p (GET_MODE (x), XEXP (x, 0),
+ MEM_ADDR_SPACE (x)))
+ {
+ XEXP (XEXP (XEXP (x, 0), 0), 1) = tem;
+ return &XEXP (XEXP (XEXP (x, 0), 0), 1);
+ }
+ XEXP (XEXP (XEXP (x, 0), 0), 1) = tem;
+ }
+
/* If that didn't work, perhaps the first operand is complex and
needs to be computed separately, so make a split point there.
This will occur on machines that just support REG + CONST
and have a constant moved through some previous computation. */
-
- else if (!OBJECT_P (XEXP (XEXP (x, 0), 0))
- && ! (GET_CODE (XEXP (XEXP (x, 0), 0)) == SUBREG
-&& OBJECT_P (SUBREG_REG (XEXP (XEXP (x, 0), 0)
+ if (!OBJECT_P (XEXP (XEXP (x, 0), 0))
+ && ! (GET_CODE (XEXP (XEXP (x, 0), 0)) == SUBREG
+ && OBJECT_P (SUBREG_REG (XEXP (XEXP (x, 0), 0)
return &XEXP (XEXP (x, 0), 0);
}
fixes this for me.
[Bug c++/87335] The stack overflow in function cplus_demangle_type in cp-demangle.c:2565 (c++filt -t)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87335 Scott Gayou changed: What|Removed |Added CC||sgayou at redhat dot com --- Comment #10 from Scott Gayou --- This reproducer seems to require adjusting the maximum stack size. i.e.: $ ulimit -s 8192 && c++filt < poc -t does NOT crash whereas: $ ulimit -s 2048 && c++filt < poc -t Segmentation fault (core dumped) This looks to be another potentially duplicated CVE. See the following: CVE-2018-18484: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87636 CVE-2018-18701: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87675 CVE-2018-18700: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87681 All appear to be the same root cause.
[Bug middle-end/88246] Abort signal terminated program collect2 - munmap_chunk(): invalid pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88246 --- Comment #9 from Martin Liška --- Author: marxin Date: Thu Nov 29 17:17:39 2018 New Revision: 266631 URL: https://gcc.gnu.org/viewcvs?rev=266631&root=gcc&view=rev Log: Fix thinko in transition to memop_ret type (PR middle-end/88246). 2018-11-29 Martin Liska PR middle-end/88246 * builtins.c (expand_movstr): Fix thinko introduced when switching to the new enum. Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c
[Bug middle-end/88246] Abort signal terminated program collect2 - munmap_chunk(): invalid pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88246 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Martin Liška --- Fixed.
[Bug libgcc/88267] New: A new flag in GCC causes a divergence in crtbegin.o file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88267 Bug ID: 88267 Summary: A new flag in GCC causes a divergence in crtbegin.o file Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- Accidentally I noticed that e.g. r266397 added a new option, so that options.h has more variables. And as crtstuff.c includes options.h (transitively), we end up with: before: $ nm ./gcc/crtbegin.o | grep completed b completed.7378 after: $ nm ./gcc/crtbegin.o | grep completed b completed.7379
[Bug target/54589] struct offset add should be folded into address calculation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54589 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- Created attachment 45125 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45125&action=edit gcc9-pr54589.patch Untested fix.
[Bug ipa/88231] aligned functions laid down inefficiently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88231
--- Comment #5 from Martin Sebor ---
The feature already exists at -Os by default (i.e., all functions are by
default minimally aligned). The suggestion here is only to let GCC minimize
the amount of padding it adds to functions in order to align the explicitly
overaligned ones that follow by changing the order it emits them in.
Outside -Os, functions would continue to be optimally aligned unless overridden
by the attribute. When their alignment is explicitly reduced by the attribute
GCC could still be smart about ordering them so as to minimize wasted space.
Consider:
__attribute__ ((aligned (4))) int f4 (int i) { return 2 * i; }
double f (double x) { return x * x * x; }
__attribute__ ((aligned (4))) int g4 (int i) { return i; }
for which GCC for x86_64 emits:
:;; unnecessarily overaligned
0: 8d 04 3flea(%rdi,%rdi,1),%eax
3: c3 retq
4: 66 90 xchg %ax,%ax
6: 66 2e 0f 1f 84 00 00nopw %cs:0x0(%rax,%rax,1)
d: 00 00 00
0010 : ;; optimally aligned
10: 66 0f 28 c8 movapd %xmm0,%xmm1
14: f2 0f 59 c8 mulsd %xmm0,%xmm1
18: f2 0f 59 c1 mulsd %xmm1,%xmm0
1c: c3 retq
1d: 0f 1f 00nopl (%rax)
0020 :;; also unnecessarily overaligned
20: 89 f8 mov%edi,%eax
22: c3 retq
If it laid down f first instead it would be able to avoid padding f4:
:
0: 66 0f 28 c8 movapd %xmm0,%xmm1
4: f2 0f 59 c8 mulsd %xmm0,%xmm1
8: f2 0f 59 c1 mulsd %xmm1,%xmm0
c: c3 retq
d: 0f 1f 00nopl (%rax)
0010 : ;; unavoidably overaligned
10: 8d 04 3flea(%rdi,%rdi,1),%eax
13: c3 retq
0014 : ;; aligned exactly as requested
14: 89 f8 mov%edi,%eax
16: c3 retq
This is probably not important outside -Os, but if it's implemented for -Os it
won't cost anything to also enable it at other optimization levels.
The following discussion provides some context:
https://gcc.gnu.org/ml/gcc/2018-11/msg00127.html
[Bug middle-end/88251] -Wformat-truncation=2 false alarms when compiling gzip, Emacs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88251
eggert at cs dot ucla.edu changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |---
--- Comment #3 from eggert at cs dot ucla.edu ---
(In reply to Martin Sebor from comment #1)
> The warning in this case is by design.
Then I’m afraid the design will have to be changed somewhat, as GCC is
generating false alarms about carefully-written code that is correctly
detecting buffer overflow, and this problem is causing GNU applications to
avoid using -Wformat-truncation=2 in code that would otherwise benefit from it.
The example I gave previously was deliberately stripped down and so perhaps
illustrates the issue poorly. Here is a less stripped-down example, taken from
an experimental version of Emacs. The original code uses repeated calls to
snprintf to gradually append to a buffer, each time using the count of the
previous snprintf to figure out where the next snprintf should start, and
returning 0 or 1 depending on whether the string fits. This stripped-down
version shows two iterations of this:
typedef unsigned long size_t;
typedef unsigned uid_t;
typedef unsigned long uintmax_t;
struct sockaddr_un
{
unsigned short sun_family;
char sun_path[108];
};
int snprintf (char *__restrict, size_t, const char *__restrict, ...)
__attribute__ ((__nothrow__))
__attribute__ ((__format__ (__printf__, 3, 4)));
int
set_socket_name (struct sockaddr_un *server, char const *server_name,
char const *tmpdir, uid_t u)
{
char *sun_path = server->sun_path;
enum { sun_pathsize = sizeof server->sun_path };
int tmpdirlen = (tmpdir
? snprintf (sun_path, sun_pathsize, "%s", tmpdir)
: snprintf (sun_path, sun_pathsize, "/tmp/u%u", u));
if (! (0 <= tmpdirlen && tmpdirlen < sun_pathsize))
return 0;
uintmax_t uid = u;
int remaining = sun_pathsize - tmpdirlen;
int n = snprintf (&sun_path[tmpdirlen], remaining, "/emacs%lu/%s",
uid, server_name);
if (! (0 <= n && n < remaining))
return 0;
return 1;
}
Compile this with ‘gcc -O2 -S -Wall -Wformat-truncation=2 emacsclient2.i’ and
the output is:
emacsclient2.i: In function ‘set_socket_name’:
emacsclient2.i:27:56: warning: ‘/emacs’ directive output truncated writing 6
bytes into a region of size 1 [-Wformat-truncation=]
int n = snprintf (&sun_path[tmpdirlen], remaining, "/emacs%lu/%s",
~^
emacsclient2.i:27:54: note: directive argument in the range [0, 4294967295]
int n = snprintf (&sun_path[tmpdirlen], remaining, "/emacs%lu/%s",
^~
emacsclient2.i:27:54: note: assuming directive output of 1 byte
emacsclient2.i:27:11: note: ‘snprintf’ output 9 or more bytes (assuming 19)
into a destination of size 1
int n = snprintf (&sun_path[tmpdirlen], remaining, "/emacs%lu/%s",
^~
uid, server_name);
~
Here GCC complains about the second snprintf call, apparently under the
assumption that the caller should first check that ‘remaining’ is at least 9
before the second call to snprintf. But such a check would be silly and hard to
maintain; the code is properly designed to let snprintf do the buffer overflow
check, and there should be no warning here.
Here’s another example, taken from Gnulib. This is a longer version of the
example I started off this bug report with (though it is still stripped down).
typedef unsigned long size_t;
extern int snprintf (char *__restrict, size_t, const char *__restrict, ...)
__attribute__ ((__nothrow__))
__attribute__ ((__format__ (__printf__, 3, 4)));
extern int __xpg_strerror_r (int, char *, size_t);
int
rpl_strerror_r (int errnum, char *buf, size_t buflen)
{
if (buflen <= 1)
{
if (buflen)
*buf = '\0';
return 34;
}
*buf = '\0';
int ret = __xpg_strerror_r (errnum, buf, buflen);
if (!*buf && ret == 22)
snprintf (buf, buflen, "Unknown error %d", errnum);
return ret;
}
This general-purpose function should work for any buffer length. It operates by
calling other general-purpose functions (__xpg_strerror_r, snprintf) that are
similar. The ‘buflen <= 1’ business works around a bug in AIX, where
__xpg_strerror_r function mishandles buffer lengths of 0 or 1. The ‘(!*buf &&
ret == 22)’ business works around an incompatibility with some other systems,
where __xpg_strerror_r does not properly fill in the buffer for unknown errors.
Compile this with ‘gcc -O2 -S -Wall -Wformat-truncation=2 strerror_r4.i’ and
the output is:
strerror_
[Bug fortran/88265] [9 Regression] gfortran.dg/simd-builtins-1.f90 fails when using --with-arch=...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88265 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #3 from Martin Liška --- Yes, you have wider vector. I'll add tomorrow -march=haswell that will force the expected width.
[Bug fortran/88265] [9 Regression] gfortran.dg/simd-builtins-1.f90 fails when using --with-arch=...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88265 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-11-29 CC|mliska at suse dot cz | Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from Martin Liška --- Mine.
[Bug fortran/87751] ICE in gfc_trans_assignment_1, at fortran/trans-expr.c:10255
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87751 --- Comment #2 from G. Steinmetz --- Changed in gcc-9 between 2018 (ICE) and 20181118 (ok=error), presumably due to pr70260. $ gfortran-9-20181125 -c z1.f90 z1.f90:8:3: 8 |g = 1 | 1 Error: Illegal assignment to external procedure at (1)
[Bug fortran/88268] New: Misleading extra warnings with -Wdo-subscript
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88268 Bug ID: 88268 Summary: Misleading extra warnings with -Wdo-subscript Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Version 8/9 with option -Wextra or -Wdo-subscript gives an additional warning for some valid code sections. Undesirable, but can be ignored. Not recommendable to change a much more complex program because of this. $ cat z1.f90 program p integer :: k, a, z(4) z = 789 do k = 1, 4 if ( k == 1 ) then a = 10 else a = z(k-1) end if print *, k, a end do end $ cat z2.f90 program p integer :: k, a, z(4) z = 789 do k = 1, 4 if ( k == 4 ) then a = 10 else a = z(k+1) end if print *, k, a end do end $ gfortran-7 -c z1.f90 -Wextra $ $ gfortran-9-20181125 -c z1.f90 -Wextra z1.f90:8:15: 4 |do k = 1, 4 | 2 .. 8 | a = z(k-1) | 1 Warning: Array reference at (1) out of bounds (0 < 1) in loop beginning at (2) [-Wdo-subscript]
[Bug fortran/88269] New: ICE in gfc_format_decoder, at fortran/error.c:947
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88269 Bug ID: 88269 Summary: ICE in gfc_format_decoder, at fortran/error.c:947 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- With invalid code, down to at least gcc-5 : $ cat z1.f90 program p write (end=1e1) write (end=1d1) write (end=1q1) end $ gfortran-9-20181125 -c z1.f90 0x619a5e gfc_format_decoder ../../gcc/fortran/error.c:947 0x131c83e pp_format(pretty_printer*, text_info*) ../../gcc/pretty-print.c:1390 0x13121e5 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*) ../../gcc/diagnostic.c:1015 0x6198fc gfc_error_opt ../../gcc/fortran/error.c:1313 0x61aea0 gfc_error(char const*, ...) ../../gcc/fortran/error.c:1342 0x63c9b2 check_io_constraints ../../gcc/fortran/io.c:3755 0x63c9b2 match_io ../../gcc/fortran/io.c:4301 0x66b341 match_word ../../gcc/fortran/parse.c:65 0x66eeb2 decode_statement ../../gcc/fortran/parse.c:585 0x66f6aa next_free ../../gcc/fortran/parse.c:1234 0x66f6aa next_statement ../../gcc/fortran/parse.c:1466 0x671a14 parse_spec ../../gcc/fortran/parse.c:3674 0x673787 parse_progunit ../../gcc/fortran/parse.c:5671 0x674e09 gfc_parse_file() ../../gcc/fortran/parse.c:6211 0x6bdaff gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204
[Bug c/88172] attribute aligned of zero silently accepted but ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88172 --- Comment #3 from Martin Sebor --- Author: msebor Date: Thu Nov 29 17:48:58 2018 New Revision: 266633 URL: https://gcc.gnu.org/viewcvs?rev=266633&root=gcc&view=rev Log: PR c/88172 - attribute aligned of zero silently accepted but ignored PR testsuite/88208 - new test case c-c++-common/builtin-has-attribute-3.c in r266335 has multiple excess errors gcc/ChangeLog: PR c/88172 PR testsuite/88208 * doc/extend.texi (attribute constructor): Clarify. gcc/c/ChangeLog: PR c/88172 PR testsuite/88208 * c-decl.c (declspec_add_alignas): Adjust call to check_user_alignment. gcc/c-family/ChangeLog: PR c/88172 PR testsuite/88208 * c-attribs.c (common_handle_aligned_attribute): Silently avoid setting alignments to values less than the target requires. (has_attribute): For attribute aligned consider both the attribute and the alignment bits. * c-common.c (c_init_attributes): Optionally issue a warning for zero alignment. gcc/testsuite/ChangeLog: PR c/88172 PR testsuite/88208 * gcc.dg/attr-aligned-2.c: New test. * gcc.dg/builtin-has-attribute.c: Adjust. * c-c++-common/builtin-has-attribute-2.c: Same. * c-c++-common/builtin-has-attribute-3.c: Same. * c-c++-common/builtin-has-attribute-4.c: Same. * c-c++-common/builtin-has-attribute-5.c: New test. * gcc.target/aarch64/attr-aligned.c: Same. * gcc.target/i386/attr-aligned.c: Same. * gcc.target/powerpc/attr-aligned.c: Same. * gcc.target/sparc/attr-aligned.c: Same. Added: trunk/gcc/testsuite/c-c++-common/builtin-has-attribute-5.c trunk/gcc/testsuite/gcc.dg/attr-aligned-2.c trunk/gcc/testsuite/gcc.target/aarch64/attr-aligned.c trunk/gcc/testsuite/gcc.target/i386/attr-aligned.c trunk/gcc/testsuite/gcc.target/powerpc/attr-aligned.c trunk/gcc/testsuite/gcc.target/sparc/attr-aligned.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-attribs.c trunk/gcc/c-family/c-common.c trunk/gcc/c/ChangeLog trunk/gcc/c/c-decl.c trunk/gcc/doc/extend.texi trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/builtin-has-attribute-2.c trunk/gcc/testsuite/c-c++-common/builtin-has-attribute-3.c trunk/gcc/testsuite/c-c++-common/builtin-has-attribute-4.c trunk/gcc/testsuite/gcc.dg/builtin-has-attribute.c
[Bug testsuite/88208] new test case c-c++-common/builtin-has-attribute-3.c in r266335 has multiple excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88208 --- Comment #3 from Martin Sebor --- Author: msebor Date: Thu Nov 29 17:48:58 2018 New Revision: 266633 URL: https://gcc.gnu.org/viewcvs?rev=266633&root=gcc&view=rev Log: PR c/88172 - attribute aligned of zero silently accepted but ignored PR testsuite/88208 - new test case c-c++-common/builtin-has-attribute-3.c in r266335 has multiple excess errors gcc/ChangeLog: PR c/88172 PR testsuite/88208 * doc/extend.texi (attribute constructor): Clarify. gcc/c/ChangeLog: PR c/88172 PR testsuite/88208 * c-decl.c (declspec_add_alignas): Adjust call to check_user_alignment. gcc/c-family/ChangeLog: PR c/88172 PR testsuite/88208 * c-attribs.c (common_handle_aligned_attribute): Silently avoid setting alignments to values less than the target requires. (has_attribute): For attribute aligned consider both the attribute and the alignment bits. * c-common.c (c_init_attributes): Optionally issue a warning for zero alignment. gcc/testsuite/ChangeLog: PR c/88172 PR testsuite/88208 * gcc.dg/attr-aligned-2.c: New test. * gcc.dg/builtin-has-attribute.c: Adjust. * c-c++-common/builtin-has-attribute-2.c: Same. * c-c++-common/builtin-has-attribute-3.c: Same. * c-c++-common/builtin-has-attribute-4.c: Same. * c-c++-common/builtin-has-attribute-5.c: New test. * gcc.target/aarch64/attr-aligned.c: Same. * gcc.target/i386/attr-aligned.c: Same. * gcc.target/powerpc/attr-aligned.c: Same. * gcc.target/sparc/attr-aligned.c: Same. Added: trunk/gcc/testsuite/c-c++-common/builtin-has-attribute-5.c trunk/gcc/testsuite/gcc.dg/attr-aligned-2.c trunk/gcc/testsuite/gcc.target/aarch64/attr-aligned.c trunk/gcc/testsuite/gcc.target/i386/attr-aligned.c trunk/gcc/testsuite/gcc.target/powerpc/attr-aligned.c trunk/gcc/testsuite/gcc.target/sparc/attr-aligned.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-attribs.c trunk/gcc/c-family/c-common.c trunk/gcc/c/ChangeLog trunk/gcc/c/c-decl.c trunk/gcc/doc/extend.texi trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/builtin-has-attribute-2.c trunk/gcc/testsuite/c-c++-common/builtin-has-attribute-3.c trunk/gcc/testsuite/c-c++-common/builtin-has-attribute-4.c trunk/gcc/testsuite/gcc.dg/builtin-has-attribute.c
[Bug testsuite/88208] new test case c-c++-common/builtin-has-attribute-3.c in r266335 has multiple excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88208 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.0 --- Comment #4 from Martin Sebor --- With r266633 the test failures should be gone.
