[Bug c++/87480] [8/9 Regression] SFINAE constructor not matched, only in templated function

2019-03-18 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87480

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/89767] ICE with tuple and optimization

2019-03-18 Thread klystron25 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89767

--- Comment #1 from Steven Blah  ---
This also fails on 8.2.

[Bug c++/89767] New: ICE with tuple and optimization

2019-03-18 Thread klystron25 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89767

Bug ID: 89767
   Summary: ICE with tuple and optimization
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: klystron25 at gmail dot com
  Target Milestone: ---

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

The following source file causes ICE when -O2 is used. This code compiles
correctly with the same command line on gcc 7.3.0.

This is gcc 8.3.0 running on amd64. I am runnig gentoo, but I downloaded 8.3.0
source and built it from scratch just to ensure it wasn't gentoo's patchset. I
tried a simple configure with just --enable-languages=c,c++ and then this below
which I'm providing the report from:

Configured with: /var/tmp/portage/sys-devel/gcc-8.3.0/work/gcc-8.3.0/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/8.3.0
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/8.3.0
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/8.3.0/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/8.3.0/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/include/g++-v8
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/8.3.0/python
--enable-languages=c,c++ --enable-obsolete --enable-secureplt --disable-werror
--with-system-zlib --enable-nls --without-included-gettext
--enable-checking=release --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo 8.3.0 p1.0' --disable-esp --enable-libstdcxx-time
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64
--disable-altivec --disable-fixed-point --enable-targets=all --enable-libgomp
--disable-libmudflap --disable-libssp --disable-libmpx --disable-systemtap
--enable-vtable-verify --disable-libquadmath --enable-lto --without-isl
--enable-default-pie --enable-default-ssp
Thread model: posix

/home/darkwing/gcc/usr/x86_64-pc-linux-gnu/gcc-bin/8.3.0/c++  -Dmsb_EXPORTS
-I/home/darkwing/work/nasa/pace/opt/include/efsi
-I/home/darkwing/work/efs/sts/repos/cvt/msb/libmsb/include
-I/home/darkwing/work/efs/sts/repos/cvt/msb/libmsb/include/internal  -fPIC  
-fvisibility=hidden --std=c++14 -pedantic -Wall -Wextra -Wundef
-Wno-noexcept-type -save-temps -o
CMakeFiles/msb.dir/src/connection/internal.cpp.o -c
/home/darkwing/work/efs/sts/repos/cvt/msb/libmsb/src/connection/internal.cpp
-O2

In file included from
/home/darkwing/gcc/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/include/g++-v8/bits/hashtable_policy.h:34,
 from
/home/darkwing/gcc/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/include/g++-v8/bits/hashtable.h:35,
 from
/home/darkwing/gcc/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/include/g++-v8/unordered_map:46,
 from
/home/darkwing/work/efs/sts/repos/cvt/msb/libmsb/include/internal/connection.hpp:4,
 from
/home/darkwing/work/efs/sts/repos/cvt/msb/libmsb/src/connection/internal.cpp:1:
/home/darkwing/gcc/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/include/g++-v8/tuple:
In instantiation of ‘constexpr _Head& std::__get_helper(std::_Tuple_impl<_Idx,
_Head, _Tail ...>&) [with long unsigned int __i = 1; _Head =
std::shared_ptr; _Tail = {}]’:
/home/darkwing/gcc/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/include/g++-v8/tuple:1315:36:
  required from ‘constexpr std::__tuple_element_t<__i, std::tuple<_Elements
...> >& std::get(std::tuple<_Elements ...>&) [with long unsigned int __i = 1;
_Elements = {std::shared_ptr,
std::shared_ptr}; std::__tuple_element_t<__i, std::tuple<_Elements
...> > = std::shared_ptr]’
/home/darkwing/work/efs/sts/repos/cvt/msb/libmsb/src/connection/internal.cpp:92:92:
  required from here
/home/darkwing/gcc/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/include/g++-v8/tuple:1303:5:
internal compiler error: Segmentation fault
 __get_helper(_Tuple_impl<__i, _Head, _Tail...>& __t) noexcept
 ^~~~
0xb5688f crash_signal
../../gcc-8.3.0/gcc/toplev.c:325
0x66d25d check_local_shadow
../../gcc-8.3.0/gcc/cp/name-lookup.c:2670
0x66d25d do_pushdecl
../../gcc-8.3.0/gcc/cp/name-lookup.c:3084
0x66d25d pushdecl(tree_node*, bool)
../../gcc-8.3.0/gcc/cp/name-lookup.c:3152
0x617626 store_parm_decls
../../gcc-8.3.0/gcc/cp/decl.c:15454
0x617626 start_preparsed_function(tree_node*, tree_node*, int)
../../gcc-8.3.0/gcc/cp/decl.c:15328
0x6b84b8 instantiate_decl(tree_node*, bool, bool)
../../gcc-8.3.0/gcc/cp/pt.c:24048
0x5f26e4 cxx_eval_call_expression
../../gcc-8.3.0/gcc/cp/constexpr.c:1563
0x5f374d cxx_eval_constant_expression
../../gcc-8.3.0/gcc/cp/constexpr.c:4231
0x5f741c cxx_eval_outermost_constant_expr

[Bug tree-optimization/89720] [9 Regression] Spurious -Warray-bounds warning on a range with max < min

2019-03-18 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89720

