[Bug ada/64712] [5 Regression] FAIL: gnat.dg/unchecked_convert1.adb execution test (x86_64/-m32)

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed|2015-01-22 00:00:00 |2015-01-23
 Ever confirmed|0   |1

--- Comment #7 from Eric Botcazou  ---
It's an uninitialized local variable.

[Bug ada/64712] [5 Regression] FAIL: gnat.dg/unchecked_convert1.adb execution test (x86_64/-m32)

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ebotcazou at gcc dot 
gnu.org

[Bug fortran/60922] [4.9/5 Regression] Memory leak with allocatable CLASS components

[janus at gcc dot gnu.org]

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

--- Comment #12 from janus at gcc dot gnu.org ---
Author: janus
Date: Fri Jan 23 08:32:09 2015
New Revision: 220029

URL: https://gcc.gnu.org/viewcvs?rev=220029&root=gcc&view=rev
Log:
2015-01-23  Janus Weil  

PR fortran/60922
* class.c (finalize_component): Apply the check for 'fini_coarray' only
to coarray components.

2015-01-23  Janus Weil  

PR fortran/60922
* gfortran.dg/class_allocate_17.f90: New.

Added:
trunk/gcc/testsuite/gfortran.dg/class_allocate_17.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/class.c
trunk/gcc/testsuite/ChangeLog

[Bug driver/64740] New: ld called with -plugin-opt=-fresolution=-plugin-opt=-debug.res

[vries at gcc dot gnu.org]

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

Bug ID: 64740
   Summary: ld called with
-plugin-opt=-fresolution=-plugin-opt=-debug.res
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org

I.

When doing lto using a single gcc invocation:
...
$install/bin/gcc $src/libgomp/testsuite/libgomp.c/target-9.c \
  -Wl,-rpath=$install/lib64 \
  -flto -ftree-parallelize-loops=0 -fopenmp \
  -o ./a.out \
  $verboseflags
...

for different verboseflags, we get the following plugin-opt args for ld:

1. -v -Wl,-v -Wl,-plugin-opt=-debug

-plugin-opt=-fresolution=/tmp/cc3WBKNB.res -plugin-opt=-debug

2. -v -Wl,-v -save-temps 

-plugin-opt=-fresolution=target-9.res

3. -v -Wl,-v -Wl,-plugin-opt=-debug -save-temps

-plugin-opt=-fresolution=target-9.res -plugin-opt=-debug

Those results look as expected.


II.

When doing lto using a two gcc invocations:
...
$install/bin/gcc $src/libgomp/testsuite/libgomp.c/target-9.c \
  -Wl,-rpath=$install/lib64 \
  -flto -ftree-parallelize-loops=0 -fopenmp \
  -c -o obj.o
$install/bin/gcc obj.o -Wl,-rpath=$install/lib64 \
  -flto -ftree-parallelize-loops=0 \
  -o ./a.out \
  $verboseflags

for different verboseflags, we get the following plugin-opt args for ld:

1. -v -Wl,-v -Wl,-plugin-opt=-debug

-plugin-opt=-fresolution=/tmp/ccCYQEcq.res -plugin-opt=-debug

2. -v -Wl,-v -save-temps 

-plugin-opt=-fresolution=-v.res

3. -v -Wl,-v -Wl,-plugin-opt=-debug -save-temps

-plugin-opt=-fresolution=-plugin-opt=-debug.res -plugin-opt=-debug

The last two don't seem intentional to me. We're using an intermediate file
starting with an option name.

Still the compilation succeeds without any problems.

[Bug driver/64740] ld called with -plugin-opt=-fresolution=-plugin-opt=-debug.res

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P5
   Severity|normal  |trivial

[Bug libgomp/64672] ICEs in libgomp.oacc-fortran when using the '-g -flto' options in the test suite.

[rguenther at suse dot de]

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

