[Bug libstdc++/87619] New: sizeof(std::variant) can be reduced if its variant_size is UCHAR_MAX

[kariya_mitsuru at hotmail dot com]

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

Bug ID: 87619
   Summary: sizeof(std::variant) can be reduced if its
variant_size is UCHAR_MAX
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kariya_mitsuru at hotmail dot com
  Target Milestone: ---

The current implementation of std::variant stores its index() on an unsigned
char member variable (_M_index) if its std::variant_size is less than
UCHAR_MAX.

But I think that its index() can be stored on unsigned char even if its
variant_size is equal to UCHAR_MAX.

cf. https://wandbox.org/permlink/CpVcCKU3526PnDel


FYI: I think that the first template parameter of _Select_int_base is slightly
larger than necessary.
https://gcc.gnu.org/viewcvs/gcc/trunk/libstdc%2B%2B-v3/include/std/variant?revision=264786&view=markup#l365

[Bug libstdc++/87618] New: Missing symbol for std::__cxx11::basic_stringbuf, std::allocator >::basic_stringbuf()

[daniel at constexpr dot org]

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

Bug ID: 87618
   Summary: Missing symbol for std::__cxx11::basic_stringbuf, std::allocator
>::basic_stringbuf()
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daniel at constexpr dot org
  Target Milestone: ---

$ cat stringbuf.cpp 
#include 

int main() {
std::stringbuf sb;
return 0;
}

$ g++ stringbuf.cpp 
/usr/bin/ld: /tmp/ccKu7olJ.o: in function `main':
stringbuf.cpp:(.text+0x11): undefined reference to
`std::__cxx11::basic_stringbuf,
std::allocator >::basic_stringbuf()'
collect2: error: ld returned 1 exit status

$ g++ --version
g++ (GCC) 9.0.0 20181014 (experimental)
Copyright (C) 2018 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.

[Bug c/51628] __attribute__((packed)) is unsafe in some cases (i.e. add -Waddress-of-packed-member, etc.)

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic
URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2018-09/msg01452.ht
   ||ml
 Blocks||87403
Summary|__attribute__((packed)) is  |__attribute__((packed)) is
   |unsafe in some cases|unsafe in some cases (i.e.
   ||add
   ||-Waddress-of-packed-member,
   ||etc.)

--- Comment #53 from Eric Gallager  ---
latest version of patch adding -Waddress-of-packed-member is here:
https://gcc.gnu.org/ml/gcc-patches/2018-09/msg01452.html 

