[Bug target/81874] internal compiler error: in do_SUBST, at combine.c:725

[zwzhangwen.zhang at huawei dot com]

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

--- Comment #4 from zwzhangwen.zhang at huawei dot com ---
I have checked it can be hidden or fixed in gcc.gnu.org/svn/gcc/trunk@239421
But it fixed PR71654 and it affected comparision expr?

[Bug lto/82229] GCC7's LTO underperforms compared to GCC6

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #10 from Martin Liška  ---
I can confirm that I'm able to build it and to see FPS on console. Please
modify the branch so that it uses -flto and optimization flags you use.

Thanks,
Martin

[Bug tree-optimization/70754] [5/6 Regression] ICE during predictive commoning

[amker at gcc dot gnu.org]

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

--- Comment #16 from amker at gcc dot gnu.org ---
(In reply to Steve Ellcey from comment #15)
> Is this still being considered for backporting?

sorry for letting this slip away.  For backport, patch for PR79663 is also
needed., it fixes a regression of this one.  Thanks

[Bug c++/81355] SegFault when using attribute target dispatch with empty parameter

[marxin at gcc dot gnu.org]

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

--- Comment #9 from Martin Liška  ---
Author: marxin
Date: Tue Sep 19 08:12:58 2017
New Revision: 252965

URL: https://gcc.gnu.org/viewcvs?rev=252965&root=gcc&view=rev
Log:
Ignore empty string in target attribute (PR c++/81355).

2017-09-19  Martin Liska  

PR c++/81355
* config/i386/i386.c (sorted_attr_string): Skip empty strings.

Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/i386/i386.c

[Bug c++/81355] SegFault when using attribute target dispatch with empty parameter

[marxin at gcc dot gnu.org]

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

--- Comment #10 from Martin Liška  ---
Author: marxin
Date: Tue Sep 19 08:18:02 2017
New Revision: 252967

URL: https://gcc.gnu.org/viewcvs?rev=252967&root=gcc&view=rev
Log:
Ignore empty string in target attribute (PR c++/81355).

2017-09-19  Martin Liska  

PR c++/81355
* config/i386/i386.c (sorted_attr_string): Skip empty strings.

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

[Bug tree-optimization/69728] [6/7/8 Regression] internal compiler error: in outer_projection_mupa, at graphite-sese-to-poly.c:1175

[rguenth at gcc dot gnu.org]

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

--- Comment #16 from Richard Biener  ---
(In reply to Richard Biener from comment #13)
> A "simple" patch like the following seems to "work".
> 
> Index: gcc/graphite-sese-to-poly.c
> ===
> --- gcc/graphite-sese-to-poly.c (revision 252920)
> +++ gcc/graphite-sese-to-poly.c (working copy)
> @@ -1043,6 +1043,13 @@ add_loop_schedule (__isl_take isl_schedu
>if (empty < 0 || empty)
>  return empty < 0 ? isl_schedule_free (schedule) : schedule;
>  
> +  isl_union_set *domain = isl_schedule_get_domain (schedule);
> +  if (isl_union_set_is_empty (domain))
> +{
> +  isl_union_set_free (domain);
> +  return schedule;
> +}
> +
>isl_space *space = isl_set_get_space (iterators);
>int loop_index = isl_space_dim (space, isl_dim_set) - 1;
>  
> @@ -1063,7 +1070,6 @@ add_loop_schedule (__isl_take isl_schedu
>prefix = isl_multi_aff_set_tuple_id (prefix, isl_dim_out, label);
>  
>int n = isl_multi_aff_dim (prefix, isl_dim_in);
> -  isl_union_set *domain = isl_schedule_get_domain (schedule);
>isl_multi_union_pw_aff *mupa = outer_projection_mupa (domain, n);
>mupa = isl_multi_union_pw_aff_apply_multi_aff (mupa, prefix);
>return isl_schedule_insert_partial_schedule (schedule, mupa);
> 
> 
> but it results in a bougs initial schedule:
> 
> [scheduler] original ast:
> {
>   for (int c0 = 0; c0 < -P_21; c0 += 1) {
> S_9(c0);
> if (P_21 + c0 <= -2)
>   S_8(c0);
>   }
>   S_10();
> }
> 
> so the conditional loop ended up not being a loop.  I believe in this
> case we are somehow confused by 'c' wrapping?  niter is computed
> as -(unsigned int) (c.7_21 + 1).  Can we really "handle" negating
> an unsigned value?

The real issue is that we probably mishandle the constraint generation for
-(unsigned int) (c.7_21 + 1) (niter of the loop) or that ISL mis-handles
them.  I can't fully decipher the details in the dump but I see

[sese-to-poly] adding constraint to the domain: [P_21] -> { [i1] : i1 <=
2147483637 }
[sese-to-poly] set pbb_9->domain: [P_21] -> { [i1] : -2147483648 <= P_21 <=
2147483647 and 0 <= i1 <= 2147483637 and 4294967296*floor((-1 -
P_21)/4294967296) < -P_21 - i1 }
[sese-to-poly] set pbb_8->domain: [P_21] -> { [i1] : -2147483648 <= P_21 <=
2147483647 and 0 <= i1 <= 2147483637 and 4294967296*floor((-1 -
P_21)/4294967296) < -P_21 - i1 }
[sese-to-poly] adding one extra dimension to the domain for loop_2.
[sese-to-poly] adding constraint to the domain: [P_21] -> { [i1, i2] : i2 >= 0
}
[sese-to-poly] set pbb_6->domain: [P_21] -> { [i1, i2] : -2147483648 <= P_21 <=
2147483647 and 0 <= i1 <= 2147483637 and 0 <= i2 <= 7 and 4294967296*floor((-1
- P_21)/4294967296) < -P_21 - i1 }
[sese-to-poly] set pbb_10->domain: [P_21] -> { [] : -2147483648 <= P_21 <=
2147483647 and 4294967296*floor((-1 - P_21)/4294967296) >= -2147483638 - P_21 }

where I believe the pbb_6 domain is the issue.  The constraint on P_21

4294967296*floor((-1 - P_21)/4294967296) < -P_21 - i1

where I assume P_21 is c.7_12, is supposed to capture th case
where c initially is negative and increasing until it is zero,
the case where it is initially positive would invoke undefined behavior.
But we have 0 <= i1 <= 2147483637, whereever that comes from.  Probably
from the i1 <= 2147483637 constraint?

That said, this testcase is somewhat confusing

Still, if ISL can get "confused" does it reliably return an empty domain?

That is, aren't we papering over possible wrong-code issues in GRAPHITE
or ISL with handling this as error?  Couldn't it be GCC simply didn't
optimize the code properly and the domain can really be empty in which
case we should not schedule any stmts of the loop?  W/o setting the
error in the patch we end up scheduling the stmt anyway which would
be wrong.  So how'd we properly handle a valid empty domain?  The
initial schedule generation is somewhat of a mess to me...

Anyway, I added

  /* We cannot apply an empty domain to pbbs in this loop so fail.
 ???  Somehow drop pbbs in the loop instead.  */

and committed the patch (we clearly cannot properly handle an empty
domain during initial schedule generation even if the empty domain
is correct).

[Bug tree-optimization/59859] [meta-bug] GRAPHITE issues

[rguenth at gcc dot gnu.org]

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

Bug 69728 Summary: [6/7/8 Regression] internal compiler error: in 
outer_projection_mupa, at graphite-sese-to-poly.c:1175
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69728

   What|Removed |Added

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

[Bug tree-optimization/69728] [6/7/8 Regression] internal compiler error: in outer_projection_mupa, at graphite-sese-to-poly.c:1175

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug other/80069] ICE at graphite-sese-to-poly.c:1176

[rguenth at gcc dot gnu.org]

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

Bug 69728 Summary: [6/7/8 Regression] internal compiler error: in 
outer_projection_mupa, at graphite-sese-to-poly.c:1175
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69728

   What|Removed |Added

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

[Bug tree-optimization/80105] [6/7/8 Regression] ICE in outer_projection_mupa, at graphite-sese-to-poly.c:1019

[rguenth at gcc dot gnu.org]

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

Bug 69728 Summary: [6/7/8 Regression] internal compiler error: in 
outer_projection_mupa, at graphite-sese-to-poly.c:1175
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69728

   What|Removed |Added

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

[Bug testsuite/77634] some vectorized testcases fail with -mcpu=thunderx

[jgreenhalgh at gcc dot gnu.org]

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

James Greenhalgh  changed:

   What|Removed |Added

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

--- Comment #2 from James Greenhalgh  ---
Comment 1 claims this is fixed, Andrew, please reopen if it is still an issue.

[Bug target/63250] Complex fp16 arithmetic uses nonexistent libgcc functions

[jgreenhalgh at gcc dot gnu.org]

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

James Greenhalgh  changed:

   What|Removed |Added

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

--- Comment #6 from James Greenhalgh  ---
This should have been fixed by my work last year, I think.

[Bug tree-optimization/69728] [6/7/8 Regression] internal compiler error: in outer_projection_mupa, at graphite-sese-to-poly.c:1175

[rguenth at gcc dot gnu.org]

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

--- Comment #18 from Richard Biener  ---
Author: rguenth
Date: Tue Sep 19 08:25:17 2017
New Revision: 252968

URL: https://gcc.gnu.org/viewcvs?rev=252968&root=gcc&view=rev
Log:
2017-09-19  Richard Biener  

PR tree-optimization/69728
* graphite-sese-to-poly.c (schedule_error): New global.
(add_loop_schedule): Handle empty domain by failing the
schedule.
(build_original_schedule): Handle schedule_error.

* gfortran.dg/graphite/pr69728.f90: New testcase.
* gcc.dg/graphite/pr69728.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/graphite/pr69728.c
trunk/gcc/testsuite/gfortran.dg/graphite/pr69728.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/graphite-sese-to-poly.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/79622] [6/7 Regression] Wrong code w/ -O2 -floop-nest-optimize

[rguenther at suse dot de]

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

--- Comment #9 from rguenther at suse dot de  ---
On Mon, 18 Sep 2017, spop at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79622
> 
> --- Comment #8 from Sebastian Pop  ---
> > I would have expected at least each memory op to be in a separate "black 
> > box"
> 
> We could have a pass before graphite that splits BBs with more than one 
> write into blocks that contain one data write with all the operations 
> and data reads needed to compute the stored value.  This would allow 
> more freedom to schedule BBs around.

Yeah, somewhat iffy but good enough for experiments I guess.  But I
think we should have different BBs for reads as well?  Though that
means we'll handle all the data flow from reads to writes with
scalar references ...

In the end this splitting of BBs should be an internal detail in the
GRAPHITE data structures and not applied to GIMPLE.  Basically
have the black-boxes be writes with all reads/operations to compute
the value implicitely included.  Code-gen would have to deal with
this by eventually duplicating stmts if they end up un-CSEd by
the scheduler.  So a black-box would be a set of stmts rather than
a whole GIMPLE BB.  First step would be abstracting the iteration
over GIMPLE stmts in a black-box I guess.

> > if you follow the original go-out-of-SSA approach you'd have their effects
> > on the CFG edges.  So a more complete fix would similarly handle uses.
> 
> In other words: how do we handle reductions?
> As you remember, the original way was to expose reductions by rewriting
> out-of-SSA
> scalar dependences crossing basic blocks (loop-phi nodes, loop-close-phi
> nodes,)
> tagging the properties of the reduction (commutative, associative)
> on the array, and adding that info to the data dependence graph.
> By adding those properties to the dependence graph, we give the scheduler
> more freedom to select transforms.
> 
> We moved away from rewriting scalar dependences out-of-SSA because we do not
> want to transform the code if the scheduler has no better transform to be 
> done:
> we do not want to leave around inefficient memory reads/writes.
> Instead, we handle SSA names and create scalar references added to the
> dependence graph.  We still need to tag scalar reductions with their
> associative properties to allow the scheduler to reorder the computations.

You mean this tagging of associativeness is not yet done?

[Bug tree-optimization/82244] -O2: ICE: tree check: expected ssa_name, have integer_cst in replace_uses_by, at tree-cfg.c:1904

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug target/82240] i386.md & -Wlogical-op in build

[dcb314 at hotmail dot com]

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

--- Comment #2 from David Binderman  ---
(In reply to Andreas Schwab from comment #1)
> It refers to the source files generated from this file.  You need to look at
> the context to see which file was actually compiled.

g++ -fno-PIE -c   -g -O3 -Wall -Wlogical-op -DIN_GCC -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H
-I. -I. -I../../trunk/gcc -I../../trunk/gcc/. -I../../trunk/gcc/../include
-I../../trunk/gcc/../libcpp/include  -I../../trunk/gcc/../libdecnumber
-I../../trunk/gcc/../libdecnumber/bid -I../libdecnumber
-I../../trunk/gcc/../libbacktrace   -o insn-latencytab.o -MT insn-latencytab.o
-MMD -MP -MF ./.deps/insn-latencytab.TPo insn-latencytab.c
../../trunk/gcc/config/i386/i386.md: In function ‘int
insn_default_latency_atom(rtx_insn*)’:
../../trunk/gcc/config/i386/i386.md:19853:36: warning: logical ‘or’ of
collectively exhaustive tests is always true [-Wlogical-op]
../../trunk/gcc/config/i386/i386.md: In function ‘int
insn_default_latency_slm(rtx_insn*)’:
../../trunk/gcc/config/i386/i386.md:21035:36: warning: logical ‘or’ of
collectively exhaustive tests is always true [-Wlogical-op]

File insn-latencytab.c seems to be generated in some way.

I can pin the warning downto this piece of source code in the file:

case 4:  /* *cmpdi_ccno_1 */
case 3:  /* *cmpsi_ccno_1 */
case 2:  /* *cmphi_ccno_1 */
case 1:  /* *cmpqi_ccno_1 */
  extract_constrain_insn_cached (insn);
  if ((which_alternative != 0) || (which_alternative != 1) ||
(get_attr_memory (insn) == MEMORY_NONE))

[Bug tree-optimization/82244] [7/8 Regression] -O2: ICE: tree check: expected ssa_name, have integer_cst in replace_uses_by, at tree-cfg.c:1904

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Priority|P3  |P2
  Known to work||6.4.0
   Target Milestone|--- |7.3
Summary|-O2: ICE: tree check:   |[7/8 Regression] -O2: ICE:
   |expected ssa_name, have |tree check: expected
   |integer_cst in  |ssa_name, have integer_cst
   |replace_uses_by, at |in replace_uses_by, at
   |tree-cfg.c:1904 |tree-cfg.c:1904

--- Comment #4 from Richard Biener  ---
So we're creating

   [9.35%] [count: INV]:
  f_26 = ASSERT_EXPR ;
  _2 = f_26 & 2;
  if (_2 != 0)
goto ; [33.00%] [count: INV]
  else
goto ; [67.00%] [count: INV]

   [3.08%] [count: INV]:
  f_27 = ASSERT_EXPR ;
  f_28(ab) = ASSERT_EXPR ;
  h ();

where we are able to fold f_26 to zero and thus end up with

  f_28(ab) = ASSERT_EXPR <0, 0 != 0>;

when we are trying to get rid of asserts.  But we may not propagate the
constant.

[Bug c++/81355] SegFault when using attribute target dispatch with empty parameter

[marxin at gcc dot gnu.org]

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

--- Comment #11 from Martin Liška  ---
Author: marxin
Date: Tue Sep 19 09:03:05 2017
New Revision: 252970

URL: https://gcc.gnu.org/viewcvs?rev=252970&root=gcc&view=rev
Log:
Ignore empty string in target attribute (PR c++/81355).

2017-09-19  Martin Liska  

PR c++/81355
* config/i386/i386.c (sorted_attr_string): Skip empty strings.

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

[Bug lto/82229] GCC7's LTO underperforms compared to GCC6

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|NEW |WAITING

[Bug sanitizer/81224] ICE in -fsanitize=address w/ a register variable of a vector type

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #21 from Martin Liška  ---
Fixed.

[Bug other/70945] Offloading: compatibility of target and offloading toolchains

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
So, can't we just add the __*_finite aliases (or wrappers) to the nvptx newlib?
 That sounds easiest to me.

[Bug target/82240] i386.md & -Wlogical-op in build

[dcb314 at hotmail dot com]

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

David Binderman  changed:

   What|Removed |Added

 CC||jh at suse dot cz,
   ||ubizjak at gmail dot com

--- Comment #3 from David Binderman  ---
The cmp* words I can only pin downto a couple of ChangeLog entries
from 2007 and 2001.

I am guessing that this bug is machine specific and not some general
problem with the machinery which generates C source code from the 
machine description files.

Adding the two people mentioned in the ChangeLog files. 
Any assistance would be most welcome.

[Bug target/82240] i386.md & -Wlogical-op in build

[ubizjak at gmail dot com]

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

--- Comment #4 from Uroš Bizjak  ---
Can you please post configure (and build?) flags?

[Bug c++/82246] New: Wrong optimisation of an offset double* attribute class allocated in stack

[erwan.adam at cea dot fr]

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

Bug ID: 82246
   Summary: Wrong optimisation of an offset double* attribute
class allocated in stack
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: erwan.adam at cea dot fr
  Target Milestone: ---

Created attachment 42204
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42204&action=edit
Use case for wrong optimisation of an offset double* attribute class allocated
in stack

The code in attachment fails with -O1 :

[adam]$ g++ -O0 -Wall -pedantic -Wextra -fno-strict-aliasing -fwrapv
-fno-aggressive-loop-optimizations main.cxx && ./a.out 
0
1 1
2 2
 POMOT3 - Convergency ok
[adam]$ g++ -O1 -Wall -pedantic -Wextra -fno-strict-aliasing -fwrapv
-fno-aggressive-loop-optimizations main.cxx && ./a.out
0
1 1
2 1
3 1
4 1
5 1
 POMOT3 - Convergency failed

This code is valgrind free errors but works in O1 with -fsanitize=undefined :

[adam]$ g++ -O1 -Wall -pedantic -Wextra -fno-strict-aliasing -fwrapv
-fno-aggressive-loop-optimizations -fsanitize=undefined main.cxx && ./a.out
0
1 1
2 2
 POMOT3 - Convergency ok

[Bug target/82240] i386.md & -Wlogical-op in build

[ubizjak at gmail dot com]

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

--- Comment #5 from Uroš Bizjak  ---
BTW: There are some shortcuts taken to ease macroization, so these warnings
could belong to patterns that are never generated and thus benign.

[Bug target/82240] i386.md & -Wlogical-op in build

[dcb314 at hotmail dot com]

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

--- Comment #6 from David Binderman  ---
(In reply to Uroš Bizjak from comment #4)
> Can you please post configure (and build?) flags?

../trunk/configure --prefix=/home/dcb/gcc/results \
--disable-bootstrap \
--disable-multilib \
--disable-werror \
--enable-checking=df,extra,fold,rtl,yes \
--enable-languages=c,c++,fortran

I also do some additional top level Makefile tweeking:

sed 's/-O2/-O3 -march=native -Wlogical-op -Wtautological-compare/' \
< Makefile > Makefile.tmp
mv Makefile.tmp Makefile

From /proc/cpuinfo, machine type for -march=native is

model name  : AMD FX(tm)-8350 Eight-Core Processor

[Bug other/70945] Offloading: compatibility of target and offloading toolchains

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

   Keywords|patch   |

--- Comment #8 from Thomas Schwinge  ---
(In reply to Jakub Jelinek from comment #7)
> So, can't we just add the __*_finite aliases (or wrappers) to the nvptx
> newlib?  That sounds easiest to me.

Yes, that was the outcome of the earlier discussion,
, once
we have "document[ed] what APIs we are willing to support",
.  I have
not yet been able to allocate the time required to do that.

[Bug c++/82247] New: [concepts] Name deduction in concepts fails depending on the argument type

[mjklaim at gmail dot com]

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

Bug ID: 82247
   Summary: [concepts] Name deduction in concepts fails depending
on the argument type
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mjklaim at gmail dot com
  Target Milestone: ---

~~
#include 
#include 

template 
bool concept Fooable = requires(const T& t) {
{ foo(t) }; // foo is unknown here
};

template 
void foo(T&& t) {
}

template 
void bar(T&& t)
{
}

class K
{
int x = 0;
};

class WTF
{
std::vector values;
};

int main() {
// int i{}; // FAIL
// K i; // SUCCEED
// float i; // FAIL
// std::string i; // FAIL?
// std::vector i; // FAIL?
// auto i =[]{}; // SUCCEED
// int i[42]; // FAIL
// int* i = nullptr;
WTF i; // SUCCEED HAHAHAHA
bar(i);
}~

~

All these lines should have succeded, but only using the custom types worked.
I have no idea what is wrong here but it seem that even for int, the deduction
of the foo function is not done at the right time.

[Bug target/82248] New: probe_stack can generate unpredictable STR on arm

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

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

Bug ID: 82248
   Summary: probe_stack can generate unpredictable STR on arm
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sch...@linux-m68k.org
  Target Milestone: ---
Target: arm*-*-*

The probe_stack insn uses "str r0,%0" with hard-coded reference to r0, but this
is unpredictable if %0 happens to use pre-indexed or post-indexed addressing
mode with r0 as base.

[Bug rtl-optimization/68988] reload_pseudo_compare_func violates qsort requirements

[amonakov at gcc dot gnu.org]

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

--- Comment #5 from Alexander Monakov  ---
Author: amonakov
Date: Tue Sep 19 10:16:20 2017
New Revision: 252972

URL: https://gcc.gnu.org/viewcvs?rev=252972&root=gcc&view=rev
Log:
lra: make reload_pseudo_compare_func a proper comparator

PR rtl-optimization/57878
PR rtl-optimization/68988
* lra-assigns.c (reload_pseudo_compare_func): Remove fragmentation
avoidance test involving non_reload_pseudos.  Move frequency test
below the general fragmentation avoidance test.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-assigns.c

[Bug rtl-optimization/57878] Incorrect code: live register clobbered in split2

[amonakov at gcc dot gnu.org]

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

--- Comment #4 from Alexander Monakov  ---
Author: amonakov
Date: Tue Sep 19 10:16:20 2017
New Revision: 252972

URL: https://gcc.gnu.org/viewcvs?rev=252972&root=gcc&view=rev
Log:
lra: make reload_pseudo_compare_func a proper comparator

PR rtl-optimization/57878
PR rtl-optimization/68988
* lra-assigns.c (reload_pseudo_compare_func): Remove fragmentation
avoidance test involving non_reload_pseudos.  Move frequency test
below the general fragmentation avoidance test.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-assigns.c

[Bug rtl-optimization/57878] Incorrect code: live register clobbered in split2

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

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

--- Comment #5 from Alexander Monakov  ---
This bug was originally fixed in July 2013 by r201036:
https://gcc.gnu.org/ml/gcc-patches/2013-07/msg00732.html , but that patch
changed the comparator in a way that made it non-transitive (PR 68988). In
2014, fixes for PR 60650 introduced a more robust fix for the original spill
failure.

This patch reverts the non_reload_pseudos check from the comparator to fix PR
68988 and also moves the fragmentation avoidance check earlier as suggested in
comment #3 since it was found that it leads to smaller cc1 size without
regressions on SPEC CPU 2000:
https://gcc.gnu.org/ml/gcc-patches/2017-09/msg01054.html

[Bug rtl-optimization/68988] reload_pseudo_compare_func violates qsort requirements

[ygribov at gcc dot gnu.org]

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

Yury Gribov  changed:

   What|Removed |Added

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

--- Comment #6 from Yury Gribov  ---
.

[Bug c++/82249] New: mismatched argument pack lengths leads to ICE

[benni.buch at gmail dot com]

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

Bug ID: 82249
   Summary: mismatched argument pack lengths leads to ICE
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: benni.buch at gmail dot com
  Target Milestone: ---

template < typename ... Ds >
constexpr auto f(Ds ...)noexcept{
return [](auto ... n){
constexpr auto calc =
[](auto n, auto dim)noexcept{ return dim; };
return (calc(n, Ds{}), ...);
}(Ds{} ...);
}


int main(){
f();  // Wrong error
f(0, 0);  // Wrong error
f(0); // ICE
}


$ g++ -std=c++1z gcc-test.cpp 
gcc-test.cpp: In instantiation of 'constexpr auto f(Ds ...) [with Ds = {}]':
gcc-test.cpp:11:4:   required from here
gcc-test.cpp:5:30: error: mismatched argument pack lengths while expanding
'calc(n, Ds{})'
return (calc(n, Ds{}), ...);
  ^
gcc-test.cpp: In instantiation of 'constexpr auto f(Ds ...) [with Ds = {int,
int}]':
gcc-test.cpp:12:8:   required from here
gcc-test.cpp:5:30: error: mismatched argument pack lengths while expanding
'calc(n, Ds{})'
gcc-test.cpp: In instantiation of 'f(Ds ...) [with Ds = {int}]:: [with auto:1 = {int}]':
gcc-test.cpp:6:4:   required from 'constexpr auto f(Ds ...) [with Ds = {int}]'
gcc-test.cpp:13:5:   required from here
gcc-test.cpp:5:16: internal compiler error: Segmentation fault
return (calc(n, Ds{}), ...);
^
0xf4671f crash_signal
../../gcc/gcc/toplev.c:341
0xa8c200 tree_check5(tree_node*, char const*, int, char const*, tree_code,
tree_code, tree_code, tree_code, tree_code)
../../gcc/gcc/tree.h:3190
0xa8c200 process_outer_var_ref(tree_node*, int)
../../gcc/gcc/cp/semantics.c:3306
0xa56311 tsubst_copy
../../gcc/gcc/cp/pt.c:14821
0xa42bd5 tsubst_copy
../../gcc/gcc/cp/pt.c:14643
0xa42bd5 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:18125
0xa430f5 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:17522
0xa5125f tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:16959
0xa5125f tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16697
0x6453e1 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:15915
0x6453e1 gen_elem_of_pack_expansion_instantiation
../../gcc/gcc/cp/pt.c:11144
0x6453e1 tsubst_pack_expansion(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:11602
0xa5443c tsubst_fold_expr_pack
../../gcc/gcc/cp/pt.c:11223
0xa5443c tsubst_unary_right_fold
../../gcc/gcc/cp/pt.c:11339
0xa5443c tsubst_copy
../../gcc/gcc/cp/pt.c:15259
0xa4439c tsubst_copy
../../gcc/gcc/cp/pt.c:14643
0xa4439c tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:18251
0xa5125f tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:16959
0xa5125f tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16697
0xa5108c tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:15940
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.


$ g++ --version
g++ (GCC) 8.0.0 20170919 (experimental)

[Bug fortran/82250] New: Fortran OpenACC acc_on_device early folding

[tschwinge at gcc dot gnu.org]

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

Bug ID: 82250
   Summary: Fortran OpenACC acc_on_device early folding
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: openacc
  Severity: enhancement
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

If a call to the acc_on_device function has a compile-time constant argument,
the function call evaluates to a compile-time constant value only for C and C++
but not for Fortran.  "As far as I remember, the Fortran front end doesn't know
about/doesn't know how to use these GCC builtins"
().

[Bug tree-optimization/82251] New: OpenMP omp_is_initial_device early folding

[tschwinge at gcc dot gnu.org]

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

Bug ID: 82251
   Summary: OpenMP omp_is_initial_device early folding
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: openmp
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

As discussed, similar to how acc_on_device is, "omp_is_initial_device should
also be implemented as a builtin"
();
"omp_is_initial_device [...] eventually can be inlined by the compiler on NVPTX
target or perhaps any ACCEL_COMPILER, but we need to provide a library version
anyway, you can take address of the function etc."
().

Fortran handling is expected to require more effort than C and C++, see
PR82250.

As may be necessary, care has to be taken to not break the special handling in
libgomp for Intel MIC offloading
(),
and HSA offloading currently per gcc/hsa-gen.c:hsa_init_simple_builtins expands
omp_is_initial_device to a zero constant.

[Bug libstdc++/82252] New: src/filesystem/ops.cc:392]: (warning) Identical condition

[dcb314 at hotmail dot com]

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

Bug ID: 82252
   Summary: src/filesystem/ops.cc:392]: (warning) Identical
condition
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

[trunk/libstdc++-v3/src/filesystem/ops.cc:390] ->
[trunk/libstdc++-v3/src/filesystem/ops.cc:392]: (warning) Identical condition
'ec', second condition is always false

Source code is

if (ec)
  return false;
if ((from_mtime <= file_time(*to_st, ec)) || ec)
  return false;

This code could probably benefit from a small tidyup.

[Bug fortran/82253] New: internal compiler error: in convert_move, at expr.c:604 (Regression somewhere between 5.4.0 and 6.2.0))