--- Comment #6 from Martin Sebor  ---
(In reply to Steinar H. Gunderson from comment #3)
> Are there also any plans to make the warning easier to trace?

If you are referring to the missing inlining context (as discussed in bug
86650) then hopefully in GCC 10.  Otherwise please explain what you mean, or
better yet, open a bug pointing out the problem.

[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds

2019-03-18 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
Bug 56456 depends on bug 89720, which changed state.

Bug 89720 Summary: [9 Regression] Spurious -Warray-bounds warning on a range 
with max < min
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89720

   What|Removed |Added

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

[Bug tree-optimization/89720] [9 Regression] Spurious -Warray-bounds warning on a range with max < min

2019-03-18 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89720

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Sebor  ---
Patch committed in r269785.

[Bug tree-optimization/89720] [9 Regression] Spurious -Warray-bounds warning on a range with max < min

2019-03-18 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89720

--- Comment #4 from Martin Sebor  ---
Author: msebor
Date: Mon Mar 18 23:48:50 2019
New Revision: 269785

URL: https://gcc.gnu.org/viewcvs?rev=269785=gcc=rev
Log:
PR tree-optimization/89720 - Spurious -Warray-bounds warning on a range with
max < min

gcc/ChangeLog:

PR tree-optimization/89720
* tree-vrp.c (vrp_prop::check_mem_ref): Treat range with max < min
more conservatively, the same as anti-range.

gcc/testsuite/ChangeLog:

PR tree-optimization/89720
* gcc.dg/Warray-bounds-42.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/Warray-bounds-42.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vrp.c

Invitation to Submit Your Paper

2019-03-18 Thread Maydim Malkov

Dear Researcher/Author,
We publish peer-reviewed academic journals dedicated to the advancement of
innovative science and technology. Now we sincerely invite scholars and
researchers to submit papers to the journals or to join in the editorial
board/reviewer team.
Invitation of Being the Member of the Editorial Board/Reviewer
To expand the editorial board and reviewer team, we would like to invite
you to be the editorial member or reviewer of our journals with great
sincerity. If you are eager for more information of the Benefits and
Responsibilities of the editorial member or reviewer, please feel free to
visit the following link:
http://www.ajepes.org/journals
Invitation to Submit Your Research Articles
We have published 200+ online, peer-reviewed journals. If you have some new
works in your specialized or interested field, welcome to submit your
papers to the corresponding Journals or Special Issues so as to share your
ideas with people around the world.
List of Featured Journals

   1. Modern Chemistry
   2. History Research
   3. International Journal of Sustainable Development Research
   4. International Journal of Biomedical Science and Engineering
   5. American Journal of Pediatrics
   6. Journal of Water Resources and Ocean Science
   7. International Journal of Mechanical Engineering and Applications
   8. Journal of Finance and Accounting

Please kindly let us know if there is any doubt.
All the best,
Jessie Wright


[Bug c++/80265] __builtin_{memcmp,memchr,strlen} are not usable in constexpr functions

2019-03-18 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265

--- Comment #40 from Jonathan Wakely  ---
I'm not sure if we really need these builtins in constexpr functions now, as we
can use is_constant_evaluated to avoid dispatching to optimised implementations
using memcmp. Maybe we can close this.

[Bug other/44032] internals documentation is not legally safe to use

2019-03-18 Thread joseph at codesourcery dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44032

--- Comment #6 from joseph at codesourcery dot com  ---
I don't have anything further to add on this issue.  If you want a 
docstring relicensing review you should say so when submitting a patch; 
for other cases of relicensing not covered by that, ask RMS.

[Bug c++/89766] New: ICE: canonical types differ for identical types, -std=c++17

2019-03-18 Thread rimvydas.jas at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89766

Bug ID: 89766
   Summary: ICE: canonical types differ for identical types,
-std=c++17
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rimvydas.jas at gmail dot com
  Target Milestone: ---

Using gcc-8 branch c++17 three different(?) ICEs with -fchecking while
compiling boost:

$ /opt/gcc8/bin/g++ --version # on DragonFlyBSD
g++ (GCC) 8.3.1 20190318 [gcc-8-branch revision
5d34f779cb1:731cdfacfef:2f978d6d097b6ad2a2fdff05d1f20a86ab674ceb]

 from libs/contract/src/contract.cpp:11:
./boost/function/function_template.hpp:523:9: internal compiler error:
canonical types differ for identical types 'F' and 'FunctionPtr'
Reduced testcase:
$ cat creduce_contract.ii
template  class a> struct b {
  template  static int c;
  decltype(c);
};
template  struct d {
  template  bool e() const;
  template  bool e() const;
}
/opt/gcc8/bin/g++ -std=c++17 -c creduce_contract.ii
creduce_contract.ii:7:47: internal compiler error: canonical types differ for
identical types 'a' and ''
   template  bool e() const;
   ^
0x9c13e8 comptypes(tree_node*, tree_node*, int)
 /zzz/gcc/gcc_git/gcc/cp/typeck.c:1480
0x933082 comp_template_parms(tree_node const*, tree_node const*)
 /zzz/gcc/gcc_git/gcc/cp/pt.c:3302
0x823f67 add_method(tree_node*, tree_node*, bool)
 /zzz/gcc/gcc_git/gcc/cp/class.c:1062
0x99276e finish_member_declaration(tree_node*)
 /zzz/gcc/gcc_git/gcc/cp/semantics.c:3114
0x929c87 cp_parser_template_declaration_after_parameters
 /zzz/gcc/gcc_git/gcc/cp/parser.c:27077
0x92a4bc cp_parser_explicit_template_declaration
 /zzz/gcc/gcc_git/gcc/cp/parser.c:27236
0x92a4bc cp_parser_template_declaration_after_export
 /zzz/gcc/gcc_git/gcc/cp/parser.c:27255
0x914fed cp_parser_member_declaration
 /zzz/gcc/gcc_git/gcc/cp/parser.c:23552
0x915eda cp_parser_member_specification_opt
...

 from libs/log/src/severity_level.cpp:18:
./boost/parameter/aux_/tagged_argument.hpp:132:5: internal compiler error:
canonical types differ for identical types 'Default' and 'F'
Reduced testcase:
$ cat creduce_severity_level.ii
template  class> struct a;
template  class b> struct a;
template  struct c {
  template  int operator[](int) const;
  template  int operator[](int) const;
};
/opt/gcc8/bin/g++ -std=c++17 -c creduce_severity_level.ii
creduce_severity_level.ii:5:47: internal compiler error: canonical types differ
for identical types '' and 'b'
   template  int operator[](int) const;
   ^
0x9c13e8 comptypes(tree_node*, tree_node*, int)
 /zzz/gcc/gcc_git/gcc/cp/typeck.c:1480
0x933082 comp_template_parms(tree_node const*, tree_node const*)
 /zzz/gcc/gcc_git/gcc/cp/pt.c:3302
0x823f67 add_method(tree_node*, tree_node*, bool)
 /zzz/gcc/gcc_git/gcc/cp/class.c:1062
0x99276e finish_member_declaration(tree_node*)
 /zzz/gcc/gcc_git/gcc/cp/semantics.c:3114
0x929c87 cp_parser_template_declaration_after_parameters
 /zzz/gcc/gcc_git/gcc/cp/parser.c:27077
0x92a4bc cp_parser_explicit_template_declaration
 /zzz/gcc/gcc_git/gcc/cp/parser.c:27236
0x92a4bc cp_parser_template_declaration_after_export
 /zzz/gcc/gcc_git/gcc/cp/parser.c:27255
0x914fed cp_parser_member_declaration
 /zzz/gcc/gcc_git/gcc/cp/parser.c:23552
0x915eda cp_parser_member_specification_opt
...

 from libs/log/src/setup/default_filter_factory.cpp:22:
./boost/spirit/home/support/action_dispatch.hpp:180:9: internal compiler error:
canonical types differ for identical types 'F' and 'Eval'
Reduced testcase:
$ cat creduce_default_filter_factory.ii
template  class> struct a;
template  class b> struct a;
template  struct c {
  template  bool operator()();
  template  bool operator()();
};
$ /opt/gcc8/bin/g++ -std=c++17 -c creduce_default_filter_factory.ii
creduce_default_filter_factory.ii:5:60: internal compiler error: canonical
types differ for identical types 'b' and ''
   template  bool operator()();
^
0x9c13e8 comptypes(tree_node*, tree_node*, int)
 /zzz/gcc/gcc_git/gcc/cp/typeck.c:1480
0x933082 comp_template_parms(tree_node const*, tree_node const*)
 /zzz/gcc/gcc_git/gcc/cp/pt.c:3302
0x823f67 add_method(tree_node*, tree_node*, bool)
 /zzz/gcc/gcc_git/gcc/cp/class.c:1062
0x99276e finish_member_declaration(tree_node*)
 /zzz/gcc/gcc_git/gcc/cp/semantics.c:3114
0x929c87 cp_parser_template_declaration_after_parameters
 /zzz/gcc/gcc_git/gcc/cp/parser.c:27077
0x92a4bc cp_parser_explicit_template_declaration
 /zzz/gcc/gcc_git/gcc/cp/parser.c:27236
0x92a4bc cp_parser_template_declaration_after_export
 /zzz/gcc/gcc_git/gcc/cp/parser.c:27255
0x914fed cp_parser_member_declaration
 /zzz/gcc/gcc_git/gcc/cp/parser.c:23552
0x915eda cp_parser_member_sp

[Bug c++/89630] [9 Regression] FAIL: g++.dg/cpp0x/alias-decl-64.C

2019-03-18 Thread hjl at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89630

--- Comment #10 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Mon Mar 18 21:22:30 2019
New Revision: 269781

URL: https://gcc.gnu.org/viewcvs?rev=269781=gcc=rev
Log:
Add a test for PR c++/89630

PR c++/89630
* g++.target/i386/pr89630.C: New test.

Added:
trunk/gcc/testsuite/g++.target/i386/pr89630.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug target/82170] gcc optimizes int range-checking poorly on x86-64

2019-03-18 Thread eggert at gnu dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82170

Paul Eggert  changed:

   What|Removed |Added

Version|7.1.1   |8.3.1

--- Comment #10 from Paul Eggert  ---
I just now ran into this problem in another situation and so was reminded of
this bug report.

For what it's worth, clang does a good job of optimizing these comparisons. I
just now compiled the sample C source code attached to this bug report, and
clang version 7.0.1 (Fedora 7.0.1-4.fc29) x86-64 generates the same code for
checked_arg_portable that it does for checked_arg_GCC7, whereas GCC 8.3.1
20190223 (Red Hat 8.3.1-2) x86-64 still generates poorly-optimized code for
checked_arg_portable.

[Bug tree-optimization/89720] [9 Regression] Spurious -Warray-bounds warning on a range with max < min

2019-03-18 Thread steinar+gcc at gunderson dot no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89720

--- Comment #3 from Steinar H. Gunderson  ---
Are there also any plans to make the warning easier to trace?

[Bug c++/89640] [9 Regression] g++ chokes on lambda with __attribute__

2019-03-18 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89640

Jason Merrill  changed:

   What|Removed |Added

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

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

[Bug c++/89761] [9 Regression] ICE: tree check: expected class 'expression', have 'exceptional' (argument_pack_select)

2019-03-18 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89761

Jason Merrill  changed:

   What|Removed |Added

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

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

[Bug c++/89630] [9 Regression] FAIL: g++.dg/cpp0x/alias-decl-64.C

2019-03-18 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89630

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #9 from Jason Merrill  ---
Should be fixed.

[Bug libstdc++/89763] Making iterator's operator== breaks existing code

2019-03-18 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89763

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
It only breaks code that is already broken, and wouldn't compile with other
compilers anyway.

The standard says that map's iterator type is implementation defined, so it's
wrong to assume it has a operator== member function. All that's guaranteed is
that x==y is a valid expression, not x.operator==(y).

[Bug c++/89741] [9 Regression] static_assert fires when template not instantiated

2019-03-18 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89741

--- Comment #11 from Jonathan Wakely  ---
(In reply to Tadeus Prastowo from comment #7)
> The code in question, which is simplified below to match the real use-case,
> does not involve template specialization, and so, the quoted passage does
> not apply:

As Jakub said, the rule refers to all template specializations, not just
partial specializations and explicit specializations.

X is a template, X<0> is a specialization of that template.

[Bug c++/58074] [C++11][DR 1333] __is_trivial intrinsic fails for deleted members and for non-trivial copy-c'tors

2019-03-18 Thread richard-gccbugzilla at metafoo dot co.uk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58074

--- Comment #11 from Richard Smith  
---
The point of trivial (as distinguished from trivially-copyable) is that an
instance of type T can be created and "properly" initialized (albeit left with
an indeterminate value) without executing any code.

(The notion of a trivial type is not used by the core language, and is used in
the library only to constrain things like the template parameters of
basic_string and aligned_storage, where it is intentional that objects of type
T can be created by allocating suitable storage and performing no further
initialization.)

So I think the language rule after the application of the relevant DRs is
approximately right: a type with a deleted default constructor should not be
considered trivial.

(It's arguable that a type with multiple default constructors should perhaps
also not be considered trivial. Or maybe we should decide that the language
notion of "trivial" is a useless relic of "POD" and should be removed from the
core language, and that the library should be looking for types that are
trivially default-constructible and trivially-copyable in the places where it
currently looks for "trivial" types.)

[Bug middle-end/88273] [8 Regression] warning: 'memcpy' offset [-527, -529] is out of the bounds [0, 16] of object 'vrsave' with type 'union ' [-Warray-bounds]

2019-03-18 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88273

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
  Known to fail||8.3.0

--- Comment #15 from Martin Sebor  ---
Fixed in GCC 8.4 via r269778.

[Bug middle-end/88273] [8 Regression] warning: 'memcpy' offset [-527, -529] is out of the bounds [0, 16] of object 'vrsave' with type 'union ' [-Warray-bounds]

2019-03-18 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88273

--- Comment #14 from Martin Sebor  ---
Author: msebor
Date: Mon Mar 18 19:44:02 2019
New Revision: 269778

URL: https://gcc.gnu.org/viewcvs?rev=269778=gcc=rev
Log:
Backport from mainline:

PR middle-end/88273 - [8/9 Regression] warning: 'memcpy' offset [-527, -529]
is out of the bounds [0, 16]

gcc/ChangeLog:

PR middle-end/88273
* gimple-ssa-warn-restrict.c (builtin_memref::extend_offset_range):
Handle anti-ranges the same as no range at all.

gcc/testsuite/ChangeLog:

PR middle-end/88273
* gcc.dg/Warray-bounds-38.c: New test.

Added:
branches/gcc-8-branch/gcc/testsuite/gcc.dg/Warray-bounds-38.c
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/gimple-ssa-warn-restrict.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug c++/89630] [9 Regression] FAIL: g++.dg/cpp0x/alias-decl-64.C

2019-03-18 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89630

--- Comment #8 from Jason Merrill  ---
Author: jason
Date: Mon Mar 18 19:37:00 2019
New Revision: 269777

URL: https://gcc.gnu.org/viewcvs?rev=269777=gcc=rev
Log:
PR c++/89630 - ICE with dependent using-decl as template arg.

Even though these two using-declarations have the same effect, they are not
the same declaration, and we don't need to work to treat them as the same
like we do for typedefs.  If we did need to, we would need to handle them
specially in iterative_hash_template_arg as well as here.

* tree.c (cp_tree_equal): Always return false for USING_DECL.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/tree.c

[Bug c++/89761] [9 Regression] ICE: tree check: expected class 'expression', have 'exceptional' (argument_pack_select)

2019-03-18 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89761

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Mon Mar 18 19:35:12 2019
New Revision: 269776

URL: https://gcc.gnu.org/viewcvs?rev=269776=gcc=rev
Log:
PR c++/89761 - ICE with sizeof... in pack expansion.

In this testcase we get confused when looking at the sizeof... because the
argument pack for 'args' has been wrapped in an ARGUMENT_PACK_SELECT as part
of expanding the fold-expression.  We handle this situation a bit lower down
in tsubst_pack_expansion, but that doesn't help the call to
argument_pack_element_is_expansion_p, which happens earlier.

* pt.c (argument_pack_element_is_expansion_p): Handle
ARGUMENT_PACK_SELECT.

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

[Bug c++/89640] [9 Regression] g++ chokes on lambda with __attribute__

2019-03-18 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89640

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Mon Mar 18 19:34:47 2019
New Revision: 269775

URL: https://gcc.gnu.org/viewcvs?rev=269775=gcc=rev
Log:
PR c++/89640 - GNU attributes on lambda.

My patch for PR 60503 to fix C++11 attribute parsing on lambdas accidentally
removed support for GNU attributes.

* parser.c (cp_parser_lambda_declarator_opt): Allow GNU attributes.

Added:
trunk/gcc/testsuite/g++.dg/ext/attr-lambda1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c

[Bug c++/60503] gcc looks for C++ attributes in the wrong place in a lambda-expression

2019-03-18 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60503

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Mon Mar 18 19:34:47 2019
New Revision: 269775

URL: https://gcc.gnu.org/viewcvs?rev=269775=gcc=rev
Log:
PR c++/89640 - GNU attributes on lambda.

My patch for PR 60503 to fix C++11 attribute parsing on lambdas accidentally
removed support for GNU attributes.

* parser.c (cp_parser_lambda_declarator_opt): Allow GNU attributes.

Added:
trunk/gcc/testsuite/g++.dg/ext/attr-lambda1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c

[Bug c++/87996] [8 Regression] "size of array is negative" error when SIZE_MAX/2 < sizeof(array) <= SIZE_MAX

2019-03-18 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87996

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #8 from Martin Sebor  ---
I don't think the bug is important enough to backport the fix to GCC 8 (if it
were to be backported the patch for PR 89294 needs to go along with it).  With
that I'm resolving it as fixed.  Richard, if you would prefer it backported
please reopen this bug.

