[Bug target/81490] x86: Handling of symbol ranges for __seg_fs/__seg_gs

[luto at kernel dot org]

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

Andy Lutomirski  changed:

   What|Removed |Added

 CC||luto at kernel dot org

--- Comment #8 from Andy Lutomirski  ---
(In reply to H. Peter Anvin from comment #7)
> Thinking about this some more, this is really not an aspect of __seg_* but
> rather the section the symbol is placed in.  An embedded system kernel, for
> example, could quite possibly want to access an absolute section while the
> kernel itself is position-independent; maybe it is even running XIP.
> 
> As such perhaps a better solution would be to have attributes that control
> these specific parameters.  A quick off-the-top-of-my-head proposal:
> 
> __attribute__((absolute))
> 
> ... this symbol should be accessed using absolute address references.
> 
> __attribute__((range(from,to)))
> 
> ... specifies the valid address range for this symbol.

I would like to see something along these lines but even stronger: a way to
instruct GCC to use a particular type of access and relocation.  For example, I
think I should be able to ask GCC to reference symbol "foo" using a PC-relative
relocation or using an absolute relocation at my option.

[Bug target/81490] x86: Handling of symbol ranges for __seg_fs/__seg_gs

[hpa at zytor dot com]

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

--- Comment #7 from H. Peter Anvin  ---
Thinking about this some more, this is really not an aspect of __seg_* but
rather the section the symbol is placed in.  An embedded system kernel, for
example, could quite possibly want to access an absolute section while the
kernel itself is position-independent; maybe it is even running XIP.

As such perhaps a better solution would be to have attributes that control
these specific parameters.  A quick off-the-top-of-my-head proposal:

__attribute__((absolute))

... this symbol should be accessed using absolute address references.

__attribute__((range(from,to)))

... specifies the valid address range for this symbol.

[Bug target/81490] x86: Handling of symbol ranges for __seg_fs/__seg_gs

[hpa at zytor dot com]

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

--- Comment #6 from H. Peter Anvin  ---
It is probably inappropriate to generate non-absolute address references for
these symbols for any kind of PIC or PIE output (as that would require unwanted
relocation!), so #2 is probably not really relevant at all.

[Bug target/81490] x86: Handling of symbol ranges for __seg_fs/__seg_gs

[hpa at zytor dot com]

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

--- Comment #5 from H. Peter Anvin  ---
The test case was compiled with:

gcc -fno-plt -fpie -fvisibility=hidden -mcmodel=small -O2

(note: no code changes between -fpie and -fpic)

[Bug target/81490] x86: Handling of symbol ranges for __seg_fs/__seg_gs

[hpa at zytor dot com]

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

--- Comment #4 from H. Peter Anvin  ---
Created attachment 41801
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41801=edit
Test case: assembly output

[Bug target/81490] x86: Handling of symbol ranges for __seg_fs/__seg_gs

[hpa at zytor dot com]

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

--- Comment #3 from H. Peter Anvin  ---
Created attachment 41800
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41800=edit
Test case: preprocessor output

[Bug target/81490] x86: Handling of symbol ranges for __seg_fs/__seg_gs

[hpa at zytor dot com]

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

--- Comment #2 from H. Peter Anvin  ---
Created attachment 41799
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41799=edit
Test case: object file

[Bug target/81490] x86: Handling of symbol ranges for __seg_fs/__seg_gs

[hpa at zytor dot com]

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

--- Comment #1 from H. Peter Anvin  ---
Created attachment 41798
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41798=edit
Test case: source code

[Bug target/81490] New: x86: Handling of symbol ranges for __seg_fs/__seg_gs

[hpa at zytor dot com]

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

Bug ID: 81490
   Summary: x86: Handling of symbol ranges for __seg_fs/__seg_gs
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hpa at zytor dot com
  Target Milestone: ---

Note: this was tested with gcc 6.3.1, but I believe there is no changes in
later versions.

On x86, gcc assumes that the valid range of symbols compiled with __seg_fs and
__seg_gs are the same as for symbols in the normal namespace.

This is not appropriate, as in general these symbols will be unrelated to the
symbol addresses, especially in position-independent code.

__thread does the right thing, and generates 32-bit absolute references rather
than (%rip)-relative.

From an optimization point of view, there seems to be two independent
parameters:

1. If the range is restricted to [0, 2G), [-2G, 2G) or unrestricted.

   This affects what kind of address expressions are available.

2. If the range is guaranteed to be within [-2G, 2G) of the loaded image.

   In this case (%rip)-relative addressing can be used.  This one is IMO not
   really significant.

We would like to migrate the way we do percpu variable handling in the Linux
kernel to something compiler-aware.  __seg_gs is a much closer fit for us than
__thread, for several reasons:

a. The Linux kernel has a concept of percpu pointers, i.e. addresses that are
   unresolved with respect to which CPU they reference.

b. The percpu base pointer, unlike the __thread base pointer, is volatile as
   it can change if a thread is preempted.

c. gcc still does not appear to provide for a mechanism to specify which
segment
   register is the thread base pointer.

[Bug other/65254] libiberty produces using extended field designator is an extension warnings in clang

[egallager at gcc dot gnu.org]

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

egallager at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-20
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from egallager at gcc dot gnu.org ---
Confirming that clang still prints these warnings when compiling libiberty

[Bug target/81317] builtin_vec_ld fails for powerpc with altivec

[randy.macleod at windriver dot com]

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

--- Comment #22 from Randy MacLeod  ---
Yes, the host is an x86-64-linux system running Ubuntu-16.04.1.
The cross-compiler was built using the Open Embedded (OE) build system so of
course, it's not part of Ubuntu. 

I did get a better backtrace as shown below but no full symbol table/line
numbers yet.


The OE build puts the toolchain in a sysroot directory structure so I tried
running gdb using the original executable:

$ file
/buildarea/rmacleod/src/distro/yocto/b/sd-ppc/tmp-glibc/work/x86_64-linux/gcc-cross-powerpc/7.1.0-r0/gcc-7.1.0/build.x86_64-linux.powerpc-oe-linux/gcc/cc1
/LONGPATH/build.x86_64-linux.powerpc-oe-linux/gcc/cc1: ELF 64-bit LSB
executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter
/lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32,
BuildID[sha1]=e4f4e565fcaeee1a3c291899d42d96b7fd76db1d, not stripped

$ gdb /LONGPATH/build.x86_64-linux.powerpc-oe-linux/gcc/cc1
(gdb) run -fpreprocessed second.i
...
Program received signal SIGSEGV, Segmentation fault.   
   
   [6/1951]
0x0075f743 in store_expr_with_bounds(tree_node*, rtx_def*, int, bool,
bool, tree_node*) ()
(gdb) bt full
#0  0x0075f743 in store_expr_with_bounds(tree_node*, rtx_def*, int,
bool, bool, tree_node*) ()
No symbol table info available.
#1  0x007604e0 in expand_assignment(tree_node*, tree_node*, bool) ()
No symbol table info available.
#2  0x006728fb in expand_gimple_stmt(gimple*) ()
No symbol table info available.
#3  0x006742f1 in expand_gimple_basic_block(basic_block_def*, bool) ()
No symbol table info available.
#4  0x00678ddf in (anonymous
namespace)::pass_expand::execute(function*) ()
No symbol table info available.
#5  0x0092be4b in execute_one_pass(opt_pass*) ()
No symbol table info available.
#6  0x0092c668 in execute_pass_list_1(opt_pass*) [clone .constprop.88]
()
No symbol table info available.
#7  0x0092c6c5 in execute_pass_list(function*, opt_pass*) ()
No symbol table info available.
#8  0x006a360d in cgraph_node::expand() ()
No symbol table info available.
#9  0x006a4b3d in symbol_table::compile() [clone .part.51] ()
No symbol table info available.
#10 0x006a6598 in symbol_table::finalize_compilation_unit() ()
No symbol table info available.
#11 0x009e75b0 in compile_file() ()
No symbol table info available.
#12 0x00577a4c in toplev::main(int, char**) ()
No symbol table info available.
#13 0x00579dd7 in main ()
No symbol table info available.
(gdb) info register
rax0x0  0
rbx0x7658ed80   140737326411136
rcx0x0  0
rdx0x7fffa8b0   140737488332976
rsi0x7fffa8a0   140737488332960
rdi0x0  0
rbp0x76722930   0x76722930
rsp0x7fffa880   0x7fffa880
r8 0x0  0
r9 0x0  0
r100x7658d798   140737326405528
r110x0  0
r120x0  0
r130x0  0
r140x0  0
r150x7658d480   140737326404736
rip0x75f743 0x75f743 
eflags 0x10246  [ PF ZF IF RF ]
cs 0x33 51
ss 0x2b 43
ds 0x0  0
es 0x0  0
fs 0x0  0
gs 0x0  0
(gdb) 

I'm not sure why the symbol table isn't available but I can work on that
tomorrow if needed.

[Bug bootstrap/49582] configure-target-libquadmath fail on powerpc-darwin8

[egallager at gcc dot gnu.org]

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

egallager at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-07-20
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from egallager at gcc dot gnu.org ---
I can't reproduce this failure with gcc8 on i386-apple-darwin9.8.0; could you
try again please? Also could this be combined with bug 37704 for a more generic
multilib disabling flag that handles other directories besides libquadmath?

[Bug middle-end/81478] By default, GCC emits a function call for complex multiplication, should partially inline that

[smcallis at gmail dot com]

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

--- Comment #6 from Sean McAllister  ---
FWIW, it seems the compute, check, re-compute if necessary is what clang does. 
Rather than "setp %al" and "jne" on that, they just use the "jp" instruction
directly after ucomiss:

   0x004005d5 <+133>:   subss  %xmm6,%xmm0  ; compute real part
   0x004005d9 <+137>:   addss  %xmm4,%xmm5  ; compute imaginary
part
   0x004005dd <+141>:   ucomiss %xmm0,%xmm0 ; check for NaN on
real
   0x004005e0 <+144>:   jnp0x4005e7   ; if OK, continue
   0x004005e2 <+146>:   ucomiss %xmm5,%xmm5 ; check for NaN on
imag
   0x004005e5 <+149>:   jp 0x400602   ; recompute if bad
result
   0x004005e7 <+151>:   cvtss2sd %xmm0,%xmm0
   0x004005eb <+155>:   cvtss2sd %xmm5,%xmm1
   0x004005ef <+159>:   mov$0x400944,%edi
   0x004005f4 <+164>:   mov$0x2,%al
   0x004005f6 <+166>:   callq  0x400430 
   0x004005fb <+171>:   xor%eax,%eax
   0x004005fd <+173>:   add$0x18,%rsp
   0x00400601 <+177>:   retq
   0x00400602 <+178>:   movaps %xmm7,%xmm0
   0x00400605 <+181>:   callq  0x400620 <__mulsc3>
   0x0040060a <+186>:   movaps %xmm0,%xmm5
   0x0040060d <+189>:   shufps $0xe5,%xmm5,%xmm5
   0x00400611 <+193>:   jmp0x4005e7 

[Bug target/48097] new Throw_2 failures in libjava under Xcode 4.0

[egallager at gcc dot gnu.org]

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

egallager at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |SUSPENDED
 CC||egallager at gcc dot gnu.org

