[Bug target/63908] [e500v2] "float_bessel"case failed on e500v2 platforms

[leimaohui at cn dot fujitsu.com]

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

leimaohui  changed:

   What|Removed |Added

 Target||e500v2

--- Comment #7 from leimaohui  ---
(In reply to leimaohui from comment #6)
> Created attachment 34294 [details]
> the patch backport to gcc 4.9.1

I tried to backport these patches to gcc4.9.1(about the packport,please see the
attachments).
But build error appeared as following.
-
powerpc-poky-linux-gnuspe-gcc  -m32 -mcpu=8548 -mabi=spe -mspe
-mfloat-gprs=double
--sysroot=/poky-build-powerpc-p1020-gcc-4.9.1/tmp/sysroots/ubinux-p1020rdb -O2
-pipe -g -feliminate-unused-debug-types -fstack-protector-all
-D_FORTIFY_SOURCE=2 -O2  -O2 -pipe -g -feliminate-unused-debug-types
-fstack-protector-all -D_FORTIFY_SOURCE=2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE
 -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include   -fPIC -mlong-double-128
-mno-minimal-toc -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector
-Dinhibit_libc  -fPIC -mlong-double-128 -mno-minimal-toc -I. -I.
-I/poky-build-powerpc-p1020-gcc-4.9.1/tmp/work/ppce500v2-poky-linux-gnuspe/libgcc-initial/4.9.1-r0/gcc-4.9.1/build.powerpc-poky-linux-gnuspe.powerpc-poky-linux-gnuspe/powerpc-poky-linux-gnuspe/libgcc/../.././gcc
-I/poky-build-powerpc-p1020-gcc-4.9.1/tmp/work-shared/gcc-4.9.1-r0/gcc-4.9.1/libgcc
-I/poky-build-powerpc-p1020-gcc-4.9.1/tmp/work-shared/gcc-4.9.1-r0/gcc-4.9.1/libgcc/.
-I/poky-build-powerpc-p1020-gcc-4.9.1/tmp/work-shared/gcc-4.9.1-r0/gcc-4.9.1/libgcc/../gcc
-I/poky-build-powerpc-p1020-gcc-4.9.1/tmp/work-shared/gcc-4.9.1-r0/gcc-4.9.1/libgcc/../include
 -DHAVE_CC_TLS  -o _addvdi3.o -MT _addvdi3.o -MD -MP -MF _addvdi3.dep
-DL_addvdi3 -c
/poky-build-powerpc-p1020-gcc-4.9.1/tmp/work-shared/gcc-4.9.1-r0/gcc-4.9.1/libgcc/libgcc2.c
-fvisibility=hidden -DHIDE_EXPORTS
/poky-build-powerpc-p1020-gcc-4.9.1/tmp/work-shared/gcc-4.9.1-r0/gcc-4.9.1/libgcc/unwind-dw2.c:
In function 'uw_init_context_1':
/poky-build-powerpc-p1020-gcc-4.9.1/tmp/work-shared/gcc-4.9.1-r0/gcc-4.9.1/libgcc/unwind-dw2.c:1593:1:
internal compiler error: Segmentation fault
 }
 ^
-
I don't know if there is more work I have to do.

Can you give me some suggestions?

[Bug target/63908] [e500v2] "float_bessel"case failed on e500v2 platforms

[leimaohui at cn dot fujitsu.com]

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

--- Comment #6 from leimaohui  ---
Created attachment 34294
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34294&action=edit
the patch backport to gcc 4.9.1

[Bug sanitizer/64336] New: Template functions are not instrumented at -O0 and -Og

[bernd.edlinger at hotmail dot de]

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

Bug ID: 64336
   Summary: Template functions are not instrumented at -O0 and -Og
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bernd.edlinger at hotmail dot de
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

I noticed that all template functions/classes do not emit any
tsan warnings at -O0 and -Og, only for -O1/-O2/-O3.

That happens because these are not insrumented at all.


cat test.cpp
#include 

template 
void
foo (x &val)
{
  val++;
}

int v;

void *
tf (void *)
{
  foo (v);
  return NULL;
}

int
main ()
{
  pthread_t th;
  if (pthread_create (&th, NULL, tf, NULL))
return 0;
  foo (v);
  pthread_join (th, NULL);
  return 0;
}
//EOF

g++ -g -fsanitize=thread test.cpp

./a.out #prints nothing.

this is what is generated for foo

_Z3fooIiEvRT_:
.LFB12:
.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-8(%rbp), %rax
movl(%rax), %eax
leal1(%rax), %edx
movq-8(%rbp), %rax
movl%edx, (%rax)
nop
popq%rbp
.cfi_def_cfa 7, 8
ret
.cfi_endproc

[Bug fortran/54687] Use gcc option machinery for gfortran

[burnus at gcc dot gnu.org]

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

--- Comment #10 from Tobias Burnus  ---
Author: burnus
Date: Wed Dec 17 06:29:30 2014
New Revision: 218808

URL: https://gcc.gnu.org/viewcvs?rev=218808&root=gcc&view=rev
Log:
2014-12-17  Tobias Burnus  

PR fortran/54687
gcc/
* flag-types.h (gfc_init_local_real, gfc_fcoarray,
gfc_convert): New enums; moved from fortran/.

gcc/fortran/
* gfortran.h (gfc_option_t): Remove flags which now
have a Var().
(init_local_real, gfc_fcoarray): Moved to ../flag-types.h.
* libgfortran.h (unit_convert): Add comment.
* lang.opt (flag-convert, flag-init_real, flag-coarray):
Add Var() and Enum().
* options.c (gfc_handle_coarray_option): Remove.
(gfc_init_options, gfc_post_options, gfc_handle_option):
Update for *.opt changes.
* array.c: Update for flag-variable name changes.
* check.c: Ditto.
* match.c: Ditto.
* resolve.c: Ditto.
* simplify.c: Ditto.
* trans-array.c: Ditto.
* trans-decl.c: Ditto.
* trans-expr.c: Ditto.
* trans-intrinsic.c: Ditto.
* trans-stmt.c: Ditto.
* trans-types.c: Ditto.
* trans.c: Ditto.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/flag-types.h
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/array.c
trunk/gcc/fortran/check.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/lang.opt
trunk/gcc/fortran/libgfortran.h
trunk/gcc/fortran/match.c
trunk/gcc/fortran/options.c
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/simplify.c
trunk/gcc/fortran/trans-array.c
trunk/gcc/fortran/trans-decl.c
trunk/gcc/fortran/trans-expr.c
trunk/gcc/fortran/trans-intrinsic.c
trunk/gcc/fortran/trans-stmt.c
trunk/gcc/fortran/trans-types.c
trunk/gcc/fortran/trans.c

[Bug rtl-optimization/64110] [5 Regression] ICE: Max. number of generated reload insns per insn is achieved (90)

[hjl.tools at gmail dot com]

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

--- Comment #10 from H.J. Lu  ---
It fails with -m32:

[hjl@gnu-6 gcc]$ /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/
/export/gnu/import/git/gcc/gcc/testsuite/gcc.target/i386/pr64110.c 
-fno-diagnostics-show-caret -fdiagnostics-color=never   -O3 -march=core-avx2 -S
 -m32  -o pr64110.s
/export/gnu/import/git/gcc/gcc/testsuite/gcc.target/i386/pr64110.c: In function
\u2018bar\u2019:
/export/gnu/import/git/gcc/gcc/testsuite/gcc.target/i386/pr64110.c:17:1:
internal compiler error: Max. number of generated reload insns per insn is
achieved (90)

0xb65d03 lra_constraints(bool)
/export/gnu/import/git/gcc/gcc/lra-constraints.c:4256
0xb52ceb lra(_IO_FILE*)
/export/gnu/import/git/gcc/gcc/lra.c:2277
0xb03357 do_reload
/export/gnu/import/git/gcc/gcc/ira.c:5402
0xb03704 execute
/export/gnu/import/git/gcc/gcc/ira.c:5573
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
[hjl@gnu-6 gcc]$

[Bug target/64331] regcprop propagates registers noted as REG_DEAD

[senthil_kumar.selvaraj at atmel dot com]

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

--- Comment #4 from Senthil Kumar Selvaraj  ---
Yes, running df_notes_add_problem and df_analyze in the target code does work.

Is it just REG_USED/REG_DEAD notes, or is register liveliness
(df_regs_ever_live_p etc..) also not guaranteed to be up to date?

[Bug c++/64335] decltype and access of a private member type

[ville.voutilainen at gmail dot com]

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

--- Comment #1 from Ville Voutilainen  ---
Pardon that, the latter example contains remnants of other experiments. Here's
a simplified version, (not that it really should matter :) )

class foo {
class bar {};
};

int main()
{
decltype (foo::bar) y;
}

This is rejected properly.

[Bug c++/64335] New: decltype and access of a private member type

[ville.voutilainen at gmail dot com]

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

Bug ID: 64335
   Summary: decltype and access of a private member type
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ville.voutilainen at gmail dot com

This compiles fine:

#include 

class foo { std::chrono::high_resolution_clock clock;};

static_assert(!decltype(foo::clock)::is_steady, "xxx");

This doesn't:

class foo {
class bar {typedef int foo;};
};

int main()
{
decltype (foo::bar) y;
}

Clang rejects both.

[Bug target/52933] SH Target: Use div0s for integer sign comparisons

[olegendo at gcc dot gnu.org]

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

--- Comment #5 from Oleg Endo  ---
Some of the original test cases are still not working.  In particular cases
where bit positions != 31 are compared/xor'ed:

bool cmp_signs_24 (int a, int b)
{
  return (a & 0x8000) ^ (b & 0x8000);
}

bool cmp_signs_25 (int a, int b)
{
  return (a & 0x8000) != (b & 0x8000);
}

bool cmp_signs_26 (short a, short b)
{
  return (a < 0) == (b < 0);
}

bool cmp_signs_27 (short a, short b)
{
  return (a < 0) != (b < 0);
}

int cmp_signs_28 (short a, short b)
{
  return (a < 0) != (b < 0) ? 40 : -10;
}

Such cases can be improved by shifting the tested bit into MSB position and
using div0s.

[Bug target/64306] [SH] Improve unaligned loads and stores

[olegendo at gcc dot gnu.org]

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

--- Comment #1 from Oleg Endo  ---
If the alignment/offset of an unaligned 32 bit store is known to be 16 bit, it
can be done with something like:
mov r5,r0
mov.w   r0,@({0|2},r4)
shlr16  r0
mov.w   r0,@({2|0},r4)

