[Bug target/77930] New: Compile time hog w/ -O2 -g -funroll-loops -ftree-loop-if-convert-stores on 32-bit targets

[asolokha at gmx dot com]

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

Bug ID: 77930
   Summary: Compile time hog w/ -O2 -g -funroll-loops
-ftree-loop-if-convert-stores on 32-bit targets
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: compile-time-hog
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: armv7a-hardfloat-linux-gnueabihf, powerpc-*-linux-gnu*

gcc for various 32-bit targets takes disproportionally large time to compile
the following reduced snippet w/ -O2 -g -funroll-loops
-ftree-loop-if-convert-stores:

int t7;

void
wm (int ch)
{
  int os = 0;
  int m7;

  for (m7 = 0; m7 < 16; ++m7)
{
  int p1 = 1 / ch;

  if (p1 != 0)
os = p1;
  else
{
  t7 &= os;
  os = t7;
}
}
}

% time powerpc-e300c3-linux-gnu-gcc-7.0.0-alpha20161009 -O1 -g -funroll-loops
-ftree-loop-if-convert-stores -misel -c mzubcyet.c   
powerpc-e300c3-linux-gnu-gcc-7.0.0-alpha20161009 -O1 -g -funroll-loops  -mise 
46.01s user 0.04s system 88% cpu 51.776 total
% time powerpc-e300c3-linux-gnu-gcc-4.8.5 -O1 -g -funroll-loops
-ftree-loop-if-convert-stores -misel -c mzubcyet.c  
^C
zsh: interrupt  powerpc-e300c3-linux-gnu-gcc-4.8.5 -O1 -g -funroll-loops 
-misel -c mzubcyet.
powerpc-e300c3-linux-gnu-gcc-4.8.5 -O1 -g -funroll-loops  -misel -c mzubcyet. 
0.00s user 0.00s system 0% cpu 2:47.99 total