--- Comment #14 from egallager at gcc dot gnu.org ---
(In reply to Iain Sandoe from comment #13)
> 
> We can leave this open, but as stated,  someone should try to find a
> non-Java reproducer.

Compromise between closing and leaving open: I'll change the status to
SUSPENDED until there's a non-Java reproducer.

[Bug web/69601] current/ redirect is off by at least a day

[egallager at gcc dot gnu.org]

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

egallager at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #7 from egallager at gcc dot gnu.org ---
(In reply to Eric Gallager from comment #6)
> Seems to be fixed for September.

Closing as fixed; I can't recall seeing this bug reoccur since then.

[Bug c++/69818] warn for C++ functional cast expression on pointer or reference

[egallager at gcc dot gnu.org]

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

egallager at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-19
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #6 from egallager at gcc dot gnu.org ---
(In reply to Chris Studholme from comment #0)
> We have -Wold-style-cast for C-style cast expressions, but there is no
> warning for C++ functional cast expressions even though they are essentially
> equal in their power and potential for problems.  Consider this contrived
> example:
> 
>   short x;
>   typedef long& R;
>   long& y = R(x);
>   typedef long* P;
>   long* z = P();
> 

Confirming that gcc still prints no warning for this code with
-Wold-style-cast.

[Bug target/81317] builtin_vec_ld fails for powerpc with altivec

[segher at gcc dot gnu.org]

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

--- Comment #21 from Segher Boessenkool  ---
Hrm, those ?? are a bit worrying, is that normal on x86_64-linux
(that is what this is, as host?)

I also don't see line numbers.

[Bug bootstrap/25470] [5/6/7/8 Regression] fixincludes/ subdirectory not cleaned by "make distclean"

[egallager at gcc dot gnu.org]

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

egallager at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #25 from egallager at gcc dot gnu.org ---
(In reply to Eric Gallager from comment #23)
> (In reply to Eric Gallager from comment #22)
> > This seems to be fixed; the only subdir that fails to distclean properly for
> > me currently is libcc1...
> 
> ...which is Bug 70173

...which has itself been closed. So I'm closing this bug as fixed.

[Bug target/63773] [meta-bug] Restoring darwin bootstrap for gcc 5.0

[egallager at gcc dot gnu.org]

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

egallager at gcc dot gnu.org changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #37 from egallager at gcc dot gnu.org ---
(In reply to Rainer Orth from comment #35)
> (In reply to Iain Sandoe from comment #31)
> > (In reply to r...@cebitec.uni-bielefeld.de from comment #30)
> > > With Xcode 6.4 as, 32-bit bootstrap is now well into running the 
> > > testsuite.
> > > 
> > > I've filed bug
> > > 
> > >   23669324 Xcode 7 as creates relocation ld cannot handle
> > 
> > Thanks!
> > 
> > The .s file in your attachment crashes TOT llvm/clang (clang -target
> > i686-apple-darwin12 .s -o t.o ) with an assertion "Value does not fit in
> > Fixup field".  Will try to investigate if I have any spare cycles today.
> 
> I've just been notified that the bug is fixed in Xcode 7.3.1.  Will try that
> as
> soon as it hits the Appstore.
> 
>   Rainer

So does this bug still need to stay open then?

[Bug target/65294] No easy way of setting default Mac OS X target - darwin_minversion not enough

[egallager at gcc dot gnu.org]

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

egallager at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-07-19
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from egallager at gcc dot gnu.org ---
Could you please attach a testcase that fails without your patch, and passes
after your patch is applied? Marking as WAITING until there is a clearer recipe
to reproduce this bug.

[Bug target/81193] PowerPC GCC __builtin_cpu_is and __builtin_cpu_supports should warn about old libraries

[meissner at gcc dot gnu.org]

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

--- Comment #15 from Michael Meissner  ---
Author: meissner
Date: Wed Jul 19 22:05:20 2017
New Revision: 250371

URL: https://gcc.gnu.org/viewcvs?rev=250371=gcc=rev
Log:
[gcc]
2017-07-19  Michael Meissner  

Back port from trunk
2017-07-12  Michael Meissner  

PR target/81193
* config/rs6000/rs6000-c.c (rs6000_cpu_cpp_builtins): If GLIBC
provides the hardware capability bits, define the macro
__BUILTIN_CPU_SUPPORTS__.
* config/rs6000/rs6000.c (cpu_expand_builtin): Generate a warning
if GLIBC does not provide the hardware capability bits.  Add a
gcc_unreachable call if the built-in cpu function is neither
__builtin_cpu_is nor __builtin_cpu_supports.
* doc/extend.texi (PowerPC built-in functions): Document that
GLIBC 2.23 or newer is needed by __builtin_cpu_is and
__builtin_cpu_supports.  Document the macros defined by GCC if the
newer GLIBC is available.

[gcc/testsuite]
2017-07-19  Michael Meissner  

Back port from trunk
2017-07-12  Michael Meissner  

PR target/81193
* gcc.target/powerpc/cpu-builtin-1.c: Change test to use #ifdef
__BUILTIN_CPU_SUPPORTS to see if the GLIBC is new enough that
__builtin_cpu_is and __builtin_cpu_supports are supported.


Modified:
branches/gcc-6-branch/gcc/config/rs6000/rs6000-c.c
branches/gcc-6-branch/gcc/config/rs6000/rs6000.c
branches/gcc-6-branch/gcc/doc/extend.texi
branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/cpu-builtin-1.c

[Bug target/62273] doc: Invoke.texi -mkernel mentions undocumented option

[egallager at gcc dot gnu.org]

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

egallager at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-19
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from egallager at gcc dot gnu.org ---
Confirming that -fapple-kext is still undocumented in FSF GCC trunk

[Bug tree-optimization/81489] invalid phi argument used in find_implicit_erroneous_behavior

[vries at gcc dot gnu.org]

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

--- Comment #3 from Tom de Vries  ---
Created attachment 41797
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41797=edit
Patch with more strict checking in gimple_phi_arg, bootstrapped and reg-tested

This is the patch with which this PR was found.

[Bug objc++/57607] g++ cannot distinguish obj-c message call from c++11 lambda

[egallager at gcc dot gnu.org]

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

egallager at gcc dot gnu.org changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #4 from egallager at gcc dot gnu.org ---
The testcase breaks again with gcc8 though, this time causing an ICE:

$ /usr/local/bin/g++ -std=c++11 -framework CoreFoundation -lobjc test57607.mm
In file included from /usr/local/include/c++/8.0.0/bits/ios_base.h:46:0,
 from /usr/local/include/c++/8.0.0/ios:42,
 from /usr/local/include/c++/8.0.0/ostream:38,
 from /usr/local/include/c++/8.0.0/iostream:39,
 from test57607.mm:2:
/usr/local/include/c++/8.0.0/system_error:191:23: internal compiler error:
Segmentation fault
 explicit operator bool() const noexcept
   ^~~~
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


Attaching gdb gives the following backtrace:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x3a138e4c
0x0010d744 in make_conv_op_name ()
(gdb) bt
#0  0x0010d744 in make_conv_op_name ()
#1  0x00169ac7 in cp_parser_unqualified_id ()
#2  0x00169e49 in cp_parser_id_expression ()
#3  0x00169fb3 in cp_parser_parse_and_diagnose_invalid_type_name ()
#4  0x0015e084 in cp_parser_member_declaration ()
#5  0x0015ea24 in cp_parser_type_specifier ()
#6  0x0016f480 in cp_parser_decl_specifier_seq ()
#7  0x00174ab5 in cp_parser_simple_declaration ()
#8  0x00175bdf in cp_parser_block_declaration ()
#9  0x0017addc in cp_parser_declaration ()
#10 0x0017b21e in cp_parser_declaration_seq_opt ()
#11 0x0017b965 in cp_parser_namespace_definition ()
#12 0x0017aeb9 in cp_parser_declaration ()
#13 0x0017b21e in cp_parser_declaration_seq_opt ()
#14 0x0017b576 in c_parse_file ()
#15 0x00280a78 in c_common_parse_file ()
#16 0x00bee0e5 in compile_file ()
#17 0x01b02420 in toplev::main ()
#18 0x01b03a34 in main ()

I'll have to rebuild my gcc with debug info to get a better backtrace. It might
be an entirely different issue that's just triggered by the same testcase,
though, so I'm leaving this bug as UNCONFIRMED for now.

[Bug tree-optimization/81489] invalid phi argument used in find_implicit_erroneous_behavior

[vries at gcc dot gnu.org]

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

--- Comment #2 from Tom de Vries  ---
Created attachment 41796
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41796=edit
Patch, bootstrapped and reg-tested

[Bug tree-optimization/81489] invalid phi argument used in find_implicit_erroneous_behavior

[vries at gcc dot gnu.org]

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

--- Comment #1 from Tom de Vries  ---
Created attachment 41795
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41795=edit
trigger and assert patch

This patch uses the bit that makes the bug easier to trigger, and adds an
assert demonstrating that we're not picking up the correct location.

Using this patch, we hit the assert:
...
FAIL: gcc.dg/tree-ssa/isolate-1.c (internal compiler error)
FAIL: gcc.dg/tree-ssa/isolate-5.c (internal compiler error)
...

[Bug tree-optimization/81489] New: invalid phi argument used in find_implicit_erroneous_behavior

[vries at gcc dot gnu.org]

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

Bug ID: 81489
   Summary: invalid phi argument used in
find_implicit_erroneous_behavior
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

In find_implicit_erroneous_behavior there's a loop:
...
  /* We've got a NULL PHI argument.  Now see if the
 PHI's result is dereferenced within BB.  */
  FOR_EACH_IMM_USE_STMT (use_stmt, iter, lhs)
{
  /* We only care about uses in BB.  Catching cases in
 in other blocks would require more complex path
 isolation code.   */
  if (gimple_bb (use_stmt) != bb)
continue;

  location_t loc = gimple_location (use_stmt)
? gimple_location (use_stmt)
: gimple_phi_arg_location (phi, i);

  if (stmt_uses_name_in_undefined_way (use_stmt, lhs, loc))
{
  duplicate = isolate_path (bb, duplicate, e,
use_stmt, lhs, false);

  /* When we remove an incoming edge, we need to
 reprocess the Ith element.  */
  next_i = i;
  cfg_altered = true;
}
}
...

There's a problem with using 'gimple_phi_arg_location (phi, i)'.

The i is the index of the zero arg in the phi before the loop. But after
isolate_path is called, the phi has one arg less, and i is no longer the index
of the zero arg in the phi. So in the next iteration 'gimple_phi_arg_location
(phi, i)' returns something random.

Mostly we use the gimple_location (use_stmt), so the bug is not easy trigger.

We can make it easier to trigger by always using the loc of the phi argument:
...
  location_t loc = gimple_phi_arg_location (phi, i);
...

[Bug tree-optimization/81463] [8 Regression] ICE in scale_loop_profile at gcc/cfgloopmanip.c:603

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||hubicka at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #2 from Jan Hubicka  ---
Fixed.

[Bug objc/53905] -Wformat-nonliteral gives false positives with __attribute__((format(NSString,...)))

[egallager at gcc dot gnu.org]

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

egallager at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-19
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from egallager at gcc dot gnu.org ---
Still happens with gcc8; confirming

[Bug regression/81331] [5/6/7 Regression] missed Eh delivery in partitioned function

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

Summary|[8 Regression] FAIL:|[5/6/7 Regression] missed
   |21_strings/basic_string/mod |Eh delivery in partitioned
   |ifiers/insert/char/1.cc |function
   |execution test  |

--- Comment #14 from Jan Hubicka  ---
Fixed on trunk, but lets not forget to backport it to release branches after
some time.  It is nasty wrong code issue that affects -fprofile-use on x86-64
ever since BB partitioning was enabled by default.

[Bug regression/81331] [8 Regression] FAIL: 21_strings/basic_string/modifiers/insert/char/1.cc execution test

[hubicka at gcc dot gnu.org]

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

--- Comment #13 from Jan Hubicka  ---
Author: hubicka
Date: Wed Jul 19 21:06:55 2017
New Revision: 250370

URL: https://gcc.gnu.org/viewcvs?rev=250370=gcc=rev
Log:
PR middle-end/81331
* except.c (execute): Fix ordering issue.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/except.c

[Bug target/80969] [8 Regression] ICE in ix86_expand_prologue, at config/i386/i386.c:14606

[daniel.santos at pobox dot com]

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

--- Comment #4 from Daniel Santos  ---
Created attachment 41794
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41794=edit
proposed fix (still needs cleanup and tests)

This still needs cleanup and tests as well as some explanations, but it appears
to fix the problem and passes regression tests.  I haven't tested on a machine
with avx512f, however.  So there is still work and testing to be done.

This re-works the way the realigned stack is calculated and also reduces wasted
stack space due to realignment in some cases.  One drawback is that I have some
code some-what duplicated in ix86_compute_frame_layout and I would like to
spend some more time with it to see if I can refactor it.

I will better document the changes when I have some more time.

[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

Bill Schmidt  changed:

   What|Removed |Added

 Target|x86_64-pc-linux-gnu |x86_64-pc-linux-gnu,
   ||powerpc64le-linux-gnu

--- Comment #7 from Bill Schmidt  ---
(In reply to Bill Schmidt from comment #5)
> Doesn't reproduce for powerpc64le.  I'll have to build a cross.

I didn't read carefully enough that I had to be in a window of revisions to
reproduce.   I see this on powerpc64le after all.

[Bug go/81393] Bootstrap failure on s390x-linux while building libgo against recent glibc

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

  Attachment #41791|0   |1
is obsolete||

--- Comment #11 from Ian Lance Taylor  ---
Created attachment 41793
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41793=edit
Possible patch

Sorry about that, updated patch.

[Bug libstdc++/81476] severe slow-down with range-v3 library compared to clang

[glisse at gcc dot gnu.org]

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

--- Comment #17 from Marc Glisse  ---
(In reply to Jonathan Wakely from comment #14)
> The advantage of doing it as in comment 13, rather than:
> [comment #11]
> is that when inserting the inputrange causes reallocations we only have to
> transfer the already inserted elements of the inputrange to the new storage,
> not the elements preceding the insertion point ("the beginning of the
> vector" and "what we already inserted at the end").

I see what you mean. Note that as soon as there is some reallocation going on
at any point, we should be able to avoid calling (in-place) rotate, which is
quite a bit more expensive than a simple range move.

[Bug middle-end/81318] [8 regression] ICE in to_reg_br_prob_base, at profile-count.h:189

[ygribov at gcc dot gnu.org]

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

Yury Gribov  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #11 from Yury Gribov  ---
(In reply to David Binderman from comment #10)
> I have this code:

Thanks (note that other attached snippets were fixed by r250310).

[Bug target/81317] builtin_vec_ld fails for powerpc with altivec

[randy.macleod at windriver dot com]

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

--- Comment #20 from Randy MacLeod  ---
I can try! ;) How's this:

$ gdb
/buildarea/rmacleod/src/distro/yocto/b/sd-ppc/tmp-glibc/work/ppc7400-oe-linux/libjpeg-turbo/1_1.5.1-r0/recipe-sysroot-native/usr/bin/powerpc-oe-linux/../../libexec/powerpc-oe-linux/gcc/powerpc-oe-linux/7.1.0/cc1

(gdb) run -fpreprocessed second.i -msecure-plt -quiet -dumpbase second.c -m32
-mhard-float -mcpu=7400 -mno-spe -maltivec -auxbase second -g -O2 -Wall
-freport-bug -feliminate-unused-debug-types
-fdebug-prefix-map=/buildarea/rmacleod/src/distro/yocto/b/sd-ppc/tmp-glibc/work/ppc7400-oe-linux/libjpeg-turbo/1_1.5.1-r0=/usr/src/debug/libjpeg-turbo/1_1.5.1-r0
-fdebug-prefix-map=/buildarea/rmacleod/src/distro/yocto/b/sd-ppc/tmp-glibc/work/ppc7400-oe-linux/libjpeg-turbo/1_1.5.1-r0/recipe-sysroot-native=
-fdebug-prefix-map=/buildarea/rmacleod/src/distro/yocto/b/sd-ppc/tmp-glibc/work/ppc7400-oe-linux/libjpeg-turbo/1_1.5.1-r0/recipe-sysroot=
-fPIC -o - -frandom-seed=0 -fdump-noaddr

Program received signal SIGSEGV, Segmentation fault.
0x0075f743 in store_expr_with_bounds(tree_node*, rtx_def*, int, bool,
bool, tree_node*) ()
(gdb) bt
#0  0x0075f743 in store_expr_with_bounds(tree_node*, rtx_def*, int,
bool, bool, tree_node*) ()
#1  0x007604e0 in expand_assignment(tree_node*, tree_node*, bool) ()
#2  0x006728fb in ?? ()
#3  0x006742f1 in ?? ()
#4  0x00678ddf in ?? ()
#5  0x0092be4b in execute_one_pass(opt_pass*) ()
#6  0x0092c668 in ?? ()
#7  0x0092c6c5 in execute_pass_list(function*, opt_pass*) ()
#8  0x006a360d in cgraph_node::expand() ()
#9  0x006a4b3d in ?? ()
#10 0x006a6598 in symbol_table::finalize_compilation_unit() ()
#11 0x009e75b0 in ?? ()
#12 0x00577a4c in toplev::main(int, char**) ()
#13 0x00579dd7 in main ()
(gdb) 
(gdb) info regs
Undefined info command: "regs".  Try "help info".
(gdb) info registers
rax0x0  0
rbx0x7658ed80   140737326411136
rcx0x0  0
rdx0x7fffa870   140737488332912
rsi0x7fffa860   140737488332896
rdi0x0  0
rbp0x76722930   0x76722930
rsp0x7fffa840   0x7fffa840
r8 0x0  0
r9 0x0  0
r100x7658d798   140737326405528
r110x0  0
r120x0  0
r130x0  0
r140x0  0
r150x7658d480   140737326404736
rip0x75f743 0x75f743 
eflags 0x10246  [ PF ZF IF RF ]
cs 0x33 51
ss 0x2b 43
ds 0x0  0
es 0x0  0
fs 0x0  0
gs 0x0  0
(gdb)

[Bug target/81193] PowerPC GCC __builtin_cpu_is and __builtin_cpu_supports should warn about old libraries

[meissner at gcc dot gnu.org]

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

--- Comment #14 from Michael Meissner  ---
Author: meissner
Date: Wed Jul 19 20:31:53 2017
New Revision: 250368

URL: https://gcc.gnu.org/viewcvs?rev=250368=gcc=rev
Log:
[gcc]
2017-07-19  Michael Meissner  

Back port from trunk
2017-07-12  Michael Meissner  

PR target/81193
* config/rs6000/rs6000-c.c (rs6000_cpu_cpp_builtins): If GLIBC
provides the hardware capability bits, define the macro
__BUILTIN_CPU_SUPPORTS__.
* config/rs6000/rs6000.c (cpu_expand_builtin): Generate a warning
if GLIBC does not provide the hardware capability bits.  Add a
gcc_unreachable call if the built-in cpu function is neither
__builtin_cpu_is nor __builtin_cpu_supports.
* doc/extend.texi (PowerPC built-in functions): Document that
GLIBC 2.23 or newer is needed by __builtin_cpu_is and
__builtin_cpu_supports.  Document the macros defined by GCC if the
newer GLIBC is available.

[gcc/testsuite]
2017-07-19  Michael Meissner  

Back port from trunk
2017-07-12  Michael Meissner  

PR target/81193
* gcc.target/powerpc/cpu-builtin-1.c: Change test to use #ifdef
__BUILTIN_CPU_SUPPORTS to see if the GLIBC is new enough that
__builtin_cpu_is and __builtin_cpu_supports are supported.


Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/rs6000/rs6000-c.c
branches/gcc-7-branch/gcc/config/rs6000/rs6000.c
branches/gcc-7-branch/gcc/doc/extend.texi
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/cpu-builtin-1.c

[Bug go/81393] Bootstrap failure on s390x-linux while building libgo against recent glibc

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
https://kojipkgs.fedoraproject.org//work/tasks/6506/20616506/build.log
That fails to build:
../../../../libgo/go/syscall/syscall_linux_s390.go:28:33: error: reference to
undefined name 'regs'
   uint32(uintptr(unsafe.Pointer(regs))),
 ^
make[8]: Leaving directory
'/builddir/build/BUILD/gcc-7.1.1-20170718/obj-s390x-redhat-linux/s390x-redhat-linux/32/libgo'
make[8]: *** [Makefile:3331: syscall.lo] Error 1
make[7]: *** [Makefile:2746: all-recursive] Error 1

Guess the each first
uint32(uintptr(unsafe.Pointer(regs)))
line should be actually
uint32(uintptr(unsafe.Pointer(regsout)))

[Bug c++/81147] [avr] C++ for -mmcu=atmega2560 doesn't do NRVO or RVO when class inherits from empty base

[felipe at expertisesolutions dot com.br]

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

--- Comment #6 from Felipe Magno de Almeida  ---
NRVO: Named Return Value Optimization
RVO: Return Value Optiomization

It is the eliminiation of copying when returning objects by value (or passed
by-value as parameters for rvalues).

The assembly shows copying from return values and/or parameters for avr gcc
which do not happen for x86, but only when the type inherits from other
classes, even if the base class is empty. This restriction doesn't happen with
x86-64 backend.

Regards,

[Bug libstdc++/81476] severe slow-down with range-v3 library compared to clang

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #16 from Jonathan Wakely  ---
Fixed on trunk.

[Bug middle-end/81318] [8 regression] ICE in to_reg_br_prob_base, at profile-count.h:189

[dcb314 at hotmail dot com]

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

--- Comment #10 from David Binderman  ---
I am not so sure this one is fixed.

I have this code:

__attribute__((__cold__)) a();
b() { a(); }
c() {
  b();
  if (d())
e();
}

derived from Linux kernel and it does this with revision 250361:

during GIMPLE pass: profile_estimate
bug368.c: In function ‘c’:
bug368.c:7:1: internal compiler error: in to_reg_br_prob_base, at
profile-count.h:189
 }
 ^
0xb58ed1 profile_probability::to_reg_br_prob_base() const
../../trunk/gcc/profile-count.h:189
0xb58ed1 estimate_bb_frequencies(bool)
../../trunk/gcc/predict.c:3568
0xb5cce4 tree_estimate_probability(bool)
../../trunk/gcc/predict.c:2825
0xb5d193 execute
../../trunk/gcc/predict.c:3710
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug driver/51063] gcc does not pass the -Fpathname option unmodified to /usr/bin/ld linker (all Darwin systems)

[egallager at gcc dot gnu.org]

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

egallager at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #3 from egallager at gcc dot gnu.org ---
(In reply to jos...@codesourcery.com from comment #2)
> This was supposed to have been fixed by:
> 
> 2011-03-30  Christian Schueler  
> 
> PR driver/48208
> * config/c.opt (F): Added 'Driver' to -F option.
> 
> 2011-02-12  Iain Sandoe  
> 
> * gcc.c (driver_handle_option): Concatenate the argument to -F with
> the switch.
> 
> But it appears that the 2011-03-30 patch isn't on 4.6 branch.

4.6 branch is no longer open so I'm closing this as FIXED

[Bug bootstrap/25537] EXTRA_MULTILIB_PARTS undocumented

[egallager at gcc dot gnu.org]

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

egallager at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #3 from egallager at gcc dot gnu.org ---
(In reply to Eric Gallager from comment #2)
> Looks like EXTRA_MULTILIB_PARTS is no longer used... (gcc/ChangeLog-2011
> mentions its removal)

...therefore I'm closing this as FIXED, since removing the variable also
removed the need to document it.

[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 #6 from Bill Schmidt  ---
Hm, the symptom looks very much like another issue I've been looking at on
trunk.  There may be an issue with the statement->candidate mapping hash table
that's responsible for both.  It appears to be a somewhat rare issue involving
chains of phis where one of the "more recent" phis is receiving the same value
from at least two different incoming edges, but I don't yet have a complete
answer.

[Bug c/81484] incorrect -Wint-in-bool-context warning

[arnd at linaro dot org]

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

--- Comment #5 from Arnd Bergmann  ---
(In reply to Marek Polacek from comment #4)
> (In reply to Arnd Bergmann from comment #3)
> > It seems I got a little confused when I only looked at the initial patch
> > that was proposed, which was supposed to cover specifically the comparison
> > followed by ?: as in
> > https://gcc.gnu.org/ml/gcc-patches/2016-09/msg00115.html. I see now that the
> > patch that made it into the release also covers the more general case and
> > that seems intentional, it just causes false-positive warnings.
> 
> I agree it's just a style warning here (to warn about if (c ? 0 : 2) I mean,
> as that's correct code), but the warning allows you to simplify the code, so
> that seems to be a good thing.

Right, in the particular case I ran into, the only thing that prevents
me from rewriting

 setsign(dest, ((control_w & CW_RC) != RC_DOWN) ? SIGN_POS : SIGN_NEG);

into

 setsign(dest, (control_w & CW_RC) == RC_DOWN);

is the local policy of always passing either SIGN_POS or SIGN_NEG
into setsign(), rather than a boolean. Similar code might rely
on those calling conventions, but this file is the only such instance
I found in Linux, so that is not a reason to change the compiler.

> > The part that still seems odd here is that the warning does not take into
> > account the macro: The caller just passes an expression as the integer
> > argument into the setsign() macro, while the macro tests it for being
> > nonzero.
> > 
> > In the opposite case, I found a piece of kernel code that does not produce a
> > warning unless we preprocess it first (as ccache does for instance):
> > 
> > #define EINVAL 22
> > #define v4l2_subdev_call(sd, f) ((sd)->f ? (sd)->f(sd) : -EINVAL)
> > struct v4l2_subdev {
> > int (*g_sliced_fmt)(struct v4l2_subdev *sd);
> > };
> > int f(struct v4l2_subdev *sd)
> > {
> > if (v4l2_subdev_call(sd, g_sliced_fmt))
> > return -EINVAL;
> > 
> > return 0;
> > }
> > 
> > Here the macro contains the ?: operator while the caller contains the
> > 'if()', and something in gcc seems to decide not to warn about this, but
> > that logic does not identify the first example as an false-positive.
> 
> The warning checks whether the ?: expression comes from a macro.  If it does
> (as in Comment 3), it doesn't warn.  But in the original testcase the ?:
> itself is not coming from a macro so it warns.

Ok, thanks for the explanation and for your time.

[Bug c/37041] -Wc++-compat refinements

[egallager at gcc dot gnu.org]

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

egallager at gcc dot gnu.org changed:

   What|Removed |Added

 CC||gdr at gcc dot gnu.org

--- Comment #8 from egallager at gcc dot gnu.org ---
*** Bug 21759 has been marked as a duplicate of this bug. ***

[Bug c/21759] Implement warning for codes at the intersection of C and C++

[egallager at gcc dot gnu.org]

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

egallager at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #12 from egallager at gcc dot gnu.org ---
(In reply to Manuel López-Ibáñez from comment #11)
> Isn't this a duplicate of PR37041? That PR is more complete than this one.

Closing as a duplicate of PR37041 then.

*** This bug has been marked as a duplicate of bug 37041 ***

[Bug bootstrap/37704] RFE: Need specific version of --disable-multilib

[egallager at gcc dot gnu.org]

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

egallager at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-07-19
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from egallager at gcc dot gnu.org ---
This bug has an assignee but its status is still marked as UNCONFIRMED so I'm
marking it as ASSIGNED to reflect the fact that it has an assignee.

[Bug preprocessor/48839] #error should terminate compilation - similar to missing #include

[egallager at gcc dot gnu.org]

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

egallager at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-19
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #5 from egallager at gcc dot gnu.org ---
Confirming as per previous comments, which acknowledged the issue, but never
actually marked the bug as confirmed.

[Bug target/81317] builtin_vec_ld fails for powerpc with altivec

[segher at gcc dot gnu.org]

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

--- Comment #19 from Segher Boessenkool  ---
(In reply to Randy MacLeod from comment #18)
> 2. The "smaller reproducer with manual work-around " DOES STILL result in an
> ICE as does the libjpeg-turbo build as you'd expect.

I still cannot reproduce that ICE though.  Will, can you?  Randy, do
you have a backtrace?

[Bug other/36994] gcc/makefile contains one very long line (over 2k)

[egallager at gcc dot gnu.org]

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

egallager at gcc dot gnu.org changed:

   What|Removed |Added

 Target|any |
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-19
 CC||egallager at gcc dot gnu.org
   Host|any |
 Ever confirmed|0   |1
  Build|any |

--- Comment #2 from egallager at gcc dot gnu.org ---
(In reply to Eric Gallager from comment #1)
> (In reply to Jay from comment #0)
> > Waiting for Autoconf >=2.60 (currently using 2.59) will make this
> > easier, so maybe just wait. 
> 
> gcc currently requires Autoconf 2.64; does this still happen when using that
> version?

I just rechecked with gcc8 and apparently the long line still occurs even with
Autoconf 2.64, so confirming.

[Bug rtl-optimization/81423] [6/7/8 Regression] Wrong code at -O2

[segher at gcc dot gnu.org]

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

--- Comment #8 from Segher Boessenkool  ---
Author: segher
Date: Wed Jul 19 19:31:26 2017
New Revision: 250365

URL: https://gcc.gnu.org/viewcvs?rev=250365=gcc=rev
Log:
combine: Fix for PR81423

We here have an AND of a SUBREG of an LSHIFTRT.  If that SUBREG is
paradoxical, the extraction we form is the length of the size of the
inner mode, which includes some bits that should not be in the result.
Just give up in that case.


PR rtl-optimization/81423
* combine.c (make_compound_operation_int): Don't try to optimize
the AND of a SUBREG of an LSHIFTRT if that SUBREG is paradoxical.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/combine.c

[Bug libstdc++/81476] severe slow-down with range-v3 library compared to clang

[redi at gcc dot gnu.org]

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

--- Comment #15 from Jonathan Wakely  ---
Author: redi
Date: Wed Jul 19 19:32:15 2017
New Revision: 250366

URL: https://gcc.gnu.org/viewcvs?rev=250366=gcc=rev
Log:
PR libstdc++/81476 Optimise vector insertion from input iterators

PR libstdc++/81476
* include/bits/vector.tcc (vector::_M_range_insert<_InputIterator>):
Only insert elements one-by-one when inserting at the end.
* testsuite/performance/23_containers/insert/81476.cc: New.

Added:
trunk/libstdc++-v3/testsuite/performance/23_containers/insert/81476.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/vector.tcc

[Bug rtl-optimization/81423] [6/7/8 Regression] Wrong code at -O2

[segher at gcc dot gnu.org]

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

--- Comment #7 from Segher Boessenkool  ---
Author: segher
Date: Wed Jul 19 19:28:41 2017
New Revision: 250363

URL: https://gcc.gnu.org/viewcvs?rev=250363=gcc=rev
Log:
simplify-rtx: The truncation of an IOR can have all bits set (PR81423)

... if it is an IOR with a constant with all bits set in the mode
that is truncated to, for example.  Handle that case.


PR rtl-optimization/81423
* simplify-rtx.c (simplify_truncation): Handle truncating an IOR
with a constant that is -1 in the truncated to mode.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/simplify-rtx.c

[Bug middle-end/81478] By default, GCC emits a function call for complex multiplication, should partially inline that

[smcallis at gmail dot com]

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

--- Comment #5 from Sean McAllister  ---
(In reply to Richard Biener from comment #3)
> Confirmed.  It shouldn't be very difficult to do,
> gcc/tree-complex.c:expand_complex_multiplication would need to emit if
> (isnan(rr) || isnan(ri)) .
> 
> Unless we want to optimize the corner case futher by skipping the
> multiplication
> in the libcall in which case we need a new entry in libgcc.
> 
> Note that the same optimization applies to division.

I think as rarely as the average user is going to have to deal with NaN/Inf in
their complex numbers, doing the multiplication, checking, and then re-doing it
if needed with full semantics is totally defensible.  Then no need for glibc
changes.  If all your numbers are NaN/Inf, then performance will be terrible,
but you probably have other problems at that juncture anyways.

[Bug go/81324] libgo does not build with glibc 2.18

[segher at gcc dot gnu.org]

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

--- Comment #4 from Segher Boessenkool  ---
That works fine.  Thanks Ian!

[Bug tree-optimization/81488] New: gcc goes off the limits allocating memory in gimple-ssa-strength-reduction.c

[babokin at gmail dot com]

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

Bug ID: 81488
   Summary: gcc goes off the limits allocating memory in
gimple-ssa-strength-reduction.c
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
  Target Milestone: ---

Created attachment 41792
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41792=edit
reproducer

gcc trunk, rev250217, x86_64.

The attached test case was obtained by reducing the bigger test case with
another SSA problem, which is manifested as the following:
 IMM ERROR : (use_p : tree - 0x7f06c0e56d68:0x7f06c0e56d88)_95049
for SSA_NAME: _95049 in statement:
slsr_55910 = PHI <_95049(199), _95049(200)>
PHI argument
_95049
for PHI node
slsr_55910 = PHI <_95049(199), _95049(200)>
during GIMPLE pass: slsr

Anyway, during the test case reduction (which keep the program at all reduction
steps correct and UB-free) compilation started consuming enormous amount of
memory - basically all available on the machine (128Gb) and crashing after
that. Compilation doesn't take long, it's typically about 2 minutes before it
crashes.

Here's example of the stack while gcc actively allocating memory:


#0  0x7f7aa06ab70b in __memset_sse2 () from /lib64/libc.so.6
#1  0x00a65e4f in ggc_internal_alloc(unsigned long, void (*)(void*),
unsigned long, unsigned long) () at ../../gcc/gcc/ggc-page.c:1392
#2  0x00f4acd9 in ggc_internal_alloc (s=) at
../../gcc/gcc/ggc.h:130
#3  allocate_phi_node (len=) at
../../gcc/gcc/tree-phinodes.c:117
#4  make_phi_node (len=, var=) at
../../gcc/gcc/tree-phinodes.c:174
#5  create_phi_node(tree_node*, basic_block_def*) () at
../../gcc/gcc/tree-phinodes.c:342
#6  0x0159219b in create_phi_basis(slsr_cand_d*, gimple*, tree_node*,
unsigned int, bool) () at ../../gcc/gcc/gimple-ssa-strength-reduction.c:2405
#7  0x015926ce in create_phi_basis(slsr_cand_d*, gimple*, tree_node*,
unsigned int, bool) () at ../../gcc/gcc/gimple-ssa-strength-reduction.c:2386
#8  0x015926ce in create_phi_basis(slsr_cand_d*, gimple*, tree_node*,
unsigned int, bool) () at ../../gcc/gcc/gimple-ssa-strength-reduction.c:2386
#9  0x015926ce in create_phi_basis(slsr_cand_d*, gimple*, tree_node*,
unsigned int, bool) () at ../../gcc/gcc/gimple-ssa-strength-reduction.c:2386
#10 0x015926ce in create_phi_basis(slsr_cand_d*, gimple*, tree_node*,
unsigned int, bool) () at ../../gcc/gcc/gimple-ssa-strength-reduction.c:2386
#11 0x015926ce in create_phi_basis(slsr_cand_d*, gimple*, tree_node*,
unsigned int, bool) () at ../../gcc/gcc/gimple-ssa-strength-reduction.c:2386
#12 0x015926ce in create_phi_basis(slsr_cand_d*, gimple*, tree_node*,
unsigned int, bool) () at ../../gcc/gcc/gimple-ssa-strength-reduction.c:2386
#13 0x015926ce in create_phi_basis(slsr_cand_d*, gimple*, tree_node*,
unsigned int, bool) () at ../../gcc/gcc/gimple-ssa-strength-reduction.c:2386
#14 0x015926ce in create_phi_basis(slsr_cand_d*, gimple*, tree_node*,
unsigned int, bool) () at ../../gcc/gcc/gimple-ssa-strength-reduction.c:2386
#15 0x015926ce in create_phi_basis(slsr_cand_d*, gimple*, tree_node*,
unsigned int, bool) () at ../../gcc/gcc/gimple-ssa-strength-reduction.c:2386
#16 0x015926ce in create_phi_basis(slsr_cand_d*, gimple*, tree_node*,
unsigned int, bool) () at ../../gcc/gcc/gimple-ssa-strength-reduction.c:2386
#17 0x015926ce in create_phi_basis(slsr_cand_d*, gimple*, tree_node*,
unsigned int, bool) () at ../../gcc/gcc/gimple-ssa-strength-reduction.c:2386
#18 0x015926ce in create_phi_basis(slsr_cand_d*, gimple*, tree_node*,
unsigned int, bool) () at ../../gcc/gcc/gimple-ssa-strength-reduction.c:2386
#19 0x015926ce in create_phi_basis(slsr_cand_d*, gimple*, tree_node*,
unsigned int, bool) () at ../../gcc/gcc/gimple-ssa-strength-reduction.c:2386
#20 0x015926ce in create_phi_basis(slsr_cand_d*, gimple*, tree_node*,
unsigned int, bool) () at ../../gcc/gcc/gimple-ssa-strength-reduction.c:2386
#21 0x015926ce in create_phi_basis(slsr_cand_d*, gimple*, tree_node*,
unsigned int, bool) () at ../../gcc/gcc/gimple-ssa-strength-reduction.c:2386
#22 0x015926ce in create_phi_basis(slsr_cand_d*, gimple*, tree_node*,
unsigned int, bool) () at ../../gcc/gcc/gimple-ssa-strength-reduction.c:2386
#23 0x015926ce in create_phi_basis(slsr_cand_d*, gimple*, tree_node*,
unsigned int, bool) () at ../../gcc/gcc/gimple-ssa-strength-reduction.c:2386
#24 0x015926ce in create_phi_basis(slsr_cand_d*, gimple*, tree_node*,
unsigned int, bool) () at ../../gcc/gcc/gimple-ssa-strength-reduction.c:2386
#25 0x015926ce in create_phi_basis(slsr_cand_d*, gimple*, tree_node*,
unsigned int, bool) () at ../../gcc/gcc/gimple-ssa-strength-reduction.c:2386
#26 