[Bug rtl-optimization/63259] Detecting byteswap sequence

[olegendo at gcc dot gnu.org]

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

--- Comment #11 from Oleg Endo  ---
(In reply to thopre01 from comment #10)
> 
> I have the same gimple and for me the bswap is correctly detected. Can you
> break at find_bswap_or_nop just after calling find_bswap_or_nop_1 on the if
> (!source_stmt) and show me the output of p/x n->n ?

n->n = 0x0102  limit = 4

For both, test_099 and test_08.

> Indeed, my mistake. Ok I tested a bit and found that the problem is the
> depth at which it's looking. Try to recompile tree-ssa-math-opts.c after
> increasing the limit number in find_bswap_or_nop. Right now the limit will
> evaluate to 4 and the gimple I have has a depth of 5.

I've tried ...

  limit += 10 + (int) ceil_log2 ((unsigned HOST_WIDE_INT) limit);

... but it doesn't change anything here.

[Bug ipa/63851] [5 Regression] ipa-icf miscompiles gfortran.dg/assumed_rank_(8|9|10).f90 at -O2 and above

[howarth at bromo dot med.uc.edu]

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

howarth at bromo dot med.uc.edu changed:

   What|Removed |Added

 CC||howarth at bromo dot med.uc.edu

--- Comment #7 from howarth at bromo dot med.uc.edu ---
(In reply to Martin Liška from comment #5)

At r218792, the proposed patch reduces the fortran test suite failures on
x86_64-apple-darwin14 to just...

FAIL: gfortran.dg/assumed_rank_10.f90   -O3 -fomit-frame-pointer -funroll-loops
 execution test
FAIL: gfortran.dg/assumed_rank_10.f90   -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  execution test

at -m32 only which appears to backtrace as...

Program aborted. Backtrace:
#0  0x5db1
#1  0x6fcf
#2  0xbcfc7
#3  0x1a8f
#4  0x1bfa

Program received signal SIGABRT, Aborted.
0x95ed369a in __pthread_kill () from /usr/lib/system/libsystem_kernel.dylib
(gdb) bt
#0  0x95ed369a in __pthread_kill () from /usr/lib/system/libsystem_kernel.dylib
#1  0x98817f19 in pthread_kill () from /usr/lib/system/libsystem_pthread.dylib
#2  0x98c72eee in abort () from /usr/lib/system/libsystem_c.dylib
#3  0x6fb0 in __gfortrani_sys_abort () at
../../../../gcc-5-20141216/libgfortran/runtime/error.c:180
#4  0x000bcfc8 in _gfortran_abort () at
../../../../gcc-5-20141216/libgfortran/intrinsics/abort.c:33
#5  0x1a90 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Does this imply that we are missing a call to 
compatible_types_p() somewhere that is exposed at -m32 for this particular test
case?

[Bug rtl-optimization/47764] The constant load instruction should be hoisted out of loop

[carrot at google dot com]

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

--- Comment #6 from Carrot  ---
Another example for ppc. 
Following code is disassembled from sha1dgst.o in openssl which is compiled by
gcc

 :
  ...
  80:   82 5a 52 3f addis   r26,r18,23170
  84:   78 9a 4a 7e xor r10,r18,r19
  88:   08 00 c4 8a lbz r22,8(r4)
  8c:   88 00 1f ea ld  r16,136(r31)
  90:   0b 00 a4 8b lbz r29,11(r4)
  94:   02 00 c4 8b lbz r30,2(r4)
  98:   99 79 5a 3b addir26,r26,31129
  ...

it uses two instructions to do (r18 + 23170 << 16 + 31129), this large constant
is used many times. In following command line sha1.gcc is disassembled from
sha1dgst.o.

$ grep 31129 sha1.gcc | wc
 20 140 881
$ grep 23170 sha1.gcc | wc
 20 140 886

If we load this large constant into a register, and use this register later, we
can save 18 instructions.

There are more such cases in the same functions:

$ grep 28378 sha1.gcc | wc
 20 140 875
$ grep "\-5215" sha1.gcc | wc
 20 140 867
$ grep "\-28900" sha1.gcc | wc
 20 140 915
$ grep "\-17188" sha1.gcc | wc
 20 140 916
$ grep "\-13725" sha1.gcc | wc
 20 140 915
$ grep "\-15914" sha1.gcc | wc
 20 140 914

More worse, these codes are inside a hot loop.

[Bug go/61265] gccgo: ICE in verify_gimple_in_seq [GoSmith]

[cmang at google dot com]

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

Chris Manghane  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-12-17
 CC||cmang at google dot com
   Assignee|ian at airs dot com|cmang at google dot com
 Ever confirmed|0   |1

--- Comment #1 from Chris Manghane  ---
This can be reproduced with a smaller program:

package main

var a = [1][0]int{B}[0]
var B = [][0]int{}[0]

func main() {}

[Bug fortran/64244] [4.8/4.9/5 Regression] ICE at class.c:236 when using non_overridable

[ondrej.certik at gmail dot com]

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

--- Comment #14 from Ondřej Čertík  ---
On Tue, Dec 16, 2014 at 4:24 PM, Ondřej Čertík  wrote:
> On Tue, Dec 16, 2014 at 1:46 PM, janus at gcc dot gnu.org
>  wrote:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64244
>>
>> --- Comment #12 from janus at gcc dot gnu.org ---
>> (In reply to Ondřej Čertík from comment #11)
>>> So my system (RHEL6) libstdc++ library might be incompatible with the
>>> trunk, but I don't see why gcc couldn't compile. Any ideas how to fix
>>> this?
>>
>> Unfortunately I have no idea. It might possibly help to use 
>> --disable-bootstrap
>> or --disable-multilib when configuring (just guessing here).
>>
>> In general, if you have trouble building GCC, you might get help from
>> gcc-h...@gcc.gnu.org (or, for Fortran-related things: fort...@gcc.gnu.org).
>>
>> Note that some people offer nightly builds of the GCC trunk, see
>> https://gcc.gnu.org/wiki/GFortranBinaries.
>
> Thanks, I might ask for help there later. In the meantime I just
> backported your patch to 4.9.2 and recompiled. I tested on our code
> base, but I realized that I also need your and Andre's patch from
> here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60255, so I am
> recompiling again.

I tested it and it seems to be working! The code compiled with
non_overridable on.

There are run-time segfaults and array bounds mismatches in our code,
that don't happen with ifort, so I will be slowly isolating those and
reporting them. They seem unrelated to the non_overridable issue, as
they also happen when I remove non_overridable.

Ondrej

[Bug c++/58650] [c++11] ICE with invalid friend declaration

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #2 from Paolo Carlini  ---
Fixed.

[Bug c++/58650] [c++11] ICE with invalid friend declaration

[paolo at gcc dot gnu.org]

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

--- Comment #1 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Tue Dec 16 23:28:31 2014
New Revision: 218801

URL: https://gcc.gnu.org/viewcvs?rev=218801&root=gcc&view=rev
Log:
/cp
2014-12-16  Paolo Carlini  

PR c++/58650
* parser.c (cp_parser_member_declaration): Fix error recovery for
initialized non-static data member declared friend.

/testsuite
2014-12-16  Paolo Carlini  

PR c++/58650
* g++.dg/parse/friend12.C: New.

Added:
trunk/gcc/testsuite/g++.dg/parse/friend12.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/64244] [4.8/4.9/5 Regression] ICE at class.c:236 when using non_overridable

[ondrej.certik at gmail dot com]

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

--- Comment #13 from Ondřej Čertík  ---
On Tue, Dec 16, 2014 at 1:46 PM, janus at gcc dot gnu.org
 wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64244
>
> --- Comment #12 from janus at gcc dot gnu.org ---
> (In reply to Ondřej Čertík from comment #11)
>> So my system (RHEL6) libstdc++ library might be incompatible with the
>> trunk, but I don't see why gcc couldn't compile. Any ideas how to fix
>> this?
>
> Unfortunately I have no idea. It might possibly help to use 
> --disable-bootstrap
> or --disable-multilib when configuring (just guessing here).
>
> In general, if you have trouble building GCC, you might get help from
> gcc-h...@gcc.gnu.org (or, for Fortran-related things: fort...@gcc.gnu.org).
>
> Note that some people offer nightly builds of the GCC trunk, see
> https://gcc.gnu.org/wiki/GFortranBinaries.

Thanks, I might ask for help there later. In the meantime I just
backported your patch to 4.9.2 and recompiled. I tested on our code
base, but I realized that I also need your and Andre's patch from
here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60255, so I am
recompiling again.

Ondrej

[Bug middle-end/64334] Common .opt handling: Support flags which take a list of values (-fopt=a,b,c ...)

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-12-16
 Ever confirmed|0   |1

--- Comment #1 from Manuel López-Ibáñez  ---
There is also -fsanitize-recover= and --help=

--help=Display descriptions of a specific class of options.  
is one or more of optimizers, target, warnings, undocumented, params

[Bug tree-optimization/64308] Missed optimization: 64-bit divide used when 32-bit divide would work

[tavianator at gmail dot com]

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

--- Comment #3 from Tavian Barnes  ---
@Richard Biener: Yes the range for _16 could be [0, 4294967294].  Why can't VRP
can't assume division by zero doesn't occur?  If it can then it could say
anything mod [a, b] fits in [0, b - 1].

That's a reasonable improvement by itself but it's not enough to optimize this
PR, because to use divl for (ret * b % m), you need (ret * b / m) to fit in [0,
4294967295] as well.  And to know that that, as Marc Glisse suggests, you'd
need symbolic ranges.

@Marc Glisse: Is there currently no support at all for symbolic ranges?  If you
can infer that b < m is an invariant then that's all you need.  Formally it's
something like this:

If x, y, and z are 32-bit unsigned integers, and x <= z || y <= z, then

(uint64_t)x * (uint64_t)y % z

can be computed with mull and divl because x * y / z is always <= max(x, y)
which fits in 32 bits.

[Bug middle-end/64334] New: Common .opt handling: Support flags which take a list of values (-fopt=a,b,c ...)

[burnus at gcc dot gnu.org]

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

Bug ID: 64334
   Summary: Common .opt handling: Support flags which take a list
of values (-fopt=a,b,c ...)
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: manu at gcc dot gnu.org
Blocks: 54687

Split off from PR54687.

There are some options which take a list of values – and applies bitwise OR to
the choice.

Example:
  fsanitize=
which takes "address" (SANITIZE_ADDRESS | SANITIZE_USER_ADDRESS),
"kernel-address" (SANITIZE_ADDRESS | SANITIZE_KERNEL_ADDRESS), "thread"
(SANITIZE_THREAD) etc. as argument.

Similarly, in Fortran: -ffpe-trap and -ffpe-summary which take "invalid",
"denormal" etc. or -fcheck= with "all", "bounds", ...

It would be useful it one could extend the current Enum scheme to support this.

[Bug fortran/54687] Use gcc option machinery for gfortran

[manu at gcc dot gnu.org]

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

--- Comment #9 from Manuel López-Ibáñez  ---
(In reply to Tobias Burnus from comment #8)
> I concur. I think it also would be useful to support combined options like
> Fortran's -ffpe-trap= and -fcheck= or common's -fsanitize=.

Total agreement! 

In my wildest dreams most of invoke.texi would be auto-generated from the opt
files.

Please could you open PRs for such missing features of the common machinery?

[Bug fortran/54687] Use gcc option machinery for gfortran

[burnus at gcc dot gnu.org]

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

--- Comment #8 from Tobias Burnus  ---
(In reply to Manuel López-Ibáñez from comment #5)
> > Is there still something missing?
> Note that the options machinery has ways to encode String->Enum options, so
> things like gfc_handle_coarray_option and the handling of OPT_finit_real_
> are redundant (and others).

Pending patch (awaiting ME review):
https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01377.html


> Also, my intuition tells me that any explicit handling of optimization
> options that does not use the common machinery such as:
>   if (gfc_option.flag_protect_parens == -1)
>   if (gfc_option.flag_stack_arrays == -1)

Those should be fine as they are completely handled in the FE: The
protect_parens translates into PAREN_EXPR and stack_arrays is also a choice
done by the FE.


> In the future, it would be ideal to have separate option structs for
> FE-specific options, such that not all FEs have to see all options from all
> other FEs. Although moving options from gfc_option_t to the globally
> generated option struct may seem a step backward in that respect, it is
> actually a step forward, since those separated structs should be generated
> directly from the *.opt files.

I concur. I think it also would be useful to support combined options like
Fortran's -ffpe-trap= and -fcheck= or common's -fsanitize=.

[Bug target/54089] [SH] Refactor shift patterns

[olegendo at gcc dot gnu.org]

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

--- Comment #32 from Oleg Endo  ---
Author: olegendo
Date: Tue Dec 16 21:37:42 2014
New Revision: 218795

URL: https://gcc.gnu.org/viewcvs?rev=218795&root=gcc&view=rev
Log:
gcc/testsuite/
PR target/54089
* gcc.target/sh/pr54089-1.c: Change optimization level from -O1 to -O2.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/sh/pr54089-1.c

[Bug go/61246] gccgo: ICE in do_determine_types [GoSmith]

[ian at gcc dot gnu.org]

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

--- Comment #3 from ian at gcc dot gnu.org  ---
Author: ian
Date: Tue Dec 16 21:36:53 2014
New Revision: 218794

URL: https://gcc.gnu.org/viewcvs?rev=218794&root=gcc&view=rev
Log:
PR go/61246
compiler: Switch expression comparisons should be boolean typed.

Modified:
trunk/gcc/go/gofrontend/statements.cc

[Bug target/53513] [SH] Add support for fpchg insn and improve fenv support

[olegendo at gcc dot gnu.org]

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

--- Comment #46 from Oleg Endo  ---
Author: olegendo
Date: Tue Dec 16 21:28:59 2014
New Revision: 218793

URL: https://gcc.gnu.org/viewcvs?rev=218793&root=gcc&view=rev
Log:
gcc/testsuite/
PR target/53513
* gcc.target/sh/fpchg.c: Rename to ...
* gcc.target/sh/pr53513-1.c: ... this.  Adjust test case to work for
-m4a and -m4a-single.

Added:
trunk/gcc/testsuite/gcc.target/sh/pr53513-1.c
Removed:
trunk/gcc/testsuite/gcc.target/sh/fpchg.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/63568] Missed optimization (a & ~mask) | (b & mask) = a ^ ((a ^ b) & mask)

[mpolacek at gcc dot gnu.org]

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

--- Comment #8 from Marek Polacek  ---
(In reply to Oleg Endo from comment #7)
> If you decide not to do the transform at the tree level, please change this
> to a target PR and assign it to me.

I have a patch that does the transformation on match-and-simplify.  Let's see
if it can make it in...

[Bug fortran/64244] [4.8/4.9/5 Regression] ICE at class.c:236 when using non_overridable

[janus at gcc dot gnu.org]

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

--- Comment #12 from janus at gcc dot gnu.org ---
(In reply to Ondřej Čertík from comment #11)
> So my system (RHEL6) libstdc++ library might be incompatible with the
> trunk, but I don't see why gcc couldn't compile. Any ideas how to fix
> this?

Unfortunately I have no idea. It might possibly help to use --disable-bootstrap
or --disable-multilib when configuring (just guessing here).

In general, if you have trouble building GCC, you might get help from
gcc-h...@gcc.gnu.org (or, for Fortran-related things: fort...@gcc.gnu.org).

Note that some people offer nightly builds of the GCC trunk, see
https://gcc.gnu.org/wiki/GFortranBinaries.

[Bug fortran/54687] Use gcc option machinery for gfortran

[burnus at gcc dot gnu.org]

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

--- Comment #7 from Tobias Burnus  ---
Author: burnus
Date: Tue Dec 16 20:44:45 2014
New Revision: 218792

URL: https://gcc.gnu.org/viewcvs?rev=218792&root=gcc&view=rev
Log:
2014-12-16  Tobias Burnus  

PR fortran/54687
* gfortran.h (gfc_option_t): Remove flags which now
have a Var().
* lang.opt (flag-aggressive_function_elimination,
flag-align_commons, flag-all_intrinsics,
flag-allow_leading_underscore, flag-automatic, flag-backslash,
flag-backtrace, flag-blas_matmul_limit, flag-cray_pointer,
flag-dollar_ok, flag-dump_fortran_original,
flag-dump_fortran_optimized, flag-external_blas, flag-f2c,
flag-implicit_none, flag-max_array_constructor,
flag-module_private, flag-pack_derived, flag-range_check,
flag-recursive, flag-repack_arrays, flag-sign_zero,
flag-underscoring): Add Var() and, where applicable, Enum().
* options.c (gfc_init_options, gfc_post_options,
gfc_handle_option): Update for *.opt changes.
* arith.c: Update for flag-variable name changes.
* array.c: Ditto.
* cpp.c: Ditto.
* decl.c: Ditto.
* expr.c: Ditto.
* f95-lang.c: Ditto.
* frontend-passes.c: Ditto.
* intrinsic.c: Ditto.
* io.c: Ditto.
* match.c: Ditto.
* module.c: Ditto.
* parse.c: Ditto.
* primary.c: Ditto.
* resolve.c: Ditto.
* scanner.c: Ditto.
* simplify.c: Ditto.
* symbol.c: Ditto.
* trans-array.c: Ditto.
* trans-common.c: Ditto.
* trans-decl.c: Ditto.
* trans-expr.c: Ditto.
* trans-intrinsic.c: Ditto.
* trans-openmp.c: Ditto.
* trans-types.c: Ditto.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/arith.c
trunk/gcc/fortran/array.c
trunk/gcc/fortran/cpp.c
trunk/gcc/fortran/decl.c
trunk/gcc/fortran/expr.c
trunk/gcc/fortran/f95-lang.c
trunk/gcc/fortran/frontend-passes.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/intrinsic.c
trunk/gcc/fortran/io.c
trunk/gcc/fortran/lang.opt
trunk/gcc/fortran/match.c
trunk/gcc/fortran/module.c
trunk/gcc/fortran/options.c
trunk/gcc/fortran/parse.c
trunk/gcc/fortran/primary.c
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/scanner.c
trunk/gcc/fortran/simplify.c
trunk/gcc/fortran/symbol.c
trunk/gcc/fortran/trans-array.c
trunk/gcc/fortran/trans-common.c
trunk/gcc/fortran/trans-decl.c
trunk/gcc/fortran/trans-expr.c
trunk/gcc/fortran/trans-intrinsic.c
trunk/gcc/fortran/trans-openmp.c
trunk/gcc/fortran/trans-types.c

[Bug c++/64333] New: C++14 constexpr gives wrong results when a looping constexpr function is evaluated twice

[ville.voutilainen at gmail dot com]

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

Bug ID: 64333
   Summary: C++14 constexpr gives wrong results when a looping
constexpr function is evaluated twice
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ville.voutilainen at gmail dot com
CC: jason at redhat dot com

#include 

constexpr int max(std::initializer_list ints)
{
int ret = *(ints.begin());
for (int i = 0; i < ints.size(); ++i) {
if (*(ints.begin()+i) > ret) {
ret = *(ints.begin()+i);
}
}
return ret;
}

int main()
{
constexpr int z = max({7,6,5,4,3,2,1});
constexpr int z2 = max({5,4,3,2,1});
static_assert(z == 7, "");
static_assert(z2 == 5, "");
}

z2 is 7. There's something fishy going on here. :)

[Bug middle-end/63568] Missed optimization (a & ~mask) | (b & mask) = a ^ ((a ^ b) & mask)

[olegendo at gcc dot gnu.org]

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

--- Comment #7 from Oleg Endo  ---
If you decide not to do the transform at the tree level, please change this to
a target PR and assign it to me.

[Bug bootstrap/64320] Missing config.h during findcomp.cc compilation

[townsend at astro dot wisc.edu]

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

--- Comment #1 from Rich Townsend  ---
OK, it seems that this bug comes from building with srcdir == objdir. If I
build in a separate directory, then the problem goes away.

As an aside, I hadn't realized that using srcdir == objdir is generally
discouraged (see, e.g., https://gcc.gnu.org/install/configure.html). Is this a
recent change, or have I always been doing it wrong?

[Bug testsuite/64328] addr_equal-1.c fails execution.

[belagod at gcc dot gnu.org]

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

--- Comment #3 from Tejas Belagod  ---
(In reply to Jan Hubicka from comment #2)
> Indeed, the testcase is meant to be nopic.  I will check how to test for
> that in dg.
> 
> Honza

{ dg-require-effective-target nonpic } ?

[Bug fortran/54687] Use gcc option machinery for gfortran

[burnus at gcc dot gnu.org]

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

--- Comment #6 from Tobias Burnus  ---
Missed the PR number for the commit r218790:

2014-12-16  Tobias Burnus  

PR fortran/54687
* lang.opt (fsecond-underscore, frecord-marker=8, frecord-marker=4,
frealloc-lhs, freal-8-real-16, freal-8-real-10, freal-8-real-4,
freal-4-real-16, freal-4-real-10, freal-4-real-8, fprotect-parens,
fstack-arrays, fmax-stack-var-size=, fmax-subrecord-length=,
ffrontend-optimize, ffree-line-length-, ffixed-line-length-,
finteger-4-integer-8, fdefault-real-8, fdefault-integer-8,
fdefault-double-8): Add Var() and Init().
* gfortran.h (gfc_option_t): Remove moved flags.
* options.c (gfc_init_options, gfc_handle_option): Ditto.
(gfc_post_options): Update for name change.
* decl.c (gfc_match_old_kind_spec, gfc_match_kind_spec): Handle
flag-name change.
* frontend-passes.c (gfc_run_passes): Ditto.
* module.c (use_iso_fortran_env_module): Ditto.
* primary.c (match_integer_constant, match_real_constant): Ditto.
* resolve.c (resolve_ordinary_assign): Ditto.
* scanner.c (gfc_next_char_literal, load_line): Ditto.
* trans-array.c (gfc_trans_allocate_array_storage,
gfc_conv_resolve_dependencies, gfc_trans_auto_array_allocation,
gfc_conv_ss_startstride): Ditto.
* trans-common.c (gfc_sym_mangled_common_id): Ditto.
* trans-decl.c (gfc_sym_mangled_function_id,
create_main_function): Ditto.
* trans-expr.c (gfc_conv_expr_op, gfc_conv_procedure_call,
arrayfunc_assign_needs_temporary, gfc_trans_arrayfunc_assign,
gfc_trans_assignment_1): Ditto.
* trans-stmt.c (gfc_trans_allocate): Ditto.
* trans-types.c (gfc_init_kinds): Ditto.

[Bug target/61296] Excessive alignment in ix86_data_alignment

[hjl.tools at gmail dot com]

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

--- Comment #15 from H.J. Lu  ---
(In reply to Jakub Jelinek from comment #13)
> Read the sources?  It really depends on many factors.

There are

  int max_align_compat
= optimize_size ? BITS_PER_WORD : MIN (256, MAX_OFILE_ALIGNMENT);

With -Os, we aren't compatible with the older GCC anyway.

[Bug go/61264] gccgo: ICE in __normal_iterator [GoSmith]

[ian at gcc dot gnu.org]

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

--- Comment #2 from ian at gcc dot gnu.org  ---
Author: ian
Date: Tue Dec 16 19:14:54 2014
New Revision: 218789

URL: https://gcc.gnu.org/viewcvs?rev=218789&root=gcc&view=rev
Log:
PR go/61264
compiler: Fix copying behavior for empty composite literals.

Modified:
trunk/gcc/go/gofrontend/expressions.cc

[Bug testsuite/64328] addr_equal-1.c fails execution.

[hubicka at ucw dot cz]

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

--- Comment #2 from Jan Hubicka  ---
Indeed, the testcase is meant to be nopic.  I will check how to test for that
in dg.

Honza

[Bug go/61273] gccgo: ICE in Unsafe_type_conversion_expression::do_get_backend [GoSmith]

[ian at gcc dot gnu.org]

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

--- Comment #1 from ian at gcc dot gnu.org  ---
Author: ian
Date: Tue Dec 16 18:53:46 2014
New Revision: 218788

URL: https://gcc.gnu.org/viewcvs?rev=218788&root=gcc&view=rev
Log:
PR go/61273
compiler: Send statements should contextually permit composite literals.

Modified:
trunk/gcc/go/gofrontend/parse.cc
trunk/gcc/go/gofrontend/parse.h

[Bug middle-end/64309] if (1 & (1 << n)) not simplified to if (n == 0)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #15 from Marek Polacek  ---
Fixed, up to some point.

[Bug middle-end/64313] [5 Regression] gcc.dg/torture/builtin-explog-1.c fails on bare-metal targets

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #4 from Eric Botcazou  ---
This very likely affects all newlib targets.

[Bug go/61264] gccgo: ICE in __normal_iterator [GoSmith]

[cmang at google dot com]

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

Chris Manghane  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-12-16
 CC||cmang at google dot com
   Assignee|ian at airs dot com|cmang at google dot com
 Ever confirmed|0   |1

--- Comment #1 from Chris Manghane  ---
This can be reproduced with

package main
func main() {
struct{ f int }{}.f++
}

which isn't a valid program although it is a minimal case of the provided
reproducer.

Another (valid) way to produce this would be

package main
func main() {
map[int]int{}[0]++
}

[Bug middle-end/64309] if (1 & (1 << n)) not simplified to if (n == 0)

[mpolacek at gcc dot gnu.org]

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

--- Comment #14 from Marek Polacek  ---
Author: mpolacek
Date: Tue Dec 16 18:29:01 2014
New Revision: 218787

URL: https://gcc.gnu.org/viewcvs?rev=218787&root=gcc&view=rev
Log:
PR middle-end/64309
* match.pd: Add ((1 << A) & 1) != 0 -> A == 0 and
((1 << A) & 1) == 0 -> A != 0.

* gcc.dg/pr64309.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr64309.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/match.pd
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/64330] [5 Regression] IPA-ICF merges const exported vars that could be addressable in other TUs

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
(In reply to Kostya Serebryany from comment #4)
> So, maybe the ODR checker in the current form is not that useless.
> Sorry, couldn't resist :)

But it isn't really an ODR checker.  Here it complains if two different symbols
share the same storage.  Which is fine if they aren't address taken and can't
be address taken elsewhere.

[Bug tree-optimization/64330] [5 Regression] IPA-ICF merges const exported vars that could be addressable in other TUs

[kcc at gcc dot gnu.org]

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

--- Comment #4 from Kostya Serebryany  ---
So, maybe the ODR checker in the current form is not that useless.
Sorry, couldn't resist :)

[Bug go/61316] gccgo: spurious "incompatible types in assignment" error [GoSmith]

[cmang at google dot com]

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

Chris Manghane  changed:

   What|Removed |Added

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

--- Comment #2 from Chris Manghane  ---
Fixed.

[Bug go/61322] gccgo: spurious "incompatible type for field 2 in struct construction" error [GoSmith]

[cmang at google dot com]

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

Chris Manghane  changed:

   What|Removed |Added

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

--- Comment #2 from Chris Manghane  ---
(In reply to Chris Manghane from comment #1)
> I'm unable to reproduce this on gcc version 5.0.0 20141210 (experimental)
> (GCC).

[Bug ipa/63851] [5 Regression] ipa-icf miscompiles gfortran.dg/assumed_rank_(8|9|10).f90 at -O2 and above

[dominiq at lps dot ens.fr]

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

--- Comment #6 from Dominique d'Humieres  ---
> Yes, IPA ICF should respect 'restrict' attribute.
> May I ask you to rerun test suite with applied:

My machine is busy regtesting 4.8.4, but a quick test shows that your patch
indeed fixes this PR. More testing tonight. Thanks for the fix.

[Bug c/64332] wrong location for Wattributes warning

[manu at gcc dot gnu.org]

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

--- Comment #6 from Manuel López-Ibáñez  ---
(In reply to Azat from comment #5)
> > Whether the correct behavior is that the system_header applies to the
> > definition or to the expansion location, I am not sure. However, the bad
> > location of the C FE is clearly a bug.
> 
> Maybe gcc will behave like clang in this case?

How does Clang behave? For example, what happens when you don't use
system_header in your testcase? and when you use it, but also add
-Wsystem-headers? What happens if the system_header #pragma is moved to c.h?
Trying to guess a correct behavior from a single testcase is quite hard. Clang
may "work" in this case, but may "fail" in another case..

My intuition is that whether the warning is printed or not depends on the way
the macro unwinder works. We have an open bug about that already PR55252, but
no one has tried to change it yet.

[Bug middle-end/64313] [5 Regression] gcc.dg/torture/builtin-explog-1.c fails on bare-metal targets

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com  ---
In the case of expf, if it's used or known to be available in a linked 
library then it can be assumed to have the required semantics (since it's 
reserved by ISO C90).  If it's used it can also be assumed to be available 
(if not used, its availability depends on targetm.libc_has_function).

In the case of exp10, a function exp10 can only be assumed to have the 
required semantics if either (a) -std=gnu* is used, so exp10 (not just 
__builtin_exp10) is built in, or (b) exp10 is declared in system headers 
(e.g. -std=c99 -D_GNU_SOURCE).  Availability can be assumed if, in 
addition to the conditions for the semantics, (a) it is used or (b) 
targetm.libc_has_function says it's available (well, except that there is 
no relevant enum function_class value for exp10).

(log10 is standard C90.  exp10 would be defined by draft TS 18661-4 to be 
available if __STDC_WANT_IEC_60559_FUNCS_EXT__.)

[Bug c/61280] GCC 4.8.2 suppresses -Wsign-compare caused by macro defined in system header

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||manu at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #1 from Manuel López-Ibáñez  ---
This seems fixed in GCC 5.0 since now the preprocessed output tracks the
system-header bit within macros:

# 1 "test.c"
# 1 ""
# 1 ""
# 1 "test.c"
# 1 "test.h" 1

# 2 "test.h" 3
# 2 "test.c" 2
int foo(int i, unsigned j) { return 
# 2 "test.c" 3
   ((
# 2 "test.c"
   i
# 2 "test.c" 3
   ) < (
# 2 "test.c"
   j
# 2 "test.c" 3
   ))
# 2 "test.c"
 ; }

[Bug sanitizer/61591] Undefined behavior sanitizer does not catch builtin_unreachable's from impossible devirtualization

[jamborm at gcc dot gnu.org]

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

--- Comment #10 from Martin Jambor  ---
Honza, given what you wrote in

https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01033.html

do you want to take over this bug?

[Bug ipa/63851] [5 Regression] ipa-icf miscompiles gfortran.dg/assumed_rank_(8|9|10).f90 at -O2 and above

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
Yes, IPA ICF should respect 'restrict' attribute.
May I ask you to rerun test suite with applied:

diff --git a/gcc/ipa-icf-gimple.c b/gcc/ipa-icf-gimple.c
index ec0290a..98f38ee 100644
--- a/gcc/ipa-icf-gimple.c
+++ b/gcc/ipa-icf-gimple.c
@@ -185,6 +185,9 @@ bool func_checker::compatible_types_p (tree t1, tree t2,
   if (TREE_CODE (t1) != TREE_CODE (t2))
 return return_false_with_msg ("different tree types");

+  if (TYPE_RESTRICT (t1) != TYPE_RESTRICT (t2))
+return return_false_with_msg ("restrict flags are different");
+
   if (!types_compatible_p (t1, t2))
 return return_false_with_msg ("types are not compatible");

Thanks,
Martin

[Bug fortran/64244] [4.8/4.9/5 Regression] ICE at class.c:236 when using non_overridable

[ondrej.certik at gmail dot com]

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

--- Comment #11 from Ondřej Čertík  ---
On Tue, Dec 16, 2014 at 9:47 AM, janus at gcc dot gnu.org
 wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64244
>
> --- Comment #10 from janus at gcc dot gnu.org ---
> (In reply to Ondřej Čertík from comment #9)
>> Janus, thanks a lot for fixing this!
>
> You're welcome!
>
>
>> Yes, it's part of a large code base. I'll try the trunk soon.
>
> That would be great. Since this bug is a regression, I plan to backport the 
> fix
> to the 4.8 and 4.9 branches. But before that it would be good to make sure 
> that
> no further problems appear. I think the NON_OVERRIDABLE attribute is not
> incredibly well-tested at this point.

I can compile 4.9.2 from source without problems, but when I follow
the same procedure with the latest trunk (I used:
https://github.com/gcc-mirror/gcc), I get:

https://gist.github.com/certik/bbb96383e540efc8d6a3

And the part of config.log says:

https://gist.github.com/certik/a308dbc6a26d12888ee6

i.e. the relevant error seems to be:

/usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.15' not found

So my system (RHEL6) libstdc++ library might be incompatible with the
trunk, but I don't see why gcc couldn't compile. Any ideas how to fix
this?

[Bug c/64332] wrong location for Wattributes warning

[a3at.mail at gmail dot com]

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

--- Comment #5 from Azat  ---
On Tue, Dec 16, 2014 at 05:16:41PM +, manu at gcc dot gnu.org wrote:
> The C FE does not point to __constructor (3:1 vs 3:19), thus it doesn't 
> realize
> this comes from a macro expansion, thus (in your testcase) the system_header 
> is
> applied. The C++ FE sees that the attribute actually appears in 1:50 and not
> 3:19, thus in your testcase the pragma system_header does not apply.

Hm.. good to know, thanks for pointing me out!

> Whether the correct behavior is that the system_header applies to the
> definition or to the expansion location, I am not sure. However, the bad
> location of the C FE is clearly a bug.

Maybe gcc will behave like clang in this case?

[Bug c/64332] wrong location for Wattributes warning

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-12-16
 CC||manu at gcc dot gnu.org
  Component|c++ |c
Summary|gcc/g++ handles |wrong location for
   |system_header differently   |Wattributes warning
 Ever confirmed|0   |1

--- Comment #4 from Manuel López-Ibáñez  ---
The difference that you see is because of macro expansion and bad location info
in the C FE. This testcase makes it clear:

$ cat test.c
#define __constructor __attribute__((constructor))
typedef void (*__cb_type)(void *);
int foo(__cb_type __constructor);

$ cc1 -Wattributes test.c
test.c:3:1: warning: ‘constructor’ attribute ignored [-Wattributes]
 int foo(__cb_type __constructor);
 ^
$ cc1plus -Wattributes test.c
test.c:1:50: warning: ‘constructor’ attribute ignored [-Wattributes]
 #define __constructor __attribute__((constructor))
  ^
test.c:3:19: note: in expansion of macro ‘__constructor’
 int foo(__cb_type __constructor);
   ^

The C FE does not point to __constructor (3:1 vs 3:19), thus it doesn't realize
this comes from a macro expansion, thus (in your testcase) the system_header is
applied. The C++ FE sees that the attribute actually appears in 1:50 and not
3:19, thus in your testcase the pragma system_header does not apply.

Whether the correct behavior is that the system_header applies to the
definition or to the expansion location, I am not sure. However, the bad
location of the C FE is clearly a bug.

[Bug c++/64332] gcc/g++ handles system_header differently

[a3at.mail at gmail dot com]

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

--- Comment #3 from Azat  ---
On Tue, Dec 16, 2014 at 07:50:48PM +0300, Azat Khuzhin wrote:
> > --- Comment #1 from Andrew Pinski  ---
> > I don't think it is system header which is being handled differently, 
> > rather I
> > think it is warning for attribute is being handled differently.
> 
> Maybe... I didn't check this.

I've checked this and you are right:
$ head main.c c-impl.h  # the same is in attach
==> main.c <==
#include "c-impl.h"

==> c-impl.h <==
#pragma GCC system_header

static inline int foo(int foo)
{
}

$ gcc -Wall -Wextra -Wpedantic -Wattributes -c main.c
$ g++ -Wall -Wextra -Wpedantic -Wattributes -c main.c

Now drop system_header:
$ head main.c c-impl.h 
==> main.c <==
#include "c-impl.h"

==> c-impl.h <==
static inline int foo(int foo)
{
}

$ gcc -Wall -Wextra -Wpedantic -Wattributes -c main.c
In file included from main.c:1:0:
c-impl.h: In function ‘foo’:
c-impl.h:3:1: warning: no return statement in function returning non-void
[-Wreturn-type]
 }
 ^
c-impl.h:1:27: warning: unused parameter ‘foo’ [-Wunused-parameter]
 static inline int foo(int foo)
   ^
$ g++ -Wall -Wextra -Wpedantic -Wattributes -c main.c
In file included from main.c:1:0:
c-impl.h: In function ‘int foo(int)’:
c-impl.h:3:1: warning: no return statement in function returning non-void
[-Wreturn-type]
 }
 ^
c-impl.h: At global scope:
c-impl.h:1:27: warning: unused parameter ‘foo’ [-Wunused-parameter]
 static inline int foo(int foo)
   ^

[Bug c++/62152] ICE caused by using __builtin_ia32_pause() inside C++11 noexcept functions on Windows

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

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

--- Comment #1 from Kai Tietz  ---
Duplicate

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

[Bug c++/61189] ICE with __builtin_return_address() in noexcept lambda on x86

[ktietz at gcc dot gnu.org]

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

--- Comment #4 from Kai Tietz  ---
*** Bug 62152 has been marked as a duplicate of this bug. ***

[Bug c++/64332] gcc/g++ handles system_header differently

[a3at.mail at gmail dot com]

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

--- Comment #2 from Azat  ---
On Tue, Dec 16, 2014 at 04:46:28PM +, pinskia at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64332
> 
> --- Comment #1 from Andrew Pinski  ---
> I don't think it is system header which is being handled differently, rather I
> think it is warning for attribute is being handled differently.

Maybe... I didn't check this.

[Bug c++/61189] ICE with __builtin_return_address() in noexcept lambda on x86

[lh_mouse at 126 dot com]

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

--- Comment #3 from lh_mouse  ---
Thanks Kai. It seems to be exactly the same reason that causes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62152. Maybe we should merge them?

[Bug fortran/64244] [4.8/4.9/5 Regression] ICE at class.c:236 when using non_overridable

[janus at gcc dot gnu.org]

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

--- Comment #10 from janus at gcc dot gnu.org ---
(In reply to Ondřej Čertík from comment #9)
> Janus, thanks a lot for fixing this!

You're welcome!


> Yes, it's part of a large code base. I'll try the trunk soon.

That would be great. Since this bug is a regression, I plan to backport the fix
to the 4.8 and 4.9 branches. But before that it would be good to make sure that
no further problems appear. I think the NON_OVERRIDABLE attribute is not
incredibly well-tested at this point.

[Bug c++/64332] gcc/g++ handles system_header differently

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
I don't think it is system header which is being handled differently, rather I
think it is warning for attribute is being handled differently.

[Bug fortran/64244] [4.8/4.9/5 Regression] ICE at class.c:236 when using non_overridable

[ondrej.certik at gmail dot com]

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

--- Comment #9 from Ondřej Čertík  ---
Janus, thanks a lot for fixing this! Yes, it's part of a large code base. I'll
try the trunk soon.

[Bug c++/61189] ICE with __builtin_return_address() in noexcept lambda on x86

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-12-16
 Ever confirmed|0   |1

--- Comment #2 from Kai Tietz  ---
Issue is related to the assert at line 9964 in config/i386/i386.c in
ix86_compute_frame_layout: 'gcc_assert (preferred_alignment <=
stack_alignment_needed);'.
The preferred_alignment is 16, but the stack_alignment_needed is just 4.

The preferred_alignment is by default for all x86/x64 targets always
PREFERRED_STACK_BOUNDARY_DEFAULT (means 128 bit=16 bytes).
So crtl->stack_alignment_needed is 32, and crtl->preferred_stack_boundary is
128.

A work-a-round is to use -mpreferred-stack-boundary=2 option. This prevents
that check fails.

So question is: Where stack_alignment_needed is set to something less then
preferred_stack_boundary

[Bug target/64331] regcprop propagates registers noted as REG_DEAD

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-12-16
 CC||ebotcazou at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Eric Botcazou  ---
Right, RTL passes aren't required to maintain REG_DEAD/REG_UNUSED notes, it's
the job of the DF framework.  And this is not done automatically, the consumers
of the notes must request it by means of df_note_add_problem prior to calling
the DF analyzer.

[Bug fortran/64321] -ffixed-line-length-none doesn't work

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #2 from Tobias Burnus  ---
Close as WORKSFORME.

Yes, I seemingly had a .f90 file without -ffixed-form, when testing
https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01289.html - and while busy
checking some other issues, I didn't closely inspect this patch.

I do not see a real need for a unified option.

[Bug rtl-optimization/64286] Redundant extend removal ignores vector element type

[izamyatin at gmail dot com]

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

--- Comment #1 from Igor Zamyatin  ---
Perhaps something like below to restrict ree for such cases?

diff --git a/gcc/ree.c b/gcc/ree.c
index 3376901..92370ea 100644
--- a/gcc/ree.c
+++ b/gcc/ree.c
@@ -1004,6 +1004,11 @@ add_removable_extension (const_rtx expr, rtx_insn *insn,
   struct df_link *defs, *def;
   ext_cand *cand;

+  if (!SCALAR_INT_MODE_P (GET_MODE (dest))
+  && (GET_MODE_UNIT_PRECISION (mode) !=
+  GET_MODE_UNIT_PRECISION (GET_MODE (XEXP (src, 0)
+return;
+
   /* First, make sure we can get all the reaching definitions.  */
   defs = get_defs (insn, XEXP (src, 0), NULL);
   if (!defs)

[Bug c++/64332] New: gcc/g++ handles system_header differently

[a3at.mail at gmail dot com]

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

Bug ID: 64332
   Summary: gcc/g++ handles system_header differently
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: a3at.mail at gmail dot com

Created attachment 34292
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34292&action=edit
warning-constructor-attribute-ignored.tgz

Digging through one or compilation errors, after doing this:
#define __constructor __attribute__((constructor))

I turned out that gcc/g++ have different behaviours for system_header pragma.

Here is a simple example (also archived in attach):
$ head *.[ch]
==> c.h <==
#define __constructor __attribute__((constructor))

==> c-impl.h <==
#pragma GCC system_header

typedef void (*__cb_type)(void *);
int foo(__cb_type __constructor);

==> main.c <==
#include "c.h"
#include "c-impl.h"

$ gcc -c main.c
$ gcc -Wall -Wextra -Wpedantic -Wattributes -c main.c
$ g++ -c main.c
In file included from main.c:1:0:
c.h:1:50: warning: ‘constructor’ attribute ignored [-Wattributes]
 #define __constructor __attribute__((constructor))
$ clang++-3.5 -c main.c
clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is
deprecated
$ clang-3.5 -c main.c

$ g++ --version
g++ (Debian 4.9.1-16) 4.9.1
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Is this desired behavior?

[Bug target/61296] Excessive alignment in ix86_data_alignment

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||kirill.yukhin at intel dot com

--- Comment #14 from H.J. Lu  ---
I got

[hjl@gnu-6 pr61296]$ cat a.c
struct foo
{
  char i[128];
};

struct foo x = { 1 };
[hjl@gnu-6 pr61296]$ make a.s
/export/build/gnu/gcc-misc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-misc/build-x86_64-linux/gcc/ -O3 -mavx2 -S a.c
[hjl@gnu-6 pr61296]$ cat a.s
.file"a.c"
.globlx
.data
.align 64
.typex, @object
.sizex, 128
x:
.byte1
.zero127
.ident"GCC: (GNU) 5.0.0 20141216 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-6 pr61296]$ 

Which older GCC expects 64-byte alignment here?  We should limit
DATA_ALIGNMENT to the maximum alignment actually expected by the
older GCC, which I believe is 32 byte, and have an option to limit
DATA_ALIGNMENT to MAX (ABI alignment, natural alignment).

[Bug fortran/64321] -ffixed-line-length-none doesn't work

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||janus at gcc dot gnu.org

--- Comment #1 from janus at gcc dot gnu.org ---
It actually works for me, at least when putting the test case into a .f file.
Is it possibly that your file has an f90 extension (meaning it's actually free
format)?

Would it be a bad idea to introduce a flag like -fline-length-none, which sets
the line length both for fixed and free format?

[Bug fortran/63473] Memory leak with ALLOCATABLE, INTENT(OUT) dummy arguments.

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

Summary|[4.9/5 Regression] Memory   |Memory leak with
   |leak with ALLOCATABLE,  |ALLOCATABLE, INTENT(OUT)
   |INTENT(OUT) dummy   |dummy arguments.
   |arguments.  |

--- Comment #5 from janus at gcc dot gnu.org ---
-fdump-tree-original shows the following:


if (array.data != 0B)
  {
__builtin_free ((void *) array.data);
  }
array.data = 0B;
allocate_mytype (&array);


So: Before the call to 'allocate_mytype', the array itself is being
auto-deallocated, but its components are not!

[Bug tree-optimization/64319] add alias runtime check to remove load after load redundancy

[b.grayson at samsung dot com]

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

--- Comment #2 from Brian Grayson  ---
alignd() in m88ksim from SPECint95 is a poster child for this kind of
optimization -- it receives several pointers to portions of FP representations,
and then operates on them via code like this:

...
*amantlo >>= 1;
*amantlo |= *amanthi << 31;
*amanthi >>= 1;
...

In this case, there may actually be a code-space reduction(!) with dynamic
disambiguation, because gcc has to insert so many redundant loads and stores in
the general case that are not needed in either of the two forks.

That may make a handy stand-alone real-world testcase.

[Bug fortran/63473] [4.9/5 Regression] Memory leak with ALLOCATABLE, INTENT(OUT) dummy arguments.

[janus at gcc dot gnu.org]

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

--- Comment #4 from janus at gcc dot gnu.org ---
(In reply to janus from comment #3)
> The second message (680 bytes) occurs only with 4.9 upwards (and already in
> the first loop execution).

Actually I think this is not a real regression, but rather a change in behavior
which is in line with the Fortran 2008 standard (variables in the main program
automatically get the SAVE attribute, and thus are not auto-deallocated).

One can get rid of that valgrind message, by explicitly deallocating the array
at the end of the main program, so that the test case becomes:


program testprogram
  implicit none
  type :: mytype_type
integer, allocatable :: i(:)
  end type
  integer :: n
  type(mytype_type), allocatable :: array(:)

  do n = 1, 2
print *, allocated(array)
call allocate_mytype(array)
  end do

  deallocate(array)

contains

  subroutine allocate_mytype(array)
type(mytype_type), allocatable, intent(out) :: array(:)
integer :: i
allocate(array(10))
do i = 1, 10
  allocate(array(i)%i(5))
  array(i)%i = 0
end do
  end subroutine

end


With this version, one only gets:

==31267== 200 bytes in 10 blocks are definitely lost in loss record 1 of 1
==31267==at 0x4C2ABA0: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==31267==by 0x400BC6: allocate_mytype.2336 (test.f90:23)
==31267==by 0x400EF6: MAIN__ (test.f90:11)
==31267==by 0x401008: main (test.f90:14)

[Bug fortran/63473] [4.9/5 Regression] Memory leak with ALLOCATABLE, INTENT(OUT) dummy arguments.

[janus at gcc dot gnu.org]

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

--- Comment #3 from janus at gcc dot gnu.org ---
Here is a slightly compactified test case:


program testprogram
  implicit none
  type :: mytype_type
integer, allocatable :: i(:)
  end type
  integer :: n
  type(mytype_type), allocatable :: array(:)

  do n = 1, 2
print *, allocated(array)
call allocate_mytype(array)
  end do

contains

  subroutine allocate_mytype(array)
type(mytype_type), allocatable, intent(out) :: array(:)
integer :: i
allocate(array(10))
do i = 1, 10
  allocate(array(i)%i(5))
  array(i)%i = 0
end do
  end subroutine

end


With 4.9.1, valgrind shows:


==31043== HEAP SUMMARY:
==31043== in use at exit: 880 bytes in 21 blocks
==31043==   total heap usage: 43 allocs, 22 frees, 13,201 bytes allocated
==31043== 
==31043== 200 bytes in 10 blocks are definitely lost in loss record 2 of 3
==31043==at 0x4C2ABA0: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==31043==by 0x400BC6: allocate_mytype.2336 (test.f90:21)
==31043==by 0x400EF3: MAIN__ (test.f90:11)
==31043==by 0x400F40: main (test.f90:9)
==31043== 
==31043== 680 (480 direct, 200 indirect) bytes in 1 blocks are definitely lost
in loss record 3 of 3
==31043==at 0x4C2ABA0: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==31043==by 0x4009A1: allocate_mytype.2336 (test.f90:19)
==31043==by 0x400EF3: MAIN__ (test.f90:11)
==31043==by 0x400F40: main (test.f90:9)
==31043== 
==31043== LEAK SUMMARY:
==31043==definitely lost: 680 bytes in 11 blocks
==31043==indirectly lost: 200 bytes in 10 blocks
==31043==  possibly lost: 0 bytes in 0 blocks
==31043==still reachable: 0 bytes in 0 blocks
==31043== suppressed: 0 bytes in 0 blocks


The first message (200 bytes) occurs with all gfortran versions I tried (and
only in the second loop execution).

The second message (680 bytes) occurs only with 4.9 upwards (and already in the
first loop execution).

[Bug target/64240] [5.0 Regression][AArch64] SMS-3.c causes runtime exception(segfault).

[fyang at gcc dot gnu.org]

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

--- Comment #6 from fyang at gcc dot gnu.org ---
Author: fyang
Date: Tue Dec 16 14:58:03 2014
New Revision: 218780

URL: https://gcc.gnu.org/viewcvs?rev=218780&root=gcc&view=rev
Log:
+   PR rtl-optimization/64240
+   * ddg.c (mark_mem_use): Check *iter instead of *x.

Added:
trunk/gcc/testsuite/gcc.dg/sms-12.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ddg.c
trunk/gcc/testsuite/ChangeLog

[Bug other/64278] [5 Regression] /sreal.c:254:22: error: call of overloaded 'abs(const int64_t&)' is ambiguous

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Liška  ---
Resolved.

[Bug other/64278] [5 Regression] /sreal.c:254:22: error: call of overloaded 'abs(const int64_t&)' is ambiguous

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Author: marxin
Date: Tue Dec 16 14:55:29 2014
New Revision: 218779

URL: https://gcc.gnu.org/viewcvs?rev=218779&root=gcc&view=rev
Log:
Fix for PR ipa/64278

* sreal.c (sreal::operator*): Replace std::abs with absu_hwi.


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

[Bug fortran/63473] [4.9/5 Regression] Memory leak with ALLOCATABLE, INTENT(OUT) dummy arguments.

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-12-16
 CC||janus at gcc dot gnu.org
Version|4.8.2   |4.9.1
Summary|Memory leak with|[4.9/5 Regression] Memory
   |ALLOCATABLE, INTENT(OUT)|leak with ALLOCATABLE,
   |dummy arguments.|INTENT(OUT) dummy
   ||arguments.
 Ever confirmed|0   |1

--- Comment #2 from janus at gcc dot gnu.org ---
Confirmed.

> ==13675== 800 bytes in 40 blocks are definitely lost in loss record 2 of 3
> ==13675==at 0x4A069EE: malloc (vg_replace_malloc.c:270)
> ==13675==by 0x400CF0: __testmodule_MOD_create_mytype
> (test_allocarg.f90:15)
> ==13675==by 0x400B74: __testmodule_MOD_allocate_mytype
> (test_allocarg.f90:24)
> ==13675==by 0x400E47: MAIN__ (test_allocarg.f90:40)
> ==13675==by 0x400E94: main (test_allocarg.f90:33)

This one I see with all gfortran versions I tried (4.4.7, 4.6.4, 4.7.4, 4.8.3,
4.9.1, trunk).


> ==13675== 1,360 (960 direct, 400 indirect) bytes in 1 blocks are definitely
> lost in loss record 3 of 3
> ==13675==at 0x4A069EE: malloc (vg_replace_malloc.c:270)
> ==13675==by 0x4009DA: __testmodule_MOD_allocate_mytype
> (test_allocarg.f90:22)
> ==13675==by 0x400E47: MAIN__ (test_allocarg.f90:40)
> ==13675==by 0x400E94: main (test_allocarg.f90:33)

This one only seems to occur with 4.9 and trunk, i.e. it's a regression.

[Bug testsuite/64328] addr_equal-1.c fails execution.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Component|tree-optimization   |testsuite

--- Comment #1 from Richard Biener  ---
I think they can be resolved to the same declaration and an alias to it.  Thus
the testcase should be guarded with nopic.

[Bug rtl-optimization/64291] [5 Regression] Miscompile t-div in GMP's testsuite

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*, i?86-*-*
   Priority|P3  |P1
 CC||vmakarov at gcc dot gnu.org

[Bug target/64331] regcprop propagates registers noted as REG_DEAD

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||avr
  Component|rtl-optimization|target

--- Comment #2 from Richard Biener  ---
Sounds like a target bug.

[Bug middle-end/63568] Missed optimization (a & ~mask) | (b & mask) = a ^ ((a ^ b) & mask)

[rguenther at suse dot de]

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

--- Comment #6 from rguenther at suse dot de  ---
On Tue, 16 Dec 2014, mpolacek at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63568
> 
> --- Comment #5 from Marek Polacek  ---
> True.  E.g. on my x86_64 i7 Nehalem I see (using ./cc1 -quiet -O2 qq.c -mbmi) 
> 
> andn%edi, %edx, %edi
> andl%edx, %esi
> movl%edi, %eax
> orl %esi, %eax
> ret
> 
> for return (a & ~m) | (b & m); and
> 
> xorl%edi, %esi
> movl%edi, %eax
> andl%esi, %edx
> xorl%edx, %eax
> ret
> 
> for return a ^ ((a ^ b) & m);

The former is also better for instruction level parallelism - but
that just asks for a clever enough expander / combiner that can
generate that from the latter.

I think on GIMPLE we want to canoncalize to the variant with less
(gimple) operations.  single-use restrictions may apply (with
the lack of a global unified combine / CSE phase)

[Bug middle-end/63568] Missed optimization (a & ~mask) | (b & mask) = a ^ ((a ^ b) & mask)

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
True.  E.g. on my x86_64 i7 Nehalem I see (using ./cc1 -quiet -O2 qq.c -mbmi) 

andn%edi, %edx, %edi
andl%edx, %esi
movl%edi, %eax
orl %esi, %eax
ret

for return (a & ~m) | (b & m); and

xorl%edi, %esi
movl%edi, %eax
andl%esi, %edx
xorl%edx, %eax
ret

for return a ^ ((a ^ b) & m);

[Bug tree-optimization/64330] [5 Regression] IPA-ICF merges const exported vars that could be addressable in other TUs

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-12-16
  Component|sanitizer   |tree-optimization
   Target Milestone|--- |5.0
Summary|[ASAN] Bogus|[5 Regression] IPA-ICF
   |"AddressSanitizer:  |merges const exported vars
   |odr-violation"  |that could be addressable
   ||in other TUs
 Ever confirmed|0   |1

--- Comment #3 from Jakub Jelinek  ---
sem_variable *
sem_variable::parse (varpool_node *node, bitmap_obstack *stack)
{
  tree decl = node->decl;

  bool readonly = TYPE_P (decl) ? TYPE_READONLY (decl) : TREE_READONLY (decl);
  bool can_handle = readonly && (DECL_VIRTUAL_P (decl)
 || !TREE_ADDRESSABLE (decl));

So it indeed doesn't consider the case when the variable is accessible by other
TUs where the variable could be addressable in them.

[Bug target/61296] Excessive alignment in ix86_data_alignment

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  ---
Read the sources?  It really depends on many factors.

[Bug target/61296] Excessive alignment in ix86_data_alignment

[hjl.tools at gmail dot com]

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

--- Comment #12 from H.J. Lu  ---
(In reply to Jakub Jelinek from comment #11)
> If you hit the assumption beyond what ABI mandates on some public symbol
> issue in some older GCC version, then sure, if you have that public symbol
> defined by ICC, it will misbehave.  But, if it is compiled with current GCC
> without your proposed changes, it will work fine, newer GCCs don't assume
> anything beyond ABI mandates alignments, unless they control the definition
> and uses bind locally to it, but still align as optimization as much or more
> as older GCC used to align.
> With your proposed changes that would be no longer true.  What is so hard to
> understand on it?

What is the maximum alignment the older GCCs may assume?

[Bug middle-end/63568] Missed optimization (a & ~mask) | (b & mask) = a ^ ((a ^ b) & mask)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Not necessarily 3 vs. 4 ops, many targets have andnot instruction and can do it
also in 3 ops.

[Bug target/61296] Excessive alignment in ix86_data_alignment

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
If you hit the assumption beyond what ABI mandates on some public symbol issue
in some older GCC version, then sure, if you have that public symbol defined by
ICC, it will misbehave.  But, if it is compiled with current GCC without your
proposed changes, it will work fine, newer GCCs don't assume anything beyond
ABI mandates alignments, unless they control the definition and uses bind
locally to it, but still align as optimization as much or more as older GCC
used to align.
With your proposed changes that would be no longer true.  What is so hard to
understand on it?

[Bug middle-end/63568] Missed optimization (a & ~mask) | (b & mask) = a ^ ((a ^ b) & mask)

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
FWIW, I used this to check the whether the transformation is correct:

int
main ()
{
  for (int i = -1000; i < 1000; ++i)
for (int a = -1000; a < 1000; ++a)
  for (int b = -1000; b < 1000; ++b)
{
  int x = (a & ~i) | (b & i);
  int y = a ^ ((a ^ b) & i);
  //__builtin_printf ("%d %d\n", x, y);
  if (x != y)
__builtin_abort ();
}
}

[Bug sanitizer/64330] [ASAN] Bogus "AddressSanitizer: odr-violation"

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
It is related, but in this case it looks like IPA-ICF bug to me, unless the C++
standard allows what G++ does since r216305.

struct S
{
  static const unsigned short a;
  static const unsigned short b;
  static const unsigned short c;
};

#ifdef A
const unsigned short S::a = 2;
const unsigned short S::b = 1;
const unsigned short S::c = 2;
#endif

#ifdef B
int
main ()
{
  if (&S::a == &S::c)
__builtin_abort ();
}
#endif

With g++ -O2 -o test test.C -DA -DB it succeeds, but with
g++ -O2 -c test.C -o testa.o -DA; g++ -O2 -o test -DB test.C testa.o
it fails.  Works with -fno-ipa-icf.  Without looking at the IPA-ICF patch, just
looking at what it generates, it sounds like it is checking TREE_ADDRESSABLE on
the variables and if they aren't addressable and are const, merges them.  That
is fine if you are in LTO and can see all TUs that could ever access those
vars, but if you can't inspect all the TUs that could take the address of it,
as in the second case, but it could very well be even LTO compiled binary that
links against a shared library that references those symbols, I think you can't
merge the variables (unless -fmerge-all-constants).

[Bug target/61296] Excessive alignment in ix86_data_alignment

[hjl.tools at gmail dot com]

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

--- Comment #10 from H.J. Lu  ---
(In reply to Jakub Jelinek from comment #9)
> (In reply to H.J. Lu from comment #8)
> > Do you have a testcase to show decreasing DATA_ALIGNMENT would break
> > backwards compatibility with older gcc versions?
> 
> Older GCC versions used DATA_ALIGNMENT (what is now DATA_ABI_ALIGNMENT) on
> MEM_ALIGN etc., and gradually more and more optimizations relied on it, even
> when the data was defined in some other compilation unit or was comdat or
> could be interposed.  See e.g.
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56564#c9

I still don't see that limit DATA_ALIGNMENT to MAX (ABI alignment,
natural alignment) will cause additional ABI problems which don't
exist today.

[Bug target/61296] Excessive alignment in ix86_data_alignment

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
(In reply to H.J. Lu from comment #8)
> Do you have a testcase to show decreasing DATA_ALIGNMENT would break
> backwards compatibility with older gcc versions?

Older GCC versions used DATA_ALIGNMENT (what is now DATA_ABI_ALIGNMENT) on
MEM_ALIGN etc., and gradually more and more optimizations relied on it, even
when the data was defined in some other compilation unit or was comdat or could
be interposed.  See e.g. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56564#c9

[Bug target/61296] Excessive alignment in ix86_data_alignment

[hjl.tools at gmail dot com]

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

--- Comment #8 from H.J. Lu  ---
(In reply to Jakub Jelinek from comment #7)
> See discussions when I've added DATA_ABI_ALIGNMENT.

DATA_ABI_ALIGNMENT was added for PR 56564:

/* Similar to DATA_ALIGNMENT, but for the cases where the ABI mandates
   some alignment increase, instead of optimization only purposes.  E.g.
   AMD x86-64 psABI says that variables with array type larger than 15 bytes
   must be aligned to 16 byte boundaries.

   If this macro is not defined, then ALIGN is used.  */

#define DATA_ABI_ALIGNMENT(TYPE, ALIGN) \
  ix86_data_alignment ((TYPE), (ALIGN), false)

and ix86_data_alignment was changed by

https://gcc.gnu.org/ml/gcc-patches/2014-01/msg01086.html

There is a discussion we should always align to DATA_ABI_ALIGNMENT:

https://gcc.gnu.org/ml/gcc-patches/2014-05/msg01435.html

My question was "Should we limit DATA_ALIGNMENT to MAX (ABI alignment,
natural alignment)?"

GCC will only use the excessive alignment with locally defined data,
which has no psABI implications:

[hjl@gnu-6 pr61296]$ cat z.c
struct foo
{
  char i[128];
};

struct foo x = { 1 };
struct foo y = { 1 };
struct foo z = { 1 };

void
bar ()
{
  int i;

  for (i = 0; i < sizeof (x.i); i++)
x.i[i] = y.i[i] + z.i[i];
}

[hjl@gnu-6 pr61296]$ /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -O3 -mavx2 -S z.c -fPIC   
[hjl@gnu-6 pr61296]$ cat z.s
.file"z.c"
.section.text.unlikely,"ax",@progbits
.LCOLDB0:
.text
.LHOTB0:
.p2align 4,,15
.globlbar
.typebar, @function
bar:
.LFB0:
.cfi_startproc
leaq8(%rsp), %r10
.cfi_def_cfa 10, 0
movqy@GOTPCREL(%rip), %rdi
andq$-32, %rsp
pushq-8(%r10)
pushq%rbp
.cfi_escape 0x10,0x6,0x2,0x76,0
movq%rsp, %rbp
pushq%r12
pushq%r10
.cfi_escape 0xf,0x3,0x76,0x70,0x6
.cfi_escape 0x10,0xc,0x2,0x76,0x78
movq%rdi, %r10
pushq%rbx
.cfi_escape 0x10,0x3,0x2,0x76,0x68
negq%r10
andl$31, %r10d
je.L7
movqx@GOTPCREL(%rip), %r8
movqz@GOTPCREL(%rip), %r9
movl%r10d, %esi
xorl%eax, %eax
xorl%edx, %edx
movl$128, %r11d
.p2align 4,,10
.p2align 3
.L3:
movzbl(%rdi,%rax), %ecx
addl$1, %edx
addb(%r9,%rax), %cl
movb%cl, (%r8,%rax)
movl%r11d, %ecx
addq$1, %rax
subl%edx, %ecx
cmpl%r10d, %edx
jne.L3
movl%edx, %eax
movl%ecx, %ebx
movl$96, %r11d
movl$3, %r12d
.L2:
leaq(%r9,%rax), %rdx
leaq(%rdi,%rax), %r10
addq%r8, %rax
cmpl$4, %r12d
vmovdqu(%rdx), %xmm0
vinserti128$0x1, 16(%rdx), %ymm0, %ymm0
vpaddb(%r10), %ymm0, %ymm0
vmovups%xmm0, (%rax)
vextracti128$0x1, %ymm0, 16(%rax)
vmovdqu32(%rdx), %xmm0
vinserti128$0x1, 48(%rdx), %ymm0, %ymm0
vpaddb32(%r10), %ymm0, %ymm0
vmovups%xmm0, 32(%rax)
vextracti128$0x1, %ymm0, 48(%rax)
vmovdqu64(%rdx), %xmm0
vinserti128$0x1, 80(%rdx), %ymm0, %ymm0
vpaddb64(%r10), %ymm0, %ymm0
vmovups%xmm0, 64(%rax)
vextracti128$0x1, %ymm0, 80(%rax)
jne.L4
vmovdqu96(%rdx), %xmm0
vinserti128$0x1, 112(%rdx), %ymm0, %ymm0
vpaddb96(%r10), %ymm0, %ymm0
vmovups%xmm0, 96(%rax)
vextracti128$0x1, %ymm0, 112(%rax)
.L4:
leal(%r11,%rsi), %eax
subl%r11d, %ecx
cmpl%r11d, %ebx
leal(%rax,%rcx), %esi
je.L10
.p2align 4,,10
.p2align 3
.L5:
movslq%eax, %rdx
addl$1, %eax
movzbl(%r9,%rdx), %ecx
addb(%rdi,%rdx), %cl
cmpl%esi, %eax
movb%cl, (%r8,%rdx)
jne.L5
.L10:
vzeroupper
popq%rbx
popq%r10
.cfi_remember_state
.cfi_def_cfa 10, 0
popq%r12
popq%rbp
leaq-8(%r10), %rsp
.cfi_def_cfa 7, 8
ret
.p2align 4,,10
.p2align 3
.L7:
.cfi_restore_state
movl$128, %r11d
movl$4, %r12d
movl$128, %ebx
xorl%eax, %eax
movl$128, %ecx
xorl%esi, %esi
movqx@GOTPCREL(%rip), %r8
movqz@GOTPCREL(%rip), %r9
jmp.L2
.cfi_endproc
.LFE0:
.sizebar, .-bar
.section.text.unlikely
.LCOLDE0:
.text
.LHOTE0:
.globlz
.data
.align 64
.typez, @object
.sizez, 128
z:
.byte1
.zero127
.globly
.align 64
.typey, @object
.sizey, 128
y:
.byte1
.zero127
.globlx
.align 64
.typex, @object
.sizex, 128
x:
.byte1
.zero127
.ident"GCC: (GNU) 5.0.0 20141205 (experimental)"
.section.note.GNU-stack,"",@progbits

Do you have a testcase to show decreasing DATA_ALIGNMENT would break
backwards compatibility with older gcc versions?
Our data show that the excessive a

[Bug rtl-optimization/64331] regcprop propagates registers noted as REG_DEAD

[senthil_kumar.selvaraj at atmel dot com]

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

--- Comment #1 from Senthil Kumar Selvaraj  ---
Created attachment 34291
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34291&action=edit
Assembly

[Bug rtl-optimization/64331] New: regcprop propagates registers noted as REG_DEAD

[senthil_kumar.selvaraj at atmel dot com]

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

Bug ID: 64331
   Summary: regcprop propagates registers noted as REG_DEAD
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: senthil_kumar.selvaraj at atmel dot com

Created attachment 34290
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34290&action=edit
Source file

For the AVR target, compiling the attached source file with -O1 results in code
like this


or r20,r21
or r20,r22
or r20,r23
breq .L1
ldd r24,Z+4
ldd r25,Z+5
ldd r26,Z+6
ldd r27,Z+7
cp r20,r24
cpc r21,r25
cpc r22,r26
cpc r23,r27


Register R20 was clobbered first up, but is used to compare against R24.

fdump-rtl-all-raw showed that cprop_hardreg is the culprit. In pass *.ce3


(insn 7 4 8 2 (set (reg:SI 16 r16 [orig:43 D.1617 ] [43]) 
(reg/v:SI 20 r20 [orig:46 x ] [46])) reduced.c:12 94 {*movsi}
 (nil))
...
(insn 13 12 14 3 (parallel [
(set (cc0)
(compare (reg/v:SI 20 r20 [orig:46 x ] [46])
(const_int 0 [0])))
(clobber (scratch:QI))
]) reduced.c:17 413 {*cmpsi}
 (expr_list:REG_DEAD (reg/v:SI 20 r20 [orig:46 x ] [46])
(nil)))
...
(insn 17 16 18 4 (parallel [
(set (cc0)
(compare (reg:SI 16 r16 [orig:43 D.1617 ] [43])
(reg:SI 24 r24 [orig:48 t_3(D)->b ] [48])))
(clobber (scratch:QI))
]) reduced.c:20 413 {*cmpsi}
 (expr_list:REG_DEAD (reg:SI 24 r24 [orig:48 t_3(D)->b ] [48])
(expr_list:REG_DEAD (reg:SI 16 r16 [orig:43 D.1617 ] [43])
(nil


into


;; Function foo (foo, funcdef_no=0, decl_uid=1599, cgraph_uid=0,
symbol_order=0)

insn 17: replaced reg 16 with 20
rescanning insn with uid = 17.
..
(insn 17 16 18 4 (parallel [
(set (cc0)
(compare (reg:SI 20 r20 [orig:43 D.1617 ] [43])
(reg:SI 24 r24 [orig:48 t_3(D)->b ] [48])))
(clobber (scratch:QI))
]) reduced.c:20 413 {*cmpsi}
 (expr_list:REG_DEAD (reg:SI 24 r24 [orig:48 t_3(D)->b ] [48])
(expr_list:REG_DEAD (reg:SI 16 r16 [orig:43 D.1617 ] [43])
(nil


The AVR backend, on seeing that reg:SI r20 is dead in insn 13, emits code that
clobbers r20, and this breaks the read in insn 17.

[Bug sanitizer/64330] [ASAN] Bogus "AddressSanitizer: odr-violation"

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

--- Comment #1 from Markus Trippelsdorf  ---
Looks like a dup of PR63888.

[Bug sanitizer/64330] New: [ASAN] Bogus "AddressSanitizer: odr-violation"

[burnus at gcc dot gnu.org]

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

Bug ID: 64330
   Summary: [ASAN] Bogus "AddressSanitizer: odr-violation"
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
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,
mpolacek at gcc dot gnu.org

I have in a C++ header file ("foo.h"):

class Foo {
 public:
  static const unsigned short   AlignRight;
  static const unsigned short   AlignBottom;
  ...
};

And in its C++ file (foo.cc):

const unsigned shortFoo::AlignRight = 2;
const unsigned shortFoo::AlignTop  = 1;
const unsigned shortFoo::AlignBottom = 2;


I fail to see a reason why that's a violation of the One Definition Rule (ORD),
but ASAN fails with:

==9056==ERROR: AddressSanitizer: odr-violation (0x04b4dbc0):
  [1] size=2 'AlignRight' foo.cc:23:22
  [2] size=2 'AlignBottom' foo.cc:25:22
These globals were registered at these points:
  [1]:
#0 0x4daa56 in __asan_register_globals
../../../../libsanitizer/asan/asan_globals.cc:217
#1 0x4b0c6ac in __libc_csu_init (foo+0x4b0c6ac)
#2 0x3761c1ecef in __libc_start_main (/lib64/libc.so.6+0x3761c1ecef)

[Bug rtl-optimization/64291] [5 Regression] Miscompile t-div in GMP's testsuite

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
(In reply to Jakub Jelinek from comment #3)
> Started with r217587.

Oops, sorry for typo, r217588.

[Bug rtl-optimization/64291] [5 Regression] Miscompile t-div in GMP's testsuite

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-12-16
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Jakub Jelinek  ---
Started with r217587.

[Bug sanitizer/64265] [5 Regression] r217669 broke tsan

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #25 from Jakub Jelinek  ---
The regression is fixed.  For the EH support, patch has been posted, but that
is not a fix for a regression, but enhancement.