[Bug rtl-optimization/81747] [8 Regression] ICE in operator[], at vec.h:749

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81747

--- Comment #6 from Segher Boessenkool  ---
Yeah, I found out it is _not_ the one the backtrace (or GDB) points at.

I have a patch:

===
diff --git a/gcc/cse.c b/gcc/cse.c
index 6a968d1..34650d2 100644
--- a/gcc/cse.c
+++ b/gcc/cse.c
@@ -6642,6 +6642,7 @@ cse_extended_basic_block (struct cse_basic_block_data
*ebb
   if (path_entry < path_size - 1
  && JUMP_P (insn)
  && single_set (insn)
+ && EDGE_COUNT (bb->succs) == 2
  && any_condjump_p (insn))
{
  basic_block next_bb = ebb_data->path[path_entry + 1].bb;
===

Do you want to handle it?  More your timezone than mine ;-)

[Bug rtl-optimization/81747] [8 Regression] ICE in operator[], at vec.h:749

[amodra at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81747

--- Comment #5 from Alan Modra  ---
Segher, the confusion is due to looking at the wrong BRANCH_EDGE occurrence in
cse.c

[Bug target/81389] _mm_cmpestri segfault on -O0

[rockeet at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81389

rockeet  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

--- Comment #7 from rockeet  ---
@Marc @Jakub @Martin
Intel CPU document says: operand of _mm_cmpestri can be memory or mm register,
when the operand is memory, it does not require alignment.

The issue is: GCC does not know this knowledge(memory operand need not memory
align), and there is no way to enforce gcc to generate a _mm_cmpestri which
always use memory operand, not mm register.

If I manually load the unaligned memory into an aligned `__m128i`, it has
performance penalty on optimizing compilation.

At last, we can always use `asm` to workaround this issue, but this is not the
ideal solution!

[Bug rtl-optimization/81747] [8 Regression] ICE in operator[], at vec.h:749

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81747

--- Comment #4 from Segher Boessenkool  ---
Yeah, but the condition in which BRANCH_EDGE is called starts with

  if (EDGE_COUNT (previous_bb_in_path->succs) == 2

so I'm confused now.

[Bug tree-optimization/81776] New: missing sprintf optimization due to pointer escape analysis

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81776

Bug ID: 81776
   Summary: missing sprintf optimization due to pointer escape
analysis
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

When a built-in function like memcpy or strcpy is called with a local buffer
GCC knows that the call doesn't clobber other local buffers.  But the analysis
seems to be missing a case to make the same determination for calls to sprintf
or snprintf.  As a result, as the following case shows, when sprintf if
transformed to strcpy, GCC successfully optimizes away the test and subsequent
call to abort in g1().  But when the same sprintf to strcpy transformation is
defeated by using the '-' flag in the "%-s" directive, GCC fails to make the
same optimization in g2().

$ cat a.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout b.c
void f (void*);

struct S { char *a, *b; };

void g1 (struct S *p, const char *s, unsigned n)
{
  p->a = __builtin_malloc (n + 1);
  p->a[0] = 123;

  p->b = __builtin_malloc (n + 1);

  __builtin_sprintf (p->b, "%s", s);

  if (p->a[0] != 123) // can never be true
__builtin_abort ();   // eliminated

  __builtin_sprintf (p->b, "%s", s);

  f (p);
}

void g2 (struct S *p, const char *s, unsigned n)
{
  p->a = __builtin_malloc (n + 1);
  p->a[0] = 123;

  p->b = __builtin_malloc (n + 1);

  __builtin_sprintf (p->b, "%-s", s);

  if (p->a[0] != 123) // can never be true
__builtin_abort ();   // not eliminated

  __builtin_sprintf (p->a, "%-s", s);

  f (p);
}

;; Function g1 (g1, funcdef_no=0, decl_uid=1822, cgraph_uid=0, symbol_order=0)

g1 (struct S * p, const char * s, unsigned int n)
{
  unsigned int _1;
  long unsigned int _2;
  void * _3;
  void * _4;

   [100.00%] [count: INV]:
  _1 = n_8(D) + 1;
  _2 = (long unsigned int) _1;
  _3 = __builtin_malloc (_2);
  p_11(D)->a = _3;
  MEM[(char *)_3] = 123;
  _4 = __builtin_malloc (_2);
  p_11(D)->b = _4;
  __builtin_strcpy (_4, s_16(D));
  __builtin_strcpy (_4, s_16(D));
  f (p_11(D)); [tail call]
  return;

}



;; Function g2 (g2, funcdef_no=1, decl_uid=1827, cgraph_uid=1, symbol_order=1)

g2 (struct S * p, const char * s, unsigned int n)
{
  unsigned int _1;
  long unsigned int _2;
  void * _3;
  void * _4;
  char * _5;
  char _6;

   [100.00%] [count: INV]:
  _1 = n_7(D) + 1;
  _2 = (long unsigned int) _1;
  _3 = __builtin_malloc (_2);
  p_10(D)->a = _3;
  MEM[(char *)_3] = 123;
  _4 = __builtin_malloc (_2);
  p_10(D)->b = _4;
  __builtin_sprintf (_4, "%-s", s_15(D));
  _5 = p_10(D)->a;
  _6 = *_5;
  if (_6 != 123)
goto ; [0.04%] [count: 0]
  else
goto ; [99.96%] [count: INV]

   [0.04%] [count: 0]:
  __builtin_abort ();

   [99.96%] [count: INV]:
  __builtin_sprintf (_5, "%-s", s_15(D));
  f (p_10(D)); [tail call]
  return;

}

[Bug target/81763] Issues with BMI on 32bit x86 apps on GCC 7.1+

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81763

--- Comment #7 from H.J. Lu  ---
(In reply to Mike Lothian from comment #6)
> I tried the test case with
> 
> gcc -O2 -march=native test.c -o test
> 
> and 
> 
> gcc -O2 -march=native -mno-bmi test.c -o test
> 
> Both executables seem to run with no output
> 
> I've only seen the issue in radeonsi in Mesa with LLVM, I'm not sure what's
> happening as the problem doesn't manifest when debugging is enabled so I'm
> not sure how to create a smaller test case

Compile radeonsi one function at a time with and without -mbmi to
find out the smallest function which causes the problem with -mbmi.
If the function is small enough, we can take a guess.

[Bug rtl-optimization/81747] [8 Regression] ICE in operator[], at vec.h:749

[amodra at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81747

Alan Modra  changed:

   What|Removed |Added

 CC||amodra at gmail dot com

--- Comment #3 from Alan Modra  ---
The ICE occurs on this line in cse.c
  bool taken = (next_bb == BRANCH_EDGE (bb)->dest);

looking at the definition of BRANCH_EDGE,

EDGE_SUCC ((bb), 0)->flags & EDGE_FALLTHRU is true
but
 p *bb->succs
$4 = {m_vecpfx = {m_alloc = 4, m_using_auto_storage = 0, m_num = 1}, m_vecdata
= {0x76a32658}}

So only one successor, and attempting to access EDGE_SUCC(bb,1) is what
triggers the ICE.

[Bug tree-optimization/81772] Compile-time snprintf optimization

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81772

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-09
 Ever confirmed|0   |1

--- Comment #3 from Martin Sebor  ---
Thanks for the strncat suggestion.  That seems quite doable.  I'll try to find
some time to look into it.

I explored some of the other ideas when I implemented the GCC 7 sprintf
optimization (-fprintf-return-value) and warnings (-Wformat-overflow and
-Wformat-truncation) but they didn't seem applicable in enough situations (when
all or at least some of the arguments were constant) to justify either the
additional complexity or the space overhead.

[Bug target/81763] Issues with BMI on 32bit x86 apps on GCC 7.1+

[mike at fireburn dot co.uk]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81763

--- Comment #6 from Mike Lothian  ---
I tried the test case with

gcc -O2 -march=native test.c -o test

and 

gcc -O2 -march=native -mno-bmi test.c -o test

Both executables seem to run with no output

I've only seen the issue in radeonsi in Mesa with LLVM, I'm not sure what's
happening as the problem doesn't manifest when debugging is enabled so I'm not
sure how to create a smaller test case

[Bug rtl-optimization/81747] [8 Regression] ICE in operator[], at vec.h:749

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81747

Segher Boessenkool  changed:

   What|Removed |Added

   Keywords|ice-on-valid-code   |ice-on-invalid-code
 Target|powerpc-*-linux-gnu*,   |powerpc*-*-linux-gnu*,
   |powerpcspe-*-linux-gnu* |powerpcspe-*-linux-gnu*

--- Comment #2 from Segher Boessenkool  ---
This ICEs on any powerpc, not just 32-bit or with isel, etc.

The ICE is gone if you make the function return a value, so it is
ICE-on-invalid (at least since C99).

[Bug c++/81607] [6/7 Regression] Conditional operator: "type mismatch in shift expression" error

[babokin at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81607

--- Comment #12 from Dmitry Babokin  ---
The fix helped all fails that I see (with all 7 different symptoms). Thanks!

[Bug driver/81498] Support creating static PIE

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81498
Bug 81498 depends on bug 81523, which changed state.

Bug 81523 Summary: -static -pie behaves differently depending on if 
--enable-default-pie is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81523

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

[Bug driver/80044] Specifying both -static and -pie insanity

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80044
Bug 80044 depends on bug 81523, which changed state.

Bug 81523 Summary: -static -pie behaves differently depending on if 
--enable-default-pie is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81523

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

[Bug target/81170] powerpc*-linux --enable-default-pie chooses incorrect startup files

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81170
Bug 81170 depends on bug 81523, which changed state.

Bug 81523 Summary: -static -pie behaves differently depending on if 
--enable-default-pie is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81523

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

[Bug driver/81523] -static -pie behaves differently depending on if --enable-default-pie is used

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81523

H.J. Lu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |8.0

--- Comment #4 from H.J. Lu  ---
Fixed for GCC 8.

[Bug driver/81523] -static -pie behaves differently depending on if --enable-default-pie is used

[hjl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81523

--- Comment #3 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Tue Aug  8 22:06:21 2017
New Revision: 250974

URL: https://gcc.gnu.org/viewcvs?rev=250974=gcc=rev
Log:
PR driver/81523: Make -static override -pie

-static and -pie together behave differently depending on whether GCC is
configured with --enable-default-pie.  On x86, "-static -pie" fails to
create executable when --enable-default-pie isn't used, but creates a
static executable when --enable-default-pie is used.  This patch makes
-static completely override -pie to create a static executable, regardless
if --enable-default-pie is used to configure GCC.

gcc/

PR driver/81523
* gcc.c (NO_PIE_SPEC): Delete.
(PIE_SPEC): Define as !no-pie/pie.  Move static|shared|r
exclusion..
(LINK_PIE_SPEC): ..to here.
(LINK_COMMAND_SPEC): Support -no-pie.
* config/gnu-user.h (GNU_USER_TARGET_STARTFILE_SPEC): Correct
chain of crtbegin*.o selection, update for PIE_SPEC changes and
format.
(GNU_USER_TARGET_ENDFILE_SPEC): Similarly.
* config/sol2.h (STARTFILE_CRTBEGIN_SPEC): Similarly.
(ENDFILE_CRTEND_SPEC): Similarly.

gcc/testsuite/

PR driver/81523
* gcc.dg/pie-7.c: New test.
* gcc.dg/pie-static-1.c: Likewise.
* gcc.dg/pie-static-2.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/pie-7.c
trunk/gcc/testsuite/gcc.dg/pie-static-1.c
trunk/gcc/testsuite/gcc.dg/pie-static-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/gnu-user.h
trunk/gcc/config/sol2.h
trunk/gcc/gcc.c
trunk/gcc/testsuite/ChangeLog

[Bug ipa/81465] [8 Regression] ICE in estimate_edge_growth at gcc/ipa-inline.h:85 on s390x target

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81465

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-08
Summary|ICE in estimate_edge_growth |[8 Regression] ICE in
   |at gcc/ipa-inline.h:85 on   |estimate_edge_growth at
   |s390x target|gcc/ipa-inline.h:85 on
   ||s390x target
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Also started with r250048.

[Bug target/81766] [8 Regression] ICE in maybe_add_or_update_dep_1, at sched-deps.c:924 caused by r250815

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81766

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #11 from Segher Boessenkool  ---
(In reply to Uroš Bizjak from comment #6)
> (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.

It can be a separate component, which is a very good idea if initialising
the PIC reg is expensive, or if you often need it done before you need the
rest of the prologue.  It can also be part of the normal prologue, which
will work just fine (shrink-wrapping knows about the PIC reg, it puts the
prologue before any use of the PIC reg).  But the i386 port uses
TARGET_INIT_PIC_REG instead.  Why can't this be done in the prologue, are
there any downsides to that?

[Bug c++/81750] Calling generic lambda with no parameter fails to compile

[rs2740 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81750

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #1 from TC  ---
This is bug 64095.

[Bug libstdc++/81669] trunk/gcc/fibonacci_heap.h:58: possible missing initialisation ?

[rs2740 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81669

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #1 from TC  ---
This is not libstdc++.

[Bug target/81485] [SH] ICE: in sh_find_set_of_reg, at config/sh/sh-protos.h:232

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81485

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-08-08
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Is it reproducible with x86_64-linux-gnu cross-compiler?

[Bug rtl-optimization/81747] [8 Regression] ICE in operator[], at vec.h:749

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81747

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-08
 CC||amodra at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org,
   ||segher at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, started with r244465 (one needs to apply patch from r244489).

[Bug tree-optimization/81772] Compile-time snprintf optimization

[bugzi...@poradnik-webmastera.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81772

--- Comment #2 from Daniel Fruzynski  ---
You probably could optimize snprintf(buf, size, "%s", str) into this:

if (size > 0)
{
  buf[0] = 0;
  strncat(buf, str, size - 1);
}

Other optimizations would require to generate more code aa you wrote. Some of
them probably could be applied, e.g. transforming first line to second:

sprintf(buf, "%s %d", "123", arg);
memcpy(buf, "123 ", 4); sprintf(buf+4, "%d", arg);

Dedicated string concatenation function with multiple args also would be
helpful to perform following transformation:

sprintf(buf, "Content-Type: %s/%s\n", str1, str2);
multistrcat(buf, "Content-Type: ", str1, "/", str2, "\n");

It is also possible to parse format string and create sprintf with series of
commands which will create the same result. Of course this will increase code
size like you wrote, so user would have to explicitly enable this optimization.
There are many factors there which must be taken into account, e.g. number of
format arguments, use of advanced formatting (e.g. setting field width or
precision), etc.

[Bug other/81096] [8 regression] test case ttest in libbacktrace fails starting with its introduction in r249111

[sje at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81096

Steve Ellcey  changed:

   What|Removed |Added

 CC||sje at gcc dot gnu.org

--- Comment #3 from Steve Ellcey  ---
I see this same failure on aarch64-*-linux-gnu.

% ./ttest
test1: not enough frames; got 1, expected at least 3
test1: not enough frames; got 1, expected at least 3
test1: not enough frames; got 1, expected at least 3
test1: not enough frames; got 1, expected at least 3
test1: not enough frames; got 1, expected at least 3
test1: not enough frames; got 1, expected at least 3
test1: not enough frames; got 1, expected at least 3
test1: not enough frames; got 1, expected at least 3
test1: not enough frames; got 1, expected at least 3
test1: not enough frames; got 1, expected at least 3
FAIL: threaded backtrace_full noinline

[Bug target/64512] ICE: in sched_analyze_reg, at sched-deps.c:2360 with -O2 -mmemcpy-strategy=vector_loop:-1:align -mno-push-args

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64512

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-08-08
 CC||marxin at gcc dot gnu.org,
   ||vmakarov at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, appeared with r217265 and disappeared with r221541.
Vladimir is the later revision really fixing the issue or just hiding?

[Bug libstdc++/81751] __basic_file::sync() may flush _all_ files

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81751

--- Comment #2 from Jonathan Wakely  ---
The current __basic_file::sys_open behaviour came from the PR 17215 fix
(r86756). Before that change we called sync() after doing _M_cfile=__file, but
after we call sync() while it's still null.

I think rather than changing sync(), the correct fix is to not call it while
_M_cfile is null. Instead we should directly call fflush(__file) in sys_open.
That should restore the behaviour that was present before GCC 3.4.4

[Bug libgomp/68033] OpenMP: ICE with teams distribute

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68033

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code, openmp
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-08
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug target/68485] ICE while building gpsd package on microblaze

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68485

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-08-08
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Can you please provide a pre-processed source file (adding -E option)?

[Bug bootstrap/79120] lm32 ICE in dwarf2out_frame_debug_expr, at dwarf2cfi.c:1747

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79120

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-08-08
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Can you please provide pre-processed source file (adding -E option)?

[Bug c++/81197] [7/8 Regression] ICE with structured binding and lifetime-extended temporaries

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81197

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-08
 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
Summary|ICE with structured binding |[7/8 Regression] ICE with
   |and lifetime-extended   |structured binding and
   |temporaries |lifetime-extended
   ||temporaries
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
Confirmed, started with r242377.

[Bug libstdc++/79820] std::ifstream sets errno to zero

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79820

--- Comment #7 from Jonathan Wakely  ---
The bug title says std::ifstream sets errno to zero, but it should never run
stdio_filebuf::sys_open. Do you have a testcase for this?

We should still fix it even if it only affects a non-standard extension, but
it's probably not worth backporting if it doesn't affect std::ifstream.

[Bug target/79391] sh ICE in in eligible_for_delay, at config/sh/sh.md:564

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79391

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-08-08
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Can you please provide pre-processed source file (-E), I will then bisect that.

[Bug target/79565] ICE in copy_to_mode_reg, at explow.c:612

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79565

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-08
 Ever confirmed|0   |1

[Bug target/81763] Issues with BMI on 32bit x86 apps on GCC 7.1+

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81763

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-08-08
 CC||hjl.tools at gmail dot com
 Ever confirmed|0   |1

--- Comment #5 from H.J. Lu  ---
Please extract a small testcase.

[Bug target/81763] Issues with BMI on 32bit x86 apps on GCC 7.1+

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81763

--- Comment #4 from Andrew Pinski  ---
This might be PR 53399.

[Bug libgcc/81775] GCC fails to compile: md-unwind-support.h:65 dereferencing pointer to incomplete type ‘struct ucontext’

[pinskia at gcc dot gnu.org]

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)

[pinskia at gcc dot gnu.org]

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 fortran/81251] check of logical pointers

[tkoenig at gcc dot gnu.org]

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] New: GCC fails to compile: md-unwind-support.h:65 dereferencing pointer to incomplete type ‘struct ucontext’

[guido at trentalancia dot com]

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_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 libstdc++/17215] [3.4 only] __basic_file::close ignores errors

[redi at gcc dot gnu.org]

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 target/81708] The x86 stack canary location should be customizable

[hpa at zytor dot com]

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 fortran/81748] extensible types non-conforming behaviour

[tkoenig at gcc dot gnu.org]

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

[hpa at zytor dot com]

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 c/81774] Volatile - order of reads in generated code

[pj at hugeone dot co.uk]

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

[luto at kernel dot org]

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 tree-optimization/81772] Compile-time snprintf optimization

[msebor at gcc dot gnu.org]

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 c/81774] Volatile - order of reads in generated code

[pinskia at gcc dot gnu.org]

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 c/81774] Volatile - order of reads in generated code

[pj at hugeone dot co.uk]

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] New: Volatile - order of reads in generated code

[pj at hugeone dot co.uk]

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 target/81708] The x86 stack canary location should be customizable

