[Bug libstdc++/53984] iostream operation throwing exception when exceptions not enabled

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
Eventually. I tried removing the throws and got a bunch of test failures:

FAIL: 27_io/basic_filebuf/overflow/char/9182-2.cc execution test
FAIL: 27_io/basic_filebuf/seekoff/wchar_t/3.cc execution test
FAIL: 27_io/basic_filebuf/seekpos/wchar_t/1.cc execution test
FAIL: 27_io/basic_filebuf/sync/char/9182-1.cc execution test
FAIL: 27_io/basic_filebuf/underflow/wchar_t/11544-1.cc execution test
FAIL: 27_io/basic_filebuf/underflow/wchar_t/11544-2.cc execution test
FAIL: 27_io/basic_filebuf/underflow/wchar_t/11603.cc execution test

[Bug target/80505] FAIL: gcc.dg/ipa/iinline-attr.c scan-ipa-dump inline "hooray[^\\n]*inline copy in test"

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Target|ppc64le-linux-gnu   |powerpc*-*-*
   Host|ppc64le-linux-gnu   |powerpc*-*-*
  Build|ppc64le-linux-gnu   |powerpc*-*-*

--- Comment #5 from Segher Boessenkool  ---
It is broken on any powerpc target (also BE, 32-bit, AIX, and Darwin).

[Bug c++/80559] New: Segmentation fault on invalid initialiser list template arguments

[matt at godbolt dot org]

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

Bug ID: 80559
   Summary: Segmentation fault on invalid initialiser list
template arguments
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: matt at godbolt dot org
  Target Milestone: ---

Build: GCC v8.0.0 (built from source 20170428)

The following code:


#include 

template 
struct Stack_t {};

template 
constexpr Stack_t(std::initializer_list l) -> Stack_t<T, l.size()>;


Yields the following errors, and ends with mmap() failing to allocate memory:

:7:69: error: template argument 2 is invalid
 constexpr Stack_t(std::initializer_list l) -> Stack_t<T, l.size()>;
 ^
:7:69: error: template argument 2 is invalid
:7:69: error: template argument 2 is invalid
:7:69: error: template argument 2 is invalid
:7:50: internal compiler error: Segmentation fault
 constexpr Stack_t(std::initializer_list l) -> Stack_t<T, l.size()>;
  ^~~
mmap: Cannot allocate memory

[Bug target/68491] libgcc calls __get_cpuid with 0 level breaks on early 486

[christos at zoulas dot com]

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

--- Comment #2 from Christos Zoulas  ---
Created attachment 41284
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41284=edit
Amended cpuid patch.

Here's an amended patch against the trunk. Also sent mail to gcc-patches@

[Bug libstdc++/80538] Probably unwanted thread yield for thread::sleep_for with < 1s

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to zulliger from comment #0)
> Which means that for values of __s.count() == 0, the current thread will
> always "yield" (according to my understanding, sleep(0) yields),

That's unspecified.

> just before
> the thread may actually fall asleep for some microseconds. Is this really
> the desired behaviour?

Any yield here is unspecified, so it's not _wrong_ but maybe suboptimal.

> Anyway, what's the desired effect of a thread::sleep_for(0.0)?

Calling this_thread::sleep_for(0s) returns immediately without ever reaching
__sleep_for. A positive value will cause the thread to sleep, which might
result in yielding one or more times.

>should the
> thread yield then? If not, then the code should look like this:
> 
> if (__s.count() > 0) ::sleep(__s.count());
> if (__ns.count() > 0)
>   {
> long __us = __ns.count() / 1000;
> if (__us == 0)
>   __us = 1;
> ::usleep(__us);
>   }
> 
> shouldn't it?

I don't think it matters. A bigger problem is that the argument to sleep has
type unsigned and we pass it a value that might not representable in that type.
We also don't check for short sleeps. We should call it in a loop and check the
return value. That would lead to multiple calls to sleep, and so in general the
number of times we call sleep (and the number of times the thread yields) is
unpredictable.

[Bug fortran/78640] [F2015] gfortran accepts invalid allocatable polymorphic result in pure function

[damian at sourceryinstitute dot org]

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

--- Comment #2 from Damian Rouson  ---
I think this bug just bit gfortran user and Fortran enthusiast Stefano Zhagi.
Is anyone interested in fixing it?

[Bug testsuite/80557] rewrite absolute line numbers into relative or saved line numbers

[vries at gcc dot gnu.org]

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

--- Comment #2 from Tom de Vries  ---
Author: vries
Date: Fri Apr 28 21:24:00 2017
New Revision: 247399

URL: https://gcc.gnu.org/viewcvs?rev=247399=gcc=rev
Log:
Replace absolute linenrs in objc.dg,obj-c++.dg

2017-04-28  Tom de Vries  

