[Bug target/77586] [7 Regression] ia64 target fails to build due to ICE triggered by -fself-test

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||ia64-*-*
   Target Milestone|--- |7.0
Summary|ia64 target fails to build  |[7 Regression] ia64 target
   |due to ICE triggered by |fails to build due to ICE
   |-fself-test |triggered by -fself-test

[Bug libgcc/71744] Concurrently throwing exceptions is not scalable

[gleb at scylladb dot com]

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

--- Comment #19 from Gleb Natapov  ---
(In reply to Jakub Jelinek from comment #18)
> (In reply to Gleb Natapov from comment #16)
> > Can you suggest an alternative to libgcc patch? Use other TLS model?
> > Allocate per thread storage dynamically somehow?
> 
> If we want to use TLS (which I hope we don't), then e.g. a single __thread
> pointer with some registered destructor that would free it on process exit
> could do the job, and on the first exception it would try to allocate memory
> for the cache and other stuff and use that (otherwise, if memory allocation
> fails, just take a lock and be non-scalable).
>
I see that sjlj uses __gthread_setspecific/__gthread_getspecific. Can we do the
same here?

> 
> Another alternative, perhaps much better, if Torvald is going to improve
> rwlocks sufficiently, would be to use rwlock to guard writes to the cache
> etc. too, and perhaps somewhat enlarge the cache (either statically, or
> allow extending it through allocation).
> I'd expect that usually these apps that use exceptions too much only care
> about a couple of shared libraries, so writes to the cache ought to be rare.
>
As I said in my previous reply, I tested the new rwlock and in congested case
it still slows does the system significantly, not the implementation fault, cpu
just does not like locked instruction much. Not having a lock will be
significantly better.

[Bug c/77587] New: C compiler produces incorrect stack alignment with __attribute((weak))

[andrew.thomas at cogent dot ca]

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

Bug ID: 77587
   Summary: C compiler produces incorrect stack alignment with
__attribute((weak))
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrew.thomas at cogent dot ca
  Target Milestone: ---

Created attachment 39615
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39615=edit
Test case for weak attribute stack misalignment

I have run into a case where GCC produces a stack aligned to 8 bytes instead of
the required 16 bytes when using __attribute__((weak)).  I originally
mistakenly reported this as a problem with sprintf() here:
https://sourceware.org/bugzilla/show_bug.cgi?id=20596 

This case produces a call to sprintf() with the stack aligned to 8 bytes, but
sprintf() calls the MOVAPS instruction which will crash if the stack is not
aligned to 16 bytes.

The attached test case consists of two files.  The compile command is in the
comments at the top of stacktest.c.  The crash occurs if __attribute__((weak))
is used in the example, and does not occur without it.  Change SPRINTF_CRASH
from 1 to 0 in stacktest.c to eliminate the crash.

My test system is Ubuntu 16.04 LTS.

uname -a:  Linux mylinux 4.4.0-22-generic #40-Ubuntu SMP Thu May 12 22:03:46
UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

gcc -v: gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.2) 

glibc:  2.23

[Bug tree-optimization/77580] Improve devirtualization

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
I think this shows up in h264 code in spec2006.

[Bug target/77587] C compiler produces incorrect stack alignment with __attribute__((weak))

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-14
 CC||trippels at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
markus@x4 tmp % gcc -c stacktest.c -S -o -
.file   "stacktest.c"
.text
.globl  APP_PointChangeHandlerDefault
.type   APP_PointChangeHandlerDefault, @function
APP_PointChangeHandlerDefault:
.LFB2:
.cfi_startproc
pushq   %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
movq%rdi, -8(%rbp)
movq%rsi, -16(%rbp)
movq%rdx, -24(%rbp)
nop
popq%rbp
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE2:
.size   APP_PointChangeHandlerDefault, .-APP_PointChangeHandlerDefault
.weak   APP_PointChangeHandler
.setAPP_PointChangeHandler,APP_PointChangeHandlerDefault
.globl  test_onPointChange
.type   test_onPointChange, @function
test_onPointChange:
.LFB3:
.cfi_startproc
pushq   %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
subq$24, %rsp
^^^ > this should be $32
movq%rdi, -8(%rbp)
movq%rsi, -16(%rbp)
movq%rdx, -24(%rbp)
movl$0, %edx
movl$0, %esi
movl$0, %edi
callAPP_PointChangeHandler
nop
leave
.cfi_def_cfa 7, 8
ret
.cfi_endproc

[Bug libgcc/71744] Concurrently throwing exceptions is not scalable

[jakub at gcc dot gnu.org]

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

--- Comment #26 from Jakub Jelinek  ---
(In reply to Gleb Natapov from comment #25)
> Using Torvald's rwlock would be definitely better that current state, but
> not as good as per thread lock.

In theory there could be e.g. an option to keep using the recursive lock by
default and if e.g. dl_iterate_phdr determines it has been called already many
times, or detects contention some way, it could under that allocate the page
with the locks and switch to using that from that point on or something
similar.
Or start with rwlock and switch to array of locks, whatever.

I'm not a glibc developer anymore, so I'll leave it to its maintainers, just
wanted to express my fears.

> I think I misunderstood what you propose. My patch essentially does what you
> suggest already, it calls the function dl_iterate_phdr_parallel instead of
> dl_iterate_phdr_rd, but otherwise it is the same: it can run multiple
> callback in parallel, so we only disagree on how _parallel_ part is achieved
> internally.
> On glibc list there were some concerns about widening the interface though.
> They may prefer to use symbol versioning to change dl_iterate_phdr semantics
> (not sure if and how this can be done yet).

Using symbol versioning to change the number of arguments of a function IMHO is
just wrong, using a different name is cleaner, and dl_iterate_phdr isn't used
these days just in glibc where I've originally added it (for the use in the
unwinder), but various other OSes, some BSDs, Solaris, ..., and not sure if all
of them use symbol versioning, especially the GNU one.

[Bug target/77587] [5/6/7 Regression] C compiler produces incorrect stack alignment with __attribute__((weak))

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #2 from Markus Trippelsdorf  ---
Started with r220608:

commit c5e076fc8d0cb2880cef40da85766ccde5d5272b
Author: hubicka 
Date:   Wed Feb 11 09:11:06 2015 +

PR ipa/65005
* ipa-visibility.c (cgraph_node::non_local_p): Turn into static
function.
* symtab.c (symtab_node::verify_base): Remove check that
non-definitions
have no comdat group.
* lto-cgraph.c (lto_output_node): Always output thunk and alias info.
(lto_output_varpool_node): Always output alias info.
(output_refs): Output refs of boundary aliases, too.
(compute_ltrans_boundary): Add alias and thunk target into boundaries.
(output_symtab): Output call eges in thunks in boundary.
(get_alias_symbol): Remove.
(input_node, input_varpool_node): Do not special case weakrefs.
* ipa.c (symbol_table::remove_unreachable_nodes): Do not remove
alias and thunks targets in the boundary; do not take removed symbols
from their comdat groups.
* cgraph.c (cgraph_node::local_info): Look through aliases and thunks.
(cgraph_node::global_info): Remove.
(cgraph_node::rtl_info): Look through aliases and thunks.
* cgrpah.h (global_info): Remove.
(non_local_p): Remove.

[Bug libgcc/71744] Concurrently throwing exceptions is not scalable

[jakub at gcc dot gnu.org]

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

--- Comment #20 from Jakub Jelinek  ---
(In reply to Gleb Natapov from comment #19)
> (In reply to Jakub Jelinek from comment #18)
> > (In reply to Gleb Natapov from comment #16)
> > > Can you suggest an alternative to libgcc patch? Use other TLS model?
> > > Allocate per thread storage dynamically somehow?
> > 
> > If we want to use TLS (which I hope we don't), then e.g. a single __thread
> > pointer with some registered destructor that would free it on process exit
> > could do the job, and on the first exception it would try to allocate memory
> > for the cache and other stuff and use that (otherwise, if memory allocation
> > fails, just take a lock and be non-scalable).
> >
> I see that sjlj uses __gthread_setspecific/__gthread_getspecific. Can we do
> the same here?

Can? Yes.  Want?  Nope.  It is worse than TLS.

> > Another alternative, perhaps much better, if Torvald is going to improve
> > rwlocks sufficiently, would be to use rwlock to guard writes to the cache
> > etc. too, and perhaps somewhat enlarge the cache (either statically, or
> > allow extending it through allocation).
> > I'd expect that usually these apps that use exceptions too much only care
> > about a couple of shared libraries, so writes to the cache ought to be rare.
> >
> As I said in my previous reply, I tested the new rwlock and in congested case
> it still slows does the system significantly, not the implementation fault,
> cpu just does not like locked instruction much. Not having a lock will be
> significantly better.

You still need at least one lock, the array of locks is definitely a bad idea.
Perhaps if you are worried about using 2 different rwlocks, it would be
possible to just use the glibc internal one, by adding dl_iterate_phdr
alternate entrypoint - dl_iterate_phdr would then be documented to only allow a
single thread in the callback, which it satisfies now and in newer libc could
wrlock _dl_load_lock, and then dl_iterate_phdr alternate entrypoint would be
documented to allow multiple threads in the callback (i.e. it could rdlock
_dl_load_lock).  On the libgcc side then it would call dl_iterate_phdr_rd (or
whatever name it would have) first, and perform only read-only lookup in the
cache, and if it wouldn't find anything, it would call dl_iterate_phdr
afterwards and tweak the cache.

[Bug libgcc/71744] Concurrently throwing exceptions is not scalable

[gleb at scylladb dot com]

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

--- Comment #22 from Gleb Natapov  ---
(In reply to torvald from comment #21)
> (In reply to Jakub Jelinek from comment #17)
> > (In reply to torvald from comment #15)
> > > > Similarly, the 64 recursive locks in libc, again, significant amount of
> > > > memory
> > > > per process that doesn't care about exceptions,
> > > 
> > > That might be reducable if we build custom locks and don't use pthread 
> > > ones,
> > > but we'll at least have 64b per lock.
> > 
> > Right now the lock is I think 40 bytes per lock, which is 64 * 40 bytes per
> > process.  That is just too much (but of course the 64x locking a recursive
> > lock is even worse).
> 
> Remembering more of the discussion we had about this in the past, then even
> with the improved rwlock, Gleb reports that there is a slowdown in Gleb's
> tests because of cache contention -- which would mean that we may have to
> use one cacheline per lock.

Right, my patch lacks it, but cache alignment will definitely be an
improvement.

[Bug libgcc/71744] Concurrently throwing exceptions is not scalable

[jakub at gcc dot gnu.org]

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

--- Comment #24 from Jakub Jelinek  ---
(In reply to Gleb Natapov from comment #23)
> I am not sure I agree. 64 lock will take one page of memory, which is
> negligible amount nowadays and we can drop the array if compiled for single
> threaded machine. 

It is perhaps negligible for your app, but libc has lots of users with
different needs.  And dl_load_lock isn't the only widely used lock in libc, are
we going to use page of array locks in each case such lock has scalability
issues with certain use cases?

> Such interface will make new dl_iterate_phdr_rd to libgcc specific, also
> scalablity will depend on cache efficiency, so while benchmark will show
> much better result, real application will not benefit. Complex C++
> applications tend to have deep call chains.

Why would it be libgcc specific?  It would be another libc supported API, with
clear documentation on what it does and any user could just use it.  As I said,
the number of entries in the cache could be extended.

[Bug libgcc/71744] Concurrently throwing exceptions is not scalable

[gleb at scylladb dot com]

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

--- Comment #27 from Gleb Natapov  ---
(In reply to Jakub Jelinek from comment #26)
> (In reply to Gleb Natapov from comment #25)
> > Using Torvald's rwlock would be definitely better that current state, but
> > not as good as per thread lock.
> 
> In theory there could be e.g. an option to keep using the recursive lock by
> default and if e.g. dl_iterate_phdr determines it has been called already
> many times, or detects contention some way, it could under that allocate the
> page with the locks and switch to using that from that point on or something
> similar.
> Or start with rwlock and switch to array of locks, whatever.
>
This is interesting idea, I will try to play with it. On the surface it will be
hard to make threads to agree on what method to use without some kind of
synchronization which may, by itself, introduce non trivial slow down.

> 
> I'm not a glibc developer anymore, so I'll leave it to its maintainers, just
> wanted to express my fears.
Your input is appreciated, especially as cooperation between two projects is
required to solve the issue.

> 
> > I think I misunderstood what you propose. My patch essentially does what you
> > suggest already, it calls the function dl_iterate_phdr_parallel instead of
> > dl_iterate_phdr_rd, but otherwise it is the same: it can run multiple
> > callback in parallel, so we only disagree on how _parallel_ part is achieved
> > internally.
> > On glibc list there were some concerns about widening the interface though.
> > They may prefer to use symbol versioning to change dl_iterate_phdr semantics
> > (not sure if and how this can be done yet).
> 
> Using symbol versioning to change the number of arguments of a function IMHO
> is just wrong, using a different name is cleaner, and dl_iterate_phdr isn't
> used these days just in glibc where I've originally added it (for the use in
> the unwinder), but various other OSes, some BSDs, Solaris, ..., and not sure
> if all of them use symbol versioning, especially the GNU one.
>
Why would new function have different number of arguments? My proposed
dl_iterate_phdr_parallel has the same list of arguments, just no global lock
around callback invocation.

Good point about other OSes. Will bring this to glibc guys attention as an
argument in favor of a new function.

[Bug debug/77589] [56/7 Regression] fortran: Missing DW_AT_byte_stride for an array record array selection

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*
   Target Milestone|--- |5.5
Summary|[Regression] fortran:   |[56/7 Regression] fortran:
   |Missing DW_AT_byte_stride   |Missing DW_AT_byte_stride
   |for an array record array   |for an array record array
   |selection   |selection

[Bug libgcc/71744] Concurrently throwing exceptions is not scalable

[gleb at scylladb dot com]

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

--- Comment #23 from Gleb Natapov  ---
(In reply to Jakub Jelinek from comment #20)
> (In reply to Gleb Natapov from comment #19)
> > (In reply to Jakub Jelinek from comment #18)
> > > (In reply to Gleb Natapov from comment #16)
> > > > Can you suggest an alternative to libgcc patch? Use other TLS model?
> > > > Allocate per thread storage dynamically somehow?
> > > 
> > > If we want to use TLS (which I hope we don't), then e.g. a single __thread
> > > pointer with some registered destructor that would free it on process exit
> > > could do the job, and on the first exception it would try to allocate 
> > > memory
> > > for the cache and other stuff and use that (otherwise, if memory 
> > > allocation
> > > fails, just take a lock and be non-scalable).
> > >
> > I see that sjlj uses __gthread_setspecific/__gthread_getspecific. Can we do
> > the same here?
> 
> Can? Yes.  Want?  Nope.  It is worse than TLS.
Got it. If __thread pointer is an acceptable solution I will be happy to
implement it.  

> 
> > > Another alternative, perhaps much better, if Torvald is going to improve
> > > rwlocks sufficiently, would be to use rwlock to guard writes to the cache
> > > etc. too, and perhaps somewhat enlarge the cache (either statically, or
> > > allow extending it through allocation).
> > > I'd expect that usually these apps that use exceptions too much only care
> > > about a couple of shared libraries, so writes to the cache ought to be 
> > > rare.
> > >
> > As I said in my previous reply, I tested the new rwlock and in congested 
> > case
> > it still slows does the system significantly, not the implementation fault,
> > cpu just does not like locked instruction much. Not having a lock will be
> > significantly better.
> 
> You still need at least one lock, the array of locks is definitely a bad
> idea.
>
I am not sure I agree. 64 lock will take one page of memory, which is
negligible amount nowadays and we can drop the array if compiled for single
threaded machine. Breaking one big lock into many smaller one is a common
technique to achieve scalability. 

Alternative is to make the lock to be per thread, then consumed memory is
proportional to amount of threads. 

> Perhaps if you are worried about using 2 different rwlocks, it would be
> possible to just use the glibc internal one, by adding dl_iterate_phdr
> alternate entrypoint - dl_iterate_phdr would then be documented to only
> allow a single thread in the callback, which it satisfies now and in newer
> libc could wrlock _dl_load_lock, and then dl_iterate_phdr alternate
> entrypoint would be documented to allow multiple threads in the callback
> (i.e. it could rdlock _dl_load_lock).  On the libgcc side then it would call
> dl_iterate_phdr_rd (or whatever name it would have) first, and perform only
> read-only lookup in the cache, and if it wouldn't find anything, it would
> call dl_iterate_phdr afterwards and tweak the cache.
>
Such interface will make new dl_iterate_phdr_rd to libgcc specific, also
scalablity will depend on cache efficiency, so while benchmark will show much
better result, real application will not benefit. Complex C++ applications tend
to have deep call chains.

[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler

[noloader at gmail dot com]

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

--- Comment #5 from Jeffrey Walton  ---
(In reply to Dominique d'Humieres from comment #4)
> I see the problem after having updated to Xcode 8.0. I am currently testing
> the following patch
> 

Just an FYI... Clang 3.7 and below do not witness the problem. Clang 3.8 and
above do.

If you are working on OS X and want to avoid iTunes accounts and the App Store,
then you can duplicate with MacPorts:

   # port install clang-3.8
   # port install gcc6
   # ln -s /opt/local/bin/clang /opt/local/bin/clang-3.8

(My apologies if I got the link backwards; I always do it in real life, too).

Then:

   CC=/opt/local/bin/gcc-mp-6 CFLAGS="-Wa,-q" make

Creating the link and using the full path allows you to keep MacPorts off-path.
I keep it off-path to avoid cross-pollination in a testing environment.

[Bug sanitizer/69539] ICE in expand_UBSAN_NULL, at internal-fn.c:202

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
I can also confirm the ICE on 4.9.0+, as well as on all active branches.

[Bug target/77587] [5/6/7 Regression] C compiler produces incorrect stack alignment with __attribute__((weak))

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
   Target Milestone|--- |5.5

[Bug libgcc/71744] Concurrently throwing exceptions is not scalable

[torvald at gcc dot gnu.org]

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

--- Comment #21 from torvald at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #17)
> (In reply to torvald from comment #15)
> > > Similarly, the 64 recursive locks in libc, again, significant amount of
> > > memory
> > > per process that doesn't care about exceptions,
> > 
> > That might be reducable if we build custom locks and don't use pthread ones,
> > but we'll at least have 64b per lock.
> 
> Right now the lock is I think 40 bytes per lock, which is 64 * 40 bytes per
> process.  That is just too much (but of course the 64x locking a recursive
> lock is even worse).

Remembering more of the discussion we had about this in the past, then even
with the improved rwlock, Gleb reports that there is a slowdown in Gleb's tests
because of cache contention -- which would mean that we may have to use one
cacheline per lock.

[Bug libgcc/71744] Concurrently throwing exceptions is not scalable

[gleb at scylladb dot com]

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

--- Comment #25 from Gleb Natapov  ---
(In reply to Jakub Jelinek from comment #24)
> (In reply to Gleb Natapov from comment #23)
> > I am not sure I agree. 64 lock will take one page of memory, which is
> > negligible amount nowadays and we can drop the array if compiled for single
> > threaded machine. 
> 
> It is perhaps negligible for your app, but libc has lots of users with
> different needs.  And dl_load_lock isn't the only widely used lock in libc,
> are we going to use page of array locks in each case such lock has
> scalability issues with certain use cases?
>
That's a fair point. I think severity of the issue should be taken into
account. I can tell from our experience (and searching the web we are not
alone) that for exception throwing languages like C++ the issue is very
serious, and no, we do not use exceptions as flow control, but when errors
happen they tend to happen in bunches and when the first bunch slows the system
to a crawl it causes even more errors. The only workaround is to not use
exception which for us is not acceptable, so fixing the issue in its root is
the only option.

Using Torvald's rwlock would be definitely better that current state, but not
as good as per thread lock.

> 
> > Such interface will make new dl_iterate_phdr_rd to libgcc specific, also
> > scalablity will depend on cache efficiency, so while benchmark will show
> > much better result, real application will not benefit. Complex C++
> > applications tend to have deep call chains.
> 
> Why would it be libgcc specific?  It would be another libc supported API,
> with clear documentation on what it does and any user could just use it.
>  
I think I misunderstood what you propose. My patch essentially does what you
suggest already, it calls the function dl_iterate_phdr_parallel instead of
dl_iterate_phdr_rd, but otherwise it is the same: it can run multiple callback
in parallel, so we only disagree on how _parallel_ part is achieved internally.
On glibc list there were some concerns about widening the interface though.
They may prefer to use symbol versioning to change dl_iterate_phdr semantics
(not sure if and how this can be done yet).


>As
> I said, the number of entries in the cache could be extended.
>
Unless it extends dynamically it would be hard to guess a proper size, and the
price of underguessing is too high. Finding a proper size dynamically
will require a lot of cache management code which I do not think belong here.

[Bug debug/77589] New: fortran: Missing DW_AT_byte_stride for an array record array selection

[jan.kratochvil at redhat dot com]

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

Bug ID: 77589
   Summary: fortran: Missing DW_AT_byte_stride for an array record
array selection
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.kratochvil at redhat dot com
  Target Milestone: ---

Fedora testcase: gdb.fortran/dwarf-stride.exp
! File written by Alan Matsuoka.

FAIL: gcc-6.2.1-1.fc26.x86_64
PASS: gcc-4.8.5-4.el7.x86_64

gfortran -o dwarf-stridex dwarf-stridex.f90 -Wall -g;../gdb ./dwarf-stridex
-batch -ex 'b 14' -ex r -ex 'p c40pt(2)'

p c40pt(2)^M
$2 = '\001\000\000\000\061-hello', ' ' ^M
(gdb) FAIL: gdb.fortran/dwarf-stride.exp: p c40pt(2)

p c40pt(2)^M
$2 = '1-hello', ' ' ^M
(gdb) PASS: gdb.fortran/dwarf-stride.exp: p c40pt(2)

FAIL:
 <2><174>: Abbrev Number: 18 (DW_TAG_subrange_type)
<175>   DW_AT_lower_bound : (DW_OP_push_object_address; DW_OP_plus_uconst:
32; DW_OP_deref)
<17a>   DW_AT_upper_bound : (DW_OP_push_object_address; DW_OP_plus_uconst:
40; DW_OP_deref)

PASS:
 <2><127>: Abbrev Number: 14 (DW_TAG_subrange_type)
<128>   DW_AT_lower_bound : (DW_OP_push_object_address; DW_OP_plus_uconst:
32; DW_OP_deref)
<12d>   DW_AT_upper_bound : (DW_OP_push_object_address; DW_OP_plus_uconst:
40; DW_OP_deref)
<132>   DW_AT_byte_stride : (DW_OP_push_object_address; DW_OP_plus_uconst:
24; DW_OP_deref; DW_OP_fbreg: -80; DW_OP_deref; DW_OP_mul)

[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-14
 CC||howarth.at.gcc at gmail dot 
com,
   ||iains at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Dominique d'Humieres  ---
I see the problem after having updated to Xcode 8.0. I am currently testing the
following patch

--- ../_clean/gcc/config/darwin-sections.def2016-01-04 19:51:16.0
+0100
+++ gcc/config/darwin-sections.def  2016-09-14 12:01:44.0 +0200
@@ -29,7 +29,7 @@ along with GCC; see the file COPYING3.  

 /* The .text section is generated in varasm.c  */
 DEF_SECTION (text_coal_section, SECTION_CODE|SECTION_NO_ANCHOR,
-".section __TEXT,__textcoal_nt,coalesced,pure_instructions", 0)
+".section __TEXT,__text,coalesced,pure_instructions", 0)

 DEF_SECTION (text_hot_section, SECTION_CODE,
 ".section __TEXT,__text_hot,regular,pure_instructions", 0)
@@ -52,7 +52,7 @@ DEF_SECTION (text_exit_coal_section, SEC
 /* const */
 DEF_SECTION (const_section, 0, ".const", 0)
 DEF_SECTION (const_coal_section, SECTION_NO_ANCHOR,
-".section __TEXT,__const_coal,coalesced", 0)
+".section __TEXT,__const,coalesced", 0)
 /* Place to put zero-sized to avoid issues with section anchors.  */
 DEF_SECTION (zobj_const_section, SECTION_NO_ANCHOR, 
 ".section\t__DATA,__zobj_const", 0)
@@ -60,7 +60,7 @@ DEF_SECTION (zobj_const_section, SECTION
 /* Write-able data.  '.data'  handled in varasm.c  */
 DEF_SECTION (static_data_section, SECTION_WRITE, ".static_data", 0)
 DEF_SECTION (data_coal_section, SECTION_WRITE|SECTION_NO_ANCHOR,
-".section __DATA,__datacoal_nt,coalesced", 0)
+".section __DATA,__data,coalesced", 0)
 /* Place to put zero-sized to avoid issues with section anchors.  */
 DEF_SECTION (zobj_data_section, SECTION_WRITE|SECTION_NO_ANCHOR, 
 ".section\t__DATA,__zobj_data", 0)
@@ -73,7 +73,7 @@ DEF_SECTION (zobj_bss_section, SECTION_W
 /* const data */
 DEF_SECTION (const_data_section, 0, ".const_data", 0)
 DEF_SECTION (const_data_coal_section, SECTION_NO_ANCHOR,
-".section __DATA,__const_coal,coalesced", 0)
+".section __DATA,__const,coalesced", 0)
 /* Place to put zero-sized to avoid issues with section anchors.  */
 DEF_SECTION (zobj_const_data_section, SECTION_NO_ANCHOR, 
 ".section\t__DATA,__zobj_cnst_data", 0)
--- ../_clean/libffi/src/x86/sysv.S 2015-01-19 23:40:03.0 +0100
+++ libffi/src/x86/sysv.S   2016-09-14 12:04:05.0 +0200
@@ -790,7 +790,7 @@ ENDF(C(ffi_closure_raw_THISCALL))

 #ifdef X86_DARWIN
 # define COMDAT(X) \
-.section __TEXT,__textcoal_nt,coalesced,pure_instructions; \
+.section __TEXT,__text,coalesced,pure_instructions;\
 .weak_definition X;\
 .private_extern X
 #elif defined __ELF__ && !(defined(__sun__) && defined(__svr4__))
--- ../_clean/gcc/testsuite/g++.dg/abi/key2.C   2014-05-10 23:18:30.0
+0200
+++ gcc/testsuite/g++.dg/abi/key2.C 2016-09-14 12:03:17.0 +0200
@@ -2,9 +2,9 @@
 // PR darwin/25908

 // { dg-do compile { target *-*-darwin* } }
-// { dg-final { scan-assembler ".globl __ZTV1f\\n  .weak_definition
__ZTV1f(\\n.section __DATA,__const_coal,coalesced)?\\n .align" } }
-// { dg-final { scan-assembler ".globl __ZTS1f\\n  .weak_definition
__ZTS1f\\n .section __TEXT,__const_coal,coalesced" } }
-// { dg-final { scan-assembler ".globl __ZTI1f\\n  .weak_definition
__ZTI1f(\\n.section __DATA,__const_coal,coalesced)?\\n .align" } }
+// { dg-final { scan-assembler ".globl __ZTV1f\\n  .weak_definition
__ZTV1f(\\n.section __DATA,__const,coalesced)?\\n  .align" } }
+// { dg-final { scan-assembler ".globl __ZTS1f\\n  .weak_definition
__ZTS1f\\n .section __TEXT,__const,coalesced" } }
+// { dg-final { scan-assembler ".globl __ZTI1f\\n  .weak_definition
__ZTI1f(\\n.section __DATA,__const,coalesced)?\\n  .align" } }

 class f
 {

[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler

[dominiq at lps dot ens.fr]

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

--- Comment #6 from Dominique d'Humieres  ---
> Just an FYI... Clang 3.7 and below do not witness the problem.
> Clang 3.8 and above do.
> ...

Thanks for the tip, but I don't use MacPorts. I am building and testing gcc
myself with the Apple's tools with a previous version of gcc (currently
r240001) as the bootstrap compiler (to build Ada).

[Bug debug/77589] fortran: Missing DW_AT_byte_stride for an array record array selection

[jan.kratochvil at redhat dot com]

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

--- Comment #1 from Jan Kratochvil  ---
Created attachment 39617
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39617=edit
dwarf-stridex.f90

[Bug tree-optimization/77580] Improve devirtualization

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Note that for inlining to kick in this all has to be done during early
optimization which is somewhat against its intent (perform transforms
reducing code-size).  Putting x > 10 ? f1 : f2 into the loop is also
against any reasonable heuristics (move invariant stuff outside).

Thus it's going to be tricky overall to teach GCC to handle this situation.

Can you share preprocessed source of that "commonly used benchmark" (or name
it at least?)

[Bug sanitizer/69539] ICE in expand_UBSAN_NULL, at internal-fn.c:202

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
There's a minimal test-case:

int fn1 (void) { return *(volatile int *) fn1; }

[Bug c++/77588] New: Internal error triggered by __builtin___chkp_bndret

[kev at semmle dot com]

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

Bug ID: 77588
   Summary: Internal error triggered by __builtin___chkp_bndret
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kev at semmle dot com
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: x86_64-linux-gnu
 Build: x86_64-linux-gnu

Created attachment 39616
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39616=edit
Short example that attempts to use __builtin___chkp_bndret

The attached file triggers an internal error. This is with gcc 5.4.0 on Ubuntu
16.04.2. I think the problem is that my gcc does not have Intel MPX enabled,
but I don't think it should cause an internal error.

$ g++ -c bug.cpp
bug.cpp: In function ‘void test2()’:
bug.cpp:4:32: internal compiler error: in arg_assoc_type, at
cp/name-lookup.c:5573
   test1(__builtin___chkp_bndret);
^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug sanitizer/69539] ICE in expand_UBSAN_NULL, at internal-fn.c:202

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
That's weird, I can still reproduce:

$ xgcc -flto -fsanitize=null  -c -o test test.c
$ xgcc -flto test
include/linux/compiler.h: In function ‘__read_once_size_nocheck’:
include/linux/compiler.h:235:44: internal compiler error: in expand_UBSAN_NULL,
at internal-fn.c:204
0xa1a4bd expand_UBSAN_NULL
/home/marek/src/gcc/gcc/internal-fn.c:204
0xa22ce3 expand_internal_call(internal_fn, gcall*)
/home/marek/src/gcc/gcc/internal-fn.c:2405
0xa22d0e expand_internal_call(gcall*)
/home/marek/src/gcc/gcc/internal-fn.c:2413
0x786336 expand_call_stmt
/home/marek/src/gcc/gcc/cfgexpand.c:2579
0x789cf8 expand_gimple_stmt_1
/home/marek/src/gcc/gcc/cfgexpand.c:3580
0x78a3ee expand_gimple_stmt
/home/marek/src/gcc/gcc/cfgexpand.c:3746
0x791c67 expand_gimple_basic_block
/home/marek/src/gcc/gcc/cfgexpand.c:5753
0x7937e3 execute
/home/marek/src/gcc/gcc/cfgexpand.c:6367
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: /home/marek/x/trunk/gcc/xgcc returned 1 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status

[Bug c++/77591] New: decltype(auto) and ternary operator allow returning local reference without a warning

[michele.caini at gmail dot com]

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

Bug ID: 77591
   Summary: decltype(auto) and ternary operator allow returning
local reference without a warning
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: michele.caini at gmail dot com
  Target Milestone: ---

I'm referring to this question on SO:
http://stackoverflow.com/questions/39490912/decltypeauto-foo-returns-local-reference-without-any-warning

The following code compiles with a warning when compiled with -Wall -O0:

decltype(auto) foo_warn() {
Counter c;
return (c);
}

The code below compiles with no warnings instead:

decltype(auto) foo_no_warn() {
Counter c;
return 1==1 ? c : c;
}

Anyway, a reference to a local variable is returned in both cases.

Using -O2 the warning appears in both cases.

[Bug c++/77592] New: GCC: Compile failures with delegated constructor circular reference

[gawain.bolton at free dot fr]

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

Bug ID: 77592
   Summary: GCC: Compile failures with delegated constructor
circular reference
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gawain.bolton at free dot fr
  Target Milestone: ---

GCC seg faults with a program which uses delegated constructors with a circular
reference.

Tested using http://melpon.org/wandbox

Compilation segfaults using gcc v5.3, v6.1 and gcc HEAD 7.0.0 20160913

Simplified program is as follows:

struct T
{
T(const int i,
  const char * s)
: T(s,i) 
{ }

T(const char * s,
  const int i)
: T(i,s)
{  }
};


int main()
{
T t{"fred",2};

return 0;
}

[Bug c++/77592] gcc accepts delegated constructor with circular reference

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-14
 CC||trippels at gcc dot gnu.org
Summary|GCC: Compile failures with  |gcc accepts delegated
   |delegated constructor   |constructor with circular
   |circular reference  |reference
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
The resulting binary segfaults not gcc.

markus@x4 /tmp % g++ seg.ii
markus@x4 /tmp % icpc seg.ii
seg.ii(4): error: constructor delegates directly or indirectly to itself
T(const char *s, const int i) : T(i, s) {}
^

compilation aborted for seg.ii (code 2)

markus@x4 /tmp % clang++ seg.ii
seg.ii:4:35: error: constructor for 'T' creates a delegation cycle
[-Wdelegating-ctor-cycles]
  T(const char *s, const int i) : T(i, s) {}
  ^
seg.ii:2:3: note: it delegates to
  T(const int i, const char *s) : T(s, i) {}
  ^
seg.ii:4:3: note: which delegates to
  T(const char *s, const int i) : T(i, s) {}
  ^
1 error generated.

[Bug libstdc++/77582] Improve std::string::clear performace

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-14
 Ever confirmed|0   |1

--- Comment #4 from Jonathan Wakely  ---
This would be fixed by the patch I wrote for PR 56166

[Bug fortran/77584] Unclassifiable statement error with procedure pointer using template named "structure_"

[fritzoreese at gmail dot com]

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

--- Comment #1 from Fritz Reese  ---
Created attachment 39618
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39618=edit
Patch for PR 77584

The attached patch fixes the issue.

2016-09-14  Fritz Reese  

PR fortran/77584

* gcc/fortran/decl.c (match_record_decl, gfc_match_decl_type_spec):
Fixes to handling of structure/record from declaration-type-spec.
* gcc/testsuite/gfortran.dg/dec_structure_15.f90: New testcase.

[Bug c++/77591] [6/7 Regression] decltype(auto) and ternary operator allow returning local reference without a warning

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  ---
Before delayed folding, the conditional was probably eliminated before we even
reached the warning code in the front-end. The warning is duplicated in the
middle-end precisely because in some cases we need optimizations to notice what
is going on. Sure, the front-end could be made a little bit more clever, but I
am not convinced it is worth going too far in that direction.

[Bug fortran/77583] ICE in pp_quoted_string, at pretty-print.c:966

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
> check_conflict is sometimes called with name = NULL and that is passed
> to %qs causing a crash.

Indeed, but this is not the case for the tests giving the error

Error: internal procedure '*' at (1) conflicts ...

but the where seems wrong.

[Bug c++/77592] gcc accepts delegated constructor with circular reference

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Gawain Bolton from comment #0)
> Compilation segfaults using gcc v5.3, v6.1 and gcc HEAD 7.0.0 20160913

Compilation works fine, the executable segfaults, due to a stack overflow.

The standard says your code is "ill-formed, no diagnostic required" so
compilers aren't required to reject the code, but it would be nice to diagnose
it.

Clang does:

circ.cc:10:7: error: constructor for 'T' creates a delegation cycle
[-Wdelegating-ctor-cycles]
: T(i,s)
  ^
circ.cc:3:5: note: it delegates to
T(const int i,
^
circ.cc:8:5: note: which delegates to
T(const char * s,
^


And EDG does:

"circ.cc", line 10: error: constructor delegates directly or indirectly to
  itself
  : T(i,s)
^

[Bug fortran/74600] [openacc] duplicate data map error

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Thomas Schwinge  ---
Cesar posted patch: ,
waiting for review.

[Bug c++/77539] gcc-5/6: comparison of array to nullptr failure in constexpr (fixed by r235506 on trunk)

[nathan at gcc dot gnu.org]

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

--- Comment #1 from Nathan Sidwell  ---
Author: nathan
Date: Wed Sep 14 14:29:01 2016
New Revision: 240136

URL: https://gcc.gnu.org/viewcvs?rev=240136=gcc=rev
Log:
cp/
PR c++/77539
* constexpr.c (get_fundef_copy): Use the original function for
non-recursive evaluations.
(save_fundef_copy): Always expect a slot to be available.

testsuite/
PR c++/77539
* g++.dg/cpp0x/constexpr-recursion3.C: New.
* g++.dg/ubsan/pr63956.C: Adjust error location.
* g++.dg/cpp1y/pr77539.C: New.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/cpp0x/constexpr-recursion3.C
branches/gcc-6-branch/gcc/testsuite/g++.dg/cpp1y/pr77539.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/constexpr.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/testsuite/g++.dg/ubsan/pr63956.C

[Bug c++/77591] [6/7 Regression] decltype(auto) and ternary operator allow returning local reference without a warning

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-14
  Known to work||5.4.0
Summary|decltype(auto) and ternary  |[6/7 Regression]
   |operator allow returning|decltype(auto) and ternary
   |local reference without a   |operator allow returning
   |warning |local reference without a
   ||warning
 Ever confirmed|0   |1
  Known to fail||6.2.0, 7.0

--- Comment #1 from Jonathan Wakely  ---
That code doesn't compile, because it's incomplete.

class Counter { };

decltype(auto) foo_warn() {
  Counter c;
  return (c);
}

decltype(auto) foo_no_warn() {
  Counter c;
  return 1==1 ? c : c;
}

Additionally, the warning that's missing without -O2 says address not
reference:

f.cc: In function ‘decltype(auto) foo_no_warn()’:
f.cc:10:21: warning: function returns address of local variable
[-Wreturn-local-addr]
   return 1==1 ? c : c;
 ^

With GCC 5 both warnings say reference and are present without optimization.

[Bug c/77590] va_arg() returns 0

[negge at dgql dot org]

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

--- Comment #1 from negge at dgql dot org ---
Created attachment 39620
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39620=edit
com.ld

[Bug c/77590] New: va_arg() returns 0

[negge at dgql dot org]

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

Bug ID: 77590
   Summary: va_arg() returns 0
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: negge at dgql dot org
  Target Milestone: ---

Created attachment 39619
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39619=edit
test_va.c

The va_arg() command always returns 0 (NULL) for this test_va.c program when
compiled as a 16bit DOS com file with the following command:

gcc -o test_va.com -std=gnu99 -Wall -Wextra -Os -nostdlib -m16 -march=i386 \
 -masm=intel -Wno-unused-function -ffreestanding -fomit-frame-pointer -fwrapv \
 -fno-strict-aliasing -fno-leading-underscore -Wl,--nmagic,-static,-Tcom.ld \
 test_va.c

The expected output is

C:\>TEST_VA.COM
Hello World

C:\>

but instead it produces

C:\>TEST_VA.COM
Hello Í ÿ

[Bug c++/77539] gcc-5/6: comparison of array to nullptr failure in constexpr (fixed by r235506 on trunk)

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #3 from Nathan Sidwell  ---
Patch backported, new testcase applied to trunk as well.

[Bug c++/77592] gcc accepts delegated constructor with circular reference

[gawain.bolton at free dot fr]

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

--- Comment #3 from Gawain Bolton  ---
You are absolutely right, it is my program that seg faults and not GCC.

As you suggest, it would be great if GCC could give a diagnostic for delegated
constructor circular references.

[Bug rtl-optimization/77289] [7 Regression] ICE in extract_constrain_insn, at recog.c:2212 on powerpc64

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

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

--- Comment #10 from Bill Schmidt  ---
Thus, fixed, it appears.  Thanks, Bernd!

[Bug c++/77539] gcc-5/6: comparison of array to nullptr failure in constexpr (fixed by r235506 on trunk)

[nathan at gcc dot gnu.org]

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

--- Comment #2 from Nathan Sidwell  ---
Author: nathan
Date: Wed Sep 14 16:13:52 2016
New Revision: 240138

URL: https://gcc.gnu.org/viewcvs?rev=240138=gcc=rev
Log:
PR c++/77539
* g++.dg/cpp1y/pr77539.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/pr77539.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug fortran/77593] New: configure-target-libgfortran " cygwin64 Windows 10 anniversary

[tprince at computer dot org]

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

Bug ID: 77593
   Summary: configure-target-libgfortran " cygwin64 Windows 10
anniversary
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tprince at computer dot org
  Target Milestone: ---

Created attachment 39621
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39621=edit
Log file as specified in "please report a bug"

This failure appears to be Windows version dependent, but it provokes "please
report a bug."
It's possible to cd into libgfortran and configure and build, but the gfortran
build is faulty as the script reports.  Attaching config.log as requested.

[Bug target/77586] [7 Regression] ia64 target fails to build due to ICE triggered by -fself-test

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  ---
My offer at  to 
provide an untested patch to always enable TFmode support in libgcc on 
ia64, if such an untested patch would be useful, stands.

[Bug libgcc/71744] Concurrently throwing exceptions is not scalable

[torvald at gcc dot gnu.org]

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

--- Comment #28 from torvald at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #20)
> (In reply to Gleb Natapov from comment #19)
> > (In reply to Jakub Jelinek from comment #18)
> > > (In reply to Gleb Natapov from comment #16)
> > > > Can you suggest an alternative to libgcc patch? Use other TLS model?
> > > > Allocate per thread storage dynamically somehow?
> > > 
> > > If we want to use TLS (which I hope we don't), then e.g. a single __thread
> > > pointer with some registered destructor that would free it on process exit
> > > could do the job, and on the first exception it would try to allocate 
> > > memory
> > > for the cache and other stuff and use that (otherwise, if memory 
> > > allocation
> > > fails, just take a lock and be non-scalable).
> > >
> > I see that sjlj uses __gthread_setspecific/__gthread_getspecific. Can we do
> > the same here?
> 
> Can? Yes.  Want?  Nope.  It is worse than TLS.
> 
> > > Another alternative, perhaps much better, if Torvald is going to improve
> > > rwlocks sufficiently, would be to use rwlock to guard writes to the cache
> > > etc. too, and perhaps somewhat enlarge the cache (either statically, or
> > > allow extending it through allocation).
> > > I'd expect that usually these apps that use exceptions too much only care
> > > about a couple of shared libraries, so writes to the cache ought to be 
> > > rare.
> > >
> > As I said in my previous reply, I tested the new rwlock and in congested 
> > case
> > it still slows does the system significantly, not the implementation fault,
> > cpu just does not like locked instruction much. Not having a lock will be
> > significantly better.
> 
> You still need at least one lock, the array of locks is definitely a bad
> idea.

I don't think it is necessarily a bad idea -- spreading out the data used for
synchronization to avoid cache conflicts when there is an asymmetrical workload
is a commonly used technique.  But we need to find a balance between compute
and space overhead that works for us and in this case.  Also, spreading out the
data should ideally happen in a NUMA-aware way, so there may be more space
overhead if we consider that too.

I've been thinking about using more scalable ways of locking in glibc which
would use per-thread data, which could be useful for more than one lock.  So if
we had that, we could just use that to deal with the exception scalability
problem, without having space overhead just for exceptions.b

[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler

[noloader at gmail dot com]

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

--- Comment #8 from Jeffrey Walton  ---
(In reply to Iain Sandoe from comment #7)
> (In reply to Dominique d'Humieres from comment #4)
> > I see the problem after having updated to Xcode 8.0. I am currently testing
> > the following patch
> 
> >  /* The .text section is generated in varasm.c  */
> >  DEF_SECTION (text_coal_section, SECTION_CODE|SECTION_NO_ANCHOR,
> > -".section __TEXT,__textcoal_nt,coalesced,pure_instructions", 0)
> > +".section __TEXT,__text,coalesced,pure_instructions", 0)
> 
> actually, we need to come up with a patch that simply emits the text/etc.
> section whenever it would have emitted the text_coal/etc. one.. So rather
> than adjusting section definitions - we need to change which ones are
> selected in config/darwin.c
> 
> .. but this should be conditional on a new enough linker to support it, or
> we will break support for folks on ancient systems.  Is this repeatable
> without xcode8?

Yes, it is repeatable with Xcode 8. Someone else mentioned they duplicatd with
it.

> I have some patches in progress to detect the linker features at
> configuration time,

be careful here. You use the new linker when -wa,-q is present. The new linker
is the one in Clang Integrated Assembler. You use the old Apple ld when -Wa,-q
is _not_present. Or maybe mor correctly, you just use ld.

> so that we don't need to rely on guessing from the host
> system version. 

I _think_ you can detect which linker at runtime with something like the
following:

IS_GAS := $(shell $(CXX) -xc -c /dev/null -Wa,-v -o/dev/null 2>&1 | $(EGREP) -c
"GNU assembler")

Now, ld returns the string "GNU assembler". Clang returns the string "clang:
error: unsupported argument '--version' to option 'Wa,'".

The LLVM folks may have fixed it in
https://llvm.org/bugs/show_bug.cgi?id=24200. A quick check with Clang-3.8 using
MacPort compiler shows its not fixed:

$ /opt/local/bin/clang-mp-3.8 -xc -c /dev/null -Wa,--version -o/dev/null 2>&1
clang: error: unsupported argument '--version' to option 'Wa,'

> If this is not detectable by a linker feature, them perhaps
> we can determine the earliest linker that can manage without the separate
> sections (most likely considerably older than the one from Xcode8).

I don't know about some of the other options available to you.

Maybe the "safety valve" should be another option? I'm already doing "-Wa,-q";
another `-Wa,-x` won't other me.

Jeff

[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler

[iains at gcc dot gnu.org]

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

--- Comment #7 from Iain Sandoe  ---
(In reply to Dominique d'Humieres from comment #4)
> I see the problem after having updated to Xcode 8.0. I am currently testing
> the following patch

>  /* The .text section is generated in varasm.c  */
>  DEF_SECTION (text_coal_section, SECTION_CODE|SECTION_NO_ANCHOR,
> -  ".section __TEXT,__textcoal_nt,coalesced,pure_instructions", 0)
> +  ".section __TEXT,__text,coalesced,pure_instructions", 0)

actually, we need to come up with a patch that simply emits the text/etc.
section whenever it would have emitted the text_coal/etc. one.. So rather than
adjusting section definitions - we need to change which ones are selected in
config/darwin.c

.. but this should be conditional on a new enough linker to support it, or we
will break support for folks on ancient systems.  Is this repeatable without
xcode8?

I have some patches in progress to detect the linker features at configuration
time, so that we don't need to rely on guessing from the host system version. 
If this is not detectable by a linker feature, them perhaps we can determine
the earliest linker that can manage without the separate sections (most likely
considerably older than the one from Xcode8).

[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler

[iains at gcc dot gnu.org]

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

--- Comment #9 from Iain Sandoe  ---
(In reply to Jeffrey Walton from comment #8)
> (In reply to Iain Sandoe from comment #7)
> > (In reply to Dominique d'Humieres from comment #4)
> > > I see the problem after having updated to Xcode 8.0. I am currently 
> > > testing
> > > the following patch
> > 
> > >  /* The .text section is generated in varasm.c  */
> > >  DEF_SECTION (text_coal_section, SECTION_CODE|SECTION_NO_ANCHOR,
> > > -  ".section __TEXT,__textcoal_nt,coalesced,pure_instructions", 0)
> > > +  ".section __TEXT,__text,coalesced,pure_instructions", 0)
> > 
> > actually, we need to come up with a patch that simply emits the text/etc.
> > section whenever it would have emitted the text_coal/etc. one.. So rather
> > than adjusting section definitions - we need to change which ones are
> > selected in config/darwin.c
> > 
> > .. but this should be conditional on a new enough linker to support it, or
> > we will break support for folks on ancient systems.  Is this repeatable
> > without xcode8?
> 
> Yes, it is repeatable with Xcode 8. Someone else mentioned they duplicatd
> with it.

without xcode8 - I don't have Xcode8 installed on any system presently.

> > I have some patches in progress to detect the linker features at
> > configuration time,
> 
> be careful here. You use the new linker when -wa,-q is present. The new
> linker is the one in Clang Integrated Assembler. You use the old Apple ld
> when -Wa,-q is _not_present. Or maybe mor correctly, you just use ld.
> 
> > so that we don't need to rely on guessing from the host
> > system version. 
> 
> I _think_ you can detect which linker at runtime with something like the
> following:
> 
> IS_GAS := $(shell $(CXX) -xc -c /dev/null -Wa,-v -o/dev/null 2>&1 | $(EGREP)
> -c "GNU assembler")
> 
> Now, ld returns the string "GNU assembler". Clang returns the string "clang:
> error: unsupported argument '--version' to option 'Wa,'".

you are conflating two things (and coming to a mixed conclusion as a result):

1. a version of the linker (ld64) that's capable of responding to the relevant
flags and operating correctly without coalesced sections to help it deal (see
the description of operation that Andrew pointed to in c #3).

2. a version of the LLVM back-end which is invoked by the cctools as
(effectively calling clang).  Which emits a warning when the section types are
emitted that are no longer needed by 1 (but, note, _are_ needed by older
linkers); the LLVM test added to gate the warning should really have been on
the target linker version, not on the arch type.



So .. IFF we have a ld64 which is sufficiently modern (number / feature test
TBD) we don't need to emit the old _coal sections.   If we have an old linker
(say ld64-85.2.1 since the LLVM commit discussion mentions ppc), then we need
to continue to emit the coal sections.

Essentially, the test and changes needed are to determine the linker (ld64's)
capability;

we ought not be in a position where we detect that the ld64 is too old at the
same time as trying to use the LLVM back end as the assembler.

[Bug bootstrap/77593] [7 Regression] Bootstrap failure with configure-target-libgfortran " cygwin64 Windows 10 anniversary

[tprince at computer dot org]

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

--- Comment #2 from tprince at computer dot org ---
I suspect the Windows 10 provided svn may be partly at fault (although it works
for bootstrapping on the Microsoft provided gcc in linux subsystem).  I grabbed
trunk using cygwin svn and have seen the bootstrap go as far as the stage3
libstdc++ build (without intervention) before jumping back to stage1 and
failing on permissions to move into stage1-gcc.

[Bug c++/77549] [7 Regression] ICE on invalid C++ code that references undeclared variable

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Wed Sep 14 21:55:10 2016
New Revision: 240148

URL: https://gcc.gnu.org/viewcvs?rev=240148=gcc=rev
Log:
PR c++/77549
* name-lookup.c (consider_binding_level): Look through TREE_LIST
and OVERLOAD.

* g++.dg/lookup/pr77549.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/lookup/pr77549.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/name-lookup.c
trunk/gcc/testsuite/ChangeLog

[Bug bootstrap/77593] [7 Regression] Bootstrap failure with configure-target-libgfortran " cygwin64 Windows 10 anniversary

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Target||x86_64-unknown-cygwin
 CC||tkoenig at gcc dot gnu.org
  Component|fortran |bootstrap
   Host||x86_64-unknown-cygwin
   Target Milestone|--- |7.0
Summary|configure-target-libgfortra |[7 Regression] Bootstrap
   |n " cygwin64 Windows 10 |failure with
   |anniversary |configure-target-libgfortra
   ||n " cygwin64 Windows 10
   ||anniversary

--- Comment #1 from Thomas Koenig  ---
Error message (from the logfile):

configure:15660: checking whether the GNU Fortran compiler is working
configure:15673: /cygdrive/c/Users/tim/gnu/gcc/cyg64/./gcc/gfortran
-B/cygdrive/c/Users/tim/gnu/gcc/cyg64/./gcc/
-B/usr/local/gcc7/x86_64-unknown-cygwin/bin/
-B/usr/local/gcc7/x86_64-unknown-cygwin/lib/ -isystem
/usr/local/gcc7/x86_64-unknown-cygwin/include -isystem
/usr/local/gcc7/x86_64-unknown-cygwin/sys-include-c   conftest.f >&5
Cygwin runtime failure: /cygdrive/c/Users/tim/gnu/gcc/cyg64/gcc/f951.exe:
Invalid relocation.  Offset 0x2feaf09a3 at address 0x1004b8179 doesn't fit into
32 bits
configure:15673: $? = 1
configure: failed program was:
| 
|   program foo
|   real, parameter :: bar = sin (12.34 / 2.5)
|   end program foo
configure:15677: result: no
configure:15679: error: GNU Fortran is not working; please report a bug in
http://gcc.gnu.org/bugzilla, attaching
/cygdrive/c/Users/tim/gnu/gcc/cyg64/x86_64-unknown-cygwin/libgfortran/config.log

[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler

[noloader at gmail dot com]

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

--- Comment #10 from Jeffrey Walton  ---
> than adjusting section definitions - we need to change which ones are
>> > selected in config/darwin.c
>> >

>> I _think_ you can detect which linker at runtime with something like the
>> following:
>>
>> IS_GAS := $(shell $(CXX) -xc -c /dev/null -Wa,-v -o/dev/null 2>&1 | $(EGREP)
>> -c "GNU assembler")
>>
>> Now, ld returns the string "GNU assembler". Clang returns the string "clang:
>> error: unsupported argument '--version' to option 'Wa,'".
>
> you are conflating two things (and coming to a mixed conclusion as a result):

Ah, you're right Ian. I mixed up the assembler and linker. I
expereinced so many problem in the past with Clang's integrated
assembler, its burned into my frontal lobe.

Sorry about that.

Jeff

[Bug middle-end/77594] New: double computation for __builtin_sub_overflow (0, ...)

[ebotcazou at gcc dot gnu.org]

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

Bug ID: 77594
   Summary: double computation for __builtin_sub_overflow (0, ...)
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ebotcazou at gcc dot gnu.org
  Target Milestone: ---

Compiling:

#include 

bool my_neg_overflow (int a, int *res)
{
  return __builtin_sub_overflow (0, a, res);
}

at -O0 yields a double computation, first an overflow-negate operation then an
overflow-sub operation.  Probably a missing return in expand_arith_overflow.

[Bug libgcc/71744] Concurrently throwing exceptions is not scalable

[torvald at gcc dot gnu.org]

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

--- Comment #15 from torvald at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #14)
> Looking at that patchset, I just want to say that the use of TLS in libgcc
> is very much undesirable, it affects every program even when not using
> exceptions (significant portion of them), especially when it uses that much
> (6 * sizeof(void *) * 8 + sizeof(void *) + 2 * 8 = 408 bytes per thread is
> significant, plus it uses the slow local dynamic TLS model.

I agree.

> Similarly, the 64 recursive locks in libc, again, significant amount of
> memory
> per process that doesn't care about exceptions,

That might be reducable if we build custom locks and don't use pthread ones,
but we'll at least have 64b per lock.

> and especially signficiant
> slowdown on dlopen/dlclose.  While some programs abuse exceptions for normal
> control flow, others abuse dlopen/dlclose.  
> 
> A rwlock ought to be better, but I don't think we have recursive rwlock in
> libc

rdlock can be recursive, rwlock cannot.  It is something we could add with not
much effort in a custom rwlock, I think.

> yet (all we need is being able to recursively lock it for writing, for
> reading
> we might not need to allow recursion in this case).

Not having to deal with recursive rdlock can make things easier for the rwlock
implementation.

> Plus the current rwlock
> implementation still takes uses a per-process lock to guard the inner
> operations
> on the rwlock, so while rwlock helps with longer critical sections, for very
> short ones it likely doesn't scale all that well.

This will change as soon as my new rwlock is upstream.  Especially short rdlock
sections will be much faster.

[Bug libgcc/71744] Concurrently throwing exceptions is not scalable

[gleb at scylladb dot com]

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

--- Comment #16 from Gleb Natapov  ---
Can you suggest an alternative to libgcc patch? Use other TLS model? Allocate
per thread storage dynamically somehow?

About lock array, I tries to use rwlock and the current one is not better than
regular lock since it does lock internally. There is a patch series to improve
this, but even with the improved rwlock array approach generates much better
result for my test case since it avoids lock contention in most cases. The
array approach can be improved/generalized by having a lock per thread, but I
think array is a much simpler approach that delivers good result.

About programs abusing dlopen/dlclose, while I am sure there are those, it is
reasonable expectation that dlopen/dlclose on different threads will serialize
them, but throwing exception, while expected to be heavy operation, is not
expected to make threads to execute in a lock step. Taking some extra lock
should be negligible compared to other work dlopen has to do.

About memory considerations, are those numbers are so significant, especially
consider the overhead each thread has in the kernel?

I would be nice to continue this discussion on the mailing list.

Regardless, lest apply your patch since it is essential to the final solution.

[Bug libgcc/71744] Concurrently throwing exceptions is not scalable

[jakub at gcc dot gnu.org]

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

--- Comment #17 from Jakub Jelinek  ---
(In reply to torvald from comment #15)
> > Similarly, the 64 recursive locks in libc, again, significant amount of
> > memory
> > per process that doesn't care about exceptions,
> 
> That might be reducable if we build custom locks and don't use pthread ones,
> but we'll at least have 64b per lock.

Right now the lock is I think 40 bytes per lock, which is 64 * 40 bytes per
process.  That is just too much (but of course the 64x locking a recursive lock
is even worse).

> > and especially signficiant
> > slowdown on dlopen/dlclose.  While some programs abuse exceptions for normal
> > control flow, others abuse dlopen/dlclose.  
> > 
> > A rwlock ought to be better, but I don't think we have recursive rwlock in
> > libc
> 
> rdlock can be recursive, rwlock cannot.  It is something we could add with
> not much effort in a custom rwlock, I think.

The dl_load_lock is I believe private, so it could use custom special rwlock.

> > Plus the current rwlock
> > implementation still takes uses a per-process lock to guard the inner
> > operations
> > on the rwlock, so while rwlock helps with longer critical sections, for very
> > short ones it likely doesn't scale all that well.
> 
> This will change as soon as my new rwlock is upstream.  Especially short
> rdlock sections will be much faster.

Nice.

[Bug libgcc/71744] Concurrently throwing exceptions is not scalable

[jakub at gcc dot gnu.org]

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

--- Comment #18 from Jakub Jelinek  ---
(In reply to Gleb Natapov from comment #16)
> Can you suggest an alternative to libgcc patch? Use other TLS model?
> Allocate per thread storage dynamically somehow?

If we want to use TLS (which I hope we don't), then e.g. a single __thread
pointer with some registered destructor that would free it on process exit
could do the job, and on the first exception it would try to allocate memory
for the cache and other stuff and use that (otherwise, if memory allocation
fails, just take a lock and be non-scalable).

Another alternative, perhaps much better, if Torvald is going to improve
rwlocks sufficiently, would be to use rwlock to guard writes to the cache etc.
too, and perhaps somewhat enlarge the cache (either statically, or allow
extending it through allocation).
I'd expect that usually these apps that use exceptions too much only care about
a couple of shared libraries, so writes to the cache ought to be rare.

[Bug target/77590] va_arg() returns 0

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |target

--- Comment #2 from Andrew Pinski  ---
-m16 is not designed for this. It is only designed for short time ato start up
before switching to 32bit mode.

[Bug fortran/77583] ICE in pp_quoted_string, at pretty-print.c:966

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #4 from kargl at gcc dot gnu.org ---
(In reply to Manuel López-Ibáñez from comment #2)
> check_conflict is sometimes called with name = NULL and that is passed to
> %qs causing a crash.

Index: symbol.c
===
--- symbol.c(revision 240140)
+++ symbol.c(working copy)
@@ -473,8 +473,8 @@ check_conflict (symbol_attribute *attr, 
}
 }

-  if (attr->dummy && ((attr->function || attr->subroutine) && 
-   gfc_current_state () == COMP_CONTAINS))
+  if (name && attr->dummy && ((attr->function || attr->subroutine)
+ && gfc_current_state () == COMP_CONTAINS))
 gfc_error_now ("internal procedure %qs at %L conflicts with "
   "DUMMY argument", name, where);

[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler

[jeremyhu at macports dot org]

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

--- Comment #11 from Jeremy Huddleston Sequoia  
---
(In reply to Jeffrey Walton from comment #5)
># port install clang-3.8
># port install gcc6
># ln -s /opt/local/bin/clang /opt/local/bin/clang-3.8

You probably meant:

$ ln -s clang-mp-3.8 /opt/local/bin/clang

However, don't create the symlink yourself.  Use 'sudo port select clang
mp-clang-3.8'

[Bug middle-end/77574] Wrong if condition in predict.c

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Author: marxin
Date: Wed Sep 14 07:18:53 2016
New Revision: 240128

URL: https://gcc.gnu.org/viewcvs?rev=240128=gcc=rev
Log:
Add braces to a condition in predict.c (PR middle-end/77574)

Martin Liska  

PR middle-end/77574
* predict.c (force_edge_cold): Add braces to a condition.

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

[Bug middle-end/77574] Wrong if condition in predict.c

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

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

[Bug target/77586] New: ia64 target fails to build due to ICE triggered by -fself-test

[nickc at gcc dot gnu.org]

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

Bug ID: 77586
   Summary: ia64 target fails to build due to ICE triggered by
-fself-test
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nickc at gcc dot gnu.org
  Target Milestone: ---

A compiler configured as "ia64-elf" currently fails to build on mainline due
to:

./gcc/xgcc -B./gcc/ -xc -S -c /dev/null -fself-test
: internal compiler error: Segmentation fault
0xad5aaf crash_signal
gcc/toplev.c:336
0x613662 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
gcc/tree.h:3148
0x613662 c_register_builtin_type(tree_node*, char const*)
gcc/c-family/c-common.c:3924
0xddd8d6 ia64_init_builtins()
gcc/config/ia64/ia64.c:10373

[Bug sanitizer/69539] ICE in expand_UBSAN_NULL, at internal-fn.c:202

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
I can't reproduce this, either with 6.x nor trunk, with -O0 I'm getting various
error: call to ‘__compiletime_assert_149’ declared with attribute error:
BUILD_BUG_ON failed: MODULES_VADDR < __START_KERNEL_map
like errors, and with -O I'm just getting expected errors due to undefined
symbols, but no ICE.

[Bug libgcc/71744] Concurrently throwing exceptions is not scalable

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  ---
Looking at that patchset, I just want to say that the use of TLS in libgcc is
very much undesirable, it affects every program even when not using exceptions
(significant portion of them), especially when it uses that much (6 *
sizeof(void *) * 8 + sizeof(void *) + 2 * 8 = 408 bytes per thread is
significant, plus it uses the slow local dynamic TLS model.
Similarly, the 64 recursive locks in libc, again, significant amount of memory
per process that doesn't care about exceptions, and especially signficiant
slowdown on dlopen/dlclose.  While some programs abuse exceptions for normal
control flow, others abuse dlopen/dlclose.
A rwlock ought to be better, but I don't think we have recursive rwlock in libc
yet (all we need is being able to recursively lock it for writing, for reading
we might not need to allow recursion in this case).  Plus the current rwlock
implementation still takes uses a per-process lock to guard the inner
operations
on the rwlock, so while rwlock helps with longer critical sections, for very
short ones it likely doesn't scale all that well.

[Bug libgcc/71744] Concurrently throwing exceptions is not scalable

[gleb at scylladb dot com]

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

--- Comment #11 from Gleb Natapov  ---
Jakub, can you apply your path please? As you've said glibc will also have to
be fixed and I am working on it, but without that patch fixing glibc will not
help either.

[Bug tree-optimization/77536] Vectorizer not maintaining relationship of relative block frequencies in absence of real profile data

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-14
 CC||hubicka at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
I think the reason of the current behavior is that without a profile we predict
loops to run for 10 iterations (or so), thus after vectorization with a 
vectorization factor of two you'd get two vector iterations out of that guess.

Honza fixed the profile updating but the real issue is probably the frequencies
we use for the extra tests the vectorizer performs which seem to be all
66% / 33%:

  /* There are many aspects to how likely the first loop is going to be
executed.
 Without histogram we can't really do good job.  Simply set it to
 2/3, so the first loop is not reordered to the end of function and
 the hot path through stays short.  */
  int first_guard_probability = 2 * REG_BR_PROB_BASE / 3;
  int second_guard_probability = 2 * REG_BR_PROB_BASE / 3;

there isn't any attempt to distinguish the different cases.  Even with that
fixed the low number of predicted iterations for the scalar loop make
coming up with a "hot" profile for the vectorized loop difficult.

[Bug libgcc/71744] Concurrently throwing exceptions is not scalable

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
I'll bootstrap/regtest it today.  That said, have you done any scalability
benchmarking with/without that patch?

[Bug libgcc/71744] Concurrently throwing exceptions is not scalable

[gleb at scylladb dot com]

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

--- Comment #13 from Gleb Natapov  ---
I've done it with my version of it which does basically the same. The patch by
itself has no effect on scalability, but in conjunction with this fix for glibc
https://patchwork.ozlabs.org/patch/652301/ I get very good results.

[Bug sanitizer/68260] false positive with tsan

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Author: jakub
Date: Wed Sep 14 09:01:49 2016
New Revision: 240129

URL: https://gcc.gnu.org/viewcvs?rev=240129=gcc=rev
Log:
PR sanitizer/68260
* tsan.c: Include target.h.
(enum tsan_atomic_action): Add bool_clear and bool_test_and_set.
(BOOL_CLEAR, BOOL_TEST_AND_SET): Define.
(tsan_atomic_table): Add BUILT_IN_ATOMIC_CLEAR and
BUILT_IN_ATOMIC_TEST_AND_SET entries.
(instrument_builtin_call): Handle bool_clear and bool_test_and_set.

* c-c++-common/tsan/pr68260.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/tsan/pr68260.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tsan.c

[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler

[jeremyhu at macports dot org]

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

--- Comment #12 from Jeremy Huddleston Sequoia  
---
(In reply to Iain Sandoe from comment #9)
> we ought not be in a position where we detect that the ld64 is too old at
> the same time as trying to use the LLVM back end as the assembler.

It is possible for someone to manually force themselves into such a situation,
but that is not a configuration we (Apple, MacPorts, LLVM, GCC) should support.

[Bug preprocessor/12258] -Wold-style-cast triggers on casts in macros from system headers

[olly at survex dot com]

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

olly at survex dot com changed:

   What|Removed |Added

 CC||olly at survex dot com

--- Comment #4 from olly at survex dot com ---
It looks like this was fixed in GCC 4.8 where -ftrack-macro-expansion=2 was
made the default.

With 4.7 the warning goes away if I explicitly pass -ftrack-macro-expansion=2,
while with 4.8 it comes back if I override this new default with
-ftrack-macro-expansion=0.