[Bug fortran/63158] Possible wrong code with absend optional BT_CLASS -> optional BT_DERIVED dummy argument

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  ---
Ping!

[Bug c/67435] Feature request: Implement align-loops attribute

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-09-04
Summary|Large performance drop on   |Feature request: Implement
   |apparently unrelated|align-loops attribute
   |changes (potential cause :  |
   |hot loop alignment) |
 Ever confirmed|0   |1

[Bug c/67279] -fsanitize=undefined spurious error: initializer element is not constant

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #9 from Marek Polacek  ---
This particular issue is fixed on trunk now.  (There are more of these.)

[Bug rtl-optimization/67449] Branch elimination problem on x86

[lh_mouse at 126 dot com]

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

lh_mouse  changed:

   What|Removed |Added

   Severity|minor   |trivial

[Bug fortran/67444] RHS in assignment of polymorphic types not finalized

[baradi09 at gmail dot com]

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

--- Comment #2 from Bálint Aradi  ---
Apparently, this is point c) in PR 37336 comment 27.

[Bug fortran/67430] reallocate lhs with overloaded assignment operators causes memory error and wrong size

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
Am I correct to summarize (simplify?) your expectation (interpretation as:

use the overloaded assignment if the lhs and rhs are conforming, otherwise use
the intrinsic assignment?

If yes, what the compiler should do if some bounds are only known at run time?

I agree with the first comment of Ian Harvey at
https://groups.google.com/forum/#!topic/comp.lang.fortran/Vk4D8iDZOdc.

I have no opinion for the second test in the above thread, beside a "don't do
that!". If you think it is a gfortran bug, please file a new PR and, if
possible, outputs from other compilers you have access to.

[Bug rtl-optimization/67449] New: Branch elimination problem on x86

[lh_mouse at 126 dot com]

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

Bug ID: 67449
   Summary: Branch elimination problem on x86
   Product: gcc
   Version: 4.9.3
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lh_mouse at 126 dot com
  Target Milestone: ---

The following `do ... while` statement creates a loop with two branches:

C code:

int a[10];

void next(int **pp){
(++*pp == a + 10) && (*pp = 0);
}

int main(){
for(int i = 0; i < 10; ++i){
a[i] = i;
}

int *p = a;
do {
__builtin_printf("element = %d\n", *p);
next();
//  __asm__("");
} while(p);
}


Assembly output:

L13:
testl   %ebx, %ebx
je  L6  ; one here.
L4:
movl(%ebx), %eax
movl$LC1, (%esp)
addl$4, %ebx
movl%eax, 4(%esp)
call_printf
cmpl$_a+40, %ebx
jne L13 ; another one here.
L6:


But if we uncomment that empty __asm__ statement, the first branch vanishes:

Assembly output:

L5:
movl(%ebx), %eax
movl$LC1, (%esp)
addl$4, %ebx
movl%eax, 4(%esp)
call_printf
cmpl$_a+40, %ebx
cmove   %esi, %ebx
testl   %ebx, %ebx  ; the only one branch in this loop.
jne L5

[Bug c++/56568] std::initializer_list return value contents lost prematurely

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
(In reply to fuzzyTew from comment #4)
> I'm not as experienced in the details.  I think perhaps my example is
> invalid as you state but the original testcase is not (see &&).

That makes no difference. Using my previous example, David's original testcase
is roughly equivalent to:

const int& f() {
  long i = 0;
  return i;
}

auto&& i = f();

It's irrelevant what you do with the result, f() returns a dangling reference
to an object that doesn't exist after the function returns.


(In reply to David Krauss from comment #5)
> I'm working on an ISO proposal (http://bit.ly/genlife) to fix some such
> cases in C++17, but all it would do for return values is allow the compiler
> to produce a warning. The way initializer_list works, the sequence is
> intrinsically incapable of escaping the current scope, much less the current
> function.

Right.

I opened PR 67445 to suggest a warning for cases like this, but I don't expect
it to be implemented any time soon.

[Bug fortran/67431] ALLOCATE with SOURCE ignores overloaded assignment operator and uses intrinsic when copying values

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  ---
>From Damian Rouson:

NAG 6.0 ouptput:

SIZE(A) 4 A 765 765 765 765


Cray Compiler Environment (CCE) 8.3.14 output:

SIZE(A) 4 A 4*765


Portland Group 15.7-0 output:

SIZE(A)4 A  765  765  765  765

and Andre Vehreschild told me on IRC that gfortran agrees with ifort.

[Bug libstdc++/65473] Including does not define __GLIBCXX__

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |6.0

--- Comment #7 from Jonathan Wakely  ---
All libstdc++ headers should include c++config.h now.

[Bug libstdc++/65473] Including does not define __GLIBCXX__

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Author: redi
Date: Fri Sep  4 09:16:29 2015
New Revision: 227484

URL: https://gcc.gnu.org/viewcvs?rev=227484=gcc=rev
Log:
Make all  headers include 

PR libstdc++/65473
* include/c/cassert: Include .
* include/c/cerrno: Likewise.
* include/c/cfloat: Likewise.
* include/c/ciso646: Likewise.
* include/c/climits: Likewise.
* include/c_global/cassert: Likewise.
* include/c_global/cerrno: Likewise.
* include/c_global/cfloat: Likewise.
* include/c_global/ciso646: Likewise.
* include/c_global/climits: Likewise.
* include/c_std/cassert: Likewise.
* include/c_std/cerrno: Likewise.
* include/c_std/cfloat: Likewise.
* include/c_std/ciso646: Likewise.
* include/c_std/climits: Likewise.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/c/cassert
trunk/libstdc++-v3/include/c/cerrno
trunk/libstdc++-v3/include/c/cfloat
trunk/libstdc++-v3/include/c/ciso646
trunk/libstdc++-v3/include/c/climits
trunk/libstdc++-v3/include/c_global/cassert
trunk/libstdc++-v3/include/c_global/cerrno
trunk/libstdc++-v3/include/c_global/cfloat
trunk/libstdc++-v3/include/c_global/ciso646
trunk/libstdc++-v3/include/c_global/climits
trunk/libstdc++-v3/include/c_std/cassert
trunk/libstdc++-v3/include/c_std/cerrno
trunk/libstdc++-v3/include/c_std/cfloat
trunk/libstdc++-v3/include/c_std/ciso646
trunk/libstdc++-v3/include/c_std/climits

[Bug c/67448] New: compiler crash#inline assembly#rvalue operand with constraint "m"

[barannikov88 at gmail dot com]

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

Bug ID: 67448
   Summary: compiler crash#inline assembly#rvalue operand with
constraint "m"
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barannikov88 at gmail dot com
  Target Milestone: ---

$ cat t1.c
void f(int i)
{
__asm("" : : "m"(i += 1));
}

$gcc t1.c -S
t1.c: In function 'f':
t1.c:3:24: internal compiler error: in expand_gimple_stmt_1, at
cfgexpand.c:3391
 __asm("" : : "m"(i += 1));
^
0x82b4249 expand_gimple_stmt_1
../../gcc-5.1.0.src/gcc/cfgexpand.c:3390
0x82b4249 expand_gimple_stmt
../../gcc-5.1.0.src/gcc/cfgexpand.c:3497
0x82b7746 expand_gimple_basic_block
../../gcc-5.1.0.src/gcc/cfgexpand.c:5509
0x82b9356 execute
../../gcc-5.1.0.src/gcc/cfgexpand.c:6127
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

The operand is an rvalue and should be restricted from using within this
context, like 'i++' is. Strangely enough, 'i = 0' is allowed despite of the
fact that it is also an rvalue.

[Bug testsuite/67450] New: [6 Regression] ERROR: can't unset "et_cache(ia32,value)": no such element in array

[hjl.tools at gmail dot com]

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

Bug ID: 67450
   Summary: [6 Regression] ERROR: can't unset
"et_cache(ia32,value)": no such element in array
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: clyon at gcc dot gnu.org
  Target Milestone: ---

r227401 added

proc check_cached_effective_target { prop args } {
global et_cache
global et_prop_list

set target [current_target_name]
if {![info exists et_cache($prop,target)]
|| $et_cache($prop,target) != $target} {
verbose "check_cached_effective_target $prop: checking $target" 2
set et_cache($prop,target) $target
set et_cache($prop,value) [uplevel eval $args]
lappend et_prop_list $prop


When $prop is already on et_prop_list, it leads to

ERROR: can't unset "et_cache(ia32,value)": no such element in array

in clear_effective_target_cache.

verbose "check_cached_effective_target cached list is now:
$et_prop_list" 2
}
set value $et_cache($prop,value)
verbose "check_cached_effective_target $prop: returning $value for
$target" 2
return $value
}

[Bug c/67435] Large performance drop on apparently unrelated changes (potential cause : hot loop alignment)

[trippels at gcc dot gnu.org]

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

--- Comment #9 from Markus Trippelsdorf  ---
(In reply to Yann Collet from comment #8)
> However, for some reason, in the table provided, both Sandy Bridge and
> Haswell get a default loop alignment value of 16. not 32.
> 
> Is there a reason for that choice ?

These values are normally strait out of the Vendors manuals.
And there are also drawbacks to high alignment values.

> Less precise but still great, having the ability to set this optimization
> parameter for a function or a section code would be great. But my experiment
> seem to show that using #pragma or __attribute__ with align-loops does not
> work, as if the optimization setting was simply ignored.

Well, there already is an aligned attribute for functions, variables and
fields,
see: 
http://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes

[Bug libstdc++/65704] Provide portable versions of std::timed_mutex and std::recursive_timed_mutex

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Fri Sep  4 11:23:44 2015
New Revision: 227490

URL: https://gcc.gnu.org/viewcvs?rev=227490=gcc=rev
Log:
Add portable timed_mutex and recursive_timed_mutex.

PR libstdc++/65704
* include/Makefile.am: Add .
* include/Makefile.in: Regenerate.
* include/bits/mutex.h (__mutex_base, mutex, lock_guard, unique_lock):
New file containing types moved from .
* include/std/condition_variable: Include  instead of
.
* include/std/mutex (__mutex_base, mutex, lock_guard, unique_lock):
Move to .
*  testsuite/30_threads/recursive_timed_mutex/cons/1.cc: Remove
dg-require-gthreads-timed.
*  testsuite/30_threads/recursive_timed_mutex/cons/assign_neg.cc:
Likewise.
*  testsuite/30_threads/recursive_timed_mutex/cons/copy_neg.cc:
Likewise.
*  testsuite/30_threads/recursive_timed_mutex/dest/
destructor_locked.cc: Likewise.
*  testsuite/30_threads/recursive_timed_mutex/lock/1.cc: Likewise.
*  testsuite/30_threads/recursive_timed_mutex/lock/2.cc: Likewise.
*  testsuite/30_threads/recursive_timed_mutex/try_lock/1.cc: Likewise.
*  testsuite/30_threads/recursive_timed_mutex/try_lock/2.cc: Likewise.
*  testsuite/30_threads/recursive_timed_mutex/try_lock_for/1.cc:
Likewise.
*  testsuite/30_threads/recursive_timed_mutex/try_lock_for/2.cc:
Likewise.
*  testsuite/30_threads/recursive_timed_mutex/try_lock_for/3.cc:
Likewise.
*  testsuite/30_threads/recursive_timed_mutex/try_lock_until/1.cc:
Likewise.
*  testsuite/30_threads/recursive_timed_mutex/try_lock_until/2.cc:
Likewise.
*  testsuite/30_threads/recursive_timed_mutex/unlock/1.cc: Likewise.
*  testsuite/30_threads/timed_mutex/cons/1.cc: Likewise.
*  testsuite/30_threads/timed_mutex/cons/assign_neg.cc: Likewise.
*  testsuite/30_threads/timed_mutex/cons/copy_neg.cc: Likewise.
*  testsuite/30_threads/timed_mutex/dest/destructor_locked.cc:
Likewise.
*  testsuite/30_threads/timed_mutex/lock/1.cc: Likewise.
*  testsuite/30_threads/timed_mutex/requirements/standard_layout.cc:
Likewise.
*  testsuite/30_threads/timed_mutex/try_lock/1.cc: Likewise.
*  testsuite/30_threads/timed_mutex/try_lock/2.cc: Likewise.
*  testsuite/30_threads/timed_mutex/try_lock_for/1.cc: Likewise.
*  testsuite/30_threads/timed_mutex/try_lock_for/2.cc: Likewise.
*  testsuite/30_threads/timed_mutex/try_lock_for/3.cc: Likewise.
*  testsuite/30_threads/timed_mutex/try_lock_until/1.cc: Likewise.
*  testsuite/30_threads/timed_mutex/try_lock_until/2.cc: Likewise.
*  testsuite/30_threads/timed_mutex/try_lock_until/57641.cc: Likewise.
*  testsuite/30_threads/timed_mutex/unlock/1.cc: Likewise.
*  testsuite/30_threads/unique_lock/cons/5.cc: Likewise.
*  testsuite/30_threads/unique_lock/cons/6.cc: Likewise.
*  testsuite/30_threads/unique_lock/locking/3.cc: Likewise.
*  testsuite/30_threads/unique_lock/locking/4.cc: Likewise.

Added:
trunk/libstdc++-v3/include/bits/mutex.h
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/Makefile.am
trunk/libstdc++-v3/include/Makefile.in
trunk/libstdc++-v3/include/std/condition_variable
trunk/libstdc++-v3/include/std/mutex
trunk/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/cons/1.cc
   
trunk/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/cons/assign_neg.cc
   
trunk/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/cons/copy_neg.cc
   
trunk/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/dest/destructor_locked.cc
trunk/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/lock/1.cc
trunk/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/lock/2.cc
trunk/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/try_lock/1.cc
trunk/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/try_lock/2.cc
   
trunk/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/try_lock_for/1.cc
   
trunk/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/try_lock_for/2.cc
   
trunk/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/try_lock_for/3.cc
   
trunk/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/try_lock_until/1.cc
   
trunk/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/try_lock_until/2.cc
trunk/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/unlock/1.cc
trunk/libstdc++-v3/testsuite/30_threads/timed_mutex/cons/1.cc
trunk/libstdc++-v3/testsuite/30_threads/timed_mutex/cons/assign_neg.cc
trunk/libstdc++-v3/testsuite/30_threads/timed_mutex/cons/copy_neg.cc
   

[Bug libstdc++/65704] Provide portable versions of std::timed_mutex and std::recursive_timed_mutex

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
Fixed on trunk

[Bug c/67279] -fsanitize=undefined spurious error: initializer element is not constant

[mpolacek at gcc dot gnu.org]

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

--- Comment #8 from Marek Polacek  ---
Author: mpolacek
Date: Fri Sep  4 12:37:39 2015
New Revision: 227491

URL: https://gcc.gnu.org/viewcvs?rev=227491=gcc=rev
Log:
PR sanitizer/67279
* c-typeck.c (build_binary_op): Don't instrument static initializers.

* gcc.dg/ubsan/pr67279.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/ubsan/pr67279.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-typeck.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/52902] Pointer to member rejected in constant expression

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||ldionne.2 at gmail dot com

--- Comment #1 from Markus Trippelsdorf  ---
*** Bug 67376 has been marked as a duplicate of this bug. ***

[Bug fortran/67451] New: ICE with sourced allocation from coarray.

[ian_harvey at bigpond dot com]

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

Bug ID: 67451
   Summary: ICE with sourced allocation from coarray.
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ian_harvey at bigpond dot com
  Target Milestone: ---

The following, when compiled with trunk r227476, results in a ICE:

  program main
implicit none
type foo
  integer :: bar = 99
end type
class(foo), allocatable :: foobar[:]
class(foo), allocatable :: some_local_object
allocate(foobar[*])
allocate(some_local_object, source=foobar)
  end program

The ICE is associated with the use of a coarray or coindexed object in the
source expression of the allocate statement.



$ gfortran -v -fcoarray=lib 2015-09-04\ sourced-alloc.f90
Driving: gfortran -v -fcoarray=lib 2015-09-04 sourced-alloc.f90 -l gfortran -l
m -shared-libgcc
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/MEGMS2/ian/usr/gcc-6.0.0/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: .././src/configure --prefix=/home/MEGMS2/ian/usr/gcc-6.0.0
--enable-languages=c,c++,fortran --enable-libgomp --enable-checking=release
Thread model: posix
gcc version 6.0.0 20150903 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-fcoarray=lib' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 /home/MEGMS2/ian/usr/gcc-6.0.0/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/f951
2015-09-04 sourced-alloc.f90 -quiet -dumpbase 2015-09-04 sourced-alloc.f90
-mtune=generic -march=x86-64 -auxbase 2015-09-04 sourced-alloc -version
-fcoarray=lib -fintrinsic-modules-path
/home/MEGMS2/ian/usr/gcc-6.0.0/lib/gcc/x86_64-pc-linux-gnu/6.0.0/finclude -o
/tmp/ccX5BIwU.s
GNU Fortran (GCC) version 6.0.0 20150903 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 6.0.0 20150903 (experimental), GMP version
6.0.0, MPFR version 3.1.2, MPC version 1.0.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran2008 (GCC) version 6.0.0 20150903 (experimental)
(x86_64-pc-linux-gnu)
compiled by GNU C version 6.0.0 20150903 (experimental), GMP version
6.0.0, MPFR version 3.1.2, MPC version 1.0.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
2015-09-04 sourced-alloc.f90:9:0:

 allocate(some_local_object, source=foobar)
1
internal compiler error: Segmentation fault
0xa1271f crash_signal
../.././src/gcc/toplev.c:352
0x690f9e gfc_class_vptr_get(tree_node*)
../.././src/gcc/fortran/trans-expr.c:153
0x694155 class_vtab_field_get
../.././src/gcc/fortran/trans-expr.c:201
0x694155 gfc_class_vtab_copy_get(tree_node*)
../.././src/gcc/fortran/trans-expr.c:223
0x694155 gfc_copy_class_to_class(tree_node*, tree_node*, tree_node*, bool)
../.././src/gcc/fortran/trans-expr.c:1084
0x6cd11b gfc_trans_allocate(gfc_code*)
../.././src/gcc/fortran/trans-stmt.c:5725
0x66a7e7 trans_code
../.././src/gcc/fortran/trans.c:1798
0x68d6f3 gfc_generate_function_code(gfc_namespace*)
../.././src/gcc/fortran/trans-decl.c:5900
0x627210 translate_all_program_units
../.././src/gcc/fortran/parse.c:5526
0x627210 gfc_parse_file()
../.././src/gcc/fortran/parse.c:5731
0x667ba2 gfc_be_parse_file
../.././src/gcc/fortran/f95-lang.c:209
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/52902] Pointer to member rejected in constant expression

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-09-04
 CC||trippels at gcc dot gnu.org
 Blocks||55004
 Ever confirmed|0   |1


Referenced Bugs:

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

[Bug c++/52902] Pointer to member rejected in constant expression

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

   Target Milestone|--- |5.0

[Bug bootstrap/67373] Can't compile gcc snapshot for avr target with mingw

[kontakt at michaelstather dot com]

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

--- Comment #2 from kontakt at michaelstather dot com ---
Thank you very much, compiling works now.
But, I get linker errors. With gcc4.9.2 it works fine, but both with 5.2 and 6
I get e.g.:

C:\AVRTools4Windows\share\doc\avr-libc-1.8.1\examples\demo>make
avr-gcc -g -Wall -O2 -mmcu=atmega8-c -o demo.o demo.c
avr-gcc -g -Wall -O2 -mmcu=atmega8  -Wl,-Map,demo.map -o demo.elf demo.o
c:/avrtools4windows/bin/../lib/gcc/avr/6.0.0/../../../../avr/bin/ld.exe: cannot
find crtatmega8.o: No such file or directory
c:/avrtools4windows/bin/../lib/gcc/avr/6.0.0/../../../../avr/bin/ld.exe: cannot
find -latmega8
collect2.exe: error: ld returned 1 exit status
Makefile:75: recipe for target 'demo.elf' failed
make: *** [demo.elf] Error 1

The file crtatmega8.o doesn't seem to exist. Other target mcus give similar
errors.

[Bug inline-asm/67448] compiler crash#inline assembly#rvalue operand with constraint "m"

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Perhaps gimplify_asm_expr should also reject MODIFY_EXPR:

--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -5210,7 +5210,8 @@ gimplify_asm_expr (tree *expr_p, gimple_seq *pre_p,
gimple_seq *post_p)
  if (TREE_CODE (inputv) == PREDECREMENT_EXPR
  || TREE_CODE (inputv) == PREINCREMENT_EXPR
  || TREE_CODE (inputv) == POSTDECREMENT_EXPR
- || TREE_CODE (inputv) == POSTINCREMENT_EXPR)
+ || TREE_CODE (inputv) == POSTINCREMENT_EXPR
+ || TREE_CODE (inputv) == MODIFY_EXPR)
TREE_VALUE (link) = error_mark_node;
  tret = gimplify_expr (_VALUE (link), pre_p, post_p,
is_gimple_lvalue, fb_lvalue | fb_mayfail);

[Bug inline-asm/67448] compiler crash#inline assembly#rvalue operand with constraint "m"

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-09-04
 CC||mpolacek at gcc dot gnu.org
  Component|c   |inline-asm
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.  Even 4.4 ICEs.

[Bug c++/67376] Comparison with pointer to past-the-end of array fails inside constant expression

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||trippels at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #2 from Markus Trippelsdorf  ---
dup.

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

[Bug c++/67376] Comparison with pointer to past-the-end of array fails inside constant expression

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|RESOLVED|NEW
   Last reconfirmed||2015-09-04
 Resolution|DUPLICATE   |---
 Ever confirmed|0   |1

--- Comment #3 from Markus Trippelsdorf  ---
Not a dup, sorry.

[Bug libstdc++/65704] Provide portable versions of std::timed_mutex and std::recursive_timed_mutex

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Sorry, that was a stupid last minute copy & paste error. Fix coming...

[Bug c++/52902] Pointer to member rejected in constant expression

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #2 from Markus Trippelsdorf  ---
Works with gcc-5 and trunk. Closing.

[Bug c++/55004] [meta-bug] constexpr issues

[trippels at gcc dot gnu.org]

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

Bug 52902 Summary: Pointer to member rejected in constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52902

   What|Removed |Added

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

[Bug libstdc++/65704] Provide portable versions of std::timed_mutex and std::recursive_timed_mutex

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 CC||iains at gcc dot gnu.org

--- Comment #5 from Iain Sandoe  ---
Created attachment 36292
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36292=edit
fix for bootstrap fail

thanks for working on this Jonathan,

small glitch: as of 227490, bootstrap is broken with problems in
libstdc++-v3/include/std/mutex.

the patch attached allows bootstrap to complete - but I can't be sure it's what
you'd intended.

[Bug middle-end/67452] New: LTO ICE with -fopenmp-simd

[jakub at gcc dot gnu.org]

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

Bug ID: 67452
   Summary: LTO ICE with -fopenmp-simd
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: jakub at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org, rguenth at gcc dot gnu.org
  Target Milestone: ---

On the gomp-4_1-branch the libgomp.c/for-5.c and libgomp.c++/for-13.C testcases
ICE with intelmic emul offloading, I've reduced it down to -O2 -fopenmp-simd
-flto on the following testcase:
float b[3][3];

__attribute__((used, noinline)) void
foo ()
{
  int v1, v2;
#pragma omp simd collapse(2)
  for (v1 = 0; v1 < 3; v1++)
for (v2 = 0; v2 < 3; v2++)
  b[v1][v2] = 2.5;
}

int
main ()
{
  asm volatile ("" : : "r" (b) : "memory");
  foo ();
  asm volatile ("" : : "r" (b) : "memory");
  return 0;
}

The ICE is:
In function ‘foo’:
lto1: internal compiler error: in operator[], at vec.h:714
0x73a7a4 vec::operator[](unsigned int)
../../gcc/vec.h:714
0x73949c vec::operator[](unsigned int)
../../gcc/vec.h:1180
0xedf193 streamer_tree_cache_get_tree
../../gcc/tree-streamer.h:111
0xee3487 streamer_get_pickled_tree(lto_input_block*, data_in*)
../../gcc/tree-streamer-in.c:1105
0xae9d42 lto_input_tree_1(lto_input_block*, data_in*, LTO_tags, unsigned int)
../../gcc/lto-streamer-in.c:1428
0xae9f7b lto_input_tree(lto_input_block*, data_in*)
../../gcc/lto-streamer-in.c:1474
0xee1da5 lto_input_ts_decl_minimal_tree_pointers
../../gcc/tree-streamer-in.c:689
0xee31c4 streamer_read_tree_body(lto_input_block*, data_in*, tree_node*)
../../gcc/tree-streamer-in.c:1046
0xae99b2 lto_read_tree_1
../../gcc/lto-streamer-in.c:1304
0xae9abd lto_read_tree
../../gcc/lto-streamer-in.c:1338
0xae9f12 lto_input_tree_1(lto_input_block*, data_in*, LTO_tags, unsigned int)
../../gcc/lto-streamer-in.c:1457
0xae9b37 lto_input_scc(lto_input_block*, data_in*, unsigned int*, unsigned
int*)
../../gcc/lto-streamer-in.c:1362
0xae9f61 lto_input_tree(lto_input_block*, data_in*)
../../gcc/lto-streamer-in.c:1472
0xae828a input_cfg
../../gcc/lto-streamer-in.c:863
0xae8e71 input_function
../../gcc/lto-streamer-in.c:1079
0xae9683 lto_read_body_or_constructor
../../gcc/lto-streamer-in.c:1232
0xae993c lto_input_function_body(lto_file_decl_data*, cgraph_node*, char
const*)
../../gcc/lto-streamer-in.c:1278
0x7f4d60 cgraph_node::get_untransformed_body()
../../gcc/cgraph.c:3286
0x800c84 cgraph_node::expand()
../../gcc/cgraphunit.c:1892
0x801395 expand_all_functions
../../gcc/cgraphunit.c:2056
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: fatal error: ./xgcc returned 1 exit status
compilation terminated.
/usr/bin/ld: lto-wrapper failed
collect2: error: ld returned 1 exit status

The problem is that early optimizations eliminate simduid.3 uses and during
release_ssa pass it is removed from cfun->local_decls, but remains in
loop->simduid, and the LTO streaming doesn't expect to have trees streamed too
late (during output_cfg) apparently.

[Bug target/65210] [avr] ICE: when using attributs 'address' and 'io_low'

[denisc at gcc dot gnu.org]

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

--- Comment #3 from denisc at gcc dot gnu.org ---
Author: denisc
Date: Fri Sep  4 16:34:11 2015
New Revision: 227496

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

PR target/65210
* config/avr/avr.c (avr_eval_addr_attrib): Look for io_low
attribute as well.

gcc/testsuite/ChangeLog

PR target/65210
* gcc.target/avr/pr65210.c: New test.



Added:
trunk/gcc/testsuite/gcc.target/avr/pr65210.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/avr/avr.c
trunk/gcc/testsuite/ChangeLog

[Bug testsuite/67450] [6 Regression] ERROR: can't unset "et_cache(ia32,value)": no such element in array

[hjl at gcc dot gnu.org]

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

--- Comment #1 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Fri Sep  4 15:09:22 2015
New Revision: 227492

URL: https://gcc.gnu.org/viewcvs?rev=227492=gcc=rev
Log:
Apppend $prop to et_prop_list only if needed

PR testsuite/67450
* lib/target-supports.exp (check_cached_effective_target):
Apppend $prop to et_prop_list only if needed.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/lib/target-supports.exp

[Bug c++/67453] New: vtable not emitted for class with no key method and defaulted destructor with attribute((used))

[redi at gcc dot gnu.org]

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

Bug ID: 67453
   Summary: vtable not emitted for class with no key method and
defaulted destructor with attribute((used))
   Product: gcc
   Version: 4.9.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

>From https://gcc.gnu.org/ml/gcc-help/2015-09/msg00015.html

The following class when compiled with g++ 4.9.2 emits the vtable for class
Foo:

class Foo
{

  virtual void dosomething() { }
  virtual ~Foo() noexcept __attribute__((used)) { }
};

The following class when compiled does not emit the vtable:

class Foo
{

  virtual void dosomething() { }
  virtual ~Foo() noexcept __attribute__((used)) = default;
};

[Bug middle-end/60725] [-Wreturn-type] false positive in trivial switch

[jens.auer at cgi dot com]

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

Jens Auer  changed:

   What|Removed |Added

 CC||jens.auer at cgi dot com

--- Comment #2 from Jens Auer  ---
This warnings becomes annoying when you also compile with -Wswitch-enum which
forces you to cover all enum values. When they are all covered, I do not need a
default statement, but to prevent Wreturn-type, I have to add a pseudo-default.

[Bug c++/67376] [5/6 regression] Comparison with pointer to past-the-end of array fails inside constant expression

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

   Keywords||rejects-valid
Summary|Comparison with pointer to  |[5/6 regression] Comparison
   |past-the-end of array fails |with pointer to
   |inside constant expression  |past-the-end of array fails
   ||inside constant expression

--- Comment #4 from Markus Trippelsdorf  ---
Started with r214941.

[Bug c++/67376] [5/6 regression] Comparison with pointer to past-the-end of array fails inside constant expression

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #6 from Martin Sebor  ---
It also fails for pointers into the array (e.g., if the number of elements in
elems_ is changed to 2).  However, it doesn't fail when the operands of the ==
operator are exchanged.

[Bug bootstrap/67363] [6 Regression] r227188 breaks build for mingw-w64

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 CC||danglin at gcc dot gnu.org

--- Comment #10 from John David Anglin  ---
The setenv and unsetenv issue also affects hppa*-*-hpux*.

[Bug c++/67453] vtable not emitted for class with no key method and defaulted destructor with attribute((used))

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-09-04
 CC||jason at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jason Merrill  ---
The bug is that we aren't emitting ~Foo even though it's marked used; the
vtable is just a side effect.

[Bug c++/67376] [5/6 regression] Comparison with pointer to past-the-end of array fails inside constant expression

[trippels at gcc dot gnu.org]

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

--- Comment #5 from Markus Trippelsdorf  ---
And:

 static_assert(a.elems_ + 1, "");

started to get rejected with r212499.

[Bug libstdc++/65704] Provide portable versions of std::timed_mutex and std::recursive_timed_mutex

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
I wasn't actually testing the new code at all due to a cock up when trying to
undefine the macro that differs between darwin and other targets. Should be OK
now.

[Bug middle-end/60725] [-Wreturn-type] false positive in trivial switch

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #3 from Manuel López-Ibáñez  ---
(In reply to Marek Polacek from comment #1)
> It adds the default case at the end of the switch so we can jump over the
> whole switch body.  But it should do so only if the labels cover the whole
> range of the controlling expression of the switch.  Here the switch label
> seemingly covers the whole range of the enum, but TYPE_MAX_VALUE of the enum
> E is UINT_MAX, while the high value of the case label is 0.

But in C, e can contain any value of the underlying type (unsigned int). Thus
one can legally call f1(10), and then what happens next is probably a bug.

enum E { E1=0 };
static inline int f1(enum E e) {
  switch (e) {
  case E1: return 1;
  }
}
int main () {
  return f1(10);
}

If this is actually undefined behavior, -fsanitize=undefined does not seem to
catch it.

[Bug middle-end/60725] [-Wreturn-type] false positive in trivial switch

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #5 from Martin Sebor  ---
Not to complicate things too much, but reaching the closing } of a non-void
function is valid in C.  What is not valid (i.e., has undefined behavior) is
calling such a function and using its return value when none was provided (as
in the program in comment #3).  The program in the Description, however, has
well-defined behavior because f1's return value isn't used.

[Bug c/66516] missing diagnostic on taking the address of a builtin function

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |6.0

--- Comment #4 from Martin Sebor  ---
Fixed on trunk.

[Bug middle-end/67452] LTO ICE with -fopenmp-simd

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Author: jakub
Date: Fri Sep  4 18:32:00 2015
New Revision: 227498

URL: https://gcc.gnu.org/viewcvs?rev=227498=gcc=rev
Log:
PR middle-end/67452
* tree-ssa-live.c: Include cfgloop.h.
(remove_unused_locals): Clear loop->simduid if simduid is about
to be removed from cfun->local_decls.

* gcc.dg/lto/pr67452_0.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/lto/pr67452_0.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-live.c

[Bug middle-end/60725] [-Wreturn-type] false positive in trivial switch

[manu at gcc dot gnu.org]

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

--- Comment #7 from Manuel López-Ibáñez  ---
(In reply to Martin Sebor from comment #5)
> The program in the Description, however,
> has well-defined behavior because f1's return value isn't used.

It is also easy to silence the warning by adding an explicit abort() or
__builtin_unreachable() before the closing }.

[Bug fortran/67454] New: GCC-5.2.0 `GCC_4.3.0' not found (required by file /usr/local/add-on/gcc/lib/libgfortran.so.3)

[j.ballantine at gmail dot com]

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

Bug ID: 67454
   Summary: GCC-5.2.0 `GCC_4.3.0' not found (required by file
/usr/local/add-on/gcc/lib/libgfortran.so.3)
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: j.ballantine at gmail dot com
  Target Milestone: ---

When attempting to build R-3.2.2, the processing fails with:
ld.so.1: R: fatal: libgcc_s.so.1: version `GCC_4.3.0' not found (required by
file /usr/local/add-on/gcc/lib/libgfortran.so.3)
GCC 4.3.0 is not on the system, and gcc version was 3.4.6 when 5.2.0 was built.
the LD_LIBRARY_PATH includes a pointer to /usr/local/add-on/gcc/lib which is a
soft link to the gcc-5.2.0 install
/usr/local/add-on/gcc -> /usr/local/add-on/gcc-5.2.0/

[Bug fortran/67429] [5/6 Regression] Missing part of error messages.

[pault at gcc dot gnu.org]

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

--- Comment #16 from Paul Thomas  ---
Author: pault
Date: Fri Sep  4 18:37:50 2015
New Revision: 227500

URL: https://gcc.gnu.org/viewcvs?rev=227500=gcc=rev
Log:
2015-09-04  Manuel López-Ibáñez  

PR fortran/67429
* error.c (gfc_clear_pp_buffer): Reset last_location, otherwise
caret lines might be skipped when actually giving a diagnostic.

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

[Bug middle-end/67452] LTO ICE with -fopenmp-simd

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Fri Sep  4 18:36:59 2015
New Revision: 227499

URL: https://gcc.gnu.org/viewcvs?rev=227499=gcc=rev
Log:
PR middle-end/67452
* tree-ssa-live.c: Include cfgloop.h.
(remove_unused_locals): Clear loop->simduid if simduid is about
to be removed from cfun->local_decls.

* gcc.dg/lto/pr67452_0.c: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/gcc.dg/lto/pr67452_0.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/testsuite/ChangeLog
branches/gcc-5-branch/gcc/tree-ssa-live.c

[Bug middle-end/60725] [-Wreturn-type] false positive in trivial switch

[manu at gcc dot gnu.org]

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

--- Comment #6 from Manuel López-Ibáñez  ---
(In reply to Martin Sebor from comment #5)
> Not to complicate things too much, but reaching the closing } of a non-void
> function is valid in C.  What is not valid (i.e., has undefined behavior) is
> calling such a function and using its return value when none was provided
> (as in the program in comment #3).  The program in the Description, however,
> has well-defined behavior because f1's return value isn't used.

Good point. I don't know whether it is possible for the sanitizers to
distinguish between the two cases. 

Pretty sure it is not possible for the warning code, since at the time of
warning we know nothing of the callers (not even if there are any callers).

[Bug fortran/67429] [5/6 Regression] Missing part of error messages.

[pault at gcc dot gnu.org]

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

--- Comment #17 from Paul Thomas  ---
Author: pault
Date: Fri Sep  4 18:41:08 2015
New Revision: 227501

URL: https://gcc.gnu.org/viewcvs?rev=227501=gcc=rev
Log:
2015-09-04  Manuel López-Ibáñez  

PR fortran/67429
* error.c (gfc_clear_pp_buffer): Reset last_location, otherwise
caret lines might be skipped when actually giving a diagnostic.

Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/error.c

[Bug testsuite/67450] [6 Regression] ERROR: can't unset "et_cache(ia32,value)": no such element in array

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |6.0

--- Comment #2 from H.J. Lu  ---
Fixed.

[Bug fortran/34040] Support for DOUBLE_TYPE_SIZE != 64 targets

[olegendo at gcc dot gnu.org]

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

--- Comment #14 from Oleg Endo  ---
(In reply to Oleg Endo from comment #13)
> 
> I think it would be easier to leave DOUBLE_TYPE_SIZE == 64 in all cases and
> use software fp if the hardware can't do double precision.  If users insist
> on doubles being automatically truncated to floats then there should be a
> compiler switch for that.

This switch is already there: -fshort-double

[Bug c++/65009] [4.9 Regression] g++ 4.9 sometimes leaves inline methods undefined when compiling with -Os

[truckman at FreeBSD dot org]

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

--- Comment #4 from Don Lewis  ---
Still fails with:

% gcc49 --version
gcc49 (FreeBSD Ports Collection) 4.9.4 20150819 (prerelease)
Copyright (C) 2015 Free Software Foundation, Inc.

[Bug middle-end/60725] [-Wreturn-type] false positive in trivial switch

[manu at gcc dot gnu.org]

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

--- Comment #4 from Manuel López-Ibáñez  ---
(In reply to Jens Auer from comment #2)
> This warnings becomes annoying when you also compile with -Wswitch-enum
> which forces you to cover all enum values. When they are all covered, I do
> not need a default statement, but to prevent Wreturn-type, I have to add a
> pseudo-default.

Even if you do not explicitly write one, there is one for the case where the
value is outside the enum values, which is valid in C (but not in C++, as far
as I know, thus the warning would be questionable there). What is not valid is
to reach the end of a non-void function.

[Bug middle-end/67452] LTO ICE with -fopenmp-simd

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug fortran/67429] [5/6 Regression] Missing part of error messages.

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #18 from Paul Thomas  ---
Fixed on trunk and 5-branch. Thanks for raising the PR, Dominique, and thanks
for a quick fix, Manuel.

Paul

[Bug fortran/53379] [4.9/5/6 Regression] No backtrace generated for array bounds violation

[jb at gcc dot gnu.org]

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

--- Comment #24 from Janne Blomqvist  ---
Author: jb
Date: Fri Sep  4 22:17:11 2015
New Revision: 227503

URL: https://gcc.gnu.org/viewcvs?rev=227503=gcc=rev
Log:
PR 53379 Print backtrace on error termination.

2015-09-05  Janne Blomqvist  

PR fortran/53379
* libgfortran.h (exit_error): New prototype.
* runtime/error.c (exit_error): New function.
(os_error): Call exit_error instead of exit.
(runtime_error): Likewise.
(runtime_error_at): Likewise.
(internal_error): Likewise.
(generate_error): Likewise.
(notify_std): Likewise.
* runtime/stop.c (error_stop_string): Likewise.
(error_stop_numeric): Likewise.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/libgfortran.h
trunk/libgfortran/runtime/error.c
trunk/libgfortran/runtime/stop.c

[Bug target/66960] Need a builtin function to access interrupt or exception data

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Target||x86
Summary|Add a builtin to get the|Need a builtin function to
   |address of the current  |access interrupt or
   |stack frame |exception data

--- Comment #2 from H.J. Lu  ---
The interrupt and exception handlers are called by x86 processors.  X86
hardware pushes information onto stack and calls the handler.  We need
a builtin function to access interrupt or exception data from the
interrupt and exception handlers which are void function without
arguments.

[Bug libstdc++/65704] Provide portable versions of std::timed_mutex and std::recursive_timed_mutex

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
Author: redi
Date: Fri Sep  4 16:09:05 2015
New Revision: 227495

URL: https://gcc.gnu.org/viewcvs?rev=227495=gcc=rev
Log:
fix darwin bootstrap errors due to .

PR libstdc++/65704
* include/std/mutex (recursive_timed_mutex): Fix uses of _Can_lock.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/mutex

[Bug objc/67455] Inheriting from Object doesn't provide alloc, init or new rendering methods usless

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Object in both apple's runtime and the gnu runtime never provided these.

[Bug target/65804] blackfin: Not support global frame pointer with -fno-omit-frame-pointer

[gang.chen.5i5j at gmail dot com]

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

--- Comment #2 from Chen Gang  ---
It is about git commit "e52beba PR debug/54694". I am just consulting about it
in gcc-help mailing list.

[Bug debug/54694] [4.7/4.8 Regression] internal compiler error: in dwarf2out_frame_debug_expr, at dwarf2out.c:2387

[gang.chen.5i5j at gmail dot com]

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

Chen Gang  changed:

   What|Removed |Added

 CC||gang.chen.5i5j at gmail dot com

--- Comment #25 from Chen Gang  ---
(In reply to Richard Henderson from comment #20)
> Author: rth
> Date: Thu Jan 16 16:33:30 2014
> New Revision: 206667
> 
> URL: http://gcc.gnu.org/viewcvs?rev=206667=gcc=rev
> Log:
> PR debug/54694
> 
> Diagnose frame_pointer_required vs fixed hfp
> 
> Added:
> branches/gcc-4_7-branch/gcc/testsuite/gcc.target/i386/pr54694.c
> Modified:
> branches/gcc-4_7-branch/gcc/ChangeLog
> branches/gcc-4_7-branch/gcc/ira.c
> branches/gcc-4_7-branch/gcc/reginfo.c
> branches/gcc-4_7-branch/gcc/rtl.h


After this git commit, the current blackfin kernel code can not pass building
when enable FUNCTION_TRACER. The related bug number is Bug65804

I want to consult: Is it the original gcc and current kernel issue? or our
related git commit "e52beba PR debug/54694" need be improved?

Thanks.

[Bug fortran/53379] [4.9/5/6 Regression] No backtrace generated for array bounds violation

[jb at gcc dot gnu.org]

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

Janne Blomqvist  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2015-09/msg00382.ht
   ||ml
   Assignee|unassigned at gcc dot gnu.org  |jb at gcc dot gnu.org

--- Comment #23 from Janne Blomqvist  ---
Patch implementing "print backtrace on error termination" at
https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00382.html

[Bug c++/56701] [C++11] The *this* pointer fails to bind to rvalue reference to pointer type

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #3 from TC  ---
This still breaks:

struct A
{
  void f(){ A*&& a = &*this; }
};
int main(){}

[Bug c++/53878] [C++11] Abstract class constructors

[aschepler at gmail dot com]

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

--- Comment #1 from Andrew Schepler  ---
Created attachment 36293
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36293=edit
Abstract class constructors may skip virtual bases

Attached is my attempt at a patch for this issue.  In addition to allowing an
abstract constructor to skip initializing virtual bases, this makes it so that
abstract classes have no "complete" constructors (which could never be called
anyway), only the "base" kind.

[Bug fortran/67454] GCC-5.2.0 `GCC_4.3.0' not found (required by file /usr/local/add-on/gcc/lib/libgfortran.so.3)

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-09-04
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
How did you get gcc-5.2.0? did you have GCC_4.3.0 version? Can you compile
fortran code? If yes could you post the output of the compilation with -v?

[Bug libfortran/63930] libgfortran should use 'abort ()' instead of 'exit (2)' for run-time errors

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #5 from Francois-Xavier Coudert  ---
Closing this one as WONTFIX: we shouldn't abort() for run-time errors. But we
can print backtraces, which is PR53379, and is about to be fixed.

[Bug fortran/53379] [4.9/5/6 Regression] No backtrace generated for array bounds violation

[jb at gcc dot gnu.org]

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

Janne Blomqvist  changed:

   What|Removed |Added

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

--- Comment #25 from Janne Blomqvist  ---
Fixed on trunk, closing.

(I don't think this should be backported, as older releases lack the new and
improved libbacktrace-based backtracing implementation.)

[Bug objc/67455] New: Inheriting from Object doesn't provide alloc, init or new rendering methods usless

[jam.hobson at hotmail dot co.uk]

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

Bug ID: 67455
   Summary: Inheriting from Object doesn't provide alloc, init or
new rendering methods usless
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: objc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jam.hobson at hotmail dot co.uk
  Target Milestone: ---

I have selected version 4.8.1, but other versions have the same problem

When ever I try to instantiate a class using ClassName *foo = [[ClassName
alloc] init]; or ClassName *foo = [ClassName new]; it tells me that +alloc and
-init or -new don't exist. Other people on the internet are having the same
issues

I know that the objc part of GCC has been updated, the bug may be that there
are no updated documents detailing how to use the new version without using
GNUStep or another runtime.

here is an example of the problem:

code:

#import 
#import 

@interface TestObject : Object
{
int internalInt;
}

- (int)add:(int)anInt;
- (int)subtract:(int)anInt;
- (int)value;

@end


@implementation TestObject

- (id)init
{
if ((self = [super init]))
{
internalInt = 0;
}

return self;
}

- (int)add:(int)anInt
{
internalInt += anInt;
return internalInt;
}

- (int)subtract:(int)anInt
{
internalInt -= anInt;
return internalInt;
}

- (int)value
{
return internalInt;
}

@end


int main(int argc, char** argv)
{
TestObject *aTestObject = [[TestObject alloc] init];
printf("Initial Value: %d\n", [aTestObject value]);
printf("+45 Value: %d\n", [aTestObject add: 45]);
printf("-63 Value: %d\n", [aTestObject subtract: 63]);

[aTestObject add: 103];
printf("+103 Value: %d\n", [aTestObject value]);

return (EXIT_SUCCESS);
}

debug error:
gcc -o main main.m -lobjc

main.m: IN function '-{TestObject init]':
main.m:20:2: warning: 'Object' may not respond to '-init' [enabled by default]
   if ((self = [super init]))
   ^
main.m:20:2: warning: (Messages without a matching method signature [enabled by
default]
main.m:20:2: warning will be assumed to return 'id' and accept [enabled by
default]
main.m:20:2: warning: '...' as arguments.) [enabled by default]
main.m: In function 'main':
   TestObject *aTestObject = [[TestObject alloc] init];
   ^
main.m:51:2: warning: incompatible implicit declaration of built-in function
'printf' [enabled by default]
   printf("Initial Value: %d\n", [aTestObject value]);
   ^


Please help!

[Bug fortran/67451] [5/6 Regression] ICE with sourced allocation from coarray.

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-09-05
 CC||vehre at gcc dot gnu.org
  Known to work||4.9.3
Summary|ICE with sourced allocation |[5/6 Regression] ICE with
   |from coarray.   |sourced allocation from
   ||coarray.
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
The test in comment 0 compiles with r221464 (2015-03-16), but gives an ICE when
compiled with r221495 (2015-03-18). Caveat: my revision r221495 contains three
patches and the ICE may be due to a patch committed after r221495.

[Bug rtl-optimization/67456] New: wrong code at -O2 and -O3 on x86_64-linux-gnu

[su at cs dot ucdavis.edu]

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

Bug ID: 67456
   Summary: wrong code at -O2 and -O3 on x86_64-linux-gnu
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The current gcc trunk miscompiles the following code on x86_64-linux-gnu at -O2
and -O3 in both 32-bit and 64-bit modes. 

This is a regression from 5.2.x.


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20150904 (experimental) [trunk revision 227491] (GCC) 
$ 
$ gcc-trunk -Os small.c; ./a.out
-1
$ gcc-5.2 -O2 small.c; ./a.out
-1
$ 
$ gcc-trunk -O2 small.c
$ ./a.out
-2
$ 


-


int printf (const char *, ...);

short d = -1;
char e, h;

int
main ()
{
  char i;
  int j = 0; 
  h = e = d;
  i = e < j ? e : e << 1;
  printf ("%d\n", i);
  return 0;
}

[Bug rtl-optimization/67447] New: [6 Regression] ICE in extract_constrain_insn (reload_cse_simplify_operands): insn does not satisfy its constraints

[miyuki at gcc dot gnu.org]

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

Bug ID: 67447
   Summary: [6 Regression] ICE in extract_constrain_insn
(reload_cse_simplify_operands): insn does not satisfy
its constraints
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: miyuki at gcc dot gnu.org
  Target Milestone: ---

This started between r227381 (OK) and r227407 (ICE).

$ cat calculix.c
struct _GPart {
  int *g;
};
static int b, d, e;
int *c, *f, *g;
int a;

int fn2(int, int);

int fn1(int p1) {
  int h = fn2(p1, (int)(long));
  for (; d < e; d++)
if (f[d] != a)
  h += g ? g[f[d]] : 1;
  return h;
}

int main() {
  struct _GPart *i;
  for (; b < (int)(long)(i->g); b++)
c[b] = fn1((int)(long)i->g);
}

$ cc1 -O3 -march=haswell -quiet calculix.c
calculix.c: In function 'main':
calculix.c:22:1: error: insn does not satisfy its constraints:
 }
 ^