I've been able to reproduce it w/ armv7a-hardfloat-linux-gnueabihf,
powerpc-e300c3-linux-gnu, powerpc-e500v2-linux-gnuspe from the current trunk
all the way back to 4.8.5 (I don't have versions prior to 4.8). Note that
-misel seems to be also necessary for powerpc.

[Bug tree-optimization/77929] New: [7 Regression] ICE: verify_gimple failed (error: non-trivial conversion at assignment)

[asolokha at gmx dot com]

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

Bug ID: 77929
   Summary: [7 Regression] ICE: verify_gimple failed (error:
non-trivial conversion at assignment)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-7.0.0-alpha20161009 ICEs when compiling the following reduced snippet at
-O1 (-O2, -O3, -Ofast):

void
jx (int xg, unsigned short int rn)
{
  int g2 = 0;
  int nf = (rn != 0) ? (xg < rn) : (g2 < 0);

  if ((xg >= 0) & nf)
while (xg != 0)
  
}

% gcc-7.0.0-alpha20161009 -O1 -c bhtuxg1w.c 
bhtuxg1w.c: In function 'jx':
bhtuxg1w.c:2:1: error: non-trivial conversion at assignment
 jx (int xg, unsigned short int rn)
 ^~
int
_Bool
_5 = _11;
bhtuxg1w.c:2:1: internal compiler error: verify_gimple failed

[Bug c++/77927] unary right fold fails to compile

[jeff.mirwaisi at gmail dot com]

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

--- Comment #3 from Jeff Mirwaisi  ---
Apologies for the poor bug report, to clarify, unary right folds which use a
binary 
operator in the fold parameter are failing to compile:

( (x op1 y) op2... );

//clearer examples - error: binary expression in operand of fold-expression
template void f1(){ ((N+1)+...); }
template void f2(){ ((1+N),...); }  
template void f3(){ ((N-1)*...); }

//op1 and op2 do not have to be the same operator

//the corresponding left folds compile as expected:
template void f4(){ (...+(1+N)); }

[Bug tree-optimization/77921] [7 Regression] tree-ssanames.c miscompiled during PGO bootstrap

[trippels at gcc dot gnu.org]

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

--- Comment #5 from Markus Trippelsdorf  ---
(In reply to kugan from comment #4)
> Sorry about the breakage. I will try to reproduce it.
> 
> (In reply to Markus Trippelsdorf from comment #1)
> > gcc version 7.0.0 20161007 was fine
> Are you saying that this is issue is gone latent? 20161007 should have
> early-vrp and ipa-vrp.

Since r240865 PGO bootstrapped gcc spins when compiling crafty.
So the question is if the endless loop is legitimate or not.
If not, then r240291 is causing wrong code.
If OK, then Richi's r240865 is the cause and this bug is a dup of PR77920.

[Bug tree-optimization/77902] Auto-vectorizes epilogue loops of manually vectorized functions

[linux at carewolf dot com]

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

--- Comment #2 from Allan Jensen  ---
While this have been the case in both GCC 5 and GCC 6, it appears to both
failing cases previously meantioned already produced the best case result in
using a half recent GCC 7.
gcc version 7.0.0 20160923 (experimental) (GCC)

[Bug tree-optimization/77921] [7 Regression] tree-ssanames.c miscompiled during PGO bootstrap

[kugan at gcc dot gnu.org]

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

--- Comment #4 from kugan at gcc dot gnu.org ---
Sorry about the breakage. I will try to reproduce it.

(In reply to Markus Trippelsdorf from comment #1)
> gcc version 7.0.0 20161007 was fine
Are you saying that this is issue is gone latent? 20161007 should have
early-vrp and ipa-vrp.

[Bug tree-optimization/77902] Auto-vectorizes epilogue loops of manually vectorized functions

[linux at carewolf dot com]

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

--- Comment #1 from Allan Jensen  ---
Further experimentation shows that GCC can sometimes reason about the remaining
range but does so inconsistenly.

For instance this examplse also fails:
int result = 0;
for (; count >= 4; count -= 4) {
// Manually vectorized or batched code
foobar_4x(result, vector);
vector += 4;
}
for (; count >= 0; --count) {   // Still autovectorized
result += *vector++;
}

But replacing the epilogue with a loop that counts up, and GCC
appears to figure out it is pointless to vectorize:

for (int i = 0; i < count; ++count) { // correctly not vectorized

[Bug c++/77927] unary right fold fails to compile

[jeff.mirwaisi at gmail dot com]

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

--- Comment #2 from Jeff Mirwaisi  ---
//error: binary expression in operand of fold-expression

[Bug target/77586] [7 Regression] ia64 target fails to build due to ICE triggered by -fself-test

[jsm28 at gcc dot gnu.org]

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

--- Comment #3 from Joseph S. Myers  ---
Author: jsm28
Date: Mon Oct 10 22:43:07 2016
New Revision: 240955

URL: https://gcc.gnu.org/viewcvs?rev=240955=gcc=rev
Log:
Always support float128 on ia64 (PR target/77586).

Bug 77586, and previously
, reports
ia64-elf failing to build because of float128_type_node being NULL,
but being used by the back end for __float128.

The global float128_type_node is only available conditionally, if
target hooks indicate TFmode is not only available as a scalar mode
and of the right format, but also supported in libgcc.  The back-end
support, however, expects the type always to be available for
__float128 even if the libgcc support is missing.

Although a target-specific node could be restored in the case where
libgcc support is missing, it seems better to address the missing
libgcc support.  Thus, this patch enables TFmode soft-fp in libgcc
globally for all ia64 targets.  Support for XFmode in libgcc (that is,
for libgcc2.c XFmode functions, not soft-fp) is also enabled for all
ia64 targets so that ia64 no longer needs to define the
TARGET_LIBGCC_FLOATING_MODE_SUPPORTED_P hook.

I've confirmed that ia64-elf builds cc1 with this patch and it passes
-fself-test.  I have not otherwise tested the patch.  It's plausible
that ia64-elf and ia64-freebsd might work as-is, but ia64-vms probably
needs further changes, by someone familiar with VMS shared libraries,
to implement an equivalent of ia64/t-softfp-compat in that case
(avoiding conflicts between __divtf3 from soft-fp and the old alias
for __divxf3).

PR target/77586
gcc:
* config/ia64/ia64.c (ia64_libgcc_floating_mode_supported_p)
(TARGET_LIBGCC_FLOATING_MODE_SUPPORTED_P): Remove.
* config/ia64/elf.h (IA64_NO_LIBGCC_TFMODE): Likewise.
* config/ia64/freebsd.h (IA64_NO_LIBGCC_TFMODE): Likewise.
* config/ia64/vms.h (IA64_NO_LIBGCC_XFMODE)
(IA64_NO_LIBGCC_TFMODE): Likewise.

libgcc:
* config.host (ia64*-*-elf*, ia64*-*-freebsd*, ia64-hp-*vms*): Use
soft-fp.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/ia64/elf.h
trunk/gcc/config/ia64/freebsd.h
trunk/gcc/config/ia64/ia64.c
trunk/gcc/config/ia64/vms.h
trunk/libgcc/ChangeLog
trunk/libgcc/config.host

[Bug target/77586] [7 Regression] ia64 target fails to build due to ICE triggered by -fself-test

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

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

--- Comment #4 from Joseph S. Myers  ---
Patch committed.

[Bug middle-end/77928] New: Add __builtin_iseqsig

[jsm28 at gcc dot gnu.org]

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

Bug ID: 77928
   Summary: Add __builtin_iseqsig
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
  Target Milestone: ---

TS 18661-1 defines a type-generic floating-point comparison macro iseqsig, that
compares its arguments for equality but generates the "invalid" exception (and
sets errno) if either argument is NaN, unlike ==.

GCC should have a corresponding __builtin_iseqsig that does the comparison and
raises "invalid" as needed (but without setting errno, so it could only be used
to implement the standard macro if -fno-math-errno).  As with existing
type-generic comparison functions the logic in fold_builtin_unordered_cmp is
needed to convert the arguments to a common type.  This operation is equivalent
to (x <= y) && (x >= y) (with arguments only evaluated once, of course), though
some architectures may have more efficient ways of doing such a comparison (and
if the architecture lacks support for exceptions, simple == can be used). 
However, various architectures have bugs where the <= comparison fails to raise
the exception it should for NaN arguments (bug 52451, bug 58684, bug 77918).

[Bug c++/77927] unary right fold fails to compile

[jeff.mirwaisi at gmail dot com]

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

--- Comment #1 from Jeff Mirwaisi  ---
//unary right fold fails to compile
template void f(){int A[]={(((void)N,int()),...)};}

//corresponding left fold works as expected
template void f(){int A[]={(...,((void)N,int()))};}

//both are simple tests that generate a single element array int A[1]={0}

[Bug c++/77927] New: unary right fold fails to compile

[jeff.mirwaisi at gmail dot com]

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

Bug ID: 77927
   Summary: unary right fold fails to compile
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jeff.mirwaisi at gmail dot com
  Target Milestone: ---

//Unary right fold fails to compile

[Bug tree-optimization/77898] incorrect VR_ANTI_RANGE after evrp and before vrp1

[msebor at gcc dot gnu.org]

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

--- Comment #8 from Martin Sebor  ---
No, I get the range for _2 with a "def_stmt _2 = (sizetype) i_4;"

i.0_1: [0, +INF]
_2: ~[2147483648, 18446744071562067967]
_3: [0, +INF]
i_4: VARYING
i_6(D): VARYING

...
  # i_4 = PHI 
  _2 = (sizetype) i_4;
  p_8 = "ab" + _2;

I don't think this is a bug (anymore).  I understand that it's 1) a limitation
of the EVRP pass as you explained (thank you), combined with 2) the sensible
get_range_info() property that it can return an increasingly refined range each
time it's called, combined with 3) the (possibly deliberate) limitation of the
tree-object-size pass that wasn't written to make use of VRP, and combined with
4) the quirk of POINTER_PLUS_EXPR taking an unsigned operand even for signed
arguments.  (Though the last one does feel like a design defect.)

I agree that in many cases there isn't enough information to tell that a range
is final and can't be further improved.  But there certainly are such cases
(the test case in comment #0 is an example of one) and it seems to me that
distinguishing the two sets from one another would be useful in order to avoid
recomputing the same result over and over.

I think it should be possible to call set_range_info() on the result of the
__builtin_object_size, and perhaps even on the offset variable in (p += i)
since its value is constrained not only by the range of its type (before VRP1)
and by statements like the 'if (i < 0 || 1 < i) i = 0;' (after VRP1) but also
by the increment '(p += i)' which is only defined for i in [0, 3] as determined
by the tree-object-size pass before VRP1.  Let me give that a try.

It seems to me that there should many other opportunities to call
set_range_info() in GCC that could help improve the generated code (and the
ability to find bugs via warnings).  I count just 9 calls to the function in
the whole code base.

[Bug middle-end/77926] New: Add __builtin_iszero

[jsm28 at gcc dot gnu.org]

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

Bug ID: 77926
   Summary: Add __builtin_iszero
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
  Target Milestone: ---

TS 18661-1 defines an iszero type-generic floating-point classification macro. 
GCC should have a corresponding type-generic built-in function
__builtin_iszero.  As with other such type-generic classification functions it
should be included in the cases in c-typeck.c:convert_arguments that remove
excess precision.  (In the absence of signaling NaNs this can just be a
comparison against 0.)

[Bug middle-end/77925] Add __builtin_issubnormal

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug middle-end/77925] New: Add __builtin_issubnormal

[jsm28 at gcc dot gnu.org]

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

Bug ID: 77925
   Summary: Add __builtin_issubnormal
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
  Target Milestone: ---

TS 18661-1 defines an issubnormal type-generic floating-point classification
macro.  GCC should have a corresponding type-generic built-in function
__builtin_issubnormal.  As with other such type-generic classification
functions it should be included in the cases in c-typeck.c:convert_arguments
that remove excess precision.

[Bug bootstrap/77917] undefined reference to '__aeabi_unwind_cpp_pr0' during ARM bootstrap

[tulipawn at gmail dot com]

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

--- Comment #3 from PeteVine  ---
Unfortunately, even with `--with-build-config=bootstrap-lto` the result was
unchanged which makes the issue real after all?

Unsurprisingly, eliminating just the `-flto` flag (-flto=4 to be exact) led to
a successful bootstrap, as usual.

[Bug tree-optimization/77424] Identical statements in if-else branches

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com
   Assignee|unassigned at gcc dot gnu.org  |law at redhat dot com

--- Comment #3 from Jeffrey A. Law  ---
Thanks.  There was a time when there was an else-if conditional between those
two which did something slightly different.

Removal of threading through backedges in the old style jump threader removed
that else-if conditional.  I just missed the second order cleanup.  I think at
that point in the code now we can just delete any remaining jump threads.  I'll
get that tested...

[Bug tree-optimization/77898] incorrect VR_ANTI_RANGE after evrp and before vrp1

[glisse at gcc dot gnu.org]

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

--- Comment #7 from Marc Glisse  ---
(In reply to Martin Sebor from comment #6)
> I meant a subrange of the i variable (i.e., a subrange of int).  The range
> of every variable is necessarily bounded by its type so returning a range of
> [INT_MIN, INT_MAX] for an int isn't terribly helpful.

Do you actually get that range when calling get_range_info on the int i_6 (as
opposed to _2 or i.0_1, which are different variables of different types)? If
so, it looks like a bug.

> I understand that the range is the most accurate it can be at this stage
> (after EVRP and before VRP1) and the get_range_info() function doesn't have
> enough smarts to indicate whether there's a chance the range might improve
> (e.g., after inlining or even with LTO).

I can't think of many cases where you know there is no chance of improving the
range, but the result is not constant.

> I suspect your suggestion is what I'm going to have to go with.  What
> bothers me about it is that it means embedding assumptions into the
> tree-object-size pass about the number of times it runs, and throwing away
> possibly optimal results computed in the initial runs of the pass and only
> using the last one, even if the last one is no better than the first.
> 
> In general this approach also denies downstream clients of a pass the
> benefit of gradually refining their results based on gradual refinements of
> the results provided by it.  In this case, it means preventing the
> tree-object-size pass from returning a potentially useful if not optimal
> size of an object based on the type (but not the value) of the offset. 
> Instead, the tree-object-size pass must return a "don't know" value even
> though it "knows" that the value is in some range.

Hmm, now it sounds like you want to set a value range on the lhs of the __bos
call. Is there some reason not to do that?

[Bug c++/64666] gcc wrongly accepts assignment in constant expression

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-10
 Ever confirmed|0   |1

--- Comment #8 from Jason Merrill  ---
Ah, true.  There's a comment in the parser that says

  /* Although the grammar says "conditional-expression", we parse an
 "assignment-expression", which also permits "throw-expression" 
 and the use of assignment operators.  In the case that 
 ALLOW_NON_CONSTANT_P is false, we get better errors than we would  
 otherwise.  In the case that ALLOW_NON_CONSTANT_P is true, it is   
 actually essential that we look for an assignment-expression.  
 For example, cp_parser_initializer_clauses uses this function to   
 determine whether a particular assignment-expression is in fact
 constant.  */

but with constexpr it seems that we need to be stricter.

[Bug tree-optimization/77898] incorrect VR_ANTI_RANGE after evrp and before vrp1

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor  ---
I meant a subrange of the i variable (i.e., a subrange of int).  The range of
every variable is necessarily bounded by its type so returning a range of
[INT_MIN, INT_MAX] for an int isn't terribly helpful.  It's no different than
the range returned for i without the if statement:

void f (int i)
{
  const char *p = "ab";

  p += i;

  unsigned long n = __builtin_object_size (p, 2);

  if (n < 2 || 3 < n)
__builtin_abort ();
}

I understand that the range is the most accurate it can be at this stage (after
EVRP and before VRP1) and the get_range_info() function doesn't have enough
smarts to indicate whether there's a chance the range might improve (e.g.,
after inlining or even with LTO).

I suspect your suggestion is what I'm going to have to go with.  What bothers
me about it is that it means embedding assumptions into the tree-object-size
pass about the number of times it runs, and throwing away possibly optimal
results computed in the initial runs of the pass and only using the last one,
even if the last one is no better than the first.

In general this approach also denies downstream clients of a pass the benefit
of gradually refining their results based on gradual refinements of the results
provided by it.  In this case, it means preventing the tree-object-size pass
from returning a potentially useful if not optimal size of an object based on
the type (but not the value) of the offset.  Instead, the tree-object-size pass
must return a "don't know" value even though it "knows" that the value is in
some range.

[Bug c++/77912] [C++17 feature] class template deduction fails in template functions and generic lambdas

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #6 from Jason Merrill  ---
Fixed.

[Bug c++/77890] class template type deduction fails for lambda functions

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #5 from Jason Merrill  ---
Fixed.

[Bug c++/77912] [C++17 feature] class template deduction fails in template functions and generic lambdas

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Mon Oct 10 20:48:51 2016
New Revision: 240948

URL: https://gcc.gnu.org/viewcvs?rev=240948=gcc=rev
Log:
C++17 class deduction issues

PR c++/77890
PR c++/77912
* pt.c (do_class_deduction): Set cp_unevaluated_operand.
(tsubst) [TEMPLATE_TYPE_PARM]: Copy CLASS_PLACEHOLDER_TEMPLATE.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/class-deduction19.C
trunk/gcc/testsuite/g++.dg/cpp1z/class-deduction20.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug c++/77890] class template type deduction fails for lambda functions

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Mon Oct 10 20:48:51 2016
New Revision: 240948

URL: https://gcc.gnu.org/viewcvs?rev=240948=gcc=rev
Log:
C++17 class deduction issues

PR c++/77890
PR c++/77912
* pt.c (do_class_deduction): Set cp_unevaluated_operand.
(tsubst) [TEMPLATE_TYPE_PARM]: Copy CLASS_PLACEHOLDER_TEMPLATE.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/class-deduction19.C
trunk/gcc/testsuite/g++.dg/cpp1z/class-deduction20.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug tree-optimization/71947] [6/7 Regression] x ^ y not folded to 0 if x == y by DOM