[ubizjak at gmail dot com]

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 libgomp/81591] segmentation fault when using priorities of nested tasks

[sistek at seznam dot cz]

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=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

[uros at gcc dot gnu.org]

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=gcc=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 fortran/81773] [Coarray] Get with vector index on lhs leads to incorrect caf_get_by_ref() call.

[vehre at gcc dot gnu.org]

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=edit
Example producing the bug

[Bug fortran/81773] [Coarray] Get with vector index on lhs leads to incorrect caf_get_by_ref() call.

[vehre at gcc dot gnu.org]

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] New: [Coarray] Get with vector index on lhs leads to incorrect caf_get_by_ref() call.

[vehre at gcc dot gnu.org]

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=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) 
  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, , _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 tree-optimization/71361] [7/8 Regression] Changes in ivopts caused perf regression on x86

[amker at gcc dot gnu.org]

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 tree-optimization/71361] [7/8 Regression] Changes in ivopts caused perf regression on x86

[amker at gcc dot gnu.org]

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/53090] suboptimal ivopt

[amker at gcc dot gnu.org]

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 c/81566] [4.9/5/6/7/8 Regression] invalid attribute aligned accepted on functions

[msebor at gcc dot gnu.org]

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 c/81544] attribute noreturn and warn_unused_result on the same function accepted

