[Bug bootstrap/90544] Build failure on MINGW for gcc-9.1.0

2019-06-03 Thread master at a1983 dot com.cn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90544

Kuang  changed:

   What|Removed |Added

 CC||master at a1983 dot com.cn

--- Comment #2 from Kuang  ---
Same problem when cross compiling for windows on Ubuntu with
x86_64-w64-mingw32-gcc (9.1.0)

[Bug target/90721] [Bug] ./gcc.dg/torture/stackalign/builtin-apply-4.c test case getting fail

2019-06-03 Thread akhilesh.k at samsung dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90721

--- Comment #1 from Akhilesh Kumar  ---
One more observation same test case getting PASS on x86 

root@akhilesh-ubuntu:/home/akhilesh.k/gcc-arm-src-snapshot-8.3-2019.03/gcc/testsuite#
gcc ./gcc.dg/torture/stackalign/builtin-apply-4.c -flto -fgnu89-inline -lm -o
builtin-apply-4.exe
root@akhilesh-ubuntu:/home/akhilesh.k/gcc-arm-src-snapshot-8.3-2019.03/gcc/testsuite#
./builtin-apply-4.exe
root@akhilesh-ubuntu:/home/akhilesh.k/gcc-arm-src-snapshot-8.3-2019.03/gcc/testsuite#

[Bug target/90689] [10 Regression] ICE in extract_insn, at recog.c:2310 on ppc64le

2019-06-03 Thread amodra at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90689

Alan Modra  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC|amodra at gcc dot gnu.org, |
   |amodra at gmail dot com|
 Resolution|--- |FIXED

--- Comment #7 from Alan Modra  ---
Fixed

[Bug target/90689] [10 Regression] ICE in extract_insn, at recog.c:2310 on ppc64le

2019-06-03 Thread amodra at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90689

--- Comment #6 from Alan Modra  ---
Author: amodra
Date: Tue Jun  4 00:13:07 2019
New Revision: 271895

URL: https://gcc.gnu.org/viewcvs?rev=271895=gcc=rev
Log:
PR90689, ICE in extract_insn on ppc64le

PR target/90689
* config/rs6000/rs6000.c (rs6000_call_aix): Correct r271753 merge
error.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c

[Bug target/90689] [10 Regression] ICE in extract_insn, at recog.c:2310 on ppc64le

2019-06-03 Thread amodra at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90689

Alan Modra  changed:

   What|Removed |Added

 CC||amodra at gmail dot com
   Assignee|unassigned at gcc dot gnu.org  |amodra at gmail dot com

--- Comment #5 from Alan Modra  ---
It's a merge error.  The correct condition for the block shown in comment #4 is

  if (is_pltseq_longcall)

I'll give that a quick test and commit as obvious.

[Bug tree-optimization/90739] [10 regression] Fortran pointer array tests fails after r271860

2019-06-03 Thread kargl at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90739

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #1 from kargl at gcc dot gnu.org ---
dup.

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

[Bug fortran/90738] [10 regression] gfortran.dg/pointer_array_10.f90 etc. FAIL

2019-06-03 Thread kargl at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90738

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||seurer at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
*** Bug 90739 has been marked as a duplicate of this bug. ***

[Bug libstdc++/90700] Wrong constraints for tuple(allocator_arg_t, const A&, const tuple&)

2019-06-03 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90700

--- Comment #1 from Jonathan Wakely  ---
Author: redi
Date: Mon Jun  3 22:31:45 2019
New Revision: 271887

URL: https://gcc.gnu.org/viewcvs?rev=271887=gcc=rev
Log:
PR libstdc++/90700 Fix constructor constraint for std::tuple

* include/std/tuple
(tuple(allocator_arg_t, const A&, const tuple&)): Fix
value category of template argument to _TC::_NonNestedTuple.
* testsuite/20_util/tuple/cons/90700.cc: New test.

Added:
branches/gcc-9-branch/libstdc++-v3/testsuite/20_util/tuple/cons/90700.cc
Modified:
branches/gcc-9-branch/libstdc++-v3/ChangeLog
branches/gcc-9-branch/libstdc++-v3/include/std/tuple

[Bug tree-optimization/90739] New: [10 regression] Fortran pointer array tests fails after r271860

2019-06-03 Thread seurer at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90739

Bug ID: 90739
   Summary: [10 regression] Fortran pointer array tests fails
after r271860
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

> FAIL: gfortran.dg/pointer_array_10.f90   -Os  execution test
> FAIL: gfortran.dg/subref_array_pointer_2.f90   -Os  execution test

Executing on host:
/home/seurer/gcc/build/gcc-test2/gcc/testsuite/gfortran/../../gfortran
-B/home/seurer/gcc/build/gcc-test2/gcc/testsuite/gfortran/../../
-B/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gfortran.dg/pointer_array_10.f90   
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never-Os   -pedantic-errors 
-B/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libatomic/.libs
-B/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libquadmath/.libs
-L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libquadmath/.libs
-L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libquadmath/.libs
 -lm  -o ./pointer_array_10.exe(timeout = 300)
spawn -ignore SIGHUP
/home/seurer/gcc/build/gcc-test2/gcc/testsuite/gfortran/../../gfortran
-B/home/seurer/gcc/build/gcc-test2/gcc/testsuite/gfortran/../../
-B/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gfortran.dg/pointer_array_10.f90
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -Os -pedantic-errors
-B/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libatomic/.libs
-B/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libquadmath/.libs
-L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libquadmath/.libs
-L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libquadmath/.libs
-lm -o ./pointer_array_10.exe
PASS: gfortran.dg/pointer_array_10.f90   -Os  (test for excess errors)
Setting LD_LIBRARY_PATH to
.:/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libatomic/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libquadmath/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libquadmath/.libs:/home/seurer/gcc/build/gcc-test2/gcc:.:/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libatomic/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libquadmath/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libquadmath/.libs:/home/seurer/gcc/build/gcc-test2/gcc:/home/seurer/gcc/build/gcc-test2/./gmp/.libs:/home/seurer/gcc/build/gcc-test2/./prev-gmp/.libs:/home/seurer/gcc/build/gcc-test2/./mpfr/src/.libs:/home/seurer/gcc/build/gcc-test2/./prev-mpfr/src/.libs:/home/seurer/gcc/build/gcc-test2/./mpc/src/.libs:/home/seurer/gcc/build/gcc-test2/./prev-mpc/src/.libs:/home/seurer/gcc/build/gcc-test2/./isl/.libs:/home/seurer/gcc/build/gcc-test2/./prev-isl/.libs:/home/seurer/gcc/install/gcc-7.2.0/lib64
Execution timeout is: 300
spawn [open ...]
STOP 1
FAIL: gfortran.dg/pointer_array_10.f90   -Os  execution test
testcase /home/seurer/gcc/gcc-test2/gcc/testsuite/gfortran.dg/dg.exp completed
in 0 seconds

=== gfortran Summary ===

# of expected passes11
# of unexpected failures1

[Bug fortran/90738] [10 regression] gfortran.dg/pointer_array_10.f90 etc. FAIL

2019-06-03 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90738

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug fortran/90738] New: [10 regression] gfortran.dg/pointer_array_10.f90 etc. FAIL

2019-06-03 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90738

Bug ID: 90738
   Summary: [10 regression] gfortran.dg/pointer_array_10.f90 etc.
FAIL
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: tkoenig at gcc dot gnu.org
  Target Milestone: ---

Between 20190601 (r271838) and 20190603 (r271873), two fortran tests regressed:

+FAIL: gfortran.dg/pointer_array_10.f90   -Os  execution test
+FAIL: gfortran.dg/subref_array_pointer_2.f90   -Os  execution test

I'm seeing it on Solaris/SPARC and x86 (both 32 and 64-bit), but there are
several gcc-testresults reports on a bunch of other targets including
Linux/x86_64.

The first test exists with

STOP 1

Perhaps this is due to
2019-06-02  Thomas Koenig  

PR fortran/90539
* trans-expr.c (gfc_conv_subref_array_arg): If the size of the
expression can be determined to be one, treat it as contiguous.
Set likelyhood of presence of an actual argument according to
PRED_FORTRAN_ABSENT_DUMMY and likelyhood of being contiguous
according to PRED_FORTRAN_CONTIGUOUS.

2019-06-02  Thomas Koenig  

PR fortran/90539
* predict.def (PRED_FORTRAN_CONTIGUOUS): New predictor.

the only fortran patch in the above range?

[Bug c/90737] [8/9/10 Regression] inconsistent address of a local converted to intptr_t between callee and caller

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-06-03
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2019-06/msg00114.html

[Bug middle-end/90694] incorrect representation of ADDR_EXPR involving a pointer to array

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

--- Comment #7 from Martin Sebor  ---
Thanks for the heads up.  I scanned the testsuite for the pattern but couldn't
find any matching tests:

$ find gcc/testsuite/ -type f | xargs grep "&\*[a-zA-Z_][a-zA-Z_0-9]*\[" | grep
scan | wc -l
0

Please let me know if you think I may have missed some.

[Bug c++/90736] [9/10 Regression] Bogus error with alignas

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

--- Comment #3 from Marek Polacek  ---
This compiles when the parm 'b' is not const.

[Bug bootstrap/89864] gcc fails to build/bootstrap with XCode 10.2

2019-06-03 Thread iains at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #100 from Iain Sandoe  ---
fixed on open branches, I will probably make local patches for 6.5 and 5.5
since there are folks who still care about them,  however this is closed as
fixed.

[Bug rtl-optimization/90706] [9 Regression] Useless code generated for stack / register operations on AVR

2019-06-03 Thread bseifert at gmx dot at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90706