(insn 301 299 624 53 (parallel [
(set (reg:V8SI 24 xmm3 [orig:390 vect__ifc__35.69 ] [390])
(unspec:V8SI [
(reg:V8SI 24 xmm3 [orig:390 vect__ifc__35.69 ] [390])
(mem:SI (unspec:DI [
(reg/f:DI 37 r8 [orig:102 g ] [102])
(reg:V8SI 25 xmm4 [orig:179 vect__26.68 ]
[179])
(const_int 4 [0x4])
] UNSPEC_VSIBADDR) [0  S4 A8])
(mem:BLK (scratch) [0  A8])
(reg:V8SI 24 xmm3 [orig:390 vect__ifc__35.69 ] [390])
] UNSPEC_GATHER))
(clobber (reg:V8SI 24 xmm3 [orig:390 vect__ifc__35.69 ] [390]))
]) calculix.c:14 4573 {*avx2_gathersiv8si}
 (nil))
calculix.c:22:1: internal compiler error: in extract_constrain_insn, at
recog.c:2200
0xa49de3 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/miyuki/gcc/src/gcc/rtl-error.c:109
0xa49e0f _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/miyuki/gcc/src/gcc/rtl-error.c:120
0xa1828d extract_constrain_insn(rtx_insn*)
/home/miyuki/gcc/src/gcc/recog.c:2200
0x9f89e6 reload_cse_simplify_operands
/home/miyuki/gcc/src/gcc/postreload.c:408
0x9f9a15 reload_cse_simplify
/home/miyuki/gcc/src/gcc/postreload.c:194
0x9f9a15 reload_cse_regs_1
/home/miyuki/gcc/src/gcc/postreload.c:233
0x9fb31b reload_cse_regs
/home/miyuki/gcc/src/gcc/postreload.c:81
0x9fb31b execute
/home/miyuki/gcc/src/gcc/postreload.c:2350
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug other/67446] libiberty sha1.c:324 sanitizer runtime error: load of misaligned address 0x62f00011847e for type 'const sha1_uint32', which requires 4 byte alignment

