[Bug debug/82738] [meta-bug] issues with the -Og optimization level

2019-03-12 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82738
Bug 82738 depends on bug 68836, which changed state.

Bug 68836 Summary: GCC can't properly emit debug info for function arguments in 
a back-trace when using -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68836

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |DUPLICATE

[Bug debug/68836] GCC can't properly emit debug info for function arguments in a back-trace when using -Og

2019-03-12 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68836

Eric Gallager  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #9 from Eric Gallager  ---
(In reply to Allan Jensen from comment #8)
> Duplicate of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78685

ok, closing as such

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

[Bug debug/78685] -Og generates too many ""s

2019-03-12 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78685

Eric Gallager  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #16 from Eric Gallager  ---
*** Bug 68836 has been marked as a duplicate of this bug. ***

[Bug translation/79618] prevent missing space in multiline string literals

2019-03-12 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79618

--- Comment #4 from Eric Gallager  ---
(In reply to David Malcolm from comment #2)
> Good idea.
> 
> We can't do it at run-time from inside the diagnostics subsystem, as the
> line-breaking information is lost when the literal is compiled.
> 
> So from an implementation POV, I believe this would have to happen inside
> xgettext when it scans the sources to create .pot files, so that it can
> enforce one of the variants described in comment #1 (presumably as a new
> --check option to xgettext).
> 
> In theory, we could do it with a compiler plugin that detects such strings,
> but given that xgettext is scanning the strings already, presumably this
> would be better implemented as an xgettext test.
> 
> Alternatively, I guess we could implement some kind of preprocessing hack to
> run when generating the .pot files, but presumably other projects would find
> this useful, so it seems to make more sense as an xgettext feature.

none of these solutions sound very trivial; I don't think this bug meets the
"with trivial fixes" criterion for the meta-bug it's now blocking.

[Bug translation/79595] Inconsistent grammar in diagnostic "partial specialization %q+D does not specialize"

2019-03-12 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79595

Eric Gallager  changed:

   What|Removed |Added

   Keywords||easyhack
   Severity|minor   |trivial

[Bug c++/89695] New: inappropriate copying of trivially copyable prvalue arguments

2019-03-12 Thread matthijsvanduin at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89695

Bug ID: 89695
   Summary: inappropriate copying of trivially copyable prvalue
arguments
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: matthijsvanduin at gmail dot com
  Target Milestone: ---

When a function that has a non-reference parameter of a trivially copyable
class-type is invoked with a prvalue expression as argument, e.g.:

#include 

struct Foo {
int data[32];
Foo() { printf( "%p (constructor)\n", this ); }
};

Foo make_foo() {  return Foo{};  }

void f( Foo x ) {  printf( "%p (parameter)\n",  );  }

int main() {
f( Foo{} );
f( make_foo() );
return 0;
}

g++ initializes a temporary from this expression and then copy-constructs the
parameter from it:

0x7fffce1caa80 (constructor)
0x7fffce1cab00 (parameter)
0x7fffce1caa80 (constructor)
0x7fffce1cab00 (parameter)

This appears to happen whenever C++17 permits it and at any optimization level,
even though Foo is large and expensive to copy. For example on armhf at -O2,
g++ produces this particularly silly-looking output:

mov r1, r5
mov r0, r7
bl  printf(PLT)
mov r2, r8
mov r1, r5
mov r0, r4
bl  memcpy(PLT)
mov r1, r4
mov r0, r6
bl  printf(PLT)
mov r1, r5
mov r0, r7
bl  printf(PLT)
mov r2, r8
mov r1, r5
mov r0, r4
bl  memcpy(PLT)
mov r1, r4
mov r0, r6
bl  printf(PLT)

If a user-provided destructor, copy-constructor, or move-constructor is added
to the class, no copying is done even at -O0 (as expected due to C++17
requirements):

mov r3, r7
mov r0, r3
bl  _ZN3FooC1Ev(PLT)
mov r3, r7
mov r0, r3
bl  _Z1f3Foo(PLT)
add r3, r7, #128
mov r0, r3
bl  _Z8make_foov(PLT)
add r3, r7, #128
mov r0, r3
bl  _Z1f3Foo(PLT)

[Bug target/89694] Redundant code with optimization

2019-03-12 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89694

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |target

--- Comment #1 from Andrew Pinski  ---
Testcase?

Note:
movl%edx, %edx 
This might not be redudent as that is a zero extend.

[Bug c/89694] New: Redundant code with optimization

2019-03-12 Thread lavr at ncbi dot nlm.nih.gov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89694

Bug ID: 89694
   Summary: Redundant code with optimization
   Product: gcc
   Version: 7.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lavr at ncbi dot nlm.nih.gov
  Target Milestone: ---

When I use the -O6 optimization, I noticed that GCC 7.4.0 interjects some
redundant code, like marked below:

mulP:
.seh_endprologue
movq%rcx, %r10
movq%rdx, %r11
movl%ecx, %eax
shrq$32, %r10
shrq$32, %r11
movl%edx, %edx // REDUNDANT
movq%r10, %r8
xorl%ecx, %ecx
imulq   %r11, %r8
imulq   %rdx, %r10
imulq   %rax, %r11
addq%r11, %r10
setc%cl
leaq59(%r10), %r11
jc  .L6
testq   %rcx, %rcx
jne .L6
cmpq$-60, %r10
cmovbe  %r10, %r11
.L6:
movq%r8, %r10
salq$32, %r8
xorl%ecx, %ecx
shrq$32, %r10
imulq   $59, %r10, %r9
addq%r8, %r9
setc%cl
leaq59(%r9), %r8
jc  .L11
testq   %rcx, %rcx
jne .L11
cmpq$-60, %r9
cmovbe  %r9, %r8
.L11:
xorl%r9d, %r9d
addq%r11, %r8
setc%r9b
movq%r8, %rcx
imulq   %rax, %rdx
testq   %r9, %r9
jne .L29
jne .L29   // REDUNDANT
cmpq$-60, %r8
ja  .L33
.L16:
movq%rcx, %r9
salq$32, %rcx
shrq$32, %r9
imulq   $59, %r9, %r8
addq%rcx, %r8
setc%cl
movq%r8, %rax
movzbl  %cl, %ecx
testq   %rcx, %rcx
jne .L30
jne .L30   // REDUNDANT
cmpq$-60, %r8
jbe .L17

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-cygwin/7.4.0/lto-wrapper.exe
Target: x86_64-pc-cygwin
Configured with:
/cygdrive/i/szsz/tmpp/gcc/gcc-7.4.0-1.x86_64/src/gcc-7.4.0/configure
--srcdir=/cygdrive/i/szsz/tmpp/gcc/gcc-7.4.0-1.x86_64/src/gcc-7.4.0
--prefix=/usr --exec-prefix=/usr --localstatedir=/var --sysconfdir=/etc
--docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C
--build=x86_64-pc-cygwin --host=x86_64-pc-cygwin --target=x86_64-pc-cygwin
--without-libiconv-prefix --without-libintl-prefix --libexecdir=/usr/lib
--enable-shared --enable-shared-libgcc --enable-static
--enable-version-specific-runtime-libs --enable-bootstrap --enable-__cxa_atexit
--with-dwarf2 --with-tune=generic
--enable-languages=ada,c,c++,fortran,lto,objc,obj-c++ --enable-graphite
--enable-threads=posix --enable-libatomic --enable-libcilkrts --enable-libgomp
--enable-libitm --enable-libquadmath --enable-libquadmath-support
--disable-libssp --enable-libada --disable-symvers --with-gnu-ld --with-gnu-as
--with-cloog-include=/usr/include/cloog-isl --without-libiconv-prefix
--without-libintl-prefix --with-system-zlib --enable-linker-build-id
--with-default-libstdcxx-abi=gcc4-compatible --enable-libstdcxx-filesystem-ts
Thread model: posix
gcc version 7.4.0 (GCC)

[Bug ipa/89693] New: [9 Regression] ICE: verify_cgraph_node failed (error: edge points to wrong declaration)

2019-03-12 Thread asolokha at gmx dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89693

Bug ID: 89693
   Summary: [9 Regression] ICE: verify_cgraph_node failed (error:
edge points to wrong declaration)
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-checking, ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

g++-9.0.0-alpha20190310 snapshot (r269561) ICEs when compiling
gcc/testsuite/g++.dg/abi/covariant5.C w/ -O3 (-Ofast) -fno-ipa-icf-functions:

% g++-9.0.0-alpha20190310 -O3 -fno-ipa-icf-functions -c
gcc/testsuite/g++.dg/abi/covariant5.C
gcc/testsuite/g++.dg/abi/covariant5.C:52:1: error: edge points to wrong
declaration:
   52 | }
  | ^
 
public unsigned DI
size 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fbf10e1cdc8>
QI
size 
unit-size 
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fbf10e40f18
arg-types >>
readonly addressable used nothrow decl_5 QI
gcc/testsuite/g++.dg/abi/covariant5.C:21:14 align:8 warn_if_not_align:0 context
>
 Instead of: 
public unsigned DI
size 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fbf10e1cdc8>
QI
size 
unit-size 
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fbf10e1cf18 method basetype 
arg-types 
chain >>
pointer_to_this >
readonly addressable asm_written used nothrow public virtual decl_5 QI
gcc/testsuite/g++.dg/abi/covariant5.C:21:14 align:8 warn_if_not_align:0 context

full-name "virtual C* C::_ZTchn8_h8_N1C3TwoEv()"
   >
main/24 (int main()) @0x7fbf10e375a0
  Type: function definition analyzed
  Visibility: externally_visible public
  References: 
  Referring: 
  Availability: available
  Function flags: count:1073741824 (estimated locally) body
only_called_at_startup executed_once
  Called by: 
  Calls: virtual C& C::_ZTchn8_h8_N1C5ThreeEv()/12 (487586162 (estimated
locally),0.45 per call) _ZTch0_h8_N1C3TwoEv.constprop/41 (1073741824 (estimated
locally),1.00 per call) 
during IPA pass: cp
gcc/testsuite/g++.dg/abi/covariant5.C:52:1: internal compiler error:
verify_cgraph_node failed
0xb7573c cgraph_node::verify_node()
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190310/work/gcc-9-20190310/gcc/cgraph.c:3444
0xb696bc symtab_node::verify()
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190310/work/gcc-9-20190310/gcc/symtab.c:1225
0xb69797 symtab_node::verify_symtab_nodes()
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190310/work/gcc-9-20190310/gcc/symtab.c:1245
0xdc6997 symtab_node::checking_verify_symtab_nodes()
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190310/work/gcc-9-20190310/gcc/cgraph.h:637
0xdc6997 symbol_table::remove_unreachable_nodes(_IO_FILE*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190310/work/gcc-9-20190310/gcc/ipa.c:667
0xeb8969 execute_todo
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190310/work/gcc-9-20190310/gcc/passes.c:2045

[Bug lto/89692] New: [9 Regression] ICE in streamer_write_chain, at tree-streamer-out.c:506

2019-03-12 Thread asolokha at gmx dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89692

Bug ID: 89692
   Summary: [9 Regression] ICE in streamer_write_chain, at
tree-streamer-out.c:506
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, lto
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

g++-9.0.0-alpha20190310 snapshot (r269561) ICEs when compiling the following
testcase at any optimization level (except -Og) and w/ -flto:

struct ln {
  short int mu;
  short int uz;
  unsigned char ib : 1;
};

int
tl (void)
{
  unsigned char w7[6] = { 0 };
  ln d8;

  __builtin_memcpy (, w7, sizeof (w7));

  return d8.ib == w7[0];
}

% g++-9.0.0-alpha20190310 -O1 -flto -c o0hulxhn.cc
during IPA pass: pure-const
o0hulxhn.cc:16:1: internal compiler error: in streamer_write_chain, at
tree-streamer-out.c:506
   16 | }
  | ^
0x7b2a11 streamer_write_chain(output_block*, tree_node*, bool)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190310/work/gcc-9-20190310/gcc/tree-streamer-out.c:506
0x11ba349 write_ts_type_non_common_tree_pointers
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190310/work/gcc-9-20190310/gcc/tree-streamer-out.c:723
0x11ba349 streamer_write_tree_body(output_block*, tree_node*, bool)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190310/work/gcc-9-20190310/gcc/tree-streamer-out.c:920
0xe41448 lto_write_tree_1
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190310/work/gcc-9-20190310/gcc/lto-streamer-out.c:405
0xe4c125 DFS::DFS(output_block*, tree_node*, bool, bool, bool)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190310/work/gcc-9-20190310/gcc/lto-streamer-out.c:704
0xe4cfe2 lto_output_tree(output_block*, tree_node*, bool, bool)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190310/work/gcc-9-20190310/gcc/lto-streamer-out.c:1628
0xe40eac write_global_stream
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190310/work/gcc-9-20190310/gcc/lto-streamer-out.c:2511
0xe4b13e lto_output_decl_state_streams(output_block*, lto_out_decl_state*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190310/work/gcc-9-20190310/gcc/lto-streamer-out.c:2558
0xe4b13e produce_asm_for_decls()
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190310/work/gcc-9-20190310/gcc/lto-streamer-out.c:2898
0xeb7bef write_lto
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190310/work/gcc-9-20190310/gcc/passes.c:2600
0xebb13e ipa_write_summaries_1
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190310/work/gcc-9-20190310/gcc/passes.c:2661
0xebb13e ipa_write_summaries()
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190310/work/gcc-9-20190310/gcc/passes.c:2724
0xb7d200 ipa_passes
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190310/work/gcc-9-20190310/gcc/cgraphunit.c:2532
0xb7d200 symbol_table::compile()
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190310/work/gcc-9-20190310/gcc/cgraphunit.c:2620
0xb7f33c symbol_table::compile()
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190310/work/gcc-9-20190310/gcc/cgraphunit.c:2599
0xb7f33c symbol_table::finalize_compilation_unit()
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190310/work/gcc-9-20190310/gcc/cgraphunit.c:2865

[Bug c++/89616] Parameter names can be redeclared in outermost block of a function definition

2019-03-12 Thread fruitclover at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89616

Michael Kashkarov  changed:

   What|Removed |Added

 CC||fruitclover at gmail dot com

--- Comment #1 from Michael Kashkarov  ---
Created attachment 45954
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45954=edit
patch

Possible fix is attached (bootstraps x86_64), detects the following case:

 1 void foo(int x){
*2void x();
 3 }

but not sure if the following redefinition is legal (compiles with gcc/clang):

 1 class C {
 2   int x;
 3 public:
 4   C(int);
 5 };
 6 
 7 C::C(int x) try : x(1) {
*8 void x();
 9 } catch (...) {}

from [basic.scope.param]:
... A parameter name shall not be redeclared in the outermost block of the
function definition nor in the outermost block of any handler associated with a
function-try-block.

[Bug c/87950] GCC warns about reaching end of non-void function when all switch cases are completely handled

2019-03-12 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87950

Eric Gallager  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=61864

--- Comment #15 from Eric Gallager  ---
(In reply to Martin Sebor from comment #12)
> I do agree there is room for improvement here.  Consider the following test
> case:
> 
>   $ cat t.c && gcc -O2 -S -Wall -Wextra -Wpedantic -Wswitch-enum
> -fdump-tree-optimized=/dev/stdout t.c
> 
>   enum E { e0 } e;
> 
>   int f (void)
>   {
> switch (e)
>   case e0: return 0;
>   }
>   t.c: In function ‘f’:
>   t.c:7:1: warning: control reaches end of non-void function [-Wreturn-type]
>   7 | }
> | ^
> 
>   ;; Function f (f, funcdef_no=0, decl_uid=1909, cgraph_uid=1,
> symbol_order=1)
> 
>   f ()
>   {
> E e.0_1;
> 
>  [local count: 1073741824]:
> e.0_1 = e;
> if (e.0_1 == 0)
>   goto ; [50.00%]
> else
>   goto ; [50.00%]
> 
>  [local count: 536870913]:
> return 0;
> 
>  [local count: 536870913]:
> return;
> 
>   }
> 
> The -Wswitch-enum option doesn't warn about the switch statement not
> handling switch values that don't correspond to any of the enumerators.  To
> have it diagnosed the -Wswitch-default option has to be explicitly specified
> (it's off by default).
> 
> Given that, I believe the same logic should apply to the -Wreturn-type
> warning: it should not trigger for the snippet above or for the test case in
> comment #0 unless explicitly requested somehow (perhaps it should consider
> -Wswitch-default).

kinda related here (w.r.t. other warnings considering whether -Wswitch-default
is on or not): bug 61864 

> 
> In addition, note the comparison to zero in the optimized GIMPLE.  It's
> unnecessary because the function returns no value when the value of e is
> non-zero.  Clang notices that and avoids the comparison.  But perhaps a
> better example to illustrate the missed optimization opportunity than the
> contrived test case above is this:
> 
>   enum E { e0, e1, e2 } e;
> 
>   int f (void)
>   {
> switch (e)
> {
>   case e0: return 1;
>   case e1: return 2;
>   case e2: return 3;
> }
>   }
> 
> Here, GCC also emits the same pointless comparison/branch:
> 
>   f:
>   movle(%rip), %eax
>   cmpl$2, %eax
>   ja  .L2
>   addl$1, %eax
>   ret
>   .L2:
>   ret

[Bug target/49854] Clean up SPE/e500 option handling

2019-03-12 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49854

--- Comment #2 from Eric Gallager  ---
The SPE port is getting removed for GCC 9, right? So can this be closed then?

[Bug tree-optimization/86708] strlen of an empty aggregate element or member string not folded

2019-03-12 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86708

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-13
 Ever confirmed|0   |1

--- Comment #2 from Martin Sebor  ---
Confirmed on the basis of bug 89688.

[Bug tree-optimization/89688] [9 Regression] -Wstringop-overflow confused by const 2D array of char

2019-03-12 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89688

Martin Sebor  changed:

   What|Removed |Added

 Depends on||86708

--- Comment #3 from Martin Sebor  ---
The missing optimization is the subject of pr86708.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86708
[Bug 86708] strlen of an empty aggregate element or member string not folded

[Bug debug/24943] [hppa64] Bad dwarf output using non-preserved base register

2019-03-12 Thread dave.anglin at bell dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24943

--- Comment #9 from dave.anglin at bell dot net ---
The problem is there isn't a fixed relationship between the stack pointer
register, %r30,
and the argument pointer register, %r29.  HP didn't provide a slot in the stack
frame to
save the argument pointer.  It is call clobbered.  The only option to fix this
issue would be
be to preserve it across calls.  This would impact performance.

[Bug middle-end/89691] New: ICE on a MEM_REF plus negative offset in gimple

2019-03-12 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89691

Bug ID: 89691
   Summary: ICE on a MEM_REF plus negative offset in gimple
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Like in pr89690, I tried the following while attempting to come up with a test
case to exercise -Warray-bounds with pointer to a VLA and got another ICE (I
was using testsuite/gcc.dg/gimplefe-21.c as a template).  I have no idea if the
'+ -2' syntax is meant to be valid.  It seems to like the hex offset.

$ cat z.c && gcc -O2 -S -Wall -fdump-tree-gimple=/dev/stdout -fgimple z.c
extern int x;

void __GIMPLE () g (int *p)
{
  int i;

  i = __MEM  ((char *)p + 1);

  __MEM  ((char *) + -2) = i;
  // __MEM  ((char *) + 0xfffe) = i;   // okay
}
z.c: In function ‘g’:
z.c:9:33: error: expected expression before ‘-’ token
9 |   __MEM  ((char *) + -2) = i;
  | ^
z.c:5:7: warning: variable ‘i’ set but not used [-Wunused-but-set-variable]
5 |   int i;
  |   ^
g (int * p)
z.c:11:1: internal compiler error: tree check: expected class ‘type’, have
‘exceptional’ (error_mark) in dump_generic_node, at tree-pretty-print.c:1694
   11 | }
  | ^
0x15b2de2 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
/src/gcc/git-svn/gcc/tree.c:9907
0x7f0831 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
/src/gcc/git-svn/gcc/tree.h:3299
0x12b27ea dump_generic_node(pretty_printer*, tree_node*, int, dump_flag, bool)
/src/gcc/git-svn/gcc/tree-pretty-print.c:1694
0xcd5b97 dump_gimple_assign
/src/gcc/git-svn/gcc/gimple-pretty-print.c:614
0xcdb7ac pp_gimple_stmt_1(pretty_printer*, gimple*, int, dump_flag)
/src/gcc/git-svn/gcc/gimple-pretty-print.c:2506
0xcd44aa dump_gimple_seq
/src/gcc/git-svn/gcc/gimple-pretty-print.c:200
0xcd74eb dump_gimple_bind
/src/gcc/git-svn/gcc/gimple-pretty-print.c:1149
0xcdb7d2 pp_gimple_stmt_1(pretty_printer*, gimple*, int, dump_flag)
/src/gcc/git-svn/gcc/gimple-pretty-print.c:2510
0xcd44aa dump_gimple_seq
/src/gcc/git-svn/gcc/gimple-pretty-print.c:200
0xcd4537 print_gimple_seq(_IO_FILE*, gimple*, int, dump_flag)
/src/gcc/git-svn/gcc/gimple-pretty-print.c:216
0x11ddfac dump_function_to_file(tree_node*, _IO_FILE*, dump_flag)
/src/gcc/git-svn/gcc/tree-cfg.c:8043
0xae5db1 dump_function(int, tree_node*)
/src/gcc/git-svn/gcc/dumpfile.c:2021
0x8c0bab c_parser_parse_gimple_body(c_parser*)
/src/gcc/git-svn/gcc/c/gimple-parser.c:120
0x87e8b3 c_parser_declaration_or_fndef
/src/gcc/git-svn/gcc/c/c-parser.c:2334
0x87ce6a c_parser_external_declaration
/src/gcc/git-svn/gcc/c/c-parser.c:1653
0x87c96b c_parser_translation_unit
/src/gcc/git-svn/gcc/c/c-parser.c:1534
0x8b6c3e c_parse_file()
/src/gcc/git-svn/gcc/c/c-parser.c:19854
0x94365c c_common_parse_file()
/src/gcc/git-svn/gcc/c-family/c-opts.c:1156
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug middle-end/89690] New: ICE on a MEM_REF in trivial gimple

2019-03-12 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89690

Bug ID: 89690
   Summary: ICE on a MEM_REF in trivial gimple
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The following test case is one of a few I tried that triggers an ICE.  I'm not
sure if it's valid or not but I put it together in response to the suggestion
here: https://gcc.gnu.org/ml/gcc-patches/2019-03/msg00543.html

$ cat z.c && gcc -O2 -S -Wall -fdump-tree-gimple=/dev/stdout -fgimple z.c
void __GIMPLE () h (void)
{
  unsigned char a[4];

  __MEM ((char*) + 16) = 0;   // ditto with MEM  ((char*)) =
0;
}
h ()
{
  unsigned char a[4];

  MEM[(char *) + 16B] = 0;
  return;
}


z.c: In function ‘h’:
z.c:1:18: error: non-trivial conversion at assignment
1 | void __GIMPLE () h (void)
  |  ^
void *
int
MEM[(char *) + 16B] = 0;
during GIMPLE pass: *warn_unused_result
z.c:1:18: internal compiler error: verify_gimple failed
0x11d4f03 verify_gimple_in_seq(gimple*)
/src/gcc/git-svn/gcc/tree-cfg.c:5094
0xfd9b5d execute_function_todo
/src/gcc/git-svn/gcc/passes.c:1979
0xfd8a82 do_per_function
/src/gcc/git-svn/gcc/passes.c:1638
0xfd9d57 execute_todo
/src/gcc/git-svn/gcc/passes.c:2031
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/89689] [7/8 regression] false warning -Wstringop-overflow=

2019-03-12 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89689

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-12
 CC||msebor at gcc dot gnu.org
  Component|c   |tree-optimization
 Ever confirmed|0   |1
  Known to fail||8.3.0, 9.0

--- Comment #1 from Martin Sebor  ---
Confirmed.  The warning is an unfortunate side-effect of an optimization
triggered by the 'if (c->data != __sb_slop)' test in the set0 function.  It
introduces a call to memcpy with __sb_slop as the destination.  The
intermediate representation of the code can be seen in the VRP dump with the
smaller test case below.  We're discussing ways to prevent this in the future
but the only way to avoid it for now that I can think of other than the
#pragma(*) is to either assert(**) h.data != __sb_slop just before calling
memcpy, or "hide" the conditional so it's not visible when compiling the
function that calls memcpy (e.g., by preventing set0 from being inlined via
attribute noinline), disable the warning for this code, or disable
_FORTIFY_SOURCE for this function by calling __builtin_memcpy directly.

[*] It's worth mentioning that #pragma GCC diagnostic doesn't work very well
for these late warnings when inlining is involved.
[**] An assert that would work without any cost is "if (h.data == __sb_slop)
__builtin_unreachable ();"

$ cat a.c && gcc -O2 -S -Wall -fdump-tree-vrp1=/dev/stdout a.c
char __sb_slop[1], buf[5];

void f (char *p)
{
  if (p != __sb_slop)
p[0] = 0;

  __builtin___memcpy_chk (p, "abcd", 4, __builtin_object_size (p, 0));

  if (p != __sb_slop)
p[0] = 0;

}