(In reply to W.H. Ding from comment #52)
> (In reply to rguent...@suse.de from comment #48)
> 
> So, is there an old bug that covers my problem, or should I file a new one?
> Thank you.

If there is an old bug, I don't know of it. I'd just file a new one and we can
close it as a duplicate if in fact someone can find an old bug it's a dup of


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403
[Bug 87403] [Meta-bug] Issues that suggest a new warning

[Bug target/85593] [6/7/8/9 Regression] GCC on ARM allocates R3 for local variable when calling naked function with O2 optimizations enabled

[austinpmorton at gmail dot com]

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

--- Comment #9 from Austin Morton  ---
Apologies for letting this sit so long.

I spent an afternoon digging through some of the mentioned functions trying to
familiarize myself with everything but I didn't make it further than that.

That was a few months ago at this point.  I don't think I have the time to go
back at this point - it's probably better left to someone already familiar with
the compiler.

Thanks,
Austin

[Bug tree-optimization/84648] Missed optimization : loop not removed.

[amker at gcc dot gnu.org]

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

--- Comment #3 from bin cheng  ---
(In reply to Richard Biener from comment #2)
> So we run into
> 
>   /* Ignore loops of while (i-- < 10) type.  */
>   if (code != NE_EXPR)
> {
>   if (iv0->step && tree_int_cst_sign_bit (iv0->step))
> return false;
> 
>   if (!integer_zerop (iv1->step) && !tree_int_cst_sign_bit (iv1->step))
> return false;
> }
> 
> where code == LE_EXPR from 0 <= iv1 with iv1 being {0, +, 1}.
> 
> This specifically singles out loop-until-wrap.  We'd need to teach niter
> analysis this kind of loop.

Thanks, I will have a look how niter analysis should be improved for this.

[Bug testsuite/87617] New test case gfortran.dg/inline_matmul_24.f90 from r265126 doesn't work quite right

[seurer at gcc dot gnu.org]

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from seurer at gcc dot gnu.org ---
yes it was

[Bug libstdc++/87614] User related warnings are hidden in system headers

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #2 from Manuel López-Ibáñez  ---
(In reply to Jonathan Wakely from comment #1)
> This can't be fixed at the moment, due to PR 80472

I'm not even sure how this could be fixed even if PR80472 was fixed. Are we
going to print the following?

In file included from
/opt/compiler-explorer/gcc-8.2.0/include/c++/8.2.0/x86_64-linux-gnu/bits/c++allocator.h:33,
 from
/opt/compiler-explorer/gcc-8.2.0/include/c++/8.2.0/bits/allocator.h:46,
 from
/opt/compiler-explorer/gcc-8.2.0/include/c++/8.2.0/vector:61,
 from :4:
/opt/compiler-explorer/gcc-8.2.0/include/c++/8.2.0/ext/new_allocator.h: In
instantiation of 'void __gnu_cxx::new_allocator<_Tp>::construct(_Up*, _Args&&
...) [with _Up = short unsigned int; _Args = {int}; _Tp = short unsigned int]':
/opt/compiler-explorer/gcc-8.2.0/include/c++/8.2.0/bits/alloc_traits.h:475:4:  
required from 'static void std::allocator_traits
>::construct(std::allocator_traits >::allocator_type&,
_Up*, _Args&& ...) [with _Up = short unsigned int; _Args = {int}; _Tp = short
unsigned int; std::allocator_traits >::allocator_type =
std::allocator]'
/opt/compiler-explorer/gcc-8.2.0/include/c++/8.2.0/bits/vector.tcc:103:30:  
required from 'std::vector<_Tp, _Alloc>::reference std::vector<_Tp,
_Alloc>::emplace_back(_Args&& ...) [with _Args = {int}; _Tp = short unsigned
int; _Alloc = std::allocator; std::vector<_Tp,
_Alloc>::reference = short unsigned int&]'
:10:9:   required from here
/opt/compiler-explorer/gcc-8.2.0/include/c++/8.2.0/ext/new_allocator.h:136:4:
warning: conversion from 'int' to 'short unsigned int' may change value
[-Wconversion]
  { ::new((void *)__p) _Up(std::forward<_Args>(__args)...); }
^

[Bug testsuite/87617] New test case gfortran.dg/inline_matmul_24.f90 from r265126 doesn't work quite right

[seurer at gcc dot gnu.org]

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

--- Comment #1 from seurer at gcc dot gnu.org ---
Maybe fixed by r265175?

[Bug c/87615] Possible excessive compile time with -O2

[dcb314 at hotmail dot com]

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

--- Comment #4 from David Binderman  ---
(In reply to Alexander Monakov from comment #3)
> Looks like gcc-9 regressed here.

Not sure. Adding flag -fno-inline to the compile line:

$  time ~/gcc/results.265139.release/bin/gcc -w -I ../trunk/runtime -O2 -c
-fno-inline destDir/testFile.8458.c 

real0m47.647s
user0m45.990s
sys 0m0.473s

So it seems that if the inline is switched off, compile time reduces a lot
(92%).

$ fgrep -c inline destDir/testFile.8458.c
0
$

Doesn't make much sense to me.

[Bug testsuite/87617] New: New test case gfortran.dg/inline_matmul_24.f90 from r265126 doesn't work quite right

[seurer at gcc dot gnu.org]

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

Bug ID: 87617
   Summary: New test case gfortran.dg/inline_matmul_24.f90 from
r265126 doesn't work quite right
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

New failures (update from 265123 to 265135):
UNRESOLVED: gfortran.dg/inline_matmul_24.f90   -O0   scan-tree-dump-times
optimized "gamma5[__var_1_do * 4 + __var_2_do]" 1
UNRESOLVED: gfortran.dg/inline_matmul_24.f90   -O1   scan-tree-dump-times
optimized "gamma5[__var_1_do * 4 + __var_2_do]" 1
UNRESOLVED: gfortran.dg/inline_matmul_24.f90   -O2   scan-tree-dump-times
optimized "gamma5[__var_1_do * 4 + __var_2_do]" 1
UNRESOLVED: gfortran.dg/inline_matmul_24.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions   scan-tree-dump-times
optimized "gamma5[__var_1_do * 4 + __var_2_do]" 1
UNRESOLVED: gfortran.dg/inline_matmul_24.f90   -O3 -g   scan-tree-dump-times
optimized "gamma5[__var_1_do * 4 + __var_2_do]" 1
UNRESOLVED: gfortran.dg/inline_matmul_24.f90   -Os   scan-tree-dump-times
optimized "gamma5[__var_1_do * 4 + __var_2_do]" 1


It looks like the dump files are not being created.  Missing option(s) perhaps?


spawn -ignore SIGHUP
/home/seurer/gcc/build/gcc-test2/gcc/testsuite/gfortran6/../../gfortran
-B/home/seurer/gcc/build/gcc-test2/gcc/testsuite/gfortran6/../../
-B/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gfortran.dg/inline_matmul_24.f90
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -O1 -ffrontend-optimize -fdump-tree-original
-B/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libatomic/.libs
-B/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libquadmath/.libs
-L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libquadmath/.libs
-L/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libquadmath/.libs
-lm -o ./inline_matmul_24.exe
PASS: gfortran.dg/inline_matmul_24.f90   -O1  (test for excess errors)
Setting LD_LIBRARY_PATH to
.:/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libatomic/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libquadmath/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libquadmath/.libs:/home/seurer/gcc/build/gcc-test2/gcc:.:/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libgfortran/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libatomic/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libquadmath/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/./libquadmath/.libs:/home/seurer/gcc/build/gcc-test2/gcc:/home/seurer/gcc/build/gcc-test2/./gmp/.libs:/home/seurer/gcc/build/gcc-test2/./prev-gmp/.libs:/home/seurer/gcc/build/gcc-test2/./mpfr/src/.libs:/home/seurer/gcc/build/gcc-test2/./prev-mpfr/src/.libs:/home/seurer/gcc/build/gcc-test2/./mpc/src/.libs:/home/seurer/gcc/build/gcc-test2/./prev-mpc/src/.libs:/home/seurer/gcc/build/gcc-test2/./isl/.libs:/home/seurer/gcc/build/gcc-test2/./prev-isl/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/src/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libsanitizer/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libssp/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libgomp/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libitm/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libatomic/.libs:/home/seurer/gcc/build/gcc-test2/./gcc:/home/seurer/gcc/build/gcc-test2/./prev-gcc:/home/seurer/gcc/build/gcc-test2/./gmp/.libs:/home/seurer/gcc/build/gcc-test2/./prev-gmp/.libs:/home/seurer/gcc/build/gcc-test2/./mpfr/src/.libs:/home/seurer/gcc/build/gcc-test2/./prev-mpfr/src/.libs:/home/seurer/gcc/build/gcc-test2/./mpc/src/.libs:/home/seurer/gcc/build/gcc-test2/./prev-mpc/src/.libs:/home/seurer/gcc/build/gcc-test2/./isl/.libs:/home/seurer/gcc/build/gcc-test2/./prev-isl/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/src/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-

[Bug c/87615] Possible excessive compile time with -O2

[amonakov at gcc dot gnu.org]

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

--- Comment #3 from Alexander Monakov  ---
On gcc-8 -fno-ipa-cp does not affect time, I brought it up prematurely:

-O2 -time
# cc1 207.15 0.22
-O2 -time -fno-ipa-cp
# cc1 207.57 0.18
-O2 -time -fno-inline
# cc1 21.13 0.10

Looks like gcc-9 regressed here.

[Bug fortran/77385] "Unclassifiable statement" from gfortran

[pault at gcc dot gnu.org]

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

--- Comment #3 from Paul Thomas  ---
(In reply to Dominique d'Humieres from comment #1)
> Confirmed from 4.7 up to trunk (7.0), Polymorphic arrays are not yet
> supported on 4.6.
> 
> Note that the following variant
> 
> MODULE a
>IMPLICIT NONE
>TYPE :: b
>   CONTAINS
>  PROCEDURE :: e
>END TYPE b
>TYPE :: c
>   CLASS(b), POINTER :: i(:) => NULL()
>END TYPE c
>CONTAINS
>   FUNCTION e(this ) RESULT (s)
>  CLASS(b) :: this
>  TYPE(b) :: s
>  s = b()
>   END FUNCTION e
> END MODULE a
> MODULE m
>USE a
>IMPLICIT NONE
>TYPE d
>   CLASS(b), DIMENSION(:), POINTER :: f => NULL()
>END TYPE d
>CONTAINS
>   FUNCTION g() RESULT (h)
>  TYPE(d) :: j
>  TYPE(c) :: h
>  allocate(j%f(1))
>  print *, shape(j%f)
>  ASSOCIATE( k => j%f )
>  END ASSOCIATE
>   END FUNCTION g
> END MODULE m
>use m
>type(c) :: res
>res = g()
> end
> 
> gives
> 
>   ASSOCIATE( k => j%f )
>  
> internal compiler error: Segmentation fault: 11
> 
> and
> 
> MODULE a
>IMPLICIT NONE
>TYPE :: b
>   CONTAINS
>  PROCEDURE :: e
>END TYPE b
>TYPE :: c
>   CLASS(b), POINTER :: i(:) => NULL()
>END TYPE c
>CONTAINS
>   FUNCTION e(this ) RESULT (s)
>  CLASS(b) :: this
>  TYPE(b) :: s
>  s = b()
>   END FUNCTION e
> END MODULE a
> MODULE m
>USE a
>IMPLICIT NONE
>TYPE d
>   CLASS(b), DIMENSION(:), POINTER :: f => NULL()
>END TYPE d
>CONTAINS
>   FUNCTION g() RESULT (h)
>  TYPE(d) :: j
>  TYPE(c) :: h
> ALLOCATE(h%i(1))
> allocate(j%f(1))
> SELECT TYPE ( l => h%i )
> TYPE IS ( b )
>l(1) = j*f(1)%e()
> END SELECT
>   END FUNCTION g
> END MODULE m
> 
> gives
> 
> l(1) = j*f(1)%e()
>  1
> Error: Symbol 'f' at (1) has no IMPLICIT type

I am not surprised at the error in the second variant. Replace the offending
statement by l(1) = j%f(1)%e() and all is well.

Paul

[Bug fortran/87495] Warning: ‘fastcall’ attribute ignored [-Wattributes] for !GCC$ ATTRIBUTES

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #3 from Tobias Burnus  ---
I wonder whether that's an ABI problem.

At least, if I use "-m32", it compiles without warning – while -m64 shows the
warning on my 86-64-gnu-linux.

I also see the following in doc/extend.texi:

@item fastcall
@cindex @code{fastcall} function attribute, x86-32
@cindex functions that pop the argument stack on x86-32
On x86-32 targets, the @code{fastcall} attribute causes the compiler to
pass the first argument (if of integral type) in the register ECX and
the second argument (if of integral type) in the register EDX@.  Subsequent
and other typed arguments are passed on the stack.  The called function
pops the arguments off the stack.  If the number of arguments is variable all
arguments are pushed on the stack.

Side note: on Microsoft's page, I do see a __fastcall for x64 Windows:
https://msdn.microsoft.com/en-us/library/ms235286.aspx

[Bug c++/87607] Cannot use fold expression in static_assert

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

[Bug fortran/87556] FORM TEAM statement team-number argument interpreted incorrectly when function

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-10-15
 CC||burnus at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Tobias Burnus  ---
Confirmed – form_team, change_team and sync_team have the same issue.

Namely, the argse.pre/post is ignored – such that one uses an uninitialized
variable, which probably is 0 and, hence, < 3.

[Bug c++/84849] Ambiguous resolution of braze initializer list to a class with explicit constructors

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Thanks, this sounds interesting.

[Bug fortran/87597] [6/7/8/9 Regression] wrong result with matmul inlining

[burnus at gcc dot gnu.org]

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

--- Comment #7 from Tobias Burnus  ---
Author: burnus
Date: Mon Oct 15 18:58:17 2018
New Revision: 265175

URL: https://gcc.gnu.org/viewcvs?rev=265175&root=gcc&view=rev
Log:
2018-10-15  Tobias Burnus  

   PR fortran/87597
   * gfortran.dg/inline_matmul_24.f90: Tweak scan-tree.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/inline_matmul_24.f90

[Bug c/87615] Possible excessive compile time with -O2

[dcb314 at hotmail dot com]

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

--- Comment #2 from David Binderman  ---
(In reply to Alexander Monakov from comment #1)
> How much does -fno-ipa-cp help (on gcc-8 I see incredibly deep recursion in
> walk_aliased_vdefs_1 under IPA-CP analysis)?

New execution time is about 8 minutes 50 seconds, so about 10 % reduction.

Alias statement walking seems to consume most of the original time.

[Bug c++/87607] Cannot use fold expression in static_assert

[havhoi92 at gmail dot com]

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

Håkon Høines  changed:

   What|Removed |Added

 Resolution|INVALID |FIXED

--- Comment #2 from Håkon Høines  ---
Yes, that compiles fine. I'm sorry, I should probably read the documentation
more carefully next time.

[Bug c++/87616] Compiler segfaults on dependent templated friend

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-10-15
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Marek Polacek  ---
Confirmed.  Not a recent regression.

[Bug c++/87616] Compiler segfaults on dependent templated friend

[mickg at mickg dot net]

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

--- Comment #2 from Michael Gorbovitski  ---
Slightly simplified test case (no need for double-argument template):

struct foo{};
template  struct friender {
using cls=foo;
};

class bar {
template 
friend class friender::cls;
int hidden;
};


int main() {
bar b;
}

[Bug c++/87616] Compiler segfaults on dependent templated friend

[mickg at mickg dot net]

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

--- Comment #1 from Michael Gorbovitski  ---
> g++ prog.cc -Wall -Wextra

prog.cc:8:36: internal compiler error: Segmentation fault
8 | friend class friender::cls;
  |^
0xb3 crash_signal
../../source/gcc/toplev.c:325
0x644fc3 make_friend_class(tree_node*, tree_node*, bool)
../../source/gcc/cp/friend.c:406
0x6a409f cp_parser_template_declaration_after_parameters
../../source/gcc/cp/parser.c:27052
0x6a4421 cp_parser_explicit_template_declaration
../../source/gcc/cp/parser.c:27271
0x6a4421 cp_parser_template_declaration_after_export
../../source/gcc/cp/parser.c:27290
0x6913bd cp_parser_member_declaration
../../source/gcc/cp/parser.c:23593
0x6921c0 cp_parser_member_specification_opt
../../source/gcc/cp/parser.c:23520
0x6921c0 cp_parser_class_specifier_1
../../source/gcc/cp/parser.c:22664
0x693a9b cp_parser_class_specifier
../../source/gcc/cp/parser.c:22926
0x693a9b cp_parser_type_specifier
../../source/gcc/cp/parser.c:16910
0x69f4b8 cp_parser_decl_specifier_seq
../../source/gcc/cp/parser.c:13747
0x6a4780 cp_parser_simple_declaration
../../source/gcc/cp/parser.c:13057
0x6a8272 cp_parser_declaration
../../source/gcc/cp/parser.c:12876
0x6a89a6 cp_parser_translation_unit
../../source/gcc/cp/parser.c:4631
0x6a89a6 c_parse_file()
../../source/gcc/cp/parser.c:39116
0x75db8b c_common_parse_file()
../../source/gcc/c-family/c-opts.c:1139
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
1

[Bug c++/87616] New: Compiler segfaults on dependent templated friend

[mickg at mickg dot net]

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

Bug ID: 87616
   Summary: Compiler segfaults on dependent templated friend
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mickg at mickg dot net
  Target Milestone: ---

Sample that does not compile : 


struct foo{};
template  struct friender {
using cls=foo;
};

class bar {
template 
friend class friender::cls;
int hidden;
};


int main() {
bar b;
}

[Bug c/87615] Possible excessive compile time with -O2

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #1 from Alexander Monakov  ---
How much does -fno-ipa-cp help (on gcc-8 I see incredibly deep recursion in
walk_aliased_vdefs_1 under IPA-CP analysis)?

[Bug fortran/87566] ICE with class(*) and select

[pault at gcc dot gnu.org]

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

--- Comment #8 from Paul Thomas  ---
Fixed on trunk.

I am going back on my original intention to backport the recent patches to
8-branch. Or, rather, I will do them one at a time if at all. The trouble is
that an omnibus patch doesn't work for all the new testcases because of some
earlier patches applied to trunk.

I will keep this open in the hope that a backport will work but do not hold
your breath.

Best regards

Paul

[Bug target/87563] [9 regression ] ICE with -march=armv8-a+sve

[renlin at gcc dot gnu.org]

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

--- Comment #4 from Renlin Li  ---
Author: renlin
Date: Mon Oct 15 16:49:05 2018
New Revision: 265172

URL: https://gcc.gnu.org/viewcvs?rev=265172&root=gcc&view=rev
Log:
[PR87563][AARCH64-SVE]: Don't keep ifcvt loop when COND_ ifn could not be
vectorized.

ifcvt will created versioned loop and it will permissively generate
scalar COND_ ifn.

If in the loop vectorize pass, COND_ could not get vectoized,
the if-converted loop should be abandoned when the target doesn't support
such ifn.


gcc/

2018-10-12  Renlin Li  

PR target/87563
* tree-vectorizer.c (try_vectorize_loop_1): Don't use
if-conversioned loop when it contains ifn with types not
supported by backend.
* internal-fn.c (expand_direct_optab_fn): Add an assert.
(direct_internal_fn_supported_p): New helper function.
* internal-fn.h (direct_internal_fn_supported_p): Declare.

gcc/testsuite/

2018-10-12  Renlin Li  

PR target/87563
* gcc.target/aarch64/sve/pr87563.c: New.


Added:
trunk/gcc/testsuite/gcc.target/aarch64/sve/pr87563.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/internal-fn.c
trunk/gcc/internal-fn.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vectorizer.c

[Bug fortran/87566] ICE with class(*) and select

[pault at gcc dot gnu.org]

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

--- Comment #7 from Paul Thomas  ---
Author: pault
Date: Mon Oct 15 16:31:15 2018
New Revision: 265171

URL: https://gcc.gnu.org/viewcvs?rev=265171&root=gcc&view=rev
Log:
2018-10-15  Paul Thomas  
Tobias Burnus  

PR fortran/87566
* resolve.c (resolve_assoc_var): Add missing array spec for
class associate names.
(resolve_select_type): Handle case where last typed component
of the selector has a different type to the expression.
* trans-expr.c (gfc_find_and_cut_at_last_class_ref): Replace
call to gfc_expr_to_initialize with call to gfc_copy_expr.
(gfc_conv_class_to_class): Guard assignment to 'len' field
against case where zero constant is supplied.

2018-10-15  Paul Thomas  
Tobias Burnus  

PR fortran/87566
* gfortran.dg/select_type_44.f90: New test.
* gfortran.dg/associate_42.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/associate_42.f90
trunk/gcc/testsuite/gfortran.dg/select_type_44.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/trans-expr.c
trunk/gcc/testsuite/ChangeLog

[Bug c/87615] New: Possible excessive compile time with -O2

[dcb314 at hotmail dot com]

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

Bug ID: 87615
   Summary: Possible excessive compile time with -O2
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 44842
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44842&action=edit
gzipped C source code

The attached C code, when compiled by a release version
of recent gcc trunk, and flag -O2, seems to take about nine
minutes 50 seconds to compile.

According to -ftime-report, 

 phase opt and generate : 511.78 (100%)   2.60 ( 69%) 518.59 (100%)
 474628 kB ( 92%)
 alias stmt walking : 265.80 ( 52%)   0.41 ( 11%) 267.65 ( 51%)
  3 kB (  0%)
 tree VRP   :  90.34 ( 18%)   0.18 (  5%)  91.33 ( 18%)
  58202 kB ( 11%)
 tree FRE   :  86.43 ( 17%)   1.22 ( 32%)  88.79 ( 17%)
   1833 kB (  0%)

$ ~/gcc/results.265139.release/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/home/dcb/gcc/results.265139.release/bin/gcc
COLLECT_LTO_WRAPPER=/home/dcb/gcc/results.265139.release/libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../trunk/configure
--prefix=/home/dcb/gcc/results.265139.release --disable-bootstrap
--disable-multilib --disable-werror --enable-checking=release
--enable-languages=c,c++,fortran
Thread model: posix
gcc version 9.0.0 20181013 (experimental) (GCC) 
$

[Bug target/87572] ICE in emit_move_insn, at expr.c:3722

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Mon Oct 15 16:08:09 2018
New Revision: 265169

URL: https://gcc.gnu.org/viewcvs?rev=265169&root=gcc&view=rev
Log:
PR target/87572
* common/config/i386/i386-common.c (OPTION_MASK_ISA_AVX512F_UNSET):
Remove OPTION_MASK_ISA_AVX5124FMAPS_UNSET and
OPTION_MASK_ISA_AVX5124VNNIW_UNSET.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/common/config/i386/i386-common.c

[Bug tree-optimization/87562] [9 Regression] ICE in in linemap_position_for_line_and_column, at libcpp/line-map.c:848

[renlin at gcc dot gnu.org]

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

Renlin Li  changed:

   What|Removed |Added

 CC||renlin at gcc dot gnu.org

--- Comment #2 from Renlin Li  ---
(In reply to David Malcolm from comment #1)
> linemap_position_for_line_and_column(line_maps*, line_map_ordinary const*,
> unsigned int, unsigned int) at libcpp/line-map.c:848
> is:
>   linemap_assert (ORDINARY_MAP_STARTING_LINE_NUMBER (ord_map) <= line);
> 
> I wonder if I introduced this in r264887 with the changes to input.c
> (macro-handling and concatenated strings), which touched the function in the
> next frame.
> 
> I'll see if I can reproduce it.

Hi David,

I checked that, the ICE starts from r264887.

[Bug libstdc++/87614] User related warnings are hidden in system headers

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-10-15
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=58876
 Depends on||80472
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
This can't be fixed at the moment, due to PR 80472


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80472
[Bug 80472] cannot use push/pop with #pragma GCC diagnostic warning
"-Wsystem-headers"

[Bug libstdc++/87614] New: User related warnings are hidden in system headers

[antoshkka at gmail dot com]

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

Bug ID: 87614
   Summary: User related warnings are hidden in system headers
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antoshkka at gmail dot com
  Target Milestone: ---

Consider the following example:

#include 

int main() {
std::vector a;
a.emplace_back(7);
}


No warning produced with "--std=c++17 -Wall -Wextra -Werror -pedantic
-Wold-style-cast -Wconversion -Wsign-conversion -Wunreachable-code
-Wno-missing-braces"

However there is an essential warning in new_allocator.h

include/c++/9.0.0/ext/new_allocator.h:139:4: error: conversion from 'long int'
to 'short unsigned int' may change value [-Werror=conversion]

The warning is also visible if we replace `emplace_back` with `push_back`.


The solution would be to enable warnings for all the places where user provided
data types are constructed or any other functions of the user provided types
are called.

[Bug c++/87613] New: Non-reachable default required in switch statement to get optimal code

[chtz at informatik dot uni-bremen.de]

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

Bug ID: 87613
   Summary: Non-reachable default required in switch statement to
get optimal code
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chtz at informatik dot uni-bremen.de
  Target Milestone: ---

Created attachment 44841
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44841&action=edit
Sample code with non-reachable default case

Compiling the attached code with -O2 generates a jump-table, which directly
contains the `foo()` function addresses. Removing the (non-reachable)
`default` case generates an indirect jump-table which jumps to code that first
moves the function address into a register and then jumps.

In g++-8.x this always generates optimal code, but without the default-case a
warning is generated:
   warning: control reaches end of non-void function [-Wreturn-type]

Godbolt-Link (try around with commenting in/out the default or return 0;)
  https://godbolt.org/z/itpvL6

Directly returning writing this also leads to an indirect jump-table:
  case X: return foo();

[Bug tree-optimization/84648] Missed optimization : loop not removed.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||amker at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
So we run into

  /* Ignore loops of while (i-- < 10) type.  */
  if (code != NE_EXPR)
{
  if (iv0->step && tree_int_cst_sign_bit (iv0->step))
return false;

  if (!integer_zerop (iv1->step) && !tree_int_cst_sign_bit (iv1->step))
return false;
}

where code == LE_EXPR from 0 <= iv1 with iv1 being {0, +, 1}.

This specifically singles out loop-until-wrap.  We'd need to teach niter
analysis this kind of loop.

[Bug sanitizer/84761] AddressSanitizer is not compatible with glibc 2.27 on x86

[rguenth at gcc dot gnu.org]

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

--- Comment #15 from Richard Biener  ---
Author: rguenth
Date: Mon Oct 15 13:43:09 2018
New Revision: 265164

URL: https://gcc.gnu.org/viewcvs?rev=265164&root=gcc&view=rev
Log:
2018-10-15  Richard Biener  

Backport from mainline
2018-03-19  Jakub Jelinek  

PR sanitizer/84761
* sanitizer_common/sanitizer_linux_libcdep.cc (__GLIBC_PREREQ):
Define if not defined.
(DL_INTERNAL_FUNCTION): Don't define.
(InitTlsSize): For __i386__ if not compiled against glibc 2.27+
determine at runtime whether to use regparm(3), stdcall calling
convention for older glibcs or normal calling convention for
newer glibcs for call to _dl_get_tls_static_info.

Modified:
branches/gcc-6-branch/libsanitizer/ChangeLog
   
branches/gcc-6-branch/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc

[Bug tree-optimization/87022] [8 Regression] miscompilation with -ftree-loop-distribution

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||9.0
Summary|[8/9 Regression]|[8 Regression]
   |miscompilation with |miscompilation with
   |-ftree-loop-distribution|-ftree-loop-distribution
  Known to fail||8.2.0

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

[Bug libstdc++/87587] [...]/libstdc++-v3/src/c++11/cxx11-shim_facets.cc:271:28: error: empty class 'std::integral_constant' parameter passing ABI changes in -fabi-version=12 (GCC 8) [-Werr

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Mon Oct 15 12:58:51 2018
New Revision: 265163

URL: https://gcc.gnu.org/viewcvs?rev=265163&root=gcc&view=rev
Log:
PR libstdc++/87587 prevent -Wabi warnings

The warnings about changes to empty struct parameter passing can be
ignored because the callers are all internal to the library, and so
compiled with the same -fabi-version as the function definitions.

It would be preferable to use #pragma GCC diagnostic warning "-Wabi=12"
to get warnings about any other ABI changes in future versions, but
until PR c++/87611 is fixed the warnings must be completely disabled
with #pragma GCC diagnostic ignroed "-Wabi".

PR libstdc++/87587
* src/c++11/cxx11-shim_facets.cc: Suppress -Wabi warnings.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/src/c++11/cxx11-shim_facets.cc

[Bug c++/87611] Cannot suppress warning with #pragma GCC diagnostic warning "-Wabi=12"

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Author: redi
Date: Mon Oct 15 12:58:51 2018
New Revision: 265163

URL: https://gcc.gnu.org/viewcvs?rev=265163&root=gcc&view=rev
Log:
PR libstdc++/87587 prevent -Wabi warnings

The warnings about changes to empty struct parameter passing can be
ignored because the callers are all internal to the library, and so
compiled with the same -fabi-version as the function definitions.

It would be preferable to use #pragma GCC diagnostic warning "-Wabi=12"
to get warnings about any other ABI changes in future versions, but
until PR c++/87611 is fixed the warnings must be completely disabled
with #pragma GCC diagnostic ignroed "-Wabi".

PR libstdc++/87587
* src/c++11/cxx11-shim_facets.cc: Suppress -Wabi warnings.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/src/c++11/cxx11-shim_facets.cc

[Bug bootstrap/44756] [meta-bug] --enable-werror-always issues

[redi at gcc dot gnu.org]

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

Bug 87587 Summary: [...]/libstdc++-v3/src/c++11/cxx11-shim_facets.cc:271:28: 
error: empty class 'std::integral_constant' parameter passing ABI 
changes in -fabi-version=12 (GCC 8) [-Werror=abi]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87587

   What|Removed |Added

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

[Bug libstdc++/87587] [...]/libstdc++-v3/src/c++11/cxx11-shim_facets.cc:271:28: error: empty class 'std::integral_constant' parameter passing ABI changes in -fabi-version=12 (GCC 8) [-Werr

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

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

[Bug target/87612] New: Bad diagnostic for conflicting mcpu and march options on aarch64

[ktkachov at gcc dot gnu.org]

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

Bug ID: 87612
   Summary: Bad diagnostic for conflicting mcpu and march options
on aarch64
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64

Giving conflicting -mcpu and -march options on aarch64 results in a useful
warning. However, it can be misleading:

aarch64-none-elf-gcc -S -O3 -march=armv8-a+sve  -mcpu=cortex-a76 foo.c

cc1: warning: switch -mcpu=armv8.2-a conflicts with -march=armv8-a switch

1. The -mcpu part wrongly reports the architecture of the CPU rather than the
CPU name itself.

2. The -march part does not print the extensions added, like +sve

This should be simple enough to fix in aarch64_override_options in
config/aarch64/aarch64.c

[Bug c++/87611] New: Cannot suppress warning with #pragma GCC diagnostic warning "-Wabi=12"

[redi at gcc dot gnu.org]

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

Bug ID: 87611
   Summary: Cannot suppress warning with #pragma GCC diagnostic
warning "-Wabi=12"
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

struct empty { };
#pragma GCC diagnostic warning "-Wabi=12"
void f(empty, int) { }

Compiling this with -Wabi=11 warns, even though the pragma should cause
-Wabi=12 to be used, and so not warn:

wabi.cc: In function 'void f(empty, int)':
wabi.cc:3:6: warning: empty class 'empty' parameter passing ABI changes in
-fabi-version=12 (GCC 8) [-Wabi]
3 | void f(empty, int) { }
  |  ^


It's necessary to completely disable -Wabi warnings with

#pragma GCC diagnostic ignored "-Wabi"


By contrast, the following does suppress the warning about the PR c++/51322
mangling change:

#pragma GCC diagnostic warning "-Wabi=6"
template struct Ident { typedef T type; };
templateclass E,class...F> struct A{typedef E type;};
typedef A B;
void f(B){}

Why doesn't it work for the first case?

[Bug middle-end/87610] [6/7/8 Regression] wrong-code with restrict

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
  Known to work||9.0
Summary|[6/7/8/9 Regression]|[6/7/8 Regression]
   |wrong-code with restrict|wrong-code with restrict

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

[Bug libstdc++/86751] [6/7/8 Regression] Ambiguous operator= overload for std::pair

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |6.5
  Known to fail||6.4.0

--- Comment #9 from Jonathan Wakely  ---
Also fixed for 6.5, 7.4, and 8.3

[Bug libstdc++/86751] [6/7/8 Regression] Ambiguous operator= overload for std::pair

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
Author: redi
Date: Mon Oct 15 11:52:48 2018
New Revision: 265162

URL: https://gcc.gnu.org/viewcvs?rev=265162&root=gcc&view=rev
Log:
PR libstdc++/86751 default assignment operators for std::pair

The solution for PR 77537 causes ambiguities due to the extra copy
assignment operator taking a __nonesuch_no_braces parameter. By making
the base class non-assignable we don't need the extra deleted overload
in std::pair. The copy assignment operator will be implicitly deleted
(and the move assignment operator not declared) as needed. Without the
additional user-provided operator in std::pair the ambiguity is avoided.

Backport from mainline
2018-07-31  Jonathan Wakely  

PR libstdc++/86751
* include/bits/stl_pair.h (__pair_base): New class with deleted copy
assignment operator.
(pair): Derive from __pair_base.
(pair::operator=): Remove deleted overload.
* python/libstdcxx/v6/printers.py (StdPairPrinter): New pretty printer
so that new base class isn't shown in GDB.
* testsuite/20_util/pair/86751.cc: New test.
* testsuite/20_util/pair/ref_assign.cc: New test.

Added:
branches/gcc-6-branch/libstdc++-v3/testsuite/20_util/pair/86751.cc
branches/gcc-6-branch/libstdc++-v3/testsuite/20_util/pair/ref_assign.cc
Modified:
branches/gcc-6-branch/libstdc++-v3/ChangeLog
branches/gcc-6-branch/libstdc++-v3/include/bits/stl_pair.h
branches/gcc-6-branch/libstdc++-v3/python/libstdcxx/v6/printers.py

[Bug libstdc++/77537] [6 Regression] pair constructors do not properly SFINAE

[redi at gcc dot gnu.org]

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

--- Comment #16 from Jonathan Wakely  ---
Author: redi
Date: Mon Oct 15 11:52:48 2018
New Revision: 265162

URL: https://gcc.gnu.org/viewcvs?rev=265162&root=gcc&view=rev
Log:
PR libstdc++/86751 default assignment operators for std::pair

The solution for PR 77537 causes ambiguities due to the extra copy
assignment operator taking a __nonesuch_no_braces parameter. By making
the base class non-assignable we don't need the extra deleted overload
in std::pair. The copy assignment operator will be implicitly deleted
(and the move assignment operator not declared) as needed. Without the
additional user-provided operator in std::pair the ambiguity is avoided.

Backport from mainline
2018-07-31  Jonathan Wakely  

PR libstdc++/86751
* include/bits/stl_pair.h (__pair_base): New class with deleted copy
assignment operator.
(pair): Derive from __pair_base.
(pair::operator=): Remove deleted overload.
* python/libstdcxx/v6/printers.py (StdPairPrinter): New pretty printer
so that new base class isn't shown in GDB.
* testsuite/20_util/pair/86751.cc: New test.
* testsuite/20_util/pair/ref_assign.cc: New test.

Added:
branches/gcc-6-branch/libstdc++-v3/testsuite/20_util/pair/86751.cc
branches/gcc-6-branch/libstdc++-v3/testsuite/20_util/pair/ref_assign.cc
Modified:
branches/gcc-6-branch/libstdc++-v3/ChangeLog
branches/gcc-6-branch/libstdc++-v3/include/bits/stl_pair.h
branches/gcc-6-branch/libstdc++-v3/python/libstdcxx/v6/printers.py

[Bug fortran/68800] Fortran FE produces many memory leaks

[aldot at gcc dot gnu.org]

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

Bernhard Reutner-Fischer  changed:

   What|Removed |Added

 CC||aldot at gcc dot gnu.org

--- Comment #3 from Bernhard Reutner-Fischer  ---
(In reply to Martin Liška from comment #0)

> are definitely lost: 2004 occurences
>   calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
>   xcalloc (xmalloc.c:163)
>   gfc_get_namespace(gfc_namespace*, int) (symbol.c:2508)
>   generate_finalization_wrapper (class.c:1589)
>   gfc_find_derived_vtab(gfc_symbol*) (class.c:2406)
>   resolve_fl_derived(gfc_symbol*) (resolve.c:13389)
>   resolve_symbol(gfc_symbol*) (resolve.c:13669)
>   do_traverse_symtree(gfc_symtree*, void (*)(gfc_symtree*), void
> (*)(gfc_symbol*)) (symbol.c:3817)
>   resolve_types(gfc_namespace*) (resolve.c:15443)
>   gfc_resolve(gfc_namespace*) [clone .part.47] (resolve.c:15553)
>   gfc_parse_file() (parse.c:5757)
>   gfc_be_parse_file() (f95-lang.c:201)
>   compile_file() (toplev.c:464)

This first one..

> are definitely lost: 1476 occurences
>   calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
>   xcalloc (xmalloc.c:163)
>   gfc_get_typebound_proc(gfc_typebound_proc*) (symbol.c:4669)
>   match_procedure_in_type (decl.c:8749)
>   gfc_match_procedure() (decl.c:5480)
>   match_word(char const*, match (*)(), locus*) [clone .part.4] (parse.c:65)
>   decode_statement() (parse.c:531)
>   next_free (parse.c:1076)
>   next_statement() (parse.c:1310)
>   parse_derived_contains (parse.c:2549)
>   parse_derived (parse.c:2751)
>   parse_spec(gfc_statement) (parse.c:3368)
>   parse_module() (parse.c:5421)
>   gfc_parse_file() (parse.c:5737)
>   gfc_be_parse_file() (f95-lang.c:201)
>   compile_file() (toplev.c:464)

This is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56491
Patch at https://gcc.gnu.org/ml/fortran/2018-09/msg00045.html and will be fixed
when merging the surrounding series.


> are definitely lost: 1401 occurences
>   calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
>   xcalloc (xmalloc.c:163)
>   gfc_get_namespace(gfc_namespace*, int) (symbol.c:2508)
>   generate_finalization_wrapper (class.c:1589)
>   gfc_find_derived_vtab(gfc_symbol*) (class.c:2406)
>   resolve_fl_derived(gfc_symbol*) (resolve.c:13389)
>   resolve_symbol(gfc_symbol*) (resolve.c:13669)
>   do_traverse_symtree(gfc_symtree*, void (*)(gfc_symtree*), void
> (*)(gfc_symbol*)) (symbol.c:3817)
>   resolve_types(gfc_namespace*) (resolve.c:15443)
>   gfc_resolve(gfc_namespace*) [clone .part.47] (resolve.c:15553)
>   resolve_all_program_units (parse.c:5551)
>   gfc_parse_file() (parse.c:5803)
>   gfc_be_parse_file() (f95-lang.c:201)
>   compile_file() (toplev.c:464)

.. and this second one will be fixed by

https://gcc.gnu.org/ml/fortran/2018-10/msg00064.html from later in
aforementioned series.

[Bug tree-optimization/87022] [8/9 Regression] miscompilation with -ftree-loop-distribution

[amker at gcc dot gnu.org]

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

--- Comment #4 from bin cheng  ---
Author: amker
Date: Mon Oct 15 11:35:56 2018
New Revision: 265161

URL: https://gcc.gnu.org/viewcvs?rev=265161&root=gcc&view=rev
Log:
PR tree-optimization/87022
* tree-loop-distribution.c (pg_add_dependence_edges): Check all
bits in dist vector rather than the first one.

gcc/testsuite
PR tree-optimization/87022
* gcc.dg/tree-ssa/pr87022.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr87022.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-loop-distribution.c

[Bug middle-end/87610] [6/7/8/9 Regression] wrong-code with restrict

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Author: rguenth
Date: Mon Oct 15 10:58:28 2018
New Revision: 265160

URL: https://gcc.gnu.org/viewcvs?rev=265160&root=gcc&view=rev
Log:
2018-10-15  Richard Biener  

PR middle-end/87610
* tree-ssa-structalias.c (struct vls_data): Add escaped_p member.
(visit_loadstore): When a used restrict tag escaped verify that
the points-to solution of "other" pointers do not include
escaped.
(compute_dependence_clique): If a used restrict tag escaped
communicated that down to visit_loadstore.

* gcc.dg/torture/restrict-6.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/restrict-6.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-structalias.c

[Bug middle-end/87610] New: [6/7/8/9 Regression] wrong-code with restrict

[rguenth at gcc dot gnu.org]

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

Bug ID: 87610
   Summary: [6/7/8/9 Regression] wrong-code with restrict
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

extern void abort (void);

void __attribute__((noinline)) g(int **a, int *b)
{
  *a = b;
}

int foo(int * restrict p, int *q)
{
  g(&q, p);
  *p = 1;
  *q = 2;
  return *p + *q;
}

int main()
{
  int x, y;
  if (foo(&x, &y) != 4)
abort ();
  return 0;
}

[Bug middle-end/87610] [6/7/8/9 Regression] wrong-code with restrict

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-10-15
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |6.5
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
I have a patch.

[Bug ipa/87024] [6 Regression] ICE in fold_stmt_1

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Author: rguenth
Date: Mon Oct 15 10:50:57 2018
New Revision: 265159

URL: https://gcc.gnu.org/viewcvs?rev=265159&root=gcc&view=rev
Log:
2018-10-15  Richard Biener  

Backport from mainline
2018-08-23  Richard Biener  

PR middle-end/87024
* tree-inline.c (copy_bb): Drop unused __builtin_va_arg_pack_len
calls.

* gcc.dg/pr87024.c: New testcase.

2018-08-17  Richard Biener  

PR middle-end/86505
* tree-inline.c (copy_bb): When inlining __builtin_va_arg_pack_len ()
across a va-arg-pack using call adjust its return value accordingly.

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

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.dg/pr87024.c
branches/gcc-6-branch/gcc/testsuite/gcc.dg/torture/pr86505.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/tree-inline.c

[Bug middle-end/86505] [6 Regression] __builtin_va_arg_pack_len() computes the number of arguments wrongly

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug ipa/87024] [6 Regression] ICE in fold_stmt_1

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug middle-end/86505] [6 Regression] __builtin_va_arg_pack_len() computes the number of arguments wrongly

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Biener  ---
Author: rguenth
Date: Mon Oct 15 10:50:57 2018
New Revision: 265159

URL: https://gcc.gnu.org/viewcvs?rev=265159&root=gcc&view=rev
Log:
2018-10-15  Richard Biener  

Backport from mainline
2018-08-23  Richard Biener  

PR middle-end/87024
* tree-inline.c (copy_bb): Drop unused __builtin_va_arg_pack_len
calls.

* gcc.dg/pr87024.c: New testcase.

2018-08-17  Richard Biener  

PR middle-end/86505
* tree-inline.c (copy_bb): When inlining __builtin_va_arg_pack_len ()
across a va-arg-pack using call adjust its return value accordingly.

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

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.dg/pr87024.c
branches/gcc-6-branch/gcc/testsuite/gcc.dg/torture/pr86505.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/tree-inline.c

[Bug fortran/58618] Wrong code with character substring and ASSOCIATE

[pault at gcc dot gnu.org]

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

--- Comment #10 from Paul Thomas  ---
(In reply to Dominique d'Humieres from comment #9)
> With the patch in comment 8, the wrong-code is replaced with an ICE
> 
> pr58618.f90:2:0:
> 
> 2 | associate (x=>s(1)(1:1))
>   | 
> internal compiler error: in fold_convert_loc, at fold-const.c:2425
> 
> (configured with --enable-checking=yes).

That's weird - I am even more puzzled then :-(

Thanks

Paul

[Bug fortran/80260] [7/8/9 Regression] ICE with polymorphic array section actual argument

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org

--- Comment #5 from Paul Thomas  ---
According to Dominique's message to the list this morning, I have fixed this
one and so I had better take it.

Paul

[Bug fortran/58906] [OOP] SELECT TYPE with CLASS IS generates ICE

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org

--- Comment #3 from Paul Thomas  ---
According to Dominique's message to the list this morning, I have fixed this
one and so I had better take it.

Paul

[Bug fortran/77385] "Unclassifiable statement" from gfortran

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org

--- Comment #2 from Paul Thomas  ---
According to Dominique's message to the list this morning, I have fixed the
variant in comment#1 and so I had better take it.

Paul

[Bug fortran/82077] [7/8/9 Regression] ICE on associating polymorphic array dummy with a type-guarded array section

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org

--- Comment #4 from Paul Thomas  ---
According to Dominique's message to the list this morning, I have fixed this
one and so I had better take it.

Paul

[Bug c++/87602] Integer Overflow in cplus-dem.c in c++filt in bintuils which leads to Undefined-behavior(OOM in this POC)

[wcventure at 126 dot com]

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

Cheng Wen  changed:

   What|Removed |Added

Summary|Integer Overflow in |Integer Overflow in
   |cplus-dem.c in c++filt in   |cplus-dem.c in c++filt in
   |bintuils|bintuils which leads to
   ||Undefined-behavior(OOM in
   ||this POC)

--- Comment #1 from Cheng Wen  ---
In cplus-dem.c:3597
   n *= 10;
   n += *p - '0';
   p++;
This testcase will set n = 7. 7 * 10 cannot be represented in
type 'int', which make n have a Integer overflow problem. This problem leads to
undefined-behavior.


I will show you the debug process as follow:

> $ gdb --args ./c++filt _rttt46__H766_
> (gdb) start
> Temporary breakpoint 1 at 0x4ea9a6: file cxxfilt.c, line 172.
> Starting program: /build/bin/c++filt _rttt46__H766__c
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> Temporary breakpoint 1, main (argc=2, argv=0x7fffdff8) at cxxfilt.c:172
> 172 {
> (gdb) b cplus-dem.c:3597
> Breakpoint 2 at 0x20171b4: file ./cplus-dem.c, line 3597.
> (gdb) c
> Continuing.
> Breakpoint 2, get_count (type=, count=) at 
> ./cplus-dem.c:3597
> 3597  n *= 10;
> (gdb) n
> cplus-dem.c:3597:10: runtime error: signed integer overflow: 7 * 10 
> cannot be represented in type 'int'
> SUMMARY: AddressSanitizer: undefined-behavior cplus-dem.c:3597:10 in
> 3598  n += *p - '0';
> (gdb) n
> 3599  p++;

[Bug c++/87607] Cannot use fold expression in static_assert

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
You've got the syntax for a fold-expression wrong. The parentheses around the
expression are required:

template
void f(Args ...args) {
static_assert((is_same::value && ...));
}

This compiles fine.

[Bug fortran/54613] [F08] Add FINDLOC plus support MAXLOC/MINLOC with KIND=/BACK=

[tkoenig at gcc dot gnu.org]

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

--- Comment #16 from Thomas Koenig  ---
Here are test cases. I tried to walk through most of the
code paths.

! { dg-do run }
! Various tests with findloc.
program main
  implicit none
  real, dimension(2,2) :: a, b
  integer, dimension(2,3) :: c
  logical, dimension(2,2) :: lo
  integer, dimension(:), allocatable :: e
  a = reshape([1.,2.,3.,4.], shape(a))
  b = reshape([1.,2.,1.,2.], shape(b))

  lo = .true.

  if (any(findloc(a, 5.) /= [0,0])) stop 1
  if (any(findloc(a, 5., back=.true.) /= [0,0])) stop 2
  if (any(findloc(a, 2.) /= [2,1])) stop 2
  if (any(findloc(a, 2. ,back=.true.) /= [2,1])) stop 3

  if (any(findloc(a,3.,mask=lo) /= [1,2])) stop 4
  if (any(findloc(a,3,mask=.true.) /= [1,2])) stop 5
  lo(1,2) = .false.
  if (any(findloc(a,3.,mask=lo) /= [0,0])) stop 6
  if (any(findloc(b,2.) /= [2,1])) stop 7
  if (any(findloc(b,2.,back=.true.) /= [2,2])) stop 8
  if (any(findloc(b,1.,mask=lo,back=.true.) /= [1,1])) stop 9
  if (any(findloc(b,1.,mask=.false.) /= [0,0])) stop 10

  c = reshape([1,2,2,2,-9,6], shape(c))
  if (any(findloc(c,value=2,dim=1) /= [2,1,0])) stop 11
  if (any(findloc(c,value=2,dim=2) /= [2,1])) stop 12
end program main

! { dg-do run }
! Various tests with findloc with character variables.
program main
  character(len=2) :: a(3,3), c(3,3), d(3,4)
  character(len=3) :: b(3,3)
  integer :: ret(2) 
  integer :: i,j
  character(len=3) :: s 
  logical :: lo 
  logical, dimension(3,4) :: msk
  data a /"11", "21", "31", "12", "22", "32", "13", "23", "33" /
  data b /"11 ", "21 ", "31 ", "12 ", "22 ", "32 ", "13 ", "23 ", "33 " /   
  if (any(findloc(a,"11 ") /= [1,1])) stop 1
  ret = findloc(b,"31") 
  do j=1,3  
 do i=1,3   
write(unit=s,fmt='(2I1," ")') i,j   
ret = findloc(b,s)  
if (b(ret(1),ret(2)) /= s) stop 2   
 end do 
  end do

  if (any(findloc(b(::2,::2),"13") /= [1,2])) stop 3

  do j=1,3  
do i=1,3
  write(unit=c(i,j),fmt='(I2)') 2+i-j   
end do
  end do

  if (any(findloc(c," 1") /= [1,2])) stop 4
  if (any(findloc(c," 1", back=.true.) /= [2,3])) stop 5
  if (any(findloc(c," 1", back=.true., mask=.false.) /= [0,0])) stop 6

  lo = .true.
  if (any(findloc(c," 2", dim=1) /= [1,2,3])) stop 7
  if (any(findloc(c," 2",dim=1,mask=lo) /= [1,2,3])) stop 8

  if (any(findloc(c," 2", dim=1,back=.true.) /= [1,2,3])) stop 9
  if (any(findloc(c," 2",dim=1,mask=lo,back=.true.) /= [1,2,3])) stop 10
  do j=1,4
 do i=1,3
if (j<= i) then
   d(i,j) = "AA"
else
   d(i,j) = "BB"
end if
 end do
  end do
  print '(4A3)', transpose(d)
  if (any(findloc(d,"AA") /= [1,1])) stop 11
  if (any(findloc(d,"BB") /= [1,2])) stop 12
  msk = .true.
  if (any(findloc(d,"AA", mask=msk) /= [1,1])) stop 11
  if (any(findloc(d,"BB", mask=msk) /= [1,2])) stop 12
  if (any(findloc(d,"AA", dim=1) /= [1,2,3,0])) stop 13
  if (any(findloc(d,"BB", dim=1) /= [0,1,1,1])) stop 14
  if (any(findloc(d,"AA", dim=2) /= [1,1,1])) stop 15
  if (any(findloc(d,"BB", dim=2) /= [2,3,4])) stop 16
  if (any(findloc(d,"AA", dim=1,mask=msk) /= [1,2,3,0])) stop 17
  if (any(findloc(d,"BB", dim=1,mask=msk) /= [0,1,1,1])) stop 18
  if (any(findloc(d,"AA", dim=2,mask=msk) /= [1,1,1])) stop 19
  if (any(findloc(d,"BB", dim=2,mask=msk) /= [2,3,4])) stop 20

  if (any(findloc(d,"AA", dim=1, back=.true.) /= [3,3,3,0])) stop 21
  if (any(findloc(d,"AA", dim=1, back=.true., mask=msk) /= [3,3,3,0])) stop 22
  if (any(findloc(d,"BB", dim=2, back=.true.) /= [4,4,4])) stop 23
  if (any(findloc(d,"BB", dim=2, back=.true.,mask=msk) /= [4,4,4])) stop 24

  msk(1,:) = .false.
  print '(4L3)', transpose(msk)
  if (any(findloc(d,"AA", dim=1,mask=msk) /= [2,2,3,0])) stop 21
  if (any(findloc(d,"BB", dim=2,mask=msk) /= [0,3,4])) stop 22
  if (any(findloc(d,"AA", dim=2, mask=msk, back=.true.) /= [0,2,3])) stop 23
  if (any(findloc(d,"AA", dim=1, mask=msk, back=.true.) /= [3,3,3,0])) stop 24

end program main

[Bug fortran/54613] [F08] Add FINDLOC plus support MAXLOC/MINLOC with KIND=/BACK=

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

  Attachment #44834|0   |1
is obsolete||

--- Comment #15 from Thomas Koenig  ---
Created attachment 44840
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44840&action=edit
Patch for the library version, minus quite a few bugs

OK, so here is something that people can actually test.

It currently has no support for simplification and no
support for findloc(rank_one_array,value,dim=1), but otherwise
it looks quite good.

If you apply this, the libgfortran/generated/findloc* files will be
added; if you apply it for a second time, everything will be added
twice in the files, which will lead to many confusing error messages :-)

Currently, you have to add -static-libgfortran to the command line
for this to work, because I didn't add the symbols to gfortran.map
yet (but this should be straightforward).

Design decision: To avoid combinatorial explosion, the library
files use index_type only.  For other integer kinds, the
results are converted on return.

[Bug fortran/58618] Wrong code with character substring and ASSOCIATE

[dominiq at lps dot ens.fr]

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

--- Comment #9 from Dominique d'Humieres  ---
With the patch in comment 8, the wrong-code is replaced with an ICE

pr58618.f90:2:0:

2 | associate (x=>s(1)(1:1))
  | 
internal compiler error: in fold_convert_loc, at fold-const.c:2425

(configured with --enable-checking=yes).

[Bug tree-optimization/87609] [6/7/8/9 Regression] miscompilation with restrict and loop

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
This changed first with r218005, where with -O3 it started to output 7 7
instead of 7 10 and since r235765 we output 10 7.

[Bug target/87288] [8 Regression] Segfault after const_cast with "-O2 -ftree-loop-vectorize" but _without_ "-mavx"

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
  Known to work||9.0
Summary|[8/9 Regression] Segfault   |[8 Regression] Segfault
   |after const_cast with "-O2  |after const_cast with "-O2
   |-ftree-loop-vectorize" but  |-ftree-loop-vectorize" but
   |_without_ "-mavx"   |_without_ "-mavx"
  Known to fail|8.2.1, 9.0  |8.2.0

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

[Bug tree-optimization/87608] Very slow swap operations

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-10-15
  Component|rtl-optimization|tree-optimization
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
I believe this is another case where an early phiopt pass would help.  We have
a sequence of

   :
  _1 = first_522(D) + 64;
  t_525 = *first_522(D);
  _3 = MEM[(int *)first_522(D) + 64B];
  if (_3 <= t_525)
goto ; [INV]
  else
goto ; [INV]

   :

   :
  # iftmp.0_391 = PHI <_3(3), t_525(2)>

in which the VRP1 pass mixes up the CFG via jump-threading so that the
later phiopt pass no longer sees this min/max patterns.

I have (even posted) a nearly finished patch to move phiopt1 early but
it had some fallout.  I'm not sure if I can find enough cycles to finish
it for GCC 9.  Some ideas were restricting it to min/max/abs recognition
because that's what most PRs talk about.  Another idea would be to move
both ifcombine and phiopt before the first real jump-threading pass (vrp1)
since most "bad" effects of moving phiopt were related to missed ifcombine
optimizations.

[Bug tree-optimization/87609] [6/7/8/9 Regression] miscompilation with restrict and loop

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |ASSIGNED
  Known to work||4.8.5
   Keywords||wrong-code
   Last reconfirmed||2018-10-15
 CC||amker at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1
Summary|miscompilation with |[6/7/8/9 Regression]
   |restrict and loop   |miscompilation with
   ||restrict and loop
   Target Milestone|--- |6.5
  Known to fail||5.5.0

--- Comment #1 from Richard Biener  ---
Confirmed.  GCC 5 and 6 output

7 7

even.  GCC 4.8 works.

This is is GIMPLE level unrolling exposing non-dependence between iterations
where that doesn't actually hold.  We've talked about this issue when
trying to expose to later passes the result of runtime dependence checks
but it of course also exists when the non-dependence is recorded via
restrict.

We have to treat unrolling similar to inlining and re-map the base/clique
sets accordingly.  Versioning should be fine(?).

I'll see if I can find time to address this in our generic infrastructure.