[msebor at gcc dot gnu.org]

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 middle-end/80283] [5/6/7/8 Regression] bad SIMD register allocation

[already5chosen at yahoo dot com]

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 middle-end/70100] [5 Regression] ICE: in execute, at cfgexpand.c:6066

[jaak at ristioja dot ee]

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 c/81772] New: Compile-time snprintf optimization

[bugzi...@poradnik-webmastera.com]

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/80283] [5/6/7/8 Regression] bad SIMD register allocation

[wilco at gcc dot gnu.org]

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 libgomp/80859] Performance Problems with OpenMP 4.5 support

[thorstenkurth at me dot com]

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 tree-optimization/81741] Misoptimisation : replacing a constant field read access by a function call

[law at redhat dot com]

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 middle-end/80283] [5/6/7/8 Regression] bad SIMD register allocation

[shatz at dsit dot co.il]

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 c/81566] [4.9/5/6/7/8 Regression] invalid attribute aligned accepted on functions

[msebor at gcc dot gnu.org]

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 target/81763] Issues with 32bit x86 apps on GCC 7.1+

[mike at fireburn dot co.uk]

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 tree-optimization/81503] [8 Regression] Wrong code at -O2

[wschmidt at gcc dot gnu.org]

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 middle-end/19706] Recognize common Fortran usages of copysign.

