[Bug c/83859] Please add new attribute which will establish relation between parameters for buffer and its size

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #7 from Eric Gallager  ---
(In reply to jos...@codesourcery.com from comment #4)
> On Mon, 15 Jan 2018, msebor at gcc dot gnu.org wrote:
> 
> > 1) How to annotate constant size buffers.  I'd like to be able to express 
> > that
> > a function requires a buffer of at least N elements without making N an
> > argument to the function.  E.g., annotate the declaration 'void f (int[2])' 
> > to
> > let GCC understand that it requires an array of at least 2 ints.
> 
> "void f (int[static 2])" means that; no GNU-specific syntax is needed.

For that to be useful, both bug 50584 and bug 67793 would have to be fixed

[Bug middle-end/84251] [8 Regression] Performance regression in gcc 8 when comparing floating point numbers

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org
   Target Milestone|--- |8.0

[Bug fortran/82049] [6/7/8 Regression] ICE with character(*),parameter array constructor

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from kargl at gcc dot gnu.org ---
I have a patch.

[Bug tree-optimization/71361] [7 Regression] Changes in ivopts caused perf regression on x86

[lesliezhai at llvm dot org.cn]

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

Leslie Zhai  changed:

   What|Removed |Added

 CC||lesliezhai at llvm dot org.cn

--- Comment #8 from Leslie Zhai  ---
(In reply to Jeffrey A. Law from comment #7)
> Fixed on the trunk.

Hi Jeff,

Could you please show me which commit fixed it on trunk? thanks a lot!

Regards,
Leslie Zhai

[Bug c++/82930] [C++17] ICE: in is_normal_capture_proxy, at cp/lambda.c:288 with structured binding in a lambda function with auto typed arguments

[vanslyke.t at husky dot neu.edu]

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

Timothy VanSlyke  changed:

   What|Removed |Added

 CC||vanslyke.t at husky dot neu.edu

--- Comment #2 from Timothy VanSlyke  ---
Created attachment 43351
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43351=edit
Minimum example of the bug

Just ran across this as well.  Attached the minimum possible example I could
reduce it to [6 lines, only three of which have semicolons :)].  x86_64 linux
gcc-7.2; 7.3 is affected as well: https://godbolt.org/g/p6LJ5V

[Bug c++/71166] [7 Regression] ICE with nested constexpr/initializer

[lesliezhai at llvm dot org.cn]

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

Leslie Zhai  changed:

   What|Removed |Added

 CC||lesliezhai at llvm dot org.cn

--- Comment #16 from Leslie Zhai  ---
But gcc-7-branch and 8.x trunk reverted the Remove?

-fini_constexpr ();

[Bug lto/84241] [8 regression] test case g++.dg/torture/pr67600.C fails starting with r257412

[paul.hua.gm at gmail dot com]

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

Paul Hua  changed:

   What|Removed |Added

 CC||paul.hua.gm at gmail dot com

--- Comment #3 from Paul Hua  ---
Confirmed on mips64el as well.

[Bug testsuite/84243] [8 Regression] gcc.target/i386/cet-intrin-4.c at r257414

[igor.v.tsimbalist at intel dot com]

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

--- Comment #10 from igor.v.tsimbalist at intel dot com ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #8)
> > --- Comment #7 from igor.v.tsimbalist at intel dot com ---
> [...]
> >> Btw., I'm seeing the cet-intrin-[34].c ICEs too on i386-pc-solaris2.11.  
> >> The
> >> two
> >> failures are completely different, probably belong into a different PR.
> >
> > Is the ICE you see the same as specified in Comment 2? If yes then this is
> > covered by 84248. Patch for this issue has been posted.
> 
> It is indeed.  Sorry for overlooking this: to many failures cooking at
> once ;-)
> 
> With my patch above, this leaves us with the cet-intrin-4.c failure:
> just replace -mshstk with -mcet?

No. Your patch should not have effect on cet-intrin-[34].c fails. Fail in these
tests has different reason (PR 84248).

[Bug testsuite/84243] [8 Regression] gcc.target/i386/cet-intrin-4.c at r257414

[ro at gcc dot gnu.org]

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

--- Comment #9 from Rainer Orth  ---
Author: ro
Date: Tue Feb  6 23:31:09 2018
New Revision: 257432

URL: https://gcc.gnu.org/viewcvs?rev=257432=gcc=rev
Log:
Don't pass x86-only options on non-x86 targets in
c-c++-common/fcf-protection-[67].c (PR testsuite/84243)

PR testsuite/84243
* c-c++-common/fcf-protection-6.c: Only pass -mshstk on x86
targets.
* c-c++-common/fcf-protection-7.c: Likewise for -mibt.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/fcf-protection-6.c
trunk/gcc/testsuite/c-c++-common/fcf-protection-7.c

[Bug testsuite/84243] [8 Regression] gcc.target/i386/cet-intrin-4.c at r257414

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #7 from igor.v.tsimbalist at intel dot com ---
[...]
>> Btw., I'm seeing the cet-intrin-[34].c ICEs too on i386-pc-solaris2.11.  The
>> two
>> failures are completely different, probably belong into a different PR.
>
> Is the ICE you see the same as specified in Comment 2? If yes then this is
> covered by 84248. Patch for this issue has been posted.

It is indeed.  Sorry for overlooking this: to many failures cooking at
once ;-)

With my patch above, this leaves us with the cet-intrin-4.c failure:
just replace -mshstk with -mcet?

Thanks.
Rainer

[Bug testsuite/84243] [8 Regression] gcc.target/i386/cet-intrin-4.c at r257414

[igor.v.tsimbalist at intel dot com]

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

igor.v.tsimbalist at intel dot com changed:

   What|Removed |Added

 CC||igor.v.tsimbalist at intel dot 
com

--- Comment #7 from igor.v.tsimbalist at intel dot com ---
(In reply to Rainer Orth from comment #6)
> Patch for the fcf-protection-[67].c failures posted:
> 
> https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00285.html
> 
> Btw., I'm seeing the cet-intrin-[34].c ICEs too on i386-pc-solaris2.11.  The
> two
> failures are completely different, probably belong into a different PR.

Is the ICE you see the same as specified in Comment 2? If yes then this is
covered by 84248. Patch for this issue has been posted.

[Bug testsuite/84243] [8 Regression] gcc.target/i386/cet-intrin-4.c at r257414

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Target|x86-64-none-linux-gnu,  |x86-64-*-*, i?86-*-*,
   |aarch64-none-linux-gnu  |aarch64-none-linux-gnu
   Target Milestone|--- |8.0

--- Comment #6 from Rainer Orth  ---
Patch for the fcf-protection-[67].c failures posted:

https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00285.html

Btw., I'm seeing the cet-intrin-[34].c ICEs too on i386-pc-solaris2.11.  The
two
failures are completely different, probably belong into a different PR.

[Bug testsuite/84243] [8 Regression] gcc.target/i386/cet-intrin-4.c at r257414

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #5 from Rainer Orth  ---
I'm seeing the c-c++-common/fcf-protection-6.c and
c-c++-common/fcf-protection-7.c
on sparc-sun-solaris2.11, too:

+FAIL: c-c++-common/fcf-protection-6.c  -std=gnu++11  (test for errors, line )
+FAIL: c-c++-common/fcf-protection-6.c  -std=gnu++11 (test for excess errors)
+FAIL: c-c++-common/fcf-protection-6.c  -std=gnu++14  (test for errors, line )
+FAIL: c-c++-common/fcf-protection-6.c  -std=gnu++14 (test for excess errors)
+FAIL: c-c++-common/fcf-protection-6.c  -std=gnu++98  (test for errors, line )
+FAIL: c-c++-common/fcf-protection-6.c  -std=gnu++98 (test for excess errors)

Excess errors:
xg++: error: unrecognized command line option '-mshstk'

+FAIL: c-c++-common/fcf-protection-7.c  -std=gnu++11  (test for errors, line )
+FAIL: c-c++-common/fcf-protection-7.c  -std=gnu++11 (test for excess errors)
+FAIL: c-c++-common/fcf-protection-7.c  -std=gnu++14  (test for errors, line )
+FAIL: c-c++-common/fcf-protection-7.c  -std=gnu++14 (test for excess errors)
+FAIL: c-c++-common/fcf-protection-7.c  -std=gnu++98  (test for errors, line )
+FAIL: c-c++-common/fcf-protection-7.c  -std=gnu++98 (test for excess errors)

Excess errors:
xg++: error: unrecognized command line option '-mibt'

ISTM that -mshstk and -mibt should only be passed on x86 targets, then you get
the expected error.

About to test a patch along those lines.

  Rainer

[Bug c++/71662] [6/7/8 Regression][DR 1485] ICE on invalid C++11 code with unqualified name look up: in tsubst_copy, at cp/pt.c:14010

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||paolo.carlini at oracle dot com

--- Comment #5 from Paolo Carlini  ---
This seems fixed in trunk, we simply reject the code without ICEing. While
reviewing this bug I noticed once more the nit that -Wreturn-type enabled by
default means that in such cases we emit a redundant warning:

71662.C:14:10: error: ‘e’ was not declared in this scope
   return e;
  ^
71662.C: In instantiation of ‘A::E A::h() [with T = int]’:
71662.C:8:23:   required from here
71662.C:15:1: warning: no return statement in function returning non-void
[-Wreturn-type]

but that seems an unrelated issue, really. Thus I mean to commit the testcase
and remove the 8 Regression marker.

[Bug middle-end/79016] missing -Wstringop-overflow= overflowing allocated buffers

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
This is also affects overflowing buffers allocated by a user-defined function
declared with attribute alloc_size.

$ cat t.c && gcc -D_FORTIFY_SOURCE=2 -O2 -S -Wall
-fdump-tree-optimized=/dev/stdout t.c
#include 

int* __attribute__ ((alloc_size (1)))
f (int);

void* g (const void *s)
{
  void *p = f (8);
  __builtin_memcpy (p, s, 9);   // missing -Wstringop-overflow
  return p;
}

void* h (const void *s)
{
  void *p = f (8);
  memcpy (p, s, 9);   // -Wstringop-overflow with _FORTIFY_SOURCE
  return p;
}

;; Function g (g, funcdef_no=14, decl_uid=2244, cgraph_uid=14, symbol_order=14)

g (const void * s)
{
  void * p;

   [local count: 1073741825]:
  p_3 = f (8);
  __builtin_memcpy (p_3, s_4(D), 9);
  return p_3;

}



;; Function h (h, funcdef_no=15, decl_uid=2248, cgraph_uid=15, symbol_order=15)

h (const void * s)
{
  void * p;

   [local count: 1073741825]:
  p_3 = f (8);
  __builtin___memcpy_chk (p_3, s_4(D), 9, 8);
  return p_3;

}


In file included from /usr/include/string.h:635,
 from t.c:1:
In function ‘memcpy’,
inlined from ‘h’ at t.c:16:3:
/usr/include/bits/string3.h:53:10: warning: ‘__builtin___memcpy_chk’ writing 9
bytes into a region of size 8 overflows the destination [-Wstringop-overflow=]
   return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest));
  ^~