[Bug target/89765] New: Multiple problems with vec-insert implementation on PowerPC

2019-03-18 Thread kelvin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89765

Bug ID: 89765
   Summary: Multiple problems with vec-insert implementation on
PowerPC
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kelvin at gcc dot gnu.org
CC: segher at gcc dot gnu.org, wschmidt at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc*-*-*

Created attachment 45993
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45993=edit
Reproducer source file

The attached test program demonstrates multiple shortcomings with the
implementation of vec-insert.

If this test program is compiled with

#define SEPARATE_PROBLEM

an internal compiler error results:

$GCC_BUILD/gcc/xgcc -B$GCC_BUILD/gcc/ -g -fno-use-linker-plugin -maltivec -mvsx
-O1 -o vec-insert.exe vec-insert.c
vec-insert.c: In function ‘set_auto_n_uint128’:
vec-insert.c:81:1: error: conversion of an SSA_NAME on the left hand side
   81 | set_auto_n_uint128 (vector unsigned __int128 a, int n, unsigned
__int128 e)
  | ^~
VIEW_CONVERT_EXPR<__int128 unsigned>(_1);

VIEW_CONVERT_EXPR<__int128 unsigned>(_1) = e;
vec-insert.c:81:1: internal compiler error: verify_gimple failed
0x10b21feb verify_gimple_in_seq(gimple*)
/home/kelvin/gcc-root/gcc-trunk/gcc/tree-cfg.c:5046
0x1069c747 gimplify_body(tree_node*, bool)
/home/kelvin/gcc-root/gcc-trunk/gcc/gimplify.c:13712
0x1069cb13 gimplify_function_tree(tree_node*)
/home/kelvin/gcc-root/gcc-trunk/gcc/gimplify.c:13802
0x103e94d7 cgraph_node::analyze()
/home/kelvin/gcc-root/gcc-trunk/gcc/cgraphunit.c:667
0x103edb37 analyze_functions
/home/kelvin/gcc-root/gcc-trunk/gcc/cgraphunit.c:1126
0x103eeebb symbol_table::finalize_compilation_unit()
/home/kelvin/gcc-root/gcc-trunk/gcc/cgraphunit.c:2837
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
Makefile:26: recipe for target 'vec-insert.exe' failed
make: *** [vec-insert.exe] Error 1

When compiled without defining SEPARATE_PROBLEM, the resulting executable
fails, apparently because the translations of the vec_insert built-in  fail to
use modulo arithmetic to compute the index of the selector expression.

(A recent patch corrected similar problems in the implementation of vec-extract
and this test program is derived from one of the regression tests that was
submitted with that patch.)

[Bug c++/89630] [9 Regression] FAIL: g++.dg/cpp0x/alias-decl-64.C

2019-03-18 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89630

Jason Merrill  changed:

   What|Removed |Added

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

[Bug tree-optimization/89720] [9 Regression] Spurious -Warray-bounds warning on a range with max < min

2019-03-18 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89720

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch
Summary|[9 Regression] Spurious |[9 Regression] Spurious
   |-Warray-bounds warning  |-Warray-bounds warning on a
   ||range with max < min

--- Comment #2 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2019-03/msg00860.html

[Bug libfortran/79540] [7/8/9 Regression] FAIL: gfortran.dg/fmt_fw_d.f90 -O0 execution test

2019-03-18 Thread dave.anglin at bell dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79540

--- Comment #21 from dave.anglin at bell dot net ---
On 2019-03-18 2:15 p.m., dominiq at lps dot ens.fr wrote:
> Are you planning to submit the patch to the mail lists?
While it seems to work, it is clear the author of this code thought ndigits was
positive.
So, something else might be wrong.

[Bug libfortran/79540] [7/8/9 Regression] FAIL: gfortran.dg/fmt_fw_d.f90 -O0 execution test

2019-03-18 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79540

--- Comment #20 from Dominique d'Humieres  ---
> Created attachment 45989 [details]
> Patch
>
> This fixes the stack overflow in memcpy.

Are you planning to submit the patch to the mail lists?

[Bug c++/89757] accepts returning with reference to temporary in constant expression

2019-03-18 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89757

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
 Blocks||55004

--- Comment #2 from Martin Sebor  ---
In the test case below with pointers rather than references the first static
assertion also isn't rejected despite being undefined, and despite the
-Wreturn-local-addr.  (Clang fails the first assertion because unlike GCC it
doesn't fold the return address to null.)

$ cat t.C && gcc -S -Wall t.C
constexpr int* f (int i)
{
  return 
}

static_assert (nullptr == f (123));
static_assert (nullptr != f (123));
t.C: In function ‘constexpr int* f(int)’:
t.C:3:10: warning: address of local variable ‘i’ returned [-Wreturn-local-addr]
3 |   return 
  |  ^~
t.C:1:23: note: declared here
1 | constexpr int* f (int i)
  |   ^
t.C: At global scope:
t.C:7:24: error: static assertion failed
7 | static_assert (nullptr != f (123));
  |^~


Referenced Bugs:

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

[Bug sanitizer/89764] New: ubsan diagnostic on generic lambdas decayed to function pointers

2019-03-18 Thread patrick.a.moran at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89764

Bug ID: 89764
   Summary: ubsan diagnostic on generic lambdas decayed to
function pointers
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick.a.moran at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

Created attachment 45992
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45992=edit
The minimal reproduction as a separate file

I've observed this on a vanilla built-from-source gcc 8.3.0. You can reproduce
by running (with the attached repro.cpp)

gcc -fsanitize=undefined repro.cpp -o repro && ./repro

You get the error message

repro.cpp:2:34: runtime error: member call on null pointer of type 'const
struct __lambda0'

The error does occur if a generic lambda with an empty capture is used, but the
error does not occur if a non-generic lambda with an empty capture is used (ie,
if you alter the repro to replace the "auto" with an "int", the error goes
away).

I know that by 8.1.5.1.6, the produced function point need only have "the same
effect as invoking the closure type’s function call operator", so requiring the
closure object to still be alive for the free function to be called is probably
one of the permitted behaviors, but I was hoping that this was unintentional,
particularly since that is true of non-generic lambdas. Being able to use
lambdas with empty captures to generate free functions is an ergonomic win for
us.

[Bug fortran/68009] [7/8/9 Regression] prototype for gfortran_runtime_error with inline matmul

2019-03-18 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68009

--- Comment #13 from Thomas Koenig  ---
Author: tkoenig
Date: Mon Mar 18 17:35:54 2019
New Revision: 269769

URL: https://gcc.gnu.org/viewcvs?rev=269769=gcc=rev
Log:
2019-03-18  Thomas Koenig  

PR fortran/68009
* iresolve.c: Include trans.h.
(gfc_resolve_fe_runtine_error): Set backend_decl on
resolved_sym.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/iresolve.c

[Bug c++/89757] accepts returning with reference to temporary in constant expression

2019-03-18 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89757

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-18
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Guess we also want to improve the -Wreturn-local-addr warning too.
Unfortunately:
--- gcc/cp/typeck.c.jj  2019-03-15 18:49:44.266307154 +0100
+++ gcc/cp/typeck.c 2019-03-18 18:24:33.791604856 +0100
@@ -9194,6 +9194,10 @@ maybe_warn_about_returning_address_of_lo
   else if (CONVERT_EXPR_P (whats_returned)
   || TREE_CODE (whats_returned) == NON_LVALUE_EXPR)
whats_returned = TREE_OPERAND (whats_returned, 0);
+  else if (VAR_P (whats_returned)
+  && DECL_INITIAL (whats_returned)
+  && TYPE_REF_P (TREE_TYPE (whats_returned)))
+   whats_returned = DECL_INITIAL (whats_returned);
   else
break;
 }
