[Bug libfortran/67540] string_intrinsics_inc.c sanitizer detects null pointer passed to memcpy

[zeccav at gmail dot com]

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

--- Comment #9 from Vittorio Zecca  ---
This test case is wrong.
It dereferences thrice a NULL pointer str4.
Unfortunately -fcheck=pointer does not detect this one. 
Just added to the CC list the test case author.

[Bug c++/68372] [concepts] invalid use of pack expansion expression in member function template declaration

[wilhelm.me...@hs-kl.de]

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

--- Comment #2 from wilhelm.me...@hs-kl.de ---
This ICE exists still in gcc-7.0.1-20170412.

[Bug tree-optimization/79390] [7 Regression] 10% performance drop in SciMark2 LU after r242550

[jakub at gcc dot gnu.org]

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

--- Comment #30 from Jakub Jelinek  ---
I didn't close it because I wanted to see updated benchmark numbers.  Either
I'll grab the benchmark, or if somebody else posts the latest numbers, we can
close it or keep open depending on that.

[Bug tree-optimization/51513] Only partially optimizes away __builtin_unreachable switch default case

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

URL|https://gcc.gnu.org/ml/gcc- |https://gcc.gnu.org/ml/gcc-
   |patches/2016-04/msg01915.ht |patches/2017-04/msg00607.ht
   |ml  |ml
   Assignee|unassigned at gcc dot gnu.org  |bergner at gcc dot 
gnu.org

--- Comment #9 from Peter Bergner  ---
New patch submitted.

[Bug target/80099] ICE in rs6000_expand_vector_extract, at config/rs6000/rs6000.c:7450

[meissner at gcc dot gnu.org]

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

--- Comment #2 from Michael Meissner  ---
The problem is rs6000_expand_vector_extract did not check for SFmode being
allowed in the Altivec (upper) registers, but the insn implementing the
variable extract had it as a condition.

In looking at the variable extract code, it currently does not require SFmode
to go in the Altivec registers, but it does require DImode to go into the
Altivec registers (vec_extract of V2DFmode will require DFmode to go in Altivec
registers instead of DImode).

[Bug target/77728] [5/6/7 Regression] Miscompilation multiple vector iteration on ARM

[jason at gcc dot gnu.org]

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

