date:20190909

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Fixed.

[Bug c++/84374] placeholder decltype(auto) accepted when it's not the placeholder alone in trailing-return-type

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

--- Comment #3 from Marek Polacek  ---
Author: mpolacek
Date: Tue Sep 10 02:29:13 2019
New Revision: 275557

URL: https://gcc.gnu.org/viewcvs?rev=275557=gcc=rev
Log:
PR c++/84374 - diagnose invalid uses of decltype(auto).
* decl.c (grokdeclarator): Diagnose wrong usage of decltype(auto) in
a function declaration.

* g++.dg/cpp1y/auto-fn57.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/auto-fn57.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/91369] Implement P0784R7: constexpr new

2019-09-09 Thread jason at gcc dot gnu.org

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

--- Comment #2 from Jason Merrill  ---
(In reply to Jakub Jelinek from comment #1)
> So, first of all, is it a good idea to represent the HEAP variables through
> artifical VAR_DECLs?

That makes sense to me.

> I guess in the outermost constexpr evaluation context we'd need to track
> which of those we have allocated and deallocated and do the checking that at
> the end of outermost constexpr evaluation no allocations are left around,

Sounds right.

> and that we don't deallocate something that hasn't been allocated.

I'd expect that to be detected during evaluation when we try to deallocate
something that isn't constant or isn't the address of one of these artificial
VAR_DECLs.

> As we don't have the actual dynamic type they will have at the end of new
> expression

We should really fix that.  Perhaps we should delay lowering new-expressions
until genericization time?

> should we mark them some way and either allow the first
> cxx_fold_indirect_ref or the above code to change their type the first time
> they are stored?

This would work, but wouldn't distinguish between a new-expression and the
equivalent written by hand.  I suppose a flag could make that distinction.

> Is placement new ok in constexpr contexts or not?

No, placement new is not replaceable.

> Can the global replaceable allocation functions be marked constexpr by the
> user?

No.

> For the constexpr dtors, we need to make sure to mark trivial dtors as
> constexpr, and default dtors as constexpr if they satisfy the rules, verify
> the restrictions for user defined constexpr dtors, and check for constexpr
> dtor in literal type check.  Plus guess for constexpr variables we need to
> at some point verify they are constexpr destructible (but on a copy of the
> variable value, such that changes to the value during destruction don't
> modify the actual value of the variable we use normally).

Right.  I think that's implied by the passage "An object a is said to have
constant destruction if ... for a hypothetical expression e whose only effect
is to destroy a, e would be a core constant expression if the lifetime of a and
its non-mutable subobjects (but not its mutable subobjects) were considered to
start within e."

[Bug target/91683] ICE: SIGSEGV at -O when compiling for riscv64

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

--- Comment #14 from Jim Wilson  ---
> 3) Do we want to prohibit calling gen_reg_rtx during combine?  Why did
> we want it, before?

Prohibiting gen_reg_rtx calls here would have helped find the bugs I'm fixing
now.  I've got a hack to do this to find the remaining bugs I need to fix.

I don't know why anyone would want it before.  I'm not sure if this ever worked
right.

[Bug target/91683] ICE: SIGSEGV at -O when compiling for riscv64

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

--- Comment #13 from Segher Boessenkool  ---
1) Yes, you'll be better of without calling gen_reg_rtx, certainly.

2) I don't see how you can make the undo scheme support this, without
big cost and/or big restructuring.

If we can replace this scheme by something much more local, that would
be great, it is one of the biggest problems combine has (others are the
sheer amount of garbage rtl it makes, and all the special cases it has
accumulated over the years).

3) Do we want to prohibit calling gen_reg_rtx during combine?  Why did
we want it, before?

[Bug target/91683] ICE: SIGSEGV at -O when compiling for riscv64

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