--- Comment #2 from Berni  ---
(In reply to Georg-Johann Lay from comment #1)
> (In reply to Berni from comment #0)
> > pushing r0 does not make sense at all since it is by definition a temporary
> > register that can freely be modified. Maybe it's just pushed to make room
> > for the stack operations?
> 
> Yes. 
> 
> The code from v8 is already suboptimal: It's nonsense to load R28 with 0x1
> just to survive a function call. Better use a call-used register and load it
> after the function call to where the return value is computed. Then there
> would be no need to push/pop R28.
> 
> Does -fno-caller-saves improve v9 code?
> 
> This is definitely not a target issue. It's likely a register-allocation
> problem. And the v8 problem is because some (tree) passes move setters away
> from their consumers.

With option -fno-caller-saves there is no change in v9 code!

[Bug bootstrap/89864] gcc fails to build/bootstrap with XCode 10.2

2019-06-03 Thread iains at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864

--- Comment #99 from Iain Sandoe  ---
Author: iains
Date: Mon Jun  3 19:13:46 2019
New Revision: 271881

URL: https://gcc.gnu.org/viewcvs?rev=271881=gcc=rev
Log:
Darwin, backport fixes for PR 89864 (with 90379 included)

2019-06-03  Iain Sandoe  

Backport from mainline.
2019-05-11  Iain Sandoe  

PR bootstrap/89864
* inclhack.def (darwin_ucred__Atomic): Do not supply test_text
for wrap fixes.
* fixincl.x: Regenerated.

Backport from mainline.
2019-04-18  Erik Schnetter  
Jakub Jelinek  
Iain Sandoe  

PR bootstrap/89864
* inclhack.def (darwin_ucred__Atomic): New, work around _Atomic keyword
use in headers included by C++.
* fixincl.x: Regenerated.


Modified:
branches/gcc-7-branch/fixincludes/ChangeLog
branches/gcc-7-branch/fixincludes/fixincl.x
branches/gcc-7-branch/fixincludes/inclhack.def

[Bug c/90737] [8/9/10 Regression] inconsistent address of a local converted to intptr_t between callee and caller

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic, wrong-code
  Known to work||4.9.4
 Blocks||90556
Summary|wrong code returning|[8/9/10 Regression]
   |address of a local  |inconsistent address of a
   |converted to intptr_t   |local converted to intptr_t
   ||between callee and caller
  Known to fail||10.0, 5.1.0, 6.4.0, 7.3.0,
   ||8.2.0, 9.1.0

--- Comment #1 from Martin Sebor  ---
The warning for this code goes at least as far back as GCC 4.1.  The
inconsistency between the callee and the caller started in GCC 4.9.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90556
[Bug 90556] [meta-bug] bogus/missing -Wreturn-local-addr

[Bug c/90737] New: wrong code returning address of a local converted to intptr_t

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

Bug ID: 90737
   Summary: wrong code returning address of a local converted to
intptr_t
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

GCC issues -Wreturn-local-addr even for returning the address of a local
variable converted to an integer.  In addition, it also replaces the value of
the integer with a zero.  Since returning the integer representation of pointer
is well-defined, as is using such an integer, this leads to
inconsistencies/undefined behavior when the integer is first determined to be
non-zero within the body of the returning function and then zero in its caller.

The warning should only be issued for functions that return a pointer. 
Likewise, the replacement of the address with a zero should only be done for
such functions and not for those returning other types.

$ cat a.c && gcc -O2 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout a.c
typedef __INTPTR_TYPE__ intptr_t;

intptr_t f (void)
{
  int i;
  if ((intptr_t) == 0)
__builtin_abort ();

  return (intptr_t)
}

void g (void)
{
  intptr_t i = f ();
  if (i == 0)
__builtin_trap ();
}
a.c: In function ‘f’:
a.c:9:10: warning: function returns address of local variable
[-Wreturn-local-addr]
9 |   return (intptr_t)
  |  ^~~~

;; Function f (f, funcdef_no=0, decl_uid=1907, cgraph_uid=1, symbol_order=0)

f ()
{
   [local count: 1073741824]:
  return 0;

}



;; Function g (g, funcdef_no=1, decl_uid=1911, cgraph_uid=2, symbol_order=1)
(unlikely executed)

g ()
{
   [count: 0]:
  __builtin_trap ();

}

[Bug middle-end/90735] missing location in -Wreturn-local-addr on a function with two return statements

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

--- Comment #2 from Martin Sebor  ---
The problem is in this function in gimple-low.c:

/* Lower a GIMPLE_RETURN GSI.  DATA is passed through the recursion.  */

static void
lower_gimple_return (gimple_stmt_iterator *gsi, struct lower_data *data)
{
  ...

  if (gimple_return_retval (stmt) == gimple_return_retval (tmp_rs.stmt))
{
  /* Remove the line number from the representative return statement.
 It now fills in for many such returns.  Failure to remove this
 will result in incorrect results for coverage analysis.  */
  gimple_set_location (tmp_rs.stmt, UNKNOWN_LOCATION);

  goto found;
}
  ...

I wonder if setting the location to the closing curly brace of the function
definition would not cause these failures.  At least the warning would point
into the right function if not the right statement.

[Bug libfortran/77278] Use LTO for libgfortran

2019-06-03 Thread rguenther at suse dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278

--- Comment #10 from rguenther at suse dot de  ---
On June 3, 2019 6:54:10 PM GMT+02:00, "tkoenig at gcc dot gnu.org"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
>
>--- Comment #9 from Thomas Koenig  ---
>Created attachment 46446
>  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46446=edit
>LTO tree dump from simple test case
>
>So, I tried out a simple program:
>
>$ cat minloc.f90
>program main
>  real, dimension(10,10) :: a
>  integer, dimension(2) :: m1
>  call random_number(a)
>  m1 = minloc(a)
>  print *,m1
>end program main
>
>Compiling this with the fat-object libgfortran results in the somewhat
>humorous
>
>$ gfortran -fdump-tree-optimized -O3 -flto -static-libgfortran 
>minloc.f90
>minloc.f90:5: warning: type of '_gfortran_minloc0_4_r4' does not match
>original
>declaration [-Wlto-type-mismatch]
>5 |   m1 = minloc(a)
>  | 
>../../../ggdb3/libgfortran/generated/minloc0_4_r4.c:38:1: note: type
>mismatch
>in parameter 3
>../../../ggdb3/libgfortran/generated/minloc0_4_r4.c:38:1: note:
>'minloc0_4_r4'
>was previously declared here
>../../../ggdb3/libgfortran/generated/minloc0_4_r4.c:38:1: note: code
>may be
>misoptimized unless '-fno-strict-aliasing' is used
>
>which looks like an LTO bug.

It tells you the actual argument of the Fortran frontend generated call is not
compatible with the C prototype. It
Doesn't say which types are involved here and the leading sentence is
confusing. 

>There is a lot of code pulled in for writing to standard output
>which could be optimized away.
>
>The good news: Inlining  _gfortran_minloc0_4_r4 appears to work :-)

[Bug c++/90736] [9/10 Regression] Bogus error with alignas

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-06-03
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |8.4
Summary|Bogus error with alignas|[9/10 Regression] Bogus
   ||error with alignas
 Ever confirmed|0   |1

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

[Bug c++/90736] Bogus error with alignas

2019-06-03 Thread mbelivea at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90736

--- Comment #1 from Matthew Beliveau  ---
Started with commit r261971

[Bug c++/90736] New: Bogus error with alignas

2019-06-03 Thread mbelivea at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90736

Bug ID: 90736
   Summary: Bogus error with alignas
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mbelivea at redhat dot com
  Target Milestone: ---

constexpr unsigned long a(const unsigned long b) { return b; }
const unsigned long c = a(alignof(int));
alignas(c) char d;

 ./cc1plus -quiet u.ii 
u.ii:3:17: error: requested alignment is not an integer constant
3 | alignas(c) char d;

[Bug middle-end/90735] missing location in -Wreturn-local-addr on a function with two return statements

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

--- Comment #1 from Martin Sebor  ---
The output of the -fdump-tree-all-lineno option shows the correct location
information in the a.c.007t.omplower dump:

;; Function f (f, funcdef_no=0, decl_uid=1909, cgraph_uid=1, symbol_order=0)

f (int i, int j)
[../a.c:4:1] {
  int * iftmp.0;
  int * D.1920;
  int c;
  int * p;

  try
{
  [../a.c:6:22] if (i < 0) goto ; else goto ;
  :
  [../a.c:6:22] iftmp.0 = [../a.c:6:20] 
  goto ;
  :
  [../a.c:6:22] iftmp.0 = [../a.c:6:24] 
  :
  [../a.c:6:8] p = iftmp.0;
  [../a.c:7:7] _1 = [../a.c:7:7] *p;
  [../a.c:7:6] if (_1 != 0) goto ; else goto ;
  :
  [../a.c:8:12] D.1920 = p;
  [../a.c:8:12] // predicted unlikely by early return (on trees) predictor.
  [../a.c:8:12] return D.1920;
  :
  [../a.c:9:6] if (j < 0) goto ; else goto ;
  :
  [../a.c:10:7] p = [../a.c:10:9] 
  :
  [../a.c:12:10] D.1920 = p;
  [../a.c:12:10] return D.1920;
}
  finally
{
  c = {CLOBBER};
}
}

but the a.c.008t.lower dump below does not.  The two return statements (one on
line 8 and the other on line 12) are merged into one at the end of the
function.  I'm not sure what would be a good solution here.  Keeping the
location of either one of the statement would still lead to inaccurate results
in some cases.  But maybe that's better than no location at all.

;; Function f (f, funcdef_no=0, decl_uid=1909, cgraph_uid=1, symbol_order=0)

f (int i, int j)
{
  int * p;
  int c;
  int * D.1920;
  int * iftmp.0;

  try
{
  [../a.c:6:22] if (i < 0) goto ; else goto ;
  :
  [../a.c:6:22] iftmp.0 = [../a.c:6:20] 
  goto ;
  :
  [../a.c:6:22] iftmp.0 = [../a.c:6:24] 
  :
  [../a.c:6:8] p = iftmp.0;
  [../a.c:7:7] _1 = [../a.c:7:7] *p;
  [../a.c:7:6] if (_1 != 0) goto ; else goto ;
  :
  [../a.c:8:12] D.1920 = p;
  [../a.c:8:12] // predicted unlikely by early return (on trees) predictor.
  [../a.c:8:12] goto ;
  :
  [../a.c:9:6] if (j < 0) goto ; else goto ;
  :
  [../a.c:10:7] p = [../a.c:10:9] 
  :
  [../a.c:12:10] D.1920 = p;
  [../a.c:12:10] goto ;
}
  finally
{
  c = {CLOBBER};
}
  :
  return D.1920;
}

[Bug c++/90734] [concepts] Pre-normalization substitution into constraints of templated function breaks subsumption

2019-06-03 Thread Casey at Carter dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90734

Casey Carter  changed:

   What|Removed |Added

 CC||Casey at Carter dot net

--- Comment #1 from Casey Carter  ---
Note that this may be a duplicate of #82507, or more precisely a different
expression of the same mechanism that causes #82507.

Handy Compiler Explorer link with repro: https://godbolt.org/z/-vPUJx.

[Bug middle-end/90735] New: missing location in -Wreturn-local-addr on a function with two return statements

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

Bug ID: 90735
   Summary: missing location in -Wreturn-local-addr on a function
with two return statements
   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 -Wreturn-local-addr warning is often missing location information when
issued for one of two (or more) return statements in a function involving
conditionals.  For example:

$ cat a.c && gcc -O2 -S -Wall -Wextra a.c
extern int a[], b[];

int* f (int i, int j)
{
  int c;
  int *p = i < 0 ? a : b;
  if (*p)
return p;
  if (j < 0)
p = 

  return p;
}
a.c: In function ‘f’:
cc1: warning: function may return address of local variable
[-Wreturn-local-addr]
a.c:5:7: note: declared here
5 |   int c;
  |   ^

[Bug c++/90734] New: [concepts] Pre-normalization substitution into constraints of templated function breaks subsumption

2019-06-03 Thread Casey at Carter dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90734

Bug ID: 90734
   Summary: [concepts] Pre-normalization substitution into
constraints of templated function breaks subsumption
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Casey at Carter dot net
  Target Milestone: ---

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

Compiling this program:

template 
inline constexpr bool bool_ = B;

#if defined(WORKAROUND)
template
concept bool Same_impl = __is_same_as(T, U);
#else
template 
concept bool Same_impl = bool_<__is_same_as(T, U)>;
#endif

template
concept bool Same = Same_impl && Same_impl;

template
concept bool Foo = Same;

template
concept bool Bar = Foo && Same;

template
struct S1 {
// overload set incorrectly is ambiguous (should resolve to second
overload)
static constexpr bool f() requires Foo { return false; }
static constexpr bool f() requires Bar { return true; }
};

template
struct S2 {
// overload set incorrectly is not ambiguous (resolves to third
overload)
static constexpr bool f() requires Foo { return false; }
static constexpr bool f() requires Bar { return false; }
static constexpr bool f() requires bool_ && true { return true; }
};

template
concept bool can_f = requires { T::f(); };

int main() {
static_assert(Foo);
static_assert(Bar);

static_assert(can_f>);  // Fails
static_assert(S1::f());// Bogus error

static_assert(!can_f>); // Fails
#ifndef WORKAROUND
static_assert(S2::f());// Bogus non-error
#endif
}

with "-std=c++2a -fconcepts" produces diagnostics:

/home/casey/casey/Desktop/repro.cpp: In function ‘int main()’:
/home/casey/casey/Desktop/repro.cpp:43:19: error: static assertion failed
43 | static_assert(can_f>);  // Fails
   |   ^~
/home/casey/casey/Desktop/repro.cpp:44:30: error: call of overloaded ‘f()’
is ambiguous
44 | static_assert(S1::f());// Bogus error
   |  ^