[ramana at gcc dot gnu.org]

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=gcc=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 target/81766] [8 Regression] ICE in maybe_add_or_update_dep_1, at sched-deps.c:924 caused by r250815

[jakub at gcc dot gnu.org]

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=edit
gcc8-pr81766.patch

Untested patch that fixes the ICE.

[Bug libstdc++/81771] __basic_file::sys_open is not a reserved name

[redi at gcc dot gnu.org]

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 libgomp/81768] error: control flow in the middle of basic block

[amonakov at gcc dot gnu.org]

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
 }
 ^
[0][0][0]
cc1: note: in statement
if (k > [0][0][0])
pr81768.c:21:1: error: constant not recomputed when ADDR_EXPR changed
[0][0][0]
cc1: note: in statement
if (j > [0][0][0])
during IPA pass: *free_lang_data
pr81768.c:21:1: internal compiler error: verify_gimple failed

[Bug libstdc++/81771] New: __basic_file::sys_open is not a reserved name

[redi at gcc dot gnu.org]

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 fortran/81770] New: [5/6/7 Regression] Bogus warning: Pointer in pointer assignment might outlive the pointer target

[janus at gcc dot gnu.org]

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 target/81766] [8 Regression] ICE in maybe_add_or_update_dep_1, at sched-deps.c:924 caused by r250815