[law at gcc dot gnu.org]

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

--- Comment #12 from Jeffrey A. Law  ---
Author: law
Date: Mon Oct 10 20:40:59 2016
New Revision: 240947

URL: https://gcc.gnu.org/viewcvs?rev=240947=gcc=rev
Log:
PR tree-optimization/71947
* tree-ssa-dom.c (cprop_into_stmt): Avoid replacing A with B, then
B with A within a single statement.

PR tree-optimization/71947
* gcc.dg/tree-ssa/pr71947-1.c: New test.
* gcc.dg/tree-ssa/pr71947-2.c: New test.
* gcc.dg/tree-ssa/pr71947-3.c: New test.
* gcc.dg/tree-ssa/pr71947-4.c: New test.
* gcc.dg/tree-ssa/pr71947-5.c: New test.
* gcc.dg/tree-ssa/pr71947-6.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr71947-1.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr71947-2.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr71947-3.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr71947-4.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr71947-5.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr71947-6.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-dom.c

[Bug tree-optimization/77898] incorrect VR_ANTI_RANGE after evrp and before vrp1

[glisse at gcc dot gnu.org]

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

--- Comment #5 from Marc Glisse  ---
(In reply to Martin Sebor from comment #4)
> I suppose I was expecting that that after EVRP (and before VRP1)
> get_range_info() would either succeed and return a range representing a
> subrange of the the variable's type or fail and return VR_VARYING.

But that's what it did! It succeeded in finding an anti-range that describes a
subrange of the variable's type (sizetype).

> If instead the first one or two times the tree-object-size pass ran
> it could somehow determine that a) the range it got from get_range_info()
> wasn't as good as it could be, and b) that it will run again and will get
> another chance to refine the result, it could avoid using the suboptimal
> results and ultimately return the correct answer.

Looks like you want to enable your new transformation only in the last
object-size pass? Otherwise, there is always a chance the range might shrink
before the next pass (though there might also be a possibility for a wider
range, if we commonize several calls to __bos).

[Bug c++/77825] [7 Regression] return type deduction regression in C++17 mode

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |UNCONFIRMED
 CC||jason at gcc dot gnu.org
 Ever confirmed|1   |0

--- Comment #2 from Jason Merrill  ---
This is due to the C++17 constexpr lambda change: previously, we would defer
instantiation of the lambda operator() until EOF, but now we instantiate it
immediately when we call it from y_combinator's operator().  Since we haven't
completed instantiating that function yet, it doesn't have a real return type
yet, so the mutual recursion leads to an error.

[Bug tree-optimization/77898] incorrect VR_ANTI_RANGE after evrp and before vrp1

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
I suppose I was expecting that that after EVRP (and before VRP1)
get_range_info() would either succeed and return a range representing a
subrange of the the variable's type or fail and return VR_VARYING.

If the range returned by get_range_info() gets refined as other passes provide
more insight into the data flow through the program (which makes perfect sense)
then there ought to be a way for callers to hold off on using the suboptimal
range if another one is coming than might be better.

To translate it to the case I'm dealing with: the tree-object-size pass runs
three times, the first time after EVRP but before VRP1, then again after VRP1,
and finally after VRP2.  If the first time it runs it calls get_range_info() to
compute the result of (p += 1) and gets back [INT_MIN, INT_MAX] then it will
set the minimum size of the object to which p points to 0 resulting in
__builtin_object_size (p, 2) returning a subopptimal value.  If instead the
first one or two times the tree-object-size pass ran it could somehow determine
that a) the range it got from get_range_info() wasn't as good as it could be,
and b) that it will run again and will get another chance to refine the result,
it could avoid using the suboptimal results and ultimately return the correct
answer.

[Bug target/68752] PowerPC: vector reciprocal square root estimate missed optimisations

[cel at us dot ibm.com]

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

--- Comment #4 from Carl Love  ---
I do not seem to have permission to change the status of the bug.  

Anton, can you recheck the issue and close if you agree it is no longer an
issue.  Thanks.

  Carl

[Bug target/68752] PowerPC: vector reciprocal square root estimate missed optimisations

[cel at us dot ibm.com]

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

--- Comment #3 from Carl Love  ---
I investigated the issue using GCC 6.1. The t1() function from file
recip-vec-sqrtf.c file is as follows:

void t1(void)
{
int i;

for (i = 0; i < 4; i++)
  r[i] = a[i] / sqrtf (b[i]);
}

The assembly code being generated for the loop using the options specified in
the bug plus -S to generate the assembly code results in the following

 -O2 -ffast-math -ftree-vectorize -mcpu=power7 -mrecip -fno-common  -S 

.file "recip-vec-sqrtf.c"
.section ".toc","aw"
.section ".text"
.machine power7
.align 2
.p2align 4,,15
.globl t1
.section ".opd","aw"
.align 3
t1:
.quad .L.t1,.TOC.@tocbase
.previous
.type t1, @function
.L.t1:
addis 9,2,.LANCHOR0@toc@ha
addis 10,2,.LC0@toc@ha
addi 9,9,.LANCHOR0@toc@l
addi 10,10,.LC0@toc@l
lxvd2x 12,0,9
lxvd2x 11,0,10
li 10,32
lxvd2x 10,9,10
li 10,16
xvrsqrtesp 0,12
xvmsubasp 12,12,11
xvmulsp 9,0,0
xvnmsubasp 11,12,9
xvmulsp 0,0,11
xvmulsp 0,0,10
stxvd2x 0,9,10
blr

The expected vector instructions are there.  It does not appear that any scalar
instructions are being generated for the computation as implied in the
bugzilla.

The other loops for the test cases in attachment 36938 are similar in that they
appear to only be generating the expected vector instructions.  The bugzilla
was filed before GCC 6 was released.  It appears the issue has since been
fixed.

[Bug target/68752] PowerPC: vector reciprocal square root estimate missed optimisations

[cel at us dot ibm.com]

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

Carl Love  changed:

   What|Removed |Added

 CC||cel at us dot ibm.com

--- Comment #2 from Carl Love  ---
I investigated the issue using GCC 6.1. The t1() function from file
recip-vec-sqrtf.c file is as follows:

void t1(void)
{
int i;

for (i = 0; i < 4; i++)
  r[i] = a[i] / sqrtf (b[i]);
}

The assembly code being generated for the loop using the options specified in
the bug plus -S to generate the assembly code results in the following

 -O2 -ffast-math -ftree-vectorize -mcpu=power7 -mrecip -fno-common  -S 

.file "recip-vec-sqrtf.c"
.section ".toc","aw"
.section ".text"
.machine power7
.align 2
.p2align 4,,15
.globl t1
.section ".opd","aw"
.align 3
t1:
.quad .L.t1,.TOC.@tocbase
.previous
.type t1, @function
.L.t1:
addis 9,2,.LANCHOR0@toc@ha
addis 10,2,.LC0@toc@ha
addi 9,9,.LANCHOR0@toc@l
addi 10,10,.LC0@toc@l
lxvd2x 12,0,9
lxvd2x 11,0,10
li 10,32
lxvd2x 10,9,10
li 10,16
xvrsqrtesp 0,12
xvmsubasp 12,12,11
xvmulsp 9,0,0
xvnmsubasp 11,12,9
xvmulsp 0,0,11
xvmulsp 0,0,10
stxvd2x 0,9,10
blr

The expected vector instructions are there.  It does not appear that any scalar
instructions are being generated for the computation as implied in the
bugzilla.

The other loops for the test cases in attachment 36938 are similar in that they
appear to only be generating the expected vector instructions.  The bugzilla
was filed before GCC 6 was released.  It appears the issue has since been
fixed.

[Bug tree-optimization/71947] [6/7 Regression] x ^ y not folded to 0 if x == y by DOM

[law at redhat dot com]

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

--- Comment #11 from Jeffrey A. Law  ---
So I don't like the pain of trying to fold at each propagation step. 
Specifically, the structure of the gimple statement can change, which
invalidates the operand cache.  And the canonicalization of operands based on
their SSA_NAME_VERSIONs means it's possible to get cycles.  While I've got
something that appears to work, I'm not at all happy with it.

So I started looking at a different approach.  Just keep a record of copy
propagated objects and if we've already propagated A for B, don't copy
propagate B for A in the same statement.  We can do this with a bitmap, but
that's a lot of overhead, even when lazily initialized.  I suspect this matters
so rarely in practice that a single entry "this was the last thing copy
propagated" is sufficient.

[Bug tree-optimization/77898] incorrect VR_ANTI_RANGE after evrp and before vrp1

[glisse at gcc dot gnu.org]

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