doesn't handle it, because for some reason we don't have DECL_INITIAL for the
reference, initialize it by a separate stmt.

Another example of the need to track variable lifetime during constexpr
evaluation is:
constexpr const int &
foo ()
{
  const int *p = nullptr;
  {
const int r = 2;
p = 
  }
  return *p;
}

constexpr int a = foo ();

[Bug libstdc++/89763] New: Making iterator's operator== breaks existing code

2019-03-18 Thread dan at stahlke dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89763

Bug ID: 89763
   Summary: Making iterator's operator== breaks existing code
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dan at stahlke dot org
  Target Milestone: ---

gcc 9 has made operator== and operator!= free functions for std::map (and
probably other) iterators.  Probably this is considered an implementation
detail and not a violation of the standard, but I thought I'd bring it to your
attention that this breaks CINT.

CINT does things like this:

./src/gcc3strm.cxx: 
G__letint(result7,103,(long)((fpos*)(G__getstructoffset()))->operator==(*(fpos*)libp->para[0].ref));
./src/Apiifold.cxx: 
G__letint(result7,105,(long)((G__ClassInfo*)(G__getstructoffset()))->operator==(*(G__ClassInfo*)libp->para[0].ref));
./src/Apiifold.cxx: 
G__letint(result7,105,(long)((G__TypeInfo*)(G__getstructoffset()))->operator==(*(G__TypeInfo*)libp->para[0].ref));
./src/Apiif.cxx: 
G__letint(result7,105,(long)((G__ClassInfo*)(G__getstructoffset()))->operator==(*(G__ClassInfo*)libp->para[0].ref));
./src/Apiif.cxx: 
G__letint(result7,105,(long)((G__TypeInfo*)(G__getstructoffset()))->operator==(*(G__TypeInfo*)libp->para[0].ref));

Given that CINT is no longer supported, CERN is not likely to release any
patches for this.

Here is a standalone demonstration of the issue:

#include 

bool f()
{
std::map m;
auto it = m.begin();
return it.operator==(it);
}

[Bug lto/89762] New: Mixing optimization levels with ostream gives lto1: internal compiler error: in get_odr_type, at ipa-devirt.c:2098

2019-03-18 Thread dan at stahlke dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89762

Bug ID: 89762
   Summary: Mixing optimization levels with ostream gives lto1:
internal compiler error: in get_odr_type, at
ipa-devirt.c:2098
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dan at stahlke dot org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

=== A.cpp

#include 
std::ostream *a;
int main() { }

=== B.cpp

#include 
std::ostream *b;

=== script (note different optimization levels)

rm -f A.o B.o AB
$CXX -flto -Wall -O1 -c A.cpp -o A.o
$CXX -flto -Wall -O2 -c B.cpp -o B.o
$CXX -flto A.o B.o -o AB

=== result

lto1: internal compiler error: in get_odr_type, at ipa-devirt.c:2098
0x5d4a06 get_odr_type(tree_node*, bool) 
../../gcc-8.3.0/gcc/ipa-devirt.c:2098   
0x8398a3 register_odr_type(tree_node*)  
../../gcc-8.3.0/gcc/ipa-devirt.c:2123   
0x626a86 lto_read_decls   
../../gcc-8.3.0/gcc/lto/lto.c:1887  
0x627788 lto_file_finalize
../../gcc-8.3.0/gcc/lto/lto.c:2121  
0x627788 lto_create_files_from_ids  
../../gcc-8.3.0/gcc/lto/lto.c:2131  
0x627788 lto_file_read
../../gcc-8.3.0/gcc/lto/lto.c:2172  
0x627788 read_cgraph_and_symbols
../../gcc-8.3.0/gcc/lto/lto.c:2845  
0x627788 lto_main()   
../../gcc-8.3.0/gcc/lto/lto.c:3362  

=== build info

Broken in 8.3:

Using built-in specs.
COLLECT_GCC=XXX/gcc-8.3.0/install/bin/g++
COLLECT_LTO_WRAPPER=XXX/gcc-8.3.0/install/libexec/gcc/x86_64-pc-linux-gnu/8.3.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-8.3.0/configure
--prefix=/nfs/orto/proj/tapeout/cit_dev10/mkgumbel/gcc-8.3.0/install
--enable-compressed-debug-sections=all
Thread model: posix
gcc version 8.3.0 (GCC) 

Works in 9-20190310:

Using built-in specs.
COLLECT_GCC=XXX/gcc-9/install/bin/g++
COLLECT_LTO_WRAPPER=XXX/gcc-9/install/libexec/gcc/x86_64-pc-linux-gnu/9.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-9-20190310/configure
--prefix=/nfs/orto/proj/tapeout/cit_dev10/mkgumbel/gcc-9/install
--enable-compressed-debug-sections=all --enable-gold --disable-werror
--disable-bootstrap
Thread model: posix
gcc version 9.0.1 20190310 (experimental) (GCC)

[Bug rtl-optimization/84842] [7/8/9 Regression] ICE in verify_target_availability, at sel-sched.c:1569

2019-03-18 Thread abel at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84842

Andrey Belevantsev  changed:

   What|Removed |Added

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

--- Comment #17 from Andrey Belevantsev  ---
Created attachment 45991
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45991=edit
tentative patch

This is a rather complex situation.  The assert checks that we have correctly
calculated the availability bit, which tells us that the original destination
insn register is free to use for the code motion.  In our case we have merged
several insns into one expression, and the resulting bit came from the variant
when it was really unavailable; however, during looking for the original insn
in the flow graph, we have been looking for really another variant, thus we
didn't get to the place with the first variant and initially unavailable stuff.

It can be fixed with the rather crude attached patch that somewhat relaxes the
assert.  While doing this, we need to mark the above situation has actually
occurred, but we don't know which of the move_op or find_best_regs we're doing
there -- Alexander, maybe you could come up with something better.

[Bug c++/89741] [9 Regression] static_assert fires when template not instantiated

2019-03-18 Thread tadeus.prastowo at unitn dot it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89741

--- Comment #10 from Tadeus Prastowo  ---
Okay, I see it now.  Thank you very much, Jakub, for your clear explanation.

[Bug c++/89744] [8/9 Regression] ICE with specialization of nested template class

2019-03-18 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89744

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
The last testcase still works in r208012 and ICEs with r208025, guess either it
must be r208024 or r208025.

[Bug c++/89761] [9 Regression] ICE: tree check: expected class 'expression', have 'exceptional' (argument_pack_select)

2019-03-18 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89761

Jason Merrill  changed:

   What|Removed |Added

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

[Bug fortran/37577] [meta-bug] change internal array descriptor format for better syntax, C interop TR, rank 15

2019-03-18 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37577

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #9 from Eric Gallager  ---
I think the "Depends on" and "Blocks" for this bug might be mixed up...
normally meta-bugs depend on more bugs than they block

[Bug c++/89744] [8/9 Regression] ICE with specialization of nested template class

2019-03-18 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89744

--- Comment #2 from Jakub Jelinek  ---
The second testcase still works with r8 and ICEs with r9, don't have
anything in between and these old compilers are getting hard to build.

[Bug c++/89640] [9 Regression] g++ chokes on lambda with __attribute__

2019-03-18 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89640

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/89744] [8/9 Regression] ICE with specialization of nested template class

2019-03-18 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89744

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-18
 CC||jakub at gcc dot gnu.org,
   ||nathan at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
The first testcase regressed with r250413.

[Bug c++/89741] [9 Regression] static_assert fires when template not instantiated

2019-03-18 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89741

--- Comment #9 from Jakub Jelinek  ---
That is the C++11 wording, e.g. the C++17 wording is:
"a hypothetical instantiation of a template immediately following its
definition would be ill-formed due to a construct that does not depend on a
template parameter"
decltype(x) does not depend on the template parameter, just on its type which
is known, similarly if you just used sizeof(int)==200.
See also
https://gcc.gnu.org/gcc-7/porting_to.html#hypothetical-instantiation
https://gcc.gnu.org/gcc-8/porting_to.html#hypothetical-instantiation

[Bug c++/89761] [9 Regression] ICE: tree check: expected class 'expression', have 'exceptional' (argument_pack_select)

2019-03-18 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89761

Marek Polacek  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Target Milestone|--- |9.0
Summary|[9.0 Regression] ICE: tree  |[9 Regression] ICE: tree
   |check: expected class   |check: expected class
   |'expression', have  |'expression', have
   |'exceptional'   |'exceptional'
   |(argument_pack_select)  |(argument_pack_select)

--- Comment #2 from Marek Polacek  ---
Started with r257018.

[Bug c++/89761] [9.0 Regression] ICE: tree check: expected class 'expression', have 'exceptional' (argument_pack_select)

2019-03-18 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89761

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-18
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug c++/89682] [9 Regression] g++9 incorrectly disallows using private static method as default arg to ctor of template type

2019-03-18 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89682

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Mon Mar 18 15:58:24 2019
New Revision: 269766