--- Comment #20 from rguenther at suse dot de  ---
On Thu, 22 Jan 2015, vries at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64672
> 
> --- Comment #17 from vries at gcc dot gnu.org ---
> (In reply to rguent...@suse.de from comment #13)
> > On Wed, 21 Jan 2015, vries at gcc dot gnu.org wrote:
> > > tentative patch, adding flag_ltrans || flag_wpa to the GOACC builtin guard
> > > conditions
> > 
> > Would be in_lto_p instead.
> > 
> 
> That actually doesn't work. in_lto_p is still false at the time when
> lto_define_builtins is called.

Huh, interesting - we should probably fix that and do in_lto_p = true
as the very first thing in lto_init.

[Bug tree-optimization/64365] [4.9 Regression] Predictive commoning after loop vectorization produces incorrect code.

[rguenther at suse dot de]

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

--- Comment #11 from rguenther at suse dot de  ---
On Thu, 22 Jan 2015, brooks at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64365
> 
> Brooks Moses  changed:
> 
>What|Removed |Added
> 
>  CC||brooks at gcc dot gnu.org
> 
> --- Comment #10 from Brooks Moses  ---
> Richard, are you expecting to backport this to the 4.9 branch as well?

Yes, I will do that after I'm sure there isn't any fallout (that
is, it will make the next release at least)

[Bug go/64738] go, gofmt and cgo binaries linked statically

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-01-23
 Ever confirmed|0   |1

--- Comment #4 from Richard Biener  ---
Confirmed. -static-libgo indeed is undesirable.

[Bug driver/64737] [5 Regression] gcc -v print extra blank line

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |5.0

[Bug c++/59766] c++1y: declaring friend function with 'auto' return type deduction is rejected with bogus reason

[potswa at mac dot com]

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

--- Comment #5 from David Krauss  ---
Created attachment 34538
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34538&action=edit
ChangeLog entry

[Bug target/64703] glibc sysdeps/powerpc/powerpc64/dl-machine.h miscompile

[amodra at gmail dot com]

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

--- Comment #7 from Alan Modra  ---
Created attachment 34539
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34539&action=edit
prototype patch

How does this look as a potential fix?  Obviously I'd need to provide the new
targetm field and arrange for it to be set on powerpc64 elfv1, but before I do
that I'd like some indication that this is going in the right direction.

[Bug sanitizer/64741] New: Incorrect size of UBSan type descriptors

[y.gribov at samsung dot com]

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

Bug ID: 64741
   Summary: Incorrect size of UBSan type descriptors
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: y.gribov at samsung dot com
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,
ryabinin.a.a at gmail dot com

Created attachment 34540
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34540&action=edit
Proposed patch

UBSan uses incomplete type for all UBSan type descriptors:
 struct {
   short __typekind;
   short __typeinfo;
   char __typename[];
 };
and this causes DECL_SIZE to return invalid (too short) values for generated
globals. This later causes ASan to report invalid (again, too short) size to
__asan_register_globals when UBSan is enabled together with ASan.

This may not be a problem for userspace (because only libubsan accesses these
descriptors and it's not sanitized) but causes false positives for kernel
(https://lkml.org/lkml/2015/1/22/670).

I attach a silly fix - if it looks more or less fine, I'll do the regtesting
and fw to gcc-patches.

[Bug c++/59766] c++1y: declaring friend function with 'auto' return type deduction is rejected with bogus reason

[potswa at mac dot com]

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

--- Comment #6 from David Krauss  ---
Created attachment 34541
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34541&action=edit
Fix: disable the error for friend declarators.

The fix is simple. Tested and submitted for approval. (I am a registered
contributor.)

I don't suppose this warrants a testcase file. If you want to exercise the
compiler, here is a more interesting case:


template< typename k >
struct t {
friend auto leak( t );

template< typename v >
struct m {
friend auto leak( t ) { return v{}; }
};
};

int main() {
t< int >::m< char > a;
decltype( leak( t< int >{} ) ) b;
static_assert ( sizeof b == 1, "" );

t< int >::m< short > c; // error: redefinition of ‘auto leak(t)’
}

[Bug debug/64511] [5 Regression] ICE at -O3 with -g enabled on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

--- Comment #18 from Jakub Jelinek  ---
Author: jakub
Date: Fri Jan 23 09:47:51 2015
New Revision: 220031

URL: https://gcc.gnu.org/viewcvs?rev=220031&root=gcc&view=rev
Log:
PR debug/64511
* dwarf2out.c (struct dw_loc_descr_node): Add chain_next
GTY markup.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.h

[Bug sanitizer/64742] New: Incorrect size of UBSan type descriptors

[y.gribov at samsung dot com]

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

Bug ID: 64742
   Summary: Incorrect size of UBSan type descriptors
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: y.gribov at samsung dot com
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,
ryabinin.a.a at gmail dot com

Created attachment 34542
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34542&action=edit
Proposed patch

UBSan uses incomplete type for all UBSan type descriptors:
 struct {
   short __typekind;
   short __typeinfo;
   char __typename[];
 };
and this causes DECL_SIZE to return invalid (too short) values for generated
globals. This later causes ASan to report invalid (again, too short) size to
__asan_register_globals when UBSan is enabled together with ASan.

This may not be a problem for userspace (because only libubsan accesses these
descriptors and it's not sanitized) but causes false positives for kernel
(https://lkml.org/lkml/2015/1/22/670).

I attach a silly fix - if it looks more or less fine, I'll do the regtesting
and fw to gcc-patches.

[Bug sanitizer/64742] Incorrect size of UBSan type descriptors

[y.gribov at samsung dot com]

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

Yury Gribov  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Yury Gribov  ---
Dup due to Bugzilla slowliness.

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

[Bug sanitizer/64741] Incorrect size of UBSan type descriptors

[y.gribov at samsung dot com]

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

--- Comment #1 from Yury Gribov  ---
*** Bug 64742 has been marked as a duplicate of this bug. ***

[Bug c/64743] New: minor issue with the location of -Wlong-long

[chengniansun at gmail dot com]

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

Bug ID: 64743
   Summary: minor issue with the location of -Wlong-long
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chengniansun at gmail dot com

The current -Wlong-long points to the location of the second "long", and I
think it will be better if it points to the first "long". 

$: cat s.c
typedef long long ll;
$: 
$: gcc-trunk -c -std=c89 s.c -pedantic
s.c:1:14: warning: ISO C90 does not support ‘long long’ [-Wlong-long]
 typedef long long ll;
  ^
$: 
$: clang-trunk -c -std=c89 s.c -pedantic
s.c:1:9: warning: 'long long' is an extension when C99 mode is not enabled
  [-Wlong-long]
typedef long long ll;
^
1 warning generated.

[Bug libstdc++/64735] std::future broken on armel

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-01-23
 CC||ramana at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||4.9.0, 4.9.1, 4.9.2, 5.0

--- Comment #1 from Ramana Radhakrishnan  ---
Confirmed with -march=armv5te on all platforms. The only thing I can think of
off the top of my head that is different for armv5te compared to armv7-a is
that on armv5te we end up going through the kernel helper function for all
atomic and sync type operations, there is no inlining and maybe that's what is
broken in some sense here. 

Would help for some comments from a libstdc++ / C++ person.

[Bug libstdc++/64735] std::future broken on armel

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
I think this is expected, the std:future type and std::async function are
declared unconditionally, but the definitions are guarded by:

#if defined(_GLIBCXX_HAS_GTHREADS) && defined(_GLIBCXX_USE_C99_STDINT_TR1) \
  && (ATOMIC_INT_LOCK_FREE > 1)

If your target doesn't meet those conditions then you don't get to use
std::future

[Bug libstdc++/64735] std::future broken on armel

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
i.e. it's not broken, it's missing, and that's by design.

[Bug target/64580] very high rs6000_stack_info() usage during LTO Firefox build on ppc64

[trippels at gcc dot gnu.org]

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

--- Comment #8 from Markus Trippelsdorf  ---
The issue is also reproducible with an --enable-checking=release compiler.

The following command reproduces the issue using r220030 on gcc110:

/home/trippels/gcc_5/usr/local/bin/../libexec/gcc/powerpc64-unknown-linux-gnu/5.0.0/lto1
-quiet -dumpbase libxul.so.ltrans7.o -mcpu=power7 -auxbase-strip /dev/null -O3
-version -fPIC -fno-exceptions -fltrans /var/tmp/libxul.so.ltrans7.o -o
/dev/null

[Bug libgomp/64672] ICEs in libgomp.oacc-fortran when using the '-g -flto' options in the test suite.

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |vries at gcc dot gnu.org

[Bug libgomp/64707] FAIL: libgomp.c/target-9.c with -ftree-parallelize-loops=0

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-01-23
   Assignee|unassigned at gcc dot gnu.org  |vries at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug target/58489] ICE: in reload_cse_simplify_operands, at postreload.c:411

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-01-23
 CC||ramana at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Ramana Radhakrishnan  ---
(In reply to Timo Teräs from comment #2)
> I got this fixed. It seems genautomata does not work properly if it is built
> with -fPIC. Since PIE/PIC get added automatically in alpine toolchain it
> caused this.
> 
> For now I'm adding explicitly -fno-PIC to genautomata compilation. However,
> it would be better if genautomata could be fixed to:
>  - abort compilation if genautomata failed to do it's job properly
>  - fix genautomata to work even if compiled with -fPIC

Interesting observation and interesting that the "broken automaton" managed to
build the whole of gcc and the run time support libraries in gcc and presumably
glibc. 

If it was genautomata that doesn't work properly when built with PIC can you
reduce the failure point in genautomata. Without more details or better input
testcases it's very hard to reduce this in any other way or form especially as
I cannot reproduce the issue with a new top of tree 4.8 toolchain.

[Bug target/58486] insufficient CFI generated for call-saved VFP registers

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-01-23
 CC||ramana at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug c++/64727] [5 Regression] g++.dg/torture/darwin-cfstring-3.C:11:80: internal compiler error: Segmentation fault: 11

[dominiq at lps dot ens.fr]

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

--- Comment #13 from Dominique d'Humieres  ---
(In reply to Jason Merrill from comment #11)
> This seems to be because darwin_build_constant_cfstring uses CONST_DECL for
> a global variable, and the C++ front end expects CONST_DECL to be used only
> for enumerators.

An error would be better than an ICE.

For the record, there are also several similar ICEs in the obj-c++ tests:

FAIL: obj-c++.dg/strings/const-str-5.mm -fnext-runtime (internal compiler
error)
FAIL: obj-c++.dg/strings/strings-1.mm -fnext-runtime (internal compiler error)
FAIL: obj-c++.dg/torture/strings/const-cfstring-1.mm   -O0  -fnext-runtime
(internal compiler error)
FAIL: obj-c++.dg/torture/strings/const-cfstring-3.mm   -O0  -fnext-runtime
(internal compiler error)
FAIL: obj-c++.dg/torture/strings/const-cfstring-4.mm   -O*  -fnext-runtime
(internal compiler error)
FAIL: obj-c++.dg/torture/strings/const-str-10.mm   -O*  -fnext-runtime
(internal compiler error)
FAIL: obj-c++.dg/torture/strings/const-str-11.mm   -O*  -fnext-runtime
(internal compiler error)
FAIL: obj-c++.dg/torture/strings/const-str-8.mm   -O*  -fnext-runtime (internal
compiler error)
FAIL: obj-c++.dg/torture/strings/const-str-9.mm   -O*  -fnext-runtime (internal
compiler error)

[Bug c++/64735] std::future broken on armel

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

  Component|libstdc++   |c++

--- Comment #4 from Ramana Radhakrishnan  ---
(In reply to Jonathan Wakely from comment #3)
> i.e. it's not broken, it's missing, and that's by design.

Right so if I parse that correctly, it boils down to implementation of atomics
with calls to kernel helper function vs the lack of it IIUC. Not really a
libstdc++ issue but more of an issue with the way in which atomics are
implemented on arch's that don't have the actual instruction support but are
implemented through kernel helper functions.

It appears as though this breaks quite a few packages on older versions of the
architecture so that's interesting.

Ramana

[Bug target/64231] [5 Regression] SIGSEGV building glibc on aarch64-linux-gnu from r217852

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|WAITING |NEW

[Bug driver/64737] [5 Regression] gcc -v print extra blank line

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Created attachment 34543
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34543&action=edit
gcc5-pr64737.patch

I think we need this.  The extra blank line is desirable in the -freport-bug
dumps.

[Bug rtl-optimization/57462] ira-costs considers only a single register at a time

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Target|arm |arm, aarch64
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-01-23
 Ever confirmed|0   |1

--- Comment #4 from Ramana Radhakrishnan  ---
This probably applies to A64 as well where we need to choose between the GP and
the SIMD registers for some of the SISD type operations.

[Bug tree-optimization/56139] unmodified static data could go in .rodata, not .data

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-01-23
 CC||ramana at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||4.9.0, 5.0

--- Comment #1 from Ramana Radhakrishnan  ---
If it worked in 4.6 then this is a regression, no ? don't have a 4.6 tree handy
to check it but ...

[Bug testsuite/63439] [5 Regression] FAIL: gcc.dg/vect/vect-33.c scan-tree-dump vect "Alignment of access forced using peeling"

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
So arm uses v16qi, but:

/* { dg-final { scan-tree-dump "Alignment of access forced using peeling"
"vect" { target { vector_alignment_reachable && vect64 } } } } */

so arm also is vect64 (v16qi is 128 bits).  arm vectorizes with v16qi and
unaligned accesses.  But

/* { dg-final { scan-tree-dump "Vectorizing an unaligned access" "vect" {
target { vect_hw_misalign && { ! vect64 } } } } } */

so the issue is that we don't have a vect128 target capability as if
vect_hw_misaling && vect128 we'd expect to vectorize an unaligned access.
Only if vect64 && !vect128 we'd expect to peel for alignment.

Luckily we have vect_multiple_sizes so I can adjust it for arm using that.


For SPARC we use v8qi and peel for alignment.  That should be handled
but it looks like SPARC is not vect64 for whatever reason :/

Rainer, can you please make SPARC vect64?


So I expect

Index: testsuite/gcc.dg/vect/vect-33.c
===
--- testsuite/gcc.dg/vect/vect-33.c (revision 220030)
+++ testsuite/gcc.dg/vect/vect-33.c (working copy)
@@ -38,7 +38,7 @@ int main (void)


 /* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect"  } } */
-/* { dg-final { scan-tree-dump "Vectorizing an unaligned access" "vect" {
target { vect_hw_misalign && { ! vect64 } } } } } */
-/* { dg-final { scan-tree-dump "Alignment of access forced using peeling"
"vect" { target { vector_alignment_reachable && vect64 } } } } */
+/* { dg-final { scan-tree-dump "Vectorizing an unaligned access" "vect" {
target { vect_hw_misalign && { {! vect64} || vect_multiple_sizes } } } } } */
+/* { dg-final { scan-tree-dump "Alignment of access forced using peeling"
"vect" { target { vector_alignment_reachable && { vect64 && {!
vect_multiple_sizes} } } } } } */
 /* { dg-final { scan-tree-dump-times "Alignment of access forced using
versioning" 1 "vect" { target { { {! vector_alignment_reachable} || {! vect64}
} && {! vect_hw_misalign} } } } } */
 /* { dg-final { cleanup-tree-dump "vect" } } */

to fix it for arm and also work for fixed SPARC.

[Bug fortran/60255] [OOP] Deferred character length variable at (1) cannot yet be associated with unlimited polymorphic entities

[vehre at gmx dot de]

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

Andre Vehreschild  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
Version|4.9.0   |5.0
 Resolution|--- |FIXED

--- Comment #8 from Andre Vehreschild  ---
Fixed with r219827.

[Bug middle-end/64744] New: ARM: gcc internal compiler error: in store_field, at expr.c:6659

[coopht at gmail dot com]

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

Bug ID: 64744
   Summary: ARM: gcc internal compiler error: in store_field, at
expr.c:6659
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: coopht at gmail dot com

Created attachment 34544
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34544&action=edit
Test to reproduce ICE on gcc's trunk

ICE occured while compiling attach like this:
./cc1 -O0 test_segfault_array.c

Reproduced on:

svn+ssh://gcc.gnu.org/svn/gcc/trunk@220028


Backtrace:
test_segfault_array.c: In function 'foo':
test_segfault_array.c:4:10: internal compiler error: in store_field, at
expr.c:6659
 char a [2] = {0};
  ^
0x92a415 store_field
/mnt/staff/compiler/gcc-head/src/gcc/gcc/expr.c:6659
0x9236e5 expand_assignment(tree_node*, tree_node*, bool)
/mnt/staff/compiler/gcc-head/src/gcc/gcc/expr.c:5000
0x7f0544 expand_gimple_stmt_1
/mnt/staff/compiler/gcc-head/src/gcc/gcc/cfgexpand.c:3398
0x7f0958 expand_gimple_stmt
/mnt/staff/compiler/gcc-head/src/gcc/gcc/cfgexpand.c:3494
0x7f7afa expand_gimple_basic_block
/mnt/staff/compiler/gcc-head/src/gcc/gcc/cfgexpand.c:5407
0x7f9519 execute
/mnt/staff/compiler/gcc-head/src/gcc/gcc/cfgexpand.c:6016
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug testsuite/63439] [5 Regression] FAIL: gcc.dg/vect/vect-33.c scan-tree-dump vect "Alignment of access forced using peeling"

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Fri Jan 23 11:00:10 2015
New Revision: 220033

URL: https://gcc.gnu.org/viewcvs?rev=220033&root=gcc&view=rev
Log:
2015-01-23  Richard Biener  

PR testsuite/63439
* gcc.dg/vect/vect-33.c: Adjust target selectors for v16qi
vectorization on vect64 targets.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/vect-33.c

[Bug testsuite/63439] [5 Regression] FAIL: gcc.dg/vect/vect-33.c scan-tree-dump vect "Alignment of access forced using peeling"

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
So SPARC has

static machine_mode
sparc_preferred_simd_mode (machine_mode mode)
{
  if (TARGET_VIS)
switch (mode)
  {
  case SImode:
return V2SImode;
  case HImode:
return V4HImode;
  case QImode:
return V8QImode;

  default:;
  }

  return word_mode;
}

which means it is unconditionally vect64 (I assume word_mode is DImode).

[Bug fortran/60322] [OOP] Incorrect bounds on polymorphic dummy array

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||vehre at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |vehre at gcc dot gnu.org

[Bug libstdc++/29366] atomics config for sh is weird

[kkojima at gcc dot gnu.org]

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

--- Comment #7 from Kazumoto Kojima  ---
(In reply to Oleg Endo from comment #6)
> The patch works on a default sh-elf/newlib config -- it just uses the
> single-thread fake atomics from libstdc++.  Kaz, could you please try the
> patch on sh4-linux?

I've confirmed that there is no new failures on sh4-unknown-linux-gnu
with it.

[Bug fortran/60289] allocating class(*) pointer as character gives type-spec requires the same character-length parameter

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||vehre at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |vehre at gcc dot gnu.org

[Bug fortran/61275] Invalid initialization expression for ALLOCATABLE component in structure constructor at (1)

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||vehre at gcc dot gnu.org
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |vehre at gcc dot gnu.org

--- Comment #3 from vehre at gcc dot gnu.org ---
Resolved with commit r219801.
Thanks Paul for commiting.

[Bug fortran/60334] Segmentation fault on character pointer assignments

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||vehre at gcc dot gnu.org
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |vehre at gcc dot gnu.org

--- Comment #6 from vehre at gcc dot gnu.org ---
Resolved with commit r219798.

[Bug target/64580] very high rs6000_stack_info() usage during LTO Firefox build on ppc64

[trippels at gcc dot gnu.org]

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

--- Comment #9 from Markus Trippelsdorf  ---
(gdb) bt
#0  0x10a64660 in compute_vrsave_mask () at
../../gcc/gcc/config/rs6000/rs6000.c:21149
#1  rs6000_stack_info () at ../../gcc/gcc/config/rs6000/rs6000.c:21686
#2  0x10a65694 in rs6000_output_function_prologue (file=0x114a5800,
size=) at ../../gcc/gcc/config/rs6000/rs6000.c:24284
#3  0x10320300 in final_start_function (first=,
file=0x114a5800, optimize_p=) at ../../gcc/gcc/final.c:1881
#4  0x10a3cc88 in rs6000_output_mi_thunk (file=0x114a5800,
thunk_fndecl=, delta=, vcall_offset=, 
function=) at ../../gcc/gcc/config/rs6000/rs6000.c:25807
#5  0x1020f5b4 in cgraph_node::expand_thunk (this=this@entry=0xcbb3390,
output_asm_thunks=output_asm_thunks@entry=true, 
force_gimple_thunk=force_gimple_thunk@entry=false) at
../../gcc/gcc/cgraphunit.c:1528
#6  0x10210814 in cgraph_node::assemble_thunks_and_aliases
(this=this@entry=0xcbb3200) at ../../gcc/gcc/cgraphunit.c:1742
#7  0x1021079c in cgraph_node::assemble_thunks_and_aliases
(this=this@entry=0xcbb23f0) at ../../gcc/gcc/cgraphunit.c:1758
#8  0x10210b04 in cgraph_node::expand (this=this@entry=0xcbb23f0) at
../../gcc/gcc/cgraphunit.c:1867
#9  0x102128d8 in expand_all_functions () at
../../gcc/gcc/cgraphunit.c:1940
#10 symbol_table::compile (this=0xa8100a8) at ../../gcc/gcc/cgraphunit.c:2293
#11 0x1015b9a0 in lto_main () at ../../gcc/gcc/lto/lto.c:3457
#12 0x106bc94c in compile_file () at ../../gcc/gcc/toplev.c:594
#13 0x101262a8 in do_compile () at ../../gcc/gcc/toplev.c:2047
#14 toplev::main (this=, argc=15, argv=0xfff00ead8) at
../../gcc/gcc/toplev.c:2144
#15 0x10126c7c in main (argc=, argv=0xfff00ead8) at
../../gcc/gcc/main.c:38

[Bug preprocessor/60570] expression in 'elif' directive mis-diagnosed as error when group will be skipped

[mpolacek at gcc dot gnu.org]

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

--- Comment #9 from Marek Polacek  ---
Author: mpolacek
Date: Fri Jan 23 11:57:43 2015
New Revision: 220035

URL: https://gcc.gnu.org/viewcvs?rev=220035&root=gcc&view=rev
Log:
DR#412
PR preprocessor/60570
* directives.c (do_elif): Don't evaluate #elif conditionals
when they don't need to be.

* gcc.dg/cpp/pr36320.c: Turn dg-error into dg-bogus.
* gcc.dg/cpp/pr60570.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/cpp/pr60570.c
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/cpp/pr36320.c
trunk/libcpp/ChangeLog
trunk/libcpp/directives.c

[Bug preprocessor/60570] expression in 'elif' directive mis-diagnosed as error when group will be skipped

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #10 from Marek Polacek  ---
Fixed for GCC 5.

[Bug tree-optimization/64745] New: Generic vectorization missed opportunities

[rguenth at gcc dot gnu.org]

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

Bug ID: 64745
   Summary: Generic vectorization missed opportunities
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
Target: x86_64-*-*, i?86-*-*

unsigned short a[2], b[2];
void foo (void)
{
  int i;
  for (i = 0; i < 2; ++i)
a[i] = b[i];
}

unsigned char x[4], y[4];
void bar (void)
{
  int i;
  for (i = 0; i < 4; ++i)
x[i] = y[i];
}

vectorizing this on i?86 (without SSE) fails for the first testcase at -O3
because we unroll the loop and SLP refuses to handle the "unaligned" load.
For the 2nd case we loop-vectorize it but apply versioning for alignment.

The alignment checks in the vectorizer do not account for non-vector modes.

If we fix that the first loop fails to SLP vectorize because of bogus
cost calculation:

t.c:6:13: note: Cost model analysis:
  Vector inside of basic block cost: 4
  Vector prologue cost: 0
  Vector epilogue cost: 0
  Scalar cost of basic block: 4
t.c:6:13: note: not vectorized: vectorization is not profitable.

because of the unaligned load/store cost:

t.c:6:13: note: vect_model_load_cost: unaligned supported by hardware.
t.c:6:13: note: vect_model_load_cost: inside_cost = 2, prologue_cost = 0 .
...
t.c:6:13: note: vect_model_store_cost: unaligned supported by hardware.
t.c:6:13: note: vect_model_store_cost: inside_cost = 2, prologue_cost = 0 .

that's a backend bug which doesn't consider !VECTOR_MODE_P vector types
in ix86_builtin_vectorization_cost.  OTOH for SLP vectorization if
the cost is equal we can assume less stmts will be used so eventually
just vectorize anyway if the costs are equal.


The real issue of course is that generic vectorization is not attempted
if a vector ISA is available - but that fails to vectorize the above cases
where SLP vectorization would take care of combining small loads and stores.

So we'd need to support HImode, SImode (and DImode on x86_64) vectorization
sizes which probably comes at a too big cost to consider that though
basic-block vectorization (knowing the size of the loads) could try anyway.
But that needs some re-org of the analysis.

[Bug gcov-profile/64123] [5 Regression] Instrumented Firefox segfaults on start

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WORKSFORME  |---

--- Comment #3 from Martin Liška  ---
Unfortunately, I can still reproduce the problem.

Martin

[Bug tree-optimization/64745] Generic vectorization missed opportunities

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-01-23
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Mine.  The alignment issue is easily fixed (I have a patch), the cost model
issue is, well, a cost model issue also easily fixed.

A big required change is to re-structure basic-block vectorization to
perform SLP analysis independent of vector types/sizes and to vectorize
independent SLP instances separately (allowing different vector
sizes in a BB).

Loop vectorization could also do SLP analysis first (basically splitting it) to
reduce the number of applicable vectorization factors.  Other analysis phases
could also contribute to that and it would also help compile-time to not
re-do dataref and dependence analysis for each size.

[Bug tree-optimization/64745] Generic vectorization missed opportunities

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Created attachment 34545
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34545&action=edit
patch for the alingment issue

[Bug libitm/52482] libitm INVALID MNEMONIC in .S (powerpc asm)

[torvald at gcc dot gnu.org]

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

torvald at gcc dot gnu.org changed:

   What|Removed |Added

 CC||torvald at gcc dot gnu.org

--- Comment #8 from torvald at gcc dot gnu.org ---
Can somebody with access to a powerpc-apple-darwin8 check whether this bug is
still present in SVN trunk?  Thanks!

[Bug libitm/53113] Build fails in x86_avx.cc if AVX disabled by -mno-avx but supported by as

[torvald at gcc dot gnu.org]

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

torvald at gcc dot gnu.org changed:

   What|Removed |Added

 CC||torvald at gcc dot gnu.org

--- Comment #26 from torvald at gcc dot gnu.org ---
(In reply to h...@gcc.gnu.org from comment #24)
> Author: hjl
> Date: Mon Jan 13 19:36:17 2014
> New Revision: 206587
> 
> URL: http://gcc.gnu.org/viewcvs?rev=206587&root=gcc&view=rev
> Log:
> Make sure that -msse/-mavx are appended at the end
> 
>   PR libitm/53113
>   * Makefile.am (x86_sse.lo): Append -msse to CXXFLAGS.
>   (x86_avx.lo): Append -mavx to CXXFLAGS.
>   * Makefile.in: Regenerate.
> 
> Modified:
> trunk/libitm/ChangeLog
> trunk/libitm/Makefile.am
> trunk/libitm/Makefile.in

H.J., can this bug be closed?

[Bug testsuite/63439] [5 Regression] FAIL: gcc.dg/vect/vect-33.c scan-tree-dump vect "Alignment of access forced using peeling"

[ro at gcc dot gnu.org]

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

--- Comment #9 from Rainer Orth  ---
Created attachment 34546
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34546&action=edit
32-bit sparc bb-slp-11.c.135t.slp2

[Bug testsuite/63439] [5 Regression] FAIL: gcc.dg/vect/vect-33.c scan-tree-dump vect "Alignment of access forced using peeling"

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #5 from Richard Biener  ---
[...]
> For SPARC we use v8qi and peel for alignment.  That should be handled
> but it looks like SPARC is not vect64 for whatever reason :/
>
> Rainer, can you please make SPARC vect64?

When I do this, the vect-33.c test now passes, both 32 and 64-bit, but
the other gcc.dg/vect tests refering to vect64 start FAILing instead:

FAIL: gcc.dg/vect/bb-slp-11.c scan-tree-dump-times slp2 "basic block
vectorized"
FAIL: gcc.dg/vect/bb-slp-26.c scan-tree-dump-times slp1 "basic block
vectorized" 1

I'm attaching the 32-bit slp? dumps for reference.

Rainer

[Bug testsuite/63439] [5 Regression] FAIL: gcc.dg/vect/vect-33.c scan-tree-dump vect "Alignment of access forced using peeling"

[ro at gcc dot gnu.org]

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

--- Comment #10 from Rainer Orth  ---
Created attachment 34547
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34547&action=edit
32-bit sparc bb-slp-26.c.129t.slp1

[Bug c++/64735] std::future broken on armel

[bastiaan at bjacques dot org]

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

--- Comment #5 from Bastiaan Jacques  ---
(In reply to Jonathan Wakely from comment #3)
> i.e. it's not broken, it's missing, and that's by design.

So is it the intention of the GCC developers that program writers targeting
such platforms simply avoid these facilities and use std::thread/mutex instead?

[Bug testsuite/63439] [5 Regression] FAIL: gcc.dg/vect/vect-33.c scan-tree-dump vect "Alignment of access forced using peeling"

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #7 from Richard Biener  ---
[...]
> which means it is unconditionally vect64 (I assume word_mode is DImode).

Unless I'm completely mistaken, word_mode is SImode for 32-bit, DImode
for 64-bit.

Rainer

[Bug libitm/53113] Build fails in x86_avx.cc if AVX disabled by -mno-avx but supported by as

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |4.9.0

--- Comment #27 from H.J. Lu  ---
Fixed for 4.9.0.

[Bug middle-end/64734] [4.9/5 Regression] ICE at omp lowering

[jakub at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-01-22
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |4.9.3
Summary|ICE at omp lowering |[4.9/5 Regression] ICE at
   ||omp lowering
 Ever confirmed|0   |1

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords||openmp
 Status|NEW |ASSIGNED
  Component|libgomp |middle-end

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug libgomp/64707] FAIL: libgomp.c/target-9.c with -ftree-parallelize-loops=0

[vries at gcc dot gnu.org]

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

--- Comment #5 from vries at gcc dot gnu.org ---
Author: vries
Date: Fri Jan 23 12:53:55 2015
New Revision: 220037

URL: https://gcc.gnu.org/viewcvs?rev=220037&root=gcc&view=rev
Log:
Make fopenmp an LTO option

2015-01-23  Tom de Vries  

PR libgomp/64707
* lto-opts.c (lto_write_options): Output non-explicit conservative
-fno-openmp.
* lto-wrapper.c (merge_and_complain): Handle merging -fopenmp.
(append_compiler_options): Pass -fopenmp through.

* c.opt (fopenmp): Mark as LTO option.

* lang.opt (fopenmp): Mark as LTO option.

* testsuite/libgomp.c/target-9.c: Add -ftree-parallelize-loops=0 to
dg-options.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c.opt
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/lang.opt
trunk/gcc/lto-opts.c
trunk/gcc/lto-wrapper.c
trunk/libgomp/ChangeLog
trunk/libgomp/testsuite/libgomp.c/target-9.c

[Bug libgomp/64672] ICEs in libgomp.oacc-fortran when using the '-g -flto' options in the test suite.

[vries at gcc dot gnu.org]

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

--- Comment #21 from vries at gcc dot gnu.org ---
Author: vries
Date: Fri Jan 23 12:54:16 2015
New Revision: 220038

URL: https://gcc.gnu.org/viewcvs?rev=220038&root=gcc&view=rev
Log:
Make fopenacc an LTO option

2015-01-23  Tom de Vries  

PR libgomp/64672
* lto-opts.c (lto_write_options): Output non-explicit conservative
-fno-openacc.
* lto-wrapper.c (merge_and_complain): Handle merging -fopenacc.
(append_compiler_options): Pass -fopenacc through.

* c.opt (fopenacc): Mark as LTO option.

* lang.opt (fopenacc): Mark as LTO option.

* testsuite/libgomp.oacc-c-c++-common/abort-5.c: New test.

Added:
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/abort-5.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c.opt
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/lang.opt
trunk/gcc/lto-opts.c
trunk/gcc/lto-wrapper.c
trunk/libgomp/ChangeLog

[Bug testsuite/63439] [5 Regression] FAIL: gcc.dg/vect/vect-33.c scan-tree-dump vect "Alignment of access forced using peeling"

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #8)
> > --- Comment #5 from Richard Biener  ---
> [...]
> > For SPARC we use v8qi and peel for alignment.  That should be handled
> > but it looks like SPARC is not vect64 for whatever reason :/
> >
> > Rainer, can you please make SPARC vect64?
> 
> When I do this, the vect-33.c test now passes, both 32 and 64-bit, but
> the other gcc.dg/vect tests refering to vect64 start FAILing instead:
> 
> FAIL: gcc.dg/vect/bb-slp-11.c scan-tree-dump-times slp2 "basic block
> vectorized"

Using V2SI, but it doesn't support 2 * V2SI -> V4HI VEC_PACK_TRUNC_EXPR.
This means the testcase misses to require vect_pack_trunc.

> FAIL: gcc.dg/vect/bb-slp-26.c scan-tree-dump-times slp1 "basic block
> vectorized" 1

Here it fails to vectorize because the accesses are unaligned.  The testcase
fails to check for vect_hw_misalign.

> I'm attaching the 32-bit slp? dumps for reference.

So 64-bit works fine?

>   Rainer

[Bug tree-optimization/64746] New: Loop with nested load/stores is not vectorized using aggressive if-conversion.

[ysrumyan at gmail dot com]

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

Bug ID: 64746
   Summary: Loop with nested load/stores is not vectorized using
aggressive if-conversion.
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ysrumyan at gmail dot com

Attached simple test-case extracted from important suite is not vectorized even
if 'pragma omp simd' is used since ifcvt_repair_bool_pattern does not remove
all multiple uses and we get the following message:

test.c:11:14: note: bit-precision arithmetic not supported.
test.c:11:14: note: not vectorized: relevant stmt not supported: _ifc__90 =
x1_7 >= 0;

The problem is that statement splitting may introduce other multiple predicate
uses and iterative algorithm should be used.

I attached simple fix which cures the problem.

[Bug testsuite/63439] [5 Regression] FAIL: gcc.dg/vect/vect-33.c scan-tree-dump vect "Alignment of access forced using peeling"

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Biener  ---
Author: rguenth
Date: Fri Jan 23 13:08:32 2015
New Revision: 220039

URL: https://gcc.gnu.org/viewcvs?rev=220039&root=gcc&view=rev
Log:
2015-01-23  Richard Biener  

PR testsuite/63439
* gcc.dg/vect/bb-slp-11.c: Require vect_pack_trunc.
* gcc.dg/vect/bb-slp-26.c: Require vect_hw_misalign.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/bb-slp-11.c
trunk/gcc/testsuite/gcc.dg/vect/bb-slp-26.c

[Bug testsuite/63439] [5 Regression] FAIL: gcc.dg/vect/vect-33.c scan-tree-dump vect "Alignment of access forced using peeling"

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #12 from Richard Biener  ---
[...]
>> I'm attaching the 32-bit slp? dumps for reference.
>
> So 64-bit works fine?

Unfortunately not.  I'll attach the dumps, too.

Rainer

[Bug tree-optimization/64746] Loop with nested load/stores is not vectorized using aggressive if-conversion.

[ysrumyan at gmail dot com]

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

--- Comment #1 from Yuri Rumyantsev  ---
Created attachment 34548
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34548&action=edit
test-case to reproduce.

Need to compile this test on x86 with option
  -O3 -fopenmp -march=core-avx2

[Bug testsuite/63439] [5 Regression] FAIL: gcc.dg/vect/vect-33.c scan-tree-dump vect "Alignment of access forced using peeling"

[ro at gcc dot gnu.org]

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

--- Comment #15 from Rainer Orth  ---
Created attachment 34549
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34549&action=edit
64-bit sparc bb-slp-11.c.135t.slp2

[Bug testsuite/63439] [5 Regression] FAIL: gcc.dg/vect/vect-33.c scan-tree-dump vect "Alignment of access forced using peeling"

[ro at gcc dot gnu.org]

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

--- Comment #16 from Rainer Orth  ---
Created attachment 34550
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34550&action=edit
64-bit sparc bb-slp-26.c.129t.slp1

[Bug tree-optimization/64746] Loop with nested load/stores is not vectorized using aggressive if-conversion.

[ysrumyan at gmail dot com]

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

--- Comment #2 from Yuri Rumyantsev  ---
Created attachment 34551
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34551&action=edit
proposed patch

Patch to cure vectorization issue.

[Bug target/64580] very high rs6000_stack_info() usage during LTO Firefox build on ppc64

[trippels at gcc dot gnu.org]

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

--- Comment #10 from Markus Trippelsdorf  ---
Created attachment 34552
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34552&action=edit
callgrind_annotate output

Output of "callgrind_annotate --tree=both callgrind.out.47690 >| out" is
attached.

[Bug c/64747] New: OpenACC: Rejects "gang()" in acc loop/kernels

[burnus at gcc dot gnu.org]

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

Bug ID: 64747
   Summary: OpenACC: Rejects "gang()" in acc loop/kernels
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Keywords: openacc, rejects-valid
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: tschwinge at gcc dot gnu.org

Example is the code
https://github.com/parallel-forall/code-samples/tree/master/posts/002-openacc-example/step3

Compiling the C example fails as follows - the "gang(" looks okay at a glance
and it seems to compile correctly with PGI's compiler. [Additionally, the ME
support seems to be missing.]


gcc -w -fopenacc -I../common *.c -lm
laplace2d.c: In function ‘main’:
laplace2d.c:80:30: error: expected ‘#pragma acc’ clause before ‘(’ token
 #pragma acc kernels loop gang(32), vector(16)
  ^
laplace2d.c:83:22: error: expected ‘#pragma acc’ clause before ‘(’ token
 #pragma acc loop gang(16), vector(32)
  ^
laplace2d.c:96:22: error: expected ‘#pragma acc’ clause before ‘(’ token
 #pragma acc loop gang(16), vector(32)

  ^
laplace2d.c:80:9: sorry, unimplemented: directive not yet implemented
 #pragma acc kernels loop gang(32), vector(16)
 ^
laplace2d.c:93:9: sorry, unimplemented: directive not yet implemented
 #pragma acc kernels loop

[Bug c/64747] OpenACC: Rejects "gang()" in acc loop/kernels

[burnus at gcc dot gnu.org]

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

--- Comment #1 from Tobias Burnus  ---
If compiling the Fortran version, it shows:

 !$acc kernels loop gang(32), vector(16)
   1
Error: Clause GANG conflicts with VECTOR at (1)


Possibly, that's the reason for the (oddly worded) C error message. Given that
PGI supports it, one should re-check whether it is permitted or not. If it is
permitted, also the Fortran FE should be modified.

[Bug c/64748] New: OpenACC: "is not a variable" error with deviceptr()

[burnus at gcc dot gnu.org]

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

Bug ID: 64748
   Summary: OpenACC: "is not a variable" error with deviceptr()
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Keywords: openacc, rejects-valid
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org

From https://github.com/jefflarkin/openacc-interoperability/

The following program seems to compile with PGI's and Cray's compilers. With
GCC, it shows the odd:

foo.c:3:30: error: ‘arr’ is not a variable
 #pragma acc kernels deviceptr(arr)
  ^

void set(int n, float val, float * restrict arr)
{
#pragma acc kernels deviceptr(arr)
  {
for(int i=0; i

[Bug target/64749] New: "truncating" instructions generated instead of a load one using SSE & AVX2 intrinsics

[adrien at guinet dot me]

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

Bug ID: 64749
   Summary: "truncating" instructions generated instead of a load
one using SSE & AVX2 intrinsics
   Product: gcc
   Version: 4.8.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: adrien at guinet dot me

Created attachment 34553
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34553&action=edit
test case

The code attached compiles and runs fine (that is the output of the program is
the good one) using GCC 4.9. When compiled with GCC 4.8, the output is
different and incorrect.

Indeed, when compiled with GCC 4.8, some kind of truncating is introduced at
the begginig of the loop (in f2). Here is the relevant assembly code (output of
GCC 4.8) :

xor eax, eax 
mov rbp, rsp 
and rsp, 0FFE0h
vbroadcastss ymm3, xmm6
add rsp, 10h 
nop dword ptr [rax]

loc_400970:
  vpmovzxwd ymm4, xmmword ptr [rdx+rax*4]
  vpmovzxwd ymm2, xmmword ptr [rcx+rax*4]
  vmovdqa [rsp-8+var_28], ymm4
; truncation here is done
  vmovdqa xmm5, xmmword ptr [rsp-8+var_28]
  vpmulld ymm0, ymm4, ymm2
; here it uses xmm5 which isn't thus the good value.
; xmm5 and ymm4 should be set like with something like this (like GCC 4.9
does): 
; vmovqda xmm5, xmmword ptr [rdx+rax*4]
; vpmovzxwd ymm4, xmm5
  vpmulhuw xmm1, xmm5, xmmword ptr [r8+rax*4]
  vpmovzxwd ymm1, xmm1
  vpmulld ymm1, ymm1, ymm3
  vpsubd  ymm0, ymm0, ymm1
  vmovdqa xmmword ptr [rsi+rax*4], xmm0
  add rax, 8
  cmp rdi, rax 
  ja  short loc_400970

GCC 4.9 indeed behaves correctly and generate this assembly code :

vbroadcastss ymm3, dword ptr [rbp-14h]
xor eax, eax
nop dword ptr [rax+00h]
loc_4009A8: 
  vmovdqa xmm0, xmmword ptr [rdx+rax*4] ; 128-bits load
  vpmulhuw xmm2, xmm0, xmmword ptr [r8+rax*4] ; correctly uses xmm0
  vpmovzxwd ymm2, xmm2 ; 16->32 bits conversion here
  vpmulld ymm2, ymm2, ymm3
  vpmovzxwd ymm1, xmm0
  vpmovzxwd ymm0, xmmword ptr [rcx+rax*4]
  vpmulld ymm0, ymm1, ymm0
  vpsubd  ymm0, ymm0, ymm2
  vmovaps xmmword ptr [rsi+rax*4], xmm0
  add rax, 8
  cmp rdi, rax
  ja  short loc_4009A8

Thanks for any help about this!

P.S: sorry but I didn't manage to have a shorter test case :/

[Bug testsuite/62286] [ARM] 4.9 Regression fails for cortex-m3 for vfp-1.c: fmacs, fmscs, fnmacs, fnmscs

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org,
   ||terry.guo at arm dot com

--- Comment #2 from ktkachov at gcc dot gnu.org ---
(In reply to Ramana Radhakrishnan from comment #1)
> Because the Cortex-M3 doesn't have those instructions ? It's a testism
> probably fixed by an appropriate dg-options values.

It's not a testism, it's a costs issue.
The FP instructions are dictated by the -mfpu option that is given (-mfpu=vfp
is hardcoded in the dg-options here) and in any case Cortex-M3 should support
the vmla instructions as far as I know.
The RTX costs during combine reject the combination of

 vnmul.f32   s15, s14, s15
 vsub.f32s15, s15, s13

into 
 vnmla.f32   s15, s13, s14

for example.
In particular I think it's the mult_addsub cost. A relevant combine log part
is:
Trying 57 -> 58:
Successfully matched this instruction:
(set (reg:SF 134 [ D.4322 ])
(plus:SF (mult:SF (reg:SF 130 [ D.4322 ])
(reg:SF 131 [ D.4322 ]))
(reg:SF 133 [ D.4322 ])))
(plus:SF (mult:SF (reg:SF 130 [ D.4322 ])
(reg:SF 131 [ D.4322 ]))
(reg:SF 133 [ D.4322 ]))

Hot cost: 24 (final)
rejecting combination of insns 57 and 58
original costs 12 + 8 = 20
replacement cost 24

Is it actually beneficial for Cortex-M3 to split this up?

[Bug middle-end/64744] ARM: gcc internal compiler error: in store_field, at expr.c:6659

[jgreenhalgh at gcc dot gnu.org]

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

jgreenhalgh at gcc dot gnu.org changed:

   What|Removed |Added

 Target|aarch64 |arm-none-linux-gnueabihf
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-01-23
 CC||jgreenhalgh at gcc dot gnu.org
   Host|x86_64  |x86_64-unknown-linux-gnu
 Ever confirmed|0   |1

--- Comment #1 from jgreenhalgh at gcc dot gnu.org ---
I can't reproduce this for an AArch64 target.

As far as I can remember, we don't support __attribute__((naked)) for AArch64,
so I would expect the attribute to be ignored (And that is what I see with your
testcase):

gcc foo.c  -O0
foo.c:3:1: warning: ‘naked’ attribute directive ignored [-Wattributes]
 {
 ^

However, I can reproduce your bug with an ARM compiler (cross and native), so
I'll confirm the bug, and update the Target field for you.

[Bug tree-optimization/55177] missed optimizations with __builtin_bswap

[dwmw2 at infradead dot org]

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

--- Comment #15 from David Woodhouse  ---
More missed optimistions (gcc version 4.9.2 20141101 (Red Hat 4.9.2-1) (GCC))

I see it using movbe for the pointer_abuse() function, but can't see a simple
way to make it use movbe *without* killing kittens.

gcc -march=atom -O2 -x c -o - -S - -Wstrict-aliasing data[1] << 16) | (p->data[2] << 8) |
p->data[1];
}

unsigned add(struct pkt *p)
{
return (p->data[0] << 24) + (p->data[1] << 16) + (p->data[2] << 8) +
p->data[1];
}

unsigned pointer_abuse(struct pkt *p)
{
return __builtin_bswap32(*(unsigned *)p->data);
}
EOF

[Bug middle-end/64744] ARM: gcc internal compiler error: in store_field, at expr.c:6659

[coopht at gmail dot com]

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

--- Comment #2 from Alexander Basov  ---
Yep, sorry it's for ARM target.

[Bug middle-end/64744] ARM: gcc internal compiler error: in store_field, at expr.c:6659

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org
  Known to fail||4.8.5, 4.9.3, 5.0

--- Comment #3 from ktkachov at gcc dot gnu.org ---
Confirmed as well on all release branches.

[Bug middle-end/64744] ARM: gcc internal compiler error: in store_field, at expr.c:6659

[coopht at gmail dot com]

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

--- Comment #4 from Alexander Basov  ---
(In reply to ktkachov from comment #3)
> Confirmed as well on all release branches.

Ok, If you have no any objections, I'd like to fix it.

BTW, what gcc should do with such code?

[Bug tree-optimization/55177] missed optimizations with __builtin_bswap

[ubizjak at gmail dot com]

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

--- Comment #16 from Uroš Bizjak  ---
(In reply to David Woodhouse from comment #15)

> {
>   return (p->data[0] << 24) | (p->data[1] << 16) | (p->data[2] << 8) |
> p->data[1];
> }

p->data[3] ?

> unsigned add(struct pkt *p)
> {
>   return (p->data[0] << 24) + (p->data[1] << 16) + (p->data[2] << 8) +
> p->data[1];

... and here?

[Bug sanitizer/64741] Incorrect size of UBSan type descriptors

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
The C FE does for vars with flexible array members with initializers:
  DECL_SIZE (decl)
= size_binop (PLUS_EXPR, DECL_SIZE (decl), TYPE_SIZE (type));
  DECL_SIZE_UNIT (decl)
= size_binop (PLUS_EXPR, DECL_SIZE_UNIT (decl), TYPE_SIZE_UNIT (type));
So what about doing the same (with type replaced by TREE_TYPE (str))?

[Bug c++/64750] New: internal compiler error: in gen_type_die_with_usage, at dwarf2out.c:19486

[zzt13 at software dot nju.edu.cn]

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

Bug ID: 64750
   Summary: internal compiler error: in gen_type_die_with_usage,
at dwarf2out.c:19486
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zzt13 at software dot nju.edu.cn

[Bug middle-end/64744] ARM: gcc internal compiler error: in store_field, at expr.c:6659

[ktkachov at gcc dot gnu.org]

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

--- Comment #5 from ktkachov at gcc dot gnu.org ---
(In reply to Alexander Basov from comment #4)
> (In reply to ktkachov from comment #3)
> > Confirmed as well on all release branches.
> 
> Ok, If you have no any objections, I'd like to fix it.
> 
> BTW, what gcc should do with such code?

Patches welcome :)
Though I note the ICE only happens at -O0 and disappears if you enable any
optimisation.
According to: https://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html
the 'naked' attribute will omit the prologue/epilogue of the function but it's
supposed to be used only with inline asm and C code is not expected to work
reliably. That being said, we should never ICE...

[Bug tree-optimization/55177] missed optimizations with __builtin_bswap

[dwmw2 at infradead dot org]

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

--- Comment #17 from David Woodhouse  ---
Er, yes. Sorry, I originally tried it with uint16_t but it wasn't even using
movbe for the pointer_abuse() function then, so I made it 32-bit instead.
Badly. Come to think of it, the lack of movbe in the 16-bit pointer_abuse()
case is potentially another bug worth fixing.

Here's the corrected test case.

/* gcc -march=atom -O2 -c load_be.c -Wstrict-aliasing -o- -S */
struct pkt {
unsigned char data[10];
};

unsigned or(struct pkt *p)
{
return (p->data[0] << 24) | (p->data[1] << 16) | (p->data[2] << 8) |
p->data[3];
}

unsigned add(struct pkt *p)
{
return (p->data[0] << 24) + (p->data[1] << 16) + (p->data[2] << 8) +
p->data[3];
}

unsigned pointer_abuse(struct pkt *p)
{
return __builtin_bswap16(*(unsigned short *)p->data);
}

[Bug tree-optimization/55177] missed optimizations with __builtin_bswap

[ubizjak at gmail dot com]

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

--- Comment #18 from Uroš Bizjak  ---
(In reply to David Woodhouse from comment #17)

> unsigned or(struct pkt *p)

gcc 5.0 optimizes the above case ...

> unsigned add(struct pkt *p)

... but not this one.  Probably just the case of missing match.pd pattern.

[Bug testsuite/62286] [ARM] 4.9 Regression fails for cortex-m3 for vfp-1.c: fmacs, fmscs, fnmacs, fnmscs

[ramana at gcc dot gnu.org]

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

--- Comment #3 from Ramana Radhakrishnan  ---
(In reply to ktkachov from comment #2)
> (In reply to Ramana Radhakrishnan from comment #1)
> > Because the Cortex-M3 doesn't have those instructions ? It's a testism
> > probably fixed by an appropriate dg-options values.
> 
> It's not a testism, it's a costs issue.
> The FP instructions are dictated by the -mfpu option that is given
> (-mfpu=vfp is hardcoded in the dg-options here) and in any case Cortex-M3
> should support the vmla instructions as far as I know.
> The RTX costs during combine reject the combination of
> 
>  vnmul.f32   s15, s14, s15
>  vsub.f32s15, s15, s13
> 
> into 
>  vnmla.f32   s15, s13, s14
> 
> for example.
> In particular I think it's the mult_addsub cost. A relevant combine log part
> is:
> Trying 57 -> 58:
> Successfully matched this instruction:
> (set (reg:SF 134 [ D.4322 ])
> (plus:SF (mult:SF (reg:SF 130 [ D.4322 ])
> (reg:SF 131 [ D.4322 ]))
> (reg:SF 133 [ D.4322 ])))
> (plus:SF (mult:SF (reg:SF 130 [ D.4322 ])
> (reg:SF 131 [ D.4322 ]))
> (reg:SF 133 [ D.4322 ]))
> 
> Hot cost: 24 (final)
> rejecting combination of insns 57 and 58
> original costs 12 + 8 = 20
> replacement cost 24
> 
> Is it actually beneficial for Cortex-M3 to split this up?

Well, there is no M3 with an FPU and this whole discussion is moot. I don't
think the costs should be changed for this if they reflect reality i.e. the
cost of a libcall for the multiply and cost of a libcall for addition !




Ramana

[Bug middle-end/64734] [4.9/5 Regression] ICE at omp lowering

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 34554
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34554&action=edit
gcc5-pr64734.patch

Untested fix.

[Bug testsuite/62286] [ARM] 4.9 Regression fails for cortex-m3 for vfp-1.c: fmacs, fmscs, fnmacs, fnmscs

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from ktkachov at gcc dot gnu.org ---
Ok, closing this off then as this doesn't affect any real configurations, only
a theoretical combination of cpu and fpu

[Bug c++/64751] New: internal compiler error: in gen_type_die_with_usage, at dwarf2out.c:19486

[zzt13 at software dot nju.edu.cn]

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

Bug ID: 64751
   Summary: internal compiler error: in gen_type_die_with_usage,
at dwarf2out.c:19486
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zzt13 at software dot nju.edu.cn

Created attachment 34555
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34555&action=edit
The console output(I pasted it into the temp file) and a temp file when using
`-v -save-temps` produces.

When compiling my program, gcc told me there is a internal compiler error as
above said. The error is disappear is I comment all header of standard libary
of c++.

[Bug c++/64751] internal compiler error: in gen_type_die_with_usage, at dwarf2out.c:19486

[zzt13 at software dot nju.edu.cn]

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

--- Comment #1 from zzt  ---
*** Bug 64750 has been marked as a duplicate of this bug. ***

[Bug c++/64750] internal compiler error: in gen_type_die_with_usage, at dwarf2out.c:19486

[zzt13 at software dot nju.edu.cn]

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

zzt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from zzt  ---
The one is the duplicate of 64751 for I accidentally send it twice.

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

[Bug jit/64752] New: Eliminate use of "file" from the jit testsuite

[dmalcolm at gcc dot gnu.org]

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

Bug ID: 64752
   Summary: Eliminate use of "file" from the jit testsuite
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: jit
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org

Currently jit.exp invokes "file" as a smoketest for the output of
gcc_context_compile_to_file, to try to verify that assembler/objects/shared
library/executables were emitted, trying to match the output of "file" against
regexes.

Some hosts won't have "file" installed, and the output of "file" seems to vary
enough from host to host that this test can never be made sane.

So we should drop this use of "file", in favor of sanity-checking the output
more directly: e.g. trying to run the assembler on the .s file, etc.

[Bug libitm/56801] Internal Compiler Error when compiling relaxed transaction

[torvald at gcc dot gnu.org]

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

torvald at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||torvald at gcc dot gnu.org
 Resolution|--- |WORKSFORME

--- Comment #6 from torvald at gcc dot gnu.org ---
I can't reproduce the ICE with SVN trunk (r220039), so I'll close this for now.

The produced code looks correct, although it's a little odd: Both the
instrumented and the uinstrumented code path are generated; on instrumented,
there's no explicit call to request going irrevocable, but the flags to
_ITM_beginTransaction state that only the uninstrumented path is available.

[Bug libitm/61594] ICE (assertion failure) in trans-mem.c

[torvald at gcc dot gnu.org]

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

torvald at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||torvald at gcc dot gnu.org
 Resolution|--- |WORKSFORME

--- Comment #3 from torvald at gcc dot gnu.org ---
I can't reproduce this on SVN trunk (r220039), so I'll close this for now.

I didn't spot anything bad when briefly looking at the generated code.

[Bug c++/64727] [5 Regression] g++.dg/torture/darwin-cfstring-3.C:11:80: internal compiler error: Segmentation fault: 11

[jason at gcc dot gnu.org]

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

--- Comment #14 from Jason Merrill  ---
Author: jason
Date: Fri Jan 23 14:59:10 2015
New Revision: 220041

URL: https://gcc.gnu.org/viewcvs?rev=220041&root=gcc&view=rev
Log:
PR c++/64727
* constexpr.c (cxx_eval_constant_expression): Allow for lvalue use
of CONST_DECL.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c

[Bug libitm/52695] libitm/config/x86/cacheline.h: '__m64' does not name a type

[torvald at gcc dot gnu.org]

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

--- Comment #8 from torvald at gcc dot gnu.org ---
Can this bug be closed?  It sounds as if this has been fixed in 4.8 already;
given that TM is experimental, backporting the fix is probably not worth it.

[Bug target/64753] New: Redundant cmp instruction on x86_64

[rv at rasmusvillemoes dot dk]

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

Bug ID: 64753
   Summary: Redundant cmp instruction on x86_64
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rv at rasmusvillemoes dot dk
  Host: x86_64
Target: x86_64

The linux kernel's library strncmp is this:

int strncmp(const char *cs, const char *ct, size_t count)
{
unsigned char c1, c2;

while (count) {
c1 = *cs++;
c2 = *ct++;
if (c1 != c2)
return c1 < c2 ? -1 : 1;
if (!c1)
break;
count--;
}
return 0;
}

Compiling with gcc -O2 -S I get this:

strncmp:
.LFB0:
.cfi_startproc
testq   %rdx, %rdx
je  .L10
movzbl  (%rdi), %ecx
movzbl  (%rsi), %r8d
#cmpb%r8b, %cl
#jne .L3
testb   %cl, %cl
je  .L10
subq$1, %rdx
xorl%eax, %eax
jmp .L4
.p2align 4,,10
.p2align 3
.L6:
movzbl  1(%rdi,%rax), %ecx
movzbl  1(%rsi,%rax), %r8d
#cmpb%r8b, %cl
#jne .L3
addq$1, %rax
testb   %cl, %cl
je  .L10
.L4:
cmpq%rdx, %rax
jne .L6
.L10:
xorl%eax, %eax
ret
.p2align 4,,10
.p2align 3
.L3:
cmpb%r8b, %cl
sbbl%eax, %eax
orl $1, %eax
ret
.cfi_endproc

At the two places marked # we do a cmp and a conditional jump to .L3, where for
good measure the same cmp is done again... there's no other path to .L3, so it
would seem that simply omitting that extra cmp should be ok. 

This is with gcc-5.0 (GCC) 5.0.0 20150112 (experimental), but I see the same
with gcc (Debian 4.7.2-5) 4.7.2.

[Bug libitm/61594] ICE (assertion failure) in trans-mem.c

[patrick.marlier at gmail dot com]

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

--- Comment #4 from Patrick Marlier  ---
GCC 4.8.3 and 4.9.1 still fail with an ICE. Please adjust the version in the PR
and change the status.
(I did not test 4.8.4 and 4.9.2 but I can test it).

[Bug tree-optimization/64421] Incorrect vector function name generated for log

[andrew.n.senkevich at gmail dot com]

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

Andrew Senkevich  changed:

   What|Removed |Added

 CC||jakub at redhat dot com

--- Comment #1 from Andrew Senkevich  ---
Any plans to fix it for upcoming release?

[Bug jit/64752] Eliminate use of "file" from the jit testsuite

[dmalcolm at gcc dot gnu.org]

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

--- Comment #1 from David Malcolm  ---
(In reply to David Malcolm from comment #0)
> Some hosts won't have "file" installed, and the output of "file" seems to
> vary enough from host to host that this test can never be made sane.

For example, on i686 Fedora I get:
FAIL: 'file' output on output-of-test-compile-to-assembler.c.s did not match:
assembler source text

since the output was:
  output-of-test-compile-to-assembler.c.s: assembler source, ASCII text
but I've seen output (on ppc iirc) that read just "ASCII text"