[Bug rtl-optimization/84058] New: RTl partitioning fixup should drag very small blocks back to hot partition

[hubicka at gcc dot gnu.org]

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

Bug ID: 84058
   Summary: RTl partitioning fixup should drag very small blocks
back to hot partition
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org
  Target Milestone: ---

In LTO/FDO bootstrapped compiler we have cold functions like this:
0065b2e8 <_Z27is_gimple_invariant_addressPK9tree_node.cold.318>:
  65b2e8:   31 c0   xor%eax,%eax
  65b2ea:   c3  retq   
  65b2eb:   eb fb   jmp65b2e8
<_Z27is_gimple_invariant_addressPK9tree_node.cold.318>
  65b2ed:   eb f9   jmp65b2e8
<_Z27is_gimple_invariant_addressPK9tree_node.cold.318>
  65b2ef:   eb f7   jmp65b2e8
<_Z27is_gimple_invariant_addressPK9tree_node.cold.318>
  65b2f1:   eb f5   jmp65b2e8
<_Z27is_gimple_invariant_addressPK9tree_node.cold.318>
  65b2f3:   eb f3   jmp65b2e8
<_Z27is_gimple_invariant_addressPK9tree_node.cold.318>
  65b2f5:   eb f1   jmp65b2e8
<_Z27is_gimple_invariant_addressPK9tree_node.cold.318>
  65b2f7:   eb ef   jmp65b2e8
<_Z27is_gimple_invariant_addressPK9tree_node.cold.318>
  65b2f9:   eb ed   jmp65b2e8
<_Z27is_gimple_invariant_addressPK9tree_node.cold.318>

Obviously there is no good to offload empty BB into cold partition. We also
have couple cases consisting only of ret or one reg-reg move and jump/ret

I suppose this is because it was not empty at the partitioning time but then we
did not bring it back.  Doing so in bb-reorder is bit late, we should do at
least one sanitization pre regalloc, so I suppose partitioning fixup is good
place.

[Bug sanitizer/84043] -fsanitize=alignment leads to massive compile time

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-26
 Ever confirmed|0   |1

--- Comment #3 from Martin Liška  ---
Confirmed, I know that Jakub did some optimization connected to such operator
sanitizer hog?

[Bug tree-optimization/81082] [8 Regression] Failure to vectorise after reassociating index computation

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug middle-end/66313] Unsafe factorization of a*b+a*c

[rguenth at gcc dot gnu.org]

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

Bug 81082 Summary: [8 Regression] Failure to vectorise after reassociating 
index computation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81082

   What|Removed |Added

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

[Bug tree-optimization/81082] [8 Regression] Failure to vectorise after reassociating index computation

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener  ---
Author: rguenth
Date: Fri Jan 26 10:30:36 2018
New Revision: 257077

URL: https://gcc.gnu.org/viewcvs?rev=257077=gcc=rev
Log:
2018-01-26  Richard Biener  

PR tree-optimization/81082
* fold-const.c (fold_plusminus_mult_expr): Do not perform the
association if it requires casting to unsigned.
* match.pd ((A * C) +- (B * C) -> (A+-B)): New patterns derived
from fold_plusminus_mult_expr to catch important cases late when
range info is available.

* gcc.dg/vect/pr81082.c: New testcase.
* gcc.dg/tree-ssa/loop-15.c: XFAIL the (int)((unsigned)n + -1U) * n + n
simplification to n * n.

Added:
trunk/gcc/testsuite/gcc.dg/vect/pr81082.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/match.pd
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/loop-15.c

[Bug lto/83997] ICE with alias template and attribute

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
It is actually much worse than just some ICE with -flto.

template
using T = int __attribute__((vector_size (sizeof(int) * N)));

T<4> q;
template
int r __attribute__((vector_size (sizeof(int) * N)));
void *s = <4>;

T<4>
foo (T<4> a)
{
  return a + 1;
}

decltype (r<4>)
bar (decltype (r<4>) a)
{
  return a + 1;
}

shows that when using the T<4> we treat it as normal int, so sizeof (q) is
sizeof (int) and foo just adds to int argument 1 and returns that as int.
Compare that to the r case which is handled right.

[Bug libstdc++/84056] map insertes a pair when check a value

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #6 from Jonathan Wakely  ---
Not a bug, this is how std::map works.

[Bug libstdc++/84056] map insertes a pair when check a value

[glisse at gcc dot gnu.org]

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

--- Comment #4 from Marc Glisse  ---
(In reply to Alper Ce from comment #3)
> I didn't assign anything to my_map(i didn't use assignment operator = ), i
> just used == operator to check value of it.

Again, did you read the doc for operator[]? For instance
http://en.cppreference.com/w/cpp/container/map/operator_at

[Bug libstdc++/84056] map insertes a pair when check a value

[alper.ccc at yandex dot com]

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