[rguenth at gcc dot gnu.org]

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 target/81766] [8 Regression] ICE in maybe_add_or_update_dep_1, at sched-deps.c:924 caused by r250815

[rguenth at gcc dot gnu.org]

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=gcc=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 middle-end/19706] Recognize common Fortran usages of copysign.

[tnfchris at gcc dot gnu.org]

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=gcc=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 middle-end/19706] Recognize common Fortran usages of copysign.

[tnfchris at gcc dot gnu.org]

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=gcc=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 tree-optimization/81354] [5/6 Regression] Segmentation fault in SSA Strength Reduction using -O3

[wschmidt at gcc dot gnu.org]

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 tree-optimization/81354] [5/6 Regression] Segmentation fault in SSA Strength Reduction using -O3

[wschmidt at gcc dot gnu.org]

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=gcc=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 middle-end/81719] Range-based for loop on short fixed size array generates long unrolled loop

[rguenth at gcc dot gnu.org]

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=gcc=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 middle-end/81719] Range-based for loop on short fixed size array generates long unrolled loop

[rguenth at gcc dot gnu.org]

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 tree-optimization/81723] [7 Regression] fortran build doesn't terminate on 64bit targets

[rguenth at gcc dot gnu.org]

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=gcc=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 tree-optimization/81723] [7 Regression] fortran build doesn't terminate on 64bit targets