[Bug objc/50909] Process "#pragma options align=reset" correctly on Mac OS X

[egallager at gcc dot gnu.org]

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

egallager at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||egallager at gcc dot gnu.org

--- Comment #10 from egallager at gcc dot gnu.org ---
Confirming that the original testcase still fails with an unpatched gcc; I
think it's worth fixing (by implementing the clang behavior) so I'm marking it
as "NEW" instead of "INVALID" or "WONTFIX"

[Bug lto/81487] New: [mingw32] ld.exe: error: asprintf failed

[gjl at gcc dot gnu.org]

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

Bug ID: 81487
   Summary: [mingw32] ld.exe: error: asprintf failed
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gjl at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Compiling a trivial program fails:

int main()
{
return 0;
}

$ avr-gcc simple.c -mmcu=atmega8 -v
Using built-in specs.
Reading specs from
e:/winavr/8.0_2017-07-18/bin/../lib/gcc/avr/8.0.0/device-specs/specs-atmega8
COLLECT_GCC=e:/WinAVR/8.0_2017-07-18/bin/avr-gcc
COLLECT_LTO_WRAPPER=e:/winavr/8.0_2017-07-18/bin/../libexec/gcc/avr/8.0.0/lto-wrapper.exe
Target: avr
Configured with: ../../gcc.gnu.org/trunk/configure --target=avr --disable-nls
--prefix=/local/gnu/install/gcc-8-avr-mingw32 --host=i686-w64-mingw32
--build=x86_64-linux-gnu --enable-languages=c,c++,lto --with-gnu-as
--with-gnu-ld --disable-shared --with-dwarf2 --enable-checking=release
Thread model: single
gcc version 8.0.0 20170718 (experimental) [trunk revision 244001] (GCC) 
...
e:/winavr/8.0_2017-07-18/bin/../lib/gcc/avr/8.0.0/../../../../avr/bin/ld.exe:
error: asprintf failed
collect2.exe: error: ld returned 1 exit status


