[Bug target/81907] memset called when it does not need to be; -mtune=cortex-a9

[dongkyun.s at samsung dot com]

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

--- Comment #13 from dongkyun.s at samsung dot com ---
> Confirmed the call on 6.4.1 but GCC 7 and trunk don't generate the call for 
> -mcpu=cortex-a9 .

I also verified memset call is not generated with GCC 7.1 + "-mcpu=cortex-a9 or
-mtune=cortex-a9" or lower.

It seems interesting that 
in GCC6,
- don't generate the memset call for -mcpu=cortex-a12 or higer(e.g, cortex-a15,
V7 big.LITTLE)
- always generate the memset call for -mcpu=cortex-a9 or lower(e.g, cortex-a7,
cotex-a5)

in GCC7.1
- always don't generate the memset call (even with V3 Architecture Processors.
e.g, -mcpu=arm7)

[Bug bootstrap/81037] Xcode 9 requires back ports on gcc-5-branch for bootstrapping under Xcode 9

[ryan at mounce dot com.au]

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

Ryan Mounce  changed:

   What|Removed |Added

 CC||ryan at mounce dot com.au

--- Comment #10 from Ryan Mounce  ---
I had also submitted a backport of r235361 and r235362 to the mailing list to
address the same issue.

https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00476.html
https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00478.html
https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00477.html

[Bug c++/60342] -Wsign-conversion ignores explicit conversion

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |WORKSFORME

--- Comment #1 from Eric Gallager  ---
gcc8 no longer prints the -Wsign-conversion warning, but instead prints one for
-Wuninitialized:

$ /usr/local/bin/g++ -c -Wall -Wextra -pedantic -Wconversion -Wsign-conversion
60342.cc
60342.cc: In function ‘int main()’:
60342.cc:7:43: warning: ‘int_value’ is used uninitialized in this function
[-Wuninitialized]
  if (std::numeric_limits::max() - static_cast(int_value))
   ^~
$

Maybe -Wsign-conversion was fixed, but I dunno for sure, so I'll just say
WORKSFORME.

[Bug c/51834] -Wsequence-point fails when convoluted expressions with multiple side effects are used

[egallager at gcc dot gnu.org]

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

--- Comment #5 from Eric Gallager  ---
*** Bug 51836 has been marked as a duplicate of this bug. ***

[Bug c++/51836] -Wsequence-point fails when convoluted expressions with multiple side effects are used

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Gallager  ---
Oh looks like you actually already had another version of this bug with more
discussion on it

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

[Bug other/32415] libgcc_s not found in library search path with --enable-version-specific-runtime-libs

[ryxi at stu dot xidian.edu.cn]

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||ryxi at stu dot xidian.edu.cn

--- Comment #16 from Xi Ruoyao  ---
(In reply to Bruno Haible from comment #14)

> Conclusion:
> 
> So it looks really like a bug in the installation rules for libgcc_s.
> - The 32-bit libgcc_s ought to be installed in
> PREFIX/lib/gcc/x86_64-pc-linux-gnu/4.9.0/32, not
> PREFIX/lib/gcc/x86_64-pc-linux-gnu/lib32.
> - The 64-bit libgcc_s ought to be installed in
> PREFIX/lib/gcc/x86_64-pc-linux-gnu/4.9.0, not
> PREFIX/lib/gcc/x86_64-pc-linux-gnu/lib64.

But if we do that there would be no PREFIX/lib(64)/libgcc_s.so.1.  Then we
have to add PREFIX/lib/gcc/{arch}/{version}/{multilibdir} to ld.so.conf.  I
think we should create symlink PREFIX/lib(64)/libgcc_s.so.1 as well.

[Bug c++/51836] -Wsequence-point fails when convoluted expressions with multiple side effects are used

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic
 CC||egallager at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
(In reply to Prasoon from comment #0)
> Consider the following example
> 
> 
> int main()
> { 
>   int i=10;
>   i += (i , i++, i) + i; // also invokes UB
> }
> 
> 
> prasoon@Prasoon:~/test_code$ cat ub.cpp
> int main()
> { 
>   int i=10;
>   i += (i , i++, i) + i; // also invokes UB
> }
> prasoon@Prasoon:~/test_code$ g++ -Wsequence-point ub.cpp
> prasoon@Prasoon:~/test_code$ 
> 
> I don't get any warning like 'operation on 'i' may be undefined.
> 

This one now warns:

$ /usr/local/bin/g++ -c -Wsequence-point 51836.cc
51836.cc: In function ‘int main()’:
51836.cc:4:13: warning: operation on ‘i’ may be undefined [-Wsequence-point]
  i += (i , i++, i) + i; // also invokes UB
~^~
$

> Another similar example
> 
> int main()
> {
> char *str;
> char array[100]= "Hello";
> if((str = array)[0] == 'H'){
>  //do something
> }
> }
> 
> As per my understanding (str = array)[0] also invokes UB but no warning is
> given by g++ even after using that option.
> 
> Another example is 
> 
> int main()
> {
>int a = 10;
>++a = 100; // UB
> }

These next ones still don't warn, although I think they might be duplicates of
other bugs. Your 3rd example looks like bug 57039 but the example in that one
now warns. Gonna leave this UNCONFIRMED until I finish searching for
duplicates.

[Bug fortran/81296] derived type I/o problem

[jvdelisle at gcc dot gnu.org]

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

--- Comment #5 from Jerry DeLisle  ---
Author: jvdelisle
Date: Tue Aug 22 01:02:15 2017
New Revision: 251254

URL: https://gcc.gnu.org/viewcvs?rev=251254=gcc=rev
Log:
2017-08-21  Jerry DeLisle  

PR fortran/81296
* trans-io.c (get_dtio_proc): Add check for format label and set
formatted flag accordingly. Reorganize the code a little.

* gfortran.dg/dtio_12.f90: Update test.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-io.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/dtio_12.f90

[Bug c++/54052] g++ takes excessive time in opt and generate phase; can lead to Segmentation Fault when not enough memory available

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||compile-time-hog,
   ||memory-hog
 Status|UNCONFIRMED |NEW
   Last reconfirmed|2012-07-24 00:00:00 |2017-08-22
 CC||egallager at gcc dot gnu.org
Summary|Segmentation Fault  |g++ takes excessive time in
   ||opt and generate phase; can
   ||lead to Segmentation Fault
   ||when not enough memory
   ||available
 Ever confirmed|0   |1

--- Comment #6 from Eric Gallager  ---
(In reply to Christophe DUVERGER from comment #5)
> Created attachment 27868 [details]
> test08.ii file

Doesn't ICE for me, just takes an inordinately long time to compile (once I add
-fpermissive):

$ /usr/local/bin/g++ -Wno-system-headers -Wall -Wextra -ansi -pedantic -O6 -c
-o test08.o test08.ii
In file included from
/usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/ext/new_allocator.h:33:0,
 from
/usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/i686-pc-cygwin/bits/c++allocator.h:34,
 from
/usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/bits/allocator.h:48,
 from /usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/string:43,
 from
/usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/bits/locale_classes.h:42,
 from
/usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/bits/ios_base.h:43,
 from /usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/ios:43,
 from /usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/ostream:40,
 from
/usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/iostream:40,
 from test08.cpp:1:
/usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/new:93:54: error: ‘operator new’
takes type ‘size_t’ (‘long unsigned int’) as first parameter [-fpermissive]
/usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/new:94:56: error: ‘operator new’
takes type ‘size_t’ (‘long unsigned int’) as first parameter [-fpermissive]
/usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/new:97:62: error: ‘operator new’
takes type ‘size_t’ (‘long unsigned int’) as first parameter [-fpermissive]
/usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/new:98:64: error: ‘operator new’
takes type ‘size_t’ (‘long unsigned int’) as first parameter [-fpermissive]
/usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/new:103:57: error: ‘operator new’
takes type ‘size_t’ (‘long unsigned int’) as first parameter [-fpermissive]
/usr/lib/gcc/i686-pc-cygwin/4.5.3/include/c++/new:104:59: error: ‘operator new’
takes type ‘size_t’ (‘long unsigned int’) as first parameter [-fpermissive]
$ /usr/local/bin/g++ -Wno-system-headers -Wall -Wextra -ansi -pedantic -O6
-fpermissive -time -ftime-report -c -o test08.o test08.ii

Execution times (seconds)
 phase setup :   0.03 ( 0%) usr   0.01 ( 0%) sys   0.06 ( 0%) wall 
   641 kB ( 0%) ggc
 phase parsing   : 384.38 (10%) usr   4.41 ( 2%) sys 390.09 ( 2%) wall 
 48551 kB (12%) ggc
 phase lang. deferred:   0.23 ( 0%) usr   0.06 ( 0%) sys   0.30 ( 0%) wall 
  2462 kB ( 1%) ggc
 phase opt and generate  :3355.32 (90%) usr 241.76 (98%) sys15451.71 (98%) wall
 362698 kB (88%) ggc
 phase last asm  :   0.00 ( 0%) usr   0.01 ( 0%) sys   1.07 ( 0%) wall 
 7 kB ( 0%) ggc
 phase finalize  :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.24 ( 0%) wall 
 0 kB ( 0%) ggc
 |name lookup:   1.21 ( 0%) usr   0.50 ( 0%) sys   1.83 ( 0%) wall 
  1946 kB ( 0%) ggc
 |overload resolution:   1.88 ( 0%) usr   0.50 ( 0%) sys   2.43 ( 0%) wall 
 13196 kB ( 3%) ggc
 garbage collection  :   3.70 ( 0%) usr   3.27 ( 1%) sys 577.45 ( 4%) wall 
 0 kB ( 0%) ggc
 dump files  :   0.04 ( 0%) usr   0.04 ( 0%) sys   0.77 ( 0%) wall 
 0 kB ( 0%) ggc
 callgraph construction  :   0.86 ( 0%) usr   0.15 ( 0%) sys   4.51 ( 0%) wall 
  8014 kB ( 2%) ggc
 callgraph optimization  :   0.85 ( 0%) usr   0.20 ( 0%) sys   2.05 ( 0%) wall 
11 kB ( 0%) ggc
 ipa function summary:   0.27 ( 0%) usr   0.03 ( 0%) sys   0.34 ( 0%) wall 
44 kB ( 0%) ggc
 ipa dead code removal   :   0.06 ( 0%) usr   0.03 ( 0%) sys   0.25 ( 0%) wall 
 0 kB ( 0%) ggc
 ipa virtual call target :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 0%) wall 
 0 kB ( 0%) ggc
 ipa devirtualization:   0.02 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 0%) wall 
 0 kB ( 0%) ggc
 ipa cp  :   0.65 ( 0%) usr   0.12 ( 0%) sys   1.81 ( 0%) wall 
  4870 kB ( 1%) ggc
 ipa inlining heuristics :   1.14 ( 0%) usr   0.03 ( 0%) sys   2.88 ( 0%) wall 