[joachim.herb at gmx dot de]

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

Bug ID: 82253
   Summary: internal compiler error: in convert_move, at
expr.c:604 (Regression somewhere between 5.4.0 and
6.2.0))
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joachim.herb at gmx dot de
  Target Milestone: ---

Created attachment 42205
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42205&action=edit
Module source code resulting in internal compiler error

The attached module source code results in the following error, if compiled
with gfortran 6.3.0, 6.4.0, 7.2.0. It works with 4.9.2, 5.2.0, and 5.4.0. 

It happens, if the option -Og is used. If -g is used, the module is compiled.

The compiler error happens using the Linux and Cygwin version:
Cygwin:

$ gfortran --version
GNU Fortran (GCC) 5.4.0
Copyright (C) 2015 Free Software Foundation, Inc.

$ gfortran -Og -c compiler_bug.f90

$ gfortran --version
GNU Fortran (GCC) 6.4.0
Copyright (C) 2017 Free Software Foundation, Inc.

$ gfortran -Og -c compiler_bug.f90
compiler_bug.f90:50:0:

   obj = transfer( zero, obj )

internal compiler error: in convert_move, at expr.c:644

compiler_bug.f90:50:0: internal compiler error: Segmentation fault
mmap: No such device
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


Linux:

gcc (GCC) 7.2.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

