[Bug fortran/84141] [8.0.1 regression] Internal error: type_name(): Bad type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84141 Thomas Koenig changed: What|Removed |Added Target Milestone|--- |8.0
[Bug fortran/68746] FAIL: gfortran.dg/read_dir.f90 -O0 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68746 Thomas Koenig changed: What|Removed |Added Status|WAITING |NEW CC||tkoenig at gcc dot gnu.org --- Comment #11 from Thomas Koenig --- Is there anything than can be done to debug this? What happens if you compile the test with -g and run it under a debgger?
[Bug c/84100] [7/8 Regression] Function __attribute__((optimize(align-loops=32))) gives spurious warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84100 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Wed Jan 31 08:26:52 2018 New Revision: 257219 URL: https://gcc.gnu.org/viewcvs?rev=257219&root=gcc&view=rev Log: PR c/84100 * common.opt (falign-functions=, falign-jumps=, falign-labels=, falign-loops=): Add Optimization flag. * gcc.dg/pr84100.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr84100.c Modified: trunk/gcc/ChangeLog trunk/gcc/common.opt trunk/gcc/testsuite/ChangeLog
[Bug c/84100] [7 Regression] Function __attribute__((optimize(align-loops=32))) gives spurious warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84100 Jakub Jelinek changed: What|Removed |Added Summary|[7/8 Regression] Function |[7 Regression] Function |__attribute__((optimize(ali |__attribute__((optimize(ali |gn-loops=32))) gives|gn-loops=32))) gives |spurious warning|spurious warning --- Comment #5 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug preprocessor/69869] [6/7/8 Regression] internal compiler error: Segmentation fault in call to skip_macro_block_comment when using '-traditional-cpp'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69869 --- Comment #8 from Jakub Jelinek --- Author: jakub Date: Wed Jan 31 08:31:52 2018 New Revision: 257220 URL: https://gcc.gnu.org/viewcvs?rev=257220&root=gcc&view=rev Log: PR preprocessor/69869 * traditional.c (skip_macro_block_comment): Return bool, true if the macro block comment is unterminated. (copy_comment): Use return value from skip_macro_block_comment instead of always false. * gcc.dg/cpp/trad/pr69869.c: New test. Added: trunk/gcc/testsuite/gcc.dg/cpp/trad/pr69869.c Modified: trunk/gcc/testsuite/ChangeLog trunk/libcpp/ChangeLog trunk/libcpp/traditional.c
[Bug preprocessor/69869] [6/7 Regression] internal compiler error: Segmentation fault in call to skip_macro_block_comment when using '-traditional-cpp'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69869 Jakub Jelinek changed: What|Removed |Added Summary|[6/7/8 Regression] internal |[6/7 Regression] internal |compiler error: |compiler error: |Segmentation fault in call |Segmentation fault in call |to skip_macro_block_comment |to skip_macro_block_comment |when using |when using |'-traditional-cpp' |'-traditional-cpp' --- Comment #9 from Jakub Jelinek --- Fixed on the trunk.
[Bug ipa/81360] [8 Regression] ice in estimate_edge_growth, at ipa-inline.h:86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81360 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #14 from Christophe Lyon --- The new test fails on arm and aarch64: FAIL: g++.dg/torture/pr81360.C -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects scan-ipa-dump icf "Equal symbols: 0"
[Bug c++/84130] excessive compile time with -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84130 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Jakub Jelinek --- Why? I think it is pretty much the rule that -O1 can take 3-4 times as long as -O0, the whole point of -O0 is that it bypasses most of the optimization passes. Your testcase is just huge, compiles to 31M assembly, there is not a single optimization where significant time would be spent, most time takes garbage collection (8%), tree CCP (7%), dominance (5%), the rest is below that.
[Bug target/79975] SEGV in cc1 compiling gcc.dg/rtl/x86_64/final.c with -fno-dwarf2-cfi-asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79975 Rainer Orth changed: What|Removed |Added Target|i?86-pc-solaris2.*, |i?86-*-*, x86_64-*-* |amd64-pc-solaris2.*,| |x86_64-unknown-freebsd12.0, | |i386-apple-darwin11.4.2,| |i386-apple-darwin16.7.0 | Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-31 Host|i?86-pc-solaris2.*, | |amd64-pc-solaris2.* | Summary|SEGV in cc1 compiling |SEGV in cc1 compiling |gcc.dg/rtl/x86_64/final.c |gcc.dg/rtl/x86_64/final.c ||with -fno-dwarf2-cfi-asm Ever confirmed|0 |1 Build|i?86-pc-solaris2.*, | |amd64-pc-solaris2.* | --- Comment #4 from Rainer Orth --- After fixing the detection of HAVE_GAS_CFI_DIRECTIVE on x86_64-pc-solaris2.* with gas, I noticed that this failure disappeared on that target. So obviously only targets with HAVE_GAS_CFI_DIRECTIVE 0 are affected. And indeed, the SEGV can easily be reproduced on x86_64-pc-linux-gnu with -fno-dwarf2-cfi-asm. Since the testcase is compile-only anyway (thus not depending on toolchain support for cfi directives) and scans for those in the assembler output, I'll soon submit a patch to add an explicit -fdwarf2-cfi-asm which avoids the SEGV on all x86 targets.
[Bug lto/83954] [6/7 Regression] LTO: Bogus -Wlto-type-mismatch warning for array of pointer to incomplete type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83954 --- Comment #11 from Rainer Orth --- Author: ro Date: Wed Jan 31 09:07:55 2018 New Revision: 257221 URL: https://gcc.gnu.org/viewcvs?rev=257221&root=gcc&view=rev Log: Fix gnat.dg/lto20.adb XPASS PR lto/83954 * gnat.dg/lto20.adb: Remove dg-excess-errors. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gnat.dg/lto20.adb
[Bug tree-optimization/84117] [8 Regression] ICE in gimplify_modify_expr, at gimplify.c:5798
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84117 --- Comment #3 from Jakub Jelinek --- This started to ICE in particular with r256644. The other PR we have about -ftrapv and vectorization is PR81661 (and probably others).
[Bug target/84145] New: Wrong CET options processing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84145
Bug ID: 84145
Summary: Wrong CET options processing
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: igor.v.tsimbalist at intel dot com
Target Milestone: ---
The gcc error message for not passing -mibt/-mshstk with -fcf-protection seems
confusing. It looks like it just checks that one of the options is present and
doesn’t check that it’s the option that is required by the protection
requested. So it's possible to do -fcf-protection=branch -mshstk and not get an
error, but not get any protection either.
Here is this part:
if (!(TARGET_IBT_P (opts->x_ix86_isa_flags2)
|| TARGET_SHSTK_P (opts->x_ix86_isa_flags)))
{
if (flag_cf_protection == CF_FULL)
{
error ("%<-fcf-protection=full%> requires CET support "
"on this target. Use -mcet or one of -mibt, "
"-mshstk options to enable CET");
}
else if (flag_cf_protection == CF_BRANCH)
{
error ("%<-fcf-protection=branch%> requires CET support "
"on this target. Use -mcet or one of -mibt, "
"-mshstk options to enable CET");
}
else if (flag_cf_protection == CF_RETURN)
{
error ("%<-fcf-protection=return%> requires CET support "
"on this target. Use -mcet or one of -mibt, "
"-mshstk options to enable CET");
}
flag_cf_protection = CF_NONE;
return false;
}
[Bug c++/84132] [8 Regression] tree-data-ref.c:3938: poor coding ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84132 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #4 from Richard Biener --- Mine.
[Bug fortran/84135] [8 Regression] ICE in gfc_trans_array_cobounds, at fortran/trans-array.c:6033
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84135 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |8.0
[Bug c++/84136] [6/7/8 Regression] ICE with goto to an && label in another function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84136 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |6.5
[Bug ipa/82256] [6/7 Regression] clones created by create_version_clone_with_body are not observable to insertion hooks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82256 --- Comment #7 from PaX Team --- (In reply to Jan Hubicka from comment #5) > I am going to test the patch against mainline and commit it. However about > backporting, can you produce some issue with this bug? well, the thing is that i ran across this while playing with the plugin API and noticed that my notification callbacks didn't see the expected cgraph nodes on certain gcc versions (v5+) which made me look into the cause and find the typo made during the refactoring. as for sideeffects, gcc itself is a user of these hooks (ipa-prop.c, ipa-pure-const.c and symbol-summary.h) so missing nodes there can probably have undesirable sideeffects but it's probably best to let gcc developers familiar with that code determine that. in any case, i think the regressive nature of this bug alone should warrant a backport to all affected versions...
[Bug libgomp/84088] [8 Regression][nvptx] libgomp.oacc-fortran/declare-*.f90 execution fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84088 Paul Thomas changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-31 Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #10 from Paul Thomas --- I'll take this and deal with it this evening. The problem lies in trans-expr.c(gfc_conv_scalar_to_descriptor), which was touched in the patch as was the code around the call to it from gfc_conv_procedure_call. You will note that not only is elem_len = 8 in comment #9 but the type is 11, which is also wrong. Thanks for the testcase with which I can reproduce the problem. Paul
[Bug middle-end/84089] [8 Regression] FAIL: g++.dg/cpp1y/lambda-generic-x.C -std=gnu++14 (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84089 Aldy Hernandez changed: What|Removed |Added CC||law at gcc dot gnu.org --- Comment #4 from Aldy Hernandez --- I know nothing about the PA back-end, or whether E_VOIDmode is valid for base14_operand, however... Before r196122, a VOIDmode would return the default value of false in base14_operand, but when S?mode and D?mode's were collapsed with the aforementioned patch, we started handling VOIDmode. This can trigger a division by 0. The untested patch below fixes this problem: diff --git a/gcc/config/pa/predicates.md b/gcc/config/pa/predicates.md index 4600f988c87..f7961cc7f88 100644 --- a/gcc/config/pa/predicates.md +++ b/gcc/config/pa/predicates.md @@ -275,6 +275,7 @@ case E_BLKmode: case E_QImode: case E_HImode: +case E_VOIDmode: return true; Again, I have no knowledge of the PA port, and I don't know if pa_legitimate_address_p() is supposed to even handle E_VOIDmode. Perhaps a PA maintainer can comment.
[Bug target/82641] Unable to enable crc32 for a certain function with target attribute on ARM (aarch32)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82641
--- Comment #24 from Tamar Christina ---
Do you have a repro for this one? compiling the kernel with
`CFLAGS="march=-armv4t"` doesn't seem to reproduce the original issue.
But the scenario should be working without needing to separate out the
functions, as long as you're in-lining the right direction.
Making a handwritten example works fine:
__attribute__((always_inline, target("arch=armv4t")))
static inline int do_this (int x)
{
return x*x;
}
#pragma GCC target("arch=armv5te")
int do_that (int x, int y)
{
return do_this (x - y);
}
what would generate the error you're getting is if you're in-lining the armv5te
code into armv4t which is an actual error
__attribute__((always_inline, target("arch=armv5te")))
static inline int do_this (int x)
{
return x*x;
}
#pragma GCC target("arch=armv4t")
int do_that (int x, int y)
{
return do_this (x - y);
}
The compiler only rejects the inlining if you've told it to always inline and
when the function to be inline's feature bits are not a strict subset of the
function in which it is to inline
[Bug c++/84132] [8 Regression] tree-data-ref.c:3938: poor coding ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84132
--- Comment #5 from Richard Biener ---
So the difference is that before this rev.
difference = chrec_fold_minus (type, chrec_a, chrec_b);
for
(gdb) p debug_generic_expr (chrec_a)
(signed int) {{(unsigned int) h_10(D), +, 1}_1, +, 6}_2
(gdb) p debug_generic_expr (chrec_b)
(signed int) {{(unsigned int) h_10(D) + 1, +, 1}_1, +, 6}_2
computed scev_not_known while now we compute -1. So there's already the
case before where chrec_a/b are _not_
evolution_function_is_affine_multivariate_p
as the comment before the gcd_of_steps_may_divide_p call suggests. And
later calls in the else if () cases suggest we indeed need to check that.
[Bug rtl-optimization/84071] [7/8 regression] wrong elimination of zero-extension after sign-extended load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84071 --- Comment #12 from Eric Botcazou --- Author: ebotcazou Date: Wed Jan 31 10:03:06 2018 New Revision: 257224 URL: https://gcc.gnu.org/viewcvs?rev=257224&root=gcc&view=rev Log: PR rtl-optimization/84071 * combine.c (record_dead_and_set_regs_1): Record the source unmodified for a paradoxical SUBREG on a WORD_REGISTER_OPERATIONS target. Added: trunk/gcc/testsuite/gcc.c-torture/execute/20180131-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/64946] [AArch64] gcc.target/aarch64/vect-abs-compile.c - "abs" vectorization fails for char/short types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64946 --- Comment #23 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Wed Jan 31 10:06:45 2018 New Revision: 257225 URL: https://gcc.gnu.org/viewcvs?rev=257225&root=gcc&view=rev Log: [AArch64] PR tree-optimization/64946: XFAIL gcc.target/aarch64/vect-abs-compile.c This test has been failing since forever, it has never passed AFAIK. The PR details the vectoriser deficiency. I propose we xfail this with a reference to the PR. PR tree-optimization/64946 * gcc.target/aarch64/vect-abs-compile.c: XFAIL byte and half-word scan-assembler checks. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/aarch64/vect-abs-compile.c
[Bug c++/84138] [8 Regression] ICE folding broken constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84138 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |8.0
[Bug rtl-optimization/84071] [7/8 regression] wrong elimination of zero-extension after sign-extended load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84071 --- Comment #13 from Eric Botcazou --- Author: ebotcazou Date: Wed Jan 31 10:08:08 2018 New Revision: 257226 URL: https://gcc.gnu.org/viewcvs?rev=257226&root=gcc&view=rev Log: PR rtl-optimization/84071 * combine.c (record_dead_and_set_regs_1): Record the source unmodified for a paradoxical SUBREG on a WORD_REGISTER_OPERATIONS target. Added: branches/gcc-7-branch/gcc/testsuite/gcc.c-torture/execute/20180131-1.c - copied unchanged from r257224, trunk/gcc/testsuite/gcc.c-torture/execute/20180131-1.c Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/combine.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug fortran/84141] [8 Regression] Internal error: type_name(): Bad type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84141 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Summary|[8.0.1 regression] Internal |[8 Regression] Internal |error: type_name(): Bad |error: type_name(): Bad |type|type
[Bug tree-optimization/82518] [8 regression] gfortran.fortran-torture/execute/in-pack.f90 fails on armeb since r252917
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82518 Aldy Hernandez changed: What|Removed |Added CC||aldyh at gcc dot gnu.org, ||nickc at gcc dot gnu.org --- Comment #7 from Aldy Hernandez --- Hi Nick! Hi all! Do we have a way of testing armeb, either through a simulator or through some aarch64 with magic flags? If anyone has a hint on how to reproduce this, I'll gladly take a stab at reproducing, bisecting, debugging, etc. Whatever it takes to inch this forward :).
[Bug rtl-optimization/84071] [7/8 regression] wrong elimination of zero-extension after sign-extended load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84071 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #14 from Eric Botcazou --- Thanks for reporting the problem and distilling a reduced testcase.
[Bug fortran/84141] [8.0.1 regression] Internal error: type_name(): Bad type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84141 Jürgen Reuter changed: What|Removed |Added Summary|[8 Regression] Internal |[8.0.1 regression] Internal |error: type_name(): Bad |error: type_name(): Bad |type|type --- Comment #5 from Jürgen Reuter --- We checked that also r257131 was already broken.
[Bug tree-optimization/82518] [8 regression] gfortran.fortran-torture/execute/in-pack.f90 fails on armeb since r252917
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82518 --- Comment #8 from Nick Clifton --- Hi Aldy, > Do we have a way of testing armeb, either through a simulator or through > some aarch64 with magic flags? GDB has an ARM simulator which is OK unless you need to test some of the newer features like scalable vector instructions. Just compile your code as normal and then build an armeb targeted version of gdb. Cheers Nick
[Bug c++/84138] [8 Regression] ICE folding broken constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84138 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug lto/84105] [8 regression] Segmentation fault in pp_tree_identifier() during LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84105 --- Comment #8 from Aldy Hernandez --- Author: aldyh Date: Wed Jan 31 10:42:52 2018 New Revision: 257228 URL: https://gcc.gnu.org/viewcvs?rev=257228&root=gcc&view=rev Log: PR lto/84105 * tree-pretty-print.c (dump_generic_node): Handle a TYPE_NAME with an IDENTIFIER_NODE for FUNCTION_TYPE's. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-pretty-print.c
[Bug lto/84105] [8 regression] Segmentation fault in pp_tree_identifier() during LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84105 Aldy Hernandez changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Aldy Hernandez --- Fixed in trunk.
[Bug target/82641] Unable to enable crc32 for a certain function with target attribute on ARM (aarch32)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82641
--- Comment #25 from Arnd Bergmann ---
(In reply to Tamar Christina from comment #24)
> Do you have a repro for this one? compiling the kernel with
> `CFLAGS="march=-armv4t"` doesn't seem to reproduce the original issue.
It needs to be a kernel configuration that enables both an ARMv4-based target
platform (e.g. ARCH_MOXART) and another target platform with ARMv5TE+IWMMXT
(e.g. ARCH_MMP).
> But the scenario should be working without needing to separate out the
> functions, as long as you're in-lining the right direction.
Ah, interesting.
> what would generate the error you're getting is if you're in-lining the
> armv5te code into armv4t which is an actual error
>
> __attribute__((always_inline, target("arch=armv5te")))
> static inline int do_this (int x)
> {
> return x*x;
> }
>
> #pragma GCC target("arch=armv4t")
>
>
> int do_that (int x, int y)
> {
> return do_this (x - y);
> }
>
> The compiler only rejects the inlining if you've told it to always inline
> and when the function to be inline's feature bits are not a strict subset of
> the function in which it is to inline
I can't reproduce it here myself now, no idea what I did earlier.
Anyway, since neither the #pragma nor the attribute work on existing
compilers, and making the hack version dependent would be worse,
I don't think we can use that anyway.
The best workaround I see so far is to either move all the affected
inline assembly statements into an external .S file to sidestep the
problem, or to apply more force and add the ".arch" to each inline
asm individually.
[Bug tree-optimization/84037] [8 Regression] Speed regression of polyhedron benchmark since r256644
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84037 --- Comment #17 from Jan Hubicka --- We already have /* This function adjusts the unroll factor based on the hardware capabilities. For ex, bdver3 has a loop buffer which makes unrolling of smaller loops less important. This function decides the unroll factor using number of memory references (value 32 is used) as a heuristic. */ static unsigned ix86_loop_unroll_adjust (unsigned nunroll, struct loop *loop) which triggers with TARGET_ADJUST_UNROLL /* X86_TUNE_ADJUST_UNROLL: This enables adjusting the unroll factor based on hardware capabilities. Bdver3 hardware has a loop buffer which makes unrolling small loop less important. For, such architectures we adjust the unroll factor so that the unrolled loop fits the loop buffer. */ DEF_TUNE (X86_TUNE_ADJUST_UNROLL, "adjust_unroll_factor", m_BDVER3 | m_BDVER4) so perhaps what you propose can be done by making this one more general?
[Bug target/83618] _rdpid_u32 doesn't work on 64-bit targets as gas expects the 64-bit register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83618 --- Comment #2 from Julia Koval --- Author: jkoval Date: Wed Jan 31 11:06:20 2018 New Revision: 257229 URL: https://gcc.gnu.org/viewcvs?rev=257229&root=gcc&view=rev Log: PR target/83618 gcc/ * config/i386/i386.c (ix86_expand_builtin): Handle IX86_BUILTIN_RDPID. * config/i386/i386.md (rdpid_rex64) New. (rdpid): Make 32bit only. gcc/testsuite/ * gcc.target/i386/rdpid.c: Remove "eax". Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.md trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/rdpid.c
[Bug target/83618] _rdpid_u32 doesn't work on 64-bit targets as gas expects the 64-bit register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83618 --- Comment #3 from Julia Koval --- Fixed by r257229
[Bug tree-optimization/84117] [8 Regression] ICE in gimplify_modify_expr, at gimplify.c:5798
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84117 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Created attachment 43305 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43305&action=edit gcc8-pr84117.patch Untested fix. Richard, or do you want to put it into another source file/header?
[Bug tree-optimization/84037] [8 Regression] Speed regression of polyhedron benchmark since r256644
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84037 --- Comment #18 from Richard Biener --- (In reply to Jan Hubicka from comment #17) > We already have > /* This function adjusts the unroll factor based on >the hardware capabilities. For ex, bdver3 has >a loop buffer which makes unrolling of smaller >loops less important. This function decides the >unroll factor using number of memory references >(value 32 is used) as a heuristic. */ > > static unsigned > ix86_loop_unroll_adjust (unsigned nunroll, struct loop *loop) > > which triggers with TARGET_ADJUST_UNROLL > /* X86_TUNE_ADJUST_UNROLL: This enables adjusting the unroll factor based > >on hardware capabilities. Bdver3 hardware has a loop buffer which makes > >unrolling small loop less important. For, such architectures we adjust > >the unroll factor so that the unrolled loop fits the loop buffer. */ > > DEF_TUNE (X86_TUNE_ADJUST_UNROLL, "adjust_unroll_factor", m_BDVER3 | > m_BDVER4) > > so perhaps what you propose can be done by making this one more general? Hmm. Both i386 and s390x expect the function to be in RTL form for this hook so it doesn't apply on GIMPLE (and gimple unrolling). If we'd make it more general, thus handle both IL forms and instead of returning an unroll factor return a maximum growth factor, not maximum size to avoid comparing apples (size unit of target) and oranges (size unit of consumer) then it could indeed work. So sth like /* Return the maximum percentage LOOP is allowed to grow to or -1U for no target specific constraints. */ unsigned targetm.loop_growth_constraint (loop *loop); the existing uses in loop-unroll.c if (targetm.loop_unroll_adjust) nunroll = targetm.loop_unroll_adjust (nunroll, loop); would then become sth like if (targetm.loop_unroll_adjust) nunroll = MIN (nunroll, targetm.loop_unroll_adjust (loop) / 100); and existing hooks would have an early out if (in_gimple_form) return -1U; and their current return value simply multiplied by 100? Note the current x86 implementation does /* Count the number of memory references within the loop body. This value determines the unrolling factor for bdver3 and bdver4 architectures. */ ... if (mem_count && mem_count <=32) return 32/mem_count; return nunroll; and thus returns 32 for mem_count == 1 and any nunroll specified by the caller (like if it specified 2 because of some user --param). That looks bougs to me and we instead want to return MIN (nunroll, 32 / mem_count)? The s390 implementation gets this right.
[Bug c++/83024] ICE in build_address, at cp/typeck.c:5623
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83024 Marek Polacek changed: What|Removed |Added Status|NEW |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #3 from Marek Polacek --- Fixed by r256765.
[Bug tree-optimization/80641] missed optimization with with std::vector resize in loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80641 --- Comment #10 from Paul Gotch --- I'm afraid the changes made to libstdc++ have only solved part of the regression if you say something like std::vector v; if(c.size() > 0) c.resize(c.size() - 1); then you no longer get a warning in 7.3 however if instead you do if(! c.empty()) c.resize(c.size() -1); the warning is produced just as in early 7.x releases. No warning is produced in 6.x so this is still a regression. I presume this happens as empty wasn't annotated in libstdc++ and the underlying data flow analysis bug is yet to be fixed.
[Bug tree-optimization/84117] [8 Regression] ICE in gimplify_modify_expr, at gimplify.c:5798
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84117 --- Comment #5 from rguenther at suse dot de --- On Wed, 31 Jan 2018, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84117 > > Jakub Jelinek changed: > >What|Removed |Added > > Status|NEW |ASSIGNED >Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot > gnu.org > > --- Comment #4 from Jakub Jelinek --- > Created attachment 43305 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43305&action=edit > gcc8-pr84117.patch > > Untested fix. Richard, or do you want to put it into another source > file/header? The file works for me. Note instead of the switch () you probably want to use if (! operation_no_trapping_overflow (TREE_TYPE (*tp), TREE_CODE (*tp))) return *tp; so we keep a single place to specify which tree codes will end up trapping for which type. Otherwise looks ok but I'd do the rewrite in number_of_iterations_exit instead? Which also means another option would be to say chrec_dont_know there if find_trapping_overflow (). That might be even safer given I'm sure we'll run into similar issues with SCEV ... (but maybe I've fixed enough of the undefined overflow cases there to also catch traps...)
[Bug target/84146] New: ICE with -mcet in dwarf2out_var_location, involving sigsetjmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84146 Bug ID: 84146 Summary: ICE with -mcet in dwarf2out_var_location, involving sigsetjmp Product: gcc Version: 8.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: fw at gcc dot gnu.org Blocks: 81652 Target Milestone: --- Target: x86-64 Created attachment 43306 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43306&action=edit reproducer.c Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81652 [Bug 81652] [meta-bug] -fcf-protection=full -mcet bugs
[Bug libstdc++/84139] C++17 Filesystem/Filesystem TS + cmcstl2 = GCC ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84139 --- Comment #3 from Jonathan Wakely --- (In reply to Christopher Di Bella from comment #0) > Please let me know if the issue > should be resubmitted for each version of GCC that it affects. No, definitely not.
[Bug target/84146] ICE with -mcet in dwarf2out_var_location, involving sigsetjmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84146 Florian Weimer changed: What|Removed |Added See Also||https://bugzilla.redhat.com ||/show_bug.cgi?id=1540549 --- Comment #1 from Florian Weimer --- Compile with: -mcet -g -O2 -fcf-protection=full during RTL pass: final reproducer.c: In function ‘f2’: reproducer.c:14:1: internal compiler error: in dwarf2out_var_location, at dwarf2out.c:26542 } ^ As seen with: gcc (GCC) 8.0.1 20180127 (Red Hat 8.0.1-0.6)
[Bug middle-end/84147] New: RTTI for base class in anonymous namespace could be avoided
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84147
Bug ID: 84147
Summary: RTTI for base class in anonymous namespace could be
avoided
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: antoshkka at gmail dot com
Target Milestone: ---
Consider the example
namespace {
struct base {
virtual int foo() noexcept {return 1;}
};
}
struct derived1 final : base {};
struct derived2 final : base {};
struct pair {
derived1 d1;
derived2 d2;
};
pair test() {
return {};
}
`base` is in the anonymous namespace (has internal linkage) and used only for
providing some functions to derived classes. There are no complex inheritances,
there are no dynamic_casts and typeid(base) calls.
RTTI for base class seems useless in that case, but it is still generated in
the assembly:
.type typeinfo for (anonymous namespace)::base, @object
.size typeinfo for (anonymous namespace)::base, 16
typeinfo for (anonymous namespace)::base:
.quad vtable for __cxxabiv1::__class_type_info+16
.quad typeinfo name for (anonymous namespace)::base
.align 16
.type typeinfo name for (anonymous namespace)::base, @object
.size typeinfo name for (anonymous namespace)::base, 23
typeinfo name for (anonymous namespace)::base:
.string "*N12_GLOBAL__N_14baseE"
[Bug target/84146] ICE with -mcet in dwarf2out_var_location, involving sigsetjmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84146
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2018-01-31
CC||jakub at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Jakub Jelinek ---
(call_insn:TI 75 646 762 3 (set (reg:SI 0 ax)
(call (mem:QI (symbol_ref:DI ("__sigsetjmp") [flags 0x41]
) [0 __sigsetjmp S1 A8])
(const_int 0 [0]))) "../../../tests/server/tftpd.c":1334 690
{*call_value}
(expr_list:REG_DEAD (reg:DI 5 di)
(expr_list:REG_DEAD (reg:SI 4 si)
(expr_list:REG_UNUSED (reg:SI 0 ax)
(expr_list:REG_CALL_DECL (symbol_ref:DI ("__sigsetjmp") [flags
0x41] )
(expr_list:REG_SETJMP (const_int 0 [0])
(expr_list:REG_EH_REGION (const_int 0 [0])
(nil)))
(expr_list:DI (use (reg:DI 5 di))
(expr_list:SI (use (reg:SI 4 si))
(nil
(insn 762 75 647 3 (unspec_volatile [
(const_int 0 [0])
] UNSPECV_NOP_ENDBR) "../../../tests/server/tftpd.c":1334 1101
{nop_endbr}
(nil))
(note 647 762 80 (expr_list:REG_DEP_TRUE (concat:DI (reg:DI 5 di)
(symbol_ref:DI ("timeoutbuf") [flags 0x2] ))
(expr_list:REG_DEP_TRUE (concat:SI (reg:SI 4 si)
(const_int 1 [0x1]))
(nil))) NOTE_INSN_CALL_ARG_LOCATION)
The bug is inserting anything in between a CALL and
NOTE_INSN_CALL_ARG_LOCATION, those need to be consecutive. Let me first reduce
this.
[Bug c++/84139] C++17 Filesystem/Filesystem TS + cmcstl2 = GCC ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84139 Jonathan Wakely changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-31 Component|libstdc++ |c++ Ever confirmed|0 |1 --- Comment #4 from Jonathan Wakely --- An ICE cannot be a libstdc++ bug. The compiler crashing is a compiler bug. I'm adding ice-on-valid-code but it's possible the ranges lib is doing something bad.
[Bug c/81779] [6/7/8 Regression] bool define from stdbool.h suppresses -Wdeclaration-after-statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81779 Marek Polacek changed: What|Removed |Added Target Milestone|--- |6.4 Summary|bool define from stdbool.h |[6/7/8 Regression] bool |suppresses |define from stdbool.h |-Wdeclaration-after-stateme |suppresses |nt |-Wdeclaration-after-stateme ||nt
[Bug rtl-optimization/84071] [7/8 regression] wrong elimination of zero-extension after sign-extended load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84071 --- Comment #15 from Wilco --- (In reply to Eric Botcazou from comment #10) > > The addition is performed on the full 32-bit register, so this obviously > > means that the top 24 bits have an undefined value. > > Not if the entire registers have a defined value before the addition. The > point of WORD_REGISTER_OPERATIONS is the following: you have a pair of > SImode registers with known values and you do a QImode addition on them. If > the macro is defined, then the compiler considers that the result has a > defined value in SImode. That's the best description of WORD_REGISTER_OPERATIONS I've seen - maybe we should fix the docs to be clearer? Also I wonder whether this means AArch64 should set it since targets like MIPS and Sparc already set it. > In any case, that's not really the issue here and I'll just fix the combiner. Thanks for fixing this. I'm still not convinced that the logic of this is right: if ((!WORD_REGISTER_OPERATIONS /* If this is a typical RISC machine, we only have to worry about the way loads are extended. */ || ((extend_op = load_extend_op (inner_mode)) == SIGN_EXTEND ? val_signbit_known_set_p (inner_mode, nonzero) : extend_op != ZERO_EXTEND) || (!MEM_P (SUBREG_REG (x)) && !REG_P (SUBREG_REG (x && xmode_width > inner_width) So assuming WORD_REGISTER_OPERATIONS and load_extend_op is ZERO_EXTEND, we fall into the (!MEM_P (SUBREG_REG (x)) && !REG_P (SUBREG_REG (x))). But that effectively means that load_extend_op applies to REG_P as well as MEM_P, which can't be right...
[Bug tree-optimization/84037] [8 Regression] Speed regression of polyhedron benchmark since r256644
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84037 --- Comment #19 from Richard Biener --- On Zen I measure 23s with --param vect-max-version-for-alias-checks=0 (thus basically before the rev.) and 33s without. With the patch and the size parameter tuned to 146 I get 25s and with 90 it is 22.5s. So Zen seems to be a bit pickier (code-size wise) than Broadwell.
[Bug fortran/84120] Syntax for used for PDT constructors is incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84120 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-01-31 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- > This explains the problem underlying PR82205 Duplicate of PR82205?
[Bug tree-optimization/84037] [8 Regression] Speed regression of polyhedron benchmark since r256644
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84037 --- Comment #20 from Richard Biener --- Note that targets already have the opportunity to limit vectorization by adjusting their finish_cost hook - here they even have more useful information available (kind of).
[Bug target/84146] ICE with -mcet in dwarf2out_var_location, involving sigsetjmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84146
--- Comment #3 from Jakub Jelinek ---
Reduced testcase:
/* PR target/84146 */
/* { dg-do compile } */
/* { dg-options "-O2 -g -mcet -fcf-protection=full" } */
int __setjmp (void **);
void *buf[64];
void
foo (void)
{
__setjmp (buf);
for (;;)
;
}
[Bug c++/84132] [8 Regression] tree-data-ref.c:3938: poor coding ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84132 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Richard Biener --- Fixed.
[Bug c++/84132] [8 Regression] tree-data-ref.c:3938: poor coding ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84132 --- Comment #7 from Richard Biener --- Author: rguenth Date: Wed Jan 31 13:07:53 2018 New Revision: 257232 URL: https://gcc.gnu.org/viewcvs?rev=257232&root=gcc&view=rev Log: 2018-01-31 Richard Biener PR tree-optimization/84132 * tree-data-ref.c (analyze_miv_subscript): Properly check whether evolution_function_is_affine_multivariate_p before calling gcd_of_steps_may_divide_p. * g++.dg/torture/pr84132.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/torture/pr84132.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-data-ref.c
[Bug target/84146] ICE with -mcet in dwarf2out_var_location, involving sigsetjmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84146
--- Comment #4 from Jakub Jelinek ---
Untested fix:
--- gcc/config/i386/i386.c.jj 2018-01-31 09:26:18.341505667 +0100
+++ gcc/config/i386/i386.c 2018-01-31 14:13:33.815243832 +0100
@@ -2609,31 +2609,27 @@ rest_of_insert_endbranch (void)
for (insn = BB_HEAD (bb); insn != NEXT_INSN (BB_END (bb));
insn = NEXT_INSN (insn))
{
- if (INSN_P (insn) && GET_CODE (insn) == CALL_INSN)
+ if (CALL_P (insn))
{
if (find_reg_note (insn, REG_SETJMP, NULL) == NULL)
continue;
/* Generate ENDBRANCH after CALL, which can return more than
twice, setjmp-like functions. */
- /* Skip notes and debug insns that must be next to the
-call insn. ??? This might skip a lot more than
-that... ??? Skipping barriers and emitting code
-after them surely looks like a mistake; we probably
-won't ever hit it, for we'll hit BB_END first. */
+ /* Skip notes that must immediately follow the call insn. */
rtx_insn *next_insn = insn;
- while ((next_insn != BB_END (bb))
- && (DEBUG_INSN_P (NEXT_INSN (next_insn))
- || NOTE_P (NEXT_INSN (next_insn))
- || BARRIER_P (NEXT_INSN (next_insn
- next_insn = NEXT_INSN (next_insn);
+ if (NEXT_INSN (insn)
+ && NOTE_P (NEXT_INSN (insn))
+ && (NOTE_KIND (NEXT_INSN (insn))
+ == NOTE_INSN_CALL_ARG_LOCATION))
+ next_insn = NEXT_INSN (insn);
cet_eb = gen_nop_endbr ();
emit_insn_after_setloc (cet_eb, next_insn, INSN_LOCATION (insn));
continue;
}
- if (INSN_P (insn) && JUMP_P (insn) && flag_cet_switch)
+ if (JUMP_P (insn) && flag_cet_switch)
{
rtx target = JUMP_LABEL (insn);
if (target == NULL_RTX || ANY_RETURN_P (target))
@@ -2668,7 +2664,7 @@ rest_of_insert_endbranch (void)
if ((LABEL_P (insn) && LABEL_PRESERVE_P (insn))
|| (NOTE_P (insn)
&& NOTE_KIND (insn) == NOTE_INSN_DELETED_LABEL))
-/* TODO. Check /s bit also. */
+ /* TODO. Check /s bit also. */
{
cet_eb = gen_nop_endbr ();
emit_insn_after (cet_eb, insn);
[Bug tree-optimization/82518] [8 regression] gfortran.fortran-torture/execute/in-pack.f90 fails on armeb since r252917
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82518 --- Comment #9 from Christophe Lyon --- (In reply to Aldy Hernandez from comment #7) > Hi Nick! Hi all! > > Do we have a way of testing armeb, either through a simulator or through > some aarch64 with magic flags? > Please note that the bug appears on armeb (ie. AArch32 big-endian), and not on aarch64.
[Bug target/84148] New: CET shouldn't be enabled in 32-bit run-time libraries by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84148 Bug ID: 84148 Summary: CET shouldn't be enabled in 32-bit run-time libraries by default Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: igor.v.tsimbalist at intel dot com Blocks: 81652 Target Milestone: --- ENDBR32 and RDSSPD are multi-byte NOPs on x86-64 processors and newer x86 processors. They are UD on older 32-bit processors. We should enable CET in 32-bit run-time libraries only if --enable-cet is used to configure GCC. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81652 [Bug 81652] [meta-bug] -fcf-protection=full -mcet bugs
[Bug fortran/78534] Use a larger integer type for character lengths on 64-bit targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78534 --- Comment #26 from Janne Blomqvist --- Author: jb Date: Wed Jan 31 13:23:20 2018 New Revision: 257233 URL: https://gcc.gnu.org/viewcvs?rev=257233&root=gcc&view=rev Log: PR 78534 Reinstate better string copy algorithm As part of the change to larger character lengths, the string copy algorithm was temporarily pessimized to get around some spurious -Wstringop-overflow warnings. Having tried a number of variations of this algorithm I have managed to get it down to one spurious warning, only with -O1 optimization, in the testsuite. This patch reinstates the optimized variant and modifies this one testcase to ignore the warning. Regtested on x86_64-pc-linux-gnu. gcc/fortran/ChangeLog: 2018-01-31 Janne Blomqvist PR fortran/78534 * trans-expr.c (fill_with_spaces): Use memset instead of generating loop. (gfc_trans_string_copy): Improve opportunity to use builtins with constant lengths. gcc/testsuite/ChangeLog: 2018-01-31 Janne Blomqvist PR fortran/78534 * gfortran.dg/allocate_deferred_char_scalar_1.f03: Prune -Wstringop-overflow warnings due to spurious warning with -O1. * gfortran.dg/char_cast_1.f90: Update dump scan pattern. * gfortran.dg/transfer_intrinsic_1.f90: Likewise. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/allocate_deferred_char_scalar_1.f03 trunk/gcc/testsuite/gfortran.dg/char_cast_1.f90 trunk/gcc/testsuite/gfortran.dg/transfer_intrinsic_1.f90
[Bug target/84148] CET shouldn't be enabled in 32-bit run-time libraries by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84148 Florian Weimer changed: What|Removed |Added CC||fw at gcc dot gnu.org --- Comment #1 from Florian Weimer --- How old are the CPUs which treat it as UD? Older than i686/Pentium Pro? Thanks.
[Bug target/84148] CET shouldn't be enabled in 32-bit run-time libraries by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84148 --- Comment #2 from H.J. Lu --- (In reply to Florian Weimer from comment #1) > How old are the CPUs which treat it as UD? Older than i686/Pentium Pro? > Thanks. They are NOPs since Pentium Pro.
[Bug middle-end/84089] [8 Regression] FAIL: g++.dg/cpp1y/lambda-generic-x.C -std=gnu++14 (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84089 --- Comment #5 from dave.anglin at bell dot net --- On 2018-01-31 4:57 AM, aldyh at gcc dot gnu.org wrote: > I know nothing about the PA back-end, or whether E_VOIDmode is valid for > base14_operand, however... > > Before r196122, a VOIDmode would return the default value of false in > base14_operand, but when S?mode and D?mode's were collapsed with the > aforementioned patch, we started handling VOIDmode. This can trigger a > division by 0. The untested patch below fixes this problem: > > diff --git a/gcc/config/pa/predicates.md b/gcc/config/pa/predicates.md > index 4600f988c87..f7961cc7f88 100644 > --- a/gcc/config/pa/predicates.md > +++ b/gcc/config/pa/predicates.md > @@ -275,6 +275,7 @@ > case E_BLKmode: > case E_QImode: > case E_HImode: > +case E_VOIDmode: > return true; > > Again, I have no knowledge of the PA port, and I don't know if > pa_legitimate_address_p() is supposed to even handle E_VOIDmode. Thanks very much for debugging this. I believe base14_operand should return false for VOIDmode as we can't do a check on the offset value in this case. The general intent of the check is to ensure that a base14 offset is consistent with those allowed by the PA instruction set. Arbitrary offsets are only allowed for byte and half word accesses. For integer word, double word and floating point accesses both the address register and the offset must be appropriately aligned on PA. Thus, it is safest to return false for VOIDmode in this check. A patch to add a E_VOIDmode case returning false in base14_operand is okay. Dave
[Bug ipa/84149] New: [8 Regression] SPEC CPU2017 505.mcf/605.mcf ~10% performance regression with r256888
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84149 Bug ID: 84149 Summary: [8 Regression] SPEC CPU2017 505.mcf/605.mcf ~10% performance regression with r256888 Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: alexander.nesterovskiy at intel dot com CC: marxin at gcc dot gnu.org Target Milestone: --- Minimal options to reproduce regression (x86, 64-bit): -O3 -flto The reason behind the regression is that since r256888 a cost_compare function is not inlined into spec_qsort. These two functions are in different source files. I've managed to force cost_compare to be inlined by creating in the same source file a copy of spec_qsort function with explicit calls of cost_compare. This reverted performance to r256887 level.
[Bug rtl-optimization/84071] [7/8 regression] wrong elimination of zero-extension after sign-extended load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84071 Eric Botcazou changed: What|Removed |Added CC|ebotcazou at gcc dot gnu.org | --- Comment #16 from Eric Botcazou --- > That's the best description of WORD_REGISTER_OPERATIONS I've seen - maybe we > should fix the docs to be clearer? Yes, I can add a blurb indeed. > Also I wonder whether this means AArch64 should set it since targets like > MIPS > and Sparc already set it. There seems to be a good reason against that: /* WORD_REGISTER_OPERATIONS does not hold for AArch64. The assigned word_mode is DImode but operations narrower than SImode behave as 32-bit operations if using the W-form of the registers rather than as word_mode (64-bit) operations as WORD_REGISTER_OPERATIONS expects. */ #define WORD_REGISTER_OPERATIONS 0 > Thanks for fixing this. I'm still not convinced that the logic of this is > right: > > if ((!WORD_REGISTER_OPERATIONS >/* If this is a typical RISC machine, we only have to worry > about the way loads are extended. */ >|| ((extend_op = load_extend_op (inner_mode)) == SIGN_EXTEND >? val_signbit_known_set_p (inner_mode, nonzero) >: extend_op != ZERO_EXTEND) >|| (!MEM_P (SUBREG_REG (x)) && !REG_P (SUBREG_REG (x > && xmode_width > inner_width) > > So assuming WORD_REGISTER_OPERATIONS and load_extend_op is ZERO_EXTEND, we > fall into the (!MEM_P (SUBREG_REG (x)) && !REG_P (SUBREG_REG (x))). But that > effectively means that load_extend_op applies to REG_P as well as MEM_P, > which can't be right... You need to be sure that the upper bits in the paradoxical SUBREG are preserved in the case of spilling to memory. In other words, you need to be sure that zeros in the upper bits are preserved through spilling and a simple way to do it is to require that loads be zero-extended, in case the SUBREG and not the entire REG is spilled. reload and LRA have specific code for WORD_REGISTER_OPERATIONS targets but I'm not sure they guarantee a full word spill in all cases, at least reload historically hasn't I think.
[Bug fortran/84119] Type parameter inquiry for PDT returns array instead of scalar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84119 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-31 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed.
[Bug target/84150] New: Wrong pointer size used in builtin setjmp/longjmp with -maddress-mode=long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84150
Bug ID: 84150
Summary: Wrong pointer size used in builtin setjmp/longjmp with
-maddress-mode=long
Product: gcc
Version: 6.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: igor.v.tsimbalist at intel dot com, ubizjak at gmail dot com
Target Milestone: ---
Target: x32
[hjl@gnu-6 gcc]$ cat /tmp/foo.c
void *buf[5];
void raise0(void)
{
__builtin_longjmp (buf, 1);
}
void execute(int cmd)
{
__builtin_setjmp (buf);
}
[hjl@gnu-6 gcc]$ gcc -S -O3 -mx32 /tmp/foo.c
[hjl@gnu-6 gcc]$ cat foo.s
.file "foo.c"
.text
.p2align 4,,15
.globl raise0
.type raise0, @function
raise0:
.LFB0:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movlbuf+4(%rip), %eax
movl%esp, %ebp
.cfi_def_cfa_register 6
movlbuf(%rip), %ebp
movlbuf+8(%rip), %esp
jmp *%rax
.cfi_endproc
.LFE0:
.size raise0, .-raise0
.p2align 4,,15
.globl execute
.type execute, @function
execute:
.LFB1:
.cfi_startproc
movl%esp, buf(%rip)
movl$.L5, buf+4(%rip)
movl%esp, buf+8(%rip)
ret
.L5:
.cfi_endproc
.LFE1:
.size execute, .-execute
.comm buf,20,16
[hjl@gnu-6 gcc]$ gcc -S -O3 -mx32 /tmp/foo.c -maddress-mode=long
[hjl@gnu-6 gcc]$ cat foo.s
.file "foo.c"
.text
.p2align 4,,15
.globl raise0
.type raise0, @function
raise0:
.LFB0:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movqbuf+8(%rip), %rax
movq%rsp, %rbp
.cfi_def_cfa_register 6
movqbuf(%rip), %rbp
movqbuf+16(%rip), %rsp
jmp *%rax
.cfi_endproc
.LFE0:
.size raise0, .-raise0
.p2align 4,,15
.globl execute
.type execute, @function
execute:
.LFB1:
.cfi_startproc
movq%rsp, buf(%rip) <<< Pointer size should be 4 bytes.
movq$.L5, buf+8(%rip)
movq%rsp, buf+16(%rip)
ret
.L5:
.cfi_endproc
.LFE1:
.size execute, .-execute
.comm buf,20,16
[Bug fortran/84122] Incorrect statement sequence in PDT definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84122 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-31 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed.
[Bug fortran/84143] Intrinsic output of PDT incorrectly includes type parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84143 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-31 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed. Note that print *, x%n gives 0. Should not it be 3?
[Bug rtl-optimization/84071] [7/8 regression] wrong elimination of zero-extension after sign-extended load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84071 --- Comment #18 from Eric Botcazou --- Author: ebotcazou Date: Wed Jan 31 15:01:53 2018 New Revision: 257238 URL: https://gcc.gnu.org/viewcvs?rev=257238&root=gcc&view=rev Log: PR rtl-optimization/84071 * doc/tm.texi.in (WORD_REGISTER_OPERATIONS): Add explicit case. * doc/tm.texi: Regenerate. Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/doc/tm.texi branches/gcc-7-branch/gcc/doc/tm.texi.in
[Bug rtl-optimization/84071] [7/8 regression] wrong elimination of zero-extension after sign-extended load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84071 --- Comment #17 from Eric Botcazou --- Author: ebotcazou Date: Wed Jan 31 15:01:40 2018 New Revision: 257237 URL: https://gcc.gnu.org/viewcvs?rev=257237&root=gcc&view=rev Log: PR rtl-optimization/84071 * doc/tm.texi.in (WORD_REGISTER_OPERATIONS): Add explicit case. * doc/tm.texi: Regenerate. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/tm.texi trunk/gcc/doc/tm.texi.in
[Bug fortran/84141] [8.0.1 regression] Internal error: type_name(): Bad type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84141 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-01-31 Ever confirmed|0 |1 --- Comment #6 from Dominique d'Humieres --- WORKSFORME on COLLECT_GCC=/opt/gcc/gcc8p-257013p2/bin/gfortran COLLECT_LTO_WRAPPER=/opt/gcc/gcc8p-257013p2/libexec/gcc/x86_64-apple-darwin17.3.0/8.0.1/lto-wrapper Target: x86_64-apple-darwin17.3.0 Configured with: ../p_work/configure --prefix=/opt/gcc/gcc8p-257013p2 --enable-languages=c,c++,lto,fortran,objc,obj-c++,ada --with-gmp=/opt/mp-new --with-system-zlib --enable-checking=release --with-isl=/opt/mp-new --enable-lto --enable-plugin --with-arch=corei7 --with-cpu=corei7 Thread model: posix gcc version 8.0.1 20180124 (experimental) [trunk revision 257013p2] (GCC) or COLLECT_GCC=gfc COLLECT_LTO_WRAPPER=/opt/gcc/gcc8w/libexec/gcc/x86_64-apple-darwin17.4.0/8.0.1/lto-wrapper Target: x86_64-apple-darwin17.4.0 Configured with: ../work/configure --prefix=/opt/gcc/gcc8w --enable-languages=c,c++,fortran,objc,obj-c++,ada,lto --with-gmp=/opt/mp-new --with-system-zlib --with-isl=/opt/mp-new --enable-lto --enable-plugin --with-arch=corei7 --with-cpu=corei7 Thread model: posix gcc version 8.0.1 20180130 (experimental) [trunk revision 257200p15] (GCC) Could you please try to find which file(s) is(are) miscompiled?
[Bug fortran/84141] [8.0.1 regression] Internal error: type_name(): Bad type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84141 --- Comment #7 from Jürgen Reuter --- We reproduced this on Darwin 17.4.0 and OpenSuSe Leap 42.2 Linux and within a Docker Image running Ubuntu LTS. The two cases on Linux are the test example of which I extracted the smaller reproducer.
[Bug target/82641] Unable to enable crc32 for a certain function with target attribute on ARM (aarch32)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82641 --- Comment #26 from Richard Earnshaw --- (In reply to Arnd Bergmann from comment #25) > or to apply more force and add the ".arch" to each inline > asm individually. No, that would not be guaranteed to be supported: and you'd be lying to the compiler again. At the end of each asm block the compiler *could* emit new .arch directive to forcibly reset the architecture to what IT thinks it should be.
[Bug fortran/84116] [7/8 Regression] ICE in gfc_match_omp_clauses, at fortran/openmp.c:1354
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84116 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-31 CC||jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Likely r242037.
[Bug c++/84138] [8 Regression] ICE folding broken constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84138 --- Comment #3 from Marek Polacek --- Author: mpolacek Date: Wed Jan 31 15:37:18 2018 New Revision: 257240 URL: https://gcc.gnu.org/viewcvs?rev=257240&root=gcc&view=rev Log: PR c++/84138 * cp-gimplify.c (cp_fold): Check if X is an error node before calling useless_type_conversion_p. * g++.dg/diagnostic/pr84138.C: New test. Added: trunk/gcc/testsuite/g++.dg/diagnostic/pr84138.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-gimplify.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/84141] [8.0.1 regression] Internal error: type_name(): Bad type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84141 --- Comment #8 from Dominique d'Humieres --- Pass with r257125.
[Bug c++/84138] [8 Regression] ICE folding broken constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84138 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Marek Polacek --- Fixed.
[Bug fortran/84141] [8.0.1 regression] Internal error: type_name(): Bad type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84141 --- Comment #9 from Jürgen Reuter --- Let me put a little smaller reproducer.
[Bug fortran/84141] [8.0.1 regression] Internal error: type_name(): Bad type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84141 --- Comment #10 from Jürgen Reuter --- Created attachment 43307 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43307&action=edit Reproducer_2, a little smaller
[Bug fortran/84141] [8.0.1 regression] Internal error: type_name(): Bad type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84141 --- Comment #11 from Jürgen Reuter --- When you run the binary created (seg_prod), you'll get | | Running self-test: mci_vamp | Running test: mci_vamp_7Internal Error: type_name(): Bad type Error termination. Backtrace: #0 0x10d68a64c #1 0x10d68b2e5 #2 0x10d68b79d #3 0x10d85ce46 #4 0x10d85cec8 #5 0x10d85fc40 #6 0x10d8601b4 #7 0x10d85d258 #8 0x10d613690 #9 0x10d61347a #10 0x10d659b44 #11 0x10d65ea5e #12 0x10d5c649e #13 0x10d6602c6 #14 0x10d6609ce #15 0x10d6616d6 #16 0x10d661775
[Bug tree-optimization/84136] [6/7/8 Regression] ICE with goto to an && label in another function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84136 --- Comment #3 from David Malcolm --- Discussion/patch: https://gcc.gnu.org/ml/gcc-patches/2018-01/msg02451.html
[Bug c++/67935] internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67935 Marek Polacek changed: What|Removed |Added Status|NEW |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #5 from Marek Polacek --- Fixed in r233512.
[Bug fortran/84116] [7/8 Regression] ICE in gfc_match_omp_clauses, at fortran/openmp.c:1354
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84116 --- Comment #2 from Jakub Jelinek --- Indeed, started with r242037.
[Bug c++/84151] New: [4.9/5/6/7 Regression] g++ generates two identical loads in a volatile-qualified member function.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84151
Bug ID: 84151
Summary: [4.9/5/6/7 Regression] g++ generates two identical
loads in a volatile-qualified member function.
Product: gcc
Version: 7.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: wasing at mail dot ru
Target Milestone: ---
The g++ generates two identical loads when the "foo" member function is called
in the following test case:
struct A {
static int& bar(int& a) {
return a;
}
int foo() volatile {
int v = c;
return bar(v);
}
int c;
};
A a;
int main() {
a.c = 2;
a.foo();
return 0;
}
The -O2 options is used to get the following assembler:
.file "test_atomic.cpp"
.section.text.startup,"ax",@progbits
.p2align 4,,15
.globl main
.type main, @function
main:
.LFB2:
.cfi_startproc
movl$2, a(%rip)
movla(%rip), %eax
movla(%rip), %eax // !!!DUPLICATED
xorl%eax, %eax
ret
.cfi_endproc
.LFE2:
.size main, .-main
.globl a
.bss
.align 4
.type a, @object
.size a, 4
a:
.zero 4
.ident "GCC: (GNU) 7.2.1 20170915 (Red Hat 7.2.1-2)"
.section.note.GNU-stack,"",@progbits
The "movl a(%rip), %eax" line is repeated twice. The
https://godbolt.org/g/yhQtDw reproduces the issue on many versions newer 4.8.
[Bug c++/84092] [8 Regression] ICE on C++14 code with variable template: in build_qualified_name, at cp/tree.c:2043
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84092 --- Comment #3 from paolo at gcc dot gnu.org --- Author: paolo Date: Wed Jan 31 16:07:06 2018 New Revision: 257242 URL: https://gcc.gnu.org/viewcvs?rev=257242&root=gcc&view=rev Log: /cp 2018-01-31 Paolo Carlini PR c++/84092 * semantics.c (finish_qualified_id_expr): When handling an UNBOUND_CLASS_TEMPLATE only adjust qualifying_class and expr. /testsuite 2018-01-31 Paolo Carlini PR c++/84092 * g++.dg/cpp1y/var-templ57.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp1y/var-templ57.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog
[Bug c++/84092] [8 Regression] ICE on C++14 code with variable template: in build_qualified_name, at cp/tree.c:2043
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84092 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org --- Comment #4 from Paolo Carlini --- Fixed.
[Bug c++/84152] New: Internal compiler error when compiling a cxx file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84152 Bug ID: 84152 Summary: Internal compiler error when compiling a cxx file Product: gcc Version: 7.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: drohr at jwdt dot org Target Milestone: --- Created attachment 43308 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43308&action=edit preprocessed source file to trigger the segfault gcc encounters an internal compiler error when compiling our software. I have preprocessed the affected source file and attached to this bug report. The command line to trigger the problem is: c++ -O3 -march=native -c ~/tmp/gcccrash.cxx -o ~/tmp/gcccrash.cxx.o I am running gentoo linux 64 bit, gcc 7.3.0, glibc 2.26, kernel 2.15. CPU model is Intel(R) Core(TM) i7-6700K. The problem appears only when the -O3 and the -march=native options are present.
[Bug c++/84152] Internal compiler error when compiling a cxx file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84152 David Malcolm changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org --- Comment #1 from David Malcolm --- Thanks for filing this; I was able to reproduce it on one machine, with gcc 7 but not gcc 8. Am investigating further. internal compiler error: in predicate_mem_writes, at tree-if-conv.c:2252 void AliAnalysisTaskZDCTree::UserExec(Option_t * ) ^~ 0x5bfb02 predicate_mem_writes ../../src/gcc/tree-if-conv.c:2252 0x5bfb02 combine_blocks ../../src/gcc/tree-if-conv.c:2377 0xbef9bf tree_if_conversion(loop*) ../../src/gcc/tree-if-conv.c:2883 0xbeffdb execute ../../src/gcc/tree-if-conv.c:2961 2252 gcc_assert (TREE_CODE (cond) == SSA_NAME); (gdb) call debug_tree (cond) constant 0>
[Bug c++/84152] Internal compiler error when compiling a cxx file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84152 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- Looks like it needs -march=haswell. I couldn't reproduce it with trunk, though.
[Bug fortran/84143] Intrinsic output of PDT incorrectly includes type parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84143 --- Comment #2 from Neil Carlson --- (In reply to Dominique d'Humieres from comment #1) > > gives 0. Should not it be 3? Yeah. I noticed the same thing myself. It is 3 if the type parameters are removed. I was intending to report it, but I thought I might have seen a similar PR linked from the PDT meta bug and was going to look again before doing so.
[Bug fortran/84141] [8.0.1 regression] Internal error: type_name(): Bad type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84141 Dominique d'Humieres changed: What|Removed |Added Keywords||wrong-code Status|WAITING |NEW CC||pault at gcc dot gnu.org --- Comment #12 from Dominique d'Humieres --- > Reproducer_2, a little smaller For this test, r257013 is OK, and I get an ICE with r257125: r257065? Related to/duplicate of pr84088?
[Bug middle-end/84150] Wrong pointer size used in builtin setjmp/longjmp with -maddress-mode=long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84150
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-01-31
CC||ebotcazou at gcc dot gnu.org
Component|target |middle-end
Ever confirmed|0 |1
--- Comment #1 from H.J. Lu ---
A run-time testcase:
[hjl@gnu-skx-1 pr84150]$ cat x.i
void *buf[6] = {
(void *) -1,
(void *) -1,
(void *) -1,
(void *) -1,
(void *) -1,
(void *) -1
};
void raise0(void)
{
__builtin_longjmp (buf, 1);
}
int execute(int cmd)
{
int last = 0;
if (__builtin_setjmp (buf) == 0)
while (1)
{
last = 1;
raise0 ();
}
if (last == 0)
return 0;
else
return cmd;
}
int main(void)
{
if (execute (1) == 0)
__builtin_abort ();
if (buf[5] != (void *) -1)
__builtin_abort ();
return 0;
}
[hjl@gnu-skx-1 pr84150]$ make CC=gcc
gcc -O2 -mx32 -maddress-mode=long -S x.i
gcc -O2 -mx32 -maddress-mode=long -o x x.s
./x
make: *** [Makefile:13: all] Aborted
[hjl@gnu-skx-1 pr84150]$
expand_builtin_setjmp_setup and expand_builtin_longjmp shouldn't use Pmode
to save and store SP, FP and IP into (void *) slots, which are ptr_mode,
32 bits.
[Bug middle-end/84150] Wrong pointer size used in builtin setjmp/longjmp with -maddress-mode=long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84150 --- Comment #2 from H.J. Lu --- This test will fail on all ILP32 targets where Pmode == DImode and ptr_mode == SImode.
[Bug rtl-optimization/84071] [7/8 regression] wrong elimination of zero-extension after sign-extended load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84071 --- Comment #19 from Wilco --- (In reply to Eric Botcazou from comment #16) > > Also I wonder whether this means AArch64 should set it since targets like > > MIPS > > and Sparc already set it. > > There seems to be a good reason against that: > > /* WORD_REGISTER_OPERATIONS does not hold for AArch64. >The assigned word_mode is DImode but operations narrower than SImode >behave as 32-bit operations if using the W-form of the registers rather >than as word_mode (64-bit) operations as WORD_REGISTER_OPERATIONS >expects. */ > #define WORD_REGISTER_OPERATIONS 0 How is this any different from 32-bit operations in say MIPS? The only difference seems to be that MIPS sign-extends 32-bit operations to 64 bit while AArch64 zero-extends. If that's correct for MIPS it seems that WORD_REGISTER_OPERATIONS only applies to types smaller than SImode.
[Bug c++/84127] pragmas to disable -Wexpansion-to-defined compiler warnings seems to be broken since 7.x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84127 Martin Sebor changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Martin Sebor --- You're right, it's a duplicated of bug 53431. *** This bug has been marked as a duplicate of bug 53431 ***
[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431 Martin Sebor changed: What|Removed |Added CC||davydden at gmail dot com --- Comment #33 from Martin Sebor --- *** Bug 84127 has been marked as a duplicate of this bug. ***
[Bug target/84113] [7/8 Regression] gcc-7.3.0/libgcc/unwind.inc:136:1: internal compiler error: in extract_insn, at recog.c:2311
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84113
Douglas Mencken changed:
What|Removed |Added
Known to fail||7.1.0, 7.2.0
--- Comment #6 from Douglas Mencken ---
the same problem with gcc 7.2
../../../gcc-7.2.0/libgcc/unwind.inc:136:1: error: unrecognizable insn:
}
^
(jump_insn/f 178 177 179 14 (parallel [
(return)
(use (symbol_ref:SI ("*eh_rest_world_r10")))
(clobber (reg:SI 11 r11))
(set (reg:SI 70 cr2)
...
and with gcc 7.1
../../../gcc-7.1.0/libgcc/unwind.inc: In function '_Unwind_RaiseException':
../../../gcc-7.1.0/libgcc/unwind.inc:136:1: error: unrecognizable insn:
}
^
(jump_insn/f 178 177 179 14 (parallel [
(return)
(use (symbol_ref:SI ("*eh_rest_world_r10")))
(clobber (reg:SI 11 r11))
(set (reg:SI 70 cr2)
(mem/c:SI (plus:SI (reg/f:SI 1 r1)
(const_int 4 [0x4])) [29 S4 A8]))
(set (reg:SI 13 r13)
...
[Bug target/84113] [7/8 Regression] gcc-7.3.0/libgcc/unwind.inc:136:1: internal compiler error: in extract_insn, at recog.c:2311
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84113 Douglas Mencken changed: What|Removed |Added Known to work||6.4.0 --- Comment #7 from Douglas Mencken --- 6.4 is okay
[Bug target/84113] [7/8 Regression] gcc-7.3.0/libgcc/unwind.inc:136:1: internal compiler error: in extract_insn, at recog.c:2311
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84113
--- Comment #8 from Douglas Mencken ---
(In reply to Jakub Jelinek from comment #4)
> (In reply to Segher Boessenkool from comment #2)
> > You cut away the most interesting part: the insn pattern that does not
> > exist.
> > Could you show us?
>
> It is in the #c0 attachment:
> (jump_insn/f 178 177 179 14 (parallel [
> (return)
> (use (symbol_ref:SI ("*eh_rest_world_r10")))
> (clobber (reg:SI 11 r11))
> (set (reg:SI 70 cr2)
> (mem/c:SI (plus:SI (reg/f:SI 1 r1)
Thanks for copying it here, but why you lowered “importance” to “P4”?
[Bug bootstrap/80867] gnat bootstrap broken on powerpc64le-linux-gnu with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80867 --- Comment #12 from kelvin at gcc dot gnu.org --- Author: kelvin Date: Wed Jan 31 18:22:19 2018 New Revision: 257248 URL: https://gcc.gnu.org/viewcvs?rev=257248&root=gcc&view=rev Log: gcc/ChangeLog: 2018-01-31 Richard Biener Kelvin Nilsen Backport from mainline 2018-01-29 Richard Biener Kelvin Nilsen PR bootstrap/80867 * tree-vect-stmts.c (vectorizable_call): Don't call targetm.vectorize_builtin_md_vectorized_function if callee is NULL. Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/tree-vect-stmts.c
