[Bug pch/63319] [5 Regression] ICE: Segmentation fault building qt5 with pch

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #4 from Markus Trippelsdorf  ---
Seems to work now on ppc64 and x86_64. Closing.

[Bug tree-optimization/64434] [5 Regression] Performance regression after operand canonicalization (r216728).

[pinskia at gcc dot gnu.org]

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

--- Comment #18 from Andrew Pinski  ---
This testcase fails for AARCH64:ilp32 (that is AARCH64 with -mabi=ilp32).

[Bug middle-end/61207] Win64 gcc 4.9.0: ICE at -Os compiling some C++ code

[public at hansmi dot ch]

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

M. Hanselmann  changed:

   What|Removed |Added

 CC||public at hansmi dot ch

--- Comment #5 from M. Hanselmann  ---
This also happens when compiling Boost 1.57.0. I've reproduced it using
TDM64-GCC (version 4.9.2-3) and Stephan T. Lavavej's MinGW distribution
(version 12.2).

How to reproduce:

- Unpack Boost 1.57.0 and change into source directory
- g++ -v -save-temps -Os -I. libs\test\src\unit_test_parameters.cpp

As mentioned in earlier comments, -O{1,2,3} work and only -Os produced an ICE.
I'm not attaching 2.3 MB preprocessed file due to the wide availability of
Boost sources.

[Bug target/55302] [SH] Add support for logical ops with GBR mems

[olegendo at gcc dot gnu.org]

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

--- Comment #1 from Oleg Endo  ---
If the atomic model allows it, the GBR logical ops can also be to implement
atomic operations on GBR relative memory.

[Bug fortran/64952] Missing temporary in assignment from elemental function

[mikael at gcc dot gnu.org]

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

--- Comment #4 from Mikael Morin  ---
Hello Paul,

setting potentially_aliased should be done inside
gfc_walk_elemental_function_args, as the ss argument may be returned
unmodified.
In fact, I think it's better to do all the trans-array.c code inside
gfc_conv_resolve_dependencies without adding the gfc_ss_info flag.

There is also the case of typebound procedures and procedure pointer
components,
for which we should generate a temporary in any case.

I think this case is something that was overlooked by the standard commitee
when they introduced the PURE attribute.  Maybe they can provide some kind of
"REALLY_PURE" attribute (or PURE ELEMENTAL, different from regular ELEMENTAL)
that avoids generating temporaries everywhere?
Or maybe the function Fred should bee IMPURE ELEMENTAL?

Anyway, I think we should not rush to fix this before we are sure that the
standard committee really expects temporaries (almost) everywhere array
elemental functions are involved.

[Bug libgomp/64972] New: Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch

[erik-gcc-bugzilla at vanpienbroek dot nl]

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

Bug ID: 64972
   Summary: Build failure in libgomp for i686-w64-mingw32 target
after latest merge from gomp-4_0-branch
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: erik-gcc-bugzilla at vanpienbroek dot nl
CC: jakub at gcc dot gnu.org, ktietz at gcc dot gnu.org
Target: i686-w64-mingw32

Recent snapshots of gcc 5 can not be built any more for the i686-w64-mingw32
target:

