[Bug target/68110] __builtin_sub_overflow unsigned performance issue

[eggert at gnu dot org]

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

--- Comment #3 from Paul Eggert  ---
(In reply to Andrew Pinski from comment #2)
> So the question is does anyone use this function without "a - b" later on? 

Not that I know of. The usual pattern for callers of the Gnulib macro is to use
the macro to check whether there's overflow, and then to subtract if the result
wouldn't overflow. So you're correct that my example is a microbenchmark and is
not a good representative.

That being said, and I'm just thinking aloud here, it may be helpful for GCC to
try "a < b" as an alternative way to test for unsigned subtraction overflow, or
conversely to have GCC use __builtin_sub_overflow as an alternative way to
compute "a < b". Here's a slightly-more-realistic example:

  unsigned long
  sub1 (unsigned long a, unsigned long b)
  {
if (a < b)
  return b - a;
else
  return a - b;
  }

  unsigned long
  sub2 (unsigned long a, unsigned long b)
  {
unsigned long c;
if (__builtin_sub_overflow (a, b, &c))
  return b - a;
else
  return c;
  }

On x86-64, gcc -O2 -S generates this:

  sub1:
  movq%rsi, %rdx
  movq%rdi, %rax
  subq%rdi, %rdx
  subq%rsi, %rax
  cmpq%rsi, %rdi
  cmovb   %rdx, %rax
  ret

  sub2:
  movq%rdi, %rax
  subq%rsi, %rax
  cmpq%rdi, %rax
  ja  .L13
  rep ret
  .L13:
  movq%rsi, %rax
  subq%rdi, %rax
  ret

The two functions have the same behavior. Presumably one implementation is
better than the other, and could be used for both sub1 and sub2.

[Bug target/68110] __builtin_sub_overflow unsigned performance issue

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
So the question is does anyone use this function without "a - b" later on?  If
not then it is just a microbenchmark of this code is showing the regression and
I would say the microbenchmark is wrong.

[Bug target/68110] __builtin_sub_overflow unsigned performance issue

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||x86_64*-* i686-*-*
  Component|c   |target

--- Comment #1 from Andrew Pinski  ---
Looks like the unused sub is not being removed.
Normally when someone uses __builtin_sub_overflow, the sub will not be unused.

[Bug c/68110] New: __builtin_sub_overflow unsigned performance issue

[eggert at gnu dot org]

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

Bug ID: 68110
   Summary: __builtin_sub_overflow unsigned performance issue
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eggert at gnu dot org
  Target Milestone: ---

I ran into this minor performance issue when changing Gnulib's lib/intprops.h
to use the new __builtin_sub_overflow function. I found that
__builtin_sub_overflow is less efficient than the portable C code that it
replaced, when the operands and result are unsigned, or unsigned long, or
unsigned long long. To reproduce the problem, compile and run the following
program with 'gcc -O2 -S' on x86-64:

  _Bool f1 (unsigned long long a, unsigned long long b)
  {
return a < b;
  }

  _Bool f2 (unsigned long long a, unsigned long long b)
  {
unsigned long long r;
return __builtin_sub_overflow (a, b, &r);
  }

Although the functions are semantically equivalent, f1 uses only 3
instructions:

f1:
cmpq%rsi, %rdi
setb%al
ret

whereas f2 uses 5 instructions:

f2:
movq%rdi, %rax
subq%rsi, %rax
cmpq%rdi, %rax
seta%al
ret

There is a similar problem for x86.

[Bug other/68109] New: GCC fails to vectorize popcount on x86_64

[haneef503 at gmail dot com]

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

Bug ID: 68109
   Summary: GCC fails to vectorize popcount on x86_64
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haneef503 at gmail dot com
  Target Milestone: ---

Created attachment 36595
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36595&action=edit
Clang Vectorized Assembly Output

The following code is an SSCCE that GCC doesn't vectorize on x86_64:

#include 
#include 

size_t hd (const uint8_t *restrict a, const uint8_t *restrict b, size_t l) {
  size_t r = 0, x;
  for (x = 0; x < l; x++)
r += __builtin_popcount (a[x] ^ b[x]);

  return r;
}

On other architectures, such as power8, GCC successfully vectorizes the loop.
However, on x86_64, there doesn't actually exist a vector version of the
`popcnt` instruction. Despite this, as shown by
[http://wm.ite.pl/articles/sse-popcount.html] it is actually possible to
vectorize popcount by using SSE2 or SSSE3 instructions. Further research on
[https://software.intel.com/sites/landingpage/IntrinsicsGuide/] shows that it
may be possible to achieve further performance on the latest architectures
gains by using AVX2 instructions along the same lines as in the article, albeit
with 256-bit YMM registers in place of the 128-bit XMM registers used in the
article. Since GCC often has support for insofar unreleased architectures, I
did a bit more research on the Intel Intrisics Guide mentioned above for future
architectures and found that the same could likely also be done using AVX-512
with the 512-bit ZMM registers if you guys are interested.

Anyways, I did find that clang has been doing these optimizations since
~clang3.5. I've attached an output of the resulting [vectorized] assembly
emitted by clang3.7 for the above function, since it appears to be done
relatively thoroughly and cleanly.

In both GCC and Clang, I used the following flags:

-xc -O2 -ftree-vectorize -D_GNU_SOURCE  -std=gnu11 -fverbose-asm

[Bug inline-asm/68095] "cc" clobber with Flag Output Operands

[gccbugzilla at limegreensocks dot com]

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

--- Comment #1 from David  ---
On further reflection, perhaps the best solution is even simpler.

It is my understanding that the "cc" clobber is redundant.  Internally, the
flags are clobbered whether you set this or not.  And I can't see how this
behavior can ever change now that it has been like this for so long.

As a result, perhaps the solution is to just change the docs for the "cc"
clobber to say that it is meaningless.  Maybe something like:

"cc" This clobber is only kept for historical reasons.  It no longer has any
effect on the generation of code.

[Bug fortran/68108] [6.0 regression] erroneous error message 'scalar integer expression expected'

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-27
 CC||kargl at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from kargl at gcc dot gnu.org ---
This looks like fallout from my patch for PR fortran/67805.

2015-10-24  Steven G. Kargl  

PR fortran/67805
* array.c (gfc_match_array_constructor): Check for error from type
spec matching.
* decl.c (char_len_param_value): Check for valid of charlen parameter.
Reap dead code dating to 2008.
match.c (gfc_match_type_spec): Special case the keyword use in REAL.

Tentative patch

Index: decl.c
===
--- decl.c  (revision 229390)
+++ decl.c  (working copy)
@@ -754,7 +754,8 @@ char_len_param_value (gfc_expr **expr, b

   gfc_reduce_init_expr (e);

-  if ((e->ref && e->ref->u.ar.type != AR_ELEMENT) 
+  if ((e->ref && e->ref->type == REF_ARRAY
+  && e->ref->u.ar.type != AR_ELEMENT) 
  || (!e->ref && e->expr_type == EXPR_ARRAY))

[Bug fortran/66927] [6 Regression] ICE in gfc_conf_procedure_call

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #19 from Steve Kargl  ---
On Tue, Oct 27, 2015 at 01:01:37AM +, juergen.reuter at desy dot de wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66927
> 
> --- Comment #17 from Jürgen Reuter  ---
> Done, 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68108
> 

I may have a patch already written.  Need to run testsuite.

[Bug fortran/66927] [6 Regression] ICE in gfc_conf_procedure_call

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #18 from Steve Kargl  ---
On Tue, Oct 27, 2015 at 01:01:37AM +, juergen.reuter at desy dot de wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66927
> 
> --- Comment #17 from Jürgen Reuter  ---
> Done, 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68108
> 

I may have a patch already written.  Need to run testsuite.

[Bug fortran/66927] [6 Regression] ICE in gfc_conf_procedure_call

[juergen.reuter at desy dot de]

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

--- Comment #17 from Jürgen Reuter  ---
Done, 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68108

[Bug fortran/68108] New: [6.0 regression] erroneous error message 'scalar integer expression expected'

[juergen.reuter at desy dot de]

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

Bug ID: 68108
   Summary: [6.0 regression] erroneous error message 'scalar
integer expression expected'
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juergen.reuter at desy dot de
  Target Milestone: ---

The following code doesn't compile anymore but used to at least until ca.
r227300 of gcc:
module lexers
  implicit none
  private
  type :: template_t
 private
 character(256) :: charset1
 integer :: len1
  end type template_t

contains

  subroutine match_quoted (tt, s, n)
type(template_t), intent(in) :: tt
character(*), intent(in) :: s
integer, intent(out) :: n
character(tt%len1) :: ch1
ch1 = tt%charset1
  end subroutine match_quoted

end module lexers
This leads to the error message:
lexers.f90:16:14:
   character(tt%len1) :: ch1
Error: Scalar INTEGER expression expected at (1)

[Bug fortran/66927] [6 Regression] ICE in gfc_conf_procedure_call

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #16 from kargl at gcc dot gnu.org ---
(In reply to Jürgen Reuter from comment #15)
> Here it it:
> {{{
> module lexers
>   implicit none
>   private
>   type :: template_t
>  private
>  character(256) :: charset1
>  integer :: len1
>   end type template_t
> 
> contains
> 
>   subroutine match_quoted (tt, s, n)
> type(template_t), intent(in) :: tt
> character(*), intent(in) :: s
> integer, intent(out) :: n
> character(tt%len1) :: ch1
> ch1 = tt%charset1
>   end subroutine match_quoted
> 
> end module lexers
> }}}
> I believe this comes from your commit, so I don't open up a new ticket.
> Would be cool if this can be solved quickly.

I doubt that it is related to Andre's patch as nothing in the above
code uses ALLOCATE.  The error messages is also one that I just
introduced.  So, submit a PR.

[Bug libffi/65441] FAIL: libffi.call/float2.c -W -Wall -Wno-psabi (test for excess errors)

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

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

--- Comment #6 from John David Anglin  ---
Fixed.

[Bug libffi/65441] FAIL: libffi.call/float2.c -W -Wall -Wno-psabi (test for excess errors)

[danglin at gcc dot gnu.org]

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

--- Comment #5 from John David Anglin  ---
Author: danglin
Date: Tue Oct 27 00:41:31 2015
New Revision: 229401

URL: https://gcc.gnu.org/viewcvs?rev=229401&root=gcc&view=rev
Log:
PR libffi/65441
* testsuite/lib/libffi.exp: Load target-supports-dg.exp.
* testsuite/libffi.call/float2.c: Don't run on hppa*-*-hpux*.


Modified:
branches/gcc-5-branch/libffi/ChangeLog
branches/gcc-5-branch/libffi/testsuite/lib/libffi.exp
branches/gcc-5-branch/libffi/testsuite/libffi.call/float2.c

[Bug libffi/65441] FAIL: libffi.call/float2.c -W -Wall -Wno-psabi (test for excess errors)

[danglin at gcc dot gnu.org]

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

--- Comment #4 from John David Anglin  ---
Author: danglin
Date: Tue Oct 27 00:39:32 2015
New Revision: 229400

URL: https://gcc.gnu.org/viewcvs?rev=229400&root=gcc&view=rev
Log:
PR libffi/65441
* testsuite/lib/libffi.exp: Load target-supports-dg.exp.
* testsuite/libffi.call/float2.c: Don't run on hppa*-*-hpux*.


Modified:
trunk/libffi/ChangeLog
trunk/libffi/testsuite/lib/libffi.exp
trunk/libffi/testsuite/libffi.call/float2.c

[Bug c/68065] Size calculations for VLAs can overflow

[joseph at codesourcery dot com]

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

--- Comment #6 from joseph at codesourcery dot com  ---
On Tue, 27 Oct 2015, ch3root at openwall dot com wrote:

> > VLA size overflow, however, is undefined behavior at runtime, not compile
> > time, hence a matter for ubsan.
> 
> VLA size overflow is very similar to overflow in "new". Shouldn't it be 
> handled in a similar way?

I'm thinking of it as essentially like stack overflow, where it's 
traditionally been the user's job to bound their stack allocations.  I 
think ubsan should enable all of (VLA size overflow checks, stack checking 
for fixed-size allocations to ensure the amount of stack space allocated 
in one go is small enough that overflow is guaranteed to be detected, 
similar checks for variable size allocations whether from VLAs or alloca).  
Of course separate options for various cases may make sense as well.

[Bug c/68107] Non-VLA type whose size is half or more of the address space constructed via a pointer

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  ---
grokdeclarator seems to check the declared size of an array (when 
processing an array declarator) - that is, the size counted in array 
elements - and then has a separate check for the size in bytes only when 
the final type of the full declarator is an array type.  I think the check 
on the size in bytes needs moving up to check every non-VLA complete array 
type constructed in the course of processing the declarator.

[Bug c/68065] Size calculations for VLAs can overflow

[ch3root at openwall dot com]

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

--- Comment #5 from Alexander Cherepanov  ---
On 2015-10-27 02:27, joseph at codesourcery dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68065
>
> --- Comment #4 from joseph at codesourcery dot com  dot com> ---
> On Mon, 26 Oct 2015, ch3root at openwall dot com wrote:
>
>> The core issue is an overflow in size computations which is not limited to 
>> VLA.
>> You can as easily get a crash with non-VLA-array+sizeof+malloc:
>>
>> #define N /* complex computation leading to.. */ (UINT_MAX / sizeof(int) + 2)
>>int (*p)[N];
>
> That sounds like a completely separate bug.  Please file a separate bug in
> Bugzilla for it.  Any construction of a non-VLA type whose size is half or
> more of the address space should receive a compile-time error, like you
> get if you don't use a pointer here.

Ok, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68107 .

> VLA size overflow, however, is undefined behavior at runtime, not compile
> time, hence a matter for ubsan.

VLA size overflow is very similar to overflow in "new". Shouldn't it be 
handled in a similar way?

[Bug c/68107] New: Non-VLA type whose size is half or more of the address space constructed via a pointer

[ch3root at openwall dot com]

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

Bug ID: 68107
   Summary: Non-VLA type whose size is half or more of the address
space constructed via a pointer
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ch3root at openwall dot com
  Target Milestone: ---

Due to an overflow in size calculation the following (seemingly reasonable)
program compiles fine, allocates too small array and crashes in a loop:

#include 
#include 
#include 

#define N (SIZE_MAX / sizeof(int) + 2)

int main(void)
{
  int (*p)[N];
  printf("%zu\n", sizeof *p);
  p = malloc(sizeof *p);
  if (!p)
return 1;
  for (size_t i = 0; i < N; i++)
(*p)[i] = 1;

  return 0;
}

According to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68065#c4 : "Any
construction of a non-VLA type whose size is half or more of the address space
should receive a compile-time error, like you get if you don't use a pointer
here."

[Bug fortran/66927] [6 Regression] ICE in gfc_conf_procedure_call

[juergen.reuter at desy dot de]

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

--- Comment #15 from Jürgen Reuter  ---
Here it it:
{{{
module lexers
  implicit none
  private
  type :: template_t
 private
 character(256) :: charset1
 integer :: len1
  end type template_t

contains

  subroutine match_quoted (tt, s, n)
type(template_t), intent(in) :: tt
character(*), intent(in) :: s
integer, intent(out) :: n
character(tt%len1) :: ch1
ch1 = tt%charset1
  end subroutine match_quoted

end module lexers
}}}
I believe this comes from your commit, so I don't open up a new ticket. Would
be cool if this can be solved quickly.

[Bug c/68065] Size calculations for VLAs can overflow

[joseph at codesourcery dot com]

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

--- Comment #4 from joseph at codesourcery dot com  ---
On Mon, 26 Oct 2015, ch3root at openwall dot com wrote:

> The core issue is an overflow in size computations which is not limited to 
> VLA.
> You can as easily get a crash with non-VLA-array+sizeof+malloc:
> 
> #define N /* complex computation leading to.. */ (UINT_MAX / sizeof(int) + 2)
>   int (*p)[N];

That sounds like a completely separate bug.  Please file a separate bug in 
Bugzilla for it.  Any construction of a non-VLA type whose size is half or 
more of the address space should receive a compile-time error, like you 
get if you don't use a pointer here.

VLA size overflow, however, is undefined behavior at runtime, not compile 
time, hence a matter for ubsan.

[Bug fortran/66927] [6 Regression] ICE in gfc_conf_procedure_call

[juergen.reuter at desy dot de]

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

--- Comment #14 from Jürgen Reuter  ---
These changes seem to break our code. Will provide an example in a minute.

[Bug rtl-optimization/68106] New: c-c++-common/torture/builtin-arith-overflow-11.c FAILs with -flra-remat @ aarch64

[zsojka at seznam dot cz]

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

Bug ID: 68106
   Summary: c-c++-common/torture/builtin-arith-overflow-11.c FAILs
with -flra-remat @ aarch64
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---

Created attachment 36594
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36594&action=edit
reduced testcase

The testcase fails at aarch64 at both trunk and 5-branch with -O -flra-remat. I
haven't managed to generate wrong code with -O2, which enables -flra-remat. I
am using qemu userspace emulation to run the testcase.

$ gcc -O -flra-remat testcase.c
$ ./a.out 
qemu: uncaught target signal 6 (Aborted) - core dumped
Aborted

$ gcc -O -flra-remat testcase.c -S
$ gcc -O -fno-lra-remat testcase.c -S -o testcase-no-lra-remat.s
$ diff -u testcase.s testcase-no-lra-remat.s
...
@@ -104,20 +104,21 @@
 .L25:
lsl x20, x23, 56
add x19, x20, x26
+   str x19, [x29, 128]
asr x22, x19, 63
addsx27, x21, x19
adc x0, x24, x22
-   str x0, [x29, 120]
-   add x2, x29, 140
+   str x0, [x29, 136]
+   add x2, x29, 156
mov x1, x19
mov x0, x25
bl  upseu
cmp x0, x27
bne .L14
-   adc x0, x24, x22
+   ldr x0, [x29, 136]
cmp x0, xzr
csetw1, ne
-   ldr w0, [x29, 140]
+   ldr w0, [x29, 156]
cmp w1, w0
bne .L14
subsx1, x21, x20
...

If I am reading the assembly correctly, the important difference is:
...
addsx27, x21, x19
adc x0, x24, x22
-   str x0, [x29, 120]
-   add x2, x29, 140
+   str x0, [x29, 136]
+   add x2, x29, 156
...
-   adc x0, x24, x22
+   ldr x0, [x29, 136]
...

Normally, without lra-remat, the result of "adc x0, x24, x22" is stored to
the stack and then reloaded. 
With -flra-remat, the value is stored as well, but later, "adc" is used to
recompute the value again - that saves one access to the stack, but cpsr has
changed in the meantime, so it is using wrong value of the C bit.

Tested revisions:
r229293 - FAIL
5-branch r229305 - FAIL
4_9-branch - doesn't know -flra-remat

[Bug sanitizer/68016] ASan doesn't catch overflow in globals when COPY relocation is involved.

[rnk at google dot com]

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

--- Comment #7 from Reid Kleckner  ---
(In reply to Jakub Jelinek from comment #6)
> Because symbol size is part of the ABI, and LLVM emits different symbol size
> between -fsanitize=address and -fno-sanitize=address.
> E.g. COPY relocations use the st_size field, so you can have:
> 1) shared library originally not ASAN instrumented, binary (e.g. non-ASAN)
> linked against it, then the shared library recompiled with ASAN - the size
> of the symbol in the binary will be the one without padding, but LLVM
> incorrectly registers the variable using global symbol rather than local
> alias and thus assumes there is padding which is not available (plus you can
> get a runtime warning on the st_size mismatch from the dynamic linker)

I thought COPY relocations only occurred with fPIE, but I must have been
mistaken.

> 2) even without COPY relocations, you could have the same variable defined
> in multiple shared libraries, if some of them are -fsanitize=address and the
> others are not, there is mismatch between the variable sizes, and depending
> on which library comes earlier in the symbol search scope, you could have
> either the version without or with padding used at runtime, but the
> sanitized libraries could very well register the non-padded one, making it
> fatal error to access e.g. variables after it

LLVM ASan tries to instrument only global definitions with external linkage.
The goal of this check is to ensure that we have found the one true definition
of the global, and it isn't COMDAT, weak, a C string, or going to get replaced
with something else at link time through some other means.

It seems like you are describing interposition, which isn't something LLVM
supports very well. LLVM has no equivalent of -fsemantic-interposition, for
example. We always operate under something like -fno-semantic-interposition. (I
know, it's ironic, because ASan interposes libc.)

Anyway, I agree the COPY relocation issue is a real problem, but other than
that I think our approach is at least internally consistent.

[Bug rtl-optimization/67609] [5/6 Regression] Generates wrong code for SSE2 _mm_load_pd

[vmakarov at gcc dot gnu.org]

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

--- Comment #30 from Vladimir Makarov  ---
(In reply to Richard Henderson from comment #29)
>
> 
> Ho hum.  Sorry, Vlad, if I'd bothered bootstrapping I'd have seen this
> myself.
> Please change != to < in the patch to re-try.  (That is, allow the TO mode to
> be wider than the FROM mode in order to support the paradoxical subregs seen
> above.)

Thanks.  I've checked the patch on Haswell x86-64 SPEC2000 using -O3
-mtune=corei7.  The patch changes code of 3 out of 12 SPECInt tests and 9 of 14
SPECFP tests.  The code size always increases.  No surprise.  But the change is
insignificant (about 0.001%).  The biggest SPEC rate decrease is achieved on
SPECFP and is only about 0.15%.

So I guess the patch is ok to fix the problem.

[Bug target/63346] xserver_xorg-server-1.15.1 crash on RaspberryPi when compiled with gcc-4.9

[ps.report at gmx dot net]

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

--- Comment #3 from Peter Seiderer  ---
Created attachment 36593
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36593&action=edit
Reduces test case from xserver_xorg-server-1.17.2/fb/fbpict.c

Reduced (but not yet minimal) test case from the
original xserver_xorg-server-1.17.2/fb/fbpict.c file.

On x86_64:

$ ./fbpict_x86
$ cat my.log
fbGlyphs() pSrc = (nil) pDst = 0x602280 glyphs = 0x6021b0
glyphs = 0x6021b0 - 1
glyphs = 0x6021b8 - 2
glyphs = 0x602070 - 3
glyphs = 0x6021b8 - 1
glyphs = 0x6021c0 - 2
glyphs = 0x6020b0 - 3
glyphs = 0x6021c0 - 1
glyphs = 0x6021c8 - 2
glyphs = 0x6020f0 - 3
glyphs = 0x6021c8 - 1
glyphs = 0x6021d0 - 2
glyphs = 0x602130 - 3
glyphs = 0x6021d0 - 1
glyphs = 0x6021d8 - 2
glyphs = 0x602170 - 3


On Raspberry Pi (arm):
$ ./fbpict_arm
Segmentation fault
$ cat my.log 
fbGlyphs() pSrc = (nil) pDst = 0x20c24 glyphs = 0x20ce4
glyphs = 0x20ce4 - 1

$ gdb ./fbpict_arm
(gdb) run
Starting program: /root/gcc_bug_63346/fbpict_arm 

Program received signal SIGSEGV, Segmentation fault.
fbGlyphs (op=op@entry=0 '\000', pSrc=0x5, pSrc@entry=0x0, pDst=0x0, 
pDst@entry=0x20c24 , maskFormat=0x5, 
maskFormat@entry=0x0, xSrc=xSrc@entry=10, ySrc=ySrc@entry=10, nlist=-1, 
nlist@entry=5, list=list@entry=0x20c6c , glyphs=0x5, 
glyphs@entry=0x20ce4 ) at fbpict.c:59
59  glyph = *glyphs++;
(gdb) disassemble
...
   0x00010658 <+272>:   beq 0x10794 
   0x0001065c <+276>:   ldrsh   r3, [r4, #-12]
   0x00010660 <+280>:   add r10, r10, r3
   0x00010664 <+284>:   ldrsh   r3, [r4, #-10]
   0x00010668 <+288>:   add r11, r11, r3
   0x0001066c <+292>:   ldrbr3, [r4, #-8]
   0x00010670 <+296>:   str r3, [sp, #52]   ; 0x34
   0x00010674 <+300>:   ldr r3, [sp, #52]   ; 0x34
   0x00010678 <+304>:   cmp r3, #0
   0x0001067c <+308>:   beq 0x10780 
   0x00010680 <+312>:   add r3, sp, #6336   ; 0x18c0
   0x00010684 <+316>:   ldr r1, [r3]
   0x00010688 <+320>:   ldr r0, [pc, #684]  ; 0x1093c 
   0x0001068c <+324>:   bl  0x1098c 
=> 0x00010690 <+328>:   ldr r3, [r2]
   0x00010694 <+332>:   add r2, sp, #6336   ; 0x18c0
   0x00010698 <+336>:   ldr r7, [r3], #4
   0x0001069c <+340>:   ldr r0, [pc, #668]  ; 0x10940 
   0x000106a0 <+344>:   str r3, [r2]
   0x000106a4 <+348>:   ldr r1, [r2]
   0x000106a8 <+352>:   bl  0x1098c 
   0x000106ac <+356>:   mov r1, r7
   0x000106b0 <+360>:   ldr r0, [pc, #652]  ; 0x10944 
   0x000106b4 <+364>:   bl  0x1098c 
   0x000106b8 <+368>:   ldr r3, [pc, #632]  ; 0x10938 
   0x000106bc <+372>:   mov r2, #0
   0x000106c0 <+376>:   mov r1, r7
   0x000106c4 <+380>:   ldr r0, [r3]
   0x000106c8 <+384>:   bl  0x10970 
   0x000106cc <+388>:   subsr9, r0, #0
   0x000106d0 <+392>:   bne 0x10748 
   0x000106d4 <+396>:   ldr r1, [sp, #84]   ; 0x54
   0x000106d8 <+400>:   mov r0, r7
   0x000106dc <+404>:   bl  0x10978 

[Bug c/68105] New: optimizing repeated floating point addition to multiplication

[zboson at zboson dot net]

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

Bug ID: 68105
   Summary: optimizing repeated floating point addition to
multiplication
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zboson at zboson dot net
  Target Milestone: ---

This discussion is based on a question I asked on Stack Overflow
http://stackoverflow.com/questions/33152446/floating-point-multiplication-vs-repeated-addition

Using appropriate compilers options I think GCC should simplify

//N is a compile time unsigned value
float sum = 0;
for(unsigned i=0; i=6 GCC should do this when
associative math is enabled e.g. with -Ofast

However, GCC only simplifies this in log(N) additions and only for small N. For
example for N = 8 GCC does with -Ofast

sum = a + a
sum = sum + sum // (a + a) + (a + a)
sum = sum + sum // ((a + a) + (a + a)) + ((a + a) + (a + a))

but it could simply do

8.0f*a;

Not only is this simpler but it's more accurate (which I show in the question
on Stack Overflow)

But even worse is that by N = 32 GCC does every iteration , i.e. N-1 additions.

In addition, the following equations are always true even without associative
math.

2*a = a + a
3*a = a + a + a
4*a = a + a + a + a
5*a = a + a + a + a + a

It turns out that GCC does simplify a + a + a + a to 4*a but only with
associative math enabled e.g. with -Ofast when it could do it with -O3.

Read the Stack Overflow question for more details.

[Bug c/68065] Size calculations for VLAs can overflow

[ch3root at openwall dot com]

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

--- Comment #3 from Alexander Cherepanov  ---
(In reply to jos...@codesourcery.com from comment #2)
> This seems like a matter for -fsanitize=undefined 

UBSAN is intended to help with invalid programs but this code looks like valid.
Hence diagnostic for problems with such code seem to belong to core gcc.

The core issue is an overflow in size computations which is not limited to VLA.
You can as easily get a crash with non-VLA-array+sizeof+malloc:

#define N /* complex computation leading to.. */ (UINT_MAX / sizeof(int) + 2)
  int (*p)[N];
  printf("%zu\n", sizeof *p);
  p = malloc(sizeof *p);
  if (!p)
return 1;
  for (unsigned i = 0; i < N; i++)
(*p)[i] = 1;

Please note:
- size in this examples is tuned so that it crashes on 32-bit platform only and
works fine on 64-bit one, i.e. the problem could arise in not quite evident
situations;
- the approach to dynanmic arrays a-la Pascal -- "int (*p)[n]; p =
malloc(sizeof *p);" -- is not common in C but could be expected to become more
popular now that UBSAN supports bounds-checking for VLAs.

[Bug c/68104] New: ice in vect_update_misalignment_for_peel with -O3

[dcb314 at hotmail dot com]

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

Bug ID: 68104
   Summary: ice in vect_update_misalignment_for_peel with -O3
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 36592
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36592&action=edit
C source code

For trunk dated 20151025 on x86_64, the attached code crashes as follows
when compiled with -O3

osm_qos.c: In function ‘vlarb_update_table_block’:
osm_qos.c:146:24: internal compiler error: in
vect_update_misalignment_for_peel, at tree-vect-data-refs.c:850
0x138e609 vect_update_misalignment_for_peel
../../src/trunk/gcc/tree-vect-data-refs.c:849
0x138f2a5 vect_peeling_hash_get_lowest_cost(_vect_peel_info**,
_vect_peel_extended_info*)
../../src/trunk/gcc/tree-vect-data-refs.c:1167
0x139bd9a void hash_table::traverse_noresize<_vect_peel_extended_info*,
&(vect_peeling_hash_get_lowest_cost(_vect_peel_info**,
_vect_peel_extended_info*))>(_vect_peel_extended_info*)
../../src/trunk/gcc/hash-table.h:915
0x139bd9a void hash_table::traverse<_vect_peel_extended_info*,
&(vect_peeling_hash_get_lowest_cost(_vect_peel_info**,
_vect_peel_extended_info*))>(_vect_peel_extended_info*)
../../src/trunk/gcc/hash-table.h:937
0x139bd9a vect_peeling_hash_choose_best_peeling
../../src/trunk/gcc/tree-vect-data-refs.c:1222
0x139bd9a vect_enhance_data_refs_alignment(_loop_vec_info*)
../../src/trunk/gcc/tree-vect-data-refs.c:1636
0xe0547f vect_analyze_loop_2
../../src/trunk/gcc/tree-vect-loop.c:1748
0xe0547f vect_analyze_loop(loop*)
../../src/trunk/gcc/tree-vect-loop.c:1934
0xe1a81f vectorize_loops()
../../src/trunk/gcc/tree-vectorizer.c:496
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug fortran/66056] ICEs and endless compilation for lonely labels/numbers in type

[lkrupp at gcc dot gnu.org]

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

lkrupp at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||lkrupp at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #7 from lkrupp at gcc dot gnu.org ---
Fixed in revision 229390.

The problem: Statement labels within a type declaration are put in the
statement label tree belonging to the type declaration's namespace's (instead
of the current namespace). When the line is otherwise empty and an error is
issued, gfc_free_st_label tries to delete the label from the label tree
belonging to the current namespace and then frees the label structure, leaving
an invalid statement label pointer in the type declaration's namespace's label
tree. When that namespace is cleaned up, bad things can happen.

The attached patch stores a namespace pointer in the statement label structure
so that if a label is deleted early for some reason, it will be deleted from
the proper namespace.

[Bug fortran/66056] ICEs and endless compilation for lonely labels/numbers in type

[lkrupp at gcc dot gnu.org]

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

--- Comment #6 from lkrupp at gcc dot gnu.org ---
Author: lkrupp
Date: Mon Oct 26 19:18:08 2015
New Revision: 229390

URL: https://gcc.gnu.org/viewcvs?rev=229390&root=gcc&view=rev
Log:
2015-10-26  Louis Krupp  

PR fortran/66056
* fortran.h: Include namespace pointer in statement label
structure.
* symbol.c (gfc_get_st_label): Store pointer to namespace
that owns the statement label tree in each label.
(gfc_free_st_label): Use namespace owning statement label
tree when deleting statement label.
* io.c: Initialize format_asterisk with NULL namespace pointer.

2015-10-26  Louis Krupp  

PR fortran/66056
* gfortran.dg/empty_label_typedecl.f90: New test

Added:
trunk/gcc/testsuite/gfortran.dg/empty_label_typedecl.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/io.c
trunk/gcc/fortran/symbol.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/67609] [5/6 Regression] Generates wrong code for SSE2 _mm_load_pd

[rth at gcc dot gnu.org]

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

--- Comment #29 from Richard Henderson  ---
(In reply to Vladimir Makarov from comment #27)
> (In reply to Vladimir Makarov from comment #25)
> > So it would be nice to benchmark it.  I'll try to do this on
> > Friday.
> 
> Practically every SPEC2000 benchmark failed to compile with this patch.  GCC
> crashes in split2 pass with messages like this
> 
> Error: unrecognizable insn:
> (insn 381 345 67 3 (set (subreg:V2DF (reg:DF 22 xmm1 [287]) 0)
> (xor:V2DF (subreg:V2DF (reg:DF 22 xmm1 [287]) 0)
> (mem/u/c:V2DF (symbol_ref/u:DI ("*.LC6") [flags 0x2]) [2  S16
> A128])))

Ho hum.  Sorry, Vlad, if I'd bothered bootstrapping I'd have seen this myself.
Please change != to < in the patch to re-try.  (That is, allow the TO mode to
be wider than the FROM mode in order to support the paradoxical subregs seen
above.)

[Bug fortran/67885] ICE on using parameter array in block

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from kargl at gcc dot gnu.org ---
I'm testing a patch now.

[Bug sanitizer/68099] arm-*-linux-gnueabihf -fsanitize=undefined warning: '' is used uninitialized in this function

[chefmax at gcc dot gnu.org]

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

--- Comment #5 from Maxim Ostapenko  ---
(In reply to Jonathan Ben-Avraham from comment #3)
> (In reply to Maxim Ostapenko from comment #2)
> > I actually believe this is a dup of PR66977, that was fixed by Marek quite
> > time ago. Could you try trunk compiler?
> 
> "trunk compiler"? As in SVN trunk? If so please send URL of branch to test.

I suspect something like this should work:

svn checkout svn://gcc.gnu.org/svn/gcc/trunk/ trunk

[Bug sanitizer/68099] arm-*-linux-gnueabihf -fsanitize=undefined warning: '' is used uninitialized in this function

[yba at tkos dot co.il]

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

--- Comment #4 from Jonathan Ben-Avraham  ---
(In reply to Richard Earnshaw from comment #1)
> The gcc developers do not use crosstool, so providing us with a config for
> it is of no help.  Furthermore, un-preprocessed source means we are unlikely
> to be able to reproduce the exact conditions leading up to the failure you
> see.
> 
> What we do need are:
> 
> 1) The output of "gcc -v", showing how the compiler was actually configured.
> 2) *Pre-processed* source that we can feed into our own builds of the
> compiler to try to reproduce the problem

Will do, +36 hours.

[Bug sanitizer/68099] arm-*-linux-gnueabihf -fsanitize=undefined warning: '' is used uninitialized in this function

[yba at tkos dot co.il]

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

--- Comment #3 from Jonathan Ben-Avraham  ---
(In reply to Maxim Ostapenko from comment #2)
> I actually believe this is a dup of PR66977, that was fixed by Marek quite
> time ago. Could you try trunk compiler?

"trunk compiler"? As in SVN trunk? If so please send URL of branch to test.

[Bug c++/68103] New: Unnecessary copying due to order of evaluation with operator new

[glisse at gcc dot gnu.org]

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

Bug ID: 68103
   Summary: Unnecessary copying due to order of evaluation with
operator new
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glisse at gcc dot gnu.org
  Target Milestone: ---

#include 
struct A{A(A const&);};
A f();
void g(A*p){new(p)A(f());}

(the same applies to other variants of new, so DR 1748 (is there a PR for that
one?) will not fix it)

g++ calls f before operator new. If the result of operator new is non-zero, it
then copies the result to *p.

On the other hand, clang calls operator new first. It then tests for zero, and
if not it calls f, letting it use *p directly for its return value.

The order of evaluation chosen by gcc seems to prevent this copy elision, for a
benefit that is unlikely to be comparable, so I would be in favor of changing
it in this particular case (both orders are legal).

(I just noticed that a possibly related paper by Gaby was discussed last week,
I didn't check if it says anything about this particular case)

[Bug sanitizer/68099] arm-*-linux-gnueabihf -fsanitize=undefined warning: '' is used uninitialized in this function

[chefmax at gcc dot gnu.org]

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

Maxim Ostapenko  changed:

   What|Removed |Added

 CC||chefmax at gcc dot gnu.org

--- Comment #2 from Maxim Ostapenko  ---
I actually believe this is a dup of PR66977, that was fixed by Marek quite time
ago. Could you try trunk compiler?

[Bug sanitizer/68099] arm-*-linux-gnueabihf -fsanitize=undefined warning: '' is used uninitialized in this function

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-10-26
 Ever confirmed|0   |1

--- Comment #1 from Richard Earnshaw  ---
The gcc developers do not use crosstool, so providing us with a config for it
is of no help.  Furthermore, un-preprocessed source means we are unlikely to be
able to reproduce the exact conditions leading up to the failure you see.

What we do need are:

1) The output of "gcc -v", showing how the compiler was actually configured.
2) *Pre-processed* source that we can feed into our own builds of the compiler
to try to reproduce the problem

[Bug fortran/68101] Provide a way to allocate arrays aligned to 32 bytes

[vladimir.fuka at gmail dot com]

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

--- Comment #2 from Vladimir Fuka  ---
Definitely similar, but the link is about failure to align to the required
alignment for that datatype. 

This feature request is about higher than required alignment for performance
reasons (SIMD vectorization).

[Bug target/68088] [6 Regression] ICE: RTL check: expected code 'reg', have 'subreg' in rhs_regno, at rtl.h:1782 @ aarch64

[jgreenhalgh at gcc dot gnu.org]

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

James Greenhalgh  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Last reconfirmed|2015-10-25 00:00:00 |2015-10-26
   Assignee|unassigned at gcc dot gnu.org  |jgreenhalgh at gcc dot 
gnu.org

--- Comment #3 from James Greenhalgh  ---
Confirmed, and mine. This looks like me trying to pull REGNO out of
"accumulator" without first checking it is a REG.

I'll take a look at a fix when I'm properly back from vacation.

[Bug fortran/67933] [5/6 Regression] ICE for array of a derived type with allocatable class in derived type object

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

Summary|[4.9/5/6 Regression] ICE|[5/6 Regression] ICE for
   |for array of a derived type |array of a derived type
   |with allocatable class in   |with allocatable class in
   |derived type object |derived type object

--- Comment #5 from Paul Thomas  ---
This is now fixed on trunk.

I will have to figure out the minimum changes to 5 branch and 4.9 branch to fix
this regression.

I'm onto it!

Paul

[Bug fortran/36192] ICE with wrong index types and bad parens

[kargl at gcc dot gnu.org]

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

--- Comment #13 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Mon Oct 26 17:39:07 2015
New Revision: 229387

URL: https://gcc.gnu.org/viewcvs?rev=229387&root=gcc&view=rev
Log:
2015-10-26  Steven G. Kargl  

PR fortran/36192
* array.c (gfc_ref_dimen_size): Check for BT_INTEGER before calling
mpz_set.


2015-10-26  Steven G. Kargl  

PR fortran/36192
* gfortran.dg/pr36192.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr36192.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/array.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/63469] Automatic reallocation of allocatable scalar length even when substring implicitly specified

[pault at gcc dot gnu.org]

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

--- Comment #3 from Paul Thomas  ---
This is now fixed on trunk and 5 branch by the patch for PR67177 and 67977. I
will see later on if they apply cleanly to 4.9 branch. If so, I will commit.

Paul

[Bug fortran/67977] allocatable strings, array section reallocated - non-standard behaviour

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #7 from Paul Thomas  ---
Fixed on trunk and 5 branch.

Many thanks for the report

Paul

[Bug fortran/67177] MOVE_ALLOC not automatically allocating deferred character arrays in derived types

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #6 from Paul Thomas  ---
Fixed on trunk and 5 branch.

Many thanks for the report

Paul

[Bug fortran/67977] allocatable strings, array section reallocated - non-standard behaviour

[pault at gcc dot gnu.org]

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

--- Comment #6 from Paul Thomas  ---
Author: pault
Date: Mon Oct 26 17:25:03 2015
New Revision: 229386

URL: https://gcc.gnu.org/viewcvs?rev=229386&root=gcc&view=rev
Log:
2015-10-26  Paul Thomas  

PR fortran/67177
PR fortran/67977
* primary.c (match_substring): Add an argument 'deferred' to
flag that a substring reference with null start and end should
not be optimized away for deferred length strings.
(match_string_constant, gfc_match_rvalue): Set the argument.
* trans-expr.c (alloc_scalar_allocatable_for_assignment): If
there is a substring reference return.
* trans-intrinsic.c (conv_intrinsic_move_alloc): For deferred
characters, assign the 'from' string length to the 'to' string
length. If the 'from' expression is deferred, set its string
length to zero. If the 'to' expression has allocatable
components, deallocate them.

2015-10-26  Paul Thomas  

PR fortran/67177
* gfortran.dg/move_alloc_15.f90: New test
* gfortran.dg/move_alloc_16.f90: New test

PR fortran/67977
* gfortran.dg/deferred_character_assignment_1.f90: New test

Added:
   
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_assignment_1.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/move_alloc_15.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/move_alloc_16.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/primary.c
branches/gcc-5-branch/gcc/fortran/trans-expr.c
branches/gcc-5-branch/gcc/fortran/trans-intrinsic.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug fortran/67177] MOVE_ALLOC not automatically allocating deferred character arrays in derived types

[pault at gcc dot gnu.org]

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

--- Comment #5 from Paul Thomas  ---
Author: pault
Date: Mon Oct 26 17:25:03 2015
New Revision: 229386

URL: https://gcc.gnu.org/viewcvs?rev=229386&root=gcc&view=rev
Log:
2015-10-26  Paul Thomas  

PR fortran/67177
PR fortran/67977
* primary.c (match_substring): Add an argument 'deferred' to
flag that a substring reference with null start and end should
not be optimized away for deferred length strings.
(match_string_constant, gfc_match_rvalue): Set the argument.
* trans-expr.c (alloc_scalar_allocatable_for_assignment): If
there is a substring reference return.
* trans-intrinsic.c (conv_intrinsic_move_alloc): For deferred
characters, assign the 'from' string length to the 'to' string
length. If the 'from' expression is deferred, set its string
length to zero. If the 'to' expression has allocatable
components, deallocate them.

2015-10-26  Paul Thomas  

PR fortran/67177
* gfortran.dg/move_alloc_15.f90: New test
* gfortran.dg/move_alloc_16.f90: New test

PR fortran/67977
* gfortran.dg/deferred_character_assignment_1.f90: New test

Added:
   
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_assignment_1.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/move_alloc_15.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/move_alloc_16.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/primary.c
branches/gcc-5-branch/gcc/fortran/trans-expr.c
branches/gcc-5-branch/gcc/fortran/trans-intrinsic.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug target/68102] [5/6 Regression] ICE: RTL check: expected code 'reg', have 'subreg' in rhs_regno, at rtl.h:1782 with float64x1_t @ aarch64

[zsojka at seznam dot cz]

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

Zdenek Sojka  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Target||aarch64-unknown-linux-gnu
  Known to work||4.9.4
   Host||x86_64-pc-linux-gnu
  Known to fail||5.2.1, 6.0

--- Comment #1 from Zdenek Sojka  ---
Forgot version:

$ xgcc -v
Using built-in specs.
COLLECT_GCC=/home/smatz/build-trunk-229293-lto-fortran-checking-yes-rtl-df-disable-bootstrap-disable-graphite-aarch64/gcc/xgcc
Target: aarch64-unknown-linux-gnu
Configured with: /mnt/svn/gcc-trunk//configure --disable-bootstrap
--enable-checking=yes,rtl,df --enable-languages=c,c++
--prefix=/mnt/svn/gcc-trunk//binary-229293-lto-fortran-checking-yes-rtl-df-disable-bootstrap-disable-graphite-aarch64/
--without-cloog --without-ppl --without-isl --host=x86_64-pc-linux-gnu
--target=aarch64-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--with-sysroot=/home/aarch64-chroot
--with-as=/usr/libexec/gcc/aarch64-unknown-linux-gnu/as
--with-ld=/usr/libexec/gcc/aarch64-unknown-linux-gnu/ld
Thread model: posix
gcc version 6.0.0 20151025 (experimental) (GCC)

[Bug target/68102] New: [5/6 Regression] ICE: RTL check: expected code 'reg', have 'subreg' in rhs_regno, at rtl.h:1782 with float64x1_t @ aarch64

[zsojka at seznam dot cz]

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

Bug ID: 68102
   Summary: [5/6 Regression] ICE: RTL check: expected code 'reg',
have 'subreg' in rhs_regno, at rtl.h:1782 with
float64x1_t @ aarch64
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---

Created attachment 36591
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36591&action=edit
reduced testcase

This might be a fallback of PR60825.

The code ICEs with:
typedef __Float64x1_t float64x1_t;
but works with:
typedef double float64x1_t;
which was the case for 4.x

The code has #include "arm_neon.h", but it can be changed to the typedef above.

RTL checking is needed to get this ICE.

Compiler output:
$ gcc -O2 testcase.c
testcase.c: In function 'foo':
testcase.c:20:1: internal compiler error: RTL check: expected code 'reg', have
'subreg' in rhs_regno, at rtl.h:1782
 }
 ^
0xa90e27 rtl_check_failed_code1(rtx_def const*, rtx_code, char const*, int,
char const*)
/mnt/svn/gcc-trunk/gcc/rtl.c:811
0x55f883 rhs_regno
/mnt/svn/gcc-trunk/gcc/rtl.h:1782
0x10571a6 rhs_regno
/mnt/svn/gcc-trunk/gcc/config/aarch64/atomics.md:510
0x10571a6 split_insns(rtx_def*, rtx_insn*)
/mnt/svn/gcc-trunk/gcc/config/aarch64/aarch64.md:1031
0x7a17b0 try_split(rtx_def*, rtx_insn*, int)
/mnt/svn/gcc-trunk/gcc/emit-rtl.c:3666
0xa4a030 split_insn
/mnt/svn/gcc-trunk/gcc/recog.c:2874
0xa5249f split_all_insns()
/mnt/svn/gcc-trunk/gcc/recog.c:2964
0xa52588 execute
/mnt/svn/gcc-trunk/gcc/recog.c:3881
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Tested revisions:
r229293 - ICE
5-branch r229292 - ICE (even at -O1)
4_9-branch r229291 - OK (it is using the other typedef)

[Bug sanitizer/68016] ASan doesn't catch overflow in globals when COPY relocation is involved.

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
(In reply to Reid Kleckner from comment #5)
> (In reply to Maxim Ostapenko from comment #4)
> > This happens because in LLVM case ASan changes symbols size ('f' in our
> > case) and just breaks ABI for the library. Relinking binary each time we
> > replace non-sanitized library with sanitized one is undesirable for large
> > package oriented systems (e.g. distributives), so we need a general solution
> > for the problem.
> 
> Can you elaborate as to why changing the size of a visible global in a
> shared lib is an ABI break with ELF? That's surprising to me, and my
> searches haven't helped me understand.

Because symbol size is part of the ABI, and LLVM emits different symbol size
between -fsanitize=address and -fno-sanitize=address.
E.g. COPY relocations use the st_size field, so you can have:
1) shared library originally not ASAN instrumented, binary (e.g. non-ASAN)
linked against it, then the shared library recompiled with ASAN - the size of
the symbol in the binary will be the one without padding, but LLVM incorrectly
registers the variable using global symbol rather than local alias and thus
assumes there is padding which is not available (plus you can get a runtime
warning on the st_size mismatch from the dynamic linker)
2) even without COPY relocations, you could have the same variable defined in
multiple shared libraries, if some of them are -fsanitize=address and the
others are not, there is mismatch between the variable sizes, and depending on
which library comes earlier in the symbol search scope, you could have either
the version without or with padding used at runtime, but the sanitized
libraries could very well register the non-padded one, making it fatal error to
access e.g. variables after it

[Bug middle-end/65962] Missed vectorization of strided stores

[wschmidt at gcc dot gnu.org]

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

--- Comment #10 from Bill Schmidt  ---
Above are the before-and-after vectorization dumps.  I haven't looked at them
in any detail myself yet.

[Bug middle-end/65962] Missed vectorization of strided stores

[wschmidt at gcc dot gnu.org]

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

--- Comment #9 from Bill Schmidt  ---
Created attachment 36590
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36590&action=edit
Vectorization dump for r229172

[Bug middle-end/65962] Missed vectorization of strided stores

[wschmidt at gcc dot gnu.org]

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

--- Comment #8 from Bill Schmidt  ---
Created attachment 36589
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36589&action=edit
Vectorization dump for r229171

[Bug libgomp/65437] acc_update_device and acc_update_self fail to initialize runtime.

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

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

--- Comment #2 from Thomas Schwinge  ---
Fixed in r229378.

[Bug libgomp/66518] FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/lib-42.c -DACC_DEVICE_TYPE_host_nonshm=1 -DACC_MEM_SHARED=0 output pattern test, is , should match \[[0-9a-fA-FxX]+,256\] is not m

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

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

--- Comment #4 from Thomas Schwinge  ---
Fixed in r229378, and r229379.

[Bug libgomp/65437] acc_update_device and acc_update_self fail to initialize runtime.

[tschwinge at gcc dot gnu.org]

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

--- Comment #1 from Thomas Schwinge  ---
Author: tschwinge
Date: Mon Oct 26 16:24:17 2015
New Revision: 229378

URL: https://gcc.gnu.org/viewcvs?rev=229378&root=gcc&view=rev
Log:
[PR libgomp/65437, libgomp/66518] Initialize runtime in acc_update_device,
acc_update_self

libgomp/
PR libgomp/65437
PR libgomp/66518
* oacc-mem.c (update_dev_host): Call goacc_lazy_initialize.
* testsuite/libgomp.oacc-c-c++-common/lib-42.c: Remove XFAIL.

Modified:
trunk/libgomp/ChangeLog
trunk/libgomp/oacc-mem.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-42.c

[Bug libgomp/66518] FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/lib-42.c -DACC_DEVICE_TYPE_host_nonshm=1 -DACC_MEM_SHARED=0 output pattern test, is , should match \[[0-9a-fA-FxX]+,256\] is not m

[tschwinge at gcc dot gnu.org]

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

--- Comment #2 from Thomas Schwinge  ---
Author: tschwinge
Date: Mon Oct 26 16:24:17 2015
New Revision: 229378

URL: https://gcc.gnu.org/viewcvs?rev=229378&root=gcc&view=rev
Log:
[PR libgomp/65437, libgomp/66518] Initialize runtime in acc_update_device,
acc_update_self

libgomp/
PR libgomp/65437
PR libgomp/66518
* oacc-mem.c (update_dev_host): Call goacc_lazy_initialize.
* testsuite/libgomp.oacc-c-c++-common/lib-42.c: Remove XFAIL.

Modified:
trunk/libgomp/ChangeLog
trunk/libgomp/oacc-mem.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-42.c

[Bug libgomp/66518] FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/lib-42.c -DACC_DEVICE_TYPE_host_nonshm=1 -DACC_MEM_SHARED=0 output pattern test, is , should match \[[0-9a-fA-FxX]+,256\] is not m

[tschwinge at gcc dot gnu.org]

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

--- Comment #3 from Thomas Schwinge  ---
Author: tschwinge
Date: Mon Oct 26 16:24:28 2015
New Revision: 229379

URL: https://gcc.gnu.org/viewcvs?rev=229379&root=gcc&view=rev
Log:
[libgomp/66518] Resolve XFAIL in libgomp.oacc-c-c++-common/lib-3.c

libgomp/
PR libgomp/66518
* testsuite/libgomp.oacc-c-c++-common/lib-3.c: Resolve XFAIL.

Modified:
trunk/libgomp/ChangeLog
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-3.c

[Bug fortran/68101] Provide a way to allocate arrays aligned to 32 bytes

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-10-26
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Similar to/duplicate of pr55916?

[Bug sanitizer/68016] ASan doesn't catch overflow in globals when COPY relocation is involved.

[rnk at google dot com]

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

Reid Kleckner  changed:

   What|Removed |Added

 CC||rnk at google dot com

--- Comment #5 from Reid Kleckner  ---
(In reply to Maxim Ostapenko from comment #4)
> This happens because in LLVM case ASan changes symbols size ('f' in our
> case) and just breaks ABI for the library. Relinking binary each time we
> replace non-sanitized library with sanitized one is undesirable for large
> package oriented systems (e.g. distributives), so we need a general solution
> for the problem.

Can you elaborate as to why changing the size of a visible global in a shared
lib is an ABI break with ELF? That's surprising to me, and my searches haven't
helped me understand.

[Bug go/68072] malformed DWARF TagVariable entry

[vogt at linux dot vnet.ibm.com]

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

--- Comment #4 from Dominik Vogt  ---
@comment 2

I can't see anything special that the file does:

-- secp256.go --
package secp256k1

/*
#cgo CFLAGS: -I./secp256k1
...
#include "./secp256k1/src/secp256k1.c"
*/
import "C"
-- END --

Then in

-- secp256k1.c --
const secp256k1_nonce_function_t secp256k1_nonce_function_rfc6979 =
nonce_function_rfc6979;
-- END --

Just this one occurence of the symbol "secp256k1_nonce_function_rfc6979".

[Bug fortran/68101] New: Provide a way to allocate arrays aligned to 32 bytes

[vladimir.fuka at gmail dot com]

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

Bug ID: 68101
   Summary: Provide a way to allocate arrays aligned to 32 bytes
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vladimir.fuka at gmail dot com
  Target Milestone: ---

This is an extension of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24261
which is claimed to be RESOLVED FIXED, but is not when `-m32` is used.

There should be a way to allocate aligned arrays independently of what malloc()
does, be it using a command-line option or a directive. It is very important
for SIMD friendly code, particularly with !$omp simd which gfortran now
supports.

With pointer arrays we can just point to a position a few bytes after the
allocated buffer, but we cannot do this with allocatable arrays. Other Fortran 
processors do have similar extensions.

According to this reference
https://software.intel.com/en-us/articles/practical-intel-avx-optimization-on-2nd-generation-intel-core-processors?language=en
:
"Similarly, to achieve best results use Intel AVX instructions on 32-byte
vectors that are 32-byte aligned."
"It is important to make every effort to align the data to 32 bytes in advance
to avoid potential performance degradation."

[Bug go/68072] malformed DWARF TagVariable entry

[vogt at linux dot vnet.ibm.com]

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

--- Comment #3 from Dominik Vogt  ---
Created attachment 36588
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36588&action=edit
Experimental fix

The attached patch fixes the problem for us by skipping DW_TAG_variable DWARF
info that only contains a DW_AT_specification (no DW_AT_type and DW_AT_name),
assuming that they are just duplicate declarations/definitions.

[Bug go/68072] malformed DWARF TagVariable entry

[ian at airs dot com]

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

--- Comment #2 from Ian Lance Taylor  ---
This is not a known bug.  I wonder what is special about this package that it
causes it to happen?  I don't see anything new in GCC related to
DW_AT_specification.

I think the place to fix in the Go sources would be cmd/cgo/gcc.go.

[Bug go/68072] malformed DWARF TagVariable entry

[vogt at linux dot vnet.ibm.com]

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

--- Comment #1 from Dominik Vogt  ---
It seems that the DWARF library is unable to handle DW_AT_specification:

-- snip --
 <1><7b4>: Abbrev Number: 27 (DW_TAG_variable)
<7b5>   DW_AT_specification: <0x8b>
<7b9>   DW_AT_decl_file   : 13
<7ba>   DW_AT_decl_line   : 77
<7bb>   DW_AT_location: 9 byte block: 3 0 0 0 0 0 0 4 80   
(DW_OP_addr: 480)


 <1><8b>: Abbrev Number: 10 (DW_TAG_variable)
<8c>   DW_AT_name: (indirect string, offset: 0x3c4):
secp256k1_nonce_function_rfc6979
<90>   DW_AT_decl_file   : 14
<91>   DW_AT_decl_line   : 104
<92>   DW_AT_type: <0x98>
<96>   DW_AT_external: 1
<97>   DW_AT_declaration : 1
-- snip --

DW_AT_name and DW_AT_type are provided by the DW_TAG_variable that the
DW_AT_specification attribute is pointing to.  Is that a known problem; ist
there already a fix?  Otherwise I can try to make a patch.

[Bug fortran/68055] ICE on using unsupported kinds in program without program statement

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #5 from Gerhard Steinmetz  
---
Sorry for answering late, but most of the time I am "offline" 
from several streams. 

Up to now I'm using mostly precompiled/configured packages from 
SUSE, currently gcc version 5.2.1 (+r228597). For several reasons,
I'm avoiding self-compiled versions, including gcc/gfortran.  
Hence my efforts are limited to black box tests and validations.

But of course I will test more on this issue with newly available
packages from software.opensuse.org as soon as possible.

Thank you very much for the continuing development and great support.

[Bug tree-optimization/68013] [6 Regression] ICE on valid code at -O2 on x86_64-linux-gnu in duplicate_thread_path, at tree-ssa-threadupdate.c:2469

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #3 from Jeffrey A. Law  ---
Fixed on trunk.

[Bug tree-optimization/68013] [6 Regression] ICE on valid code at -O2 on x86_64-linux-gnu in duplicate_thread_path, at tree-ssa-threadupdate.c:2469

[law at gcc dot gnu.org]

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

--- Comment #2 from Jeffrey A. Law  ---
Author: law
Date: Mon Oct 26 15:36:04 2015
New Revision: 229375

URL: https://gcc.gnu.org/viewcvs?rev=229375&root=gcc&view=rev
Log:
[PATCH] [PR tree-optimization/68013] Make sure first block in FSM path
is in VISITED_BBs

PR tree-optimization/68013
* tree-ssa-threadbackward.c
(fsm_find_control_statement_thread_paths): Make sure the first block
in the path is in VISITED_BBs.

PR tree-optimization/68013
* gcc.c-torture/compile/pr68013.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr68013.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-threadbackward.c

[Bug sanitizer/68100] New: runtime segfault ARM boost::regex_replace -fsanitize=undefined member access within misaligned address

[yba at tkos dot co.il]

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

Bug ID: 68100
   Summary: runtime segfault ARM boost::regex_replace
-fsanitize=undefined member access within misaligned
address
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yba at tkos dot co.il
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

Created attachment 36587
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36587&action=edit
crosstool-ng .config file for arm-mxs-linux-gnueabihf

Command line:
arm-mxs-linux-gnueabihf-g++ \
-Wall -Wextra \
-fsanitize=undefined \
-O3 \
--sysroot=${STAGING} \
-L ${STAGING}/usr/lib \
-l boost_regex \
-o main main.cpp

Code:
#include 
#include 
#include 

int main(int argc, char* argv[]) {
boost::regex two_apost_to_quote;
two_apost_to_quote.assign("( |^)(''|' ')"); // change '' or ' ' to "
std::string two_apost_to_quote_fmt = "\\1\"";

std::string input = "hi there";
printf("before: %s\n", input.c_str());
std::string output = boost::regex_replace(input, two_apost_to_quote,
two_apost_to_quote_fmt, boost::match_default | boost::format_all);
printf("after: %s\n", output.c_str());
}

Runtime execution:
before: hi there
/env/dev/filesystem/rootfs_images/mxs/sysroot/usr/include/boost/regex/v4/perl_matcher_non_recursive.hpp:188:27:
runtime error: member call on misaligned address 0x952b4cc2 for type 'struct
perl_matcher', which requires 4 byte alignment
0x952b4cc2: note: pointer points here

/env/dev/filesystem/rootfs_images/mxs/sysroot/usr/include/boost/regex/v4/perl_matcher_non_recursive.hpp:349:54:
runtime error: member access within misaligned address 0x952b4cc2 for type
'struct perl_matcher', which requires 4 byte alignment
0x952b4cc2: note: pointer points here

Segmentation fault

Comments:
1. The space in the string "input" is required

2. Boost version is boost-1.58.0, built with GCC 5.1.0 built with crosstool-ng
using attached .config

3. The problem does not happen with the same GCC 5.1.0 and boost version built
using crosstool-ng with a similar .config

4. The runtime platform is i.MX6

5. Removing the optimization from the command line prevents the segfault

[Bug tree-optimization/68013] [6 Regression] ICE on valid code at -O2 on x86_64-linux-gnu in duplicate_thread_path, at tree-ssa-threadupdate.c:2469

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-10-26
 Ever confirmed|0   |1

--- Comment #1 from Jeffrey A. Law  ---
The problem here is the first block in an FSM path may not be added to
VISITED_BBs.  That in turn results in the threader finding a path which passes
through that initial block a second time, reaching a different destination the
second time through.

This is caught by the assertion (to avoid generating incorrect code).  Fixing
is simple.  But...

I'm not real happy with how the affected code is structured, but I'm at a loss
right now how to reorganize it in the immediate term.  I'm hoping to get some
clarity as I continue to look to replace the EDGE_DFS_BACK support in the old
threader with the FSM threader.

Anyway, I'll be committing a fix shortly.

[Bug rtl-optimization/67443] [5/6 regression] DSE removes required store instruction

[rguenth at gcc dot gnu.org]

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

--- Comment #22 from Richard Biener  ---
Author: rguenth
Date: Mon Oct 26 15:24:45 2015
New Revision: 229372

URL: https://gcc.gnu.org/viewcvs?rev=229372&root=gcc&view=rev
Log:
2015-10-26  Richard Biener  
Dominik Vogt  

PR middle-end/67443
* alias.c (ao_ref_from_mem): Remove promoted subreg handling.
Properly prune ref->ref for accesses outside of ref.

* gcc.target/s390/pr67443.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.target/s390/pr67443.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/alias.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/67443] [5 regression] DSE removes required store instruction

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-10-26
  Known to work||6.0
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
Summary|[5/6 regression] DSE|[5 regression] DSE removes
   |removes required store  |required store instruction
   |instruction |
 Ever confirmed|0   |1

--- Comment #23 from Richard Biener  ---
Fixed on trunk sofar.

[Bug tree-optimization/67794] [6 regression] internal compiler error: Segmentation fault

[jamborm at gcc dot gnu.org]

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

--- Comment #9 from Martin Jambor  ---
Author: jamborm
Date: Mon Oct 26 14:36:43 2015
New Revision: 229367

URL: https://gcc.gnu.org/viewcvs?rev=229367&root=gcc&view=rev
Log:
Also remap SSA_NAMEs of PARM_DECLs in IPA-SRA

2015-10-26  Martin Jambor  

PR tree-optimization/67794
* tree-sra.c (replace_removed_params_ssa_names): Do not distinguish
between types of statements but accept original definitions as a
parameter.
(ipa_sra_modify_function_body): Use FOR_EACH_SSA_DEF_OPERAND to
iterate over definitions.

testsuite/
* gcc.dg/ipa/ipa-sra-10.c: New test.
* gcc.dg/torture/pr67794.c: Likewise.


Added:
branches/gcc-5-branch/gcc/testsuite/gcc.dg/ipa/ipa-sra-10.c
branches/gcc-5-branch/gcc/testsuite/gcc.dg/torture/pr67794.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/testsuite/ChangeLog
branches/gcc-5-branch/gcc/tree-sra.c

[Bug tree-optimization/67794] [6 regression] internal compiler error: Segmentation fault

[jamborm at gcc dot gnu.org]

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

--- Comment #8 from Martin Jambor  ---
For the record, the patch got into trunk as revision r228654, I made a
mistake in the ChangeLog tag and so it did not appear here.  I am
about to backport it to gcc 5.

[Bug fortran/67528] Wrong result with defined assignment operator and/or parenthesized expressions and allocatable components

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
> AFAICT this PR is fixed after revision r229303.

Well, this is not true with -O and above. If i compile the code with '-O0
-fsanitize=address,undefined' I get at run time

pr67528.f90:17: runtime error: load of null pointer of type 'real(kind=4)'
 Case A: v1%x =  -0.372548997

and with '-O -fsanitize=address,undefined'

pr67528.f90:17: runtime error: load of null pointer of type 'real(kind=4)'
ASAN:DEADLYSIGNAL
=
==36379==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc
0x00010c738887 bp 0x sp 0x7fff534c8130 T0)
#0 0x10c738886 in __m_MOD_copy_t_a (a.out+0x11886)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (a.out+0x11886) in __m_MOD_copy_t_a
==36379==ABORTING

Program received signal SIGABRT: Process abort signal.

Backtrace for this error:
#0  0x10d4866a4
#1  0x10d485aa5
#2  0x7fff8f8aff19
Abort

[Bug sanitizer/68099] New: arm-*-linux-gnueabihf -fsanitize=undefined warning: '' is used uninitialized in this function

[yba at tkos dot co.il]

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

Bug ID: 68099
   Summary: arm-*-linux-gnueabihf -fsanitize=undefined warning:
'' is used uninitialized in this function
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yba at tkos dot co.il
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

Created attachment 36586
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36586&action=edit
crosstool-ng .config file for arm-mxs-linux-gnueabihf

Command:
arm-mxs-linux-gnueabihf-g++ \
-Wall -Wextra \
-O3 \
--sysroot=${STAGING} \
-o test test.cpp

Code:
#include 

class Dog
{
public:

typedef void(Dog::*BarkFunction)(int);
Dog () {}

void makeNoise (int z)
{
std::cout << "Woof!" << z << std::endl;
}

void something1()
{
BarkFunction fnc = &Dog::makeNoise;
(this->*fnc)(7);
}

void something2();
};

void Dog::something2() {
BarkFunction fnc = &Dog::makeNoise;
(this->*fnc)(7);

Dog::makeNoise(7);
}

int main(int argc, char* argv[])
{
return 0;
}

Output:
dog.cpp:26:14: warning: '' is used uninitialized in this function
[-Wuninitialized]
  (this->*fnc)(7);
  ^

Comments:
1. crosstool-ng .config attached.

2. The warning cited is not emitted when the optimization -O is removed from
the command.

3. The warning cited is not emitted on x86_64 compiler built with similar
config

4. Compiler was built using crosstool-ng using the attached .config.

5. Same problem happens with GCC 5.1.0 compiled with crosstool-ng with similar
arm-*-linux-gnuabihf .config

[Bug fortran/66927] [6 Regression] ICE in gfc_conf_procedure_call

[vehre at gcc dot gnu.org]

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

--- Comment #13 from vehre at gcc dot gnu.org ---
Author: vehre
Date: Mon Oct 26 13:03:22 2015
New Revision: 229353

URL: https://gcc.gnu.org/viewcvs?rev=229353&root=gcc&view=rev
Log:
gcc/fortran/ChangeLog:

2015-10-26  Andre Vehreschild  

PR fortran/66927
* trans-array.c (evaluate_bound): For deferred length arrays get the
bounds directly from the descriptor, i.e., prevent using constant
zero lower bound from the gfc_conv_array_lbound () routine.
(gfc_conv_section_startstride): Hand deferred array status to
evaluate_bound ().
(gfc_conv_expr_descriptor): Same.



Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-array.c

[Bug target/65251] sh4: internal compiler error: Bus error when compiling cpp-netlib

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #4 from John Paul Adrian Glaubitz  ---
(In reply to Oleg Endo from comment #3)
> Adrian, any updates on this issue?

One of the buildds is currently building a fresh gcc-5 snapshot. We'll just
have to wait another 2 days, then I'll report back. Same goes for PR
target/66312.

Adrian

[Bug target/66312] [SH] Regression: Bootstrap failure gcc/d/ctfeexpr.dmd.o differs with gcc-4.8/4.9

[olegendo at gcc dot gnu.org]

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

--- Comment #22 from Oleg Endo  ---
Adrian, any updates on this issue?

[Bug target/65251] sh4: internal compiler error: Bus error when compiling cpp-netlib

[olegendo at gcc dot gnu.org]

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

--- Comment #3 from Oleg Endo  ---
Adrian, any updates on this issue?

[Bug target/66609] [sh] Relative address expressions bind at as-time, even if symbol is weak

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

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

--- Comment #10 from Oleg Endo  ---
I think we can close this as fixed.

[Bug middle-end/68067] [4.9/5/6 Regression] Wrong constant folding

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Ok, so we transform a - (b - c) to (c - b) + a, that's invalid of course.  This
also started with GCC 4.3.0.

negate_expr_p has

case MINUS_EXPR:
  /* We can't turn -(A-B) into B-A when we honor signed zeros.  */
  return !HONOR_SIGN_DEPENDENT_ROUNDING (element_mode (type))
 && !HONOR_SIGNED_ZEROS (element_mode (type))
 && reorder_operands_p (TREE_OPERAND (t, 0),
TREE_OPERAND (t, 1));

and fold_binary:

  /* A - B -> A + (-B) if B is easily negatable.  */
  if (negate_expr_p (arg1)
  && !TYPE_OVERFLOW_SANITIZED (type)
  && ((FLOAT_TYPE_P (type)
   /* Avoid this transformation if B is a positive REAL_CST.  */
   && (TREE_CODE (arg1) != REAL_CST
   ||  REAL_VALUE_NEGATIVE (TREE_REAL_CST (arg1
  || INTEGRAL_TYPE_P (type)))
return fold_build2_loc (loc, PLUS_EXPR, type,
fold_convert_loc (loc, type, arg0),
fold_convert_loc (loc, type,
  negate_expr (arg1)));

we can see "!TYPE_OVERFLOW_SANITIZED" here, a clear sign that sth is wrong.

I think the PLUS_EXPR case of negate_expr_p has the same issue
A + B negated as -B - A or -A - B as as if A == INT_MIN and B == 0 we
again get -0 - INT_MIN instead of INT_MIN + 0.

Testcase:

int main(void)
{
  int a = -1;
  static int b = -2147483647 - 1;
  static int c = 0;
  int t = a - (b + c*-2);
  if (t != 2147483647) { __builtin_abort(); }
  return 0;
}

[Bug target/67716] [5] [SH]: Miscompiles libraw: Assembler: unaligned opcodes detected in executable segment

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

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

--- Comment #22 from Oleg Endo  ---
I think we can close this as fixed.

[Bug go/67968] go1: internal compiler error: in write_specific_type_functions, at go/gofrontend/types.cc:1812

[vogt at linux dot vnet.ibm.com]

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

--- Comment #10 from Dominik Vogt  ---
We cannot reproduce the crash on x86_64.

[Bug tree-optimization/68083] [6 Regression] wrong code at -O3 on x86_64-linux-gnu

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

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

[Bug middle-end/65962] Missed vectorization of strided stores

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
(In reply to Bill Schmidt from comment #6)
> This commit (r229172) caused a vectorization failure for POWER:
> 
> FAIL: gcc.dg/vect/vect-62.c -flto -ffat-lto-objects  scan-tree-dump-times
> vect "vectorized 1 loops" 1
> FAIL: gcc.dg/vect/vect-62.c scan-tree-dump-times vect "vectorized 1 loops" 1
> 
> Seems like an odd result, but that's what the bisection shows...

Huh.  Can you please attach vectorizer dumps before/after?

[Bug middle-end/68067] [4.9/5/6 Regression] Wrong constant folding

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
  Component|tree-optimization   |middle-end
  Known to work||4.2.4
Version|trans-mem   |6.0
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
  Known to fail||4.3.0, 5.2.0

--- Comment #6 from Richard Biener  ---
Ok, I'll investigate further (the rev. in question just exposes the issue).

[Bug target/13423] sh-elf: V4SFmode passed in integer registers

[olegendo at gcc dot gnu.org]

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

--- Comment #7 from Oleg Endo  ---
See also PR 68091

[Bug tree-optimization/68083] [6 Regression] wrong code at -O3 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-26
  Known to work||5.2.0
   Target Milestone|--- |6.0
Summary|wrong code at -O3 on|[6 Regression] wrong code
   |x86_64-linux-gnu|at -O3 on x86_64-linux-gnu
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug c/68090] VLA compound literal -- "confused by earlier errors, bailing out"

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-26
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

--- Comment #3 from Marek Polacek  ---
Confirmed.  I'll have a look, but likely not this week.

[Bug target/68091] [6 Regression] [SH] internal compiler error: in expand_vec_cond_expr, at optabs.c:5391

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug c++/68094] Compiler segmentation fault

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
Please attach preprocessed source for the testcase and the output of appending
-v to the compiler-command.

See https://gcc.gnu.org/bugs.html

[Bug c++/68094] Compiler segmentation fault

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-10-26
 Ever confirmed|0   |1

[Bug c++/68096] internal compiler error: Segmentation fault(program cc1plus)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-linux-gnu
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-10-26
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Please report this with Ubuntu, I hardly beleive this is a FSF GCC issue. 
Please also always attach a preprocessed testcase, even if it is trivial.

[Bug tree-optimization/68097] We should track ranges for floating-point values too

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-26
 CC||rguenth at gcc dot gnu.org
Version|unknown |6.0
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
Confirmed.

Note the main part will be to make the FP "range info" available on SSA names.

Other useful queries would include "cannot be Inf/NaN/signed zero".

Note that transforms based on this (and also nonnegative!) need to be careful
as there are no data dependences on conditions.  Thus with

  if (x > 0.)
   foo (x);

we may not optimize foo based on 'nonnegative' as code motion has no barrier
that prevents it from hoisting it before the if.

Yes, vectors could also be handled (and yes, please one "value range" per
SSA name only).  Likewise complex (integer) types.

[Bug target/68091] [6 Regression] [SH] internal compiler error: in expand_vec_cond_expr, at optabs.c:5391

[kkojima at gcc dot gnu.org]

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

--- Comment #3 from Kazumoto Kojima  ---
Author: kkojima
Date: Mon Oct 26 11:30:11 2015
New Revision: 229336

URL: https://gcc.gnu.org/viewcvs?rev=229336&root=gcc&view=rev
Log:
[config/sh/sh.c] Fix PR68091: Return false for non shmedia targets in
sh_vector_mode_supported_p

PR target/68091
* config/sh/sh.c (sh_vector_mode_supported_p): Use
TARGET_SHMEDIA_FPU instead of TARGET_FPU_ANY.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/sh.c

[Bug sanitizer/68016] ASan doesn't catch overflow in globals when COPY relocation is involved.

[chefmax at gcc dot gnu.org]

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

--- Comment #4 from Maxim Ostapenko  ---
Actualy, LLVM is not better here (perhaps even worse). Consider the following
testcase (it's the same Jakub provided in PR63888):

max@max:/tmp$ cat libfoo.c

long f = 4;
long foo (long *p) {
  return *p;
}

max@max:/tmp$ cat libbar.c

long h = 12;
long i = 13;

max@max:/tmp$ cat main.c

extern void abort (void);
extern long f;
extern long h;
extern long i;
long foo (long *);

int main () {
  if (foo (&f) != 4 || foo (&h) != 12 || foo (&i) != 13)
abort ();
  return 0;
}


max@max:/tmp$ clang libfoo.c -shared -fpic -o libfoo.so -g
max@max:/tmp$ clang libbar.c -shared -fpic -o libbar.so -g
max@max:/tmp$ clang main.c -c -o main.o -g
max@max:/tmp$ clang  main.o ./libfoo.so ./libbar.so -o main -fsanitize=address
max@max:/tmp$ ./main
max@max:/tmp$ echo $?
0
max@max:/tmp$ clang libfoo.c -shared -fpic -o libfoo.so -g -fsanitize=address
max@max:/tmp$ ./main
./main: Symbol `f' has different size in shared object, consider re-linking
=
==19089==ERROR: AddressSanitizer: global-buffer-overflow on address
0x0070fb10 at pc 0x7f0e0b65c931 bp 0x7ffc67828000 sp 0x7ffc67827ff8
READ of size 8 at 0x0070fb10 thread T0
#0 0x7f0e0b65c930 in foo /tmp/libfoo.c:2:29
#1 0x4e166f in main /tmp/main.c:9:42
#2 0x7f0e0a570ec4 in __libc_start_main
/build/buildd/eglibc-2.19/csu/libc-start.c:287
#3 0x418fd5 in _start (/tmp/main+0x418fd5)

0x0070fb10 is located 0 bytes to the right of global variable 'f' defined
in 'libfoo.c:1:6' (0x70fb08) of size 8
SUMMARY: AddressSanitizer: global-buffer-overflow /tmp/libfoo.c:2:29 in foo
Shadow bytes around the buggy address:
  0x800d9f10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x800d9f20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x800d9f30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x800d9f40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x800d9f50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x800d9f60: 00 00[f9]f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00
  0x800d9f70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x800d9f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x800d9f90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x800d9fa0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x800d9fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:   fa
  Heap right redzone:  fb
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack partial redzone:   f4
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
  Left alloca redzone: ca
  Right alloca redzone:cb
==19089==ABORTING 

This happens because in LLVM case ASan changes symbols size ('f' in our case)
and just breaks ABI for the library. Relinking binary each time we replace
non-sanitized library with sanitized one is undesirable for large package
oriented systems (e.g. distributives), so we need a general solution for the
problem.

[Bug middle-end/65947] Vectorizer misses conditional assignment of constant

[alan.hayward at arm dot com]

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

--- Comment #7 from Alan Hayward  ---
(In reply to Andreas Schwab from comment #6)
> FAIL: gcc.dg/vect/pr65947-1.c (internal compiler error)
> FAIL: gcc.dg/vect/pr65947-1.c (test for excess errors)
> Excess errors:
> /opt/gcc/gcc-20151024/gcc/testsuite/gcc.dg/vect/pr65947-1.c:10:1: error:
> bogus comparison result type
> vector(4) signed int
> _35 = _44 == _34;
> /opt/gcc/gcc-20151024/gcc/testsuite/gcc.dg/vect/pr65947-1.c:10:1: error: the
> first argument of a VEC_COND_EXPR must be of a boolean vector type of the
> same number of elements as the result
> vector(4) int
> vector(4) signed int
> _36 = VEC_COND_EXPR <_35, vect_last_1.9_31, _32>;
> /opt/gcc/gcc-20151024/gcc/testsuite/gcc.dg/vect/pr65947-1.c:10:1: internal
> compiler error: verify_gimple failed
> 0xb27adf verify_gimple_in_cfg(function*, bool)
> ../../gcc/tree-cfg.c:5093
> 0xa1d47f execute_function_todo
> ../../gcc/passes.c:1968
> 0xa1df1f execute_todo
> ../../gcc/passes.c:2025

VEC_COND_EXPR's have been changed to use boolean vectors for arg1. I'll submit
a small patch ASAP,

[Bug tree-optimization/68097] We should track ranges for floating-point values too

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  ---
If we are generalizing VRP, how about vectors? A single interval per vector
would be enough for most of the benefit.