[miyuki at gcc dot gnu.org]

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

Mikhail Maltsev  changed:

   What|Removed |Added

 CC||miyuki at gcc dot gnu.org

--- Comment #2 from Mikhail Maltsev  ---
BTW, a similar bug reproduces during GCC bootstrap with ubsan:

/home/jenkins/workspace/ubsan-bootstrap/src/libiberty/md5.c:336:7: runtime
error: load of misaligned address 0x7fff91f9983a for type 'const md5_uint32',
which requires 4 byte alignment
0x7fff91f9983a: note: pointer points here
 00 00  f4 48 00 00 00 00 00 00  0a 00 00 00 0e 00 00 00  0d 01 00 00 00 00 00
00  07 49 00 00 00 00
  ^

[Bug other/67446] libiberty sha1.c:324 sanitizer runtime error: load of misaligned address 0x62f00011847e for type 'const sha1_uint32', which requires 4 byte alignment

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Mikhail Maltsev from comment #2)
> BTW, a similar bug reproduces during GCC bootstrap with ubsan:
> 
> /home/jenkins/workspace/ubsan-bootstrap/src/libiberty/md5.c:336:7: runtime
> error: load of misaligned address 0x7fff91f9983a for type 'const
> md5_uint32', which requires 4 byte alignment
> 0x7fff91f9983a: note: pointer points here
>  00 00  f4 48 00 00 00 00 00 00  0a 00 00 00 0e 00 00 00  0d 01 00 00 00 00
> 00 00  07 49 00 00 00 00
>   ^