The caller is lto-plugin.c::claim_file_handler()

  if (file->offset != 0)
{
  char *objname;
  /* We pass the offset of the actual file, not the archive header.
 Can't use PRIx64, because that's C99, so we have to print the
 64-bit hex int as two 32-bit ones. */
  int lo, hi, t;
  lo = file->offset & 0x;
  hi = ((int64_t)file->offset >> 32) & 0x;
  t = hi ? asprintf (, "%s@0x%x%08x", file->name, lo, hi)
 : asprintf (, "%s@0x%x", file->name, lo);
  check (t >= 0, LDPL_FATAL, "asprintf failed");
  lto_file.name = objname;
}

Presumably, the problem is caused by a broken asprintf host implementation
which returns -1 for a string of length 46.  So it would be nice to use a
working implementation like xasprintf from libiberty.

Apart from that, the ordering of lo and hi in 

  asprintf (, "%s@0x%x%08x", file->name, lo, hi)

looks wrong.  The arguments should be "file->name, hi, lo" to get a correct
64-bit value if hi != 0.

[Bug middle-end/323] optimized code gives strange floating point results

[egallager at gcc dot gnu.org]

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

egallager at gcc dot gnu.org changed:

   What|Removed |Added

 CC||j.d.pryce at ntlworld dot com