--- Comment #15 from Jason Merrill  ---
(In reply to rguent...@suse.de from comment #13)
> IMHO TYPE_DECL shouldn't even _have_ DECL_ALIGN ...

Agreed.

[Bug lto/79062] -Walloca-larger-than and -Wformat-overflow warnings disabled by -flto

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
All of warn_format, warn_format_overflow, and warn_format_trunc are, in fact,
zero in gimple-ssa-sprintf.c when -flto is set.

At least one problem is the dependency of -Wformat-{overflow,truncation} in
c-common/c.opt on -Wformat, which in turn depends on -Wall.  I.e.,
-Wformat-overflow is LangEnabledBy(C ObjC C++ ObjC++, Wformat=, warn_format >=
1, 0), and doesn't mention LTO.  -Wformat depends on -Wall, neither of which
mentions LTO.  Adding LTO helps somewhat, in that explicitly specifying
-Wformat-overflow (or -truncation) enables the warning, but specifying -Wformat
or -Wall doesn't have the same effect.  To set flags based on dependencies
among options the C front end calls the generated C_handle_option_auto()
function in $objdir/gcc/options.c which initializes its set of options.  There
is an LTO_handle_option_auto() in $objdir/gcc/options.c as well but nothing
seems to call it.  So it looks like some basic pieces aren't hooked up quite
right for LTO.

[Bug target/80098] ICE in curr_insn_transform, at lra-constraints.c:3816 on ppc64le

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

  Attachment #41180|0   |1
is obsolete||

--- Comment #3 from Michael Meissner  ---
Created attachment 41192
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41192=edit
Updated patch

[Bug target/80099] ICE in rs6000_expand_vector_extract, at config/rs6000/rs6000.c:7450

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

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

[Bug middle-end/57955] [5/6/7 Regression] Uniquization of constants reduces alignment of initializers

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P2
 CC||law at redhat dot com

[Bug target/74563] [6/7 regression] Classic MIPS16 (non-MIPS16e) function return broken

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P2
 CC||law at redhat dot com

[Bug rtl-optimization/78116] [7 regression] Performance drop after r241173 on avx512 target

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P2
 CC||law at redhat dot com

[Bug sanitizer/80403] UBSAN: compile time crash with "type mismatch in binary expression" message in / and % expr

[babokin at gmail dot com]

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

--- Comment #8 from Dmitry Babokin  ---
Three errors in one test case. GCC r246882.

> cat f.cpp
extern const long long int var_7;
extern unsigned long int var_59;
int foo() {
  int a = (0 - 40U <= (0 == 8)) << !var_59 << (0 < var_7) == 0;
  int b = ((0 ^ 0) < long(1066066618772207110 <= 0)) / 0 << 0;
  return a+b;
}

> g++ -w -fsanitize=undefined -O0 -c f.cpp
f.cpp: In function ‘int foo()’:
f.cpp:3:5: error: mismatching comparison operand types
 int foo() {
 ^~~
unsigned int
int
_4 = D.2761 < 0;
f.cpp:3:5: error: type mismatch in shift expression
int
unsigned int
int
_19 = D.2761 << _18;
f.cpp:3:5: error: type mismatch in binary expression
int

long int

int

D.2772 = 0 / 0;
f.cpp:3:5: internal compiler error: verify_gimple failed

[Bug rtl-optimization/80343] [7 Regression] ICE in extract_constrain_insn, at recog.c:2213 (error: insn does not satisfy its constraints)

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P2
 CC||law at redhat dot com

[Bug c++/79508] [6 Regression] Parse error in template argument list using nested template arguments

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

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

[Bug c++/79566] [6 Regression] elaborated-type-specifier incorrectly rejected in range-based for

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

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

[Bug c++/79640] [5/6 Regression] ICE with generic lambda expression

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|5.5 |6.4

--- Comment #7 from Jason Merrill  ---
Fixed for 6.4, not backporting to 5.

[Bug c++/79519] [5/6 Regression] ICE deleting template friend function

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|5.5 |6.4

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

[Bug tree-optimization/79390] [7 Regression] 10% performance drop in SciMark2 LU after r242550

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #29 from Jeffrey A. Law  ---
Jakub's fix addresses the last remaining issue IIUC.  Should we close this out?

[Bug c++/80038] [6/7 Regression] Random segfault using local vectors in Cilk function

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P2  |P4

--- Comment #30 from Jeffrey A. Law  ---
Given that Cilk is likely to be deprecated, there's no way this should be a P2
issue.

[Bug fortran/80361] [5/6/7 Regression] bogus recursive call to nonrecursive procedure with -fcheck=recursion

[tkoenig at gcc dot gnu.org]

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

--- Comment #19 from Thomas Koenig  ---
(In reply to janus from comment #16)
> This seems to be sufficient to fix the runtime error on the reduced test
> case in comment #13:
> 
> 
> Index: gcc/fortran/class.c
> ===
> --- gcc/fortran/class.c   (revision 246822)
> +++ gcc/fortran/class.c   (working copy)
> @@ -1613,6 +1613,7 @@ generate_finalization_wrapper (gfc_symbol *derived
>final->attr.flavor = FL_PROCEDURE;
>final->attr.function = 1;
>final->attr.pure = 0;
> +  final->attr.recursive = 1;
>final->result = final;
>final->ts.type = BT_INTEGER;
>final->ts.kind = 4;

Simple enough to be obvious :-)

Pre-approved.

[Bug fortran/80408] Problems with SIGNAL, pthread and print together

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-04-12
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
> You may not call arbitrary functions in signal context but only
> async-signal safe ones.

Thus invalid?

[Bug c/80413] sanitizer detects undefined behaviour in gcov-io.c using -ftest-coverage

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
I'll take a look.

[Bug sanitizer/80403] UBSAN: compile time crash with "type mismatch in binary expression" message in / and % expr

[babokin at gmail dot com]

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

--- Comment #7 from Dmitry Babokin  ---
80404 and 80405 seemed similar, but different to me, so I decided to report
them separately. Anyway, after the latest fixes I still see 2 compile crashes.
I'm reducing them and will report here.

[Bug lto/80407] --as-needed cannot be combined with -flto

[dilyan.palauzov at aegee dot org]

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

Дилян Палаузов  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |MOVED

--- Comment #3 from Дилян Палаузов  ---
Moved to https://sourceware.org/bugzilla/show_bug.cgi?id=21382 .

[Bug middle-end/79929] [7 Regression] Bogus Warning: '__builtin_memset': specified size 4294967291 exceeds maximum object size 2147483647

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

   Priority|P4  |P3
  Component|fortran |middle-end

--- Comment #7 from Thomas Koenig  ---
Setting component to middle end, resetting priority.

[Bug fortran/80361] [5/6/7 Regression] bogus recursive call to nonrecursive procedure with -fcheck=recursion

[janus at gcc dot gnu.org]

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

--- Comment #18 from janus at gcc dot gnu.org ---
(In reply to janus from comment #17)
> (In reply to janus from comment #16)
> > This seems to be sufficient to fix the runtime error on the reduced test
> > case in comment #13:
> 
> And it also does the trick for PR 67505 ...

... and regtests cleanly.

[Bug sanitizer/80414] New: [UBSAN] segfault with -fsanitize=undefined

[d.khalikov at partner dot samsung.com]

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

Bug ID: 80414
   Summary: [UBSAN] segfault with -fsanitize=undefined
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: d.khalikov at partner dot samsung.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
  Target Milestone: ---

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

Hello everyone.

I got segfault on 32 bit host with -fsanitize=undefined

My test case:

# cat test.c 

int main()
{
  long long offset = 10;
  char array[10];
  char c = array[offset];
  return 0;
}

# gcc -o test test.c -fsanitize=undefined -static-libubsan
# ./test

That happens while checking for bounds-strict option on 32 bit host.

As i can see gcc push value of the index to the stack before call 
__ubsan_handle_out_of_bounds

 67 subl$44, %esp
 68 movl$10, -32(%ebp)
 69 movl$0, -28(%ebp)
 70 movl-32(%ebp), %ebx
 71 movl-28(%ebp), %esi
 72 movl%ebx, %eax
 73 cmpl$9, %eax
 74 jbe .L2
 75 subl$8, %esp
 76 pushl   %eax
 77 pushl   $.Lubsan_data0
 78 call__ubsan_handle_out_of_bounds

instead clang push address of that index

 15 movl$10, -32(%ebp)
 16 movl-28(%ebp), %eax
 17 movl-32(%ebp), %ecx
 18 movl%ecx, %edx
 19 cmpl$10, %edx
 20 movl%eax, -44(%ebp) # 4-byte Spill
 21 movl%ecx, -48(%ebp) # 4-byte Spill
 22 jb  .LBB0_2
 23 # BB#1:
 24 leal.L__unnamed_1, %eax
 25 leal-40(%ebp), %ecx
 26 movl-48(%ebp), %edx # 4-byte Reload
 27 movl%edx, -40(%ebp)
 28 movl-44(%ebp), %esi # 4-byte Reload
 29 movl%esi, -36(%ebp)
 30 movl%eax, (%esp)
 31 movl%ecx, 4(%esp)
 32 calll   __ubsan_handle_out_of_bounds

In this case fix should be in IR generation for
__ubsan_handle_out_of_bounds.

Looks like tree val should be generated from original tree 
index and not from tree index which 
were converted to bound type.

diff --git a/gcc/ubsan.c b/gcc/ubsan.c
index 17965ef..c56f376 100644
--- a/gcc/ubsan.c
+++ b/gcc/ubsan.c
@@ -672,7 +672,8 @@ ubsan_expand_bounds_ifn (gimple_stmt_iterator *gsi)

   /* Pick up the arguments of the UBSAN_BOUNDS call.  */
   tree type = TREE_TYPE (TREE_TYPE (gimple_call_arg (stmt, 0)));
-  tree index = gimple_call_arg (stmt, 1);
+  tree index, orig_index;
+  index = orig_index = gimple_call_arg (stmt, 1);
   tree orig_index_type = TREE_TYPE (index);
   tree bound = gimple_call_arg (stmt, 2);

@@ -708,9 +709,9 @@ ubsan_expand_bounds_ifn (gimple_stmt_iterator *gsi)
  ? BUILT_IN_UBSAN_HANDLE_OUT_OF_BOUNDS
  : BUILT_IN_UBSAN_HANDLE_OUT_OF_BOUNDS_ABORT;
   tree fn = builtin_decl_explicit (bcode);
-  tree val = force_gimple_operand_gsi (gsi, ubsan_encode_value (index),
-  true, NULL_TREE, true,
-  GSI_SAME_STMT);
+  tree val
+   = force_gimple_operand_gsi (gsi, ubsan_encode_value (orig_index), true,
+   NULL_TREE, true, GSI_SAME_STMT);
   g = gimple_build_call (fn, 2, data, val);
 }
   gimple_set_location (g, loc);

I attached patch.
Tests with make check RUNTESTFLAGS="ubsan.exp" passed for x86 32bit 
and 64 bit host.

[Bug c++/77563] [5 Regression] explicit constructor breaks narrowing conversion overload resolution

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|5.5 |6.4
Summary|[5/6 Regression] explicit   |[5 Regression] explicit
   |constructor breaks  |constructor breaks
   |narrowing conversion|narrowing conversion
   |overload resolution |overload resolution

--- Comment #9 from Jason Merrill  ---
Fixed for 6.4.  Since the GCC 5 bug is just a strange diagnostic, I'm not going
to fix it there.

[Bug c++/80150] [6 Regression] Internal compiler error when in in try_one_overload, at cp/pt.c:18903

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #7 from Jason Merrill  ---
Fixed for 6.4 as well.

[Bug c++/78282] [6 Regression] Overload resolution failure, in parameter pack expansion, inside a template class

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #7 from Jason Merrill  ---
Fixed on 6 branch as well.

[Bug c++/77563] [5/6 Regression] explicit constructor breaks narrowing conversion overload resolution

[jason at gcc dot gnu.org]

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

--- Comment #8 from Jason Merrill  ---
Author: jason
Date: Wed Apr 12 19:23:30 2017
New Revision: 246893

URL: https://gcc.gnu.org/viewcvs?rev=246893=gcc=rev
Log:
PR c++/77563 - missing ambiguous conversion error.

* call.c (convert_like_real): Use LOOKUP_IMPLICIT.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/overload/ambig3.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/call.c

[Bug c++/80150] [6 Regression] Internal compiler error when in in try_one_overload, at cp/pt.c:18903

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  ---
Author: jason
Date: Wed Apr 12 19:23:37 2017
New Revision: 246894

URL: https://gcc.gnu.org/viewcvs?rev=246894=gcc=rev
Log:
PR c++/80150 - ICE with overloaded variadic deduction.

* pt.c (try_one_overload): Remove asserts.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/cpp0x/variadic-unify-3.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/pt.c

[Bug c++/79519] [5/6 Regression] ICE deleting template friend function

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Wed Apr 12 19:23:23 2017
New Revision: 246892

URL: https://gcc.gnu.org/viewcvs?rev=246892=gcc=rev
Log:
PR c++/79519 - ICE with deleted template friend.

* decl.c (grokdeclarator): Complain about misplaced function
definition using =, as well.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/cpp0x/deleted13.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/decl.c

[Bug c++/79640] [5/6 Regression] ICE with generic lambda expression

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  ---
Author: jason
Date: Wed Apr 12 19:23:15 2017
New Revision: 246891

URL: https://gcc.gnu.org/viewcvs?rev=246891=gcc=rev
Log:
PR c++/79640 - infinite recursion with generic lambda.

* pt.c (tsubst_copy) [VAR_DECL]: Register the dummy instantiation
before substituting its initializer.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/cpp1y/lambda-generic-const3.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/pt.c

[Bug c++/79607] [5/6 Regression] ICE with brace-initialization of static const member

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Wed Apr 12 19:22:56 2017
New Revision: 246888

URL: https://gcc.gnu.org/viewcvs?rev=246888=gcc=rev
Log:
PR c++/79607 - ICE with T{} initializer

* decl.c (type_dependent_init_p): Check the type of a CONSTRUCTOR.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/template/init11.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/decl.c

[Bug c++/80043] [6/7 Regression] ICE with pointer-to-member-function and -fpermissive

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Wed Apr 12 19:23:09 2017
New Revision: 246890

URL: https://gcc.gnu.org/viewcvs?rev=246890=gcc=rev
Log:
PR c++/80043 - ICE with -fpermissive

* typeck.c (convert_for_assignment): Handle instantiate_type
not giving an error.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/parse/ptrmem7.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/typeck.c

[Bug c++/78282] [6 Regression] Overload resolution failure, in parameter pack expansion, inside a template class

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  ---
Author: jason
Date: Wed Apr 12 19:23:02 2017
New Revision: 246889

URL: https://gcc.gnu.org/viewcvs?rev=246889=gcc=rev
Log:
PR c++/78282 - auto template and pack expansion

* pt.c (find_parameter_packs_r): Don't walk into the type of
templates other than template template-parameters.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/cpp1y/auto-fn36.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/pt.c

[Bug c++/79566] [6 Regression] elaborated-type-specifier incorrectly rejected in range-based for

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Wed Apr 12 19:22:50 2017
New Revision: 246887

URL: https://gcc.gnu.org/viewcvs?rev=246887=gcc=rev
Log:
PR c++/79566 - elaborated-type-specifier in range for

* parser.c (cp_parser_simple_declaration): Fix check for type
definition.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/cpp0x/range-for34.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/parser.c

[Bug c++/79580] [5/6 Regression] ICE in nested_anon_class_index, at cp/mangle.c:1604

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Wed Apr 12 19:22:44 2017
New Revision: 246886

URL: https://gcc.gnu.org/viewcvs?rev=246886=gcc=rev
Log:
PR c++/79580 - ICE with compound literal

* parser.c (cp_parser_class_head): If we're in the middle of an
expression, use ts_within_enclosing_non_class.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/ext/complit15.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/parser.c

[Bug c++/79508] [6 Regression] Parse error in template argument list using nested template arguments

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  ---
Author: jason
Date: Wed Apr 12 19:22:38 2017
New Revision: 246885

URL: https://gcc.gnu.org/viewcvs?rev=246885=gcc=rev
Log:
PR c++/79508 - lookup error with member template

* parser.c (cp_parser_template_name): Clear
parser->context->object_type if we aren't doing lookup.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/template/memtmpl5.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/parser.c

[Bug c++/79050] [5/6 Regression] ICE: tree code 'template_type_parm' is not supported in LTO streams

[jason at gcc dot gnu.org]

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

--- Comment #9 from Jason Merrill  ---
Author: jason
Date: Wed Apr 12 19:22:32 2017
New Revision: 246884

URL: https://gcc.gnu.org/viewcvs?rev=246884=gcc=rev
Log:
PR c++/79050 - ICE with undeduced auto and LTO

* decl.c (poplevel): Remove undeduced auto decls.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/lto/pr79050_0.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/decl.c

[Bug c++/79461] [5/6 Regression] [C++1z] ICE when capturing a variable in a lambda in a constexpr constructor

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Wed Apr 12 19:22:25 2017
New Revision: 246883

URL: https://gcc.gnu.org/viewcvs?rev=246883=gcc=rev
Log:
PR c++/79461 - ICE with lambda in constexpr constructor

* constexpr.c (build_data_member_initialization): Ignore
initialization of a local variable.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/cpp1z/constexpr-lambda15.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/constexpr.c

[Bug fortran/67505] [F03] bogus runtime error with final subroutine and -fcheck=recursion

[janus at gcc dot gnu.org]

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

--- Comment #4 from janus at gcc dot gnu.org ---
The patch in PR 80361 comment 16 fixes the error.

[Bug fortran/80361] [5/6/7 Regression] bogus recursive call to nonrecursive procedure with -fcheck=recursion

[janus at gcc dot gnu.org]

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

--- Comment #17 from janus at gcc dot gnu.org ---
(In reply to janus from comment #16)
> This seems to be sufficient to fix the runtime error on the reduced test
> case in comment #13:

And it also does the trick for PR 67505 ...

[Bug fortran/80361] [5/6/7 Regression] bogus recursive call to nonrecursive procedure with -fcheck=recursion

[janus at gcc dot gnu.org]

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

--- Comment #16 from janus at gcc dot gnu.org ---
This seems to be sufficient to fix the runtime error on the reduced test case
in comment #13:


Index: gcc/fortran/class.c
===
--- gcc/fortran/class.c (revision 246822)
+++ gcc/fortran/class.c (working copy)
@@ -1613,6 +1613,7 @@ generate_finalization_wrapper (gfc_symbol *derived
   final->attr.flavor = FL_PROCEDURE;
   final->attr.function = 1;
   final->attr.pure = 0;
+  final->attr.recursive = 1;
   final->result = final;
   final->ts.type = BT_INTEGER;
   final->ts.kind = 4;

[Bug sanitizer/80403] UBSAN: compile time crash with "type mismatch in binary expression" message in / and % expr

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/79390] [7 Regression] 10% performance drop in SciMark2 LU after r242550

[jakub at gcc dot gnu.org]

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

--- Comment #28 from Jakub Jelinek  ---
Author: jakub
Date: Wed Apr 12 18:09:47 2017
New Revision: 246882

URL: https://gcc.gnu.org/viewcvs?rev=246882=gcc=rev
Log:
PR tree-optimization/79390
* optabs.c (emit_conditional_move): If the preferred op2/op3 operand
order does not result in usable sequence, retry with reversed operand
order.

* gcc.target/i386/pr70465-2.c: Xfail the scan-assembler-not test.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/optabs.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/pr70465-2.c

[Bug sanitizer/80405] UBSAN: compile time crash with "type mismatch in shift expression" error

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Wed Apr 12 18:08:29 2017
New Revision: 246881

URL: https://gcc.gnu.org/viewcvs?rev=246881=gcc=rev
Log:
PR sanitizer/80403
PR sanitizer/80404
PR sanitizer/80405
* fold-const.c (fold_ternary_loc): Use op1 instead of arg1 as argument
to fold_build2_loc.  Convert TREE_OPERAND (tem, 0) to type.  Use
op0 instead of fold_convert_loc (loc, type, arg0).

* g++.dg/ubsan/pr80403.C: New test.
* g++.dg/ubsan/pr80404.C: New test.
* g++.dg/ubsan/pr80405.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/ubsan/pr80403.C
trunk/gcc/testsuite/g++.dg/ubsan/pr80404.C
trunk/gcc/testsuite/g++.dg/ubsan/pr80405.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog

[Bug sanitizer/80403] UBSAN: compile time crash with "type mismatch in binary expression" message in / and % expr

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Wed Apr 12 18:08:29 2017
New Revision: 246881

URL: https://gcc.gnu.org/viewcvs?rev=246881=gcc=rev
Log:
PR sanitizer/80403
PR sanitizer/80404
PR sanitizer/80405
* fold-const.c (fold_ternary_loc): Use op1 instead of arg1 as argument
to fold_build2_loc.  Convert TREE_OPERAND (tem, 0) to type.  Use
op0 instead of fold_convert_loc (loc, type, arg0).

* g++.dg/ubsan/pr80403.C: New test.
* g++.dg/ubsan/pr80404.C: New test.
* g++.dg/ubsan/pr80405.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/ubsan/pr80403.C
trunk/gcc/testsuite/g++.dg/ubsan/pr80404.C
trunk/gcc/testsuite/g++.dg/ubsan/pr80405.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog

[Bug sanitizer/80404] UBSAN: compile time crash with "non-trivial conversion at assignment" error

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Wed Apr 12 18:08:29 2017
New Revision: 246881

URL: https://gcc.gnu.org/viewcvs?rev=246881=gcc=rev
Log:
PR sanitizer/80403
PR sanitizer/80404
PR sanitizer/80405
* fold-const.c (fold_ternary_loc): Use op1 instead of arg1 as argument
to fold_build2_loc.  Convert TREE_OPERAND (tem, 0) to type.  Use
op0 instead of fold_convert_loc (loc, type, arg0).

* g++.dg/ubsan/pr80403.C: New test.
* g++.dg/ubsan/pr80404.C: New test.
* g++.dg/ubsan/pr80405.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/ubsan/pr80403.C
trunk/gcc/testsuite/g++.dg/ubsan/pr80404.C
trunk/gcc/testsuite/g++.dg/ubsan/pr80405.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog

[Bug c/80413] New: sanitizer detects undefined behaviour in gcov-io.c using -ftest-coverage

[zeccav at gmail dot com]

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

Bug ID: 80413
   Summary: sanitizer detects undefined behaviour in gcov-io.c
using -ftest-coverage
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

/* gcc -ftest-coverage */
/* gcc-trunk-246751/gcc/gcov-io.c:351:10: runtime error: null pointer passed as
argument 2, which is declared to never be null*/
/* gcov-io.c:351 "memcpy ([1], string, length);" */
/* string is NULL but most probably length is zero */
int main () {}

[Bug lto/79062] -Walloca-larger-than and -Wformat-overflow warnings disabled by -flto

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
The following allows the format string to be recognized even with LTO.  The
sprintf pass runs and seems to work correctly, but warnings from it for some
reason do not appear on output.  It's as if they were disabled.  I'm not sure
what's causing that.

diff --git a/gcc/gimple-ssa-sprintf.c b/gcc/gimple-ssa-sprintf.c
index 85f97b2..687a87f 100644
--- a/gcc/gimple-ssa-sprintf.c
+++ b/gcc/gimple-ssa-sprintf.c
@@ -373,7 +373,16 @@ get_format_string (tree format, location_t *ploc)
   if (TREE_CODE (format) != STRING_CST)
 return NULL;

-  if (TYPE_MAIN_VARIANT (TREE_TYPE (TREE_TYPE (format))) != char_type_node)
+  tree type = TREE_TYPE (format);
+  if (TREE_CODE (type) == ARRAY_TYPE)
+type = TREE_TYPE (type);
+
+  /* Can't just test that:
+   TYPE_MAIN_VARIANT (TREE_TYPE (TREE_TYPE (format))) != char_type_node
+ See bug 79062.  */
+  if (TREE_CODE (type) != INTEGER_TYPE
+  || TYPE_MODE (type) != TYPE_MODE (char_type_node)
+  || TYPE_PRECISION (type) != TYPE_PRECISION (char_type_node))
 {
   /* Wide format string.  */
   return NULL;

[Bug fortran/79929] [7 Regression] Bogus Warning: '__builtin_memset': specified size 4294967291 exceeds maximum object size 2147483647

[dominiq at lps dot ens.fr]

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

--- Comment #6 from Dominique d'Humieres  ---
Likely caused by revision r243419. Note that I don't get the warning with the C
code in comment 4.

[Bug target/78994] -Ofast makes aarch64 C++ benchmark slower for A53

[wilco at gcc dot gnu.org]

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

wilco at gcc dot gnu.org changed:

   What|Removed |Added

 CC||wilco at gcc dot gnu.org

--- Comment #8 from wilco at gcc dot gnu.org ---
It looks like scheduling but not of int<->fp transfers, try -frename-registers.

[Bug fortran/79929] [7 Regression] Bogus Warning: '__builtin_memset': specified size 4294967291 exceeds maximum object size 2147483647

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
Thanks for the C test case.  In it, the warning is a false positive caused by
GCC's failure to eliminate the excessive memset at -O1.  The call is emitted by
the ccp1 pass at all optimization levels.  At -O2, it's also removed, looks
like by the forward propagation pass that runs just after ccp1, but at -O1 it's
never removed.

[Bug fortran/59910] ICE in gfc_conv_array_initializer, at fortran/trans-array.c:5327

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #7 from Jerry DeLisle  ---
(In reply to Dominique d'Humieres from comment #6)
> > A patch to fix the problem exposed by code in comment #1
> > has been committed to trunk.  Same patch does not fix
> > 5-branch.  Closing as fixed.
> 
> It does for me provided the patch is applied at the proper location:
> 
> @@ -2657,6 +2657,12 @@ gfc_match_structure_constructor (gfc_sym
> 
> Applying the patch with patch -p0 -i patch-59910 put the fix in the wrong
> location
> 
> @@ -245,6 +245,12 @@ match_integer_constant (gfc_expr **resul
> 
> Regtesting in progress. Any objection if I do the back port?

This is a little confusing. The original patch is in
gfc_match_structure_constructor (). Is your new patch still in this function
for 5 or in a different function? Maybe post your clean diff so we can
understand better. Is the original patch in the wrong place?

[Bug fortran/79929] [7 Regression] Bogus Warning: '__builtin_memset': specified size 4294967291 exceeds maximum object size 2147483647

[tkoenig at gcc dot gnu.org]

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

--- Comment #4 from Thomas Koenig  ---
Here's equivlalent C code:

$ cat bug.c
#include 
#include 

char * foo(char *c, int len)
{
  char *p, *n;
  n = malloc(len + 5);
  p = c + 5;
  memmove (c, n, p-c);
  if (p < c)
memset (n + 5, 32, c-p);
  return n;
}
$ gcc -Wall -O -c bug.c
bug.c: In function 'foo':
bug.c:11:5: warning: 'memset': specified size 18446744073709551611 exceeds
maximum object size 9223372036854775807 [-Wstringop-overflow=]
 memset (n + 5, 32, c-p);

I don't think the code is buggy, but the warning is bogus.

[Bug middle-end/80131] powerpc: 1U << (31 - x) doesn't generate optimised code

[wilco at gcc dot gnu.org]

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

wilco at gcc dot gnu.org changed:

   What|Removed |Added

 CC||wilco at gcc dot gnu.org

--- Comment #6 from wilco at gcc dot gnu.org ---
See https://gcc.gnu.org/ml/gcc-patches/2017-04/msg00570.html

[Bug tree-optimization/80198] [6/7/8 Regression] does not vectorize generic inplace integer operation

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com
   Target Milestone|6.4 |8.0
Summary|[6/7 Regression] does not   |[6/7/8 Regression] does not
   |vectorize generic inplace   |vectorize generic inplace
   |integer operation   |integer operation

--- Comment #8 from Jeffrey A. Law  ---
Note that I've got POC changes that would allow us to distinguish between
normal equivalences and those created by conditionals.  That in turn would
allow DOM to avoid ping-ponging copy propagations -- only propagating when
doing so allows real simplifications.  But that is gcc-8 material.  Explicitly
deferring.

[Bug middle-end/80399] Premature optimization with unsigned

[wilco at gcc dot gnu.org]

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

wilco at gcc dot gnu.org changed:

   What|Removed |Added

 CC||wilco at gcc dot gnu.org

--- Comment #3 from wilco at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #2)
> Related case (but I know it goes down a different path) is:
> struct ss
> {
>   int aa;
>   int s;
> };
> 
> int
> f(int a, struct ss *rn, int i)
> {
>   return rn[i-1].s == a;
> }
> 
> Which shows up in SPEC INT.

This works for me (unlike similar cases where we fail to use loads with
offsets):

add x1, x1, x2, sxtw 3
ldr w1, [x1, -4]
cmp w1, w0
csetw0, eq
ret

That's the best possible code as when you use a[i-1], a[i], a[i+1] you don't
want 3 address computations but a single shared one and loads/stores with
simple immediate offsets.

[Bug fortran/59910] ICE in gfc_conv_array_initializer, at fortran/trans-array.c:5327

[dominiq at lps dot ens.fr]

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

--- Comment #6 from Dominique d'Humieres  ---
> A patch to fix the problem exposed by code in comment #1
> has been committed to trunk.  Same patch does not fix
> 5-branch.  Closing as fixed.

It does for me provided the patch is applied at the proper location:

@@ -2657,6 +2657,12 @@ gfc_match_structure_constructor (gfc_sym

Applying the patch with patch -p0 -i patch-59910 put the fix in the wrong
location

@@ -245,6 +245,12 @@ match_integer_constant (gfc_expr **resul

Regtesting in progress. Any objection if I do the back port?

[Bug middle-end/80163] ICE on hopefully valid code

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c/80409] Document that va_arg(ap, void*) can be used to consume any pointer argument

[pascal_cuoq at hotmail dot com]

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

--- Comment #2 from Pascal Cuoq  ---
> it should work even with standard c

Quoting from 7.6.1.1:2

  … the behavior is undefined, except for the following cases:
  * …
  * one type is pointer to void and the other is a pointer to a character type.

Why would the standard say the above, if using void* with any pointer type
worked?

> for an example %p in printf takes a void* but nobody casts it to void* when 
> passing to printf

This does not correspond to my experience. The C programmers I know fall into
two categories:

- C programmers who do not cast printf %p arguments to void*, because it works.
These programmers also write “*(float*)_variable = 1.0f;”, because it
works, and “if (int_variable + 1 < int_variable) printf ("overflow!");”,
because it works.

- C programmers who do cast printf %p arguments to void*.

The good ship “we shouldn't have to document this because it obviously should
work on normal architectures even if the C standard does not say so” sailed
some time in the late nineties.

[Bug middle-end/80163] ICE on hopefully valid code

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Wed Apr 12 13:57:45 2017
New Revision: 246876

URL: https://gcc.gnu.org/viewcvs?rev=246876=gcc=rev
Log:
PR c/80163
* expr.c : For EXPAND_INITIALIZER determine SIGN_EXTEND
vs. ZERO_EXTEND based on signedness of treeop0's type rather than
signedness of the result type.

* gcc.dg/torture/pr80163.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr80163.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/expr.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/79590] ICE (internal compiler error) in nothrow_spec_p with generic lambda and `noexcept(noexcept(...))` expression

[vittorio.romeo at outlook dot com]

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

--- Comment #2 from Vittorio Romeo  ---
This is still present. Here are some more examples:



int main()
{
[](auto x) noexcept(noexcept(x)) { } (0);
}

:3:40: internal compiler error: in nothrow_spec_p, at cp/except.c:1159
 [](auto x) noexcept(noexcept(x)) { } (0);
^



int main()
{
[](auto) noexcept(noexcept(0)) { } (0);
}

: In function 'int main()':
:3:38: internal compiler error: in nothrow_spec_p, at cp/except.c:1159
 [](auto) noexcept(noexcept(0)) { } (0);
  ^

[Bug target/80376] Some vec_xxpermdi usage lead to ICE

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

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

--- Comment #9 from Bill Schmidt  ---
Fixed everywhere.

[Bug tree-optimization/80359] [7 Regression] DSE causes error: invalid reference prefix

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug target/80315] Calling __builtin_crypto_vshasigmaw with argument 3 out of range creates an unrecognizable insn

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

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

--- Comment #6 from Bill Schmidt  ---
Fixed everywhere.

[Bug tree-optimization/80359] [7 Regression] DSE causes error: invalid reference prefix

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
Author: rguenth
Date: Wed Apr 12 13:47:26 2017
New Revision: 246875

URL: https://gcc.gnu.org/viewcvs?rev=246875=gcc=rev
Log:
2017-04-12  Richard Biener  
Jeff Law  

PR tree-optimization/80359
* tree-ssa-dse.c (maybe_trim_partially_dead_store): Do not
trim stores to TARGET_MEM_REFs.

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

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr80359.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-dse.c

[Bug target/80315] Calling __builtin_crypto_vshasigmaw with argument 3 out of range creates an unrecognizable insn

[wschmidt at gcc dot gnu.org]

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

--- Comment #5 from Bill Schmidt  ---
Author: wschmidt
Date: Wed Apr 12 13:45:27 2017
New Revision: 246874

URL: https://gcc.gnu.org/viewcvs?rev=246874=gcc=rev
Log:
2017-04-12  Bill Schmidt  

Backport from mainline
2017-04-11  Bill Schmidt  

PR target/80376
PR target/80315
* config/rs6000/rs6000.c (rs6000_expand_unop_builtin): Return
CONST0_RTX (mode) rather than const0_rtx where appropriate.
(rs6000_expand_binop_builtin): Likewise.
(rs6000_expand_ternop_builtin): Likewise; also add missing
vsx_xxpermdi_* variants; also fix typo (arg1 => arg2) for
vshasigma built-ins.
* doc/extend.texi: Document that vec_xxpermdi's third argument
must be a constant.


Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/rs6000/rs6000.c
branches/gcc-5-branch/gcc/doc/extend.texi

[Bug target/80376] Some vec_xxpermdi usage lead to ICE

[wschmidt at gcc dot gnu.org]

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

--- Comment #8 from Bill Schmidt  ---
Author: wschmidt
Date: Wed Apr 12 13:45:27 2017
New Revision: 246874

URL: https://gcc.gnu.org/viewcvs?rev=246874=gcc=rev
Log:
2017-04-12  Bill Schmidt  

Backport from mainline
2017-04-11  Bill Schmidt  

PR target/80376
PR target/80315
* config/rs6000/rs6000.c (rs6000_expand_unop_builtin): Return
CONST0_RTX (mode) rather than const0_rtx where appropriate.
(rs6000_expand_binop_builtin): Likewise.
(rs6000_expand_ternop_builtin): Likewise; also add missing
vsx_xxpermdi_* variants; also fix typo (arg1 => arg2) for
vshasigma built-ins.
* doc/extend.texi: Document that vec_xxpermdi's third argument
must be a constant.


Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/rs6000/rs6000.c
branches/gcc-5-branch/gcc/doc/extend.texi

[Bug rtl-optimization/80357] [7 Regression] ICE in model_update_limit_points_in_group, at haifa-sched.c:1982 on powerpc64le-linux-gnu

[segher at gcc dot gnu.org]

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

--- Comment #11 from Segher Boessenkool  ---
The pressure becomes quite negative here...  that isn't supposed to
happen as far as I can see.  Allowing all negative pressures in the
asserts makes everything compile fine, but there really shouldn't
be negative pressures at all?

[Bug target/80315] Calling __builtin_crypto_vshasigmaw with argument 3 out of range creates an unrecognizable insn

[wschmidt at gcc dot gnu.org]

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

--- Comment #4 from Bill Schmidt  ---
Author: wschmidt
Date: Wed Apr 12 13:37:30 2017
New Revision: 246873

URL: https://gcc.gnu.org/viewcvs?rev=246873=gcc=rev
Log:
2017-04-12  Bill Schmidt  

Backport from mainline
2017-04-11  Bill Schmidt  

PR target/80376
PR target/80315
* config/rs6000/rs6000.c (rs6000_expand_unop_builtin): Return
CONST0_RTX (mode) rather than const0_rtx where appropriate.
(rs6000_expand_binop_builtin): Likewise.
(rs6000_expand_ternop_builtin): Likewise; also add missing
vsx_xxpermdi_* variants; also fix typo (arg1 => arg2) for
vshasigma built-ins.
* doc/extend.texi: Document that vec_xxpermdi's third argument
must be a constant.


Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/rs6000/rs6000.c
branches/gcc-6-branch/gcc/doc/extend.texi

[Bug target/80376] Some vec_xxpermdi usage lead to ICE

[wschmidt at gcc dot gnu.org]

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

--- Comment #7 from Bill Schmidt  ---
Author: wschmidt
Date: Wed Apr 12 13:37:30 2017
New Revision: 246873

URL: https://gcc.gnu.org/viewcvs?rev=246873=gcc=rev
Log:
2017-04-12  Bill Schmidt  

Backport from mainline
2017-04-11  Bill Schmidt  

PR target/80376
PR target/80315
* config/rs6000/rs6000.c (rs6000_expand_unop_builtin): Return
CONST0_RTX (mode) rather than const0_rtx where appropriate.
(rs6000_expand_binop_builtin): Likewise.
(rs6000_expand_ternop_builtin): Likewise; also add missing
vsx_xxpermdi_* variants; also fix typo (arg1 => arg2) for
vshasigma built-ins.
* doc/extend.texi: Document that vec_xxpermdi's third argument
must be a constant.


Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/rs6000/rs6000.c
branches/gcc-6-branch/gcc/doc/extend.texi

[Bug debug/80321] [7 regression] infinite recursion with inlining of nested function and debug info

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Note this breaks profiledbootstrap with Ada on various targets.

[Bug tree-optimization/80359] [7 Regression] DSE causes error: invalid reference prefix

[law at redhat dot com]

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

--- Comment #8 from Jeffrey A. Law  ---
That's exactly what I tested yesterday.  It bootstraps and regression tests
successfully.  So no need to wait on the testrun.

[Bug sanitizer/69279] Uncomplete documentation for -fsanitize-recovery option

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Fixed on trunk, no plan to backport it.

[Bug tree-optimization/80359] [7 Regression] DSE causes error: invalid reference prefix

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|law at redhat dot com  |rguenth at gcc dot 
gnu.org

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

Patch I am testing.  Constructor stores are similarly affected.

[Bug gcov-profile/77698] Unrolled loop not considered hot after profiling

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Confirmed. Actually I talked with Honza last week about usage of working sets
and problems it has. Your sample nicely illustrates one of them:

As you have a really dominant edge and the rest of program has sum really
really small, then hotness is equal to execution count of the maximal edge.
Which is obviously very wrong even in case where loop unrolling is asking for a
split edge with fraction of the frequency.

Just for your information, before the current state (r193747), we used to
compute the hotness threshold as follows:

profile_info->sum_max / PARAM_VALUE (HOT_BB_COUNT_FRACTION)

where the param used to have value 1. That results in value 100. By the
way, I believe the value should be also divided by profile_info->runs (number
of runs) as sum_max is increasing with # of a binary is executed.

Second issue I see is quite huge performance overhead during instrumentation
run. For programs that are executed repeatedly, one can see in perf top:

11.23%  git [.] gcov_do_dump
 9.14%  git [.] __gcov_write_summary
 5.60%  libc-2.25.so[.] __memset_sse2_unaligned_erms
 3.82%  git [.] __gcov_read_summary

and of course it occupies space both in profile and an instrumented binary.

That said I'm planning to test the original mechanism and compare it to the
current one.
And we can add an option to switch in between these 2 methods.

[Bug target/77728] [5/6/7 Regression] Miscompilation multiple vector iteration on ARM

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  ---
For the base class alignment vs. alignment of base class members, I think
testcases could be e.g. like:
struct B { char a __attribute__((aligned (8))); };
struct A : public B {};

A
foo (int x, A y)
{
  return y;
}

or
struct __attribute__((aligned (8))) B { char a; };
struct A : public B {};

A
foo (int x, A y)
{
  return y;
}
and similar, though it seems g++ and clang++ agree on the passing at least in
these two testcases.  Of course, one should also try multiple inheritance, etc.
Virtual inheritance probably doesn't matter, I think those types must be passed
always by invisible reference.

[Bug rtl-optimization/80357] [7 Regression] ICE in model_update_limit_points_in_group, at haifa-sched.c:1982 on powerpc64le-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #10 from Jakub Jelinek  ---
CCing Richard as SCHED_PRESSURE_MODEL author.

[Bug tree-optimization/79390] [7 Regression] 10% performance drop in SciMark2 LU after r242550

[rguenther at suse dot de]

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

--- Comment #27 from rguenther at suse dot de  ---
On Wed, 12 Apr 2017, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79390
> 
> --- Comment #26 from Jakub Jelinek  ---
> Created attachment 41189
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41189=edit
> gcc7-pr79390-ecm.patch
> 
> Untested fix for the -O3 -ffast-math -march=haswell case.
> The difference between -fno-fast-math and -ffast-math is in:
>   if (swap_commutative_operands_p (op2, op3)
>   && ((reversed = reversed_comparison_code_parts (code, op0, op1, NULL))
>   != UNKNOWN))
> {
>   std::swap (op2, op3);
>   code = reversed;
> }
> 
> swap_commutative_operands_p is true in both cases, but without
> -ffast-math reversed_comparison_code_parts fails (returns UNKNOWN), so we 
> don't
> try that order and succeed, while with -ffast-math it doesn't fail, returns 
> LE,
> but we reject it in the predicates of the cmov insn and thus don't emit
> anything.  This patch just retries with the other order of operands in that
> case.

Looks sensible.

[Bug tree-optimization/79390] [7 Regression] 10% performance drop in SciMark2 LU after r242550

[jakub at gcc dot gnu.org]

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

--- Comment #26 from Jakub Jelinek  ---
Created attachment 41189
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41189=edit
gcc7-pr79390-ecm.patch

Untested fix for the -O3 -ffast-math -march=haswell case.
The difference between -fno-fast-math and -ffast-math is in:
  if (swap_commutative_operands_p (op2, op3)
  && ((reversed = reversed_comparison_code_parts (code, op0, op1, NULL))
  != UNKNOWN))
{
  std::swap (op2, op3);
  code = reversed;
}

swap_commutative_operands_p is true in both cases, but without
-ffast-math reversed_comparison_code_parts fails (returns UNKNOWN), so we don't
try that order and succeed, while with -ffast-math it doesn't fail, returns LE,
but we reject it in the predicates of the cmov insn and thus don't emit
anything.  This patch just retries with the other order of operands in that
case.

[Bug debug/77343] ICE in dwarf2out_frame_debug_expr, at dwarf2cfi.c:1596

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Confirmed, started with 4.8.0, before that:

pr77343.c:1:0: error: -mpreferred-stack-boundary=3 is not between 4 and 12

[Bug c/80409] Document that va_arg(ap, void*) can be used to consume any pointer argument

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
I don't see why this needs to be documented as it should work even with
standard c. That is for an example %p in printf takes a void* but nobody casts
it to void* when passing to printf.

[Bug gcov-profile/71672] inlining indirect calls does not work with autofdo

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
I will take a look as soon as autofdo issues will be resolved:
https://github.com/google/autofdo/issues/43

[Bug c++/80412] [c++17] crash with class template deduction guide and inheritance

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code

--- Comment #1 from Markus Trippelsdorf  ---
template  struct A;
template  struct B : A < B { ,

[Bug c++/80412] [c++17] crash with class template deduction guide and inheritance

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

   Keywords||error-recovery
   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-04-12
 CC||trippels at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug rtl-optimization/80357] [7 Regression] ICE in model_update_limit_points_in_group, at haifa-sched.c:1982 on powerpc64le-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug tree-optimization/79390] [7 Regression] 10% performance drop in SciMark2 LU after r242550

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P1  |P2

[Bug c++/80412] New: [c++17] crash with class template deduction guide and inheritance

[h2+bugs at fsfe dot org]

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

Bug ID: 80412
   Summary: [c++17] crash with class template deduction guide and
inheritance
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: h2+bugs at fsfe dot org
  Target Milestone: ---

Created attachment 41188
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41188=edit
intermediate file

% uname -a 
FreeBSD  11.0-RELEASE-p1 FreeBSD 11.0-RELEASE-p1 #0 r306420: Thu Sep 29
01:43:23 UTC 2016 r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC
 amd64

% g++7 --version
g++7 (FreeBSD Ports Collection) 7.0.1 20170402 (experimental)
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


I have a class template that has a user defined type deduction guide and
another class template that inherits from the first (and doesn't have its own
guide).
If I try to instantiate an object of the derived class without <>, i.e.
triggering type deduction, I first get an error that type deduction failed and
then a crash:

/home/mi/h4nn3s/devel/seqan3/test/alphabet/quality/composition_test.cpp:187:50:
error: class template argument deduction failed:
 quality_composition t0{dna4::C, illumina18{7}};
  ^
/home/mi/h4nn3s/devel/seqan3/test/alphabet/quality/composition_test.cpp:187:50:
internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


I have attached the zipped .ii

Adding a manual deduction guide for the derived class template fixes the
problem. I am not sure what the expected behaviour is, i.e. whether guides
should be inherited -- if possible -- or not, but I thought I would report the
crash in any case.

Note that I use -fconcepts, but I think it is unrelated.

[Bug tree-optimization/79390] [7 Regression] 10% performance drop in SciMark2 LU after r242550

[rguenth at gcc dot gnu.org]

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

--- Comment #25 from Richard Biener  ---
So the original report is fixed (-O3 -march-native).  But adding -ffast-math
still ends up regressing.

At this point it's probably appropriate to re-target to GCC 8.

[Bug middle-end/80411] DCE vs. offloading

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
They are probably referenced in the global tables we build for offloading?  The
symtab code isn't made aware of those references though.

.offload_var_table:
.section.gnu.offload_funcs,"aw",@progbits
.align 8
.type   .offload_func_table, @object
.size   .offload_func_table, 16
.offload_func_table:
.quad   main._omp_fn.0
.quad   main._omp_fn.1
.comm   __gnu_lto_v1,1,1

not sure where we emit the above.

[Bug target/77728] [5/6/7 Regression] Miscompilation multiple vector iteration on ARM

[rguenther at suse dot de]

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

--- Comment #13 from rguenther at suse dot de  ---
On Wed, 12 Apr 2017, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77728
> 
> Jakub Jelinek  changed:
> 
>What|Removed |Added
> 
>  CC||jason at gcc dot gnu.org
> 
> --- Comment #12 from Jakub Jelinek  ---
> I had a brief look at why there is the difference in DECL_ALIGN on TYPE_DECL
> in this case, and the difference seems to come up from whether the type
> size/layout has been finalized before calling layout_decl on the corresponding
> TYPE_DECL or not.  The question is if we ever except for the arm/aarch64 bug
> ever care about DECL_ALIGN on TYPE_DECLs, if yes, perhaps finalize_type_size
> should check if type or any variant's TYPE_NAME is a TYPE_DECL and in that 
> case
> relayout_decl it?

IMHO TYPE_DECL shouldn't even _have_ DECL_ALIGN ...

[Bug target/77728] [5/6/7 Regression] Miscompilation multiple vector iteration on ARM

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #12 from Jakub Jelinek  ---
I had a brief look at why there is the difference in DECL_ALIGN on TYPE_DECL
in this case, and the difference seems to come up from whether the type
size/layout has been finalized before calling layout_decl on the corresponding
TYPE_DECL or not.  The question is if we ever except for the arm/aarch64 bug
ever care about DECL_ALIGN on TYPE_DECLs, if yes, perhaps finalize_type_size
should check if type or any variant's TYPE_NAME is a TYPE_DECL and in that case
relayout_decl it?

[Bug target/80082] [5/6 regression] GCC incorrectly assumes Cortex-r[578] have 64-bit single-copy atomic LDRD

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||ramana at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #12 from Ramana Radhakrishnan  ---
Fixed .

[Bug rtl-optimization/78255] [5/6 regression] Indirect sibling call causing wrong code generation for ARM

[andre.simoesdiasvieira at arm dot com]

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

Andre Vieira  changed:

   What|Removed |Added

 CC||andre.simoesdiasvieira@arm.
   ||com

--- Comment #17 from Andre Vieira  ---
Yes, how do I change this to "verified"?

[Bug target/80236] ARM NEON: Crash in std::map

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #11 from ktkachov at gcc dot gnu.org ---
I can't reproduce the segfault with a 6.3.1 arm-linux-gnueabihf toolchain.
What glibc version are you using?

[Bug middle-end/79209] [5/6/7 Regression] AArch64: Inconsistent packed volatile bitfield accesses

[p...@gcc-bugzilla.mail.kapsi.fi]

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

--- Comment #5 from Pekka S  ---
It's true what you quoted, but on the other hand the current behaviour does not
produce code that will not fault -- it will indeed fault.

I see the rationale behind the packed attribute applied to a structure (say,
the attached structure has a default alignment of 4) so the compiler may
generate access that is narrower (or has a smaller alignment) that what it
would be normally be (at least with strict alignment) for whatever reason.

However, bitfields are not marked volatile and -fstrict-volatile-bitfield is
not used just for nothing. So when it says "it may not be possible to access
the field with a single read or write [...]" I don't why it wouldn't be
possible to use access that has a greater alignment requirement (on a strict
aligment platform -- although it's actually run-time configurable on AArch64)
than what the structure has with the packed attribute (reduced to the minimum,
i.e. 1) set.

Now, it could be argued, that with the packed attribute one could still force
narrower volatile bitfield accesses if -fstrict-volatile-bitfield is used (I
can't think of any reason why one would, but still), but currently even that is
not possible as the accesses are not consistent. Also, what is the most
misleading in this case is that -fstrict-volatile-bitfield "should use a single
access of the width of the field's type" and I guess everyone agrees that
packed attribute has nothing to do with width of the field's type, at least
with attached structure and alike. So, perhaps inheritably by language design
width and alignment are used somewhat interchangeably, even though they are
not.

Maybe this falls a bit inside the undefined behaviour land, but again, a
warning message would suffice, if the behaviour is not going to be changed to
inform the user that his mileage may vary.