--- Comment #5 from Alper Ce  ---
(In reply to Marc Glisse from comment #4)
> (In reply to Alper Ce from comment #3)
> > I didn't assign anything to my_map(i didn't use assignment operator = ), i
> > just used == operator to check value of it.
> 
> Again, did you read the doc for operator[]? For instance
> http://en.cppreference.com/w/cpp/container/map/operator_at

Sorry
You are right.

[Bug c++/83937] [7/8 Regression] C++17 binds braced init of a type T to default arg of a ctor instead of using T's own default ctor

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #6 from Marek Polacek  ---
struct S
{
S(int i = 42); // (1)
};

void f()
{
S( {} ); // (2)
}

So if I understand this right, (2) is a copy-list-initialization which is
supposed to initialize the constructor's parameter in (1), i.e. an integer to
0, as if we wrote int i = {} (copy-list-initialization), not the type S.  But
the latter is what's happening in C++17 and that is wrong.

[Bug fortran/77504] "is used uninitialized" with allocatable string and array constructors

[jb at gcc dot gnu.org]

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

Janne Blomqvist  changed:

   What|Removed |Added

 CC||jb at gcc dot gnu.org

--- Comment #7 from Janne Blomqvist  ---
I suppose another variant of this bug is:

module foo
contains
  subroutine bar(a)
implicit none
integer, dimension(:), intent(in) :: a
integer, dimension(:), allocatable :: c

c = a
  end subroutine bar
end module foo

❯ gfortran -c -Wall test.f90
test.f90:8:0:

 c = a

Warning: ‘c.offset’ is used uninitialized in this function [-Wuninitialized]
test.f90:8:0: Warning: ‘c.dim[0].lbound’ is used uninitialized in this function
[-Wuninitialized]
test.f90:8:0: Warning: ‘c.dim[0].ubound’ is used uninitialized in this function
[-Wuninitialized]
test.f90:8:0:

 c = a

Warning: ‘c.dim[0].lbound’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
test.f90:8:0: Warning: ‘c.dim[0].ubound’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
test.f90:8:0: Warning: ‘c.dim[0].ubound’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
test.f90:8:0: Warning: ‘c.dim[0].lbound’ may be used uninitialized in this
function [-Wmaybe-uninitialized]

[Bug libstdc++/83981] vector::resize(size_type) should not require T to be CopyInsertable when std=c++14

[redi at gcc dot gnu.org]

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

--- Comment #14 from Jonathan Wakely  ---
(In reply to Daniel Krügler from comment #11)
> (In reply to Jonathan Wakely from comment #10)
> > Perhaps Daniel can comment, since he wrote the resolution of lwg 2033.
> > 
> > Daniel, if the intent was that vector::resize(size_type) must only move,
> > even if that can throw, why is the exception-safety guarantee worded in
> > terms of a non-CopyInsertable condition? Was the intention really to forbid
> > implementations from giving the strong exception-safety guarantee (by
> > copying) if possible?
> 
> I'm in the mid of something else, so forgive me if I'm still catching up.
> The wording was slightly changed by LWG 2323 later on, does that clarify?

No, that doesn't change the part I'm asking about.

> [If not, I can look deeper into it tomorrow evening, so please let me know]
> The basic idea that the original wording tried to ensure is that strong
> exception-safety holds for non-throwing move-only types or copyable types,
> because that was the original intend suggested by Howard Hinnant.

Right, that was my understanding too. The current wording doesn't say that,
because (as Daniel T. explains) by only requiring MoveInsertable it seems to
forbid doing copy-insertion when the move might throw, and therefore providing
the strong guarantee by copying is forbidden.

(In reply to Daniel Trebbien from comment #12)
> https://wg21.link/lwg2158 looks relevant, particularly this part:
> 
> "This requirement is not sufficient if an implementation is free to select
> copy constructor when !is_nothrow_move_constructible::value &&
> is_copy_constructible::value evaluates to true. Unfortunately,
> is_copy_constructible cannot reliably determine whether T is really
> copy-constructible. A class may contain public non-deleted copy constructor
> whose definition does not exist or cannot be instantiated successfully
> (e.g., std::vector has copy constructor, but this type
> is not copy-constructible)."

Ah yes, that's *exactly* the problem. We need to be allowed to copy when that
would work, but in general we can't tell if copying will work because
is_copy_constructible doesn't always tell us the right answer.

(And also, is_copy_constructible isn't the right trait because the allocator
could inject different arguments in the construct call, but that's the separate
issue I mentioned in comment 10).

> Even though is_copy_constructible for std::vector> is
> true, resizing a vector of this element type works because the std::vector
> move constructor is noexcept, so the move constructor is selected.
> 
> Jonathan, I personally think that your argument in Comment 10 is persuasive.
> 
> Further, I like the suggestion in LWG 2158 to add "if
> !is_nothrow_move_constructible::value && is_copy_constructible::value
> then T shall be CopyInsertable into *this;" to the requirements of
> vector::resize(size_type). I think that this would be required because,
> based on my reading of [temp.inst], it is a well-formed program to
> instantiate boost::optional, as this does not
> require the instantiation of the boost::optional
> copy constructor.

Agreed. This would mean that it's the author of the std::vector value_type who
must be responsible for ensuring that the type really is copyable if the traits
cause std::vector to try and copy it (i.e. it is a boost::optional bug, for
having a noexcept(false) move constructor and a copy constructor that is always
declared but might be ill-formed when instantiated).

[Bug sanitizer/81929] [7/8 Regression] exponential slowdown in undefined behavior sanitizer for streaming

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||sduvan.gcc at gmail dot com

--- Comment #6 from Jakub Jelinek  ---
*** Bug 84043 has been marked as a duplicate of this bug. ***

[Bug sanitizer/84043] -fsanitize=alignment leads to massive compile time

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
   Last reconfirmed|2018-01-26 00:00:00 |
 Resolution|--- |DUPLICATE

--- Comment #4 from Jakub Jelinek  ---
Dup.

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

[Bug c++/84059] [8 Regression] ICE in ix86_get_function_versions_dispatcher, at config/i386/i386.c:32429

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Priority|P3  |P1
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org

--- Comment #1 from Martin Liška  ---
Let me fix that.

[Bug c++/84059] New: [8 Regression] ICE in ix86_get_function_versions_dispatcher, at config/i386/i386.c:32429

[marxin at gcc dot gnu.org]

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

Bug ID: 84059
   Summary: [8 Regression] ICE in
ix86_get_function_versions_dispatcher, at
config/i386/i386.c:32429
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

Starting from Nathan's commit r251316 we ICE on:

$ cat ice.ii
template < typename > struct a {
  int __attribute__((target("arch=ivybridge"))) c(int);
  int __attribute__((target("default"))) c(int);
};
void d() {
  a< double > b;
  b.c(2);
}

$ g++ ice.ii
ice.ii: In function ‘void d()’:
ice.ii:7:8: internal compiler error: in ix86_get_function_versions_dispatcher,
at config/i386/i386.c:32429
   b.c(2);
^
0x1131c53 ix86_get_function_versions_dispatcher
../../gcc/config/i386/i386.c:32429
0x60dd5d get_function_version_dispatcher(tree_node*)
../../gcc/cp/call.c:7479
0x6138e0 build_over_call
../../gcc/cp/call.c:8191
0x616858 build_new_method_call_1
../../gcc/cp/call.c:9274
0x616858 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
../../gcc/cp/call.c:9343
0x776467 cp_parser_postfix_expression
../../gcc/cp/parser.c:7207
0x776d3d cp_parser_unary_expression
../../gcc/cp/parser.c:8281
0x754939 cp_parser_cast_expression
../../gcc/cp/parser.c:9049
0x7551a7 cp_parser_binary_expression
../../gcc/cp/parser.c:9150
0x756b54 cp_parser_assignment_expression
../../gcc/cp/parser.c:9437
0x757338 cp_parser_expression
../../gcc/cp/parser.c:9606
0x7593b8 cp_parser_expression_statement
../../gcc/cp/parser.c:11075
0x75f5cf cp_parser_statement
../../gcc/cp/parser.c:10879
0x760e20 cp_parser_statement_seq_opt
../../gcc/cp/parser.c:11218
0x760ef7 cp_parser_compound_statement
../../gcc/cp/parser.c:11172
0x779c48 cp_parser_function_body
../../gcc/cp/parser.c:21710
0x779c48 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/cp/parser.c:21747
0x77a3e0 cp_parser_function_definition_after_declarator
../../gcc/cp/parser.c:26648
0x77b0be cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/cp/parser.c:26564
0x77b0be cp_parser_init_declarator
../../gcc/cp/parser.c:19436

[Bug fortran/84060] New: Wrong assignment from a class(*) variable which is a function result.

[vladimir.fuka at gmail dot com]

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

Bug ID: 84060
   Summary: Wrong assignment from a class(*) variable which is a
function result.
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vladimir.fuka at gmail dot com
  Target Milestone: ---

The following gives random garbage results:


select type (tmp => getValue())
  type is (integer)
print *, "tmp",tmp
int_var = tmp
end select

print *, int_var
contains

  function getValue() result(res)
class(*), allocatable :: res

res = 5
  end function

end


> gfortran-7 unlimfunction.f90
> ./a.out 
 tmp   5
   32682


That was an expression, but a variable does the same:

class(*), allocatable :: a

a = getValue()

select type (a)
  type is (integer)
print *, "tmp",a
int_var = a
end select

print *, int_var
contains

  function getValue() result(res)
class(*), allocatable :: res

res = 5
  end function

end


> gfortran-7 unlimfunction.f90 -
> ./a.out 
 tmp   5
   0


Changing assignments to sourced allocations changes nothing.

[Bug c++/83950] [8 regression] error: no matching function for call to ‘folly::dynamic::at(size_t&) const’

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #5 from Jakub Jelinek  ---
Invalid.

[Bug tree-optimization/84057] [8 Regression] ICE: Segmentation fault (in can_remove_branch_p)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||jakub at gcc dot gnu.org

[Bug tree-optimization/84061] New: [8 Regression] gcc.dg/tree-ssa/loop-15.c XFAIL

[rguenth at gcc dot gnu.org]

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

Bug ID: 84061
   Summary: [8 Regression] gcc.dg/tree-ssa/loop-15.c XFAIL
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: missed-optimization, xfail
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

After r257077 we fail to fold (int) ((unsigned int) n_5 + 4294967295) * n_5 +
n_5
to n_5 * n_5.  Before the rev. we managed to fold to (int)((unsigned)n_5 *
(unsigned)n_5) via fold_plusminus_mult_expr.

The rev. contains everything necessary to fold this during late VRP to n_5 *
n_5
but the substitute-and-fold engine doesn't fold all stmts.

The following fixes this regression:

Index: gcc/tree-ssa-propagate.c
===
--- gcc/tree-ssa-propagate.c(revision 257048)
+++ gcc/tree-ssa-propagate.c(working copy)
@@ -1056,13 +1056,17 @@ substitute_and_fold_dom_walker::before_d
   && gimple_call_noreturn_p (stmt));

   /* Replace real uses in the statement.  */
-  did_replace |= substitute_and_fold_engine->replace_uses_in (stmt);
+  if (substitute_and_fold_engine->replace_uses_in (stmt))
+   {
+ did_replace = true;
+ gimple_set_modified (stmt, true);
+   }

-  /* If we made a replacement, fold the statement.  */
-  if (did_replace)
+  /* Fold the statement.  */
+  if (fold_stmt (, follow_single_use_edges))
{
- fold_stmt (, follow_single_use_edges);
  stmt = gsi_stmt (i);
+ did_replace = true;
  gimple_set_modified (stmt, true);
}


queued for GCC 9.

[Bug target/81763] Issues with BMI on 32bit x86 apps on GCC 7.1+

[mike at fireburn dot co.uk]

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

--- Comment #42 from Mike Lothian  ---
With the patch in Comment 36 I get the following error compiling Clang

FAILED: lib/Lex/CMakeFiles/clangLex.dir/PPExpressions.cpp.o
/usr/bin/x86_64-pc-linux-gnu-g++ -m32 -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE
-D_LARGEFILE_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS
-D__STDC_LIMIT_MACROS -Ilib/Lex
-I/var/tmp/portage/sys-devel/clang-/work/x/y/clang-/lib/Lex
-I/var/tmp/portage/sys-devel/clang-/work/x/y/clang-/include -Iinclude
-I/usr/lib/llvm/7/include  -DNDEBUG -O2 -march=native -pipe
-mindirect-branch=thunk -mfunction-return=thunk -mindirect-branch-register
-fpermissive -fPIC -fvisibility-inlines-hidden -Werror=date-time -std=c++11
-Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual
-Wno-missing-field-initializers -Wdelete-non-virtual-dtor -Wno-comment
-ffunction-sections -fdata-sections -fno-common -Woverloaded-virtual
-fno-strict-aliasing -pedantic -Wno-long-long -fPIC -MD -MT
lib/Lex/CMakeFiles/clangLex.dir/PPExpressions.cpp.o -MF
lib/Lex/CMakeFiles/clangLex.dir/PPExpressions.cpp.o.d -o
lib/Lex/CMakeFiles/clangLex.dir/PPExpressions.cpp.o -c
/var/tmp/portage/sys-devel/clang-/work/x/y/clang-/lib/Lex/PPExpressions.cpp
/var/tmp/portage/sys-devel/clang-/work/x/y/clang-/lib/Lex/PPExpressions.cpp:
In function ‘bool EvaluateValue({anonymous}::PPValue&, clang::Token&,
DefinedTracker&, bool, clang::Preprocessor&)’:
/var/tmp/portage/sys-devel/clang-/work/x/y/clang-/lib/Lex/PPExpressions.cpp:492:1:
internal compiler error: in gen_split_178, at config/i386/i386.md:8623
 }
 ^

[Bug c++/81086] [8 Regression] ICE with structured binding of initializer_list

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Liška  ---
(In reply to ensadc from comment #2)
> Fixed by r255705 ?

I can confirm that.

[Bug target/81763] Issues with BMI on 32bit x86 apps on GCC 7.1+

[jakub at gcc dot gnu.org]

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

--- Comment #40 from Jakub Jelinek  ---
(In reply to Uroš Bizjak from comment #37)
> (In reply to Jakub Jelinek from comment #33)
> 
> > and it should work.  The last case would be right now:
> >   SI:N+1 = SI:N &~ SI:N+2; SI:N+2 = SI:N+1 &~ SI:N+3;
> > and is again wrong, but we could again swap:
> >   SI:N+2 = SI:N+1 &~ SI:N+3; SI:N+1 = SI:N &~ SI:N+2;
> > and all is fine.
> 
> Whoops, it looks that SI:N+2 is clobbered in the swapped case.

You're right.  So the question is if IRA/LRA can ever allow that case where
there is partial overlap with both registers.  I've tried hard to simulate that
case with:
unsigned long long
foo (unsigned long long x, unsigned long long y)
{
  unsigned long long z;
  asm ("" : "+A" (x), "+Q" (y));
  z = x & ~y;
  asm ("" : "+Q" (z) : "a" (0), "b" (0));
  return z;
}
where IRA indeed allocates the used pseudos such that x is in ax:dx, y in cx:bx
and z in dx:cx.  Now, if I try this and testcase with ~x & y instead of x & ~y
with GCC patched with #c36, I get:
andn%eax, %ecx, %ecx
xorl%eax, %eax
andn%edx, %ebx, %ebx
movl%ecx, %edx
movl%ebx, %ecx
movl%eax, %ebx
resp.
andn%ecx, %eax, %ecx
xorl%eax, %eax
andn%ebx, %edx, %ebx
movl%ecx, %edx
movl%ebx, %ecx
movl%eax, %ebx
between the two inline asms, and if I leave just the =r <- (r, r) alternative
and nothing else, LRA ICEs on it (on both variants).  All is with -O2 -m32
-mbmi -mstv -msse2.  So, is there something in LRA that prevents these partial
overlaps?

[Bug rtl-optimization/84058] RTl partitioning fixup should drag very small blocks back to hot partition

[hubicka at gcc dot gnu.org]

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

--- Comment #1 from Jan Hubicka  ---
0065ff3a :
  65ff3a:   b8 01 00 00 00  mov$0x1,%eax
  65ff3f:   c3  retq   
  65ff40:   b8 01 00 00 00  mov$0x1,%eax
  65ff45:   c3  retq   
  65ff46:   b8 01 00 00 00  mov$0x1,%eax
  65ff4b:   c3  retq   
  65ff4c:   b8 01 00 00 00  mov$0x1,%eax
  65ff51:   c3  retq   
  65ff52:   b8 01 00 00 00  mov$0x1,%eax
  65ff57:   c3  retq   

another cute example of this phenomena. Also missed tail merging.

[Bug target/81763] Issues with BMI on 32bit x86 apps on GCC 7.1+

[ubizjak at gmail dot com]

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

--- Comment #41 from Uroš Bizjak  ---
Let's go forward with this pattern:

(define_insn "*andndi3_doubleword"
  [(set (match_operand:DI 0 "register_operand" "=,r,r,")
(and:DI
  (not:DI (match_operand:DI 1 "register_operand" "r,0,r,0"))
  (match_operand:DI 2 "nonimmediate_operand" "rm,rm,0,rm")))
   (clobber (reg:CC FLAGS_REG))]
  "!TARGET_64BIT && TARGET_STV && TARGET_SSE2"
  "#"
  [(set_attr "isa" "bmi,bmi,bmi,*")])

(=,r,rm) alternative avoids matching of output to all other overlapped and
partial overlapped operands.

(=r,0,rm) alternative allows matching with op1, so we are sure output won't
*partially* overlap with op2. This is true for register and memory operands. It
can still fully overlap with register op2 in case the same reg is allocated for
op1, op2 and op3, which is OK for BMI.

(=r,r,0) alternative will prevent *partial* overlap of output with op1 in a
similar way.

(=,0,rm) is non-bmi alternative. Earlyclobber is needed, otherwise RA can
match op2 with op0 and op1, so the same reg is allocated for op0, op1 and op2.
If this is the case, after the split, NOT/AND sequence won't match ANDN
instruction, since NOT will change both input operands to a follow-up AND insn.

[Bug lto/84044] Spurious -Wodr warning with -flto

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-26
  Known to work||8.0
 Ever confirmed|0   |1

--- Comment #3 from Martin Liška  ---
Fixed on trunk by Richi's r256685. Is it intentional Richi that the revision
should fix such situations?

[Bug c++/84059] [8 Regression] ICE in ix86_get_function_versions_dispatcher, at config/i386/i386.c:32429

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-01-26
 CC||nathan at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug c++/81086] [8 Regression] ICE with structured binding of initializer_list

[ensadc at mailnesia dot com]

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

ensadc at mailnesia dot com changed:

   What|Removed |Added

 CC||ensadc at mailnesia dot com

--- Comment #2 from ensadc at mailnesia dot com ---
Fixed by r255705 ?

[Bug c++/84015] [7/8 Regression] ICE with class template argument deduction

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

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

commit b1363399fad470a536bd8731be39c3fbfe4e6fad
Author: jason 
Date:   Wed Nov 9 20:02:50 2016 +

Implement P0127R2, Declaring non-type parameters with auto.

gcc/cp/
* cp-tree.h (enum auto_deduction_context): Add adc_unify.
* decl.c (grokdeclarator): Allow 'auto' in C++17 template non-type
parameter types.
* pt.c (do_auto_deduction): Add outer_targs parameter.
(convert_template_argument): Call do_auto_deduction.  If adc_unify,
don't give up on dependent init.
(unify): Likewise.  In C++17, walk into the type of a
TEMPLATE_PARM_INDEX.
(for_each_template_parm): Add any_fn parameter.
(struct pair_fn_data): Likewise.
(for_each_template_parm_r): Call it for any tree.  In C++17, walk
into the type of a TEMPLATE_PARM_INDEX.
(zero_r, array_deduction_r, try_array_deduction): New.
(type_unification_real): Call try_array_deduction.
(get_partial_spec_bindings): Likewise.
gcc/c-family/
* c-cppbuiltin.c (c_cpp_builtins): Define __cpp_template_auto.

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

[Bug libstdc++/84056] map insertes a pair when check a value

[alper.ccc at yandex dot com]

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

--- Comment #3 from Alper Ce  ---
(In reply to Marc Glisse from comment #2)
> Where is the bug? Did you read the documentation for operator[]?

I didn't assign anything to my_map(i didn't use assignment operator = ), i just
used == operator to check value of it.

[Bug tree-optimization/84037] [8 Regression] Speed regression of polyhedron benchmark since r256644

[hubicka at gcc dot gnu.org]

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

--- Comment #8 from Jan Hubicka  ---
https://gcc.opensuse.org/gcc-old/c++bench-czerny/pb11/pb11-summary.txt-2-0.html
runs with  -Ofast -funroll-loops so indeed does not seem essential to trigger
the regression (it may be two different ones of course)

note that also tfft,aermod and tfft2 shows regression that may be easy to
track/fix.

[Bug rtl-optimization/83985] [8 Regression] Compile time hog for 32-bit BE powerpc targets

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
Author: jakub
Date: Fri Jan 26 11:48:05 2018
New Revision: 257087

URL: https://gcc.gnu.org/viewcvs?rev=257087=gcc=rev
Log:
PR rtl-optimization/83985
* dce.c (deletable_insn_p): Return false for separate shrink wrapping
REG_CFA_RESTORE insns.
(delete_unmarked_insns): Don't ignore separate shrink wrapping
REG_CFA_RESTORE insns here.

* gcc.dg/pr83985.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr83985.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dce.c
trunk/gcc/testsuite/ChangeLog

[Bug c/83989] [8 Regression] -Wrestrict false positive with malloc-style functions

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Fri Jan 26 11:47:11 2018
New Revision: 257086

URL: https://gcc.gnu.org/viewcvs?rev=257086=gcc=rev
Log:
PR c/83989
* gimple-ssa-warn-restrict.c (builtin_memref::builtin_memref): Don't
use SSA_NAME_VAR as base for SSA_NAMEs with non-NULL SSA_NAME_VAR.

* c-c++-common/Wrestrict-3.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/Wrestrict-3.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-warn-restrict.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/84045] [7/8 Regression] ICE when is_nothrow_default_constructible is used before #include

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.4
Summary|ICE when|[7/8 Regression] ICE when
   |is_nothrow_default_construc |is_nothrow_default_construc
   |tible is used before|tible is used before
   |#include   |#include

[Bug c++/84062] error: no matching function for call to 'std::vector::push_back()

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
This is not a bug. In C++11 the default member-initializer means that the type
is not an aggregate, so you cannot use aggregate-initialization to create it.
In C++14 aggregates are allowed to have default member-initializers, so you can
use aggregate-initialization syntax to create it.

i.e. this is valid in C++14 but not in C++11:

struct option_s
{
  int parameter = 1 ;
};

option_s o = { 1 };


So either you need to say option_s{1} or you need to compile as C++14.

If it works in Visual Studio that's because it doesn't conform to C++11, or you
are not using the right options to select C++11 conformance.

[Bug lto/84044] Spurious -Wodr warning with -flto

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
(In reply to Richard Biener from comment #4)
> (In reply to Martin Liška from comment #3)
> > Fixed on trunk by Richi's r256685. Is it intentional Richi that the revision
> > should fix such situations?
> 
> Not really.  It means that the following hunk removes too many TYPE_BINFOs
> I guess?
> 
> @@ -5150,15 +5145,9 @@ free_lang_data_in_type (tree type)
> {
>   free_lang_data_in_binfo (TYPE_BINFO (type));
>   /* We need to preserve link to bases and virtual table for all
> -polymorphic types to make devirtualization machinery working.
> -Debug output cares only about bases, but output also
> -virtual table pointers so merging of -fdevirtualize and
> --fno-devirtualize units is easier.  */
> - if ((!BINFO_VTABLE (TYPE_BINFO (type))
> -  || !flag_devirtualize)
> - && ((!BINFO_N_BASE_BINFOS (TYPE_BINFO (type))
> -  && !BINFO_VTABLE (TYPE_BINFO (type)))
> - || debug_info_level != DINFO_LEVEL_NONE))
> +polymorphic types to make devirtualization machinery working. 
> */
> + if (!BINFO_VTABLE (TYPE_BINFO (type))
> + || !flag_devirtualize)
> TYPE_BINFO (type) = NULL;
> }
>  }

Reverting this hunk makes the warning visible again.

[Bug lto/83997] ICE with alias template and attribute

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Seems nothing actually handles the late attributes in TYPE_ATTRIBUTES that
aren't {RECORD,UNION,CLASS,ENUMERAL}_TYPE.

Tried:
--- pt.c.jj52018-01-24 17:18:42.393392254 +0100
+++ pt.c2018-01-26 14:12:46.470745138 +0100
@@ -13662,18 +13662,43 @@ tsubst (tree t, tree args, tsubst_flags_
 case ERROR_MARK:
 case IDENTIFIER_NODE:
 case VOID_TYPE:
+case LANG_TYPE:
+  return t;
+
 case REAL_TYPE:
 case COMPLEX_TYPE:
 case VECTOR_TYPE:
 case BOOLEAN_TYPE:
 case NULLPTR_TYPE:
-case LANG_TYPE:
+  if (TYPE_ATTRIBUTES (t))
+   {
+ tree orig_t = t;
+ tree attributes = TYPE_ATTRIBUTES (t);
+ TYPE_ATTRIBUTES (t) = NULL_TREE;
+ apply_late_template_attributes (, attributes, 0,
+ args, complain, NULL_TREE);
+ if (t != orig_t)
+   TYPE_ATTRIBUTES (orig_t) = attributes;
+ fixup_attribute_variants (t);
+   }
   return t;

 case INTEGER_TYPE:
   if (t == integer_type_node)
return t;

+  if (TYPE_ATTRIBUTES (t))
+   {
+ tree orig_t = t;
+ tree attributes = TYPE_ATTRIBUTES (t);
+ TYPE_ATTRIBUTES (t) = NULL_TREE;
+ apply_late_template_attributes (, attributes, 0,
+ args, complain, NULL_TREE);
+ if (t != orig_t)
+   TYPE_ATTRIBUTES (orig_t) = attributes;
+ fixup_attribute_variants (t);
+   }
+
   if (TREE_CODE (TYPE_MIN_VALUE (t)) == INTEGER_CST
   && TREE_CODE (TYPE_MAX_VALUE (t)) == INTEGER_CST)
 return t;
but even that is already ugly hack, but would need to deal with t becoming
something else after the apply_late_template_attributes call (VECTOR_TYPE in
this case).

[Bug c/84063] New: Misleading diagnostic for ignored attributes under -Wattributes

[rimvydas.jas at gmail dot com]

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

Bug ID: 84063
   Summary: Misleading diagnostic for ignored attributes under
-Wattributes
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rimvydas.jas at gmail dot com
  Target Milestone: ---

Created attachment 43253
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43253=edit
testcase

Wouldn't -Wignored-attributes be better for this test case?

gcc80 -c test_packed_aligned.c
test_packed_aligned.c:42:16: warning: ignoring attribute 'aligned' because it
conflicts with attribute 'packed' [-Wattributes]
 struct usb_device_request req_reset_tt
__attribute__((__aligned__(4)));

[Bug target/84064] New: ICE in ix86_expand_prologue related to -fstack-clash-protection and memcpy on i686

[fw at gcc dot gnu.org]

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

Bug ID: 84064
   Summary: ICE in ix86_expand_prologue related to
-fstack-clash-protection and memcpy on i686
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: law at redhat dot com
  Reporter: fw at gcc dot gnu.org
  Target Milestone: ---
Target: i686

Compile this with -O2 -m32 -march=i686 -fstack-clash-protection:

void
f (void *p1, void *p2)
{
  __builtin_memcpy (p1, p2, 1000);
}

The failing assertion is:

  /* We expect the GP registers to be saved when probes are used
 as the probing sequences might need a scratch register and
 the routine to allocate one assumes the integer registers
 have already been saved.  */
  gcc_assert (int_registers_saved);

Seen with trunk@257087.

[Bug middle-end/82878] [7 Regression] ICE in assign_temp, at function.c:968 when using optimization

[nathan at gcc dot gnu.org]

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

--- Comment #10 from Nathan Sidwell  ---
Author: nathan
Date: Fri Jan 26 13:48:37 2018
New Revision: 257089

URL: https://gcc.gnu.org/viewcvs?rev=257089=gcc=rev
Log:
[C++/82878] backport fix

https://gcc.gnu.org/ml/gcc-patches/2018-01/msg02170.html
PR c++/82878
PR c++/78495
* call.c (build_call_a): Don't set CALL_FROM_THUNK_P for inherited
ctor.
* cp-gimplify.c (cp_genericize_r): Restore THUNK dereference
inhibibition check removed in previous c++/78495 change.

PR c++/82878
* g++.dg/cpp0x/pr82878.C: New.
* g++.dg/cpp1z/inh-ctor38.C: Check moves too.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/cpp0x/pr82878.C
Modified:
branches/gcc-7-branch/gcc/cp/ChangeLog
branches/gcc-7-branch/gcc/cp/call.c
branches/gcc-7-branch/gcc/cp/cp-gimplify.c
branches/gcc-7-branch/gcc/cp/lambda.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/testsuite/g++.dg/cpp1z/inh-ctor38.C

[Bug c++/78495] [7 regression][new inheriting ctors] invisible-ref parm has address taken

[nathan at gcc dot gnu.org]

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

--- Comment #6 from Nathan Sidwell  ---
Author: nathan
Date: Fri Jan 26 13:48:37 2018
New Revision: 257089

URL: https://gcc.gnu.org/viewcvs?rev=257089=gcc=rev
Log:
[C++/82878] backport fix

https://gcc.gnu.org/ml/gcc-patches/2018-01/msg02170.html
PR c++/82878
PR c++/78495
* call.c (build_call_a): Don't set CALL_FROM_THUNK_P for inherited
ctor.
* cp-gimplify.c (cp_genericize_r): Restore THUNK dereference
inhibibition check removed in previous c++/78495 change.

PR c++/82878
* g++.dg/cpp0x/pr82878.C: New.
* g++.dg/cpp1z/inh-ctor38.C: Check moves too.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/cpp0x/pr82878.C
Modified:
branches/gcc-7-branch/gcc/cp/ChangeLog
branches/gcc-7-branch/gcc/cp/call.c
branches/gcc-7-branch/gcc/cp/cp-gimplify.c
branches/gcc-7-branch/gcc/cp/lambda.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/testsuite/g++.dg/cpp1z/inh-ctor38.C

[Bug lto/84044] Spurious -Wodr warning with -flto

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
(In reply to Martin Liška from comment #3)
> Fixed on trunk by Richi's r256685. Is it intentional Richi that the revision
> should fix such situations?

Not really.  It means that the following hunk removes too many TYPE_BINFOs
I guess?

@@ -5150,15 +5145,9 @@ free_lang_data_in_type (tree type)
{
  free_lang_data_in_binfo (TYPE_BINFO (type));
  /* We need to preserve link to bases and virtual table for all
-polymorphic types to make devirtualization machinery working.
-Debug output cares only about bases, but output also
-virtual table pointers so merging of -fdevirtualize and
--fno-devirtualize units is easier.  */
- if ((!BINFO_VTABLE (TYPE_BINFO (type))
-  || !flag_devirtualize)
- && ((!BINFO_N_BASE_BINFOS (TYPE_BINFO (type))
-  && !BINFO_VTABLE (TYPE_BINFO (type)))
- || debug_info_level != DINFO_LEVEL_NONE))
+polymorphic types to make devirtualization machinery working.  */
+ if (!BINFO_VTABLE (TYPE_BINFO (type))
+ || !flag_devirtualize)
TYPE_BINFO (type) = NULL;
}
 }

Or this change drops required information for the ODR warning.

@@ -5186,6 +5175,11 @@ free_lang_data_in_type (tree type)
   while (ctx && TREE_CODE (ctx) == BLOCK);
   TYPE_CONTEXT (type) = ctx;
 }
+
+  /* Drop TYPE_DECLs in TYPE_NAME in favor of the identifier in the
+ TYPE_DECL if the type doesn't have linkage.  */
+  if (! type_with_linkage_p (type))
+TYPE_NAME (type) = TYPE_IDENTIFIER (type);
 }


Maybe you can "bisect" that.

But I guess the warning is "correct" and -fno-semantic-interposition
affects details in the vtable that lead to the warning.

Honza?

[Bug middle-end/84048] [8 Regression] FAIL: gcc.dg/torture/tls/run-ld.c -O0 -pie -fPIE execution test

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug tree-optimization/84047] [6/7/8 Regression] missing -Warray-bounds on an out-of-bounds index into an array

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.5

[Bug gcov-profile/82614] GCOV crashes while parsing gcda file

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/83055] [8 Regression] ICE in operator>, at profile-count.h:834

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #9 from Martin Liška  ---
Then fixed.

[Bug fortran/84065] New: [8 regression] string_1.f90 fails since r256944

[clyon at gcc dot gnu.org]

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

Bug ID: 84065
   Summary: [8 regression] string_1.f90 fails since r256944
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

Hi,

I've noticed failures on arm*linux* cross-compilers in:
gfortran.dg/string_1.f90   -O   (test for errors, line 10)
gfortran.dg/string_1.f90   -O   (test for errors, line 7)
gfortran.dg/string_1.f90   -O   (test for errors, line 8)
gfortran.dg/string_1.f90   -O   (test for errors, line 9)
gfortran.dg/string_1.f90   -O  (test for excess errors)

It appeared between r256941 and r256970, and I bisected this to r256944.

The logs say:
spawn -ignore SIGHUP
/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-linux-gnueabihf/gcc3/gcc/testsuite/gfortran4/../../gfortran
-B/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-linux-gnueabihf/gcc3/gcc/testsuite/gfortran4/../../
-B/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-linux-gnueabihf/gcc3/arm-none-linux-gnueabihf/./libgfortran/
/gcc/testsuite/gfortran.dg/string_1.f90 -fno-diagnostics-show-caret
-fdiagnostics-color=never -O -pedantic-errors -S -o string_1.s

f951: out of memory allocating 17179869204 bytes after a total of 569344 bytes
compiler exited with status 1
FAIL: gfortran.dg/string_1.f90   -O   (test for errors, line 7)
FAIL: gfortran.dg/string_1.f90   -O   (test for errors, line 8)
FAIL: gfortran.dg/string_1.f90   -O   (test for errors, line 9)
FAIL: gfortran.dg/string_1.f90   -O   (test for errors, line 10)
FAIL: gfortran.dg/string_1.f90   -O  (test for excess errors)


According to gcc-testresults, this happens on other targets too.

In my case, I'm building a cross-compiler on x86_64, target
arm-none-linux-gnueabihf (cpu/fpu/mode settings do not matter)

[Bug libstdc++/81122] [DR 2381] parsing f stopped after '0' when reading std::hexfloat >> f;

[woodard at redhat dot com]

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

--- Comment #4 from Ben Woodard  ---
Without this Is there a way to read and write floats and doubles accurately
without the rounding that converting to/from base 10 ends up introducing? How
are you supposed to use istreams like

printf(“%a”,dbl);
scanf(“%f, );

Note that scanf does handle doubles in whatever form they come in.
Further note that according to stackexchange this works on llvm and other
libstdc++ implementations. Therefore if the standard is unclear in this area
maybe it is a topic to be clarified.

[Bug middle-end/84040] [8 regression] compilation time of gcc.c-torture/compile/limits-blockid.c is 50x slower

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||compile-time-hog
   Priority|P3  |P1
   Target Milestone|--- |8.0

[Bug target/81763] Issues with BMI on 32bit x86 apps on GCC 7.1+

[jakub at gcc dot gnu.org]

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

--- Comment #43 from Jakub Jelinek  ---
(In reply to Uroš Bizjak from comment #41)
> Let's go forward with this pattern:
> 
> (define_insn "*andndi3_doubleword"
>   [(set (match_operand:DI 0 "register_operand" "=,r,r,")
>   (and:DI
> (not:DI (match_operand:DI 1 "register_operand" "r,0,r,0"))
> (match_operand:DI 2 "nonimmediate_operand" "rm,rm,0,rm")))
>(clobber (reg:CC FLAGS_REG))]
>   "!TARGET_64BIT && TARGET_STV && TARGET_SSE2"
>   "#"
>   [(set_attr "isa" "bmi,bmi,bmi,*")])

This looks reasonable to me.

(In reply to Mike Lothian from comment #42)
> With the patch in Comment 36 I get the following error compiling Clang

Just out of interest, could you attach the preprocessed source here, I'd like
to see the case when the RA assigns such a partial overlap.  As you're using
-march=native, will need g++ output with -v added to the command too (what
flags it expands to).

[Bug tree-optimization/84050] [6/7/8 Regression] missing -Warray-bounds accessing a struct array member

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.5

[Bug testsuite/84049] libgomp.c++/for-[56].C and libgomp.c/for-[56].c take a long time to run

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-26
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
I've seen this as well (with 64 cores/threads).  Can we limit OMP_NUM_THREADS
to at most 4 for example?

[Bug lto/84044] Spurious -Wodr warning with -flto

[hubicka at ucw dot cz]

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

--- Comment #6 from Jan Hubicka  ---
> > @@ -5150,15 +5145,9 @@ free_lang_data_in_type (tree type)
> > {
> >   free_lang_data_in_binfo (TYPE_BINFO (type));
> >   /* We need to preserve link to bases and virtual table for all
> > -polymorphic types to make devirtualization machinery working.
> > -Debug output cares only about bases, but output also
> > -virtual table pointers so merging of -fdevirtualize and
> > --fno-devirtualize units is easier.  */
> > - if ((!BINFO_VTABLE (TYPE_BINFO (type))
> > -  || !flag_devirtualize)
> > - && ((!BINFO_N_BASE_BINFOS (TYPE_BINFO (type))
> > -  && !BINFO_VTABLE (TYPE_BINFO (type)))
> > - || debug_info_level != DINFO_LEVEL_NONE))
> > +polymorphic types to make devirtualization machinery working. 
> > */
> > + if (!BINFO_VTABLE (TYPE_BINFO (type))
> > + || !flag_devirtualize)
> > TYPE_BINFO (type) = NULL;
> > }
> >  }
> 
> Reverting this hunk makes the warning visible again.

Hmm, I will take a look. BIFOs are bit of a magic.

Thanks!
Honza

[Bug target/84064] ICE in ix86_expand_prologue related to -fstack-clash-protection and memcpy on i686

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
In:
11787 if ((!to_allocate && frame->nregs <= 1)
11788 || (TARGET_64BIT && to_allocate >= HOST_WIDE_INT_C (0x8000))
11789 /* If stack clash probing needs a loop, then it needs a
11790scratch register.  But the returned register is only
guaranteed
11791to be safe to use after register saves are complete.  So if
11792stack clash protections are enabled and the allocated frame is
11793larger than the probe interval, then use pushes to save
11794callee saved registers.  */
11795 || (flag_stack_clash_protection && to_allocate >
get_probe_interval ()))
11796   frame->save_regs_using_mov = false;

to_allocate is 0, so we don't set frame->save_regs_using_mov, frame->nregs is
4, so int_regs_saved is initially false, frame_pointer_needed is also false,
and we aren't using red zone either, so nothing sets int_regs_saved afterwards.
But allocate is 16 for those 4 pushes we want to do.
I fail to see what we need to do though, if allocate is equal to the register
save area, then we don't need any probes, those pushes are themselves a probe.

[Bug c++/84062] New: error: no matching function for call to 'std::vector::push_back()

[daffra.claudio at gmail dot com]

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

Bug ID: 84062
   Summary: error: no matching function for call to
'std::vector::push_back()
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daffra.claudio at gmail dot com
  Target Milestone: ---

Created attachment 43251
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43251=edit
source code where error7bug  is generated

as you see in example below, g++ -std=c++11 fails compiler code,
when i assign a default value to a parameter in a struct definition
( i've tested with visual studio 2017 and all works good)
issue has generated in standard vectoru push back member
because it can not recognize struct correclty

g++ -v

Using built-in specs.
COLLECT_GCC=g++
   
COLLECT_LTO_WRAPPER=C:/TDM-GCC-64/bin/../libexec/gcc/x86_64-w64-mingw32/5.1.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../../../src/gcc-5.1.0/configure
--build=x86_64-w64-mingw32 --enable-targets=all
--enable-languages=ada,c,c++,fortran,lto,objc,obj-c++ --enable-libgomp
--enable-lto --enable-graphite --enable-cxx-flags=-DWINPTHREAD_STATIC
--disable-build-with-cxx --disable-build-poststage1-with-cxx
--enable-libstdcxx-debug --enable-threads=posix
--enable-version-specific-runtime-libs --enable-fully-dynamic-string
--enable-libstdcxx-threads --enable-libstdcxx-time --with-gnu-ld
--disable-werror --disable-nls --disable-win32-registry --prefix=/mingw64tdm
--with-local-prefix=/mingw64tdm --with-pkgversion=tdm64-1
--with-bugurl=http://tdm-gcc.tdragon.net/bugs
Thread model: posix
gcc version 5.1.0 (tdm64-1) 

source code 

#include 
#include 
#include 
#include 


typedef struct option_s
{
int8_t  parameter  ;   // <-- Works !
// int8_t   parameter = 1 ; <--
ERROR : if i put default parameter, gcc gives me error in : vOption.push_back (
{ 1 }  ) ;  
} option_t ;


class Option
{
public:
std::vector   vOption ;


Option(void) 
{ 
} ;

void add  ( void )
{

vOption.push_back ( { 1 }  ) ;
}


} zzz ;


int main ( void )
{
return 0 ;
}


Error Message

prova.cpp: In member function 'void Option::add()':
prova.cpp:29:32: error: no matching function for call to
'std::vector::push_back()'
 vOption.push_back ( { 1 }  ) ;
^
In file included from
C:/TDM-GCC-64/lib/gcc/x86_64-w64-mingw32/5.1.0/include/c++/vector:64:0,
 from prova.cpp:5:
   
C:/TDM-GCC-64/lib/gcc/x86_64-w64-mingw32/5.1.0/include/c++/bits/stl_vector.h:913:7:
note: candidate: void std::vector<_Tp, _Alloc>::push_back(const value_type&)
[with _Tp = option_s; _Alloc = std::allocator; std::vector<_Tp,
_Alloc>::value_type = option_s]
   push_back(const value_type& __x)
   ^
   
C:/TDM-GCC-64/lib/gcc/x86_64-w64-mingw32/5.1.0/include/c++/bits/stl_vector.h:913:7:
note:   no known conversion for argument 1 from '' to 'const value_type& {aka const option_s&}'
   
C:/TDM-GCC-64/lib/gcc/x86_64-w64-mingw32/5.1.0/include/c++/bits/stl_vector.h:931:7:
note: candidate: void std::vector<_Tp, _Alloc>::push_back(std::vector<_Tp,
_Alloc>::value_type&&) [with _Tp = option_s; _Alloc = std::allocator;
std::vector<_Tp, _Alloc>::value_type = option_s]
   push_back(value_type&& __x)
   ^
   
C:/TDM-GCC-64/lib/gcc/x86_64-w64-mingw32/5.1.0/include/c++/bits/stl_vector.h:931:7:
note:   no known conversion for argument 1 from '' to 'std::vector::value_type&& {aka option_s&&}'

[Bug rtl-optimization/83985] [8 Regression] Compile time hog for 32-bit BE powerpc targets

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
Author: jakub
Date: Fri Jan 26 12:24:53 2018
New Revision: 257088

URL: https://gcc.gnu.org/viewcvs?rev=257088=gcc=rev
Log:
PR rtl-optimization/83985
* dce.c (deletable_insn_p): Return false for separate shrink wrapping
REG_CFA_RESTORE insns.
(delete_unmarked_insns): Don't ignore separate shrink wrapping
REG_CFA_RESTORE insns here.

* gcc.dg/pr83985.c: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.dg/pr83985.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/dce.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/84053] [6/7/8 Regression] missing -Warray-bounds accessing a struct array member

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.5
Summary|[5//6/7 Regression] missing |[6/7/8 Regression] missing
   |-Warray-bounds accessing a  |-Warray-bounds accessing a
   |struct array member |struct array member

[Bug tree-optimization/84057] [8 Regression] ICE: Segmentation fault (in can_remove_branch_p)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P4  |P2
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #2 from Richard Biener  ---
A latent issue somewhere I would guess.

Program received signal SIGSEGV, Segmentation fault.
0x009eba5e in can_remove_branch_p (e=0x76a04a80)
at /space/rguenther/src/svn/early-lto-debug/gcc/cfghooks.c:389
389   if (EDGE_COUNT (e->src->succs) != 2)
(gdb) p e
$1 = (const_edge) 0x76a04a80
(gdb) p e->src
$2 = 

ok, so we end up queueing a lot of edges in edges_to_remove and then end up
removing a path disconnecting a CFG region that another edge to be removed
is queued in.

Before the rev. this all just happened in a different order which was fine.
I've patched this logic in the unroller quite some times already for similar
issues...

[Bug c/84054] seems -fno-bounds-checking no longer supported

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Firstly, GCC 4.8.1 has not been supported here for several years, and secondly
the option is clearly documented as not doing anything for C.


https://gcc.gnu.org/onlinedocs/gcc-4.8.1/gcc/Code-Gen-Options.html

-fbounds-check
For front ends that support it, generate additional code to check that
indices used to access arrays are within the declared range. This is
currently only supported by the Java and Fortran front ends, where this
option defaults to true and false respectively.



https://gcc.gnu.org/onlinedocs/gcc-3.4.5/gcc/Code-Gen-Options.html

-fbounds-check
For front-ends that support it, generate additional code to check that
indices used to access arrays are within the declared range. This is
currently only supported by the Java and Fortran 77 front-ends, where
this option defaults to true and false respectively.

[Bug lto/84044] Spurious -Wodr warning with -flto

[rguenther at suse dot de]

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

--- Comment #7 from rguenther at suse dot de  ---
On Fri, 26 Jan 2018, marxin at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84044
> 
> --- Comment #5 from Martin Liška  ---
> (In reply to Richard Biener from comment #4)
> > (In reply to Martin Liška from comment #3)
> > > Fixed on trunk by Richi's r256685. Is it intentional Richi that the 
> > > revision
> > > should fix such situations?
> > 
> > Not really.  It means that the following hunk removes too many TYPE_BINFOs
> > I guess?
> > 
> > @@ -5150,15 +5145,9 @@ free_lang_data_in_type (tree type)
> > {
> >   free_lang_data_in_binfo (TYPE_BINFO (type));
> >   /* We need to preserve link to bases and virtual table for all
> > -polymorphic types to make devirtualization machinery working.
> > -Debug output cares only about bases, but output also
> > -virtual table pointers so merging of -fdevirtualize and
> > --fno-devirtualize units is easier.  */
> > - if ((!BINFO_VTABLE (TYPE_BINFO (type))
> > -  || !flag_devirtualize)
> > - && ((!BINFO_N_BASE_BINFOS (TYPE_BINFO (type))
> > -  && !BINFO_VTABLE (TYPE_BINFO (type)))
> > - || debug_info_level != DINFO_LEVEL_NONE))
> > +polymorphic types to make devirtualization machinery working. 
> > */
> > + if (!BINFO_VTABLE (TYPE_BINFO (type))
> > + || !flag_devirtualize)
> > TYPE_BINFO (type) = NULL;
> > }
> >  }
> 
> Reverting this hunk makes the warning visible again.

Interesting.  This means that with -g it didn't warn before either?
Which means that maybe unconditionally

  && !BINFO_N_BASE_BINFOS (TYPE_BINFO (type))

was intented?  Honza?

[Bug c/84054] seems -fno-bounds-checking no longer supported

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
Huh.  C code never (no longer?) supports something like "bounds checking". 
There's a no-op option called -fbounds-check which only has an effect for
Fortran and Java.

It looks like the GCC 3.4 driver accepts random unknown options (ignoring
them), including -fbounds-checkignsakfdhi and the supported option
was -fbounds-check in the first place.  -fbounds-checking never existed.

[Bug lto/83997] ICE with alias template and attribute

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
With
--- pt.c.jj 2018-01-24 17:18:42.393392254 +0100
+++ pt.c2018-01-26 14:21:07.285737403 +0100
@@ -13662,18 +13662,45 @@ tsubst (tree t, tree args, tsubst_flags_
 case ERROR_MARK:
 case IDENTIFIER_NODE:
 case VOID_TYPE:
+case LANG_TYPE:
+  return t;
+
 case REAL_TYPE:
 case COMPLEX_TYPE:
 case VECTOR_TYPE:
 case BOOLEAN_TYPE:
 case NULLPTR_TYPE:
-case LANG_TYPE:
+  if (TYPE_ATTRIBUTES (t))
+   {
+ tree orig_t = t;
+ tree attributes = TYPE_ATTRIBUTES (t);
+ TYPE_ATTRIBUTES (t) = NULL_TREE;
+ apply_late_template_attributes (, attributes, 0,
+ args, complain, NULL_TREE);
+ if (t != orig_t)
+   TYPE_ATTRIBUTES (orig_t) = attributes;
+ fixup_attribute_variants (t);
+   }
   return t;

 case INTEGER_TYPE:
   if (t == integer_type_node)
return t;

+  if (TYPE_ATTRIBUTES (t))
+   {
+ tree orig_t = t;
+ tree attributes = TYPE_ATTRIBUTES (t);
+ TYPE_ATTRIBUTES (t) = NULL_TREE;
+ apply_late_template_attributes (, attributes, 0,
+ args, complain, NULL_TREE);
+ if (t != orig_t)
+   TYPE_ATTRIBUTES (orig_t) = attributes;
+ fixup_attribute_variants (t);
+ if (TREE_CODE (t) != INTEGER_TYPE)
+   return t;
+   }
+
   if (TREE_CODE (TYPE_MIN_VALUE (t)) == INTEGER_CST
   && TREE_CODE (TYPE_MAX_VALUE (t)) == INTEGER_CST)
 return t;

we don't ICE during tsubst anymore and actually get what I expect at least for
variable sizes and foo/bar/baz function code on:
template
using T = int __attribute__((vector_size (sizeof(int) * N)));

template
struct S
{
  typedef int type __attribute__((vector_size (sizeof(int) * N)));
};

T<4> q;
template
int r __attribute__((vector_size (sizeof(int) * N)));
void *s = <4>;
S<4>::type t;

T<4>
foo (T<4> a)
{
  return a + 1;
}

decltype (r<4>)
bar (decltype (r<4>) a)
{
  return a + 1;
}

S<4>::type
baz (S<4>::type a)
{
  return a + 1;
}

but with -flto we still ICE.  I'm afraid I must give up.

[Bug c++/83990] [7/8 Regression] Spurious "potential null pointer dereference" warning regression from 7.1 onwards

[jamborm at gcc dot gnu.org]

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

--- Comment #12 from Martin Jambor  ---
Created attachment 43254
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43254=edit
Lost location fix

I'm testing this patch which does what Jakub suggested in comment #4.  With the
patch, -fno-ipa-sra has no effect on either the original testcase or the
reduced one from comment 10.

[Bug testsuite/84049] libgomp.c++/for-[56].C and libgomp.c/for-[56].c take a long time to run

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
What's expensive on for-6.C?
#pragma omp parallel for with 10 iterations each, doing #pragma omp atomic in
there.
For capping the number of threads, you can always just export
OMP_NUM_THREADS=32
or something similar when running make check.
Perhaps the libgomp make check could have some upper bound like that by
default, check how many threads are available and if it is more than certain
count, add OMP_NUM_THREADS=something into the environment, but certainly there
needs to be a way to override it.
Limiting OMP_NUM_THREADS to 4 by default is way too low though.

[Bug libstdc++/81122] [DR 2381] parsing f stopped after '0' when reading std::hexfloat >> f;

[woodard at redhat dot com]

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

--- Comment #5 from Ben Woodard  ---
The example code in: http://en.cppreference.com/w/cpp/io/manip/fixed
suggests that this should work. Probably either the behavior or the library or
the example on cppreference should change.

[Bug libstdc++/81122] [DR 2381] parsing f stopped after '0' when reading std::hexfloat >> f;

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
(In reply to Ben Woodard from comment #5)
> The example code in: http://en.cppreference.com/w/cpp/io/manip/fixed
> suggests that this should work. Probably either the behavior or the library
> or the example on cppreference should change.

The standard does not permit the example to read the hex float, because 'P' is
not one of the characters that std::num_get::do_get will accumulate.
Implementations which parse that hex float are non-conforming.

Again, see comment 1.

[Bug libstdc++/81122] [DR 2381] parsing f stopped after '0' when reading std::hexfloat >> f;

[woodard at redhat dot com]

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

--- Comment #10 from Ben Woodard  ---
Also note: https://connect.microsoft.com/VisualStudio/feedback/details/742775

My reading of:
https://wg21.link/lwg2381

is that if the first part of the number includes a '.' then the portion after
the 'p' or 'P' is not part of the number and is left in the string. The example
is 
0x1a.bp+07p

So I believe that your assertion that 2381 applies in this situation is not
accurate. This example refers to the number: 26.6875 (16+10+11/16) and because
there is already a hexadecimal point '.' separating the integral portion from
the fractional portion the 'p' is not part of the number.

However, if the number was: "0x1abp+07p" (note the absence of the '.') then the
number would be: in the normal hexfloat format and refer to 1752839.0 leaving
the trailing 'p' in the stream.

[Bug middle-end/84048] [8 Regression] FAIL: gcc.dg/torture/tls/run-ld.c -O0 -pie -fPIE execution test

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||jakub at gcc dot gnu.org

[Bug rtl-optimization/84003] FAIL: g++.dg/torture/pr77745.C with noinline foo

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Fri Jan 26 14:50:25 2018
New Revision: 257091

URL: https://gcc.gnu.org/viewcvs?rev=257091=gcc=rev
Log:
2018-01-26  Richard Biener  

PR rtl-optimization/84003
* dse.c (record_store): Only record redundant stores when
the earlier store aliases at least all accesses the later one does.

* g++.dg/torture/pr77745.C: Mark foo noinline to trigger
latent bug in DSE if NOINLINE is appropriately defined.
* g++.dg/torture/pr77745-2.C: New testcase including pr77745.C
and defining NOINLINE.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr77745-2.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dse.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/torture/pr77745.C

[Bug rtl-optimization/84003] FAIL: g++.dg/torture/pr77745.C with noinline foo

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||8.0
  Known to fail||7.3.0

--- Comment #6 from Richard Biener  ---
Fixed on trunk sofar.  I'm considering a backport to GCC 7.

[Bug target/83008] [performance] Is it better to avoid extra instructions in data passing between loops?

[sergey.shalnov at intel dot com]

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

--- Comment #31 from sergey.shalnov at intel dot com ---
Richard,
Thank you for your latest patch. This patch is exactly that 
I’ve discussed in this issue request.
I tested it with SPEC20[06|17] and see no performance/stability degradation.

Could you please merge your latest patch into main trunk?

I will provide Intel specific changes (in gcc/config/i386) that 
will leverage your patch to get the performance better 
for the provided testcase (step N2)

Thank you
Sergey

[Bug bootstrap/80867] gnat bootstrap broken on powerpc64le-linux-gnu with -O3

[kelvin at gcc dot gnu.org]

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

--- Comment #9 from kelvin at gcc dot gnu.org ---
I've been investigating this and have identified the origin of the problem.

The ICE occurs because tree-vect-stmts.c: vectorizable_call () is calling
targetm.vectorize.builtin_md_vectorized_function (callee, vectype_out,
vectype_in) with a NULL value for callee.

I can "fix" the Power backend by checking for callee == NULL and returning
NULL_TREE from rs6000_builtin_md_vectorized_function.  But I'm wondering if the
generic code should be fixed instead.

I don't fully understand the implementation of vectorizable_call ().  I suspect
it is getting confused because we are invoking the "vectorizable call" through
a pointer to a function.  In general, I don't think we can vectorize that.  On
the other hand, if the function is in-lined (as it is in this case), then it
may be possible to find the definition of the function pointer, in which case
it should be possible to vectorize the call.  Here's the offending source code:

   function Value
 (Map : Character_Mapping;
  Element : Character) return Character
   is
   begin
  return Map (Element);
   end Value;

Bottom line: I'm wondering if the "better" fix to this problem is to adjust the
generic implementation of vectorizable_call rather than requiring each target
to independently check for callee equal to NULL.  The changes would be to:

1. Not call targetm.vectorize.builtin_md_vectorized_function if callee equals
NULL.
2. Give more "sophisticated" handling to calls through function pointers,
identifying the callee if it is possible to find the definition of the function
pointer.

[Bug libstdc++/81122] [DR 2381] parsing f stopped after '0' when reading std::hexfloat >> f;

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  ---
(In reply to Heinz Kohl from comment #8)
> o.k., it looks like a flawy definition.

Yes, that's why it's being fixed by the standards committee. I don't want to
change our implementation yet, until the intention of the committee is clear.

> First of all, it would be nice, if you would refer my error message to the
> right instance.

I don't know what this means.

We know you can't currently read hex floats using istreams with libstdc++, we
know it's a defect in the standard, we're working on it.

[Bug c++/82514] [8 Regression] ICE: in operator[], at vec.h:749

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

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

[Bug middle-end/84067] [8 regression] gcc.dg/wmul-1.c regression on aarch64 after r257077

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||7.2.1
   Keywords||missed-optimization
   Last reconfirmed||2018-01-26
 CC||ktkachov at gcc dot gnu.org
 Ever confirmed|0   |1
   Target Milestone|--- |8.0
  Known to fail||8.0

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed.

[Bug tree-optimization/81038] [8 regression] test case g++.dg/vect/slp-pr56812.cc fails starting with r248678

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Target|powerpc*-*-*, i?86-*-*, |powerpc*-*-*, i?86-*-*,
   |x86_64-*-*, aarch64-*-* |x86_64-*-*, aarch64-*-*,
   ||arm*-*-*
 CC||ktkachov at gcc dot gnu.org

--- Comment #6 from ktkachov at gcc dot gnu.org ---
I'm also seeing this FAIL on arm

[Bug target/84066] New: Wrong shadow stack register size is saved for x32

[hjl.tools at gmail dot com]

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

Bug ID: 84066
   Summary: Wrong shadow stack register size is saved for x32
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: igor.v.tsimbalist at intel dot com
Blocks: 81652
  Target Milestone: ---
Target: x86-64

x32 is a 64-bit process with 32-bit software pointer and kernel may
place x32 shadow stack above 4GB.  We need to save and restore 64-bit
shadow stack register for x32:


[hjl@gnu-tools-1 tmp]$ cat x.c
void *buf[5];

int execute(void)
{
  if (__builtin_setjmp (buf) == 0)
return 0;
  else
return 1;
}
[hjl@gnu-tools-1 tmp]$ /usr/gcc-8.0.0-x32/bin/gcc -O2 -fcf-protection -mcet x.c
-S -mx32
[hjl@gnu-tools-1 tmp]$ cat x.s
.file   "x.c"
.text
.p2align 4,,15
.globl  execute
.type   execute, @function
execute:
.LFB0:
.cfi_startproc
endbr64
.L2:
endbr64
xorl%eax, %eax
movl%esp, buf(%rip)
movl$.L2, buf+4(%rip)
movl%esp, buf+8(%rip)
rdsspd  %eax  << Only 32-bit shadow stack register is saved.
movl%eax, buf+12(%rip)
xorl%eax, %eax
ret
.cfi_endproc
.LFE0:
.size   execute, .-execute
.comm   buf,20,16

Since builtin jmp buf size is 5 pointers.  We have space to save 64-bit
shadow stack pointers: 32-bit SP, 32-bit FP, 32-bit IP, 64-bit SSP.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81652
[Bug 81652] [meta-bug] -fcf-protection=full -mcet bugs

[Bug c++/83990] [7/8 Regression] Spurious "potential null pointer dereference" warning regression from 7.1 onwards

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  ---
Comment on attachment 43254
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43254
Lost location fix

As use use it multiple time, perhaps do location_t loc = gimple_location
(stmt);
early and use loc afterwards?
Otherwise LGTM.

[Bug fortran/84065] [8 regression] string_1.f90 fails since r256944

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-26
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed.

[Bug c/83989] [8 Regression] -Wrestrict false positive with malloc-style functions

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug libstdc++/81122] [DR 2381] parsing f stopped after '0' when reading std::hexfloat >> f;

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
(In reply to Ben Woodard from comment #4)
> Without this Is there a way to read and write floats and doubles accurately
> without the rounding that converting to/from base 10 ends up introducing?
> How are you supposed to use istreams like
> 
> printf(“%a”,dbl);

std::cout << std::hexfloat << dbl;

> scanf(“%f, );

You can't read a hexadecimal float back in using an istream.

C++17 provides std::to_chars and std::from_chars for lossless conversion of
numbers to/from strings, but GCC only supports it for integers so far, not
floats.

> Note that scanf does handle doubles in whatever form they come in.

As do strtof, strtod and strtold.

> Further note that according to stackexchange this works on llvm and other
> libstdc++ implementations.

N.B. There are no other libstdc++ implementations, libstdc++ is the name of
GCC's C++ standard library implementation, not the generic name.

Some cases work with LLVM's libc++, but their support also gives the wrong
result for valid cases that don't involve hex floats:

#include 
#include 

int main()
{
  double d;
  char c;
  std::istringstream in("1.00f");
  in >> d >> c;
  assert( d == 1.0 && c == 'f' );
}

This fails with libc++.

> Therefore if the standard is unclear in this area
> maybe it is a topic to be clarified.

See comment 1.

[Bug tree-optimization/84061] [8 Regression] gcc.dg/tree-ssa/loop-15.c XFAIL

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-01-26
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Testing that reveals fallout probably because EVRP folds all stmts before
forwprop gets a chance to do this for inlined bodies.   As said, will look
at this during next stage1.

FAIL: gcc.dg/pr35691-1.c scan-tree-dump forwprop1 "gimple_simplified to _[0-9]* 
= (int) z1_[0-9]*(D);"
FAIL: gcc.dg/pr35691-2.c scan-tree-dump forwprop1 "gimple_simplified to _[0-9]* 
= (int) z1_[0-9]*(D);"
FAIL: gcc.dg/pr35691-3.c scan-tree-dump forwprop1 "gimple_simplified to _[0-9]* 
= (int) z1_[0-9]*(D);"
FAIL: gcc.dg/pr35691-4.c scan-tree-dump forwprop1 "gimple_simplified to _[0-9]* 
= (int) z1_[0-9]*(D);"
...
FAIL: gcc.dg/tree-ssa/20040305-1.c scan-tree-dump-times forwprop1
"gimple_simpli
fied" 1 (found 0 times)
FAIL: gcc.dg/tree-ssa/bit-assoc.c scan-tree-dump-times forwprop1
"gimple_simplif
ied" 3 (found 0 times)
XPASS: gcc.dg/tree-ssa/loop-15.c scan-tree-dump-times optimized " + " 0
FAIL: gcc.dg/tree-ssa/pr23744.c scan-tree-dump-times vrp1 "Folding
predicate.*to 1" 1 (found 0 times)
FAIL: gcc.dg/tree-ssa/pr52631.c scan-tree-dump-times fre1 "Replaced b_[0-9]+ &
1 with b_[0-9]+ in" 1 (found 0 times)
FAIL: gcc.dg/tree-ssa/vrp23.c scan-tree-dump-times vrp1 "Simplified relational"
1 (found 0 times)
FAIL: gcc.dg/tree-ssa/vrp24.c scan-tree-dump-times vrp1 "Simplified relational"
1 (found 0 times)

[Bug libstdc++/81122] [DR 2381] parsing f stopped after '0' when reading std::hexfloat >> f;

[koh...@t-online.de]

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

--- Comment #8 from Heinz Kohl  ---
o.k., it looks like a flawy definition.

First of all, it would be nice, if you would refer my error message to the
right instance.

It's unclear, what's to do in the meantime.
An idea might give, what's a simple C++-user like me would expect in this
case(s).
That may be one of the following:
1) no change of behavior 
2) read is symmetric to write
Both together isn't possible.

Standards for programming language are imperfect. That's a very known situation
in the history of programming languages at least since Algol60 (when I was an
implementor).
There's no really conforming implementation possible, when the standard is
faulty.
The difference between a good and a bad implementation is laying not at least
in the way to cope with this problem. Usability, not principled implementation
is the criterion for a good implementation.

The classical considerations are "What seems to be the best work around for
users? What's the best work around for me as implementor? What are other
implementers doing? Is it better to use implement a mostly restricted manner,
or in a mostly wide, or let the user select dependend on an option?".

Every of these cases may violate expectations and should be documented
therefore.
For all these cases it seems to be necessary to document the decision, at least
in the user's guide.

For many applications it's expected to read exactly the same value as written.
Without the possibility to do it with hexfloat, there's no safe base to do
that.

The only possible way to document floating point values in an exact manner
indepently to the internal representation is to use this format, not only, but
especially when using multi precision floating point numbers.
When there's no possibility to read these values back, this is senseless -
more, it looks like a crazy joke.

(my workaround: add 64 bits of precision, write decimal, analyze input for
values like inf, -inf, nan, else read decimal. It's still inexactly beside a
lot more programming and spending much more space and time at runtime).

[Bug c++/82514] [8 Regression] ICE: in operator[], at vec.h:749

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  ---
Author: jason
Date: Fri Jan 26 15:25:23 2018
New Revision: 257093

URL: https://gcc.gnu.org/viewcvs?rev=257093=gcc=rev
Log:
PR c++/82514 - ICE with local class in generic lambda.

* pt.c (regenerated_lambda_fn_p): Remove.
(enclosing_instantiation_of): Don't use it.
(tsubst_function_decl): Call enclosing_instantiation_of.

* pt.c (lookup_template_class_1): Add sanity check.
* name-lookup.c (do_pushtag): Don't add closures to local_classes.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-nested2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/name-lookup.c
trunk/gcc/cp/pt.c

[Bug middle-end/84067] New: [8 regression] gcc.dg/wmul-1.c regression on aarch64 after r257077

[clyon at gcc dot gnu.org]

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

Bug ID: 84067
   Summary: [8 regression] gcc.dg/wmul-1.c regression on aarch64
after r257077
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

After r257077, I have noticed a regression on aarch64:
FAIL: gcc.dg/wmul-1.c scan-tree-dump-not widening_mul "WIDEN_MULT_PLUS_EXPR"

Richi said:
Late forwprop does

@@ -75,7 +21,7 @@
   _1 = (long unsigned int) Idx_6(D);
   _2 = _1 * 40;
   _12 = _1 * 4;
-  _17 = _2 + _12;
+  _17 = _1 * 44;
   _13 = Arr_7(D) + _17;
   MEM[(int[10] *)_13] = 1;
   _4 = _2 + 400;
  _18 = _4 + _12;
  _16 = Arr_7(D) + _18;
  MEM[(int[10] *)_16] = 2;


which I'm not sure ends up profitable at the end.  It makes _12
dead so the total number of multiplications stays the same.
For this we then apply the WIDEN_MULT_PLUS_EXPR two
times given _2 is no longer used multiple times.

The reason the above transform happens is the match.pd :s
behavior which "ignores" :s in case the resulting expression
is "simple".

[Bug middle-end/84040] [8 regression] compilation time of gcc.c-torture/compile/limits-blockid.c is 50x slower

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 43255
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43255=edit
gcc8-pr84040.patch

Untested fix.

[Bug lto/81440] -Wlto-type-mismatch warning with flexible array in struct

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #9 from Eric Gallager  ---
(In reply to Martin Liška from comment #8)
> Fixed on trunk, queued for backport.

Since you're the assignee I'm changing the status to ASSIGNED for the backport

[Bug c++/84059] [8 Regression] ICE in ix86_get_function_versions_dispatcher, at config/i386/i386.c:32429

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Created attachment 43256
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43256=edit
Untested patch

[Bug c++/84036] [8 Regression] ICE on valid code in C++14, variadic lambda capture in a template function

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug middle-end/82878] [7 Regression] ICE in assign_temp, at function.c:968 when using optimization

[nathan at gcc dot gnu.org]

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

--- Comment #11 from Nathan Sidwell  ---
fixed on gcc-7 branch r257089.

[Bug middle-end/84040] [8 regression] compilation time of gcc.c-torture/compile/limits-blockid.c is 50x slower

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
So, instead of no insns at all wqe have 10 debug markers in a single bb and
nothing else.  So some slowdown is completely justified.
The 2 minutes looks weird, even -O0 built cc1 on x86_64 takes just 1:10 minute
to compile it, with a single pass that takes most time:
 scheduling 2:  55.89 (85%) usr   0.02 ( 5%) sys  56.00 (84%) wall 
  3908 kB ( 2%) ggc
With RTL checking but optimized x86_64 cc1:
 scheduling 2:  17.95 (90%) usr   0.01 ( 2%) sys  17.99 (86%) wall 
  3908 kB ( 2%) ggc
So something is wrong during sched2.

[Bug bootstrap/80867] gnat bootstrap broken on powerpc64le-linux-gnu with -O3

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
I suggest the following (pre-approved if it works):

Index: tree-vect-stmts.c
===
--- tree-vect-stmts.c   (revision 257091)
+++ tree-vect-stmts.c   (working copy)
@@ -3159,7 +3159,7 @@ vectorizable_call (gimple *gs, gimple_st
   if (cfn != CFN_LAST)
fndecl = targetm.vectorize.builtin_vectorized_function
  (cfn, vectype_out, vectype_in);
-  else
+  else if (callee)
fndecl = targetm.vectorize.builtin_md_vectorized_function
  (callee, vectype_out, vectype_in);
 }

[Bug middle-end/82123] [7/8 regression] spurious -Wformat-overflow warning for converted vars

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #8 from Eric Gallager  ---
(In reply to Jeffrey A. Law from comment #3)
> So the core bits of the embeddable range analyzer have landed.I've just
> updated (locally) my bits to use that in the sprintf warnings and they do
> indeed fix this problem.  Let me finish beating those into shape.

Changing status to ASSIGNED then, since you put yourself as the assignee

[Bug target/81763] Issues with BMI on 32bit x86 apps on GCC 7.1+

[uros at gcc dot gnu.org]

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

--- Comment #45 from uros at gcc dot gnu.org ---
Author: uros
Date: Fri Jan 26 15:36:32 2018
New Revision: 257096

URL: https://gcc.gnu.org/viewcvs?rev=257096=gcc=rev
Log:
PR target/81763
* config/i386/i386.md (*andndi3_doubleword): Add earlyclobber
to (=,r,rm) alternative. Add (=r,0,rm) and (=r,r,0) alternatives.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md

[Bug middle-end/84048] [8 Regression] FAIL: gcc.dg/torture/tls/run-ld.c -O0 -pie -fPIE execution test

[dave.anglin at bell dot net]

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

--- Comment #3 from dave.anglin at bell dot net ---
On 2018-01-26 2:15 AM, ebotcazou at gcc dot gnu.org wrote:
> Did you upgrade binutils?
Yes.

[Bug middle-end/84019] [7/8 regression] ICE in fold-const of std::complex division

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
The code in question is:
  const struct real_format *const fmt =
REAL_MODE_FORMAT (TYPE_MODE (TREE_TYPE (type)));
  const int prec = fmt->p;
  const mp_rnd_t rnd = fmt->round_towards_zero ? GMP_RNDZ : GMP_RNDN;
  const mpc_rnd_t crnd = fmt->round_towards_zero ? MPC_RNDZZ :
MPC_RNDNN;
  int inexact;
  mpc_t m0, m1;

  mpc_init2 (m0, prec);
  mpc_init2 (m1, prec);
and unless Debian builds the compiler with --disable-checking, REAL_MODE_FORMAT
should ICE if it is used with mode other than with MODE_FLOAT class or
DECIMAL_FLOAT_MODE_P.  All the fmt modes have p in between 11 and 200 or so, so
I don't see how this is possible.

[Bug testsuite/83983] FAIL: g++.dg/lto/pr83121 (test for LTO warnings, pr83121_0.C line 8)

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Target|hppa-unknown-linux-gnu  |hppa-unknown-linux-gnu,
   ||arm-none-linux-gnueabihf
 CC||ktkachov at gcc dot gnu.org

--- Comment #2 from ktkachov at gcc dot gnu.org ---
As David mentioned these also fail on arm:

$TOP/gcc/testsuite/g++.dg/lto/pr83121_0.C:7:10: warning: type 'struct
AsyncHooks' violates the C++ One Definition Rule [-Wodr]
$TOP/gcc/testsuite/g++.dg/lto/pr83121_1.C:2:10: note: a different type is
defined in another translation unit
$TOP/gcc/testsuite/g++.dg/lto/pr83121_0.C:8:21: note: the first difference of
corresponding definitions is field 'providers_'
$TOP/gcc/testsuite/g++.dg/lto/pr83121_1.C:3:21: note: a field of same name but
different type is defined in another translation unit
$TOP/gcc/testsuite/g++.dg/lto/pr83121_0.C:7:10: note: array types have
different bounds
$TOP/gcc/testsuite/g++.dg/lto/pr83121_0.C:6:8: warning: type 'struct
Environment' violates the C++ One Definition Rule [-Wodr]
$TOP/gcc/testsuite/g++.dg/lto/pr83121_1.C:1:8: note: a different type is
defined in another translation unit
$TOP/gcc/testsuite/g++.dg/lto/pr83121_0.C:10:14: note: the first difference of
corresponding definitions is field 'async_hooks_'
$TOP/gcc/testsuite/g++.dg/lto/pr83121_1.C:5:14: note: a field of same name but
different type is defined in another translation unit
$TOP/gcc/testsuite/g++.dg/lto/pr83121_0.C:7:10: note: type 'struct AsyncHooks'
itself violates the C++ One Definition Rule
$TOP/gcc/testsuite/g++.dg/lto/pr83121_1.C:2:10: note: the incompatible type is
defined here

[Bug c/84046] [6/7/8 Regression] global zero-sized objects may have same address

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
  Known to work||4.9.4
Version|unknown |8.0
   Keywords||wrong-code
   Last reconfirmed||2018-01-26
 CC||jsm28 at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|global zero-sized objects   |[6/7/8 Regression] global
   |may have same address   |zero-sized objects may have
   ||same address
   Target Milestone|--- |6.5
  Known to fail||5.1.0

--- Comment #1 from Richard Biener  ---
Confirmed.  I think the C language doesn't specify this since zero-sized arrays
are a GNU extension and thus in C no zero-sized types/decls exist?

So not sure if there's anything to fix - Joseph?

Note that for global unique addresses you can use global objects of size 1,
like a char object.  Not sure why you think using a GNU extension is
superior?

[Bug testsuite/84049] libgomp.c++/for-[56].C and libgomp.c/for-[56].c take a long time to run

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  ---
FAIL: libgomp.c++/for-11.C execution test
FAIL: libgomp.c++/for-13.C execution test

have the same issue.  They just lead to

WARNING: program timed out.
WARNING: program timed out.

[Bug tree-optimization/84051] [6/7/8 Regression] missing -Warray-bounds on an out-of-bounds access via an array pointer

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.5