[Bug target/84248] [8 Regression] r257414 failed too bootstrap in libitm

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||build, ice-on-valid-code
  Component|bootstrap   |target
   Target Milestone|--- |8.0
Summary|r257414 failed too  |[8 Regression] r257414
   |bootstrap in libitm |failed too bootstrap in
   ||libitm

[Bug debug/84252] [8 Regression] ICE in get_tracked_reg_offset when building libvpx for aarch64

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Started with r255867.  I'll have a look tomorrow.

[Bug c++/84255] accepts redefinition of template variable

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-06
Version|7.0 |7.3.1
 Ever confirmed|0   |1

[Bug other/80589] Typing mistakes in two messages

[goeran at uddeborg dot se]

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

Göran Uddeborg  changed:

   What|Removed |Added

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

--- Comment #8 from Göran Uddeborg  ---
This doesn't seem completely fixed.  I don't see the second mistake any more. 
But the first mistake still remains in param.def, while the same string in
doc/invoke.texi is fixed.

[Bug libstdc++/84256] New: Use object size checking built-ins in libstdc++

[redi at gcc dot gnu.org]

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

Bug ID: 84256
   Summary: Use object size checking built-ins in libstdc++
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

#include 

int main()
{
  int a[2] = { };
  std::vector v(a, a+3);
}

This gets caught by AddressSanitizer, but it would be possible to warn at
compile-time by using __builtin_object_size, with something like

--- a/libstdc++-v3/include/bits/stl_vector.h
+++ b/libstdc++-v3/include/bits/stl_vector.h
@@ -71,6 +71,15 @@ __sanitizer_annotate_contiguous_container(const void*, const
void*,
  const void*, const void*);
 #endif