> gfortran -c compiler_bug.f90  -g
> gfortran -c compiler_bug.f90  -Og
compiler_bug.f90:50:0:

   obj = transfer( zero, obj )

internal compiler error: in convert_move, at expr.c:604
0x85b18b convert_move(rtx_def*, rtx_def*, int)
../../gcc-7.2.0/gcc/expr.c:604
0x861773 store_expr_with_bounds(tree_node*, rtx_def*, int, bool, bool,
tree_node*)
../../gcc-7.2.0/gcc/expr.c:5629
0x8628d1 expand_assignment(tree_node*, tree_node*, bool)
../../gcc-7.2.0/gcc/expr.c:5110
0x774f00 expand_gimple_stmt_1
../../gcc-7.2.0/gcc/cfgexpand.c:3639
0x774f00 expand_gimple_stmt
../../gcc-7.2.0/gcc/cfgexpand.c:3737
0x7764cf expand_gimple_basic_block
../../gcc-7.2.0/gcc/cfgexpand.c:5744
0x77b636 execute
../../gcc-7.2.0/gcc/cfgexpand.c:6357
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug libstdc++/82252] src/filesystem/ops.cc:392]: (warning) Identical condition

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
No, because the call to file_time can set 'ec', so even if (bool)ec is
originally false, it can become true.

