[Bug target/91851] New: [m68k] Convert the backend to MODE_CC so it can be kept in future releases

2019-09-21 Thread glaubitz at physik dot fu-berlin.de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91851

Bug ID: 91851
   Summary: [m68k] Convert the backend to MODE_CC so it can be
kept in future releases
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glaubitz at physik dot fu-berlin.de
CC: burnus at gcc dot gnu.org, jason.duerstock at gmail dot com,
jrtc27 at jrtc27 dot com, law at redhat dot com,
sch...@linux-m68k.org
  Target Milestone: ---
  Host: m68k-*-*

This is a tracker bug for the convert the m68k backend from CC0 to MODE_CC so
it can be kept in future releases.

See: https://gcc.gnu.org/wiki/CC0Transition

I will be using this bug report to create a bounty on BountySource.com.

[Bug target/91269] [9/10 regression] unaligned floating-point register with -mcpu=niagara4 -fcall-used-g6

2019-09-21 Thread ebotcazou at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91269

--- Comment #16 from Eric Botcazou  ---
> I believe the Known to work field is wrong and gcc-8.3.0 has this bug as
> well.

No, the field is correct and you're wrong.

[Bug target/91269] [9/10 regression] unaligned floating-point register with -mcpu=niagara4 -fcall-used-g6

2019-09-21 Thread slyfox at inbox dot ru 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91269

--- Comment #17 from Sergei Trofimovich  ---
Created attachment 46906
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46906&action=edit
bug-lz4-8.3.0.c

Here is a bug-lz4-8.3.0.c that exposes suspiciously similar failure on sparc64
gcc-8.3.0 on lz4-1.8.3 package:

  $ LANG=C sparc64-unknown-linux-gnu-gcc-8.3.0 -O2 -pipe -mcpu=niagara4 -fPIC
-c bug-lz4-8.3.0.c -o bug-lz4-8.3.0.o

  {standard input}: Assembler messages:
  {standard input}:365: Error: Illegal operands

[Bug fortran/91588] ICE in check_inquiry, at fortran/expr.c:2673

2019-09-21 Thread pault at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91588

--- Comment #5 from Paul Thomas  ---
Author: pault
Date: Sat Sep 21 08:35:17 2019
New Revision: 276016

URL: https://gcc.gnu.org/viewcvs?rev=276016&root=gcc&view=rev
Log:
2019-09-21  Paul Thomas  

Backport from mainline
PR fortran/91588
* expr.c (check_inquiry): Remove extended component refs by
using symbol pointers. If a function argument is an associate
variable with a constant target, copy the target expression in
place of the argument expression. Check that the charlen is not
NULL before using the string length.

2019-09-21  Paul Thomas  

Backport from mainline
PR fortran/91588
* gfortran.dg/associate_49.f90 : New test.


Added:
branches/gcc-9-branch/gcc/testsuite/gfortran.dg/associate_49.f90
Modified:
branches/gcc-9-branch/gcc/fortran/ChangeLog
branches/gcc-9-branch/gcc/fortran/expr.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog

[Bug c/91852] New: Compile the code with -O0 is slower than with -O1/-O2/-O3

2019-09-21 Thread hehaochen at hotmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91852

Bug ID: 91852
   Summary: Compile the code with -O0 is slower than with
-O1/-O2/-O3
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hehaochen at hotmail dot com
  Target Milestone: ---

Compile the following code with -O0 is slower than with -O1/-O2/-O3 :

-O1 applies some optimization on execution time and binary size, I expected
using -O1 takes more time than -O0. So is there something wrong with -O0 in
this case?


 class c {
public:
c() {}
};

class a {
c array[50] {};
};

int main() {
a t;
}


root@72c6552d0d56:/# gcc --version
gcc (GCC) 8.3.0
Copyright (C) 2018 Free Software Foundation, Inc.

root@72c6552d0d56:/downloads# time gcc -std=c++14 -O0 -Wall a.cc

real1m14.121s   SLOW 
user1m7.966s
sys 0m5.948s

root@72c6552d0d56:/downloads# time gcc -std=c++14 -O1 -Wall a.cc

real0m26.268s
user0m23.591s
sys 0m2.657s

root@72c6552d0d56:/downloads# time gcc -std=c++14 -O2 -Wall a.cc