PR testsuite/80557
* obj-c++.dg/bitfield-1.mm: Replace absolute linenrs.
* obj-c++.dg/bitfield-4.mm: Same.
* obj-c++.dg/bitfield-5.mm: Same.
* obj-c++.dg/exceptions-3.mm: Same.
* obj-c++.dg/exceptions-5.mm: Same.
* obj-c++.dg/method-1.mm: Same.
* obj-c++.dg/method-12.mm: Same.
* obj-c++.dg/method-13.mm: Same.
* obj-c++.dg/method-15.mm: Same.
* obj-c++.dg/method-16.mm: Same.
* obj-c++.dg/property/at-property-18.mm: Same.
* obj-c++.dg/property/at-property-25.mm: Same.
* obj-c++.dg/property/at-property-5.mm: Same.
* obj-c++.dg/property/dynamic-2.mm: Same.
* obj-c++.dg/property/property-neg-3.mm: Same.
* obj-c++.dg/protocol-inheritance-1.mm: Same.
* obj-c++.dg/protocol-inheritance-2.mm: Same.
* obj-c++.dg/syntax-error-1.mm: Same.
* obj-c++.dg/try-catch-13.mm: Same.
* objc.dg/bitfield-4.m: Same.
* objc.dg/class-1.m: Same.
* objc.dg/method-11.m: Same.
* objc.dg/method-6.m: Same.
* objc.dg/method-7.m: Same.
* objc.dg/method-9.m: Same.
* objc.dg/missing-proto-3.m: Same.
* objc.dg/naming-2.m: Same.
* objc.dg/property/at-property-16.m: Same.
* objc.dg/property/at-property-18.m: Same.
* objc.dg/property/at-property-25.m: Same.
* objc.dg/property/at-property-5.m: Same.
* objc.dg/property/dynamic-2.m: Same.
* objc.dg/property/property-neg-3.m: Same.
* objc.dg/protocol-inheritance-1.m: Same.
* objc.dg/protocol-inheritance-2.m: Same.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/obj-c++.dg/bitfield-1.mm
trunk/gcc/testsuite/obj-c++.dg/bitfield-4.mm
trunk/gcc/testsuite/obj-c++.dg/bitfield-5.mm
trunk/gcc/testsuite/obj-c++.dg/exceptions-3.mm
trunk/gcc/testsuite/obj-c++.dg/exceptions-5.mm
trunk/gcc/testsuite/obj-c++.dg/method-1.mm
trunk/gcc/testsuite/obj-c++.dg/method-12.mm
trunk/gcc/testsuite/obj-c++.dg/method-13.mm
trunk/gcc/testsuite/obj-c++.dg/method-15.mm
trunk/gcc/testsuite/obj-c++.dg/method-16.mm
trunk/gcc/testsuite/obj-c++.dg/property/at-property-18.mm
trunk/gcc/testsuite/obj-c++.dg/property/at-property-25.mm
trunk/gcc/testsuite/obj-c++.dg/property/at-property-5.mm
trunk/gcc/testsuite/obj-c++.dg/property/dynamic-2.mm
trunk/gcc/testsuite/obj-c++.dg/property/property-neg-3.mm
trunk/gcc/testsuite/obj-c++.dg/protocol-inheritance-1.mm
trunk/gcc/testsuite/obj-c++.dg/protocol-inheritance-2.mm
trunk/gcc/testsuite/obj-c++.dg/syntax-error-1.mm
trunk/gcc/testsuite/obj-c++.dg/try-catch-13.mm
trunk/gcc/testsuite/objc.dg/bitfield-4.m
trunk/gcc/testsuite/objc.dg/class-1.m
trunk/gcc/testsuite/objc.dg/method-11.m
trunk/gcc/testsuite/objc.dg/method-6.m
trunk/gcc/testsuite/objc.dg/method-7.m
trunk/gcc/testsuite/objc.dg/method-9.m
trunk/gcc/testsuite/objc.dg/missing-proto-3.m
trunk/gcc/testsuite/objc.dg/naming-2.m
trunk/gcc/testsuite/objc.dg/property/at-property-16.m
trunk/gcc/testsuite/objc.dg/property/at-property-18.m
trunk/gcc/testsuite/objc.dg/property/at-property-25.m
trunk/gcc/testsuite/objc.dg/property/at-property-5.m
trunk/gcc/testsuite/objc.dg/property/dynamic-2.m
trunk/gcc/testsuite/objc.dg/property/property-neg-3.m
trunk/gcc/testsuite/objc.dg/protocol-inheritance-1.m
trunk/gcc/testsuite/objc.dg/protocol-inheritance-2.m

[Bug fortran/78640] [F2015] gfortran accepts invalid allocatable polymorphic result in pure function

[stefano.zaghi at cnr dot it]

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

--- Comment #3 from Stefano Zaghi  ---
Yes, I am one who think that respecting this constrain is important: I was not
aware that standard does not allow pure polymorphic functions, thus I mislead
myself from the fact that the compiler did bot complain about this violation.

My best regards.

An enthusiast.

[Bug c++/80560] warn on undefined memory operations involving non-trivial types

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-04-28
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
I'm testing a simple patch to provide this enhancement.

[Bug c++/80560] New: warn on undefined memory operations involving non-trivial types

[msebor at gcc dot gnu.org]

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

Bug ID: 80560
   Summary: warn on undefined memory operations involving
non-trivial types
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