[Bug libstdc++/82252] src/filesystem/ops.cc:392]: (warning) Identical condition

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
What tool produces this warning?

[Bug c++/82254] New: std::is_nothrow_invocable is broken

[bolero.murakami at gmail dot com]

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

Bug ID: 82254
   Summary: std::is_nothrow_invocable is broken
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bolero.murakami at gmail dot com
  Target Milestone: ---

std::is_nothrow_invocable is broken.

example:

struct X {
X(int x) { throw x; }
};
int f(int x) noexcept { return x; }
using F = decltype(f);


INVOKE(F, int) throws exception,
but std::is_nothrow_invocable_r_v is true.
Should actually return false.

Run code(wandbox): https://wandbox.org/permlink/WDeMGw6zbAZ7pYk1

[Bug c++/82246] Wrong optimisation of an offset double* attribute class allocated in stack

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Taking the address of array [-1] is undefined according to the c standard.

[Bug tree-optimization/82244] [7/8 Regression] -O2: ICE: tree check: expected ssa_name, have integer_cst in replace_uses_by, at tree-cfg.c:1904

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Tue Sep 19 11:57:39 2017
New Revision: 252973

URL: https://gcc.gnu.org/viewcvs?rev=252973&root=gcc&view=rev
Log:
2017-09-19  Richard Biener  

PR tree-optimization/82244
* tree-vrp.c (remove_range_assertions): Do not propagate
a constant to abnormals but replace the assert with a copy.

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

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr82244.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vrp.c

[Bug libstdc++/82254] std::is_nothrow_invocable_r is broken

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-09-19
  Component|c++ |libstdc++
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
#include 

struct X {
X(int x) { throw x; }
};
int f(int x) noexcept { return x; }
using F = decltype(f);

static_assert( !std::is_nothrow_invocable_r_v );

[Bug tree-optimization/82244] [7 Regression] -O2: ICE: tree check: expected ssa_name, have integer_cst in replace_uses_by, at tree-cfg.c:1904

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||8.0
Summary|[7/8 Regression] -O2: ICE:  |[7 Regression] -O2: ICE:
   |tree check: expected|tree check: expected
   |ssa_name, have integer_cst  |ssa_name, have integer_cst
   |in replace_uses_by, at  |in replace_uses_by, at
   |tree-cfg.c:1904 |tree-cfg.c:1904
  Known to fail||7.2.0

--- Comment #6 from Richard Biener  ---
Fixed on trunk sofar.

[Bug libstdc++/82252] src/filesystem/ops.cc:392]: (warning) Identical condition

[dcb314 at hotmail dot com]

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

--- Comment #3 from David Binderman  ---
(In reply to Jonathan Wakely from comment #2)
> What tool produces this warning?

cppcheck, available from sourceforge.

My apologies for the false positive.

[Bug middle-end/82253] internal compiler error: in convert_move, at expr.c:604 (Regression somewhere between 5.4.0 and 6.2.0))

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-09-19
  Component|fortran |middle-end
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
With -Og we end up with

  complex(kind=16) transfer.1;
  static integer(kind=1) zero[32] = {};
  complex(kind=16) obj;
  complex(kind=16) transfer.3_1;
  __complex__ uint128_t _4;

   [100.00%] [count: INV]:
  _4 = MEM[(c_char * {ref-all})&zero];
  MEM[(c_char * {ref-all})&transfer.1] = _4;
  transfer.3_1 = transfer.1;
  obj = transfer.3_1;
  transfer.1 ={v} {CLOBBER};

which ends up as

#2  0x00b94512 in convert_mode_scalar (to=0x76a50bb8, 
from=0x76a56018, unsignedp=1) at /tmp/trunk2/gcc/expr.c:280
280   scalar_mode from_mode = as_a  (GET_MODE (from));
(gdb) p from
$1 = (rtx) 0x76a56018
(gdb) p debug_rtx (from)
(mem/u/c:CTI (reg/f:DI 96) [0 MEM[(c_char * {ref-all})&zero]+0 S32 A256])

as you see this is a complex mode, not a scalar one.  convert_move is called
with

(gdb) p debug_rtx (target)
(concat:TC (reg:TF 91 [ transfer.1 ])
(reg:TF 92 [ transfer.1+16 ]))
$5 = void
(gdb) p debug_rtx (temp)
(mem/u/c:CTI (reg/f:DI 96) [0 MEM[(c_char * {ref-all})&zero]+0 S32 A256])

but convert_move isn't prepared to handle this kind of move.

With -O1 we expand from the simpler

  __complex__ uint128_t _24;
  complex(kind=16) _26;

   [100.00%] [count: INV]:
  _24 = MEM[(c_char * {ref-all})&zero];
  _26 = VIEW_CONVERT_EXPR(_24);
  obj = _26;

this "transform" requires two FRE pass instances as in the first we are
presented with

  parm.0.data = &zero[0];
  parm.0.offset = -1;
  _3 = parm.0.dim[0].ubound;
  _4 = parm.0.dim[0].lbound;
  _23 = _3 - _4;
  _5 = _23 + 1;
  _6 = MIN_EXPR <_5, 32>;
  _7 = MAX_EXPR <_6, 0>;
  _8 = (unsigned long) _7;
  _9 = parm.0.data;
  __builtin_memcpy (&transfer.1, _9, _8);
  transfer.3_10 = transfer.1;
  obj = transfer.3_10;

which gets optimized to

  _22 = MEM[(c_char * {ref-all})&zero];
  MEM[(c_char * {ref-all})&transfer.1] = _22;
  transfer.3_10 = transfer.1;

only during folding of the memcpy during elimination of the first pass.  We
do not expose the memcpy result in the VN hashtable when looking through it
(not sure if that would be easily possible).

[Bug c++/82247] [concepts] Name deduction in concepts fails depending on the argument type

[mjklaim at gmail dot com]

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

--- Comment #1 from Joël Lamotte  ---
Just so that it's clear, it's on godbolt's compiler that I tried this:
https://godbolt.org/g/d78J4H

[Bug tree-optimization/80213] [7/8 Regression] ICE in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:704

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
I can't reproduce either issue on trunk or the GCC 7 branch.  Assuming fixed
(might want to bisect what fixed it/them).

[Bug tree-optimization/59859] [meta-bug] GRAPHITE issues

[rguenth at gcc dot gnu.org]

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

Bug 80213 Summary: [7/8 Regression] ICE in check_loop_closed_ssa_use, at 
tree-ssa-loop-manip.c:704
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80213

   What|Removed |Added

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

[Bug c++/82246] Wrong optimisation of an offset double* attribute class allocated in stack

[erwan.adam at cea dot fr]

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