--- Comment #3 from Marc Glisse  ---
(In reply to Martin Sebor from comment #2)
> I may also be confused about other things but below is what I see in GDB
> when I call get_range_info() from plus_stmt_object_size() on the offset in
> POINTER_PLUS_EXPR (get_offset_range is a function I've added in my patch for
> bug 77608).  As best I can tell the anti-range doesn't correspond to the
> range of the variable i which is [0, 1].

You seem to be assuming that EVRP is clever enough to find out that the range
of i_4 is [0, 1], as VRP1 does. However, EVRP is a limited version, which
doesn't manage it in this case. All it knows is that _2 is an unsigned long
obtained by casting from some arbitrary int, so its range is the union of [0,
INT_MAX] (if the int is non-negative) and [ULONG_MAX+INT_MIN+1,ULONG_MAX] (if
the int is negative), which is represented as an anti-range. This conservative
(anti-)range is valid, since it contains [0,1].

Now maybe evrp could be enhanced to find a tighter range without making it too
costly, I don't know.

[Bug target/77924] -mfloat128-type change broke AIX

[meissner at gcc dot gnu.org]

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

--- Comment #2 from Michael Meissner  ---
Created attachment 39785
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39785=edit
Revised proposed patch to fix the problem without syntax error

[Bug tree-optimization/77824] unreachable code in SLSR GIMPLE pass

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

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

--- Comment #8 from Bill Schmidt  ---
Fixed.

[Bug tree-optimization/77824] unreachable code in SLSR GIMPLE pass

[wschmidt at gcc dot gnu.org]

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

--- Comment #7 from Bill Schmidt  ---
Author: wschmidt
Date: Mon Oct 10 18:39:41 2016
New Revision: 240945

URL: https://gcc.gnu.org/viewcvs?rev=240945=gcc=rev
Log:
2016-10-10  Bill Schmidt  

PR tree-optimization/77824
* gimple-ssa-strength-reduction.c (stmt_cost): Explicitly return
zero cost for copies.
(find_candidates_dom_walker::before_dom_children): Replace
MODIFY_EXPR with SSA_NAME.
(replace_mult_candidate): Likewise.
(replace_profitable_candidates): Likewise.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-strength-reduction.c

[Bug c++/64666] gcc wrongly accepts assignment in constant expression

[harald at gigawatt dot nl]

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

--- Comment #7 from Harald van Dijk  ---
(In reply to Jason Merrill from comment #6)
> > but
> > anyway, even with -std=c++14 -pedantic-errors, no message at all is given
> > for the program in my earlier comment.
> 
> I don't see the syntax error in your earlier comment, S()=1 is a C++14
> constant expression.

The relevant production in the grammar, [expr.const]p1, is:

  constant-expression:
conditional-expression

This doesn't allow assignment-expressions unless parenthesised. It's also
echoed by [expr.const]p2:

  A conditional-expression e is a core constant expression unless [...]

and there is nothing that would allow other types of expressions to qualify as
core constant expressions.

[Bug c++/64666] gcc wrongly accepts assignment in constant expression

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #6 from Jason Merrill  ---
(In reply to Harald van Dijk from comment #5)
> (In reply to Jakub Jelinek from comment #4)
> > Just use -pedantic-errors if you want strict language conformance?
> 
> -std=* -pedantic is supposed to be enough to get GCC to conform to the
> specified standard (the standards pretty much never require an error)

Yes, and it does: it gives a diagnostic about a VLA (because the bound is not a
constant expression).  The standard doesn't require particular wording in the
diagnostic.

> but
> anyway, even with -std=c++14 -pedantic-errors, no message at all is given
> for the program in my earlier comment.

I don't see the syntax error in your earlier comment, S()=1 is a C++14 constant
expression.

[Bug target/77924] -mfloat128-type change broke AIX

[meissner at gcc dot gnu.org]

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

--- Comment #1 from Michael Meissner  ---
Created attachment 39784
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39784=edit
Proposed patch to fix the problem

This patch should only create the __ibm128 type when long double == IEEE and
long double size is 128 bits, so it should allow AIX to build (AIX long double
is 64-bits).

[Bug tree-optimization/77898] incorrect VR_ANTI_RANGE after evrp and before vrp1

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |---
Summary|VR_RANGE with inverted  |incorrect VR_ANTI_RANGE
   |bounds after evrp and   |after evrp and before vrp1
   |before vrp1 |

--- Comment #2 from Martin Sebor  ---
I may have made a mistake and miread the VR_ANTI_RANGE as VR_RANGE here.  Sorry
about that.  I've adjusted the Summary.

I may also be confused about other things but below is what I see in GDB when I
call get_range_info() from plus_stmt_object_size() on the offset in
POINTER_PLUS_EXPR (get_offset_range is a function I've added in my patch for
bug 77608).  As best I can tell the anti-range doesn't correspond to the range
of the variable i which is [0, 1].

Breakpoint 1, get_offset_range (op1=0x70daa990, offrange=0x7fffd360)
at /src/gcc/77608/gcc/tree-object-size.c:824
824   bool antirange = false;
(gdb) n
826   if (TREE_CODE (op1) == SSA_NAME)
(gdb) n
829   wide_int min, max;
(gdb) n
830   enum value_range_type range_type = get_range_info (op1, ,
);
(gdb) n
831   if (range_type == VR_RANGE || (antirange = range_type ==
VR_ANTI_RANGE))
(gdb) p debug_tree(op1)
 
unit size 
align 64 symtab 0 alias set -1 canonical type 0x70da41f8 precision
64 min  max >
static visited
def_stmt _2 = (sizetype) i_4;
version 2
ptr-info 0x70ec8f80>
$1 = void
(gdb) p range_type
$2 = VR_ANTI_RANGE
(gdb) p min
$3 = { = {val = {2147483648, 18061790, 140737235423104}, 
len = 1, precision = 64}, static is_sign_extended = }
(gdb) p max
$4 = { = {val = {-2147483649, 18061836, 140737235423104}, 
len = 1, precision = 64}, static is_sign_extended = }
(gdb) p debug_tree(gimple_assign_rhs1 (SSA_NAME_DEF_STMT (op1)))
 
unit size 
align 32 symtab 0 alias set -1 canonical type 0x70da47e0 precision
32 min  max 
pointer_to_this >
visited var 
def_stmt i_4 = PHI 
version 4>

[Bug c++/77890] class template type deduction fails for lambda functions

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/77912] [C++17 feature] class template deduction fails in template functions and generic lambdas

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug tree-optimization/77899] incorrect VR_RANGE for a signed char function argument

[msebor at gcc dot gnu.org]

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

--- Comment #10 from Martin Sebor  ---
Yes, I've also come to realize that the surprising signed char range is a red
herring since the abort in the following test case is also not optimized away.

void f (_Bool i)
{
  char d [3];

  const char *p = [1];

  p += i;

  if (p < d + 1 || d + 2 < p)
__builtin_abort ();
}

But I do stand by my point about the range representation of signed char in
POINTER_PLUS_EXPR.  It confused me enough to suspect that it may have been the
reason why the if statement wasn't optimized away (possibly also because in my
patch for bug 77608 wasn't prepared to handle such ranges, or handle them
correctly; the handling I added seemed like a workaround to me, hence this
bug).

[Bug target/77924] -mfloat128-type change broke AIX

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

   Priority|P3  |P2
 CC||dje at gcc dot gnu.org,
   ||segher at gcc dot gnu.org,
   ||wschmidt at gcc dot gnu.org

[Bug target/77924] -mfloat128-type change broke AIX

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-10-10
   Assignee|unassigned at gcc dot gnu.org  |meissner at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug target/77924] New: -mfloat128-type change broke AIX

[meissner at gcc dot gnu.org]

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

Bug ID: 77924
   Summary: -mfloat128-type change broke AIX
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org
  Target Milestone: ---

The change to split -mfloat128 into -mfloat128-type and -mfloat128 broke AIX,
due to the fact that AIX defaults to long doubles being 64-bit, and the
compiler created a type for __ibm128, even though it does not have 128-bit long
double support.

[Bug tree-optimization/77899] incorrect VR_RANGE for a signed char function argument

[glisse at gcc dot gnu.org]

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

--- Comment #9 from Marc Glisse  ---
I don't see what "signed" has to do with it.

void f (unsigned char i)
{
  char d [1260];

  const char *p = [130];

  p += i;

  if (p < d + 2 || d + 757 < p)
__builtin_abort ();
}

We don't optimize this either. We would need either to record a range of
[d+130, d+385] for p_3, or to match the pattern [CST1] + X cmp [CST2] and
check if the range of X lets us conclude (actually, maybe we could generally
turn this into X + CST1 cmp CST2, which would then be handled by existing
code).

[Bug tree-optimization/77899] incorrect VR_RANGE for a signed char function argument

[pinskia at gcc dot gnu.org]

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