[rguenth at gcc dot gnu.org]

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 target/81766] [7/8 Regression] ICE in maybe_add_or_update_dep_1, at sched-deps.c:924 caused by r250815

[jakub at gcc dot gnu.org]

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

[hjl.tools at gmail dot com]

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 c++/81767] Unused variable warning with structured binding

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81767

--- Comment #1 from Jonathan Wakely  ---
Already fixed on trunk with r248483

[Bug libgomp/81768] New: error: control flow in the middle of basic block

[vries at gcc dot gnu.org]

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 = [0][0][0]; i < [0][0][10]; i++)

for (float *j = [0][15][0]; j > [0][0][0]; j -= 10)

  for (float *k = [0][0][10]; k > [0][0][0]; --k)

b[i - [0][0][0]][(j - [0][0][0]) / 10 - 1][(k - [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  for instructions.
...

[Bug target/81766] [7/8 Regression] ICE in maybe_add_or_update_dep_1, at sched-deps.c:924 caused by r250815

[ubizjak at gmail dot com]

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 target/81766] [7/8 Regression] ICE in maybe_add_or_update_dep_1, at sched-deps.c:924 caused by r250815

[jakub at gcc dot gnu.org]

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/81753] Building of cross-compiler for powerpc-darwin7 is broken

[acsawdey at gcc dot gnu.org]

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

[jakub at gcc dot gnu.org]

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 tree-optimization/81696] [5/6/7/8 Regression] ICF ICE on non-local goto

[marxin at gcc dot gnu.org]

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=gcc=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/81736] Unnecessary save and restore frame pointer with -fno-omit-frame-pointer

[hjl.tools at gmail dot com]

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 target/81736] Unnecessary save and restore frame pointer with -fno-omit-frame-pointer

[hjl.tools at gmail dot com]

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 tree-optimization/81744] [8 Regression] ICE: verify_ssa failed, at tree-ssa.c:1186

[amker at gcc dot gnu.org]

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=gcc=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/81313] Bad stack realignment code with -mno-accumulate-outgoing-args

[hjl.tools at gmail dot com]

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

[hjl.tools at gmail dot com]

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.