--- Comment #2 from erwan.adam at cea dot fr ---
(In reply to Andrew Pinski from comment #1)
> Taking the address of array [-1] is undefined according to the c standard.

Hi Andrew,

Thanks for you answer.

Strictly speaking, I don't access directly array[-1].
It will be the case if I have written _container(&data[-offset]).
In my case, I write _container(data-offset) and after I always
take indexes >= offset to access _container values.
Doing that, neither valgrind or sanitize complains.

Moreover, this piece of code works perfectly if CIS_data is
allocated in the heap via a double* CIS_data = new double[1];
and once again, neither valgrind or sanitize complains.

I possible, could you point me a link where I can find more
informations about this particular point ?

E.A.

[Bug tree-optimization/59859] [meta-bug] GRAPHITE issues

[marxin at gcc dot gnu.org]

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

Bug 80213 Summary: [7/8 Regression] ICE in check_loop_closed_ssa_use, at 
tree-ssa-loop-manip.c:704
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80213

   What|Removed |Added

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

[Bug tree-optimization/80213] [7/8 Regression] ICE in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:704

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Last reconfirmed||2017-09-19
 Resolution|FIXED   |---
 Ever confirmed|0   |1

--- Comment #4 from Martin Liška  ---
I can, even with GCC 7.2 release, please add -fchecking.

[Bug c++/82246] Wrong optimisation of an offset double* attribute class allocated in stack

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
&array [-1] and &array [0] - 1 are the same and still both undefined.

[Bug sanitizer/81068] Sanitizer memory leak in codecvt_utf8

[piotr.stachura at delphi dot com]

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

--- Comment #2 from Piotr Stachura  ---
I have to check it deeper.
I have 2 systems - one gentoo and one Ubuntu.
On Ubuntu, code is correct (as I posted in bug report).
When I compile this same code on gentoo (gcc-5.4.0 and gcc-7.2.0) I have this
same results as you "terminate called after throwing an instance of
'std::range_error'".
Maybe a locale settings are making a difference...
LANG=pl_PL.utf8 vs LANG=pl_PL.UTF-8

On ubuntu:

valgrind ./1

==2581== Memcheck, a memory error detector
==2581== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==2581== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info
==2581== Command: ./1
==2581== 
==2581== 
==2581== HEAP SUMMARY:
==2581== in use at exit: 0 bytes in 0 blocks
==2581==   total heap usage: 3 allocs, 3 frees, 72,794 bytes allocated
==2581== 
==2581== All heap blocks were freed -- no leaks are possible
==2581== 
==2581== For counts of detected and suppressed errors, rerun with: -v
==2581== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 6.2.0-7ubuntu11'
--with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-6 --program-prefix=x86_64-linux-gnu- --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 6.2.0 20161018 (Ubuntu 6.2.0-7ubuntu11)

[Bug sanitizer/81715] asan-stack=1 redzone allocation is too inflexible

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #5 from Martin Liška  ---
I can confirm that for the biggest function 'nl80211_send_wiphy', it really
contains majority of stack variables which are 4B large. Having an adaptive
redzone mechanism, one can effectively save half of stack. That will still not
be enough for 1024B.

Anyway, I there's another example where one needs to limit (or disable ASAN) in
kernel: https://patchwork.kernel.org/patch/9653417/

Jakub what's your opinion on this?

[Bug tree-optimization/82255] New: Vectorizer cost model overcounts cost of some vectorized loads

[wschmidt at gcc dot gnu.org]

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

Bug ID: 82255
   Summary: Vectorizer cost model overcounts cost of some
vectorized loads
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wschmidt at gcc dot gnu.org
  Target Milestone: ---

Consider the following testcase, compiled at -O3 on powerpc64le:

extern int abs (int __x) __attribute__ ((__nothrow__, __leaf__)) __attribute__
\
((__const__));

static int
foo (unsigned char *w, int i, unsigned char *x, int j)
{
  int tot = 0;
  for (int a = 0; a < 16; a++)
{
  for (int b = 0; b < 16; b++)
tot += abs (w[b] - x[b]);  (*)
  w += i;
  x += j;
}
  return tot;
}

void
bar (unsigned char *w, unsigned char *x, int i, int *result)
{
  *result = foo (w, 16, x, i);
}

The salient feature here is that we process 16 characters from "w" at
a time, and each time through the "a" loop we increment the "w"
pointer by 16; and we process 16 characters from "x" at a time, but
here each time through the "a" loop we increment the "x" pointer by an
unknown but unchanging value.

Since we don't know the alignment of either "w" or "x", it is logical
to assume that vectorizing this loop on a machine with a 128-bit
vector size will treat both "w" and "x" the same.  The 16 loads of
characters from each array can be combined into a single unaligned
load of a 16-byte vector.  And indeed, this is the code that the
vectorizer produces.  It is only the stride *between* vector loads
that differs; one is constant and the other is variable.

However, the vector cost model does NOT produce the same results for
"w" and "x".  For "w", the cost model represents the combined loads as
a single "unaligned_load" vect_cost_for_stmt.  For "x", the cost model
represents them as an "unaligned_load" followed by a "vec_construct".
This wrongly makes the load of "x" look a good deal more expensive
than the load of "w".

Now, how does this happen?  Prior to vectorization, the "b" loop is
completely unrolled, exposing the main computation (*) to SLP
vectorization.  In tree-vect-slp.c:vect_analyze_slp_cost_1, we find
that for "x" (but not "w"), STMT_VINFO_STRIDED_P (stmt_info) is TRUE,
and this causes us to assume a memory access type of
VMAT_STRIDED_SLP.  That value is passed to tree-vect-stmts.c:
vect_model_load_cost, which first records the cost of the load, and
then (because of the memory access type VMAT_STRIDED_SLP) also records
a vec_construct cost.

This would be appropriate if the loads making up the vectorized load
didn't already form a full vector, so that a strided load of elements
were being loaded.  For example, if we loaded 4 characters at a time
and then skipped ahead by an unknown stride amount to get the next 4,
a strided load of four 32-bit elements would indeed require a
vec_construct.  But that's not the case here.

Going back a bit further, STMT_VINFO_STRIDED_P (stmt_info) is set to
TRUE in tree-vect-data-refs.c:vect_analyze_data_refs, because the
group of data references appears within a loop, and the DR_STEP for
the group is not a constant.  Note that the analysis is done for the
outer loop, but is consumed when doing SLP vectorization on the
unrolled inner loop (on the loop body of the outer loop).

Looking at tree-vect-stmts.c:vectorizable_load, we don't actually
generate the constructor unless the number of loads we're going to
generate is greater than 1.  So we're missing the corresponding logic
in the analysis phase.

I'm working on a patch.

[Bug sanitizer/81068] Sanitizer memory leak in codecvt_utf8

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||redi at gcc dot gnu.org

--- Comment #3 from Martin Liška  ---
Adding Jonathan, can you please take a look whether it's a valid or invalid
code?

[Bug tree-optimization/82255] Vectorizer cost model overcounts cost of some vectorized loads

[wschmidt at gcc dot gnu.org]

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

--- Comment #1 from Bill Schmidt  ---
Created attachment 42206
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42206&action=edit
Patch under test

Here's a patch I'm testing.  It solves the problem for this test case but
hasn't been regstrapped yet.

[Bug tree-optimization/82255] Vectorizer cost model overcounts cost of some vectorized loads

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||missed-optimization
   Last reconfirmed||2017-09-19
 CC||rguenth at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |wschmidt at gcc dot 
gnu.org
 Ever confirmed|0   |1
   Target Milestone|--- |8.0
  Known to fail||7.2.1, 8.0

[Bug c++/82246] Wrong optimisation of an offset double* attribute class allocated in stack

[erwan.adam at cea dot fr]

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

--- Comment #4 from erwan.adam at cea dot fr ---
Ok

[Bug ipa/82256] New: regression: clones created by create_version_clone_with_body are not observable to insertion hooks

[pageexec at gmail dot com]

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

Bug ID: 82256
   Summary: regression: clones created by
create_version_clone_with_body are not observable to
insertion hooks
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pageexec at gmail dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

the following

commit 35ee1c662b92e8c6475d4eab310bf33371708a28
Author: marxin 
Date:   Mon Aug 25 13:01:47 2014 +

IPA C++ refactoring 4/N

introduced a presumably unintended change in
cgraph_node::create_version_clone_with_body:

@@ -970,14 +972,14 @@ cgraph_node::create_version_clone_with_body
   /* Update the call_expr on the edges to call the new version node. */
   update_call_expr (new_version_node);

-  new_version_node->call_function_insertion_hooks ();
+  symtab->call_cgraph_insertion_hooks (this);
   return new_version_node;
 }

notice how 'this' is passed to call_cgraph_insertion_hooks instead of the
previously passed new_version_node. this makes new nodes unobservable to such
hooks and also makes 'this' observed as many times as these clones are created,
both broke existing behaviour i think. the correct change should be:

  symtab->call_cgraph_insertion_hooks (new_version_node);

i hope this can be fixed in time for the last 5.x release (and of course also
all the newer versions, master is affected).

[Bug tree-optimization/81373] [7/8 Regression] Graphite ICE in ssa_default_def at gcc/tree-dfa.c:305

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
The following patch fixes this.  We fail to handle scev_analyzable_p
loop-closed
PHIs that are live-out to the region.