/home/casey/casey/Desktop/repro.cpp:24:27: note: candidate: ‘static
constexpr bool S1::f() requires  Foo [with T = int]’
24 | static constexpr bool f() requires Foo { return false; }
   |   ^
/home/casey/casey/Desktop/repro.cpp:25:27: note: candidate: ‘static
constexpr bool S1::f() requires  Bar [with T = int]’
25 | static constexpr bool f() requires Bar { return true; }
   |   ^
/home/casey/casey/Desktop/repro.cpp:46:19: error: static assertion failed
46 | static_assert(!can_f>); // Fails
   |   ^~~

when it should diagnose only the static_assert on line 48. Bar subsumes
Foo, so S1::f should be unambiguous. Conversely, Neither Bar nor
bool_ && true subsumes the other, so S2::f should be ambiguous. The
compiler's disagreement with both of these facts suggests premature
substitution replacing bool_<__is_same_as(T, T)> and bool_<__is_same_as(const
T&, const T&)> with bool_ *before* determination of subsumption in
overload resolution. That replacement would result in Foo being replaced
with bool_ && bool_, and Bar being replaced with bool_ &&
bool_ && bool_ && bool_ which *would* produce the observed
behavior during overload resolution.

[Bug libfortran/77278] Use LTO for libgfortran

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

--- Comment #9 from Thomas Koenig  ---
Created attachment 46446
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46446=edit
LTO tree dump from simple test case

So, I tried out a simple program:

$ cat minloc.f90
program main
  real, dimension(10,10) :: a
  integer, dimension(2) :: m1
  call random_number(a)
  m1 = minloc(a)
  print *,m1
end program main

Compiling this with the fat-object libgfortran results in the somewhat
humorous

$ gfortran -fdump-tree-optimized -O3 -flto -static-libgfortran  minloc.f90
minloc.f90:5: warning: type of '_gfortran_minloc0_4_r4' does not match original
declaration [-Wlto-type-mismatch]
5 |   m1 = minloc(a)
  | 
../../../ggdb3/libgfortran/generated/minloc0_4_r4.c:38:1: note: type mismatch
in parameter 3
../../../ggdb3/libgfortran/generated/minloc0_4_r4.c:38:1: note: 'minloc0_4_r4'
was previously declared here
../../../ggdb3/libgfortran/generated/minloc0_4_r4.c:38:1: note: code may be
misoptimized unless '-fno-strict-aliasing' is used

which looks like an LTO bug.

There is a lot of code pulled in for writing to standard output
which could be optimized away.

The good news: Inlining _gfortran_minloc0_4_r4 appears to work :-)

[Bug c/90733] New: [8/9/10 Regression] ICE in simplify_subreg, at simplify-rtx.c:6440

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

Bug ID: 90733
   Summary: [8/9/10 Regression] ICE in simplify_subreg, at
simplify-rtx.c:6440
   Product: gcc
   Version: 10.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 early gcc-8 and options -g -O2+ :


$ cat z1.c
typedef struct
{
  unsigned a : 1;
} s;

typedef union
{
  s b;
  _Complex unsigned c;
} t;

t f (t d)
{
  t e = d;
  return e;
}

int g ()
{
  t x;
  t y;
  x.c = x.b.a;
  y = f(x);
  return (x.c != y.c);
}


$ gcc-10-20190602 -c z1.c -O2
$
$ gcc-10-20190602 -c z1.c -O2 -g
z1.c: In function 'g':
z1.c:22:12: warning: 'x.b.a' is used uninitialized in this function
[-Wuninitialized]
   22 |   x.c = x.b.a;
  | ~~~^~
during RTL pass: vartrack
z1.c:25:1: internal compiler error: in simplify_subreg, at simplify-rtx.c:6440
   25 | }
  | ^
0xa67144 simplify_subreg(machine_mode, rtx_def*, machine_mode, poly_int<1u,
unsigned long>)
../../gcc/simplify-rtx.c:6440
0xa66b24 simplify_subreg(machine_mode, rtx_def*, machine_mode, poly_int<1u,
unsigned long>)
../../gcc/simplify-rtx.c:6544
0xa6ac78 simplify_gen_subreg(machine_mode, rtx_def*, machine_mode, poly_int<1u,
unsigned long>)
../../gcc/simplify-rtx.c:6711
0xce16a5 vt_expand_loc_callback
../../gcc/var-tracking.c:8488
0x710f31 cselib_expand_value_rtx_1
../../gcc/cselib.c:1681
0x7124ae cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def*
(*)(rtx_def*, bitmap_head*, int, void*), void*)
../../gcc/cselib.c:1562
0xce19e9 vt_expand_var_loc_chain
../../gcc/var-tracking.c:8384
0xce19e9 vt_expand_loc_callback
../../gcc/var-tracking.c:8547
0x710df2 cselib_expand_value_rtx_1
../../gcc/cselib.c:1716
0x7124ae cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def*
(*)(rtx_def*, bitmap_head*, int, void*), void*)
../../gcc/cselib.c:1562
0xce19e9 vt_expand_var_loc_chain
../../gcc/var-tracking.c:8384
0xce19e9 vt_expand_loc_callback
../../gcc/var-tracking.c:8547
0x710ced cselib_expand_value_rtx_1
../../gcc/cselib.c:1755
0x7124ae cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def*
(*)(rtx_def*, bitmap_head*, int, void*), void*)
../../gcc/cselib.c:1562
0xce19e9 vt_expand_var_loc_chain
../../gcc/var-tracking.c:8384
0xce19e9 vt_expand_loc_callback
../../gcc/var-tracking.c:8547
0x710df2 cselib_expand_value_rtx_1
../../gcc/cselib.c:1716
0x7124ae cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def*
(*)(rtx_def*, bitmap_head*, int, void*), void*)
../../gcc/cselib.c:1562
0xce0a65 vt_expand_var_loc_chain
../../gcc/var-tracking.c:8384
0xce0a65 vt_expand_1pvar
../../gcc/var-tracking.c:8660

[Bug c++/90732] New: regression - ICE with std::apply after variable length array

2019-06-03 Thread v at vsamko dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90732

Bug ID: 90732
   Summary: regression - ICE with std::apply after variable length
array
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: v at vsamko dot com
  Target Milestone: ---

With -O0 -std=c++17 this results in ICE

#include 
#include 

volatile size_t SIZE = 100;

template
void foo(Ts&... out) {
std::tuple dummy;
char buf[SIZE];
std::apply([, ](auto&... x) { (x, ...); }, dummy);
}

int main() {
int x1;
foo(x1);
}


during RTL pass: expand
test.cpp: In lambda function:
test.cpp:10:16: internal compiler error: in expand_expr_real_1, at expr.c:10012
   10 | std::apply([, ](auto&... x) { (x, ...); }, dummy);
  |^
0x79d4d9 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc-9.1.0/gcc/expr.c:10012
0x1236818 expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
../../gcc-9.1.0/gcc/expr.c:8275
0x1236818 expand_expr
../../gcc-9.1.0/gcc/expr.h:279
0x1236818 expand_operands(tree_node*, tree_node*, rtx_def*, rtx_def**,
rtx_def**, expand_modifier)
../../gcc-9.1.0/gcc/expr.c:7873
0x123082a expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
../../gcc-9.1.0/gcc/expr.c:8733
0x115d279 expand_gimple_stmt_1
../../gcc-9.1.0/gcc/cfgexpand.c:3789
0x115d279 expand_gimple_stmt
../../gcc-9.1.0/gcc/cfgexpand.c:3850
0x11579de expand_gimple_basic_block
../../gcc-9.1.0/gcc/cfgexpand.c:5886
0x11579de execute
../../gcc-9.1.0/gcc/cfgexpand.c:6509
Please submit a full bug report,

[Bug c++/90731] regression - noexcept broken for forward declarations with decltype

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
r260238