But those are two different issues.  Also the md5 code explicitly checks to see
if unaligned loads are supported though, it could be better about it.  Please
file this as a separate bug and also note both of these functions really come
from glibc so you might want to file it there (but there might be another
upstream code too).

[Bug other/67446] New: libiberty sha1.c:324 sanitizer runtime error: load of misaligned address 0x62f00011847e for type 'const sha1_uint32', which requires 4 byte alignment

[zeccav at gmail dot com]

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

Bug ID: 67446
   Summary: libiberty sha1.c:324 sanitizer runtime error: load of
misaligned address 0x62f00011847e for type 'const
sha1_uint32', which requires 4 byte alignment
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

While building the Fedora 21 kernel 4.1.6-100 with a sanitized version of ld
I got the following sanitizer messages (sha1.c compiled with 
gcc -fsanitize=undefined)
This is sha1.c in libiberty

sha1.c:324:11: runtime error: load of misaligned address 0x62f00011847e for
type 'const sha1_uint32', which requires 4 byte alignment
0x62f00011847e: note: pointer points here
 84 00 00 00 00 00  55 be 1a 00 00 00 48 c7  c7 60 7f c1 82 48 89 e5  e8 7b 03
ed fe 5d c3 66  0f 1f
 ^ 
sha1.c:324:11: runtime error: load of misaligned address 0x62f00011847e for
type 'const sha1_uint32', which requires 4 byte alignment
0x62f00011847e: note: pointer points here
 84 00 00 00 00 00  55 be 1a 00 00 00 48 c7  c7 60 7f c1 82 48 89 e5  e8 7b 03