73 kB ( 0%) ggc
 

[Bug fortran/81898] [7/8 Regression] [OOP] Issue with polymorphic container class

[janus at gcc dot gnu.org]

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

--- Comment #4 from janus at gcc dot gnu.org ---
(In reply to janus from comment #3)
> I think the regression has been introduced by r241439, in particular the
> resolve.c part. Reverting it makes the segfault disappear.

Unfortunately reverting that part seems to cause quite a number of regressions
in the testsuite:

FAIL: gfortran.dg/allocate_with_source_16.f90   -O0  (internal compiler error)
FAIL: gfortran.dg/allocate_with_source_6.f90   -O  execution test
FAIL: gfortran.dg/associated_target_4.f90   -O0  execution test
FAIL: gfortran.dg/class_10.f03   -O  (internal compiler error)
FAIL: gfortran.dg/class_array_15.f03   -O0  (internal compiler error)
FAIL: gfortran.dg/coarray_allocate_4.f08   -O0  execution test
FAIL: gfortran.dg/dtio_5.f90   -O0  execution test
FAIL: gfortran.dg/dynamic_dispatch_6.f03   -O0  (internal compiler error)
FAIL: gfortran.dg/interface_32.f90   -O  (internal compiler error)
FAIL: gfortran.dg/pointer_assign_9.f90   -O0  (internal compiler error)
FAIL: gfortran.dg/pointer_assign_11.f90   -O0  (internal compiler error)
FAIL: gfortran.dg/select_type_35.f03   -O0  execution test
FAIL: gfortran.dg/select_type_4.f90   -O0  (internal compiler error)
FAIL: gfortran.dg/typebound_proc_25.f90   -O  (internal compiler error)
FAIL: gfortran.dg/unlimited_polymorphic_22.f90   -O0  execution test
FAIL: gfortran.dg/unlimited_polymorphic_24.f03   -O0  (internal compiler error)
FAIL: gfortran.dg/unlimited_polymorphic_3.f03   -O0  execution test
FAIL: gfortran.dg/prof/dynamic_dispatch_6.f03 compilation,  -fprofile-generate
-D_PROFILE_GENERATE (internal compiler error)

[Bug target/81709] __attribute__((interrupt)) should handle SSE registers

[hjl.tools at gmail dot com]

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

--- Comment #5 from H.J. Lu  ---
(In reply to Anatol from comment #4)
> > you need to save the complete vector state
> 
> It is a good point. Would it make sense for compiler to do it? Instead of
> forcing users to track if SSE registers are used and doing xsave/xrstor
> manually?

To save and restore the complete vector state, you need to do

Check if CPU supports xsave/restore
if yes
  Query CPU for the complete vector state size
  Allocate space on stack for the complete vector state
  xsave
else
  Allocate space on stack for the fxsave area.
  fxsave
endif
...
if CPU supports xsave/restore
  xrstor
else
  fxrstor
endif

I don't believe compiler needs to do all that.

[Bug target/81709] __attribute__((interrupt)) should handle SSE registers

[anatol.pomozov at gmail dot com]

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

--- Comment #4 from Anatol  ---
> you need to save the complete vector state

It is a good point. Would it make sense for compiler to do it? Instead of
forcing users to track if SSE registers are used and doing xsave/xrstor
manually?

[Bug ada/81919] New: Compiler refuses to compile valid code

[porton at narod dot ru]

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

Bug ID: 81919
   Summary: Compiler refuses to compile valid code
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: porton at narod dot ru
  Target Milestone: ---

Created attachment 42023
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42023=edit
A file which does not compile

The compiler refuses to verify the code in attached file.

$ gnatgcc -gnatc -gnat2012 -c my.ads 
my.ads:23:09: type must be declared abstract or "First" overridden
my.ads:23:09: "First" has been inherited from subprogram at a-iteint.ads:26,
instance at line 9

We think that the refusal to compile it is a compiler bug.

Note that if I remove "type Iterated_Object is access all Integer;" and replace
"type Cursor is new Iterated_Object;" with "type Cursor is access all Integer;"
then the compiler does not complaint.

[Bug c++/81918] New: muddles Concept confuses compiler (segfault)

[jesse at mind dot net]

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

Bug ID: 81918
   Summary: muddles Concept confuses compiler (segfault)
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jesse at mind dot net
  Target Milestone: ---

Created attachment 42022
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42022=edit
Triggers segfault

g++ (SUSE Linux) 7.1.1 20170629 [gcc-7-branch revision 249772]

g++ -Wall -Wextra -std=c++17 -fconcepts -o segfault segfault.cpp 

segfault.cpp: In instantiation of ‘main():: [with auto:1
= std::_Fwd_list_iterator]’:
segfault.cpp:9:5:   required from here
segfault.cpp:25:40: internal compiler error: Segmentation fault
  [](const auto& x) { return x; });

A confused Concept appears to also confuse GCC.

[Bug fortran/81898] [7/8 Regression] [OOP] Issue with polymorphic container class

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||vehre at gcc dot gnu.org

--- Comment #3 from janus at gcc dot gnu.org ---
I think the regression has been introduced by r241439, in particular the
resolve.c part. Reverting it makes the segfault disappear.

[Bug c++/80144] Concept introduced with "template" is not diagnosed

[webrown.cpp at gmail dot com]

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

--- Comment #2 from W E Brown  ---
> Confirmed, although I'm not sure which of those 2 options is correct...

Per N4687, [temp.concept]/4:
  A concept shall not have associated constraints (17.4.2).

Since Second's declaration does specify Never as an associated constraint,
Second's declaration appears to be in error.  Any such declarations ought
likely be diagnosed accordingly.

[Bug middle-end/81908] [8 Regression] FAIL: gfortran.dg/alloc_comp_auto_array_2.f90 -O3 -g -m32

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
(In reply to Richard Biener from comment #1)

The code was originally designed for -Walloc-size-larger-than and does the
right thing for that warning.  The range I see is

  _248: ~[1, 2147483647]
  __builtin_memcpy (_251, _259, _248);

leaving 0 as the only valid value less than SIZE_MAX / 2 in ILP32.  Zero is not
really a valid allocation size so the code excludes it.

But the code is also used for -Wstringop-overflow and the same logic doesn't
apply equally well there.  The warning does suggest that the memcpy could be
eliminated, so as in most instances of it, the true root cause is really a
missed optimization opportunity.   In fact, this whole block must be
unreachable because if it were executed it would either attempt to allocate
more than SIZE_MAX / 2 bytes (which would fail) or allocate and write past the
end of the 1-byte block:

   [0.43%] [count: INV]:
  vect_cst__246 = { -1, 265, 1, 1 };
  _247 = ubound.2_35 * 4;
  _248 = (character(kind=4)) _247; // _248
is ~[1, 2147483647]
  _249 = MAX_EXPR <_248, 1>;   // _249
must be 1
  _251 = __builtin_malloc (_249);  // _251
= malloc(1)
  __builtin_memcpy (_251, _259, _248); // no-op
  MEM[(struct grid_index_region *)] = _251;
  MEM[(struct grid_index_region *) + 4B] = { -1, 265, 1, 1 };   //
invalid/write-past-end
  MEM[(struct grid_index_region *) + 20B] = ubound.2_35;//
invalid/write-past-end


(In reply to Richard Biener from comment #1)

get_size_range() sets the RANGE[] array to the unsigned bounds of the range of
sizes.  It can't set RANGE[0] > RANGE[1].  For example, the following must not
be diagnosed but is with the suggested cleanup in comment #2.  There may be a
way to clean up the code but the suggested patch is not sufficient (it causes
test suite regressions).

void __attribute__ ((alloc_size (1))) f (unsigned long);

void g (int n)
{
  if (n < -9 || 9 < n)
n = -9;

  f (n);
}

[Bug c/53037] warn_if_not_aligned(X)

[ebotcazou at gcc dot gnu.org]

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

--- Comment #39 from Eric Botcazou  ---
> i don't quite understand this reasoning, i would
> not expect the internal STRICT_ALIGNMENT setting
> to change how types behave (e.g. it might mean
> some code errors out, but the semantics of packed
> and aligned attributes are not changed).

That's not what I said.  I only described how modes work on strict-alignment
targets: modes have alignment and you cannot have a type with a mode and the
type's alignment be lower than the mode's alignment.

> i don't see this on arm/sparc, instead i see wrong
> alignment given:
> 
> struct __attribute__ ((aligned (8))) S8 { char a[8]; };
> struct __attribute__ ((packed)) S1 { struct S8 s8; };
> 
> char a[_Alignof(struct S8)] = {0};
> char b[_Alignof(struct S1)] = {0};
> 
> compiles into a size 8 array for a and size 1 array for b,
> so _Alignof is inconsistent, which i'd expect to be an
> error (or warning at least).

I don't see any inconsistency here, __attribute__ ((packed)) is expected to
lower the alignment and takes precedence.  Whether or not this is the best
possible implementation is debatable, but it's the historical one.  We might
indeed want to warn about that, but the proposed patch is IMO not correct.

Would this patch be sufficient for:

struct __attribute__ ((aligned (4))) S8 { char a[8]; };
struct __attribute__ ((packed)) S1 { struct S8 s8; };

for example?

[Bug fortran/81898] [7/8 Regression] [OOP] Issue with polymorphic container class

[janus at gcc dot gnu.org]

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

--- Comment #2 from janus at gcc dot gnu.org ---
Comparing the dump that is produced by version 6 and 7, I see that the latter
contains an additional line, just before the type-bound call which produces the
segfault:

   (struct __vtype_amodule_Btype *) a._data->obj._vptr =
&__vtab_amodule_Btype;
+  a._vptr = (struct __vtype_amodule_Atype * {ref-all}) a._data->obj._vptr;
   a._data->bobj = a._data->obj._data;

It seems to come from the pointer assignment, but is certainly wrong (it
effectively sets a's vptr to Btype).

[Bug c++/57078] Unhelpful -Wunused-variable warning

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

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

[Bug c++/57039] -Wsequence-point missing warning for such case

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |WORKSFORME

--- Comment #1 from Eric Gallager  ---
I get a -Wsequence-point warning with gcc8:

$ /usr/local/bin/g++ -c -Wall -Wextra -pedantic -Wsequence-point 57039.cc
57039.cc: In function ‘int main(int, char**)’:
57039.cc:5:5: warning: operation on ‘color’ may be undefined [-Wsequence-point]
 ++color = (color > 3) ? 0 : color;
 ^~~
57039.cc:2:31: warning: unused parameter ‘argv’ [-Wunused-parameter]
 int main(int argc, char* argv[])
   ^
$

Was probably FIXED, but I don't have the computing resources for bisection, so
I'll just say WORKSFORME.

[Bug c++/81178] [concepts] poor (partial?) diagnostic for alias substitution failure in a concept body

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #1 from Eric Gallager  ---
(In reply to Casey Carter from comment #0)
> GCC 6.3/7.1/trunk as of 20170621 all diagnose this ill-formed program
> (https://wandbox.org/permlink/uatmNSnlLbhvSvls):
> 
> template
> concept bool C1 = true;
> 
> template
> using alias = typename T::type;
> 
> template
> concept bool C2 = C1;
> 
> void bar(C2) {}
> 
> int main() { bar(42); }
> 
> with:
> 
> prog.cc: In function 'int main()':
> prog.cc:12:20: error: cannot call function 'void bar(auto:1) [with auto:1 =
> int]'
>  int main() { bar(42); }
> ^
> prog.cc:10:6: note:   constraints not satisfied
>  void bar(C2) {}
>   ^~~
> prog.cc:10:6: note: in the expansion of concept 'C2 template T> concept const bool C2 [with T = int]'
> 
> (Yes, that is the entire diagnostic.)

Confirmed for this first testcase.

> If we expand the definition of C2 fully into bar
> (https://wandbox.org/permlink/GKW0vWSPIY5XrGRE):
> 
> template
>   requires C1
> void bar(T) {}
> 
> the compiler gives a more complete diagnostic:
> 
> prog.cc: In function 'int main()':
> prog.cc:14:20: error: cannot call function 'void bar(T) [with T = int]'
>  int main() { bar(42); }
> ^
> prog.cc:12:6: note:   constraints not satisfied
>  void bar(T) {}
>   ^~~
> prog.cc:12:6: note: invalid use of the concept 'C1'
> prog.cc:14:20: error: 'int' is not a class, struct, or union type
>  int main() { bar(42); }
> ^

...and actually confirmed for this second part, too. (At first I thought it was
a separate standalone testcase, and when compiling it like that it gave me a
different error, but then I noticed it was actually a modification to the first
one, so after modifying the first one accordingly, I got the same result as you
did.)


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
[Bug 67491] [meta-bug] concepts issues

[Bug c++/71138] [concepts] ill-formed non-constant expression use in nested requirement produces duplicated diagnostics with poor source locations

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

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

[Bug c++/70125] attributes diagnostics missing essential context

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-21
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||8.0

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

[Bug c++/80496] missing diagnostic regarding noreturn mismatch in function pointer initialization

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

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

[Bug c++/80144] Concept introduced with "template" is not diagnosed

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #1 from Eric Gallager  ---
(In reply to Arthur O'Dwyer from comment #0)
> Compile this code with GCC trunk and -fconcepts:
> 
> template
> concept bool Never = requires(T t) {
> { t != 42 };
> };
> 
> template concept bool First = Never;
> template concept bool Second = true;
> 
> int main()
> {
> static_assert(!Never);
> static_assert(!First);
> static_assert(!Second);  // static assertion failed
> }
> 
> I claim that the final static_assert should not fail, or else GCC should
> diagnose some kind of syntax error in my concept definitions (perhaps the
> syntax "Never T" is not intended to be supported).

Confirmed, although I'm not sure which of those 2 options is correct...

[Bug c++/79592] incomplete diagnostic "is not usable as a constexpr function because:"

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #1 from Eric Gallager  ---
(In reply to Jonathan Wakely from comment #0)
> struct pthread_mutex {
>   void *m_ptr;
> };
> 
> struct M {
>   pthread_mutex m = { ((void *) 1LL) };
> };
> 
> constexpr M m;
> 
> pt.cc:9:13: error: ‘constexpr M::M()’ called in a constant expression
>  constexpr M m;
>  ^
> pt.cc:5:8: note: ‘constexpr M::M()’ is not usable as a constexpr function
> because:
>  struct M {
> ^
> 
> It just says "because:" without saying what the problem is (the cast is not
> allowed in a constant expression).
> 
> If the expression is (void*)1 rather than (void*)1LL then it is incorrectly
> accepted.

On a 32-bit target, it is always incorrectly accepted; adding -m64 is necessary
to get the incomplete diagnostic:

$ /usr/local/bin/g++ -c -Wall -Wextra -pedantic -std=c++11 79592.cc
$ /usr/local/bin/g++ -c -Wall -Wextra -pedantic -std=c++11 -m64 79592.cc
79592.cc:9:13: error: ‘constexpr M::M()’ called in a constant expression
 constexpr M m;
 ^
79592.cc:5:8: note: ‘constexpr M::M()’ is not usable as a constexpr function
because:
 struct M {
^
$

Confirmed.

[Bug translation/80191] diagnostic placeholder "new initializer" must be marked for translation

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic
 CC||egallager at gcc dot gnu.org
  Component|c++ |translation
   Severity|normal  |minor

--- Comment #7 from Eric Gallager  ---
Changing component to translation, but leaving UNCONFIRMED since there seems to
be disagreement

[Bug fortran/81903] [OOP] problem with ASSOCIATE and class pointer (Invalid character in name at)

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

Summary|compiler reports a language |[OOP] problem with
   |problem (Invalid character  |ASSOCIATE and class pointer
   |in name at) |(Invalid character in name
   ||at)

--- Comment #2 from janus at gcc dot gnu.org ---
Further reduction:

Implicit None
Type :: TestType_A
  Real :: a
End type

class(TestType_A), Pointer :: TT(:)
real, pointer :: a
associate(y => TT)
a => y(0)%a
end associate

end

[Bug translation/79595] Inconsistent grammar in diagnostic "partial specialization %q+D does not specialize"

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Gallager  ---
Confirming and changing component to translation.

[Bug c++/79013] Inconsistent auto diagnostic in member declarations

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords|rejects-valid   |accepts-invalid, diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-21
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Confirmed, although changing from rejects-valid to accepts-invalid since g++
accepts all of the examples without printing any diagnostics.

[Bug c++/78157] Incorrect diagnostic for variable template declaration

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #1 from Eric Gallager  ---
Confirmed, the "got 1 template parameters" message should probably also use
gcc's internationalization routines to handle plurals properly.

[Bug c++/78119] wrong diagnostic pointer for -Werror=ignored-qualifiers

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #1 from Eric Gallager  ---
Could you provide a more complete testcase please?

[Bug c/53037] warn_if_not_aligned(X)

[nsz at gcc dot gnu.org]

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

nsz at gcc dot gnu.org changed:

   What|Removed |Added

 CC||nsz at gcc dot gnu.org

--- Comment #38 from nsz at gcc dot gnu.org ---
(In reply to Eric Botcazou from comment #32)
> > Sparc defines STRICT_ALIGNMENT which leads to
> > 
> >   unsigned mode_align = GET_MODE_ALIGNMENT (TYPE_MODE (type));
> > 
> >   /* Don't override a larger alignment requirement coming from a user
> >  alignment of one of the fields.  */
> >   if (mode_align >= TYPE_ALIGN (type))
> > {
> >   SET_TYPE_ALIGN (type, mode_align);
> >   TYPE_USER_ALIGN (type) = 0; 
> > }
> > 
> > so __attribute__ ((packed)) is basically ignored on Sparc.
> 
> I don't think that's correct.  Simply, on strict-alignment targets, you
> cannot have an aggregate type less aligned than its scalar mode, if any; for
> other targets, that's only true for scalar types.  But you can have an
> aggregate type with alignment 1 if it has BLKmode.
> 

i don't quite understand this reasoning, i would
not expect the internal STRICT_ALIGNMENT setting
to change how types behave (e.g. it might mean
some code errors out, but the semantics of packed
and aligned attributes are not changed).

> > diff --git a/gcc/stor-layout.c b/gcc/stor-layout.c
> > index 3028d55773a..6dd605810ac 100644
> > --- a/gcc/stor-layout.c
> > +++ b/gcc/stor-layout.c
> > @@ -1784,7 +1784,7 @@ finalize_type_size (tree type)
> >  
> >/* Don't override a larger alignment requirement coming from a user
> > alignment of one of the fields.  */
> > -  if (mode_align >= TYPE_ALIGN (type))
> > +  if (mode_align > TYPE_ALIGN (type))
> >{
> >  SET_TYPE_ALIGN (type, mode_align);
> >  TYPE_USER_ALIGN (type) = 0;
> > 
> > works with cross compiler.
> 
> The existing code works as intended: if the alignment given by the mode is
> larger than or equal to the type's alignment, then this alignment given by
> the mode becomes the natural alignment and TYPE_USER_ALIGN becomes
> obsolete/wrong.
> 

i don't see this on arm/sparc, instead i see wrong
alignment given:

struct __attribute__ ((aligned (8))) S8 { char a[8]; };
struct __attribute__ ((packed)) S1 { struct S8 s8; };

char a[_Alignof(struct S8)] = {0};
char b[_Alignof(struct S1)] = {0};

compiles into a size 8 array for a and size 1 array for b,
so _Alignof is inconsistent, which i'd expect to be an
error (or warning at least).

> So I think that the absence of warning is correct on strict-alignment
> platforms and that, if you want to make the tests portable, then you must
> use structures whose rounded size is not a power of 2 or is larger than 128
> bits, so that they don't get a scalar mode.

[Bug c++/77540] Confusing diagnostics due to stray comma in ctor-init-list

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

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

[Bug c++/66924] Bad diagnostic for parameter name used as non-type template argument

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

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

$ /usr/local/bin/g++ -c -Wall -Wextra -pedantic 66924.cc
66924.cc: In function ‘int main()’:
66924.cc:5:37: error: parse error in template argument list
 auto f = [] (int x) -> decltype(variable) {return{};};
 ^~~
66924.cc:5:37: error: template argument 1 is invalid
66924.cc: In lambda function:
66924.cc:5:22: warning: unused parameter ‘x’ [-Wunused-parameter]
 auto f = [] (int x) -> decltype(variable) {return{};};
  ^
$

[Bug c++/60095] Dubious diagnostics for attempted surrogate call function

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #3 from Eric Gallager  ---
(In reply to lucdanton from comment #0)
> Using ‘gcc version 4.9.0 20140123 (experimental) (GCC)’ with the following
> snippet:
> 
> //
> 
> struct foo {
> typedef void(*ptr)(int&);
> operator ptr() const;
> };
> 
> int main()
> {
> foo f;
> void* p = 0;
> f(p);
> }
> 
> //
> 
> $ g++-trunk -std=c++03 main.cpp 
> main.cpp: In function 'int main()':
> main.cpp:10:8: error: no match for call to '(foo) (void*&)'
>  f(p);
> ^
> main.cpp:1:8: note: candidate is:
>  struct foo {
> ^
> main.cpp:10:8: note: foo::ptr {aka void (*)(int&)} 
>  f(p);
> ^
> main.cpp:10:8: note:   candidate expects 2 arguments, 2 provided
> 
> Same output for all -std=c++{03,11,1y} modes. If e.g. foo has a call
> operator instead, then the appropriate ‘no known conversion for argument 1
> from 'void*' to 'int&'’ is produced.

Message is now:

$ /usr/local/bin/g++ -c -std=c++03 -Wall -Wextra -pedantic 60095.cc
60095.cc: In function ‘int main()’:
60095.cc:10:8: error: no match for call to ‘(foo) (void*&)’
 f(p);
^
60095.cc:10:8: note: candidate: ‘foo::ptr {aka void (*)(int&)}’ 
60095.cc:10:8: note:   conversion of argument 2 would be ill-formed:
60095.cc:10:8: error: invalid conversion from ‘void*’ to ‘int’ [-fpermissive]
60095.cc:10:8: error: cannot bind rvalue ‘(int)p’ to ‘int&’
$

Is that better enough for you? I think it's still kinda confusing, but at least
there's no longer the bogus "expects 2 arguments, 2 provided" note anymore.

[Bug c++/81917] internal compiler error: in finish_member_declaration, at cp/semantics.c:3004

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
I couldn't reduce it further because creduce is crashing for me.  

Started with

commit 996ae1f4f1d512b4ccad62c7d52eb2f14b3e814c
Author: jason 
Date:   Sat Nov 8 06:06:42 2014 +

DR 1558
* pt.c (dependent_alias_template_spec_p): New.
(dependent_type_p_r): Handle dependent alias template
specialization.
(template_args_equal): A dependent alias template specializations
is not equal to its underlying type as a template argument.
* tree.c (strip_typedefs): Don't strip a dependent alias
template-id.

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

[Bug c++/81917] internal compiler error: in finish_member_declaration, at cp/semantics.c:3004

[mpolacek at gcc dot gnu.org]

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

--- Comment #1 from Marek Polacek  ---
Created attachment 42021
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42021=edit
q.ii.gz

q.ii.gz

[Bug c++/71007] Divergence between treatment of char[0] between OR (=> SFINAE failure) and diagnostic printing (no failure)

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||compile-time-hog,
   ||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-21
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Eric Gallager  ---
(In reply to Johannes Schaub from comment #0)
> The following is supposed to tell the user that char[0] is an invalid type,
> during diagnostic printing. But instead, it infinitely recurses up to
> SIZE_MAX or something during printing the diagnostic message, eventually
> crashing
> 
>#include 
>#include 
> 
>template
>auto ignore_n(std::integer_sequence) {
> return std::make_tuple((I, std::ignore)...);
>}
> 
>template
>auto function(Ts... ts)
>   -> decltype((std::tuple_cat(
>
> ignore_n(std::make_index_sequence  
> ()),
> std::tuple()) = std::forward_as_tuple(ts...)),
> void())
>{
>
>}
> 
>int main() {
>   function(2);
>   function(1, 2, 3);
>}
> 

This un-reduced version was taking forever to compile, so I had to kill it
before it could crash:

$ /usr/local/bin/g++ -c -Wall -Wextra -pedantic -time -ftime-report 71007.cc
71007.cc: In function ‘int main()’:
71007.cc:19:12: error: no matching function for call to ‘function(int)’
  function(2);
^
71007.cc:10:6: note: candidate: ‘template decltype
((std::tuple_cat(ignore_n(typename std::_Make_integer_sequence::__type>::make_index_sequence()), std::tuple())=
std::forward_as_tuple(function::ts ...), void())) function(Ts ...)’
 auto function(Ts... ts)
  ^~~~
71007.cc:10:6: note:   template argument deduction/substitution failed:
71007.cc: In substitution of ‘template decltype
((std::tuple_cat(ignore_n(typename std::_Make_integer_sequence::__type>::make_index_sequence()), std::tuple())=
std::forward_as_tuple(function::ts ...), void())) function(Ts ...) [with Ts =
{int}]’:
71007.cc:19:12:   required from here
71007.cc:12:42: warning: ISO C++ forbids zero-size array [-Wpedantic]
ignore_n(std::make_index_sequence
  ()),
  ^~
^C
$

(In reply to Johannes Schaub from comment #1)
> Sorry, forgot to actually add the code of the reduced testcase:
> 
>template
>void f(char(&)[N])
>{ }
> 
>int main() {
>   char x[1];
>   f(x);
>}

Confirmed:

$ /usr/local/bin/g++ -c -Wall -Wextra -pedantic 71007_reduced.cc
71007_reduced.cc: In function ‘int main()’:
71007_reduced.cc:7:4: error: no matching function for call to ‘f(char [1])’
 f(x);
^
71007_reduced.cc:2:6: note: candidate: ‘template void f(char
(&)[N])’
 void f(char(&)[N])
  ^
71007_reduced.cc:2:6: note:   template argument deduction/substitution failed:
71007_reduced.cc:1:17: warning: ISO C++ forbids zero-size array [-Wpedantic]
 template
 ^~~~
$

Weird that the underlining here points to the typename before T rather than the
actual array size.

[Bug c++/81917] New: internal compiler error: in finish_member_declaration, at cp/semantics.c:3004

[mpolacek at gcc dot gnu.org]

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

Bug ID: 81917
   Summary: internal compiler error: in finish_member_declaration,
at cp/semantics.c:3004
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

The attached preprocessed source file ICEs with:

internal compiler error: in finish_member_declaration, at cp/semantics.c:3004
0xa45741 finish_member_declaration(tree_node*)
/home/marek/src/gcc/gcc/cp/semantics.c:3004
0x9d442e instantiate_class_template_1
/home/marek/src/gcc/gcc/cp/pt.c:10675
0x9d4fae instantiate_class_template(tree_node*)
/home/marek/src/gcc/gcc/cp/pt.c:10892
0xa8e08e complete_type(tree_node*)
/home/marek/src/gcc/gcc/cp/typeck.c:136
0x9e42dc tsubst(tree_node*, tree_node*, int, tree_node*)
/home/marek/src/gcc/gcc/cp/pt.c:14042
0x9d501e tsubst_template_arg
/home/marek/src/gcc/gcc/cp/pt.c:10905
0x9d8267 tsubst_template_args
/home/marek/src/gcc/gcc/cp/pt.c:11778
0x9d8efe tsubst_aggr_type
/home/marek/src/gcc/gcc/cp/pt.c:11980
0x9e1b5b tsubst(tree_node*, tree_node*, int, tree_node*)
/home/marek/src/gcc/gcc/cp/pt.c:13472
0x9df347 tsubst_decl
/home/marek/src/gcc/gcc/cp/pt.c:12884
0x9e120b tsubst(tree_node*, tree_node*, int, tree_node*)
/home/marek/src/gcc/gcc/cp/pt.c:13389
0x9d416f instantiate_class_template_1
/home/marek/src/gcc/gcc/cp/pt.c:10608
0x9d4fae instantiate_class_template(tree_node*)
/home/marek/src/gcc/gcc/cp/pt.c:10892
0xa8e08e complete_type(tree_node*)
/home/marek/src/gcc/gcc/cp/typeck.c:136
0x9e42dc tsubst(tree_node*, tree_node*, int, tree_node*)
/home/marek/src/gcc/gcc/cp/pt.c:14042
0x9df347 tsubst_decl
/home/marek/src/gcc/gcc/cp/pt.c:12884
0x9e120b tsubst(tree_node*, tree_node*, int, tree_node*)
/home/marek/src/gcc/gcc/cp/pt.c:13389
0x9d416f instantiate_class_template_1
/home/marek/src/gcc/gcc/cp/pt.c:10608
0x9d4fae instantiate_class_template(tree_node*)
/home/marek/src/gcc/gcc/cp/pt.c:10892
0xa8e08e complete_type(tree_node*)
/home/marek/src/gcc/gcc/cp/typeck.c:136
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug middle-end/81914] [7/8 Regression] gcc 7.1 generates branch for code which was branchless in earlier gcc version

[bugzi...@poradnik-webmastera.com]

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

--- Comment #3 from Daniel Fruzynski  ---
Yes, branchless version is faster. Here are results for code compiled with gcc
4.8.5:

BenchmarkTime   CPU Iterations
--
BM_memcmp6 ns  6 ns  111001949
BM_int64cmp  4 ns  4 ns  183761752

And here for gcc 7.1.0:

BenchmarkTime   CPU Iterations
--
BM_memcmp6 ns  6 ns  113198940
BM_int64cmp  8 ns  8 ns   82036754

Note: Code tested accepted values passed via pointer instead of value, to
better compare it with memcmp function. Functions were comparing random values,
generated before tests and stored in arrays. srand was called with constant
value to get repeatable results.

[Bug c++/67928] Ambiguous call not diagnosed

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

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

$ /usr/local/bin/g++ -c -Wall -Wextra -pedantic -O2 -std=c++14 67928.cc
67928.cc: In instantiation of ‘void print(const T&, const types& ...) [with T =
test; types = {int}; unsigned int U = 8]’:
67928.cc:20:21:   required from here
67928.cc:7:22: warning: unused parameter ‘arg1’ [-Wunused-parameter]
 void print( const T& arg1, const types&... args ) {
  ^~~~
67928.cc: In instantiation of ‘void print(const T&, const types& ...) [with T =
int; types = {}]’:
67928.cc:8:6:   required from ‘void print(const T&, const types& ...) [with T =
test; types = {int}; unsigned int U = 8]’
67928.cc:20:21:   required from here
67928.cc:12:22: warning: unused parameter ‘arg1’ [-Wunused-parameter]
 void print( const T& arg1, const types&... args ) {
  ^~~~
$ /sw/opt/llvm-3.1/bin/clang++ -c -Wall -Wextra -pedantic -O2 -std=c++11
67928.cc
67928.cc:7:22: warning: unused parameter 'arg1' [-Wunused-parameter]
void print( const T& arg1, const types&... args ) {
 ^
67928.cc:12:22: warning: unused parameter 'arg1' [-Wunused-parameter]
void print( const T& arg1, const types&... args ) {
 ^
67928.cc:20:4: error: call to 'print' is ambiguous
print( test{}, 1 );
^
67928.cc:7:6: note: candidate function [with T = test, types = , U = 8]
void print( const T& arg1, const types&... args ) {
 ^
67928.cc:12:6: note: candidate function [with T = test, types = ]
void print( const T& arg1, const types&... args ) {
 ^
2 warnings and 1 error generated.
$

[Bug c++/69103] Misleading diagnostic for invalid constexpr initialization

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Gallager  ---
(In reply to TC from comment #0)
> Consider:
> 
> static int i;
> static int* temp = 
> static constexpr int *& = static_cast(temp) + 1;
> 
> This correctly doesn't compile, but produces the misleading error message
> 
> prog.cc:3:57: error: modification of '_ZGRL1r0' is not a constant-expression
>  static constexpr int *& = static_cast(temp) + 1;
>  ^

The '_ZGRL1r0' is now '':

$ /usr/local/bin/g++ -c -Wall -Wextra -pedantic 69103.cc
69103.cc:3:57: error: modification of ‘’ is not a constant
expression
 static constexpr int *& = static_cast(temp) + 1;
 ^
$

(In reply to Mikhail Maltsev from comment #1)
> Link to the original thread, for the record:
> https://groups.google.com/a/isocpp.org/forum/#!topic/std-discussion/
> WS5pLaXwC8Y
> 
> _ZGRL1r0 demangles as "reference temporary #0 for r"

Confirmed that demangling it like that would still be better though.

(In reply to TC from comment #0)
> 
> We aren't modifying anything in the initializer.
> 
> In contrast, Clang produces:
> 
> prog.cc:3:25: error: constexpr variable 'r' must be initialized by a
> constant expression
> static constexpr int *& = static_cast(temp) + 1;
> ^   ~
> prog.cc:3:29: note: read of non-constexpr variable 'temp' is not allowed in
> a constant expression
> static constexpr int *& = static_cast(temp) + 1;
> ^
> prog.cc:2:13: note: declared here
> static int* temp = 

...and of course doing like clang here would be the best.

[Bug go/81893] [8 regression] compilation error in libgo starting with r251127

[seurer at gcc dot gnu.org]

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

--- Comment #6 from seurer at gcc dot gnu.org ---
Yes, it looks good now.  Thanks!

[Bug middle-end/81916] New: expansion of rint/nearbyint can simplified under -fno-signed-zeros

[amonakov at gcc dot gnu.org]

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

Bug ID: 81916
   Summary: expansion of rint/nearbyint can simplified under
-fno-signed-zeros
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amonakov at gcc dot gnu.org
  Target Milestone: ---

When -fno-signed-zeros is enabled, rint/nearbyint do not need to produce
negative zeros as appropriate, and if -fno-rounding-math [+ -fno-trapping-math
for rint] are also enabled, GCC can use a two-operation expansion 'x + 1.5p52 -
1.5p52'.

[Bug c++/68301] self-dependent reference member initialization not diagnosed

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-21
 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=2972,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=19808
 Ever confirmed|0   |1

--- Comment #2 from Eric Gallager  ---
(In reply to Martin Sebor from comment #1)
> This seems related to bug 2972 or bug 19808 and probably falls under the
> Wuninitialized alias.

Confirming as related to but separate from those bugs.

[Bug target/46091] missed optimization: x86 bt/btc/bts instructions

[uros at gcc dot gnu.org]

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

--- Comment #4 from uros at gcc dot gnu.org ---
Author: uros
Date: Mon Aug 21 15:15:07 2017
New Revision: 251235

URL: https://gcc.gnu.org/viewcvs?rev=251235=gcc=rev
Log:
PR target/46091
* config/i386/i386.md (*btsq_imm): Rename from *btsq.
(*btrq_imm): Rename from *btrq.
(*btcq_imm): Rename from *btcq.
(btsc): New code attribute.
(*): New insn pattern.
(*btr): Ditto.
(*_mask): New insn_and_split pattern.
(*btr_mask): Ditto.

testsuite/ChangeLog:

PR target/46091
* gcc.target/i386/pr46091-4.c: New test.
* gcc.target/i386/pr46091-4a.c: Ditto.
* gcc.target/i386/pr46091-5.c: Ditto.
* gcc.target/i386/pr46091-5a.c: Ditto.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr46091-4.c
trunk/gcc/testsuite/gcc.target/i386/pr46091-4a.c
trunk/gcc/testsuite/gcc.target/i386/pr46091-5.c
trunk/gcc/testsuite/gcc.target/i386/pr46091-5a.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/81912] std::distance not constexpr in C++17 mode

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Mon Aug 21 15:14:27 2017
New Revision: 251234

URL: https://gcc.gnu.org/viewcvs?rev=251234=gcc=rev
Log:
PR libstdc++/81912 make std::__iterator_category constexpr

PR libstdc++/81912
* include/bits/stl_iterator_base_types.h (__iterator_category): Add
constexpr for C++11 and later.
* testsuite/24_iterators/container_access.cc: Add target selector.
* testsuite/24_iterators/range_access.cc: Fix clause number in
comment.
* testsuite/24_iterators/range_access_cpp14.cc: Likewise.
* testsuite/24_iterators/range_access_cpp17.cc: New.

Added:
trunk/libstdc++-v3/testsuite/24_iterators/range_access_cpp17.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/stl_iterator_base_types.h
trunk/libstdc++-v3/testsuite/24_iterators/container_access.cc
trunk/libstdc++-v3/testsuite/24_iterators/range_access.cc
trunk/libstdc++-v3/testsuite/24_iterators/range_access_cpp14.cc

[Bug c++/66968] Incorrect template argument shown in diagnostic

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-21
 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=99
 Ever confirmed|0   |1

--- Comment #3 from Eric Gallager  ---
Confirming as a separate bug from bug 99, but still adding it to "See Also"
though.

[Bug c++/63374] unhelpful diagnostics for missing initializer

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #1 from Eric Gallager  ---
Confirmed, the output I get is:

$ /usr/local/bin/g++ -c -Wall -Wextra -pedantic -Wmissing-field-initializers
-Weffc++ 63374.cc
63374.cc: In constructor ‘A::A(int)’:
63374.cc:16:2: warning: ‘A::a1’ should be initialized in the member
initialization list [-Weffc++]
  A(int x) : b1(x), b2(x), b3(x), b4(x) {}
  ^
63374.cc:16:2: warning: ‘A::a2’ should be initialized in the member
initialization list [-Weffc++]
63374.cc:16:2: warning: ‘A::a4’ should be initialized in the member
initialization list [-Weffc++]
63374.cc:16:38: error: no matching function for call to ‘B::B()’
  A(int x) : b1(x), b2(x), b3(x), b4(x) {}
  ^
63374.cc:3:2: note: candidate: ‘B::B(int)’
  B(int x) : z(x) {}
  ^
63374.cc:3:2: note:   candidate expects 1 argument, 0 provided
63374.cc:1:7: note: candidate: ‘constexpr B::B(const B&)’
 class B {
   ^
63374.cc:1:7: note:   candidate expects 1 argument, 0 provided
63374.cc:1:7: note: candidate: ‘constexpr B::B(B&&)’
63374.cc:1:7: note:   candidate expects 1 argument, 0 provided
$

[Bug c++/60917] sub-optimal diagnostic when instantiating template

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

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

[Bug target/81906] [7/8 Regression] Calls to rint() wrongly optimized away starting in g++ 6

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #12 from Alexander Monakov  ---
[my comment collided with Joseph's, I'm pointing out that one additional
copysign is sufficient under -frounding-math)

I think this expansion works as intended for to-nearest and towards-zero
rounding modes, and swaps upwards and downwards rounding for negative operands.
Which implies that under -frounding-math the approach is fixable by swapping
signs of the 2**52 operands:

  xa = fabs (operand1);
  a2_52 = 2**52;
  [if flag_rounding_math]
a2_52 = copysign (a2_52, operand1);
  xa = xa + a2_52 - a2_52;
  return copysign (xa, operand1);

[Bug c++/55588] Failure to diagnose non-template-id prefixed by keyword template

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

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

[Bug c++/81836] ill-formed qualified name not diagnosed

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #1 from Eric Gallager  ---
Confirmed, clang's message is:

$ /usr/local/bin/g++ -c -Wall -Wextra -pedantic 81836.cc
$ /sw/opt/llvm-3.1/bin/clang++ -c -Wall -Wextra -pedantic 81836.cc
81836.cc:8:1: error: expected a class or namespace
foo ::Foo::g() { return 1; }
^
81836.cc:8:12: error: C++ requires a type specifier for all declarations
foo ::Foo::g() { return 1; }
~~~^
2 errors generated.
$

[Bug c++/57170] No diagnostic for a negative case when switching over unsigned

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #1 from Eric Gallager  ---
Use -Wsign-conversion to get a warning:

$ /usr/local/bin/gcc -c -Wall -Wextra -Wconversion -Wnarrowing -pedantic
-Wswitch -Wsign-promo -Wtype-limits -Wsign-conversion -std=c++98 57170.cc
57170.cc: In function ‘int main()’:
57170.cc:4:3: warning: unsigned conversion from ‘int’ to ‘unsigned int’ changes
value from ‘-1’ to ‘4294967295’ [-Wsign-conversion]
   case -1:
   ^~~~
$

-Wsign-conversion has to be specified explicitly in c++, but in plain c, it's
implied by -Wconversion:

$ /usr/local/bin/gcc -c -x c -Wall -Wextra -Wconversion -pedantic -Wswitch
-Wtype-limits 57170.cc
57170.cc: In function ‘main’:
57170.cc:4:3: warning: unsigned conversion from ‘int’ to ‘unsigned int’ changes
value from ‘-1’ to ‘4294967295’ [-Wsign-conversion]
   case -1:
   ^~~~
$

[Bug target/81906] [7/8 Regression] Calls to rint() wrongly optimized away starting in g++ 6

[joseph at codesourcery dot com]

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

--- Comment #11 from joseph at codesourcery dot com  ---
(That's essentially what the generic C implementation of rint in glibc 
does.  I make no assertions about whether inlining this long expansion of 
rint for SSE, or even the shorter -fno-rounding-math version, actually 
makes sense.)

[Bug target/81906] [7/8 Regression] Calls to rint() wrongly optimized away starting in g++ 6

[joseph at codesourcery dot com]

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

--- Comment #10 from joseph at codesourcery dot com  ---
A correct (for -frounding-math) SSE sequence would (for arguments with 
absolute value < 2**52) add and subtract 2**52 for a positive operand, 
-2**52 for a negative operand.  Then it would need to copy the sign of the 
original operand to the result to ensure zero results get the correct sign 
in all cases.

[Bug c++/56951] Poor diagnostics for error: invalid abstract return type 'XXX'

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

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

[Bug c++/56272] Poor diagnostics for error: specialization of ... after instantiation

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #1 from Eric Gallager  ---
With a caret, that is:

$ /usr/local/bin/g++ -c -Wall -Wextra -pedantic 56272.cc
56272.cc:11:40: error: specialization of ‘void A::Invert() [with T =
double]’ after instantiation
 template <> void A < double >::Invert ();
^
56272.cc: In instantiation of ‘void A::Invert() [with T = double]’:
56272.cc:9:16:   required from here
56272.cc:5:16: warning: unused variable ‘a’ [-Wunused-variable]
A < double >a;
^
$

Confirmed that it could use an extra note.

[Bug middle-end/64928] [5/6/7/8 Regression] Inordinate cpu time and memory usage in "phase opt and generate" with -ftest-coverage -fprofile-arcs

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed|2015-02-09 00:00:00 |2017-8-21

--- Comment #24 from Richard Biener  ---
I think we made LIM more powerful and/or changed coalescing.  We didn't really
address the issue with LIMs lack of a costmodel or out-of-SSA coalescing being
quadratic in size requirement (but I see RTL passes bumping up to 5GB of memory
use as well, REE for example, also noted elsewhere).

[Bug c++/55809] Doesn't differentiate elaborated type specifier and typename specifier in dependent types

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

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

[Bug c++/81899] [8 Regression] ICE: Segmentation fault

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #3 from Nathan Sidwell  ---
Fixed in 251226

[Bug c++/81899] [8 Regression] ICE: Segmentation fault

[nathan at gcc dot gnu.org]

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

--- Comment #2 from Nathan Sidwell  ---
Author: nathan
Date: Mon Aug 21 13:29:20 2017
New Revision: 251227

URL: https://gcc.gnu.org/viewcvs?rev=251227=gcc=rev
Log:
PR c++/81899
* pt.c (instantiate_class_template_1):
BOUND_TEMPLATE_TEMPLATE_PARM is never friend-injected.

PR c++/81899
* g++.dg/template/pr81899.C: New.

Added:
trunk/gcc/testsuite/g++.dg/template/pr81899.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/81900] [8 Regression] GCC trunk miscompiles Perl / __sigsetjmp issue

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
Author: rguenth
Date: Mon Aug 21 13:18:35 2017
New Revision: 251226

URL: https://gcc.gnu.org/viewcvs?rev=251226=gcc=rev
Log:
2017-08-21  Richard Biener  

PR tree-optimization/81900
* tree-ssa-pre.c (compute_antic_aux): Properly compute changed
for blocks with abnormal predecessors.
(compute_antic): Do not set visited flag prematurely.

* gcc.dg/torture/pr81900.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr81900.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-pre.c

[Bug tree-optimization/81900] [8 Regression] GCC trunk miscompiles Perl / __sigsetjmp issue

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug target/79883] avr i18n: untranslated "interrupt" or "signal"

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

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

--- Comment #15 from Georg-Johann Lay  ---
#

[Bug target/79883] avr i18n: untranslated "interrupt" or "signal"

[gjl at gcc dot gnu.org]

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

--- Comment #14 from Georg-Johann Lay  ---
Author: gjl
Date: Mon Aug 21 12:44:23 2017
New Revision: 251225

URL: https://gcc.gnu.org/viewcvs?rev=251225=gcc=rev
Log:
PR target/79883
* config/avr/avr.c (avr_set_current_function): Typo in diagnostic.

Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/avr/avr.c

[Bug target/79883] avr i18n: untranslated "interrupt" or "signal"

[gjl at gcc dot gnu.org]

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

--- Comment #13 from Georg-Johann Lay  ---
Author: gjl
Date: Mon Aug 21 12:42:47 2017
New Revision: 251224

URL: https://gcc.gnu.org/viewcvs?rev=251224=gcc=rev
Log:
PR target/79883
* config/avr/avr.c (avr_set_current_function): Typo in diagnostic.

Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/avr/avr.c

[Bug target/79883] avr i18n: untranslated "interrupt" or "signal"

[gjl at gcc dot gnu.org]

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

--- Comment #12 from Georg-Johann Lay  ---
Author: gjl
Date: Mon Aug 21 12:39:59 2017
New Revision: 251223

URL: https://gcc.gnu.org/viewcvs?rev=251223=gcc=rev
Log:
PR target/79883
* config/avr/avr.c (avr_set_current_function): Typo in diagnostic.

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

[Bug middle-end/81914] [7/8 Regression] gcc 7.1 generates branch for code which was branchless in earlier gcc version

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*, i?86-*-*
   Target Milestone|--- |7.3

--- Comment #2 from Richard Biener  ---
But are you sure the branchless variant is faster?

[Bug c/53037] warn_if_not_aligned(X)

[hjl.tools at gmail dot com]

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

--- Comment #37 from H.J. Lu  ---
(In reply to Andreas Schwab from comment #35)
> On m68k:
> 
> FAIL: gcc.dg/pr53037-1.c  (test for warnings, line 42)
> FAIL: gcc.dg/pr53037-1.c  (test for warnings, line 75)
> FAIL: gcc.dg/pr53037-1.c (test for excess errors)
> Excess errors:
> /daten/aranym/gcc/gcc-20170821/gcc/testsuite/gcc.dg/pr53037-1.c:42:1:
> warning: alignment 2 of 'struct foo5' is less than 16 [-Wif-not-aligned]
> /daten/aranym/gcc/gcc-20170821/gcc/testsuite/gcc.dg/pr53037-1.c:75:1:
> warning: alignment 2 of 'union bar3' is less than 16 [-Wif-not-aligned]
> 
> FAIL: g++.dg/pr53037-1.C  -std=gnu++98  (test for warnings, line 38)
> FAIL: g++.dg/pr53037-1.C  -std=gnu++98  (test for warnings, line 71)
> FAIL: g++.dg/pr53037-1.C  -std=gnu++98 (test for excess errors)
> Excess errors:
> /daten/aranym/gcc/gcc-20170821/gcc/testsuite/g++.dg/pr53037-1.C:38:8:
> warning: alignment 2 of 'foo5' is less than 16 [-Wif-not-aligned]
> /daten/aranym/gcc/gcc-20170821/gcc/testsuite/g++.dg/pr53037-1.C:71:7:
> warning: alignment 2 of 'bar3' is less than 16 [-Wif-not-aligned]

A patch is posted at

https://gcc.gnu.org/ml/gcc-patches/2017-08/msg01193.html

[Bug c/53037] warn_if_not_aligned(X)

[hjl.tools at gmail dot com]

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

--- Comment #36 from H.J. Lu  ---
(In reply to Andreas Schwab from comment #34)
> On ia64:
> 
> FAIL: g++.dg/pr53037-4.C  -std=gnu++11 (test for excess errors)
> Excess errors:
> /usr/local/gcc/gcc-20170821/gcc/testsuite/g++.dg/pr53037-4.C:9:1: error:
> alignment for 'void foo2()' must be at least 16

A patch is posted at

https://gcc.gnu.org/ml/gcc-patches/2017-08/msg01192.html

[Bug target/81915] bug with thread_local inline variables

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Target||*-*-cygwin
  Component|c++ |target

--- Comment #2 from Jonathan Wakely  ---
Yes, this works OK on GNU/Linux.

[Bug tree-optimization/81900] [8 Regression] GCC trunk miscompiles Perl / __sigsetjmp issue

[pipcet at gmail dot com]

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

--- Comment #7 from pipcet at gmail dot com ---
I can confirm that fixes things here, thank you!

[Bug c++/81915] bug with thread_local inline variables

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

--- Comment #1 from Markus Trippelsdorf  ---
Must be a target issue. What target are you on?

[Bug middle-end/81914] [7/8 Regression] gcc 7.1 generates branch for code which was branchless in earlier gcc version

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-21
 CC||mpolacek at gcc dot gnu.org
  Component|c   |middle-end
Summary|gcc 7.1 generates branch|[7/8 Regression] gcc 7.1
   |for code which was  |generates branch for code
   |branchless in earlier gcc   |which was branchless in
   |version |earlier gcc version
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Started with r237185.

[Bug target/67317] [x86] Silly code generation for _addcarry_u32/_addcarry_u64

[noloader at gmail dot com]

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

Jeffrey Walton  changed:

   What|Removed |Added

 CC||noloader at gmail dot com

--- Comment #10 from Jeffrey Walton  ---
I'm not sure why Bugzilla did not return this result when I searched for the
instructions earlier. Adding search terms that might help others find this:

ADCX
adcx
ADOX
adox

[Bug c++/81915] New: bug with thread_local inline variables

[nico at josuttis dot de]

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

Bug ID: 81915
   Summary: bug with thread_local inline variables
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nico at josuttis dot de
  Target Milestone: ---

Consider:

inlinetls.hpp:
  #include 
  inline thread_local std::string tlsString = "hello";

inlinetls1.cpp:
  #include "inlinetls.hpp"
  int main()
  {
  }

inlinetls2.cpp:
  #include "inlinetls.hpp"

IMO, this is valid code since C++17 having a thread-local tlsString.

But I get:
> /cygdrive/p/gcc/gcc72/bin/g++72 --std=c++17 -O2 --pedantic --pedantic-errors 
> -Wall -Wextra -Wnon-virtual-dtor -Wconversion inlinetls1.cpp inlinetls2.cpp 
> -latomic -o inlinetlsraw17.exe
> /cygdrive/c/Users/nico/AppData/Local/Temp/ccyiFSQ3.o:inlinetls2.cpp:(.text+0x0):
>  multiple definition of `TLS init function for tlsString[abi:cxx11]'
> /cygdrive/c/Users/nico/AppData/Local/Temp/cc5mSIJv.o:inlinetls1.cpp:(.text+0x0):
>  first defined here
> collect2: error: ld returned 1 exit status

[Bug c/81914] New: gcc 7.1 generates branch for code which was branchless in earlier gcc version

[bugzi...@poradnik-webmastera.com]

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

Bug ID: 81914
   Summary: gcc 7.1 generates branch for code which was branchless
in earlier gcc version
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bugzi...@poradnik-webmastera.com
  Target Milestone: ---

Code:

#include 

int cmp(int64_t a, int64_t b)
{
return a < b ? -1 : a > b;
}

Above function compiled with gcc 4.5 or above and -O2 is compiled in following
way. It is branchless:

cmp(long, long):
  xor eax, eax
  cmp rdi, rsi
  mov edx, -1
  setg al
  cmovl eax, edx
  ret

gcc 7.1 generates different code. It has branch:

cmp(long, long):
  cmp rdi, rsi
  jl .L3
  setg al
  movzx eax, al
  ret
.L3:
  mov eax, -1
  ret

[Bug tree-optimization/81913] [8 Regression] wrong code at -O1

[amker at gcc dot gnu.org]

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

--- Comment #5 from amker at gcc dot gnu.org ---
(In reply to Martin Liška from comment #4)
> Started with r249778.

Looks like overflow handling.  Thanks for bisecting.

[Bug tree-optimization/81913] [8 Regression] wrong code at -O1

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #4 from Martin Liška  ---
Started with r249778.

[Bug tree-optimization/81913] [8 Regression] wrong code at -O1

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from amker at gcc dot gnu.org ---
Thanks for reporting, I will investigate this.

[Bug tree-optimization/81913] [8 Regression] wrong code at -O1

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
It's SCEV const-prop aka final value replacement (and thus likely niter
analysis):

Analyzing # of iterations of loop 1
  exit condition [0, + , 5] <= 0
  bounds on difference of bases: 0 ... 0
  result:
# of iterations 1, bounded by 1
Replacing uses of: e_5 with: 4266897156
gimple_simplified to if (1 != 0)

[Bug tree-optimization/81913] [8 Regression] wrong code at -O1

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-21
  Known to work||7.2.0
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

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

[Bug tree-optimization/81913] New: [8 Regression] wrong code at -O1

[zsojka at seznam dot cz]

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

Bug ID: 81913
   Summary: [8 Regression] wrong code at -O1
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-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 42020
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42020=edit
reduced testcase

$ x86_64-pc-linux-gnu-gcc -O 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-251215-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-251215-checking-yes-rtl-df-extra-nographite-amd64
Thread model: posix
gcc version 8.0.0 20170821 (experimental) (GCC) 


All tested targets are affected (not x86 specific).

[Bug libstdc++/60936] [5/6 Regression] Binary code bloat with std::string

[rguenth at gcc dot gnu.org]

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

--- Comment #35 from Richard Biener  ---
We keep regression bugs open until all maintained branches close to be able to
correctly set known-to-fail

[Bug target/81879] Bad compilation of small program if LTO is used

[freddy77 at gmail dot com]

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

--- Comment #3 from Frediano Ziglio  ---
I noted that during the link the resolution file using -static or not is
different

without -static

750 6dacea834fb099d1 PREVAILING_DEF_IRONLY _ZNKSt5ctypeIcE8do_widenEc
753 6dacea834fb099d1 PREVAILING_DEF main
738 6dacea834fb099d1 RESOLVED_EXEC
_ZNKSt9basic_iosIcSt11char_traitsIcEE5widenEc
743 6dacea834fb099d1 RESOLVED_EXEC
_ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_
797 6dacea834fb099d1 UNDEF _ZSt4cout
761 6dacea834fb099d1 RESOLVED_EXEC _ZNSt8ios_base4InitD1Ev
766 6dacea834fb099d1 RESOLVED_EXEC _ZNKSt5ctypeIcE13_M_widen_initEv
771 6dacea834fb099d1 RESOLVED_EXEC _ZSt16__throw_bad_castv
776 6dacea834fb099d1 RESOLVED_EXEC _ZNSo5flushEv
782 6dacea834fb099d1 RESOLVED_EXEC _ZNSo3putEc
788 6dacea834fb099d1 RESOLVED_EXEC atexit
791 6dacea834fb099d1 RESOLVED_EXEC _ZNSt8ios_base4InitC1Ev

with -static

750 1b64a3a32ab1e36a PREEMPTED_REG _ZNKSt5ctypeIcE8do_widenEc
753 1b64a3a32ab1e36a PREVAILING_DEF main
738 1b64a3a32ab1e36a RESOLVED_EXEC
_ZNKSt9basic_iosIcSt11char_traitsIcEE5widenEc
743 1b64a3a32ab1e36a RESOLVED_EXEC
_ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_
797 1b64a3a32ab1e36a RESOLVED_EXEC _ZSt4cout
761 1b64a3a32ab1e36a RESOLVED_EXEC _ZNSt8ios_base4InitD1Ev
766 1b64a3a32ab1e36a RESOLVED_EXEC _ZNKSt5ctypeIcE13_M_widen_initEv
771 1b64a3a32ab1e36a RESOLVED_EXEC _ZSt16__throw_bad_castv
776 1b64a3a32ab1e36a RESOLVED_EXEC _ZNSo5flushEv
782 1b64a3a32ab1e36a RESOLVED_EXEC _ZNSo3putEc
788 1b64a3a32ab1e36a RESOLVED_EXEC atexit
791 1b64a3a32ab1e36a RESOLVED_EXEC _ZNSt8ios_base4InitC1Ev


Specifically the _ZNKSt5ctypeIcE8do_widenEc (our missing function) in the
failing case is PREEMPTED_REG while with the successful one is
PREVAILING_DEF_IRONLY.

[Bug libstdc++/60936] [5/6 Regression] Binary code bloat with std::string

[d.v.a at ngs dot ru]

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

--- Comment #34 from __vic  ---
Fixed in 7.1.
Shouldn't we close this bug?

[Bug libstdc++/81912] std::distance not constexpr in C++17 mode

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-08-21
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Target Milestone|--- |7.3
 Ever confirmed|0   |1

[Bug libstdc++/81912] std::distance not constexpr in C++17 mode

[gcc at hazardy dot de]

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

--- Comment #1 from Björn Schäpers  ---
Created attachment 42019
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42019=edit
The preprocessed test file.

[Bug libstdc++/81912] New: std::distance not constexpr in C++17 mode

[gcc at hazardy dot de]

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

Bug ID: 81912
   Summary: std::distance not constexpr in C++17 mode
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc at hazardy dot de
  Target Milestone: ---

Created attachment 42018
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42018=edit
The test file.

Although std::distance is marked with _GLIBCXX17_CONSTEXPR the called
std::__iterator_category is not and thus std::distance can not be called in a
constexpr environment.

Tested with MinGW 7.1 on Windows and GCC 7.1 and 7.2 on godbolt [1]. The only
parameter used is -std=c++1z.

[1] https://godbolt.org/g/87Edtw

$ g++ -v
Using built-in specs.
COLLECT_GCC=E:\MinGW64\bin\g++.exe
COLLECT_LTO_WRAPPER=E:/MinGW64/bin/../libexec/gcc/x86_64-w64-mingw32/7.1.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../../../src/gcc-7.1.0/configure --host=x86_64-w64-mingw32
--build=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --prefix=/mingw64
--with-sysroot=/c/mingw710/x86_64-710-posix-seh-rt_v5-rev0/mingw64
--enable-shared --enable-static --disable-multilib
--enable-languages=c,c++,fortran,lto --enable-libstdcxx-time=yes
--enable-threads=posix --enable-libgomp --enable-libatomic --enable-lto
--enable-graphite --enable-checking=release --enable-fully-dynamic-string
--enable-version-specific-runtime-libs --enable-libstdcxx-filesystem-ts=yes
--disable-libstdcxx-pch --disable-libstdcxx-debug --enable-bootstrap
--disable-rpath --disable-win32-registry --disable-nls --disable-werror
--disable-symvers --with-gnu-as --with-gnu-ld --with-arch=nocona
--with-tune=core2 --with-libiconv --with-system-zlib
--with-gmp=/c/mingw710/prerequisites/x86_64-w64-mingw32-static
--with-mpfr=/c/mingw710/prerequisites/x86_64-w64-mingw32-static
--with-mpc=/c/mingw710/prerequisites/x86_64-w64-mingw32-static
--with-isl=/c/mingw710/prerequisites/x86_64-w64-mingw32-static
--with-pkgversion='x86_64-posix-seh-rev0, Built by MinGW-W64 project'
--with-bugurl=http://sourceforge.net/projects/mingw-w64 CFLAGS='-O2 -pipe
-fno-ident -I/c/mingw710/x86_64-710-posix-seh-rt_v5-rev0/mingw64/opt/include
-I/c/mingw710/prerequisites/x86_64-zlib-static/include
-I/c/mingw710/prerequisites/x86_64-w64-mingw32-static/include' CXXFLAGS='-O2
-pipe -fno-ident
-I/c/mingw710/x86_64-710-posix-seh-rt_v5-rev0/mingw64/opt/include
-I/c/mingw710/prerequisites/x86_64-zlib-static/include
-I/c/mingw710/prerequisites/x86_64-w64-mingw32-static/include' CPPFLAGS='
-I/c/mingw710/x86_64-710-posix-seh-rt_v5-rev0/mingw64/opt/include
-I/c/mingw710/prerequisites/x86_64-zlib-static/include
-I/c/mingw710/prerequisites/x86_64-w64-mingw32-static/include' LDFLAGS='-pipe
-fno-ident -L/c/mingw710/x86_64-710-posix-seh-rt_v5-rev0/mingw64/opt/lib
-L/c/mingw710/prerequisites/x86_64-zlib-static/lib
-L/c/mingw710/prerequisites/x86_64-w64-mingw32-static/lib '
Thread model: posix
gcc version 7.1.0 (x86_64-posix-seh-rev0, Built by MinGW-W64 project)

$ g++ -std=c++1z test.cpp
test.cpp: In function 'int main()':
test.cpp:6:5: error: non-constant condition for static assertion
 static_assert(std::distance(a.begin(), a.end()) == 2);
 ^
test.cpp:6:32: error: 'constexpr typename
std::iterator_traits<_Iterator>::difference_type std::distance(_InputIterator,
_InputIterator) [with _InputIterator = int*; typename
std::iterator_traits<_Iterator>::difference_type = long long int]' called in a
constant expression
 static_assert(std::distance(a.begin(), a.end()) == 2);
   ~^~~~
In file included from
E:/MinGW64/lib/gcc/x86_64-w64-mingw32/7.1.0/include/c++/bits/stl_algobase.h:66:0,
 from
E:/MinGW64/lib/gcc/x86_64-w64-mingw32/7.1.0/include/c++/algorithm:61,
 from test.cpp:1:
E:/MinGW64/lib/gcc/x86_64-w64-mingw32/7.1.0/include/c++/bits/stl_iterator_base_funcs.h:138:5:
note: 'constexpr typename std::iterator_traits<_Iterator>::difference_type
std::distance(_InputIterator, _InputIterator) [with _InputIterator = int*;
typename std::iterator_traits<_Iterator>::difference_type = long long int]' is
not usable as a constexpr function because:
 distance(_InputIterator __first, _InputIterator __last)
 ^~~~
E:/MinGW64/lib/gcc/x86_64-w64-mingw32/7.1.0/include/c++/bits/stl_iterator_base_funcs.h:142:33:
error: call to non-constexpr function 'typename
std::iterator_traits<_Iterator>::iterator_category
std::__iterator_category(const _Iter&) [with _Iter = int*; typename
std::iterator_traits<_Iterator>::iterator_category =
std::random_access_iterator_tag]'
 std::__iterator_category(__first));
 ^

[Bug tree-optimization/81900] [8 Regression] GCC trunk miscompiles Perl / __sigsetjmp issue

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Ah ...

@@ -2396,9 +2446,6 @@ compute_antic (void)
if (e->flags & EDGE_ABNORMAL)
  {
bitmap_set_bit (has_abnormal_preds, block->index);
-
-   /* We also anticipate nothing.  */
-   BB_VISITED (block) = 1;
break;
  }

[Bug tree-optimization/81900] [8 Regression] GCC trunk miscompiles Perl / __sigsetjmp issue

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
So while there is one simple issue with the iteration, fix:

@@ -2119,14 +2170,13 @@ static sbitmap has_abnormal_preds;
 static bool
 compute_antic_aux (basic_block block, bool block_has_abnormal_pred_edge)
 {
-  bool changed = false;
   bitmap_set_t S, old, ANTIC_OUT;
   bitmap_iterator bi;
   unsigned int bii;
   edge e;
   edge_iterator ei;
-  bool was_visited = BB_VISITED (block);

+  bool changed = ! BB_VISITED (block);
   old = ANTIC_OUT = S = NULL;
   BB_VISITED (block) = 1;

@@ -2217,7 +2267,7 @@ compute_antic_aux (basic_block block, bo
   /* clean (ANTIC_IN (block)) is defered to after the iteration converged
  because it can cause non-convergence, see for example PR81181.  */

-  if (!was_visited || !bitmap_set_equal (old, ANTIC_IN (block)))
+  if (!bitmap_set_equal (old, ANTIC_IN (block)))
 changed = true;

  maybe_dump_sets:

there is another issue as we think *_7 is antic and thus hoist the dereference
before the _7 == 0 check which will optimize that away as not necessary in
a later pass.

[Bug c/53037] warn_if_not_aligned(X)

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

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

--- Comment #35 from Andreas Schwab <sch...@linux-m68k.org> ---
On m68k:

FAIL: gcc.dg/pr53037-1.c  (test for warnings, line 42)
FAIL: gcc.dg/pr53037-1.c  (test for warnings, line 75)
FAIL: gcc.dg/pr53037-1.c (test for excess errors)
Excess errors:
/daten/aranym/gcc/gcc-20170821/gcc/testsuite/gcc.dg/pr53037-1.c:42:1: warning:
alignment 2 of 'struct foo5' is less than 16 [-Wif-not-aligned]
/daten/aranym/gcc/gcc-20170821/gcc/testsuite/gcc.dg/pr53037-1.c:75:1: warning:
alignment 2 of 'union bar3' is less than 16 [-Wif-not-aligned]

FAIL: g++.dg/pr53037-1.C  -std=gnu++98  (test for warnings, line 38)
FAIL: g++.dg/pr53037-1.C  -std=gnu++98  (test for warnings, line 71)
FAIL: g++.dg/pr53037-1.C  -std=gnu++98 (test for excess errors)
Excess errors:
/daten/aranym/gcc/gcc-20170821/gcc/testsuite/g++.dg/pr53037-1.C:38:8: warning:
alignment 2 of 'foo5' is less than 16 [-Wif-not-aligned]
/daten/aranym/gcc/gcc-20170821/gcc/testsuite/g++.dg/pr53037-1.C:71:7: warning:
alignment 2 of 'bar3' is less than 16 [-Wif-not-aligned]

[Bug c/53037] warn_if_not_aligned(X)

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

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

--- Comment #34 from Andreas Schwab <sch...@linux-m68k.org> ---
On ia64:

FAIL: g++.dg/pr53037-4.C  -std=gnu++11 (test for excess errors)
Excess errors:
/usr/local/gcc/gcc-20170821/gcc/testsuite/g++.dg/pr53037-4.C:9:1: error:
alignment for 'void foo2()' must be at least 16

[Bug c++/81901] false-positive -Warray-bounds

[vermaelen.wouter at gmail dot com]

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

--- Comment #2 from Wouter Vermaelen  ---
Euhm, i=0x30 should not enter case 0x00. (Or did you mean the analysis pass
that produces the warning). This code should not store anything to a[].

(I know this reduced function is useless/obfuscated. The original code before
minimizing and manual inlining made more sense ;-)

[Bug tree-optimization/81900] [8 Regression] GCC trunk miscompiles Perl / __sigsetjmp issue

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-08-21
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

--- Comment #4 from Richard Biener  ---
Mine.

[Bug target/81906] [7/8 Regression] Calls to rint() wrongly optimized away starting in g++ 6

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Target||x86_64-*-*, i?86-*-*
   Priority|P3  |P2
  Component|c++ |target
   Target Milestone|--- |7.3

--- Comment #9 from Richard Biener  ---
rint () is inlined into an SSE sequence:

void
ix86_expand_rint (rtx operand0, rtx operand1)
{
  /* C code for the stuff we're doing below:
xa = fabs (operand1);
if (!isless (xa, 2**52))
  return operand1;
xa = xa + 2**52 - 2**52;
return copysign (xa, operand1);
   */

that doesn't work for rounding modes != to-nearest.  Previously we had
the pattern guarded by !flag_trapping_math.  Thus with GCC 6 the bug
persists with -frounding-math -fno-trapping-math.

For ! TARGET_ROUND we need to use ! flag_rounding_math (or fix the code
sequence in case there exists one that works).

[Bug c++/81911] New: Constant expression from permitted result of a constant expression is not constexpr

[antoshkka at gmail dot com]

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

Bug ID: 81911
   Summary: Constant expression from permitted result of a
constant expression is not constexpr
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antoshkka at gmail dot com
  Target Milestone: ---

The following code fails to compile:



int main() {
static const char someVar[] = "str";
constexpr auto c0 = someVar[0];
}



error: the value of 'someVar' is not usable in a constant expression
 constexpr auto c0 = someVar[0];
  ^



This seems to be an error:

"In any constexpr variable declaration, the full-expression of the
initialization shall be a constant expression [expr.const]"

Where [expr.const] has the paragraphs:

"A constant expression is either a glvalue core constant expression that refers
to an entity that is a permitted result of a constant expression 

An entity is a permitted result of a constant expression if it is an object
with static storage duration that is either not a temporary object "