...
f (char * p)
{
  long unsigned int _15;
  long unsigned int _18;

   [local count: 1073741824]:
  if (p_4(D) != &__sb_slop)
goto ; [70.00%]
  else
goto ; [30.00%] ;; p_4(D) == &__sb_slop

   [local count: 751619278]:
  *p_4(D) = 0;
  _15 = __builtin_object_size (p_4(D), 0);
  __builtin_memcpy (p_4(D), "abcd", 4);
  *p_4(D) = 0;

   [local count: 1073741824]:
  return;

   [local count: 322122544]:
  _18 = __builtin_object_size (p_4(D), 0);
  __builtin_memcpy (p_4(D), "abcd", 4);   ;; p_4(D) == &__sb_slop
  goto ; [100.00%]

}


a.c: In function ‘f’:
a.c:8:3: warning: ‘__builtin_memcpy’ forming offset [2, 4] is out of the bounds
[0, 1] of object ‘__sb_slop’ with type ‘char[1]’ [-Warray-bounds]
8 |   __builtin___memcpy_chk (p, "abcd", 4, __builtin_object_size (p, 0));
  |   ^~~
a.c:1:6: note: ‘__sb_slop’ declared here
1 | char __sb_slop[1], buf[5];
  |  ^

[Bug d/88957] ICE: Segmentation fault in tree_could_trap_p, at tree-eh.c:2672

2019-03-12 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88957

Iain Buclaw  changed:

   What|Removed |Added

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

--- Comment #2 from Iain Buclaw  ---
Fixed in r269627.

[Bug libstdc++/89461] FAIL: experimental/net/timer/waitable/cons.cc

2019-03-12 Thread danglin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89461

--- Comment #9 from John David Anglin  ---
Author: danglin
Date: Tue Mar 12 23:13:36 2019
New Revision: 269628

URL: https://gcc.gnu.org/viewcvs?rev=269628=gcc=rev
Log:
PR libstdc++/89461
* testsuite/lib/libstdc++.exp: Locate libatomic.
* testsuite/lib/dg-options.exp (add_options_for_libatomic): New.
* testsuite/20_util/shared_ptr/thread/default_weaktoshared.cc: Add
libatomic options.
* testsuite/20_util/shared_ptr/thread/mutex_weaktoshared.cc: Likewise.
* testsuite/experimental/net/timer/waitable/cons.cc: Likewise.
* testsuite/experimental/net/timer/waitable/dest.cc: Likewise.
* testsuite/experimental/net/timer/waitable/ops.cc: Likewise.


Modified:
trunk/libstdc++-v3/ChangeLog
   
trunk/libstdc++-v3/testsuite/20_util/shared_ptr/thread/default_weaktoshared.cc
   
trunk/libstdc++-v3/testsuite/20_util/shared_ptr/thread/mutex_weaktoshared.cc
trunk/libstdc++-v3/testsuite/experimental/net/timer/waitable/cons.cc
trunk/libstdc++-v3/testsuite/experimental/net/timer/waitable/dest.cc
trunk/libstdc++-v3/testsuite/experimental/net/timer/waitable/ops.cc
trunk/libstdc++-v3/testsuite/lib/dg-options.exp
trunk/libstdc++-v3/testsuite/lib/libstdc++.exp

[Bug d/88957] ICE: Segmentation fault in tree_could_trap_p, at tree-eh.c:2672

2019-03-12 Thread ibuclaw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88957

--- Comment #1 from ibuclaw at gcc dot gnu.org ---
Author: ibuclaw
Date: Tue Mar 12 23:10:49 2019
New Revision: 269627

URL: https://gcc.gnu.org/viewcvs?rev=269627=gcc=rev
Log:
d/dmd: Merge upstream dmd 19b1454b5

Backports fixes for many ICEs that occurred when using the vector .array
property in both CTFE and code generation passes.

Fixes https://gcc.gnu.org/PR88957

Reviewed-on: https://github.com/dlang/dmd/pull/9438

gcc/d/ChangeLog:

2019-03-13  Iain Buclaw  

PR d/88957
* expr.cc (ExprVisitor::visit(VectorArrayExp)): New override.

gcc/testsuite/ChangeLog:

2019-03-13  Iain Buclaw  

PR d/88957
* gdc.dg/pr88957.d: New test.
* gdc.dg/simd.d: Add new vector tests.

Added:
trunk/gcc/testsuite/gdc.dg/pr88957.d
Modified:
trunk/gcc/d/ChangeLog
trunk/gcc/d/dmd/MERGE
trunk/gcc/d/dmd/ctfeexpr.c
trunk/gcc/d/dmd/dinterpret.c
trunk/gcc/d/dmd/expression.c
trunk/gcc/d/dmd/expression.h
trunk/gcc/d/dmd/expressionsem.c
trunk/gcc/d/dmd/hdrgen.c
trunk/gcc/d/dmd/mtype.c
trunk/gcc/d/dmd/parse.c
trunk/gcc/d/dmd/tokens.c
trunk/gcc/d/dmd/tokens.h
trunk/gcc/d/dmd/visitor.h
trunk/gcc/d/expr.cc
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gdc.dg/simd.d

[Bug c/84717] suffix for double constant is a GCC extension is not documented

2019-03-12 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84717

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
See PR39027 for more details (PR29027 contains the commit info due to PR number
typo).

[Bug c/89684] [8/9 Regression] ICE in gsi_for_stmt, at gimple-iterator.c:613

2019-03-12 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89684