Index: gcc/graphite-scop-detection.c
===
--- gcc/graphite-scop-detection.c   (revision 252968)
+++ gcc/graphite-scop-detection.c   (working copy)
@@ -1717,17 +1717,20 @@ build_cross_bb_scalars_def (scop_p scop,
   if (!def || !is_gimple_reg (def))
 return;

-  /* Do not gather scalar variables that can be analyzed by SCEV as they can
be
- generated out of the induction variables.  */
-  if (scev_analyzable_p (def, scop->scop_info->region))
-return;
+  bool scev_analyzable = scev_analyzable_p (def, scop->scop_info->region);

   gimple *use_stmt;
   imm_use_iterator imm_iter;
   FOR_EACH_IMM_USE_STMT (use_stmt, imm_iter, def)
-if ((def_bb != gimple_bb (use_stmt) && !is_gimple_debug (use_stmt))
-   /* PHIs have their effect at "BBs" on the edges.  See PR79622.  */
-   || gimple_code (SSA_NAME_DEF_STMT (def)) == GIMPLE_PHI)
+/* Do not gather scalar variables that can be analyzed by SCEV as they can
+   be generated out of the induction variables.  */
+if ((! scev_analyzable
+/* But gather SESE liveouts as we otherwise fail to rewrite their
+   exit PHIs.  */
+|| ! bb_in_sese_p (gimple_bb (use_stmt), scop->scop_info->region))
+   && ((def_bb != gimple_bb (use_stmt) && !is_gimple_debug (use_stmt))
+   /* PHIs have their effect at "BBs" on the edges.  See PR79622.  */
+   || gimple_code (SSA_NAME_DEF_STMT (def)) == GIMPLE_PHI))
   {
writes->safe_push (def);
DEBUG_PRINT (dp << "Adding scalar write: ";

[Bug sanitizer/81068] Sanitizer memory leak in codecvt_utf8

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
The difference in results isn't very relevant. I'm pretty sure the reason for
the sanitizer errors is that libstdc++.so isn't instrumented by the sanitizers.
If you build libstdc++.so with UBsan you wouldn't get the errors (although last
time I tried, building libstdc++.so with UBsan isn't possible due to compiler
bugs).

[Bug sanitizer/81068] Sanitizer memory leak in codecvt_utf8

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED
 Ever confirmed|1   |0

--- Comment #5 from Jonathan Wakely  ---
The code is invalid (I have no idea why it doesn't throw an exception on
Ubuntu).

The correct end of the string is input_data + 8 not &input_data[7]

[Bug sanitizer/81068] Sanitizer memory leak in codecvt_utf8

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
If you use &input_data[7] then you do not have valid UTF-8 input, because it
ends with an incomplete multibyte character, "\xCD", instead of "\CD\x8B"

Microsoft Dynamics Users Email List

[Brooke Stewart]

Hi,

Trust my email discovers you well.

Are you looking out to acquire the list of customers or companies using 
Microsoft Dynamics Users Info?

We also have Microsoft Products which you may be interested in:-



Microsoft Dynamics SL


Microsoft Dynamics AX


Microsoft Dynamics ERP


Microsoft Yammer


Microsoft Azure


Microsoft Dynamics NAV


Microsoft SharePoint


Microsoft Dynamics CRM


Microsoft Access


Microsoft Dynamics GP


Microsoft Power BI


Microsoft Dynamics 365




Please drop us a quick email with your thoughts when you get the chance and I 
can send you samples on the same for you to test our quality.



If you have any other unique requirement and if it is not mentioned above, 
please feel free to share your requirement with us as we can help you with 
on-demand list customized as per your requirement.

Regards,

Brooke Stewart

Technology list consultant

Demand generation team



 To Opt Out, please respond "Over Look" in the 
Subject line.

[Bug c/81854] weak alias of an incompatible symbol accepted

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
Author: msebor
Date: Tue Sep 19 14:27:32 2017
New Revision: 252976

URL: https://gcc.gnu.org/viewcvs?rev=252976&root=gcc&view=rev
Log:
PR c/81854 - weak alias of an incompatible symbol accepted

gcc/ChangeLog:

PR c/81854
* cgraphunit.c (handle_alias_pairs): Reject aliases between functions
of incompatible types.

gcc/testsuite/ChangeLog:

PR c/81854
* gcc.dg/pr81854.c: New test.
* g++.dg/ext/attr-ifunc-5.C: New test.
* g++.dg/ext/attr-ifunc-1.C: Adjust.
* g++.dg/ext/attr-ifunc-2.C: Same.
* g++.dg/ext/attr-ifunc-3.C: Same.
* g++.dg/ext/attr-ifunc-4.C: Same.
* g++.old-deja/g++.abi/vtable2.C: Same.
* gcc.dg/attr-ifunc-1.c: Same.

Added:
trunk/gcc/testsuite/g++.dg/ext/attr-ifunc-5.C
trunk/gcc/testsuite/gcc.dg/pr81854.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraphunit.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/ext/attr-ifunc-1.C
trunk/gcc/testsuite/g++.dg/ext/attr-ifunc-2.C
trunk/gcc/testsuite/g++.dg/ext/attr-ifunc-3.C
trunk/gcc/testsuite/g++.dg/ext/attr-ifunc-4.C
trunk/gcc/testsuite/g++.old-deja/g++.abi/vtable2.C
trunk/gcc/testsuite/gcc.dg/attr-ifunc-1.c

[Bug fortran/82257] New: f951: Internal compiler error segmentation fault

[only_for_nouse at gmx dot de]

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

Bug ID: 82257
   Summary: f951: Internal compiler error segmentation fault
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: only_for_nouse at gmx dot de
  Target Milestone: ---

Created attachment 42207
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42207&action=edit
Fortran source code for a simple vector class

compiling the PVector.F90 file with gfortran gives
f951: internal compiler error: Segmentation fault

Source code is still buggy, but the errors should be reported.

[Bug tree-optimization/69728] [6/7/8 Regression] internal compiler error: in outer_projection_mupa, at graphite-sese-to-poly.c:1175

[spop at gcc dot gnu.org]

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

--- Comment #19 from Sebastian Pop  ---
> So how'd we properly handle a valid empty domain?

DCE the statement.

If the domain for a statement is empty, it means that the statement does not
execute: it is dead code.

I think we are better enforcing the elimination of the statement as this wrong
analysis (or translation) of the number of iterations could produce wrong code.

> I assume P_21 is c.7_12

the number after P_ is the ssa variable number, so P_21 is c.7_21.

> we have 0 <= i1 <= 2147483637, whereever that comes from.

you can think about i1 as a canonical induction variable: 0 <= i1
and i1 is indexing all iterations in that loop: i.e., i1 is incremented by 1.

> Probably from the i1 <= 2147483637 constraint

this constraint is added based on the type of the induction variable that gives
an upper bound for the iteration domain.

> 4294967296*floor((-1 - P_21)/4294967296) < -P_21 - i1

Yes, this constraint seems to be wrong.

[Bug c/81854] weak alias of an incompatible symbol accepted

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Sebor  ---
Fixed in r252976.

[Bug libstdc++/82254] std::is_nothrow_invocable_r is broken

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Tue Sep 19 14:33:51 2017
New Revision: 252977

URL: https://gcc.gnu.org/viewcvs?rev=252977&root=gcc&view=rev
Log:
PR libstdc++/82254 fix std::is_nothrow_invocable_r w.r.t throwing conversions

PR libstdc++/82254
* include/std/type_traits (__is_invocable): Add partial specialization
for INVOKE case and remove is_void check from partial
specialization for INVOKE case.
(__is_nt_invocable_impl): New helper for is_nothrow_invocable_r.
(is_nothrow_invocable_r): Use __is_nt_invocable_impl.
* testsuite/20_util/is_nothrow_invocable/value.cc: Add tests for
conversions that can throw or fail to convert. Use static assert
strings to explain negative results.
* testsuite/20_util/is_nothrow_invocable/value_ext.cc: Use
is_nothrow_constructible in is_nt_invocable_conv.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/type_traits
trunk/libstdc++-v3/testsuite/20_util/is_nothrow_invocable/value.cc
trunk/libstdc++-v3/testsuite/20_util/is_nothrow_invocable/value_ext.cc

[Bug libstdc++/82254] std::is_nothrow_invocable_r is broken

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |7.3

--- Comment #3 from Jonathan Wakely  ---
Fixed on trunk so far.

[Bug tree-optimization/79622] [6/7 Regression] Wrong code w/ -O2 -floop-nest-optimize

[spop at gcc dot gnu.org]

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

--- Comment #10 from Sebastian Pop  ---
> So a black-box would be a set of stmts rather than a whole GIMPLE BB

Correct: this can be an abstract view of the IR.  The only place where we want
to start transforming the code is in the code generation.  We should be able to
interrupt graphite at any point (maybe due to a compute-out) and leave the
original unmodified IR.  Code generation should not fail and it should be
linear time in number of statements, such that when we start code generation we
know that it will succeed in a short amount of compilation time.

> You mean this tagging of associativeness is not yet done?

Yes, we removed the tagging code when we removed the out-of-ssa translation.
The original tagging relied on the name of the arrays that we created to find
whether the reduction was associative.  This caused some performance
regressions of loops not interchanged anymore (for example the swim loop.)

[Bug tree-optimization/81373] [7/8 Regression] Graphite ICE in ssa_default_def at gcc/tree-dfa.c:305

[spop at gcc dot gnu.org]

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

--- Comment #4 from Sebastian Pop  ---
The patch looks good.  Thanks!

[Bug fortran/82258] New: [regression] allocate_zerosize_3.f fails since r251949

[clyon at gcc dot gnu.org]

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

Bug ID: 82258
   Summary: [regression] allocate_zerosize_3.f fails since r251949
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

Hi,

Since r251949, I've noticed regressions on armeb:
FAIL:gfortran.dg/allocate_zerosize_3.f   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL:gfortran.dg/allocate_zerosize_3.f   -O3 -g  execution test
FAIL:gfortran.dg/assumed_rank_1.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL:gfortran.dg/assumed_rank_1.f90   -O3 -g  execution test
FAIL:gfortran.dg/assumed_rank_2.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL:gfortran.dg/assumed_rank_2.f90   -O3 -g  execution test

target: armeb-none-linux-gnueabihf
--with-cpu=cortex-a9
--with-fpu=neon-fp16

The same tests pass if GCC is configured --with-fpu=vfpv3-d16-fp16

[Bug target/82150] Produces a branch prefetch which causes a hang

[mgretton at gcc dot gnu.org]

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

mgretton at gcc dot gnu.org changed:

   What|Removed |Added

 CC||mgretton at gcc dot gnu.org

--- Comment #4 from mgretton at gcc dot gnu.org ---
As you suggest in your original comment this hang could be coming from the
instruction pre-fetch going to some place in memory that is mapped (and
executable) but the memory system is not giving a response to memory accesses
to that location.

As a general point all read sensitive devices must be marked as XN to prevent
speculative corruption of those read sensitive devices by instruction fetch
(this is true on future versions of the architecture as well).

Can you ensure that the XN-bit is set on memory pages mapped to read-sensitive
devices?

(XN description ARM11 MP Core TRM:
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0360f/CACHFICI.html)

[Bug middle-end/80295] [7/8 Regression] ICE in __builtin_update_setjmp_buf expander

[qing.zhao at oracle dot com]

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

--- Comment #4 from Qing Zhao  ---
working on a fix to this bug.
let me know if you are working on it too.

[Bug middle-end/80295] [7/8 Regression] ICE in __builtin_update_setjmp_buf expander

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |qing.zhao at oracle dot 
com

--- Comment #5 from Paolo Carlini  ---
Working on it.

[Bug target/47769] [missed optimization] use of btr (bit test and reset)

[peter at cordes dot ca]

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

Peter Cordes  changed:

   What|Removed |Added

 CC||peter at cordes dot ca

--- Comment #6 from Peter Cordes  ---
This seems to be partially fixed in gcc8.0:

#include 
uint64_t btr_variable(uint64_t x, unsigned bit) {
//bit = 53;  // produces btr in older gcc, too.
return x & ~(1ULL << bit);
}
movq%rdi, %rax
btrq%rsi, %rax
ret

vs. gcc7.2 -O3 -mtune=haswell
movl%esi, %ecx
movq$-2, %rdx
rolq%cl, %rdx
movq%rdx, %rax  # this is dumb, should have put the mask in rax
in the first place
andq%rdi, %rax
ret

Or with bit=53:
movabsq $-9007199254740993, %rax
andq%rdi, %rax
ret

btr $53, %rax  only has 2 per clock throughput instead of 4 per clock for AND,
but a 10-byte mov instruction to set up the constant is almost never going to
be worth it for -mtune=haswell.  It takes up extra slots in the uop cache.

---

The inner loop from the Matthias's attached program *really* confuses gcc, so
badly that it never gets to the btr pattern, apparently.

unsigned long cfunc_one(unsigned long tmp) {
for (unsigned long bit = 0; bit < sizeof(unsigned long) * 8; bit += 3) {
tmp &= ~(1UL << bit);
}
return tmp;
}

movq%rdi, %rax
xorl%ecx, %ecx
movl$1, %esi
.L5:
movq%rsi, %rdx   # start with 1UL every time
salq%cl, %rdx
addq$3, %rcx
notq%rdx # what happened to rotating -2?
andq%rdx, %rax
cmpq$66, %rcx
jne .L5
ret


This is obviously horrible, but the right answer isn't btr in a loop, it's what
clang does:

movabsq $7905747460161236406, %rax # imm = 0x6DB6DB6DB6DB6DB6 every
third bit unset
andq%rdi, %rax
retq

gcc does spot this with `bit += 7`, I guess because with fewer iterations it
decides to try fully unrolling and then can optimize.

With a constant shift count and an inline function call, gcc manages to get
really confused auto-vectorizing the loop:

uint64_t btr64(uint64_t x, unsigned bit) {
bit = 53;
return x & ~(1ULL << bit);
}

unsigned long cfunc_one(unsigned long tmp) {
for (unsigned long bit = 0; bit < sizeof(unsigned long) * 8; bit += 7) {
//tmp &= ~(1UL << bit);
tmp = btr64(tmp, bit);
}
return tmp;
}


movdqa  .LC0(%rip), %xmm0# constant with both halves the same.
movdqa  %xmm0, %xmm1
psrldq  $8, %xmm1
pand%xmm1, %xmm0
movq%xmm0, %rax
 # The above is equivalent to mov .LC0(%rip), %rax
andq%rdi, %rax
ret



(In reply to Richard Biener from comment #1)
> Can you provide a testcase that can be compiled please?
> 
> Cut&pasting from i386.md:
> 
> ;; %%% bts, btr, btc, bt.
> ;; In general these instructions are *slow* when applied to memory,
> ;; since they enforce atomic operation.

This error is fixed in the current version 
https://raw.githubusercontent.com/gcc-mirror/gcc/master/gcc/config/i386/i386.md.

They're slow because of crazy-CISC semantics, and aren't atomic without a lock
prefix.  btr %rax, (%rdi) uses %rax as a bit index into memory relative to
%rdi, so the actual byte or dword or qword eventually accessed is *not*
determined by the addressing mode alone.  It's micro-coded as several uops.

>  When applied to registers,
> ;; it depends on the cpu implementation.  They're never faster than
> ;; the corresponding and/ior/xor operations, so with 32-bit there's
> ;; no point.  But in 64-bit, we can't hold the relevant immediates
> ;; within the instruction itself, so operating on bits in the high
> ;; 32-bits of a register becomes easier.

This section is talking about using it with an immediate operand like
  btr  $53, %raxbecause  and $imm64, %rax  doesn't exist, only and
$sign_extended_imm32, %rax

Does `(set_attr "type" "alu1")` mean gcc thinks it only has 1 per clock
throughput?  Or that it competes with other "alu1" instructions?

On Intel since Sandybridge, bt/btr/bts/btc reg,reg or imm,reg is 2 per clock. 
It's 1 per clock on Bulldozer-family and Jaguar, 2 per clock on Ryzen.

On Silvermont / KNL, they're 1 per clock occupying both integer ports.

[Bug target/82259] New: missed optimization: use LEA to add 1 to flip the low bit when copying before AND with 1

[peter at cordes dot ca]

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

Bug ID: 82259
   Summary: missed optimization: use LEA to add 1 to flip the low
bit when copying before AND with 1
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: peter at cordes dot ca
  Target Milestone: ---
Target: x86_64-*-*, i?86-*-*

bool bt_signed(int x, unsigned bit) {
bit = 13;
return !(x & (1

[Bug target/82259] missed optimization: use LEA to add 1 to flip the low bit when copying before AND with 1

[peter at cordes dot ca]

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

--- Comment #1 from Peter Cordes  ---
More generally, you can flip a higher bit while copying with

lea  64(%rdi), %eax

That leaves the bits above that position munged by carry-out, but that isn't
always a problem.

[Bug target/82260] New: [x86] Unnecessary use of 8-bit registers with -Os. slightly slower and larger code

[peter at cordes dot ca]

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

Bug ID: 82260
   Summary: [x86] Unnecessary use of 8-bit registers with -Os.
slightly slower and larger code
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: peter at cordes dot ca
  Target Milestone: ---
Target: x86_64-*-*, i?86-*-*

int shift(int x, int c) {
return x >> c;
}
// https://godbolt.org/g/waovLu

gcc8 20170915 -Os -mtune=haswell:
movl%edi, %eax
movb%sil, %cl   # bad
sarl%cl, %eax
ret

-O3:
movl%edi, %eax
movl%esi, %ecx  # good
sarl%cl, %eax
ret

The 8-bit MOV needs a REX prefix to access %sil, and has a false dependency on
the old value of RCX.  Haswell/Skylake don't rename low8 partial registers,
only high8.  https://stackoverflow.com/q/45660139/224132.  P6 and Sandybridge
do, but an 8-bit mov is definitely *not* better when a 32-bit mov is also an
option.

So -Os makes code that's larger and also potentially slower.

[Bug target/82259] missed optimization: use LEA to add 1 to flip the low bit when copying before AND with 1

[ubizjak at gmail dot com]

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

--- Comment #2 from Uroš Bizjak  ---
(In reply to Peter Cordes from comment #0)

> Related:
> 
> bool bt_unsigned(unsigned x, unsigned bit) {
> //bit = 13;
> return !(x & (1< }
> 
> movl%esi, %ecx
> movl$1, %eax
> sall%cl, %eax
> testl   %edi, %eax
> sete%al
> ret
> 
> This is weird.  The code generated with  1U << bit  is like the bt_signed
> code above and has identical results, so gcc should emit whatever is optimal
> for both cases.  There are similar differences on ARM32.
> 
> (With a fixed count, it just makes the difference between NOT vs. XOR $1.)
> 
> If we're going to use setcc, it's definitely *much* better to use  bt 
> instead of a variable-count shift + test.
> 
> bt  %esi, %edi
> setz%al
> ret

A couple of *scc_bt patterns are missing. These are similar to already existing
*jcc_bt patterns. Combine wants:

Failed to match this instruction:
(set (reg:QI 97)
(eq:QI (zero_extract:SI (reg/v:SI 91 [ x ])
(const_int 1 [0x1])
(zero_extend:SI (subreg:QI (reg/v:SI 92 [ bit ]) 0)))
(const_int 0 [0])))

[Bug target/82259] missed optimization: use LEA to add 1 to flip the low bit when copying before AND with 1

[peter at cordes dot ca]

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

--- Comment #3 from Peter Cordes  ---
Oops, BT sets CF, not ZF.  So

bt  $13, %edi
setnc   %al# aka setae
ret

This is what clang does for the bt_ functions, and might be optimal for many
use-cases.  (For branching with an immediate, test/jcc is of course better
because it can macro-fuse into a test+branch uop on Intel and AMD.)

[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

--- Comment #17 from Jonathan Wakely  ---
Author: redi
Date: Tue Sep 19 17:06:12 2017
New Revision: 252981

URL: https://gcc.gnu.org/viewcvs?rev=252981&root=gcc&view=rev
Log:
PR libstdc++/71500 restore C++11 compatibility in 

PR libstdc++/71500
* include/bits/regex_executor.tcc
(_Backref_matcher>::_M_apply): Use
std::__equal4 instead of C++14 4-iterator overloads of std::equal.
* include/bits/stl_algobase.h (__equal4): New functions implementing
4-iterator overloads of std::equal for use in C++11.
(equal(It1, It1, It2, It2), equal(It1, It1, It2, It2, BinaryPred)):
Move function bodies to new __equal4 functions.
* testsuite/28_regex/simple_c++11.cc: New.

Added:
trunk/libstdc++-v3/testsuite/28_regex/simple_c++11.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/regex_executor.tcc
trunk/libstdc++-v3/include/bits/stl_algobase.h

[Bug target/82261] New: x86: missing peephole for SHLD / SHRD

[peter at cordes dot ca]

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

Bug ID: 82261
   Summary: x86: missing peephole for SHLD / SHRD
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: peter at cordes dot ca
  Target Milestone: ---
Target: x86_64-*-*, i?86-*-*

unsigned shld(unsigned a, unsigned b, unsigned n){
//n=13;
a <<= n;
b >>= (32-n); //&31;
return a|b;
}
// https://godbolt.org/g/3jbgbR

g++ (GCC-Explorer-Build) 8.0.0 20170919 -O3 -march=haswell
movl$32, %eax
subl%edx, %eax  # missed optimization: NEG would work
shrx%eax, %esi, %eax
shlx%edx, %edi, %esi
orl %esi, %eax
ret

Intel has efficient SHLD/SHRD, so this should be compiled similar to what clang
does:

movl%edx, %ecx
movl%edi, %eax   # move first so we overwrite a
mov-elimination result right away
shldl   %cl, %esi, %eax
retq

Without SHLD, there's another missed optimization: shifts mask their count, and
32 & 31 is 0, so we could just NEG instead of setting up a constant 32.

shlx%edx, %edi, %eax
neg %edx
shrx%edx, %esi, %esi
orl %esi, %eax
ret

This *might* be worth it on AMD, where SHLD is 7 uops and one per 3 clock
throughput/latency.  Without BMI2, though, it may be good to just use SHLD
anyway.

There are various inefficiencies (extra copying of the shift count) in the
non-BMI2 output, but this bug report is supposed to be about the SHRD/SHLD
peephole.  (I didn't check for SHRD).

[Bug lto/82229] GCC7's LTO underperforms compared to GCC6

[krzysio.kurek at wp dot pl]

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

--- Comment #11 from krzysio.kurek at wp dot pl ---
Done, cmake will now default to Release config with altered compiler flags that
include -flto.

[Bug target/82261] x86: missing peephole for SHLD / SHRD

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
Related to PR 55583.

[Bug target/81647] inconsistent LTGT behavior at different optimization levels on AArch64.

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

 CC||wilco at gcc dot gnu.org

--- Comment #6 from Wilco  ---
(In reply to Steve Ellcey from comment #5)
> Looking at the code and the aarch64 documentation, the non-vectorized
> version does the comparisons with fcmp which is defined as a "quiet compare"
> and only generates an exception for signaling NANs.  The vectorized version
> uses fcmgt and that is defined to raise exceptions.  I am not sure what GCC
> can do here other than manually clear the exceptions that fcmgt raised (Yuk).

Well with -ftrapping-math or -fno-finite-math-only we should emit:

(cmeq(a,a) & cmeq(b,b)) & ~cmeq(a,b)

[Bug fortran/25071] dummy argument larger than actual argument

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #22 from janus at gcc dot gnu.org ---
On the current trunk, the patch produces one failure:

FAIL: gfortran.dg/warn_argument_mismatch_1.f90   -O  (test for excess errors)

Another problem is that it removes the warning for -std=legacy.

Do with it what you will ...

[Bug lto/82229] GCC7's LTO underperforms compared to GCC6

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #12 from Martin Liška  ---
(In reply to krzysio.kurek from comment #11)
> Done, cmake will now default to Release config with altered compiler flags
> that include -flto.

Thanks. I can confirm I can reproduce it on my laptop. Tomorrow, I'll bisect
that.

[Bug target/82240] i386.md & -Wlogical-op in build

[pinskia at gcc dot gnu.org]

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

--- Comment #7 from Andrew Pinski  ---
I think this due to the following from atom.md:
(define_insn_reservation  "atom_icmp" 1
  (and (eq_attr "cpu" "atom")
   (and (eq_attr "type" "icmp")
(eq_attr "memory" "none")))
  "atom-simple-either")

(define_insn_reservation  "atom_icmp_mem" 1
  (and (eq_attr "cpu" "atom")
   (and (eq_attr "type" "icmp")
(eq_attr "memory" "!none")))
  "atom-simple-either")

(define_insn_reservation  "atom_test" 1
  (and (eq_attr "cpu" "atom")
   (and (eq_attr "type" "test")
(eq_attr "memory" "none")))
  "atom-simple-either")

(define_insn_reservation  "atom_test_mem" 1
  (and (eq_attr "cpu" "atom")
   (and (eq_attr "type" "test")
(eq_attr "memory" "!none")))
  "atom-simple-either")


Basically the latency code generator is being a little dumb here (I had similar
issues when writing a scheduler for a new aarch64 processor) but atom.md could
be improved to just say:
(define_insn_reservation  "atom_icmp" 1
  (and (eq_attr "cpu" "atom")
   (and (eq_attr "type" "icmp")
(eq_attr "memory" "none")))
  "atom-simple-either")

(define_insn_reservation  "atom_icmp_mem" 1
  (and (eq_attr "cpu" "atom")
   (eq_attr "type" "icmp"))
  "atom-simple-either")

(define_insn_reservation  "atom_test" 1
  (and (eq_attr "cpu" "atom")
   (and (eq_attr "type" "test")
(eq_attr "memory" "none")))
  "atom-simple-either")

(define_insn_reservation  "atom_test_mem" 1
  (and (eq_attr "cpu" "atom")
   (eq_attr "type" "test"))
  "atom-simple-either")

That is get rid of the check for memory attr on the second case.

[Bug lto/82229] GCC7's LTO underperforms compared to GCC6

[marxin at gcc dot gnu.org]

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

--- Comment #13 from Martin Liška  ---
One another observation: using PGO (-fprofile-generate and -fprofile-use), both
GCC 6 and GCC 7 have similar performance: 34fps. While GCC 6 has 43 fps on my
machine.

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

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #3 from Paul Thomas  ---
Hi Karl and Janus,

I have just noticed that I am responsible for a number of regressions in the
ASSOCIATE construct. I came across your PR in the course of my investigations.
I will attempt to fix it but just note that tehre is a workaround, which
produces correct code.

In Jason's reduced testcase:

s/associate(y => TT)/associate(y => TT(:))/

Cheers

Paul

[Bug target/82150] Produces a branch prefetch which causes a hang

[david.welch at netronome dot com]

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

--- Comment #5 from david.welch at netronome dot com ---
it is definitely doing prefetching by not realizing those instructions are
unconditional branches.  most likely going with strongly ordered rather than
the XN bit but noted as a workaround.  Since the armv4t does not support the
pop pc and there are runtime flags, wanted to first know what options are there
or would they have to be added.  What other cores have been reported as having
this issue, where there any compiler additions made for them?

[Bug target/82240] i386.md & -Wlogical-op in build

[dcb314 at hotmail dot com]

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

David Binderman  changed:

   What|Removed |Added

 CC||hjl at gcc dot gnu.org

--- Comment #8 from David Binderman  ---
I think hjl in revision 145624 back in 2009 either wrote (or maybe
imported from Intel) the code you mentioned in atom.md.

Maybe casting the net wider might help.

[Bug libstdc++/82262] New: std::hash>::operator() missing remove_const_t

[zhangxy at google dot com]

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

Bug ID: 82262
   Summary: std::hash>::operator()  missing
remove_const_t
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhangxy at google dot com
  Target Milestone: ---

std::hash> specialization doesn't work with const-qualified
type. I think the problem is that std::remove_const_t is missing.

For example, the following code will result in compiler error:

#include 

void Foo() {
std::hash> h;
std::optional o(1);
size_t v = h(o);
}

/opt/compiler-explorer/gcc-7.2.0/include/c++/7.2.0/optional: In instantiation
of 'std::size_t std::__optional_hash_call_base<_Tp, 
>::operator()(const std::optional<_Tp>&) const [with _Tp = const int; bool
 = true; std::size_t = long unsigned int]':
6 : :6:19:   required from here
/opt/compiler-explorer/gcc-7.2.0/include/c++/7.2.0/optional:1009:37: error:
could not convert '()' from '' to 'std::__hash_enum'
   noexcept(noexcept(hash<_Tp> {}(*__t)))
 ^~

[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic

[sandra at gcc dot gnu.org]

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #32 from sandra at gcc dot gnu.org ---
Here's another case which I think is the same bug, observed in GCC 7.2:

#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wpedantic"
#include_next 
#pragma GCC diagnostic pop

does nothing to suppress the -Wpedantic warning about #include_next.

[Bug java/82263] New: java multilib -m32 version is using 64 bit include and lib, _GStaticAssertCompileTimeAssertion_0

[gccbugzilla.severach at spamgourmet dot com]

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

Bug ID: 82263
   Summary: java multilib -m32 version is using 64 bit include and
lib, _GStaticAssertCompileTimeAssertion_0
   Product: gcc
   Version: 6.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: java
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gccbugzilla.severach at spamgourmet dot com
  Target Milestone: ---

Snapshot 6-20170913 fixed all glibc 2.26 issues except for the -m32 multilib
version of the java compiler. It halts with

/usr/include/glib-2.0/glib/gmacros.h:232:53: error: size of array
‘_GStaticAssertCompileTimeAssertion_0’ is negative

This is because it is including a 64 bit
/usr/lib/glib-2.0/include/glibconfig.h. I can patch the makefile to get it to
use the 32 bit /usr/lib32/glib-2.0/include/glibconfig.h which completes the
compile then crashes on linking to the 64 bit libs.

$ pacman -Q gcc-multilib glibc
gcc-multilib 7.2.0-1
glibc 2.26-4

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc-multilib/src/gcc/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --enable-multilib --disable-werror
--enable-checking=release --enable-default-pie --enable-default-ssp
Thread model: posix
gcc version 7.2.0 (GCC)