URL: https://gcc.gnu.org/viewcvs?rev=269766=gcc=rev
Log:
PR c++/89682 - wrong access error in default argument.

Here we were pushing into the right access context, but we were called from
a deferred checking context, so didn't end up doing the checks until after
we left the access context.

* pt.c (tsubst_default_argument): Don't defer access checks.

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

[Bug c++/89682] [9 Regression] g++9 incorrectly disallows using private static method as default arg to ctor of template type

2019-03-18 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89682

Jason Merrill  changed:

   What|Removed |Added

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

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

[Bug regression/89733] [7/8/9 Regression] False positive -Wuninitialized in C++14+ mode

2019-03-18 Thread nok.raven at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89733

--- Comment #2 from Nikita Kniazev  ---
Created attachment 45990
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45990=edit
preprocessed repro

[Bug c++/89761] New: [9.0 Regression] ICE: tree check: expected class 'expression', have 'exceptional' (argument_pack_select)

2019-03-18 Thread leni536 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89761

Bug ID: 89761
   Summary: [9.0 Regression] ICE: tree check: expected class
'expression', have 'exceptional'
(argument_pack_select)
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: leni536 at gmail dot com
  Target Milestone: ---

The following code triggers an ICE in g++ 9.0.1:

template  struct seq {};
template  struct S {
template 
constexpr static void call(Args&&...) {}
};

template 
auto foo (seq, Args&& ...args) {
return (S::call(args), ...);
}

void bar() {
foo(seq<0,1,2>{}, 1,2,3);
}

I'm not sure about the validity of the code above.

Tested on godbolt.org with "-std=c++17" flag:

: In instantiation of 'auto foo(seq, Args&& ...) [with int
...Idx = {0, 1, 2}; Args = {int, int, int}]':
:13:28:   required from here
:9:20: internal compiler error: tree check: expected class
'expression', have 'exceptional' (argument_pack_select) in tree_operand_check,
at tree.h:3674
9 | return (S::call(args), ...);
  |^~~
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Version:
g++ (Compiler-Explorer-Build) 9.0.1 20190316 (experimental)

[Bug c++/89741] [9 Regression] static_assert fires when template not instantiated

2019-03-18 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89741

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #8 from Jakub Jelinek  ---
There are indeed no explicit specializations (nor partial specializations) but
IMHO the above mentioned sentence talks about all specializations, including
the implicit specializations.
Just read the two sentences before that, those say:
"Knowing which names are type names allows the syntax of every template
definition to be checked. No diagnostic shall be issued for a template
definition for which a valid specialization can be generated."
The example at the end of that paragraph also shows a couple of cases when
issues in a template may be diagnosed even when it is not instantiated and when
the diagnostics must be deferred until instantiation.

[Bug target/89736] New test pr87532-mc.c fails on compiler not defaulting to VSX

2019-03-18 Thread segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89736

--- Comment #2 from Segher Boessenkool  ---
I found this on a Power7 (maybe -m32, not sure).

Your patch is eerily like what I did to fix this in testing, but the comment
right below says it does not use -mvsx on purpose?

[Bug target/89752] [8/9 Regression] ICE in emit_move_insn, at expr.c:3723

2019-03-18 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89752

--- Comment #11 from Jakub Jelinek  ---
Actually can't bisect, as gcc 8 I have installed is no longer able to build
r215000 or revisions around it (some error on wide-int.h:
../../gcc/wide-int.h:372:10: error: too many template-parameter-lists
   struct binary_traits 
  ^~
etc.).

That said, if we want to fix the:
struct A { A (); ~A (); short c; };

void
foo ()
{
  A a0, a1;
  __asm volatile ("" : "+rm" (a0), "+rm" (a1));
}
in the provided testcase, we could use:
--- gcc/gimplify.c.jj   2019-03-07 20:45:39.168938360 +0100
+++ gcc/gimplify.c  2019-03-18 16:18:16.515466234 +0100
@@ -6155,6 +6155,19 @@ gimplify_asm_expr (tree *expr_p, gimple_
  is_inout = false;
}