--- Comment #3 from Jakub Jelinek  ---
Tried:
--- gcc/multiple_target.c.jj2019-01-18 09:13:59.081781785 +0100
+++ gcc/multiple_target.c   2019-03-12 22:38:53.197662850 +0100
@@ -105,8 +105,24 @@ create_dispatcher_calls (struct cgraph_n
   auto_vec edges_to_redirect;
   auto_vec references_to_redirect;

+  /* If there are any references where ref->referring == node, we need to
+ be more careful, as ref->remove_reference () will copy the last reference
+ over to the removed one and pop the last one.  So, make sure that
+ the self references are added from the last to first one in the
references
+ vector, then their removal will not affect any earlier references.  */
+  bool self_referring_p = false;
   for (unsigned i = 0; node->iterate_referring (i, ref); i++)
-references_to_redirect.safe_push (ref);
+if (ref->referring == node)
+  self_referring_p = true;
+else
+  references_to_redirect.safe_push (ref);
+  if (self_referring_p)
+{
+  for (unsigned i = node->num_references () - 1;
+  node->iterate_reference (i, ref); i--)
+   if (ref->referred == node)
+ references_to_redirect.safe_push (ref);
+}

   /* We need to remember NEXT_CALLER as it could be modified in the loop.  */
   for (cgraph_edge *e = node->callers; e ; e = e->next_caller)
but it actually isn't sufficient, the problem is any time there is more than
one reference from the same referring to node, because if we don't process them
from last to first, then
  struct ipa_ref *ref = this;

  if (ref != last)
{
  *ref = *last;
  ref->referred_ref_list ()->referring[referred_index] = ref;
}
  list2->references->pop ();
in remove_reference can clobber the other reference we still have in the list.
I'll try tomorrow to capture the references by value instead of pointers to
them and remove them immediately, though guess even that can affect
iterate_referring.

[Bug c/89684] [8/9 Regression] ICE in gsi_for_stmt, at gimple-iterator.c:613

2019-03-12 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89684

--- Comment #2 from Jakub Jelinek  ---
The problem is that references_to_redirect contains ipa_ref_t and those
ipa_ref_t nodes live in the referring node->ref_list.references vector.
If there is more than one reference with ref->referring == node, then we need
to ensure we process them from the one which appears last in
node->ref_list.references vector.

[Bug c/84717] suffix for double constant is a GCC extension is not documented

2019-03-12 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84717

Eric Gallager  changed:

   What|Removed |Added

 CC||joseph at codesourcery dot com,
   ||pinskia at gcc dot gnu.org,
   ||redi at gcc dot gnu.org

--- Comment #5 from Eric Gallager  ---
(In reply to jos...@codesourcery.com from comment #4)
> The 'd' suffix, and the FLOAT_CONST_DECIMAL64 pragma, were in TR 
> 24732:2009.  Those features were not carried forward to the newer decimal 
> floating-point specification in TS 18661-2:2015.
> 
> There haven't been any updates to the DFP support in GCC for the newer 
> specification in TS 18661-2 (or -3, for additional types).  But the vast 
> bulk of the changes in TS 18661-2 are library changes, not language ones, 
> so there probably wouldn't be much to do there (beyond constant rounding 
> modes, which aren't supported for binary floating-point either in GCC).  
> And since we don't have -std modes for TR/TS documents, we don't really 
> have a way to distinguish in GCC which DFP extensions came from which 
> document (until TS 18661-1 and -2 at least get merged into C2x so -std=c2x 
> -pedantic accepts features merged in there but not the features not merged 
> in there).

Wait I thought that was something different? This is just about regular
doubles, not decimal ones, right?

[Bug fortran/66695] [7/8/9 Regression] [F03] ICE with binding-name equal to the name of a use-associated procedure

2019-03-12 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66695

--- Comment #10 from Thomas Koenig  ---
(In reply to Jürgen Reuter from comment #9)
> Sorry if that maybe a stupid question but is it wise that close before the
> new release to start such a bigger coding?

Well, it turned out to be much less invasive than my first approach.

[Bug c++/89668] make[2]: autogen: Command not found

2019-03-12 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89668

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #5 from Eric Gallager  ---
(In reply to Pei JIA from comment #4)
> I just strictly follow
> http://linuxfromscratch.org/lfs/view/stable/chapter06/gcc.html,
> 
> and I'm using the following command line:
> 
> su nobody -s /bin/bash -c "PATH=$PATH make -k check"
> 
> 
> Should I do:
> 
> su nobody -s /bin/bash -c "PATH=$PATH make -k -j8 check" instead??

I'd also add RUNTESTFLAGS=-v

[Bug tree-optimization/89688] [9 Regression] -Wstringop-overflow confused by const 2D array of char

2019-03-12 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89688

Martin Sebor  changed:

   What|Removed |Added

 Blocks||83819

--- Comment #2 from Martin Sebor  ---
Actually, it's slightly more complicated.  string_constant does fold the
reference to the STRING_CST "2" but with the size of 1 because it doesn't
consider the implicit zero that follows the '2'.  Simply changing
string_constant to look at the next element to see if it's zero isn't enough to
handle the case when the zero is implicit because fold_ctor_reference called to
extract the element value only handles explicit initializers.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819
[Bug 83819] [meta-bug] missing strlen optimizations

[Bug c/89689] New: [7/8 regression] false warning -Wstringop-overflow=

2019-03-12 Thread chantry.xavier at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89689

Bug ID: 89689
   Summary: [7/8 regression] false warning -Wstringop-overflow=
   Product: gcc
   Version: 8.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chantry.xavier at gmail dot com
  Target Milestone: ---

Created attachment 45953
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45953=edit
test case

I am testing gcc version 8.3.1 20190228

With "gcc -O" I get the following warning:
In function ‘a’,
inlined from ‘o’ at result2.c:31:5:
result2.c:7:12: warning: ‘__builtin_memcpy’ writing 4 bytes into a region of
size 1 overflows the destination [-Wstringop-overflow=]
 return __builtin___memcpy_chk(c, d, n, __builtin_object_size(c, 0));
^~~~

With "gcc -O -Wall" I get the following warning:
In function ‘a’,
inlined from ‘o’ at result2.c:31:5:
result2.c:7:12: warning: ‘__builtin_memcpy’ forming offset [2, 4] is out of the
bounds [0, 1] of object ‘__sb_slop’ with type ‘const char[1]’ [-Warray-bounds]
 return __builtin___memcpy_chk(c, d, n, __builtin_object_size(c, 0));
^~~~
result2.c: In function ‘o’:
result2.c:13:12: note: ‘__sb_slop’ declared here
 const char __sb_slop[1];
^

In both cases it looks buggy, because h.data points to "char buf[5]" and not to
"const char __sb_slop[1]".

According to my tests on godbolt.org, the first warning appeared on gcc 7, the
second warning appeared on gcc 8. There was no warning with gcc <= 6.

This test case does not make sense but it was derived from production code
using creduce.
I do not want to disable Wstringop-overflow or Warray-bounds entirely because
they look useful sometimes, and I did not find a workaround by modifying the
code. Fortunately the warning can be disabled locally using pragma directives.

[Bug c/89684] [8/9 Regression] ICE in gsi_for_stmt, at gimple-iterator.c:613

2019-03-12 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89684

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-12
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |8.4
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Cleaned up testcase:

void bar (int, void (*) (void));

__attribute__((target_clones ("default", "avx")))
void foo (void)
{
  bar (0, foo);
  bar (0, foo);
}

Started with r258596.

[Bug c++/89686] Lambda pack capture with pack on both sides

2019-03-12 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89686

Marek Polacek  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #2 from Marek Polacek  ---
https://gcc.gnu.org/ml/gcc-patches/2019-03/msg00583.html

[Bug preprocessor/48957] GCC's handling of include-fixed does not work well with --sysroot

2019-03-12 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48957

Eric Gallager  changed:

   What|Removed |Added

 CC||joseph at codesourcery dot com

--- Comment #3 from Eric Gallager  ---
(In reply to Eric Gallager from comment #2)
> (In reply to jos...@codesourcery.com from comment #1)
> > On Wed, 11 May 2011, psmith at gnu dot org wrote:
> > 
> > > I think that the include-fixed directory should be associated with the 
> > > sysroot,
> > 
> > It should be associated with each system include directory (sysroot or 
> > otherwise) - so there should be a fixed version of /usr/local/include, 
> > searched immediately before /usr/local/include, and likewise for 
> > /usr/include.
> 
> This sounds like an agreement that some form of change would be worthwhile;
> I'm going to take that as confirmation.
> 
> > But there are certainly sysroot uses where include-fixed is 
> > still relevant - where the sysroot is based on a copy of that used when 
> > GCC was built, but with extra libraries added.  (That's the case of 
> > sysroots that works most reliably for other reasons as well; GCC's runtime 
> > libraries get configured depending on the libc libraries and headers 
> > present when GCC was built, and in some cases the headers affect the 
> > configuration of GCC itself as well as GCC's libraries.)
> > 
> > http://gcc.gnu.org/ml/gcc-patches/2010-07/msg02088.html
> > http://gcc.gnu.org/ml/gcc/2004-11/msg00255.html
> 
> Shouldn't it be possible to come up with a solution that still supports
> those cases while also fixing the cases Paul described?

Joseph, can you think of one?

[Bug c++/86521] [8/9 Regression] GCC 8 selects incorrect overload of ref-qualified conversion operator template

2019-03-12 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86521

--- Comment #7 from Jason Merrill  ---
Created attachment 45952
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45952=edit
patch to prefer copy elision

This implements that, but I'm going to hold off a bit before committing it.

[Bug tree-optimization/89688] [9 Regression] -Wstringop-overflow confused by const 2D array of char

2019-03-12 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89688

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org

[Bug tree-optimization/89688] [9 Regression] -Wstringop-overflow confused by const 2D array of char

2019-03-12 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89688

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic,
   ||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-12
 CC||msebor at gcc dot gnu.org
  Component|c++ |tree-optimization
Summary|-Wstringop-overflow |[9 Regression]
   |confused by 2D array of |-Wstringop-overflow
   |char|confused by const 2D array
   ||of char
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed.  string_constant successfully folds the call but also sets *DECL to
point to the array which fold_builtin_strlen interprets as the array not being
nul-terminated.  This in turn disables the folding and results in the false
positive.  Fixing it should be as simple as clearing *DECL.

The false positive is a regression.  The strlen() call wasn't folded before so
it by itself isn't, but they might both as well be fixed together.

[Bug d/87824] x86_64-linux multilib issues

2019-03-12 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87824

Iain Buclaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #26 from Iain Buclaw  ---
I think r269625 was the last one to do in the list.

[Bug c/89685] [9 Regression] ICE on attribute copy with a compound expression

2019-03-12 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89685

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||msebor at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
Summary|[9 Regression] ICE: tree|[9 Regression] ICE on
   |check: expected class   |attribute copy with a
   |'type', have 'expression'   |compound expression
   |(compound_expr) in  |
   |diag_attr_exclusions, at|
   |attribs.c:396   |

--- Comment #2 from Martin Sebor  ---
The code in handle_copy_attribute assume that NODE is either a DECL or a TYPE. 
In this case it's a COMPOUND_EXPR:

  /* NODE is either the current DECL to which the attribute is being
 applied or its TYPE.  For the former, consider the attributes on
 both the DECL and its type.  */
  tree attrs[2];

  if (DECL_P (node))
{
  attrs[0] = DECL_ATTRIBUTES (node);
  attrs[1] = TYPE_ATTRIBUTES (TREE_TYPE (node));
}
  else
{
  attrs[0] = TYPE_ATTRIBUTES (node);   <<< ICE here
  attrs[1] = NULL_TREE;
}

This otherwise untested change avoids the ICE but there may be a better way to
fix it.

index adf497322da..aaf8d10dc23 100644
--- a/gcc/attribs.c
+++ b/gcc/attribs.c
@@ -393,7 +393,10 @@ diag_attr_exclusions (tree last_decl, tree node, tree
attrname,
 }
   else
 {
-  attrs[0] = TYPE_ATTRIBUTES (node);
+  if (TYPE_P (node))
+   attrs[0] = TYPE_ATTRIBUTES (node);
+  else
+   attrs[0] = TYPE_ATTRIBUTES (TREE_TYPE (node));
   attrs[1] = NULL_TREE;
 }

[Bug c++/89688] New: -Wstringop-overflow confused by 2D array of char

2019-03-12 Thread redbeard0531 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89688

Bug ID: 89688
   Summary: -Wstringop-overflow confused by 2D array of char
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redbeard0531 at gmail dot com
  Target Milestone: ---

Also, for some reason it repeats the warning 3 times.

https://godbolt.org/z/SStUsl

// Fine
extern const char a[2] = {'1'};
auto z = __builtin_strlen(a);

// Warns
extern const char aa[1][2] = {{'2'}};
auto zz = __builtin_strlen(aa[0]);



> ~/opensource/gcc/prefix/bin/g++ -Wall str.cpp  -fsyntax-only
str.cpp:7:27: warning: ‘strlen’ argument missing terminating nul
[-Wstringop-overflow=]
7 | auto zz = __builtin_strlen(aa[0]);
  |   ^~~
str.cpp:6:19: note: referenced argument declared here
6 | extern const char aa[1][2] = {{'2'}};
  |   ^~
str.cpp:7:27: warning: ‘strlen’ argument missing terminating nul
[-Wstringop-overflow=]
7 | auto zz = __builtin_strlen(aa[0]);
  |   ^~~
str.cpp:6:19: note: referenced argument declared here
6 | extern const char aa[1][2] = {{'2'}};
  |   ^~
str.cpp:7:32: warning: ‘strlen’ argument missing terminating nul
[-Wstringop-overflow=]
7 | auto zz = __builtin_strlen(aa[0]);
  |^
str.cpp:6:19: note: referenced argument declared here
6 | extern const char aa[1][2] = {{'2'}};
  |   ^~


Reduced example from real code at:
https://github.com/boostorg/date_time/blob/b0437e2999a65668dc4178dbb817a89a382ece94/include/boost/date_time/special_values_formatter.hpp#L89-L92
+
https://github.com/boostorg/date_time/blob/b0437e2999a65668dc4178dbb817a89a382ece94/include/boost/date_time/special_values_formatter.hpp#L43-L45

[Bug c++/89686] Lambda pack capture with pack on both sides

2019-03-12 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89686

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org

[Bug d/87824] x86_64-linux multilib issues

2019-03-12 Thread uros at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87824

--- Comment #25 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue Mar 12 18:37:31 2019
New Revision: 269625

URL: https://gcc.gnu.org/viewcvs?rev=269625=gcc=rev
Log:
PR d/87824
* lib/gdc.exp (gdc_include_flags): Find C++ headers by calling
libstdc++v3/scripts/testsuite_flags.  Filter out unsupported
-nostdinc++ flag.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/lib/gdc.exp

[Bug c++/89687] New: Empty pack expansion in `decltype` results in cryptic compiler error (dump_expr)

2019-03-12 Thread vittorio.romeo at outlook dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89687

Bug ID: 89687
   Summary: Empty pack expansion in `decltype` results in cryptic
compiler error (dump_expr)
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vittorio.romeo at outlook dot com
  Target Milestone: ---

Consider the following code:

template 
void foo(F f) 
{
[f](auto... xs) 
{
[xs...]() -> decltype(f(xs...)) { };
};
}

int main()
{
foo([]{ });
}

Live example on godbolt.org:
https://gcc.godbolt.org/z/DTC3f6

It compiles under clang++ trunk, but fails to compile under g++ trunk (9.0.1
20190311) with the following error:

: In instantiation of 'void foo(F) [with F = main()::]':
:12:14:   required from here
:6:32: error: expansion pattern '#'nontype_argument_pack' not
supported by dump_expr#' contains no parameter packs
6 | [xs...]() -> decltype(f(xs...)) { };
|   ~^~~
Compiler returned: 1

[Bug c++/89686] Lambda pack capture with pack on both sides

2019-03-12 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89686

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-12
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Hah.  Confirmed.

[Bug c/89670] __builtin_ctz(_mm256_movemask_epi8(foo)) assumed to be <31 ?

2019-03-12 Thread joern at purestorage dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89670

--- Comment #15 from Jörn Engel  ---
> int foo (int x) { return __builtin_ctz (x); }
> 
> Without -mbmi, gcc emits:
> xorl%eax, %eax
> rep bsfl%edi, %eax
> ret

That example convinces me.  Code would be broken with a zero-argument,
but if the compiler cannot decide whether that is possible and the
programmer can, it makes sense to generate less/faster code.

Thank you!

[Bug c++/89686] New: Lambda pack capture with pack on both sides

2019-03-12 Thread barry.revzin at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89686

Bug ID: 89686
   Summary: Lambda pack capture with pack on both sides
   Product: gcc
   Version: 9.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: ---

Vittorio, the wizard of lambda+pack bugs, is at it again:
https://stackoverflow.com/questions/55127906/lambda-pack-capture-with-ellipsis-on-both-sides-what-is-the-meaning

template 
void foo(Ts... xs)
{
[...xs...]{}();
}

int main()
{
foo(0, 1, 2);
}

gcc trunk accepts this, but it should be ill-formed - you can't have ellipses
on both sides. Gotta be either simple-capture [...xs] or init-capture
[...xs=xs]

[Bug c/89678] Bogus -Wstringop-truncation on strncat with bound that depends on strlen of source

2019-03-12 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89678

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org

[Bug c/89678] Bogus -Wstringop-truncation on strncat with bound that depends on strlen of source

2019-03-12 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89678

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=88780
Summary|Bogus -Wstringop-truncation |Bogus -Wstringop-truncation
   |error   |on strncat with bound that
   ||depends on strlen of source
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
The test case boils down to this:

  void f (char *p, char *q)
  {
unsigned m = __builtin_strlen (p);
unsigned n = __builtin_strlen (q);

__builtin_strncat (p, q, n);
p[m + n] = '\0';
  }

The warning in these cases is by design: it points out that the bound in the
strncat call depends on the length of the source string (which is usually a
bug).  The use case the warning is designed not to trigger for is the one
described in the CERT strncpy and strncat article:
https://www.us-cert.gov/bsi/articles/knowledge/coding-practices/strncpy-and-strncat,
i.e.,

  strncat (dest, source, dest_size - strlen (dest) - 1);

In general, the warning assumes that strncpy and strncat are used in meaningful
(though perhaps incorrect) ways.  In the test case in comment #0, the use of
strncat is correct but pointless.  It's clear that the size of the buffer is
sufficient for the concatenation of the two strings, so there is no point in
using strncat to constrain the copy.  The code would be more clearly and also
more efficiently written like so:

  if ((dst = __builtin_realloc(dst, dstlen + retlen + 1)) != 0) {
strcpy(dst + dstlen, ret);

That said, a patch I'm testing for pr88780 relaxes the warning to avoid
triggering for code like this.

[Bug fortran/83515] ICE: Invalid expression in gfc_element_size

2019-03-12 Thread liakhdi at ornl dot gov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83515

--- Comment #6 from DIL  ---
(In reply to Thomas Schwinge from comment #4)
> (In reply to DIL from comment #2)
> > For GFORTRAN 6.4.0 and earlier, the relevant compiler bug has been fixed in
> > 78300.
> 
> Are you saying that the exact same bug reappeared here, which had previously
> been discussed and fixed in PR78300?
> 
> 
> (In reply to G. Steinmetz from comment #3)
> > Simplified : [...]
> 
> Thanks, ICE confirmed/still present.

What I meant in Comment 2 is that this ICE might be related to 78300 that I
reported in the past. Both have issues with optional dummy procedure arguments.
Sorry for the confusion. This is still an open issue and I still observe this
ICE with gfortran/8.2.0.

[Bug fortran/83515] ICE: Invalid expression in gfc_element_size

2019-03-12 Thread liakhdi at ornl dot gov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83515

--- Comment #5 from DIL  ---
(In reply to Thomas Schwinge from comment #4)
> (In reply to DIL from comment #2)
> > For GFORTRAN 6.4.0 and earlier, the relevant compiler bug has been fixed in
> > 78300.
> 
> Are you saying that the exact same bug reappeared here, which had previously
> been discussed and fixed in PR78300?
> 
> 
> (In reply to G. Steinmetz from comment #3)
> > Simplified : [...]
> 
> Thanks, ICE confirmed/still present.

This ICE is still present in gfortran/8.2.0.

[Bug c/89685] [9 Regression] ICE: tree check: expected class 'type', have 'expression' (compound_expr) in diag_attr_exclusions, at attribs.c:396

2019-03-12 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89685

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-12
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug rtl-optimization/89679] [7/8/9 Regression] wrong code with -Og -frerun-cse-after-loop -fno-tree-fre

2019-03-12 Thread ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89679

--- Comment #5 from Eric Botcazou  ---
> The other variant would be perhaps more in line with the PR70574 change
> where we don't add REG_EQUAL notes with paradoxical subregs in it.

Yes, that looks like the right thing to do to me.

[Bug c/89685] New: [9 Regression] ICE: tree check: expected class 'type', have 'expression' (compound_expr) in diag_attr_exclusions, at attribs.c:396

2019-03-12 Thread gs...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89685

Bug ID: 89685
   Summary: [9 Regression] ICE: tree check: expected class 'type',
have 'expression' (compound_expr) in
diag_attr_exclusions, at attribs.c:396
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed between 20181104 and 2018 :


$ cat z1.c
struct __attribute__((packed)) A {};
struct B { __attribute__((copy ((struct A *) (0, 1 int c; };


$ gcc-9-20190310 -c z1.c
z1.c:2:33: warning: cast to pointer from integer of different size
[-Wint-to-pointer-cast]
2 | struct B { __attribute__((copy ((struct A *) (0, 1 int c; };
  | ^
z1.c:2:41: internal compiler error: tree check: expected class 'type', have
'expression' (compound_expr) in diag_attr_exclusions, at attribs.c:396
2 | struct B { __attribute__((copy ((struct A *) (0, 1 int c; };
  | ^
0x5cf8ca tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc/tree.c:9907
0x5fc44d tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
../../gcc/tree.h:3299
0x5fc44d diag_attr_exclusions
../../gcc/attribs.c:396
0x5fc349 diag_attr_exclusions
../../gcc/attribs.c:379
0x5fe6b8 decl_attributes(tree_node**, tree_node*, int, tree_node*)
../../gcc/attribs.c:698
0x7113c8 handle_copy_attribute
../../gcc/c-family/c-attribs.c:2524
0x5fe732 decl_attributes(tree_node**, tree_node*, int, tree_node*)
../../gcc/attribs.c:719
0x679197 c_parser_struct_declaration
../../gcc/c/c-parser.c:3415
0x66fc1f c_parser_struct_or_union_specifier
../../gcc/c/c-parser.c:3217
0x66fc1f c_parser_declspecs(c_parser*, c_declspecs*, bool, bool, bool, bool,
bool, c_lookahead_kind)
../../gcc/c/c-parser.c:2796
0x6881f8 c_parser_declaration_or_fndef
../../gcc/c/c-parser.c:1850
0x691dc3 c_parser_external_declaration
../../gcc/c/c-parser.c:1653
0x692889 c_parser_translation_unit
../../gcc/c/c-parser.c:1534
0x692889 c_parse_file()
../../gcc/c/c-parser.c:19854
0x6f2890 c_common_parse_file()
../../gcc/c-family/c-opts.c:1155

[Bug c/89684] New: [8/9 Regression] ICE in gsi_for_stmt, at gimple-iterator.c:613

2019-03-12 Thread gs...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89684

Bug ID: 89684
   Summary: [8/9 Regression] ICE in gsi_for_stmt, at
gimple-iterator.c:613
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started with gcc-8, compiles with gcc-7 and older :


$ cat z1.c
__attribute__((target_clones ("default", "avx")))
int f ()
{
  g (0, f);
  g (0, f);
}


$ gcc-9-20190310 -c z1.c
z1.c: In function 'f':
z1.c:4:3: warning: implicit declaration of function 'g'
[-Wimplicit-function-declaration]
4 |   g (0, f);
  |   ^
during IPA pass: targetclone
z1.c: At top level:
z1.c:6:1: internal compiler error: Segmentation fault
6 | }
  | ^
0xa8ab5f crash_signal
../../gcc/toplev.c:326
0x8334b0 gsi_for_stmt(gimple*)
../../gcc/gimple-iterator.c:613
0x1233aae create_dispatcher_calls
../../gcc/multiple_target.c:143
0x1233aae ipa_target_clone
../../gcc/multiple_target.c:505
0x1233aae execute
../../gcc/multiple_target.c:537

[Bug fortran/87673] [7/8/9 Regression] Errors caused by using function for character length in allocate with typespec

2019-03-12 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87673

--- Comment #11 from Thomas Koenig  ---
Author: tkoenig
Date: Tue Mar 12 17:22:28 2019
New Revision: 269624

URL: https://gcc.gnu.org/viewcvs?rev=269624=gcc=rev
Log:
2019-03-12  Thomas Koenig  

PR fortran/87673
* match.c (gfc_match_type_spec): Remove call to
gfc_resolve_expr for character length.

2019-03-12  Thomas Koenig  

PR fortran/87673
* gfortran.dg/charlen_17.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/charlen_17.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/match.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/89679] [7/8/9 Regression] wrong code with -Og -frerun-cse-after-loop -fno-tree-fre

2019-03-12 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89679

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
  Component|middle-end  |rtl-optimization

[Bug middle-end/89677] [8 Regression] internal compiler error: in wide_int_to_tree_1, at tree.c:1549

2019-03-12 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89677

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #2 from Richard Biener  ---
I will investigate.

[Bug libstdc++/86655] std::assoc_legendre should not constrain the value of m

2019-03-12 Thread joseph at codesourcery dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86655

--- Comment #9 from joseph at codesourcery dot com  ---
On Mon, 4 Mar 2019, emsr at gcc dot gnu.org wrote:

> Also, the legendre functions should not be onstrained on the argument x 
> either.
> They are just polynomials.  The recursions are numerically good in this range
> (|x| > 1) also.

"Otherwise, the function shall report a domain error for just those 
argument values for which: the function description's Returns: clause 
explicitly specifies a domain and those argument values fall outside the 
specified domain, or [...]" (and the Returns: clause in this case 
explicitly says "for |x| <= 1", which I read as making that case a domain 
error even though the function is mathematically defined there).

For the corresponding C specification, ISO 24747, there's a Rationale 
document  (not 
sure if there's any more recent version, or such a rationale for the C++ 
version) saying "The associated Legendre polynomials are well defined for 
all m and n; hence the ISO 31 restriction m <= n is omitted. On the other 
hand, adding the restriction |x| <= 1 simplifies implementation at no 
apparent hardship to programmers.".

[Bug fortran/83515] ICE: Invalid expression in gfc_element_size

2019-03-12 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83515

Thomas Schwinge  changed:

   What|Removed |Added

   Last reconfirmed|2017-12-22 00:00:00 |2019-3-12
 CC||tschwinge at gcc dot gnu.org

--- Comment #4 from Thomas Schwinge  ---
(In reply to DIL from comment #2)
> For GFORTRAN 6.4.0 and earlier, the relevant compiler bug has been fixed in
> 78300.

Are you saying that the exact same bug reappeared here, which had previously
been discussed and fixed in PR78300?


(In reply to G. Steinmetz from comment #3)
> Simplified : [...]

Thanks, ICE confirmed/still present.

[Bug tree-optimization/89679] [7/8/9 Regression] wrong code with -Og -frerun-cse-after-loop -fno-tree-fre

2019-03-12 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89679

--- Comment #4 from Jakub Jelinek  ---
The other variant would be perhaps more in line with the PR70574 change where
we don't add REG_EQUAL notes with paradoxical subregs in it, by:
--- gcc/expmed.c.jj 2019-01-10 11:43:14.387377695 +0100
+++ gcc/expmed.c2019-03-12 17:38:55.286511666 +0100
@@ -3356,13 +3356,20 @@ expand_mult_const (machine_mode mode, rt
  tem = gen_lowpart (nmode, op0);
}

- insn = get_last_insn ();
- wide_int wval_so_far
-   = wi::uhwi (val_so_far,
-   GET_MODE_PRECISION (as_a  (nmode)));
- rtx c = immed_wide_int_const (wval_so_far, nmode);
- set_dst_reg_note (insn, REG_EQUAL, gen_rtx_MULT (nmode, tem, c),
-   accum_inner);
+ /* Don't add a REG_EQUAL note if tem is a paradoxical SUBREG.
+In that case, only the low bits of accum would be guaranteed to
+be equal to the content of the REG_EQUAL note, the upper bits
+can be anything.  */
+ if (!paradoxical_subreg_p (tem))
+   {
+ insn = get_last_insn ();
+ wide_int wval_so_far
+   = wi::uhwi (val_so_far,
+   GET_MODE_PRECISION (as_a  (nmode)));
+ rtx c = immed_wide_int_const (wval_so_far, nmode);
+ set_dst_reg_note (insn, REG_EQUAL, gen_rtx_MULT (nmode, tem, c),
+   accum_inner);
+   }
}
 }

[Bug d/87866] gdc fails to compile minimal test

2019-03-12 Thread ibuclaw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87866

--- Comment #7 from ibuclaw at gcc dot gnu.org ---
Author: ibuclaw
Date: Tue Mar 12 16:31:48 2019
New Revision: 269619

URL: https://gcc.gnu.org/viewcvs?rev=269619=gcc=rev
Log:
Use libiberty's lrealpath to avoid portability problems.

The dmd front-end function FileName::canonicalName could be called
during the semantic pass of import("file") expressions, so still
requires that realpath() be redefined.

Initial patch by Rainer Orth.

gcc/d/ChangeLog:

2019-03-12  Iain Buclaw  

PR d/87866
* d-system.h (realpath): Redefine as lrealpath.

Modified:
trunk/gcc/d/ChangeLog
trunk/gcc/d/d-system.h

[Bug tree-optimization/89679] [7/8/9 Regression] wrong code with -Og -frerun-cse-after-loop -fno-tree-fre

2019-03-12 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89679

Jakub Jelinek  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org,
   ||law at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
If I change inside of the debugger that 0x in REG_EQUAL note to
constm1_rtx, then the testcase is not miscompiled.
The REG_EQUAL note is initially added by expand_mult_const:
  if (SCALAR_INT_MODE_P (mode))
{
  /* Write a REG_EQUAL note on the last insn so that we can cse
 multiplication sequences.  Note that if ACCUM is a SUBREG,
 we've set the inner register and must properly indicate that.  */
  tem = op0, nmode = mode;
  accum_inner = accum;
  if (GET_CODE (accum) == SUBREG)
{
  accum_inner = SUBREG_REG (accum);
  nmode = GET_MODE (accum_inner);
  tem = gen_lowpart (nmode, op0);
}

  insn = get_last_insn ();
  wide_int wval_so_far
= wi::uhwi (val_so_far,
GET_MODE_PRECISION (as_a  (nmode)));
  rtx c = immed_wide_int_const (wval_so_far, nmode);
  set_dst_reg_note (insn, REG_EQUAL, gen_rtx_MULT (nmode, tem, c),
accum_inner);
}
As accum is a (subreg:HI (reg:SI 140) 0), it emits a REG_EQUAL note with
paradoxical subreg in it:
(insn 17 16 18 2 (set (reg:SI 140)
(plus:SI (subreg:SI (reg:HI 138) 0)
(subreg:SI (reg:HI 136) 0))) "pr89679.c":16:3 -1
 (expr_list:REG_EQUAL (mult:SI (subreg:SI (reg:HI 136) 0)
(const_int 257 [0x101]))
(nil)))
the note is already quite questionable, because the SImode register is not
necessarily equal to that, the high 16 bits can be anything.
If it is not valid, then we either must make sure not to emit a REG_EQUAL note
in that case or emit it on some insn that sets a HImode reg rather than SImode.
Note we emit that that way for quite a long time, I think since
https://gcc.gnu.org/ml/gcc-patches/2000-12/msg00837.html

This is related to the https://gcc.gnu.org/ml/gcc-patches/2016-04/msg00418.html
change, though in this case we already have such a REG_EQUAL note that before
the change can be at least determined to have a paradoxical subreg in it and so
REG_EQUAL note consumers could take that into account.
But if we simplify it into a CONST_INT or whatever else that doesn't have the
paradoxical subreg in there anymore, this info is lost.

We could e.g. do:
--- gcc/fwprop.c.jj 2019-01-01 12:37:21.190908780 +0100
+++ gcc/fwprop.c2019-03-12 17:24:14.623863160 +0100
@@ -1327,7 +1327,12 @@ forward_propagate_and_simplify (df_ref u
 {
   rtx note = find_reg_note (use_insn, REG_EQUAL, NULL_RTX);
   if (DF_REF_FLAGS (use) & DF_REF_IN_NOTE)
-   loc =  (note, 0);
+   {
+ loc =  (note, 0);
+ /* Don't simplify a paradoxical SUBREG in a REG_EQUAL note.  */
+ if (paradoxical_subreg_p (DF_REF_REG (use)))
+   return false;
+   }
   else
loc = _SRC (use_set);

and thus not really simplify paradoxical subregs in REG_EQUAL notes, the notes
will be then removed if we DCE the setters of corresponding pseudos.

Thoughts on this?

[Bug tree-optimization/89664] [8 Regression] ICE in free_bb, at tree-ssa-math-opts.c:522

2019-03-12 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89664

--- Comment #7 from Richard Biener  ---
Author: rguenth
Date: Tue Mar 12 16:15:47 2019
New Revision: 269618

URL: https://gcc.gnu.org/viewcvs?rev=269618=gcc=rev
Log:
2019-03-12  Richard Biener  

PR tree-optimization/89664
* tree-ssa-math-opts.c (execute_cse_reciprocals_1): Properly
free the occurance tree after the early out.

* gfortran.dg/pr89664.f90: New testcase.

Added:
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pr89664.f90
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/gcc/tree-ssa-math-opts.c

[Bug tree-optimization/89664] [8 Regression] ICE in free_bb, at tree-ssa-math-opts.c:522

2019-03-12 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89664

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||8.3.1, 9.0
 Resolution|--- |FIXED
  Known to fail|9.0 |

--- Comment #6 from Richard Biener  ---
Fixed.

[Bug c++/89683] New: Function-style cast inside alignas on struct does not compile

2019-03-12 Thread deaeod at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89683

Bug ID: 89683
   Summary: Function-style cast inside alignas on struct does not
compile
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: deaeod at gmail dot com
  Target Milestone: ---

The following snippet does not compile with g++:

struct alignas(unsigned(8)) s {};

Workaround:

struct alignas((unsigned)8) s {};

[Bug tree-optimization/89679] [7/8/9 Regression] wrong code with -Og -frerun-cse-after-loop -fno-tree-fre

2019-03-12 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89679

--- Comment #2 from Jakub Jelinek  ---
The first thing which looks invalid to me is when fwprop1 adds a bogus
REG_EQUAL note:
(insn 17 6 19 2 (set (reg:SI 140)
(const_int -1 [0x])) "pr89679.c":16:3 494
{*movsi_internal1}
 (expr_list:REG_DEAD (reg:HI 138 [ c ])
(expr_list:REG_DEAD (reg:HI 136 [ c ])
(expr_list:REG_EQUAL (const_int 65535 [0x])
(nil)

SImode -1 is certainly not equal to 0x.

[Bug fortran/89363] RANK incorrect for unallocated allocatable

2019-03-12 Thread pault at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89363

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #4 from Paul Thomas  ---
Fixed on trunk.

Thanks for the report.

Paul

[Bug fortran/89364] Assumed rank object with incorrect values for shape and bounds

2019-03-12 Thread pault at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89364

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #5 from Paul Thomas  ---
Fixed on trunk.

Thanks for the report.

Paul

[Bug tree-optimization/89679] [7/8/9 Regression] wrong code with -Og -frerun-cse-after-loop -fno-tree-fre

2019-03-12 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89679

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-12
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |7.5
Summary|wrong code with -Og |[7/8/9 Regression] wrong
   |-frerun-cse-after-loop  |code with -Og
   |-fno-tree-fre   |-frerun-cse-after-loop
   ||-fno-tree-fre
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r205060.

[Bug c++/89682] [9 Regression] g++9 incorrectly disallows using private static method as default arg to ctor of template type

2019-03-12 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89682

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-12
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
   Target Milestone|--- |9.0
Summary|g++9 incorrectly disallows  |[9 Regression] g++9
   |using private static method |incorrectly disallows using
   |as default arg to ctor of   |private static method as
   |template type   |default arg to ctor of
   ||template type
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Rejected since r261656.

[Bug target/87561] [9 Regression] 416.gamess is slower by ~10% starting from r264866 with -Ofast

2019-03-12 Thread matz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87561

--- Comment #9 from Michael Matz  ---
(In reply to Richard Biener from comment #8)
> 
> I'm out of ideas suitable for GCC 9 (besides reverting the patch, reverting
> to bogus state).

Either that or some hack (e.g. artificially avoiding vectorization if runtime
checks are necessary and the loop-nest isn't a box but a pyramid).  Whatever
we do it's better to release GCC with internal bogus state than to release
GCC with a known 10% performance regression (you could revert only on the
release branch so that the regression stays in trunk).

[Bug c++/89682] New: g++9 incorrectly disallows using private static method as default arg to ctor of template type

2019-03-12 Thread redbeard0531 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89682

Bug ID: 89682
   Summary: g++9 incorrectly disallows using private static method
as default arg to ctor of template type
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redbeard0531 at gmail dot com
  Target Milestone: ---

New in GCC9. No other compiler errors on this:

https://godbolt.org/z/480KfZ

template 
class C {
class TagType {};
public:
C(int, TagType = makeTag());
private:
static TagType makeTag();
};

void test() {
C(1);
}


> g++ -fsyntax-only./creduce_repro/test.ii
./creduce_repro/test.ii: In function ‘void test()’:
./creduce_repro/test.ii:5:29: error: ‘static C::TagType C::makeTag()
[with T = int]’ is private within this context
5 | C(int, TagType = makeTag());
  |  ~~~^~
./creduce_repro/test.ii:7:20: note: declared private here
7 | static TagType makeTag();
  |^~~

[Bug c/43673] Incorrect warning: use of 'D' length modifier with 'a' type character

2019-03-12 Thread joseph at codesourcery dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43673

--- Comment #6 from joseph at codesourcery dot com  ---
On Tue, 12 Mar 2019, luoxhu at cn dot ibm.com wrote:

> Actually this was introduced by the initial patch
> https://gcc.gnu.org/ml/gcc-patches/2005-12/msg00330.html committed in 2005. 
> All

That means this is not a regression, and trunk is currently in 
regression-fixes mode in preparation for GCC 9 branching.  So I suggest 
resubmitting / pinging the patch after the GCC 9 branch is created, likely 
next month.

[Bug debug/89681] Incorrect source positions on O1 for simple code case

2019-03-12 Thread alahay01 at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89681

--- Comment #2 from alahay01 at gcc dot gnu.org ---
Created attachment 45951
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45951=edit
O0 expand pass

[Bug debug/89681] Incorrect source positions on O1 for simple code case

2019-03-12 Thread alahay01 at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89681

--- Comment #1 from alahay01 at gcc dot gnu.org ---
Created attachment 45950
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45950=edit
O1 expand pass

[Bug debug/89681] New: Incorrect source positions on O1 for simple code case

2019-03-12 Thread alahay01 at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89681

Bug ID: 89681
   Summary: Incorrect source positions on O1 for simple code case
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alahay01 at gcc dot gnu.org
  Target Milestone: ---

Created attachment 45949
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45949=edit
source code

Compiling a simple test case with O1 gives incorrect line numbers for two of
the lines of assembly.

Tested this on HEAD, 6.4.0, 7.2.0, using both X86-64 and AArch64. Debug results
are the same for all.

$ gcc --version
gcc (Ubuntu 7.2.0-1ubuntu1~16.04) 7.2.0

$ cat -n consume.c
 1  extern void consume(int);
 2  void testfunc(int **p) {
 3int *a = *p;
 4int b = *a;
 5consume(b);
 6  }

$ gcc -O1 -g consume.c -c -fdump-rtl-all
$ objdump -S -l -d consume.o

consume.o: file format elf64-x86-64


Disassembly of section .text:

 :
testfunc():
/home/alahay01/consume.c:2
extern void consume(int);
void testfunc(int **p) {
   0:   48 83 ec 08 sub$0x8,%rsp
/home/alahay01/consume.c:4
  int *a = *p;
  int b = *a;
   4:   48 8b 07mov(%rdi),%rax
/home/alahay01/consume.c:5
  consume(b);
   7:   8b 38   mov(%rax),%edi
   9:   e8 00 00 00 00  callq  e 
/home/alahay01/consume.c:6
}
   e:   48 83 c4 08 add$0x8,%rsp
  12:   c3  retq


>The two MOV instructions are on the wrong line. They are given lines 4 and 5. 
>They should have lines 3 and 4.



$ cat consume.c.229r.expand

;; Function testfunc (testfunc, funcdef_no=0, decl_uid=1795, cgraph_uid=0,
symbol_order=0)


;; Generating RTL for gimple basic block 2


try_optimize_cfg iteration 1

Merging block 3 into block 2...
Merged blocks 2 and 3.
Merged 2 and 3 without moving.
Merging block 4 into block 2...
Merged blocks 2 and 4.
Merged 2 and 4 without moving.


try_optimize_cfg iteration 2



;;
;; Full RTL generated for this function:
;;
(note 1 0 4 NOTE_INSN_DELETED)
(note 4 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(insn 2 4 3 2 (set (reg/v/f:DI 89 [ p ])
(reg:DI 5 di [ p ])) "consume.c":2 -1
 (nil))
(note 3 2 6 2 NOTE_INSN_FUNCTION_BEG)
(debug_insn 6 3 7 2 (var_location:DI a (mem/f:DI (reg/v/f:DI 89 [ p ]) [1
*p_2(D)+0 S8 A64])) "consume.c":3 -1
 (nil))
(debug_insn 7 6 8 2 (var_location:SI b (mem:SI (mem/f:DI (reg/v/f:DI 89 [ p ])
[1 *p_2(D)+0 S8 A64]) [2 *a_3+0 S4 A32])) "consume.c":4 -1
 (nil))
(insn 8 7 9 2 (set (reg/f:DI 90)
(mem/f:DI (reg/v/f:DI 89 [ p ]) [1 *p_2(D)+0 S8 A64])) "consume.c":4 -1
 (nil))
(insn 9 8 10 2 (set (reg:SI 5 di)
(mem:SI (reg/f:DI 90) [2 *a_3+0 S4 A32])) "consume.c":5 -1
 (nil))
(call_insn 10 9 0 2 (call (mem:QI (symbol_ref:DI ("consume") [flags 0x41] 
) [0 consume S1 A8])
(const_int 0 [0])) "consume.c":5 -1
 (nil)
(expr_list:SI (use (reg:SI 5 di))
(nil)))


>Looks to me like it goes wrong in the expand phase. There are two debug_insn's 
>for lines 3 and 4. But, then there are two insn's for line 4 and 5. I think 
>these are incorrect, and should be lines 3 and 4.



>With O0 the results are correct:

$ gcc -O0 -g consume.c -c -fdump-rtl-all
$ objdump -S -l -d consume.o

consume.o: file format elf64-x86-64


Disassembly of section .text:

 :
testfunc():
/home/alahay01/consume.c:2
extern void consume(int);
void testfunc(int **p) {
   0:   55  push   %rbp
   1:   48 89 e5mov%rsp,%rbp
   4:   48 83 ec 20 sub$0x20,%rsp
   8:   48 89 7d e8 mov%rdi,-0x18(%rbp)
/home/alahay01/consume.c:3
  int *a = *p;
   c:   48 8b 45 e8 mov-0x18(%rbp),%rax
  10:   48 8b 00mov(%rax),%rax
  13:   48 89 45 f8 mov%rax,-0x8(%rbp)
/home/alahay01/consume.c:4
  int b = *a;
  17:   48 8b 45 f8 mov-0x8(%rbp),%rax
  1b:   8b 00   mov(%rax),%eax
  1d:   89 45 f4mov%eax,-0xc(%rbp)
/home/alahay01/consume.c:5
  consume(b);
  20:   8b 45 f4mov-0xc(%rbp),%eax
  23:   89 c7   mov%eax,%edi
  25:   e8 00 00 00 00  callq  2a 
/home/alahay01/consume.c:6
}
  2a:   90  nop
  2b:   c9  leaveq
  2c:   c3  retq


$ cat consume.c.229r.expand

;; Function testfunc (testfunc, funcdef_no=0, decl_uid=1795, cgraph_uid=0,
symbol_order=0)

Partition 0: size 8 align 8
a_3
Partition 1: size 4 align 4
b_4

;; Generating RTL for gimple basic block 2


try_optimize_cfg iteration 1

Merging block 3 into block 2...
Merged blocks 2 and 3.
Merged 2 and 3 without moving.
Merging block 4 into block 2...
Merged blocks 2 and 4.
Merged 2 and 4 without 

[Bug rtl-optimization/89680] Redundant moves with -march=skylake for long long shift on 32bit x86

2019-03-12 Thread ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89680

Uroš Bizjak  changed:

   What|Removed |Added

   Keywords||ra
  Component|target  |rtl-optimization

--- Comment #1 from Uroš Bizjak  ---
This issue can be "solved" by the following cost-adjustment patch:

diff --git a/gcc/config/i386/x86-tune-costs.h
b/gcc/config/i386/x86-tune-costs.h
index ac06e37733a0..9301fc2d9231 100644
--- a/gcc/config/i386/x86-tune-costs.h
+++ b/gcc/config/i386/x86-tune-costs.h
@@ -1457,7 +1457,7 @@ struct processor_costs skylake_cost = {
   {6, 6, 6, 10, 20},   /* cost of loading SSE registers
   in 32,64,128,256 and 512-bit */
   {6, 6, 6, 10, 20},   /* cost of unaligned loads.  */
-  {8, 8, 8, 12, 24},   /* cost of storing SSE registers
+  {8, 6, 8, 12, 24},   /* cost of storing SSE registers
   in 32,64,128,256 and 512-bit */
   {8, 8, 8, 8, 16},/* cost of unaligned stores.  */
   2, 2,/* SSE->integer and
integer->SSE moves */

However, RA should notice that the value is already in memory and should be
loaded from there regardless of costs. Based on this reasoning, I think this is
RA problem.

[Bug fortran/89364] Assumed rank object with incorrect values for shape and bounds

2019-03-12 Thread pault at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89364

--- Comment #4 from Paul Thomas  ---
Author: pault
Date: Tue Mar 12 13:40:51 2019
New Revision: 269612

URL: https://gcc.gnu.org/viewcvs?rev=269612=gcc=rev
Log:
2019-03-12  Paul Thomas  

PR fortran/89363
PR fortran/89364
* trans-expr.c (set_dtype_for_unallocated): New function.
(gfc_conv_gfc_desc_to_cfi_desc): Call it for allocatable and
pointer arguments.
(gfc_conv_procedure_call): Likewise. Also, set the ubound of
the final dimension to -1 for assumed rank formal args that are
associated with assumed size arrays.
* trans-intrinsic.c (gfc_conv_intrinsic_bound): Return -1 for
the final dimension of assumed rank entities that are argument
associated with assumed size arrays.
(gfc_conv_intrinsic_shape): Likewise return -1 for the final
dimension of the shape intrinsic.

2019-03-12  Paul Thomas  

PR fortran/89363
* gfortran.dg/assumed_rank_16.f90: New test.

PR fortran/89364
* gfortran.dg/assumed_rank_17.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/assumed_rank_16.f90
trunk/gcc/testsuite/gfortran.dg/assumed_rank_17.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-expr.c
trunk/gcc/fortran/trans-intrinsic.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/89363] RANK incorrect for unallocated allocatable

2019-03-12 Thread pault at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89363

--- Comment #3 from Paul Thomas  ---
Author: pault
Date: Tue Mar 12 13:40:51 2019
New Revision: 269612

URL: https://gcc.gnu.org/viewcvs?rev=269612=gcc=rev
Log:
2019-03-12  Paul Thomas  

PR fortran/89363
PR fortran/89364
* trans-expr.c (set_dtype_for_unallocated): New function.
(gfc_conv_gfc_desc_to_cfi_desc): Call it for allocatable and
pointer arguments.
(gfc_conv_procedure_call): Likewise. Also, set the ubound of
the final dimension to -1 for assumed rank formal args that are
associated with assumed size arrays.
* trans-intrinsic.c (gfc_conv_intrinsic_bound): Return -1 for
the final dimension of assumed rank entities that are argument
associated with assumed size arrays.
(gfc_conv_intrinsic_shape): Likewise return -1 for the final
dimension of the shape intrinsic.

2019-03-12  Paul Thomas  

PR fortran/89363
* gfortran.dg/assumed_rank_16.f90: New test.

PR fortran/89364
* gfortran.dg/assumed_rank_17.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/assumed_rank_16.f90
trunk/gcc/testsuite/gfortran.dg/assumed_rank_17.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-expr.c
trunk/gcc/fortran/trans-intrinsic.c
trunk/gcc/testsuite/ChangeLog

[Bug target/89680] New: Redundant moves with -march=skylake for long long shift on 32bit x86

2019-03-12 Thread ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89680

Bug ID: 89680
   Summary: Redundant moves with -march=skylake for long long
shift on 32bit x86
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ubizjak at gmail dot com
  Target Milestone: ---

Following testcase:

--cut here--
unsigned long long
foo (unsigned long long i)
{
  return i << 3;
}
--cut here--

compiles with -O2 -march=skylake -m32 to:

subl$28, %esp
movl32(%esp), %eax
movl36(%esp), %edx
movl%eax, (%esp)
movl%edx, 4(%esp)
vmovdqa (%esp), %xmm1
addl$28, %esp
vpsllq  $3, %xmm1, %xmm0
vmovd   %xmm0, %eax
vpextrd $1, %xmm0, %edx
ret

but with -O2 -march=haswell -m32 to:

vmovq   4(%esp), %xmm0
vpsllq  $3, %xmm0, %xmm0
vmovd   %xmm0, %eax
vpextrd $1, %xmm0, %edx
ret

The difference starts in IRA pass with:

Pass 0 for finding pseudo/allocno costs

 a0 (r88,l0) best DREG, allocno DREG
 a1 (r87,l0) best AREG, allocno AREG
 a2 (r85,l0) best NO_REX_SSE_REGS, allocno NO_REX_SSE_REGS
-a3 (r83,l0) best NO_REX_SSE_REGS, allocno NO_REX_SSE_REGS
+a3 (r83,l0) best NO_REGS, allocno NO_REGS

 Pass 1 for finding pseudo/allocno costs

 r88: preferred DREG, alternative GENERAL_REGS, allocno GENERAL_REGS
 r87: preferred AREG, alternative GENERAL_REGS, allocno GENERAL_REGS
 r85: preferred NO_REX_SSE_REGS, alternative NO_REGS, allocno
NO_REX_SSE_REGS
-r83: preferred NO_REX_SSE_REGS, alternative NO_REGS, allocno
NO_REX_SSE_REGS
+r83: preferred NO_REGS, alternative NO_REGS, allocno NO_REGS

and going downhill from there.

[Bug rtl-optimization/89654] [8/9 Regression] Invalid reload with -march=skylake -m32

2019-03-12 Thread ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89654

--- Comment #7 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #6)
> (In reply to H.J. Lu from comment #4)
> > Is this a dup of PR 69693?
> 
> Yes, indeed. The issue with too many moves remain, I'll open a new PR for
> that.

I'll also open a new PR due to difference with -march=haswell (---) and
-march=skylake (+++):

--- haswell/pr89654.s   2019-03-12 13:54:24.517146380 +0100
+++ skylake/pr89654.s   2019-03-12 13:57:39.792106411 +0100
@@ -6,8 +6,16 @@
 foo:
 .LFB0:
.cfi_startproc
-   vmovq   4(%esp), %xmm0
-   vpsllq  $3, %xmm0, %xmm0
+   subl$28, %esp
+   .cfi_def_cfa_offset 32
+   movl32(%esp), %eax
+   movl36(%esp), %edx
+   movl%eax, (%esp)
+   movl%edx, 4(%esp)
+   vmovdqa (%esp), %xmm1
+   addl$28, %esp
+   .cfi_def_cfa_offset 4
+   vpsllq  $3, %xmm1, %xmm0
vmovd   %xmm0, %eax
vpextrd $1, %xmm0, %edx
ret

[Bug fortran/89646] Spurious actual argument might interfere warning

2019-03-12 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89646

--- Comment #3 from Dominique d'Humieres  ---
The check has been introduced at revision r141931 and is now

  /* We are told not to check dependencies.
 We do it, however, and issue a warning in case we find
one.
 If a dependency is found in the case
 elemental == ELEM_CHECK_VARIABLE, we will generate
 a temporary, so we don't need to bother the user.  */
  gfc_warning (0, "INTENT(%s) actual argument at %L might "
   "interfere with actual argument at %L.",
   intent == INTENT_OUT ? "OUT" : "INOUT",
   >where, >where);

The warning is unconditional, but it should be easy to replace the 9 with some
suitable option.

[Bug target/69693] Wrong mode is used to load spilled register

2019-03-12 Thread ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69693

--- Comment #8 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #3)
> Your patch will just paper over the real issue in this particular testcase.

This can be illustrated with an example from PR89654:

--cut here--
unsigned long long
foo (unsigned long long i, int z)
{
  return i << 3;
}
--cut here--

with a patch:

--cut here--
diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index d4c01407f4a2..6142f5272a2e 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -1290,6 +1290,16 @@
(set_attr "prefix" "maybe_vex")
(set_attr "mode" "TI")])

+;; Used by STV to load a DI into an xmm register.
+(define_insn "*movdi_to_v2di"
+  [(set (match_operand:V2DI 0 "register_operand" "=x")
+(subreg:V2DI (match_operand:DI 1 "nonimmediate_operand" "xm") 0))]
+  "!TARGET_64BIT && TARGET_SSE2"
+  "%vmovq\t{%1, %0|%0, %1}"
+  [(set_attr "type" "ssemov")
+   (set_attr "prefix" "maybe_vex")
+   (set_attr "mode" "DI")])
+
 ;; Move a DI from a 32-bit register pair (e.g. %edx:%eax) to an xmm.
 ;; We'd rather avoid this entirely; if the 32-bit reg pair was loaded
 ;; from memory, we'd prefer to load the memory directly into the %xmm
--cut here--

./cc1 -O2 -m32 -march=skylake indeed creates:

movl32(%esp), %eax  # 24[c=8 l=4]  *movsi_internal/0
movl36(%esp), %edx  # 25[c=8 l=4]  *movsi_internal/0
movl%eax, (%esp)# 26[c=4 l=3]  *movsi_internal/1
movl%edx, 4(%esp)   # 27[c=4 l=4]  *movsi_internal/1
vmovq   (%esp), %xmm1   # 21[c=24 l=5]  *movdi_to_v2di
vpsllq  $3, %xmm1, %xmm0# 7 [c=4 l=5]  ashlv2di3/1

but ./cc1 -O2 -m32 -march=skylake-avx512 shows:

movl32(%esp), %eax  # 23[c=8 l=4]  *movsi_internal/0
movl36(%esp), %edx  # 24[c=8 l=4]  *movsi_internal/0
movl%eax, (%esp)# 25[c=4 l=3]  *movsi_internal/1
movl%edx, 4(%esp)   # 26[c=4 l=4]  *movsi_internal/1
vpsllq  $3, (%esp), %xmm0   # 7 [c=20 l=6]  *ashlv2di3/1

where VPSLLQ still loads V2DImode from stack.

[Bug tree-optimization/89679] New: wrong code with -Og -frerun-cse-after-loop -fno-tree-fre

2019-03-12 Thread zsojka at seznam dot cz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89679

Bug ID: 89679
   Summary: wrong code with -Og -frerun-cse-after-loop
-fno-tree-fre
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: powerpc64le-unknown-linux-gnu

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

Output:
$ powerpc64le-unknown-linux-gnu-gcc -Og -frerun-cse-after-loop -fno-tree-fre
testcase.c -static -Wall -W
$ ./a.out 
qemu: uncaught target signal 6 (Aborted) - core dumped
Aborted

$ powerpc64le-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-powerpc64le/bin/powerpc64le-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-269602-checking-yes-rtl-df-extra-powerpc64le/bin/../libexec/gcc/powerpc64le-unknown-linux-gnu/9.0.1/lto-wrapper
Target: powerpc64le-unknown-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl
--with-sysroot=/usr/powerpc64le-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=powerpc64le-unknown-linux-gnu
--with-ld=/usr/bin/powerpc64le-unknown-linux-gnu-ld
--with-as=/usr/bin/powerpc64le-unknown-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-269602-checking-yes-rtl-df-extra-powerpc64le
Thread model: posix
gcc version 9.0.1 20190312 (experimental) (GCC)

[Bug fortran/89646] Spurious actual argument might interfere warning

2019-03-12 Thread ian_harvey at bigpond dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89646

--- Comment #2 from Ian Harvey  ---
The spurious warning is issued regardless of whether warnings are requested or
not (i.e. it is reported with a command line of just `gfortran -c file.f90`). 
The warning is issued even if -Wno-aliasing is explicitly provided.

[Bug middle-end/89677] [8 Regression] internal compiler error: in wide_int_to_tree_1, at tree.c:1549

2019-03-12 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89677

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-12
 CC||jakub at gcc dot gnu.org
  Known to work||7.3.0, 9.0
   Target Milestone|--- |8.4
Summary|internal compiler error: in |[8 Regression] internal
   |wide_int_to_tree_1, at  |compiler error: in
   |tree.c:1549 |wide_int_to_tree_1, at
   ||tree.c:1549
 Ever confirmed|0   |1
  Known to fail||8.3.0

--- Comment #1 from Jakub Jelinek  ---
Started to ICE with r247048.
This got fixed or made latent with r266956 on the trunk.
Slightly cleaned up testcase:
int a, b, d;
unsigned c;
float e, f, g;
void
foo (void)
{
  float *i = 
  for (; c < 10; c += 3)
for (; d; d += 3)
  {
a = *i;
g = f + 0;
f = b + *i + (b - e + 305219) + -b + 3;
  }
}

[Bug middle-end/89677] [8 Regression] internal compiler error: in wide_int_to_tree_1, at tree.c:1549

2019-03-12 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89677

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c/89678] New: Bogus -Wstringop-truncation error

2019-03-12 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89678

Bug ID: 89678
   Summary: Bogus -Wstringop-truncation error
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

I see following isolated from bctoolbox package:

$ cat log.c
#include 
#include 

char *bctbx_strcat_vprintf(char *dst, char *ret) {
  size_t dstlen, retlen;

  if (!dst)
return ret;

  dstlen = strlen(dst);
  retlen = strlen(ret);

  if ((dst = __builtin_realloc(dst, dstlen + retlen + 1)) != 0) {
strncat(dst, ret, retlen);
dst[dstlen + retlen] = '\0';
return dst;
  } else {
return 0;
  }
}

char *a;
char *b;

int main(int argc, char **argv) {
  a = malloc(10);
  b = malloc(10);

  if (argc) {
strcpy(a, "one");
strcpy(b, "two");
  }

  __builtin_printf(bctbx_strcat_vprintf(a, b));
  return 0;
}

$ gcc log.c -c -O2 -Wstringop-truncation
log.c: In function ‘bctbx_strcat_vprintf.part.0’:
log.c:14:5: warning: ‘strncat’ output truncated before terminating nul copying
as many bytes from a string as its length [-Wstringop-truncation]
   14 | strncat(dst, ret, retlen);
  | ^
log.c:11:12: note: length computed here
   11 |   retlen = strlen(ret);
  |^~~

[Bug rtl-optimization/89676] [7/8/9 Regression] Redundant moves for long long shift on 32bit x86

2019-03-12 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89676

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |7.5
Summary|Redundant moves for long|[7/8/9 Regression]
   |long shift on 32bit x86 |Redundant moves for long
   ||long shift on 32bit x86

--- Comment #2 from Jakub Jelinek  ---
Started with r244942 (at least with -O2 -m32 -fomit-frame-pointer), before that
we emitted
foo:
movl4(%esp), %eax
movl8(%esp), %edx
shldl   $3, %eax, %edx
sall$3, %eax
ret

[Bug rtl-optimization/89676] Redundant moves for long long shift on 32bit x86

2019-03-12 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89676

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-12
 CC||jakub at gcc dot gnu.org,
   ||vmakarov at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Indeed, we have:
(insn 14 3 6 2 (set (reg/v:DI 83 [ i ])
(mem/c:DI (reg/f:SI 16 argp) [1 i+0 S8 A32])) "pr89676.c":4:12 66
{*movdi_internal}
 (expr_list:REG_EQUIV (mem/c:DI (reg/f:SI 16 argp) [1 i+0 S8 A32])
(nil)))
(insn 6 14 11 2 (parallel [
(set (reg:DI 84)
(ashift:DI (reg/v:DI 83 [ i ])
(const_int 3 [0x3])))
(clobber (reg:CC 17 flags))
]) "pr89676.c":4:12 509 {*ashldi3_doubleword}
 (expr_list:REG_DEAD (reg/v:DI 83 [ i ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
(insn 11 6 12 2 (set (reg/i:DI 0 ax)
(reg:DI 84)) "pr89676.c":5:1 66 {*movdi_internal}
 (expr_list:REG_DEAD (reg:DI 84)
(nil)))
and the important insn has:
(define_insn "*ashl3_doubleword"
  [(set (match_operand:DWI 0 "register_operand" "=")
(ashift:DWI (match_operand:DWI 1 "reg_or_pm1_operand" "0n")
(match_operand:QI 2 "nonmemory_operand" "c")))
   (clobber (reg:CC FLAGS_REG))]
constraints, IRA decides:
Pass 0 for finding pseudo/allocno costs

a0 (r84,l0) best AD_REGS, allocno AD_REGS
a1 (r83,l0) best GENERAL_REGS, allocno GENERAL_REGS

  a0(r84,l0) costs: AD_REGS:-1000,-1000 CLOBBERED_REGS:2000,2000
Q_REGS:2000,2000 NON_Q_REGS:2000,2000 TLS_GOTBASE_REGS:2000,2000
GENERAL_REGS:2000
,2000 MEM:24000,24000
  a1(r83,l0) costs: AD_REGS:0,0 CLOBBERED_REGS:0,0 Q_REGS:0,0 NON_Q_REGS:0,0
TLS_GOTBASE_REGS:0,0 GENERAL_REGS:0,0 MEM:0,0


Pass 1 for finding pseudo/allocno costs

r84: preferred AD_REGS, alternative GENERAL_REGS, allocno GENERAL_REGS
r83: preferred GENERAL_REGS, alternative NO_REGS, allocno GENERAL_REGS

  a0(r84,l0) costs: AD_REGS:2000,-1000 CLOBBERED_REGS:2000,2000
Q_REGS:2000,2000 NON_Q_REGS:4000,4000 TLS_GOTBASE_REGS:2000,2000
GENERAL_REGS:2000,
2000 MEM:36000,36000
  a1(r83,l0) costs: GENERAL_REGS:0,0 MEM:0,0

Disposition:
1:r83  l0 00:r84  l0 0

which I believe is to put both pseudo 83 and 84 into DImode eax.

LRA dump has:
** Assignment #1: **

Spill r83 after risky transformations
  Reassigning non-reload pseudos
   Assign 2 to r83 (freq=2000)
is that when it decides to put pseudo 83 into DImode %ecx instead?
If yes, what kind of risky transformation was here and why?

Vlad, can you please have a look?  Thanks.

[Bug middle-end/89677] New: internal compiler error: in wide_int_to_tree_1, at tree.c:1549

2019-03-12 Thread konstantin.vladimirov at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89677

Bug ID: 89677
   Summary: internal compiler error: in wide_int_to_tree_1, at
tree.c:1549
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: konstantin.vladimirov at gmail dot com
  Target Milestone: ---

Reproduction after creduce:

---
a, b, d;
unsigned c;
float e, f, g;
h() {
  float *i = 
  for (; c < 10; c += 3)
for (; d; d += 3) {
  a = *i;
  g = f + 0;
  f = b + *i + (b - e + 305219) + -b + 3;
}
}
---

Compiler information:

---
> gcc -v
Reading specs from
/apps/gcc/8.1.0/.bin/../lib64/gcc/x86_64-suse-linux/8.1.0/specs
COLLECT_GCC=/apps/gcc/8.1.0/.bin/gcc
COLLECT_LTO_WRAPPER=/apps/gcc/8.1.0/.bin/../libexec/gcc/x86_64-suse-linux/8.1.0/lto-wrapper
Target: x86_64-suse-linux
Configured with: ./configure --prefix=/apps/gcc/8.1.0
--libdir=/apps/gcc/8.1.0/lib64 --libexecdir=/apps/gcc/8.1.0/libexec
--bindir=/apps/gcc/8.1.0/bin --with-isl=/apps/gcc/8.1.0
--with-libelf=/apps/gcc/8.1.0 --with-mpfr=/apps/gcc/8.1.0
--with-gmp=/apps/gcc/8.1.0 --with-mpc=/apps/gcc/8.1.0
--disable-gnu-unique-object --enable-gold=yes --enable-lto
--enable-languages=c,c++,objc,fortran --build=x86_64-suse-linux
--host=x86_64-suse-linux --target=x86_64-suse-linux --enable-libotm
--disable-multilib --disable-bootstrap --disable-libstdcxx-pch
Thread model: posix
gcc version 8.1.0 (GCC)
---

Compile with:

> gcc -w -O1 minimize.c -S

You will see:

---
during GIMPLE pass: cunroll
minimize.c: In function ‘h’:
minimize.c:4:1: internal compiler error: in wide_int_to_tree_1, at tree.c:1549
 h() {
 ^
0x620ba8 ???
../sysdeps/x86_64/elf/start.S:113
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
---

[Bug translation/40883] [meta-bug] Translation breakage with trivial fixes

2019-03-12 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883
Bug 40883 depends on bug 52726, which changed state.

Bug 52726 Summary: Composed error message will not get translated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52726

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

[Bug target/52726] Composed error message will not get translated

2019-03-12 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52726

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Fixed.

[Bug target/52726] Composed error message will not get translated

2019-03-12 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52726

--- Comment #1 from Jakub Jelinek  ---
Author: jakub
Date: Tue Mar 12 10:07:25 2019
New Revision: 269607

URL: https://gcc.gnu.org/viewcvs?rev=269607=gcc=rev
Log:
PR target/52726
* config/s390/s390.md (tabort): Use %wd instead of
HOST_WIDE_INT_PRINT_DEC in error message, reword to avoid two capital
letters and periods.
* config/tilepro/tilepro.c (tilepro_print_operand): Use %wd in
output_operand_lossage instead of HOST_WIDE_INT_PRINT_DEC, replace
's with %< and %>.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/s390/s390.md
trunk/gcc/config/tilepro/tilepro.c

[Bug target/42689] bad formatting of specs diagnostics

2019-03-12 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42689

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
I don't see any such issues on the current trunk:
sed -n 's/^.*\(Warn\|MissingArgError\)(\(.*\))$/\2/p' *.opt */*.opt */*/*.opt
2>/dev/null | sort -u
assertion missing after %qs
{-fhandle-exceptions has been renamed -fexceptions (and is now on by default)}
macro name missing after %qs
%<-mcpu=%> is deprecated; use %<-mtune=%> or %<-march=%> instead
%<-mfused-madd%> is deprecated; use %<-ffp-contract=%> instead
%<-mintel-syntax%> and %<-mno-intel-syntax%> are deprecated; use
%<-masm=intel%> and %<-masm=att%> instead
missing device or architecture after %qs
missing filename after %qs
missing makefile target after %qs
missing path after %qs
%<-msse5%> was removed
%<-mvrsave=no%> is deprecated; use %<-mno-vrsave%> instead
%<-mvrsave=yes%> is deprecated; use %<-mvrsave%> instead
no class name specified with %qs
options or targets missing after %qs
%qs is deprecated
%qs is deprecated; use -fno-zero-initialized-in-bss
%qs is deprecated; use -fstack-check
using old darwin ABI) Var(rs6000_darwin64_abi, 0

[Bug translation/40883] [meta-bug] Translation breakage with trivial fixes

2019-03-12 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883
Bug 40883 depends on bug 42689, which changed state.

Bug 42689 Summary: bad formatting of specs diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42689

   What|Removed |Added

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

[Bug target/79924] aarch64: untranslated diagnostics in aarch64_err_no_fpadvsimd

2019-03-12 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79924

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Assuming this is fixed.

[Bug translation/40883] [meta-bug] Translation breakage with trivial fixes

2019-03-12 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883
Bug 40883 depends on bug 79924, which changed state.

Bug 79924 Summary: aarch64: untranslated diagnostics in aarch64_err_no_fpadvsimd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79924

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

[Bug target/81879] An undefined symbol put into final LTO when using -static on mingw target

2019-03-12 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81879

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |MOVED

--- Comment #7 from Martin Liška  ---
Closing as it's binutils issue.

[Bug rtl-optimization/89676] New: Redundant moves for long long shift on 32bit x86

2019-03-12 Thread ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89676

Bug ID: 89676
   Summary: Redundant moves for long long shift on 32bit x86
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ubizjak at gmail dot com
  Target Milestone: ---

Following testcase:

--cut here--
unsigned long long
foo (unsigned long long i)
{
  return i << 3;
}
--cut here--

compiles for 32bit x86 to (-O2):

pushl   %ebx
movl8(%esp), %ecx
movl12(%esp), %ebx
movl%ecx, %eax
movl%ebx, %edx
popl%ebx
shldl   $3, %eax, %edx
sall$3, %eax
ret

There is unnecessary move to %ecx/%ebx pair in the above code.

Clang creates:

movl4(%esp), %eax
movl8(%esp), %edx
shldl   $3, %eax, %edx
shll$3, %eax
retl

[Bug rtl-optimization/89654] [8/9 Regression] Invalid reload with -march=skylake -m32

2019-03-12 Thread ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89654

--- Comment #6 from Uroš Bizjak  ---
(In reply to H.J. Lu from comment #4)
> Is this a dup of PR 69693?

Yes, indeed. The issue with too many moves remain, I'll open a new PR for that.

  1   2   >