As discussed in the review of an otherwise unrelated GCC patch
(https://gcc.gnu.org/ml/gcc-patches/2017-04/msg01506.html), calling a function
like memset to zero out an object of a non-trivial type is an easy mistake to
make, especially in C code bases that are migrating to C++.  As noted in the
same discussion, projects (GDB in this instance) have developed solutions to
help detect these misuses.  It would make sense for GCC to provide an option to
detect and report such errors.  This is an enhancement request to track this
feature.

[Bug testsuite/80557] rewrite absolute line numbers into relative or saved line numbers

[vries at gcc dot gnu.org]

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

--- Comment #3 from Tom de Vries  ---
Author: vries
Date: Fri Apr 28 21:52:16 2017
New Revision: 247400

URL: https://gcc.gnu.org/viewcvs?rev=247400=gcc=rev
Log:
Replace absolute linenrs in gfortran.dg

2017-04-28  Tom de Vries  

PR testsuite/80557
* gfortran.dg/gomp/appendix-a/a.24.1.f90: Replace absolute linenrs.
* gfortran.dg/gomp/appendix-a/a.31.3.f90: Same.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/gomp/appendix-a/a.24.1.f90
trunk/gcc/testsuite/gfortran.dg/gomp/appendix-a/a.31.3.f90

[Bug tree-optimization/80523] -Wformat-overflow doesn't consider -fexec-charset

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
Fixed via r247401.

[Bug tree-optimization/80523] -Wformat-overflow doesn't consider -fexec-charset

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Author: msebor
Date: Fri Apr 28 22:29:40 2017
New Revision: 247401

URL: https://gcc.gnu.org/viewcvs?rev=247401=gcc=rev
Log:
PR tree-optimization/80523 -  -Wformat-overflow doesn't consider -fexec-charset

gcc/ChangeLog:

PR tree-optimization/80523
* gimple-ssa-sprintf.c (target_to_host_charmap): New global variable.
(init_target_to_host_charmap, target_to_host, target_strtol10): New
functions.
(maybe_warn, format_directive, parse_directive): Use new functions.
(pass_sprintf_length::execute): Call init_target_to_host_charmap.

gcc/testsuite/ChangeLog:

PR tree-optimization/80523
* gcc.dg/tree-ssa/builtin-sprintf-warn-18.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-18.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/c.opt
trunk/gcc/gimple-ssa-sprintf.c
trunk/gcc/testsuite/ChangeLog

[Bug driver/80545] option -Wstringop-overflow not recognized by Fortran

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic, patch

--- Comment #3 from Martin Sebor  ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2017-04/msg01544.html

[Bug libstdc++/80553] std::vector allows instantiation with type having a deleted destructor

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Marco Arena from comment #0)
> This compiles just fine, although it shouldn't because 'Foo' is not Erasable.

If you fail to meet the requirements for a container then your code has
undefined behaviour. No compiler error is required.

[Bug libstdc++/80553] std::vector allows instantiation with type having a deleted destructor

[marco at italiancpp dot org]

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

--- Comment #6 from Marco Arena  ---
Hi guys,
thanks for the clarification, I didn't know it's UB, rather I thought this was
a requirement as stated here: http://en.cppreference.com/w/cpp/concept/Erasable
(see "Notes"). I had to read the standard, though. My fault.

Anyway, as clang and vs do, I think it's worthwhile having a compile-error.

Thanks for your comments.

[Bug fortran/80555] New: gfortran crashes with segmentation fault

[gustavo.hime at mpimet dot mpg.de]

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

Bug ID: 80555
   Summary: gfortran crashes with segmentation fault
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gustavo.hime at mpimet dot mpg.de
  Target Milestone: ---

Created attachment 41282
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41282=edit
Run gfortran -c on this.

gfortran crashes with segmentation fault when compiling the attached file.
Problem is related to using MAXVAL of a rank-2 PARAMETER array as dimension for
a static variable.No special flags required, just gfortran -c. No assembly
generated. Running on Debian Jessie, tested with Debian's gcc 5.3.0 and 6.2.0
plus locally compiled 5.4.0. Compiler output from 6.2.0 is terse, from 5.4.0 is
pasted below:f951: internal compiler error: Segmentation fault
0xa8d25f crash_signal
../../gcc/toplev.c:383
0x6e9d72 gfc_add_decl_to_parent_function
../../gcc/fortran/trans-decl.c:239
0x6e9d72 create_index_var
../../gcc/fortran/trans-decl.c:802
0x6ebffa gfc_build_qualified_array
../../gcc/fortran/trans-decl.c:889
0x6eec34 gfc_get_symbol_decl(gfc_symbol*)
../../gcc/fortran/trans-decl.c:1549
0x6f0f3b gfc_create_module_variable
../../gcc/fortran/trans-decl.c:4592
0x6bd42b do_traverse_symtree
../../gcc/fortran/symbol.c:3646
0x6f0c4b gfc_generate_module_vars(gfc_namespace*)
../../gcc/fortran/trans-decl.c:5035
0x6d4bd1 gfc_generate_module_code(gfc_namespace*)
../../gcc/fortran/trans.c:2061
0x68f14d translate_all_program_units
../../gcc/fortran/parse.c:5393
0x68f14d gfc_parse_file()
../../gcc/fortran/parse.c:5603
0x6ce915 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:229

[Bug libstdc++/80553] std::vector allows instantiation with type having a deleted destructor

[glisse at gcc dot gnu.org]

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

--- Comment #3 from Marc Glisse  ---
__has_trivial_destructor(Foo) returns true for Foo which has a deleted
destructor (clang, gcc and the standard agree on this). That's bound to confuse
people forever, but I guess there's nothing we can do about it :-(

[Bug libstdc++/80553] std::vector allows instantiation with type having a deleted destructor

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
All standard library requirements produce undefined behaviour when violated,
unless specified otherwise. I'm trying to fix that: https://wg21.link/p0411r0

It probably won't be possible to enforce the "T is Erasable from X" requirement
for some containers, because C++17 allows std::vector to be
instantiated, and so we can't test for a usable destructor. The requirement
might have to be moved to the container's destructor to be enforceable as a
compile-time error.

[Bug bootstrap/80531] [7 Regression] RC1 bootstrap comparison failure

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
Author: jakub
Date: Fri Apr 28 11:42:14 2017
New Revision: 247368

URL: https://gcc.gnu.org/viewcvs?rev=247368=gcc=rev
Log:
PR bootstrap/80531
* cgraph.h (symtab_node::debug_symtab): No longer inline.
* symtab.c (symtab_node::debug_symtab): Move definition here.

Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/cgraph.h
branches/gcc-7-branch/gcc/symtab.c

[Bug driver/80545] option -Wstringop-overflow not recognized by Fortran

[janus at gcc dot gnu.org]

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

--- Comment #2 from janus at gcc dot gnu.org ---
(In reply to Richard Biener from comment #1)
> I suggest to enable them only for C family languages (I notice the options
> do not use EnabledBy()).

I guess that would also fix the bogus warning from PR 79929 ...

[Bug target/80505] FAIL: gcc.dg/ipa/iinline-attr.c scan-ipa-dump inline "hooray[^\\n]*inline copy in test"

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||dje at gcc dot gnu.org,
   ||segher at gcc dot gnu.org

--- Comment #3 from Martin Liška  ---
(In reply to Martin Jambor from comment #2)
> The testcase was added with a i386 specific patch to test that
> inlining of indirect calls in presence of __optimize__ attribute.
> 
> I am not sure whether inlining, even direct, in presence of the
> attribute is supposed to work on ppc64le, but it shows that it does
> not.  Even early inliner dump shows that an attempt to inline hiphip/1
> into test/2 fails because of "optimization level attribute mismatch."
> I suppose we need something like r222559 for ppc.

Yes, I really believe so. I'm CCing port maintainers.

> 
> If not, the testcase should be moved to a i386 specific directory.
> 
> And by the way, I tend to think that the testcase should use
> -fno-indirect-inlining option, the indirect call is direct when the
> IPA layer sees it.

Why should we add -fno-indirect-inlining to the test?

[Bug libstdc++/80553] std::vector allows instantiation with type having a deleted destructor

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
We can't change the silly rule, but I suppose we could do:

--- a/libstdc++-v3/include/bits/stl_construct.h
+++ b/libstdc++-v3/include/bits/stl_construct.h
@@ -114,7 +114,15 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 {
   template
 static void
-__destroy(_ForwardIterator, _ForwardIterator) { }
+__destroy(_ForwardIterator, _ForwardIterator)
+   {
+#if __cplusplus >= 201103L
+ using _Tp
+   = typename std::iterator_traits<_ForwardIterator>::value_type;
+ static_assert( std::is_destructible<_Tp>::value,
+ "type must be destructible" );
+#endif
+   }
 };

   /**

So we get a diagnostic for trying to destroy something that isn't destructible.

[Bug tree-optimization/80549] [7/8 Regression] wrong code at -O2 and -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu (executable does not terminate)

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Ok.  So the issue is that the irreducible region becomes reducible after DOM1
which means cfg-cleanup ends up with a CFG that has the former exit edge
of loop 2 turned into an additional latch (re-starting the loop IV at 5).
This invalidates the number of iteration upper bounds.

So the error lies in fix_loop_structure which fails to reset the upper
bound / estimates.  Doing so unconditionally is quite a hammer (but well,
we shouldn't do fix_loop_structure so often...).  I don't see a good way
to detect this situation though (given in fixup we can't rely on
irreducible flags being set for example, neither can we at the start of
CFG cleanup).

The easiest thing would be if we can rely on the loop not be re-discovered
as loop 2.

Maybe we can, in CFG cleanup, ensure that we have preheaders.  Like the
following:

Index: gcc/tree-cfgcleanup.c
===
--- gcc/tree-cfgcleanup.c   (revision 247362)
+++ gcc/tree-cfgcleanup.c   (working copy)
@@ -766,6 +766,26 @@ cleanup_tree_cfg_noloop (void)
   changed = false;
 }

+  /* Make sure existing loops have preheaders as we need to preserve
+ the existing loop structure to not wreck niter bounds and generally
+ regions identified as a specific loop.  */
+  if (current_loops)
+{
+  /* ???  To be able to use create_preheaders we have to first
+ fixup loops.  Another possibility is to refactor it somehow
+and rely on bb_loop_header_p and a full CFG walk, also handling
+multiple latches.  */
+  if (loops_state_satisfies_p (LOOPS_NEED_FIXUP))
+   fix_loop_structure (NULL);
+  if (! loops_state_satisfies_p (LOOPS_HAVE_PREHEADERS))
+   {
+ if (loops_state_satisfies_p (LOOPS_MAY_HAVE_MULTIPLE_LATCHES))
+   disambiguate_loops_with_multiple_latches ();
+ create_preheaders (LOOPS_HAVE_PREHEADERS);
+ loops_state_clear (LOOPS_HAVE_PREHEADERS);
+   }
+}
+
   changed |= cleanup_tree_cfg_1 ();

   gcc_assert (dom_info_available_p (CDI_DOMINATORS));

[Bug libstdc++/80553] std::vector allows instantiation with type having a deleted destructor

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|RESOLVED|ASSIGNED
   Last reconfirmed||2017-04-28
 Resolution|INVALID |---
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #5 from Jonathan Wakely  ---
We can use a static_assert to improve the diagnostic even for the non-trivial
case, so this seems worthwhile.

[Bug bootstrap/80531] [7 Regression] RC1 bootstrap comparison failure

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Author: jakub
Date: Fri Apr 28 11:15:55 2017
New Revision: 247367

URL: https://gcc.gnu.org/viewcvs?rev=247367=gcc=rev
Log:
PR bootstrap/80531
* cgraph.h (symtab_node::debug_symtab): No longer inline.
* symtab.c (symtab_node::debug_symtab): Move definition here.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraph.h
trunk/gcc/symtab.c

[Bug bootstrap/80531] [7 Regression] RC1 bootstrap comparison failure

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug bootstrap/69790] LTO compiling GCC does not work (lib/bfd-plugin path has unclear location)

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
I see, I believe LTO bootstrap is properly tested and I haven't noticed any
problem. What version of binutils Дилян do you use and what's your system?

[Bug target/80505] FAIL: gcc.dg/ipa/iinline-attr.c scan-ipa-dump inline "hooray[^\\n]*inline copy in test"

[jamborm at gcc dot gnu.org]

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

--- Comment #4 from Martin Jambor  ---
(In reply to Martin Liška from comment #3)
> > And by the way, I tend to think that the testcase should use
> > -fno-indirect-inlining option, the indirect call is direct when the
> > IPA layer sees it.
> 
> Why should we add -fno-indirect-inlining to the test?

I meant -fno-early-inlining, sorry.

The reason is that early inlining inlines hiphip() to test() and then
constant propagation turns the indirect call into a direct one before
IPA inliner (well, IPA-CP, but anyway) sees it.  So, at least as far
as internal representation is concerned, we never actually do inlining
of an indirect call.

However, it really depends on why such a test using indirect calls was
added in the first place and that (i.e. why direct calls are not
enough) is not clear to me.  Maybe we are fine.

[Bug lto/77954] LTO_STREAMER_DEBUG ICE with OpenMP SIMD clones

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-04-28
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Can I reproduce it on a normal GCC (no target compiler) on my x86_64-linux-gnu
target?

After setting the macro, following works for me:
./gcc/xgcc -B gcc
/home/marxin/Programming/gcc/libgomp/testsuite/libgomp.fortran/declare-simd-4.f90
-flto -c -mavx -fno-use-linker-plugin -fno-inline

[Bug driver/69690] -pg -fomit-frame-pointer fails with error even if -pg does not depend on frame pointers

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-04-28
 CC||kyrylo.tkachov at arm dot com,
   ||marxin at gcc dot gnu.org,
   ||nickc at gcc dot gnu.org,
   ||ramana at gcc dot gnu.org,
   ||rearnsha at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Yes, it's there for very long time. I'm adding ARM maintainers so that they can
reply to your request.

[Bug testsuite/80557] New: rewrite absolute line numbers into relative or saved line numbers

[vries at gcc dot gnu.org]

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

Bug ID: 80557
   Summary: rewrite absolute line numbers into relative or saved
line numbers
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

https://gcc.gnu.org/ml/gcc-patches/2017-04/msg01280.html:
...
Are there any spots where the relative line number is with too big bias
(say .+10 or .-10 and more)?  I guess those should be decided case by case
whether we want relative, absolute or saved line numbers.  If the
diagnostic is within the same function or code block as the stuff it is
relative to, relative is fine, but if e.g. the messages are just at the end
of file and there are unrelated functions in between, it is not a good idea
to use relative.
...

[Bug libstdc++/53984] iostream operation throwing exception when exceptions not enabled

[dibeas at ieee dot org]

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

David Rodriguez Ibeas  changed:

   What|Removed |Added

 CC||dibeas at ieee dot org

--- Comment #6 from David Rodriguez Ibeas  ---
Still failling 6.2.

Any plans to look at this one?

[Bug bootstrap/69790] LTO compiling GCC does not work (lib/bfd-plugin path has unclear location)

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

--- Comment #2 from Markus Trippelsdorf  ---
He means gcc-nm.

[Bug bootstrap/69790] LTO compiling GCC does not work (lib/bfd-plugin path has unclear location)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-04-28
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Hm, are you installing GCC directly too root without any prefix?
Actually GCC does not compile nm during bootstrap. Can you please present
command line and strace results for the problematic invocations of GCC and nm?

[Bug ada/80556] [8 Regression] Ada breaks bootstrap on x86_64-apple-darwin16

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Severity|normal  |blocker

[Bug middle-end/78081] -Wmaybe-initialized false-alarm regression for Emacs regex.c

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-04-28
 CC||marxin at gcc dot gnu.org
  Known to work||4.8.5
 Ever confirmed|0   |1
  Known to fail||5.4.0, 6.3.0, 7.0.1, 8.0

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

[Bug testsuite/80557] rewrite absolute line numbers into relative or saved line numbers

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #1 from Tom de Vries  ---
Two patches posted at https://gcc.gnu.org/ml/gcc-patches/2017-04/msg01436.html
, for 37 out of 168 test-cases.

[Bug ada/80556] New: [8 Regression] Ada breaks bootstrap on x86_64-apple-darwin16

[dominiq at lps dot ens.fr]

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

Bug ID: 80556
   Summary: [8 Regression] Ada breaks bootstrap on
x86_64-apple-darwin16
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
CC: charlet at gcc dot gnu.org
  Target Milestone: ---

Compiling g-exptty.adb on x86_64-apple-darwin16 at r247343 fails with

/opt/gcc/build_a/./gcc/xgcc -B/opt/gcc/build_a/./gcc/
-B/opt/gcc/gcc8a/x86_64-apple-darwin16.5.0/bin/
-B/opt/gcc/gcc8a/x86_64-apple-darwin16.5.0/lib/ -isystem
/opt/gcc/gcc8a/x86_64-apple-darwin16.5.0/include -isystem
/opt/gcc/gcc8a/x86_64-apple-darwin16.5.0/sys-include-c -g -O2  -fno-common 
-W -Wall -gnatpg -nostdinc   g-exptty.adb -o g-exptty.o
xgcc: internal compiler error: Illegal instruction: 4 (program gnat1)

and breaks bootstrap. Revision r247285 is OK.

[Bug fortran/80555] gfortran crashes with segmentation fault

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-04-28
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, all releases I have (4.5.0) do ICE.

[Bug ada/80556] [8 Regression] Ada breaks bootstrap on x86_64-apple-darwin16

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug gcov-profile/79891] Wrong count of line coverage in case of gcov -a

[marxin at gcc dot gnu.org]

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

--- Comment #9 from Martin Liška  ---
Author: marxin
Date: Fri Apr 28 12:51:05 2017
New Revision: 247374

URL: https://gcc.gnu.org/viewcvs?rev=247374=gcc=rev
Log:
Make gcno more precise about BBs really belonging to a line (PR
gcov-profile/79891).

2017-04-28  Martin Liska  

PR gcov-profile/79891
* gcov.c (add_line_counts): Assign BBs to lines just if the BB
is marked by compiler as living on a line.
(get_cycles_count): Remove usage of the union.
(output_intermediate_file): Likewise.
(find_source): Fix GNU coding style.
(accumulate_line_counts): Remove old non-all block mode.
(output_lines): Remove usage of the union.
* profile.c (output_location): Include all BBs, even if
belonging to a same line (and file) as a previous BB.
2017-04-28  Martin Liska  

PR gcov-profile/79891
* gcc.misc-tests/gcov-17.c: New test.
* gcc.misc-tests/gcov-18.c: New test.

Added:
trunk/gcc/testsuite/gcc.misc-tests/gcov-17.c
trunk/gcc/testsuite/gcc.misc-tests/gcov-18.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gcov.c
trunk/gcc/profile.c
trunk/gcc/testsuite/ChangeLog

[Bug gcov-profile/53915] gcov can call format_gcov with top > bottom, which is unexpected and gives 99.99%

[marxin at gcc dot gnu.org]

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

--- Comment #8 from Martin Liška  ---
Author: marxin
Date: Fri Apr 28 12:51:22 2017
New Revision: 247375

URL: https://gcc.gnu.org/viewcvs?rev=247375=gcc=rev
Log:
Fix format_gcov to not print misleading values (PR gcov-profile/53915)

2017-04-28  Martin Liska  

PR gcov-profile/53915
* gcov.c (format_gcov): Print 'NAN %' when top > bottom.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gcov.c

[Bug tree-optimization/80549] [7/8 Regression] wrong code at -O2 and -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu (executable does not terminate)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org

--- Comment #4 from Richard Biener  ---
As (I believe) CFG cleanup preserves single-entry loops (single entry headers)
and a latch cannot become an entry maintaining this CFG property throughout the
compilation pipeline might make sense (and might be not too intrusive either).
That would be certainly cheaper than doing this again and again (when usually
it will not be necessary).

So doing instead

Index: gcc/tree-cfg.c
===
--- gcc/tree-cfg.c  (revision 247362)
+++ gcc/tree-cfg.c  (working copy)
@@ -402,7 +402,7 @@ execute_build_cfg (void)
   dump_scope_blocks (dump_file, dump_flags);
 }
   cleanup_tree_cfg ();
-  loop_optimizer_init (AVOID_CFG_MODIFICATIONS);
+  loop_optimizer_init (LOOPS_HAVE_PREHEADERS);
   replace_loop_annotate ();
   return 0;
 }