ed fe 5d c3 66  0f 1f
 ^ 
sha1.c:324:11: runtime error: load of misaligned address 0x62f00011847e for
type 'const sha1_uint32', which requires 4 byte alignment
0x62f00011847e: note: pointer points here
 84 00 00 00 00 00  55 be 1a 00 00 00 48 c7  c7 60 7f c1 82 48 89 e5  e8 7b 03
ed fe 5d c3 66  0f 1f
 ^ 
sha1.c:324:11: runtime error: load of misaligned address 0x62f00011847e for
type 'const sha1_uint32', which requires 4 byte alignment
0x62f00011847e: note: pointer points here
 84 00 00 00 00 00  55 be 1a 00 00 00 48 c7  c7 60 7f c1 82 48 89 e5  e8 7b 03
ed fe 5d c3 66  0f 1f

sha1.c:324 is

x[t] = SWAP (*words);

so it seems that words is not a multiple of four, but it should point to type
sha1_uint32 which is four bytes aligned.
This is on x86-64 building "LD  init/built-in.o" and the command is

ld -m elf_x86_64 --build-id -X -o .tmp_vmlinux1 -T
./arch/x86/kernel/vmlinux.lds arch/x86/kernel/head_64.o
arch/x86/kernel/head64.o arch/x86/kernel/head.o init/built-in.o --start-group
usr/built-in.o arch/x86/built-in.o kernel/built-in.o mm/built-in.o
fs/built-in.o ipc/built-in.o security/built-in.o crypto/built-in.o
block/built-in.o lib/lib.a arch/x86/lib/lib.a lib/built-in.o
arch/x86/lib/built-in.o drivers/built-in.o sound/built-in.o firmware/built-in.o
arch/x86/pci/built-in.o arch/x86/power/built-in.o arch/x86/video/built-in.o
net/built-in.o --end-group

[Bug other/67446] libiberty sha1.c:324 sanitizer runtime error: load of misaligned address 0x62f00011847e for type 'const sha1_uint32', which requires 4 byte alignment

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
According to the source, it assumes the input to the sha1_process_block is
aligned correctly.  It might be a bug in ld passing an incorrect aligned block
to that function.