[Bug c++/90728] False positive Wmemset-elt-size with zero size array

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-06-03
 CC||msebor at gcc dot gnu.org
  Component|c   |c++
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed in C++.  The code that issues the warning is the same between C and
C++:

  if (COMPLETE_TYPE_P (elt_type)
  && !integer_onep (TYPE_SIZE_UNIT (elt_type))
  && domain != NULL_TREE
  && TYPE_MAX_VALUE (domain)
  && TYPE_MIN_VALUE (domain)
  && integer_zerop (TYPE_MIN_VALUE (domain))
  && integer_onep (fold_build2 (MINUS_EXPR, domain,
arg2,
TYPE_MAX_VALUE (domain
warning_at (loc, OPT_Wmemset_elt_size,
"% used with length equal to "
"number of elements without multiplication "
"by element size");

but the difference is that in C the domain of the zero-length array is [0,
null] while in C++ it's [0, SIZE_MAX].  I.e., TYPE_MAX_VALUE (domain) is null
in C which makes the if condition evaluate to false.

[Bug c++/83534] C++17: typeinfo for noexcept function lacks noexcept information

2019-06-03 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83534

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Indeed it is. I thought I'd confirmed this when it was first reported.

[Bug driver/90730] -fdump-tree-gimple-optimized-... accepted

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||accepts-invalid

--- Comment #1 from Martin Sebor  ---
Another invalid example that's accepted:

  -fdump-tree-gimple-all-all-details-details

Based on a warning when one is issued, it looks like GCC simply ignores all
syntactically valid "keywords" after -fdump-tree-- like all and details
but gives warnings for invalid ones.

$ gcc -Wall -Wextra -S -fdump-tree-gimple-all-details-detail -xc - < /dev/null
cc1: warning: ignoring unknown option ‘detail’ in ‘-fdump-tree-gimple’

[Bug c++/90731] New: regression - noexcept broken for forward declarations with decltype

2019-06-03 Thread v at vsamko dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90731

Bug ID: 90731
   Summary: regression - noexcept broken for forward declarations
with decltype
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: v at vsamko dot com
  Target Milestone: ---

void foo1() noexcept(true) {}
decltype(foo1) stub_foo1;
void stub_foo1() noexcept(true) {}

This compiles fine with clang 8 and gcc 8.3, but not with gcc 9.1 (all in c++17
mode).

g++ 9.1 produces error
:9:6: error: declaration of 'void stub_foo1() noexcept' has a different
exception specifier

9 | void stub_foo1() noexcept(true) {}

  |  ^

:7:16: note: from previous declaration 'void stub_foo1()'

7 | decltype(foo1) stub_foo1;

  |^

Compiler returned: 1

According to the standard
(https://en.cppreference.com/w/cpp/language/noexcept_spec) - Functions
differing only in their exception specification cannot be overloaded (just like
the return type, exception specification is part of function type, but not part
of the function signature) (since C++17).

And indeed, 
void foo1() noexcept(true) {}
void foo2() noexcept(false) {}
std::is_same_v // evaluates to false

[Bug driver/90730] New: -fdump-tree-gimple-optimized-... accepted

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

Bug ID: 90730
   Summary: -fdump-tree-gimple-optimized-... accepted
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Some non-sensical -fdump-tree-xxx options are silently accepted, such as:

$ gcc -Wall -Wextra -S -fdump-tree-gimple-optimized -xc - < /dev/null

The result is a .gimple dump file but no .optimized dump.

This is also accepted: -fdump-tree-gimple-all with the same effect.

[Bug target/90689] [10 Regression] ICE in extract_insn, at recog.c:2310 on ppc64le

2019-06-03 Thread segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90689

--- Comment #4 from Segher Boessenkool  ---
rs6000.c does

  if (HAVE_AS_PLTSEQ
  && DEFAULT_ABI == ABI_ELFv2
  && GET_CODE (func_desc) == SYMBOL_REF)
{
  rtvec v = gen_rtvec (3, toc_reg, func_desc, tlsarg);
  rtx mark_toc_reg = gen_rtx_UNSPEC (Pmode, v, UNSPEC_PLTSEQ);
  emit_insn (gen_rtx_SET (stack_toc_mem, mark_toc_reg));
}
  else
emit_move_insn (stack_toc_mem, toc_reg);

but the insn condition for *pltseq_tocsave_ is

  "TARGET_PLTSEQ
   && DEFAULT_ABI == ABI_ELFv2"

I think that HAVE_AS_PLTSEQ there should be TARGET_PLTSEQ?

[Bug c++/83534] C++17: typeinfo for noexcept function lacks noexcept information

2019-06-03 Thread v at vsamko dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83534

Valentine  changed:

   What|Removed |Added

 CC||v at vsamko dot com

--- Comment #1 from Valentine  ---
I'm having the same problem. Looks like a bug. Clang handles this fine.

[Bug target/90689] [10 Regression] ICE in extract_insn, at recog.c:2310 on ppc64le

2019-06-03 Thread segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90689

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed|2019-05-31 00:00:00 |2019-06-03
 Ever confirmed|0   |1

--- Comment #3 from Segher Boessenkool  ---
I have reproduced it now (on a native build).  It needs all of
  -mno-pltseq -fno-inline -fno-plt -Os -mabi=elfv2
to fail.

[Bug d/90729] libphobos.phobos_shared/std/math.d FAILs on Solaris

2019-06-03 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90729

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |9.2

[Bug d/90729] New: libphobos.phobos_shared/std/math.d FAILs on Solaris

2019-06-03 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90729

Bug ID: 90729
   Summary: libphobos.phobos_shared/std/math.d FAILs on Solaris
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
Target: *-*-solaris2.11

The libphobos.phobos_shared/std/math.d test FAILs on Solaris/SPARC and x86,
though in different ways:

* x86:

Arithmetic Exception

Thread 2 received signal SIGFPE, Arithmetic exception.
[Switching to Thread 1 (LWP 1)]
0x0807d4f2 in std.math.__unittestL2454_30() ()
at /vol/gcc/src/hg/trunk/solaris/libphobos/testsuite/../src/std/math.d:2533
2533if (x == real.infinity)

(gdb) p x
$1 = 2.6711020675522791803e-4932

* sparc:

core.exception.AssertError@/vol/gcc/src/hg/trunk/solaris/libphobos/testsuite/../src/std/math.d(1516):
unittest failure

assert(equalsDigit(acosh(cosh(3.0)), 3, useDigits));

[Bug c/90728] New: False positive Wmemset-elt-size with zero size array

2019-06-03 Thread yyc1992 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90728

Bug ID: 90728
   Summary: False positive Wmemset-elt-size with zero size array
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yyc1992 at gmail dot com
  Target Milestone: ---

The code below comes from a template expansion (when certain cache feature is
disabled) and all the operation on the `buff` member are no-op.

```
#include 

struct A {
A()
{
memset(, 0xff, sizeof(buff));
}

int buff[0];
};
```

However, this start to raise a warning on GCC 9

```
a.cpp: In constructor 'A::A()':
a.cpp:8:41: warning: 'memset' used with length equal to number of elements
without multiplication by element size [-Wmemset-elt-size]
8 | memset(, 0xff, sizeof(buff));
  | ^
```

It seems that the warning logic simply compare the size (as well as checking
element size != 1) without taking into account the 0 size case.

[Bug d/90727] libphobos.phobos_shared/std/datetime/systime.d etc. FAIL on Solaris

2019-06-03 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90727

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |9.2

[Bug d/90727] New: libphobos.phobos_shared/std/datetime/systime.d etc. FAIL on Solaris

2019-06-03 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90727

Bug ID: 90727
   Summary: libphobos.phobos_shared/std/datetime/systime.d etc.
FAIL on Solaris
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
Target: *-*-solaris2.11

libphobos.phobos_shared/std/datetime/systime.d and
libphobos.phobos_shared/std/datetime/timezone.d
FAIL on Solaris/SPARC and x86, 32 and 64-bit:

core.exception.AssertError@/vol/gcc/src/hg/trunk/solaris/libphobos/testsuite/../src/std/datetime/systime.d(748):
Value given: -1998-Jan-01 01:59:59

Failed time zone: America/Los_Angeles
core.exception.AssertError@/vol/gcc/src/hg/trunk/solaris/libphobos/testsuite/../src/std/datetime/timezone.d(236):
Assertion failure

I've not yet wrapped my head around that code, but suspect the failures are
related to Solaris' lack of tm_gmtoff and tm_zone members in struct tm.

[Bug libstdc++/90686] Libstdc++ C++20 status table is missing entry for P1357R1 "Traits for [Un]bounded Arrays"

2019-06-03 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90686

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Mon Jun  3 14:05:50 2019
New Revision: 271872

URL: https://gcc.gnu.org/viewcvs?rev=271872=gcc=rev
Log:
PR libstdc++/90686 update C++2a library status docs

PR libstdc++/90686
* doc/xml/manual/status_cxx2014.xml: Document what's missing from
.
* doc/xml/manual/status_cxx2020.xml: Document status of P0777R1,
P0339R6, P0340R3, P1164R1 and P1357R1.
* doc/html/*: Regenerate.

Modified:
branches/gcc-9-branch/libstdc++-v3/ChangeLog
branches/gcc-9-branch/libstdc++-v3/doc/html/manual/status.html
branches/gcc-9-branch/libstdc++-v3/doc/xml/manual/status_cxx2014.xml
branches/gcc-9-branch/libstdc++-v3/doc/xml/manual/status_cxx2020.xml

[Bug libstdc++/90686] Libstdc++ C++20 status table is missing entry for P1357R1 "Traits for [Un]bounded Arrays"

2019-06-03 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90686

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
Fixed

[Bug middle-end/64242] Longjmp expansion incorrect

2019-06-03 Thread wilco at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64242

--- Comment #24 from Wilco  ---
Author: wilco
Date: Mon Jun  3 13:55:15 2019
New Revision: 271870

URL: https://gcc.gnu.org/viewcvs?rev=271870=gcc=rev
Log:
Fix PR64242 - Longjmp expansion incorrect

Improve the fix for PR64242.  Various optimizations can change a memory
reference into a frame access.  Given there are multiple virtual frame pointers
which may be replaced by multiple hard frame pointers, there are no checks for
writes to the various frame pointers.  So updates to a frame pointer tends to
generate incorrect code.  Improve the previous fix to also add clobbers of
several frame pointers and add a scheduling barrier.  This should work in most
cases until GCC supports a generic "don't optimize across this instruction"
feature.

Bootstrap OK. Testcase passes on AArch64 and x86-64.  Inspected x86, Arm,
Thumb-1 and Thumb-2 assembler which looks correct. 

gcc/
PR middle-end/64242
* builtins.c (expand_builtin_longjmp): Add frame clobbers and schedule
block.
(expand_builtin_nonlocal_goto): Likewise.

testsuite/
PR middle-end/64242
* gcc.c-torture/execute/pr64242.c: Update test.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.c-torture/execute/pr64242.c

[Bug middle-end/90726] exponential behavior on SCEV results everywhere

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||compile-time-hog
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-06-03
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug middle-end/90726] New: exponential behavior on SCEV results everywhere

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

Bug ID: 90726
   Summary: exponential behavior on SCEV results everywhere
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

A GIMPLE testcase derived from gcc.dg/torture/pr88597.c exposes quadraticnesses
in chrec and ivopts predicates (I have patches for this) as well as
expand_simple_operations.  It also shows expression_expensive_p happily
accepts the GENERIC tree resulting in exponential amount of generated GIMPLE
due to unsharing/gimplification.  I also have a patch for
expression_expensive_p.

int __GIMPLE (ssa,guessed_local(12348030),startwith("fix_loops"))
un (int dd)
{
  int s2;
  int q8;
  int nz;

  __BB(2,guessed_local(12348030)):
  goto __BB3(guessed(134217728));

  __BB(3,loop_header(1),guessed_local(37044096)):
  nz_7 = __PHI (__BB2: 0, __BB5: nz_10);
  q8_13 = dd_9(D) * dd_9(D);
  q8_17 = q8_13 * q8_13;
  q8_21 = q8_17 * q8_17;
  q8_25 = q8_21 * q8_21;
  q8_29 = q8_25 * q8_25;
  q8_33 = q8_29 * q8_29;
  q8_37 = q8_33 * q8_33;
  q8_41 = q8_37 * q8_37;
  q8_45 = q8_41 * q8_41;
  q8_49 = q8_45 * q8_45;
  q8_53 = q8_49 * q8_49;
  q8_57 = q8_53 * q8_53;
  q8_61 = q8_57 * q8_57;
  q8_65 = q8_61 * q8_61;
  q8_69 = q8_65 * q8_65;
  q8_73 = q8_69 * q8_69;
  q8_77 = q8_73 * q8_73;
  q8_81 = q8_77 * q8_77;
  q8_85 = q8_81 * q8_81;
  q8_89 = q8_85 * q8_85;
  q8_93 = q8_89 * q8_89;
  q8_97 = q8_93 * q8_93;
  q8_101 = q8_97 * q8_97;
  q8_105 = q8_101 * q8_101;
  q8_109 = q8_105 * q8_105;
  q8_113 = q8_109 * q8_109;
  q8_117 = q8_113 * q8_113;
  q8_121 = q8_117 * q8_117;
  nz_10 = nz_7 + 1;
  if (nz_10 != 3)
goto __BB5(guessed(89478485));
  else
goto __BB4(guessed(44739243));

  __BB(5,guessed_local(24696064)):
  goto __BB3(precise(134217728));

  __BB(4,guessed_local(12348031)):
  return q8_121;

}

[Bug libstdc++/90686] Libstdc++ C++20 status table is missing entry for P1357R1 "Traits for [Un]bounded Arrays"

2019-06-03 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90686

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Mon Jun  3 13:23:03 2019
New Revision: 271867

URL: https://gcc.gnu.org/viewcvs?rev=271867=gcc=rev
Log:
PR libstdc++/90686 update C++2a library status docs

PR libstdc++/90686
* doc/xml/manual/status_cxx2014.xml: Document what's missing from
.
* doc/xml/manual/status_cxx2020.xml: Document status of P1285R0,
P0339R6, P0340R3, P1164R1 and P1357R1.
* doc/html/*: Regenerate.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/doc/html/manual/memory.html
trunk/libstdc++-v3/doc/html/manual/status.html
trunk/libstdc++-v3/doc/xml/manual/status_cxx2014.xml
trunk/libstdc++-v3/doc/xml/manual/status_cxx2020.xml

[Bug c++/90725] New: implicitly used 'this' not diagnosed in static member fn declaration

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

Bug ID: 90725
   Summary: implicitly used 'this' not diagnosed in static member
fn declaration
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

struct S {
  int a;
  static int foo() noexcept(noexcept(a));
};

is compiled fine, but 'this' cannot be used in a static member function
declaration.  This one we handle ok:

struct S2 {
  int a;
  static int foo() noexcept(noexcept(this->a));
};

[Bug pch/61250] Random pch failures on x86_64-apple-darwin1(3|4).

2019-06-03 Thread iains at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61250

Iain Sandoe  changed:

   What|Removed |Added

 Target|x86_64-apple-darwin1(3|4)   |x86_64-apple-darwin1(345678
   ||)
   Last reconfirmed|2014-11-11 00:00:00 |2019-6-3
   Host|x86_64-apple-darwin1(3|4)   |x86_64-apple-darwin1(345678
   ||)
  Build|x86_64-apple-darwin1(3|4)   |x86_64-apple-darwin1(345678
   ||)

--- Comment #23 from Iain Sandoe  ---
I do not see these fails on m32 darwin9 or on x86_64 darwin10-12, so there is
some OS interaction, apparently (even if that is only exposing a latent issue).

[Bug target/90724] New: ICE with __sync_bool_compare_and_swap with -march=armv8.2-a+sve

2019-06-03 Thread prathamesh3492 at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90724

Bug ID: 90724
   Summary: ICE with __sync_bool_compare_and_swap with
-march=armv8.2-a+sve
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: prathamesh3492 at gcc dot gnu.org
  Target Milestone: ---

Following test (pr82096.c) and few others fail with following ICE with 
-march=armv8.2-a+sve that contain call to __sync_bool_compare_and_swap:

static long long AL[24];

int
check_ok (void)
{
  return (__sync_bool_compare_and_swap (AL+1, 0x20003ll, 0x1234567890ll));
}

pr82096.c: In function 'check_ok':
pr82096.c:11:1: error: unrecognizable insn:
   11 | }
  | ^
(insn 11 10 12 2 (set (reg:CC 66 cc)
(compare:CC (reg:DI 95)
(const_int 8589934595 [0x20003]))) "pr82096.c":10:11 -1
 (nil))
during RTL pass: vregs
pr82096.c:11:1: internal compiler error: in extract_insn, at recog.c:2310
0x64bb6e _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/gcc/rtl-error.c:108
0x64bb8a _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc/gcc/rtl-error.c:116
0x64a58b extract_insn(rtx_insn*)
../../gcc/gcc/recog.c:2310
0xa28a45 instantiate_virtual_regs_in_insn
../../gcc/gcc/function.c:1605
0xa28a45 instantiate_virtual_regs
../../gcc/gcc/function.c:1975
0xa28a45 execute
../../gcc/gcc/function.c:2024

Thanks,
Prathamesh

[Bug target/90723] New: pr88598-2.c segfaults with -msve-vector-bits=256

2019-06-03 Thread prathamesh3492 at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90723

Bug ID: 90723
   Summary: pr88598-2.c segfaults with -msve-vector-bits=256
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: prathamesh3492 at gcc dot gnu.org
  Target Milestone: ---

cc1 segfaults with the following test-case, with -O2 -march=armv8.2-a+sve
-msve-vector-bits=256:

typedef double v4df __attribute__ ((vector_size (32)));

void foo(v4df);

int
main ()
{
  volatile v4df x1;
  x1 = (v4df) { 0, 1, 1, 2 };
  foo (x1);
  return 0;
}

gdb backtrace (clipped to last 14):

Program received signal SIGSEGV, Segmentation fault.
0x00bfdad1 in expand_binop_directly (icode=CODE_FOR_adddi3,
mode=mode@entry=E_DImode, binoptab=binoptab@entry=add_optab, 
op0=op0@entry=0x77a233a8, op1=op1@entry=0x77a2b290,
target=target@entry=0x75095468, unsignedp=1, methods=OPTAB_LIB_WIDEN, 
last=0x75094bc0) at ../../gcc/gcc/optabs.c:1038
1038{
(gdb) bt
#0  0x00bfdad1 in expand_binop_directly (icode=CODE_FOR_adddi3,
mode=mode@entry=E_DImode, binoptab=binoptab@entry=add_optab, 
op0=op0@entry=0x77a233a8, op1=op1@entry=0x77a2b290,
target=target@entry=0x75095468, unsignedp=1, methods=OPTAB_LIB_WIDEN, 
last=0x75094bc0) at ../../gcc/gcc/optabs.c:1038
#1  0x00bfc0dd in expand_binop (mode=E_DImode, binoptab=, op0=0x77a233a8, op1=0x77a2b290, target=0x75095468, 
unsignedp=1, methods=OPTAB_LIB_WIDEN) at ../../gcc/gcc/optabs.c:1209
#2  0x009cc7e4 in force_operand (value=0x77859f90,
target=0x75095468) at ../../gcc/gcc/expr.c:7527
#3  0x009a80a3 in copy_to_mode_reg (mode=E_DImode,
x=x@entry=0x77859f90) at ../../gcc/gcc/explow.c:627
#4  0x00bf2dce in maybe_legitimize_operand_same_code
(icode=icode@entry=CODE_FOR_aarch64_pred_movvnx2df, opno=opno@entry=2,
op=)
at ../../gcc/gcc/optabs.c:7146
#5  0x00bf56ee in maybe_legitimize_operand (op=0x7bfff400, opno=2,
icode=CODE_FOR_aarch64_pred_movvnx2df) at ../../gcc/gcc/optabs.c:7196
#6  maybe_legitimize_operands (icode=CODE_FOR_aarch64_pred_movvnx2df, opno=0,
nops=, ops=0x7bfff3c0) at ../../gcc/gcc/optabs.c:7323
#7  0x00bf5c0a in maybe_gen_insn
(icode=CODE_FOR_aarch64_pred_movvnx2df, nops=,
ops=0x7bfff3c0)
at ../../gcc/gcc/optabs.c:7342
#8  0x00bf8c39 in maybe_expand_insn (ops=ops@entry=0x7bfff3b0,
nops=nops@entry=3, icode=) at ../../gcc/gcc/optabs.c:7416
#9  expand_insn (icode=, nops=nops@entry=3,
ops=ops@entry=0x7bfff3c0) at ../../gcc/gcc/optabs.c:7416
#10 0x010378a4 in aarch64_emit_sve_pred_move (dest=,
pred=, src=) at ./insn-opinit.h:735
#11 0x012cb710 in gen_movvnx2df (operand0=0x75095408,
operand1=0x77859f78) at ../../gcc/gcc/config/aarch64/aarch64-sve.md:77
#12 0x009c7505 in insn_gen_fn::operator() (this=,
a1=0x77859f78, a0=0x75095408) at ../../gcc/gcc/recog.h:301
#13 emit_move_insn_1 (x=0x75095408, y=0x77859f78) at
../../gcc/gcc/expr.c:3701
#14 0x009c7950 in emit_move_insn (x=x@entry=0x75095408,
y=y@entry=0x77859f78) at ../../gcc/gcc/expr.c:3797

Thanks,
Prathamesh

[Bug target/90722] New: ICE with __builtin_convertvector with -msve-vector-bits=256

2019-06-03 Thread prathamesh3492 at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90722

Bug ID: 90722
   Summary: ICE with __builtin_convertvector with
-msve-vector-bits=256
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: prathamesh3492 at gcc dot gnu.org
  Target Milestone: ---

The following test-case:

typedef int v4si __attribute__((vector_size (4 * sizeof (int;
typedef double v4df __attribute__((vector_size (4 * sizeof (double;

void
f4 (v4df *x, v4si *y)
{
  *y = __builtin_convertvector (*x, v4si);
}

results in ICE with -O2 -march=armv8.2-a+sve -msve-vector-bits=256:

0xcddacd simplify_const_unary_operation(rtx_code, machine_mode, rtx_def*,
machine_mode)
../../gcc/gcc/simplify-rtx.c:1763
0xcd9c2a simplify_unary_operation(rtx_code, machine_mode, rtx_def*,
machine_mode)
../../gcc/gcc/simplify-rtx.c:873
0x13bca5a combine_simplify_rtx
../../gcc/gcc/combine.c:5787
0x13bf1a6 subst
../../gcc/gcc/combine.c:5727
0x13bf2bb subst
../../gcc/gcc/combine.c:5590
0x13bf102 subst
../../gcc/gcc/combine.c:5661
0x13c0568 try_combine
../../gcc/gcc/combine.c:3420
0x13c66c6 combine_instructions
../../gcc/gcc/combine.c:1306
0x13c66c6 rest_of_handle_combine
../../gcc/gcc/combine.c:15068
0x13c66c6 execute
../../gcc/gcc/combine.c:15113

because it hits following assert in simplify_const_unary_operation:
gcc_assert (known_eq (GET_MODE_NUNITS (mode), n_elts));

GET_MODE_NUNITS (mode) == 8 and n_elts == 4 for the test-case.

Thanks,
Prathamesh

[Bug target/90689] [10 Regression] ICE in extract_insn, at recog.c:2310 on ppc64le

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

Martin Liška  changed:

   What|Removed |Added

 CC||amodra at gcc dot gnu.org,
   ||wschmidt at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
Started with r271753. I use normal cross compiler:

Configured with: ../configure --enable-languages=c,c++,fortran
--disable-multilib --prefix=/home/marxin/bin/gcc2 --disable-bootstrap
--disable-libsanitizer --target=ppc64le-linux-gnu
--with-as=/usr/bin/powerpc64le-suse-linux-as : (reconfigured)

[Bug driver/90684] New alignment options incorrectly report error

2019-06-03 Thread wilco at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90684

--- Comment #3 from Wilco  ---
Author: wilco
Date: Mon Jun  3 11:27:50 2019
New Revision: 271864

URL: https://gcc.gnu.org/viewcvs?rev=271864=gcc=rev
Log:
Fix alignment option parser (PR90684)

Fix the alignment option parser to always allow up to 4 alignments.
Now -falign-functions=16:8:8:8 no longer reports an error.

gcc/
PR driver/90684
* opts.c (parse_and_check_align_values): Allow 4 alignment values.
Mgcc/ChangeLog
Mgcc/opts.c

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

[Bug rtl-optimization/90706] [9 Regression] Useless code generated for stack / register operations on AVR

2019-06-03 Thread gjl at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90706

Georg-Johann Lay  changed:

   What|Removed |Added

  Component|target  |rtl-optimization
Summary|Useless code generated for  |[9 Regression] Useless code
   |stack / register operations |generated for stack /
   |on AVR  |register operations on AVR

--- Comment #1 from Georg-Johann Lay  ---
(In reply to Berni from comment #0)
> pushing r0 does not make sense at all since it is by definition a temporary
> register that can freely be modified. Maybe it's just pushed to make room
> for the stack operations?

Yes. 

The code from v8 is already suboptimal: It's nonsense to load R28 with 0x1 just
to survive a function call. Better use a call-used register and load it after
the function call to where the return value is computed. Then there would be no
need to push/pop R28.

Does -fno-caller-saves improve v9 code?

This is definitely not a target issue. It's likely a register-allocation
problem. And the v8 problem is because some (tree) passes move setters away
from their consumers.

[Bug middle-end/82853] Optimize x % 3 == 0 without modulo

2019-06-03 Thread wilco at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82853

--- Comment #36 from Wilco  ---
(In reply to Orr Shalom Dvory from comment #35)
> Hi, thanks for your respond. can someone mark this bug as need to be
> improved?
> Does anyone agree/disagree with my new proposed method?

It's best to create a new bug if there are still easy cases that could be
optimized. Also it seems the constants it uses are quite complex - it may be
feasible to simplify them. Eg. long f(long x) { return x % 35 == 0; }

[Bug c/90721] New: [Bug] ./gcc.dg/torture/stackalign/builtin-apply-4.c test case getting fail

2019-06-03 Thread akhilesh.k at samsung dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90721

Bug ID: 90721
   Summary: [Bug]  ./gcc.dg/torture/stackalign/builtin-apply-4.c
test case getting fail
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: akhilesh.k at samsung dot com
  Target Milestone: ---

Hello 

I am working On ARM target: in that 
./gcc.dg/torture/stackalign/builtin-apply-4.c test case getting fail when we
use -flto flag with gcc 8.3 but same test cases getting pass when we run on gcc
6.3 
=
bash-3.2# cat ./gcc.dg/torture/stackalign/builtin-apply-4.c
/* PR tree-optimization/20076 */
/* { dg-do run } */
/* { dg-additional-options "-fgnu89-inline" } */
/* { dg-require-effective-target untyped_assembly } */

#include 
extern void abort (void);

double
foo (int arg)
{
  if (arg != 116)
abort();
  return arg + 1;
}

inline double
bar (int arg)
{
  foo (arg);
  __builtin_return (__builtin_apply ((void (*) ()) foo,
 __builtin_apply_args (), 16));
}

int
main (int argc, char **argv)
{
  if (bar (116) != 117.0)
printf("hello\n");
  return 0;
}

bash-3.2#

=
gcc 8.x Results 
bash-3.2# gcc ./gcc.dg/torture/stackalign/builtin-apply-4.c -flto
-fgnu89-inline -lm -o ./builtin-apply-4.exe
bash-3.2# ./builtin-apply-4.exe
hello
bash-3.2#

gcc 6.3 test results 
bash-3.2# /bin/gcc ./gcc.dg/torture/stackalign/builtin-apply-4.c -flto
-fgnu89-inline -lm -o ./builtin-apply-4.exe
bash-3.2# ./builtin-apply-4.exe
bash-3.2#

it seems that __builtin_apply returning wrong value

[Bug driver/90692] The "%{!shared:%:if-exists(default-manifest.o%s)}" spec option fails if gcc is installed in a path with spaces

2019-06-03 Thread Olivier.Michel at cyberbotics dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90692

--- Comment #1 from Olivier Michel  ---
The principle of this patch is that it breaks the recursion of the specs
function evaluation as soon as a library file is expanded. This is needed
because otherwise, the file path containing a space is broken down into two
tokens that are evaluated separately and this ends up in two wrong file names
(resulting from the split at the location of the space in the original path).

Indeed, once a library file is expanded, there is no need to further recurse in
the evaluation. So, the recursion is stopped and the result is added to the
argbuf list.

That makes the code slightly more efficient and fixes the handling of paths
with spaces.

Please let me know if you believe this a good approach to fix this bug or if
you have a different idea to achieve a better patch.

[Bug target/89803] Missing AVX512 intrinsics

2019-06-03 Thread crazylht at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89803

--- Comment #6 from Hongtao.liu  ---
Using "vector_operand" "vm" instead

Index: gcc/config/i386/sse.md
===
--- gcc/config/i386/sse.md  (revision 271853)
+++ gcc/config/i386/sse.md  (working copy)
@@ -600,6 +600,10 @@
(V8HI "v8si")   (V16HI "v16si") (V32HI "v32si")
(V4SI "v4di")   (V8SI "v8di")   (V16SI "v16di")])

+(define_mode_attr mem_suffix
+ [(V16SF "{z}") (V8SF "{y}") (V4SF "{x}")
+  (V8DF "{z}") (V4DF "{y}") (V2DF "{x}")])
+
 (define_mode_attr ssedoublemode
   [(V4SF "V8SF") (V8SF "V16SF") (V16SF "V32SF")
(V2DF "V4DF") (V4DF "V8DF") (V8DF "V16DF")
@@ -21317,26 +21321,26 @@
 (define_insn "avx512dq_fpclass"
   [(set (match_operand: 0 "register_operand" "=k")
   (unspec:
-[(match_operand:VF_AVX512VL 1 "register_operand" "v")
+[(match_operand:VF_AVX512VL 1 "vector_operand" "vm")
  (match_operand:QI 2 "const_0_to_255_operand" "n")]
  UNSPEC_FPCLASS))]
"TARGET_AVX512DQ"
-   "vfpclass\t{%2, %1,
%0|%0, %1, %2}";
+   "vfpclass\t{%2, %1,
%0|%0, %1, %2}";
   [(set_attr "type" "sse")
(set_attr "length_immediate" "1")
(set_attr "prefix" "evex")
(set_attr "mode" "")])

also need to modify scan assembler tests.

[Bug debug/90716] [10 Regression] gcc generates wrong debug information at -O2

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Mon Jun  3 10:17:16 2019
New Revision: 271858

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

PR tree-optimization/90716
* tree-loop-distribution.c (destroy_loop): Process blocks in
correct order.

* gcc.dg/guality/pr90716.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/guality/pr90716.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-loop-distribution.c

[Bug debug/90716] [10 Regression] gcc generates wrong debug information at -O2

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug target/88837] [SVE] Poor vector construction code in VL-specific mode

2019-06-03 Thread prathamesh3492 at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88837

--- Comment #1 from prathamesh3492 at gcc dot gnu.org ---
Author: prathamesh3492
Date: Mon Jun  3 09:35:37 2019
New Revision: 271857

URL: https://gcc.gnu.org/viewcvs?rev=271857=gcc=rev
Log:
2019-06-03  Prathamesh Kulkarni  

PR target/88837
* vector-builder.h (vector_builder::count_dups): New method.
* config/aarch64/aarch64-protos.h (aarch64_expand_sve_vector_init):
Declare prototype.
* config/aarch64/aarch64/sve.md (aarch64_sve_rev64): Use @.
(vec_init): New pattern.
* config/aarch64/aarch64.c (emit_insr): New function.
(aarch64_sve_expand_vector_init_handle_trailing_constants): Likewise.
(aarch64_sve_expand_vector_init_insert_elems): Likewise.
(aarch64_sve_expand_vector_init_handle_trailing_same_elem): Likewise.
(aarch64_sve_expand_vector_init): Define two overloaded functions.

testsuite/
* gcc.target/aarch64/sve/init_1.c: New test.
* gcc.target/aarch64/sve/init_1_run.c: Likewise.
* gcc.target/aarch64/sve/init_2.c: Likewise.
* gcc.target/aarch64/sve/init_2_run.c: Likewise.
* gcc.target/aarch64/sve/init_3.c: Likewise.
* gcc.target/aarch64/sve/init_3_run.c: Likewise.
* gcc.target/aarch64/sve/init_4.c: Likewise.
* gcc.target/aarch64/sve/init_4_run.c: Likewise.
* gcc.target/aarch64/sve/init_5.c: Likewise.
* gcc.target/aarch64/sve/init_5_run.c: Likewise.
* gcc.target/aarch64/sve/init_6.c: Likewise.
* gcc.target/aarch64/sve/init_6_run.c: Likewise.
* gcc.target/aarch64/sve/init_7.c: Likewise.
* gcc.target/aarch64/sve/init_7_run.c: Likewise.
* gcc.target/aarch64/sve/init_8.c: Likewise.
* gcc.target/aarch64/sve/init_8_run.c: Likewise.
* gcc.target/aarch64/sve/init_9.c: Likewise.
* gcc.target/aarch64/sve/init_9_run.c: Likewise.
* gcc.target/aarch64/sve/init_10.c: Likewise.
* gcc.target/aarch64/sve/init_10_run.c: Likewise.
* gcc.target/aarch64/sve/init_11.c: Likewise.
* gcc.target/aarch64/sve/init_11_run.c: Likewise.
* gcc.target/aarch64/sve/init_12.c: Likewise.
* gcc.target/aarch64/sve/init_12_run.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.target/aarch64/sve/init_1.c
trunk/gcc/testsuite/gcc.target/aarch64/sve/init_10.c
trunk/gcc/testsuite/gcc.target/aarch64/sve/init_10_run.c
trunk/gcc/testsuite/gcc.target/aarch64/sve/init_11.c
trunk/gcc/testsuite/gcc.target/aarch64/sve/init_11_run.c
trunk/gcc/testsuite/gcc.target/aarch64/sve/init_12.c
trunk/gcc/testsuite/gcc.target/aarch64/sve/init_12_run.c
trunk/gcc/testsuite/gcc.target/aarch64/sve/init_1_run.c
trunk/gcc/testsuite/gcc.target/aarch64/sve/init_2.c
trunk/gcc/testsuite/gcc.target/aarch64/sve/init_2_run.c
trunk/gcc/testsuite/gcc.target/aarch64/sve/init_3.c
trunk/gcc/testsuite/gcc.target/aarch64/sve/init_3_run.c
trunk/gcc/testsuite/gcc.target/aarch64/sve/init_4.c
trunk/gcc/testsuite/gcc.target/aarch64/sve/init_4_run.c
trunk/gcc/testsuite/gcc.target/aarch64/sve/init_5.c
trunk/gcc/testsuite/gcc.target/aarch64/sve/init_5_run.c
trunk/gcc/testsuite/gcc.target/aarch64/sve/init_6.c
trunk/gcc/testsuite/gcc.target/aarch64/sve/init_6_run.c
trunk/gcc/testsuite/gcc.target/aarch64/sve/init_7.c
trunk/gcc/testsuite/gcc.target/aarch64/sve/init_7_run.c
trunk/gcc/testsuite/gcc.target/aarch64/sve/init_8.c
trunk/gcc/testsuite/gcc.target/aarch64/sve/init_8_run.c
trunk/gcc/testsuite/gcc.target/aarch64/sve/init_9.c
trunk/gcc/testsuite/gcc.target/aarch64/sve/init_9_run.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64-protos.h
trunk/gcc/config/aarch64/aarch64-sve.md
trunk/gcc/config/aarch64/aarch64.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/vector-builder.h

[Bug ipa/90720] New: g++.dg/lto/alias-1 FAILs

2019-06-03 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90720

Bug ID: 90720
   Summary: g++.dg/lto/alias-1 FAILs
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org
  Target Milestone: ---
Target: *-*-solaris2.11

The new g++.dg/lto/alias-1 test FAILs on Solaris, 32 and 64-bit, sparc and x86:

+FAIL: g++.dg/lto/alias-1 cp_lto_alias-1_0.o-cp_lto_alias-1_1.o execute  -O2
-flto 

Thread 2 received signal SIGABRT, Aborted.
[Switching to Thread 1 (LWP 1)]
0xfe29f7d5 in __lwp_sigqueue () from /lib/libc.so.1
(gdb) where
#0  0xfe29f7d5 in __lwp_sigqueue () from /lib/libc.so.1
#1  0xfe2980af in thr_kill () from /lib/libc.so.1
#2  0xfe1d986a in raise () from /lib/libc.so.1
#3  0xfe1ab84e in abort () from /lib/libc.so.1
#4  0x08050ddf in main (argc=1, argv=0xfeffd95c)
at /vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/lto/alias-1_0.C:29

  if (!__builtin_constant_p (aptr == 0))
__builtin_abort ();

[Bug ipa/90720] g++.dg/lto/alias-1 FAILs

2019-06-03 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90720

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug tree-optimization/90681] [10 Regression] ICE in vect_slp_analyze_node_operations_1, at tree-vect-slp.c:2513 since r271704

2019-06-03 Thread alejandro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90681

--- Comment #4 from alejandro at gcc dot gnu.org ---
Author: alejandro
Date: Mon Jun  3 09:13:32 2019
New Revision: 271856

URL: https://gcc.gnu.org/viewcvs?rev=271856=gcc=rev
Log:
Fix ICE in vect_slp_analyze_node_operations_1

This patch fixes bug 90681.  It was caused by trying to SLP vectorize a non
groupped load.  We've fixed it by tweaking a bit the implementation: mark
masked loads as not vectorizable, but support them as an special case.  Then
the detect them in the test for normal non-groupped loads that was already
there.


Added:
trunk/gcc/testsuite/gfortran.dg/vect/pr90681.f
Modified:
trunk/gcc/ChangeLog
trunk/gcc/internal-fn.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-slp.c

[Bug testsuite/90713] [10 regression] FAIL: gcc.dg/gimplefe-40.c (internal compiler error)

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Mon Jun  3 09:03:48 2019
New Revision: 271855

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

PR testsuite/90713
* gcc.dg/gimplefe-40.c: Add -maltivec for powerpc.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/gimplefe-40.c

[Bug testsuite/90713] [10 regression] FAIL: gcc.dg/gimplefe-40.c (internal compiler error)

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug testsuite/90713] [10 regression] FAIL: gcc.dg/gimplefe-40.c (internal compiler error)

2019-06-03 Thread rguenther at suse dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90713

--- Comment #3 from rguenther at suse dot de  ---
On Mon, 3 Jun 2019, segher at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90713
> 
> Segher Boessenkool  changed:
> 
>What|Removed |Added
> 
>  Status|UNCONFIRMED |NEW
>Last reconfirmed||2019-06-03
>  Ever confirmed|0   |1
> 
> --- Comment #2 from Segher Boessenkool  ---
> Confirmed.  And confirmed that the testcase works fine with -maltivec.
> 
> vect_float is the wrong selector to see if vectors of float are enabled by
> current compiler options:
> 
> # Return 1 if the target supports hardware vectors of float when
> # -funsafe-math-optimizations is enabled, 0 otherwise.
> #
> # This won't change for different subtargets so cache the result.
> 
> This testcase will need a test to see if there are 16 byte vector floats.
> Something that just tries to create a
>   typedef float v4sf __attribute__((vector_size(16)));
> variable should do fine.
> 
> Oh, and the gimple front end shouldn't ICE the compiler, of course :-/

The GIMPLE FE expects valid GIMPLE - but yes, the GIMPLE verifier
lacks verification of certain vector target constraints so we end
up ICEing in the expander or lowering things unexpectedly.

The GIMPLE FE is a unit-testing / debugging tool, not a "proper"
frontend ;)

