[Bug demangler/82026] Undemanglable symbol

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-30
 CC||trippels at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
Confirmed. Stack overflow.

[Bug driver/81519] Enhancement: Add --help=target-distcc or similar to dump clean, optimal CFLAGS without using -march=native

[daniel.santos at pobox dot com]

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

--- Comment #7 from Daniel Santos  ---
(In reply to Martin Liška from comment #4)
> Ok, so I've briefly investigated source code and providing such information
> is definitely not a simple task :/
> 
> I would recommend to fix PR39851 and then one will just compare output of
> following 2 invocations:
> 
> gcc --help=target  -Q
> gcc --help=target -march=native -Q 
> 
> Will it work for you?
> 
> Note that fully understand which ISA extensions are enable when is also
> quite complex.

I've thought about this some more and I'm starting to think that all of this
can be determined with a script that iteratively calls gcc --help=target -Q
with various machine flags to determine which -mno-* flags are really needed
and which -m flags include others.  So in effect, I'm thinking that we can
produce optimal C(XX)FLAGS with a script and your PR39851 fix.  I'll have to
test this out.

Thanks

[Bug c++/81932] Template arguments of type unsigned generate incorrect debugging information

[ryxi at stu dot xidian.edu.cn]

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

--- Comment #24 from Xi Ruoyao  ---
(In reply to Paul Smith from comment #23)
> The lookup_type() was just to show the problem more clearly: I don't do that
> in my actual Python code.  This part (or something similar) is what I use:
> 
>   class tv(gdb.Function):
>   def __init__(self):
>   gdb.Function.__init__(self, "tv")
>   def invoke(self, vector):
>   gdb.write("depth: %d\n" % (vector['tree']['_depth']))
> 
> and when I run this I get:
> 
>   warning: RTTI symbol not found for class 'TreeVector::Tree'
> 
> In other words, it's not that I'm trying to look up that type myself: that's
> the type that GDB is trying to look up when it tries to evaluate the
> variable of type "TreeVector::Tree" in my program.

Yes.  GDB does following:

(1) Find the mangled name of the vtable of tv.
(2) Demangle the name, to be 'vtable for TreeVector::Tree'.
(3) Skip 'vtable for ' and get 'TreeVector::Tree'.
(4) Lookup this symbol.

[Bug c++/81932] Template arguments of type unsigned generate incorrect debugging information

[psmith at gnu dot org]

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

--- Comment #23 from Paul Smith  ---
The lookup_type() was just to show the problem more clearly: I don't do that in
my actual Python code.  This part (or something similar) is what I use:

  class tv(gdb.Function):
  def __init__(self):
  gdb.Function.__init__(self, "tv")
  def invoke(self, vector):
  gdb.write("depth: %d\n" % (vector['tree']['_depth']))

and when I run this I get:

  warning: RTTI symbol not found for class 'TreeVector::Tree'

In other words, it's not that I'm trying to look up that type myself: that's
the type that GDB is trying to look up when it tries to evaluate the variable
of type "TreeVector::Tree" in my program.

[Bug tree-optimization/82017] missing strlen optimization for chained mempcpy calls

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-30
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Eric Gallager  ---
Confirmed.

[Bug middle-end/79220] missing -Wstringop-overflow= on a memcpy overflow

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-30
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Eric Gallager  ---
Confirmed.

[Bug middle-end/77799] missing -Wformat-overflow warning on a trivial sprintf overflow with no directives

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #3 from Eric Gallager  ---
(In reply to Martin Sebor from comment #2)
> This bug was fixed along with the related pr77671 in r248035.

...so closing as FIXED then.

[Bug middle-end/81512] duplicate note in -Walloca-larger-than and alloca in a return statement

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-30
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Confirmed.

[Bug tree-optimization/81454] missing strcmp optimization and warning on duplicate call with an unknown string

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-30
 CC||egallager at gcc dot gnu.org
Summary|missing strcmp optimization |missing strcmp optimization
   |on duplicate call with an   |and warning on duplicate
   |unknown string  |call with an unknown string
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Confirmed.

[Bug c++/81932] Template arguments of type unsigned generate incorrect debugging information

[msebor at gcc dot gnu.org]

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

--- Comment #22 from Martin Sebor  ---
Paul, have you considered determining the type of the specialization of the
template from an object of one instead of hardcoding its name?

I.e., instead of calling gdb.lookup_type("TreeVector::Tree") in your
Python printer script, use something like gdb.lookup_type(str(vector.type) %
"::Tree")?  (I couldn't get this to work but I could have done something
wrong.)

[Bug tree-optimization/81452] warn on realloc(p, 0)

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-30
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Confirmed:

$ cat 81452.c && /usr/local/bin/gcc -c -Wall -Wextra -pedantic 81452.c
#include 

int main(void)
{
void *p = malloc(5);
p = realloc(p, 0);
return ((p == NULL) ? 0 : 1);
}
$

(no warnings)

[Bug tree-optimization/81437] missing -Wstringop-overflow reading past the end of a string

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-30
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Confirmed. Note that I only get the 1 warning when compiling for 64-bits; when
I compile for 32-bits I get no warnings at all.

[Bug tree-optimization/81436] missing -Wstringop-overflow on strncat to a zero-size buffer

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-30
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Confirmed.

[Bug target/81593] Optimize PowerPC vector set from vector extract

[meissner at gcc dot gnu.org]

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

--- Comment #4 from Michael Meissner  ---
Author: meissner
Date: Wed Aug 30 01:14:05 2017
New Revision: 251446

URL: https://gcc.gnu.org/viewcvs?rev=251446=gcc=rev
Log:
2017-08-29  Michael Meissner  

Back port from trunk
2017-08-07  Michael Meissner  

PR target/81593
* gcc.target/powerpc/vsx-extract-6.c: New tests for optimzing
vector inserts from vector extracts.
* gcc.target/powerpc/vsx-extract-7.c: Likewise.


Added:
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vsx-extract-6.c
  - copied unchanged from r251429,
trunk/gcc/testsuite/gcc.target/powerpc/vsx-extract-6.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vsx-extract-7.c
  - copied unchanged from r251429,
trunk/gcc/testsuite/gcc.target/powerpc/vsx-extract-7.c

[Bug target/81593] Optimize PowerPC vector set from vector extract

[meissner at gcc dot gnu.org]

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

--- Comment #3 from Michael Meissner  ---
Author: meissner
Date: Wed Aug 30 01:12:21 2017
New Revision: 251445

URL: https://gcc.gnu.org/viewcvs?rev=251445=gcc=rev
Log:
[gcc]
2017-08-29  Michael Meissner  

Back port from trunk
2017-08-07  Michael Meissner  

PR target/81593
* config/rs6000/vsx.md (vsx_concat__1): New combiner insns
to recognize inserting into a vector from a double word element
that was extracted from another vector, and eliminate extra
XXPERMDI instructions.
(vsx_concat__2): Likewise.
(vsx_concat__3): Likewise.
(vsx_set_, VSX_D): Rewrite vector set in terms of vector
concat to allow optimizing inserts from previous extracts.

[gcc/testsuite]
2017-08-29  Michael Meissner  

Back port from trunk
2017-08-07  Michael Meissner  

PR target/81593
* gcc.target/powerpc/vec-setup.h: New tests to test various
combinations of setting up vectors of 2 double word elements.
* gcc.target/powerpc/vec-setup-long.c: Likewise.
* gcc.target/powerpc/vec-setup-double.c: Likewise.
* gcc.target/powerpc/vec-setup-be-long.c: Likewise.
* gcc.target/powerpc/vec-setup-be-double.c: Likewise.


Added:
   
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vec-setup-be-double.c
  - copied unchanged from r251429,
trunk/gcc/testsuite/gcc.target/powerpc/vec-setup-be-double.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vec-setup-be-long.c
  - copied unchanged from r251429,
trunk/gcc/testsuite/gcc.target/powerpc/vec-setup-be-long.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vec-setup-double.c
  - copied unchanged from r251429,
trunk/gcc/testsuite/gcc.target/powerpc/vec-setup-double.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vec-setup-long.c
  - copied unchanged from r251429,
trunk/gcc/testsuite/gcc.target/powerpc/vec-setup-long.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vec-setup.h
  - copied unchanged from r251429,
trunk/gcc/testsuite/gcc.target/powerpc/vec-setup.h
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/rs6000/vsx.md
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug target/78643] [5/6/7/8 Regression] ICE in convert_move, at expr.c:230

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
E.g. the following untested patch fixes it (or we could do it in the callers):
--- gcc/expr.c.jj   2017-08-29 19:03:09.0 +0200
+++ gcc/expr.c  2017-08-30 02:09:33.150618229 +0200
@@ -7010,7 +7010,11 @@ get_inner_reference (tree exp, HOST_WIDE
 size.  */
mode = TYPE_MODE (DECL_BIT_FIELD_TYPE (field));
   else if (!DECL_BIT_FIELD (field))
-   mode = DECL_MODE (field);
+   {
+ mode = DECL_MODE (field);
+ if (mode == BLKmode && VECTOR_TYPE_P (TREE_TYPE (exp)))
+   mode = TYPE_MODE (TREE_TYPE (exp));
+   }
   else if (DECL_MODE (field) == BLKmode)
blkmode_bitfield = true;

[Bug target/78643] [5/6/7/8 Regression] ICE in convert_move, at expr.c:230

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
I think the problem is that while TYPE_MODE has the hacks for vector types
(vector_type_mode call), DECL_MODE doesn't have something similar.
We have some hacks for this here and there.

[Bug bootstrap/81926] go/parse.o differs between stage2 and stage3

[dclarke at blastwave dot org]

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

--- Comment #21 from Dennis Clarke  ---
update : after 11.7 hours the bootstrap completes with no errors. 

running gmake -k check now.

[Bug rtl-optimization/82024] [8 Regression] wrong code with -Og -fgcse-sm -frerun-cse-after-loop --param=max-combine-insns=3

[segher at gcc dot gnu.org]

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

--- Comment #2 from Segher Boessenkool  ---
What were the original insns?  (combine dump shows that right at the
start, with the insn costs for-em).

[Bug target/82002] [8 Regression] ICE in sp_valid_at, at config/i386/i386.c:13233

[daniel.santos at pobox dot com]

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

--- Comment #1 from Daniel Santos  ---
(In reply to Martin Liška from comment #0)
> Starting from r251321 we ICE on:
> 
> $ cat stack-check.ii
> void a (char *);
> void
> b ()
> {
>   char c[100];
>   c[1099511627776] = 'b';
>   a (c);
>   a (c);
> }
> 
> $ g++ stack-check.ii -Ofast -mstackrealign -mabi=ms

Thanks for the report!  I added a new check to catch things that shouldn't be
and it this is good because this invokes a code path that hadn't gotten yet.

  if (TARGET_64BIT
  && m->fs.sp_offset > 0x7fff
  && sp_valid_at (frame.stack_realign_offset)
  && (frame.nsseregs + frame.nregs) != 0)
{
  pro_epilogue_adjust_stack (stack_pointer_rtx, stack_pointer_rtx,
 GEN_INT (m->fs.sp_offset
  - frame.sse_reg_save_offset),
 style,
 m->fs.cfa_reg == stack_pointer_rtx);
}

The 3rd test in that if statement used to be m->fs.sp_valid, but I changed the
way we manage that so that it's valid for some offsets but not others.  I think
that this should be sp_valid_at (frame.stack_realign_offset + 1) however --
stack-grows-down math is still new and weird to me.  I'll spend some more time
with this tomorrow, but I think that one change is correct.

[Bug c/81389] _mm_cmpestri segfault on -O0

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |INVALID

--- Comment #14 from Jakub Jelinek  ---
(In reply to rockeet from comment #11)
> @H.J. Lu
> 
> Have you tried your `solution`?
> 
> `_mm_cmpestri` is a C function and have no overloaded with type `__m128i_u`.

Why would it need that?  __m128i_u is convertible to __m128i, just do what H.J.
posted.  Doing *(const __m128i*)(ptr+3) is UB at runtime if ptr mod 16 isn't
13, it doesn't matter what function you pass it into.  And at -O1 GCC is able
to merge the memory load with the pcmpestri instruction in this case, if you
care about code quality, don't use -O0.

There is no bug on the GCC side.

[Bug tree-optimization/81435] missing strlen optimization for strcat past the beginning of clear array

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-29
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Confirmed.

[Bug target/81585] fastcall/stdcall attribute conflict not detected on distinct declarations of the same function

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-29
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1
   Severity|normal  |minor

--- Comment #2 from Eric Gallager  ---
Confirmed that I get the same output as you but I dunno if I'd say "not
detected" so much as "detected inconsistently" in the title. In the end, does
it really matter that much, since they're still both errors anyways? Changing
importance from normal to minor.

[Bug c++/81327] cast to void* does not suppress -Wclass-memaccess

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-29
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1
   Severity|minor   |normal

--- Comment #2 from Eric Gallager  ---
Confirmed.

(In reply to Ville Voutilainen from comment #1)
> Note that this currently blocks building Qt with gcc 8. We could work around
> it by turning our void* casts to char* casts, but we have a preference for
> fixing this problem in the compiler.

Raising importance from minor to normal then.

[Bug c/81887] pragma omp ordered simd ignored under -fopenmp-simd

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-08-29
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
Created attachment 42084
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42084=edit
gcc8-pr81887.patch

Untested fix.

[Bug tree-optimization/81385] missing optimization involving strlen of arrays of known size

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-29
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Eric Gallager  ---
Confirmed.

[Bug tree-optimization/81343] missing strlen optimization with intervening strcat of unknown strings

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-29
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Eric Gallager  ---
Confirmed.

[Bug c++/78679] Produce a warning on `int + string literal`

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #3 from Eric Gallager  ---
(In reply to Eric Gallager from comment #1)
> 
> So I guess confirmed that g++ could warn earlier about the addition, too, to
> prevent it from leading to further issues. Might be related to requests for
> a -Wstring-plus-int, but in reverse order.

The bug for -Wstring-plus-int is bug 62181, by the way, and it led to this
patch series, which I think is still being worked on:
https://gcc.gnu.org/ml/gcc-patches/2017-06/msg00729.html

[Bug bootstrap/81926] go/parse.o differs between stage2 and stage3

[dclarke at blastwave dot org]

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

--- Comment #20 from Dennis Clarke  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #17)
> > --- Comment #16 from Dennis Clarke  ---
> > This is excellent follow up ...

> > Here is the diff on 7.2.0 gcc/config/sparc/sparc.c based on your patch :
> 
> Thanks.  Before trying a backport, we probably should go for the
> different solution Richard suggested, though.

Please see my question below.

> 
> > I do have GNU objcopy laying about also : 
> >
> > v9_7++ $ /usr/local/bin/gobjcopy --version 
> > GNU objcopy (GNU Binutils) 2.23.1
> > Copyright 2012 Free Software Foundation, Inc.
> > This program is free software; you may redistribute it under the terms of
> > the GNU General Public License version 3 or (at your option) any later 
> > version.
> > This program has absolutely no warranty.
> 
> This won't help right now: libgo's configure will only look for objcopy
> (or sparc64-sun-solaris2.10-objcopy in your case) and doesn't know about
> gobjcopy.
> 

yikes ... however see info below.

> AFAICS toplevel configure checks for the g-prefixed tools and passes the
> result to gcc/configure which heeds them, while libgo/configure does
> not.
> 
> Probably an issue for a separate libgo bug report.
> 
>   Rainer

Just a bit of info and a question. 

info : I have set the env var OBJCOPY=/usr/local/bin/gobjcopy and
   also set env var OBJDUMP=/usr/local/bin/gobjdump where both
   those tools exist and are from binutils 2.23.1


ques : Richard Bierner had said earlier "I'd rather do that where the
   assemby_start debug hook is called instead..." however I already 
   applied Rainer's patch to gcc/config/sparc/sparc.c and am running
   a stage3 bootstrap now. Should that change have been done elsewhere
   other than in a sparc specific target related source?

[Bug c++/78840] [5 Regression] ICE with const variables in templates implicitly captured by nested lambda expressions

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|5.5 |6.5

--- Comment #5 from Jason Merrill  ---
Added testcase, closing.

[Bug c++/81236] Crash when calling a template member function from generic lambda

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Tue Aug 29 21:38:21 2017
New Revision: 251438

URL: https://gcc.gnu.org/viewcvs?rev=251438=gcc=rev
Log:
PR c++/81236 - ICE with template-id in generic lambda

* semantics.c (finish_id_expression): Remove special dependent case.
Avoid some later pieces when dependent.
(finish_qualified_id_expr): Do normal BASELINK handling in a
template.  Always build a SCOPE_REF for a destructor BIT_NOT_EXPR.
(parsing_default_capturing_generic_lambda_in_template): Remove.
* parser.c (cp_parser_postfix_dot_deref_expression): Always give an
error for types that will never be complete.
* mangle.c (write_expression): Add sanity check.
* tree.c (build_qualified_name): Add sanity check.
(cp_walk_subtrees): Walk into the class context of a BASELINK.
* lambda.c (add_capture): Improve diagnostic for generic lambda
capture failure.
* call.c (build_new_method_call_1): Print the right constructor
name.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-this1.C
trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-this1a.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/lambda.c
trunk/gcc/cp/mangle.c
trunk/gcc/cp/parser.c
trunk/gcc/cp/semantics.c
trunk/gcc/cp/tree.c
trunk/gcc/testsuite/g++.dg/template/pseudodtor3.C

[Bug target/81193] PowerPC GCC __builtin_cpu_is and __builtin_cpu_supports should warn about old libraries

[meissner at gcc dot gnu.org]

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

--- Comment #17 from Michael Meissner  ---
Author: meissner
Date: Tue Aug 29 21:06:21 2017
New Revision: 251437

URL: https://gcc.gnu.org/viewcvs?rev=251437=gcc=rev
Log:


[gcc]
2017-07-13  Michael Meissner  

Back port from trunk
2017-07-12  Michael Meissner  

PR target/81193
* config/rs6000/rs6000-c.c (rs6000_cpu_cpp_builtins): If GLIBC
provides the hardware capability bits, define the macro
__BUILTIN_CPU_SUPPORTS__.
* config/rs6000/rs6000.c (cpu_expand_builtin): Generate a warning
if GLIBC does not provide the hardware capability bits.  Add a
gcc_unreachable call if the built-in cpu function is neither
__builtin_cpu_is nor __builtin_cpu_supports.
* doc/extend.texi (PowerPC built-in functions): Document that
GLIBC 2.23 or newer is needed by __builtin_cpu_is and
__builtin_cpu_supports.  Document the macros defined by GCC if the
newer GLIBC is available.

[gcc/testsuite]
2017-07-13  Michael Meissner  

Back port from trunk
2017-06-28  Michael Meissner  

PR target/81193
* lib/target-supports.exp
(check_ppc_cpu_supports_hw_available): New test to make sure
__builtin_cpu_supports works on power7 and newer.

Back port from trunk
2017-07-12  Michael Meissner  

PR target/81193
* gcc.target/powerpc/cpu-builtin-1.c: Add guard against using
__builtin_cpu_supports with old GLIBC's.


Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug lto/82027] [5/6/7/8 Regression] wrong code with -O3 -flto

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||hubicka at ucw dot cz
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org

--- Comment #2 from Martin Liška  ---
Started with r236012. I'll take a look tomorrow.

[Bug target/82015] PowerPC should check if 2nd argument to __builtin_unpackv1ti and similar functions is 0 or 1

[meissner at gcc dot gnu.org]

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

--- Comment #1 from Michael Meissner  ---
Author: meissner
Date: Tue Aug 29 20:25:57 2017
New Revision: 251432

URL: https://gcc.gnu.org/viewcvs?rev=251432=gcc=rev
Log:
[gcc]
2017-08-29  Michael Meissner  

PR target/82015
* config/rs6000/rs6000.c (rs6000_expand_binop_builtin): Insure
that the second argument of the built-in functions to unpack
128-bit scalar types to 64-bit values is 0 or 1.  Change to use a
switch statement instead a lot of if statements.
* config/rs6000/rs6000.md (unpack, FMOVE128_VSX iterator):
Allow 64-bit values to be in Altivec registers as well as
traditional floating point registers.
(pack, FMOVE128_VSX iterator): Likewise.

[gcc/testsuite]
2017-08-29  Michael Meissner  

PR target/82015
* gcc.target/powerpc/pr82015.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr82015.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/config/rs6000/rs6000.md
trunk/gcc/testsuite/ChangeLog

[Bug fortran/81841] [5/6/7/8 Regression] THREADPRIVATE (OpenMP) wrongly rejected in BLOCK DATA

[dibr-bugzilla at daswigwam dot de]

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

--- Comment #11 from dbroemmel  ---
Created attachment 42083
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42083=edit
testcase for the fix

I'm not sure this is the test you had in mind. A fresh gcc-7.2.0 shows an
unexpected failure while a 'patched' gcc-7.2.0 doesn't.

Still don't know how dejagnu works, but I copied what I found in other
blockdata tests.

[Bug c++/78840] [5 Regression] ICE with const variables in templates implicitly captured by nested lambda expressions

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Tue Aug 29 20:21:23 2017
New Revision: 251431

URL: https://gcc.gnu.org/viewcvs?rev=251431=gcc=rev
Log:
PR c++/78840 - ICE with const and nested generic lambda

* g++.dg/cpp1y/lambda-generic-const5.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-const5.C

[Bug testsuite/82006] [8 Regression] ERROR: torture-init: torture_without_loops is not empty as expected

[rai...@emrich-ebersheim.de]

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

--- Comment #4 from Rainer Emrich  ---
(In reply to Richard Biener from comment #3)
> In case it matters I have tcl 8.6.1 and 8.6.3.

I tried several different veriosn of tcl, expect an dejagnu. AFAIS the issue is
unrelated to a specific version of the tools.

I try hunting for the cause of the issue when I find the time.

[Bug lto/82027] [5/6/7/8 Regression] wrong code with -O3 -flto

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-29
Summary|wrong code with -O3 -flto   |[5/6/7/8 Regression] wrong
   ||code with -O3 -flto
 Ever confirmed|0   |1

--- Comment #1 from Marc Glisse  ---
gcc mistakenly thinks it found some UB (division by zero) and inserts a trap.

[Bug c++/80935] [C++1z] incorrect error 'uninitialized variable in constexpr function' when conditionally declaring variable inside lambda inside template class

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Tue Aug 29 19:51:30 2017
New Revision: 251429

URL: https://gcc.gnu.org/viewcvs?rev=251429=gcc=rev
Log:
PR c++/80935 - wrong C++17 error with lambda

* decl.c (check_for_uninitialized_const_var): Check
is_instantiation_of_constexpr.
* constexpr.c (ensure_literal_type_for_constexpr_object): Check
is_instantiation_of_constexpr.
(potential_constant_expression_1): Check var_in_maybe_constexpr_fn.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/constexpr-lambda16.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/cp/decl.c

[Bug c++/82008] nonnull attribute and multiple inheritance

[joerg.rich...@pdv-fs.de]

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

--- Comment #2 from Jörg Richter  ---
My original intention was to use the attribute to skip the nullptr check when
up-casting.
So my preference is to optimize based on the attribute if possible.

[Bug c/82028] Windows x86_64 should not pass float aggregates in xmm

[jistone at redhat dot com]

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

--- Comment #1 from Josh Stone  ---
Fedora's mingw-gcc also produces code passing through xmm0:

 :
   0:   55  push   %rbp
   1:   48 89 e5mov%rsp,%rbp
   4:   f2 0f 11 45 10  movsd  %xmm0,0x10(%rbp)
   9:   f2 0f 10 4d 10  movsd  0x10(%rbp),%xmm1
   e:   f3 0f 7e 05 00 00 00movq   0x0(%rip),%xmm0# 16 
  15:   00 
  16:   66 0f 54 c1 andpd  %xmm1,%xmm0
  1a:   f2 0f 11 45 10  movsd  %xmm0,0x10(%rbp)
  1f:   f2 0f 10 45 10  movsd  0x10(%rbp),%xmm0
  24:   5d  pop%rbp
  25:   c3  retq   

$ x86_64-w64-mingw32-gcc -v
Using built-in specs.
COLLECT_GCC=x86_64-w64-mingw32-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-w64-mingw32/7.1.0/lto-wrapper
Target: x86_64-w64-mingw32
Configured with: ../configure --prefix=/usr --bindir=/usr/bin
--includedir=/usr/include --mandir=/usr/share/man --infodir=/usr/share/info
--datadir=/usr/share --build=x86_64-redhat-linux-gnu
--host=x86_64-redhat-linux-gnu --with-gnu-as --with-gnu-ld --verbose
--without-newlib --disable-multilib --disable-plugin --with-system-zlib
--disable-nls --without-included-gettext --disable-win32-registry
--enable-languages=c,c++,objc,obj-c++,fortran
--with-bugurl=http://bugzilla.redhat.com/bugzilla --with-cloog
--enable-threads=posix --enable-libgomp --target=x86_64-w64-mingw32
--with-sysroot=/usr/x86_64-w64-mingw32/sys-root
--with-gxx-include-dir=/usr/x86_64-w64-mingw32/sys-root/mingw/include/c++
Thread model: posix
gcc version 7.1.0 20170502 (Fedora MinGW 7.1.0-1.fc26) (GCC)

[Bug c++/80767] Eager instantiation of generic lambda body when not required

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Tue Aug 29 19:40:55 2017
New Revision: 251427

URL: https://gcc.gnu.org/viewcvs?rev=251427=gcc=rev
Log:
PR c++/80767 - unnecessary instantiation of generic lambda

* call.c (convert_like_real): Call build_user_type_conversion_1 if
cand is null.
(add_conv_candidate): Build a ck_user conversion with no candidate.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/lambda-inherit1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c

[Bug c/82028] New: Windows x86_64 should not pass float aggregates in xmm

[jistone at redhat dot com]

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

Bug ID: 82028
   Summary: Windows x86_64 should not pass float aggregates in xmm
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jistone at redhat dot com
  Target Milestone: ---

Given this input foo.c:

#include 
typedef struct { double x; } Foo;
Foo foo(Foo f) {
f.x = fabs(f.x);
return f;
}

mingw-gcc produces code that uses XMM0 for both the argument and return.

 :
   0:   55  push   %rbp
   1:   48 89 e5mov%rsp,%rbp
   4:   f2 0f 11 45 10  movsd  %xmm0,0x10(%rbp)
   9:   f2 0f 10 4d 10  movsd  0x10(%rbp),%xmm1
   e:   f3 0f 7e 05 00 00 00movq   0x0(%rip),%xmm0# 16 
  15:   00
  16:   66 0f 54 c1 andpd  %xmm1,%xmm0
  1a:   f2 0f 11 45 10  movsd  %xmm0,0x10(%rbp)
  1f:   f2 0f 10 45 10  movsd  0x10(%rbp),%xmm0
  24:   5d  pop%rbp
  25:   c3  retq

MSVC passes the argument in RCX and the return value in RAX:

 :
   0:   48 89 4c 24 08  mov%rcx,0x8(%rsp)
   5:   48 83 ec 28 sub$0x28,%rsp
   9:   f2 0f 10 44 24 30   movsd  0x30(%rsp),%xmm0
   f:   e8 00 00 00 00  callq  14 
  14:   f2 0f 11 44 24 30   movsd  %xmm0,0x30(%rsp)
  1a:   48 8b 44 24 30  mov0x30(%rsp),%rax
  1f:   48 83 c4 28 add$0x28,%rsp
  23:   c3  retq

And mingw-clang uses RCX/RAX like MSVC:

 :
   0:   48 83 ec 10 sub$0x10,%rsp
   4:   48 89 0c 24 mov%rcx,(%rsp)
   8:   f2 0f 10 04 24  movsd  (%rsp),%xmm0
   d:   0f 28 0d 00 00 00 00movaps 0x0(%rip),%xmm1# 14 
  14:   66 0f db c1 pand   %xmm1,%xmm0
  18:   f2 0f 11 04 24  movsd  %xmm0,(%rsp)
  1d:   48 8b 0c 24 mov(%rsp),%rcx
  21:   48 89 4c 24 08  mov%rcx,0x8(%rsp)
  26:   48 8b 44 24 08  mov0x8(%rsp),%rax
  2b:   48 83 c4 10 add$0x10,%rsp
  2f:   c3  retq



$ gcc -v
Using built-in specs.
COLLECT_GCC=C:\msys64\mingw64\bin\gcc.exe
COLLECT_LTO_WRAPPER=C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.2.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-7.2.0/configure --prefix=/mingw64
--with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32
--host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32
--with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include
--libexecdir=/mingw64/lib --enable-bootstrap --with-arch=x86-64
--with-tune=generic --enable-languages=c,lto,c++,objc,obj-c++,fortran,ada
--enable-shared --enable-static --enable-libatomic --enable-threads=posix
--enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-time=yes
--disable-libstdcxx-pch --disable-libstdcxx-debug --disable-isl-version-check
--enable-lto --enable-libgomp --disable-multilib --enable-checking=release
--disable-rpath --disable-win32-registry --disable-nls --disable-werror
--disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw64
--with-mpfr=/mingw64 --with-mpc=/mingw64 --with-isl=/mingw64
--with-pkgversion='Rev1, Built by MSYS2 project'
--with-bugurl=https://sourceforge.net/projects/msys2 --with-gnu-as
--with-gnu-ld
Thread model: posix
gcc version 7.2.0 (Rev1, Built by MSYS2 project)

$ clang -v
clang version 4.0.0 (tags/RELEASE_400/final)
Target: x86_64-w64-windows-gnu
Thread model: posix
InstalledDir: C:\msys64\mingw64\bin

>cl
Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24210 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

[Bug libstdc++/81964] istream_iterator: unexpected read in ctor

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #5 from Jonathan Wakely  ---
I don't see why we need a new test.

[Bug libstdc++/81857] [DR2471] istreambuf_iterator not work as input iterator

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |SUSPENDED
   Last reconfirmed||2017-08-29
Summary|istreambuf_iterator not |[DR2471]
   |work as input iterator  |istreambuf_iterator not
   ||work as input iterator
 Ever confirmed|0   |1

--- Comment #4 from Jonathan Wakely  ---
As TC said, there's nothing wrong with our istreambuf_iterator. Our copy_n is
also conforming, due to the poor specification. I don't want to add a test
verifying behaviour that might be defective and might change.

The "suggested workaround" certainly doesn't belong in our testsuite.

[Bug c++/78679] Produce a warning on `int + string literal`

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Vittorio Romeo from comment #0)
> This code snippet
> 
> int main()
> {
> auto a = 6 + ".txt";   
> }
> 
> does not produce any warning with `-Wall -Wextra -Wpedantic`.
> 
> I think this is a common beginner mistake that a warning could avoid.

But this is valid C++ code, and there are valid reasons to write that. The fact
it does something different to what a beginner might expect doesn't mean it
should warn. Certainly not with -Wall.

// returns either "long-filename.txt" or "filename.txt"
const char* filename(bool shortname)
{
  return (shortname ? 5 : 0) + "long-filename.txt";
}

I'm curious what the precise behaviour of Clang's -Wstring-plus-int is, and
which cases it does/doesn't warn about. It warns about this case:

prog.cc:4:30: warning: adding 'int' to a string does not append to the string
[-Wstring-plus-int]
  return (shortname ? 5 : 0) + "long-filename.txt";
 ^
prog.cc:4:30: note: use array indexing to silence this warning
1 warning generated.

But using array indexing would not improve the code IMHO:

  return &"long-filename.txt"[shortname ? 5 : 0];

[Bug lto/82027] New: wrong code with -O3 -flto

[ssbssa at yahoo dot de]

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

Bug ID: 82027
   Summary: wrong code with -O3 -flto
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ssbssa at yahoo dot de
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

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

With the attached file I get a division by 0 when using "-O3 -flto", but not
with "-O2 -flto" or just "-O3".
Fails with 7.1.0 and 7.2.0, but not with 6.3.0.


$ g++ -O3 -flto -g -odiv0 div0.cpp

$ gdb -q div0
Reading symbols from div0...done.
(gdb) r
Starting program: C:\qiewer\div0.exe
[New Thread 1768.0x4e0]

Program received signal SIGFPE, Arithmetic exception.
0x0040f8f3 in calcPercent (name=0x411000 "", size=0, pos=4263936,
this=0x3b1f60) at div0.cpp:49
49int percent = 100*pos/size;
(gdb) bt
#0  0x0040f8f3 in calcPercent (name=0x411000 "", size=0, pos=4263936,
this=0x3b1f60) at div0.cpp:49
#1  Looper::loop() () at div0.cpp:23
#2  main (argc=, argv=) at div0.cpp:64
(gdb) kill
Kill the program being debugged? (y or n) [answered Y; input not from terminal]
(gdb) quit

[Bug c++/66256] noexcept evaluation done before end of class

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  ---
Right, GCC's behaviour for comment 0, comment 7 and comment 8 is a bug.

GCC's behaviour for comment 3 and comment 4 is not a bug.

[Bug target/81803] [7/8 regression] miscompilation at -O1 on mips64el

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

   Assignee|ebotcazou at gcc dot gnu.org   |mpf at gcc dot gnu.org

--- Comment #10 from Eric Botcazou  ---
> Created attachment 42075 [details]
> Proposed fix
> 
> Off-thread James pointed out that one of my patches I did last year appeared
> to fix this issue but it was one I reverted owing to breaking ARM (and
> probably others). The thread was:
> 
> https://gcc.gnu.org/ml/gcc-patches/2017-02/msg00518.html

Great, reassigned to you then, but I can provide testing on SPARC of course.

[Bug c++/81932] Template arguments of type unsigned generate incorrect debugging information

[redi at gcc dot gnu.org]

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

--- Comment #21 from Jonathan Wakely  ---
(In reply to Xi Ruoyao from comment #20)
> (In reply to Martin Sebor from comment #18)
> > GDB already has a C++ parser.  It just isn't good enough.  It understands
> > that B and B are one and the same type but it
> > interprets A<2> and A<2u> as distinct.  In my view, this is not just a
> > limitation but a bug.
> 
> My point is B and B are the same symbol (_Z1BIjE),
> but
> A<2> is _Z1AILi2EE, and A<2u> is _Z1AILj2EE.

But if A is a class template A taking an unsigned template argument
then A<2> can only mean the same thing as A<2u>. So there's no problem with
calling it A<2> in the DWARF info.

I agree with Martin that GDB needs to be able to handle this, because the
formatting of non-type template arguments in debuginfo varies between compilers
in other ways too, see 
https://sourceware.org/bugzilla/show_bug.cgi?id=21296 and 
https://sourceware.org/bugzilla/show_bug.cgi?id=21492

I don't see a GCC bug here.

[Bug c++/82025] [6/7 Regression] ICE: in finish_expr_stmt, at cp/semantics.c:678

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-29
 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
Summary|ICE: in finish_expr_stmt,   |[6/7 Regression] ICE: in
   |at cp/semantics.c:678   |finish_expr_stmt, at
   ||cp/semantics.c:678
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
With -std=c++14 fixed in r249083 and started with r233183.

[Bug c++/82008] nonnull attribute and multiple inheritance

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-29
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
The upcast to the base class requires adjustment if the pointer is non-null, so
the GIMPLE for the call is funcyyy (d != 0B ? >D.2287 : 0B). This triggers
the warning.

Either we shouldn't warn here, because the null argument is emitted by the
compiler not the user code, or we should optimize based on the nonnull
attribute to perform the adjustment unconditionally: funcyyy (>D.2287)

[Bug tree-optimization/80936] bcmp, bcopy, and bzero not declared nonnull

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-29
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
I get warnings for the bcopy parts:

$ /usr/local/bin/gcc -c -O2 -S -Wall -Wextra 80936.c
80936.c: In function ‘zero0’:
80936.c:4:3: warning: argument 1 null where non-null expected [-Wnonnull]
   __builtin_memset (p, 0, n);   // warning, good
   ^~
80936.c:4:3: note: in a call to built-in function ‘__builtin_memset’
80936.c: In function ‘copy0’:
80936.c:16:3: warning: argument 1 null where non-null expected [-Wnonnull]
   __builtin_memcpy (p, q, n);   // warning, good
   ^~
80936.c:16:3: note: in a call to built-in function ‘__builtin_memcpy’
80936.c: In function ‘copy1’:
80936.c:22:3: warning: argument 2 null where non-null expected [-Wnonnull]
   __builtin_memcpy (p, q, n);   // warning, good
   ^~
80936.c:22:3: note: in a call to built-in function ‘__builtin_memcpy’
80936.c: In function ‘copy2’:
80936.c:28:3: warning: argument 1 null where non-null expected [-Wnonnull]
   __builtin_bcopy (q, p, n);   // missing warning
   ^
80936.c:28:3: note: in a call to built-in function ‘__builtin_memmove’
80936.c: In function ‘copy3’:
80936.c:34:3: warning: argument 2 null where non-null expected [-Wnonnull]
   __builtin_bcopy (q, p, n);   // missing warning
   ^
80936.c:34:3: note: in a call to built-in function ‘__builtin_memmove’
80936.c: In function ‘cmp0’:
80936.c:40:10: warning: argument 1 null where non-null expected [-Wnonnull]
   return __builtin_memcmp (p, q, n);   // warning, good
  ^~
80936.c:40:10: note: in a call to built-in function ‘__builtin_memcmp’
80936.c: In function ‘cmp1’:
80936.c:47:10: warning: argument 2 null where non-null expected [-Wnonnull]
   return __builtin_memcmp (p, q, n);   // warning, good
  ^~
80936.c:47:10: note: in a call to built-in function ‘__builtin_memcmp’
$

Confirmed for the rest though.

[Bug libstdc++/71500] regex::icase only works on first character in a range

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-29
 Ever confirmed|0   |1

--- Comment #15 from Jonathan Wakely  ---


Another testcase from Bug 77492:

#include 
#include 

using namespace std;

void check(const string& s, regex re) {
cout << s << " : " << (regex_match(s, re) ? "Match" : "Nope") << endl;
}

int main() {
regex re1 = regex("([a-z]+) \\1", regex::icase);
check("abc abc", re1);
check("Abc abc", re1);
check("abc Abc", re1);
}

output:
abc abc : Match
Abc abc : Nope
abc Abc : Nope


Tim, your patch didn't change the behaviour for this - is that expected?

[Bug libstdc++/71500] regex::icase only works on first character in a range

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||flashmozzg at gmail dot com

--- Comment #14 from Jonathan Wakely  ---
*** Bug 77492 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/82024] [8 Regression] wrong code with -Og -fgcse-sm -frerun-cse-after-loop --param=max-combine-insns=3

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-29
 CC||marxin at gcc dot gnu.org,
   ||segher at gcc dot gnu.org
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

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

[Bug libstdc++/77492] std regex icase doesn't seem to work correctly.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from Jonathan Wakely  ---
(In reply to Danila from comment #2)
> (In reply to Tim Shen from comment #1)
> > Seems to be the same issue as 71500.
> 
> Even though I assume that that bug (71500) was fixed (even though the status
> is still UNCONFIRMED) it haven't fixed the issue.

If the bug is still open it's not fixed.

> I tried with both latest gcc (7.2) and clang (5.0) on Ubuntu 16.04 and in
> both cases the result of this simple code was the same:

Since this is a library feature of course the result will be the same.

Tim says this is dup of Bug 71500 so marking it as such.

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

[Bug c++/82021] Unnecessary null pointer check in global placement new (and also in any class-specific placement new operator declared as noexcept)

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from Jonathan Wakely  ---
See PR 35878, the commit was r246301

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

[Bug c++/35878] [LWG 2302] Useless NULL pointer check when constructing object

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||carl.cook at gmail dot com

--- Comment #14 from Jonathan Wakely  ---
*** Bug 82021 has been marked as a duplicate of this bug. ***

[Bug sanitizer/81902] new -fsanitize=pointer-overflow option undocumented

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-08-29
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Created attachment 42081
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42081=edit
gcc8-pr81902.patch

Untested fix.

[Bug sanitizer/81021] stack-use-after-scope false positive error with exceptions

[matt at godbolt dot org]

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

--- Comment #34 from Matt Godbolt  ---
Confirmed this fixes all the issues we were seeing. Thanks!

[Bug c++/82021] Unnecessary null pointer check in global placement new (and also in any class-specific placement new operator declared as noexcept)

[glisse at gcc dot gnu.org]

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

--- Comment #3 from Marc Glisse  ---
You can search for "Ville Voutilainen", the patch was this year, not long
before the release so maybe March.

[Bug fortran/82018] -Wextra should imply -Wconversion-extra

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #6 from Thomas Koenig  ---
(In reply to janus from comment #5)
> (In reply to tkoe...@netcologne.de from comment #3)
> > > Maybe one could re-enable such warnings at least with -Wextra?
> > 
> > The warning is given with -Wconversion-extra.
> > 
> > We could enable -Wconversion-extra with -Wextra.
> 
> Yes, please! Why isn't that done already? Sounds like an ideal candidate for
> -Wextra. Leaving it out certainly violates the principle of least surprise
> ...
> 
> If no one else has time for such "trivialities", I will take the time.

The patch is quite simple (just modify the relevant line
in lang.opts and update the docs).

-Wconversion-extra uncovers lots of things that people may not want to
see a warning about, such as i8=i4.

We had a lengthy discussion about this in 2015, with the current
implementation as the result.

See https://gcc.gnu.org/ml/fortran/2015-05/msg00176.html and
followups for the discussions about this.

[Bug sanitizer/81981] [8 Regression] -fsanitize=undefined makes a -Wmaybe-uninitialized warning disappear

[jakub at gcc dot gnu.org]

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

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 42080
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42080=edit
gcc8-pr81981.patch

Untested fix.

[Bug demangler/82026] New: Undemanglable symbol

[jeanmichael.celerier at gmail dot com]

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

Bug ID: 82026
   Summary: Undemanglable symbol
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: demangler
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jeanmichael.celerier at gmail dot com
  Target Milestone: ---

This one makes c++filt and GDB crash: 


_ZN4eggs8variants6detail7visitorINS1_6_applyIvZN5Media12AudioDecoder14on_startDecodeE7QStringEUlRT_E_NS1_4packIJEEENSA_IJRNS1_8_storageINSA_IJNS1_5emptyEN12_GLOBAL__N_17DecoderIsLm1ELm16ELb1EEENSF_IsLm2ELm16ELb1EEENSF_IsLm2ELm16ELb0EEENSF_IsLm4ELm16ELb1EEENSF_IsLm4ELm16ELb0EEENSF_IsLm6ELm16ELb1EEENSF_IsLm6ELm16ELb0EEENSF_IsLm8ELm16ELb1EEENSF_IsLm8ELm16ELb0EEENSF_IsLm18446744073709551615ELm16ELb1EEENSF_IsLm18446744073709551615ELm16ELb0EEENSF_IiLm1ELm24ELb1EEENSF_IiLm2ELm24ELb1EEENSF_IiLm2ELm24ELb0EEENSF_IiLm4ELm24ELb1EEENSF_IiLm4ELm24ELb0EEENSF_IiLm6ELm24ELb1EEENSF_IiLm6ELm24ELb0EEENSF_IiLm8ELm24ELb1EEENSF_IiLm8ELm24ELb0EEENSF_IiLm18446744073709551615ELm24ELb1EEENSF_IiLm18446744073709551615ELm24ELb0EEENSF_IiLm1ELm32ELb1EEENSF_IiLm2ELm32ELb1EEENSF_IiLm2ELm32ELb0EEENSF_IiLm4ELm32ELb1EEENSF_IiLm4ELm32ELb0EEENSF_IiLm6ELm32ELb1EEENSF_IiLm6ELm32ELb0EEENSF_IiLm8ELm32ELb1EEENSF_IiLm8ELm32ELb0EEENSF_IiLm18446744073709551615ELm32ELb1EEENSF_IiLm18446744073709551615ELm32ELb0EEENSF_IfLm1ELm32ELb1EEENSF_IfLm2ELm32ELb1EEENSF_IfLm2ELm32ELb0EEENSF_IfLm4ELm32ELb1EEENSF_IfLm4ELm32ELb0EEENSF_IfLm6ELm32ELb1EEENSF_IfLm6ELm32ELb0EEENSF_IfLm8ELm32ELb1EEENSF_IfLm8ELm32ELb0EEENSF_IfLm18446744073709551615ELm32ELb1EEENSF_IfLm18446744073709551615ELm32ELb0EELb1ELb1FvOS9_S1Q_EE6_tableIJNS1_5indexILm1EEENS1X_ILm2EEENS1X_ILm3EEENS1X_ILm4EEENS1X_ILm5EEENS1X_ILm6EEENS1X_ILm7EEENS1X_ILm8EEENS1X_ILm9EEENS1X_ILm10EEENS1X_ILm11EEENS1X_ILm12EEENS1X_ILm13EEENS1X_ILm14EEENS1X_ILm15EEENS1X_ILm16EEENS1X_ILm17EEENS1X_ILm18EEENS1X_ILm19EEENS1X_ILm20EEENS1X_ILm21EEENS1X_ILm22EEENS1X_ILm23EEENS1X_ILm24EEENS1X_ILm25EEENS1X_ILm26EEENS1X_ILm27EEENS1X_ILm28EEENS1X_ILm29EEENS1X_ILm30EEENS1X_ILm31EEENS1X_ILm32EEENS1X_ILm33EEENS1X_ILm34EEENS1X_ILm35EEENS1X_ILm36EEENS1X_ILm37EEENS1X_ILm38EEENS1X_ILm39EEENS1X_ILm40EEENS1X_ILm41EEENS1X_ILm42EEENS1X_ILm43EEENS1X_ILm44E5valueE

[Bug c++/82021] Unnecessary null pointer check in global placement new (and also in any class-specific placement new operator declared as noexcept)

[carl.cook at gmail dot com]

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

--- Comment #2 from Carl Cook  ---
Thanks Marc, that was it. I'd tried with no std=X flags, and std=c+=11. 

Definitely a DUP. I didn't find any related bug reports when skimming through
bugzilla, but that's probably just my fault.

Incidentally, if you have a sha of the commit(s) that fixed this, please let me
know, I'd be interested in taking a look.

[Bug libstdc++/77492] std regex icase doesn't seem to work correctly.

[flashmozzg at gmail dot com]

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

--- Comment #3 from Danila  ---
Update: Clang with libc++ also matches regex in all 3 cases.

[Bug libstdc++/77492] std regex icase doesn't seem to work correctly.

[flashmozzg at gmail dot com]

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

--- Comment #2 from Danila  ---
(In reply to Tim Shen from comment #1)
> Seems to be the same issue as 71500.

Even though I assume that that bug (71500) was fixed (even though the status is
still UNCONFIRMED) it haven't fixed the issue.
I tried with both latest gcc (7.2) and clang (5.0) on Ubuntu 16.04 and in both
cases the result of this simple code was the same:

#include 
#include 

using namespace std;

void check(const string& s, regex re) {
cout << s << " : " << (regex_match(s, re) ? "Match" : "Nope") << endl;
}

int main() {
regex re1 = regex("([a-z]+) \\1", regex::icase);
check("abc abc", re1);
check("Abc abc", re1);
check("abc Abc", re1);
}

output:
abc abc : Match
Abc abc : Nope
abc Abc : Nope

It looks like both compilers don't ignore the case of the backreferences which
looks like a bug. I haven't found any exceptions to the icase flag in case of
backrefs and this how it works in most languages. Also, it looks like Visual
C++ compiler works with this case correctly (i.e. it matches the string in all
3 cases).

[Bug c++/82021] Unnecessary null pointer check in global placement new (and also in any class-specific placement new operator declared as noexcept)

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
Did you try with -std=c++1z? (if that solves your issue, this is a DUP, it
should be enabled in all mode, but it isn't yet)

[Bug c++/82025] New: ICE: in finish_expr_stmt, at cp/semantics.c:678

[nsz at gcc dot gnu.org]

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

Bug ID: 82025
   Summary: ICE: in finish_expr_stmt, at cp/semantics.c:678
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nsz at gcc dot gnu.org
  Target Milestone: ---

following code fails with ice with gcc 7.2.1 and gcc 6.3.0 (works on gcc 8):

constexpr int nlz(int x) {
  return __builtin_constant_p(x) ? 0 : 1;
}

struct A {
  constexpr A() { nlz(0); }
};

constexpr A operator-(A x) { return x; }

constexpr A bar() {
  constexpr A x;
  A y = -x;
  return y;
}

$ g++ -S bar.cpp 
bar.cpp: In function 'constexpr A bar()':
bar.cpp:13:10: internal compiler error: in finish_expr_stmt, at
cp/semantics.c:678
   A y = -x;
  ^
0x695d33 finish_expr_stmt(tree_node*)
/S/gcc/cp/semantics.c:678
0x5c9e3f initialize_local_var
/S/gcc/cp/decl.c:6612
0x5c9e3f cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
/S/gcc/cp/decl.c:7173
0x65d60b cp_parser_init_declarator
/S/gcc/cp/parser.c:19403
0x65dd97 cp_parser_simple_declaration
/S/gcc/cp/parser.c:12786
0x65e97f cp_parser_block_declaration
/S/gcc/cp/parser.c:12611
0x65f2a7 cp_parser_declaration_statement
/S/gcc/cp/parser.c:12221
0x63fa27 cp_parser_statement
/S/gcc/cp/parser.c:10708
0x640e8b cp_parser_statement_seq_opt
/S/gcc/cp/parser.c:11040
0x640f4f cp_parser_compound_statement
/S/gcc/cp/parser.c:10994
0x652b43 cp_parser_function_body
/S/gcc/cp/parser.c:21455
0x652b43 cp_parser_ctor_initializer_opt_and_function_body
/S/gcc/cp/parser.c:21493
0x6594a3 cp_parser_function_definition_after_declarator
/S/gcc/cp/parser.c:26284
0x65da47 cp_parser_function_definition_from_specifiers_and_declarator
/S/gcc/cp/parser.c:26196
0x65da47 cp_parser_init_declarator
/S/gcc/cp/parser.c:19182
0x65dd97 cp_parser_simple_declaration
/S/gcc/cp/parser.c:12786
0x65e97f cp_parser_block_declaration
/S/gcc/cp/parser.c:12611
0x63c65b cp_parser_declaration
/S/gcc/cp/parser.c:12509
0x662eb3 cp_parser_declaration_seq_opt
/S/gcc/cp/parser.c:12385
0x6631e3 cp_parser_translation_unit
/S/gcc/cp/parser.c:4368
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug c++/81932] Template arguments of type unsigned generate incorrect debugging information

[ryxi at stu dot xidian.edu.cn]

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

--- Comment #20 from Xi Ruoyao  ---
(In reply to Martin Sebor from comment #18)
> GDB already has a C++ parser.  It just isn't good enough.  It understands
> that B and B are one and the same type but it
> interprets A<2> and A<2u> as distinct.  In my view, this is not just a
> limitation but a bug.

My point is B and B are the same symbol (_Z1BIjE), but
A<2> is _Z1AILi2EE, and A<2u> is _Z1AILj2EE.

But let's focus on THIS problem now.  I'm trying to make GDB working and GDBing
a GDB :)

[Bug rtl-optimization/82024] New: [8 Regression] wrong code with -Og -fgcse-sm -frerun-cse-after-loop --param=max-combine-insns=3

[zsojka at seznam dot cz]

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

Bug ID: 82024
   Summary: [8 Regression] wrong code with -Og -fgcse-sm
-frerun-cse-after-loop --param=max-combine-insns=3
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

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

Output:
$ x86_64-pc-linux-gnu-gcc -Og -fgcse-sm -frerun-cse-after-loop
--param=max-combine-insns=3 testcase.c
$ ./a.out 
Aborted

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


.combine does:
...
Trying 13, 12 -> 14:
...
Successfully matched this instruction:
(set (reg:DI 106)
(const_int 0 [0]))
Successfully matched this instruction:
(set (reg:DI 105)
(plus:DI (reg/v:DI 101 [ eD.1821 ])
(reg:DI 103)))
allowing combination of insns 12, 13 and 14
original costs 4 + 4 + 0 = 0
replacement costs 4 + 4 = 8
deferring deletion of insn with uid = 12.
modifying insn i213: r106:DI=0
deferring rescan insn with uid = 13.
modifying insn i314: r105:DI=r101:DI+r103:DI
  REG_DEAD r101:DI
  REG_DEAD r103:DI
deferring rescan insn with uid = 14.
...
Trying 14, 13 -> 20:
Successfully matched this instruction:
(set (reg:DI 105)
(plus:DI (reg/v:DI 101 [ eD.1821 ])
(reg:DI 103)))
allowing combination of insns 13, 14 and 20
original costs 4 + 4 + 6 = 14
replacement cost 4
deferring rescan insn with uid = 20.
deferring deletion of insn with uid = 14.
deferring deletion of insn with uid = 13.
modifying insn i320: r105:DI=r101:DI+r103:DI
  REG_DEAD r103:DI
  REG_DEAD r101:DI
deferring rescan insn with uid = 20.
...


which results in:
...
(insn 17 16 20 2 (parallel [
(set (reg/v:DI 100 [  ])
(plus:DI (reg:DI 107 [ _2 ])
(reg:DI 105)))
(clobber (reg:CC 17 flags))
]) "testcase.c":16 218 {*adddi_1}
 (expr_list:REG_DEAD (reg:DI 107 [ _2 ])
(expr_list:REG_DEAD (reg:DI 105)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)
(insn 20 17 25 2 (set (reg:DI 105)
(plus:DI (reg/v:DI 101 [ eD.1821 ])
(reg:DI 103))) "testcase.c":18 214 {*leadi}
 (expr_list:REG_DEAD (reg:DI 103)
(expr_list:REG_DEAD (reg/v:DI 101 [ eD.1821 ])
(nil
...

insn 17 uses r105, which is now set in insn 20, which appears after it

[Bug c++/82023] New: [arm] constexpr ICE: in cxx_eval_constant_expression, at cp/constexpr.c:4556

[nsz at gcc dot gnu.org]

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

Bug ID: 82023
   Summary: [arm] constexpr ICE: in cxx_eval_constant_expression,
at cp/constexpr.c:4556
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nsz at gcc dot gnu.org
  Target Milestone: ---

following c++14 code fails to compile with ice on arm targets:

struct A {
  constexpr A() {
return;
  }
};

A x;

$ arm-none-linux-gnueabihf-g++ -S foo.cpp
foo.cpp:7:3:   in constexpr expansion of ‘x.A::A()’
foo.cpp:7:3: internal compiler error: in cxx_eval_constant_expression, at
cp/constexpr.c:4556
 A x;
   ^
0x6777c3 cxx_eval_constant_expression
/S/gcc/cp/constexpr.c:4556
0x677a37 cxx_eval_statement_list
/S/gcc/cp/constexpr.c:3770
0x677a37 cxx_eval_constant_expression
/S/gcc/cp/constexpr.c:4497
0x67728b cxx_eval_constant_expression
/S/gcc/cp/constexpr.c:4503
0x677a37 cxx_eval_statement_list
/S/gcc/cp/constexpr.c:3770
0x677a37 cxx_eval_constant_expression
/S/gcc/cp/constexpr.c:4497
0x675f4f cxx_eval_call_expression
/S/gcc/cp/constexpr.c:1661
0x67723f cxx_eval_constant_expression
/S/gcc/cp/constexpr.c:4035
0x670d33 cxx_eval_outermost_constant_expr
/S/gcc/cp/constexpr.c:4667
0x67ee57 maybe_constant_init(tree_node*, tree_node*)
/S/gcc/cp/constexpr.c:4990
0x72b9a7 expand_default_init
/S/gcc/cp/init.c:1869
0x72b9a7 expand_aggr_init_1
/S/gcc/cp/init.c:1972
0x72c05f build_aggr_init(tree_node*, tree_node*, int, int)
/S/gcc/cp/init.c:1713
0x6c14ff build_aggr_init_full_exprs
/S/gcc/cp/decl.c:6094
0x6c14ff check_initializer
/S/gcc/cp/decl.c:6242
0x6e205f cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
/S/gcc/cp/decl.c:6961
0x7b50df cp_parser_init_declarator
/S/gcc/cp/parser.c:19674
0x7b7b4b cp_parser_simple_declaration
/S/gcc/cp/parser.c:13051
0x7b8a1f cp_parser_block_declaration
/S/gcc/cp/parser.c:12877
0x7c1063 cp_parser_declaration
/S/gcc/cp/parser.c:12774
Please submit a full bug report,
with preprocessed source if appropriate.

the assert is

 4554case GOTO_EXPR:
 4555  *jump_target = TREE_OPERAND (t, 0);  
 4556  gcc_assert (breaks (jump_target) || continues (jump_target));
 4557  break;   

the -tree-original output is unexpected on arm:

;; Function constexpr A::A() (null)
;; enabled by -tree-original


{
  // predicted unlikely by goto predictor.;
  goto ;
}
:;
return this;


e.g. on aarch64 it's:

;; Function constexpr A::A() (null)
;; enabled by -tree-original


{
  return;
}

[Bug sanitizer/81923] [ASAN] gcc emites wrong odr asan instrumentation for glibc

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-08-29
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #7 from Jakub Jelinek  ---
Created attachment 42078
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42078=edit
gcc8-pr81923.patch

Full untested fix.

[Bug target/80204] macosx-version-min wrong for macOS Sierra 10.12.3

[simon at pushface dot org]

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

--- Comment #3 from simon at pushface dot org ---
Created attachment 42077
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42077=edit
Patch to gcc/config/darwin-driver.c

[Bug sanitizer/81986] sanitizer detects negation of large number in string.c

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
(In reply to Vittorio Zecca from comment #2)
> I do not know if this is a libgfortran or a sanitizer bug.
> 
> What I do know is that changing string.c:199 from
> 
> t = - n;
> 
> into
> 
> t = -(GFC_UINTEGER_LARGEST)n;

This is of course the right fix, negation of smallest signed number is UB in C,
while it is well defined when the negation is performed in corresponding
unsigned type.

[Bug target/80204] macosx-version-min wrong for macOS Sierra 10.12.3

[simon at pushface dot org]

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

--- Comment #2 from simon at pushface dot org ---
Created attachment 42076
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42076=edit
Proposed solution

Demonstrates the solution proposed in the patch.

[Bug tree-optimization/81987] [8 Regression] ICE in verify_ssa with -O3 -march=skylake-avx512

[wschmidt at gcc dot gnu.org]

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

--- Comment #5 from Bill Schmidt  ---
-march is not required.  This repros on powerpc64le-linux-gnu as well with just
-O3.

[Bug target/81988] [7/8 Regression] invalid std instruction with odd register

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #5 from Eric Botcazou  ---
Investigating.

[Bug target/81988] [7/8 Regression] invalid std instruction with odd register

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-29
 CC||ebotcazou at gcc dot gnu.org
Summary|[7/8 Regression] sparc64:   |[7/8 Regression] invalid
   |emits STD instruction with  |std instruction with odd
   |odd register|register
 Ever confirmed|0   |1

--- Comment #4 from Eric Botcazou  ---
I can reproduce.

[Bug target/81803] [7/8 regression] miscompilation at -O1 on mips64el

[mpf at gcc dot gnu.org]

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

--- Comment #9 from mpf at gcc dot gnu.org ---
Created attachment 42075
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42075=edit
Proposed fix

Off-thread James pointed out that one of my patches I did last year appeared to
fix this issue but it was one I reverted owing to breaking ARM (and probably
others). The thread was:

https://gcc.gnu.org/ml/gcc-patches/2017-02/msg00518.html

At the time I thought I had fixed the same problem twice and that the changes
to simplify_operand_subreg were sufficient. It occurs to me however that
simplify_operand_subreg only has the opportunity to fix
WORD_REGISTER_OPERATIONS issues affecting subreg(mem) patterns not subreg(reg)
patterns where reg is a pseudo that may yet be spilled.

I can't say that I am 100% convinced yet with my thinking here but I've
attached an updated version of the original patch with some changes:

* Incorporated Eric's feedback on the original patch to check
GET_MODE_PRECISION instead of GET_MODE_SIZE for comparing whether a mode is
strictly narrower
* Limited the test to word sized inner modes or smaller
* Limited the test to OP_OUT or OP_INOUT as I can't see any reason why it would
matter if we do a narrower input reload

This is barely tested but does fix testcase-c which is the only one I can get
to trigger.

[Bug tree-optimization/80576] dead strcpy and strncpy followed by memset not eliminated

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-29
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Eric Gallager  ---
Confirmed.

[Bug tree-optimization/80537] missing -Wformat-overflow on POSIX %C conversion specification

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-29
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Confirmed. My comments about POSIX conformance from bug 80535 also apply here.

[Bug c++/81932] Template arguments of type unsigned generate incorrect debugging information

[psmith at gnu dot org]

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

--- Comment #19 from Paul Smith  ---
Hi; is there a next step for this?  I understand there's some concern that we
should be asking GDB to improve their capabilities but in the meantime can we
get GCC to emit the previous format?  It would be great if this could be fixed
for GCC 7.3.

I found another issue in GDB finding types containing defaulted template
arguments, but this problem exists in all versions of GCC so I filed the issue
against GDB instead.  No response so far.

https://sourceware.org/bugzilla/show_bug.cgi?id=22013

I also posted a question to the GDB mailing list asking for some conversation
around this issue, but also no response so far.

https://sourceware.org/ml/gdb/2017-08/msg00069.html

[Bug tree-optimization/80535] missing -Wformat-overfow on POSIX directives with the apostrophe flag

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-29
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Confirmed. Note that GCC is available for non-POSIX platforms though. There
should really be some sort of -posix-std= flag to mirror the -std=cyy flag,
i.e., to tell GCC which version of the POSIX standard to conform to, as opposed
to which version of the C standard. Maybe also recognize the POSIXLY_CORRECT
environment variable that other GNU programs use? Still, when GCC does conform
to POSIX, I agree that it should warn here.

[Bug sanitizer/81923] [ASAN] gcc emites wrong odr asan instrumentation for glibc

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
I think the right fix is something like:
--- asan.c.jj   2017-08-10 02:31:21.0 +0200
+++ asan.c  2017-08-29 17:25:58.337595628 +0200
@@ -2529,9 +2529,12 @@ create_odr_indicator (tree decl, tree ty
   /* DECL_NAME theoretically might be NULL.  Bail out with 0 in this case.  */
   if (decl_name == NULL_TREE)
 return build_int_cst (uptr, 0);
-  size_t len = strlen (IDENTIFIER_POINTER (decl_name)) + sizeof
("__odr_asan_");
+  const char *dname = IDENTIFIER_POINTER (decl_name);
+  if (HAS_DECL_ASSEMBLER_NAME_P (decl))
+dname = targetm.strip_name_encoding (dname);
+  size_t len = strlen (dname) + sizeof ("__odr_asan_");
   name = XALLOCAVEC (char, len);
-  snprintf (name, len, "__odr_asan_%s", IDENTIFIER_POINTER (decl_name));
+  snprintf (name, len, "__odr_asan_%s", dname);
 #ifndef NO_DOT_IN_LABEL
   name[sizeof ("__odr_asan") - 1] = '.';
 #elif !defined(NO_DOLLAR_IN_LABEL)

Let me try to write a full patch with a testcase.

[Bug ada/81961] [7/8 regression] an imported unsized C array in the auto-translated binding raises Storage_Error

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-29
 CC||ebotcazou at gcc dot gnu.org
Summary|[7 regression] an imported  |[7/8 regression] an
   |unsized C array in the  |imported unsized C array in
   |auto-translated binding |the auto-translated binding
   |raises Storage_Error|raises Storage_Error
 Ever confirmed|0   |1

--- Comment #2 from Eric Botcazou  ---
Confirmed, the new check is too broad.

[Bug tree-optimization/80532] warning on pointer access after free

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-29
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Confirmed; I'm surprised there wasn't already a bug for detecting
use-after-free at compile-time... (or maybe I just didn't find it)

[Bug fortran/81841] [5/6/7/8 Regression] THREADPRIVATE (OpenMP) wrongly rejected in BLOCK DATA

[dibr-bugzilla at daswigwam dot de]

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

--- Comment #10 from dbroemmel  ---
(In reply to janus from comment #9)
> This seems to be PR 81018 (which translates into "not your fault").
Good :)

> I'm happy for now. Backed by your OpenMP quotes, the patch looks pretty
> solid to me.
Can I add again: I've not checked (and wouldn't quite know how to) if this
Fortran/OpenMP syntax would require any GOMP machinery to work that's not there
yet. I did write a few simple minded tests for myself if the outcome of a
binary is what I would expect and it did seem work. I also assume that as it
did work prior to 4.9.x, all the OpenMP parts are there and work as expected
and only the syntax check in the parser failed.

And I don't take credit for the patch. It's what the OpenMP-forum entry
suggested.

> Do you feel confident enough to turn your small example into a dejagnu test
> case to be committed along with the patch? We'll also need a short ChangeLog
> entry for both.
I'm afraid not right now. I have no idea how dejagnu works. I can try and
devote some more time to it tomorrow, but I can't promise anything.

[Bug c++/82022] constexpr lambda in template context: expression ‘’ is not a constant expression

[bastien.penavayre at epitech dot eu]

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

--- Comment #1 from bastien penavayre  ---
Created attachment 42074
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42074=edit
log error

[Bug c++/82022] New: constexpr lambda in template context: expression ‘’ is not a constant expression

[bastien.penavayre at epitech dot eu]

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

Bug ID: 82022
   Summary: constexpr lambda in template context: expression
‘’ is not a constant expression
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bastien.penavayre at epitech dot eu
  Target Milestone: ---

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

in a template context a constexpr lambda doesn't seem to be able to be
constexpr evaluated and its result is not constexpr.

if constexpr ([]() constexpr {return true;}()); //expression ‘’ is not
a constant expression

constexpr bool r = []() constexpr {return true;}();
if constexpr (r); //"r" used in its own initializer

[Bug tree-optimization/80512] missing -Wformat-overfow on a numbered directive with width specified by "*m$"

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-29
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Confirmed.

[Bug ada/81956] [7/8 regression] calling a null procedure is not skipped

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-29
 CC||ebotcazou at gcc dot gnu.org
Summary|[7 regression] calling a|[7/8 regression] calling a
   |null procedure is not   |null procedure is not
   |skipped |skipped
 Ever confirmed|0   |1
  Known to fail||8.0

--- Comment #1 from Eric Botcazou  ---
Right, unfortunate change.

[Bug fortran/81841] [5/6/7/8 Regression] THREADPRIVATE (OpenMP) wrongly rejected in BLOCK DATA

[janus at gcc dot gnu.org]

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

--- Comment #9 from janus at gcc dot gnu.org ---
(In reply to dbroemmel from comment #8)
> (In reply to janus from comment #7)
> > Sounds unrelated to your patch (supported by the fact that the 6.2 testsuite
> > runs cleanly), however I haven't seen that failure on trunk recently.
> That's what I thought as well.
> 
> > Maybe you can check if it also occurs without the patch on your machine
> > (i.e. with a clean trunk)?
> It wasn't a clean trunk but the single line commented

Clean enough ;)


> and it still shows the same unexpected failure.

This seems to be PR 81018 (which translates into "not your fault").


> I can run more tests if you tell me which ones.

I'm happy for now. Backed by your OpenMP quotes, the patch looks pretty solid
to me.

Do you feel confident enough to turn your small example into a dejagnu test
case to be committed along with the patch? We'll also need a short ChangeLog
entry for both.

[Bug tree-optimization/81503] [8 Regression] Wrong code at -O2

[wschmidt at gcc dot gnu.org]

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

--- Comment #17 from Bill Schmidt  ---
Fixed in trunk so far.  Although this test case succeeds on GCC 7, the bug is
latent there, so I'll keep this open and backport the fix to other releases in
a week or so.

[Bug sanitizer/81923] [ASAN] gcc emites wrong odr asan instrumentation for glibc

[m.ostapenko at samsung dot com]

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

--- Comment #5 from Maxim Ostapenko  ---
(In reply to Maxim Ostapenko from comment #4)
> Created attachment 42071 [details]
> Untested fix
> 
> The patch I'm testing now. It works on attached testcase.

Yeeks, this patch is wrong, especially for C++. Please ignore it.

[Bug tree-optimization/81503] [8 Regression] Wrong code at -O2

[wschmidt at gcc dot gnu.org]

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

--- Comment #16 from Bill Schmidt  ---
Author: wschmidt
Date: Tue Aug 29 14:41:53 2017
New Revision: 251414

URL: https://gcc.gnu.org/viewcvs?rev=251414=gcc=rev
Log:
[gcc]

2017-08-29  Bill Schmidt  
Jakub Jelinek  
Richard Biener  

PR tree-optimization/81503
* gimple-ssa-strength-reduction.c (replace_mult_candidate): Ensure
folded constant fits in the target type; reorder tests for clarity.

[gcc/testsuite]

2017-08-29  Bill Schmidt  

PR tree-optimization/81503
* gcc.c-torture/execute/pr81503.c: New file.


Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr81503.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-strength-reduction.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/82021] New: Unnecessary null pointer check in global placement new (and also in any class-specific placement new operator declared as noexcept)

[carl.cook at gmail dot com]

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

Bug ID: 82021
   Summary: Unnecessary null pointer check in global placement new
(and also in any class-specific placement new operator
declared as noexcept)
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: carl.cook at gmail dot com
  Target Milestone: ---

Hi,

This is just a minor nitpick, but after the clarification made in DR 1748
(http://open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1748), there is a
redundant null pointer check being performed within placement new.

The null pointer check is done (in general) to make sure that any memory passed
in is valid, and if not, no object initialization or deinitialization should
take place. However, after a clarification to 5.3.4.15, it now states for
placement new, passing null is undefined behavior (i.e. the caller must do any
pointer checks).

When using any version of gcc (from 7.2.1 and below), for any optimization
level, and for the following two forms of placement new:
* Global placement new (i.e. no user-defined operator placement new)
* User-defined placement new (with noexcept specified)

Then not only does the null pointer check still exist, but this seems to cause
the optimizer to really miss a few things. Below is an obviously silly example,
but you can see that the opportunitity to inline gets discarded, as does the
opportunity to optimize-out the call to malloc.

--

#include 

int GetVal (int x) {
  if (x == 0)
return 1;
  else
return 2;
}

struct Object {
  Object(int x)  
  : i(GetVal(x)) {}
  int i;
};

void* GetBuffer() {
  return malloc(sizeof(Object));
}

int MyFn(int i) {
  void* mem = GetBuffer();
  Object* object = new(mem)Object(i);
  return object->i;
}

int main(int argc, char** argv) {
  int rv = MyFn(*argv[0]);
  return rv; 
}

--

If the following is added, at level O2, then this entire program gets optimized
away (into returning the address of the first character of argv[0] as an
integer)

void* Object::operator new(size_t, void* where) { return where; }

e.g.

  mov rax, QWORD PTR [rsi]
  cmp BYTE PTR [rax], 0
  setne al
  movzx eax, al
  add eax, 1
  ret

I'm assuming that gcc now relies on the object-specific placement new to signal
a null pointer by way of throwing an exception, hence the optimizer can be more
aggressive. But I think the optimizer can now be just as agressive with all
forms of placement new.

[Bug target/81803] [7/8 regression] miscompilation at -O1 on mips64el

[jcowgill+gcc at jcowgill dot uk]

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

--- Comment #8 from James Cowgill  ---
Created attachment 42072
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42072=edit
testcase-c

Here is another smaller testcase which was manually created. It works by using
asm to clobber all the registers and passing -ffixed for the saved registers to
force a stack spill and trigger the bug.

Compile with:
> gcc -S -O2 -fstack-protector-strong -ffixed-s0 -ffixed-s1 -ffixed-s2 
> -ffixed-s3 -ffixed-s4 -ffixed-s5 -ffixed-s6 -ffixed-s7 test.c

[Bug sanitizer/81923] [ASAN] gcc emites wrong odr asan instrumentation for glibc

[m.ostapenko at samsung dot com]

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

--- Comment #4 from Maxim Ostapenko  ---
Created attachment 42071
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42071=edit
Untested fix

The patch I'm testing now. It works on attached testcase.