--- Comment #203 from egallager at gcc dot gnu.org ---
*** Bug 34261 has been marked as a duplicate of this bug. ***

[Bug target/34261] Directed rounding doesn't work on MacOS X

[egallager at gcc dot gnu.org]

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

egallager at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #7 from egallager at gcc dot gnu.org ---
Closing as a duplicate of bug 323 per comments 3 and 4

*** This bug has been marked as a duplicate of bug 323 ***

[Bug rtl-optimization/68988] reload_pseudo_compare_func violates qsort requirements

[ygribov at gcc dot gnu.org]

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

--- Comment #4 from Yury Gribov  ---
(In reply to Alexander Monakov from comment #3)
> Not a commit, merely a proposed patch at this point. Sorry I missed this bug
> when preparing the patch.

Yes, I should avoid working too late in the evening.  A pity BZ does not allow
to edit coments.

[Bug regression/81331] [8 Regression] FAIL: 21_strings/basic_string/modifiers/insert/char/1.cc execution test

[hubicka at gcc dot gnu.org]

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

--- Comment #12 from Jan Hubicka  ---
Author: hubicka
Date: Wed Jul 19 18:08:07 2017
New Revision: 250358

URL: https://gcc.gnu.org/viewcvs?rev=250358=gcc=rev
Log:

PR middle-end/81331
* except.c (maybe_add_nop_after_section_switch): New function.
(execute): Use it.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/except.c

[Bug go/81393] Bootstrap failure on s390x-linux while building libgo against recent glibc

[ian at airs dot com]

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

--- Comment #9 from Ian Lance Taylor  ---
Created attachment 41791
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41791=edit
Possible patch

I agree that the simplest approach is to not try to pick up the definitions
from the header files for the older branches, but to just write them directly. 
I don't have a way to test a patch; can you see if this one works?

[Bug rtl-optimization/68988] reload_pseudo_compare_func violates qsort requirements

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #3 from Alexander Monakov  ---
Not a commit, merely a proposed patch at this point. Sorry I missed this bug
when preparing the patch.

[Bug middle-end/81483] spurious -Wformat-overflow warning for limited types

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-19
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
The VRP pass computes the correct range for the sprintf argument but the range
made available outside the pass via the get_range_info() function for the
promoted argument is that of unsigned int (a similar problem is described in
bug 78969).  It's a bug/limitation in the range propagation machinery in GCC. 
I'm not sure there's an easy way to work around it in the sprintf pass.  If
not, hopefully the new VRP implementation will solve these problems.

Until then, a workaround is to unsigned int as the loop counter and cast it to
unsigned char in the sprintf call:

unsigned zone;
char buffer[10];

for (zone = 0; zone != num_zones; zone++)
__builtin_sprintf (buffer, "zone%02X", (unsigned char)zone);

[Bug c++/81486] New: Class template argument deduction fails with (), succeeds with {}

[barry.revzin at gmail dot com]

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

Bug ID: 81486
   Summary: Class template argument deduction fails with (),
succeeds with {}
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

Consider this example, simplified from
https://stackoverflow.com/q/45195890/2069064:

template 
struct C { 
C(T );
};

template <>
struct C { };

C() -> C;

int main() {
auto a = C{}; // ok
auto b = C(); // error
}

The two forms are equivalent in this context - a and b should both deduce to
C. Yet, gcc accepts a and errors on b with: cannot deduce template
arguments for 'C' from ()

[Bug c/81484] incorrect -Wint-in-bool-context warning

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
(In reply to Arnd Bergmann from comment #3)
> It seems I got a little confused when I only looked at the initial patch
> that was proposed, which was supposed to cover specifically the comparison
> followed by ?: as in
> https://gcc.gnu.org/ml/gcc-patches/2016-09/msg00115.html. I see now that the
> patch that made it into the release also covers the more general case and
> that seems intentional, it just causes false-positive warnings.

I agree it's just a style warning here (to warn about if (c ? 0 : 2) I mean, as
that's correct code), but the warning allows you to simplify the code, so that
seems to be a good thing.

> The part that still seems odd here is that the warning does not take into
> account the macro: The caller just passes an expression as the integer
> argument into the setsign() macro, while the macro tests it for being
> nonzero.
> 
> In the opposite case, I found a piece of kernel code that does not produce a
> warning unless we preprocess it first (as ccache does for instance):
> 
> #define EINVAL 22
> #define v4l2_subdev_call(sd, f) ((sd)->f ? (sd)->f(sd) : -EINVAL)
> struct v4l2_subdev {
> int (*g_sliced_fmt)(struct v4l2_subdev *sd);
> };
> int f(struct v4l2_subdev *sd)
> {
> if (v4l2_subdev_call(sd, g_sliced_fmt))
> return -EINVAL;
> 
> return 0;
> }
> 
> Here the macro contains the ?: operator while the caller contains the
> 'if()', and something in gcc seems to decide not to warn about this, but
> that logic does not identify the first example as an false-positive.

The warning checks whether the ?: expression comes from a macro.  If it does
(as in Comment 3), it doesn't warn.  But in the original testcase the ?: itself
is not coming from a macro so it warns.

I think I still don't see any bug here.

[Bug target/81317] builtin_vec_ld fails for powerpc with altivec

[randy.macleod at windriver dot com]

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

--- Comment #18 from Randy MacLeod  ---
With both patches applied:
1. The "minimal testcase produced by the delta utility" no longer ICEs the
toolchain. 
2. The "smaller reproducer with manual work-around " DOES STILL result in an
ICE as does the libjpeg-turbo build as you'd expect.


Here's the patch I'm using just to keep myself honest:

$ diffstat meta/recipes-devtools/gcc/gcc-7.1/backport-gcc-altivec-no-lhs.patch 
 rs6000-c.c |2 ++
 rs6000.c   |1 +
 2 files changed, 3 insertions(+)

$ cat meta/recipes-devtools/gcc/gcc-7.1/backport-gcc-altivec-no-lhs.patch 
--- a/gcc/config/rs6000/rs6000-c.c
+++ b/gcc/config/rs6000/rs6000-c.c
@@ -6216,6 +6216,8 @@
   /* Strip qualifiers like "const" from the pointer arg.  */
   tree arg1_type = TREE_TYPE (arg1);
   tree inner_type = TREE_TYPE (arg1_type);
+  if (!POINTER_TYPE_P (arg1_type))
+ goto bad;
   if (TYPE_QUALS (TREE_TYPE (arg1_type)) != 0)
{
  arg1_type = build_pointer_type (build_qualified_type (inner_type,
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -17001,6 +17001,7 @@
 = (enum rs6000_builtins) DECL_FUNCTION_CODE (fndecl);
   tree arg0, arg1, lhs;

+  if (!gimple_call_lhs (stmt)) return false;
   switch (fn_code)
 {
 /* Flavors of vec_add.  We deliberately don't expand

[Bug rtl-optimization/81434] AArch64 instruction fusing and pipeline scheduling problem

[jim.wilson at linaro dot org]

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

--- Comment #5 from jim.wilson at linaro dot org ---
On Wed, Jul 19, 2017 at 4:25 AM, wilco at gcc dot gnu.org
 wrote:
> To more accurately schedule fusion pairs wouldn't we need to specify the
> scheduling behaviour of the group as well? From the dumps below it schedules
> the adrp/add in the same cycle if we're lucky, but it is modelled as using 2
> ALUs rather than a new single fused instruction.

The fusion pair takes two issue slots and uses one alu, but is modeled
as taking two issues slots and using two alus.  I haven't tried to
address this problem.  I'm just trying to get the issue slot handling
correct for now, so that they can issue in the same cycle.

> Also is your change fixing the issue that the scheduler cannot schedule 2
> instructions with a zero latency dependency between them in the same cycle?
> That's a very similar bug.

The scheduler can schedule 2 insns w/ zero latency dependency in the
same cycle.  However, it does not do so when a SCHED_GROUP is
involved.  This is the bug that my patch fixes.

Jim

[Bug bootstrap/81470] [8 Regression] Bootstrap comparison failures in gcc/ada

[rai...@emrich-ebersheim.de]

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

Rainer Emrich  changed:

   What|Removed |Added

 CC||charlet at gcc dot gnu.org

--- Comment #1 from Rainer Emrich  ---
The issue is caused by revision 247301:
Revision 247301
Modified Thu Apr 27 09:48:45 2017 UTC by charlet

Revision 247299 caused an additional in libada:
cannot generate code for file s-excmac.ads (package spec)
make[6]: *** [../gcc-interface/Makefile:299: s-excmac.o] Error 1

This issue may be still latent. I cannot test because the bootstrap comparison
failure.

[Bug c/81484] incorrect -Wint-in-bool-context warning

[arnd at linaro dot org]

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

--- Comment #3 from Arnd Bergmann  ---
It seems I got a little confused when I only looked at the initial patch that
was proposed, which was supposed to cover specifically the comparison followed
by ?: as in https://gcc.gnu.org/ml/gcc-patches/2016-09/msg00115.html. I see now
that the patch that made it into the release also covers the more general case
and that seems intentional, it just causes false-positive warnings.

The part that still seems odd here is that the warning does not take into
account the macro: The caller just passes an expression as the integer argument
into the setsign() macro, while the macro tests it for being nonzero.

In the opposite case, I found a piece of kernel code that does not produce a
warning unless we preprocess it first (as ccache does for instance):

#define EINVAL 22
#define v4l2_subdev_call(sd, f) ((sd)->f ? (sd)->f(sd) : -EINVAL)
struct v4l2_subdev {
int (*g_sliced_fmt)(struct v4l2_subdev *sd);
};
int f(struct v4l2_subdev *sd)
{
if (v4l2_subdev_call(sd, g_sliced_fmt))
return -EINVAL;

return 0;
}

Here the macro contains the ?: operator while the caller contains the 'if()',
and something in gcc seems to decide not to warn about this, but that logic
does not identify the first example as an false-positive.

[Bug middle-end/81478] By default, GCC emits a function call for complex multiplication, should partially inline that

[smcallis at gmail dot com]

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

--- Comment #4 from Sean McAllister  ---
Looking at the assembly for the __mulsc3 function:

 <+0>:movaps %xmm0,%xmm10
 <+4>:movaps %xmm2,%xmm11
 <+8>:movaps %xmm0,%xmm5
<+11>:mulss  %xmm3,%xmm10
<+16>:movaps %xmm1,%xmm6
<+19>:mulss  %xmm1,%xmm11
<+24>:mulss  %xmm2,%xmm5
<+28>:mulss  %xmm3,%xmm6
<+32>:movaps %xmm10,%xmm4
<+36>:addss  %xmm11,%xmm4
<+41>:movaps %xmm5,%xmm9
<+45>:subss  %xmm6,%xmm9
<+50>:ucomiss %xmm4,%xmm4
<+53>:setp   %al
<+56>:ucomiss %xmm9,%xmm9
<+60>:setp   %dl
<+63>:and%dl,%al
<+65>:jne0x77530a27 <__mulsc3+87>


The isnan(a) && isnan(b) isn't short-circuited.  It'd be possible to write
something like this:


<+50>:ucomiss %xmm4,%xmm4
<+53>:setp%al
<+XX>:je  good_cxmultiply
<+XX>:ucomiss %xmm9,%xmm9
<+XX>:setp%dl
<+XX>:and %dl,%al
<+XX>:jne 0x77530a27 <__mulsc3+XX>
<+XX>good_cxmultiply:


This makes the overhead in the general case three pretty cheap instructions
instead of 6 (also very cheap), someone smarter than me will have to decide if
that's a net win or not. Also emitting the code instead of calling __mulsc3
every time will also benefit the register allocator and give it options for
shuffling things around. (I do a lot of complex arithmetic so I'm interested in
this being fast =D).  It'd be cool if the vectorizer still had a shot at it,
but I don't immediately see an easy way to achieve that.

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

[glaubitz at physik dot fu-berlin.de]

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

Bug ID: 81485
   Summary: [SH] ICE: in sh_find_set_of_reg, at
config/sh/sh-protos.h:232
   Product: gcc
   Version: 7.1.0
   URL: https://people.debian.org/~glaubitz/totem-pl-parser_3.
10.8-1_sh4.build
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glaubitz at physik dot fu-berlin.de
CC: kkojima at gcc dot gnu.org, olegendo at gcc dot gnu.org
  Target Milestone: ---
Target: sh*-*-*

Created attachment 41790
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41790=edit
Preprocessed source cclGjyyS.out (gzipped)

Trying to build totem-pl-parser on Debian unstable sh4 bails out with an
internal compiler error [1]:

libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../lib -I../plparse
-DGNOMELOCALEDIR=\"/usr/share/locale\"
-DLIBEXECDIR=\"/usr/lib/sh4-linux-gnu/libtotem-plparser18\" -Wdate-time
-D_FORTIFY_SOURCE=2 -pthread -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
-pthread -I/usr/include/libsoup-2.4 -I/usr/include/libxml2
-I/usr/include/gmime-2.6 -I/usr/include/glib-2.0
-I/usr/lib/sh4-linux-gnu/glib-2.0/include -fno-strict-aliasing -Wall -Wextra
-Wundef -Wnested-externs -Wwrite-strings -Wpointer-arith -Wmissing-declarations
-Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls
-Wno-unused-parameter -Wno-missing-field-initializers
-Wdeclaration-after-statement -Wformat=2 -Wold-style-definition -Wcast-align
-Wformat-nonliteral -Wformat-security -Wsign-compare -Wstrict-aliasing -Wshadow
-Winline -Wpacked -Wmissing-format-attribute -Wmissing-noreturn -Winit-self
-Wmissing-include-dirs -Wunused-but-set-variable -Warray-bounds
-Wimplicit-function-declaration -Wreturn-type -Wswitch-enum -Wswitch-default
-Wno-error=unused-parameter -Wno-error=missing-field-initializers
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -I../lib -D_GNU_SOURCE -g -O2
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
-Werror=format-security -c totem-pl-parser-pla.c  -fPIC -DPIC -o
.libs/libtotem_plparser_la-totem-pl-parser-pla.o
(...)
totem-pl-parser-pla.c: In function 'totem_pl_parser_save_pla':
totem-pl-parser-pla.c:67:4: warning: cast increases required alignment of
target type [-Wcast-align]
  *((gint32 *)buffer) = GINT32_TO_BE (num_entries_total);
^
In file included from /usr/include/glib-2.0/glib/galloca.h:32:0,
 from /usr/include/glib-2.0/glib.h:30,
 from totem-pl-parser-pla.c:26:
totem-pl-parser-pla.c: In function 'totem_pl_parser_add_pla':
totem-pl-parser-pla.c:189:34: warning: cast increases required alignment of
target type [-Wcast-align]
  max_entries = GINT32_FROM_BE (*((gint32 *)contents));
  ^
/usr/include/glib-2.0/glib/gtypes.h:184:77: note: in definition of macro
'GUINT32_SWAP_LE_BE'
 #define GUINT32_SWAP_LE_BE(val) ((guint32) __builtin_bswap32 ((gint32)
(val)))

^~~
/usr/include/glib-2.0/glib/gtypes.h:351:30: note: in expansion of macro
'GINT32_TO_BE'
 #define GINT32_FROM_BE(val) (GINT32_TO_BE (val))
  ^~~~
totem-pl-parser-pla.c:189:16: note: in expansion of macro 'GINT32_FROM_BE'
  max_entries = GINT32_FROM_BE (*((gint32 *)contents));
^~
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../lib -I../plparse
-DGNOMELOCALEDIR=\"/usr/share/locale\"
-DLIBEXECDIR=\"/usr/lib/sh4-linux-gnu/libtotem-plparser18\" -Wdate-time
-D_FORTIFY_SOURCE=2 -pthread -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
-pthread -I/usr/include/libsoup-2.4 -I/usr/include/libxml2
-I/usr/include/gmime-2.6 -I/usr/include/glib-2.0
-I/usr/lib/sh4-linux-gnu/glib-2.0/include -fno-strict-aliasing -Wall -Wextra
-Wundef -Wnested-externs -Wwrite-strings -Wpointer-arith -Wmissing-declarations
-Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls
-Wno-unused-parameter -Wno-missing-field-initializers
-Wdeclaration-after-statement -Wformat=2 -Wold-style-definition -Wcast-align
-Wformat-nonliteral -Wformat-security -Wsign-compare -Wstrict-aliasing -Wshadow
-Winline -Wpacked -Wmissing-format-attribute -Wmissing-noreturn -Winit-self
-Wmissing-include-dirs -Wunused-but-set-variable -Warray-bounds
-Wimplicit-function-declaration -Wreturn-type -Wswitch-enum -Wswitch-default
-Wno-error=unused-parameter -Wno-error=missing-field-initializers
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -I../lib -D_GNU_SOURCE -g -O2
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
-Werror=format-security -c totem-pl-parser-misc.c -o
libtotem_plparser_la-totem-pl-parser-misc.o >/dev/null 2>&1
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../lib -I../plparse
-DGNOMELOCALEDIR=\"/usr/share/locale\"

[Bug libquadmath/65757] gfortran gives incorrect result for anint with real*16 argument

[jakub at gcc dot gnu.org]

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

--- Comment #20 from Jakub Jelinek  ---
Author: jakub
Date: Wed Jul 19 13:12:58 2017
New Revision: 250343

URL: https://gcc.gnu.org/viewcvs?rev=250343=gcc=rev
Log:
PR libquadmath/65757
* quadmath-imp.h (math_opt_barrier, math_force_eval,
math_narrow_eval, math_check_force_underflow,
math_check_force_underflow_nonneg): Define.
* math/ceilq.c: Backport changes from upstream glibc
between 2012-11-01 and 2017-07-13.
* math/remquoq.c: Likewise.
* math/expq.c: Likewise.
* math/llroundq.c: Likewise.
* math/logq.c: Likewise.
* math/atanq.c: Likewise.
* math/nearbyintq.c: Likewise.
* math/scalblnq.c: Likewise.
* math/finiteq.c: Likewise.
* math/atanhq.c: Likewise.
* math/expm1q.c: Likewise.
* math/sinhq.c: Likewise.
* math/log10q.c: Likewise.
* math/rintq.c: Likewise.
* math/roundq.c: Likewise.
* math/fmaq.c: Likewise.
* math/erfq.c: Likewise.
* math/log2q.c: Likewise.
* math/lroundq.c: Likewise.
* math/j1q.c: Likewise.
* math/scalbnq.c: Likewise.
* math/truncq.c: Likewise.
* math/frexpq.c: Likewise.
* math/sincosq.c: Likewise.
* math/tanhq.c: Likewise.
* math/asinq.c: Likewise.
* math/coshq.c: Likewise.
* math/j0q.c: Likewise.
* math/asinhq.c: Likewise.
* math/floorq.c: Likewise.
* math/sinq_kernel.c: Likewise.
* math/powq.c: Likewise.
* math/hypotq.c: Likewise.
* math/sincos_table.c: Likewise.
* math/rem_pio2q.c: Likewise.
* math/nextafterq.c: Likewise.
* math/log1pq.c: Likewise.
* math/sincosq_kernel.c: Likewise.
* math/tanq.c: Likewise.
* math/acosq.c: Likewise.
* math/lrintq.c: Likewise.
* math/llrintq.c: Likewise.

Modified:
trunk/libquadmath/ChangeLog
trunk/libquadmath/math/acosq.c
trunk/libquadmath/math/asinhq.c
trunk/libquadmath/math/asinq.c
trunk/libquadmath/math/atanhq.c
trunk/libquadmath/math/atanq.c
trunk/libquadmath/math/ceilq.c
trunk/libquadmath/math/coshq.c
trunk/libquadmath/math/erfq.c
trunk/libquadmath/math/expm1q.c
trunk/libquadmath/math/expq.c
trunk/libquadmath/math/finiteq.c
trunk/libquadmath/math/floorq.c
trunk/libquadmath/math/fmaq.c
trunk/libquadmath/math/frexpq.c
trunk/libquadmath/math/hypotq.c
trunk/libquadmath/math/j0q.c
trunk/libquadmath/math/j1q.c
trunk/libquadmath/math/llrintq.c
trunk/libquadmath/math/llroundq.c
trunk/libquadmath/math/log10q.c
trunk/libquadmath/math/log1pq.c
trunk/libquadmath/math/log2q.c
trunk/libquadmath/math/logq.c
trunk/libquadmath/math/lrintq.c
trunk/libquadmath/math/lroundq.c
trunk/libquadmath/math/nearbyintq.c
trunk/libquadmath/math/nextafterq.c
trunk/libquadmath/math/powq.c
trunk/libquadmath/math/rem_pio2q.c
trunk/libquadmath/math/remquoq.c
trunk/libquadmath/math/rintq.c
trunk/libquadmath/math/roundq.c
trunk/libquadmath/math/scalblnq.c
trunk/libquadmath/math/scalbnq.c
trunk/libquadmath/math/sincos_table.c
trunk/libquadmath/math/sincosq.c
trunk/libquadmath/math/sincosq_kernel.c
trunk/libquadmath/math/sinhq.c
trunk/libquadmath/math/sinq_kernel.c
trunk/libquadmath/math/tanhq.c
trunk/libquadmath/math/tanq.c
trunk/libquadmath/math/truncq.c
trunk/libquadmath/quadmath-imp.h

[Bug tree-optimization/81346] Missed constant propagation into comparison

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek  ---
Author: jakub
Date: Wed Jul 19 13:10:05 2017
New Revision: 250342

URL: https://gcc.gnu.org/viewcvs?rev=250342=gcc=rev
Log:
PR tree-optimization/81346
* match.pd: Optimize (X - 1U) <= INT_MAX-1U into (int) X > 0.

* gcc.dg/tree-ssa/pr81346-5.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr81346-5.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/match.pd
trunk/gcc/testsuite/ChangeLog

[Bug c/81484] incorrect -Wint-in-bool-context warning

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
...which could be simply written as:

void
foo (int c)
{
  if (c == 0)
__builtin_abort ();
}

[Bug c/81484] incorrect -Wint-in-bool-context warning

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
a) and b) are the same.  I don't think c) is necessarily wrong code, but the
warning doesn't warn (and it shouldn't), so let's put that aside.  So this
boils down to

void
foo (int c)
{
  if (c ? 0 : 2)
__builtin_abort ();
}

w.c: In function ‘foo’:
w.c:4:13: warning: ?: using integer constants in boolean context
[-Wint-in-bool-context]
   if (c ? 0 : 2)
   ~~^~~

[Bug go/81393] Bootstrap failure on s390x-linux while building libgo against recent glibc

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
And r249663.  Perhaps it would be better for the release branches to just
define the ptrace_area type in the *.go files like syscall_linux_alpha.go used
to.

[Bug go/81393] Bootstrap failure on s390x-linux while building libgo against recent glibc

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Oh, and r249712.

[Bug tree-optimization/81346] Missed constant propagation into comparison

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  ---
Author: jakub
Date: Wed Jul 19 12:31:59 2017
New Revision: 250338

URL: https://gcc.gnu.org/viewcvs?rev=250338=gcc=rev
Log:
PR tree-optimization/81346
* fold-const.h (fold_div_compare, range_check_type): Declare.
* fold-const.c (range_check_type): New function.
(build_range_check): Use range_check_type.
(fold_div_compare): No longer static, rewritten into
a match.pd helper function.
(fold_comparison): Don't call fold_div_compare here.
* match.pd (X / C1 op C2): New optimization using fold_div_compare
as helper function.

* gcc.dg/tree-ssa/pr81346-1.c: New test.
* gcc.dg/tree-ssa/pr81346-2.c: New test.
* gcc.dg/tree-ssa/pr81346-3.c: New test.
* gcc.dg/tree-ssa/pr81346-4.c: New test.
* gcc.target/i386/umod-3.c: Hide comparison against 1 from the
compiler to avoid X / C1 op C2 optimization to trigger.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr81346-1.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr81346-2.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr81346-3.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr81346-4.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/fold-const.h
trunk/gcc/match.pd
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/umod-3.c

[Bug libstdc++/81476] severe slow-down with range-v3 library compared to clang

[redi at gcc dot gnu.org]

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

--- Comment #14 from Jonathan Wakely  ---
Oops, the rotate needs to be done unconditionally.

The advantage of doing it as in comment 13, rather than:

(In reply to Marc Glisse from comment #11)
> switch to the "new allocation" strategy, create a new vector, copy the
> beginning of the vector, copy what we already inserted at the end, append
> the rest of the inputrange, copy the rest of the original vector, and
> finally adopt this new vector.

is that when inserting the inputrange causes reallocations we only have to
transfer the already inserted elements of the inputrange to the new storage,
not the elements preceding the insertion point ("the beginning of the vector"
and "what we already inserted at the end").

Another solution would be to grow the vector exponentially during range
insertion from input iterators, as we do for a push_back. Either manually in
_M_range_insert<_InputIterator> or in _M_realloc_insert.

I think at the moment I prefer comment 12 (but using
_GLIBCXX_MAKE_MOVE_ITERATOR to avoid copies when possible).

[Bug c/81484] New: incorrect -Wint-in-bool-context warning

[arnd at linaro dot org]

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

Bug ID: 81484
   Summary: incorrect -Wint-in-bool-context warning
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arnd at linaro dot org
  Target Milestone: ---

I came across a warning in the linux kernel with gcc-7.1.1:

arch/x86/math-emu/reg_add_sub.c: In function 'FPU_add':
arch/x86/math-emu/reg_add_sub.c:80:48: error: ?: using integer constants in
boolean context [-Werror=int-in-bool-context]

After analyzing it further, I reduced it to this test program, please compile
with "gcc-7.1.1 -Wall -O2":

#define signbyte(a) (((unsigned char *)(a))[9])
#define getsign(a)  (signbyte(a) & 0x80)
#define setsign(a,b)do { if (b) signbyte(a) |= 0x80; else signbyte(a) &=
0x7f; } while (0)
#define CW_RC   0x0C00
#define RC_DOWN 0x0400
#define SIGN_POS0u
#define SIGN_NEG0x80u
int FPU_add(void *dest, int control_w)
{
/* a) correct code, bogus warning */
setsign(dest, ((control_w & CW_RC) != RC_DOWN) ? SIGN_POS : SIGN_NEG);

/* b) false-positive warning */
setsign(dest, (control_w & CW_RC) != RC_DOWN ? SIGN_POS : SIGN_NEG);

/* c) wrong code, no warning */
setsign(dest, (control_w & CW_RC) != (RC_DOWN ? SIGN_POS : SIGN_NEG));

return 0;
}

The warning we get is about case a), which as far as I can tell is written
correctly and unambiguous, and should not trigger a warning.

It appears that the compiler mistakes this for code that is written in a
somewhat ambiguous way like the (still-correct) variant b) when the author
actually meant to write it like c). The result is that we also get a
false-positive warning for b) that makes a lot of sense, while the incorrect
case c) is a false-negative here, as we don't get a warning.