fixes it up to the point where DOM (via threading) introduces another
edge to the header.  ISTR I tried to "fix" this before, by inserting
a preheader at that point.  Basically it threads through the preheader
to the loop header itself.  Avoiding that would be nice -- ending
the path one block earlier or creating a forwarder.

[Bug gcov-profile/53915] gcov can call format_gcov with top > bottom, which is unexpected and gives 99.99%

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to work||8.0
  Known to fail||5.4.0, 6.3.0, 7.0.1

--- Comment #9 from Martin Liška  ---
Fixed on trunk.

[Bug gcov-profile/79891] Wrong count of line coverage in case of gcov -a

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to work||8.0
  Known to fail||5.4.0, 6.3.0, 7.0.1

--- Comment #10 from Martin Liška  ---
Fixed on trunk.

[Bug libstdc++/80553] std::vector allows instantiation with type having a deleted destructor

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
Author: redi
Date: Fri Apr 28 12:56:53 2017
New Revision: 247379

URL: https://gcc.gnu.org/viewcvs?rev=247379=gcc=rev
Log:
PR libstdc++/80553 don't allow destroying non-destructible types

PR libstdc++/80553
* include/bits/stl_construct.h (_Destroy, _Destroy_n): Add static
assertions to ensure type is destructible.
(destroy_at, destroy, destroy_n): Move from stl_uninitialized.h.
* include/bits/stl_uninitialized.h (destroy_at, destroy, destroy_n):
Move to stl_construct.h.
* testsuite/20_util/specialized_algorithms/memory_management_tools/
destroy_neg.cc: New test.
* testsuite/23_containers/vector/cons/destructible_neg.cc: New test.