real0m26.413s
user0m23.704s
sys 0m2.708s

root@72c6552d0d56:/downloads# time gcc -std=c++14 -O3 -Wall a.cc

real0m26.553s
user0m23.874s
sys 0m2.678s

The result is nearly same in
gcc-9.2.0
gcc-7.3.0
gcc-6.5.0

The root cause lies in "phase opt and generate" in -ftime-report

The problem falls on '-O1' in older version: (gcc-4.8.5 gcc-5.4.0)

 class c {
public:
c() {}
};

class a {
// As described in bug 77443:
// compile time grows super-linearly in (gcc-4.8.5 gcc-5.4.0)
c array[3] {};
};

int main() {
a t;
}

# time gcc -O0 -std=c++11 -Wall a.cc
1.25s user 0.22s system 99% cpu 1.464 total

# time gcc -O1 -std=c++11 -Wall a.cc
7.93s user 0.16s system 99% cpu 8.089 total

# time gcc -O2 -std=c++11 -Wall a.cc
7.94s user 0.15s system 99% cpu 8.097 total

# time gcc -O3 -std=c++11 -Wall a.cc
7.92s user 0.18s system 99% cpu 8.095 total

In gcc-5.4.0
-O0: 0m1.834s
-O1: 0m5.467s
-O2: 0m5.407s

[Bug target/91269] [9/10 regression] unaligned floating-point register with -mcpu=niagara4 -fcall-used-g6

2019-09-21 Thread ebotcazou at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91269

--- Comment #18 from Eric Botcazou  ---
> Here is a bug-lz4-8.3.0.c that exposes suspiciously similar failure on
> sparc64 gcc-8.3.0 on lz4-1.8.3 package:

Please open a new PR with the appropriate information, this one is closed.

[Bug target/91841] vector_size(8) passes MMX register without emms cleanup

2019-09-21 Thread ubizjak at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91841