+  /* If we can't make copies, we can only accept memory.  */
+  if (TREE_ADDRESSABLE (TREE_TYPE (TREE_VALUE (link
+   {
+ if (allows_mem)
+   allows_reg = 0;
+ else
+   {
+ error ("impossible constraint in %");
+ error ("non-memory output %d must stay in memory", i);
+ return GS_ERROR;
+   }
+   }
+
   if (!allows_reg && allows_mem)
mark_addressable (TREE_VALUE (link));

which is something we already do for the input args, just for some strange
reason not for output args as well (if we wanted to backport it, I'd leave the
error part out).

That said, because users can write even that:
struct A { A (); ~A (); short c; };

void
foo ()
{
  A a0, a1;
  __asm volatile ("" : "=rm" (a0), "=rm" (a1) : "0" (a0), "1" (a1));
}
we need something in LRA too, that will simply treat BLKmode matching
constraints when both registers and memory are allowed as if only memory was
allowed.

[Bug libstdc++/89759] pop_back on empty vector gives wrong size

2019-03-18 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89759

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
It is undefined. Compiling with -D_GLIBCXX_DEBUG will diagnose it.

[Bug c++/89741] [9 Regression] static_assert fires when template not instantiated

2019-03-18 Thread tadeus.prastowo at unitn dot it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89741

Tadeus Prastowo  changed:

   What|Removed |Added

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

--- Comment #7 from Tadeus Prastowo  ---
The code in question, which is simplified below to match the real use-case,
does not involve template specialization, and so, the quoted passage does not
apply:
-- 8< ---
template
struct X {
  static_assert(sizeof(decltype(x)) == 200, "1");
};
-- 8< ---

The said code compiles fine with other GCC and Clang versions mentioned in the
initial report.

The code above has the merit of not requiring the specification of a
redundant/dummy template argument just to fire the static assertion.

[Bug libstdc++/89758] queue and priority queue show invalid size when empty container is poped. Further pushes lead to inconsistent values/ queue state

2019-03-18 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89758

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Your code has undefined behaviour, it's your responsibility to ensure you don't
try to pop from an empty queue.

Compiling with -D_GLIBCXX_DEBUG will show the problem:

queue
/usr/include/c++/8/bits/stl_queue.h:286: void std::queue<_Tp, _Sequence>::pop()
[with _Tp = int; _Sequence = std::__debug::deque >]:
Assertion '__builtin_expect(!this->empty(), true)' failed.
Aborted (core dumped)

[Bug libfortran/79540] [7/8/9 Regression] FAIL: gfortran.dg/fmt_fw_d.f90 -O0 execution test

2019-03-18 Thread danglin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79540

--- Comment #19 from John David Anglin  ---
The patch also fixes test failure on hppa2.0w-hp-hpux11.11.

[Bug c++/89682] [9 Regression] g++9 incorrectly disallows using private static method as default arg to ctor of template type

2019-03-18 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89682

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/89741] [9 Regression] static_assert fires when template not instantiated

2019-03-18 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89741

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #6 from Jason Merrill  ---
(In reply to Jakub Jelinek from comment #5)
> This needs to be verified by our C++ language lawyers, but if:
> "If no valid specialization can be generated for a template definition, and
> that template is not instantiated, the template definition is ill-formed, no
> diagnostic required."
> rule applies in this case, then what you are trying to do is not valid C++

Right.  G++ is giving a correct, though optional, diagnostic; if you want to
delay this diagnostic until instantiation, you need to make the expression
somehow dependent on template arguments.

[Bug target/89752] [8/9 Regression] ICE in emit_move_insn, at expr.c:3723

2019-03-18 Thread wilco at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89752

--- Comment #10 from Wilco  ---
It seems that rewriting "+rm" into "=rm" and "0" is not equivalent. Eg.

__asm__  ("" : [a0] "=m" (A0) : "0" (A0));

gives a million warnings "matching constraint does not allow a register", so
"0" appears to imply a register operand. Reload seems to deal with "=rm" and
"rm" or "=rm" and "0m", but a single "0" prefers a register and that's why it
tries to insert an incorrect BLK move.

[Bug libfortran/79540] [7/8/9 Regression] FAIL: gfortran.dg/fmt_fw_d.f90 -O0 execution test

2019-03-18 Thread danglin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79540

--- Comment #18 from John David Anglin  ---
Created attachment 45989
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45989=edit
Patch

This fixes the stack overflow in memcpy.

[Bug libfortran/89747] valgrind error in gfc_match_decl_type_spec

2019-03-18 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89747

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
   Target Milestone|--- |9.0

--- Comment #4 from Martin Liška  ---
I'm trying to reproduce that..

[Bug c++/89741] [9 Regression] static_assert fires when template not instantiated

2019-03-18 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89741

--- Comment #5 from Jakub Jelinek  ---
This needs to be verified by our C++ language lawyers, but if:
"If no valid specialization can be generated for a template definition, and
that template is not instantiated, the template definition is ill-formed, no
diagnostic required."
rule applies in this case, then what you are trying to do is not valid C++ and
you'll need to find some other way, e.g. one where there are instantiations
that could be instantiated.  Say use
template
struct Y {
  static constexpr bool value = false;
};

template<>
struct Y {
  static constexpr bool value = true;
};

template<>
struct Y {
  static constexpr bool value = true;
};

template
struct X {
  static_assert(Y::value, "1");
};
or something similar where all instantiations aren't invalid.

[Bug libstdc++/89760] [9 Regression] libstdc++ experimental testsuite failures

2019-03-18 Thread dje at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89760

David Edelsohn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-18
 Ever confirmed|0   |1

--- Comment #1 from David Edelsohn  ---
Confirmed.

[Bug libstdc++/89760] New: [9 Regression] libstdc++ experimental testsuite failures

2019-03-18 Thread dje at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89760

Bug ID: 89760
   Summary: [9 Regression] libstdc++ experimental testsuite
failures
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org
CC: redi at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc-ibm-aix*

Twelve new failures in experimental code, all like:

FAIL: experimental/net/execution_context/use_service.cc (test for excess
errors)
Excess errors:
/tmp/GCC/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/experimental/executor:507:
error: 'mutex' in namespace 'std' does not name a type
/tmp/GCC/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/experimental/executor:554:
error: 'mutex' is not a member of 'std'
/tmp/GCC/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/experimental/executor:554:
error: 'mutex' is not a member of 'std'
/tmp/GCC/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/experimental/executor:554:
error: template argument 1 is invalid
/tmp/GCC/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/experimental/executor:554:
error: 'class std::experimental::net::v1::execution_context' has no member
named '_M_mutex'
/tmp/GCC/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/experimental/executor:578:
error: 'mutex' is not a member of 'std'
/tmp/GCC/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/experimental/executor:578:
error: 'mutex' is not a member of 'std'
/tmp/GCC/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/experimental/executor:578:
error: template argument 1 is invalid
/tmp/GCC/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/experimental/executor:578:
error: 'class std::experimental::net::v1::execution_context' has no member
named '_M_mutex'
/tmp/GCC/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/experimental/executor:600:
error: 'mutex' is not a member of 'std'
/tmp/GCC/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/experimental/executor:600:
error: 'mutex' is not a member of 'std'
/tmp/GCC/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/experimental/executor:600:
error: template argument 1 is invalid
/tmp/GCC/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/experimental/executor:600:
error: 'const class std::experimental::net::v1::execution_context' has no
member named '_M_mutex'
/tmp/GCC/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/experimental/executor:888:
error: 'thread' does not name a type; did you mean 'fread'?
/tmp/GCC/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/experimental/executor:889:
error: 'mutex' does not name a type
/tmp/GCC/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/experimental/executor:890:
error: 'condition_variable' does not name a type
/tmp/GCC/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/experimental/executor:866:
error: 'mutex' was not declared in this scope
/tmp/GCC/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/experimental/executor:866:
error: template argument 1 is invalid
/tmp/GCC/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/experimental/executor:866:
error: '_M_mtx' was not declared in this scope
/tmp/GCC/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/experimental/executor:868:
error: '_M_cv' was not declared in this scope
/tmp/GCC/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/experimental/executor:873:
error: 'mutex' was not declared in this scope
/tmp/GCC/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/experimental/executor:873:
error: template argument 1 is invalid
/tmp/GCC/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/experimental/executor:873:
error: '_M_mtx' was not declared in this scope
/tmp/GCC/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/experimental/executor:879:
error: '_M_thread' was not declared in this scope; did you mean '__n_pthreads'?
/tmp/GCC/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/experimental/executor:901:
error: 'mutex' was not declared in this scope
/tmp/GCC/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/experimental/executor:901:
error: template argument 1 is invalid
/tmp/GCC/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/experimental/executor:901:
error: '_M_mtx' was not declared in this scope
/tmp/GCC/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/experimental/executor:902:
error: '_M_cv' was not declared in this scope
/tmp/GCC/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/experimental/executor:916:
error: 'mutex' was not declared in this scope
/tmp/GCC/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/experimental/executor:916:
error: template argument 1 is invalid
/tmp/GCC/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/experimental/executor:916:
error: '_M_mtx' was not declared in this scope
/tmp/GCC/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/experimental/executor:919:
error: '_M_thread' was not declared in this scope; did you mean '__n_pthreads'?
/tmp/GCC/powerpc-ibm-aix7.2.0.0/libstdc++-v3/include/experimental/executor:920:
error: 'thread' is not a 

[Bug c++/89741] [9 Regression] static_assert fires when template not instantiated

2019-03-18 Thread tadeus.prastowo at unitn dot it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89741

--- Comment #4 from Tadeus Prastowo  ---
My use-case is to use the instantiation of `struct X' to fire the static
assert.

[Bug libfortran/79540] [7/8/9 Regression] FAIL: gfortran.dg/fmt_fw_d.f90 -O0 execution test

2019-03-18 Thread danglin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79540

--- Comment #17 from John David Anglin  ---
   0x7adcb864 :cmpclr,> r21,r3,r0
   0x7adcb868 :copy r21,r3
   0x7adcb86c :stw r20,-8c(sp)
   0x7adcb870 :stw r21,-90(sp)
   0x7adcb874 :copy r19,r4
   0x7adcb878 :copy r5,r25
   0x7adcb87c :b,l 0x7adab298 ,rp
   0x7adcb880 :copy r3,r24
=> 0x7adcb884 :add,l r6,r3,ret0

(gdb) p/x $r21
$12 = 0x1
(gdb) p nafter
$13 = 1
(gdb) p ndigits
No symbol "ndigits" in current context.
(gdb) p/x $r3
$14 = 0xfffd

The cmpclr does a signed compare between $r21 and $r3.  The following
instruction is nullified because $r21 > $r3.  Presumably, $r3 is supposed to
contain ndigits.

  /* Set digits after the decimal point, padding with zeros.  */
  if (nafter > 0)
{
  if (nafter > ndigits)
i = ndigits;
  else
i = nafter;

  memcpy (put, digits, i);
  while (i < nafter)
put[i++] = '0';

  digits += i;
  ndigits -= i;
  put += nafter;
}

[Bug libstdc++/52114] SFINAE out the rvalue iostream operators to give better error messages

2019-03-18 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52114

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #14 from Jonathan Wakely  ---
Indeed, this was fixed for 5.1 (and now gives 200+ lines of diagnostic output
instead of 9 - yay!)

[Bug libstdc++/89759] pop_back on empty vector gives wrong size

2019-03-18 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89759

--- Comment #1 from Richard Biener  ---
It's probably undefined to pop_back () on an empty vector.

[Bug rtl-optimization/84206] ICE in get_all_loop_exits, at sel-sched-ir.h:1138

2019-03-18 Thread abel at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84206

Andrey Belevantsev  changed:

   What|Removed |Added

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

--- Comment #1 from Andrey Belevantsev  ---
The code that fails here tries to skip the inner loop's body to get to the next
blocks in the outer loop.  The failing assert is designed to check that, if
we've skipped an inner loop, and we have hit an empty block, then this block
could only be the preheader of the next inner loop, whose body we should also
skip.  In the testcase the block is definitely a preheader, but not for the
inner loop; it starts the very outer loop we're working with in the first
place.

Fixed by adding code to check that we're not going in the outer direction of
the loop hierarchy via checking depths like below.

diff --git a/gcc/sel-sched-ir.h b/gcc/sel-sched-ir.h
index b5ec63cf94d..3943eee3468 100644
--- a/gcc/sel-sched-ir.h
+++ b/gcc/sel-sched-ir.h
@@ -1144,6 +1144,7 @@ get_all_loop_exits (basic_block bb)
   struct loop *this_loop;
   struct loop *pred_loop = NULL;
   int i;
+  unsigned this_depth;
   edge e;

   for (this_loop = bb->loop_father;
@@ -1155,11 +1156,14 @@ get_all_loop_exits (basic_block bb)
   gcc_assert (this_loop != NULL);

   exits = get_loop_exit_edges_unique_dests (this_loop);
+  this_depth = loop_depth (this_loop);

-  /* Traverse all loop headers.  */
+  /* Traverse all loop headers.  Be careful not to go back
+to the outer loop's header (see PR 84206).  */
   for (i = 0; exits.iterate (i, ); i++)
-   if (in_current_region_p (e->dest)
-   || inner_loop_header_p (e->dest))
+   if ((in_current_region_p (e->dest)
+|| (inner_loop_header_p (e->dest)))
+   && loop_depth (e->dest->loop_father) >= this_depth)
  {
vec next_exits = get_all_loop_exits (e->dest);

[Bug target/89752] [8/9 Regression] ICE in emit_move_insn, at expr.c:3723

2019-03-18 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89752

--- Comment #9 from Jakub Jelinek  ---
Bisecting now, r21 still works, r215000 ICEs.

[Bug target/89752] [8/9 Regression] ICE in emit_move_insn, at expr.c:3723

2019-03-18 Thread rguenther at suse dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89752

--- Comment #8 from rguenther at suse dot de  ---
On Mon, 18 Mar 2019, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89752
> 
> Jakub Jelinek  changed:
> 
>What|Removed |Added
> 
>  CC||jakub at gcc dot gnu.org
> 
> --- Comment #7 from Jakub Jelinek  ---
> I've reduced it to:
> struct A { A (); ~A (); short c; };
> 
> void
> foo ()
> {
>   A a0, a1;
>   __asm volatile ("" : "=rm" (a0), "=rm" (a1) : "0" (a0), "1" (a1));
> }
> which better matches what is going on (the type is TYPE_ADDRESSABLE and that 
> is
> why it has BLKmode).

And it works "fine" in x86_64 ...

[Bug libfortran/79540] [7/8/9 Regression] FAIL: gfortran.dg/fmt_fw_d.f90 -O0 execution test

2019-03-18 Thread danglin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79540

--- Comment #16 from John David Anglin  ---
print '(f2.1)',100.00
end

Here is backtrace info:

Breakpoint 2, 0x7afce720 in memcpy () from /usr/lib/libc.2
(gdb) p/x $r26
$6 = 0x7eff0c1d
(gdb) p/x $r25
$8 = 0x7eff0d9a
(gdb) p/x $r24
$5 = 0xfffd

$r24 contains number of bytes to copy.

(gdb) bt
Python Exception  Failed to load
/home/gnu/lib/python2.7/lib-dynload/itertools.sl:
#0  0x7afce720 in memcpy () from /usr/lib/libc.2
#1  0x7adcb884 in build_float_string (dtp=0x7eff0658, f=0x0,
buffer=0x7eff0d98 '+100.\000', size=1, nprinted=0, precision=1,
sign_bit=0, zero_flag=0, npad=0,
result=0x7eff0c18 '.\377\006\364\000', len=0x7eff0f18)
at ../../../gcc/libgfortran/io/write_float.def:630
#2  0x7adcc00c in get_float_string (dtp=0xfffd, f=0x7eff0658,
source=0xfffd ,
kind=2130644378, comp_d=0, buffer=0x7eff0d98 '+100.\000', precision=1,
size=6, result=0x7eff0c18 '.\377\006\364\000', res_len=0x7eff0f18)
at ../../../gcc/libgfortran/io/write_float.def:1065
#3  0x7adcd4dc in write_float_0 (dtp=0xfffd, f=0x7eff0c1d,
source=0x7eff0c1c '.\377\006\364\000', kind=2130644378)
at ../../../gcc/libgfortran/io/write.c:1584
#4  0x7adc1420 in formatted_transfer_scalar_write (dtp=0xfffd,
type=2130643997, p=0x7eff0658, kind=28, size=4)
at ../../../gcc/libgfortran/io/transfer.c:2097
#5  0x7adc1984 in formatted_transfer (dtp=0x7eff0658, type=BT_UNKNOWN,
p=0xfffd, kind=2130643996, size=4, nelems=1)
at ../../../gcc/libgfortran/io/transfer.c:2335
#6  0x7adbd0a4 in wrap_scalar_transfer.constprop.0 (dtp=0x7eff0c1d,
type=2130644378, p=0xfffd, kind=1074790400, size=4)
at ../../../gcc/libgfortran/io/transfer.c:2369
#7  0x7adbd6c8 in *_gfortran_transfer_real (dtp=0xfffd, p=0x7eff0c1d,
kind=2130644378) at ../../../gcc/libgfortran/io/transfer.c:2396
#8  0x7adbd728 in *_gfortran_transfer_real_write (dtp=0x7eff0c1d,
p=0x7eff0d9a, kind=-3) at ../../../gcc/libgfortran/io/transfer.c:2402

write_float.def may be miscompiled.

[Bug target/89752] [8/9 Regression] ICE in emit_move_insn, at expr.c:3723

2019-03-18 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89752

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
I've reduced it to:
struct A { A (); ~A (); short c; };

void
foo ()
{
  A a0, a1;
  __asm volatile ("" : "=rm" (a0), "=rm" (a1) : "0" (a0), "1" (a1));
}
which better matches what is going on (the type is TYPE_ADDRESSABLE and that is
why it has BLKmode).

[Bug tree-optimization/88945] ICE in fold_convert_loc in FRE when using -fdump-tree-fre-details

2019-03-18 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88945

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||9.0
 Resolution|--- |FIXED
  Known to fail|9.0 |

--- Comment #5 from Richard Biener  ---
Fixed on trunk, not worth backporting.

[Bug tree-optimization/88945] ICE in fold_convert_loc in FRE when using -fdump-tree-fre-details

2019-03-18 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88945

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Mon Mar 18 13:59:11 2019
New Revision: 269765

URL: https://gcc.gnu.org/viewcvs?rev=269765=gcc=rev
Log:
2019-03-18  Richard Biener  

PR middle-end/88945
* tree-ssanames.c (release_ssa_name_fn): For released SSA names
use a TREE_TYPE of error_mark_node to avoid ICEs when dumping
basic-blocks that are removed.  Remove restoring SSA_NAME_VAR.
* tree-outof-ssa.c (eliminate_useless_phis): Remove redundant checking.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-outof-ssa.c
trunk/gcc/tree-ssanames.c

[Bug target/89752] [8/9 Regression] ICE in emit_move_insn, at expr.c:3723

2019-03-18 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89752

--- Comment #6 from Jakub Jelinek  ---
It is on:
__asm__("" : "a0" "=rm" A0, "a1" "=rm" A1 : "0" A0, "1" A1);
where A0 and A1 are variables with LhsPacket type, which is 2 byte
TYPE_ADDRESSABLE aggregate type.
The r in the constraints looks completely bogus to me for addressable vars that
must live in memory, but guess we shouldn't ICE even on this invalid stuff.

[Bug target/89736] New test pr87532-mc.c fails on compiler not defaulting to VSX

2019-03-18 Thread kelvin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89736

--- Comment #1 from kelvin at gcc dot gnu.org ---

Hi Segher,


I agree with your analysis.  I'm not sure we have easy access to a platform
where I can demonstrate/reproduce the problem.  Do you know where I can test
this?

I believe the proper fix is the following, which is not yet tested.  Comments?

Index: gcc/testsuite/gcc.target/powerpc/pr87532-mc.c
===
--- gcc/testsuite/gcc.target/powerpc/pr87532-mc.c   (revision 269764)
+++ gcc/testsuite/gcc.target/powerpc/pr87532-mc.c   (working copy)
@@ -1,8 +1,8 @@
 /* { dg-do run { target int128 } } */
-/* { dg-require-effective-target vmx_hw } */
-/* { dg-options "-maltivec -O2" } */
+/* { dg-require-effective-target vsx_hw } */
+/* { dg-options "-mvsx -O2" } */

-/* This test should run the same on any target that supports altivec/dfp
+/* This test should run the same on any target that supports vsx
instructions.  Intentionally not specifying cpu in order to test
all code generation paths.  */

[Bug target/89752] [8/9 Regression] ICE in emit_move_insn, at expr.c:3723

2019-03-18 Thread rguenther at suse dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89752

--- Comment #5 from rguenther at suse dot de  ---
On Mon, 18 Mar 2019, wilco at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89752
> 
> --- Comment #4 from Wilco  ---
> Small example which generates the same ICE on every GCC version:
> 
> typedef struct { int x, y, z; } X;
> 
> void f(void)
> {
>   X A0, A1;
>   __asm__ ("" : [a0] "+rm" (A0),[a1] "+rm" (A1));
> }
> 
> So it's completely invalid inline asm...

Looks like an attempt to provide some barrier?

We still shouldn't ICE.

[Bug sanitizer/82501] AddressSanitizer does not handle negative offset for first global variable

2019-03-18 Thread a.drobyshev at samsung dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82501

--- Comment #26 from Andrey Drobyshev  ---
(In reply to Jakub Jelinek from comment #24)
> (In reply to Martin Liška from comment #23)
> > (In reply to Andrey Drobyshev from comment #22)
> > > Created attachment 45851 [details]
> > > Work-in-progress fix considering relocations
> > > 
> > > I'm a bit stuck. I managed to precompute reloc value for the globals (the
> > > code for detect_reloc_for_node() is stealed from get_variable_section 
> > > ()). I
> > > also succeded in putting dummy variable into .data.rel.ro by making a decl
> > > of a pointer type.
> > 
> > Nice progress!
> > 
> > > But .data.rel is not working: checks from varasm.c:1173
> > > and varasm.c:1197 are somewhat conflicting. Maybe you could find a way to
> > > overcome this?
> > 
> > Can you please paste content of the lines, the lines you mentioned point to
> > a '}' for me.
> 
> I would like to ask, has the idea of adding an artificial object linked with
> -fsanitize=address early on the link line which would register artificial
> dummy variables in at least the most common data sections been considered
> and rejected?
> I mean, it should at least for large libraries mean significantly fewer
> dummy variables, on the other side, when mixing sanitized and non-sanitized
> objects within one binary/library (having sanitized ones first and then say
> linking a static library non-sanitized would be fine) would mean catching up
> fewer issues.

Could you describe how you imagine this solution in more details? Wouldn't it
require us to patch the linker along with compiler?

[Bug sanitizer/82501] AddressSanitizer does not handle negative offset for first global variable

2019-03-18 Thread a.drobyshev at samsung dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82501

--- Comment #25 from Andrey Drobyshev  ---
(In reply to Martin Liška from comment #23)
> (In reply to Andrey Drobyshev from comment #22)
> > Created attachment 45851 [details]
> > Work-in-progress fix considering relocations
> > 
> > I'm a bit stuck. I managed to precompute reloc value for the globals (the
> > code for detect_reloc_for_node() is stealed from get_variable_section ()). I
> > also succeded in putting dummy variable into .data.rel.ro by making a decl
> > of a pointer type.
> 
> Nice progress!
> 
> > But .data.rel is not working: checks from varasm.c:1173
> > and varasm.c:1197 are somewhat conflicting. Maybe you could find a way to
> > overcome this?
> 
> Can you please paste content of the lines, the lines you mentioned point to
> a '}' for me.

Sorry for the delay, was out of the office for a couple of weeks...
What I actually meant was the following: setting DECL_INITIAL to
error_mark_node and making the decl of pointer type for computing the right
reloc here:

if (DECL_INITIAL (decl) == error_mark_node) 
reloc = contains_pointers_p (TREE_TYPE (decl)) ? 3 : 0; 
else if (DECL_INITIAL (decl))   
reloc = compute_reloc_for_constant (DECL_INITIAL (decl));   
else
reloc = 0;

along with making the decl non read only (as we want to put it in the data.rel)
causes it to be put in .bss here (in particular, because bss_initializer_p
(decl) becomes true):
if (ADDR_SPACE_GENERIC_P (as)   
&& !DECL_THREAD_LOCAL_P (decl)  
&& !(prefer_noswitch_p && targetm.have_switchable_bss_sections) 
&& bss_initializer_p (decl))
{   
if (!TREE_PUBLIC (decl) 
&& !((flag_sanitize & SANITIZE_ADDRESS) 
&& asan_protect_global (decl))) 
return lcomm_section;   
if (bss_noswitch_section)   
return bss_noswitch_section;
}

[Bug libstdc++/89759] New: pop_back on empty vector gives wrong size

2019-03-18 Thread anshulaggarwal987654321 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89759

Bug ID: 89759
   Summary: pop_back on empty vector gives wrong size
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anshulaggarwal987654321 at gmail dot com
  Target Milestone: ---

after calling pop_back on an empty vector, the vector.size() doesnt display
zero and displays a large value UINT64_MAX.

this leads to inconsistency and breaking of the data structure. (bug)


unconfirmed : it might try to deallocate unowned memory

[Bug libstdc++/89758] queue and priority queue show invalid size when empty container is poped. Further pushes lead to inconsistent values/ queue state

2019-03-18 Thread anshulaggarwal987654321 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89758

--- Comment #1 from anshul aggarwal  
---
uncomfirmed : the dataStructure might try to "free" unowned memory

[Bug tree-optimization/89754] Vectorizer cost model check should look at evolution of niter in outer loop(s)

2019-03-18 Thread rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89754

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-18
 CC||rsandifo at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug libstdc++/89758] New: queue and priority queue show invalid size when empty container is poped. Further pushes lead to inconsistent values

2019-03-18 Thread anshulaggarwal987654321 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89758

Bug ID: 89758
   Summary: queue and priority queue show invalid size when empty
container is poped. Further pushes lead to
inconsistent values
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anshulaggarwal987654321 at gmail dot com
  Target Milestone: ---

Created attachment 45988
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45988=edit
this code does the operations and prints the inconsistencies

After poping an empty queue or a dequeue , when we check the size it outputs
UINT64_MAX -1 = "18446744073709551615" (bug1)

incase of queue, pushing leads to inconsistent results (bug2)

incase of priority queue, pushing gives out an error ( not a bug)

[Bug target/89752] [8/9 Regression] ICE in emit_move_insn, at expr.c:3723

2019-03-18 Thread wilco at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89752

--- Comment #4 from Wilco  ---
Small example which generates the same ICE on every GCC version:

typedef struct { int x, y, z; } X;

void f(void)
{
  X A0, A1;
  __asm__ ("" : [a0] "+rm" (A0),[a1] "+rm" (A1));
}

So it's completely invalid inline asm...

[Bug c++/89757] New: accepts returning with reference to temporary in constant expression

2019-03-18 Thread leni536 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89757

Bug ID: 89757
   Summary: accepts returning with reference to temporary in
constant expression
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: leni536 at gmail dot com
  Target Milestone: ---

g++ accepts this ill-formed code:

constexpr const int& foo(int x, int y) {
const int& z = x+y;
return z;
}

constexpr int&& bar(int x, int y) {
int&& z = x+y;
return static_cast(z);
}

int main() {
constexpr int a = foo(1,2);
constexpr int b = bar(1,2);
return a+b;
}

This is invalid because both foo and bar return with a reference to a local
temporary object and expressions containing UB when evaluated are not constant
expressions.

$ g++ -std=c++14 -Wall -Wextra -pedantic -o gcc_bug gcc_bug.cpp && ./gcc_bug;
echo $?
6

Note: I tested it on 8.3.0 on my own machine, but it seems to be the same for
all versions on godbolt.

[Bug d/89756] New: FAIL: gdc.dg/asm4.d -O0 (internal compiler error)

2019-03-18 Thread danglin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89756

Bug ID: 89756
   Summary: FAIL: gdc.dg/asm4.d   -O0  (internal compiler error)
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa2.0w-hp-hpux11.11
Target: hppa2.0w-hp-hpux11.11
 Build: hppa2.0w-hp-hpux11.11

spawn /test/gnu/gcc/objdir/gcc/testsuite/gdc/../../gdc
-B/test/gnu/gcc/objdir/gc
c/testsuite/gdc/../../ /test/gnu/gcc/gcc/gcc/testsuite/gdc.dg/asm4.d
-fno-diagno
stics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never
-I
/test/gnu/gcc/gcc/gcc/testsuite/../../libphobos/libdruntime
-I/test/gnu/gcc/gcc/
gcc/testsuite/../../libphobos/src
-I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/l
ibstdc++-v3/include/hppa2.0w-hp-hpux11.11
-I/test/gnu/gcc/objdir/hppa2.0w-hp-hpu
x11.11/libstdc++-v3/include -I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++
-I/test/g
nu/gcc/gcc/libstdc++-v3/include/backward
-I/test/gnu/gcc/gcc/libstdc++-v3/testsu
ite/util -O0 -Wall -Wdeprecated -Werror -S -o asm4.s
:1: internal compiler error: in register_moduleinfo, at
d/modules.cc:40
2
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
compiler exited with status 1
output is:
:1: internal compiler error: in register_moduleinfo, at
d/modules.cc:40
2
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

FAIL: gdc.dg/asm4.d   -O0  (internal compiler error)
FAIL: gdc.dg/asm4.d   -O0  (test for excess errors)
Excess errors:
:1: internal compiler error: in register_moduleinfo, at
d/modules.cc:402

modules.cc:402 is:
gcc_assert (targetm_common.have_named_sections);

Target doesn't support named sections although special sections can be created.

[Bug target/89746] powerpc-none-eabi-gcc emits code using stfiwx to misaligned address

2019-03-18 Thread segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89746

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #6 from Segher Boessenkool  ---
Created attachment 45987
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45987=edit
PoC

[Bug target/89746] powerpc-none-eabi-gcc emits code using stfiwx to misaligned address

2019-03-18 Thread segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89746

--- Comment #5 from Segher Boessenkool  ---
Yes, it is just a code quality issue.

I have the attached patch, and it works; it needs to be updated so that the
alignment check is only done for CPUs where it is needed.

[Bug target/89752] [8/9 Regression] ICE in emit_move_insn, at expr.c:3723

2019-03-18 Thread wilco at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89752

--- Comment #3 from Wilco  ---
Full instruction:

(insn 531 530 532 19 (parallel [
(set (mem/c:BLK (reg:DI 3842) [29 A0+0 S2 A64])
(asm_operands:BLK ("") ("=rm") 0 [
(mem/c:BLK (reg:DI 3846) [29 A0+0 S2 A64])
(mem/c:BLK (reg:DI 3848) [29 A1+0 S2 A128])
]
 [
(asm_input:BLK ("0")
external/eigen_archive/unsupported/Eigen/CXX11/../../../Eigen/src/Core/products/GeneralBlockPanelKernel.h:1418)
(asm_input:BLK ("1")
external/eigen_archive/unsupported/Eigen/CXX11/../../../Eigen/src/Core/products/GeneralBlockPanelKernel.h:1418)
]
 []
external/eigen_archive/unsupported/Eigen/CXX11/../../../Eigen/src/Core/products/GeneralBlockPanelKernel.h:1418))
(set (mem/c:BLK (reg:DI 3844) [29 A1+0 S2 A128])
(asm_operands:BLK ("") ("=rm") 1 [
(mem/c:BLK (reg:DI 3846) [29 A0+0 S2 A64])
(mem/c:BLK (reg:DI 3848) [29 A1+0 S2 A128])
]
 [
(asm_input:BLK ("0")
external/eigen_archive/unsupported/Eigen/CXX11/../../../Eigen/src/Core/products/GeneralBlockPanelKernel.h:1418)
(asm_input:BLK ("1")
external/eigen_archive/unsupported/Eigen/CXX11/../../../Eigen/src/Core/products/GeneralBlockPanelKernel.h:1418)
]
 []
external/eigen_archive/unsupported/Eigen/CXX11/../../../Eigen/src/Core/products/GeneralBlockPanelKernel.h:1418))
])
"external/eigen_archive/unsupported/Eigen/CXX11/../../../Eigen/src/Core/products/GeneralBlockPanelKernel.h":1418:511
-1
 (nil))


I guess this comes from the source like this with some of the arguments being
immediates due to template substitution:

__asm__ ("" : [a0] "+rm" (A0),[a1] "+rm" (A1));

It's not obvious what this is supposed to achieve, let alone whether it is
valid...

[Bug c/89734] [7/8/9 Regression] const qualifier on return type not erased inside __typeof__

2019-03-18 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89734

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-03-18
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Jakub Jelinek  ---
Created attachment 45986
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45986=edit
gcc9-pr89734.patch

Untested fix.

[Bug target/89752] [8/9 Regression] ICE in emit_move_insn, at expr.c:3723

2019-03-18 Thread wilco at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89752

Wilco  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-18
 CC||wilco at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Wilco  ---
Confirmed. It ICEs in Eigen::internal::gebp_kernel, 2, 4,
false, false>::operator()

It seems to choke on this asm during reload:

  531: {[r3842:DI]=asm_operands;[r3844:DI]=asm_operands;}

and somehow emit a move between these operands:

(reg:BLK 3849) (mem/c:BLK (reg:DI 3846) [29 A0+0 S2 A64])

[Bug tree-optimization/89546] [8/9 Regression] Suspected arm flint miscompilation starting with r255510

2019-03-18 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89546

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/89546] [8/9 Regression] Suspected arm flint miscompilation starting with r255510

2019-03-18 Thread jamborm at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89546

--- Comment #11 from Martin Jambor  ---
Author: jamborm
Date: Mon Mar 18 11:31:52 2019
New Revision: 269762

URL: https://gcc.gnu.org/viewcvs?rev=269762=gcc=rev
Log:
Add forgotten requeing in propagate_subaccesses_across_link

2019-03-18  Martin Jambor  

PR tree-optimization/89546
* tree-sra.c (propagate_subaccesses_across_link): Requeue new_acc if
any propagation to its children took place.

testsuite/
* gcc.dg/tree-ssa/pr89546.c: New test.


Added:
branches/gcc-8-branch/gcc/testsuite/gcc.dg/tree-ssa/pr89546.c
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/gcc/tree-sra.c

[Bug tree-optimization/89546] [8/9 Regression] Suspected arm flint miscompilation starting with r255510

2019-03-18 Thread jamborm at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89546

--- Comment #10 from Martin Jambor  ---
Author: jamborm
Date: Mon Mar 18 11:28:01 2019
New Revision: 269761

URL: https://gcc.gnu.org/viewcvs?rev=269761=gcc=rev
Log:
Add forgotten requeing in propagate_subaccesses_across_link

2019-03-18  Martin Jambor  

PR tree-optimization/89546
* tree-sra.c (propagate_subaccesses_across_link): Requeue new_acc if
any propagation to its children took place.

testsuite/
* gcc.dg/tree-ssa/pr89546.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr89546.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-sra.c

[Bug c++/89741] [9 Regression] static_assert fires when template not instantiated

2019-03-18 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89741

--- Comment #3 from Jakub Jelinek  ---
This might actually be invalid testcase with no diagnostics required though.
Certainly no instantiations of X can be accepted.

  1   2   >