Added:
   
trunk/libstdc++-v3/testsuite/20_util/specialized_algorithms/memory_management_tools/destroy_neg.cc
trunk/libstdc++-v3/testsuite/23_containers/vector/cons/destructible_neg.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/stl_construct.h
trunk/libstdc++-v3/include/bits/stl_uninitialized.h

[Bug libstdc++/80553] std::vector allows instantiation with type having a deleted destructor

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |8.0
   Severity|enhancement |normal

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

We were also silently accepting attempts to use C++17's std::destroy and
std::destroy_n on types with deleted destructors.

[Bug driver/56469] The .gcno file being generated is not cleaned up after gcc exits with an error.

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to work||8.0
  Known to fail||5.4.0, 6.3.0, 7.0.1

--- Comment #3 from Martin Liška  ---
Fixed on trunk.

[Bug fortran/80555] [5/6/7/8 Regression] ICE when using MAXVAL of a rank-2 PARAMETER array in a module

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
  Known to work||4.3.6
Summary|gfortran crashes with   |[5/6/7/8 Regression] ICE
   |segmentation fault  |when using MAXVAL of a
   ||rank-2 PARAMETER array in a
   ||module
  Known to fail||4.4.7, 4.5.4, 4.6.4, 4.7.3,
   ||4.8.5, 4.9.3, 5.4.0, 6.3.0,
   ||7.0.1, 8.0