Uroš Bizjak  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #5 from Uroš Bizjak  ---
(In reply to Matthias Kretz from comment #4)
> (In reply to Uroš Bizjak from comment #3)
> > [f]emms should be emitted by an intrinsic (_mm_empty), inserted by the
> > programmer. The programmer can mix FP and MMX instructions in the same
> > function, so there is no way for compiler to automatically emit emms.
> 
> But that was my original point. In #0 the programmer did not mix FP and MMX
> instructions, only float and ushort [[gnu::vector_size(8)]] (which isn't
> even the same type as __m64) operations. The compiler did it. ;-) In that
> case, I understand 2.2.1 p3 as a requirement on the compiler. I sure agree
> that the use of MMX intrinsics puts the responsibility with the developer,
> but use of vector_size(8)?

Hm, ICC is of no help here, as it ignores attribute:

f(unsigned short):
push  rbp   #6.28
mov   rbp, rsp  #6.28
sub   rsp, 16   #6.28
mov   WORD PTR [-16+rbp], di#6.28
movzx eax, WORD PTR [-16+rbp]   #6.37
leave   #6.37
ret #6.37

Let's ask ABI expert about this.

> > Obviously, when the function returns value in %mm0 register (or in %fp),
> > emms should not be inserted at function exit.
> 
> Right. Does that mean you agree the ABI document is contradicting itself?

Yes, unfortunately.

[Bug tree-optimization/91837] Wrong code with -ftree-loop-vectorize and -march=skylake-avx512 on some Intel machines

2019-09-21 Thread dan.cooke89 at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91837

--- Comment #5 from Daniel Cooke  ---
(In reply to H.J. Lu from comment #4)
> (In reply to Daniel Cooke from comment #3)
> > I tried replicating the issue on a CentOS machine (AWS EC2) with the exact
> > same CPU and got the correct output. However, I just fired up a fresh AWS
> > EC2 instance running Ubuntu and I can replicate the bug again. Is it
> > possible that the bug is CPU *and* OS specific?
> 
> You may run into
> 
> https://sourceware.org/bugzilla/show_bug.cgi?id=23465

It does seem like this could be the issue. I upgraded my binutils to 2.32 (from
2.30) and the problem disappears. I'll do some more testing and report back.

[Bug ipa/91853] New: [10 Regression] ICE in gimplify_modify_expr, at gimplify.c:5902 since r275982

2019-09-21 Thread marxin at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91853

Bug ID: 91853
   Summary: [10 Regression] ICE in gimplify_modify_expr, at
gimplify.c:5902 since r275982
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: jamborm at gcc dot gnu.org, marxin at gcc dot gnu.org
  Target Milestone: ---

Following is causing ICE:

$ gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr60647-1.c --param
ipa-cp-value-list-size=0 -Os -fno-inline
during IPA pass: inline
In function ‘fn3.constprop.isra’:
cc1: internal compiler error: in gimplify_modify_expr, at gimplify.c:5902
0x655a38 gimplify_modify_expr
/home/marxin/Programming/gcc/gcc/gimplify.c:5902
0xb1d1f8 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/marxin/Programming/gcc/gcc/gimplify.c:13136
0xb20cf6 gimplify_stmt(tree_node**, gimple**)
/home/marxin/Programming/gcc/gcc/gimplify.c:6780
0xb2337f gimplify_and_add(tree_node*, gimple**)
/home/marxin/Programming/gcc/gcc/gimplify.c:480
0xb2337f internal_get_tmp_var
/home/marxin/Programming/gcc/gcc/gimplify.c:636
0xb2363a get_initialized_tmp_var(tree_node*, gimple**, gimple**, bool)
/home/marxin/Programming/gcc/gcc/gimplify.c:667
0xb2363a prepare_gimple_addressable
/home/marxin/Programming/gcc/gcc/gimplify.c:4278
0xb25a0b gimplify_addr_expr
/home/marxin/Programming/gcc/gcc/gimplify.c:6144
0xb1df2a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/marxin/Programming/gcc/gcc/gimplify.c:13183
0xb3bf9d force_gimple_operand_1(tree_node*, gimple**, bool (*)(tree_node*),
tree_node*)
/home/marxin/Programming/gcc/gcc/gimplify-me.c:78
0xb3c04f force_gimple_operand_gsi_1(gimple_stmt_iterator*, tree_node*, bool
(*)(tree_node*), tree_node*, bool, gsi_iterator_update)
/home/marxin/Programming/gcc/gcc/gimplify-me.c:115
0xbd42a4 ipa_param_adjustments::modify_call(gcall*,
vec*, tree_node*, bool)
/home/marxin/Programming/gcc/gcc/ipa-param-manipulation.c:724
0x983814 cgraph_edge::redirect_call_stmt_to_callee()
/home/marxin/Programming/gcc/gcc/cgraph.c:1380
0x16bf764 inline_transform(cgraph_node*)
/home/marxin/Programming/gcc/gcc/ipa-inline-transform.c:684
0xcdfd9a execute_one_ipa_transform_pass
/home/marxin/Programming/gcc/gcc/passes.c:2231
0xcdfd9a execute_all_ipa_transforms(bool)
/home/marxin/Programming/gcc/gcc/passes.c:2270
0x98c431 cgraph_node::expand()
/home/marxin/Programming/gcc/gcc/cgraphunit.c:2187
0x98d40b expand_all_functions
/home/marxin/Programming/gcc/gcc/cgraphunit.c:2332
0x98d40b symbol_table::compile()
/home/marxin/Programming/gcc/gcc/cgraphunit.c:2688
0x98fc4c symbol_table::compile()
/home/marxin/Programming/gcc/gcc/cgraphunit.c:2595
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Similarly here:
$ gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr60647-2.c -fipa-sra
-Og
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr60647-2.c: In function
‘bar’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr60647-2.c:21:4: warning:
function called through a non-compatible type
   21 |   ((void (*) (void *, int, int)) foo) ((void *) 0, winInfo, 0);  /* {
dg-warning "function called through a non-compatible type" } */
  |   ~^~
during IPA pass: inline
In function ‘bar.isra’:
cc1: internal compiler error: in gimplify_modify_expr, at gimplify.c:5902
0x655a38 gimplify_modify_expr
/home/marxin/Programming/gcc/gcc/gimplify.c:5902
0xb1d1f8 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/marxin/Programming/gcc/gcc/gimplify.c:13136
0xb20cf6 gimplify_stmt(tree_node**, gimple**)
/home/marxin/Programming/gcc/gcc/gimplify.c:6780
0xb2337f gimplify_and_add(tree_node*, gimple**)
/home/marxin/Programming/gcc/gcc/gimplify.c:480
0xb2337f internal_get_tmp_var
/home/marxin/Programming/gcc/gcc/gimplify.c:636
0xb2363a get_initialized_tmp_var(tree_node*, gimple**, gimple**, bool)
/home/marxin/Programming/gcc/gcc/gimplify.c:667
0xb2363a prepare_gimple_addressable
/home/marxin/Programming/gcc/gcc/gimplify.c:4278
0xb25a0b gimplify_addr_expr
/home/marxin/Programming/gcc/gcc/gimplify.c:6144
0xb1df2a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/marxin/Programming/gcc/gcc/gimplify.c:13183
0xb3bf9d force_gimple_operand_1(tree_node*, gimple**, bool (*)(tree_node*),
tree_node*)
/home/marxin/Programming/gcc/gcc/gimplify-me.c:78
0xb3c04f

[Bug ipa/91853] [10 Regression] ICE in gimplify_modify_expr, at gimplify.c:5902 since r275982

2019-09-21 Thread marxin at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91853

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-21
  Known to work||9.2.0
Version|9.0 |10.0
   Target Milestone|--- |10.0
 Ever confirmed|0   |1
  Known to fail||10.0

[Bug ipa/91836] [10 Regression] Speed regression of 525.x264_r with -Ofast -march=native since r275982

2019-09-21 Thread marxin at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91836

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed|2019-09-20 00:00:00 |2019-09-21
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug c/91854] New: gcc-8.3.0 generates invalid assembly on lz4-1.8.3: Assembler messages: Error: Illegal operands (-mcpu=niagara4 -fPIC)

2019-09-21 Thread slyfox at inbox dot ru 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91854

Bug ID: 91854
   Summary: gcc-8.3.0 generates invalid assembly on lz4-1.8.3:
Assembler messages: Error: Illegal operands
(-mcpu=niagara4 -fPIC)
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at inbox dot ru
  Target Milestone: ---

The bug looks similar to bug #91269 but Eric Botcazou suggests to consider it a
separate bug.

lz4-1.8.3 triggers assembler errors for sparc64-unknown-linux-gnu gcc-8.3.0
(and others).

Here are a few versions attempted:

8.3.0:

$ /home/slyfox/dev/git/gcc-sparc64/gcc/xgcc
-B/home/slyfox/dev/git/gcc-sparc64/gcc -O2 -pipe -fPIC -mcpu=niagara4 -c
bug.orig.c -o bug.o
{standard input}: Assembler messages:
{standard input}:10435: Error: Illegal operands
{standard input}:10686: Error: Illegal operands

$ /home/slyfox/dev/git/gcc-sparc64/gcc/xgcc
-B/home/slyfox/dev/git/gcc-sparc64/gcc -v
Reading specs from /home/slyfox/dev/git/gcc-sparc64/gcc/specs
COLLECT_GCC=/home/slyfox/dev/git/gcc-sparc64/gcc/xgcc
COLLECT_LTO_WRAPPER=/home/slyfox/dev/git/gcc-sparc64/gcc/lto-wrapper
Target: sparc64-unknown-linux-gnu
Configured with: ../gcc/configure --target=sparc64-unknown-linux-gnu
--with-sysroot=/usr/sparc64-unknown-linux-gnu --enable-languages=c
--disable-bootstrap
--prefix=/home/slyfox/dev/git/gcc-sparc64/../gcc-sparc64-installed
--disable-multilib cross_compiling=yes
Thread model: posix
gcc version 8.3.0 (GCC)

8-branch:

$ /home/slyfox/dev/git/gcc-sparc64/gcc/xgcc
-B/home/slyfox/dev/git/gcc-sparc64/gcc -O2 -pipe -fPIC -mcpu=niagara4 -c
bug.orig.c -o bug.o
{standard input}: Assembler messages:
{standard input}:10401: Error: Illegal operands
{standard input}:10652: Error: Illegal operands

$ /home/slyfox/dev/git/gcc-sparc64/gcc/xgcc
-B/home/slyfox/dev/git/gcc-sparc64/gcc -v
Reading specs from /home/slyfox/dev/git/gcc-sparc64/gcc/specs
COLLECT_GCC=/home/slyfox/dev/git/gcc-sparc64/gcc/xgcc
COLLECT_LTO_WRAPPER=/home/slyfox/dev/git/gcc-sparc64/gcc/lto-wrapper
Target: sparc64-unknown-linux-gnu
Configured with: ../gcc/configure --target=sparc64-unknown-linux-gnu
--with-sysroot=/usr/sparc64-unknown-linux-gnu --enable-languages=c
--disable-bootstrap
--prefix=/home/slyfox/dev/git/gcc-sparc64/../gcc-sparc64-installed
--disable-multilib cross_compiling=yes
Thread model: posix
gcc version 8.3.1 20190920 (GCC)

[Bug c/91854] gcc-8.3.0 generates invalid assembly on lz4-1.8.3: Assembler messages: Error: Illegal operands (-mcpu=niagara4 -fPIC)

2019-09-21 Thread slyfox at inbox dot ru 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91854

--- Comment #1 from Sergei Trofimovich  ---
Created attachment 46907
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46907&action=edit
bug.orig.c

bug.orig.c is a selfcontained example.

"{standard input}:10401: Error: Illegal operands" points to double store for
odd register (invalid):
std%f27, [%fp+1943]

[Bug c/91854] gcc-8.3.0 generates invalid assembly on lz4-1.8.3: Assembler messages: Error: Illegal operands (-mcpu=niagara4 -fPIC)

2019-09-21 Thread slyfox at inbox dot ru 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91854

Sergei Trofimovich  changed:

   What|Removed |Added

 CC||davem at redhat dot com,
   ||ebotcazou at libertysurf dot fr

--- Comment #2 from Sergei Trofimovich  ---
CCing sparc maintainers.

[Bug target/91269] [9/10 regression] unaligned floating-point register with -mcpu=niagara4 -fcall-used-g6

2019-09-21 Thread slyfox at inbox dot ru 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91269

--- Comment #19 from Sergei Trofimovich  ---
(In reply to Eric Botcazou from comment #18)
> > Here is a bug-lz4-8.3.0.c that exposes suspiciously similar failure on
> > sparc64 gcc-8.3.0 on lz4-1.8.3 package:
> 
> Please open a new PR with the appropriate information, this one is closed.

Sounds good. Filed bug #91854.

[Bug c/91854] gcc-8.3.0 generates invalid assembly on lz4-1.8.3: Assembler messages: Error: Illegal operands (-mcpu=niagara4 -fPIC)

2019-09-21 Thread slyfox at inbox dot ru 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91854

--- Comment #3 from Sergei Trofimovich  ---
Created attachment 46908
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46908&action=edit
bug-min-against-8.3.0.c

While original sample fails both against 8.3.0 and 9.2.0 this distilled example
fails only on gcc-8.3.0 and gcc-8-branch:

$ LANG=C /home/slyfox/dev/git/gcc-sparc64/gcc/xgcc
-B/home/slyfox/dev/git/gcc-sparc64/gcc -O2 -pipe -fPIC -mcpu=niagara4 -c
bug-min-against-8.3.0.c -o bug.o
...
{standard input}: Assembler messages:
{standard input}:402: Error: Illegal operands

[Bug c++/91844] Implement CWG 2352, Similar types and reference binding

2019-09-21 Thread mpolacek at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91844

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-21
 Ever confirmed|0   |1

[Bug c++/91844] Implement CWG 2352, Similar types and reference binding

2019-09-21 Thread mpolacek at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91844

--- Comment #1 from Marek Polacek  ---
As a consequence, this program will become invalid:

int &f (const int *&&);

void
fn (int *p)
{
  const int *&&r = p;
  f (p);
}

With this DR, "const int *" and "int *" are reference-related, and 5.4.4. says
that in that case, if the reference is an rvalue reference, the initializer
expression shall not be an lvalue.

[Bug libstdc++/78237] std::timed_mutex::try_lock_for/until affected by system realtime clock

2019-09-21 Thread mac at mcrowe dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78237

Mike Crowe  changed:

   What|Removed |Added

 CC||mac at mcrowe dot com

--- Comment #1 from Mike Crowe  ---
The fix for this is similar to the fix for 41861 if the new
pthread_mutex_clockwait function is used from glibc 2.30.

std::shared_timed_mutex is afflicted similarly and can be fixed with
pthread_rwlock_clockrdlock and pthread_rwlock_clockwrlock.

I'm working on fixes for both, but don't appear to have the required Bugzilla
privileges to assign this bug to me. :(

[Bug lto/83452] FAIL: gfortran.dg/save_6.f90 -O0 (test for excess errors)

2019-09-21 Thread dimitar.yordanov at sap dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83452

dimitar.yordanov at sap dot com changed:

   What|Removed |Added

 CC||dimitar.yordanov at sap dot com

--- Comment #15 from dimitar.yordanov at sap dot com ---
Hi,

after this fix I see.debug_info entries in the .symtab, which seem unneeded to
me(on Linux x86_64). If they are unnecessary should they be removed by the
linker or the plugin? Is the fix in this patch only needed for HPUX, because of
misbehaving linker?


cat > foo.c << EOF
const char *a = "a";
EOF

g++ -flto -gdwarf-4 -g1 -o foo.c.o -c foo.c
g++ -flto -shared -o libfoo.so foo.c.o
objdump -t libfoo.so | grep debug_info

Best wishes,
D.

[Bug c++/30277] bit-field: wrong overload resolution

2019-09-21 Thread jakub at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30277

--- Comment #9 from Jakub Jelinek  ---
Author: jakub
Date: Sat Sep 21 21:54:38 2019
New Revision: 276021

URL: https://gcc.gnu.org/viewcvs?rev=276021&root=gcc&view=rev
Log:
PR c++/30277
* g++.dg/expr/bitfield14.C (struct S): Use signed long long instead
of signed long.
(foo): Use long long instead of long.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/expr/bitfield14.C

[Bug tree-optimization/91830] [10 Regression] Bogus -Warray-bounds on strcpy into a member of a subobject compiling binutils

2019-09-21 Thread msebor at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91830

--- Comment #7 from Martin Sebor  ---
Author: msebor
Date: Sat Sep 21 22:32:59 2019
New Revision: 276022

URL: https://gcc.gnu.org/viewcvs?rev=276022&root=gcc&view=rev
Log:
PR middle-end/91830 - Bogus -Warray-bounds on strcpy into a member
of a subobject compiling binutils

gcc/ChangeLog:
* gcc/gimple-ssa-warn-restrict.c (builtin_memref::set_base_and_offset):
Simplify computation of the offset of the referenced subobject.

gcc/testsuite/ChangeLog:
* gcc/testsuite/gcc.dg/Warray-bounds-47.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/Warray-bounds-47.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-warn-restrict.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds

2019-09-21 Thread msebor at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
Bug 56456 depends on bug 91830, which changed state.

Bug 91830 Summary: [10 Regression] Bogus -Warray-bounds on strcpy into a member 
of a subobject compiling binutils
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91830

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug tree-optimization/91830] [10 Regression] Bogus -Warray-bounds on strcpy into a member of a subobject compiling binutils

2019-09-21 Thread msebor at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91830

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Martin Sebor  ---
Fixed in r276022.

[Bug target/82920] cet test failures on darwin

2019-09-21 Thread iains at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82920

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #20 from Iain Sandoe  ---
it seems some (or related) fails are also present on 7 branch.

[Bug tree-optimization/91570] [10 Regression] ICE in get_range_strlen_dynamic on a conditional of two strings

2019-09-21 Thread msebor at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91570

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #3 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01304.html

[Bug fortran/49566] [DWARF/DEBUG] Add coarray shapes (codimensions) to the debug output

2019-09-21 Thread egallager at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49566

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #3 from Eric Gallager  ---
(In reply to Tobias Burnus from comment #2)
> (In reply to Dominique d'Humieres from comment #1)
> > Any progress?
> 
> Yes - they are part of DWARF 5, unfortunately, the draft is not yet publicly
> available.

How about now?

[Bug fortran/44882] Bogus types in references with mismatched commons

2019-09-21 Thread egallager at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44882

--- Comment #21 from Eric Gallager  ---
(In reply to Eric Gallager from comment #20)
> 
> ...so does this bug still need to be marked as WAITING then?

Update: guess not