--- Comment #8 from Andrew Pinski  ---
(In reply to Martin Sebor from comment #7)
> Here's what I see in GDB after get_range_info returns to update_value_range:
> 
> (gdb) p rtype
> $39 = VR_ANTI_RANGE
> (gdb) p min
> $40 = { = {val = {128, 18061790, 140737235530016}, len =
> 1, precision = 64}, static is_sign_extended = }
> (gdb) p max
> $41 = { = {val = {-129, 18061836, 140737235530016}, len =
> 1, precision = 64}, static is_sign_extended = }

wide_int_storage has no interpretation of the bits that is it can be either
unsigned or 2 comp signed.  You need to know the type (signed or unsigned) to
figure out that.

[Bug c++/77923] GCC emits "declares nothing" diagnostic on meaningful declarations.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-10
 Ever confirmed|0   |1

[Bug c++/55039] std::addressof vs. constexpr

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #9 from Jonathan Wakely  ---
r240873 added __builtin_addressof and r240929 made std::addressof use it.

[Bug c++/55004] [meta-bug] constexpr issues

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
Bug 55004 depends on bug 55039, which changed state.

Bug 55039 Summary: std::addressof vs. constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55039

   What|Removed |Added

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

[Bug tree-optimization/77899] incorrect VR_RANGE for a signed char function argument

[msebor at gcc dot gnu.org]

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

--- Comment #7 from Martin Sebor  ---
Here's what I see in GDB after get_range_info returns to update_value_range:

(gdb) p rtype
$39 = VR_ANTI_RANGE
(gdb) p min
$40 = { = {val = {128, 18061790, 140737235530016}, len = 1,
precision = 64}, static is_sign_extended = }
(gdb) p max
$41 = { = {val = {-129, 18061836, 140737235530016}, len = 1,
precision = 64}, static is_sign_extended = }

[Bug tree-optimization/77899] incorrect VR_RANGE for a signed char function argument

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Martin Sebor from comment #5)
> My other point (one somewhat related to bug 77898) is that it's confusing to
> represent the VR_RANGE [-128, 127] of the signed char variable as a
> VR_ANTI_RANGE ~[128, 18446744073709551487]

No we are not presenting signed char range as ~[128, 18446744073709551487] . 
This is a signed char converted into an unsigned type.  The range of that is
~[128, 18446744073709551487] .

[Bug tree-optimization/77899] incorrect VR_RANGE for a signed char function argument

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |---

--- Comment #5 from Martin Sebor  ---
> Consumers need to interpret POINTER_PLUS_EXPR offset (and MEM_REF offset)
> as signed entity.  This means you want to interpret the range as signed
> as well -- there is nothing wrong with the range as recorded as Andrew
> notices, it's fully correct.

My point is that the call to abort should be eliminated because it can never
take place.  I don't know enough about the VRP pass and its users to tell if
it's because the consumer of get_range_info doesn't interpret it as signed or
for some other reason.

My other point (one somewhat related to bug 77898) is that it's confusing to
represent the VR_RANGE [-128, 127] of the signed char variable as a
VR_ANTI_RANGE ~[128, 18446744073709551487], or the entire offset as unsigned
size_type.  I understand that it's not strictly incorrect but dealing with such
a range is more difficult, and more likely to lead bugs or missed optimization
opportunities such as the one in the test cases, than dealing with an ordinary
range.

[Bug target/77904] [ARM Cortex-M0] Frame pointer thrashes registers if assembly statements with "sp" clobber are used

[thopre01 at gcc dot gnu.org]

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

Thomas Preud'homme  changed:

   What|Removed |Added

   Last reconfirmed||2016-10-10
 CC||thopre01 at gcc dot gnu.org
  Known to fail||7.0

--- Comment #1 from Thomas Preud'homme  ---
I can reproduce the behavior mentioned on trunk.

[Bug fortran/77900] Compile time errors/warning for IO statements appear wrong

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jvdelisle at gcc dot 
gnu.org

--- Comment #3 from Jerry DeLisle  ---
I should mention. The reason I spotted this is:

  open (-3, err=200, iomsg=ch)   <=== should also be a compile error.

-3 is a reserved unit number, currently representing GFC_INVALID_UNIT.

-1 and -2 are used for internal units. I have a need for one more special unit
related to DTIO, so the new code I am working on failed the subject test case.

No word from FX, so I am going to fix this.

[Bug bootstrap/77917] undefined reference to '__aeabi_unwind_cpp_pr0' during ARM bootstrap

[tulipawn at gmail dot com]

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

--- Comment #2 from PeteVine  ---
I'll try that, thanks!

[Bug fortran/77915] [6 Regression] Internal error for matmul() in forall with optimization

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #3 from Jerry DeLisle  ---
Thomas, I think you may have broken the gfortran bug report to bug fixed speed
record.

[Bug tree-optimization/77921] [7 Regression] tree-ssanames.c miscompiled during PGO bootstrap

[trippels at gcc dot gnu.org]

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

--- Comment #3 from Markus Trippelsdorf  ---
markus@x4 crafty % gcc -Wall -Wno-array-bounds -pipe -O3 -pthread -DSYZYGY
-DTEST -DCPUS=4 -DUNIX -c crafty.c

  61.88%  cc1 [.] release_defs
   2.01%  libc-2.24.90.so [.] strcmp
   1.83%  libc-2.24.90.so [.] _int_malloc

   │Disassembly of section .text:
   │
   │00897897 :
   │_Z12release_defsP6gimple.cold.41():
   │  movstderr,%rdi
   │  mov%r15,%rsi
   │→ callq  verify_imm_links(_IO_FILE*, tree_node*)
   │↓ jmpq   120
   │  mov0x8(%rsp),%edx
   │  shl$0x3,%rdx
   │1c:   mov0x8(%rsp),%r15d
   │  mov0x4(%rsp),%esi
   │  cmp%esi,%r15d
   │↓ je 248
   │  inc%r15d
   │  lea(%rbx,%rdx,1),%rdi
   │  add$0x8,%rdx
   │  mov%r15d,0x8(%rsp)
   │  mov(%rdi,%r8,1),%r15
   │  test   %r15,%r15
   │↓ jne3c3
   │↑ jmp1c
   │  movzbl 0x49(%rdi),%edx
   │  mov0x30(%rdi),%r15
   │  test   %r15,%r15
   │  mov%edx,0x4(%rsp)
   │↑ je 3f
   │  movl   $0x0,0x8(%rsp)
   │  movl   $0x2,0xc(%rsp)
   │↓ jmpq   419
100.00 │77:└─→jmp77
   │  mov0x30(%rdi),%r15
   │  test   %r15,%r15
   │↓ je 248
   │  movl   $0x0,0x4(%rsp)
   │  movl   $0x0,0x8(%rsp)
   │  movl   $0x0,0xc(%rsp)
   │↓ jmpq   419
   │  mov0x8(%rsp),%edx
   │↑ jmpq   41
   │  mov%ebp,0x8(%rsp)
   │↓ jmpq   1cb
   │  mov0x20(%r15),%r15
   │  movzwl (%r15),%r11d
   │↓ jmpq   220
   │  mov%ebp,%r10d
   │  shl$0x3,%r10
   │c9:   cmp0x4(%rsp),%ebp
   │↓ je e8
   │  lea(%rbx,%r10,1),%r15
   │  inc%ebp
   │  add$0x8,%r10
   │  mov(%r15,%r12,1),%r15
   │  test   %r15,%r15
   │↓ jne211
   │↑ jmpc9
   │e8: ↓ jmpq   248

[Bug c++/77923] New: GCC emits "declares nothing" diagnostic on meaningful declarations.

[eric at efcs dot ca]

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

Bug ID: 77923
   Summary: GCC emits "declares nothing" diagnostic on meaningful
declarations.
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

I ran into this error defining a typedef for "struct ::stat" where "stat" names
both a function and type on POSIX systems.

Reduced reproducer:
// g++ -std=c++14 -Werror test.cpp
struct foo {};
void foo() {}
using FooType = struct ::foo; // emits error {{declaration 'struct ::foo' does
not declare anything}}

[Bug gcov-profile/77921] [7 Regression] tree-ssanames.c miscompiled during PGO bootstrap

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

   Keywords||wrong-code
 CC||kugan at gcc dot gnu.org

--- Comment #2 from Markus Trippelsdorf  ---
Hmm, it apparently started with r240291:

commit 6e93da1b453a9f4d865982caf9888470a2d3a63c
Author: kugan 
Date:   Tue Sep 20 23:23:55 2016 +

Add Early VRP

