[Bug ipa/78555] New: gcc/sreal.c:232:20: runtime error: left shift of negative value -2018967552
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78555
Bug ID: 78555
Summary: gcc/sreal.c:232:20: runtime error: left shift of
negative value -2018967552
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: trippels at gcc dot gnu.org
Target Milestone: ---
bootstrap-ubsan on ppc64le hits the following error very often:
gcc/sreal.c:232:20: runtime error: left shift of negative value -2018967552
I will test:
diff --git a/gcc/sreal.c b/gcc/sreal.c
index 9c43b4e..ceb63b7 100644
--- a/gcc/sreal.c
+++ b/gcc/sreal.c
@@ -227,9 +227,10 @@ sreal::operator* (const sreal &other) const
sreal
sreal::operator/ (const sreal &other) const
{
+ int64_t sign = m_sig < 0 ? -1 : 1;
gcc_checking_assert (other.m_sig != 0);
sreal r;
- r.m_sig = (m_sig << SREAL_PART_BITS) / other.m_sig;
+ r.m_sig = sign * (absu_hwi (m_sig) << SREAL_PART_BITS) / other.m_sig;
r.m_exp = m_exp - other.m_exp - SREAL_PART_BITS;
r.normalize ();
return r;
[Bug target/78556] New: config/rs6000/rs6000.c:6217:36: runtime error: left shift of negative value -12301
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78556 Bug ID: 78556 Summary: config/rs6000/rs6000.c:6217:36: runtime error: left shift of negative value -12301 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: trippels at gcc dot gnu.org Target Milestone: --- Host: powerpc64le-unknown-linux-gnu Target: powerpc64le-unknown-linux-gnu Build: powerpc64le-unknown-linux-gnu On powerpc64le-unknown-linux-gnu during bootstrap-ubsan: config/rs6000/rs6000.c:6217:36: runtime error: left shift of negative value -12301 I will test: diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c index 6c28e6a..1ec43c7 100644 --- a/gcc/config/rs6000/rs6000.c +++ b/gcc/config/rs6000/rs6000.c @@ -6214,7 +6214,7 @@ vspltis_constant (rtx op, unsigned step, unsigned copies) bitsize /= 2; small_val = splat_val >> bitsize; mask >>= bitsize; - if (splat_val != ((small_val << bitsize) | (small_val & mask))) + if (splat_val != ((UINTVAL (small_val) << bitsize) | (small_val & mask))) return false; splat_val = small_val; }
[Bug target/78556] config/rs6000/rs6000.c:6217:36: runtime error: left shift of negative value -12301
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78556 --- Comment #1 from Markus Trippelsdorf --- Sorry, should be: diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c index 6c28e6a..89751c5 100644 --- a/gcc/config/rs6000/rs6000.c +++ b/gcc/config/rs6000/rs6000.c @@ -6214,7 +6214,7 @@ vspltis_constant (rtx op, unsigned step, unsigned copies) bitsize /= 2; small_val = splat_val >> bitsize; mask >>= bitsize; - if (splat_val != ((small_val << bitsize) | (small_val & mask))) + if (splat_val != ((absu_hwi (small_val) << bitsize) | (small_val & mask))) return false; splat_val = small_val; }
[Bug target/41076] [avr] pessimal code for logical OR of 8-bit fields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41076 --- Comment #8 from Georg-Johann Lay --- Author: gjl Date: Mon Nov 28 08:40:11 2016 New Revision: 242907 URL: https://gcc.gnu.org/viewcvs?rev=242907&root=gcc&view=rev Log: PR 41076 * config/avr/avr.md (SPLIT34): New mode iterator. (bitop): New code iterator. (*iorhi3.ashift8-*). New insn-and-split patterns. (*movhi): Post-reload split reg = 0. [!MOVW]: Post-reload split reg = reg. (*mov) [SI,SF,PSI,SQ,USQ,SA,USA]: Post-reload split reg = reg. (andhi3, andpsi3, andsi3): Post-reload split reg-reg operations. (iorhi3, iorpsi3, iorsi3): Same. (xorhi3, xorpsi3, xorsi3): Same. * config/avr/avr.c (avr_rtx_costs_1) [IOR && HImode]: Adjust rtx costs to *iorhi3.ashift8-* patterns. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.c trunk/gcc/config/avr/avr.md
[Bug target/41076] [avr] pessimal code for logical OR of 8-bit fields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41076 Georg-Johann Lay changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |7.0 --- Comment #9 from Georg-Johann Lay --- Fixed in v7 (hope so).
[Bug tree-optimization/65964] [meta] Operand Shortening
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65964 Bug 65964 depends on bug 41076, which changed state. Bug 41076 Summary: [avr] pessimal code for logical OR of 8-bit fields https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41076 What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED
[Bug libgomp/78468] [7 regression] libgomp.c/reduction-10.c and many more FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468 --- Comment #19 from Eric Botcazou --- > Another approach may be to make the middleend ask the backend for the actual > value of REGNO_POINTER_ALIGN (VIRTUAL_STACK_DYNAMIC_REGNUM). Since on Sparc > the address is always 4 mod 8, we'd get an additional gap for *each* > alloca() if the size is still required to be a multiple of STACK_BOUNDARY. I think that the patch is simply incorrect and should be reverted, it very likely breaks other ports than PowerPC and SPARC and the failure more is quite nasty. IMO it's fundamentally backwards: instead of making it so that the alignment of VIRTUAL_STACK_DYNAMIC_REGNUM is honored by every dynamic allocation, it assumes that it is already honored to optimize the dynamic allocation.
[Bug target/78546] [6/7 Regression] wrong code at -O2 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78546 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-11-28 CC||jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from Jakub Jelinek --- Started with r225825.
[Bug tree-optimization/78528] Recursion not optimized for structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78528 --- Comment #3 from Richard Biener --- And I don't see how we can easily do this (or why it should be worth all the hassle).
[Bug tree-optimization/78529] [7 Regression] gcc.c-torture/execute/builtins/strcat-chk.c failed with lto/O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78529 Richard Biener changed: What|Removed |Added Keywords||lto Target||aarch64 Component|lto |tree-optimization Target Milestone|--- |7.0 Summary|gcc.c-torture/execute/built |[7 Regression] |ins/strcat-chk.c failed |gcc.c-torture/execute/built |with lto/O2 |ins/strcat-chk.c failed ||with lto/O2 --- Comment #1 from Richard Biener --- Note this might be an artifact of how these tests are set up (implemeting their own builtins).
[Bug rtl-optimization/78120] [6/7 Regression] If conversion no longer performed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78120 --- Comment #13 from Bernd Schmidt --- Author: bernds Date: Mon Nov 28 08:59:01 2016 New Revision: 242908 URL: https://gcc.gnu.org/viewcvs?rev=242908&root=gcc&view=rev Log: PR rtl-optimization/78120 * rtlanal.c (insn_rtx_cost): Revert previous change. Modified: trunk/gcc/ChangeLog trunk/gcc/rtlanal.c
[Bug tree-optimization/78533] tree check fail in int_fits_type_p, at tree.c:9153
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78533 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Richard Biener --- dup *** This bug has been marked as a duplicate of bug 78507 ***
[Bug middle-end/78507] [7 Regression] ICE: tree check: expected integer_type or enumeral_type or boolean_type or real_type or fixed_point_type, have pointer_type in int_fits_type_p, at tree.c:9153
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78507 Richard Biener changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #7 from Richard Biener --- *** Bug 78533 has been marked as a duplicate of this bug. ***
[Bug target/78546] [6/7 Regression] wrong code at -O2 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78546
--- Comment #5 from Jakub Jelinek ---
But e.g.
typedef unsigned __int128 u128;
u128 b;
int
main ()
{
u128 x = ((u128) ~0x7fff) - b;
u128 y = 1 - x;
if (y != 0x8001)
__builtin_abort();
return 0;
}
is miscompiled already before that, bisecting again.
[Bug ipa/78535] [6.2] invalid code generation with -O1 -fdevirtualize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78535 Richard Biener changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #2 from Richard Biener --- Works on x86_64-linux. Can you attach -fdump-ipa-devirt-details dump please?
[Bug c/78539] feature request: __noextension__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78539 Richard Biener changed: What|Removed |Added Severity|normal |enhancement
[Bug tree-optimization/78542] [7 Regression] wrong code at -Og results in endless loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78542 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- I will have a look.
[Bug target/78546] [6/7 Regression] wrong code at -O2 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78546 Richard Biener changed: What|Removed |Added Priority|P1 |P2 CC||rguenth at gcc dot gnu.org Known to work||5.4.0 Known to fail||6.1.0
[Bug target/78546] [6/7 Regression] wrong code at -O2 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78546 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- That started with r217349. I'll have a look.
[Bug middle-end/78540] [6/7 Regression] ICE: in df_refs_verify, at df-scan.c:4062 with -O -march=core2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78540 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-11-28 CC||marxin at gcc dot gnu.org, ||rth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, started with r234196.
[Bug sanitizer/78541] [7 Regression] ICE when compiling libquadmath/printf/printf_fp.c with -fsanitize=address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78541 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-11-28 CC||marxin at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Mine.
[Bug c/78548] ice on valid C code on x86_64-linux-gnu at -O2 and -O3 in 64-bit mode with -Wall (*** Error in `/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/cc1': double free or corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78548 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Known to work||6.2.1 --- Comment #1 from Richard Biener --- Works on the GCC 6 branch (but I also fail to reproduce on trunk)
[Bug c++/78550] [6/7 Regression] bit field and std::initializer_list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78550 Richard Biener changed: What|Removed |Added Keywords||rejects-valid Target Milestone|--- |6.3
[Bug c++/78551] [5/6/7 Regression] Internal compiler error with constexpr initialization of union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78551
Richard Biener changed:
What|Removed |Added
Keywords||ice-on-invalid-code
Known to work||4.9.4
Target Milestone|--- |5.5
Summary|Internal compiler error |[5/6/7 Regression] Internal
|with constexpr |compiler error with
|initialization of union |constexpr initialization of
||union
Known to fail||5.4.0, 6.2.0, 7.0
--- Comment #3 from Richard Biener ---
ICEs in
t.C:20:53: internal compiler error: in output_constructor_regular_field, at
varasm.c:4968
constexpr std::array array({"long", "longer"});
^
GCC 4.9 rejects it, so does clang++:
> clang++ t.C -S -std=gnu++14
t.C:20:28: error: constexpr variable 'array' must be initialized by a constant
expression
constexpr std::array array({"long", "longer"});
^
t.C:14:22: note: assignment to member 'buff' of union with active member 's' is
not allowed in a constant expression
buff[i] = str[i];
^
t.C:20:35: note: in call to 'A(&"long"[0])'
constexpr std::array array({"long", "longer"});
^
1 error generated.
Backtrace from GCC 6 branch head:
> /space/rguenther/install/gcc-6.2/bin/g++ t.ii -B /abuild/rguenther/gcc6-g/gcc
t.C:20:53: internal compiler error: in output_constructor_regular_field, at
varasm.c:4968
constexpr std::array array({"long", "longer"});
^
0x14386b5 output_constructor_regular_field
/space/rguenther/src/svn/gcc-6-branch/gcc/varasm.c:4968
0x14394c1 output_constructor
/space/rguenther/src/svn/gcc-6-branch/gcc/varasm.c:5276
0x1437f16 output_constant
/space/rguenther/src/svn/gcc-6-branch/gcc/varasm.c:4803
0x143897b output_constructor_regular_field
/space/rguenther/src/svn/gcc-6-branch/gcc/varasm.c:5006
0x14394c1 output_constructor
/space/rguenther/src/svn/gcc-6-branch/gcc/varasm.c:5276
0x1437f16 output_constant
/space/rguenther/src/svn/gcc-6-branch/gcc/varasm.c:4803
0x143897b output_constructor_regular_field
/space/rguenther/src/svn/gcc-6-branch/gcc/varasm.c:5006
0x14394c1 output_constructor
/space/rguenther/src/svn/gcc-6-branch/gcc/varasm.c:5276
0x1437bd8 output_constant
/space/rguenther/src/svn/gcc-6-branch/gcc/varasm.c:4773
0x143897b output_constructor_regular_field
/space/rguenther/src/svn/gcc-6-branch/gcc/varasm.c:5006
0x14394c1 output_constructor
/space/rguenther/src/svn/gcc-6-branch/gcc/varasm.c:5276
0x1437f16 output_constant
/space/rguenther/src/svn/gcc-6-branch/gcc/varasm.c:4803
0x142f4d9 assemble_variable_contents
/space/rguenther/src/svn/gcc-6-branch/gcc/varasm.c:2062
0x142fe82 assemble_variable(tree_node*, int, int, int)
/space/rguenther/src/svn/gcc-6-branch/gcc/varasm.c:2238
0x1447096 varpool_node::assemble_decl()
/space/rguenther/src/svn/gcc-6-branch/gcc/varpool.c:582
0xbb40d9 output_in_order
/space/rguenther/src/svn/gcc-6-branch/gcc/cgraphunit.c:2231
0xbb4784 symbol_table::compile()
/space/rguenther/src/svn/gcc-6-branch/gcc/cgraphunit.c:2468
0xbb49c3 symbol_table::finalize_compilation_unit()
/space/rguenther/src/svn/gcc-6-branch/gcc/cgraphunit.c:2564
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
[Bug rtl-optimization/78547] [7 Regression] ICE: in loc_cmp, at var-tracking.c:3417 with -Os -g -mstringop-strategy=libcall -freorder-blocks-algorithm=simple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78547 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-11-28 CC||jgreenhalgh at gcc dot gnu.org, ||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, started with r238594.
[Bug fortran/78557] New: [7.0 regression] ICE in trans-expr.c with -fcheck=all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78557 Bug ID: 78557 Summary: [7.0 regression] ICE in trans-expr.c with -fcheck=all Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: juergen.reuter at desy dot de Target Milestone: --- Created attachment 40171 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40171&action=edit Source code that triggers the ICE. With the following code (also attached) I get an ICE in trans-expr.c as gfortran -fcheck=all -c sf_isr_uti.f90 sf_isr_uti.f90:39:0: allocate (t3 :: sf_int (2)) internal compiler error: in gfc_trans_assignment_1, at fortran/trans-expr.c:9771 sf_isr_uti.f90:39:0: internal compiler error: Abort trap: 6 gfortran: internal compiler error: Abort trap: 6 (program f951) The code correctly compiles with default options, but throws the ICE with -fcheck=all. At least with 4.8.4 and 4.9.4 this was working. Here is the code (also attached): module interactions implicit none private public :: t1 type :: t1 private logical, dimension(:), allocatable :: flag contains procedure :: basic_init => t1_init end type t1 contains subroutine t1_init (int) class(t1), intent(out) :: int int%flag = .false. end subroutine t1_init end module interactions ! module foo_uti use interactions implicit none private type, abstract, extends (t1) :: t2 end type t2 type, extends (t2) :: t3 end type t3 contains subroutine foo () class(t3), dimension(:), allocatable :: sf_int allocate (t3 :: sf_int (2)) end subroutine foo end module foo_uti
[Bug c/78548] ice on valid C code on x86_64-linux-gnu at -O2 and -O3 in 64-bit mode with -Wall (*** Error in `/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/cc1': double free or corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78548
Zhendong Su changed:
What|Removed |Added
CC||su at cs dot ucdavis.edu
--- Comment #2 from Zhendong Su ---
I can still reproduce it with r242892 with "-Wall -w -O3 -m64". Interestingly,
without "-m64", GCC hangs, instead of crashing.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20161127 (experimental) [trunk revision 242892] (GCC)
$
$ gcc-trunk -Wall -w -O3 -m64 small.c
*** Error in `/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/cc1':
double free or corruption (fasttop): 0x038273b0 ***
small.c: In function ‘main’:
small.c:6:5: internal compiler error: Aborted
int main ( ) {
^~~~
0xbfe10f crash_signal
../../gcc-source-trunk/gcc/toplev.c:333
0xe1c630 xcallocator::data_free(gimple**)
../../gcc-source-trunk/gcc/hash-table.h:273
0xe1c630 ~hash_table
../../gcc-source-trunk/gcc/hash-table.h:627
0xe1c630 ~hash_set
../../gcc-source-trunk/gcc/hash-set.h:25
0xe1c630 find_def_preds
../../gcc-source-trunk/gcc/tree-ssa-uninit.c:775
0xe1c630 is_use_properly_guarded
../../gcc-source-trunk/gcc/tree-ssa-uninit.c:2375
0xe1da0a find_uninit_use
../../gcc-source-trunk/gcc/tree-ssa-uninit.c:2434
0xe1da0a warn_uninitialized_phi
../../gcc-source-trunk/gcc/tree-ssa-uninit.c:2504
0xe1da0a execute
../../gcc-source-trunk/gcc/tree-ssa-uninit.c:2612
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
$
[Bug fortran/78557] [7.0 regression] ICE in trans-expr.c with -fcheck=all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78557 --- Comment #1 from Jürgen Reuter --- Oh, I'm using r241975 of the gcc trunk.
[Bug c/78548] [7 Regression ]ICE on valid C code on x86_64-linux-gnu at -O2 and -O3 in 64-bit mode with -Wall (*** Error in `/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/cc1': double fre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78548 Martin Liška changed: What|Removed |Added Keywords||ice-on-valid-code Last reconfirmed||2016-11-28 CC||aldyh at gcc dot gnu.org, ||marxin at gcc dot gnu.org Summary|ice on valid C code on |[7 Regression ]ICE on valid |x86_64-linux-gnu at -O2 and |C code on x86_64-linux-gnu |-O3 in 64-bit mode with |at -O2 and -O3 in 64-bit |-Wall (*** Error in |mode with -Wall (*** Error |`/usr/local/gcc-trunk/libex |in |ec/gcc/x86_64-pc-linux-gnu/ |`/usr/local/gcc-trunk/libex |7.0.0/cc1': double free or |ec/gcc/x86_64-pc-linux-gnu/ |corruption (fasttop): |7.0.0/cc1': double free or |0x03c15810 ***) |corruption (fasttop): ||0x03c15810 ***) --- Comment #3 from Martin Liška --- Confirmed, started with r242639.
[Bug target/78546] [6/7 Regression] wrong code at -O2 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78546 --- Comment #7 from Jakub Jelinek --- Preliminary analysis shows 2 issues. 1) r217349 regressed an optimization, before that change we have been able to b.0_2 = b; x_3 = 0x8000 - b.0_2; y_4 = 1 - x_3; if (y_4 != 9223372036854775809) gimple_simplified to y_4 = b.0_2 + 9223372036854775809; Replaced 'y_4 != 9223372036854775809' with 'b.0_2 != 0' into: b.0_2 = b; x_3 = 0x8000 - b.0_2; if (b.0_2 != 0) but we no longer are able to do that. 2) simplify-rtx.c opts during combine attempt to do the similar transformation, but do it incorrectly, 1 - (0x8000 - b) is turned into (b + 0x8001) rather than (b + 0x8001). I'll debug 2) now.
[Bug c++/78551] [5/6/7 Regression] Internal compiler error with constexpr initialization of union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78551 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-11-28 CC||marxin at gcc dot gnu.org, ||nathan at gcc dot gnu.org Known to work||5.3.0 Ever confirmed|0 |1 --- Comment #4 from Martin Liška --- Confirmed, started on trunk with r234636. It was also backported to GCC 5.4.0.
[Bug ipa/78555] gcc/sreal.c:232:20: runtime error: left shift of negative value -2018967552
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78555 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-11-28 CC||marxin at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- That's mine, I'm going to write some tests to sreal unit tests.
[Bug c++/78558] New: Incorrect loop optimization leads to crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78558 Bug ID: 78558 Summary: Incorrect loop optimization leads to crash Product: gcc Version: 5.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: Anton.Grichina at harmonicinc dot com Target Milestone: --- Created attachment 40172 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40172&action=edit main.cpp GCC optimizes loop using SSE instructions (in this case "movdqa"), but for some reason memory alignment is wrong and application crashes in run-time. I attached the code. It crashes in "copy_stats" and "copy_stats1". Compiled with: g++ -o main -O3 -std=c++11 main.cpp (compiling with -fno-strict-aliasing -fwrapv and -Wall -Wextra does not change behavior or show anything useful) Target: x86_64-linux-gnu I`ve ran it in gdb to see what happens: (gdb) run Starting program: /home/agrichin/test/align_bug/main Program received signal SIGSEGV, Segmentation fault. 0x004004e8 in main () In asm layout I see: 0x4004e8 movdqa (%rax),%xmm0 And this is content of rax: (gdb) info registers rax0x6010d8 6295768 Memory aligned to 8, not to 16. This bug reproducible with O3 on GCC 5.4 . On GCC 4.8.4 it is not reproducible. Workarounds to overcome this bug: 1. Remove/reorder fields in Session structure 2. Remove "copy_stats" function from source 3. Compile with O2 4. Use older compiler, it is not reproducible with 4.8.4
[Bug fortran/78557] [7 Regression] ICE in trans-expr.c with -fcheck=all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78557 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-11-28 CC||marxin at gcc dot gnu.org, ||vehre at gmx dot de Target Milestone|--- |7.0 Summary|[7.0 regression] ICE in |[7 Regression] ICE in |trans-expr.c with |trans-expr.c with |-fcheck=all |-fcheck=all Ever confirmed|0 |1 Known to fail||7.0 --- Comment #2 from Martin Liška --- Confirmed, started with r241439.
[Bug libstdc++/78264] [7 regression] ICE in build_noexcept_spec, at cp/except.c:1196
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78264 Eric Botcazou changed: What|Removed |Added Target|i386-pc-solaris2.12,|i386-pc-solaris2.12, |sparc-sun-solaris2.12, |sparc-sun-solaris2.12, |x86-64-linux-gnu| CC||ebotcazou at gcc dot gnu.org Component|c++ |libstdc++ Host|i386-pc-solaris2.12,|i386-pc-solaris2.12, |sparc-sun-solaris2.12, |sparc-sun-solaris2.12 |x86-64-linux-gnu| Build|i386-pc-solaris2.12,|i386-pc-solaris2.12, |sparc-sun-solaris2.12, |sparc-sun-solaris2.12 |x86-64-linux-gnu| Severity|normal |major --- Comment #5 from Eric Botcazou --- Still present on Solaris.
[Bug c++/78558] [5 Regression] Incorrect loop optimization leads to crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78558 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-11-28 CC||marxin at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Target Milestone|--- |5.5 Summary|Incorrect loop optimization |[5 Regression] Incorrect |leads to crash |loop optimization leads to ||crash Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, was fixed by Richi's commit r224598. Do we want to somehow back port it to GCC 5 branch?
[Bug tree-optimization/78528] Recursion not optimized for structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78528
--- Comment #4 from Marc Glisse ---
:
MEM[(struct &)&D.2329] ={v} {CLOBBER};
D.2329.m_value = 0;
goto ;
:
_2 = s_5(D) + 1;
D.2336 = mystrlen (_2);
lhs$m_value_7 = MEM[(struct Int *)&D.2336];
_8 = lhs$m_value_7 + 1;
MEM[(struct Int *)&D.2329] = _8;
:
return D.2329;
I think the 2 writes to D.2329 could be moved to bb 5, where we would have PHI
<0(3), _8(4)>. That would already make it look slightly more similar to the int
case, although it is unlikely that would suffice.
If strlen was static, we could also imagine gcc cloning it to a function with a
scalarized return type of int.
[Bug c++/78558] [5 Regression] Incorrect loop optimization leads to crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78558 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- It's going to be non-trivial, but maybe the correctness issue separates out nicely...
[Bug libfortran/78549] Very slow formatted internal file output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78549 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-11-28 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- You can add another attachments after you submit the bug. I can confirm that it takes (GCC 6.2.1): gfortran -Ofast pr78549.c && time ./a.out ... 0m1.524s gfortran -Ofast pr78549.f90 && time ./a.out ... 0m4.985s
[Bug lto/78211] [7 Regression] -fcompare-debug failure with -flto -fno-use-linker-plugin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78211 --- Comment #8 from Jakub Jelinek --- Author: jakub Date: Mon Nov 28 10:00:43 2016 New Revision: 242910 URL: https://gcc.gnu.org/viewcvs?rev=242910&root=gcc&view=rev Log: PR lto/78211 * ipa-icf.h (sem_item_optimizer): Add m_classes_vec member. * ipa-icf.c (sem_item_optimizer::sem_item_optimizer): Initialize it. (sem_item_optimizer::~sem_item_optimizer): Traverse m_classes_vec vector instead of traversing m_classes hash table. Release m_classes_vec. (sem_item_optimizer::read_section, sem_item_optimizer::add_class): Formatting fixes. (sem_item_optimizer::get_group_by_hash): When inserting a new group, add it also to m_classes_vec vector. (sem_item_optimizer::remove_symtab_node, sem_item_optimizer::build_hash_based_classes, sem_item_optimizer::parse_nonsingleton_classes): Formatting fixes. (sem_item_optimizer::subdivide_classes_by_equality, sem_item_optimizer::subdivide_classes_by_sensitive_refs, sem_item_optimizer::verify_classes): Traverse m_classes_vec vector instead of traversing m_classes hash table. Formatting fixes. (sem_item_optimizer::traverse_congruence_split, sem_item_optimizer::do_congruence_step_for_index, sem_item_optimizer::do_congruence_step): Formatting fixes. (sem_item_optimizer::process_cong_reduction): Traverse m_classes_vec vector instead of traversing m_classes hash table. (sem_item_optimizer::dump_cong_classes): Likewise. Formatting fixes. (sem_item_optimizer::merge_classes): Traverse m_classes_vec vector instead of traversing m_classes hash table. * g++.dg/ipa/pr78211.C: New test. Added: trunk/gcc/testsuite/g++.dg/ipa/pr78211.C Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-icf.c trunk/gcc/ipa-icf.h trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/78559] New: [7 Regression] wrong code due to tree if-conversion?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78559
Bug ID: 78559
Summary: [7 Regression] wrong code due to tree if-conversion?
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ktkachov at gcc dot gnu.org
Target Milestone: ---
The testcase:
int g = 20;
int d = 0;
short
fn2 (int p1, int p2)
{
return p2 >= 2 || 5 >> p2 ? p1 : p1 << p2;
}
int
main ()
{
int result = 0;
lbl_2582:
if (g)
{
for (int c = -3; c; c++)
result = fn2 (1, g);
}
else
{
for (int i = 0; i < 2; i += 2)
if (d)
goto lbl_2582;
}
if (result != 1)
__builtin_abort ();
return 0;
}
used to (erroneously) abort on aarch64-none-linux-gnu with -O3 after r235808
but stopped aborting with r242550. It still passes after the fix r242689 but
I'm not sure if the bug has just gone latent.
To reproduce on aarch64 you'll have to revert r242689 and r242550.
[Bug tree-optimization/78559] [7 Regression] wrong code due to tree if-conversion?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78559 ktkachov at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Target||aarch64 CC||amker at gcc dot gnu.org Known to work||6.2.1 Target Milestone|--- |7.0 Known to fail||7.0
[Bug fortran/78557] [7 Regression] ICE in trans-expr.c with -fcheck=all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78557 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Known to work||5.4.0, 6.2.0 --- Comment #3 from Dominique d'Humieres --- Triggered by -fcheck=mem.
[Bug other/60145] [AVR] Suboptimal code for byte order shuffling using shift and or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60145
--- Comment #2 from Georg-Johann Lay ---
Created attachment 40173
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40173&action=edit
2 patterns for the 4-byte case
The 2-byte case should be improved by r242909 but the 4-byte case just leads to
insane patterns if tried to catch such code in the backend. FYI I attached 2
patterns that would improve your code, but I didn't even consider to propose
them for revirew...
If your intention is to swap bytes to adjust endianess, you might consider
__builtin_bswap32, cf.
https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#index-g_t_005f_005fbuiltin_005fbswap32-4387
If you want to compose 32-bit values out of 8-bit values, you can use a union
as indicated in your example, or you can use vectors which is a GCC extension:
#include
typedef uint8_t v4 __attribute__((vector_size (4)));
uint32_t join4 (uint8_t b0, uint8_t b1, uint8_t b2, uint8_t b3)
{
return (uint32_t) (v4) { b0, b1, b2, b3 };
}
uint32_t join4 (uint8_t b0, uint8_t b1, uint8_t b2, uint8_t b3)
{
v4 vec;
vec[0] = b0;
vec[1] = b1;
vec[2] = b2;
vec[3] = b3;
return (uint32_t) vec;
}
And as always, consider inlining such functions.
[Bug tree-optimization/65964] [meta] Operand Shortening
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65964 Bug 65964 depends on bug 60145, which changed state. Bug 60145 Summary: [AVR] Suboptimal code for byte order shuffling using shift and or https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60145 What|Removed |Added Status|RESOLVED|NEW Resolution|DUPLICATE |---
[Bug other/60145] [AVR] Suboptimal code for byte order shuffling using shift and or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60145 Georg-Johann Lay changed: What|Removed |Added Status|RESOLVED|NEW Last reconfirmed||2016-11-28 Resolution|DUPLICATE |--- Ever confirmed|0 |1
[Bug middle-end/78559] [7 Regression] wrong code due to tree if-conversion?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78559 --- Comment #1 from amker at gcc dot gnu.org --- Thanks for reporting. I will investigate.
[Bug target/78255] [5/6/7 regression] Indirect sibling call causing wrong code generation for ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78255 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-11-28 CC||ktkachov at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from ktkachov at gcc dot gnu.org --- Confirmed in any case
[Bug tree-optimization/78542] [7 Regression] wrong code at -Og results in endless loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78542
--- Comment #3 from Richard Biener ---
The SSA propagator does:
Visiting statement:
_11 = {x_4, x_4, x_4, x_4};
which is likely CONSTANT
Lattice value changed to VARYING. Adding SSA edges to worklist.
Visiting statement:
_12 = BIT_FIELD_REF <_11, 32, 0>;
which is likely CONSTANT
Applying pattern match.pd:3627, gimple-match.c:67610
Match-and-simplified BIT_FIELD_REF <_11, 32, 0> to x_4
Lattice value changed to CONSTANT x_6(D). Adding SSA edges to worklist.
marking stmt to be not simulated again
so while _11 is VARYING we still optimize the BIT_FIELD_REF optimistically,
namely to x_6(D) instead of x_4 using
Visiting PHI node: x_4 = PHI
Argument #0 (2 -> 3 executable)
x_6(D) Value: CONSTANT x_6(D)
Argument #1 (3 -> 3 not executable)
PHI node value: CONSTANT x_6(D)
Lattice value changed to CONSTANT x_6(D). Adding SSA edges to worklist.
this node will be visited again but the above not.
The issue is valueization here:
simplified = ccp_fold (stmt);
if (simplified && TREE_CODE (simplified) == SSA_NAME)
{
ccp_prop_value_t *val = get_value (simplified);
if (val && val->lattice_val != VARYING)
{
fold_undefer_overflow_warnings (true, stmt, 0);
return *val;
}
ccp_fold (correctly) returns x_4 but then we valueize to x_6(D).
[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71767 --- Comment #53 from Iain Sandoe --- Author: iains Date: Mon Nov 28 10:29:19 2016 New Revision: 242912 URL: https://gcc.gnu.org/viewcvs?rev=242912&root=gcc&view=rev Log: [Darwin, config] Fix version number extraction to portable method The method used in the applied patch caused configuration errors on freeBSD and hppa. 2016-11-28 Iain Sandoe PR target/71767 * configure.ac (with_ld64): Use portable method to extract the major part of the version number. * configure: Regenerated. Modified: trunk/gcc/ChangeLog trunk/gcc/configure trunk/gcc/configure.ac
[Bug rtl-optimization/78546] [6/7 Regression] wrong code at -O2 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78546 --- Comment #8 from Jakub Jelinek --- Created attachment 40174 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40174&action=edit gcc7-pr78546.patch Untested fix for 2), i.e. the wrong-code bug. For 1), i.e. the optimization regression, I think it should be tracked in a separate PR.
[Bug tree-optimization/78343] [6 Regression] Loop is not eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78343 --- Comment #6 from Richard Biener --- Author: rguenth Date: Mon Nov 28 10:49:12 2016 New Revision: 242913 URL: https://gcc.gnu.org/viewcvs?rev=242913&root=gcc&view=rev Log: 2016-11-28 Richard Biener PR tree-optimization/78343 * gcc.dg/tree-ssa/20030808-1.c: Fix dump to generate. * gcc.dg/tree-ssa/20040305-1.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/20030808-1.c trunk/gcc/testsuite/gcc.dg/tree-ssa/20040305-1.c
[Bug tree-optimization/78529] [7 Regression] gcc.c-torture/execute/builtins/strcat-chk.c failed with lto/O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78529 --- Comment #2 from prathamesh3492 at gcc dot gnu.org --- Sorry for the breakage, I am looking into the issue. Regards, Prathamesh
[Bug c++/78550] [6/7 Regression] bit field and std::initializer_list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78550 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-11-28 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/78550] [6/7 Regression] bit field and std::initializer_list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78550
--- Comment #1 from Jakub Jelinek ---
Started with r230365.
Testcase without any headers:
namespace std
{
template
struct initializer_list
{
const T *a;
__SIZE_TYPE__ b;
constexpr initializer_list (const T *x, __SIZE_TYPE__ y) : a(x), b(y) { }
};
}
template
struct A {
A (std::initializer_list);
};
struct B {
int k : 1;
};
A a{{0}};
[Bug target/78560] New: powerpc64le ICE with -mcpu=power9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78560
Bug ID: 78560
Summary: powerpc64le ICE with -mcpu=power9
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: anton at samba dot org
CC: meissner at gcc dot gnu.org, segher at gcc dot gnu.org,
wschmidt at gcc dot gnu.org
Target Milestone: ---
Target: powerpc64le-linux
The following test case:
int a, b, d;
short *const c = (short *)&b;
void e(void)
{
d = 3;
for (; d < 100; d++) {
a = 0;
for (; a != 30; a = a + 5)
*c |= 4;
}
}
when built with:
gcc -O3 -mcpu=power9 testcase.c
fails with:
testcase.c: In function ‘e’:
testcase.c:13:1: error: unrecognizable insn:
}
^
(insn 7 6 8 2 (set (reg:V8HI 166)
(unspec:V8HI [
(reg:V8HI 166)
(mem/c:HI (reg/f:DI 167) [2 MEM[(short int *)&b]+0 S2 A32])
(const_int 0 [0])
] UNSPEC_VSX_SET)) -1
(nil))
testcase.c:13:1: internal compiler error: in extract_insn, at recog.c:2311
0x1086b173 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/gcc/rtl-error.c:108
0x1086b1d7 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc/gcc/rtl-error.c:116
0x1082f137 extract_insn(rtx_insn*)
../../gcc/gcc/recog.c:2311
0x10564c5b instantiate_virtual_regs_in_insn
../../gcc/gcc/function.c:1589
0x10564c5b instantiate_virtual_regs
../../gcc/gcc/function.c:1956
0x10564c5b execute
../../gcc/gcc/function.c:2005
[Bug libfortran/78449] compile time ieee_support_halting is not correct on arm and aarch64 ( FAIL: gfortran.dg/ieee/ieee_8.f90 -Os execution test )
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78449 Ramana Radhakrishnan changed: What|Removed |Added CC||ramana at gcc dot gnu.org --- Comment #2 from Ramana Radhakrishnan --- Fixed then ?
[Bug libfortran/78449] compile time ieee_support_halting is not correct on arm and aarch64 ( FAIL: gfortran.dg/ieee/ieee_8.f90 -Os execution test )
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78449 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2016-11-28 Ever confirmed|0 |1
[Bug middle-end/52544] compilation fails with -finstrument-functions and sse c code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52544 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #10 from Jakub Jelinek --- This has been fixed on the trunk with r242487. *** This bug has been marked as a duplicate of bug 78333 ***
[Bug middle-end/78333] [5 Regression] always-inline gnu-inline functions break -finstrument-functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78333 Jakub Jelinek changed: What|Removed |Added CC||jgpiccinali at free dot fr --- Comment #9 from Jakub Jelinek --- *** Bug 52544 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/78561] New: Constant pool size (offset) can become stale where constant pool entires become unused
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78561
Bug ID: 78561
Summary: Constant pool size (offset) can become stale where
constant pool entires become unused
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jgreenhalgh at gcc dot gnu.org
Target Milestone: ---
This bug report is mostly from inspection, but the effects of this issue can be
seen with this testcase on AArch64 (See also PR70120 for why we need the size
of the constant pool to be correct).
int
main (__fp16 x)
{
__fp16 a = 6.5504e4;
return (x <= a);
}
gcc foo.c -O3 -mcmodel=tiny -g
/tmp/ccwJITmo.s: Assembler messages:
/tmp/ccwJITmo.s: Error: unaligned opcodes detected in executable segment
In this test case, a call to force_const_mem in ira adds a new 32-bit constant
in the constant pool, but ultimately doesn't use it. That means that when we
sweep patterns looking for which constant pool entries to emit, we don't mark
the unused pattern created by ira, and it doesn't get emitted. But, that leaves
us with inconsistent information between the offset we think we've got, and
what we've actually emitted.
Presumably IRA isn't the only pass at fault here. Anything which eliminates a
reference to a constant pool entry can cause the constant pool offset
information to become stale, as it is only updated when inserting entries to
the constant pool, not when we decide those entries are actually used.
Maybe force_const_mem shouldn't be updating the offset information at all, and
we should only update that as we make the sweep in mark_constant_pool looking
for live pool entries? I guess the trouble there is that we don't record the
mode of the mem in the constant_descriptor_rtx - but if we were to do that it
looks like we might be able to defer calculating offset until when we actually
emit the pool. rs6000 might need some changes, but a better interface for their
uses of get_pool_size looks like it would be "pool_empty_p" anyway.
I'm not sure of this code though, so I don't know if that would make for a
clean design.
[Bug rtl-optimization/78561] Constant pool size (offset) can become stale where constant pool entires become unused
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78561 James Greenhalgh changed: What|Removed |Added Target||aarch64*-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2016-11-28 Ever confirmed|0 |1
[Bug target/70120] [6 Regression][aarch64] -g causes Assembler messages: Error: unaligned opcodes detected in executable segment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70120 James Greenhalgh changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #14 from James Greenhalgh --- > I do think a new bug should be opened. OK. PR78561 .
[Bug rtl-optimization/78120] [6/7 Regression] If conversion no longer performed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78120 Bernd Schmidt changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #14 from Bernd Schmidt --- Still fixed.
[Bug middle-end/78559] [7 Regression] wrong code due to tree if-conversion?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78559 --- Comment #2 from Richard Biener --- Should reproduce still with -ftree-loop-if-convert after r242550?
[Bug middle-end/78559] [7 Regression] wrong code due to tree if-conversion?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78559 --- Comment #3 from ktkachov at gcc dot gnu.org --- (In reply to Richard Biener from comment #2) > Should reproduce still with -ftree-loop-if-convert after r242550? Yes it does with 242837. Thanks
[Bug c++/78558] [5 Regression] Incorrect loop optimization leads to crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78558 Richard Biener changed: What|Removed |Added Depends on||66598 --- Comment #3 from Richard Biener --- See also the related PR66598, fixed by the same commit. Not 100% sure it's a duplicate but there I tried backporting the relevant change and have up because of the large amount of changes required. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66598 [Bug 66598] [5 Regression] With -O3 gcc incorrectly assumes aligned SSE instructions (e.g. movapd) can be used
[Bug target/31667] Integer extensions vectorization could be improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31667 Allan Jensen changed: What|Removed |Added CC||linux at carewolf dot com --- Comment #3 from Allan Jensen --- Gcc 5 and 6 produces code with pmovzx when compiling the example with -O3 -msse4.1 I assume this can be closed.
[Bug other/60145] [AVR] Suboptimal code for byte order shuffling using shift and or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60145 --- Comment #3 from Matthijs Kooijman --- Thanks for digging into this :-D I suppose you meant https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=242907 instead of the commit you linked (which is also nice btw, I noticed that extra sbiw in some places as well). Looking at the generated assembly, the optimizations look like fairly simple (composable) translations, but I assume that the optimization needs to happen before/while the assembly is generated, not afterwards. And then I can see that the patterns would indeed become complex. My goal was indeed to compose values. Using a union is endian-dependent, which is a downside. If I understand your vector-example correctly, vectors are always stored as big endian, so using this approach would be portable? I couldn't find anything about this in the documentation, though.
[Bug rtl-optimization/78546] [6/7 Regression] wrong code at -O2 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78546
--- Comment #9 from Richard Biener ---
Testing
diff --git a/gcc/match.pd b/gcc/match.pd
index 2d4e019..9e5df64 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -1216,6 +1216,13 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
(if (cst && !TREE_OVERFLOW (cst))
(minus { cst; } @0)
+ /* CST - (CST - A) -> CST - A */
+ (simplify
+ (minus CONSTANT_CLASS_P@1 (minus CONSTANT_CLASS_P@2 @0))
+ (with { tree cst = const_binop (MINUS_EXPR, type, @1, @2); }
+(if (cst && !TREE_OVERFLOW (cst))
+ (minus { cst; } @0
+
/* ~A + A -> -1 */
(simplify
(plus:c (bit_not @0) @0)
for the optimization regression.
[Bug rtl-optimization/78546] [6/7 Regression] wrong code at -O2 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78546
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #10 from Marek Polacek ---
(In reply to Richard Biener from comment #9)
> Testing
>
> diff --git a/gcc/match.pd b/gcc/match.pd
> index 2d4e019..9e5df64 100644
> --- a/gcc/match.pd
> +++ b/gcc/match.pd
> @@ -1216,6 +1216,13 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
> (if (cst && !TREE_OVERFLOW (cst))
>(minus { cst; } @0)
>
> + /* CST - (CST - A) -> CST - A */
Shouldn't this be just -> -A?
[Bug target/31667] Integer extensions vectorization could be improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31667 --- Comment #4 from Allan Jensen --- (In reply to Allan Jensen from comment #3) > Gcc 5 and 6 produces code with pmovzx when compiling the example with -O3 > -msse4.1 > > I assume this can be closed. Note like comment 1 saids, it will not use a memory load, though instead it does half as many memory reads. movdqa 0x0(%rip),%xmm0# 8 pmovzxbw %xmm0,%xmm1 psrldq $0x8,%xmm0 pmovzxbw %xmm0,%xmm0 movaps %xmm1,0x0(%rip)# 1e movaps %xmm0,0x0(%rip)# 25
[Bug lto/78562] New: Wrong warning for built-in functions with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78562 Bug ID: 78562 Summary: Wrong warning for built-in functions with -flto Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: gjl at gcc dot gnu.org Target Milestone: --- Created attachment 40175 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40175&action=edit lto.c: C test case The attaches test case throws an incorrect warning when compiled with -flto $ avr-gcc -mmcu=atmega8 lto.c -Os -flto : warning: type of '__builtin_avr_absr' does not match original declaration [-Wlto-type-mismatch] : note: return value type mismatch : note: '__builtin_avr_abshk' was previously declared here : note: code may be misoptimized unless -fno-strict-aliasing is used Using GCC from v7 trunk Last Changed Rev: 242822 Last Changed Date: 2016-11-24 10:45:01 +0100 (Do, 24 Nov 2016) GCC configured as $ ../../gcc.gnu.org/trunk/configure --target=avr --prefix=/local/gnu/install/gcc-7 --disable-shared --disable-nls --with-dwarf2 --enable-target-optspace=yes --with-gnu-as --with-gnu-ld --enable-checking=release --enable-languages=c,c++
[Bug lto/78562] Wrong warning for built-in functions with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78562 Georg-Johann Lay changed: What|Removed |Added Keywords||diagnostic Target||avr Status|UNCONFIRMED |NEW Last reconfirmed||2016-11-28 Ever confirmed|0 |1
[Bug rtl-optimization/78546] [6/7 Regression] wrong code at -O2 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78546
--- Comment #11 from rguenther at suse dot de ---
On Mon, 28 Nov 2016, mpolacek at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78546
>
> Marek Polacek changed:
>
>What|Removed |Added
>
> CC||mpolacek at gcc dot gnu.org
>
> --- Comment #10 from Marek Polacek ---
> (In reply to Richard Biener from comment #9)
> > Testing
> >
> > diff --git a/gcc/match.pd b/gcc/match.pd
> > index 2d4e019..9e5df64 100644
> > --- a/gcc/match.pd
> > +++ b/gcc/match.pd
> > @@ -1216,6 +1216,13 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
> > (if (cst && !TREE_OVERFLOW (cst))
> >(minus { cst; } @0)
> >
> > + /* CST - (CST - A) -> CST - A */
>
> Shouldn't this be just -> -A?
The constants need not be the same.
[Bug ipa/78535] [6.2] invalid code generation with -O1 -fdevirtualize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78535 --- Comment #3 from Daniel Starke --- Created attachment 40176 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40176&action=edit -fdump-ipa-devirt-details output Requested -fdump-ipa-devirt-details output.
[Bug target/78563] New: SSE4.1 pmovzx shuffle pattern not recognized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78563
Bug ID: 78563
Summary: SSE4.1 pmovzx shuffle pattern not recognized
Product: gcc
Version: 6.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: linux at carewolf dot com
Target Milestone: ---
An unpack pattern with 0 constant are neither folded nor recognized as a pmovzx
instruction.
SSE2 code:
_mm_unpacklo_epi32(X, _mm_setzero_si128())
GCC code:
__builtin_shuffle((__v4si)X, (__v4si)_mm_setzero_si128(), (__v4si){0, 4, 1,
5});
Will both produce the same result of an xor setting 0 and an unpack
instruction, while it could with SSE4.1 emit a pmozx instruction.
Note epi32 is just an example here used because it is most compact, this also
affects the 8 and 16 bit equivelents.
Looking in config/i386/i386.c it seems like there is no code in the
expand_vec_perm_* methods for detecting pmovzx patterns.
[Bug target/78563] SSE4.1 pmovzx shuffle pattern not recognized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78563 --- Comment #1 from Allan Jensen --- Created attachment 40177 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40177&action=edit Test
[Bug c++/78564] New: cp-demangle fails to decode Ul+auto/anon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78564
Bug ID: 78564
Summary: cp-demangle fails to decode Ul+auto/anon
Product: gcc
Version: 6.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jengelh at inai dot de
Target Milestone: ---
$ g++-6 -std=gnu++14 -c x.cpp
int main(void)
{
struct NAMED {} f;
struct {} g;
struct {} h;
[](auto &&){}(f);
[](auto &&, auto &&){}(g, h);
}
{binutils 2.27}
$ nm -C x.o
t _ZZ4mainENKUlOT_E_clIRZ4mainE5NAMEDEEDaS0_
0010 t _ZZ4mainENKUlOT_OT0_E0_clIRZ4mainEUt_RZ4mainEUt0_EEDaS0_S2_
$ gcc -v
Using built-in specs.
Reading specs from /usr/lib64/gcc/x86_64-suse-linux/6/defaults.spec
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/6/lto-wrapper
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada,go
--enable-offload-targets=hsa --enable-checking=release
--with-gxx-include-dir=/usr/include/c++/6 --enable-ssp --disable-libssp
--disable-libvtv --disable-libcc1 --enable-plugin
--with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--disable-libgcj --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --enable-linker-build-id
--enable-linux-futex --enable-gnu-indirect-function --program-suffix=-6
--without-system-libunwind --enable-multilib --with-arch-32=x86-64
--with-tune=generic --build=x86_64-suse-linux --host=x86_64-suse-linux
Thread model: posix
gcc version 6.2.1 20160830 [gcc-6-branch revision 239856] (SUSE Linux)
[Bug c++/78564] cp-demangle fails to decode Ul+auto/anon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78564 --- Comment #1 from Jan Engelhardt --- crosslink https://sourceware.org/bugzilla/show_bug.cgi?id=20873
[Bug rtl-optimization/78546] [6/7 Regression] wrong code at -O2 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78546 --- Comment #12 from Jakub Jelinek --- Therefore the comment should be /* CST1 - (CST2 - A) -> (CST1 - CST2) - A */ rather than /* CST - (CST - A) -> CST - A */
[Bug rtl-optimization/78546] [6/7 Regression] wrong code at -O2 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78546 --- Comment #13 from rguenther at suse dot de --- On Mon, 28 Nov 2016, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78546 > > --- Comment #12 from Jakub Jelinek --- > Therefore the comment should be > /* CST1 - (CST2 - A) -> (CST1 - CST2) - A */ > rather than > /* CST - (CST - A) -> CST - A */ All other comments are similar, but I can change them all.
[Bug libstdc++/77459] [6 Regression] undefined reference to `snprintf' when building mingw-w64 cross-compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77459 --- Comment #11 from Georg Koppen --- (In reply to Jakub Jelinek from comment #10) > Assuming r242055 fixed it then. Yes, that issue is not showing up anymore when compiling with r242055.
[Bug libstdc++/78565] New: undefined reference to `aligned_alloc' when building mingw-w64 cross-compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78565 Bug ID: 78565 Summary: undefined reference to `aligned_alloc' when building mingw-w64 cross-compiler Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: gk at torproject dot org Target Milestone: --- When testing r242055 to check whether it fixes bug 77459 (which it seems to do) I ran into another issue. This time I got: libtool: link: /home/ubuntu/build/gcc/./gcc/xgcc -shared-libgcc -B/home/ubuntu/build/gcc/./gcc -nostdinc++ -L/home/ubuntu/build/gcc/i686-w64-mingw32/libstdc++-v3/src -L/home/ubuntu/build/gcc/i686-w64-mingw32/libstdc++-v3/src/.libs -L/home/ubuntu/build/gcc/i686-w64-mingw32/libstdc++-v3/libsupc++/.libs -L/home/ubuntu/install/mingw-w64/i686-w64-mingw32/lib -L/home/ubuntu/install/mingw-w64/mingw/lib -isystem /home/ubuntu/install/mingw-w64/i686-w64-mingw32/include -isystem /home/ubuntu/install/mingw-w64/mingw/include -B/home/ubuntu/install/mingw-w64/i686-w64-mingw32/bin/ -B/home/ubuntu/install/mingw-w64/i686-w64-mingw32/lib/ -isystem /home/ubuntu/install/mingw-w64/i686-w64-mingw32/include -isystem /home/ubuntu/install/mingw-w64/i686-w64-mingw32/sys-include-shared -nostdlib /home/ubuntu/install/mingw-w64/i686-w64-mingw32/lib/dllcrt2.o /home/ubuntu/build/gcc/./gcc/crtbegin.o .libs/compatibility.o .libs/compatibility-debug_list.o .libs/compatibility-debug_list-2.o .libs/compatibility-c++0x.o .libs/compatibility-atomic-c++0x.o .libs/compatibility-thread-c++0x.o .libs/compatibility-chrono.o .libs/compatibility-condvar.o -Wl,--whole-archive ../libsupc++/.libs/libsupc++convenience.a ../src/c++98/.libs/libc++98convenience.a ../src/c++11/.libs/libc++11convenience.a -Wl,--no-whole-archive -L/home/ubuntu/build/gcc/i686-w64-mingw32/libstdc++-v3/libsupc++/.libs -L/home/ubuntu/build/gcc/i686-w64-mingw32/libstdc++-v3/src -L/home/ubuntu/build/gcc/i686-w64-mingw32/libstdc++-v3/src/.libs -L/home/ubuntu/install/mingw-w64/i686-w64-mingw32/lib -L/home/ubuntu/install/mingw-w64/mingw/lib -L/home/ubuntu/build/gcc/./gcc -L/home/ubuntu/install/mingw-w64/i686-w64-mingw32/bin -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcr100 -ladvapi32 -lshell32 -luser32 -lkernel32 -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcr100 /home/ubuntu/build/gcc/./gcc/crtend.o -Wl,-O1 -Wl,--gc-sections -Wl,--version-script=libstdc++-symbols.ver -o .libs/libstdc++-6.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker .libs/libstdc++.dll.a ../libsupc++/.libs/libsupc++convenience.a(new_opa.o): In function `ZnwjSt11align_val_t': /home/ubuntu/build/gcc/i686-w64-mingw32/libstdc++-v3/libsupc++/../../../gcc-test/libstdc++-v3/libsupc++/new_opa.cc:80: undefined reference to `aligned_alloc' collect2: error: ld returned 1 exit status make[5]: *** [libstdc++.la] Error 1 git blame gives me r240187 as the culprit.
[Bug target/78563] SSE4.1 pmovzx shuffle pattern not recognized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78563 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Target||x86_64-*-*, i?86-*-* Severity|normal |enhancement
[Bug fortran/78557] [7 Regression] [OOP] ICE in trans-expr.c with -fcheck=mem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78557 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code CC||janus at gcc dot gnu.org Summary|[7 Regression] ICE in |[7 Regression] [OOP] ICE in |trans-expr.c with |trans-expr.c with |-fcheck=all |-fcheck=mem --- Comment #4 from janus at gcc dot gnu.org --- Reduced test case: implicit none type :: t1 logical, allocatable :: flag end type class(t1), dimension(:), allocatable :: sf_int allocate (t1 :: sf_int (2)) end
[Bug middle-end/78566] New: [7 regression] gcc.dg/uninit-pred-6_[abc].c regressions on Arm and m68k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78566 Bug ID: 78566 Summary: [7 regression] gcc.dg/uninit-pred-6_[abc].c regressions on Arm and m68k Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: aldyh at gcc dot gnu.org Target Milestone: --- FAIL: gcc.dg/uninit-pred-6_a.c warning (test for warnings, line 36) FAIL: gcc.dg/uninit-pred-6_b.c warning (test for warnings, line 42) FAIL: gcc.dg/uninit-pred-6_c.c warning (test for warnings, line 43) Caused by my change of r242639 for pr61409. On Arm it is reproduced with: configure' '--disable-multilib' '--target=arm-none-linux-gnueabihf' '--with-cpu=cortex-a5' '--with-fpu=vfpv3-d16-fp16' 'target_alias=arm-none-linux-gnueabihf' '--enable-languages=c,lto'
[Bug middle-end/78566] [7 regression] gcc.dg/uninit-pred-6_[abc].c regressions on Arm and m68k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78566 Aldy Hernandez changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-11-28 Ever confirmed|0 |1 --- Comment #1 from Aldy Hernandez --- Mine.
[Bug rtl-optimization/78546] [6/7 Regression] wrong code at -O2 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78546 --- Comment #14 from Zdenek Sojka --- (In reply to Jakub Jelinek from comment #12) > Therefore the comment should be > /* CST1 - (CST2 - A) -> (CST1 - CST2) - A */ > rather than > /* CST - (CST - A) -> CST - A */ How comes it is not "CST1 - (CST2 - A) -> (CST1 - CST2) + A"?
[Bug libfortran/78549] Very slow formatted internal file output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78549 --- Comment #2 from mecej4 at operamail dot com --- Thanks, Martin. After posting, I found that I could add more add more attachments, but I was a bit worried that, as in other forums, the initial post could not be edited or modified. I presume that you ran your confirmation runs on Linux. Even if the Fortran version is three times slower than the C version, as you found, perhaps one could live with that. However, on Windows(+Cygwin,Mingw,etc.) the performance of the Fortran version is terrible, and I think that this reflects poorly on the otherwise fine Gfortran compiler, which often outperforms expensive commercial Fortran compilers in the quality of the generated code. A collaborator tells me that the problem did not exist in the Windows/MinGW release of Gfortran 4.9.3. I could not test that assertion myself because the installer failed on my Windows 10 system.
[Bug tree-optimization/60145] [AVR] Suboptimal code for byte order shuffling using shift and or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60145
Georg-Johann Lay changed:
What|Removed |Added
Component|other |tree-optimization
--- Comment #4 from Georg-Johann Lay ---
(In reply to Matthijs Kooijman from comment #3)
> I suppose you meant
> https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=242907 instead of the
> commit you linked (which is also nice btw, I noticed that extra sbiw in some
> places as well).
Ah yes, I meant r242907.
> Looking at the generated assembly, the optimizations look like fairly simple
> (composable) translations, but I assume that the optimization needs to
> happen before/while the assembly is generated, not afterwards. And then I
> can see that the patterns would indeed become complex.
Well, 4 extensions from u8 to u32, 3 shifts and 3 or make 10 operations which
have to be written as ONE single insn if the backend should catch this... This
needs at least one intermediate pattern because otherwise the insn combiner
will not combine such complex expressions.
> My goal was indeed to compose values. Using a union is endian-dependent,
> which is a downside.
Maybe you can use GCC built-in macros like __BYTE_ORDER__ to factor out
endianess?
#define __ORDER_LITTLE_ENDIAN__ 1234
#define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
(as displayed with -E -dM | grep END)
> If I understand your vector-example correctly, vectors are always stored as
> big endian, so using this approach would be portable? I couldn't find
> anything about this in the documentation, though.
Looking at the code the example
typedef uint8_t v4 __attribute__((vector_size (4)));
uint32_t join4 (uint8_t b0, uint8_t b1, uint8_t b2, uint8_t b3)
{
v4 vec;
vec[0] = b0;
vec[1] = b1;
vec[2] = b2;
vec[3] = b3;
return (uint32_t) vec;
}
generates, it's little endian, i.e. b0 is stored in the low byte of vec so that
vectors are similar to arrays:
join4:
mov r23,r22 ; b1
mov r25,r18 ; b3
mov r22,r24 ; b0
mov r24,r20 ; b2
ret
On tree level, this is represented as BIT_INSERT_EXPR (from
-fdump-tree-optimized)
join4 (uint8_t b0, uint8_t b1, uint8_t b2, uint8_t b3)
{
v4 vec;
uint32_t _6;
:
vec_8 = BIT_INSERT_EXPR ;
vec_9 = BIT_INSERT_EXPR ;
vec_10 = BIT_INSERT_EXPR ;
vec_11 = BIT_INSERT_EXPR ;
_6 = VIEW_CONVERT_EXPR(vec_11);
return _6;
}
Hence an open-coded composition of byte-values into a 4-byte value can be
represented neatly on tree level, and this is quite an improvement over
ZERO_EXTEND + ASHIFT + IOR w.r.t. the resulting code.
Thus turned into a tree level optimization issue.
[Bug lto/78562] Wrong warning for built-in functions with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78562 Richard Biener changed: What|Removed |Added CC||hubicka at gcc dot gnu.org, ||rguenth at gcc dot gnu.org --- Comment #1 from Richard Biener --- The two builtins share DECL_ASSEMBLER_NAME, __ssabs_2. Can it be the AVR backend misuses DECL_ASSEMBLER_NAME for builtins somehow? They have different return mode, HQ vs. HA mode. It might be possible to avoid diagnosing this but the middle-end can't see that there is no ABI issue. unit size align 8 symtab 0 alias set -1 canonical type 0x2c039c78 precision 16> QI size unit size align 8 symtab 0 alias set -1 structural equality arg-types chain >> pointer_to_this > addressable public external built-in HI file line 0 col 0 align 8 built-in BUILT_IN_MD 17 context > unit size align 8 symtab 0 alias set -1 canonical type 0x2c039498 precision 16> QI size unit size align 8 symtab 0 alias set -1 structural equality arg-types chain >> pointer_to_this > addressable public external built-in HI file line 0 col 0 align 8 built-in BUILT_IN_MD 14 context >
[Bug fortran/78298] ICE in lookup_decl_in_outer_ctx, bei omp-low.c:4115
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78298 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Created attachment 40178 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40178&action=edit gcc7-pr78298.patch Untested fix.
[Bug middle-end/78566] [7 regression] gcc.dg/uninit-pred-6_[abc].c regressions on Arm and m68k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78566 Richard Biener changed: What|Removed |Added Target Milestone|--- |7.0
[Bug rtl-optimization/78546] [6/7 Regression] wrong code at -O2 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78546 --- Comment #15 from rguenther at suse dot de --- On Mon, 28 Nov 2016, zsojka at seznam dot cz wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78546 > > --- Comment #14 from Zdenek Sojka --- > (In reply to Jakub Jelinek from comment #12) > > Therefore the comment should be > > /* CST1 - (CST2 - A) -> (CST1 - CST2) - A */ > > rather than > > /* CST - (CST - A) -> CST - A */ > > How comes it is not "CST1 - (CST2 - A) -> (CST1 - CST2) + A"? My mistake
[Bug lto/78562] Wrong warning for built-in functions with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78562 --- Comment #2 from Georg-Johann Lay --- Thanks for looking into it. IIUC it's a backend issue. config/avr/builtins.def sets library names for some built-ins, and some libnames are the same because the libgcc asm code is exactly the same, even if the used types on C level are different. So the fix for this one would be to use different asm names (pointing to the same code)?
[Bug target/78543] [6 Regression] ICE in push_reload, at reload.c:1349 on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78543 Peter Bergner changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot gnu.org --- Comment #2 from Peter Bergner --- I'll have a look.
[Bug lto/78562] Wrong warning for built-in functions with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78562 --- Comment #3 from rguenther at suse dot de --- On Mon, 28 Nov 2016, gjl at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78562 > > --- Comment #2 from Georg-Johann Lay --- > Thanks for looking into it. > > IIUC it's a backend issue. > > config/avr/builtins.def sets library names for some built-ins, and some > libnames are the same because the libgcc asm code is exactly the same, even if > the used types on C level are different. > > So the fix for this one would be to use different asm names (pointing to the > same code)? Yes, using aliases would be a good workaround. Richard.
[Bug c++/71848] [7 Regression] libstdc++ testsuite error on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71848 David Edelsohn changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from David Edelsohn --- Fixed.
[Bug c++/78551] [5/6/7 Regression] Internal compiler error with constexpr initialization of union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78551
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek ---
Reduced testcase:
struct A { union { long s; char d[1]; }; constexpr A (char x) : s(0) { d[0] =
x; } };
struct B { A b[2]; };
B c { 'a', 'b' };