I guess I'll add { dg-additional-options "-maltivec" { target powerpc*-*-* 
} }

[Bug tree-optimization/90697] ia64: segmentation fault during GIMPLE pass: dom

2019-06-03 Thread rguenther at suse dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90697

--- Comment #5 from rguenther at suse dot de  ---
On Mon, 3 Jun 2019, glaubitz at physik dot fu-berlin.de wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90697
> 
> --- Comment #4 from John Paul Adrian Glaubitz  fu-berlin.de> ---
> (In reply to Richard Biener from comment #3)
> > I can't reproduce this.  Matthias, IIRC the debian version is not 8.3.0 but
> > patched - to which rev?
> 
> That's currently SVN 20190428 (r270630), see [1].
> 
> > [1] 
> > http://metadata.ftp-master.debian.org/changelogs/main/g/gcc-8/gcc-8_8.3.0-7_changelog

OK, with that rev. and a simple cross cc1 to ia64-linux the issue doesn't
reproduce on a x86_64 host:

> ./cc1 -quiet /tmp/t.i -O3 -I include -g -fPIC -fno-strict-overflow 
-fstack-protector-all -std=c11 -fomit-frame-pointer -fno-math-errno 
-fno-signed-zeros -fno-tree-vectorize
>

[Bug libfortran/77278] Use LTO for libgfortran

2019-06-03 Thread rguenther at suse dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278

--- Comment #8 from rguenther at suse dot de  ---
On Sun, 2 Jun 2019, tkoenig at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278
> 
> --- Comment #6 from Thomas Koenig  ---
...
> So, dt_parm_1 is still filled with information in the tight loop
> (which the library does not change), and the call to
> transfer_real_write.constprop does not do a lot of the things
> that could be done in theory, for example keeping the unit
> number cached, take a note that this is not asynchronous,
> that we always use "NO" on advance in the loop, etc.
> 
> So, is it realistic to expect that LTO could do this kind
> of thing with the very complex structure that libgfortran?

Sure, why not.  Of course the original motivation wasn't so
much I/O but inlining/optimizing intrinsics.  The frontend
does a lot more inlining itself here today so the effect
might not be as big.

[Bug c++/26989] C++ front-end (and others parts of GCC) use the wrong check to see if hidden visibility is there

2019-06-03 Thread iains at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26989

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #10 from Iain Sandoe  ---
(In reply to Jonathan Wakely from comment #9)
> The G++ code now uses:
> 
>   if (is_attribute_p ("visibility", name))
> 
> and the test that was failing uses:
> 
> // { dg-require-visibility "" }
> 
> which also depends on whether the attribute is supported:
> 
> ###
> # proc check_visibility_available { what_kind }
> ###
> 
> # The visibility attribute is only support in some object formats
> # This proc returns 1 if it is supported, 0 if not.
> # The argument is the kind of visibility, default/protected/hidden/internal.
> 
> proc check_visibility_available { what_kind } {
> if [string match "" $what_kind] { set what_kind "hidden" }
> 
> return [check_no_compiler_messages visibility_available_$what_kind
> object "
>   void f() __attribute__((visibility(\"$what_kind\")));
>   void f() {}
> "]
> }
> 
> So I think this is probably doing the right thing for all targets now.

Yeah, the attribute is supported on Darwin at least back to Darwin8, and as
noted, earlier systems won't bootstrap without a tools update (which would
include such support). So I think we can close this as 'fixed by the passage of
time'.

[Bug d/90719] libphobos.phobos_shared/std/file.d FAILs on 32-bit Solaris

2019-06-03 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90719

--- Comment #1 from Rainer Orth  ---
Created attachment 46445
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46445=edit
Proposed patch

[Bug d/90719] libphobos.phobos_shared/std/file.d FAILs on 32-bit Solaris

2019-06-03 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90719

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |9.2

[Bug middle-end/32503] __builtin_pow[i] - vectorize for other exponents besides 2 and 0.5

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed|2007-06-26 10:47:05 |2019-6-3
 Blocks||53947
Summary|__builtin_powi - optimize   |__builtin_pow[i] -
   |for other exponents besides |vectorize for other
   |2 and 0.5   |exponents besides 2 and 0.5

--- Comment #5 from Richard Biener  ---
(In reply to Eric Gallager from comment #4)
> (In reply to Richard Biener from comment #2)
> > Confirmed.  I had done tree-level expansion of powi into add/mul sequences 
> > at
> > one time.  But this had been rejected for some reason I cannot remember
> > right now.
> 
> Do you at least remember when that time was, so we can know where to go
> looking in the archives?

See the followup comment.  We now do this expansion but it is too late
for vectorization.  The vectorizer knows how to handle pow of a
constant via exp[2] which have vectorized variants.  It also knows
square-root and square but doesn't try anything more fancy.  See
vect_recog_pow_pattern.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations

[Bug d/90719] New: libphobos.phobos_shared/std/file.d FAILs on 32-bit Solaris

2019-06-03 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90719

Bug ID: 90719
   Summary: libphobos.phobos_shared/std/file.d FAILs on 32-bit
Solaris
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
Target: *-*-solaris2.11

libphobos.phobos_shared/std/file.d currently FAILs on 32-bit Solaris:

FAIL: libphobos.phobos_shared/std/file.d execution test

core.exception.AssertError@/vol/gcc/src/hg/trunk/solaris/libphobos/testsuite/../src/std/file.d(1040):
unittest failure

[2000-Feb-03 23:12:09.5593787] [2000-Feb-04 01:09:39.5593787] [2019-Jun-01
10:45:13.9496087] [-1008 weeks, -1 days, -10 hours, -33 minutes, -4 secs, -390
ms, and -230 μs] [-1008 weeks, -1 days, -8 hours, -35 minutes, -34 secs, -390
ms, and -230 μs]

It turns out there's another mismatch between the system and druntime
declarations, this time affecting struct stat:

Solaris 11  has

struct  stat {
dev_t   st_dev;
longst_pad1[3]; /* reserved for network id */
ino_t   st_ino;
mode_t  st_mode;
nlink_t st_nlink;
uid_t   st_uid;
gid_t   st_gid;
dev_t   st_rdev;
longst_pad2[2];
off_t   st_size;
#if _FILE_OFFSET_BITS != 64
longst_pad3;/* future off_t expansion */
#endif
timespec_t  st_atim;
timespec_t  st_mtim;
timespec_t  st_ctim;
blksize_t   st_blksize;
blkcnt_tst_blocks;
charst_fstype[_ST_FSTYPSZ];
longst_pad4[8]; /* expansion area */
};

while libdruntime/core/sys/posix/sys/stat.d has

struct stat32_t
{
dev_t st_dev;
c_long[3] st_pad1;
ino_t st_ino;
mode_t st_mode;
nlink_t st_nlink;
uid_t st_uid;
gid_t st_gid;
dev_t st_rdev;
c_long[2] st_pad2;
off_t st_size;
c_long st_pad3;
union
{
timestruc_t st_atim;
time_t  st_atime;
}
union
{
timestruc_t st_mtim;
time_t  st_mtime;
}
union
{
timestruc_t st_ctim;
time_t  st_ctime;
}
blksize_t st_blksize;
blkcnt_t st_blocks;
char[_ST_FSTYPSZ] st_fstype = 0;
c_long[8] st_pad4;
}

static if (__USE_FILE_OFFSET64)
alias stat64_t stat_t;
else
alias stat32_t stat_t;

i.e. st_pad3 is included in the non-largefile version of struct stat when it
shouldn't be.

Fixed by the attached patch which lets the test PASS.

[Bug libfortran/77278] Use LTO for libgfortran

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

--- Comment #7 from Richard Biener  ---
(In reply to Thomas Koenig from comment #5)
> One thing we would also have to tackle is GFC_LOGICAL arguments.
> C only has one bool type, which is (for gcc) equivalent to
> logical(kind=1).  We might just get by with 
> 
> typedef enum { _zero=1, _one=1 } GFC_LOGICAL_4;
> 
> but what about arguments with other logical types?
> We might actually need a C extension there, or disable
> aliasing-based optimization.

aliasing shouldn't be an issue here.  The other logical kinds need to
be mapped to short/int/long anyways for ABI reasons, no?

[Bug c++/26989] C++ front-end (and others parts of GCC) use the wrong check to see if hidden visibility is there

2019-06-03 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26989

--- Comment #9 from Jonathan Wakely  ---
The G++ code now uses:

  if (is_attribute_p ("visibility", name))

and the test that was failing uses:

// { dg-require-visibility "" }

which also depends on whether the attribute is supported:

###
# proc check_visibility_available { what_kind }
###

# The visibility attribute is only support in some object formats
# This proc returns 1 if it is supported, 0 if not.
# The argument is the kind of visibility, default/protected/hidden/internal.

proc check_visibility_available { what_kind } {
if [string match "" $what_kind] { set what_kind "hidden" }

return [check_no_compiler_messages visibility_available_$what_kind object "
void f() __attribute__((visibility(\"$what_kind\")));
void f() {}
"]
}

So I think this is probably doing the right thing for all targets now.

[Bug fortran/90608] Inline non-scalar minloc/maxloc calls

2019-06-03 Thread ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90608

--- Comment #3 from ktkachov at gcc dot gnu.org ---
(In reply to Thomas Koenig from comment #1)
> Another, not mutually exclusive approach would be to make libgfortran LTO
> clean so the more complex minloc etc calls could be pulled in.

Interesting. What would it take to build libgfortran with LTO? Is it just a
matter of adding -flto to then right build flags?

[Bug testsuite/90713] [10 regression] FAIL: gcc.dg/gimplefe-40.c (internal compiler error)

2019-06-03 Thread segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90713

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #2 from Segher Boessenkool  ---
Confirmed.  And confirmed that the testcase works fine with -maltivec.

vect_float is the wrong selector to see if vectors of float are enabled by
current compiler options:

# Return 1 if the target supports hardware vectors of float when
# -funsafe-math-optimizations is enabled, 0 otherwise.
#
# This won't change for different subtargets so cache the result.

This testcase will need a test to see if there are 16 byte vector floats.
Something that just tries to create a
  typedef float v4sf __attribute__((vector_size(16)));
variable should do fine.

Oh, and the gimple front end shouldn't ICE the compiler, of course :-/

[Bug d/90718] libphobos.phobos_shared/std/socket.d FAILs on 32-bit Solaris/SPARC

2019-06-03 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90718

--- Comment #1 from Rainer Orth  ---
Created attachment 46444
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46444=edit
Proposed patch

[Bug d/90718] libphobos.phobos_shared/std/socket.d FAILs on 32-bit Solaris/SPARC

2019-06-03 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90718

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |9.2

[Bug tree-optimization/90697] ia64: segmentation fault during GIMPLE pass: dom

2019-06-03 Thread glaubitz at physik dot fu-berlin.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90697

--- Comment #4 from John Paul Adrian Glaubitz  ---
(In reply to Richard Biener from comment #3)
> I can't reproduce this.  Matthias, IIRC the debian version is not 8.3.0 but
> patched - to which rev?

That's currently SVN 20190428 (r270630), see [1].

> [1] 
> http://metadata.ftp-master.debian.org/changelogs/main/g/gcc-8/gcc-8_8.3.0-7_changelog

[Bug d/90718] New: libphobos.phobos_shared/std/socket.d FAILs on 32-bit Solaris/SPARC

2019-06-03 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90718

Bug ID: 90718
   Summary: libphobos.phobos_shared/std/socket.d FAILs on 32-bit
Solaris/SPARC
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
Target: sparc*-*-solaris2.11

The libphobos.phobos_shared/std/socket.d test FAILs on 32-bit Solaris/SPARC:

Thread 2 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0x00043eb4 in std.socket.getAddressInfoImpl(const(char[]), const(char[]),
core.sys.posix.netdb.addrinfo*) (node=..., service=..., hints=0xffbfddd4)
at
/vol/gcc/src/hg/trunk/solaris/libphobos/testsuite/../src/std/socket.d:1006
1006cast(AddressFamily) ai.ai_family,

1: x/i $pc
=> 0x43eb4
<_D3std6socket18getAddressInfoImplFxAaxAaPS4core3sys5posix5netdb8addrinfoZAS3std6socket11AddressInfo+504>:
  ld  [ %g1 + 4 ], %g1
(gdb) p/x $g1
$1 = 0x21

The first time through, ai is

$9 = {ai_flags = 0, ai_family = 2, ai_socktype = 0, ai_protocol = 0, 
  _ai_pad = 16, ai_addrlen = 0, ai_canonname = 0xac710 "", ai_addr = 0xac4c0, 
  ai_next = 0x21}

i.e. ai_next is bogus.

Comparing the struct addrinfo declarations in 

struct addrinfo {
int ai_flags;   /* AI_PASSIVE, AI_CANONNAME, ... */
int ai_family;  /* PF_xxx */
int ai_socktype;/* SOCK_xxx */
int ai_protocol;/* 0 or IPPROTO_xxx for IPv4 and IPv6 */
#ifdef __sparcv9
int _ai_pad;/* for backwards compat with old size_t */
#endif /* __sparcv9 */
socklen_t ai_addrlen;
char *ai_canonname; /* canonical name for hostname */
struct sockaddr *ai_addr;   /* binary address */
struct addrinfo *ai_next;   /* next structure in linked list */
};

and libdruntime/core/sys/posix/netdb.d

struct addrinfo
{
int ai_flags;
int ai_family;
int ai_socktype;
int ai_protocol;

version (SPARC)
int _ai_pad;
else version (SPARC64)
int _ai_pad;

socklen_t ai_addrlen;
char* ai_canonname;
sockaddr* ai_addr;
addrinfo* ai_next;
}

There's a mismatch here: the system version has no _ai_pad member on 32-bit
SPARC; no idea how this crept into the druntime version.

Fixing as in the attached patch lets the test get further along.  It still
FAILs
however:

Aborting from
/vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/gcc/sections/elf_shared.d(724)
DSO already registered.

but this is a different issue affecting a couple of other tests as well.

[Bug debug/90717] wrong stmt location for breakpoint, XFAIL gcc.dg/guality/pr90716.c -flto -fuse-linker-plugin

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-debug
 CC||aoliva at gcc dot gnu.org
 Blocks||90716

--- Comment #1 from Richard Biener  ---
Alex?  Even in .final t.c:23 is only mentioned after all locations for b/j,
while we want to preserve them we only want the "last" value, not all views
on a instruction for line 23.  At least until gdb has better support for
location views?

(note 476 553 477 2 t.c:16 NOTE_INSN_BEGIN_STMT)
(note 477 476 478 2 t.c:17 NOTE_INSN_BEGIN_STMT)
(note 478 477 554 2 t.c:16 NOTE_INSN_BEGIN_STMT)
(note 554 478 479 2 (var_location j (const_int 8 [0x8]))
NOTE_INSN_VAR_LOCATION)
(note 479 554 480 2 t.c:16 NOTE_INSN_BEGIN_STMT)
(note 480 479 555 2 t.c:14 NOTE_INSN_BEGIN_STMT)
(note 555 480 481 2 (var_location b (const_int 7 [0x7]))
NOTE_INSN_VAR_LOCATION)
(note 481 555 482 2 t.c:14 NOTE_INSN_BEGIN_STMT)
(note 482 481 286 2 t.c:23 NOTE_INSN_BEGIN_STMT)
(insn:TI 286 482 272 2 (parallel [
(set (reg:DI 0 ax)
(const_int 0 [0]))
(clobber (reg:CC 17 flags))
]) "t.c":23:3 60 {*movdi_xor}
 (expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
(call_insn:TI 272 286 483 2 (call (mem:QI (symbol_ref:DI ("optimize_me_not")
[flags 0x3]  ) [0 optimize_me_not
S1 A8])
(const_int 0 [0])) "t.c":23:3 666 {*call}
 (expr_list:REG_CALL_ARG_LOCATION (nil)
(expr_list:REG_DEAD (reg:QI 0 ax)
(expr_list:REG_CALL_DECL (symbol_ref:DI ("optimize_me_not") [flags
0x3]  )
(expr_list:REG_EH_REGION (const_int 0 [0])
(nil)
(expr_list (use (reg:QI 0 ax))
(nil)))
(note 483 272 287 2 t.c:24 NOTE_INSN_BEGIN_STMT)
(insn 287 483 279 2 (parallel [
(set (reg:DI 0 ax)
(const_int 0 [0]))
(clobber (reg:CC 17 flags))
]) "t.c":25:1 60 {*movdi_xor}
 (expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
(insn 279 287 288 2 (use (reg/i:SI 0 ax)) "t.c":25:1 -1
 (nil))


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90716
[Bug 90716] [10 Regression] gcc generates wrong debug information at -O2

[Bug debug/90717] New: wrong stmt location for breakpoint, XFAIL gcc.dg/guality/pr90716.c -flto -fuse-linker-plugin

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

Bug ID: 90717
   Summary: wrong stmt location for breakpoint, XFAIL
gcc.dg/guality/pr90716.c -flto -fuse-linker-plugin
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

The gcc.dg/guality/pr90716.c testcase fails with -O2 -fwhole-program,
expanding from

main ()
{
   [local count: 17041817]:
  [t.c:12:3] # DEBUG BEGIN_STMT
  [t.c:13:3] # DEBUG BEGIN_STMT
  [t.c:13:5] # DEBUG b => 0
  [t.c:14:3] # DEBUG BEGIN_STMT
  # DEBUG b => 0
  [t.c:14:10] # DEBUG BEGIN_STMT
  # DEBUG j => 0
  [t.c:16:14] # DEBUG BEGIN_STMT
... unrolled loop ...
  [t.c:16:14] # DEBUG BEGIN_STMT
  [t.c:17:2] # DEBUG BEGIN_STMT
  [t.c:16:21] # DEBUG BEGIN_STMT
  # DEBUG j => 8
  [t.c:16:14] # DEBUG BEGIN_STMT
  [t.c:14:17] # DEBUG BEGIN_STMT
  # DEBUG b => 7
  [t.c:14:10] # DEBUG BEGIN_STMT
  [t.c:23:3] # DEBUG BEGIN_STMT
  [t.c:23:3] optimize_me_not ();
  [t.c:24:3] # DEBUG BEGIN_STMT
  return 0;

gdb puts the breakpoint at

Breakpoint 1, main ()
at
/space/rguenther/src/svn/trunk2/gcc/testsuite/gcc.dg/guality/pr90716.c:23
23optimize_me_not(); /* { dg-final { gdb-test . "j + 1" "9" } } */
(gdb) disassemble
Dump of assembler code for function main:
=> 0x004003e0 <+0>: xor%eax,%eax
   0x004003e2 <+2>: callq  0x4004d0 
   0x004003e7 <+7>: xor%eax,%eax
   0x004003e9 <+9>: retq   

where

(gdb) p j
$1 = 0

but at the "correct" location the correct value is displayed.

(gdb) si
0x004003e2  23optimize_me_not(); /* { dg-final { gdb-test .
"j + 1" "9" } } */
(gdb) p j
$2 = 8

Somehow things must go wrong on the RTL / debuginfo creation level putting
the location views for 'j' on a assembler stmt associated with line 23.

[Bug debug/90716] [10 Regression] gcc generates wrong debug information at -O2

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
Version|unknown |10.0
   Keywords||wrong-debug
   Last reconfirmed||2019-06-03
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1
Summary|gcc generates wrong debug   |[10 Regression] gcc
   |information at -O2  |generates wrong debug
   ||information at -O2
   Target Milestone|--- |10.0

--- Comment #1 from Richard Biener  ---
Confirmed.  loop-distribution performs manual removal of the old loop body
in destroy_loop () but it moves debug stmts in bogus order.

I have a patch.

[Bug c++/26989] C++ front-end (and others parts of GCC) use the wrong check to see if hidden visibility is there

2019-06-03 Thread iains at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26989

--- Comment #8 from Iain Sandoe  ---
(In reply to Jonathan Wakely from comment #7)
> Cc Iain who probably knows more about the Darwin linker. I'm pretty sure it
> supports visibility now because LLVM's libc++ makes extensive use of
> visibility attributes.

hmm... Darwin7 ...

Well... as things stand Darwin7 will not bootstrap even gcc-4.6 with its system
toolchain [xcode 1.5] (it fails very early with "make is too old") I haven't
figured a recipe for the minimum number of tools that need to be upgraded yet
(and it's frankly very low priority).



However, that being said - we should verify that the test is appropriate to
newer systems too (or even still exists?)

[Bug c++/26989] C++ front-end (and others parts of GCC) use the wrong check to see if hidden visibility is there

2019-06-03 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26989

Jonathan Wakely  changed:

   What|Removed |Added

 CC||iains at gcc dot gnu.org

--- Comment #7 from Jonathan Wakely  ---
Cc Iain who probably knows more about the Darwin linker. I'm pretty sure it
supports visibility now because LLVM's libc++ makes extensive use of visibility
attributes.

[Bug testsuite/90713] [10 regression] FAIL: gcc.dg/gimplefe-40.c (internal compiler error)

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

Richard Biener  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org
  Component|middle-end  |testsuite

--- Comment #1 from Richard Biener  ---
This means that V4SF is not a supported vector type despite { target {
vect_float } }.  I suppose -maltivec is needed here, but why does vect_float
not verify that is provided?

[Bug testsuite/90713] [10 regression] FAIL: gcc.dg/gimplefe-40.c (internal compiler error)

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug target/90712] [10 regression] gcc.dg/rtl/aarch64/subs_adds_sp.c fails with ICE

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |10.0
   Target Milestone|--- |10.0

[Bug tree-optimization/90697] ia64: segmentation fault during GIMPLE pass: dom

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

Richard Biener  changed:

   What|Removed |Added

 CC||doko at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #3 from Richard Biener  ---
I can't reproduce this.  Matthias, IIRC the debian version is not 8.3.0 but
patched - to which rev?

[Bug middle-end/90694] incorrect representation of ADDR_EXPR involving a pointer to array

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

--- Comment #6 from Richard Biener  ---
(In reply to Richard Biener from comment #5)
> Just as a note - the tree/GIMPLE dumps are not C source code so 
> this kind of "issues" are expected.  Watch out for testsuite fallout.

For the latter esp. tests with scan-tree-dump-not might no longer be
testing what they were supposed to ...

[Bug middle-end/90694] incorrect representation of ADDR_EXPR involving a pointer to array

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

--- Comment #5 from Richard Biener  ---
Just as a note - the tree/GIMPLE dumps are not C source code so 
this kind of "issues" are expected.  Watch out for testsuite fallout.