Current trunk when PGO bootstrapped hits this endless loop
when compiling crafty (http://www.craftychess.com/downloads/source/).

[Bug target/77267] MPX does not work in a presence of "-Wl,-as-needed" option (Ubuntu default)

[aivchenk at gmail dot com]

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

--- Comment #10 from Alexander Ivchenko  ---
Matthias, could you apply the fix for that bug
(https://gcc.gnu.org/viewcvs?rev=240057=gcc=rev) to the Ubuntu
version of gcc?

[Bug fortran/77915] [6/7 Regression] Internal error for matmul() in forall with optimization

[tkoenig at gcc dot gnu.org]

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

--- Comment #2 from Thomas Koenig  ---
Author: tkoenig
Date: Mon Oct 10 14:54:26 2016
New Revision: 240928

URL: https://gcc.gnu.org/viewcvs?rev=240928=gcc=rev
Log:
2016-10-10  Thomas Koenig  

PR fortran/77915
* frontend-passes.c (inline_matmul_assign):  Return early if
inside a FORALL statement.

2016-10-10  Thomas Koenig  

PR fortran/77915
* gfortran.dg/matmul_11.f90:  New test.


Added:
trunk/gcc/testsuite/gfortran.dg/matmul_11.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/frontend-passes.c
trunk/gcc/testsuite/ChangeLog

[Bug target/77267] MPX does not work in a presence of "-Wl,-as-needed" option (Ubuntu default)

[aivchenk at gmail dot com]

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

--- Comment #9 from Alexander Ivchenko  ---
Looks like exactly the same discussion happened when '-z bndplt' option was
discussed. Here is the reference: https://patchwork.ozlabs.org/patch/456557/ .
It's a long one, but seems that the consensus was formulated by Jeff Law:

"I guess the one thing I don't like here is that whether or not to pass 
-z bndplt is made at the time we configure GCC.  Yet, it's trivial for 
someone to change the system linker later, either to gold or from an old 
BFD linker that doesn't support -z bndplt to one that does support -z 
bndplt.

[ Note we have the same issue with certain assembler feature tests. ]

I'm not aware of any real infrastructure in GCC to query the behavior of 
the linker at link time and then customize the options passed.  So if 
it's going to be configurable, then that's the only time to do the test."
...
"So, in an ideal world, we'd query the linker at link time and pass the 
flag anytime we have a linker that supports the capability and perhaps 
warn if the linker doesn't support that capability.

Given we're not in that ideal world, I think Ilya's patch is reasonable 
and should be installed."

[Bug c++/77922] Bogus suggestion: ‘constexpr’ does not name a type; did you mean ‘constexpr’?

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Jakub Jelinek from comment #0)
> pr.C:1:1: note: C++11 ‘constexpr’ only available with -std=c++11 or
> -std=gnu++11

Also this note isn't true, because it's also available with -std=gnu++14, or
with no option, etc.

[Bug c++/77922] Bogus suggestion: ‘constexpr’ does not name a type; did you mean ‘constexpr’?

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
A similar thing happens with other C++11 keywords:

bad.cc:1:1: warning: identifier ‘decltype’ is a keyword in C++11
[-Wc++11-compat]
 decltype i = 0;
 ^~~~
bad.cc:1:1: error: ‘decltype’ does not name a type; did you mean ‘decltype’?
 decltype i = 0;
 ^~~~
 decltype

It's even worse in this case, because the code isn't valid even in C++11, so
the fix-it can never be a useful change.

(In reply to Jakub Jelinek from comment #0)
> I'd say we should just not print the bogus "did you mean" if the identifier
> fuzzy matching found is the same as the one used originally.  Or not add
> constexpr into the suggestions in this case because it is not C++98?

Not adding non-C++98 keywords into the suggestions make sense, and would solve
both of these examples. (Another option for the constexpr case would be to
suggest dropping the -std=c++98/-std=gnu++98/-std=c++03/-std=gnu++03/-ansi
option).

If there are still other ways that the match could end up being the same as the
original then suppressing the "did you mean" would still make sense.

[Bug c++/77922] New: Bogus suggestion: ‘constexpr’ does not name a type; did you mean ‘constexpr’?

[jakub at gcc dot gnu.org]

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

Bug ID: 77922
   Summary: Bogus suggestion: ‘constexpr’ does not name a type;
did you mean ‘constexpr’?
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

constexpr int a = 1;
with -std=c++98 gives
pr.C:1:1: error: ‘constexpr’ does not name a type; did you mean ‘constexpr’?
 constexpr int a = 1;
 ^
 constexpr
pr.C:1:1: note: C++11 ‘constexpr’ only available with -std=c++11 or
-std=gnu++11

I'd say we should just not print the bogus "did you mean" if the identifier
fuzzy matching found is the same as the one used originally.  Or not add
constexpr into the suggestions in this case because it is not C++98?

[Bug gcov-profile/77921] [7 Regression] tree-ssanames.c miscompiled during PGO bootstrap

[trippels at gcc dot gnu.org]

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

--- Comment #1 from Markus Trippelsdorf  ---
gcc version 7.0.0 20161007 was fine

[Bug tree-optimization/77916] [6/7 Regression] ICE in verify_gimple_in_cfg: invalid (pointer) operands to plus/minus

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |wschmidt at gcc dot 
gnu.org

--- Comment #3 from Bill Schmidt  ---
Mine.  Sounds familiar, too -- thought all such instances had been cleaned up.

[Bug c++/32658] Supposedly illegal conversion compiles without errors

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #12 from Nathan Sidwell  ---
This appears resolved.

32658.ii: In function 'void bar()':
32658.ii:12:6: error: invalid initialization of non-const reference of type
'xyz&' from an rvalue of type 'xyz'
  foo(xyz());
  ^
32658.ii:9:6: note:   initializing argument 1 of 'void foo(xyz&)'
 void foo(xyz &);
  ^~~
which looks right to me.  Now we have rvalue refs, one can DTRT (doesn't help
Aristid thoug).

[Bug gcov-profile/77921] New: [7 Regression] tree-ssanames.c miscompiled during PGO bootstrap

[trippels at gcc dot gnu.org]

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

Bug ID: 77921
   Summary: [7 Regression] tree-ssanames.c miscompiled during PGO
bootstrap
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Target Milestone: ---

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

% g++ -S -Wno-coverage-mismatch -c -O2 -fprofile-use tree-ssanames.ii

.section.text.unlikely  
.cfi_startproc  
.type   _Z12release_defsP6gimple.cold.41, @function 
_Z12release_defsP6gimple.cold.41:   
.L138:  
.cfi_def_cfa_offset 80  
.cfi_offset 3, -56  
.cfi_offset 6, -48  
.cfi_offset 12, -40 
.cfi_offset 13, -32 
.cfi_offset 14, -24 
.cfi_offset 15, -16 
movl%r14d, %r12d
.L123:  
movq32(%rbx), %rbx  
movzwl  (%rbx), %ecx
jmp .L128   
.L105:  
movqstderr(%rip), %rdi  
movq%rbx, %rsi  
call_Z16verify_imm_linksP8_IO_FILEP9tree_node   
jmp .L106   
.L85:   
movq48(%rdi), %rbx  
testq   %rbx, %rbx  
je  .L80
movl$0, 4(%rsp) 
movl$0, 8(%rsp) 
movl$0, 12(%rsp)
jmp .L98
.L82:   
movzbl  73(%rdi), %edx  
movq48(%rdi), %rbx  
testq   %rbx, %rbx  
movl%edx, 4(%rsp)   
je  .L87
movl$0, 8(%rsp) 
movl$2, 12(%rsp)
jmp .L98
.L133:  
movl8(%rsp), %edx   
jmp .L89
.L137:  
movl%r14d, 8(%rsp)  
jmp .L121   
.L180:  
.L115:  
jmp .L115  

Also happens on ppc64le (although in a different function):

108b5450 <_Z19release_ssa_name_fnP8functionP9tree_node>:
...
108b5690:   00 00 00 48 b   108b5690
<_Z19release_ssa_name_fnP8functionP9tree_node+0x240>

[Bug middle-end/77920] [7 Regression] 186.crafty doesn't compile

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-10
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

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

[Bug rtl-optimization/77919] ICE converting DC to V2DF mode

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Created attachment 39782
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39782=edit
another test-case


Following simplified test-case ICEs on 5.1.0+:

$ g++ pr77919-2.cpp  -c -O1 -std=c++11 -fpermissive:

0xa1274b copy_to_mode_reg(machine_mode, rtx_def*)
/home/marxin/BIG/Programming/gcc/gcc/explow.c:601
0x915d63 precompute_register_parameters
/home/marxin/BIG/Programming/gcc/gcc/calls.c:921
0x915d63 expand_call(tree_node*, rtx_def*, int)
/home/marxin/BIG/Programming/gcc/gcc/calls.c:3120
0xa28c4c expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/home/marxin/BIG/Programming/gcc/gcc/expr.c:10594
0x92918a expand_expr
/home/marxin/BIG/Programming/gcc/gcc/expr.h:256
0x92918a expand_call_stmt
/home/marxin/BIG/Programming/gcc/gcc/cfgexpand.c:2660
0x92918a expand_gimple_stmt_1
/home/marxin/BIG/Programming/gcc/gcc/cfgexpand.c:3548
0x92918a expand_gimple_stmt
/home/marxin/BIG/Programming/gcc/gcc/cfgexpand.c:3714
0x92a87e expand_gimple_basic_block
/home/marxin/BIG/Programming/gcc/gcc/cfgexpand.c:5720
0x9309b6 execute
/home/marxin/BIG/Programming/gcc/gcc/cfgexpand.c:6335

[Bug target/77918] S390: Floating point comparisons don't raise invalid for unordered operands.

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Attachment #39781|0   |1
is obsolete||

--- Comment #2 from Martin Liška  ---
Comment on attachment 39781
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39781
another test-case

Sorry, wrong PR.

[Bug target/77918] S390: Floating point comparisons don't raise invalid for unordered operands.

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Created attachment 39781
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39781=edit
another test-case

Following simplified test-case ICEs on 5.1.0+:

$ g++ pr77919-2.cpp  -c -O1 -std=c++11 -fpermissive:

0xa1274b copy_to_mode_reg(machine_mode, rtx_def*)
/home/marxin/BIG/Programming/gcc/gcc/explow.c:601
0x915d63 precompute_register_parameters
/home/marxin/BIG/Programming/gcc/gcc/calls.c:921
0x915d63 expand_call(tree_node*, rtx_def*, int)
/home/marxin/BIG/Programming/gcc/gcc/calls.c:3120
0xa28c4c expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/home/marxin/BIG/Programming/gcc/gcc/expr.c:10594
0x92918a expand_expr
/home/marxin/BIG/Programming/gcc/gcc/expr.h:256
0x92918a expand_call_stmt
/home/marxin/BIG/Programming/gcc/gcc/cfgexpand.c:2660
0x92918a expand_gimple_stmt_1
/home/marxin/BIG/Programming/gcc/gcc/cfgexpand.c:3548
0x92918a expand_gimple_stmt
/home/marxin/BIG/Programming/gcc/gcc/cfgexpand.c:3714
0x92a87e expand_gimple_basic_block
/home/marxin/BIG/Programming/gcc/gcc/cfgexpand.c:5720
0x9309b6 execute
/home/marxin/BIG/Programming/gcc/gcc/cfgexpand.c:6335

[Bug rtl-optimization/77919] ICE converting DC to V2DF mode

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-10
 CC||marxin at gcc dot gnu.org
  Known to work||4.7.4
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, started to ICE from 4.8.0+.

[Bug target/77738] Invalid initialisation of ar.lc register

[sch...@linux-m68k.org]

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

Andreas Schwab  changed:

   What|Removed |Added

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

--- Comment #4 from Andreas Schwab  ---
Fixed.

[Bug target/77738] Invalid initialisation of ar.lc register

[schwab at gcc dot gnu.org]

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

--- Comment #3 from Andreas Schwab  ---
Author: schwab
Date: Mon Oct 10 12:16:00 2016
New Revision: 240918

URL: https://gcc.gnu.org/viewcvs?rev=240918=gcc=rev
Log:
PR target/77738
* config/ia64/ia64.md ("doloop_end"): Reject if mode of loop
pseudo is not DImode.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/ia64/ia64.md

[Bug middle-end/77920] [7 Regression] 186.crafty doesn't compile

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org
   Target Milestone|--- |7.0

--- Comment #1 from Richard Biener  ---
Might be my last VRP change (caller of vrp_fold_stmt should update stmt).

[Bug bootstrap/77917] undefined reference to '__aeabi_unwind_cpp_pr0' during ARM bootstrap

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Richard Biener  ---
Yes, please use documented ways (--with-build-config=bootstrap-lto) to build
with LTO.  Generally configure tests easily get confused by things like -flto.

[Bug middle-end/77920] New: [7 Regression] 186.crafty doesn't compile

[trippels at gcc dot gnu.org]

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

Bug ID: 77920
   Summary: [7 Regression] 186.crafty doesn't compile
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Target Milestone: ---

markus@x4 crafty % cat crafty.i
int a, b;
void fn1() {
  int c;
  for (; b < 0;) {
{
  int d = 56, e = (b >> 3) - (d >> 3) > 0 ? (b >> 3) - (d >> 3)
  : -((b >> 3) - (d >> 3));
  c = 1 >= e;
}
if (c)
  a = 0;
  }
}

markus@x4 crafty % /var/tmp/gcc_test/usr/local/bin/gcc -O2 -c crafty.i
crafty.i: In function ‘fn1’:
crafty.i:2:6: error: use operand missing for stmt
 void fn1() {
  ^~~
_2
e_7 = 7 - _2;
crafty.i:2:6: internal compiler error: verify_ssa failed
0xd7f431 verify_ssa(bool, bool)
../../gcc/gcc/tree-ssa.c:1158
0xa97189 execute_function_todo
../../gcc/gcc/passes.c:1971
0xa980fc execute_todo
../../gcc/gcc/passes.c:2014

[Bug rtl-optimization/77919] New: ICE converting DC to V2DF mode

[krebbel at gcc dot gnu.org]

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

Bug ID: 77919
   Summary: ICE converting DC to V2DF mode
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: krebbel at gcc dot gnu.org
  Target Milestone: ---

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

The attached testcase ICEs with a segmentation fault compiled on x86-64 r240231
with -O1:


t.cc:94:21: internal compiler error: Segmentation fault
   return vfrom->v2d;
 ^~~
0xd7c1cf crash_signal
/home/andreas/clean/../gcc/gcc/toplev.c:336
0xa4ea44 emit_move_insn(rtx_def*, rtx_def*)
/home/andreas/clean/../gcc/gcc/expr.c:3692
0xa5785c store_expr_with_bounds(tree_node*, rtx_def*, int, bool, bool,
tree_node*)
/home/andreas/clean/../gcc/gcc/expr.c:5624
0xa582b5 expand_assignment(tree_node*, tree_node*, bool)
/home/andreas/clean/../gcc/gcc/expr.c:5316
0x94107c expand_gimple_stmt_1
/home/andreas/clean/../gcc/gcc/cfgexpand.c:3649
0x94107c expand_gimple_stmt
/home/andreas/clean/../gcc/gcc/cfgexpand.c:3745
0x942ec1 expand_gimple_basic_block
/home/andreas/clean/../gcc/gcc/cfgexpand.c:5752
0x9485e6 execute
/home/andreas/clean/../gcc/gcc/cfgexpand.c:6363
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Program received signal SIGSEGV, Segmentation fault.
0x00af72b4 in emit_move_insn (x=0x7fffefe36ee8, y=0x0) at
/home/andreas/clean/../gcc/gcc/expr.c:3692
3692  gcc_assert (mode != BLKmode
Missing separate debuginfos, use: debuginfo-install
glibc-2.17-106.el7_2.8.x86_64 gmp-6.0.0-12.el7_1.x86_64
libgcc-4.8.5-4.el7.x86_64 libmpc-1.0.1-3.el7.x86_64
libstdc++-4.8.5-4.el7.x86_64 mpfr-3.1.1-4.el7.x86_64 zlib-1.2.7-15.el7.x86_64
(gdb) bt
#0  0x00af72b4 in emit_move_insn (x=0x7fffefe36ee8, y=0x0) at
/home/andreas/clean/../gcc/gcc/expr.c:3692
#1  0x00aee203 in convert_move (to=0x7fffefe36ee8, from=0x0,
unsignedp=0) at /home/andreas/clean/../gcc/gcc/expr.c:264
#2  0x00afd961 in store_expr_with_bounds (exp=0x7fffefe24bd0,
target=0x7fffefe36ee8, call_param_p=0, nontemporal=false, reverse=false,
btarget=0x7fffefe23f30)
at /home/andreas/clean/../gcc/gcc/expr.c:5624
#3  0x00afbde0 in expand_assignment (to=0x7fffefe23f30,
from=0x7fffefe24bd0, nontemporal=false) at
/home/andreas/clean/../gcc/gcc/expr.c:5316
#4  0x009be95a in expand_gimple_stmt_1 (stmt=0x7fffefe22fa0) at
/home/andreas/clean/../gcc/gcc/cfgexpand.c:3649
#5  0x009bed45 in expand_gimple_stmt (stmt=0x7fffefe22fa0) at
/home/andreas/clean/../gcc/gcc/cfgexpand.c:3745
#6  0x009c5e4e in expand_gimple_basic_block (bb=0x7fffefe1e208,
disable_tail_calls=false) at /home/andreas/clean/../gcc/gcc/cfgexpand.c:5752
#7  0x009c7922 in (anonymous namespace)::pass_expand::execute
(this=0x236e4e0, fun=0x701cc498) at
/home/andreas/clean/../gcc/gcc/cfgexpand.c:6363
#8  0x00dab0ef in execute_one_pass (pass=pass@entry=0x236e4e0) at
/home/andreas/clean/../gcc/gcc/passes.c:2342
#9  0x00dab768 in execute_pass_list_1 (pass=0x236e4e0) at
/home/andreas/clean/../gcc/gcc/passes.c:2431
#10 0x00dab7c5 in execute_pass_list (fn=0x701cc498, pass=) at /home/andreas/clean/../gcc/gcc/passes.c:2442
#11 0x00a038ed in cgraph_node::expand (this=0x701cb8a0) at
/home/andreas/clean/../gcc/gcc/cgraphunit.c:1985
#12 0x00a05211 in expand_all_functions () at
/home/andreas/clean/../gcc/gcc/cgraphunit.c:2121
#13 symbol_table::compile (this=this@entry=0x7fffeffd20a8) at
/home/andreas/clean/../gcc/gcc/cgraphunit.c:2478
#14 0x00a072ea in symbol_table::finalize_compilation_unit
(this=0x7fffeffd20a8) at /home/andreas/clean/../gcc/gcc/cgraphunit.c:2568
#15 0x00e890b8 in compile_file () at
/home/andreas/clean/../gcc/gcc/toplev.c:491
#16 0x00e8b66b in do_compile () at
/home/andreas/clean/../gcc/gcc/toplev.c:2010
#17 0x00e8b93b in toplev::main (this=0x7fffe270, argc=3,
argv=0x7fffe378) at /home/andreas/clean/../gcc/gcc/toplev.c:2144
#18 0x006708f7 in main (argc=3, argv=0x7fffe378) at
/home/andreas/clean/../gcc/gcc/main.c:39
(gdb) frame 2
#2  0x00afd961 in store_expr_with_bounds (exp=0x7fffefe24bd0,
target=0x7fffefe36ee8, call_param_p=0, nontemporal=false, reverse=false,
btarget=0x7fffefe23f30)
at /home/andreas/clean/../gcc/gcc/expr.c:5624
5624convert_move (target, temp, TYPE_UNSIGNED (TREE_TYPE
(exp)));
(gdb) p temp
$1 = (rtx) 0x7fffefe41558
(gdb) p debug_rtx(temp)
(concat:DC (reg:DF 110 [ D.3170 ])
(reg:DF 111 [ D.3170+8 ]))
$2 = void
(gdb) p debug_rtx(target)
(reg:V2DF 107 [ 

[Bug target/77918] New: S390: Floating point comparisons don't raise invalid for unordered opperands.

[stli at linux dot vnet.ibm.com]

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

Bug ID: 77918
   Summary: S390: Floating point comparisons don't raise invalid
for unordered opperands.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stli at linux dot vnet.ibm.com
  Target Milestone: ---

The C comparison operators <, >, <=, >= (as opposed to the isgreater, etc.
macros) are specified to raise the invalid exception on comparisons involving a
NaN (quiet or signaling). However, gcc on s390 is generating e.g. the cebr
(Short BFP COMPARE) instruction rather than kebr (Short BFP COMPARE AND
SIGNAL). The first one does not raise the invalid exception unless it
encounters a signaling NaN. The latter one raise the invalid exception if one
operand is quiet or signaling NaN. I haven't checked if invalid is raised if
gcc is using vector instructions.

[Bug bootstrap/77917] New: undefined reference to '__aeabi_unwind_cpp_pr0' during ARM bootstrap

[tulipawn at gmail dot com]

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

Bug ID: 77917
   Summary: undefined reference to '__aeabi_unwind_cpp_pr0' during
ARM bootstrap
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tulipawn at gmail dot com
  Target Milestone: ---

In case that's the culprit, I had the CFLAGS I customarily use, including
-flto, present in the environment before starting the bootstrap (gcc4 ABI,
using 4.9): 

checking size of long long... configure: error: in
`/home/guest/gcc-svn-master/build/gcc':
configure: error: cannot compute sizeof (long long)
See `config.log' for more details.
make[2]: *** [configure-stage2-gcc] Error 77

configure:6075: checking size of long long
configure:6080:  /home/guest/gcc-svn-master/build/./prev-gcc/xg++
-B/home/guest/gcc-svn-master/build/./prev-gcc/ -B/usr/gcc7/arm-linux-gnue
abihf/bin/ -nostdinc++
-B/home/guest/gcc-svn-master/build/prev-arm-linux-gnueabihf/libstdc++-v3/src/.libs
-B/home/guest/gcc-svn-master/buil
d/prev-arm-linux-gnueabihf/libstdc++-v3/libsupc++/.libs 
-I/home/guest/gcc-svn-master/build/prev-arm-linux-gnueabihf/libstdc++-v3/include/a
rm-linux-gnueabihf 
-I/home/guest/gcc-svn-master/build/prev-arm-linux-gnueabihf/libstdc++-v3/include
 -I/home/guest/gcc-svn-master/libstdc+
+-v3/libsupc++
-L/home/guest/gcc-svn-master/build/prev-arm-linux-gnueabihf/libstdc++-v3/src/.libs
-L/home/guest/gcc-svn-master/build/prev-a
rm-linux-gnueabihf/libstdc++-v3/libsupc++/.libs -o conftest -g -O2 -gtoggle 
-static-libstdc++ -static-libgcc  conftest.cpp  >&5

/tmp/ccFBuI5b.o(.ARM.exidx.text.startup+0x0): error: undefined reference to
'__aeabi_unwind_cpp_pr0'
collect2: error: ld returned 1 exit status

Should LTO be avoided early on?

[Bug tree-optimization/77916] [6/7 Regression] ICE in verify_gimple_in_cfg: invalid (pointer) operands to plus/minus

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||wschmidt at gcc dot gnu.org

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

[Bug go/77910] [7 Regression] go: open zversion.go: no such file or directory

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-10
 Ever confirmed|0   |1

--- Comment #5 from Markus Trippelsdorf  ---
Started with r240083:

commit 91d733e1ca11bfb60afa7191b1fba12cc4966f76
Author: ian 
Date:   Sun Sep 11 13:23:27 2016 +

runtime/internal/sys: new package, API copied from Go 1.7

Copy over the Go 1.7 runtime/internal/sys package, but instead of
having
separate files for each GOARCH and GOOS value, set the values in
configure.ac and write them out in Makefile.am.  Setting the values in
configure.ac should make it easier to add new processors.

Remove the automake GOARCH conditionals, which are no longer used.
Leave the GOOS conditionals for now, as they are used for the C runtime
package.

I've reproduced the issue on a second machine to rule out a pilot error.

BTW bisecting go is slow, because one has to build from scratch on every
iteration (one gets build errors otherwise). For the rest of gcc rebuilding
in an existing build directory works >99% of the time...

[Bug tree-optimization/77916] [6/7 Regression] ICE in verify_gimple_in_cfg: invalid (pointer) operands to plus/minus

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Target||aarch64*-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-10
 CC||ramana at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Ramana Radhakrishnan  ---
Confirmed.

[Bug rtl-optimization/60641] Converting ushort to offset on x86_64 generates double movzwl

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

  Component|target  |rtl-optimization

--- Comment #3 from Uroš Bizjak  ---
(In reply to Alex Kruppa from comment #2)
> Dump of assembler code for function bar:
>0x0020 <+0>:   movzwl %si,%eax
>0x0023 <+3>:   movzwl %si,%esi
>0x0026 <+6>:   mov%esi,(%rdi,%rax,4)
>0x0029 <+9>:   retq

bar:
movzwl  %si, %eax   # 8 zero_extendhidi2/1
movzwl  %si, %esi   # 9 *zero_extendhisi2/1
movl%esi, (%rdi,%rax,4) # 10*movsi_internal/2
ret # 16simple_return_internal

These two movzwl insns are actually different instructions. The first extends
from HImode to DImode, the other from HImode to SImode.

Perhaps copy propagator or REE pass can be enhanced to propagate zero-extended
value from a wider mode to a narrow mode access.

[Bug tree-optimization/77916] [6/7 Regression] ICE in verify_gimple_in_cfg: invalid (pointer) operands to plus/minus

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |6.3
  Known to fail||6.2.1, 7.0

[Bug fortran/77915] [6/7 Regression] Internal error for matmul() in forall with optimization

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-10-10
 CC||tkoenig at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |tkoenig at gcc dot 
gnu.org
   Target Milestone|--- |6.3
Summary|Internal error for matmul() |[6/7 Regression] Internal
   |in forall with optimization |error for matmul() in
   ||forall with optimization
 Ever confirmed|0   |1

--- Comment #1 from Thomas Koenig  ---
Confirmed; having the BLOCK inside FORALL does not work.

[Bug tree-optimization/77916] New: [6/7 Regression] ICE in verify_gimple_in_cfg: invalid (pointer) operands to plus/minus

[ktkachov at gcc dot gnu.org]

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

Bug ID: 77916
   Summary: [6/7 Regression] ICE in verify_gimple_in_cfg: invalid
(pointer) operands to plus/minus
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
  Target Milestone: ---

The following testcase ICEs for me on aarch64 with -O3
on GCC 6 and trunk (GCC 7)

typedef struct
{
  void *f1;
} S;

S *a;
int b;

void
fn1 (void)
{
  for (; b; b++, a++)
a->f1 = b;
}


foo.c: In function 'fn1':
foo.c:13:11: warning: assignment makes pointer from integer without a cast
[-Wint-conversion]
 a->f1 = b;
   ^
foo.c:10:1: error: invalid (pointer) operands to plus/minus
 fn1 (void)
 ^~~
slsr_65 = _108 + 1B;
foo.c:10:1: error: invalid (pointer) operands to plus/minus
slsr_94 = _118 + 1B;
foo.c:10:1: error: invalid (pointer) operands to plus/minus
slsr_158 = _128 + 1B;
foo.c:10:1: error: invalid (pointer) operands to plus/minus
slsr_160 = _138 + 1B;
foo.c:10:1: error: invalid (pointer) operands to plus/minus
slsr_162 = _148 + 1B;
foo.c:10:1: error: invalid (pointer) operands to plus/minus
slsr_166 = _9 + 1B;
foo.c:10:1: error: invalid (pointer) operands to plus/minus
slsr_164 = _96 + 1B;
foo.c:10:1: internal compiler error: verify_gimple failed
0xb89e64 verify_gimple_in_cfg(function*, bool)
$SRC/gcc/tree-cfg.c:5208
0xa6a457 execute_function_todo
$SRC/gcc/passes.c:1964
0xa6a777 do_per_function
$SRC/gcc/passes.c:1648
0xa6a895 execute_todo
$SRC/gcc/passes.c:2014

[Bug fortran/77915] New: Internal error for matmul() in forall with optimization

[hroch at physics dot muni.cz]

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

Bug ID: 77915
   Summary: Internal error for matmul() in forall with
optimization
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hroch at physics dot muni.cz
  Target Milestone: ---

Dear colleagues,

I encountered an internal problem in gfortran
compiler for matmul() in forall loop, while
optimization is switched on.

There is a minimal code:
---
program x
  integer, parameter :: d = 3
  real,dimension(d,d,d) :: cube,xcube
  real, dimension(d,d) :: cmatrix
  integer :: i,j
  forall(i=1:d,j=1:d)
 xcube(i,j,:) = matmul(cmatrix,cube(i,j,:))
  end forall
end program x
---

which works correctly for

 $ gfortran f.f95

while with optimization flag

 $ gfortran -O f.f95

fails on:

---
f.f95:6:0:

   forall(i=1:d,j=1:d)

internal compiler error: in gfc_trans_forall_1, at fortran/trans-stmt.c:4388
0x6edc26 gfc_trans_forall_1
../../src/gcc/fortran/trans-stmt.c:4388
0x68dfd7 trans_code
../../src/gcc/fortran/trans.c:1832
0x6b167c gfc_generate_function_code(gfc_namespace*)
../../src/gcc/fortran/trans-decl.c:6167
0x649b90 translate_all_program_units
../../src/gcc/fortran/parse.c:5915
0x649b90 gfc_parse_file()
../../src/gcc/fortran/parse.c:6121
0x68b322 gfc_be_parse_file
../../src/gcc/fortran/f95-lang.c:201
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
---

The compiler version is

 $ gfortran --version
GNU Fortran (Debian 6.2.0-5) 6.2.0 20160927
Copyright (C) 2016 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 PURPOS

which is from latest GNU/Debian (unstable) compiler collection.
Older compilers (GNU Fortran (Debian 4.9.2-10) 4.9.2) works
correctly. Use of both '-O -finline-matmul-limit=0' is also
successful.


Thank you for developing of gfortran!

[Bug target/77897] Compile error with KNL & -O3 for GTC code

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-10-10
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
You need recent enough assembler to support the extra registers available with
KNL.  What is your binutils version?

[Bug tree-optimization/77901] ICE in tree-sse-reassoc,c:2881

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c++/77896] Object vtable lookups are not hoisted out of loops

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #7 from Richard Biener  ---
Thus really invalid.

[Bug tree-optimization/77898] VR_RANGE with inverted bounds after evrp and before vrp1

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Richard Biener  ---
You seem to be misinterpreting 18446744071562067967 as -2147483649, the
range-info
looks valid to me.  So it must be your get_range_info () code being wrong.

[Bug tree-optimization/77899] incorrect VR_RANGE for a signed char function argument

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from Richard Biener  ---
(In reply to Martin Sebor from comment #3)
> The offset is this in plus_stmt_object_size() in tree-object-size.c:
> 
>   type  size 
> unit size 
> align 64 symtab 0 alias set -1 canonical type 0x70da41f8
> precision 64 min  max  0x70db1480 18446744073709551615>>
> static visited
> def_stmt _1 = (sizetype) i_3(D);
> version 1
> ptr-info 0x70ec8f20>
> 
> I can work around it there by checking the type of i_3(D) (which is signed
> char) and using its range to bound _1.  I wonder if this same workaround
> could be put in get_range_info until POINTER_PLUS_EXPR is changed to take a
> signed offset as you suggest.

Consumers need to interpret POINTER_PLUS_EXPR offset (and MEM_REF offset)
as signed entity.  This means you want to interpret the range as signed
as well -- there is nothing wrong with the range as recorded as Andrew notices,
it's fully correct.

-> INVALID.

[Bug c++/77890] class template type deduction fails for lambda functions

[jeff.mirwaisi at gmail dot com]

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

--- Comment #3 from Jeff Mirwaisi  ---
Bug 77912 is not a duplicate of this bug (77890), please see 77912 for details,
unless 77890 is to be used as a general bug for all class template type
deduction issues - if not Vittorio Romeo's example of failure with respect to
local types should also be a standalone bug