+namespace __gnu_debug
+{
+  void
+  __bad_iterator_range()
+  __attribute__((__warning__("invalid end iterator")));
+
+  inline void __bad_iterator_range() { }
+}
+
 namespace std _GLIBCXX_VISIBILITY(default)
 {
 _GLIBCXX_BEGIN_NAMESPACE_VERSION
@@ -543,7 +552,16 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
vector(_InputIterator __first, _InputIterator __last,
   const allocator_type& __a = allocator_type())
: _Base(__a)
-   { _M_initialize_dispatch(__first, __last, __false_type()); }
+   {
+ if _GLIBCXX17_CONSTEXPR (is_pointer<_InputIterator>::value)
+   {
+ const size_t __len = __builtin_object_size(__first, 1);
+ using _Vp = typename iterator_traits<_InputIterator>::value_type;
+ if (__len < (size_t)std::distance(__last - __first) *
sizeof(_Vp))
+   __gnu_debug::__bad_iterator_range();
+   }
+ _M_initialize_dispatch(__first, __last, __false_type());
+   }
 #else
   template
vector(_InputIterator __first, _InputIterator __last,


We could do this in every function that takes a pair of iterators to read from
or write to, although maybe only when _GLIBCXX_ASSERTIONS is defined.

We could also use the checking versions of __builtin_memmove etc. in
 (although only when __memcpy_chk is available, and again
probably onyl when ASSERTIONS are enabled).

https://gcc.gnu.org/onlinedocs/gcc/Object-Size-Checking.html

(This is the general case of PR 54924 which is specific to std::basic_string)

[Bug debug/84252] [8 Regression] ICE in get_tracked_reg_offset when building libvpx for aarch64

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 CC||pinskia at gcc dot gnu.org
  Component|target  |debug
   Target Milestone|--- |8.0
Summary|ICE in  |[8 Regression] ICE in
   |get_tracked_reg_offset when |get_tracked_reg_offset when
   |building libvpx for aarch64 |building libvpx for aarch64

[Bug c++/84255] New: accepts redefinition of template variable

[smw at gcc dot gnu.org]

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

Bug ID: 84255
   Summary: accepts redefinition of template variable
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: smw at gcc dot gnu.org
  Target Milestone: ---

The following code is accepted by all version of GCC tested, but rejected by
other compilers following ISO/IEC 14889 [temp]/1.

template
constexpr T pi = T(3.1415926535897932385);

template
constexpr T pi = T(3.1415926535897932385);

I would expect a diagnostic similar to the one from the LLVM compiler:

:5:21: error: redefinition of 'pi'
constexpr T pi = T(3.1415926535897932385);
^
:2:21: note: previous definition is here
constexpr T pi = T(3.1415926535897932385);

[Bug c/81824] Warn for missing attributes with function aliases

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #3 from Martin Sebor  ---
I'm adding a new warning to do something similar for the C++ front end per
Jason's suggestion (https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00197.html). 
I don't expect to also resolve this request for GCC 8 but I might as well
assign it to myself and finish it in GCC 9.

[Bug libstdc++/54924] Warn for std::string constructor with wrong size

[redi at gcc dot gnu.org]

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

--- Comment #14 from Jonathan Wakely  ---
Created attachment 43350
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43350=edit
Patch to use __builtin_object_size in std::string

So it isn't lost, here's a prototype I was working on last year (which only
helps if you use -Wsystem-headers).

[Bug libstdc++/54924] Warn for std::string constructor with wrong size

[redi at gcc dot gnu.org]

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

--- Comment #13 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #10)
> I'm starting to think we should just make libstdc++ headers 100%
> warning-free

We're closer to that now, but not in a position to stop marking our headers as
system headers.

[Bug target/84252] ICE in get_tracked_reg_offset when building libvpx for aarch64

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-06
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
More reduced, -g -O2 needed:

struct S { __Int32x4_t b[2]; };
void foo (struct S x) {}

[Bug testsuite/84243] [8 Regression] gcc.target/i386/cet-intrin-4.c at r257414

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Last reconfirmed||2018-02-06
 Resolution|DUPLICATE   |---
 Ever confirmed|0   |1

--- Comment #4 from H.J. Lu  ---
Reopened.

[Bug target/78303] PowerPC vec-init-{1,2,4,5,8,9} tests do not run on -mlittle -maltivec=be

[wschmidt at gcc dot gnu.org]

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

--- Comment #3 from Bill Schmidt  ---
The memory layout is correct.  It should not change regardless of endianness
settings.  (The byte order of each element is dependent upon the fundamental
endianness, but the order of array elements with respect to one another is
always the same.

On a POWER8, -maltivec=be means to load the array with lxvd2x, whereas
-maltivec=le means to load the array with lxvd2x and adjust with a swap
instruction.

On a POWER9, lxvx can be used when the -maltivec setting matches the
fundamental endianness (so is correct on BE and LE by default).  Using
-maltivec=be on an LE system requires using lxvd2x or similar (depending upon
element size).

I am tempted to deprecate -maltivec=be in GCC 8 and remove support for it in
GCC 9.  This behavior is optional and was designed primarily to support certain
libraries that are not supported by GCC anyway.  Keeping it consistent is a
time sink with little benefit...

[Bug target/84252] ICE in get_tracked_reg_offset when building libvpx for aarch64

[dmalcolm at gcc dot gnu.org]

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

--- Comment #1 from David Malcolm  ---
In vt_add_function_parameter:
(gdb) p incoming
$6 = (parallel:OI [
(expr_list:REG_DEP_TRUE (reg:V4SI 32 v0 [ qIn0 ])
(const_int 0 [0]))
(expr_list:REG_DEP_TRUE (reg:V4SI 33 v1 [ qIn0+16 ])
(const_int 16 [0x10]))
])

[Bug target/84146] ICE with -mcet in dwarf2out_var_location, involving sigsetjmp

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Tue Feb  6 20:32:45 2018
New Revision: 257431

URL: https://gcc.gnu.org/viewcvs?rev=257431=gcc=rev
Log:
PR target/84146
* config/i386/i386.c (rest_of_insert_endbranch): Only skip
NOTE_INSN_CALL_ARG_LOCATION after a call, not anything else,
and skip it regardless of bb boundaries.  Use CALL_P macro,
don't test INSN_P (insn) together with CALL_P or JUMP_P check
unnecessarily, formatting fix.

* gcc.target/i386/pr84146.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr84146.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug target/84252] New: ICE in get_tracked_reg_offset when building libvpx for aarch64

[dmalcolm at gcc dot gnu.org]

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

Bug ID: 84252
   Summary: ICE in get_tracked_reg_offset when building libvpx for
aarch64
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64-redhat-linux

Created attachment 43349
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43349=edit
Reduced test case

This downstream bug report:
  https://bugzilla.redhat.com/show_bug.cgi?id=1541670
describes an ICE building libvpx on aarch64.

I managed to reduce the testcase to ~300 lines; I'm attaching it.

The ICE happens during vartrack (at -O1 and above and -Os; needs -g).

(gdb) p reg
$2 = (reg:V4SI 33 v1 [ qIn0+16 ])

1866static HOST_WIDE_INT
1867get_tracked_reg_offset (rtx loc)
1868{
1869  HOST_WIDE_INT offset;
1870  if (!track_offset_p (REG_OFFSET (loc), ))
1871gcc_unreachable ();
1872  return offset;
1873}

It appears to be hitting the gcc_unreachable.

(this was with r257097 fwiw)

[Bug target/84154] [7/8 Regression] PowerPC GCC 7 and 8 have regression in converting fp to short/char and returning it

[meissner at gcc dot gnu.org]

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

--- Comment #2 from Michael Meissner  ---
Author: meissner
Date: Tue Feb  6 20:15:40 2018
New Revision: 257429

URL: https://gcc.gnu.org/viewcvs?rev=257429=gcc=rev
Log:
2018-02-06  Michael Meissner  

PR target/84154
* config/rs6000/rs6000.md (su code attribute): Use "u" for
unsigned_fix, not "s".


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

[Bug testsuite/84243] [8 Regression] gcc.target/i386/cet-intrin-4.c at r257414

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from H.J. Lu  ---
Dup.

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

[Bug bootstrap/84248] r257414 failed too bootstrap in libitm

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||jgreenhalgh at gcc dot gnu.org

--- Comment #4 from H.J. Lu  ---
*** Bug 84243 has been marked as a duplicate of this bug. ***

[Bug bootstrap/84248] r257414 failed too bootstrap in libitm

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  ---
I am testing this patch

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 6c612c77987..1fa8bebca1d 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -4915,7 +4915,7 @@ ix86_option_override_internal (bool main_args_p,
   /* Do not support control flow instrumentation if CET is not enabled.  */
   if (opts->x_flag_cf_protection != CF_NONE)
 {
-  switch (flag_cf_protection)
+  switch ((flag_cf_protection & ~CF_SET))
   {
   case CF_NONE:
 break;

[Bug bootstrap/84248] r257414 failed too bootstrap in libitm

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  ---
[hjl@gnu-skx-1 libitm]$
/export/build/gnu/gcc-test/build-x86_64-linux/./gcc/xg++
-B/export/build/gnu/gcc-test/build-x86_64-linux/./gcc/ -nostdinc++ -nostdinc++
-I/export/build/gnu/gcc-test/build-x86_64-linux/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu
-I/export/build/gnu/gcc-test/build-x86_64-linux/x86_64-pc-linux-gnu/libstdc++-v3/include
-I/export/gnu/import/git/sources/gcc/libstdc++-v3/libsupc++
-I/export/gnu/import/git/sources/gcc/libstdc++-v3/include/backward
-I/export/gnu/import/git/sources/gcc/libstdc++-v3/testsuite/util
-L/export/build/gnu/gcc-test/build-x86_64-linux/x86_64-pc-linux-gnu/libstdc++-v3/src
-L/export/build/gnu/gcc-test/build-x86_64-linux/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L/export/build/gnu/gcc-test/build-x86_64-linux/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/export/build/gnu/gcc-test/build-x86_64-linux/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-B/export/build/gnu/gcc-test/build-x86_64-linux/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/usr/gcc-8.0.1-x32/x86_64-pc-linux-gnu/bin/
-B/usr/gcc-8.0.1-x32/x86_64-pc-linux-gnu/lib/ -isystem
/usr/gcc-8.0.1-x32/x86_64-pc-linux-gnu/include -isystem
/usr/gcc-8.0.1-x32/x86_64-pc-linux-gnu/sys-include -DHAVE_CONFIG_H -I.
-I/export/gnu/import/git/sources/gcc/libitm
-I/export/gnu/import/git/sources/gcc/libitm/config/linux/x86
-I/export/gnu/import/git/sources/gcc/libitm/config/linux
-I/export/gnu/import/git/sources/gcc/libitm/config/x86
-I/export/gnu/import/git/sources/gcc/libitm/config/posix
-I/export/gnu/import/git/sources/gcc/libitm/config/generic
-I/export/gnu/import/git/sources/gcc/libitm -mrtm -Wall -pthread -Werror
-fcf-protection -mcet -std=gnu++0x -funwind-tables -fno-exceptions -fno-rtti
-fabi-version=4 -O2 -g -D_GNU_SOURCE -MT aatree.lo -MD -MP -MF .deps/aatree.Tpo
-c /export/gnu/import/git/sources/gcc/libitm/aatree.cc  -fPIC -DPIC -S
In file included from
/export/build/gnu/gcc-test/build-x86_64-linux/gcc/include/x86intrin.h:27,
 from
/export/gnu/import/git/sources/gcc/libitm/config/x86/target.h:26,
 from /export/gnu/import/git/sources/gcc/libitm/libitm_i.h:74,
 from /export/gnu/import/git/sources/gcc/libitm/aatree.cc:28:
/export/build/gnu/gcc-test/build-x86_64-linux/gcc/include/ia32intrin.h:56:28:
internal compiler error: in ix86_option_override_internal, at
config/i386/i386.c:4952
 #pragma GCC target("sse4.2")
^
0x168245f ix86_option_override_internal
/export/gnu/import/git/sources/gcc/gcc/config/i386/i386.c:4952
0x1683e67 ix86_valid_target_attribute_tree(tree_node*, gcc_options*,
gcc_options*)
/export/gnu/import/git/sources/gcc/gcc/config/i386/i386.c:5656
0xbbfaf1 ix86_pragma_target_parse
/export/gnu/import/git/sources/gcc/gcc/config/i386/i386-c.c:538
0xb90391 handle_pragma_target
/export/gnu/import/git/sources/gcc/gcc/c-family/c-pragma.c:907
0xb91110 c_invoke_pragma_handler(unsigned int)
/export/gnu/import/git/sources/gcc/gcc/c-family/c-pragma.c:1482
0x9fd977 cp_parser_pragma
/export/gnu/import/git/sources/gcc/gcc/cp/parser.c:38764
0x9bd45d cp_parser_declaration_seq_opt
/export/gnu/import/git/sources/gcc/gcc/cp/parser.c:12595
0x9ac029 cp_parser_translation_unit
/export/gnu/import/git/sources/gcc/gcc/cp/parser.c:4559
0x9fdaed c_parse_file()
/export/gnu/import/git/sources/gcc/gcc/cp/parser.c:38820
0xb8b12f c_common_parse_file()
/export/gnu/import/git/sources/gcc/gcc/c-family/c-opts.c:1132
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
[hjl@gnu-skx-1 libitm]$

[Bug middle-end/84251] New: Performance regression in gcc 8 when comparing floating point numbers

[mikulas at artax dot karlin.mff.cuni.cz]

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

Bug ID: 84251
   Summary: Performance regression in gcc 8 when comparing
floating point numbers
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mikulas at artax dot karlin.mff.cuni.cz
  Target Milestone: ---

See this simple function and compile it with -O2 on x86-64:
#include 
#include 

int cmp(double a, double b)
{
if (isnan(a) || isnan(b))
abort();
return a == b;
}

On gcc-7, we get optimal code:
 :
   0:   66 0f 2e c1 ucomisd %xmm1,%xmm0
   4:   7a 07   jp d 
   6:   0f 94 c0sete   %al
   9:   0f b6 c0movzbl %al,%eax
   c:   c3  retq   
   d:   48 83 ec 08 sub$0x8,%rsp
  11:   e8 00 00 00 00  callq  16 

On gcc-8, we get inoptimal code. See the nonsensical "setnp" instruction in a
block of code where it is known that the "P" flag must be clear.
 :
   0:   48 83 ec 08 sub$0x8,%rsp
   4:   66 0f 2e c1 ucomisd %xmm1,%xmm0
   8:   0f 8a 00 00 00 00   jp e 
   e:   0f 9b c0setnp  %al
  11:   ba 00 00 00 00  mov$0x0,%edx
  16:   0f b6 c0movzbl %al,%eax
  19:   0f 45 c2cmovne %edx,%eax
  1c:   48 83 c4 08 add$0x8,%rsp
  20:   c3  retq   
Disassembly of section .text.unlikely:
 :
   0:   e8 00 00 00 00  callq  5 

[Bug sanitizer/84250] New: Symbol collision when using both Address and Undefined Behavior sanitizers (-fsanitize=address,undefined)

[pedronavf at gmail dot com]

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

Bug ID: 84250
   Summary: Symbol collision when using both Address and Undefined
Behavior sanitizers (-fsanitize=address,undefined)
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pedronavf at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

When using both Address and Undefined Behavior sanitizers
(-fsanitize=address,undefined ) the reporting functions, like
__sanitizer_set_report_path, get called only for Address Sanitizer.

Because both sanitizers statically link libsanitizer_common (where the
__report_* functions are) both libraries have the __sanitizer_set_report_path
symbol and the linker resolves the call to the one in libasan.so. Also, this
issue is the one that causes UBSAN_OPTIONS to not respect the "log_path" flag
when using both sanitizers.

Clang's approach is to embed ubsan in asan when using both sanitizers
(https://github.com/google/sanitizers/issues/912).

Test program (test.cpp)

#include 
int main(int argc, char **argv) {
  __sanitizer_set_report_path("/tmp/sanitizer.txt");
  int i = 23;
  i <<= 32;
  int *array = new int[100];
  delete [] array;
  return array[argc];
}

Compile: g++ -O -g -fsanitize=address test.cpp (works)
 g++ -O -g -fsanitize=undefined test.cpp (works)
 g++ -O -g -fsanitize=address,undefined test.cpp (doesn't work!)

This program triggers both asan and ubsan. When using -fsanitize=address or
-fsanitize=undefined the sanitizer output is correctly written to
/tmp/sanitizer.txt.. When using both sanitizers, only asan's gets written
to file; ubsan output goes to stderr.

The same thing happens when linking the sanitizers statically (-static-libasan
-static-libubsan), but I found out that using __sanitizer_set_report_path never
works for ubsan when linking statically:

g++ -O -g -fsanitize=undefined test.cpp -static-libubsan

[Bug bootstrap/84248] r257414 failed too bootstrap in libitm

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-06
 CC||itsimbal at gcc dot gnu.org
Summary|r25742 failed to bootstrap  |r257414 failed too
   |in libitm   |bootstrap in libitm
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
It is caused by r257414.

[Bug testsuite/84243] [8 Regression] gcc.target/i386/cet-intrin-4.c at r257414

[jgreenhalgh at gcc dot gnu.org]

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

--- Comment #2 from James Greenhalgh  ---
gcc -v:

  Configured with: .../gcc/configure --disable-bootstrap
--enable-languages=c,c++,fortran --disable-multilib --disable-libsanitizer
--prefix=.../build/install/ 

FAIL: gcc.target/i386/cet-intrin-3.c (internal compiler error)
FAIL: gcc.target/i386/cet-intrin-3.c (test for excess errors)
  Excess errors:
  .../build/gcc/include/pmmintrin.h:35:9: internal compiler error: in
ix86_option_override_internal, at config/i386/i386.c:4952
  0xfa1687 ix86_option_override_internal
.../gcc/config/i386/i386.c:4952
  0xfaf246 ix86_valid_target_attribute_tree(tree_node*, gcc_options*,
gcc_options*)
.../gcc/config/i386/i386.c:5656
  0x76b7cb ix86_pragma_target_parse
.../gcc/config/i386/i386-c.c:539
  0x743cd3 handle_pragma_target
.../gcc/c-family/c-pragma.c:907
  0x6c2349 c_parser_pragma
.../gcc/c/c-parser.c:11122
  0x6e600d c_parser_external_declaration
.../gcc/c/c-parser.c:1624
  0x6e6971 c_parser_translation_unit
.../gcc/c/c-parser.c:1524
  0x6e6971 c_parse_file()
.../gcc/c/c-parser.c:18410
  0x7417f5 c_common_parse_file()
.../gcc/c-family/c-opts.c:1132

FAIL: gcc.target/i386/cet-intrin-4.c (test for excess errors)
  Excess errors:
  cc1: error: '-fcf-protection=full' requires Intel CET support. Use -mcet or
both of -mibt and -mshstk options to enable CET

[Bug bootstrap/84248] New: r25742 failed to bootstrap in libitm

[hjl.tools at gmail dot com]

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

Bug ID: 84248
   Summary: r25742 failed to bootstrap in libitm
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---
Target: x86-64

In file included from
/export/build/gnu/gcc-test/build-x86_64-linux/gcc/include/x86intrin.h:27,
 from
/export/gnu/import/git/sources/gcc/libitm/config/x86/target.h:26,
 from /export/gnu/import/git/sources/gcc/libitm/libitm_i.h:74,
 from /export/gnu/import/git/sources/gcc/libitm/alloc.cc:25:
/export/build/gnu/gcc-test/build-x86_64-linux/gcc/include/ia32intrin.h:56:28:
internal compiler error: in ix86_option_override_internal, at
config/i386/i386.c:4952
 #pragma GCC target("sse4.2")

[Bug tree-optimization/83456] -Wrestrict false positive on a non-overlapping memcpy in an inline function

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=32667

--- Comment #3 from Martin Sebor  ---
See also bug 32667 for some background into GCC emitting perfectly overlapping
calls to memcpy for some aggregate assignments.  The code that controls the
diagnostic tries to work around that bug:

  /* If SRC and DEST are the same (and not volatile), return
 DEST{,+LEN,+LEN-1}.  */
  if (operand_equal_p (src, dest, 0))
{
  /* Avoid diagnosing exact overlap in calls to __builtin_memcpy.
 It's safe and may even be emitted by GCC itself (see bug
 32667).  However, diagnose it in explicit calls to the memcpy
 function.  */
  if (check_overlap && *IDENTIFIER_POINTER (DECL_NAME (func)) != '_')
warning_at (loc, OPT_Wrestrict,
"%qD source argument is the same as destination",
func);

[Bug tree-optimization/83456] -Wrestrict false positive on a non-overlapping memcpy in an inline function

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
And another test case from bug 84095 comment #9, also due to the check in
gimple-fold.c.  This one seems closer to the first test case in comment #0. 

$ cat t.c && gcc -O2 -S -Wall t.c
extern void* memcpy (void*, const void*, __SIZE_TYPE__);

struct netdevice {
  void *priv;
};

struct ip_tunnel {
  struct netdevice *dev;
  int ip6rd[3];
};

struct sit_net {
  struct netdevice *fb_tunnel_dev;
};

void ipip6_tunnel_clone_6rd (struct netdevice *dev, struct sit_net *sitn)
{
  struct ip_tunnel *t = dev->priv;
  if (t->dev == sitn->fb_tunnel_dev)
return;

  struct ip_tunnel *t0 = sitn->fb_tunnel_dev->priv;
  memcpy(>ip6rd, >ip6rd, sizeof(t->ip6rd));
}

void sit_init_net (struct sit_net *sitn, struct netdevice *fb_tunnel_dev)
{
  sitn->fb_tunnel_dev = fb_tunnel_dev;
  ipip6_tunnel_clone_6rd (sitn->fb_tunnel_dev, sitn);
}
t.c: In function ‘sit_init_net’:
t.c:23:3: warning: ‘memcpy’ source argument is the same as destination
[-Wrestrict]
   memcpy(>ip6rd, >ip6rd, sizeof(t->ip6rd));
   ^~~

[Bug testsuite/84243] [8 Regression] gcc.target/i386/cet-intrin-4.c at r257414

[igor.v.tsimbalist at intel dot com]

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

--- Comment #1 from igor.v.tsimbalist at intel dot com ---
Hi,

I do not have 'none-linux' platform at hand. Could you please show the output
for the failing tests?

Thanks,
Igor


> -Original Message-
> From: jgreenhalgh at gcc dot gnu.org [mailto:gcc-bugzi...@gcc.gnu.org]
> Sent: Tuesday, February 6, 2018 5:58 PM
> To: itsim...@gcc.gnu.org
> Subject: [Bug testsuite/84243] New: [8 Regression] gcc.target/i386/cet-intrin-
> 4.c at r257414
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84243
> 
> Bug ID: 84243
>Summary: [8 Regression] gcc.target/i386/cet-intrin-4.c at
> r257414
>Product: gcc
>Version: 8.0
> Status: UNCONFIRMED
>   Severity: normal
>   Priority: P3
>  Component: testsuite
>   Assignee: unassigned at gcc dot gnu.org
>   Reporter: jgreenhalgh at gcc dot gnu.org
> CC: itsimbal at gcc dot gnu.org
>   Target Milestone: ---
> Target: x86-64-none-linux-gnu, aarch64-none-linux-gnu
> 
> Hi, our bisect robot spotted a failure in gcc.target/i386/cet-intrin-3.c,
> gcc.target/i386/cet-intrin-4.c, after revision r257414 on
> x86-64-none-linux-gnu, and c-c++-common/fcf-protection-6.c and
> c-c++-common/fcf-protection-7.c on aarch64-none-linux.gnu. Would you
> mind
> taking a look?
> 
> Your new tests will always FAIL on non-x86 targets (for example
> aarch64-none-linux-gnu). Is dg-error really the right directive, that is a
> guaranteed FAIL, I would expect a skip.
> 
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug tree-optimization/83456] -Wrestrict false positive on a non-overlapping memcpy in an inline function

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-06
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=84095
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Here's a slightly different test case, this one from bug 84095 comment 14
(reduced from bug 84095 comment 17).  I'll confirm this bug based on that one.

$ cat t.c && gcc -O2 -S -Wall t.c
extern void* memcpy (void*, const void*, __SIZE_TYPE__);

char a[4];

void f (unsigned n)
{
  for (int i = 0; i < 1; i++)
{
  if (!i)
continue;

  memcpy (a, a, n);
}
}
t.c: In function ‘f’:
t.c:12:7: warning: ‘memcpy’ source argument is the same as destination
[-Wrestrict]
   memcpy (a, a, n);
   ^~~~

[Bug middle-end/84095] [8 Regression] false-positive -Wrestrict warnings for memcpy within array

[msebor at gcc dot gnu.org]

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

--- Comment #17 from Martin Sebor  ---
I've reduced the test case from comment #14 to the one below.  I'm inclined to
think the warning is justified.  As you say, the code clearly does use the same
pointer for both the source and the destination, so the code is strictly not
valid.  GCC ultimately eliminates the memcpy call and the whole loop, but not
before it notices the argument is the same.  The warning is issued in the same
places as the one for bug 83456 so if a decision is made to fix that bug this
warning will also disappear.

$ cat t.c && gcc -O2 -S -Wall t.c
extern void* memcpy (void*, const void*, __SIZE_TYPE__);

char a[4];

void f (unsigned n)
{
  for (int i = 0; i < 1; i++)
{
  if (!i)
continue;

  memcpy (a, a, n);
}
}
t.c: In function ‘f’:
t.c:12:7: warning: ‘memcpy’ source argument is the same as destination
[-Wrestrict]
   memcpy (a, a, n);
   ^~~~

[Bug c/82210] [6/7/8 Regression] Having _Alignas in a struct with VLAs causes writing to one array to overwrite another

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org

--- Comment #3 from Aldy Hernandez  ---
Even with aligned, as Richard points out:

struct {
__attribute__((aligned(16)))
struct {
short aa;
} a[size];
int b[size];
} s;

the .original dump setting s.b[i]=0 is:

  s.b{off: (sizetype) SAVE_EXPR  * 2}[i] = 0;

I would have expected size * 2 plus magic to round up to 16 bytes.  It looks
like we're throwing away the alignment.

As a reference, without the aligned attribute we get:

  s.b{off: (sizetype) SAVE_EXPR  * 2 + 3 & 18446744073709551612}[i] = 0;

  Note: C operator precedence actually yields (size * 2 + 3) & blah

Which is rounding up to 4 byte alignment.

I'll investigate.

[Bug fortran/84246] New: [7/8 Regression] ICE in conv_caf_send, at fortran/trans-intrinsic.c:1950

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

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

Bug ID: 84246
   Summary: [7/8 Regression] ICE in conv_caf_send, at
fortran/trans-intrinsic.c:1950
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed between 20161127 and 20161204 :


$ cat z1.f90
program p
   type t
  character(:), allocatable :: a
   end type
   type(t) :: x[*], y[*]
   x%a = 'abc'
   y%a = x%a
end


$ cat z2.f90
program p
   type t
  character(:), allocatable :: a
   end type
   type(t) :: x[*], y[*]
   allocate (x%a, source='abc')
   y%a = x%a
end


$ gfortran-7-20161127 -c z1.f90 -fcoarray=lib
$
$ gfortran-8-20180204 -c z1.f90 -fcoarray=lib
z1.f90:7:0:

y%a = x%a

internal compiler error: in conv_caf_send, at fortran/trans-intrinsic.c:1950
0x79194d conv_caf_send
../../gcc/fortran/trans-intrinsic.c:1950
0x7973cb gfc_conv_intrinsic_subroutine(gfc_code*)
../../gcc/fortran/trans-intrinsic.c:10777
0x785803 gfc_trans_assignment_1
../../gcc/fortran/trans-expr.c:10210
0x7496c7 trans_code
../../gcc/fortran/trans.c:1828
0x770779 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6490
0x700040 translate_all_program_units
../../gcc/fortran/parse.c:6121
0x700040 gfc_parse_file()
../../gcc/fortran/parse.c:6324
0x74686f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/84245] New: [7/8 Regression] ICE in delete_root, at fortran/bbt.c:150

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

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

Bug ID: 84245
   Summary: [7/8 Regression] ICE in delete_root, at
fortran/bbt.c:150
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed between 20161023 and 20161030 :


$ cat z1.f90
program p
   select type (x%a)
   end select
end


$ cat z2.f90
program p
   select type (x%
   end select
end


$ gfortran-7-20161023 -c z1.f90
z1.f90:2:18:

select type (x%a)
  1
Error: Symbol 'x' at (1) has no IMPLICIT type
z1.f90:3:6:

end select
  1
Error: Expecting END PROGRAM statement at (1)


$ gfortran-8-20180204 -c z1.f90
f951: internal compiler error: Segmentation fault
0xb953ff crash_signal
../../gcc/toplev.c:325
0x67b0bb delete_root
../../gcc/fortran/bbt.c:150
0x67b28e gfc_delete_bbt(void*, void*, int (*)(void*, void*))
../../gcc/fortran/bbt.c:197
0x737048 gfc_delete_symtree(gfc_symtree**, char const*)
../../gcc/fortran/symbol.c:2925
0x738816 gfc_restore_last_undo_checkpoint()
../../gcc/fortran/symbol.c:3694
0x6f5347 reject_statement
../../gcc/fortran/parse.c:2565
0x6f545c match_word_omp_simd
../../gcc/fortran/parse.c:98
0x6f8e0a match_word
../../gcc/fortran/parse.c:428
0x6f8e0a decode_statement
../../gcc/fortran/parse.c:428
0x6faa54 next_free
../../gcc/fortran/parse.c:1230
0x6faa54 next_statement
../../gcc/fortran/parse.c:1462
0x6fc86c parse_spec
../../gcc/fortran/parse.c:3670
0x6fe833 parse_progunit
../../gcc/fortran/parse.c:5667
0x6ffe14 gfc_parse_file()
../../gcc/fortran/parse.c:6207
0x74686f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug middle-end/84095] [8 Regression] false-positive -Wrestrict warnings for memcpy within array

[msebor at gcc dot gnu.org]

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

--- Comment #16 from Martin Sebor  ---
Thanks for the test case in comment #14.  I've reproduced the warning and will
look into it.

The false positive from comment #9 isn't fixed yet.  I'm assuming it's due to
the same root cause as bug 83456 that I'm tracking separately.  There's no way
to avoid that one other than by disabling the warning in a whole set of cases. 
I'm trying to decide if trading the false positives for the unavoidable false
negatives make sense.

[Bug fortran/84244] New: [7/8 Regression] ICE in recompute_tree_invariant_for_addr_expr, at tree.c:4535

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

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

Bug ID: 84244
   Summary: [7/8 Regression] ICE in
recompute_tree_invariant_for_addr_expr, at tree.c:4535
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Function f in z1.f90 is not used, z2.f90 without f compiles.
Changed between 20161218 and 20170108.


$ cat z1.f90
program p
   real, target :: a = 1.0
   type t
  real, pointer :: q
   end type
   type(t) :: z[*]
   z%q => a
contains
   function f(x)
  type(t), intent(in) :: x
   end
end


$ cat z2.f90
program p
   real, target :: a = 1.0
   type t
  real, pointer :: q
   end type
   type(t) :: z[*]
   z%q => a
end


$ gfortran-7-20161218 -c z1.f90 -fcoarray=lib
$
$ gfortran-8-20180204 -c z1.f90 -fcoarray=lib
z1.f90:11:0:

end

internal compiler error: Segmentation fault
0xb953ff crash_signal
../../gcc/toplev.c:325
0xdca5d4 recompute_tree_invariant_for_addr_expr(tree_node*)
../../gcc/tree.c:4535
0xdca8c1 build1(tree_code, tree_node*, tree_node*)
../../gcc/tree.c:4635
0x92233c build1_loc
../../gcc/tree.h:4102
0x92233c fold_build1_loc(unsigned int, tree_code, tree_node*, tree_node*)
../../gcc/fold-const.c:12284
0x7497af gfc_build_addr_expr(tree_node*, tree_node*)
../../gcc/fortran/trans.c:298
0x75d208 structure_alloc_comps
../../gcc/fortran/trans-array.c:8782
0x76588e generate_coarray_sym_init
../../gcc/fortran/trans-decl.c:5369
0x7341cb do_traverse_symtree
../../gcc/fortran/symbol.c:4157
0x764a45 generate_coarray_init
../../gcc/fortran/trans-decl.c:5410
0x770bfc gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6428
0x700040 translate_all_program_units
../../gcc/fortran/parse.c:6121
0x700040 gfc_parse_file()
../../gcc/fortran/parse.c:6324
0x74686f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug tree-optimization/82518] [8 regression] gfortran.fortran-torture/execute/in-pack.f90 fails on armeb since r252917

[aldyh at gcc dot gnu.org]

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

--- Comment #30 from Aldy Hernandez  ---
(In reply to Christophe Lyon from comment #29)
> I still haven't found a commit where the test passes with
> -fno-vect-cost-model (before -O3).
> 
> I went back to r193053 (Nov 1, 2012), where I was able to build GCC but the
> test fails.
> With a revision 1 month earlier, the GCC fails to build.
> I tried with earlier revision, but soon reached a point where
> "-mfloat-abi=hard and VFP" is not implemented.

Ok, bisecting isn't getting us anywhere.  I apologize for making you going
through all this in vain.

Could you further reduce the testcase as I suggested in comment 12, and perhaps
we can start looking at the assembly to see where things are going wrong?

[Bug c++/84222] [6/7/8 Regression] [[deprecated]] class complains about internal class usage

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Blocks||79078

--- Comment #4 from Martin Sebor  ---
This is a subset of bug 79078 that lists a number of problems with the handling
of attribute deprecated.  I'm keeping this one open independent of the latter
since this is a regression.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79078
[Bug 79078] Warnings from deprecated attribute are too noisy

[Bug tree-optimization/84225] [8 Regression] ICE in operation_no_trapping_overflow, at tree.c:7206

[aldyh at gcc dot gnu.org]

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

--- Comment #5 from Aldy Hernandez  ---
Author: aldyh
Date: Tue Feb  6 17:11:01 2018
New Revision: 257420

URL: https://gcc.gnu.org/viewcvs?rev=257420=gcc=rev
Log:
PR tree-optimization/84225
Add test for previous commit for PR84225.

Added:
trunk/gcc/testsuite/gcc.dg/pr84225.c

[Bug testsuite/84243] New: [8 Regression] gcc.target/i386/cet-intrin-4.c at r257414

[jgreenhalgh at gcc dot gnu.org]

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

Bug ID: 84243
   Summary: [8 Regression] gcc.target/i386/cet-intrin-4.c at
r257414
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jgreenhalgh at gcc dot gnu.org
CC: itsimbal at gcc dot gnu.org
  Target Milestone: ---
Target: x86-64-none-linux-gnu, aarch64-none-linux-gnu

Hi, our bisect robot spotted a failure in gcc.target/i386/cet-intrin-3.c,
gcc.target/i386/cet-intrin-4.c, after revision r257414 on
x86-64-none-linux-gnu, and c-c++-common/fcf-protection-6.c and
c-c++-common/fcf-protection-7.c on aarch64-none-linux.gnu. Would you mind
taking a look?

Your new tests will always FAIL on non-x86 targets (for example
aarch64-none-linux-gnu). Is dg-error really the right directive, that is a
guaranteed FAIL, I would expect a skip.

[Bug c++/84222] [6/7/8 Regression] [[deprecated]] class complains about internal class usage

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 CC||msebor at gcc dot gnu.org
  Known to work||4.2.3
Summary|[[deprecated]] class|[6/7/8 Regression]
   |complains about internal|[[deprecated]] class
   |class usage |complains about internal
   ||class usage
  Known to fail||4.3.4, 4.5.4, 4.8.3, 4.9.3,
   ||5.3.0, 6.2.0, 7.1.0, 8.0

--- Comment #3 from Martin Sebor  ---
Confirmed with the following simplified C++ 98 test case:

$ cat pr84222.C && gcc -O2 -c -g -Wall pr84222.C
struct __attribute__ ((deprecated)) C {
C() {}
C(const C&);  // emits a deprecation warning
};
pr84222.C:3:15: warning: ‘C’ is deprecated [-Wdeprecated-declarations]
 C(const C&);  // emits a deprecation warning
   ^

It's a very old regression introduced in GCC 4.3.  The likely candidate is 
r128691:

PR c++/16370
* decl.c (grokdeclarator): Look through implicit TYPE_DECLs
for deprecation warnings.

[Bug lto/84241] [8 regression] test case g++.dg/torture/pr67600.C fails starting with r257412

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

 CC||jgreenhalgh at gcc dot gnu.org

--- Comment #2 from Richard Earnshaw  ---
*** Bug 84242 has been marked as a duplicate of this bug. ***

[Bug lto/84242] [8 Regression] g++.dg/torture/pr67600.C at r257412

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Richard Earnshaw  ---
Dup

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

[Bug tree-optimization/82518] [8 regression] gfortran.fortran-torture/execute/in-pack.f90 fails on armeb since r252917

[clyon at gcc dot gnu.org]

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

--- Comment #29 from Christophe Lyon  ---
I still haven't found a commit where the test passes with -fno-vect-cost-model
(before -O3).

I went back to r193053 (Nov 1, 2012), where I was able to build GCC but the
test fails.
With a revision 1 month earlier, the GCC fails to build.
I tried with earlier revision, but soon reached a point where "-mfloat-abi=hard
and VFP" is not implemented.

[Bug lto/84242] [8 Regression] g++.dg/torture/pr67600.C at r257412

[jgreenhalgh at gcc dot gnu.org]

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

--- Comment #1 from James Greenhalgh  ---
Also gcc.target/i386/mvc9.c on x86-64-none-linux-gnu.

[Bug lto/84242] New: [8 Regression] g++.dg/torture/pr67600.C at r257412

[jgreenhalgh at gcc dot gnu.org]

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

Bug ID: 84242
   Summary: [8 Regression] g++.dg/torture/pr67600.C at r257412
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jgreenhalgh at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64-none-linux-gnu, x86-64-none-linux-gnu

Hi

Our testing robot spotted a failure in g++.dg/torture/pr67600.C, after revision
r257412 on aarch64-none-linux-gnu and x86-64-none-linux-gnu. Would you mind
taking a look?

[Bug lto/84241] [8 regression] test case g++.dg/torture/pr67600.C fails starting with r257412

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Target||powerpc64-unknown-linux-gnu
   ||, aarch64-none-linux-gnu
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-06
 CC||ktkachov at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||8.0

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed on aarch64 as well.

[Bug target/78303] PowerPC vec-init-{1,2,4,5,8,9} tests do not run on -mlittle -maltivec=be

[kelvin at gcc dot gnu.org]

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

kelvin at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kelvin at gcc dot gnu.org

--- Comment #2 from kelvin at gcc dot gnu.org ---
The gcc.pdf documentation states the following:

-maltivec=be
Generate  AltiVec  instructions  using  big-endian  element  order,  regardless
 of whether  the  target  is  big-  or  little-endian.   This  is  the  default
 when  targeting a big-endian platform.  The element order is used to interpret
element numbers in AltiVec intrinsics such as vec_splat, vec_extract, and
vec_insert.  By default, these match array element order corresponding to the
endianness for the target.

Should this documentation be clarified?  As I ponder the problem, it is not
clear to me whether I should be fixing the load and store operations, or fixing
the layout of the "initialization vectors" in memory.

Suppose I have code such as the following:

static vector int v = { 0, 1, 2, 3 };
int *ip = (int *) 
fprintf (stderr, "The vector contains { %d, %d, %d, %d }\n", 
 ip[0], ip[1], ip[2], ip[3]);

Do I expect different output depending on whether this program is compiled with
-maltivec=be?

My first inclination is to do "extra swapping" (or undo existing swapping) on
each load and store if the "Altivec element ordering" is different than the
target's default ordering.  It's not entirely clear if this is what was
intended.

[Bug target/57547] Missing vector intrinsics in PowerPC Altivec documentation

[kelvin at gcc dot gnu.org]

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

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

Oops.  Sent that comment to the wrong bugzilla.  Please disregard.

[Bug lto/84241] New: [8 regression] test case g++.dg/torture/pr67600.C fails starting with r257412

[seurer at linux dot vnet.ibm.com]

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

Bug ID: 84241
   Summary: [8 regression] test case g++.dg/torture/pr67600.C
fails starting with r257412
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at linux dot vnet.ibm.com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Executing on host: /home/seurer/gcc/build/gcc-test/gcc/testsuite/g++/../../xg++
-B/home/seurer/gcc/build/gcc-test/gcc/testsuite/g++/../../
/home/seurer/gcc/gcc-test/gcc/testsuite/g++.dg/torture/pr67600.C 
-fno-diagnostics-show-caret -fdiagnostics-color=never  -nostdinc++
-I/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-test/libstdc++-v3/libsupc++
-I/home/seurer/gcc/gcc-test/libstdc++-v3/include/backward
-I/home/seurer/gcc/gcc-test/libstdc++-v3/testsuite/util -fmessage-length=0  
-O2 -flto -fuse-linker-plugin -fno-fat-lto-objects 
-L/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs

-B/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs

-L/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-B/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libitm/
-L/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libitm/.libs
-lm-o ./pr67600.exe(timeout = 300)
spawn -ignore SIGHUP
/home/seurer/gcc/build/gcc-test/gcc/testsuite/g++/../../xg++
-B/home/seurer/gcc/build/gcc-test/gcc/testsuite/g++/../../
/home/seurer/gcc/gcc-test/gcc/testsuite/g++.dg/torture/pr67600.C
-fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++
-I/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-test/libstdc++-v3/libsupc++
-I/home/seurer/gcc/gcc-test/libstdc++-v3/include/backward
-I/home/seurer/gcc/gcc-test/libstdc++-v3/testsuite/util -fmessage-length=0 -O2
-flto -fuse-linker-plugin -fno-fat-lto-objects
-L/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-B/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-L/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-B/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libitm/
-L/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libitm/.libs
-lm -o ./pr67600.exe
lto1: fatal error: missing resolution data for
_ZTCNSt7__cxx1119basic_ostringstreamIcSt11char_traitsIcESaIcEEE0_So
compilation terminated.
lto-wrapper: fatal error:
/home/seurer/gcc/build/gcc-test/gcc/testsuite/g++/../../xg++ returned 1 exit
status
compilation terminated.
/home/seurer/binutils/install/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
compiler exited with status 1
output is:
lto1: fatal error: missing resolution data for
_ZTCNSt7__cxx1119basic_ostringstreamIcSt11char_traitsIcESaIcEEE0_So
compilation terminated.
lto-wrapper: fatal error:
/home/seurer/gcc/build/gcc-test/gcc/testsuite/g++/../../xg++ returned 1 exit
status
compilation terminated.
/home/seurer/binutils/install/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status

FAIL: g++.dg/torture/pr67600.C   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  (test for excess errors)
Excess errors:
lto1: fatal error: missing resolution data for
_ZTCNSt7__cxx1119basic_ostringstreamIcSt11char_traitsIcESaIcEEE0_So
compilation terminated.

[Bug target/57547] Missing vector intrinsics in PowerPC Altivec documentation

[kelvin at gcc dot gnu.org]

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

--- Comment #2 from kelvin at gcc dot gnu.org ---
The gcc.pdf documentation states the following:

-maltivec=be
Generate  AltiVec  instructions  using  big-endian  element  order,  regardless
 of whether  the  target  is  big-  or  little-endian.   This  is  the  default
 when  targeting a big-endian platform.  The element order is used to interpret
element numbers in AltiVec intrinsics such as vec_splat, vec_extract, and
vec_insert.  By default, these match array element order corresponding to the
endianness for the target.

Should this documentation be clarified?  As I ponder the problem, it is not
clear to me whether I should be fixing the load and store operations, or fixing
the layout of the "initialization vectors" in memory.

Suppose I have code such as the following:

static vector int v = { 0, 1, 2, 3 };
int *ip = (int *) 
fprintf (stderr, "The vector contains { %d, %d, %d, %d }\n", 
 ip[0], ip[1], ip[2], ip[3]);

Do I expect different output depending on whether this program is compiled with
-maltivec=be?

My first inclination is to do "extra swapping" (or undo existing swapping) on
each load and store if the "Altivec element ordering" is different than the
target's default ordering.  It's not entirely clear if this is what was
intended.

[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE

[andrewjenner at gcc dot gnu.org]

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

--- Comment #17 from Andrew Jenner  ---
I have committed another small patch to the .opt files:
https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00247.html

and updated my docs patch per Joseph's feedback:
https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00248.html

[Bug target/83828] FAIL: gcc.target/i386/avx512vpopcntdqvl-vpopcntq-1.c execution test

[hjl.tools at gmail dot com]

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

--- Comment #11 from H.J. Lu  ---
(In reply to Kirill Yukhin from comment #10)
> HJ, I cannot reproduce this fail on recent SDE.
> 
> Here's what I have in gcc.log:
> 
> spawn -ignore SIGHUP /export/kyukhin/gcc/bld-svn/build-x86_64-linux/gcc/xgcc
> -B/export/kyukhin/gcc/bld-svn/build-x86_64-linux/gcc/
> /export/kyukhin/gcc/svn/trunk/gcc/testsuite/gcc.target/i386/avx512bitalgvl-
> vpopc\
> ntb-1.c -fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -mavx512vl
> -mavx512bitalg -mavx512bw -lm -o ./avx512bitalgvl-vpopcntb-1.exe^M
> PASS: gcc.target/i386/avx512bitalgvl-vpopcntb-1.c (test for excess errors)
> Setting LD_LIBRARY_PATH to
> :/export/kyukhin/gcc/bld-svn/build-x86_64-linux/gcc:/export/kyukhin/gcc/bld-
> svn/build-x86_64-linux/gcc/32:
> spawn /home/kyukhin/bin/dejagnu/sde-sim ./avx512bitalgvl-vpopcntb-1.exe^M
> PASS: gcc.target/i386/avx512bitalgvl-vpopcntb-1.c execution test
> 
> I've also verified manually that test PASS, not SKIPPED.

You can't reproduce it with SDE since it emulates the new AVX512 instructions.
Olga posted a patch at:

https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00209.html

[Bug c++/81674] gcc cannot detect missing initialisers for fields in constructors

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
But -Weffc++ also warns about members that don't need to be initialized, so is
useless in detecting uninitialized data.

[Bug tree-optimization/84225] [8 Regression] ICE in operation_no_trapping_overflow, at tree.c:7206

[aldyh at gcc dot gnu.org]

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

--- Comment #3 from Aldy Hernandez  ---
Author: aldyh
Date: Tue Feb  6 15:44:51 2018
New Revision: 257416

URL: https://gcc.gnu.org/viewcvs?rev=257416=gcc=rev
Log:
PR tree-optimization/84225
* tree-eh.c (find_trapping_overflow): Only call
operation_no_trapping_overflow when ANY_INTEGRAL_TYPE_P.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-eh.c

[Bug tree-optimization/84225] [8 Regression] ICE in operation_no_trapping_overflow, at tree.c:7206

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

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

--- Comment #4 from Aldy Hernandez  ---
Fixed in trunk.

[Bug c/84100] [7 Regression] Function __attribute__((optimize(align-loops=32))) gives spurious warning

[marxin at gcc dot gnu.org]

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

--- Comment #9 from Martin Liška  ---
And I see very similar problem for -falign-loops, ...

[Bug c++/84177] Attributes on C++17 nested namespaces

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=79817

--- Comment #1 from Eric Gallager  ---
Possibly related: bug 79817

[Bug c++/81674] gcc cannot detect missing initialisers for fields in constructors

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #3 from Eric Gallager  ---
-Weffc++ catches it:

$ $ /usr/local/bin/g++ -c -O2 -Wall -Wextra -pedantic -Weffc++ 81674.cc
81674.cc: In constructor 'S::S()':
81674.cc:5:3: warning: 'S::b' should be initialized in the member
initialization list [-Weffc++]
   S() : a( 0)
   ^
81674.cc:5:3: warning: 'S::c' should be initialized in the member
initialization list [-Weffc++]
$

[Bug c/84240] New: Error in extract_constrain_insn, at recog.c:2246

[xvl5190 at psu dot edu]

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

Bug ID: 84240
   Summary: Error in extract_constrain_insn, at recog.c:2246
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xvl5190 at psu dot edu
  Target Milestone: ---

Building modified tests by turning on the optimizations. Get internal errors:

gcc -w -O1 asm-flag-6.c_0.1.c 
asm-flag-6.c_0.1.c: In function ‘TestP’:
asm-flag-6.c_0.1.c:5:2: error: unrecognizable insn:
  __asm__ ("addb $1, %1" : "=@ccnp"(r), "+r"(res)); if (r) return 1; } return
0; } char TestS () { char r, res = 1; /* sign bit set. 
  ^
(insn 13 12 16 3 (parallel [
(set (reg:QI 0 ax [orig:96 r ] [96])
(asm_operands:QI ("addb $1, %1") ("=@ccnp") 0 [
(reg:QI 1 dx [orig:97 res ] [97])
]
 [
(asm_input:QI ("1") asm-flag-6.c_0.1.c:5)
]
 [] asm-flag-6.c_0.1.c:5))
(set (reg:QI 1 dx [orig:97 res ] [97])
(asm_operands:QI ("addb $1, %1") ("=r") 1 [
(reg:QI 1 dx [orig:97 res ] [97])
]
 [
(asm_input:QI ("1") asm-flag-6.c_0.1.c:5)
]
 [] asm-flag-6.c_0.1.c:5))
(clobber (reg:QI 18 fpsr))
(clobber (reg:QI 17 flags))
]) asm-flag-6.c_0.1.c:5 -1
 (nil))
asm-flag-6.c_0.1.c:5:2: internal compiler error: in extract_constrain_insn, at
recog.c:2246
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug target/84145] Wrong CET options processing

[itsimbal at gcc dot gnu.org]

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

--- Comment #3 from itsimbal at gcc dot gnu.org ---
Author: itsimbal
Date: Tue Feb  6 15:25:31 2018
New Revision: 257414

URL: https://gcc.gnu.org/viewcvs?rev=257414=gcc=rev
Log:
Fix checking -mibt and -mshstk options for control flow protection

PR target/84145
* config/i386/i386.c: Reimplement the check of possible options
-mibt/-mshstk conbination. Change error messages.
* doc/invoke.texi: Fix a typo: remove extra '='.
* c-c++-common/fcf-protection-1.c: Change a compared message.
* c-c++-common/fcf-protection-2.c: Likewise.
* c-c++-common/fcf-protection-3.c: Likewise.
* c-c++-common/fcf-protection-5.c: Likewise.
* c-c++-common/fcf-protection-6.c: New test.
* c-c++-common/fcf-protection-7.c: Likewise.

Added:
trunk/gcc/testsuite/c-c++-common/fcf-protection-6.c
trunk/gcc/testsuite/c-c++-common/fcf-protection-7.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/doc/invoke.texi
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/fcf-protection-1.c
trunk/gcc/testsuite/c-c++-common/fcf-protection-2.c
trunk/gcc/testsuite/c-c++-common/fcf-protection-3.c
trunk/gcc/testsuite/c-c++-common/fcf-protection-5.c

[Bug tree-optimization/84238] [8 Regression] ICE tree check: expected integer_cst, have plus_expr in to_wide, at tree.h:5527

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Untested fix:

--- a/gcc/tree-ssa-strlen.c
+++ b/gcc/tree-ssa-strlen.c
@@ -1899,7 +1899,10 @@ maybe_diag_stxncpy_trunc (gimple_stmt_iterator gsi, tree
src, tree cnt)
 {
   tree range[2];
   get_range_strlen (src, range);
-  if (range[0])
+  if (range[0] != NULL_TREE
+ && TREE_CODE (range[0]) == INTEGER_CST
+ && range[1] != NULL_TREE
+ && TREE_CODE (range[1]) == INTEGER_CST)
{
  lenrange[0] = wi::to_wide (range[0], prec);
  lenrange[1] = wi::to_wide (range[1], prec);

[Bug target/84239] New: Reimplement rdssp[d|q] and incssp[d|q] CET intrinsics

[igor.v.tsimbalist at intel dot com]

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

Bug ID: 84239
   Summary: Reimplement rdssp[d|q] and incssp[d|q] CET intrinsics
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: igor.v.tsimbalist at intel dot com
  Target Milestone: ---

There was an online discussion related to syncing CET intrinsic names between 3
compilers, gcc, llvm and icc. The intrinsics in question were rdssp[d|q] and
incssp[d|q]. It was agreed that:

* new utility intrinsics should be introduced:
#ifdef _x86_64_
__int64 _get_ssp(void);
#else
__int32 _get_ssp(void);
#endif
void _inc_ssp(unsigned int);

* it's up to a compiler to provide the initial intrinsics, which maps 1:1 to
the instruction.

* GCC compiler is going to provide utility intrinsics only.

The current intrinsic implementation for rdssp[d|q] and incssp[d|q] has to
updated to reflect the decision.

[Bug middle-end/84237] [8 Regression] xen build faiulre only zero initializers are allowed in section '.bss.page_aligned.const'

[jakub at gcc dot gnu.org]

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

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

Untested fix.

[Bug lto/81004] [7 Regression] linking failed with -flto and static libboost_program_options

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

Summary|[7/8 Regression] linking|[7 Regression] linking
   |failed with -flto and   |failed with -flto and
   |static  |static
   |libboost_program_options|libboost_program_options

--- Comment #26 from Jan Hubicka  ---
Fixed on trunk so far. Note that the issue affects all releases with LTO even
if the testcase reproduces only with GCC 7. So we probably want to backport to
all active release branches.

[Bug fortran/84217] [8 Regression] ICE: verify_gimple failed

[vries at gcc dot gnu.org]

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

--- Comment #4 from Tom de Vries  ---
C testcase:
...
void
foo (void)
{
  #pragma acc parallel loop tile (2, 3)
  for (short i = 0; i < 10; ++i)
for (short j = 0; j < 10; ++j)
  ;
}
...

[Bug fortran/84217] [8 Regression] ICE: verify_gimple failed

[vries at gcc dot gnu.org]

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

--- Comment #3 from Tom de Vries  ---
Tentative patch:
...
diff --git a/gcc/omp-expand.c b/gcc/omp-expand.c
index 90e0631..bb20490 100644
--- a/gcc/omp-expand.c
+++ b/gcc/omp-expand.c
@@ -1433,6 +1433,8 @@ expand_oacc_collapse_init (const struct omp_for_data *fd,
plus_type = sizetype;
   if (POINTER_TYPE_P (diff_type) || TYPE_UNSIGNED (diff_type))
diff_type = signed_type_for (diff_type);
+  if (TYPE_PRECISION (diff_type) < TYPE_PRECISION (integer_type_node))
+   diff_type = integer_type_node;

   if (tiling)
{
...

[Bug tree-optimization/84238] [8 Regression] ICE tree check: expected integer_cst, have plus_expr in to_wide, at tree.h:5527

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

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

[Bug tree-optimization/84238] [8 Regression] ICE tree check: expected integer_cst, have plus_expr in to_wide, at tree.h:5527

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Priority|P3  |P1
   Last reconfirmed||2018-2-6
  Known to work||7.3.0
   Target Milestone|--- |8.0
  Known to fail||8.0

[Bug tree-optimization/84238] New: [8 Regression] ICE tree check: expected integer_cst, have plus_expr in to_wide, at tree.h:5527

[marxin at gcc dot gnu.org]

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

Bug ID: 84238
   Summary: [8 Regression] ICE tree check: expected integer_cst,
have plus_expr in to_wide, at tree.h:5527
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: msebor at gcc dot gnu.org
  Target Milestone: ---

Starting from r256457 we ICE on:

$ cat ice.i
char a[1];
int b;
char *strncpy (char *, char *, long);
void
c ()
{
  char d[b];
  strncpy (a, [3], 3);
}

$ gcc -O2 -g ice.i
during GIMPLE pass: strlen
ice.i: In function ‘c’:
ice.i:5:1: internal compiler error: tree check: expected integer_cst, have
plus_expr in to_wide, at tree.h:5527
 c ()
 ^
0x5c76a6 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/tree.c:9325
0x6fbce5 tree_check(tree_node const*, char const*, int, char const*, tree_code)
../../gcc/tree.h:3388
0x6fbce5 wi::to_wide(tree_node const*)
../../gcc/tree.h:5527
0x6fbce5 wi::to_wide(tree_node const*, unsigned int)
../../gcc/tree.h:5538
0xdc8180 maybe_diag_stxncpy_trunc
../../gcc/tree-ssa-strlen.c:1905
0xdc8b52 handle_builtin_stxncpy
../../gcc/tree-ssa-strlen.c:2076
0xdcc05f strlen_check_and_optimize_stmt
../../gcc/tree-ssa-strlen.c:3139
0xdcc05f strlen_dom_walker::before_dom_children(basic_block_def*)
../../gcc/tree-ssa-strlen.c:3472
0x13851b7 dom_walker::walk(basic_block_def*)
../../gcc/domwalk.c:353
0xdc64a7 execute
../../gcc/tree-ssa-strlen.c:3552
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug middle-end/84237] [8 Regression] xen build faiulre only zero initializers are allowed in section '.bss.page_aligned.const'

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-02-06
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

[Bug middle-end/84237] New: [8 Regression] xen build faiulre only zero initializers are allowed in section '.bss.page_aligned.const'

[jakub at gcc dot gnu.org]

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

Bug ID: 84237
   Summary: [8 Regression] xen build faiulre only zero
initializers are allowed in section
'.bss.page_aligned.const'
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

const char __attribute__((__section__(".bss.page_aligned.const"),
__aligned__(4096))) zero_page[4096];
is rejected starting with r251602.  I think if the user explicitly requests it
to be put into a bss section, we should do it even when it is read-only.

[Bug go/84215] Random results in go/libgo tests

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-06
 Ever confirmed|0   |1

--- Comment #4 from H.J. Lu  ---
FWIW, I have seen these on i686 and x86-64.  They are purely random.

[Bug tree-optimization/82518] [8 regression] gfortran.fortran-torture/execute/in-pack.f90 fails on armeb since r252917

[clyon at gcc dot gnu.org]

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

--- Comment #28 from Christophe Lyon  ---
It's possible that my bisect script got confused by the fact the GCC started
ICEing at -O2 on this test at r197671.

Investigating

[Bug tree-optimization/84235] [8 Regression] Miscompilation of floating point code by dom2

[jakub at gcc dot gnu.org]

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

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

Untested fix.

[Bug go/84215] Random results in go/libgo tests

[clyon at gcc dot gnu.org]

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

--- Comment #3 from Christophe Lyon  ---

> FAIL: context
> but the next build is still running, I don't know yet if it passes.

Next build completed, and:
PASS: context

Did something change wrt this test since yesterday?

[Bug tree-optimization/84235] [8 Regression] Miscompilation of floating point code by dom2

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-02-06
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

[Bug tree-optimization/84235] New: [8 Regression] Miscompilation of floating point code by dom2

[jakub at gcc dot gnu.org]

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

Bug ID: 84235
   Summary: [8 Regression] Miscompilation of floating point code
by dom2
   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: ---

int
main ()
{
  double d = 1.0 / 0.0;
  _Bool b = d == d && (d - d) != (d - d);
  if (!b)
__builtin_abort ();
  return 0;
}

is miscompiled at -O2 starting with r251279.  I have a fix.

[Bug middle-end/84234] New: #pragma omp declare simd is ignored

[gcc.account at lemaitre dot re]

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

Bug ID: 84234
   Summary: #pragma omp declare simd is ignored
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc.account at lemaitre dot re
  Target Milestone: ---

Created attachment 43344
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43344=edit
Simple example showing the bug: gcc -O3 -fopenmp-simd

When I try to use #pragma omp declare simd on a forward declaration, it seems
to be ignored during vectorization at the call site.

ex:
#pragma omp declare simd
float add2(float a, float b);
void ADD2() {
  for (int i = 0; i < 1024; i++) {
A[i] = add2(A[i], B[i]);
  }
}

is compiled into:
ADD2:
.LFB2:
  .cfi_startproc
  pushq %rbx
  .cfi_def_cfa_offset 16
  .cfi_offset 3, -16
  xorl  %ebx, %ebx
  .p2align 4,,10
  .p2align 3
.L19:
  movss B(%rbx), %xmm1
  addq  $4, %rbx
  movss A-4(%rbx), %xmm0
  call  add2
  movss %xmm0, A-4(%rbx)
  cmpq  $4096, %rbx
  jne .L19
  popq  %rbx
  .cfi_def_cfa_offset 8
  ret
  .cfi_endproc


where
#pragma omp declare simd
float __attribute((noinline)) add1(float a, float b) {
  return a+b;
}
void ADD1() {
  for (int i = 0; i < 1024; i++) {
A[i] = add1(A[i], B[i]);
  }
}

is compiled into:
ADD1:
.LFB1:
  .cfi_startproc
  pushq %rbx
  .cfi_def_cfa_offset 16
  .cfi_offset 3, -16
  xorl  %ebx, %ebx
  .p2align 4,,10
  .p2align 3
.L15:
  movaps  A(%rbx), %xmm0
  addq  $16, %rbx
  movaps  B-16(%rbx), %xmm1
  call  _ZGVbN4vv_add1
  movaps  %xmm0, A-16(%rbx)
  cmpq  $4096, %rbx
  jne .L15
  popq  %rbx
  .cfi_def_cfa_offset 8
  ret
  .cfi_endproc

When the function has no definition, the compiler doesn't use the vectorized
variant of the function.
This also happens if one tries to give the definition of the function, but
defines the symbol as weak.

This is really annoying as we have to put the definition of such a function
within the same translation unit as it uses, with all problems that might
occur.

This bug is present on all gcc versions I tested, namely: GCC 4.9 x86, GCC 5.5
x86, GCC 6.4 x86, GCC 7.3 x86 and GCC trunk x86 (from godbolt.org).
On other architectures, the pragma seems to be always ignored, even when a
definition is available (GCC 7.2 ARM, GCC 6.3 AARCH64, GCC 6.3 PPC64).

For information, this works as expected on ICC.

[Bug c/84100] [7 Regression] Function __attribute__((optimize(align-loops=32))) gives spurious warning

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
   Assignee|jakub at gcc dot gnu.org   |marxin at gcc dot 
gnu.org

--- Comment #8 from Martin Liška  ---
I see one another problem with usage of the pragma:

$ cat lbm.i
void a (void) {}
#pragma GCC push_options
#pragma GCC optimize "align-functions=128"
void b (void) {}
#pragma GCC pop_options
void c (void) {}

$ ./xgcc -B. -O2 -S lbm.i -c -o/dev/stdout
.file   "lbm.i"
.text
.p2align 4,,15
.globl  a
.type   a, @function
a:
.LFB0:
.cfi_startproc
ret
.cfi_endproc
.LFE0:
.size   a, .-a
.p2align 4,,127 < THIS is wrong as it should be '6,,127'
.globl  b
.type   b, @function
b:
.LFB1:
.cfi_startproc
ret
.cfi_endproc
.LFE1:
.size   b, .-b
...

I've got patch for that, let me Jakub take this PR.

[Bug middle-end/84095] [8 Regression] false-positive -Wrestrict warnings for memcpy within array

[arnd at linaro dot org]

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

--- Comment #15 from Arnd Bergmann  ---
(In reply to Arnd Bergmann from comment #14)
> I applied the patches and seem to still get a warning for this

I also just got the one from comment #9 again and found that the reduced test
case is still affected (and not claimed to be fixed by any of the patches, so
that's my fault for not checking).

[Bug lto/81004] [7/8 Regression] linking failed with -flto and static libboost_program_options

[hubicka at gcc dot gnu.org]

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

--- Comment #25 from Jan Hubicka  ---
Author: hubicka
Date: Tue Feb  6 13:27:04 2018
New Revision: 257412

URL: https://gcc.gnu.org/viewcvs?rev=257412=gcc=rev
Log:

PR lto/81004
* lto.c: Include builtins.h
(register_resolution): Merge resolutions in case trees was
merged across units.
(lto_maybe_register_decl): Break out from ...
(lto_read_decls): ... here.
(unify_scc): Also register decls here.
(read_cgraph_and_symbols): Sanity check that all resolutions was
read.

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

[Bug tree-optimization/84228] Bogus -Wstringop-truncation warning with -g

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
Fixed.

[Bug tree-optimization/84228] Bogus -Wstringop-truncation warning with -g

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Author: mpolacek
Date: Tue Feb  6 13:25:54 2018
New Revision: 257411

URL: https://gcc.gnu.org/viewcvs?rev=257411=gcc=rev
Log:
PR tree-optimization/84228
* tree-ssa-strlen.c (maybe_diag_stxncpy_trunc): Skip debug statements.

* c-c++-common/Wstringop-truncation-3.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/Wstringop-truncation-3.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-strlen.c

[Bug ipa/83179] [8 regression] gcc.dg/ipa/inline-1.c fail

[andrey.y.guskov at intel dot com]

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

Andrey Guskov  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED