[Bug target/81759] Improve data tracking for _pext_u64 and __builtin_ffsll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81759
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2017-08-08
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
extern __inline unsigned long long
__attribute__((__gnu_inline__, __always_inline__, __artificial__))
_pext_u64 (unsigned long long __X, unsigned long long __Y)
{
return __builtin_ia32_pext_di (__X, __Y);
}
so it's transparent to the optimizers and thus a target or RTL optimization
issue issue.
[Bug rtl-optimization/81747] [8 Regression] ICE in operator[], at vec.h:749
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81747 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.0
[Bug tree-optimization/81741] Misoptimisation : replacing a constant field read access by a function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81741 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-08-08 CC||rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Richard Biener --- I'm quite sure it is because of propagating a conditional equivalence. -fno-tree-dominator-opts fixes this (it's the only pass doing this kind of propagation IIRC). [100.00%]: _1 = s_5(D)->ptr; _2 = strlen (_1); _3 = s_5(D)->size; if (_2 != _3) goto ; [0.04%] else goto ; [99.96%] [0.04%]: __builtin_unreachable (); [99.96%]: _6 = (int) _3; return _6; here DOM decides well, on the else path _2 == _3 so let's propagate! IMHO we _never_ should propagate (non-constant) conditional equivalences.
[Bug c++/81765] New: Internal compiler error: Segmentation fault with -O2 -fnon-call-exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81765
Bug ID: 81765
Summary: Internal compiler error: Segmentation fault with -O2
-fnon-call-exceptions
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: theubik at mail dot ru
Target Milestone: ---
// begin main.cpp
struct A
{
virtual void do1() { }
};
struct B
{
A* m_a;
B() : m_a(nullptr) {}
B(A* a) : m_a(a) {}
~B() { if (m_a) m_a->do1(); }
void do2(B& other)
{
A* tmp = m_a;
m_a = other.m_a;
other.m_a = tmp;
}
B& operator=(A* a)
{
B(a).do2(*this);
return *this;
}
};
int main()
{
int ar[] = { 0, 1 };
for (int i = 0; i < 2; ++i)
{
int j = ar[i];
B b;
b = nullptr;
}
return 0;
}
// end main.cpp
$ g++ -S -std=c++11 -O2 -fnon-call-exceptions main.cpp
main.cpp: In function ‘int main()’:
main.cpp:25:5: internal compiler error: Segmentation fault
int main()
^~~~
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions
$ g++ --version
gcc (Debian 6.3.0-18) 6.3.0 20170516
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ uname -a
Linux machine 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u2 (2017-06-26) x86_64
GNU/Linux
[Bug target/81739] Replace calls to memcmp with more efficient code if possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81739 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Target||x86_64-*-*, i?86-*-* Component|tree-optimization |target --- Comment #1 from Richard Biener --- I think we do this if the result is used in a != 0 equality compare, your case is much harder generally. We do have a cmpmem optab though, thus the target(s) could do better here.
[Bug tree-optimization/81740] [5/6/7/8 Regression] wrong code at -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81740 Richard Biener changed: What|Removed |Added Priority|P3 |P2 CC||amker at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Component|c |tree-optimization Version|unknown |7.1.1
[Bug target/81766] New: [7/8 Regression] ICE in maybe_add_or_update_dep_1, at sched-deps.c:924 caused by r250815
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81766
Bug ID: 81766
Summary: [7/8 Regression] ICE in maybe_add_or_update_dep_1, at
sched-deps.c:924 caused by r250815
Product: gcc
Version: 7.1.1
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-*-*, i?86-*-*
int main(void) { return 0;}
> ./cc1 -quiet t.c -O2 -fPIE -mcmodel=large
t.c: In function ‘main’:
t.c:1:1: internal compiler error: in maybe_add_or_update_dep_1, at
sched-deps.c:924
int main(void) { return 0;}
^~~
0x17b13ec maybe_add_or_update_dep_1
/space/rguenther/src/svn/gcc-7-branch/gcc/sched-deps.c:924
0x17b355a haifa_note_dep
/space/rguenther/src/svn/gcc-7-branch/gcc/sched-deps.c:1866
0x17b3666 note_dep
/space/rguenther/src/svn/gcc-7-branch/gcc/sched-deps.c:1901
0x17b9aa9 add_dependence_1
Breaks grub2 build because its configury fails the test for -mcmodel=large.
[Bug target/81766] [7/8 Regression] ICE in maybe_add_or_update_dep_1, at sched-deps.c:924 caused by r250815
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81766 Richard Biener changed: What|Removed |Added Priority|P3 |P1 CC||jakub at gcc dot gnu.org Known to work||7.1.0 Blocks||79499 Target Milestone|--- |7.2 Known to fail||7.1.1, 8.0 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79499 [Bug 79499] ICE in rtl_verify_bb_insns, at cfgrtl.c:2661
[Bug libstdc++/81749] std::align: runtime error: negation of 8 cannot be represented in type 'size_t'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81749 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #11 from Eric Botcazou --- At least things are clear in Ada: unsigned types are called modular types and they are explicitly defined to use modular arithmetics.
[Bug fortran/81758] [OOP] Broken vtab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81758 Thomas Koenig changed: What|Removed |Added Blocks||81748 --- Comment #3 from Thomas Koenig --- Could be a dup of 81748. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81748 [Bug 81748] extensible types non-conforming behaviour
[Bug middle-end/81719] Range-based for loop on short fixed size array generates long unrolled loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81719
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2017-08-08
Component|c++ |middle-end
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
We are not able to analyze the number of iterations and end up vectorizing the
function.
t.C:12:19: note: Symbolic number of iterations is (((unsigned long) __for_end_6
- (unsigned long) ((const int *) __for_range_5 + 4)) /[ex] 4 &
4611686018427387903) + 1
[15.00%]:
__for_range_5 = &this_4(D)->items;
__for_end_6 = &MEM[(void *)this_4(D) + 8B];
[85.00%]:
# total_11 = PHI
# __for_begin_14 = PHI <__for_begin_10(4), __for_range_5(2)>
item_8 = *__for_begin_14;
total_9 = item_8 + total_11;
__for_begin_10 = __for_begin_14 + 4;
if (__for_end_6 == __for_begin_10)
goto ; [15.00%]
else
goto ; [85.00%]
[72.25%]:
goto ; [100.00%]
[15.00%]:
# total_12 = PHI
it looks like expand_simple_operations fails to handle ADDR_EXPR in
e = gimple_assign_rhs1 (stmt);
code = gimple_assign_rhs_code (stmt);
if (get_gimple_rhs_class (code) == GIMPLE_SINGLE_RHS)
{
if (is_gimple_min_invariant (e))
return e;
if (code == SSA_NAME)
return expand_simple_operations (e, stop);
return expr;
}
but when it is sth that just mimics a POINTER_PLUS_EXPR it should.
Index: gcc/tree-ssa-loop-niter.c
===
--- gcc/tree-ssa-loop-niter.c (revision 250813)
+++ gcc/tree-ssa-loop-niter.c (working copy)
@@ -42,6 +42,7 @@ along with GCC; see the file COPYING3.
#include "tree-chrec.h"
#include "tree-scalar-evolution.h"
#include "params.h"
+#include "tree-dfa.h"
/* The maximum number of dominator BBs we search for conditions
@@ -1980,6 +1981,21 @@ expand_simple_operations (tree expr, tre
if (code == SSA_NAME)
return expand_simple_operations (e, stop);
+ else if (code == ADDR_EXPR)
+ {
+ HOST_WIDE_INT offset;
+ tree base = get_addr_base_and_unit_offset (TREE_OPERAND (e, 0),
+&offset);
+ if (base
+ && TREE_CODE (base) == MEM_REF)
+ {
+ ee = expand_simple_operations (TREE_OPERAND (base, 0), stop);
+ return fold_build2 (POINTER_PLUS_EXPR, TREE_TYPE (expr), ee,
+ wide_int_to_tree (sizetype,
+ mem_ref_offset (base)
+ + offset));
+ }
+ }
return expr;
}
[Bug tree-optimization/81723] [7/8 Regression] fortran build doesn't terminate on 64bit targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81723 Richard Biener changed: What|Removed |Added Target||x86_64-*-* Priority|P3 |P2 Status|UNCONFIRMED |ASSIGNED Last reconfirmed|2017-08-05 00:00:00 |2017-08-08 Known to work||6.4.0 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||7.1.0 --- Comment #6 from Richard Biener --- I will have a look. Workaround: -fno-tree-slp-vectorize.
[Bug c++/81722] [7/8 Regression] memory hog building c++ on i686-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81722 Richard Biener changed: What|Removed |Added Target Milestone|--- |7.2
[Bug driver/81519] Enhancement: Add --help=target-distcc or similar to dump clean, optimal CFLAGS without using -march=native
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81519 --- Comment #4 from Martin Liška --- Ok, so I've briefly investigated source code and providing such information is definitely not a simple task :/ I would recommend to fix PR39851 and then one will just compare output of following 2 invocations: gcc --help=target -Q gcc --help=target -march=native -Q Will it work for you? Note that fully understand which ISA extensions are enable when is also quite complex.
[Bug c++/81607] Conditional operator: "type mismatch in shift expression" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81607 --- Comment #10 from Marek Polacek --- Author: mpolacek Date: Tue Aug 8 08:55:43 2017 New Revision: 250948 URL: https://gcc.gnu.org/viewcvs?rev=250948&root=gcc&view=rev Log: PR c++/81607 * cp-gimplify.c (cp_fold): If folding exposed a branch of a COND_EXPR, convert it to the original type of the COND_EXPR, if they differ. * g++.dg/other/bitfield6.C: New test. Added: trunk/gcc/testsuite/g++.dg/other/bitfield6.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-gimplify.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/81723] [7/8 Regression] fortran build doesn't terminate on 64bit targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81723 --- Comment #7 from Richard Biener --- Ok, so the issue is that SLP tree size limiting doesn't work effectively here with the build-from-scalars fallback as the cost of doing this is not accounted for. The tree size itself doesn't grow too much but as we analyze depth first and only after a lot of repeated work throwing away stuff for the build-from-scalars fallback this is effectively a case of exponential search.
[Bug other/81752] Sanity-check OMP clause arguments, command-line flags, and environment variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81752 Thomas Schwinge changed: What|Removed |Added Target|nvptx | Status|UNCONFIRMED |NEW Last reconfirmed||2017-08-08 Component|libgomp |other Summary|num_gangs(65536) converted |Sanity-check OMP clause |to 0|arguments, command-line ||flags, and environment ||variables Ever confirmed|0 |1 --- Comment #1 from Thomas Schwinge --- We're often using "unsigned short" to store dimension clauses, and sometimes "int" or "unsigned int". I'd say that "unsigned short" is an OK limitation, but we should add compile-time overflow checks whenever we evaluate constant clause arguments' values, and compile-time type-size checks for non-constant arguments (actually, the latter check would work for both cases?), corresponding checks for "-fopenacc-dim" parsing, and run-time checks in libgomp for the "GOMP_OPENACC_DIM" environment variable. And then, the same issue no doubt applies to other OMP clause arguments, command-line flags, and environment variables, too. (Thus adjusting the "Summary".)
[Bug c++/81607] [6/7/8 Regression] Conditional operator: "type mismatch in shift expression" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81607 Marek Polacek changed: What|Removed |Added Target Milestone|--- |6.5 Summary|Conditional operator: "type |[6/7/8 Regression] |mismatch in shift |Conditional operator: "type |expression" error |mismatch in shift ||expression" error
[Bug c++/81607] [6/7 Regression] Conditional operator: "type mismatch in shift expression" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81607 Marek Polacek changed: What|Removed |Added Summary|[6/7/8 Regression] |[6/7 Regression] |Conditional operator: "type |Conditional operator: "type |mismatch in shift |mismatch in shift |expression" error |expression" error --- Comment #11 from Marek Polacek --- Fixed on trunk so far.
[Bug c++/81668] LTO ODR warnings are not helpful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81668
--- Comment #7 from sgunderson at bigfoot dot com ---
(In reply to Manuel López-Ibáñez from comment #6)
>> fts0pars.y:62:0: note: a field with different name is defined in another
>> translation unit
> Did you cut the above? It looks like a note without a previous warning.
> Also, GCC will have trouble to point out the correct location when compiling
> a generated file that contains linemarkers, unless the linemarkers exactly
> point out to the original file AND the original file is available to read.
Sorry, yes, it was cut (I didn't intend to include it, as it is related to
another and very real warning).
Let me make a more minimal example to illustrate my issue (adapted from the
case in 81716). I thought I'd pasted it already, but evidently it never made
Bugzilla.
atum17:~> cat test1.cc
#include "test.h"
void foo(S *t)
{
q[0] = nullptr;
}
atum17:~> cat test2.cc
#include
#include "test.h"
class S {
int m;
};
void bar(S *t)
{
printf("%p\n", q[0]);
}
atum17:~> cat test.h
class S;
extern S *q[10];
atum17:~> /usr/lib/gcc-snapshot/bin/g++ -Wall -O2 -flto -o test.so test1.cc
test2.cc
test.h:2:11: warning: type of 'q' does not match original declaration
[-Wlto-type-mismatch]
extern S *q[10];
^
test.h:2:11: note: 'q' was previously declared here
extern S *q[10];
^
test.h:2:11: note: code may be misoptimized unless -fno-strict-aliasing is used
/usr/lib/x86_64-linux-gnu/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
collect2: error: ld returned 1 exit status
What I'd like is some sort of indication about where test.h came in from
(test1.cc and test2.cc).
[Bug target/81766] [7/8 Regression] ICE in maybe_add_or_update_dep_1, at sched-deps.c:924 caused by r250815
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81766
--- Comment #1 from Jakub Jelinek ---
If contemplating reversion, perhaps:
--- gcc/function.c.jj 2017-08-07 18:50:09.0 +0200
+++ gcc/function.c 2017-08-08 11:11:25.506239318 +0200
@@ -6073,17 +6073,16 @@ thread_prologue_and_epilogue_insns (void
if (prologue_insn
&& BLOCK_FOR_INSN (prologue_insn) == NULL)
prologue_insn = NULL;
- if (split_prologue_insn || prologue_insn)
- {
- auto_sbitmap blocks (last_basic_block_for_fn (cfun));
- bitmap_clear (blocks);
- if (split_prologue_insn)
- bitmap_set_bit (blocks,
- BLOCK_FOR_INSN (split_prologue_insn)->index);
- if (prologue_insn)
- bitmap_set_bit (blocks, BLOCK_FOR_INSN (prologue_insn)->index);
- find_many_sub_basic_blocks (blocks);
- }
+ auto_sbitmap blocks (last_basic_block_for_fn (cfun));
+ bitmap_clear (blocks);
+ if (split_prologue_insn)
+ bitmap_set_bit (blocks,
+ BLOCK_FOR_INSN (split_prologue_insn)->index);
+ if (prologue_insn)
+ bitmap_set_bit (blocks, BLOCK_FOR_INSN (prologue_insn)->index);
+ bitmap_set_bit (blocks, entry_edge->dest->index);
+ bitmap_set_bit (blocks, orig_entry_edge->dest->index);
+ find_many_sub_basic_blocks (blocks);
}
default_rtl_profile ();
should be safe too (which does what we used to do before and additionally marks
the new blocks if needed and different from the old ones.
Can't test it right now though. And, I really need to debug why we need to
find_many_sub_basic_blocks when split_prologue_seq is NULL and prologue_seq is
just
(note 17 0 0 NOTE_INSN_PROLOGUE_END)
alone. Perhaps something inserts insns elsewhere.
[Bug c++/81765] Internal compiler error: Segmentation fault with -O2 -fnon-call-exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81765 --- Comment #1 from Ubikovich --- How to avoid this bug?
[Bug testsuite/81738] [8 Regression] gcc.dg/vect/vect-alias-check-6.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81738 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-08-08 Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from rsandifo at gcc dot gnu.org --- Ah yeah, the second loop needs vect_perm. Will fix.
[Bug c++/81767] New: Unused variable warning with structured binding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81767
Bug ID: 81767
Summary: Unused variable warning with structured binding
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: antoshkka at gmail dot com
Target Milestone: ---
The following code produces "warning: unused variable 'ignore'
[-Wunused-variable]":
int main() {
int m[2][2] = {{1,2}, {3, 4}};
int sum = 0;
for (auto& [ignore, value] : m) {
sum += value;
}
return sum - 6;
}
This is not good, as multiple users would like to ignore part of the result and
deal only with the other part.
Seems better to warn only if result of structured binding does not used at all:
for (auto& [ignore, value] : m) { // "warning: structured binding result not
used
sum += 0;
}
Otherwise emit no warning (just like clang does).
[Bug target/81708] The x86 stack canary location should be customizable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81708 --- Comment #3 from Uroš Bizjak --- Created attachment 41949 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41949&action=edit Patch that introduces mstack-protector-guard-offset= and mstack-protector-guard-reg= Prototype patch that introduces mstack-protector-guard-offset= and mstack-protector-guard-reg= options. The later can be used to override default TLS reg, so compilation becomes independent of -mcmodel=kernel.
[Bug c++/81765] Internal compiler error: Segmentation fault with -O2 -fnon-call-exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81765 --- Comment #2 from Ubikovich --- (In reply to Ubikovich from comment #1) > How to avoid this bug? Compiling this code with optimization -O1 helps to avoid the problem.
[Bug target/81708] The x86 stack canary location should be customizable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81708 Uroš Bizjak changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-08-08 Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com Target Milestone|--- |8.0 Ever confirmed|0 |1
[Bug target/81708] The x86 stack canary location should be customizable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81708 --- Comment #4 from Uroš Bizjak --- (In reply to Uroš Bizjak from comment #3) > Created attachment 41949 [details] > Patch that introduces mstack-protector-guard-offset= and > mstack-protector-guard-reg= e.g.: -mstack-protector-guard-reg=%fs -mstack-protector-guard-offset=0x200
[Bug target/81766] [7/8 Regression] ICE in maybe_add_or_update_dep_1, at sched-deps.c:924 caused by r250815
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81766
--- Comment #2 from rguenther at suse dot de ---
On Tue, 8 Aug 2017, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81766
>
> --- Comment #1 from Jakub Jelinek ---
> If contemplating reversion, perhaps:
> --- gcc/function.c.jj 2017-08-07 18:50:09.0 +0200
> +++ gcc/function.c 2017-08-08 11:11:25.506239318 +0200
> @@ -6073,17 +6073,16 @@ thread_prologue_and_epilogue_insns (void
>if (prologue_insn
> && BLOCK_FOR_INSN (prologue_insn) == NULL)
> prologue_insn = NULL;
> - if (split_prologue_insn || prologue_insn)
> - {
> - auto_sbitmap blocks (last_basic_block_for_fn (cfun));
> - bitmap_clear (blocks);
> - if (split_prologue_insn)
> - bitmap_set_bit (blocks,
> - BLOCK_FOR_INSN (split_prologue_insn)->index);
> - if (prologue_insn)
> - bitmap_set_bit (blocks, BLOCK_FOR_INSN (prologue_insn)->index);
> - find_many_sub_basic_blocks (blocks);
> - }
> + auto_sbitmap blocks (last_basic_block_for_fn (cfun));
> + bitmap_clear (blocks);
> + if (split_prologue_insn)
> + bitmap_set_bit (blocks,
> + BLOCK_FOR_INSN (split_prologue_insn)->index);
> + if (prologue_insn)
> + bitmap_set_bit (blocks, BLOCK_FOR_INSN (prologue_insn)->index);
> + bitmap_set_bit (blocks, entry_edge->dest->index);
> + bitmap_set_bit (blocks, orig_entry_edge->dest->index);
> + find_many_sub_basic_blocks (blocks);
> }
>
>default_rtl_profile ();
>
> should be safe too (which does what we used to do before and additionally
> marks
> the new blocks if needed and different from the old ones.
> Can't test it right now though. And, I really need to debug why we need to
> find_many_sub_basic_blocks when split_prologue_seq is NULL and prologue_seq is
> just
> (note 17 0 0 NOTE_INSN_PROLOGUE_END)
> alone. Perhaps something inserts insns elsewhere.
find_many_sub_basic_blocks just splits the BB after
NOTE_INSN_PROLOGUE_END because there's a label there(?). So
commit_one_edge_insertion fails to split the edge?
There's NOTE_INSN_BASIC_BLOCK before the label and the fn expects
it the other way around(?). "Fixing" that doesn't help
(NOTE_INSN_PROLOGUE_END after the L12: label)
OTOH maybe add_branch_dependences is just bougus.
The label is inserted by
#1 0x01147df5 in ix86_init_pic_reg ()
at /space/rguenther/src/svn/gcc-7-branch/gcc/config/i386/i386.c:8513
8513 insert_insn_on_edge (seq, entry_edge);
so maybe that is the real issue. Either we can't insert labels
that way or we need to handle it?
Don't know enough about RTL internals.
[Bug target/81766] [7/8 Regression] ICE in maybe_add_or_update_dep_1, at sched-deps.c:924 caused by r250815
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81766 --- Comment #3 from Richard Biener --- find_bb_boundaries doesn't seem to expect existing NOTE_INSN_BASIC_BLOCK, so calling it on existing blocks exposes un-optimalities in case labels are valid after NOTE_INSN_BASIC_BLOCK.
[Bug c++/81765] Internal compiler error: Segmentation fault with -O2 -fnon-call-exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81765 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||6.4.0 Resolution|--- |FIXED Known to fail||6.3.0 --- Comment #3 from Richard Biener --- This has been fixed in GCC 6.4.
[Bug target/81643] FAIL: gcc.target/aarch64/long_branch_1.c scan-assembler Ltb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81643
amker at gcc dot gnu.org changed:
What|Removed |Added
CC||jgreenhalgh at gcc dot gnu.org
--- Comment #5 from amker at gcc dot gnu.org ---
(In reply to Martin Liška from comment #3)
> Confirmed that
> /* { dg-final { scan-assembler "Ltb" } } */
>
> is missing after the revision. Can you amker please tell me how the test
> works?
I don't know the details either. Looks like it tests correct code generation
for long distance conditional jump. With the change, one type of long distance
jump disappeared thus no relevant code is generated. I guess this requires a
test case change. CCing AArch64 maintainer.
[Bug other/39851] gcc -Q --help=target does not list extensions selected by -march=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39851 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org --- Comment #6 from Martin Liška --- I've got a patch candidate, let's see what maintainers say about it.
[Bug tree-optimization/81184] [8 regression] gcc.dg/pr21643.c and gcc.dg/tree-ssa/phi-opt-11.c fail starting with r249450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81184 --- Comment #4 from Martin Liška --- Jakub?
[Bug target/81313] Bad stack realignment code with -mno-accumulate-outgoing-args
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81313 H.J. Lu changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #6 from H.J. Lu --- Oops. Wrong one.
[Bug target/81313] Bad stack realignment code with -mno-accumulate-outgoing-args
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81313 H.J. Lu changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #5 from H.J. Lu --- The patch was reverted.
[Bug tree-optimization/81744] [8 Regression] ICE: verify_ssa failed, at tree-ssa.c:1186
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81744 --- Comment #7 from amker at gcc dot gnu.org --- Author: amker Date: Tue Aug 8 11:32:05 2017 New Revision: 250950 URL: https://gcc.gnu.org/viewcvs?rev=250950&root=gcc&view=rev Log: PR tree-optimization/81744 * tree-predcom.c (prepare_finalizers_chain): Deep copy expr of loop's number of iterations. gcc/testsuite * gcc.dg/tree-ssa/pr81744.c: New. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr81744.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-predcom.c
[Bug target/81736] Unnecessary save and restore frame pointer with -fno-omit-frame-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81736 H.J. Lu changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2017-08-08 Resolution|FIXED |--- Ever confirmed|0 |1 --- Comment #3 from H.J. Lu --- The patch was reverted.
[Bug target/81736] Unnecessary save and restore frame pointer with -fno-omit-frame-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81736
--- Comment #4 from H.J. Lu ---
Another weird code with -fno-omit-frame-pointer:
[hjl@gnu-6 pr59501]$ cat k.i
typedef int v8si __attribute__ ((vector_size (32)));
void
foo (v8si *idx, v8si *out_start, v8si *out_end,
v8si *regions)
{
v8si base = regions[3];
*out_start = base;
*out_end = base;
}
[hjl@gnu-6 pr59501]$ make k.s
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -O -fno-omit-frame-pointer
-mavx -S k.i
[hjl@gnu-6 pr59501]$ cat k.s
.file "k.i"
.text
.globl foo
.type foo, @function
foo:
.LFB0:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
andq$-32, %rsp Why do we realign stack?
vmovdqa 96(%rcx), %ymm0
vmovdqa %ymm0, (%rsi)
vmovdqa %ymm0, (%rdx)
leave
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE0:
.size foo, .-foo
.ident "GCC: (GNU) 8.0.0 20170807 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-6 pr59501]$
[Bug tree-optimization/81696] [5/6/7/8 Regression] ICF ICE on non-local goto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81696 --- Comment #3 from Martin Liška --- Author: marxin Date: Tue Aug 8 11:59:23 2017 New Revision: 250951 URL: https://gcc.gnu.org/viewcvs?rev=250951&root=gcc&view=rev Log: ICF: properly handle LABEL_DECLs (PR tree-opt/81696). 2017-08-08 Martin Liska PR tree-opt/81696 * ipa-icf-gimple.c (func_checker::compare_cst_or_decl): Consider LABEL_DECLs that can be from a different function. 2017-08-08 Martin Liska PR tree-opt/81696 * gcc.dg/ipa/pr81696.c: New test. Added: trunk/gcc/testsuite/gcc.dg/ipa/pr81696.c Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-icf-gimple.c trunk/gcc/testsuite/ChangeLog
[Bug target/81766] [7/8 Regression] ICE in maybe_add_or_update_dep_1, at sched-deps.c:924 caused by r250815
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81766 --- Comment #4 from Jakub Jelinek --- So, it seems the CODE_LABEL in the first bb (successor of entry bb) is added by ix86_init_large_pic_reg called by called by ix86_init_pic_reg from: 5135 /* Perform target specific PIC register initialization. */ 5136 targetm.init_pic_reg (); in ira. In particular, the seq including the CODE_LABEL is added to: 8887 entry_edge = single_succ_edge (ENTRY_BLOCK_PTR_FOR_FN (cfun)); insert_insn_on_edge (seq, entry_edge); 8889 commit_one_edge_insertion (entry_edge); so I'd say this is a backend bug, it should have created the extra bb, or called find_many_sub_basic_blocks (blocks); using a similar technique I've added in r250815, because it doesn't really know where the edge insertion will insert stuff. I think we were just extremely lucky no other pass in between ira and pro_and_epilogue was upset on the invalid RTL. That said, for 7.2 my preference is above patch, and for 8.0 I think we should fix the i386 backend (the only one that has targetm.init_pic_reg implemented). This stuff is weird anyway, do we really need it at the beginning of the function, even if we say shrink-wrap (i.e. shouldn't it be done in the prologue)?
[Bug target/81753] Building of cross-compiler for powerpc-darwin7 is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81753 --- Comment #5 from acsawdey at gcc dot gnu.org --- Yes please do. The only wrinkle is as segher pointed out to me yesterday, make sure this only applies to powerpc darwin in config.gcc.
[Bug target/81766] [7/8 Regression] ICE in maybe_add_or_update_dep_1, at sched-deps.c:924 caused by r250815
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81766 --- Comment #5 from Jakub Jelinek --- (In reply to Richard Biener from comment #3) > find_bb_boundaries doesn't seem to expect existing NOTE_INSN_BASIC_BLOCK, so > calling it on existing blocks exposes un-optimalities in case labels are > valid after NOTE_INSN_BASIC_BLOCK. Another possibility is to use NOTE_INSN_DELETED_LABEL instead of CODE_LABEL, after all, we aren't jumping to it. Let me try it now.
[Bug target/81766] [7/8 Regression] ICE in maybe_add_or_update_dep_1, at sched-deps.c:924 caused by r250815
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81766 --- Comment #6 from Uroš Bizjak --- (In reply to Jakub Jelinek from comment #4) > This stuff is weird anyway, do we really need it at the beginning of the > function, even if we say shrink-wrap (i.e. shouldn't it be done in the > prologue)? PIC setup should be emitted in the prologue. Perhaps this is the task for separate components shrink-wrapping, since PIC register can nowadays be any register.
[Bug libgomp/81768] New: error: control flow in the middle of basic block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81768
Bug ID: 81768
Summary: error: control flow in the middle of basic block
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
This code, minimized from for-5.c:
...
extern void abort ();
int a[1500];
float b[10][15][10];
void
f14_tpf_simd_static32 (void)
{
float *i;
#pragma omp target parallel for simd schedule(static, 32) collapse(3)
for (i = &b[0][0][0]; i < &b[0][0][10]; i++)
for (float *j = &b[0][15][0]; j > &b[0][0][0]; j -= 10)
for (float *k = &b[0][0][10]; k > &b[0][0][0]; --k)
b[i - &b[0][0][0]][(j - &b[0][0][0]) / 10 - 1][(k - &b[0][0][0]) - 1]
-= 3.5;
}
...
Compiled like this:
...
$ ./install/bin/gcc -O2 -fopenmp for-5.c
...
Results in:
...
for-5.c: In function ‘f14_tpf_simd_static32._omp_fn.1’:
for-5.c:21:1: error: control flow in the middle of basic block 12
for-5.c:21:1: error: label
in the middle of basic block 12for-5.c:21:1: error: control flow in the
middle of basic block 12
for-5.c:21:1: error: control flow in the middle of basic block 12
for-5.c:21:1: error: control flow in the middle of basic block 12
for-5.c:21:1: error: label
in the middle of basic block 12for-5.c:21:1: error: control flow in the
middle of basic block 12
for-5.c:21:1: error: control flow in the middle of basic block 12
for-5.c:21:1: error: label
in the middle of basic block 12for-5.c:21:1: error: control flow in the
middle of basic block 12
for-5.c:21:1: error: control flow in the middle of basic block 12
for-5.c:21:1: error: control flow in the middle of basic block 12
for-5.c:21:1: error: control flow in the middle of basic block 12
for-5.c:21:1: error: control flow in the middle of basic block 12
for-5.c:21:1: error: control flow in the middle of basic block 12
for-5.c:21:1: error: control flow in the middle of basic block 12
for-5.c:21:1: error: control flow in the middle of basic block 12
for-5.c:21:1: error: label
in the middle of basic block 12for-5.c:21:1: error: control flow in the
middle of basic block 12
for-5.c:21:1: error: control flow in the middle of basic block 12
for-5.c:21:1: error: control flow in the middle of basic block 12
for-5.c:21:1: error: label
in the middle of basic block 12for-5.c:21:1: error: control flow in the
middle of basic block 12
for-5.c:21:1: error: control flow in the middle of basic block 12
for-5.c:21:1: error: label
in the middle of basic block 12for-5.c:21:1: error: control flow in the
middle of basic block 12
for-5.c:21:1: error: control flow in the middle of basic block 7
for-5.c:21:1: error: label
in the middle of basic block 7for-5.c:21:1: error: control flow in the
middle of basic block 7
for-5.c:21:1: error: control flow in the middle of basic block 7
for-5.c:21:1: error: control flow in the middle of basic block 7
for-5.c:21:1: error: label
in the middle of basic block 7for-5.c:21:1: error: control flow in the
middle of basic block 7
for-5.c:21:1: error: control flow in the middle of basic block 7
for-5.c:21:1: error: label
in the middle of basic block 7for-5.c:21:1: error: control flow in the
middle of basic block 7
for-5.c:21:1: error: control flow in the middle of basic block 7
for-5.c:21:1: error: control flow in the middle of basic block 7
for-5.c:21:1: error: control flow in the middle of basic block 7
for-5.c:21:1: error: control flow in the middle of basic block 7
for-5.c:21:1: error: control flow in the middle of basic block 7
for-5.c:21:1: error: control flow in the middle of basic block 7
for-5.c:21:1: error: control flow in the middle of basic block 7
for-5.c:21:1: error: label
in the middle of basic block 7for-5.c:21:1: error: control flow in the
middle of basic block 7
for-5.c:21:1: error: control flow in the middle of basic block 7
for-5.c:21:1: error: control flow in the middle of basic block 7
for-5.c:21:1: error: label
in the middle of basic block 7for-5.c:21:1: error: control flow in the
middle of basic block 7
for-5.c:21:1: error: control flow in the middle of basic block 7
for-5.c:21:1: error: label
in the middle of basic block 7for-5.c:21:1: error: control flow in the
middle of basic block 7
during GIMPLE pass: fixup_cfg
dump file: for-5.c.019t.fixup_cfg1
for-5.c:21:1: internal compiler error: verify_flow_info failed
0x7bef03 verify_flow_info()
/home/vries/oacc/trunk/source-gcc/gcc/cfghooks.c:259
0xb33762 execute_function_todo
/home/vries/oacc/trunk/source-gcc/gcc/passes.c:2002
0xb34199 execute_todo
/home/vries/oacc/trunk/source-gcc/gcc/passes.c:2044
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/81767] Unused variable warning with structured binding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81767 --- Comment #1 from Jonathan Wakely --- Already fixed on trunk with r248483
[Bug target/81766] [7/8 Regression] ICE in maybe_add_or_update_dep_1, at sched-deps.c:924 caused by r250815
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81766 --- Comment #7 from Jakub Jelinek --- Sadly: --- gcc/config/i386/i386.c.jj 2017-08-07 18:50:10.0 +0200 +++ gcc/config/i386/i386.c 2017-08-08 14:33:06.462836529 +0200 @@ -8846,6 +8846,10 @@ ix86_init_large_pic_reg (unsigned int tm emit_insn (gen_set_got_offset_rex64 (tmp_reg, label)); emit_insn (ix86_gen_add3 (pic_offset_table_rtx, pic_offset_table_rtx, tmp_reg)); + const char *name = LABEL_NAME (label); + PUT_CODE (label, NOTE); + NOTE_KIND (label) = NOTE_INSN_DELETED_LABEL; + NOTE_DELETED_LABEL_NAME (label) = name; } /* Create and initialize PIC register if required. */ doesn't work, because cselib is unhappy to see NOTE_INSN_DELETED_LABEL referenced in an insn.
[Bug target/81769] New: Unnecessary stack realign with -mavx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81769
Bug ID: 81769
Summary: Unnecessary stack realign with -mavx
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
Target Milestone: ---
Target: x86
[hjl@gnu-6 pr59501]$ cat k.i
typedef int v8si __attribute__ ((vector_size (32)));
void
foo (unsigned long long *idx, v8si *out_start, v8si *regions)
{
if (*idx < 20 ) {
v8si base = regions[*idx];
*out_start = base;
}
}
[hjl@gnu-6 pr59501]$ make k.s
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -O -mregparm=3 -m32 -mavx -S
k.i
[hjl@gnu-6 pr59501]$ cat k.s
.file "k.i"
.text
.globl foo
.type foo, @function
foo:
.LFB0:
.cfi_startproc
pushl %ebp
.cfi_def_cfa_offset 8
.cfi_offset 5, -8
movl%esp, %ebp
.cfi_def_cfa_register 5
pushl %ebx
andl$-32, %esp <<< This isn't needed.
.cfi_offset 3, -12
movl(%eax), %ebx
cmpl$0, 4(%eax)
jne .L1
cmpl$19, %ebx
ja .L1
sall$5, %ebx
vmovdqa (%ecx,%ebx), %ymm0
vmovdqa %ymm0, (%edx)
.L1:
movl-4(%ebp), %ebx
leave
.cfi_restore 5
.cfi_restore 3
.cfi_def_cfa 4, 4
ret
.cfi_endproc
.LFE0:
.size foo, .-foo
.ident "GCC: (GNU) 8.0.0 20170807 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-6 pr59501]$
[Bug tree-optimization/81723] [7 Regression] fortran build doesn't terminate on 64bit targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81723 Richard Biener changed: What|Removed |Added Known to work||8.0 Summary|[7/8 Regression] fortran|[7 Regression] fortran |build doesn't terminate on |build doesn't terminate on |64bit targets |64bit targets --- Comment #8 from Richard Biener --- Fixed on trunk sofar.
[Bug tree-optimization/81723] [7 Regression] fortran build doesn't terminate on 64bit targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81723 --- Comment #9 from Richard Biener --- Author: rguenth Date: Tue Aug 8 12:49:39 2017 New Revision: 250953 URL: https://gcc.gnu.org/viewcvs?rev=250953&root=gcc&view=rev Log: 2017-08-08 Richard Biener PR tree-optimization/81723 * tree-vect-slp.c (struct bst_traits): New hash traits. (bst_fail): New global. (vect_build_slp_tree_2): New worker, split out from ... (vect_build_slp_tree): ... this now wrapping it with using bst_fail set to cache SLP tree build fails. Properly handle max_tree_size. (vect_analyze_slp_instance): Allocate and free bst_fail. * gfortran.dg/pr81723.f: New testcase. Added: trunk/gcc/testsuite/gfortran.dg/pr81723.f Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-slp.c
[Bug middle-end/81719] Range-based for loop on short fixed size array generates long unrolled loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81719 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||8.0 Resolution|--- |FIXED --- Comment #2 from Richard Biener --- Fixed on trunk.
[Bug middle-end/81719] Range-based for loop on short fixed size array generates long unrolled loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81719 --- Comment #3 from Richard Biener --- Author: rguenth Date: Tue Aug 8 12:51:20 2017 New Revision: 250954 URL: https://gcc.gnu.org/viewcvs?rev=250954&root=gcc&view=rev Log: 2017-08-08 Richard Biener PR middle-end/81719 * tree-ssa-loop-niter.c: Include tree-dfa.h. (expand_simple_operations): Also look through ADDR_EXPRs with MEM_REF bases treating them as POINTER_PLUS_EXPR. * g++.dg/tree-ssa/pr81719.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/tree-ssa/pr81719.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-loop-niter.c
[Bug tree-optimization/81354] [5/6 Regression] Segmentation fault in SSA Strength Reduction using -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81354 --- Comment #10 from Bill Schmidt --- Author: wschmidt Date: Tue Aug 8 12:52:22 2017 New Revision: 250955 URL: https://gcc.gnu.org/viewcvs?rev=250955&root=gcc&view=rev Log: [gcc] 2017-08-08 Bill Schmidt PR tree-optimization/81354 * gimple-ssa-strength-reduction.c (create_add_on_incoming_edge): Insert on edges rather than explicitly creating landing pads. (analyze_candidates_and_replace): Commit edge inserts. [gcc/testsuite] 2017-08-08 Bill Schmidt PR tree-optimization/81354 * g++.dg/torture/pr81354.C: New file. Added: trunk/gcc/testsuite/g++.dg/torture/pr81354.C Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-ssa-strength-reduction.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/81354] [5/6 Regression] Segmentation fault in SSA Strength Reduction using -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81354 --- Comment #11 from Bill Schmidt --- Fixed on trunk so far, and verified that a modified backport fixes the limited range on 5.4 where the provided test case fails. Backports to follow in about a week after burn-in.
[Bug middle-end/19706] Recognize common Fortran usages of copysign.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19706 --- Comment #2 from Tamar Christina --- Author: tnfchris Date: Tue Aug 8 13:15:44 2017 New Revision: 250956 URL: https://gcc.gnu.org/viewcvs?rev=250956&root=gcc&view=rev Log: 2017-08-08 Tamar Christina Andrew Pinski PR middle-end/19706 * internal-fn.def (XORSIGN): New. * optabs.def (xorsign_optab): New. * tree-ssa-math-opts.c (is_copysign_call_with_1): New. (convert_expand_mult_copysign): New. (pass_optimize_widening_mul::execute): Call convert_expand_mult_copysign. Modified: trunk/gcc/ChangeLog trunk/gcc/internal-fn.def trunk/gcc/optabs.def trunk/gcc/tree-ssa-math-opts.c
[Bug middle-end/19706] Recognize common Fortran usages of copysign.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19706 --- Comment #3 from Tamar Christina --- Author: tnfchris Date: Tue Aug 8 13:17:41 2017 New Revision: 250957 URL: https://gcc.gnu.org/viewcvs?rev=250957&root=gcc&view=rev Log: 2017-08-08 Tamar Christina PR middle-end/19706 * config/aarch64/aarch64.md (xorsign3): New optabs. * config/aarch64/aarch64-builtins.c (aarch64_builtin_vectorized_function): Added CASE_CFN_XORSIGN. * config/aarch64/aarch64-simd-builtins.def: Added xorsign BINOP. * config/aarch64/aarch64-simd.md: Added xorsign3. gcc/testsuite/ 2017-08-08 Tamar Christina * gcc.target/aarch64/xorsign.c: New. * gcc.target/aarch64/xorsign_exec.c: New. * gcc.target/aarch64/vect-xorsign_exec.c: New. Added: trunk/gcc/testsuite/gcc.target/aarch64/vect-xorsign_exec.c trunk/gcc/testsuite/gcc.target/aarch64/xorsign.c trunk/gcc/testsuite/gcc.target/aarch64/xorsign_exec.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/aarch64-simd.md trunk/gcc/config/aarch64/aarch64.md trunk/gcc/testsuite/ChangeLog
[Bug target/81766] [8 Regression] ICE in maybe_add_or_update_dep_1, at sched-deps.c:924 caused by r250815
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81766 Richard Biener changed: What|Removed |Added Target Milestone|7.2 |8.0 Summary|[7/8 Regression] ICE in |[8 Regression] ICE in |maybe_add_or_update_dep_1, |maybe_add_or_update_dep_1, |at sched-deps.c:924 caused |at sched-deps.c:924 caused |by r250815 |by r250815 --- Comment #8 from Richard Biener --- Fix committed to gcc 7 branch. --- Comment #9 from Richard Biener --- Author: rguenth Date: Tue Aug 8 13:21:12 2017 New Revision: 250958 URL: https://gcc.gnu.org/viewcvs?rev=250958&root=gcc&view=rev Log: 2017-08-08 Richard Biener PR middle-end/81766 * function.c (thread_prologue_and_epilogue_insns): Restore behavior of always calling find_many_sub_basic_blocks on the inserted prologue. * gcc.target/i386/pr81766.c: New testcase. Added: branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr81766.c Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/function.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug target/81766] [8 Regression] ICE in maybe_add_or_update_dep_1, at sched-deps.c:924 caused by r250815
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81766 Richard Biener changed: What|Removed |Added Target Milestone|7.2 |8.0 Summary|[7/8 Regression] ICE in |[8 Regression] ICE in |maybe_add_or_update_dep_1, |maybe_add_or_update_dep_1, |at sched-deps.c:924 caused |at sched-deps.c:924 caused |by r250815 |by r250815 --- Comment #8 from Richard Biener --- Fix committed to gcc 7 branch.
[Bug fortran/81770] New: [5/6/7 Regression] Bogus warning: Pointer in pointer assignment might outlive the pointer target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81770 Bug ID: 81770 Summary: [5/6/7 Regression] Bogus warning: Pointer in pointer assignment might outlive the pointer target Product: gcc Version: 7.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: janus at gcc dot gnu.org Target Milestone: --- Please consider this test case: module m type t integer, allocatable :: l end type contains subroutine sub(c_in, list) type(t), target, intent(in) :: c_in integer, pointer, intent(out) :: list type(t), pointer :: container container => c_in list => container%l end subroutine end Since version 4.8 gfortran with -Wall gives the bogus warning: list => container%l 1 Warning: Pointer at (1) in pointer assignment might outlive the pointer target [-Wtarget-lifetime]
[Bug libstdc++/81771] New: __basic_file::sys_open is not a reserved name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81771 Bug ID: 81771 Summary: __basic_file::sys_open is not a reserved name Product: gcc Version: 8.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Target Milestone: --- #define sys_open 1 #include This fails to compile: so.cc:1:18: error: expected unqualified-id before numeric constant #define sys_open 1 ^ In file included from /usr/include/c++/6.3.1/fstream:42:0, from so.cc:2: /usr/include/c++/6.3.1/x86_64-redhat-linux/bits/basic_file.h:87:19: error: expected ‘;’ at end of member declaration __basic_file* ^ so.cc:1:18: error: expected unqualified-id before numeric constant #define sys_open 1 ^ so.cc:1:18: error: expected unqualified-id before numeric constant #define sys_open 1 ^ In file included from /usr/include/c++/6.3.1/fstream:42:0, from so.cc:2: /usr/include/c++/6.3.1/x86_64-redhat-linux/bits/basic_file.h:90:19: error: expected ‘;’ at end of member declaration __basic_file* ^ so.cc:1:18: error: expected unqualified-id before numeric constant #define sys_open 1 ^
[Bug libgomp/81768] error: control flow in the middle of basic block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81768 Alexander Monakov changed: What|Removed |Added Keywords||openmp CC||amonakov at gcc dot gnu.org --- Comment #1 from Alexander Monakov --- It's not quite right to say this is minimized from for-5.c, as original for-5.c does not fail in this way. The difference that makes this one ICE is presence of #pragma omp declare target [end] around declarations of global arrays. Unrelated to offloading (fails the same with -foffload=disable). Without the 'simd' clause it exhibits a different ICE: pr81768.c: In function ‘f14_tpf_simd_static32._omp_fn.1’: pr81768.c:21:1: error: constant not recomputed when ADDR_EXPR changed } ^ &b[0][0][0] cc1: note: in statement if (k > &b[0][0][0]) pr81768.c:21:1: error: constant not recomputed when ADDR_EXPR changed &b[0][0][0] cc1: note: in statement if (j > &b[0][0][0]) during IPA pass: *free_lang_data pr81768.c:21:1: internal compiler error: verify_gimple failed
[Bug libstdc++/81771] __basic_file::sys_open is not a reserved name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81771 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-08-08 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- Also __basic_file::fd, __basic_file::file, and __basic_file::xsputn_2
[Bug target/81766] [8 Regression] ICE in maybe_add_or_update_dep_1, at sched-deps.c:924 caused by r250815
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81766 --- Comment #10 from Jakub Jelinek --- Created attachment 41950 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41950&action=edit gcc8-pr81766.patch Untested patch that fixes the ICE.
[Bug middle-end/19706] Recognize common Fortran usages of copysign.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19706 Ramana Radhakrishnan changed: What|Removed |Added CC||ramana at gcc dot gnu.org Target Milestone|--- |8.0 --- Comment #4 from Ramana Radhakrishnan --- (In reply to Tamar Christina from comment #3) > Author: tnfchris > Date: Tue Aug 8 13:17:41 2017 > New Revision: 250957 > > URL: https://gcc.gnu.org/viewcvs?rev=250957&root=gcc&view=rev > Log: > 2017-08-08 Tamar Christina > > PR middle-end/19706 > * config/aarch64/aarch64.md (xorsign3): New optabs. > * config/aarch64/aarch64-builtins.c > (aarch64_builtin_vectorized_function): Added CASE_CFN_XORSIGN. > * config/aarch64/aarch64-simd-builtins.def: Added xorsign BINOP. > * config/aarch64/aarch64-simd.md: Added xorsign3. > > gcc/testsuite/ > 2017-08-08 Tamar Christina > > * gcc.target/aarch64/xorsign.c: New. > * gcc.target/aarch64/xorsign_exec.c: New. > * gcc.target/aarch64/vect-xorsign_exec.c: New. > > > Added: > trunk/gcc/testsuite/gcc.target/aarch64/vect-xorsign_exec.c > trunk/gcc/testsuite/gcc.target/aarch64/xorsign.c > trunk/gcc/testsuite/gcc.target/aarch64/xorsign_exec.c > Modified: > trunk/gcc/ChangeLog > trunk/gcc/config/aarch64/aarch64-simd.md > trunk/gcc/config/aarch64/aarch64.md > trunk/gcc/testsuite/ChangeLog I would have put these testcases into gcc.dg/vect and added a target_supports_vect_xorsign so that other targets had a fighting chance of catching such changes. Is this pattern relevant to AArch32 for instance ? If so I'd like to add those patterns there for bonus points ... I suspect the drotg testcase is fixed up by this . If so this bug should then be closed out as the mid-end has support for it. I'm not clear if slasv2.f is worth looking at further as another example.
[Bug tree-optimization/81503] [8 Regression] Wrong code at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81503 --- Comment #15 from Bill Schmidt --- Proposed patch awaiting approval: https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00347.html
[Bug target/81763] Issues with 32bit x86 apps on GCC 7.1+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81763 --- Comment #3 from Mike Lothian --- So dropping the -march=native allows everything to work again no matter which version of GCC Just using -mbmi breaks things and using -march=native -mno-bmi allows it all to work This is on a Skylake processor with the following in /proc/cpuinfo flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb intel_pt tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp
[Bug c/81566] [4.9/5/6/7/8 Regression] invalid attribute aligned accepted on functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81566 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-08-08 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Martin Sebor --- Testing a patch.
[Bug middle-end/80283] [5/6/7/8 Regression] bad SIMD register allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80283 shatz at dsit dot co.il changed: What|Removed |Added CC||shatz at dsit dot co.il --- Comment #16 from shatz at dsit dot co.il --- I still think that effect of tree-ter is accidental and relatively unimportant. Very similar problems with SIMD register allocation could easily happen without tree-ter, as demonstrated by 3 out of 4 cases of bad register allocation presented in this thread. It seems to me that the problem shall be handled in the back-end rather than middle-end (not sure that I got your terminology about various "ends" right).
[Bug tree-optimization/81741] Misoptimisation : replacing a constant field read access by a function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81741 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #4 from Jeffrey A. Law --- I've got changes to remove the propagation of conditional equivalences in DOM, but still allow us to use those equivalences for simplifications. However, they're backed up behind several other things. The most pressing of which is the stack-clash-protection work. Review work on stack-clash-protection would be appreciated. And FWIW, RTL CSE does conditional equivalence propagation as well.
[Bug libgomp/80859] Performance Problems with OpenMP 4.5 support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80859 --- Comment #27 from Thorsten Kurth --- Hello Jakub, I wanted to follow up on this. Is there any progress on this issue? Best Regards Thorsten Kurth
[Bug middle-end/80283] [5/6/7/8 Regression] bad SIMD register allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80283 --- Comment #17 from Wilco --- (In reply to shatz from comment #16) > I still think that effect of tree-ter is accidental and relatively > unimportant. > Very similar problems with SIMD register allocation could easily happen > without tree-ter, as demonstrated by 3 out of 4 cases of bad register > allocation presented in this thread. > > It seems to me that the problem shall be handled in the back-end rather than > middle-end (not sure that I got your terminology about various "ends" right). Backends cannot fix bad scheduling/allocation/spilling. The unnecessary register pressure is caused by the mid-end. Whether it's due to expand, ter, vectorizer or scheduler doesn't really matter - there must be a pass that reduces register pressure in areas where it is high.
[Bug c/81772] New: Compile-time snprintf optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81772 Bug ID: 81772 Summary: Compile-time snprintf optimization Product: gcc Version: 5.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: bugzi...@poradnik-webmastera.com Target Milestone: --- snprintf is slow. This is caused not only by format string handling, but there is also some internal fault with string handling - see https://sourceware.org/bugzilla/show_bug.cgi?id=21905 . Because of this it would be nice if gcc could perform some compile-time optimization. The best would be to parse format string at compile time and generate appropriate code for it, so there would be no format parsing at runtime at all. However any partial optimization here would be helpful. I found that sprintf with %s format is replaced with strcpy. snprintf with %s format could be replaced with strlcpy - unfortunately is is not supported yet by gcc/glibc, so other approach is needed (or implement strlcpy/strlcat and use them :))
[Bug middle-end/70100] [5 Regression] ICE: in execute, at cfgexpand.c:6066
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70100
--- Comment #3 from Jaak Ristioja ---
(In reply to Markus Trippelsdorf from comment #1)
> template struct K {
> using CmdSP = std::D;
> template void operator()(Args... args) {
> using MakeFunc = CmdSP(...);
> MakeFunc makeFuncs;
> [=] { [=] { makeFuncs(args...); }; };
> }
> };
...
> main.ii: In member function ‘void state::gen::K::operator()(Args ...)
> [with Args = {int}; Cmd = Get]’:
> main.ii:79:36: internal compiler error: in execute, at cfgexpand.c:6069
We hit a similar case in our proprietary production code, which compiled with
-O2 resulted in a segmentation fault, but when compiled with -O0, resulted in
this ICE.
Here is a smaller test-case to trigger this ICE with -std=c++11 -O0:
void b(int) {}
template
void f(Args && ... args) {
[&] {
[&] {
b(args...);
};
};
}
int main() { f(2); }
// gcc (Gentoo Hardened 5.4.0-r3 p1.3, pie-0.6.5) 5.4.0
Dunno, if it is relevant, but here is some of the disassembly output
at proprietary crash site with -O2 (attempting to read 1 byte from address 0x0,
according to Valgrind):
0x00105aa024ab <+1643>: mov%rax,%rbx
0x00105aa024ae <+1646>: movl $0x1,0x8(%rax)
0x00105aa024b5 <+1653>: movl $0x1,0xc(%rax)
0x00105aa024bc <+1660>: lea0x2a7f35(%rip),%rax #,
(__gnu_cxx::_Lock_policy)2>
=> 0x00105aa024c3 <+1667>: movzbl 0x0,%ecx
[Bug middle-end/80283] [5/6/7/8 Regression] bad SIMD register allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80283 --- Comment #18 from Michael_S --- O.k. Not a back end. The part of compiler that is responsible for binding local variables to registers or to stack locations. I am assuming that such part exists in gcc and acts after tree-ter phase, but before instruction scheduling. If nothing like that exists then please forget the previous comment.
[Bug c/81544] attribute noreturn and warn_unused_result on the same function accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81544 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #2 from Martin Sebor --- Patch posted for review: https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00602.html This general solution is intended to supersed Marek's more targeted fix previously posted here: https://gcc.gnu.org/ml/gcc-patches/2017-07/msg01590.html
[Bug c/81566] [4.9/5/6/7/8 Regression] invalid attribute aligned accepted on functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81566 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #4 from Martin Sebor --- Patch posted for review: https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00601.html
[Bug tree-optimization/53090] suboptimal ivopt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53090 amker at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #10 from amker at gcc dot gnu.org --- Hmm, It's not mentioned at which optimization level the original bug was reported. I suspect O2 because vect_perm instruction is needed after vectorization. So current status is: After ivopt rewriting, we generate below 8 instructions loop at O2 .L14: movl(%r14,%rax,4), %ecx movl(%r14,%rdx,4), %esi movl%esi, (%r14,%rax,4) movl%ecx, (%r14,%rdx,4) addq$1, %rax subq$1, %rdx cmpl%eax, %edx jg .L14 It's better than what was reported. at O3: .L14: movdqu (%rsi,%rdx), %xmm2 movdqa (%r12,%rax), %xmm0 pshufd $27, %xmm2, %xmm1 pshufd $27, %xmm0, %xmm0 movaps %xmm1, (%r12,%rax) addq$16, %rax movups %xmm0, (%rsi,%rdx) subq$16, %rdx cmpq%rax, %rdi jne .L14 Consider this fixed.
[Bug tree-optimization/71361] [7/8 Regression] Changes in ivopts caused perf regression on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71361 --- Comment #5 from amker at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #4) > So shall we defer this PR to GCC 8 then (i.e. [8 Regression] and Target > Milestone: 8.0? Richard, are you ok with that? With ivopt rewriting, we now generate below code: .L5: movl(%esi,%ecx,4), %eax movl40(%esp), %edx movl44(%esp), %ebx imull (%edi,%ecx,4), %ebx imull %eax, %edx imull 44(%esp), %eax addl%ebx, %edx movl40(%esp), %ebx imull (%edi,%ecx,4), %ebx addl%ebx, %eax movl36(%esp), %ebx movl%edx, (%ebx,%ecx,4) movl32(%esp), %ebx movl%edx, (%edi,%ecx,4) movl%eax, (%ebx,%ecx,4) movl%eax, (%esi,%ecx,4) addl28(%esp), %ecx cmpl$511, %ecx jle .L5 Which I think is optimal. Shall we consider this fixed?
[Bug tree-optimization/71361] [7/8 Regression] Changes in ivopts caused perf regression on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71361 --- Comment #6 from amker at gcc dot gnu.org --- Hmm, but it can't be backported to 7 branch.
[Bug fortran/81773] New: [Coarray] Get with vector index on lhs leads to incorrect caf_get_by_ref() call.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81773
Bug ID: 81773
Summary: [Coarray] Get with vector index on lhs leads to
incorrect caf_get_by_ref() call.
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: vehre at gcc dot gnu.org
Target Milestone: ---
Created attachment 41951
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41951&action=edit
Dump
Fortran code like:
tv(loc_idx(1:nhl,ip)) = xv%v(rmt_idx(1:nhl,ip))[xchg(ip)]
leads to the generation of pseudo-code:
atmp.33.dtype = 281;
atmp.33.dim[0].stride = 1;
atmp.33.dim[0].lbound = 0;
atmp.33.dim[0].ubound = 1;
atmp.33.data = (void * restrict) &A.34;
atmp.33.offset = 0;
{
integer(kind=8) S.35;
S.35 = 0;
while (1)
{
if (S.35 > 1) goto L.26;
{
integer(kind=4) D.3704;
D.3704 = (*(integer(kind=4)[0:] *)
parm.32.data)[parm.32.dim[0].stride * NON_LVALUE_EXPR ];
(*(real(kind=4)[2] * restrict) atmp.33.data)[S.35] =
(*D.3696)[(integer(kind=8)) D.3704 + D.3697];
}
S.35 = S.35 + 1;
}
L.26:;
}
atmp.33.dtype = 281;
caf_ref.36.type = 1;
__asm__ __volatile__("":::"memory");
_gfortran_caf_get_by_ref (xv.v.token, ((*(integer(kind=4)[0:] *
restrict) xchg.data)[xchg.offset + (integer(kind=8)) ip] - (integer(kind=4))
xv.v.dim[1].lbound) + 1, &atmp.33, &caf_ref.36, 4, 4, 0, 0, 0B);
without copying back the result afterwards. In fact is the while(1) loop above
unnecessary, because atmp.33 is write-only in this call.
Example and dump attached.
[Bug fortran/81773] [Coarray] Get with vector index on lhs leads to incorrect caf_get_by_ref() call.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81773 vehre at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 CC||vehre at gcc dot gnu.org Severity|minor |normal
[Bug fortran/81773] [Coarray] Get with vector index on lhs leads to incorrect caf_get_by_ref() call.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81773 --- Comment #1 from vehre at gcc dot gnu.org --- Created attachment 41952 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41952&action=edit Example producing the bug
[Bug target/81708] The x86 stack canary location should be customizable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81708 --- Comment #5 from uros at gcc dot gnu.org --- Author: uros Date: Tue Aug 8 16:48:46 2017 New Revision: 250965 URL: https://gcc.gnu.org/viewcvs?rev=250965&root=gcc&view=rev Log: PR target/81708 * config/i386/i386.opt (mstack-protector-guard-reg=): New option (mstack-protector-guard-offset=): Ditto. * config/i386/i386.c (ix86_option_override): Handle -mstack-protector-guard-reg= and -mstack-protector-guard-offset= options. (ix86_stack_protect_guard): Use ix86_stack_protect_guard_reg and ix86_stack_protect_guard_offset variables. (TARGET_STACK_PROTECT_GUARD): Always define. * doc/invoke.texi (x86 Options): Document -mstack-protector-guard-reg= and -mstack-protector-guard-offset= options. testsuite/ChangeLog: PR target/81708 * gcc.target/i386/stack-prot-guard.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/stack-prot-guard.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.opt trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/ChangeLog
[Bug libgomp/81591] segmentation fault when using priorities of nested tasks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81591 --- Comment #9 from Jakub Sistek --- Created attachment 41953 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41953&action=edit an enhanced version of the example producing an error Hi Jakub, sorry for my late response, I was on vacation :-) Thanks a lot for looking into it. Yes, your proposal seems to fix the issue for the example given before. Nevertheless, we are still observing some issues in the PLASMA library, and I have been able to reproduce them in the slightly extended example attached to this comment. The bug is not completely reproducible, sometimes, it pops out, other times the code works. I build the GOMP library with #define _LIBGOMP_CHECKING_ 1 and run the executable by OMP_NUM_THREADS=4 OMP_MAX_TASK_PRIORITY=10 ./nested_omp_tasks In approximately half of my runs, I get: libgomp: Attempt to downgrade missing task 0x7fe91c000900 If I do not run with the LIBGOMP_CHECKING, the code segfaults around line 940 of task.c, where the list becomes NULL, yet is accessed on line 942 inside the call to priority_list_downgrade_task. The other half of runs works just fine, so it is probably somehow related to the rate in which tasks get executed. This issue seems to be somehow related to the extra #pragma omp taskwait inside the parallel region. If this is not there, the code seems to work fine. I hope you can reproduce the problem. Thanks a lot and best wishes, Jakub
[Bug target/81708] The x86 stack canary location should be customizable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81708 Uroš Bizjak changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Uroš Bizjak --- Implemented for gcc-8.
[Bug c/81774] New: Volatile - order of reads in generated code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81774
Bug ID: 81774
Summary: Volatile - order of reads in generated code
Product: gcc
Version: new-ra
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pj at hugeone dot co.uk
Target Milestone: ---
I do not know if it and bug but it look strange to me.
Lets consider a trivial example:
int x3(int x)
{
volatile int y = x;
return y * y * y * y;
}
the code generated for x86-64 (7.1.0 - tested on many versions since 4.4.7)
(tested on ARM gcc up to 6.3 & AVR as well)
mov DWORD PTR [rsp-4], edi
mov eax, DWORD PTR [rsp-4]
mov esi, DWORD PTR [rsp-4]
mov ecx, DWORD PTR [rsp-4]
mov edx, DWORD PTR [rsp-4]
imuleax, esi
imuleax, ecx
imuleax, edx
IMO it reading the variable should be between the muls:
mov DWORD PTR [rsp-4], edi
mov eax, DWORD PTR [rsp-4]
mov esi, DWORD PTR [rsp-4]
imuleax, esi
mov ecx, DWORD PTR [rsp-4]
imuleax, ecx
mov edx, DWORD PTR [rsp-4]
imuleax, edx
as the stored value can change during the multiplications
[Bug c/81774] Volatile - order of reads in generated code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81774 Piotr changed: What|Removed |Added CC||pj at hugeone dot co.uk Version|new-ra |unknown --- Comment #1 from Piotr --- versions from 4.47 to 7.1.0
[Bug c/81774] Volatile - order of reads in generated code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81774 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andrew Pinski --- There is no sequence points between the accesses so the order of the reads is unspecified. Also multiply has no side effects on the loads so it gets scheduled around the loads.
[Bug tree-optimization/81772] Compile-time snprintf optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81772 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #1 from Martin Sebor --- GCC 7 does implement some additional sprintf and snprintf optimizations but it doesn't go quite as far as you'd like it to. The trouble is that there is no suitable alternative function to call when the arguments aren't constant. I suppose in the non-constant case and for small enough positive n, snprintf(d, n, "%s", s) could be transformed into something like tmp = strlen (s); if (n <= tmp) tmp = n - 1; memcpy (d, s, tmp); d[tmp] = '\0'; trading off space (more code) for speed. But whether or not this would be a win would depend on the snprintf implementation. It seems to me that a better place to implement this optimization is in snprintf itself.
[Bug target/81708] The x86 stack canary location should be customizable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81708 --- Comment #7 from Andy Lutomirski --- Hmm. This is a big improvement, but it's still going to be awkward to use -- if we want to use a normal Linux percpu variable, we're stuck putting it in a fixed location that's known at compile time as opposed to just at link time. It also still prevents Linux from switching to PC-relative percpu addressing to reduce text size. Can we do -mstack-protector-offset=[symbol name]? And could it be extended to ask for PC-relative addressing?
[Bug c/81774] Volatile - order of reads in generated code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81774
--- Comment #3 from Piotr ---
And what about if volatile variable changes during the multiplications. Mybe
not in this example but if y was declared global - it can be interrupted
between multiplications.
volatile int y;
int x3(int x)
{
return y * y * y * y;
}
[Bug target/81708] The x86 stack canary location should be customizable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81708 --- Comment #8 from H. Peter Anvin --- How about simply letting the user enter an assembly expression of neither of the standard ABI options are suitable? Also, shouldn't the user space default on 64 bits be an offset into the TLS using %fs, or is there something magic about how the kernel is compiled that changes it to %gs:?
[Bug fortran/81748] extensible types non-conforming behaviour
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81748 Thomas Koenig changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-08-08 CC||tkoenig at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Thomas Koenig --- Seems the output varies a bit. With current trunk, I get the (also incorrect) 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 4195840 4195840 4 5 and valgrind tells me ig25@linux-d6cw:/tmp> valgrind ./a.out ==3717== Memcheck, a memory error detector ==3717== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==3717== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info ==3717== Command: ./a.out ==3717== 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 ==3717== Conditional jump or move depends on uninitialised value(s) ==3717==at 0x40081F: __m_MOD_s (anton.f90:17) ==3717==by 0x400B8F: MAIN__ (anton.f90:30) ==3717==by 0x400D4E: main (anton.f90:22) ==3717== ==3717== Conditional jump or move depends on uninitialised value(s) ==3717==at 0x4E5560B: _gfortrani_gfc_itoa (string.c:191) ==3717==by 0x516FF7A: write_integer (write.c:1311) ==3717==by 0x5178CC5: list_formatted_write_scalar (write.c:1880) ==3717==by 0x517C1D4: _gfortrani_list_formatted_write (write.c:1958) ==3717==by 0x4008BA: __m_MOD_s (anton.f90:17) ==3717==by 0x400B8F: MAIN__ (anton.f90:30) ==3717==by 0x400D4E: main (anton.f90:22)
[Bug target/81708] The x86 stack canary location should be customizable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81708 --- Comment #9 from H. Peter Anvin --- In some applications it might even be appropriate to use the RDPID instruction and store the canary in the IA32_TSC_AUX MSR.
[Bug libstdc++/17215] [3.4 only] __basic_file::close ignores errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17215 Jonathan Wakely changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=65411 --- Comment #11 from Jonathan Wakely --- N.B. For PR 65411 I reverted the loop on fclose, because even after EINTR it's undefined to retry fclose.
[Bug libgcc/81775] New: GCC fails to compile: md-unwind-support.h:65 dereferencing pointer to incomplete type ‘struct ucontext’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81775 Bug ID: 81775 Summary: GCC fails to compile: md-unwind-support.h:65 dereferencing pointer to incomplete type ‘struct ucontext’ Product: gcc Version: 7.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: guido at trentalancia dot com Target Milestone: --- GCC 7.1.0 fails to rebuild (with the same version of the compiler) because of the following error: /home/guido/build-gcc-7.1.0/./gcc/xgcc -B/home/guido/build-gcc-7.1.0/./gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include -g -O2 -O3 -march=nehalem -mtune=nehalem -O2 -g -O2 -O3 -march=nehalem -mtune=nehalem -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fpic -mlong-double-80 -DUSE_ELF_SYMVER -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fpic -mlong-double-80 -DUSE_ELF_SYMVER -I. -I. -I../.././gcc -I../../../gcc-7.1.0/libgcc -I../../../gcc-7.1.0/libgcc/. -I../../../gcc-7.1.0/libgcc/../gcc -I../../../gcc-7.1.0/libgcc/../include -I../../../gcc-7.1.0/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_TLS -o unwind-dw2-fde-dip.o -MT unwind-dw2-fde-dip.o -MD -MP -MF unwind-dw2-fde-dip.dep -fexceptions -c ../../../gcc-7.1.0/libgcc/unwind-dw2-fde-dip.c -fvisibility=hidden -DHIDE_EXPORTS /home/guido/build-gcc-7.1.0/./gcc/xgcc -B/home/guido/build-gcc-7.1.0/./gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include -g -O2 -O3 -march=nehalem -mtune=nehalem -O2 -g -O2 -O3 -march=nehalem -mtune=nehalem -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fpic -mlong-double-80 -DUSE_ELF_SYMVER -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fpic -mlong-double-80 -DUSE_ELF_SYMVER -I. -I. -I../.././gcc -I../../../gcc-7.1.0/libgcc -I../../../gcc-7.1.0/libgcc/. -I../../../gcc-7.1.0/libgcc/../gcc -I../../../gcc-7.1.0/libgcc/../include -I../../../gcc-7.1.0/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_TLS -o unwind-sjlj.o -MT unwind-sjlj.o -MD -MP -MF unwind-sjlj.dep -fexceptions -c ../../../gcc-7.1.0/libgcc/unwind-sjlj.c -fvisibility=hidden -DHIDE_EXPORTS In file included from ../../../gcc-7.1.0/libgcc/unwind-dw2.c:403:0: ./md-unwind-support.h: In function ‘x86_64_fallback_frame_state’: ./md-unwind-support.h:65:47: error: dereferencing pointer to incomplete type ‘struct ucontext’ sc = (struct sigcontext *) (void *) &uc_->uc_mcontext; ^~ make[3]: *** [../../../gcc-7.1.0/libgcc/shared-object.mk:14: unwind-dw2.o] Error 1 make[3]: exiting from directory "/home/guido/build-gcc-7.1.0/x86_64-pc-linux-gnu/libgcc"
[Bug fortran/81251] check of logical pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81251 Thomas Koenig changed: What|Removed |Added Status|WAITING |RESOLVED CC||tkoenig at gcc dot gnu.org Resolution|--- |INVALID --- Comment #2 from Thomas Koenig --- -Wall gives the relevant warning, as Dominique pointed out.
[Bug libgcc/81775] GCC fails to compile: md-unwind-support.h:65 dereferencing pointer to incomplete type ‘struct ucontext’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81775 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Already fixed. *** This bug has been marked as a duplicate of bug 81712 ***
[Bug other/81712] gcc does not compile when using glib 2.26 (everything works fine with 2.25)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81712 Andrew Pinski changed: What|Removed |Added CC||guido at trentalancia dot com --- Comment #5 from Andrew Pinski --- *** Bug 81775 has been marked as a duplicate of this bug. ***
[Bug target/81763] Issues with BMI on 32bit x86 apps on GCC 7.1+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81763 --- Comment #4 from Andrew Pinski --- This might be PR 53399.
