[Bug debug/86452] [8 Regression] ICE in force_decl_die, at dwarf2out.c:25922 with -g1 and -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86452 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Known to work||9.0 Target Milestone|--- |8.2 Summary|ICE in force_decl_die, at |[8 Regression] ICE in |dwarf2out.c:25922 with -g1 |force_decl_die, at |and -flto |dwarf2out.c:25922 with -g1 ||and -flto --- Comment #7 from Richard Biener --- Fixed on trunk sofar, I guess this is really a regression.
[Bug tree-optimization/86492] [8/9 Regression] store-merging wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86492 Umesh Kalappa changed: What|Removed |Added CC||umesh.kalappa0 at gmail dot com --- Comment #7 from Umesh Kalappa --- Thank you Jakub for the quick fix and as stated the patch works for reported case.
[Bug middle-end/86471] GCC/libstdc++ outputs inferior code for std::fill and std::fill_n vs std::memset on c-style arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86471 --- Comment #9 from Marc Glisse --- (In reply to Andrew Pinski from comment #7) > This is incorrect for floating point types Because of negative 0 I assume. > And it introduces an extra check at runtime if value is not known to compile > time. We could also use __builtin_constant_p, if the function is inlined often enough (don't know if it is). Best would still be to see if we can enable parts of ldist at -O2.
[Bug middle-end/86511] [9 Regression] Unordered comparisons are expanded with branchless code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86511 Richard Biener changed: What|Removed |Added Keywords||wrong-code Target||alpha Known to work||7.3.1 Target Milestone|--- |9.0 Summary|Unordered comparisons are |[9 Regression] Unordered |expanded with branchless|comparisons are expanded |code|with branchless code Known to fail||9.0 --- Comment #2 from Richard Biener --- What about GCC 8? Note that the middle-end thinks only SNaNs can cause UNGE_EXPR to trap which I belive is correct. It looks like this goes wrong somewhere in expansion which seems to expand this as UNORDERED || GE w/o protecting the GE properly. It looks like we do not have optabs for UNGE, but only unord_optab. I guess you need to trace expansion to see where it goes wrong (maybe it's just a bug in if-conversion...)
[Bug testsuite/86510] [9 regression] test case g++.dg/warn/pr86453.C fails starting with r262596
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86510 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.0
[Bug libgcc/86512] New: Incorrect sub result for float subnormal inputs in armv7(with -msoft-float).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86512 Bug ID: 86512 Summary: Incorrect sub result for float subnormal inputs in armv7(with -msoft-float). Product: gcc Version: 8.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: umesh.kalappa0 at gmail dot com Target Milestone: --- Created attachment 44389 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44389&action=edit input filename command used : arm-none-linux-gnueabi-gcc test.c -msoft-float -march=armv7 file test.c attached. expected o/p :0xf incorrect o/p:0xe with (-mhard-float) getting the expected o/p (with flush to zero mode disabled). while debugging the soft-float code,we see that ,the compiler calls the intrinsic "__aeabi_dsub" with arm calling conventions i.e passing "a" in r0 and r1 registers and respectively for "b" and we are investigating the routine "__aeabi_dsub" that comes from libgcc(libgcc/config/arm/ieee754-df.S) for incorrect result. any inputs from the community will be appreciated. thank you
[Bug tree-optimization/86259] [8/9 Regression] min(4, strlen(s)) optimized to strlen(s) with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86259 --- Comment #23 from Davin McCall --- (In reply to Martin Sebor from comment #22) > The test cases in this report are variations on this theme. [...] Ok, except that the one I posted in comment #21 specifically copies the string into a union member which is long enough to contain it, and while it takes the address of a subobject from the other union member, it does so while that member is active, and it casts to uintptr_t before subtracting the offset (so as to obtain a pointer to the containing object in a way that doesn't involve advancing a pointer beyond the bounds of the object it points into). It even casts this back to the union type before casting to (char *) again. At that stage it either: - points at the union object itself and its active member, which is a char[12], or - points at the union object but not its active member - points at the union object (and possibly its active member) but dereference is illegal due to provenance rules. The 3rd case would be greatly disturbing to myself and, I think, to many others; it would mean that you cannot meaningfully obtain a pointer to a containing object from a contained member other than the first one. The 1st case would mean that GCC is in error in compiling that code, since it gives the wrong result. Only the 2nd case avoids both those issues, but only if we allow that strlen on (part of) a non-char[] object has undefined behaviour even if the relevant portion of that object contains a suitably-sized char[] as a subobject in the relevant range. That seems tenuous and certainly not directly supported by the wording of the current specification, unless I've missed something.
[Bug c++/86216] g++ ICE on valid code: verify_ssa failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86216
Richard Biener changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 from Richard Biener ---
The interesting thing is that the RHS _1 is from a different function, a
SAVE_EXPR expansion actually, which means this is another case of
cross-function
tree sharing (I remember fixing such thing in the fortran FE).
Breakpoint 7, gimplify_save_expr (expr_p=0x76db3b18, pre_p=0x7fffd058,
post_p=0x7fffca98) at ../../src/trunk/gcc/gimplify.c:5870
5870 enum gimplify_status ret = GS_ALL_DONE;
$38 =
$39 =
...
Breakpoint 7, gimplify_save_expr (expr_p=0x76da3ab8, pre_p=0x7fffc658,
post_p=0x7fffc458) at ../../src/trunk/gcc/gimplify.c:5870
5870 enum gimplify_status ret = GS_ALL_DONE;
$42 =
$43 =
(gdb) p (*expr_p)->base.public_flag
$45 = 1
I guess we can track down at least the SAVE_EXPR case with
Index: gcc/gimplify.c
===
--- gcc/gimplify.c (revision 262624)
+++ gcc/gimplify.c (working copy)
@@ -869,7 +869,11 @@ copy_if_shared_r (tree *tp, int *walk_su
/* Otherwise, mark the node as visited and keep looking. */
else
-TREE_VISITED (t) = 1;
+{
+ if (TREE_CODE (t) == SAVE_EXPR)
+ gcc_assert (!SAVE_EXPR_RESOLVED_P (t));
+ TREE_VISITED (t) = 1;
+}
return NULL_TREE;
}
It's probably easy that this case of sharing happens for nested functions
since most type sizes are wrapped in SAVE_EXPRs and those do not get
unshared even when that is explicitely asked for.
But it looks like the tree sharing happens outside of a SAVE_EXPR given
we have at gimplify_function_tree time
{
intptr_t & n [value-expr: this->__n];
intptr_t & n [value-expr: this->__n];
{
<;
}
}
where _1 + 1 was what a SAVE_EXPR was resolved to but here we should have
seen the DECL created for it rather than the in-place gimplified result.
The .original dump though has
;; Function b(intptr_t, T) [with T = int; intptr_t =
int] (null)
;; enabled by -tree-original
{
intptr_t & n [value-expr: this->__n];
intptr_t & n [value-expr: this->__n];
{
<) + 1) * 4)) >;
}
}
it looks like there's tree sharing for a bigger part of the expression...
Indeed, between the above and
{
intptr_t & n [value-expr: this->__n];
intptr_t & n [value-expr: this->__n];
{
{
typedef struct __lambda3 __lambda3;
<) + 1) * 4)) >;
;
}
}
}
we have shared
arg:0
side-effects
arg:0
side-effects
arg:0
side-effects arg:0
t.ii:3:22 start: t.ii:3:22 finish: t.ii:3:26>>
arg:1 >>
which is the (sizetype) (SAVE_EXPR <(ssizetype) arg + -1>) + 1 part.
unit-size
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x76c5b7e0 precision:64 min max
pointer_to_this >
side-effects
arg:0 unit-size
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x76c5b000 precision:64 min max >
side-effects
arg:0
side-effects
these nodes are built by c_sizeof_or_alignof_type
#4 0x00bde3e2 in c_sizeof_or_alignof_type (loc=283249,
type=, is_sizeof=true, min_alignof=false,
complain=1) at ../../src/trunk/gcc/c-family/c-common.c:3650
3650 value = fold_convert_loc (loc, size_type_node, value);
where TYPE_SIZE_UNIT of type is
((sizetype) (SAVE_EXPR <(ssizetype) arg - 1>) + 1) * 4
which is of course asking for trouble :/
In the end this is layout_type doing
2483if (TYPE_SIZE_UNIT (element))
2484 TYPE_SIZE_UNIT (type)
2485= size_binop (MULT_EXPR, TYPE_SIZE_UNIT (element),
length);
on (sizetype) (SAVE_EXPR <(ssizetype) arg - 1>) + 1
The gimplifier is not set up to do unsharing across functions, so this has
to be fixed elsewhere. The particular case could be fixed in
c_sizeof_or_alignof_type by doing unshare_expr on TYPE_SIZE_UNIT for all
types that might be shared between functions (thus where the gimplifier
doesn't take care of unsharing).
Or we could make layout_type make sure to wrap all non-constant TYPE_*
in a SAVE_EXPR.
So the following patch restores the ICE we see in earlier releases.
I have audited all possibly variable-size processing in c-common.c.
Any comments?
Index: gcc/c-family/c-common.c
===
--- gcc/c-family/c-common.c (revision 262624)
+++ gcc/c-family/c-common.c (working copy)
@@ -3635,7 +3635,8 @@ c_sizeof_or_alignof_type (location_t loc
{
if (
[Bug c++/86216] g++ ICE on valid code: verify_ssa failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86216 Richard Biener changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #4 from Richard Biener --- And the original expansion bug simply says we're not getting function nesting /unnesting correct. The D.2371 local (what the SAVE_EXPR resolves to in the outer function) needs to be pulled from the static chain but I do not see any. In fact the middle-end isn't presented with nested functions at all but it looks like the C++ FE does lambdas in its own way but forgets about cross-"function/lambda" SAVE_EXPRs? I'm out-of-the way for that C++ FE issue. Maybe it doesn't want to share the SAVE_EXPRs in the end. Who knows.
[Bug c++/86216] g++ ICE on valid code: verify_ssa failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86216
--- Comment #5 from Jakub Jelinek ---
I guess lambdas really need to have all the needed parameters captured, and for
VLAs that likely includes not just the VLAs themselves, but their sizes as
well.
That is something that needs to be done in the FE somewhere, because lambdas
are handled only at that point. Wonder if that means also creating another set
of the VLA types for the lambda with TYPE_SIZE{,_UNIT} that map to an
artificial field and that the capturing code initializes it with the
TYPE_SIZE{,_UNIT} (i.e. the SAVE_EXPR it has). For normal nested functions (C
or Fortran) this is tree-nested.c's job and I think we handle it there already
right, because it is after gimplification and so the needed vars are exposed.
Or reject capturing VLAs (with a sorry) until that is done.
[Bug middle-end/86202] [8/9 Regression] ICE in get_range_info calling an invalid memcpy() declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86202 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- Marek, do you plan to backport this? 8.2 rc1 is tentatively planned for next week...
[Bug libstdc++/86507] std::filesystem not work on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86507 --- Comment #4 from tower120 --- > Are you sure about that? You might be able to include the header, but nothing > else works. "Everything" that I use, which is: * std::experimental::filesystem::path (construction, c_str, comparison) * std::experimental::filesystem::file_size This work in mingw-w64 gcc 7.1 with "stdc++fs".
[Bug c++/86495] [8/9 Regression] false no return statement warning in "if constexpr" branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86495 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Jakub Jelinek --- Dup. *** This bug has been marked as a duplicate of bug 85842 ***
[Bug c++/85842] [8/9 Regression] Bogus -Wreturn-type with generic lambda and constexpr if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85842 Jakub Jelinek changed: What|Removed |Added CC||tower120 at gmail dot com --- Comment #5 from Jakub Jelinek --- *** Bug 86495 has been marked as a duplicate of this bug. ***
[Bug debug/86064] [8/9 Regression] compiling Linux kernel: Error: can't resolve `.text.unlikely' {.text.unlikely section} - `.LVL43x' {.text section}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86064 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |FIXED --- Comment #13 from Jakub Jelinek --- Assuming fixed.
[Bug middle-end/86511] [9 Regression] Unordered comparisons are expanded with branchless code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86511 --- Comment #3 from Uroš Bizjak --- (In reply to Richard Biener from comment #2) > It looks like this goes wrong somewhere in expansion which seems to expand > this as UNORDERED || GE w/o protecting the GE properly. It looks like we > do not have optabs for UNGE, but only unord_optab. > > I guess you need to trace expansion to see where it goes wrong (maybe > it's just a bug in if-conversion...) This happens in expmed.c, emit_store flag, where the comparison is split using split_comparison (from dojump.c) to first_code and code. Following the split, we get to: /* Try using a setcc instruction for ORDERED/UNORDERED, followed by a conditional move. */ tem = emit_store_flag_1 (subtarget, first_code, op0, op1, mode, 0, normalizep, target_mode); if (tem == 0) return 0; if (and_them) tem = emit_conditional_move (target, code, op0, op1, mode, tem, const0_rtx, GET_MODE (tem), 0); else tem = emit_conditional_move (target, code, op0, op1, mode, trueval, tem, GET_MODE (tem), 0); which emits both comparisons via setcc and cmove. For example, UNGE gets split to UNORDERED and GE, the second one traps. I don't think the above is correct for trapping math.
[Bug libstdc++/86513] New: ostringstream default constructor missing from libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86513 Bug ID: 86513 Summary: ostringstream default constructor missing from libstdc++ Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: csaba_22 at yahoo dot co.uk Target Milestone: --- $ svn info ../trunk/ Path: ~/wk/GCC99/trunk Working Copy Root Path: ~/wk/GCC99/trunk URL: https://gcc.gnu.org/svn/gcc/trunk Relative URL: ^/trunk Repository Root: https://gcc.gnu.org/svn/gcc Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4 Revision: 262551 Node Kind: directory Schedule: normal Last Changed Author: rguenth Last Changed Rev: 262551 Last Changed Date: 2018-07-11 09:08:54 +0200 (Wed, 11 Jul 2018) After building and running 'make install' $ g++-99 -v 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 --no-create --no-recursion Thread model: posix gcc version 9.0.0 20180711 (experimental) (GCC) $ echo _ZNSt7__cxx1119basic_ostringstreamIcSt11char_traitsIcESaIcEEC1Ev@PLT | c++filt std::__cxx11::basic_ostringstream, std::allocator >::basic_ostringstream()@PLT $ $ nm /usr/local/lib/gcc/x86_64-pc-linux-gnu/9.0.0/libstdc++.so | grep _ZNSt7__cxx1119basic_ostringstreamIcSt11char_traitsIcESaIcEEC1Ev@PLT (no output) $ nm /usr/local/lib/gcc/x86_64-pc-linux-gnu/9.0.0/libstdc++.a | grep _ZNSt7__cxx1119basic_ostringstreamIcSt11char_traitsIcESaIcEEC1Ev@PLT (no output) $ nm /usr/local/lib/gcc/x86_64-pc-linux-gnu/9.0.0/libstdc++.a | grep _ZNSt7__cxx1119basic_ostringstreamIcSt11char_traitsIcESaIcEEC1E W _ZNSt7__cxx1119basic_ostringstreamIcSt11char_traitsIcESaIcEEC1EOS4_ W _ZNSt7__cxx1119basic_ostringstreamIcSt11char_traitsIcESaIcEEC1ERKNS_12basic_stringIcS2_S3_EESt13_Ios_Openmode W _ZNSt7__cxx1119basic_ostringstreamIcSt11char_traitsIcESaIcEEC1ESt13_Ios_Openmode GCC is currently unusable for any program trying to use ostringstream: I get a bunch of undefined reference to `std::__cxx11::basic_ostringstream, std::allocator >::basic_ostringstream()' errors.
[Bug middle-end/86511] [9 Regression] Unordered comparisons are expanded with branchless code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86511 --- Comment #4 from Uroš Bizjak --- This patch fixes inf-compare-[78].c testsuite failures on alphaev68 for me: --cut here-- diff --git a/gcc/expmed.c b/gcc/expmed.c index b01e1946898a..f114eb45e01f 100644 --- a/gcc/expmed.c +++ b/gcc/expmed.c @@ -6038,6 +6038,11 @@ emit_store_flag (rtx target, enum rtx_code code, rtx op0, rtx op1, if (!HAVE_conditional_move) return 0; + /* Do not turn a trapping comparison into a non-trapping one. */ + if ((code != EQ && code != NE && code != UNEQ && code != LTGT) + && flag_trapping_math) + return 0; + /* Try using a setcc instruction for ORDERED/UNORDERED, followed by a conditional move. */ tem = emit_store_flag_1 (subtarget, first_code, op0, op1, mode, 0, --cut here--
[Bug fortran/82617] Internal compiler error in expand_expr_real_1 when compiling the attached file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82617 --- Comment #10 from Ögmundur Petersson --- Thanks for the fix!
[Bug c++/86216] g++ ICE on valid code: verify_ssa failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86216
--- Comment #6 from rguenther at suse dot de ---
On Fri, 13 Jul 2018, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86216
>
> --- Comment #5 from Jakub Jelinek ---
> I guess lambdas really need to have all the needed parameters captured, and
> for
> VLAs that likely includes not just the VLAs themselves, but their sizes as
> well.
> That is something that needs to be done in the FE somewhere, because lambdas
> are handled only at that point. Wonder if that means also creating another
> set
> of the VLA types for the lambda with TYPE_SIZE{,_UNIT} that map to an
> artificial field and that the capturing code initializes it with the
> TYPE_SIZE{,_UNIT} (i.e. the SAVE_EXPR it has). For normal nested functions (C
> or Fortran) this is tree-nested.c's job and I think we handle it there already
> right, because it is after gimplification and so the needed vars are exposed.
Yeah, though the "new" issue is that while previously tree sharing between
nested functions and the respective locals that are defined in the wrong
function are resolved by unnesting (also the reason we need to gimplify
outer-to-inner and only lower nested functions after that) since we
are generating SSA temporaries we'll have cross-function SSA names for
such tree sharing. That isn't resolved by unnesting and this is what
the pasted patch snippet fixes also for non-lambdas.
I think that either the tree sharing is a bug or the gimplifier
woring in-place (and thus its need to unshare in the first place)
is the bug here.
The SSA temporaries by gimplification are new since GCC 7 so we
somehow didn't run into this before.
> Or reject capturing VLAs (with a sorry) until that is done.
Possibly, given VLAs are a GNU extension.
[Bug ada/86514] New: GCC/GNAT fails to optimize access to packed array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86514 Bug ID: 86514 Summary: GCC/GNAT fails to optimize access to packed array Product: gcc Version: 8.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: reznikmm at gmail dot com Target Milestone: --- Created attachment 44390 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44390&action=edit reproducer Description of problem: Ada compiler performs incorrect optimization of operations on a packed array of Booleans. Version-Release number of selected component: Initially I found this on Fedora 28 and its gcc 8.1.1: gcc version 8.1.1 20180502 (Red Hat 8.1.1-1) (GCC) RPM: gcc-gnat-8.1.1-1.fc28.x86_64 Then I checked gcc 9 snapshot 20180708 and it fails too. Configuration is: Target: x86_64-pc-linux-gnu Configured with: ../gcc-9-20180708/configure --enable-languages=c,c++,ada --prefix=/work/reznik/gcc/install --enable-shared --enable-threads=posix --disable-multilib Thread model: posix gcc version 9.0.0 20180708 (experimental) (GCC) How reproducible: * Compile and run attached code with optimization is on (-O1). * Without optimization (-O0) the example works well - without exception. Actual results: [max@4803f13cbde8 tmp]$ gnatmake -O1 ts_00021.adb gcc -c -O1 ts_00021.adb gnatbind -x ts_00021.ali gnatlink ts_00021.ali -O1 [max@4803f13cbde8 tmp]$ ./ts_00021 raised PROGRAM_ERROR : ts_00021.adb:30 explicit raise Expected results: No exception should be raised. Additional info: Fedora bug report https://bugzilla.redhat.com/show_bug.cgi?id=1600886
[Bug c++/86515] New: std::initializer_list constructor is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86515 Bug ID: 86515 Summary: std::initializer_list constructor is not a constant expression Product: gcc Version: 8.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: sliser at mail dot ru Target Milestone: ---
[Bug c++/86515] std::initializer_list constructor is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86515
--- Comment #1 from sliser at mail dot ru ---
struct A1
{
static constexpr auto SupportedVersions = {"1.1", "1.2", "1.3", "1.4"}; //
Ok
};
template
struct A2
{
static constexpr auto SupportedVersions = {"1.1", "1.2", "1.3", "1.4"}; //
Fails
};
error: ‘std::initializer_list{((const char*
const*)(&)), 4}’ is not a constant expression
static constexpr auto SupportedVersions = {"1.1", "1.2", "1.3", "1.4"};
[Bug ada/86514] [8/9 regression] wrong manipulation of 2-dimensional packed array at -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86514 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-07-13 CC||ebotcazou at gcc dot gnu.org Known to work||6.4.1, 7.3.1 Target Milestone|--- |8.2 Summary|GCC/GNAT fails to optimize |[8/9 regression] wrong |access to packed array |manipulation of ||2-dimensional packed array ||at -O Ever confirmed|0 |1 Known to fail||8.1.1, 9.0 --- Comment #1 from Eric Botcazou --- I can reproduce with 8.x and 9.x compilers.
[Bug ada/86514] [8/9 regression] wrong manipulation of 2-dimensional packed array at -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86514 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #2 from Eric Botcazou --- Investigating.
[Bug middle-end/85974] [8 Regression] Failure to optimize difference of two pointers into a compile time constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85974 Richard Biener changed: What|Removed |Added Known to work||9.0 Summary|[8/9 Regression] Failure to |[8 Regression] Failure to |optimize difference of two |optimize difference of two |pointers into a compile |pointers into a compile |time constant |time constant Known to fail||8.1.0 --- Comment #5 from Richard Biener --- Fixed on trunk sofar.
[Bug middle-end/85974] [8 Regression] Failure to optimize difference of two pointers into a compile time constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85974 --- Comment #6 from Richard Biener --- Author: rguenth Date: Fri Jul 13 11:25:38 2018 New Revision: 262632 URL: https://gcc.gnu.org/viewcvs?rev=262632&root=gcc&view=rev Log: 2018-07-13 Richard Biener PR middle-end/85974 * match.pd (addr1 - addr2): Allow either of the operand to have a conversion. * gcc.c-torture/compile/930326-1.c: Adjust to cover widening. Modified: trunk/gcc/ChangeLog trunk/gcc/match.pd trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.c-torture/compile/930326-1.c
[Bug lto/69866] lto1: internal compiler error: in add_symbol_to_partition_1, at lto/lto-partition.c:158
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69866 --- Comment #16 from Thomas Preud'homme --- @honza: would you mind backporting to GCC 7? IIRW GCC 6 backport is more tricky. Thanks!
[Bug c++/86216] g++ ICE on valid code: verify_ssa failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86216
--- Comment #7 from Richard Biener ---
I can't fully reproduce the obfuscation of the C++ FE (the +-1) but the
following is close but it also works:
typedef int intptr_t;
void foo (intptr_t n, unsigned a)
{
typedef intptr_t ArrTy[(long)a+1];
ArrTy buffer2;
ArrTy buffer1[(long)a+1];
void bar ()
{
n = sizeof(buffer1[n]);
void baz()
{
n = sizeof(buffer2);
}
baz();
}
bar();
}
and it has similar gimplification (but not broken):
foo (intptr_t n, unsigned int a)
{
...
_1 = (long int) a;
D.1910 = _1 + 1;
bar ()
{
static void baz ();
_1 = (unsigned int) D.1910;
_2 = _1 * 4;
n = (intptr_t) _2;
baz ();
}
baz ()
{
_1 = (unsigned int) D.1910;
_2 = _1 * 4;
n = (intptr_t) _2;
}
without the array size adjustment I get the SAVE_EXPR only wrapping a, so some
promotion done by the C++ FE ends up breaking things.
[Bug c++/86216] g++ ICE on valid code: verify_ssa failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86216 --- Comment #8 from Richard Biener --- The C FE does /* Arrange for the SAVE_EXPR on the inside of the MINUS_EXPR, which allows the -1 to get folded with the +1 that happens when building TYPE_SIZE. */ if (size_varies) size = save_expr (size); while the C++ FE relies on variable_size() after building the whole expression. Eliding the above optimization makes the IL more similar but it still doesn't break.
[Bug libstdc++/86516] New: Spurious warning __builtin_memset at O3 when protected by a conditional involving empty()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86516 Bug ID: 86516 Summary: Spurious warning __builtin_memset at O3 when protected by a conditional involving empty() Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: paulg at chiark dot greenend.org.uk Target Milestone: --- This is spurious diagnostic regression in GCC 7 and beyond and is related to two previous bugs. The first one was was 82698 which was resolved as a duplicate of 88641. However the workaround applied for 88641 is not complete and does not solve the problem. The issue is that at O3 if you do std::vector v; if(c.size() > 0) c.resize(c.size() - 1); then you no longer get a spurious builtin memset warning in 7.3 however if instead you do if(! c.empty()) c.resize(c.size() -1); it produces an erroneous warning. The fundamental problem is a dataflow analysis issue which is somewhat difficult to fix. In 88641 decorations were added to libstdc++ to avoid the warning however they seem to have only been added to size() not empty() so the 2nd form of code above still produces a spurious warning.
[Bug tree-optimization/86489] ICE in gimple_phi_arg starting with r261682 when building 531.deepsjeng_r with FDO + LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86489 Pat Haugen changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #8 from Pat Haugen --- Fixed, thanks.
[Bug tree-optimization/85804] [8/9 Regression][AArch64] Mis-compilation of loop with strided array access and xor reduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85804 --- Comment #3 from Ramana Radhakrishnan --- (In reply to Ramana Radhakrishnan from comment #2) > Patch being discussed here. > https://gcc.gnu.org/ml/gcc-patches/2018-05/msg01026.html Bin are you still working on this ?
[Bug middle-end/86202] [8/9 Regression] ICE in get_range_info calling an invalid memcpy() declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86202 --- Comment #8 from Marek Polacek --- Author: mpolacek Date: Fri Jul 13 13:36:35 2018 New Revision: 262635 URL: https://gcc.gnu.org/viewcvs?rev=262635&root=gcc&view=rev Log: PR middle-end/86202 * gimple-fold.c (size_must_be_zero_p): Check the type of the size. * gcc.dg/Wint-conversion-2.c: New test. Added: branches/gcc-8-branch/gcc/testsuite/gcc.dg/Wint-conversion-2.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/gimple-fold.c
[Bug middle-end/86202] [8/9 Regression] ICE in get_range_info calling an invalid memcpy() declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86202 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|mpolacek at gcc dot gnu.org|unassigned at gcc dot gnu.org --- Comment #9 from Marek Polacek --- Done, but there might be more to do; unassigning.
[Bug lto/86517] New: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86517
Bug ID: 86517
Summary: relocation R_X86_64_32 against `.rodata.str1.1' can
not be used when making a shared object with LTO
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org
Target Milestone: ---
When mixing PIE and PIC one gets:
$ cat 1.i
int key_thread_attempt_id ;
int main() {
}
$ cat 2.i
void get_ioctl_ops();
void a() {
get_ioctl_ops();
}
$ cat lib.i
void open_fd(char *);
void init_ioctl_ctl() { open_fd(""); }
void get_ioctl_ops() {}
$ gcc -flto -c -fPIE -O2 1.i 2.i && gcc -fPIC -c -O2 lib.i -flto && ar rv x.a
lib.o && gcc -pie -O2 -pthread -ldl -lxml2 1.o 2.o x.a -rdynamic -flto=9
-shared
r - lib.o
/usr/lib64/gcc/x86_64-suse-linux/8/../../../../x86_64-suse-linux/bin/ld:
/tmp/cctTbHed.ltrans0.ltrans.o: relocation R_X86_64_32 against `.rodata.str1.1'
can not be used when making a shared object; recompile with -fPIC
/usr/lib64/gcc/x86_64-suse-linux/8/../../../../x86_64-suse-linux/bin/ld: final
link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
Without LTO it works fine:
$ gcc -c -fPIE -O2 1.i 2.i && gcc -fPIC -c -O2 lib.i && ar rv x.a lib.o && gcc
-pie -O2 -pthread -ldl -lxml2 1.o 2.o x.a -rdynamic -shared
Note that usage -shared is trick how I was able to reduce number of object
files. But original test-case does not use it.
[Bug middle-end/78809] Inline strcmp with small constant strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809 --- Comment #36 from qinzhao at gcc dot gnu.org --- the 3rd part (the last part) of this PR was checked into GCC 9 today as: https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=262636
[Bug middle-end/78809] Inline strcmp with small constant strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809 --- Comment #37 from qinzhao at gcc dot gnu.org --- since all the implementation were in trunk. can I close this PR now?
[Bug middle-end/78809] Inline strcmp with small constant strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809 --- Comment #38 from Wilco --- (In reply to qinzhao from comment #37) > since all the implementation were in trunk. > can I close this PR now? Thanks, it generates pretty much what I expected for t1. However there is an issue: t1: ldrsb w1, [x0] subsw1, w1, #97 bne .L68 ldrsb w1, [x0, 1] .L68: mov w0, w1 ret This uses signed char while the C standard says the comparison is done on unsigned chars.
[Bug c++/86374] [8/9 regression] template member name lookup problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86374 --- Comment #2 from Nathan Sidwell --- Author: nathan Date: Fri Jul 13 15:33:27 2018 New Revision: 262637 URL: https://gcc.gnu.org/viewcvs?rev=262637&root=gcc&view=rev Log: [PR c++/86374] Name lookup failure in enclosing template https://gcc.gnu.org/ml/gcc-patches/2018-07/msg00701.html PR c++/86374 * pt.c (lookup_template_class_1): Use tsubst_aggr_type for contexts that are classes. * parser.c (cp_parser_template_id): Combine entering_scope decl & initializer. PR c++/86374 * g++.dg/pr86374.C: New. Added: trunk/gcc/testsuite/g++.dg/pr86374.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug debug/86455] var-tracking mishandles pre_dec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86455
--- Comment #2 from Tom de Vries ---
Created attachment 44391
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44391&action=edit
Reproducer patch, splits push
Reproduced without the fkeep-vars-live patch.
Consider this test-case:
...
static volatile int vv = 1;
static volatile int z;
static long __attribute__((noinline, noclone))
foo (long x)
{
z = x;
}
int
main ()
{
long x = vv;
foo (x);
foo (x + 1);
return 0;
}
...
which at -O1 -g -fpeephole2 contains a pushq at the start of main:
...
.cfi_startproc
pushq %rbx
.cfi_def_cfa_offset 16
.cfi_offset 3, -16
...
Using this debug patch:
...
diff --git a/gcc/var-tracking.c b/gcc/var-tracking.c
index 8e800960b6d..0a2ac16b914 100644
--- a/gcc/var-tracking.c
+++ b/gcc/var-tracking.c
@@ -10213,7 +10213,11 @@ vt_initialize (void)
}
cselib_hook_called = false;
+ fprintf (stderr, "ORIGINAL: \n");
+ debug_rtx (insn);
adjust_insn (bb, insn);
+ fprintf (stderr, "ADJUSTED: \n");
+ debug_rtx (insn);
if (DEBUG_MARKER_INSN_P (insn))
{
reemit_marker_as_note (insn);
...
we can observe the var-tracking translation of the push:
...
ORIGINAL:
(insn/f 26 3 27 2 (set (mem:DI (pre_dec:DI (reg/f:DI 7 sp)) [0 S8 A8])
(reg:DI 3 bx)) "clztest.c":12 61 {*pushdi2_rex64}
(expr_list:REG_DEAD (reg:DI 3 bx)
(nil)))
ADJUSTED:
(insn/f 26 3 27 2 (parallel [
(set (mem:DI (plus:DI (reg/f:DI 16 argp)
(const_int -24 [0xffe8])) [0 S8 A8])
(reg:DI 3 bx))
(set (reg/f:DI 7 sp)
(plus:DI (reg/f:DI 16 argp)
(const_int -24 [0xffe8])))
]) "clztest.c":12 61 {*pushdi2_rex64}
(expr_list:REG_DEAD (reg:DI 3 bx)
(nil)))
...
Now, using the reproducer patch, we split up the push:
...
.cfi_startproc
leaq-8(%rsp), %rsp
.cfi_def_cfa_offset 16
movq%rbx, (%rsp)
.cfi_offset 3, -16
...
and once more observe the var-tracking translation, now of the split up push:
...
ORIGINAL:
(insn/f 34 3 35 2 (set (reg/f:DI 7 sp)
(plus:DI (reg/f:DI 7 sp)
(const_int -8 [0xfff8]))) "clztest.c":12 228 {*leadi}
(nil))
ADJUSTED:
(insn/f 34 3 35 2 (set (reg/f:DI 7 sp)
(plus:DI (reg/f:DI 16 argp)
(const_int -16 [0xfff0]))) "clztest.c":12 228 {*leadi}
(nil))
ORIGINAL:
(insn/f 35 34 27 2 (set (mem:DI (reg/f:DI 7 sp) [0 S8 A8])
(reg:DI 3 bx)) "clztest.c":12 85 {*movdi_internal}
(nil))
ADJUSTED:
(insn/f 35 34 27 2 (set (mem:DI (plus:DI (reg/f:DI 16 argp)
(const_int -16 [0xfff0])) [0 S8 A8])
(reg:DI 3 bx)) "clztest.c":12 85 {*movdi_internal}
(nil))
...
Interestingly, the argp offset changed from -24 to -16.
[Bug middle-end/78809] Inline strcmp with small constant strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809 --- Comment #39 from Qing Zhao --- > --- Comment #38 from Wilco --- > This uses signed char while the C standard says the comparison is done on > unsigned chars. > during my implementation, I did some research on whether I should use “unsigned char” or “signed char” for the comparison. what I checked was man page of strcmp, memcmp, (I don’t have C standard in hand). in the manpage of memcmp, it clearly and explicitly mentioned that the chars are interpreted as unsigned char; however, in the manpage of strcmp/strncmp, it’s not mentioned at all. So, I thought that for strcmp/strncmp, I should use signed char. but for memcmp, I used unsigned char. since I don’t have a C standard, could you please point me the corresponding section for this? thanks.
[Bug middle-end/78809] Inline strcmp with small constant strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809 --- Comment #40 from Wilco --- (In reply to Qing Zhao from comment #39) > > --- Comment #38 from Wilco --- > > This uses signed char while the C standard says the comparison is done on > > unsigned chars. > > > > during my implementation, I did some research on whether I should use > “unsigned char” or “signed char” > for the comparison. what I checked was man page of strcmp, memcmp, (I don’t > have C standard in hand). > in the manpage of memcmp, it clearly and explicitly mentioned that the chars > are interpreted as unsigned char; > however, in the manpage of strcmp/strncmp, it’s not mentioned at all. So, I > thought that for strcmp/strncmp, > I should use signed char. but for memcmp, I used unsigned char. > > since I don’t have a C standard, could you please point me the corresponding > section for this? > thanks. See eg. http://www.iso-9899.info/n1570.html section 7.24.4: "The sign of a nonzero value returned by the comparison functions memcmp, strcmp, and strncmp is determined by the sign of the difference between the values of the first pair of characters (both interpreted as unsigned char) that differ in the objects being compared."
[Bug middle-end/78809] Inline strcmp with small constant strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809 --- Comment #41 from Qing Zhao --- > --- Comment #40 from Wilco --- > See eg. http://www.iso-9899.info/n1570.html section 7.24.4: > > "The sign of a nonzero value returned by the comparison functions memcmp, > strcmp, and strncmp is determined by the sign of the difference between the > values of the first pair of characters (both interpreted as unsigned char) > that > differ in the objects being compared." Thanks. I will provide a small patch to fix this issue soon.
[Bug tree-optimization/86514] [8/9 regression] wrong manipulation of 2-dimensional packed array at -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86514 Eric Botcazou changed: What|Removed |Added Component|ada |tree-optimization --- Comment #3 from Eric Botcazou --- This comes from the reassoc pass.
[Bug bootstrap/86518] New: Strengthen bootstrap comparison by not enabling warnings at stage3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86518 Bug ID: 86518 Summary: Strengthen bootstrap comparison by not enabling warnings at stage3 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: amonakov at gcc dot gnu.org Target Milestone: --- Currently stage2 and 3 use the same warning options, but that is redundant: if any warnings are generated, they will be present at stage2 (and stop bootstrap). By not enabling any warnings for stage3, we would get checking that warnings do not affect code generation. Note that simply adding -w at stage3 doesn't work, as it simply suppresses the warning at print time. I tried leaving only -Wno-narrowing in warning flags and got many comparison failures: Comparing stages 2 and 3 warning: gcc/cc1obj-checksum.o differs Bootstrap comparison failure! gcc/calls.o differs gcc/dwarf2out.o differs gcc/loop-iv.o differs gcc/generic-match.o differs gcc/ipa-inline.o differs gcc/builtins.o differs gcc/optabs.o differs gcc/tree-vrp.o differs gcc/profile.o differs gcc/i386.o differs gcc/cfgexpand.o differs gcc/simplify-rtx.o differs gcc/gimple-ssa-sprintf.o differs gcc/expr.o differs gcc/print-tree.o differs gcc/gimple-match.o differs gcc/godump.o differs gcc/gimple-ssa-nonnull-compare.o differs gcc/targhooks.o differs gcc/tree-ssa-live.o differs gcc/gimple-ssa-warn-restrict.o differs gcc/tree-ssa-ccp.o differs gcc/gimplify.o differs gcc/tree-cfg.o differs gcc/tree-pretty-print.o differs make: *** [compare] Error 1
[Bug c++/86374] [8/9 regression] template member name lookup problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86374 --- Comment #3 from Nathan Sidwell --- Author: nathan Date: Fri Jul 13 16:46:08 2018 New Revision: 262639 URL: https://gcc.gnu.org/viewcvs?rev=262639&root=gcc&view=rev Log: [PR c++/86374] Name lookup failure in enclosing template https://gcc.gnu.org/ml/gcc-patches/2018-07/msg00701.html PR c++/86374 * pt.c (lookup_template_class_1): Use tsubst_aggr_type for contexts that are classes. PR c++/86374 * g++.dg/pr86374.C: New. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/pr86374.C Modified: branches/gcc-8-branch/gcc/cp/ChangeLog branches/gcc-8-branch/gcc/cp/pt.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug c++/86374] [8/9 regression] template member name lookup problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86374 Nathan Sidwell changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Nathan Sidwell --- Fixed trunk & gcc-8
[Bug lto/86490] lto1: fatal error: multiple prevailing defs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86490 --- Comment #10 from zenith432 at users dot sourceforge.net --- Followup on what gold does... First, it reads the symbol table from the archive (w/o using the plugin) - and if it doesn't need any of the symbols in an LTO member of the archive - it doesn't call the plugin's claim_file_handler on the member. Second, even if it needs an LTO member from an archive - it first adds all the LTO object's symbols to its own symbol table during the add_symbols callback from the plugin. For each symbol, it remembers which object file it first was seen in and whether that first object file is claimed by a plugin. Later, when get_symbols callback is called from the plugin to get resolutions - it sets LDPR_PREVAILING_DEF_IRONLY for symbols it doesn't need, but only if the symbol was first seen in the same object file. If it was first seen in another object file, it sets the resolution to either LDPR_PREEMPTED_IR or LDPR_PREEMPTED_REG, depending on whether the symbol's first source is claimed by a plugin or not. This algorithm makes sure each IRONLY symbol only gets a single PREVAILING_DEF.
[Bug libstdc++/86516] Spurious warning __builtin_memset at O3 when protected by a conditional involving empty()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86516 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||msebor at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Martin Sebor --- Bug 80641 is still open and we are aware that the workaround no longer suppresses the warning. I don't think we need a separate bug to keep track of it. *** This bug has been marked as a duplicate of bug 80641 ***
[Bug tree-optimization/80641] missed optimization with with std::vector resize in loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80641 --- Comment #11 from Martin Sebor --- *** Bug 86516 has been marked as a duplicate of this bug. ***
[Bug debug/86455] var-tracking mishandles pre_dec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86455
--- Comment #3 from Tom de Vries ---
Hmm, even more obvious. We push bx to argp - 24:
...
ORIGINAL:
(insn/f 26 3 27 2 (set (mem:DI (pre_dec:DI (reg/f:DI 7 sp)) [0 S8 A8])
(reg:DI 3 bx)) "clztest.c":12 61 {*pushdi2_rex64}
(expr_list:REG_DEAD (reg:DI 3 bx)
(nil)))
ADJUSTED:
(insn/f 26 3 27 2 (parallel [
(set (mem:DI (plus:DI (reg/f:DI 16 argp)
(const_int -24 [0xffe8])) [0 S8 A8])
(reg:DI 3 bx))
(set (reg/f:DI 7 sp)
(plus:DI (reg/f:DI 16 argp)
(const_int -24 [0xffe8])))
]) "clztest.c":12 61 {*pushdi2_rex64}
(expr_list:REG_DEAD (reg:DI 3 bx)
(nil)))
...
but pop bx from argp - 16:
...
ORIGINAL:
(insn/f 29 28 30 2 (set (reg:DI 3 bx)
(mem:DI (post_inc:DI (reg/f:DI 7 sp)) [0 S8 A8])) "clztest.c":17 71
{*popdi1}
(expr_list:REG_CFA_ADJUST_CFA (set (reg/f:DI 7 sp)
(plus:DI (reg/f:DI 7 sp)
(const_int 8 [0x8])))
(nil)))
ADJUSTED:
(insn/f 29 28 30 2 (parallel [
(set (reg:DI 3 bx)
(mem:DI (plus:DI (reg/f:DI 16 argp)
(const_int -16 [0xfff0])) [0 S8 A8]))
(set (reg/f:DI 7 sp)
(plus:DI (reg/f:DI 16 argp)
(const_int -8 [0xfff8])))
]) "clztest.c":17 71 {*popdi1}
(expr_list:REG_CFA_ADJUST_CFA (set (reg/f:DI 7 sp)
(plus:DI (reg/f:DI 7 sp)
(const_int 8 [0x8])))
(nil)))
...
[Bug lto/86490] lto1: fatal error: multiple prevailing defs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86490 --- Comment #11 from H.J. Lu --- (In reply to zenith432 from comment #10) > Followup on what gold does... This is a gold bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23411
[Bug lto/86490] lto1: fatal error: multiple prevailing defs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86490 --- Comment #12 from zenith432 at users dot sourceforge.net --- Fair enough, it's a gold bug in the sense that gold's algorithm for selecting a prevailing def among multiple defs has an error. If an IR symbol has multiple definitions as LDPK_COMMON and a single definition as LDPK_DEF then the one marked as LDPK_DEF should be resolved as LDPR_PREVAILING_DEF_IRNONLY and the other defintions as PREEMPTED_IR. However, the limitation of a single prevailing def is documented... http://gcc.gnu.org/wiki/whopr/driver In the subsection The "All Symbols Read" Event "In the case of a symbol that is defined in more than one IR file, WPA will need to know which definition to use and which definitions to ignore." Logically, it is the linker's job to make this decision, because the prevailing def depends on the order that object files are given on the command line, on whether the object file has to be included in the link (i.e. it's on the command line) - or it's in a library and is optional. And also on whether it's a common def or not. lto1 cannot make this decision by itself. It is not possible to leave multiple prevailing defs for lto1 just because the linker doesn't need the symbol and considers it discardable - because an IR symbol may be referenced from inside the IR by another part needed in the link. In that case lto1 will need to generate the multiply defined symbol, and can't decide which one to use - for example because it doesn't know the order of the object files in the libraries given on the linker command line.
[Bug lto/86490] lto1: fatal error: multiple prevailing defs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86490 --- Comment #13 from H.J. Lu --- (In reply to zenith432 from comment #12) > Fair enough, it's a gold bug in the sense that gold's algorithm for > selecting a prevailing def among multiple defs has an error. > If an IR symbol has multiple definitions as > LDPK_COMMON > and a single definition as > LDPK_DEF > then the one marked as LDPK_DEF should be resolved as > LDPR_PREVAILING_DEF_IRNONLY and the other defintions as PREEMPTED_IR. > > However, the limitation of a single prevailing def is documented... > http://gcc.gnu.org/wiki/whopr/driver > In the subsection > The "All Symbols Read" Event > "In the case of a symbol that is defined in more than one IR file, WPA will > need to know which definition to use and which definitions to ignore." > > Logically, it is the linker's job to make this decision, because the > prevailing def depends on the order that object files are given on the > command line, on whether the object file has to be included in the link > (i.e. it's on the command line) - or it's in a library and is optional. And > also on whether it's a common def or not. lto1 cannot make this decision by > itself. > > It is not possible to leave multiple prevailing defs for lto1 just because > the linker doesn't need the symbol and considers it discardable - because an > IR symbol may be referenced from inside the IR by another part needed in the > link. In that case lto1 will need to generate the multiply defined symbol, > and can't decide which one to use - for example because it doesn't know the > order of the object files in the libraries given on the linker command line. But the symbol in question won't be USED by lto1 at all.
[Bug testsuite/86519] New: New test case gcc.dg/strcmpopt_6.c fails with its introduction in r262636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519 Bug ID: 86519 Summary: New test case gcc.dg/strcmpopt_6.c fails with its introduction in r262636 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- make -k check-gcc RUNTESTFLAGS=dg.exp=gcc.dg/strcmpopt_6.c . . . Setting LD_LIBRARY_PATH to :/home/seurer/gcc/build/gcc-test2/gcc::/home/seurer/gcc/build/gcc-test2/gcc:/home/seurer/gcc/build/gcc-test2/./gmp/.libs:/home/seurer/gcc/build/gcc-test2/./prev-gmp/.libs:/home/seurer/gcc/build/gcc-test2/./mpfr/src/.libs:/home/seurer/gcc/build/gcc-test2/./prev-mpfr/src/.libs:/home/seurer/gcc/build/gcc-test2/./mpc/src/.libs:/home/seurer/gcc/build/gcc-test2/./prev-mpc/src/.libs:/home/seurer/gcc/build/gcc-test2/./isl/.libs:/home/seurer/gcc/build/gcc-test2/./prev-isl/.libs:/home/seurer/gcc/install/gcc-7.2.0/lib64 Execution timeout is: 300 spawn [open ...] PASS: gcc.dg/strcmpopt_6.c execution test gcc.dg/strcmpopt_6.c: pattern found 0 times FAIL: gcc.dg/strcmpopt_6.c scan-rtl-dump-times expand "__builtin_memcmp" 4 testcase /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/dg.exp completed in 0 seconds === gcc Summary === # of expected passes2 # of unexpected failures1
[Bug target/84413] [8/9 Regression] -mtune=skylake,skylake-avx512,cannonlake,icelake disable many optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84413
--- Comment #5 from hjl at gcc dot gnu.org ---
Author: hjl
Date: Fri Jul 13 20:25:57 2018
New Revision: 262649
URL: https://gcc.gnu.org/viewcvs?rev=262649&root=gcc&view=rev
Log:
x86: Tune Skylake, Cannonlake and Icelake as Haswell
r259399, which added PROCESSOR_SKYLAKE, disabled many x86 optimizations
which are enabled by PROCESSOR_HASWELL. As the result, -mtune=skylake
generates slower codes on Skylake than before. The same also applies
to Cannonlake and Icelak tuning.
This patch changes -mtune={skylake|cannonlake|icelake} to tune like
-mtune=haswell for until their tuning is properly adjusted. It also
enables -mprefer-vector-width=256 for -mtune=haswell, which has no
impact on codegen when AVX512 isn't enabled.
Performance impacts on SPEC CPU 2017 rate with 1 copy using
-march=native -mfpmath=sse -O2 -m64
are
1. On Broadwell server:
500.perlbench_r -0.56%
502.gcc_r -0.18%
505.mcf_r 0.24%
520.omnetpp_r 0.00%
523.xalancbmk_r -0.32%
525.x264_r -0.17%
531.deepsjeng_r 0.00%
541.leela_r 0.00%
548.exchange2_r 0.12%
557.xz_r0.00%
Geomean 0.00%
503.bwaves_r0.00%
507.cactuBSSN_r 0.21%
508.namd_r 0.00%
510.parest_r0.19%
511.povray_r-0.48%
519.lbm_r 0.00%
521.wrf_r 0.28%
526.blender_r 0.19%
527.cam4_r 0.39%
538.imagick_r 0.00%
544.nab_r -0.36%
549.fotonik3d_r 0.51%
554.roms_r 0.00%
Geomean 0.17%
On Skylake client:
500.perlbench_r 0.96%
502.gcc_r 0.13%
505.mcf_r -1.03%
520.omnetpp_r -1.11%
523.xalancbmk_r 1.02%
525.x264_r 0.50%
531.deepsjeng_r 2.97%
541.leela_r 0.50%
548.exchange2_r -0.95%
557.xz_r2.41%
Geomean 0.56%
503.bwaves_r0.49%
507.cactuBSSN_r 3.17%
508.namd_r 4.05%
510.parest_r0.15%
511.povray_r0.80%
519.lbm_r 3.15%
521.wrf_r 10.56%
526.blender_r 2.97%
527.cam4_r 2.36%
538.imagick_r 46.40%
544.nab_r 2.04%
549.fotonik3d_r 0.00%
554.roms_r 1.27%
Geomean 5.49%
On Skylake server:
500.perlbench_r 0.71%
502.gcc_r -0.51%
505.mcf_r -1.06%
520.omnetpp_r -0.33%
523.xalancbmk_r -0.22%
525.x264_r 1.72%
531.deepsjeng_r -0.26%
541.leela_r 0.57%
548.exchange2_r -0.75%
557.xz_r-1.28%
Geomean -0.21%
503.bwaves_r0.00%
507.cactuBSSN_r 2.66%
508.namd_r 3.67%
510.parest_r1.25%
511.povray_r2.26%
519.lbm_r 1.69%
521.wrf_r 11.03%
526.blender_r 3.39%
527.cam4_r 1.69%
538.imagick_r 64.59%
544.nab_r -0.54%
549.fotonik3d_r 2.68%
554.roms_r 0.00%
Geomean 6.19%
This patch improves -march=native performance on Skylake up to 60% and
leaves -march=native performance unchanged on Haswell.
gcc/
2018-07-13 H.J. Lu
Sunil K Pandey
PR target/84413
* config/i386/i386.c (m_CORE_AVX512): New.
(m_CORE_AVX2): Likewise.
(m_CORE_ALL): Add m_CORE_AVX2.
* config/i386/x86-tune.def: Replace m_HASWELL with m_CORE_AVX2.
Replace m_SKYLAKE_AVX512 with m_CORE_AVX512 on avx256_optimal
and remove the rest of m_SKYLAKE_AVX512.
gcc/testsuite/
2018-07-13 H.J. Lu
Sunil K Pandey
PR target/84413
* gcc.target/i386/pr84413-1.c: New test.
* gcc.target/i386/pr84413-2.c: Likewise.
* gcc.target/i386/pr84413-3.c: Likewise.
Added:
trunk/gcc/testsuite/gcc.target/i386/pr84413-1.c
trunk/gcc/testsuite/gcc.target/i386/pr84413-2.c
trunk/gcc/testsuite/gcc.target/i386/pr84413-3.c
Modified:
trunk/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/x86-tune.def
trunk/gcc/testsuite/ChangeLog
[Bug target/84413] [8/9 Regression] -mtune=skylake,skylake-avx512,cannonlake,icelake disable many optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84413
--- Comment #6 from hjl at gcc dot gnu.org ---
Author: hjl
Date: Fri Jul 13 20:36:01 2018
New Revision: 262650
URL: https://gcc.gnu.org/viewcvs?rev=262650&root=gcc&view=rev
Log:
x86: Tune Skylake, Cannonlake and Icelake as Haswell
r259399, which added PROCESSOR_SKYLAKE, disabled many x86 optimizations
which are enabled by PROCESSOR_HASWELL. As the result, -mtune=skylake
generates slower codes on Skylake than before. The same also applies
to Cannonlake and Icelak tuning.
This patch changes -mtune={skylake|cannonlake|icelake} to tune like
-mtune=haswell for until their tuning is properly adjusted. It also
enables -mprefer-vector-width=256 for -mtune=haswell, which has no
impact on codegen when AVX512 isn't enabled.
Performance impacts on SPEC CPU 2017 rate with 1 copy using
-march=native -mfpmath=sse -O2 -m64
are
1. On Broadwell server:
500.perlbench_r -0.56%
502.gcc_r -0.18%
505.mcf_r 0.24%
520.omnetpp_r 0.00%
523.xalancbmk_r -0.32%
525.x264_r -0.17%
531.deepsjeng_r 0.00%
541.leela_r 0.00%
548.exchange2_r 0.12%
557.xz_r0.00%
Geomean 0.00%
503.bwaves_r0.00%
507.cactuBSSN_r 0.21%
508.namd_r 0.00%
510.parest_r0.19%
511.povray_r-0.48%
519.lbm_r 0.00%
521.wrf_r 0.28%
526.blender_r 0.19%
527.cam4_r 0.39%
538.imagick_r 0.00%
544.nab_r -0.36%
549.fotonik3d_r 0.51%
554.roms_r 0.00%
Geomean 0.17%
On Skylake client:
500.perlbench_r 0.96%
502.gcc_r 0.13%
505.mcf_r -1.03%
520.omnetpp_r -1.11%
523.xalancbmk_r 1.02%
525.x264_r 0.50%
531.deepsjeng_r 2.97%
541.leela_r 0.50%
548.exchange2_r -0.95%
557.xz_r2.41%
Geomean 0.56%
503.bwaves_r0.49%
507.cactuBSSN_r 3.17%
508.namd_r 4.05%
510.parest_r0.15%
511.povray_r0.80%
519.lbm_r 3.15%
521.wrf_r 10.56%
526.blender_r 2.97%
527.cam4_r 2.36%
538.imagick_r 46.40%
544.nab_r 2.04%
549.fotonik3d_r 0.00%
554.roms_r 1.27%
Geomean 5.49%
On Skylake server:
500.perlbench_r 0.71%
502.gcc_r -0.51%
505.mcf_r -1.06%
520.omnetpp_r -0.33%
523.xalancbmk_r -0.22%
525.x264_r 1.72%
531.deepsjeng_r -0.26%
541.leela_r 0.57%
548.exchange2_r -0.75%
557.xz_r-1.28%
Geomean -0.21%
503.bwaves_r0.00%
507.cactuBSSN_r 2.66%
508.namd_r 3.67%
510.parest_r1.25%
511.povray_r2.26%
519.lbm_r 1.69%
521.wrf_r 11.03%
526.blender_r 3.39%
527.cam4_r 1.69%
538.imagick_r 64.59%
544.nab_r -0.54%
549.fotonik3d_r 2.68%
554.roms_r 0.00%
Geomean 6.19%
This patch improves -march=native performance on Skylake up to 60% and
leaves -march=native performance unchanged on Haswell.
gcc/
Backport from mainline
2018-07-13 H.J. Lu
Sunil K Pandey
PR target/84413
* config/i386/i386.c (m_CORE_AVX512): New.
(m_CORE_AVX2): Likewise.
(m_CORE_ALL): Add m_CORE_AVX2.
* config/i386/x86-tune.def: Replace m_HASWELL with m_CORE_AVX2.
Replace m_SKYLAKE_AVX512 with m_CORE_AVX512 on avx256_optimal
and remove the rest of m_SKYLAKE_AVX512.
gcc/testsuite/
Backport from mainline
2018-07-13 H.J. Lu
Sunil K Pandey
PR target/84413
* gcc.target/i386/pr84413-1.c: New test.
* gcc.target/i386/pr84413-2.c: Likewise.
* gcc.target/i386/pr84413-3.c: Likewise.
Added:
branches/gcc-8-branch/gcc/testsuite/gcc.target/i386/pr84413-1.c
branches/gcc-8-branch/gcc/testsuite/gcc.target/i386/pr84413-2.c
branches/gcc-8-branch/gcc/testsuite/gcc.target/i386/pr84413-3.c
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/config/i386/i386.c
branches/gcc-8-branch/gcc/config/i386/x86-tune.def
branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug target/84413] [8/9 Regression] -mtune=skylake,skylake-avx512,cannonlake,icelake disable many optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84413 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from H.J. Lu --- Fixed for GCC 8.2 and GCC 9.
[Bug c/86520] New: AArch64: Two 8-bit accesses coalesced into a single 16-bit access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86520
Bug ID: 86520
Summary: AArch64: Two 8-bit accesses coalesced into a single
16-bit access
Product: gcc
Version: 7.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: swarren at nvidia dot com
Target Milestone: ---
When compiling for AArch64 (64-bit ARM), the following code:
void func(char *str)
{
*str = '0';
str++;
*str = 'x';
str++;
}
... I believe should always perform two separate 8-bit accesses, simply because
the compiler can't know whether str is aligned to anything more than byte
alignment.
With recent compilers without optimization, and with older compilers, the
following code is generated:
:
0: 52800601mov w1, #0x30 // #48
4: 3901strbw1, [x0]
8: 52800f01mov w1, #0x78 // #120
c: 39000401strbw1, [x0,#1]
10: d65f03c0ret
However, with any all Linaro gcc 7.x releases and -O3, those two byte writes
are combined:
:
0: 528f0601mov w1, #0x7830 // #30768
4: 7901strhw1, [x0]
8: d65f03c0ret
When this happens in the real code I'm compiling/execution, an alignment
exception is thrown because str (x0) is only byte aligned not 16-bit aligned.
I have not tested gcc-8.x yet, since I'm using Linaro binary releases not
building from source.
[Bug tree-optimization/86520] AArch64: Two 8-bit accesses coalesced into a single 16-bit access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86520 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Component|c |tree-optimization Target Milestone|--- |8.0 --- Comment #1 from Andrew Pinski --- >any all Linaro gcc 7.x releases Yes because they backported the patch which fixed this issue.
[Bug lto/86517] relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86517 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||hjl.tools at gmail dot com Resolution|--- |INVALID --- Comment #1 from H.J. Lu --- I(In reply to Martin Liška from comment #0) > > $ gcc -flto -c -fPIE -O2 1.i 2.i && gcc -fPIC -c -O2 lib.i -flto && ar rv > x.a lib.o && gcc -pie -O2 -pthread -ldl -lxml2 1.o 2.o x.a -rdynamic -flto=9 > -shared > r - lib.o I don't believe you can build a shared object with -fPIE and linker tells you to recompile with -fPIC.
[Bug tree-optimization/86259] [8/9 Regression] min(4, strlen(s)) optimized to strlen(s) with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86259
--- Comment #24 from Martin Sebor ---
The code in example #21 has the same bug:
union U u;
u.s = (struct S){0, 0, 0};
char *bp = u.s.b; // <<< bp points to u.s.b
uintptr_t sp_ip = (uintptr_t)bp - offsetof(struct S,b); // sp_ip has
u.s.b's provenance
strcpy(u.xx, "abcdefghijk");
size_t len = strlen((char *)(union U *)sp_ip + 4); // still the same
provenance
puts(len == 7 ? "YES" : "NO");
The strlen call is undefined because (char*)sp_ip is known to point just past
the last element of u.s.b. It wouldn't matter if there happened to be a valid
string at that address -- there isn't in this case because what's there is a
char[4] with no terminating NUL. The pointer wasn't derived from that address.
The pointer was derived from u.s.b and points to u.s.b + sizeof u.s.b, and
there can never be anything valid beyond the end of an object.
Compile the test case with -fdump-tree-fre1=/dev/stdout to see what GCC sees:
bp.0_1 = (long unsigned int) &u.s.b;
sp_ip_9 = bp.0_1 + 18446744073709551612;
MEM[(char * {ref-all})&u] = MEM[(char * {ref-all})"abcdefghijk"];
_4 = __builtin_strlen (&u.s.b);
The rule to keep in mind is that pointer arithmetic is only valid within the
boundaries of the smallest subobject it points to. This applies to structs as
much as arrays. Just like it's not valid to increment a pointer from a[0][1]
to a[1][0] and dereference the latter in 'char a[2][2]; it's not valid to
increment a pointer to one struct member to point to another and dereference
it.
[Bug c++/78173] Hard error subtracting pointers to incomplete type in SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78173
Casey Carter changed:
What|Removed |Added
CC||Casey at Carter dot net
Blocks||67491
--- Comment #1 from Casey Carter ---
This still reproduces on trunk, and in concepts land. This program fragment:
template
concept bool CanDifference = requires(T const& x, T const& y) {
x - y;
};
static_assert(!CanDifference);
produces diagnostics when compiled with "g++ -std=c++2a -fconcepts"
(https://godbolt.org/g/e36eFK):
:3:7: error: invalid use of 'void'
x - y;
~~^~~
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
[Bug 67491] [meta-bug] concepts issues
[Bug testsuite/86519] New test case gcc.dg/strcmpopt_6.c fails with its introduction in r262636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519 --- Comment #1 from qinzhao at gcc dot gnu.org --- I cannot repeat this issue on a powerPc machine: Native configuration is powerpc64-unknown-linux-gnu === gcc tests === Schedule of variations: unix Running target unix Running /home/qinzhao/Work/GCC/latest_gcc/gcc/testsuite/gcc.dg/dg.exp ... PASS: gcc.dg/strcmpopt_6.c (test for excess errors) PASS: gcc.dg/strcmpopt_6.c execution test PASS: gcc.dg/strcmpopt_6.c scan-rtl-dump-times expand "__builtin_memcmp" 4
[Bug tree-optimization/85804] [8/9 Regression][AArch64] Mis-compilation of loop with strided array access and xor reduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85804 --- Comment #4 from bin cheng --- (In reply to Ramana Radhakrishnan from comment #3) > (In reply to Ramana Radhakrishnan from comment #2) > > Patch being discussed here. > > https://gcc.gnu.org/ml/gcc-patches/2018-05/msg01026.html > > > Bin are you still working on this ? No, since there is no further discussion, I am not on this now.