--- Comment #2 from Dominique d'Humieres  ---
Confirmed from 4.4.7 up to trunk (8.0). The test compiles with 4.3.6.

Note also that the test

  INTEGER, PARAMETER :: a(2,2) = RESHAPE((/1,2,3,4/), SHAPE=(/2,2/))
  REAL, DIMENSION(MAXVAL(a)) :: b
  print *, MAXVAL(a)

end

compiles and gives 4 at run time.

The following test

  INTEGER, PARAMETER :: a(2,2) = RESHAPE((/1,2,3,4/), SHAPE=(/2,2/))
  integer :: i = MAXVAL(a)
end

is rejected with

   integer :: i = MAXVAL(a)
1
Error: transformational intrinsic 'maxval' at (1) is not permitted in an
initialization expression

[Bug gcov-profile/80031] gcno files contain BB flags that are not used

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Author: marxin
Date: Fri Apr 28 12:49:26 2017
New Revision: 247370

URL: https://gcc.gnu.org/viewcvs?rev=247370=gcc=rev
Log:
gcno file: do not stream block flags (PR gcov-profile/80031).

2017-04-28  Martin Liska  

PR gcov-profile/80031
* gcov-dump.c (tag_blocks): Just print number of basic blocks.
* gcov-io.h (GCOV_TAG_BLOCKS_NUM): Remove unused macro.
* gcov.c (read_graph_file): Read just number of blocks.
* profile.c (branch_prob): Do not stream 0 flags per a basic
block.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gcov-dump.c
trunk/gcc/gcov-io.h
trunk/gcc/gcov.c
trunk/gcc/profile.c

[Bug driver/56469] The .gcno file being generated is not cleaned up after gcc exits with an error.

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Author: marxin
Date: Fri Apr 28 12:50:08 2017
New Revision: 247371

URL: https://gcc.gnu.org/viewcvs?rev=247371=gcc=rev
Log:
Remove .gcno file when compilation does not success (PR driver/56469).

2017-04-28  Martin Liska  

PR driver/56469
* coverage.c (coverage_remove_note_file): New function.
* coverage.h: Declare the function.
* toplev.c (finalize): Clean if an error has been seen.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/coverage.c
trunk/gcc/coverage.h
trunk/gcc/toplev.c

[Bug gcov-profile/80031] gcno files contain BB flags that are not used

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2017-4-28
  Known to work||8.0
  Known to fail||5.4.0, 6.3.0, 7.0.1

--- Comment #3 from Martin Liška  ---
Fixed on trunk.

[Bug tree-optimization/80549] [7/8 Regression] wrong code at -O2 and -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu (executable does not terminate)

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Created attachment 41283
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41283=edit
patch

Patch I am testing.

[Bug boehm-gc/74750] Address sanitizer detects stack-buffer-underflow in GC_push_all_eager in mark.c

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-04-28
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
As java FE was buried, is it still actual? If not, we can close it.

[Bug tree-optimization/80558] New: VRP not handling x & -2 well

[jakub at gcc dot gnu.org]

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

Bug ID: 80558
   Summary: VRP not handling x & -2 well
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

The VRP handling of BIT_AND_EXPR when one of the operands is a INTEGER_CST mask
with all 1 bits starting from MSB followed by only 0 bits is not good enough.
Consider:
void link_error (void);

void
foo (int x)
{
  if (x >= 5 && x <= 19)
{
  x &= -2;
  if (x < 4 || x > 18)
link_error ();
}
}
With assertions we have:
  x_10 = ASSERT_EXPR ;
  x_8 = x_10 & -2;
and properly compute:
x_10: [5, 19]  EQUIVALENCES: { x_6(D) } (1 elements)
but for x_8 we generate an unnecessarily wide range:
x_8: [0, 19]
while
x_8: [4, 18]
is the right result.  Shall we special case BIT_AND_EXPR with one of the
operands a singleton range equal to wi::shifted_mask (start, precision - start,
false, precision) for some value of start (i.e. one where its negation is a
power of 2)?  If the other range is VR_RANGE, I think we can just mask the min
and max, maybe something similar even for anti range?

[Bug other/78889] GCC fails to build due to graphite-dependences.c

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-04-28
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Hm, I've just tried GCC 6 branch where I run contrib/download_prerequisites and
cross compiler for the target on x86_64-linux-gnu works for me. Can you please
test HEAD of the gcc 6 branch?

[Bug middle-end/78081] -Wmaybe-initialized false-alarm regression for Emacs regex.c

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #2 from Jeffrey A. Law  ---
This is fallout from the change in how we compute the cost of a jump threading
path.  gcc-7 was changed to use common infrastructure to estimate the cost of
duplicating a path during jump threading.  That common infrastructure is much
more accurate than the ad-hoc scheme the threader used in gcc-6.

The net result is the threader does not think it is profitable to thread
certain paths and that leaves a path with an uninitialized use of offset2 in
the CFG that can't actually occur at runtime.

The paths involving offset1 are shorter, and thus less costly to duplicate and
they get threaded, removing the path with the uninitialized use of offset1.

I have some local patches (for an unrelated BZ) which retune cutoffs (which was
not done after changing the costing model).  Hopefully as we work through the
new tunings we'll be able to pick up this case.

[Bug driver/80545] option -Wstringop-overflow not recognized by Fortran

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

[Bug ada/80556] [8 Regression] Ada breaks bootstrap on x86_64-apple-darwin16

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-04-28
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Not fixed at revision r247391.

[Bug testsuite/80552] New: Make consecutive relative line numbers more maintainable

[vries at gcc dot gnu.org]

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

Bug ID: 80552
   Summary: Make consecutive relative line numbers more
maintainable
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