make[4]: Entering directory
'/home/erik/fedora/mingw-gcc/gcc-5-20150125/build_win32/i686-w64-mingw32/libgomp'
/bin/sh ./libtool --tag=CC
--mode=compile
/home/erik/fedora/mingw-gcc/gcc-5-20150125/build_win32/./gcc/xgcc
-B/home/erik/fedora/mingw-gcc/gcc-5-20150125/build_win32/./gcc/
-L/usr/i686-w64-mingw32/lib -L/usr/mingw/lib -isystem
/usr/i686-w64-mingw32/include -isystem /usr/mingw/include
-B/usr/i686-w64-mingw32/bin/ -B/usr/i686-w64-mingw32/lib/ -isystem
/usr/i686-w64-mingw32/include -isystem /usr/i686-w64-mingw32/sys-include   
-DHAVE_CONFIG_H -I. -I../../../libgomp  -I../../../libgomp/config/mingw32
-I../../../libgomp/config/posix -I../../../libgomp
-I../../../libgomp/../include  -Wall -Werror -Wc,-pthread -g -O2 -MT target.lo
-MD -MP -MF .deps/target.Tpo -c -o target.lo ../../../libgomp/target.c
libtool:
compile:  /home/erik/fedora/mingw-gcc/gcc-5-20150125/build_win32/./gcc/xgcc
-B/home/erik/fedora/mingw-gcc/gcc-5-20150125/build_win32/./gcc/
-L/usr/i686-w64-mingw32/lib -L/usr/mingw/lib -isystem
/usr/i686-w64-mingw32/include -isystem /usr/mingw/include
-B/usr/i686-w64-mingw32/bin/ -B/usr/i686-w64-mingw32/lib/ -isystem
/usr/i686-w64-mingw32/include -isystem /usr/i686-w64-mingw32/sys-include
-DHAVE_CONFIG_H -I. -I../../../libgomp -I../../../libgomp/config/mingw32
-I../../../libgomp/config/posix -I../../../libgomp
-I../../../libgomp/../include -Wall -pthread -Werror -g -O2 -MT target.lo -MD
-MP -MF .deps/target.Tpo -c ../../../libgomp/target.c  -DDLL_EXPORT -DPIC -o
.libs/target.o
../../../libgomp/target.c: In function 'gomp_map_vars':
../../../libgomp/target.c:440:21: error: unknown conversion type
character 'z' in format [-Werror=format=]
 gomp_fatal ("present clause: !acc_is_present (%p, "
 ^
../../../libgomp/target.c:440:21: error: unknown conversion type
character 'z' in format [-Werror=format=]
../../../libgomp/target.c:440:21: error: too many arguments for format
[-Werror=format-extra-args]
cc1: all warnings being treated as errors
Makefile:613: recipe for target 'target.lo' failed
make[4]: *** [target.lo] Error 1
make[4]: Leaving directory
'/home/erik/fedora/mingw-gcc/gcc-5-20150125/build_win32/i686-w64-mingw32/libgomp'


The offending line contains this piece of code:
gomp_fatal ("present clause: !acc_is_present (%p, "
"%zd (0x%zx))", (void *) k->host_start,
size, size);

This piece of code was introduced in r219682 which was applied on January 15
2015.

This issue was also discussed at the mingw-w64 mailing list @ 
http://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/54cd7703.8080...@users.sourceforge.net/
and also contains some possible solutions

[Bug ipa/61548] [5 Regression] FAIL: gcc.dg/tls/alias-1.c (internal compiler error)

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #24 from Hans-Peter Nilsson  ---
Apparently the test still fails, so I'm re-opening it as wrongly closed, since
it still fails for arm-eabi and cris-elf (same as in comment #23) and according
to  also for
hppa64-hp-hpux11.11.  The error changed from ICE to something else but that is
not a reason to close the PR.

Comment #23 isn't clear that the assembler complains and that the relevant part
of gcc.log is:

output is:
/tmp/ccDUW6dB.s: Assembler messages:
/tmp/ccDUW6dB.s:37: Error: symbol `___emutls_v.foo' is already defined

Assembler code will be attached.

[Bug ipa/61548] [5 Regression] FAIL: gcc.dg/tls/alias-1.c (internal compiler error)

[hp at gcc dot gnu.org]

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

--- Comment #25 from Hans-Peter Nilsson  ---
Created attachment 34695
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34695&action=edit
Assembly file showing the duplicate label

[Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs

[amker at gcc dot gnu.org]

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

--- Comment #28 from amker at gcc dot gnu.org ---
On hppa 32, the two iv uses are:
use 0
  address
  in statement *p_1 = 0;

  at position *p_1
  type int *
  base p_7
  step 4
  base object (void *) p_7
  related candidates 
use 1
  compare
  in statement if (i_11 <= 99)

  at position 
  type unsigned int
  base i_4(D) + 1
  step 1
  is a biv
  related candidates 
And the BIV/GIV candidates are:
candidate 3 (important)
  original biv
  type int *
  base p_7
  step 4
  base object (void *) p_7
candidate 4 (important)
  ...
candidate 5 (important)
  original biv
  type unsigned int
  base i_4(D)
  step 1

The costs table are:

Candidate costs:
  candcost
  05
  15
  25
  34
  45
  54
  65
  75
Use 0:
  candcostcompl.depends on
  0121
  110
  2111
  310
  432 inv_expr:0
  532 inv_expr:0
  611
  7193 inv_expr:1

Use 1:
  candcostcompl.depends on
  040 inv_expr:2
  330 inv_expr:3
  400
  500
  741

It seems cand3 and cand5 have same level cost, but GCC chooses candidate 5 as
below:
Initial set of candidates:
  cost: 9 (complexity 2)
  cand_cost: 4
  cand_use_cost: 3 (complexity 2)
  candidates: 5
   use:0 --> iv_cand:5, cost=(3,2)
   use:1 --> iv_cand:5, cost=(0,0)

While on other targets, cand 3 is selected.

[Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs

[amker at gcc dot gnu.org]

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

--- Comment #29 from amker at gcc dot gnu.org ---
(In reply to amker from comment #28)
> On hppa 32, the two iv uses are:
> use 0
>   address
>   in statement *p_1 = 0;
> 
>   at position *p_1
>   type int *
>   base p_7
>   step 4
>   base object (void *) p_7
>   related candidates 
> use 1
>   compare
>   in statement if (i_11 <= 99)
> 
>   at position 
>   type unsigned int
>   base i_4(D) + 1
>   step 1
>   is a biv
>   related candidates 
> And the BIV/GIV candidates are:
> candidate 3 (important)
>   original biv
>   type int *
>   base p_7
>   step 4
>   base object (void *) p_7
> candidate 4 (important)
>   ...
> candidate 5 (important)
>   original biv
>   type unsigned int
>   base i_4(D)
>   step 1
> 
> The costs table are:
> 
> Candidate costs:
>   candcost
>   0   5
>   1   5
>   2   5
>   3   4
>   4   5
>   5   4
>   6   5
>   7   5
> Use 0:
>   candcostcompl.  depends on
>   0   1   2   1
>   1   1   0   
>   2   1   1   1
>   3   1   0   
>   4   3   2inv_expr:0
>   5   3   2inv_expr:0
>   6   1   1   
>   7   19  3inv_expr:1
> 
> Use 1:
>   candcostcompl.  depends on
>   0   4   0inv_expr:2
>   3   3   0inv_expr:3
>   4   0   0   
>   5   0   0   
>   7   4   1   
> 
> It seems cand3 and cand5 have same level cost, but GCC chooses candidate 5

Ah, candidate 5 is considered cheaper according to the cost table.

> as below:
> Initial set of candidates:
>   cost: 9 (complexity 2)
>   cand_cost: 4
>   cand_use_cost: 3 (complexity 2)
>   candidates: 5
>use:0 --> iv_cand:5, cost=(3,2)
>use:1 --> iv_cand:5, cost=(0,0)
> 
> While on other targets, cand 3 is selected.

[Bug libstdc++/64467] [5 Regression] 28_regex/traits/char/isctype.cc and wchar_t/isctype.cc

[hp at gcc dot gnu.org]

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

--- Comment #9 from Hans-Peter Nilsson  ---
To wit, at r220506  still see:
assertion "!t.isctype('\n', t.lookup_classname(blank,
blank+sizeof(blank)/sizeof(blank[0])-1))" failed: file
"/tmp/hpautotest-gcc1/gcc/libstdc++-v3/testsuite/28_regex/traits/char/isctype.cc",
line 61, function: void test01()
program stopped with signal 6 (Aborted).

Maybe the newlib preprocessor symbol isn't universal?

[Bug fortran/63744] [4.8/4.9/5 Regression] Duplicate use-statement causes error

[mikael at gcc dot gnu.org]

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

--- Comment #9 from Mikael Morin  ---
Author: mikael
Date: Sun Feb  8 14:18:16 2015
New Revision: 220515

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

Use the local name instead of the original name in the check for name conflicts
between a hosting program unit and use-associated symbols
in that program unit.

fortran/
PR fortran/63744
* module.c (check_for_ambiguous): Change argument type
from gfc_symbol to gfc_symtree.  Check local (symtree) name
instead of original (symbol) name.
(read_module): Update caller.

testsuite/
PR fortran/63744
gfortran.dg/use_rename_8.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/use_rename_8.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/module.c
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/64467] [5 Regression] 28_regex/traits/char/isctype.cc and wchar_t/isctype.cc

[hp at gcc dot gnu.org]

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

--- Comment #10 from Hans-Peter Nilsson  ---
(In reply to Hans-Peter Nilsson from comment #9)
> To wit, at r220506  still see:
> assertion "!t.isctype('\n', t.lookup_classname(blank,
> blank+sizeof(blank)/sizeof(blank[0])-1))" failed: file
> "/tmp/hpautotest-gcc1/gcc/libstdc++-v3/testsuite/28_regex/traits/char/
> isctype.cc", line 61, function: void test01()
> program stopped with signal 6 (Aborted).
> 
> Maybe the newlib preprocessor symbol isn't universal?

Universal regarding targets but not regarding time as it's recent-ish:

2014-09-17  Jeff Johnston  

* libc/include/sys/features.h: Add __NEWLIB__ and
__NEWLIB_MINOR__ macros.

My autotester hasn't automatically updated to a version with this change as
there hasn't been a regression-free period for gcc since 2014-05-08-20:35:45
r210245. :(

More to the point, this test being the random only requirement for the last
newlib release seems spurious.

There's a _NEWLIB_VERSION and a __NEWLIB_H__ which would work for not just the
latest newlib version.  Would it be ok to change to (suggesting) #ifdef
_NEWLIB_VERSION?  Alternatively, we have an effective-target newlib which can
be used to define a NEWLINE_IN_CLASS_BLANK which can be used for other
misfortunate targets.

[Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs

[dave.anglin at bell dot net]

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

--- Comment #30 from dave.anglin at bell dot net ---
On 2015-02-08, at 9:09 AM, amker at gcc dot gnu.org wrote:

> Ah, candidate 5 is considered cheaper according to the cost table.

Is this a problem with insn costs, or a problem in the estimation of the total
cost
for each candidate?

Dave
--
John David Anglindave.ang...@bell.net

[Bug middle-end/62247] [5 Regression] FAIL: g++.dg/abi/anon3.C -std=c++98 scan-assembler .weak(_definition)

[danglin at gcc dot gnu.org]

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

--- Comment #4 from John David Anglin  ---
Created attachment 34696
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34696&action=edit
4.9 assembler output

[Bug middle-end/62247] [5 Regression] FAIL: g++.dg/abi/anon3.C -std=c++98 scan-assembler .weak(_definition)

[dave.anglin at bell dot net]

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

--- Comment #5 from dave.anglin at bell dot net ---
On 2015-02-07, at 10:49 AM, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62247
> 
> --- Comment #3 from Jakub Jelinek  ---
> With cross-compiler I get the same anon3.s (no .weak occurrences in the
> assembly) as in 4.9.  As neither the test nor dg-require-weak seems to have
> changed, I guess the important questions are:
> 1) can you compare 4.9.2 and 5.0.0 generated assembly?

Attached assembler output from 4.9.3 20150207.

The assembly output from 5.0.0 is wierd.  It has a few nop's which make up body
of function:

virtual void Heya::A::f()
...
(insn 2 11 3 (set (mem/f/c:SI (reg/f:SI 28 %r28 [98]) [0 this+0 S4 A32])
(reg:SI 26 %r26 [ this ]))
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/abi/an
on3.C:14 40 {*pa.md:2204}
 (nil))
(note 3 2 8 NOTE_INSN_FUNCTION_BEG)(insn 8 3 18 (const_int 0 [0])
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/abi/anon3.
C:14 213 {nop}
 (nil))
(note 18 8 19 NOTE_INSN_EPILOGUE_BEG)

> 2) does the test in 4.9.2 PASS or is it UNSUPPORTED?

The test passes in 4.9.2.

> 3) has something changed in auto-host.h, such as previously HAVE_GAS_WEAK and
> now no longer true or something similar?

Both 4.9 and 5.0 have:

/* Define if your assembler supports .weak. */
#ifndef USED_FOR_TARGET
#define HAVE_GAS_WEAK 1
#endif


/* Define if your assembler supports .weakref. */
#ifndef USED_FOR_TARGET
#define HAVE_GAS_WEAKREF 1
#endif

> 4) if there has been any change on the compiler side, can you bisect when did
> that happen?


Will try to narrow this down.

Dave
--
John David Anglindave.ang...@bell.net

[Bug fortran/64973] New: Duplicate use-statements could be diagnosed

[mikael at gcc dot gnu.org]

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

Bug ID: 64973
   Summary: Duplicate use-statements could be diagnosed
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mikael at gcc dot gnu.org

This is a followup to PR63744 and was suggested in:
https://gcc.gnu.org/ml/fortran/2015-02/msg00036.htm

We accept duplicate use-rename statements like:
  use m, only: A => X
  use m, only: A => X
But it doesn't make sense for someone to type them twice, so they may actually
be a typo.  The compiler could diagnose it, probably under some flag
(Dominique suggested -Wall).

There is also:
  use m, only: A => X, A => X

and also:
  use m
  use m

[Bug fortran/64973] Duplicate use-statements could be diagnosed

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

   Keywords||diagnostic
   Priority|P3  |P4
   Severity|normal  |enhancement

[Bug fortran/59765] [4.9/5 Regression] [OOP] ICE on valid with finalizable array components

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #15 from Paul Thomas  ---
This is one and the same as PR64932 for which I have just posted a fix. Thanks
to Dominique for noticing this.

Since it is a regression, I will be posting to 4.9 and 5.0.

Cheers


Paul

[Bug fortran/60529] [4.9/4.10 Regression] [OOP] ICE with allocatable sub-component

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #6 from Paul Thomas  ---
This is the same as PR64932 and PR59765. I have posted a patch for the former.

Thanks for pointing this out Dominique!

Paul

[Bug fortran/61766] [4.9/4.10 regression] ICE on trans-array.c

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #5 from Paul Thomas  ---
This is fixed by my patch for PR64932, which also fixes PR59765 and PR60529.

Thanks to Dominique for pointing this out.

Paul

[Bug ipa/60871] [4.9 Regression] internal compiler error: in possible_polymorphic_call_targets, at ipa-devirt.c:1510

[boris at kolpackov dot net]

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

Boris Kolpackov  changed:

   What|Removed |Added

 CC||boris at kolpackov dot net

--- Comment #15 from Boris Kolpackov  ---
I just tried gcc-4.9-20150204[1] which seems to have been packaged after your
commit, and I still get the ICE.

[1] https://gcc.gnu.org/ml/gcc/2015-02/msg00035.html

[Bug fortran/64932] [4.9/5 Regression] ICE in gfc_conv_descriptor_data_get for generated finalizer

[paul.richard.thomas at gmail dot com]

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

--- Comment #4 from paul.richard.thomas at gmail dot com  ---
Dear All,

It would be nice to commit this tonight, if possible. An impetus to do
this is added by Dominique pointing out that it fixes PRs 59765, 60529
and 61766!

Cheers

Paul

On 7 February 2015 at 12:23, pault at gcc dot gnu.org
 wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64932
>
> Paul Thomas  changed:
>
>What|Removed |Added
> 
>  CC||pault at gcc dot gnu.org
>Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot 
> gnu.org
>
> --- Comment #3 from Paul Thomas  ---
> Created attachment 34691
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34691&action=edit
> Patch for the PR
>
> class.c(finalize_component) is not able to deal correctly with non-allocatable
> derived type array components that have finalizable components. Rather than
> generating loops in finalize_component, I detected the condition in
> trans-stmt.c(gfc_trans_deallocate) and have called gfc_deallocate_alloc_comp
> after obtaining the derived type for the array.
>
> Happily, this fix does not generate the error:
> Error: Two or more part references with nonzero rank must not be specified at
> (1)
>
> which occurs if the code is written explicitly.
>
> Bootstraps and regtests on FC21/x_86_64
>
> OK for trunk?
>
> Paul
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
> You are the assignee for the bug.

[Bug middle-end/62247] [5 Regression] FAIL: g++.dg/abi/anon3.C -std=c++98 scan-assembler .weak(_definition)

[dave.anglin at bell dot net]

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

--- Comment #6 from dave.anglin at bell dot net ---
On 2015-02-07, at 10:49 AM, jakub at gcc dot gnu.org wrote:

> 4) if there has been any change on the compiler side, can you bisect when did
> that happen?

>From test logs:
r214122 was okay and r214400 failed.

Dave
--
John David Anglindave.ang...@bell.net

[Bug middle-end/64974] New: [SH] Weird expansion of 'expected' operand in atomic_compare_and_swap

[olegendo at gcc dot gnu.org]

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

Bug ID: 64974
   Summary: [SH] Weird expansion of 'expected' operand in
atomic_compare_and_swap
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: olegendo at gcc dot gnu.org
Target: sh*-*-*

While working on PR 64661, I've noticed that the expansion of the
atomic_compare_and_swap pattern's 'expected value' operand seems to be
weird.

When compiling with -m4a -matomic-model=hard-llcs -O2, the 'expected value' and
'new value' can be immediate operands in the range -128..+127, if the atomic is
SImode.

The following example function:

void
test_0 (int* mem)
{
  int expected = 1;
  int desired = 5;
  __atomic_compare_exchange (mem, &expected, &desired, 0, __ATOMIC_ACQ_REL,
 __ATOMIC_RELAXED);
}

is expanded to:

(insn 11 10 12 2 (parallel [
(set (reg:SI 167)
(unspec_volatile:SI [
(mem/v:SI (reg/v/f:SI 162 [ mem ]) [-1  S4 A32])
>   (reg:SI 166)
>   (const_int 5 [0x5])
] UNSPECV_CMPXCHG_1))
(set (mem/v:SI (reg/v/f:SI 162 [ mem ]) [-1  S4 A32])
(unspec_volatile:SI [
(const_int 0 [0])
] UNSPECV_CMPXCHG_2))
(set (reg:SI 147 t)
(unspec_volatile:SI [
(const_int 0 [0])
] UNSPECV_CMPXCHG_3))
(clobber (reg:SI 0 r0))
]) sh_tmp.cpp:9 -1
 (nil))

While the 'new value' operand is successfully passed as an immediate value, the
'expected value' is not and ends up being written onto the stack.  After
various RTL passes combine manages to plug the const_int 1 into the operand and
the stack write is eliminated.  However, the stack frame setup remains.

[Bug target/64975] New: [AArch64] Thunderx should not default to crypto enabled

[rearnsha at gcc dot gnu.org]

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

Bug ID: 64975
   Summary: [AArch64] Thunderx should not default to crypto
enabled
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: pinskia at gcc dot gnu.org
  Reporter: rearnsha at gcc dot gnu.org
CC: pinskia at gcc dot gnu.org

According to https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02118.html the
thunderX processors should not default to crypto enabled by default, since
non-crypto versions also exist.

[Bug bootstrap/64976] New: Bootstrap fails with -O3 -fgraphite-identity

[hete2 at gmx dot de]

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

Bug ID: 64976
   Summary: Bootstrap fails with -O3 -fgraphite-identity
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hete2 at gmx dot de

On my System (Ubuntu 14.04 on an Sandy-Bridge Processor) bootstrapping
gcc-5-20150201 fails with BOOT_CFLAGS= -O3 -fgraphite-identity. The output is:

 /home/hete/buggcc/gcc-5-20150201/Build1/./prev-gcc/xg++
-B/home/hete/buggcc/gcc-5-20150201/Build1/./prev-gcc/
-B/usr/local/x86_64-unknown-linux-gnu/bin/ -nostdinc++
-B/home/hete/buggcc/gcc-5-20150201/Build1/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/home/hete/buggcc/gcc-5-20150201/Build1/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/home/hete/buggcc/gcc-5-20150201/Build1/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu

-I/home/hete/buggcc/gcc-5-20150201/Build1/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include
 -I/home/hete/buggcc/gcc-5-20150201/libstdc++-v3/libsupc++
-L/home/hete/buggcc/gcc-5-20150201/Build1/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/home/hete/buggcc/gcc-5-20150201/Build1/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-c  -DIN_GCC_FRONTEND -O3 -fgraphite-identity -pipe -gtoggle -DIN_GCC   
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror
-fno-common  -DHAVE_CONFIG_H -I. -Ifortran -I../../gcc -I../../gcc/fortran
-I../../gcc/../include -I../../gcc/../libcpp/include 
-I../../gcc/../libdecnumber -I../../gcc/../libdecnumber/bid -I../libdecnumber
-I../../gcc/../libbacktrace   -o fortran/options.o -MT fortran/options.o -MMD
-MP -MF fortran/.deps/options.TPo ../../gcc/fortran/options.c
../../gcc/fortran/module.c: In Funktion »void load_omp_udrs()«:
../../gcc/fortran/module.c:4582:24: Fehler: »name« könnte in dieser Funktion
uninitialisiert verwendet werden [-Werror=maybe-uninitialized]
size_t len = strlen (name + 1);
^
/home/hete/buggcc/gcc-5-20150201/Build1/./prev-gcc/xg++
-B/home/hete/buggcc/gcc-5-20150201/Build1/./prev-gcc/
-B/usr/local/x86_64-unknown-linux-gnu/bin/ -nostdinc++
-B/home/hete/buggcc/gcc-5-20150201/Build1/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/home/hete/buggcc/gcc-5-20150201/Build1/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/home/hete/buggcc/gcc-5-20150201/Build1/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu

-I/home/hete/buggcc/gcc-5-20150201/Build1/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include
 -I/home/hete/buggcc/gcc-5-20150201/libstdc++-v3/libsupc++
-L/home/hete/buggcc/gcc-5-20150201/Build1/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/home/hete/buggcc/gcc-5-20150201/Build1/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-c  -DIN_GCC_FRONTEND -O3 -fgraphite-identity -pipe -gtoggle -DIN_GCC   
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror
-fno-common  -DHAVE_CONFIG_H -I. -Ifortran -I../../gcc -I../../gcc/fortran
-I../../gcc/../include -I../../gcc/../libcpp/include 
-I../../gcc/../libdecnumber -I../../gcc/../libdecnumber/bid -I../libdecnumber
-I../../gcc/../libbacktrace   -o fortran/parse.o -MT fortran/parse.o -MMD -MP
-MF fortran/.deps/parse.TPo ../../gcc/fortran/parse.c
../../gcc/fortran/module.c: In Funktion »void read_module()«:
../../gcc/fortran/module.c:1562:7: Fehler: »n« könnte in dieser Funktion
uninitialisiert verwendet werden [-Werror=maybe-uninitialized]
   if (i < 0)
   ^
../../gcc/fortran/module.c:4932:12: Anmerkung: »n« wurde hier deklariert
int n;
^
../../gcc/fortran/module.c:4940:41: Fehler: »comp_name« könnte in dieser
Funktion uninitialisiert verwendet werden [-Werror=maybe-uninitialized]
gcc_assert (comp_name == c->name);
 ^
cc1plus: Alle Warnungen werden als Fehler behandelt
make[3]: *** [fortran/module.o] Fehler 1
make[3]: *** Warte auf noch nicht beendete Prozesse...
rm cpp.pod gcov-tool.pod gcj-dbtool.pod jcf-dump.pod jv-convert.pod grmic.pod
gcov.pod gcj.pod gc-analyze.pod gfdl.pod fsf-funding.pod gij.pod gfortran.pod
gcc.pod
make[3]: Verlasse Verzeichnis '/home/hete/buggcc/gcc-5-20150201/Build1/gcc'
make[2]: *** [all-stage2-gcc] Fehler 2
make[2]: Verlasse Verzeichnis '/home/hete/buggcc/gcc-5-20150201/Build1'
make[1]: *** [stage2-bubble] Fehler 2
make[1]: Verlasse Verzeichnis '/home/hete/buggcc/gcc-5-20150201/Build1'
make: *** [bootstrap] Fehler 2

Without CFLAGS or with --enable-

[Bug fortran/57822] I/O: "(g0)" wrongly prints "E+0000"

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #1 from Jerry DeLisle  ---
Possible Patch:  Still Testing

Index: write_float.def
===
--- write_float.def(revision 220505)
+++ write_float.def(working copy)
@@ -724,7 +724,7 @@
 }

   /* Output the exponent.  */
-  if (expchar)
+  if (expchar && !(dtp->u.p.g0_no_blanks && e == 0))
 {
   if (expchar != ' ')
 {

[Bug other/61805] Demangler crash (GDB PR 17157)

[gcc-bugzilla at ca dot sh13.net]

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

gcc-bugzilla at ca dot sh13.net changed:

   What|Removed |Added

 CC||gcc-bugzilla at ca dot sh13.net

--- Comment #1 from gcc-bugzilla at ca dot sh13.net ---
Some more comments, copied from the GDB bug report:

Ok, this problem is a bit more complicated. First, a newer GCC (4.9.1) and
Clang 3.5 doesn't produce the symbol any more. Running a more recent c++filt on
it now crashes c++filt -- if you look closely, the originally demangled type
was also incorrect, as: decltype (((float)()*(float)())) does not make sense --
should have been decltype (float ()*float ()) which is simply float.

I'm debugging a new crash now where the demangler/libiberty starts producing a
symbol name with decltype in it, which I strongly suspect is similar to the
original issue. Am I right to assume that decltype is never part of a mangled
symbol name?

[Bug ipa/63566] [5 Regression] i686 bootstrap fails: ICE RTL flag check: INSN_UID used with unexpected rtx code 'set' in INSN_UID, at rtl.h:1326

[hubicka at gcc dot gnu.org]

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

--- Comment #10 from Jan Hubicka  ---
Author: hubicka
Date: Sun Feb  8 20:08:21 2015
New Revision: 220518

URL: https://gcc.gnu.org/viewcvs?rev=220518&root=gcc&view=rev
Log:
PR ipa/63566 
* cgraphunit.c (cgraph_node::analyze): Be sure target of thunk is
aliases before trying to expand it.
(cgraph_node::expand_thunk): Fix formating.

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

[Bug ipa/63566] [5 Regression] i686 bootstrap fails: ICE RTL flag check: INSN_UID used with unexpected rtx code 'set' in INSN_UID, at rtl.h:1326

[hubicka at gcc dot gnu.org]

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

--- Comment #11 from Jan Hubicka  ---
Author: hubicka
Date: Sun Feb  8 20:13:01 2015
New Revision: 220519

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

PR ipa/63566 
* ipa-split.c (execute_split_functions): Split if function has aliases.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-split.c

[Bug preprocessor/64864] [5 Regression] preprocessor linemarkers break configure checks

[trippels at gcc dot gnu.org]

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

--- Comment #7 from Markus Trippelsdorf  ---
The list of broken packages goes on and on.
xorg-server-1.17:

sdksyms.c:313:15: error: expected expression before ‘,’ token
 (void *) &,  /*
/var/tmp/portage/x11-base/xorg-server-1.17.0/work/xorg-server-1.17.0/include/os.h:92
*/
   ^
Makefile:801: recipe for target 'sdksyms.o' failed

From sdksyms.sh: 
...
topdir=$1   
shift   
LC_ALL=C
export LC_ALL   
${CPP:-cpp} "$@" sdksyms.c > /dev/null || exit $?   
${CPP:-cpp} "$@" sdksyms.c | ${AWK:-awk} -v topdir=$topdir '
BEGIN {
...

[Bug target/64975] [AArch64] Thunderx should not default to crypto enabled

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-02-08
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
.

[Bug ipa/63566] [5 Regression] i686 bootstrap fails: ICE RTL flag check: INSN_UID used with unexpected rtx code 'set' in INSN_UID, at rtl.h:1326

[hubicka at gcc dot gnu.org]

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

--- Comment #12 from Jan Hubicka  ---
Author: hubicka
Date: Sun Feb  8 21:04:41 2015
New Revision: 220520

URL: https://gcc.gnu.org/viewcvs?rev=220520&root=gcc&view=rev
Log:
PR ipa/63566 
* i386.c (ix86_function_regparm): Look through aliases to see if callee
is local and optimized.
(ix86_function_sseregparm): Likewise; also use target's SSE math
settings; error out instead of silently generating wrong code
on mismatches.
(init_cumulative_args): Look through aliases.

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

[Bug ipa/63566] [5 Regression] i686 bootstrap fails: ICE RTL flag check: INSN_UID used with unexpected rtx code 'set' in INSN_UID, at rtl.h:1326

[hubicka at gcc dot gnu.org]

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

--- Comment #13 from Jan Hubicka  ---
Author: hubicka
Date: Sun Feb  8 21:08:44 2015
New Revision: 220521

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

PR ipa/63566 
* ipa-visibility.c (cgraph_node::non_local_p): Accept aliases.
(cgraph_node::local_p): Remove thunk related FIXME.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-visibility.c

[Bug ipa/60871] [4.9 Regression] internal compiler error: in possible_polymorphic_call_targets, at ipa-devirt.c:1510

[hubicka at ucw dot cz]

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

--- Comment #16 from Jan Hubicka  ---
> I just tried gcc-4.9-20150204[1] which seems to have been packaged after your
> commit, and I still get the ICE.
This is probably because I commited the fix to mainline only (GCC-5), I will
backport
it to GCC-4.9

[Bug target/64953] Compiling sourcecode for STM32F103 causes USB errors with some optimization settings

[manuel.reimer at gmx dot de]

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

--- Comment #7 from manuel.reimer at gmx dot de ---
I've tried to find out when the bug first occured.

This one (oldes 4.9 snapshot, I can get) already has the problem:
ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20140302/

And this one (newest 4.8 snapshot) doesn't have the problem:
ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20150129/

Is there any easy way to get snapshots between these two?

[Bug target/64953] Compiling sourcecode for STM32F103 causes USB errors with some optimization settings

[trippels at gcc dot gnu.org]

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

--- Comment #8 from Markus Trippelsdorf  ---
(In reply to manuel.reimer from comment #7)
> I've tried to find out when the bug first occured.
> 
> This one (oldes 4.9 snapshot, I can get) already has the problem:
> ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20140302/
> 
> And this one (newest 4.8 snapshot) doesn't have the problem:
> ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20150129/
> 
> Is there any easy way to get snapshots between these two?

Sure. Just use git or svn and bisect...

[Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs

[ebotcazou at gcc dot gnu.org]

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

--- Comment #31 from Eric Botcazou  ---
The test also fails on PowerPC, the 2 IVs are kept by ivopts.

[Bug target/64953] Compiling sourcecode for STM32F103 causes USB errors with some optimization settings

[manuel.reimer at gmx dot de]

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

--- Comment #9 from manuel.reimer at gmx dot de ---
The two commits are in different branches. How to bisect in this case?

[Bug c++/64970] Hard error instead of SFINAE for expression in nested template alias

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-02-08
 CC||ville.voutilainen at gmail dot 
com
 Ever confirmed|0   |1
  Known to fail||4.8.2, 4.9.1, 5.0

--- Comment #1 from Ville Voutilainen  ---
Clang accepts the code without a hard error.

[Bug c++/64959] SFINAE in UDLs

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-02-08
 CC||ville.voutilainen at gmail dot 
com
 Ever confirmed|0   |1
  Known to fail||4.8.2, 4.9.1, 5.0

[Bug ipa/61548] [5 Regression] FAIL: gcc.dg/tls/alias-1.c

[hubicka at gcc dot gnu.org]

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

--- Comment #26 from Jan Hubicka  ---
Hmm, emutls_foo is added to symtab twice and therefore it is also output twice.
__emutls_v.foo/6 (__emutls_v.foo) @0x76973300   
  Type: variable definition analyzed
  Visibility: externally_visible public artificial  
  next sharing asm name: 4  
  References:   
  Referring: __emutls_v.bar/7 (alias)   
  Availability: available   
  Varpool flags: initialized tls-emulated   
__emutls_v.foo/4 (__emutls_v.foo) @0x76973200   
  Type: variable definition analyzed
  Visibility: externally_visible public artificial  
  previous sharing asm name: 6  
  References:   
  Referring:
  Availability: available   
  Varpool flags: initialized tls-emulated

[Bug target/50751] SH Target: Displacement addressing does not work for QImode and HImode

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

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

--- Comment #40 from Oleg Endo  ---
I'd like to close this PR as fixed.  The R0 splill failure issues are problems
on their own, which are just emphasized by QIHImode displacement addressing
insns.

[Bug ipa/61548] [5 Regression] FAIL: gcc.dg/tls/alias-1.c

[hubicka at gcc dot gnu.org]

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

--- Comment #27 from Jan Hubicka  ---
Does the following patch fix the problem?
Index: tree-emutls.c
===
--- tree-emutls.c   (revision 220509)
+++ tree-emutls.c   (working copy)
@@ -753,17 +753,19 @@ ipa_lower_emutls (void)
   cgraph_node *func;
   bool any_aliases = false;
   tree ctor_body = NULL;
-
+  hash_set  visited;
   auto_vec  tls_vars;

   /* Examine all global variables for TLS variables.  */
   FOR_EACH_VARIABLE (var)
-if (DECL_THREAD_LOCAL_P (var->decl))
+if (DECL_THREAD_LOCAL_P (var->decl)
+   && !visited.add (var))
   {
gcc_checking_assert (TREE_STATIC (var->decl)
 || DECL_EXTERNAL (var->decl));
tls_vars.safe_push (var);
-   if (var->alias && var->definition)
+   if (var->alias && var->definition
+   && !visited.add (var->ultimate_alias_target ()))
  tls_vars.safe_push (var->ultimate_alias_target ());
   }

[Bug target/64971] [5 Regression] gcc.c-torture/compile/pr37433.c ICEs with -mabi=ilp32

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Created attachment 34697
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34697&action=edit
Patch which I am testing right now

Fix gcc.c-torture/compile/pr37433.c for AARCH64:ILP32.

The problem here is that we get a symbol_ref which is SImode
but for the sibcall patterns we only match symbol_refs which
use DImode.

OK?  Bootstrapped and tested on aarch64-linux-gnu with no regressions.

Thanks,
Andrew Pinski

* config/aarch64/aarch64.md (sibcall): Force operands[0]'s
address to be DImode for ILP32.
(sibcall_value): Likewise.

* gcc.c-torture/compile/pr37433-1.c: New testcase.

[Bug c++/64977] New: GCC incorrectly rejects constexpr variable definition.

[ytj000 at gmail dot com]

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

Bug ID: 64977
   Summary: GCC incorrectly rejects constexpr variable definition.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ytj000 at gmail dot com

struct A {
constexpr operator int() const { return 0; }
};

int main() {
A a{};
constexpr int b = a; // ok
[a]() { constexpr int b = a; };  // ok

// error: the value of 'a' is not usable in a constant expression
[&a]() { constexpr int b = a; }; 
}

GCC doesn't compile, clang compiles. (with -std=c++11)

[Bug rtl-optimization/64916] [5 regression] ira.c update_equiv_regs patch causes gcc/testsuite/gcc.target/arm/pr43920-2.c regression

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

Version|unknown |5.0
   Target Milestone|--- |5.0
Summary|[5.0 regression] ira.c  |[5 regression] ira.c
   |update_equiv_regs patch |update_equiv_regs patch
   |causes  |causes
   |gcc/testsuite/gcc.target/ar |gcc/testsuite/gcc.target/ar
   |m/pr43920-2.c regression|m/pr43920-2.c regression

[Bug libstdc++/64443] [5 Regression] New std::string implementation breaks tests on AArch64.

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |5.0
Summary|[5.0 Regression] New|[5 Regression] New
   |std::string implementation  |std::string implementation
   |breaks tests on AArch64.|breaks tests on AArch64.

[Bug middle-end/64491] [5 Regression] incorrect warning: loop exit may only be reached after undefined behavior

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |5.0

[Bug ipa/64813] [5 Regression] 23_containers/unordered_map/requirements/explicit_instantiation/[2,4].cc iCEs

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |5.0

[Bug middle-end/64909] [4.8/5 regression] Missed vectorization

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |5.0

[Bug target/64930] [5 regression] FAIL: gcc.target/powerpc/atomic-p7.c scan-assembler-times isync 12

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |5.0
Summary|[5.0 regression] FAIL:  |[5 regression] FAIL:
   |gcc.target/powerpc/atomic-p |gcc.target/powerpc/atomic-p
   |7.c scan-assembler-times|7.c scan-assembler-times
   |isync 12|isync 12

[Bug rtl-optimization/64921] [4.9/5 Regression] FAIL: gfortran.dg/class_allocate_18.f90

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |5.0

[Bug target/64938] [4.9 Regression] ICE in symtab_remove_unreachable_nodes, at ipa.c:547 on arm-linux-gnueabihf

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
Fixed.

[Bug libstdc++/64967] [5 Regression] Bootstrap fails due to errors in libstdc++ sources with `--enable-symvers=gnu-versioned-namespace'

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |5.0

[Bug target/64971] [5 Regression] gcc.c-torture/compile/pr37433.c ICEs with -mabi=ilp32

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-02-09
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
   Target Milestone|--- |5.0
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
Mine.

[Bug target/61578] [4.9/5 regression] Code size increase for ARM thumb compared to 4.8.x when compiling with -Os

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.3
Summary|[4.9/ 5 regression] Code|[4.9/5 regression] Code
   |size increase for ARM thumb |size increase for ARM thumb
   |compared to 4.8.x when  |compared to 4.8.x when
   |compiling with -Os  |compiling with -Os

[Bug preprocessor/55115] [>=4.5.0 regression] missing headers as fatal breaks cproto logic

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED
 Ever confirmed|1   |0

[Bug middle-end/51017] GCC 4.6 performance regression (vs. 4.4/4.5)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #8 from Andrew Pinski  ---
Can you try GCC 4.9?

[Bug target/45389] CPU2006 cactusADM: gcc 4.6 15% regression from 4.5

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Is this still true with GCC 4.9 or the trunk?

[Bug debug/53770] Regression: incorrect line numbers in debug info since 4.5+

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Is this still true with GCC 4.9 or the trunk?

[Bug target/45390] CPU2006 434.zeusmp: gcc 4.6 7% regression from gcc 4.5

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Is this still true with GCC 4.9 or the trunk?

[Bug target/45391] CPU2006 482.sphinx3: gcc4.6 5% regression from prefetching of vectorized loop

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #6 from Andrew Pinski  ---
Is this still true with GCC 4.9 or the trunk?

[Bug target/64941] -O3 breaks tar

[brian at soulspark dot org]

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

--- Comment #3 from Brian M  ---
I tried sussing the flags for my march and mtune native, but didn't have any
luck (sorry, I'm mostly hardware, not software).

The best I can do is tell you what processor I'm running:

processor   : 3
vendor_id   : GenuineIntel
cpu family  : 6
model   : 60
model name  : Intel(R) Core(TM) i5-4590 CPU @ 3.30GHz

[Bug middle-end/62247] [5 Regression] FAIL: g++.dg/abi/anon3.C -std=c++98 scan-assembler .weak(_definition)

[danglin at gcc dot gnu.org]

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

--- Comment #7 from John David Anglin  ---
Introduced in r214176:
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=214177

[Bug libstdc++/64443] [5 Regression] New std::string implementation breaks tests on AArch64.

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Are these still failing?

[Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs

[amker at gcc dot gnu.org]

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

--- Comment #32 from amker at gcc dot gnu.org ---
(In reply to dave.anglin from comment #30)
> On 2015-02-08, at 9:09 AM, amker at gcc dot gnu.org wrote:
> 
> > Ah, candidate 5 is considered cheaper according to the cost table.
> 
> Is this a problem with insn costs, or a problem in the estimation of the
> total cost
> for each candidate?
The total cost I think.  Cost in IVOPT is tricky and inaccurate since 1) it
needs to estimate cost of RTL on gimple IR; 2) The rtx expression cost is
computed together with address expression cost, which doesn't happen in other
part of GCC.  
I can try to make the case less vulnerable for now.  Should we consider this as
a missed optimization since GCC never did the optimization for the case before
(and still not for mentioned targets)?

Thanks,
bin
> 
> Dave
> --
> John David Anglin dave.ang...@bell.net

[Bug ipa/61548] [5 Regression] FAIL: gcc.dg/tls/alias-1.c

[hp at gcc dot gnu.org]

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

--- Comment #28 from Hans-Peter Nilsson  ---
(In reply to Jan Hubicka from comment #27)
> Does the following patch fix the problem?

Yes! Full regtest is underway but this particular FAIL is fixed.  Thanks.

[Bug target/64953] Compiling sourcecode for STM32F103 causes USB errors with some optimization settings

[trippels at gcc dot gnu.org]

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

--- Comment #10 from Markus Trippelsdorf  ---
(In reply to manuel.reimer from comment #9)
> The two commits are in different branches. How to bisect in this case?

gcc's history is linear in git. So you could start with a 
bad commit on 20140302 and go back a year and use e.g. a commit on 
20130302 as good.

(Or you could wait until an ARM guy takes a look at this bug...)

[Bug target/64975] [AArch64] Thunderx should not default to crypto enabled

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |WONTFIX

--- Comment #2 from Andrew Pinski  ---
It turns out I was mistaken that some ThunderX would not have the crypto
instructions.  So closing as won't fix.

[Bug target/64971] [5 Regression] gcc.c-torture/compile/pr37433.c ICEs with -mabi=ilp32

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||patch
URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2015-02/msg00502.ht
   ||ml

--- Comment #3 from Andrew Pinski  ---
Patch posted:
https://gcc.gnu.org/ml/gcc-patches/2015-02/msg00502.html

[Bug ipa/64978] New: [5 Regression] ICE: in ipcp_verify_propagated_values, at ipa-cp.c:1060

[trippels at gcc dot gnu.org]

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

Bug ID: 64978
   Summary: [5 Regression] ICE: in ipcp_verify_propagated_values,
at ipa-cp.c:1060
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org

Honza's patches from today break Firefox LTO build on ppc64:

trippels@gcc2-power8 makeconv % /home/trippels/gcc_test/usr/local/bin/c++ -fPIC
-Wall -Wempty-body -Woverloaded-virtual -Wsign-compare -Wwrite-strings
-Werror=endif-labels -Werror=int-to-pointer-cast -Werror=missing-braces
-Werror=pointer-arith -Werror=return-type -Werror=sequence-point
-Werror=unused-label -Werror=trigraphs -Werror=type-limits
-Wno-invalid-offsetof -Wcast-align -flto=80 --param lto-partitions=80
-fno-semantic-interposition -fdevirtualize-at-ltrans -mcpu=power8
-ffunction-sections -fdata-sections -fno-exceptions -fno-strict-aliasing -frtti
-fno-exceptions -fno-math-errno -std=gnu++0x -pthread -pipe -UDEBUG -DNDEBUG
-O3 -DU_STATIC_IMPLEMENTATION -fvisibility=hidden -W -Wall -pedantic
-Wpointer-arith -Wwrite-strings -Wno-long-long -Wno-unused
-Wno-unused-parameter -lpthread
-Wl,--hash-style=gnu,--as-needed,--gc-sections,--icf=all -Wl,-z,noexecstack
-Wl,-z,text -Wl,--build-id -Wl,--gc-sections -o ../../bin/makeconv makeconv.o
ucnvstat.o genmbcs.o gencnvex.o -L../../lib -licutu -L../../lib -licui18n
-L../../lib -licuuc -L../../stubdata -licudata -lpthread -ldl -lm
lto1: internal compiler error: in ipcp_verify_propagated_values, at
ipa-cp.c:1060
0x10d1bbef ipcp_verify_propagated_values()
../../gcc/gcc/ipa-cp.c:1060
0x10d1dcfb ipcp_propagate_stage
../../gcc/gcc/ipa-cp.c:2761
0x10d1dcfb ipcp_driver
../../gcc/gcc/ipa-cp.c:4410
0x10d1dcfb execute
../../gcc/gcc/ipa-cp.c:4505
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: fatal error: /home/trippels/gcc_test/usr/local/bin/c++ returned 1
exit status
compilation terminated.
/home/trippels/bin/ld: fatal error: lto-wrapper failed
collect2: error: ld returned 1 exit status

[Bug ipa/64978] [5 Regression] ICE: in ipcp_verify_propagated_values, at ipa-cp.c:1060

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |5.0

[Bug bootstrap/64976] Bootstrap fails with -O3 -fgraphite-identity

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
With such non-standard bootstrap flags you should use --disable-werror, we
don't guarantee no warnings for all possible command line switches.
At least looking at the first warning, it is a clear false positive.

[Bug ipa/64978] [5 Regression] ICE: in ipcp_verify_propagated_values, at ipa-cp.c:1060

[trippels at gcc dot gnu.org]

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

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

[Bug ipa/64978] [5 Regression] ICE: in ipcp_verify_propagated_values, at ipa-cp.c:1060

[trippels at gcc dot gnu.org]

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

--- Comment #1 from Markus Trippelsdorf  ---
Created attachment 34698
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34698&action=edit
ipa-cp-dump


...
182467 IPA lattices after constant propagation, before gcc_unreachable: 
182468  
182469 Lattices:
182470   Node: __deleting_dtor /202322: 
182471 param [0]: BOTTOM
182472  ctxs: BOTTOM
182473  Alignment unusable  
182474 AGGS BOTTOM