--- Comment #12 from Jim Wilson  ---
(In reply to Segher Boessenkool from comment #11)
> Oh lol, I finally wake up.  It is called from the splitter.  That isn't
> really a valid thing to do.

Right.  I want to eliminate that.

> We have some limited support for that since a while, but it seems this
> cannot ever really work?

Maybe with changes to the combine undo buffer, but there is still the lack of
REG_DEAD notes that can cause problems, so I think I'm still better off
avoiding calling gen_reg_rtx from splitters.

[Bug target/91683] ICE: SIGSEGV at -O when compiling for riscv64

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

--- Comment #11 from Segher Boessenkool  ---
Oh lol, I finally wake up.  It is called from the splitter.  That isn't
really a valid thing to do.

We have some limited support for that since a while, but it seems this
cannot ever really work?

[Bug target/91683] ICE: SIGSEGV at -O when compiling for riscv64

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

--- Comment #10 from Segher Boessenkool  ---
(In reply to Segher Boessenkool from comment #9)
> So when was the array reallocated?  combine does in general rely on all
> rtxen to stay in place, etc.

Ah pretty much directly from gen_reg_rtx.  Bah.  So where was that called from?

[Bug target/91683] ICE: SIGSEGV at -O when compiling for riscv64

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

--- Comment #9 from Segher Boessenkool  ---
So when was the array reallocated?  combine does in general rely on all
rtxen to stay in place, etc.

[Bug target/91683] ICE: SIGSEGV at -O when compiling for riscv64

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

--- Comment #8 from Jim Wilson  ---
(In reply to Richard Biener from comment #3)
> Hmm, but shouldn't we instead fix combine to record not the reg rtx but the
> regno for UNDO_MODE?  Because nothing prevents this from happening elsewhere
> (even in combine itself?).

Changing do_SUBST_MODE to save the regno instead of the address of rhe reg rtx
is a possible solution, but can work only if there is no other place in combine
that might take the address of a reg rtx.  I can't be sure of that unless I do
more analysis, which I don't plan to do as I don't think this is the right
solution.

Also, I think I will get better code if I fix the splitters to use a clobber. 
As was mentioned in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91635#c19 ,
calling gen_reg_rtx means no REG_DEAD note which limits what combine can do,
whereas using a clobber means getting an existing reg that likely already has a
REG_DEAD note which helps combine.

[Bug target/91683] ICE: SIGSEGV at -O when compiling for riscv64

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

--- Comment #7 from Jim Wilson  ---
> Would --param=ggc-min-expand=0 and/or --param=ggc-min-heapsize=0 help to
> reproduce the issue?

I don't think so.  The problem occurs in ensure_regno_capacity, which isn't
affected by frequency of garbage collection.  It is only affected by the number
of gen_reg_rtx calls.

It is already the case that ggc_free overwrites freed memory with 0xa5 when
ENABLE_GC_CHECKING is on, that is what exposed the problem.

[Bug target/91683] ICE: SIGSEGV at -O when compiling for riscv64

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

--- Comment #6 from Jim Wilson  ---
(In reply to Richard Biener from comment #4)
> Btw, the rtx of pseudos doesn't change, what changes is the address of the
> entry in regno_reg_rtx[] which is the pseudo-nr -> rtx map.  But I don't see
> that involved...

do_SUBST_MODE saves the address of the rtx being modified, in this case the
address of a pseudo reg.

Breakpoint 5, do_SUBST_MODE (into=0x76280458, newval=E_DImode)
at ../../gcc-svn/gcc/combine.c:809
(gdb) print into
$5 = (rtx *) 0x76280458
(gdb) print *into
$6 = (rtx) 0x76287630
(gdb) pr
warning: Expression is not an assignment (and might have no effect)
(reg:SI 139)
(gdb) print regno_reg_rtx[139]
$7 = (rtx) 0x76287630
(gdb) print _reg_rtx[139]
$8 = (rtx *) 0x76280458
(gdb) 

So into is an address into regno_reg_rtx.  When we realloc regno_reg_rtx this
changes.

Breakpoint 6, emit_status::ensure_regno_capacity (this=0x1a881f0 )
at ../../gcc-svn/gcc/emit-rtl.c:1215
(gdb) next 6
(gdb) print regno_reg_rtx[139]
$13 = (rtx) 0x76287630
(gdb) print _reg_rtx[139]
$14 = (rtx *) 0x7627b458
(gdb) print $5
$15 = (rtx *) 0x76280458
(gdb) print *$5
$16 = (rtx) 0xa5a5a5a5a5a5a5a5
(gdb)

[Bug c++/91705] [9/10 Regression] operator++ broken in constexpr floating point code

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug target/91683] ICE: SIGSEGV at -O when compiling for riscv64

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

--- Comment #5 from Jim Wilson  ---
(In reply to Richard Biener from comment #3)
> Hmm, but shouldn't we instead fix combine to record not the reg rtx but the
> regno for UNDO_MODE?  Because nothing prevents this from happening elsewhere
> (even in combine itself?).

Combine doesn't call gen_reg_rtx, other than make_more_copies, and splitters
aren't supposed to either.  As Segher mentioned, if a define_split needs a
temporary it is supposed to add a clobber of a match_operand.

I tried an experiment, I set a global var at the start of combine_instructions,
cleared it at the end, added an abort to gen_reg_rtx if the var is set, and did
an x86 bootstrap.  It completed successfully.  A make check is running, but I
don't expect to hit the abort there either.

A RISC-V toolchain with my proposed fix added still fails as riscv_split_symbol
called from gen_split_13 has the same problem and needs a similar fix.

[Bug c++/88329] Implement C++20 std concepts.

2019-09-09 Thread jason at gcc dot gnu.org

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-09
 CC||jason at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Jason Merrill  ---
Implementation has been proceeding on the concepts-cxx2a git-only branch, and
is nearly ready to merge.

[Bug c++/91705] [9/10 Regression] operator++ broken in constexpr floating point code

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

--- Comment #5 from Marek Polacek  ---
But using fold_simple instead does seem to work, so I'll go with that.

[Bug c++/91705] [9/10 Regression] operator++ broken in constexpr floating point code

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

--- Comment #4 from Marek Polacek  ---
Nevermind, that doesn't work.

[Bug c++/67348] [concepts] Constraints, special member functions, and default/delete

2019-09-09 Thread jason at gcc dot gnu.org

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-09-09
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Jason Merrill  ---
This has been fixed on the concepts-cxx2a branch since I implemented P0848R3.

[Bug c++/91705] [9/10 Regression] operator++ broken in constexpr floating point code

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

--- Comment #3 from Marek Polacek  ---
Candidate fix:

--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -4162,7 +4162,6 @@ cxx_eval_increment_expression (const constexpr_ctx *ctx,
tree t,
   tree type = TREE_TYPE (t);
   tree op = TREE_OPERAND (t, 0);
   tree offset = TREE_OPERAND (t, 1);
-  gcc_assert (TREE_CONSTANT (offset));

   /* The operand as an lvalue.  */
   op = cxx_eval_constant_expression (ctx, op, true,
@@ -4172,6 +4171,11 @@ cxx_eval_increment_expression (const constexpr_ctx *ctx,
tree t,
   tree val
 = cxx_eval_constant_expression (ctx, op, false,
non_constant_p, overflow_p);
+
+  offset = cxx_eval_constant_expression (ctx, offset, false,
+non_constant_p, overflow_p);
+  VERIFY_CONSTANT (offset);
+
   /* Don't VERIFY_CONSTANT if this might be dealing with a pointer to
  a local array in a constexpr function.  */
   bool ptr = INDIRECT_TYPE_P (TREE_TYPE (val));

[Bug target/91713] GP linker relaxation is not performed with -nostdlib

2019-09-09 Thread pinskia at gcc dot gnu.org

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Component|c   |target
 Resolution|--- |MOVED

--- Comment #2 from Andrew Pinski  ---
MOve this to binutils bug database.

[Bug c/91713] GP linker relaxation is not performed with -nostdlib

2019-09-09 Thread sgk at troutmask dot apl.washington.edu

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

Jim Wilson  changed:

   What|Removed |Added

 CC||wilson at gcc dot gnu.org

--- Comment #1 from Jim Wilson  ---
This is an edge condition and an accident of circumstances.  When you link with
the default libraries, other stuff gets put in sdata before a, and so the
variable a is in range of gp because it is at -0x7f0.  When you link with
-nostdlib, a is the only thing in sdata, and we run into an edge condition
where a is -0x800 from gp, which is at the extreme limit, but the linker
relaxation has to limit the range to deal with section alignment issues that
may changes addresses after relaxation, and so we have to assume that a is out
of range.

If you change the example to
int a = 1;
int b = 2;
int c = 3;
int d = 4;
int e = 5;

int main()
{
return a + b + c + d + e;
}
then we see that all 5 variables use gp address with default libraries, and
only the last 3 with -nostdlib, so we are losing the first two variables due to
address range limitation at linker relaxation time.

There is a somewhat related open binutils bug report
  https://sourceware.org/bugzilla/show_bug.cgi?id=24678
and another somewhat related binutils bug report I recently fixed
  https://sourceware.org/ml/binutils/2019-08/msg00244.html
if gp was still computed inside the .sdata section we wouldn't have this
problem, but that means undoing a change that reduced code size for most
applications.  Maybe there is a different way to solve the earlier problem that
doesn't cause this problem.

Anyways, this is a linker issue not a gcc issue.

[Bug libgomp/91694] configure.ac does not correctly check for gethostname

2019-09-09 Thread ri...@extreme-scale.com

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

--- Comment #6 from Rishi Khan  ---
(In reply to Jakub Jelinek from comment #5)
> > It seems like libgomp's configure.ac is already using AC_LINK_IFELSE for all
> > OS's around line 241 to 'Check for pthread_{,attr_}[sg]etaffinity_np.'.
> 
> True, but that is something most of the targets don't have, it is glibc
> specific mostly, so doesn't matter if it fails.
> 
> > In my newlib startup setup, I only build libgomp in stage2.
> > See here for Makefile:
> > https://github.com/riscv/riscv-gnu-toolchain/blob/master/Makefile.in
> > On line 541 I have --enable-threads and on line 551 I have --enable-libgomp
> 
> Your OS isn't among those where libgomp is supported.  

This may be the case. It worked fine in gcc-7.3 but when we upgraded it failed
due to these configure errors.

> Do you say you have POSIX threads but not gethostname?

Yes. There is no real reason we don't have gethostname beyond the fact that we
didn't implement it yet.

Why is it the case that libgomp checks to see if it has gethostname by
compiling a program that has gethostname but not linking it? Regardless of if
the OS supports or is does not support gethostname, just compiling it will
succeed. [same for uname and getpid]

Here are some more examples where it tries to link to check if a function
exists:
# Check for functions needed. (line 219 of configure.ac, 
AC_CHECK_FUNCS(getloadavg clock_gettime strtoull)
AC_CHECK_FUNCS(aligned_alloc posix_memalign memalign _aligned_malloc)

in configure, AC_CHECK_FUNCS resolves to calls to ac_fn_c_check_func (line
15811), which calls ac_fn_c_try_link (line 1867)

[Bug gcov-profile/91087] g++.dg/gcov/pr16855.C fails everywhere on Darwin.

2019-09-09 Thread iains at gcc dot gnu.org

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

--- Comment #6 from Iain Sandoe  ---
Author: iains
Date: Mon Sep  9 20:27:05 2019
New Revision: 275547

URL: https://gcc.gnu.org/viewcvs?rev=275547=gcc=rev
Log:
[Darwin, testsuite] Address PR91087 - XFAIL parts of pr16855.C.

The testcase is failing to instrument part of the source because of a bug
in the ordering of static DTORs. It seems unlikely that this is generically
fixable in the toolchain (and given that it's likely to be a dynamic loader
change would not be expected to be applied retrospectively to OS versions
that are out of support). To avoid the testsuite noise, xfail the count lines
that don't match (we can adjust the xfails as/when the upstream bug is fixed).

dejagnu xfails do not seem to work when embedded in a line like:
~Test (void) {  /* count(1) { xfail ... } */ }
the closing brace seems to confuse the parser. The solution is to exapnd the
text onto three lines.

2019-09-09  Iain Sandoe  

Backport from mainline.
2019-07-25  Iain Sandoe  

PR gcov-profile/91087
* g++.dg/gcov/pr16855.C: Xfail the count lines for the DTORs and the
"final" line for the failure summaries.  Adjust source layout so that
dejagnu xfail expressions work.


Modified:
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/testsuite/g++.dg/gcov/pr16855.C

[Bug fortran/91690] Slow IEEE intrinsics

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

--- Comment #7 from Steve Kargl  ---
On Mon, Sep 09, 2019 at 07:22:24PM +, wdijkstr at arm dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91690
> 
> Wilco  changed:
> 
>What|Removed |Added
> 
>  CC||wdijkstr at arm dot com
> 
> --- Comment #6 from Wilco  ---
> (In reply to Steve Kargl from comment #5)
> > On Mon, Sep 09, 2019 at 06:25:53PM +, wilco at gcc dot gnu.org wrote:
> > > > 
> > > > The Fortran standard may require this behavior.  18-007r1 page 435
> > > 
> > > But none of that is needed since a correct implementation of isnan
> > > etc does not affect the floating point state at all (see PR66462).
> > > 
> > 
> > OK.  So you can special case IEEE_IS_NAN().  What about
> > the other IEEE_ARITHMETIC functions?
> 
> The same is true for the other isxxx functions from C99 and the new iszero and
> isdenormal. Are there other functions besides these in IEEE_ARITHMETIC?

Don't know.  I haven't tried cross-referencing C99 against Fortran 2018.
Table 17.2i lists the functions made available by IEEE_ARITHMETIC.

> > PR66462 has been re-opened.  Tamir seemed to have developed
> > 4 different patches, yet no one can agree on "a correct
> > implementation" for all targets.
> 
> As his latest comments explain, Tamar's last patch is correct. That should be
> the default since an integer implementation which doesn't affect floating 
> point
> state is the only correct one. It happens to be the fastest as well as a 
> bonus.
> 
> Either way, I don't believe the Fortran front-end should try to work around
> mid-end bugs. As reported a save/restore is prohibitive expensive on all
> targets so shouldn't even be contemplated.

The saving and restoring FPU state was implemented in

troutmask:sgk[206] svn log -r 216036

r216036 | fxcoudert | 2014-10-09 02:47:25 -0700 (Thu, 09 Oct 2014) | 25 lines

The above is a full 8 months before PR66462.

PR66462 was opened on 2015-06-08.  A patch was committed
on 2017-06-08 and the PR was closed.  PR66462 was re-opened
on 2017-06-09.  The patch seems to have been reverted in
r249050, but this action isn't recorded in the PR.
Tamar's last comment #19 contains "Yes it was committed and 
reverted and fixed, but never committed again."

So, it seems that the Fortran FE isn't trying to workaround
anything.  It is seemingly trying to ensure the requirements
of the Fortran standard are met.  If and when someone has 
the time to review the implementation IEEE_ARITHMETIC, 
perhaps, the saving/restoring of fpu state can be addressed.

[Bug testsuite/65364] FAIL: gcc.dg/uninit-19.c (test for warnings, line 22)

2019-09-09 Thread iains at gcc dot gnu.org

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

--- Comment #8 from Iain Sandoe  ---
Author: iains
Date: Mon Sep  9 20:21:30 2019
New Revision: 275546

URL: https://gcc.gnu.org/viewcvs?rev=275546=gcc=rev
Log:
[Darwin, testsuite] Fix PR 65364 (uninit-19.c).

This test currently fails on Darwin, because the port inlines fn2 for
both PIC (and non-pic for m32). Fixed by adjusting the target condition.

2019-09-09  Iain Sandoe  

Backport from mainline.
2019-06-11  Iain Sandoe  

PR testsuite/65364
* gcc.dg/uninit-19.c (fn1): Adjust target condition for Darwin.
(fn2): Likewise.


Modified:
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/testsuite/gcc.dg/uninit-19.c

[Bug middle-end/91709] Missed optimization for multiplication on 1.5 and 1.25

2019-09-09 Thread joseph at codesourcery dot com

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

--- Comment #2 from joseph at codesourcery dot com  ---
If the result of multiplying by 1.5 is outside the range of the integer 
type, the version with multiplication is required to raise the FE_INVALID 
exception for the out-of-range conversion to integer, so the 
transformation is not valid with -ftrapping-math (which is on by default).

Note also that the transformation would not be valid when the constant is 
1.5f (generally, any case where the types / values involved mean the 
conversion from integer to floating, or the multiplication, might not be 
exact in the floating-point type).

[Bug libgomp/91694] configure.ac does not correctly check for gethostname

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

--- Comment #5 from Jakub Jelinek  ---
(In reply to Rishi Khan from comment #4)
> (In reply to Jakub Jelinek from comment #3)
> > Can you start by saying what OS this is on?  The lib*/configure* in gcc tree
> > can't use linking in all cases due to newlib startup setups, but it is true
> > that in libgomp's configure AC_LINK_IFELSE is used already for most targets
> > (but not all).
> 
> This is on my custom OS that doesn't have gethostname ('hcos', which is in
> the config.sub upstream). I am actually using newlib. 
> 
> It seems like libgomp's configure.ac is already using AC_LINK_IFELSE for all
> OS's around line 241 to 'Check for pthread_{,attr_}[sg]etaffinity_np.'.

True, but that is something most of the targets don't have, it is glibc
specific mostly, so doesn't matter if it fails.

> In my newlib startup setup, I only build libgomp in stage2.
> See here for Makefile:
> https://github.com/riscv/riscv-gnu-toolchain/blob/master/Makefile.in
> On line 541 I have --enable-threads and on line 551 I have --enable-libgomp

Your OS isn't among those where libgomp is supported.  Do you say you have
POSIX threads but not gethostname?

[Bug libgomp/91694] configure.ac does not correctly check for gethostname

2019-09-09 Thread ri...@extreme-scale.com

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

--- Comment #4 from Rishi Khan  ---
(In reply to Jakub Jelinek from comment #3)
> Can you start by saying what OS this is on?  The lib*/configure* in gcc tree
> can't use linking in all cases due to newlib startup setups, but it is true
> that in libgomp's configure AC_LINK_IFELSE is used already for most targets
> (but not all).

This is on my custom OS that doesn't have gethostname ('hcos', which is in the
config.sub upstream). I am actually using newlib. 

It seems like libgomp's configure.ac is already using AC_LINK_IFELSE for all
OS's around line 241 to 'Check for pthread_{,attr_}[sg]etaffinity_np.'.

In my newlib startup setup, I only build libgomp in stage2.
See here for Makefile:
https://github.com/riscv/riscv-gnu-toolchain/blob/master/Makefile.in
On line 541 I have --enable-threads and on line 551 I have --enable-libgomp

[Bug libgomp/91694] configure.ac does not correctly check for gethostname

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

--- Comment #3 from Jakub Jelinek  ---
Can you start by saying what OS this is on?  The lib*/configure* in gcc tree
can't use linking in all cases due to newlib startup setups, but it is true
that in libgomp's configure AC_LINK_IFELSE is used already for most targets
(but not all).

[Bug libgomp/91694] configure.ac does not correctly check for gethostname

2019-09-09 Thread ri...@extreme-scale.com

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

--- Comment #2 from Rishi Khan  ---
Created attachment 46857
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46857=edit
patch for libgomp

Attached is a patch that works for me.

[Bug target/91708] [10 regression][ARM] Bootstrap fails in gen_movsi, at config/arm/arm.md:5258

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

--- Comment #10 from Bernd Edlinger  ---
$ grep -A4 -r "insn 234 .*:SI 340" real.c.*|less

real.c.237r.subreg1:(insn 234 233 235 11 (set (reg:SI 340)
real.c.237r.subreg1-(mem:SI (reg/v/f:SI 273 [ rD.73757 ]) [52 MEM
 [(struct real_valueD.28367 *)r_77(D)]+0 S4 A32]))
"../../gcc-trunk-1/gcc/real.c":5185:9 643 {*thumb2_movsi_vfp}
real.c.237r.subreg1- (nil))
real.c.237r.subreg1-(insn 235 234 236 11 (set (reg:SI 339)
real.c.237r.subreg1-(and:SI (reg:SI 340)
--
real.c.238r.dfinit:(insn 234 233 235 11 (set (reg:SI 340)
real.c.238r.dfinit-(mem:SI (reg/v/f:SI 273 [ rD.73757 ]) [52 MEM
 [(struct real_valueD.28367 *)r_77(D)]+0 S4 A32]))
"../../gcc-trunk-1/gcc/real.c":5185:9 643 {*thumb2_movsi_vfp}
real.c.238r.dfinit- (nil))
real.c.238r.dfinit-(insn 235 234 236 11 (set (reg:SI 339)
real.c.238r.dfinit-(and:SI (reg:SI 340)
--
real.c.239r.cse1:(insn 234 233 235 11 (set (reg:SI 340)
real.c.239r.cse1-(mem:SI (reg/v/f:SI 273 [ rD.73757 ]) [52 MEM
 [(struct real_valueD.28367 *)r_77(D)]+0 S4 A32]))
"../../gcc-trunk-1/gcc/real.c":5185:9 643 {*thumb2_movsi_vfp}
real.c.239r.cse1- (nil))
real.c.239r.cse1-(insn 235 234 236 11 (set (reg:SI 339)
real.c.239r.cse1-(and:SI (reg:SI 340)
--
real.c.239r.cse1:(insn 234 233 235 11 (set (reg:SI 340 [ MEM 
[(struct real_valueD.28367 *)r_77(D)] ])
real.c.239r.cse1-(mem:SI (plus:SI (reg/v/f:SI 273 [ rD.73757 ])
real.c.239r.cse1-(const_int 20 [0x14])) [0 MEM 
[(voidD.73 *)r_77(D)]+20 S4 A8])) "../../gcc-trunk-1/gcc/real.c":5185:9 643
{*thumb2_movsi_vfp}
real.c.239r.cse1- (nil))
real.c.239r.cse1-(insn 235 234 236 11 (set (reg:SI 339)
--

so initially the mem-ref was:
[52 MEM  [(struct real_valueD.28367 *)r_77(D)]+0 S4 A32]

but it is replaced by:
[0 MEM  [(voidD.73 *)r_77(D)]+20 S4 A8]

this is bad, because the Alignment is worse, and the alias-set
is changed from 52 to 0, alias everything.

[Bug fortran/91690] Slow IEEE intrinsics

2019-09-09 Thread wdijkstr at arm dot com

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

Wilco  changed:

   What|Removed |Added

 CC||wdijkstr at arm dot com

--- Comment #6 from Wilco  ---
(In reply to Steve Kargl from comment #5)
> On Mon, Sep 09, 2019 at 06:25:53PM +, wilco at gcc dot gnu.org wrote:
> > > 
> > > The Fortran standard may require this behavior.  18-007r1 page 435
> > 
> > But none of that is needed since a correct implementation of isnan
> > etc does not affect the floating point state at all (see PR66462).
> > 
> 
> OK.  So you can special case IEEE_IS_NAN().  What about
> the other IEEE_ARITHMETIC functions?

The same is true for the other isxxx functions from C99 and the new iszero and
isdenormal. Are there other functions besides these in IEEE_ARITHMETIC?

> PR66462 has been re-opened.  Tamir seemed to have developed
> 4 different patches, yet no one can agree on "a correct
> implementation" for all targets.

As his latest comments explain, Tamar's last patch is correct. That should be
the default since an integer implementation which doesn't affect floating point
state is the only correct one. It happens to be the fastest as well as a bonus.

Either way, I don't believe the Fortran front-end should try to work around
mid-end bugs. As reported a save/restore is prohibitive expensive on all
targets so shouldn't even be contemplated.

[Bug target/91708] [10 regression][ARM] Bootstrap fails in gen_movsi, at config/arm/arm.md:5258

2019-09-09 Thread sgk at troutmask dot apl.washington.edu

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

--- Comment #9 from Bernd Edlinger  ---
I see this instruction is responsible (in function real_nextafter
first in real.c.239r.cse1:

(insn 234 198 205 11 (set (reg:SI 340 [ MEM  [(struct
real_valueD.28367 *)r_77(D)] ])
(mem:SI (plus:SI (reg/v/f:SI 273 [ rD.73757 ])
(const_int 20 [0x14])) [0 MEM  [(voidD.73
*)r_77(D)]+20 S4 A8])) "../../gcc-trunk-1/gcc/real.c":5185:9 643
{*thumb2_movsi_vfp}

it should to be a unaligned_loadsi of course.

[Bug fortran/91690] Slow IEEE intrinsics

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

--- Comment #5 from Steve Kargl  ---
On Mon, Sep 09, 2019 at 06:25:53PM +, wilco at gcc dot gnu.org wrote:
> > 
> > The Fortran standard may require this behavior.  18-007r1 page 435
> 
> But none of that is needed since a correct implementation of isnan
> etc does not affect the floating point state at all (see PR66462).
> 

OK.  So you can special case IEEE_IS_NAN().  What about
the other IEEE_ARITHMETIC functions?

PR66462 has been re-opened.  Tamir seemed to have developed
4 different patches, yet no one can agree on "a correct
implementation" for all targets.

[Bug c++/91705] [9/10 Regression] operator++ broken in constexpr floating point code

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-09
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |9.3
Summary|operator++ broken in|[9/10 Regression]
   |constexpr floating point|operator++ broken in
   |code|constexpr floating point
   ||code
 Ever confirmed|0   |1

--- Comment #2 from Marek Polacek  ---
Looks like it started with r269078.

[Bug libstdc++/91711] 23_containers/span/get_neg.cc fails on arm

2019-09-09 Thread redi at gcc dot gnu.org

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-09-09
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Target Milestone|--- |10.0
 Ever confirmed|0   |1

[Bug middle-end/91680] Integer promotion quirk prevents efficient power of 2 division

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 46856
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46856=edit
gcc10-pr91680.patch

Untested fix.

[Bug target/91708] [10 regression][ARM] Bootstrap fails in gen_movsi, at config/arm/arm.md:5258

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

--- Comment #8 from Wilco  ---
(In reply to Bernd Edlinger from comment #7)
> without looking in detail, this could
> be another middle-end error or the back-end
> generating an invalid instruction where no assertions
> are, then lra can rewrite the insn in a way that
> triggers the assertion later.
> 
> I have no resources to work on reducing this
> due to the upcoming OpenSSL release tomorrow, were
> I need to work on a fix for a CVE I found.
> 
> Could you pleas help reducing this one?

I'll have a go - it bootstraps when I set #define SLOW_BYTE_ACCESS 1. So I'm
guessing it's a case of the mid-end emitting an unaligned access for an aligned
bitfield eventhough that is neither useful nor optimal.

[Bug fortran/91690] Slow IEEE intrinsics

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

Wilco  changed:

   What|Removed |Added

 CC||wilco at gcc dot gnu.org

--- Comment #4 from Wilco  ---
(In reply to Steve Kargl from comment #3)
> On Mon, Sep 09, 2019 at 08:05:33AM +, rguenth at gcc dot gnu.org wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91690
> > 
> > --- Comment #2 from Richard Biener  ---
> > __builtin_isnan is required to preserve FPU state, not sure why the Fortran 
> > FE
> > thinks it needs some extra magic around it?
> > 
> 
> The magic seems to come from trans-decl.c
> 
> /* Generate code for a function.  */
> 
> void
> gfc_generate_function_code (gfc_namespace * ns)
> {
> 
> ...
> 
>   /* Check if an IEEE module is used in the procedure.  If so, save
>  the floating point state.  */
>   ieee = is_ieee_module_used (ns);
>   if (ieee)
> fpstate = gfc_save_fp_state ();
> 
> ...
> 
>   /* If IEEE modules are loaded, restore the floating-point state.  */
>   if (ieee)
> gfc_restore_fp_state (, fpstate);
> 
> }
> 
> The Fortran standard may require this behavior.  18-007r1 page 435

But none of that is needed since a correct implementation of isnan etc does not
affect the floating point state at all (see PR66462).

[Bug target/91684] [10 regression][ARM] ICE in gen_movdi, at config/arm/arm.md:5079

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

--- Comment #8 from Christophe Lyon  ---
Indeed, it's now unsupported in this config.

[Bug target/91684] [10 regression][ARM] ICE in gen_movdi, at config/arm/arm.md:5079

2019-09-09 Thread sgk at troutmask dot apl.washington.edu

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

--- Comment #7 from Bernd Edlinger  ---
probably fixed by r275489
It was not intended to run this test on cortex-a9,
but I used the wrong effective-target.

[Bug fortran/91690] Slow IEEE intrinsics

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

--- Comment #3 from Steve Kargl  ---
On Mon, Sep 09, 2019 at 08:05:33AM +, rguenth at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91690
> 
> --- Comment #2 from Richard Biener  ---
> __builtin_isnan is required to preserve FPU state, not sure why the Fortran FE
> thinks it needs some extra magic around it?
> 

The magic seems to come from trans-decl.c

/* Generate code for a function.  */

void
gfc_generate_function_code (gfc_namespace * ns)
{

...

  /* Check if an IEEE module is used in the procedure.  If so, save
 the floating point state.  */
  ieee = is_ieee_module_used (ns);
  if (ieee)
fpstate = gfc_save_fp_state ();

...

  /* If IEEE modules are loaded, restore the floating-point state.  */
  if (ieee)
gfc_restore_fp_state (, fpstate);

}

The Fortran standard may require this behavior.  18-007r1 page 435

  In a scoping unit that has access to IEEE_EXCEPTIONS or IEEE_ARITHMETIC,
  if an intrinsic procedure or a procedure defined in an intrinsic module
  executes normally, the values of the flags IEEE_OVERFLOW,
IEEE_DIVIDE_BY_ZERO,
  and IEEE_INVALID shall be as on entry to the procedure, even if one or more
  of them signals during the calculation.

then on page 437

  In a procedure other than IEEE_SET_ROUNDING_MODE or IEEE_SET_STATUS, the
  processor shall not change the rounding modes on entry, and on return
  shall ensure that the rounding modes are the same as they were on entry.
...
  In a procedure other than IEEE_SET_UNDERFLOW_MODE or IEEE_SET_STATUS, the
  processor shall not change the underflow mode on entry, and on return
  shall ensure that the underflow mode is the same as it was on entry.

then on page 438

  In a procedure other than IEEE_SET_HALTING_MODE or IEEE_SET_STATUS, the
  processor shall not change the halting mode on entry, and on return shall
  ensure that the halting mode is the same as it was on entry.

[Bug rtl-optimization/42575] arm-eabi-gcc 64-bit multiply weirdness

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

--- Comment #20 from Wilco  ---
(In reply to Wilco from comment #19)
> (In reply to Christophe Lyon from comment #18)
> > This is still wrong with current trunk.
> 
> I don't see it happening since expansion of DImode instructions improved.
> The only case that uses an extra register is -mcpu=cortex-a9/-mcpu=cortex-a5
> with -O2 -mthumb:
> 
>   mul r3, r0, r3
>   push{r4}
>   mov r4, r1
>   umull   r0, r1, r0, r2
>   mla r2, r2, r4, r3
>   ldr r4, [sp], #4
>   add r1, r1, r2
>   bx  lr
> 
> I don't think we should expect perfect register allocation in severely
> constrained cases like this - scheduling can increase register pressure.

Interestingly this will be fixed by
https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00576.html:

mul r3, r0, r3
mov ip, r1
umull   r0, r1, r0, r2
mla ip, r2, ip, r3
add r1, r1, ip
bx  lr

With r12 as an extra temporary r4 no longer needs to be saved/restored.

[Bug fortran/91716] New: [9/10 Regression] ICE in output_constant, at varasm.c:5026

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

Bug ID: 91716
   Summary: [9/10 Regression] ICE in output_constant, at
varasm.c:5026
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Something has changed between 20180722 and 20180805 :


$ cat z1.f90
module m
   type t
  character :: c(2) = [character(-1) :: 'a', 'b']
   end type
end


$ gfortran-9-20180722 -c z1.f90
$
$ gfortran-10-20190908 -c z1.f90
z1.f90:5:0:

5 | end
  |
internal compiler error: in output_constant, at varasm.c:5026
0x1006c0c output_constant
../../gcc/varasm.c:5026
0x1008367 output_constant
../../gcc/varasm.c:5259
0x1008367 output_constructor_regular_field
../../gcc/varasm.c:5259
0x1008367 output_constructor
../../gcc/varasm.c:5526
0x1008367 output_constant
../../gcc/varasm.c:5259
0x1008367 output_constructor_regular_field
../../gcc/varasm.c:5259
0x1008367 output_constructor
../../gcc/varasm.c:5526
0x1009509 output_constant
../../gcc/varasm.c:4898
0x1009509 assemble_variable_contents
../../gcc/varasm.c:2147
0x10135e1 assemble_variable(tree_node*, int, int, int)
../../gcc/varasm.c:2326
0x1016524 varpool_node::assemble_decl()
../../gcc/varpool.c:584
0x83ee44 output_in_order
../../gcc/cgraphunit.c:2442
0x83ee44 symbol_table::compile()
../../gcc/cgraphunit.c:2685
0x841aa6 symbol_table::compile()
../../gcc/cgraphunit.c:2871
0x841aa6 symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2868

[Bug fortran/91646] gfortran takes long time and consumes a lot of memory

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

--- Comment #8 from G. Steinmetz  ---

First a remark, the phrase "the facts" had an unintended 
sound, should be read as "the given" or similar.

---

It is apparently not necessary to have a cascade of several 
types, a single one suffices. Associated generator :

$ cat generator_type_long.f90
program generator_type_long
   implicit none
   character(*), parameter :: fmt = '(*(a,i6.6))'
   integer :: n   ! number of base items
   integer :: i
   read(*,*) n
   n = max (0, min (n, 99))

   print fmt, 'module m'
   print fmt, '   type t', 0
   do i = 1, n
  print fmt, '  real, allocatable :: a', i, '(:)'
   end do
   print fmt, '   end type'
   print fmt, 'end module'
end


The output then looks like :

module m
   type t00
  real, allocatable :: a01(:)
  ...
  real, allocatable :: a004000(:)
   end type
end module


Similar to comment 5 a variant with "real, pointer" is placed 
next to it, and one with fixed size "real :: a...(10)" 


Intentional tested with a very old box, some results :

   --- allocatable ---  pointerfixed a(10)
  Nuser timememory user timeuser time
500  3.1 sec130 MB 0.026 sec0.031 sec
   1000  7.8 sec250 MB 0.046 sec0.045 sec
   2000 20.3 sec540 MB 0.087 sec0.091 sec
   3000 42.2 sec850 MB 0.125 sec0.145 sec
   4000 68.5 sec   1090 MB 0.180 sec0.213 sec


For this limited range, memory consumption is roughly ~ N.
OTOH, run time raises from N=1000 to 4000 by a factor of 9.
For higher numbers not necessarily monotone.

Memory consumption goes up stepwise, e.g. for N=4000
between 26 and 58 sec consumption is constant 510 MB,
then doubles between 59 and 63 sec to 1040 MB.

In general depending on size/speed of caches/ram/disc and other.
For slightly different numbers N and N+1, output and dumps can
be diff compared, but not done here.

Numbers vary for different OS, CPU, compiler versions, etc.

[Bug fortran/91715] New: ICE in resolve_fntype, at fortran/resolve.c:16884

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

Bug ID: 91715
   Summary: ICE in resolve_fntype, at fortran/resolve.c:16884
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

With a typo, down to at least gfortran-5.


$ cat z1.f90
character(1function f()
end


$ gfortran-10-20190901 -c z1.f90
f951: internal compiler error: Segmentation fault
0xcb928f crash_signal
../../gcc/toplev.c:326
0x6af81c resolve_fntype
../../gcc/fortran/resolve.c:16884
0x6af81c resolve_types
../../gcc/fortran/resolve.c:17027
0x6b349c gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:17140
0x6a196c resolve_all_program_units
../../gcc/fortran/parse.c:6193
0x6a196c gfc_parse_file()
../../gcc/fortran/parse.c:6440
0x6eca8f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/91714] Accepts type statement without delimiter in free form

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

G. Steinmetz  changed:

   What|Removed |Added

   Keywords||accepts-invalid

--- Comment #1 from G. Steinmetz  ---


Similar for double precision and character,
while detected for integer, logical, real, complex :


$ cat z2.f90
program p
   double precisiona
   a = 1
   print *, a
end

$ gfortran-10-20190908 z2.f90 && ./a.out
   1.


$ cat z3.f90
program p
   charactera
   a = 'a'
   print *, a
end

$ gfortran-10-20190908 z3.f90 && ./a.out
 a



$ cat z5i.f90
program p
   integera
   a = 1
   print *, a
end

$ gfortran-10-20190908 -c z5i.f90
z5i.f90:2:3:

2 |integera
  |   1
Error: Unclassifiable statement at (1)

[Bug fortran/91714] New: Accepts type statement without delimiter in free form

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

Bug ID: 91714
   Summary: Accepts type statement without delimiter in free form
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

With a missing blank in "typea" in a free form source,
down to at least version 5 :


$ cat z1.f90
program p
   typea
  integer b
   end type
   type(a) :: c
   c = a(1)
   print *, c
end


$ gfortran-10-20190908 z1.f90 && ./a.out
   1
$

[Bug libstdc++/91653] ostream::operator<<(streambuf*) should fail the ostream when write output stream error but not

2019-09-09 Thread rs2740 at gmail dot com

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #3 from TC  ---
Looks NAD to me.

http://eel.is/c++draft/ostream.inserters#8.2 doesn't say that we set any bit in
that case. Contrast with http://eel.is/c++draft/ostream.unformatted#3 and
http://eel.is/c++draft/ostream.unformatted#5.2

[Bug testsuite/91670] [10 regression] g++.dg/ubsan/pr59415.C fails starting with rr275388

2019-09-09 Thread ctice at gcc dot gnu.org

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

ctice at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from ctice at gcc dot gnu.org ---
Patch fixes this problem.

[Bug target/91708] [10 regression][ARM] Bootstrap fails in gen_movsi, at config/arm/arm.md:5258

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

--- Comment #7 from Bernd Edlinger  ---
without looking in detail, this could
be another middle-end error or the back-end
generating an invalid instruction where no assertions
are, then lra can rewrite the insn in a way that
triggers the assertion later.

I have no resources to work on reducing this
due to the upcoming OpenSSL release tomorrow, were
I need to work on a fix for a CVE I found.

Could you pleas help reducing this one?

[Bug target/91708] [10 regression][ARM] Bootstrap fails in gen_movsi, at config/arm/arm.md:5258

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

--- Comment #6 from Bernd Edlinger  ---
(In reply to Wilco from comment #5)
> (In reply to Christophe Lyon from comment #4)
> > (In reply to Bernd Edlinger from comment #3)
> > > I will try to reproduce with building of a cross for this target.
> > 
> > FWIW, cross-build looked fine for me at r275501:
> > --target arm-none-linux-gnueabihf
> > --with-mode arm / thumb
> > --with-cpu cortex-a57
> > --with-fpu crypto-neon-fp-armv8
> 
> It passes with --with-fpu=neon-fp-armv8, so it seems not having Neon enabled
> is necessary too.

Yeah, using Wico's config flags I was able to reproduce this now:

during RTL pass: reload
../../gcc-trunk-1/gcc/real.c: In function 'bool real_nextafter(real_value*,
format_helper, const real_value*, const real_value*)':
../../gcc-trunk-1/gcc/real.c:5240:1: internal compiler error: in gen_movsi, at
config/arm/arm.md:5435
 5240 | }
  | ^
0x882ecb gen_movsi(rtx_def*, rtx_def*)
../../gcc-trunk-1/gcc/config/arm/arm.md:5435
0xc82977 insn_gen_fn::operator()(rtx_def*, rtx_def*) const
../../gcc-trunk-1/gcc/recog.h:318
0xc82977 emit_move_insn_1(rtx_def*, rtx_def*)
../../gcc-trunk-1/gcc/expr.c:3694
0xc82d04 emit_move_insn(rtx_def*, rtx_def*)
../../gcc-trunk-1/gcc/expr.c:3790
0xe2eb4a lra_emit_move(rtx_def*, rtx_def*)
../../gcc-trunk-1/gcc/lra.c:498
0xe44be2 curr_insn_transform
../../gcc-trunk-1/gcc/lra-constraints.c:4402
0xe463fe lra_constraints(bool)
../../gcc-trunk-1/gcc/lra-constraints.c:4999
0xe2f0d4 lra(_IO_FILE*)
../../gcc-trunk-1/gcc/lra.c:2452
0xde7191 do_reload
../../gcc-trunk-1/gcc/ira.c:5522
0xde7191 execute
../../gcc-trunk-1/gcc/ira.c:5706
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[2]: *** [real.o] Error 1
make[2]: Leaving directory
`/home/ed/gnu/gcc-build-arm-linux-gnueabihf-cross-1/gcc'
make[1]: *** [all-gcc] Error 2
make[1]: Leaving directory `/home/ed/gnu/gcc-build-arm-linux-gnueabihf-cross-1'
make: *** [all] Error 2

[Bug target/91708] [10 regression][ARM] Bootstrap fails in gen_movsi, at config/arm/arm.md:5258

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

--- Comment #5 from Wilco  ---
(In reply to Christophe Lyon from comment #4)
> (In reply to Bernd Edlinger from comment #3)
> > I will try to reproduce with building of a cross for this target.
> 
> FWIW, cross-build looked fine for me at r275501:
> --target arm-none-linux-gnueabihf
> --with-mode arm / thumb
> --with-cpu cortex-a57
> --with-fpu crypto-neon-fp-armv8

It passes with --with-fpu=neon-fp-armv8, so it seems not having Neon enabled is
necessary too.

[Bug c/91713] New: GP linker relaxation is not performed with -nostdlib

2019-09-09 Thread bmeng.cn at gmail dot com

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

Bug ID: 91713
   Summary: GP linker relaxation is not performed with -nostdlib
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bmeng.cn at gmail dot com
  Target Milestone: ---

See the following test case
$ cat test.c
int a = 1;

int main()
{
return a;
}

Building the test case with "-nostdlib" seems to disable the GP linker
relaxation:
$ riscv64-unknown-linux-gnu-gcc test.c -o test -nostdlib
$ riscv64-unknown-linux-gnu-objdump -d test | grep gp


But if we compile test.c without "-nostdlib":
$ riscv64-unknown-linux-gnu-gcc test.c -o test
$ riscv64-unknown-linux-gnu-objdump -d test | grep gp
   103bc:   2197auipc   gp,0x2
   103c0:   46418193addigp,gp,1124 # 12820
<__global_pointer$>
   1041c:   8141c783lbu a5,-2028(gp) # 12034 <_edata>
   1042a:   80f18a23sb  a5,-2028(gp) # 12034 <_edata>
   10440:   8101a783lw  a5,-2032(gp) # 12030

[Bug go/91712] [10 regression] ICE in bind_field_or_method, at go/gofrontend/types.cc:11878

2019-09-09 Thread ro at gcc dot gnu.org

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug go/91712] New: [10 regression] ICE in bind_field_or_method, at go/gofrontend/types.cc:11878

2019-09-09 Thread ro at gcc dot gnu.org

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

Bug ID: 91712
   Summary: [10 regression] ICE in bind_field_or_method, at
go/gofrontend/types.cc:11878
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: ro at gcc dot gnu.org
CC: cmang at google dot com
  Target Milestone: ---
Target: i386-pc-solaris2.11, sparc-sun-solaris2.11

After the Go 1.13 Beta 1 import, mainline bootstrap failed on Solaris as
described in https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00464.html.
With the patch posted there, I managed to restore bootstrap.  However, one
libgo testcase regressed on both sparc and x86:

go1: internal compiler error: in bind_field_or_method, at
go/gofrontend/types.cc:11878
0x8b68e73 Type::bind_field_or_method(Gogo*, Type const*, Expression*,
std::__cxx11::basic_string, std::allocator >
const&, Location)
/vol/gcc/src/hg/trunk/local/gcc/go/gofrontend/types.cc:11878
0x8ae942c Expression::lower(Gogo*, Named_object*, Statement_inserter*, int)
/vol/gcc/src/hg/trunk/local/gcc/go/gofrontend/expressions.h:929
0x8ae942c Lower_parse_tree::expression(Expression**)
/vol/gcc/src/hg/trunk/local/gcc/go/gofrontend/gogo.cc:3090
0x8aaaffc Expression::traverse(Expression**, Traverse*)
/vol/gcc/src/hg/trunk/local/gcc/go/gofrontend/expressions.cc:45
0x8ab63de Call_expression::do_traverse(Traverse*)
/vol/gcc/src/hg/trunk/local/gcc/go/gofrontend/expressions.cc:10716
0x8ae93e6 Lower_parse_tree::expression(Expression**)
/vol/gcc/src/hg/trunk/local/gcc/go/gofrontend/gogo.cc:3084
0x8aea784 Gogo::lower_expression(Named_object*, Statement_inserter*,
Expression**)
/vol/gcc/src/hg/trunk/local/gcc/go/gofrontend/gogo.cc:3158
0x8aeb368 Variable::lower_init_expression(Gogo*, Named_object*,
Statement_inserter*)
/vol/gcc/src/hg/trunk/local/gcc/go/gofrontend/gogo.cc:7449
0x8b33647 Variable_declaration_statement::do_lower(Gogo*, Named_object*,
Block*, Statement_inserter*)
/vol/gcc/src/hg/trunk/local/gcc/go/gofrontend/statements.cc:304
0x8ae9abb Statement::lower(Gogo*, Named_object*, Block*, Statement_inserter*)
/vol/gcc/src/hg/trunk/local/gcc/go/gofrontend/statements.h:310
0x8ae9abb Lower_parse_tree::statement(Block*, unsigned int*, Statement*)
/vol/gcc/src/hg/trunk/local/gcc/go/gofrontend/gogo.cc:3056
0x8ae9abb Lower_parse_tree::statement(Block*, unsigned int*, Statement*)
/vol/gcc/src/hg/trunk/local/gcc/go/gofrontend/gogo.cc:3033
0x8b34826 Statement::traverse(Block*, unsigned int*, Traverse*)
/vol/gcc/src/hg/trunk/local/gcc/go/gofrontend/statements.cc:46
0x8aeba06 Block::traverse(Traverse*)
/vol/gcc/src/hg/trunk/local/gcc/go/gofrontend/gogo.cc:6879
0x8ae9a53 Lower_parse_tree::statement(Block*, unsigned int*, Statement*)
/vol/gcc/src/hg/trunk/local/gcc/go/gofrontend/gogo.cc:3045
0x8ae9a53 Lower_parse_tree::statement(Block*, unsigned int*, Statement*)
/vol/gcc/src/hg/trunk/local/gcc/go/gofrontend/gogo.cc:3033
0x8b34826 Statement::traverse(Block*, unsigned int*, Traverse*)
/vol/gcc/src/hg/trunk/local/gcc/go/gofrontend/statements.cc:46
0x8aeba06 Block::traverse(Traverse*)
/vol/gcc/src/hg/trunk/local/gcc/go/gofrontend/gogo.cc:6879
0x8aeba06 Block::traverse(Traverse*)
/vol/gcc/src/hg/trunk/local/gcc/go/gofrontend/gogo.cc:5779

[Bug target/91684] [10 regression][ARM] ICE in gen_movdi, at config/arm/arm.md:5079

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #6 from Christophe Lyon  ---
The new test fails on target arm-none-linux-gnueabihf
--with-mode arm
--with-cpu cortex-a9
--with-fpu neon-fp16

gcc.target/arm/pr91684.c: strd found 0 times
FAIL: gcc.target/arm/pr91684.c scan-assembler-times strd 1

It passes with -mthumb or if the compiler is configured --with-mode thumb.

[Bug c++/91711] New: 23_containers/span/get_neg.cc fails on arm

2019-09-09 Thread sgk at troutmask dot apl.washington.edu

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

Bug ID: 91711
   Summary: 23_containers/span/get_neg.cc fails on arm
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

The new test introduced at r275403 fails on arm targets:
/libstdc++-v3/testsuite/23_containers/span/get_neg.cc:27: error: call of
overloaded 'span(int*, long unsigned int)' is ambiguous

[Bug fortran/91556] Problems with better interface checking

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

--- Comment #26 from Steve Kargl  ---
On Mon, Sep 09, 2019 at 11:21:05AM +, mario-baumann at web dot de wrote:
> 
> --- Comment #25 from Mario Baumann  ---
> 
> the following fortran code (without module/interface statements)
> 
>   SUBROUTINE FOO (A)
>   IMPLICIT NONE
>   DOUBLE PRECISION :: A(2)
>   DOUBLE PRECISION :: B(2)
>   CALL GOO (A(1))
>   CALL GOO (B)
>   END
> 
> returns a similar error:
> 
> > /Gcc/10.0.0/bin/gfortran -c foo.F
> foo.F:6:16:
> 
> 6 |   CALL GOO (B)
>   |1
> Error: Rank mismatch in argument '_formal_0' at (1) (scalar and rank-1)
> 

You can use the -fallow-argument-mismatch option to
degrade the error to warning.  You'll continue to 
get a warning until you fix the code.

[Bug middle-end/36262] [4.3 Regression] Extreme memory usage of VRP compared to older versions

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

--- Comment #16 from Christophe Lyon  ---

> Wrong bugzilla?  But also should be fixed by the followup.
I replied to the bugzilla mentioned in the ChangeLog...

> 
> 2019-09-05  Richard Biener  
> 
> PR rtl-optimization/91656
> * postreload-gcse.c (record_last_mem_set_info): Revert addition
> of early out.

But yes indeed, this fixes what I reported, sorry for the noise.

[Bug middle-end/36262] [4.3 Regression] Extreme memory usage of VRP compared to older versions

2019-09-09 Thread rguenther at suse dot de

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

--- Comment #15 from rguenther at suse dot de  ---
On Mon, 9 Sep 2019, clyon at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36262
> 
> Christophe Lyon  changed:
> 
>What|Removed |Added
> 
>  CC||clyon at gcc dot gnu.org
>   Known to work||
>   Known to fail||
> 
> --- Comment #14 from Christophe Lyon  ---
> Hi Richard,
> 
> r275365 is causing regressions on aarch64:
> FAIL: gcc.dg/atomic/stdatomic-compare-exchange-4.c   -O3 -g  execution test
> FAIL: gcc.dg/tree-prof/20050826-2.c execution,-fprofile-use -D_PROFILE_USE
> 
> In addition, on arm:
> FAIL: gcc.c-torture/execute/builtins/pr23484-chk.c execution,  -O3 -g

Wrong bugzilla?  But also should be fixed by the followup.

2019-09-05  Richard Biener  

PR rtl-optimization/91656
* postreload-gcse.c (record_last_mem_set_info): Revert addition
of early out.

[Bug middle-end/36262] [4.3 Regression] Extreme memory usage of VRP compared to older versions

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org
  Known to work||
  Known to fail||

--- Comment #14 from Christophe Lyon  ---
Hi Richard,

r275365 is causing regressions on aarch64:
FAIL: gcc.dg/atomic/stdatomic-compare-exchange-4.c   -O3 -g  execution test
FAIL: gcc.dg/tree-prof/20050826-2.c execution,-fprofile-use -D_PROFILE_USE

In addition, on arm:
FAIL: gcc.c-torture/execute/builtins/pr23484-chk.c execution,  -O3 -g

[Bug middle-end/91709] Missed optimization for multiplication on 1.5 and 1.25

2019-09-09 Thread antoshkka at gmail dot com

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

--- Comment #1 from Antony Polukhin  ---
Godbolt playground: https://godbolt.org/z/rHQj2w

[Bug c/91710] New: unexpected ABI change note

2019-09-09 Thread jbeulich at suse dot com

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

Bug ID: 91710
   Summary: unexpected ABI change note
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jbeulich at suse dot com
  Target Milestone: ---

Presumably as a result of the fix for bug 88469 on aarch64 there's now a
diagnostic apparently on any passing by value of a compound type using a
bitfield:

struct s {
unsigned int i:4;
};

unsigned int test1(struct s s) {
return s.i;
}

unsigned int test2(unsigned x, struct s s) {
return x - s.i;
}

unsigned int test3(unsigned x, unsigned y, struct s s) {
return x - y - s.i;
}

triggers three note diagnostics. Comparing the generated code there is (as
expected) no change at all from 8.x (same also when looking at the caller side
code).

I wonder whether this isn't simply because aarch64_function_arg_boundary()
guards its inform() invocation only by a condition not depending on the
function inputs.

For reference, the issue was originally noticed with p2m_mem_access_check() in
https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/arm/mem_access.c;h=3e3620294cbcee685f13c25a03f343f7d4422847;hb=refs/heads/staging
with struct npfec being declared in
https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/include/xen/mm.h;h=8d0ddfb60cf4cd08bf907c1f0155049661e3370d;hb=refs/heads/staging

[Bug middle-end/87647] [7/8 Regression] ICE on valid code in decode_addr_const, at varasm.c:2958

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||david at pgmasters dot net

--- Comment #10 from Jakub Jelinek  ---
*** Bug 91689 has been marked as a duplicate of this bug. ***

[Bug target/91689] internal compiler error: in decode_addr_const, at varasm.c:2864

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
 Resolution|FIXED   |DUPLICATE

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

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

[Bug middle-end/91709] New: Missed optimization for multiplication on 1.5 and 1.25

2019-09-09 Thread antoshkka at gmail dot com

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

Bug ID: 91709
   Summary: Missed optimization for multiplication on 1.5 and 1.25
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antoshkka at gmail dot com
  Target Milestone: ---

On x86_32 for any number X of type (unsigned, unsigned short, unsigned char)
multiplication by 1.5 with a conversion back to unsigned with any rounding mode
produces the exactly same result as if X + (X >> 1).

Same holds for 1.25:
unsigned(X * 1.25) == unsigned(X + (X >> 2))

The above transformation allows to emit a short code without floating point
computations:

test2(unsigned int):
  mov eax, edi
  shr eax
  add eax, edi
  ret


Instead of:
test(unsigned int):
  movl %edi, %edi
  pxor %xmm0, %xmm0
  cvtsi2sdq %rdi, %xmm0
  mulsd .LC0(%rip), %xmm0
  cvttsd2siq %xmm0, %rax
  ret
.LC0:
  .long 0
  .long 1073217536

[Bug target/91704] [X86] Codegen for _mm256_cmpgt_epi8 is affected by -funsigned-char

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |7.5

--- Comment #6 from Jakub Jelinek  ---
Fixed for 7.5, 8.4+ and 9.3+.

[Bug c/91664] Undefined reference linker errors when static linking archive with gcc target_clones function multi-versioning

2019-09-09 Thread marxin at gcc dot gnu.org

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

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #9 from Martin Liška  ---
(In reply to Richard Biener from comment #7)
> The issue is that with a declaration like
> 
> double fmv_test (double *dArray, int size) __attribute__ ((__target_clones__
> ("avx2","avx","sse4.1","sse2","default")));
> 
> we're creating a resolver even if there's no definition of fmv_test visible.
> We shouldn't do that.  We should only emit resolvers for definitions.

Are you sure we want to generate resolver only for definitions?
Similarly to normal declarations, it's linkers job to resolve symbols and
eventually print errors.

I don't see why the linker bails out when the archive is used.

[Bug target/91708] [10 regression][ARM] Bootstrap fails in gen_movsi, at config/arm/arm.md:5258

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #4 from Christophe Lyon  ---
(In reply to Bernd Edlinger from comment #3)
> I will try to reproduce with building of a cross for this target.

FWIW, cross-build looked fine for me at r275501:
--target arm-none-linux-gnueabihf
--with-mode arm / thumb
--with-cpu cortex-a57
--with-fpu crypto-neon-fp-armv8

[Bug target/91708] [10 regression][ARM] Bootstrap fails in gen_movsi, at config/arm/arm.md:5258

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug target/91708] [10 regression][ARM] Bootstrap fails in gen_movsi, at config/arm/arm.md:5258

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

--- Comment #3 from Bernd Edlinger  ---
I will try to reproduce with building of a cross for this target.

[Bug target/91708] [10 regression][ARM] Bootstrap fails in gen_movsi, at config/arm/arm.md:5258

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

--- Comment #2 from Wilco  ---
(In reply to Bernd Edlinger from comment #1)
> Oh, nice, could you say what config options you use?

The full set I used:

${src}/configure --disable-libsanitizer --enable-languages=c,c++ 
--prefix=${install} --target=arm-none-linux-gnueabihf
--host=arm-none-linux-gnueabihf --build=arm-none-linux-gnueabihf
--with-cpu=cortex-a57 --with-mode=thumb --with-fpu=fp-armv8 --with-float=hard

The cortex-a57 part is essential since its tuning prefers LDRD/STRD generation
while basic armv8 doesn't.

[Bug lto/84579] __gnu_lto_v1 should be removed when linking with -fno-lto

2019-09-09 Thread romain.geissler at amadeus dot com

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

--- Comment #10 from Romain Geissler  ---
Ah thanks, I had backported this one as well, but not the one you mentionned:

commit 217597acb2493b727255b66cd199fafa065427b7
Author: marxin 
Date:   Wed Jul 24 07:00:48 2019 +

Fix off-by-one in simple-object-elf.c (PR lto/91228).

2019-07-24  Martin Liska  

PR lto/91228
* simple-object-elf.c (simple_object_elf_copy_lto_debug_sections):
Find first '\0' starting from gnu_lto + 1.


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@273757
138bc75d-0d04-0410-961f-82ee72b054a4

[Bug target/91708] [10 regression][ARM] Bootstrap fails in gen_movsi, at config/arm/arm.md:5258

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

--- Comment #1 from Bernd Edlinger  ---
Oh, nice, could you say what config options you use?

[Bug target/91708] New: [10 regression][ARM] Bootstrap fails in gen_movsi, at config/arm/arm.md:5258

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

Bug ID: 91708
   Summary: [10 regression][ARM] Bootstrap fails in gen_movsi, at
config/arm/arm.md:5258
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wilco at gcc dot gnu.org
  Target Milestone: ---

Arm bootstrap still fails with latest trunk when configured with
--with-cpu=cortex-a57:

gcc/gcc/real.c:5240:1: internal compiler error: in gen_movsi, at
config/arm/arm.md:5258

This is another alignment assertion:

(define_expand "movsi"
  [(set (match_operand:SI 0 "general_operand")
(match_operand:SI 1 "general_operand"))]
  "TARGET_EITHER"
  "
  {
  rtx base, offset, tmp;

  gcc_checking_assert (aligned_operand (operands[0], SImode));
  gcc_checking_assert (aligned_operand (operands[1], SImode));

Support the Taiwan Model - A Permanent Peace System Urgently Needed in Hong Kong, Tibet, North Korea, and Chinese 33 provinces

2019-09-09 Thread Permanent peace partnership

This e-mail contains graphics, if you don't see them » view it online. (
https://vms1304.pppartner.org/tw/component/acymailing/mailid-75?key=TrZ692UK=10350971-wNeGOX9AZDT4ao=component
)

Support the Taiwan Model - A Permanent Peace System Urgently Needed in Hong
Kong, Tibet, North Korea, and Chinese provinces (33)
Permanent Peace Urgently Needs Your Support. Please Tell Your Friends and
Relatives to Go to the "Change the World” Platform at
http://chng.it/6hbwm78z (
https://vms1304.pppartner.org/index.php?option=com_acymailing=url=10350971=9=75
)

Inasmuch as we humans ultimately have only two roads to the future: peace and
destruction, faced with unending nuclear weapons development, once
nuclear warfare erupts, everything will become ashes. This points up the fact
that peace is life, is truth, and is the absolute truth of all things on
earth; It integrates the concepts of "One World” (India), “Global Unity (China)
in the East, with the West’s "One Principality, One Human
Family" and other ancient ideals. It combines modern technology and systematic
structure to provide the ultimate system urgently needed by humanity.

Inasmuch as eliminating nuclear-weapons backed autocracies cannot be achieved
with nuclear weapons alone; this calls for the proper system. "All
battles must be fought on the battlefield of "system performance." Here, each
system will be evaluated for its usefulness to nations. Thus we propose
a super-national level (UN, EU), national level (US, China, Russia), and
sub-national level (Hong Kong, Tibet, Crimea, states, provinces) system
Charter for Permanent Peace that more than 249 political entities (including
the UN 193 Member States) and countless sub-national levels can use. It
can function for a long time, will eliminate excessive wars, and can peacefully
evolve nuclear-backed authoritarian regimes. Military budgets can be
slashed and used to eliminate human poverty and spur development

Inasmuch as the Global Village embraces the theme of ‘All for One and One for
All,’ every citizen cares about their own issues even as they work
to end persecution by authoritarian regimes and other forms of evil until in
the end, "no one speaks for me anymore." Action against persecution must
anticipate reactions by the institutions it targets. Consider the strategy
behind the image here: “He drew a circle that shut me out- Heretic,
rebel, a thing to flout. But love and I had the wit to win: We drew a circle
and took him in.”

Now, we Taiwanese and the oppressed people of the world stand in front of
humanity at this historical point in time. We offer Taiwan as a model for
entering the ultimate stage of human development to achieve permanent peace for
centuries to come. This landmark constitutional proposition for world
peace presents a three-level system of constitutional standards at the
supranational, national and sub-national levels that all people and all
countries will strive to achieve, implementing human rights standards and
upholding the rights of every world citizen. This will directly lead to
universal and effective observance of the Charter for Permanent Peace and
unveil the secrets of this human system:

The Charter for Permanent Peace is based on two core concepts: 1. Achieve
permanent peace with global integration of law, global participation of
judges, and the promotion of constitutional standards (ISO); 2. Create
sustainable development: become the master of all worlds, pursuing world
harmony and advancing world government (ISO). Its 28 basic claims are divided
into two parts. One is the people's rights and obligations; the other is
national decentralization standards (referred to as Charter 228). Every clause
of the charter is a necessary condition for permanent peace in a nation
or political entity (such as Hong Kong or Tibet), but it must be drafted and
amended by the world’s heroes in order to serve as an amulet for the
people and a formula for governing nations. See the "Change the World” platform
at http://chng.it/6hbwm78z (
https://vms1304.pppartner.org/index.php?option=com_acymailing=url=10350971=10=75
) for details.

Keep in mind the lessons of history. For example, Chamberlain’s missteps cannot
be repeated... Taiwan firmly chooses to stand with the 2/3 of the
world’s people under authoritarian oppression, fighting for universal values
such as freedom, democracy, human rights, and the rule of law. In doing
so, we Taiwanese will lose only our iron curtains and chains, violence and
lies, they will suffer no loss, instead winning the capital city of a
long-prospering nation and world.

Inasmuch as approval of more than half of the electorate is needed in
democracies for decisions to be legally effective, the world's citizens must
take the lead in signing up supporters. This will enhance the "chain reaction"
effect and the power of "wave diffusion". The butterfly effect will
kick in, leading thousands of people to sign up, and quantitative change

[Bug target/87853] _mm_cmpgt_epi8 broken with -funsigned-char

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

--- Comment #17 from Jakub Jelinek  ---
Author: jakub
Date: Mon Sep  9 11:44:17 2019
New Revision: 275516

URL: https://gcc.gnu.org/viewcvs?rev=275516=gcc=rev
Log:
PR target/87853
* config/i386/emmintrin.h (_mm_cmpeq_epi8): Use casts to __v16qi
instead of __v16qs.

* gcc.target/i386/pr87853.c: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr87853.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/i386/emmintrin.h
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug target/91704] [X86] Codegen for _mm256_cmpgt_epi8 is affected by -funsigned-char

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Mon Sep  9 11:43:08 2019
New Revision: 275515

URL: https://gcc.gnu.org/viewcvs?rev=275515=gcc=rev
Log:
PR target/91704
* config/i386/avxintrin.h (__v32qs): New typedef.
* config/i386/avx2intrin.h (_mm256_cmpgt_epi8): Use casts to __v32qs
instead of __v32qi.

* gcc.target/i386/pr91704.c: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr91704.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/i386/avx2intrin.h
branches/gcc-7-branch/gcc/config/i386/avxintrin.h
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug fortran/91556] Problems with better interface checking

2019-09-09 Thread mario-baumann at web dot de

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

Mario Baumann  changed:

   What|Removed |Added

 CC||mario-baumann at web dot de

--- Comment #25 from Mario Baumann  ---
Hi all,

the following fortran code (without module/interface statements)

  SUBROUTINE FOO (A)
  IMPLICIT NONE
  DOUBLE PRECISION :: A(2)
  DOUBLE PRECISION :: B(2)
  CALL GOO (A(1))
  CALL GOO (B)
  END

returns a similar error:

> /Gcc/10.0.0/bin/gfortran -c foo.F
foo.F:6:16:

6 |   CALL GOO (B)
  |1
Error: Rank mismatch in argument '_formal_0' at (1) (scalar and rank-1)


> /Gcc/10.0.0/bin/gfortran -v
Using built-in specs.
COLLECT_GCC=/Gcc/10.0.0/bin/gfortran
COLLECT_LTO_WRAPPER=/Gcc/10.0.0/libexec/gcc/x86_64-apple-darwin17/10.0.0/lto-wrapper
Target: x86_64-apple-darwin17
Configured with: /Gcc/10.0.0/.src/configure --prefix=/Gcc/10.0.0
--build=x86_64-apple-darwin17 --enable-languages=c,c++,fortran --enable-lto
--enable-stage1-checking --enable-libstdcxx-time --disable-nls
--disable-libquadmath --disable-libquadmath-support --with-ld=/opt/local/bin/ld
--with-ar=/opt/local/bin/ar --with-as=/opt/local/bin/as --with-system-zlib
--with-pkgversion=svn-revision-275501
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.0.0 20190909 (experimental) (svn-revision-275501)

[Bug c++/91706] [8/9/10 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in equate_type_number_to_die, at dwarf2out.c:5782

2019-09-09 Thread marxin at gcc dot gnu.org

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

Martin Liška  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
Started with r251438.

[Bug target/87853] _mm_cmpgt_epi8 broken with -funsigned-char

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

--- Comment #16 from Jakub Jelinek  ---
Author: jakub
Date: Mon Sep  9 11:00:46 2019
New Revision: 275512

URL: https://gcc.gnu.org/viewcvs?rev=275512=gcc=rev
Log:
PR target/87853
* config/i386/emmintrin.h (_mm_cmpeq_epi8): Use casts to __v16qi
instead of __v16qs.

* gcc.target/i386/pr87853.c: New test.

Added:
branches/gcc-8-branch/gcc/testsuite/gcc.target/i386/pr87853.c
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/config/i386/emmintrin.h
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug target/91704] [X86] Codegen for _mm256_cmpgt_epi8 is affected by -funsigned-char

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Mon Sep  9 10:59:48 2019
New Revision: 275511

URL: https://gcc.gnu.org/viewcvs?rev=275511=gcc=rev
Log:
PR target/91704
* config/i386/avxintrin.h (__v32qs): New typedef.
* config/i386/avx2intrin.h (_mm256_cmpgt_epi8): Use casts to __v32qs
instead of __v32qi.

* gcc.target/i386/pr91704.c: New test.

Added:
branches/gcc-8-branch/gcc/testsuite/gcc.target/i386/pr91704.c
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/config/i386/avx2intrin.h
branches/gcc-8-branch/gcc/config/i386/avxintrin.h
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug sanitizer/91707] [10 Regression] spurious stringop-overflow warning with -fsanitize=undefined

2019-09-09 Thread marxin at gcc dot gnu.org

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-09
 CC||msebor at gcc dot gnu.org
  Known to work||9.2.0
   Target Milestone|--- |10.0
Summary|spurious stringop-overflow  |[10 Regression] spurious
   |warning with|stringop-overflow warning
   |-fsanitize=undefined|with -fsanitize=undefined
 Ever confirmed|0   |1
  Known to fail||10.0

--- Comment #1 from Martin Liška  ---
Confirmed, started with r273783.

[Bug target/87853] _mm_cmpgt_epi8 broken with -funsigned-char

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

--- Comment #15 from Jakub Jelinek  ---
Author: jakub
Date: Mon Sep  9 10:52:00 2019
New Revision: 275510

URL: https://gcc.gnu.org/viewcvs?rev=275510=gcc=rev
Log:
PR target/87853
* config/i386/emmintrin.h (_mm_cmpeq_epi8): Use casts to __v16qi
instead of __v16qs.

* gcc.target/i386/pr87853.c: New test.

Added:
branches/gcc-9-branch/gcc/testsuite/gcc.target/i386/pr87853.c
Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/config/i386/emmintrin.h
branches/gcc-9-branch/gcc/testsuite/ChangeLog

[Bug target/91704] [X86] Codegen for _mm256_cmpgt_epi8 is affected by -funsigned-char

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Mon Sep  9 10:51:04 2019
New Revision: 275509

URL: https://gcc.gnu.org/viewcvs?rev=275509=gcc=rev
Log:
PR target/91704
* config/i386/avxintrin.h (__v32qs): New typedef.
* config/i386/avx2intrin.h (_mm256_cmpgt_epi8): Use casts to __v32qs
instead of __v32qi.

* gcc.target/i386/pr91704.c: New test.

Added:
branches/gcc-9-branch/gcc/testsuite/gcc.target/i386/pr91704.c
Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/config/i386/avx2intrin.h
branches/gcc-9-branch/gcc/config/i386/avxintrin.h
branches/gcc-9-branch/gcc/testsuite/ChangeLog

[Bug c++/91706] [8/9/10 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in equate_type_number_to_die, at dwarf2out.c:5782

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-09
   Target Milestone|--- |8.4
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.

The struct B type has a member

 
asm_written external nonlocal suppress-debug decl_6 VOID t.C:12:9
align:8 warn_if_not_align:0 context 
result 
fullname 

normal local bindings <0x75d40be0>>
chain >
   >

which we don't expect.  Frontend issue.  It should have raised an error here?

> clang++ t.C
t.C:16:3: error: static_assert failed due to requirement 'B
  >::type::value' "assertion failed"
  static_assert(B>::type::value, "assertion failed");
  ^ 
1 error generated.


The ICE with GCC 9 is the same

note DECL_ORGINAL_TYPE is "sane" (well, 'void').  And dwarf2out has

25421 if (DECL_ORIGINAL_TYPE (decl))
25422   {
25423 type = DECL_ORIGINAL_TYPE (decl);
25424 if (type == error_mark_node)
25425   return;
25426
25427 gcc_assert (type != TREE_TYPE (decl));
25428 equate_type_number_to_die (TREE_TYPE (decl), type_die);

so it checks DECL_ORIGINAL_TYPE but then uses TREE_TYPE which actually
is error_mark_node.

[Bug target/87853] _mm_cmpgt_epi8 broken with -funsigned-char

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

--- Comment #14 from Jakub Jelinek  ---
Author: jakub
Date: Mon Sep  9 10:31:02 2019
New Revision: 275508

URL: https://gcc.gnu.org/viewcvs?rev=275508=gcc=rev
Log:
PR target/87853
* config/i386/emmintrin.h (_mm_cmpeq_epi8): Use casts to __v16qi
instead of __v16qs.

* gcc.target/i386/pr87853.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr87853.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/emmintrin.h
trunk/gcc/testsuite/ChangeLog

[Bug target/91704] [X86] Codegen for _mm256_cmpgt_epi8 is affected by -funsigned-char

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Mon Sep  9 10:26:50 2019
New Revision: 275507

URL: https://gcc.gnu.org/viewcvs?rev=275507=gcc=rev
Log:
PR target/91704
* config/i386/avxintrin.h (__v32qs): New typedef.
* config/i386/avx2intrin.h (_mm256_cmpgt_epi8): Use casts to __v32qs
instead of __v32qi.

* gcc.target/i386/pr91704.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr91704.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/avx2intrin.h
trunk/gcc/config/i386/avxintrin.h
trunk/gcc/testsuite/ChangeLog

[Bug c++/91705] operator++ broken in constexpr floating point code

2019-09-09 Thread john at johnmaddock dot co.uk

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

--- Comment #1 from John Maddock  ---
Forgot to add: this effects operators ++ and -- in both prefix and postfix
versions.  The standard selected (14,17,2a) makes no difference.

[Bug fortran/91686] ICE in gimplify:2554

2019-09-09 Thread pault at gcc dot gnu.org

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

Paul Thomas  changed:

   What|Removed |Added

 Status|WAITING |NEW
   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org

--- Comment #4 from Paul Thomas  ---
Created attachment 46855
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46855=edit
Fix for the PR

D.3530 = (*(integer(kind=4)[0:] *) parm.1.data)[parm.1.dim[0].stride *
NON_LVALUE_EXPR ];

appeared before D.3530 was declared and outside of the loop, so that S.3 was
undefined.

Fortunately, I remembered the fix and went straight to it. I have simply copied
and pasted the correct code from the current trunk.

I will commit tomorrow morning.

Paul

[Bug rtl-optimization/91656] [10 Regression] wrong code with -fgcse-after-reload

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #11 from Richard Biener  ---
We have PR91676 tracking that.

[Bug sanitizer/91707] New: spurious stringop-overflow warning with -fsanitize=undefined

2019-09-09 Thread uecker at eecs dot berkeley.edu

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

Bug ID: 91707
   Summary: spurious stringop-overflow warning with
-fsanitize=undefined
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: uecker at eecs dot berkeley.edu
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

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

With recent GCC versions from git there is a spurious warning
when the undefined behavior sanitizer is used.


$ ../gcc_build_clean/gcc/xgcc -B ../gcc_build_clean/gcc -Wall -O2 
-fsanitize=undefined -c strop.c 
In function ‘real_from_complex_dims’,
inlined from ‘md_test’ at strop.c:14:2:
strop.c:7:11: warning: writing 8 bytes into a region of size 0
[-Wstringop-overflow=]
7 |  odims[0] = 2;
  |  ~^~~
$ ../gcc_build_clean/gcc/xgcc --version
xgcc (GCC) 10.0.0 20190907 (experimental)
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ cat strop.c 

extern void md_copy_dims(unsigned int D, long odims[D], const long idims[D]);
extern void md_test(unsigned int D, const long idims[D]);

static void real_from_complex_dims(unsigned int D, long odims[D + 1], const
long idims[D])
{
   odims[0] = 2;
   md_copy_dims(D, odims + 1, idims);
}

void md_test(unsigned int D, const long idims[D])
{
   long dimsR[D + 1];
   real_from_complex_dims(D, dimsR, idims);

   long strsR[D + 1];
   (void)strsR;

   return;
}

[Bug c++/91706] New: [8/9/10 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in equate_type_number_to_die, at dwarf2out.c:5782

2019-09-09 Thread szotsaki at gmail dot com

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

Bug ID: 91706
   Summary: [8/9/10 Regression] ICE: tree check: expected class
'type', have 'exceptional' (error_mark) in
equate_type_number_to_die, at dwarf2out.c:5782
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: szotsaki at gmail dot com
  Target Milestone: ---

The following test case causes internal compiler error:

#include 
#include 

struct A {
  template 
  static std::false_type fn(...);
};

template 
struct B : public A  {
  using fn = decltype(fn(0));
  using type = typename std::conditional::type;
};

int main(){
  static_assert(B>::type::value, "assertion failed");
}

If you change either of them, the bug will go away:
- Move A::fn() out of its structure thus make "B : public A" inheritance
unnecessary
- Rename B::fn to something else, like B::fn_alias.

The issue first appeared in 8.1 (7.4 is fine) and still occurs with 10.0.0
20190908.

Error messages:

GCC 10.0:
internal compiler error: tree check: expected class 'type', have 'exceptional'
(error_mark) in equate_type_number_to_die, at dwarf2out.c:5782

9.2 - 8.1:
internal compiler error: in is_base_type, at dwarf2out.c:12987

Related issue: Bug 87772 (though I don't know whether the path is the same
which led to a similar ICE message).

[Bug middle-end/91703] Segmentation Fault

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

Richard Biener  changed:

   What|Removed |Added

 Target||avr
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-09-09
  Component|ada |middle-end
   Host||mingw64
Version|unknown |5.4.0
 Ever confirmed|0   |1
  Build||mingw64

--- Comment #1 from Richard Biener  ---
Guessing some bits.  Note GCC 5 is no longer supported, you should look for a
newer version of the AVR toolchain.

[Bug target/91702] [9/10 Regression] ICE with mips16

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.3
Summary|ICE with mips16 |[9/10 Regression] ICE with
   ||mips16

[Bug tree-optimization/91699] [10 Regression] Bogus warnings with -O3 -flto after revision r274997