[ Spinoff from PR80221: "Contrib script to rewrite testcase from absolute to
relative line numbers" ]

We have patterns using relative line numbers in dg directives like this in
gcc/testsuite/obj-c++.dg/class-extension-2.mm:
...
@implementation MyObject2
@end /* { dg-warning "incomplete implementation of class .MyObject2." } */
 /* { dg-warning "method definition for .-test. not found" "" { target
*-*-* } .-1 } */
 /* { dg-warning "class .MyObject2. does not fully implement the
.MyProtocol. protocol" "" { target *-*-* } .-2 } */
 /* { dg-warning "method definition for .-test2. not found" "" { target
*-*-* } .-3 } */
 /* { dg-warning "class .MyObject2. does not fully implement the
.MyProtocol2. protocol" "" { target *-*-* } .-4 } */
 /* { dg-warning "method definition for .-test3. not found" "" { target
*-*-* } .-5 } */
 /* { dg-warning "class .MyObject2. does not fully implement the
.MyProtocol3. protocol" "" { target *-*-* } .-6 } */
...

A few ideas were generated in PR80221 to deal with this in a less verbose and
more maintainable fashion.

PR80221 comment 7:
...
  foobar;
  /* { dg-warning "warning for foobar" continue }
 { dg-warning "another warning for foobar" continue }
 { dg-error "error for foobar" } */
...

PR80221 comment 10:
...
foobar;
/* { dg-warning "warning for foobar" .-1 }
   Bla, bla, reasoning.
   { dg-warning "another warning for foobar" continue }
   Bla, bla, more reasoning.
   { dg-error "error for foobar" continue } */
...

PR80221 comment 11:
...
foobar;
/* { dg-begin-same-line-output .-1 }
   ...
   { dg-warning "warning for foobar" }
   ...
   { dg-message "note for foobar" }
   ...
   { dg-error "error for foobar" }
   ...
   { dg-end-same-line-output }  */
...

[Bug testsuite/80221] Contrib script to rewrite testcase from absolute to relative line numbers

[vries at gcc dot gnu.org]

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

--- Comment #19 from Tom de Vries  ---
Filed spinoff PR80552 - "Make consecutive relative line numbers more
maintainable" to capture discussion related to 'continue' line and
dg-{begin,end}-same-line-output.

[Bug testsuite/80552] Make consecutive relative line numbers more maintainable

[vries at gcc dot gnu.org]

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

--- Comment #1 from Tom de Vries  ---
FTR, a way to deal with the consecutive relative line numbers pattern using
dg-line would be:
...
 foobar; /* { dg-line foobar_line } */
  /* { dg-warning "warning for foobar" foobar_line }
 { dg-warning "another warning for foobar" foobar_line }
 { dg-error "error for foobar" foobar_line } */
...
but that requires you to come up with a variable name for the line. It's better
to have a solution that can be applied mechanically.

[Bug libstdc++/80553] New: std::vector allows instantiation with type having a deleted destructor

[marco at italiancpp dot org]

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

Bug ID: 80553
   Summary: std::vector allows instantiation with type having a
deleted destructor
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marco at italiancpp dot org
  Target Milestone: ---

struct Foo
{
~Foo() = delete;
};

int main()
{
vector v;
}

This compiles just fine, although it shouldn't because 'Foo' is not Erasable.

Repro: https://wandbox.org/#wandbox-resultwindow-code-body-12

On the other hand, in the following code a compile error is legitimately
thrown:

struct Foo
{
private:
~Foo();
};

int main()
{
vector v;
}

std::list does not exhibit the same behavior:

struct Foo
{
~Foo() = delete;
};

int main()
{
list v;
}

which just fails. I have not tried other containers.

[Bug libstdc++/80553] std::vector allows instantiation with type having a deleted destructor

[marco at italiancpp dot org]

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

--- Comment #1 from Marco Arena  ---
My apologies, here is the repro link:
https://wandbox.org/permlink/SOzsFGQ1vGVjwy1O

[Bug tree-optimization/80549] [7/8 Regression] wrong code at -O2 and -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu (executable does not terminate)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
   Priority|P3  |P2
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #2 from Richard Biener  ---
I will have a look (disabling VRP1 seems to help).  It is cunroll that does the
harmful transform in the end (niter analysis?):

-Loop 4 iterates 246 times.
-Loop 4 iterates at most 246 times.
-Loop 4 likely iterates at most 246 times.
-Not unrolling loop 4 (--param max-completely-peel-times limit reached).
+Loop 2 iterates 246 times.
+Loop 2 iterates at most 27 times.
+Loop 2 likely iterates at most 27 times.
+Analyzing # of iterations of loop 2
+  exit condition [246, + , 255] != 0
+  bounds on difference of bases: -246 ... -246
+  result:
+# of iterations 246, bounded by 246
+Removed pointless exit: if (ivtmp_32 != 0)
+Not unrolling loop 2 (--param max-completely-peel-times limit reached).

we see we can somehow preserve loop2 while we re-discovered it with vrp1
disabled (eventually dropping the upper iteration bound).

Looks like another latent threading issue to me.  Without VRP1:

  Threaded jump 14 --> 3 to 17
  Threaded jump 7 --> 11 to 18
fix_loop_structure: fixing up loops for function
fix_loop_structure: removing loop 1
flow_loops_find: discovered new loop 3 with header 3
flow_loops_find: discovered new loop 4 with header 9

that's CFG cleanup after DOM2.  With VRP1 enabled we thread the same amount
of jumps but only have

  Threaded jump 14 --> 3 to 17
  Threaded jump 7 --> 11 to 18
fix_loop_structure: fixing up loops for function
fix_loop_structure: removing loop 1
flow_loops_find: discovered new loop 3 with header 3

[Bug target/78926] Build fails after update to GCC 6.3

[d.v.a at ngs dot ru]

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

--- Comment #14 from __vic  ---
GCC 7-RC1 now reports

lto1: fatal error: bytecode stream in file ‘lib/libssl.a’ generated with LTO
version 5.1 instead of the expected 6.0
compilation terminated.
lto-wrapper: fatal error: g++ returned 1 exit status
compilation terminated.
/opt/binutils/bin/ld: fatal error: lto-wrapper failed
collect2: error: ld returned 1 exit status

in such situation. Very helpful!

[Bug testsuite/80221] Contrib script to rewrite testcase from absolute to relative line numbers

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

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

--- Comment #17 from Tom de Vries  ---
I've written the script contrib/tests-rewrite-relative-line-number.py, and
committed the results of running it. The script itself is not committed, given
that we're not expecting to reuse it.

I've added the dg-line directive, so hopefully most of the remaining absolute
linenrs can be rewritten on a case-by-case-basis using either relative or saved
line nrs.

Given that the automated part of the effort is done, marking as resolved,
fixed.

[Bug testsuite/80221] Contrib script to rewrite testcase from absolute to relative line numbers

[vries at gcc dot gnu.org]

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

--- Comment #18 from Tom de Vries  ---
(In reply to Thomas Schwinge from comment #9)
> You could further optimize the script to omit "." locations: if the "dg-*"
> directive actually is placed on the appropriate line already.

I did this in a separate cleanup action, which I implemented using find and
sed.

Commited in r247363 "Remove superfluous ' . ' in
dg-(error|warning|message|bogus)".

[Bug fortran/80554] New: [f08] variable redefinition in submodule

[tamas.bela.feher at ipp dot mpg.de]

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

Bug ID: 80554
   Summary: [f08] variable redefinition in submodule
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tamas.bela.feher at ipp dot mpg.de
  Target Milestone: ---

Created attachment 41281
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41281=edit
submodule redefines a variable from the ancestor module

Dear GFortran team,

In the attached program, module M and its submodule S both define a
variable with the name i. This triggers an error message in GFortran 6.3.0 and
also in the latest version form SVN trunk.

The Intel Fortran compiler accepts the code, and the compiled code produces the
following output:
./a.out
 137

I think GFortran should also accept the code. As far as I know, entities from
the ancestor module are host associated, and we should be allowed to specify a
local entity in the submodule with the same name. Or is there any restriction
in the standard which forbids it?

Could you look into this problem? Thank you for your help.

Best regards,
Tamas


$ cat submod_var_scope.f90 
module M
  implicit none
  integer :: i = 0
  interface
module subroutine write_i()
end subroutine
  end interface
end module

submodule (M) S
  integer :: i = 137
  contains
module subroutine write_i()
   write (*,*) i
end subroutine
end submodule

program test_submod_variable
  use M
  implicit none
  i = 42
  call write_i
end program

$ gfortran-6 -v submod_var_scope.f90 
Driving: gfortran-6 -v submod_var_scope.f90 -l gfortran -l m -shared-libgcc
Using built-in specs.
COLLECT_GCC=gfortran-6
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/6.3.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-6.3.0/configure --program-suffix=-6
Thread model: posix
gcc version 6.3.0 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/local/libexec/gcc/x86_64-pc-linux-gnu/6.3.0/f951 submod_var_scope.f90
-quiet -dumpbase submod_var_scope.f90 -mtune=generic -march=x86-64 -auxbase
submod_var_scope -version -fintrinsic-modules-path
/usr/local/lib/gcc/x86_64-pc-linux-gnu/6.3.0/finclude -o /tmp/ccq0YC9g.s
GNU Fortran (GCC) version 6.3.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 6.3.0, GMP version 6.1.2, MPFR version 3.1.3,
MPC version 1.0.3, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran2008 (GCC) version 6.3.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 6.3.0, GMP version 6.1.2, MPFR version 3.1.3,
MPC version 1.0.3, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
submod_var_scope.f90:11:14:

   integer :: i = 137
  1
Error: Symbol ‘i’ at (1) already has basic type of INTEGER


$ gfortran-svn -v submod_var_scope.f90 
Driving: gfortran-svn -v submod_var_scope.f90 -l gfortran -l m -shared-libgcc
Using built-in specs.
COLLECT_GCC=gfortran-svn
COLLECT_LTO_WRAPPER=/opt/gcc-svn/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-svn-trunk/configure --prefix=/opt/gcc-svn
--program-suffix=-svn --enable-languages=c,fortran
Thread model: posix
gcc version 8.0.0 20170427 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /opt/gcc-svn/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/f951 submod_var_scope.f90
-quiet -dumpbase submod_var_scope.f90 -mtune=generic -march=x86-64 -auxbase
submod_var_scope -version -fintrinsic-modules-path
/opt/gcc-svn/lib/gcc/x86_64-pc-linux-gnu/8.0.0/finclude -o /tmp/ccRu9s2z.s
GNU Fortran (GCC) version 8.0.0 20170427 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 8.0.0 20170427 (experimental), GMP version
6.1.2, MPFR version 3.1.3, MPC version 1.0.3, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU Fortran2008 (GCC) version 8.0.0 20170427 (experimental)
(x86_64-pc-linux-gnu)
compiled by GNU C version 8.0.0 20170427 (experimental), GMP version
6.1.2, MPFR version 3.1.3, MPC version 1.0.3, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
submod_var_scope.f90:11:14:

   integer :: i = 137
  1
Error: Symbol ‘i’ at (1) already has basic type of INTEGER

[Bug testsuite/80551] c-c++-common/tsan/race_on_mutex.c fails on powerpc

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-04-28
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Good, I can help you with that. Can you please investigate why unwinding fails
to identify function name?

I guess softening the pattern scan can lead to catch basically every function
:/

[Bug middle-end/80548] -Wmaybe-uninitialized false positive when an assignment is added

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-04-28
 Ever confirmed|0   |1
  Known to fail||4.8.5, 5.4.1, 6.3.1, 7.0.1

--- Comment #1 from Richard Biener  ---
Confirmed (also with -O2).  Older compilers need -Wuninitialized to trigger it.

[WORKLIST]: add to initial list: x_22 = PHI 
[WORKLIST]: add to initial list: y_21 = PHI 
[CHECK]: examining phi: y_21 = PHI 
[CHECK]: Found unguarded use: y_18 = PHI 
[WORKLIST]: Update worklist with phi: y_18 = PHI 
[CHECK]: examining phi: y_18 = PHI 

[CHECK] Found def edge 1 in y_21 = PHI 

[CHECK] Found def edge 1 in y_18 = PHI 
[CHECK]: Found unguarded use: h (x_22, y_18);
[CHECK]: examining phi: x_22 = PHI 
[BEFORE SIMPLICATION -- [DEF]:

it's confused by the CFG structure it seems.

[Bug target/80547] [6/7/8 Regression] nvptx back end ICE with OpenACC "reduction(OP:x)", "x = [...]"

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |6.4

[Bug testsuite/80546] [7/8 Regression] FAIL: gcc.target/powerpc/bool3-p[78].c scan-assembler-not

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |7.2
Summary|[7 Regression] FAIL:|[7/8 Regression] FAIL:
   |gcc.target/powerpc/bool3-p[ |gcc.target/powerpc/bool3-p[
   |78].c scan-assembler-not|78].c scan-assembler-not

[Bug driver/80545] option -Wstringop-overflow not recognized by Fortran

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-04-28
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
I suggest to enable them only for C family languages (I notice the options
do not use EnabledBy()).

Supposedly the option machinery initializes warn_stringop_overflow to 2 even
when not in the set of options it is guarded with:

Wstringop-overflow=
C ObjC C++ ObjC++ Joined RejectNegative UInteger Var(warn_stringop_overflow)
Init(2) Warning
Under the control of Object Size type, warn about buffer overflow in string
manipulation functions like memcpy and strcpy.