[Bug target/80846] auto-vectorized AVX2 horizontal sum should narrow to 128b right away, to be more efficient for Ryzen and Intel

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
Created attachment 41789
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41789=edit
gcc8-pr80846.patch

Untested i386 backend V2TImode and V4TImode vec_extract/vec_init and move
improvements.

[Bug libstdc++/81476] severe slow-down with range-v3 library compared to clang

[redi at gcc dot gnu.org]

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

--- Comment #13 from Jonathan Wakely  ---
(In reply to Marc Glisse from comment #11)
> Or one could (not legal) directly start a new allocation, copy the beginning
> of the vector, append the range, then append the end of the vector. Or a
> combination of all that: first try appending the range to the vector. If
> that works without reallocating, rotate. If a reallocation is necessary,
> switch to the "new allocation" strategy, create a new vector, copy the
> beginning of the vector, copy what we already inserted at the end, append
> the rest of the inputrange, copy the rest of the original vector, and
> finally adopt this new vector.

Or something like this (which would require lots of  for
std::rotate):

--- a/libstdc++-v3/include/bits/vector.tcc
+++ b/libstdc++-v3/include/bits/vector.tcc
@@ -617,10 +617,28 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
   _M_range_insert(iterator __pos, _InputIterator __first,
  _InputIterator __last, std::input_iterator_tag)
   {
-   for (; __first != __last; ++__first)
+   const size_type __orig_size = size();
+   pointer& __finish = this->_M_impl._M_finish;
+   while (__finish != this->_M_impl._M_end_of_storage
+   && __first != __last)
  {
-   __pos = insert(__pos, *__first);
-   ++__pos;
+   _Alloc_traits::construct(_M_get_Tp_allocator(),
+std::__addressof(*__finish),
+*__first);
+   ++__finish;
+   ++__first;
+ }
+
+   if (__first != __last)
+ {
+   const size_type __elems_before = __pos - begin();
+   vector __tmp(__first, __last, _M_get_Tp_allocator());
+   reserve(size() + __tmp.size());
+   iterator __prev_end = end();
+   insert(__prev_end,
+  _GLIBCXX_MAKE_MOVE_ITERATOR(__tmp.begin()),
+  _GLIBCXX_MAKE_MOVE_ITERATOR(__tmp.end()));
+   std::rotate(begin() + __elems_before, __prev_end, end());
  }
   }

[Bug rtl-optimization/81434] AArch64 instruction fusing and pipeline scheduling problem

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

 CC||wilco at gcc dot gnu.org

--- Comment #4 from Wilco  ---
To more accurately schedule fusion pairs wouldn't we need to specify the
scheduling behaviour of the group as well? From the dumps below it schedules
the adrp/add in the same cycle if we're lucky, but it is modelled as using 2
ALUs rather than a new single fused instruction.

Also is your change fixing the issue that the scheduler cannot schedule 2
instructions with a zero latency dependency between them in the same cycle?
That's a very similar bug.

[Bug target/81481] [7/8 Regression] Spills %xmm to stack in glibc strspn SSE 4.2 variant

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
I'm too dumb to understand the LRA dump ;)

[Bug middle-end/81483] New: spurious -Wformat-overflow warning for limited types

[arnd at linaro dot org]

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

Bug ID: 81483
   Summary: spurious -Wformat-overflow warning for limited types
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arnd at linaro dot org
  Target Milestone: ---

After looking in more detail at -Wformat-overflow warnings in the linux
kernels, I managed to reduce one warning to this test case:

#include 
void alienware_zone_init(unsigned char num_zones)
{
unsigned char zone;
char buffer[10];

for (zone = 0; zone < num_zones; zone++)
sprintf(buffer, "zone%02X", zone);
}

I get this warning:

$ x86_64-linux-gcc-7.1.1 -Wall -S /tmp/test4.c -O2 
/tmp/test4.c: In function 'alienware_zone_init':
/tmp/test4.c:9:24: warning: '%02X' directive writing between 2 and 8 bytes into
a region of size 6 [-Wformat-overflow=]
   sprintf(buffer, "zone%02X", zone);
^~~~
/tmp/test4.c:9:19: note: directive argument in the range [0, 2147483647]
   sprintf(buffer, "zone%02X", zone);
   ^~
/tmp/test4.c:9:3: note: 'sprintf' output between 7 and 13 bytes into a
destination of size 10
   sprintf(buffer, "zone%02X", zone);
   ^

which is surprising because the range "[0, 2147483647]" is larger
than an 'unsigned char' can hold. In similar test cases that use
an 'unsigned char' without the loop, we do not get the warning.

[Bug lto/81430] nvptx acceleration compilation broken because of running pass_partition_blocks

[vries at gcc dot gnu.org]

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

--- Comment #5 from Tom de Vries  ---
Created attachment 41788
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41788=edit
for lto1, call finish_options after cl_optimization_restore in
invoke_set_current_function_hook

This is an attempt to actually fix the issue, by reusing finish_options in
lto1.

[Bug middle-end/81478] By default, GCC emits a function call for complex multiplication, should partially inline that

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-19
Summary|By default, GCC emits a |By default, GCC emits a
   |function call for complex   |function call for complex
   |multiplication  |multiplication, should
   ||partially inline that
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
Confirmed.  It shouldn't be very difficult to do,
gcc/tree-complex.c:expand_complex_multiplication would need to emit if
(isnan(rr) || isnan(ri)) .

Unless we want to optimize the corner case futher by skipping the
multiplication
in the libcall in which case we need a new entry in libgcc.

Note that the same optimization applies to division.

[Bug libstdc++/81482] New: by-value lambda capture in remove_if

[fabian-gcc at kloetzl dot info]

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

Bug ID: 81482
   Summary: by-value lambda capture in remove_if
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fabian-gcc at kloetzl dot info
  Target Milestone: ---

Hi all,

There is a little quirks with `remove_if` and lambdas that mutably capture by
value. As a contrived example let's print all the odd numbers from a list and
also count how many elements were removed already.


#include 
#include 
#include 

int main(int argc, char *argv[])
{
auto numbers = std::vector{0,1,2,3,4,5,6,7,8,9};

auto count = 0;
auto odd = [=] (int n) mutable {
if (n & 1) {
printf("%i %i\n", n, count);
count++;
return true;
}
return false;
};

std::remove_if(std::begin(numbers), std::end(numbers), odd);
return 0;
}


Note that the use of `printf` is to avoid a libc++ bug [1].

The expected output is as follows.

1 0
3 1
5 2
7 3
9 4


However, with GCC 7.1.1 and libstdc++ 3.3.6 (current arch) the output is
different.


1 0
3 0
5 1
7 2
9 3


Clang with libc++ produces the desired output. As far as I can tell, both
behaviours are correct, according to the standard. But I guess the second is
unexpected.

A possible fix would be to pass the lambda by reference to `find_if`, instead
of by-value which makes an implicit copy [2]. That is how libc++ does it [3].

Some other standard algorithms might also be affected by this, didn't check. ☺

Best,
Fabian


[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808086
[2]:
https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/bits/stl_algo.h#L863
[3]:
https://github.com/llvm-mirror/libcxx/blob/master/include/algorithm#L2218-L2219

[Bug go/81451] missing futex check - libgo/runtime/thread-linux.c:12:0 futex.h:13:12: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘long’

[mfe at live dot de]

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

--- Comment #6 from martin  ---
Thanks!

[Bug go/81393] Bootstrap failure on s390x-linux while building libgo against recent glibc

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Note that the patch doesn't apply cleanly (capital vs. lowercase letter of some
field), and depends on r249472, r249662 and r250324.

[Bug target/81481] [7/8 Regression] Spills %xmm to stack in glibc strspn SSE 4.2 variant

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu.org
  Known to work||4.8.5, 6.4.0
   Target Milestone|--- |7.2
  Known to fail||7.1.0, 7.1.1, 8.0

--- Comment #1 from Richard Biener  ---
Unfortunately neither -mincoming-stack-boundary nor -mstackrealign are valid in
target attributes (to annotate affected functions only).

[Bug target/81481] New: [7/8 Regression] Spills %xmm to stack in glibc strspn SSE 4.2 variant

[rguenth at gcc dot gnu.org]

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

Bug ID: 81481
   Summary: [7/8 Regression] Spills %xmm to stack in glibc strspn
SSE 4.2 variant
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: missed-optimization, ra
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---
Target: i?86-*-*

Created attachment 41787
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41787=edit
reduced testcase

We're seeing crashes in 32bit programs violating the ABI by not properly
aligning the outgoing stack when calling strspn which eventually dispatches to
__strspn_sse42.  This is because GCC 7 and trunk compile this to

.L28:
.cfi_restore_state
movdqu  ___m128i_shift_right@GOTOFF(%edi,%ebx), %xmm3
movl%esi, %ebp
andl$-16, %ebp
movl$16, %eax
movaps  %xmm3, (%esp)
movdqa  0(%ebp), %xmm0
pshufb  (%esp), %xmm0
pcmpistri   $58, %xmm0, %xmm0

spilling %xmm3 for no good reason.  GCC 4.8 at least did better here and
avoided
spilling (and the crashes).  There are other string routines similarly
affected.

movdqu  ___m128i_shift_right@GOTOFF(%ebx,%eax), %xmm0
andl$-16, %ebp
movdqa  0(%ebp), %xmm1
pshufb  %xmm0, %xmm1
pcmpistri   $58, %xmm1, %xmm1

Reduced testcase attached, compile with -O2 -m32 -fPIC.

[Bug libstdc++/81480] Assertion `ec' failed

[akhilesh.k at samsung dot com]

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

Akhilesh Kumar  changed:

   What|Removed |Added

 Target||arm
   Host||x86_64
  Build||arm toolchain

--- Comment #2 from Akhilesh Kumar  ---
Common i run 
run libstdc++ test suite with dejagnu
runtest --tool libstdc++ --srcdir=/path/to/gcc/libstdc++-v3/testsuite

[Bug libstdc++/81476] severe slow-down with range-v3 library compared to clang

[redi at gcc dot gnu.org]

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

--- Comment #12 from Jonathan Wakely  ---
(In reply to Marc Glisse from comment #10)
> Inserting an InputRange (not even Forward) at the beginning of a vector is
> really a misuse of vector. It is true that we can do better than what
> libstdc++ currently does, though we shouldn't encourage the practice.

Completely agreed.

> Trivial idea would be first to copy the InputRange to some array (either
> something dynamic like a vector, or by block to a fixed size buffer), then
> insert that. Variants include tricks like inserting the InputRange at the
> end of the vector, then calling std::rotate to move it to the right position.

Right, with this patch:

--- a/libstdc++-v3/include/bits/vector.tcc
+++ b/libstdc++-v3/include/bits/vector.tcc
@@ -617,11 +617,8 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
   _M_range_insert(iterator __pos, _InputIterator __first,
  _InputIterator __last, std::input_iterator_tag)
   {
-   for (; __first != __last; ++__first)
- {
-   __pos = insert(__pos, *__first);
-   ++__pos;
- }
+   vector __tmp(__first, __last, get_allocator());
+   insert(__pos, __tmp.begin(), __tmp.end());
   }

   template

I get these times for -O2:

Insert directly: 11593
100
Insert from range: 14070
100

Rather than:

Insert directly: 11976
100
Insert from range: 11383109
100

Or using clang and libc++ with -O2:

Insert directly: 13327
100
Insert from range: 674060
100

[Bug libstdc++/81480] Assertion `ec' failed

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-07-19
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
We need a lot more information for this to be a usable bug report.

https://gcc.gnu.org/bugs/

[Bug libstdc++/81476] severe slow-down with range-v3 library compared to clang

[glisse at gcc dot gnu.org]

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

--- Comment #11 from Marc Glisse  ---
Or one could (not legal) directly start a new allocation, copy the beginning of
the vector, append the range, then append the end of the vector. Or a
combination of all that: first try appending the range to the vector. If that
works without reallocating, rotate. If a reallocation is necessary, switch to
the "new allocation" strategy, create a new vector, copy the beginning of the
vector, copy what we already inserted at the end, append the rest of the
inputrange, copy the rest of the original vector, and finally adopt this new
vector.