[Bug tree-optimization/58088] [4.8/4.9 Regression] ICE in gcc.c

[mpolacek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58088

--- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org ---
Another testcases:

int
bar (int i)
{
  return 1 | ((i * 2)  254);
}

int
foo (int i)
{
  return 1 | ((i * 2)  255);
}

[Bug fortran/57306] [OOP] [F08] ICE on valid with class pointer initialization

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57306

--- Comment #13 from janus at gcc dot gnu.org ---
Author: janus
Date: Tue Aug  6 08:20:17 2013
New Revision: 201521

URL: http://gcc.gnu.org/viewcvs?rev=201521root=gccview=rev
Log:
2013-08-06  Janus Weil  ja...@gcc.gnu.org

PR fortran/57306
* class.c (gfc_class_null_initializer): Rename to
'gfc_class_initializer'. Treat non-NULL init-exprs.
* gfortran.h (gfc_class_null_initializer): Update prototype.
* trans-decl.c (gfc_get_symbol_decl): Treat class variables.
* trans-expr.c (gfc_conv_initializer): Ditto.
(gfc_trans_subcomponent_assign): Renamed gfc_class_null_initializer.

2013-08-06  Janus Weil  ja...@gcc.gnu.org

PR fortran/57306
* gfortran.dg/pointer_init_8.f90: New.

Added:
trunk/gcc/testsuite/gfortran.dg/pointer_init_8.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/class.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/trans-decl.c
trunk/gcc/fortran/trans-expr.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/57306] [OOP] [F08] ICE on valid with class pointer initialization

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57306

janus at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #14 from janus at gcc dot gnu.org ---
r201521 basically fixes this PR (the remaining problem of comment 7 will be
tracked by PR 55207). Closing.

[Bug tree-optimization/58088] [4.8/4.9 Regression] ICE in gcc.c

[ktkachov at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58088

--- Comment #5 from ktkachov at gcc dot gnu.org ---
(In reply to Marek Polacek from comment #4)
 Another testcases:
 
 int
 bar (int i)
 {
   return 1 | ((i * 2)  254);
 }
 
 int
 foo (int i)
 {
   return 1 | ((i * 2)  255);
 }

This happens for any value of the RHS of the AND that is = 128.
A stack overflow occurs because fold_binary_loc keeps getting called, but op1,
which is supposed to be the result of maksing the RHS with the NOT of the 2 in
(i * 2) is set to something else.
Now investigating...

[Bug fortran/55207] Automatic deallocation of variables declared in the main program

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55207

--- Comment #13 from janus at gcc dot gnu.org ---
Test case from PR 57306 comment 7 (see also
http://gcc.gnu.org/ml/fortran/2013-07/msg00103.html):


  type :: c
  end type c

  type(c), target :: x
  class(c), pointer :: px = x

  if (.not. associated(px)) call abort()
end

[Bug target/40523] GCC generates invalid instructions when building for Thumb-2 on armel

[rearnsha at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40523

Richard Earnshaw rearnsha at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|WONTFIX |FIXED

--- Comment #5 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
It was fixed in 4.4.0, just not in 4.3.

[Bug tree-optimization/58088] [4.8/4.9 Regression] ICE in gcc.c

[mpolacek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58088

--- Comment #6 from Marek Polacek mpolacek at gcc dot gnu.org ---
Well, for (i * 2)  128 the BIT_AND_EXPR case doesn't do anything, but then we
get into BIT_IOR_EXPR case, here the Canonicalize (X  C1) | C2. code changes
that into (i * 2)  255, then in BIT_AND_EXPR we drop the zero bits, so we get
(i * 2)  254, but then it gets canonicalized into (i * 2)  255 again and so
on and on, then we overflow.

[Bug fortran/49213] [OOP] gfortran rejects structure constructor expression

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49213

--- Comment #15 from janus at gcc dot gnu.org ---
Another test case related to comment 12 (from
http://gcc.gnu.org/ml/fortran/2013-08/msg00015.html):


integer, target :: tgt
type t2
end type t2
type(t2), target :: tgt2
type t
  class(*), pointer :: a = tgt
  class(*), pointer :: b = tgt2
end type t
type(t) :: x
type(t), SAVE :: y
end


Unpatched gfortran gives:


tobias3.f90:1.22:

integer, target :: tgt
  1
Internal Error at (1):
tobias3.f90:6.31:

  class(*), pointer :: a = tgt
   1
Can't convert INTEGER(4) to CLASS(*) at (1)


and also the patches from comment 8 and 10 don't help here.

[Bug fortran/57959] [F03] ICE with structure constructor with scalar allocatable components

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57959

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-08-06
 CC||janus at gcc dot gnu.org
Summary|ICE with structure  |[F03] ICE with structure
   |constructor with scalar |constructor with scalar
   |allocatable components  |allocatable components
 Ever confirmed|0   |1

--- Comment #2 from janus at gcc dot gnu.org ---
Loosely related: PR 49213.

[Bug fortran/49213] [OOP] gfortran rejects structure constructor expression

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49213

--- Comment #16 from janus at gcc dot gnu.org ---
(In reply to janus from comment #15)
 and also the patches from comment 8 and 10 don't help here.

... but the following does:


Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c(revision 201520)
+++ gcc/fortran/expr.c(working copy)
@@ -3936,8 +3936,7 @@ gfc_default_initializer (gfc_typespec *ts)
   if (comp-initializer)
 {
   ctor-expr = gfc_copy_expr (comp-initializer);
-  if ((comp-ts.type != comp-initializer-ts.type
-   || comp-ts.kind != comp-initializer-ts.kind)
+  if (!gfc_compare_types (comp-ts, comp-initializer-ts)
!comp-attr.pointer  !comp-attr.proc_pointer)
 gfc_convert_type_warn (ctor-expr, comp-ts, 2, false);
 }

[Bug tree-optimization/58039] -ftree-vectorizer makes a loop crash on a non-aligned memory

[bar at mariadb dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58039

--- Comment #2 from Alexander Barkov bar at mariadb dot org ---
Any updates? Thanks.

[Bug fortran/49213] [OOP] gfortran rejects structure constructor expression

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49213

--- Comment #17 from janus at gcc dot gnu.org ---
(In reply to janus from comment #16)
  and also the patches from comment 8 and 10 don't help here.
 
 ... but the following does:

... without any testsuite failures, btw.

[Bug c++/58091] Non-ambiguous member lookup rejected

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58091

--- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com ---
However current ICC agrees with GCC. We may have something in Bugzilla.

[Bug middle-end/58041] Unaligned access to arrays in packed structure

[jamborm at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041

Martin Jambor jamborm at gcc dot gnu.org changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2013-08/msg00224.htm
   ||l

--- Comment #29 from Martin Jambor jamborm at gcc dot gnu.org ---
Richi approved the patch, I've committed it to trunk.  I'm about to
bootstrap and test n the 4.8 branch.


Author: jamborm
Date: Tue Aug  6 09:22:16 2013
New Revision: 201523

URL: http://gcc.gnu.org/viewcvs?rev=201523root=gccview=rev
Log:
2013-08-06  Martin Jambor  mjam...@suse.cz

PR middle-end/58041
* gimple-ssa-strength-reduction.c (replace_ref): Make sure built
MEM_REF has proper alignment information.

testsuite/
* gcc.dg/torture/pr58041.c: New test.
* gcc.target/arm/pr58041.c: Likewise.


Added:
trunk/gcc/testsuite/gcc.dg/torture/pr58041.c
trunk/gcc/testsuite/gcc.target/arm/pr58041.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-strength-reduction.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/58091] Non-ambiguous member lookup rejected

[fimbul77 at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58091

--- Comment #2 from fimbul77 at gmail dot com ---
3.4 Name lookup
The name lookup rules apply uniformly to all names (including typedef-names
(7.1.3), namespace-names (7.3), and class-names (9.1)) wherever the grammar
allows such names in the context discussed by a particular rule.

NS0::value

NS(namespace) should not be lookup(the grammar don't allow appearing angle
brackets after namespace name).
Only NS(class template) should be lookup.

Perhaps Clang is correct.

[Bug c/58092] New: BEQ (Branch on equal) jumps to wrong address (executes conditional code!)

[zajec5 at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58092

Bug ID: 58092
   Summary: BEQ (Branch on equal) jumps to wrong address (executes
conditional code!)
   Product: gcc
   Version: 4.6.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zajec5 at gmail dot com

Created attachment 30617
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30617action=edit
Minimal test case (ANSI C)

In my code I'm using simple if (rev == 0x4) to make a conditional write.
Unfortunately when using mipsel gcc with -Os the code from conditional part
is *partially* executed even when rev doesn't equal 4.

 mipsel-openwrt-linux-uclibc-gcc -v
Reading specs from
/home/zajec/openwrt/openwrt.git/staging_dir/toolchain-mipsel_gcc-4.6-linaro_uClibc-0.9.33.2/lib64/gcc/mipsel-openwrt-linux-uclibc/4.6.4/specs
COLLECT_GCC=mipsel-openwrt-linux-uclibc-gcc
COLLECT_LTO_WRAPPER=/home/zajec/openwrt/openwrt.git/staging_dir/toolchain-mipsel_gcc-4.6-linaro_uClibc-0.9.33.2/lib/gcc/mipsel-openwrt-linux-uclibc/4.6.4/lto-wrapper
Target: mipsel-openwrt-linux-uclibc
Configured with:
/home/zajec/openwrt/openwrt.git/build_dir/toolchain-mipsel_gcc-4.6-linaro_uClibc-0.9.33.2/gcc-linaro-4.6-2012.12/configure
--with-bugurl=https://dev.openwrt.org/ --with-pkgversion='OpenWrt/Linaro GCC
4.6-2012.12 r36315'
--prefix=/home/zajec/openwrt/openwrt.git/staging_dir/toolchain-mipsel_gcc-4.6-linaro_uClibc-0.9.33.2
--build=x86_64-suse-linux --host=x86_64-suse-linux
--target=mipsel-openwrt-linux-uclibc --with-gnu-ld --enable-target-optspace
--disable-libgomp --disable-libmudflap --disable-multilib --disable-nls
--with-host-libstdcxx=-lstdc++ --with-float=soft
--with-gmp=/home/zajec/openwrt/openwrt.git/staging_dir/host
--with-mpfr=/home/zajec/openwrt/openwrt.git/staging_dir/host
--disable-decimal-float --with-mips-plt
--with-mpc=/home/zajec/openwrt/openwrt.git/staging_dir/host --disable-libssp
--disable-__cxa_atexit
--with-headers=/home/zajec/openwrt/openwrt.git/staging_dir/toolchain-mipsel_gcc-4.6-linaro_uClibc-0.9.33.2/include
--enable-languages=c,c++ --enable-shared --enable-threads
--with-slibdir=/home/zajec/openwrt/openwrt.git/staging_dir/toolchain-mipsel_gcc-4.6-linaro_uClibc-0.9.33.2/lib
--enable-lto --with-libelf=/home/zajec/openwrt/openwrt.git/staging_dir/host
Thread model: posix
gcc version 4.6.4 (OpenWrt/Linaro GCC 4.6-2012.12 r36315)

[Bug c/58092] BEQ (Branch on equal) jumps to wrong address (executes conditional code!)

[zajec5 at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58092

--- Comment #1 from Rafał Miłecki zajec5 at gmail dot com ---
Created attachment 30618
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30618action=edit
Compiled version of test.c

Command I use to compile test.c:

mipsel-openwrt-linux-uclibc-gcc \
-I arch/mips/include \
-I arch/mips/include/generated \
-I arch/mips/include/asm/mach-bcm47xx \
-I arch/mips/include/asm/mach-generic \
-I include  \
-include include/linux/kconfig.h \
-D__KERNEL__ -DMODULE \
-Wall -Wundef -Wstrict-prototypes -Wno-trigraphs
-Werror-implicit-function-declaration -Wno-format-security
-Wframe-larger-than=1024 -Wno-unused-but-set-variable
-Wdeclaration-after-statement -Wno-pointer-sign \
-fno-strict-aliasing -fno-common -fno-delete-null-pointer-checks
-fno-caller-saves -fno-stack-protector -fno-pic -pipe -fomit-frame-pointer
-femit-struct-debug-baseonly -fno-strict-overflow -fconserve-stack \
-mno-check-zero-division -mno-abicalls -mno-branch-likely -msoft-float
-mno-long-calls -ffreestanding -mabi=32 -march=mips32 -Wa,-mips32 -Wa,--trap \
-D CC_HAVE_ASM_GOTO \
-Os \
-c -o test.o test.c

[Bug c++/58091] Non-ambiguous member lookup rejected

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58091

--- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com ---
Generally speaking, this is a basic C++ issue, doesn't have to do with the
recent constexpr, and normally icc is very solid about those. Remember there
are also DRs, besides the published Standards. At the moment, I simply don't
know.

[Bug c/58092] BEQ (Branch on equal) jumps to wrong address (executes conditional code!)

[zajec5 at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58092

--- Comment #2 from Rafał Miłecki zajec5 at gmail dot com ---
### Decompiled object ###

 test:
   0:   24020002li  v0,2
   4:   24030004li  v1,4
   8:   aca2sw  v0,0(a1)
   c:   10830002beq a0,v1,18 test+0x18
  10:   24020008li  v0,8
  14:   8ca20040lw  v0,64(a1)
  18:   aca20040sw  v0,64(a1)
  1c:   03e8jr  ra
  20:   nop



### Decompiled with my explanations ###

   0:   24020002li  v0,2
   4:   24030004li  v1,4
   8:   aca2sw  v0,0(a1)
v0 (0x2) is stored in a1 unconditionally - this is fine

   c:   10830002beq a0,v1,18 test+0x18
  10:   24020008li  v0,8
a0 (rev argument) is compared with v1 (0x4) - if equal CPU jumps to 0x18

  14:   8ca20040lw  v0,64(a1)
the above line is executed to rev != 4

  18:   aca20040sw  v0,64(a1)
the above lins (store v0 in a1+64) is always executed!
it should be executed for rev==4 only
v0 is 0x8 by default, or some different value for rev != 4

  1c:   03e8jr  ra
  20:   nop

[Bug c++/58014] vshuf-v2si.C fails at -O3 on hppa64

[danglin at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58014

--- Comment #2 from John David Anglin danglin at gcc dot gnu.org ---
Introduced in r197845:

2013-04-12  Richard Biener  rguent...@suse.de

* gimple.c (is_gimple_constant): Vector CONSTRUCTORs should
not be considered a gimple constant.

[Bug c++/58093] New: Semi-bogus warning about narrowing conversions and variadic templates

[nmm1 at cam dot ac.uk]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58093

Bug ID: 58093
   Summary: Semi-bogus warning about narrowing conversions and
variadic templates
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nmm1 at cam dot ac.uk

This may be related to 45397 and 53661, but it's not clear.  The diagnostic
is both confusing and makes many uses of variadic templates extremely
confusing to their users.

4.13 [conv.rank], 4.7 [conv.integral] and 5 [expr] make it pretty clear
that this is not a narrowing conversion, which makes the diagnostic very
confusing.  I agree that it potentially changes value, but the wording
could be better (e.g. 'loss of sign').  That's the trivial part of this
report.

The more serious (but still minor) one is that I don't think that this
is a soluble problem for the variadic template writer.  It is unreasonable
to have to convert arguments explicitly, when it's automatic under almost
all circumstances.

The following program:

#include iostream
using namespace std;

templatetypename ... Pack
void weeble (Pack ... Dims) {
size_t r[] = {Dims...};
for (int i = 0; i  sizeof...(Dims); ++i)
std::cout r[i];
std::cout  std::endl;
}

int main() {
weeble(7,13,42,69);
}

produces:

junk.cpp: In instantiation of 'void weeble(Pack ...) [with Pack = {int, int,
int, int}]':
junk.cpp:13:22:   required from here
junk.cpp:6:26: warning: narrowing conversion of 'Dims#0' from 'int' to 'size_t
{aka long unsigned int}' inside { } [-Wnarrowing]
 size_t r[] = {Dims...};
  ^
junk.cpp:6:26: warning: narrowing conversion of 'Dims#1' from 'int' to 'size_t
{aka long unsigned int}' inside { } [-Wnarrowing]
junk.cpp:6:26: warning: narrowing conversion of 'Dims#2' from 'int' to 'size_t
{aka long unsigned int}' inside { } [-Wnarrowing]
junk.cpp:6:26: warning: narrowing conversion of 'Dims#3' from 'int' to 'size_t
{aka long unsigned int}' inside { } [-Wnarrowing]

g++ -v produces:

Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/home/nmm/GCC/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/home/nmm/GCC --disable-bootstrap
--enable-languages=c,c++,fortran --enable-werror=yes --disable-decimal-float
Thread model: posix
gcc version 4.8.1 (GCC)

[Bug fortran/57987] Fortran finalizers considered extern-inline by middle-end

[jamborm at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57987

Martin Jambor jamborm at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2013-08/msg00074.htm
   ||l
 Resolution|--- |FIXED

--- Comment #6 from Martin Jambor jamborm at gcc dot gnu.org ---
Author: jamborm
Date: Tue Aug  6 12:48:53 2013
New Revision: 201526

URL: http://gcc.gnu.org/viewcvs?rev=201526root=gccview=rev
Log:
2013-08-06  Martin Jambor  mjam...@suse.cz

PR fortran/57987
* cgraphunit.c (cgraph_finalize_function): Assert that nested function
is not re-finalized.  Rename second parameter to no_collect.

fortran/
* trans-decl.c (gfc_generate_function_code): Never call
cgraph_finalize_function on nested functions.

testsuite/
* gfortran.dg/pr57987.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/pr57987.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraphunit.c
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-decl.c
trunk/gcc/testsuite/ChangeLog

[Bug c/58092] BEQ (Branch on equal) jumps to wrong address (executes conditional code!)

[mikpe at it dot uu.se]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58092

--- Comment #3 from Mikael Pettersson mikpe at it dot uu.se ---
Please attach the pre-processed test.i (gcc -E or -save-temps).

[Bug c++/58093] Semi-bogus warning about narrowing conversions and variadic templates

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58093

Jonathan Wakely redi at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org ---
(In reply to Nick Maclaren from comment #0)
 4.13 [conv.rank], 4.7 [conv.integral] and 5 [expr] make it pretty clear
 that this is not a narrowing conversion, which makes the diagnostic very
 confusing.  I agree that it potentially changes value, but the wording
 could be better (e.g. 'loss of sign').  That's the trivial part of this
 report.

8.5.4 [dcl.init.list] p7 makes it very clear it *is* a narrowing conversion,
because the elements in the pack expansion Dims... are not constant
expressions.

 The more serious (but still minor) one is that I don't think that this
 is a soluble problem for the variadic template writer.  It is unreasonable
 to have to convert arguments explicitly, when it's automatic under almost
 all circumstances.

Why is it not soluble? The solution is trivial:

 size_t r[] = {static_castsize_t(Dims)...};

Or replace the static_cast with your preferred choice of cast.

G++ is following the standard, this is not a bug.

 size_t r[] = {Dims...};
 for (int i = 0; i  sizeof...(Dims); ++i)
 std::cout r[i];

This would be simpler as:

size_t r[] = {Dims...};
for (auto i : r)
std::cout i;

[Bug middle-end/58094] New: [4.9 Regression] IPA devirt testsuite errors

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58094

Bug ID: 58094
   Summary: [4.9 Regression] IPA devirt testsuite errors
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org

http://gcc.gnu.org/ml/gcc-patches/2013-08/msg00092.html

This patch caused new testsuite regressions:

FAIL: g++.dg/ipa/devirt-11.C -std=gnu++98  scan-ipa-dump-times inline
Discovered a virtual call to a known target 3
FAIL: g++.dg/ipa/devirt-11.C -std=gnu++98  scan-ipa-dump-times inline
and turned into root of the clone tree 1
FAIL: g++.dg/ipa/devirt-11.C -std=gnu++11  scan-ipa-dump-times inline
Discovered a virtual call to a known target 3
FAIL: g++.dg/ipa/devirt-11.C -std=gnu++11  scan-ipa-dump-times inline
and turned into root of the clone tree 1

FAIL: g++.dg/tree-ssa/pr42337.C -std=gnu++98 (test for excess errors)
FAIL: g++.dg/tree-ssa/pr42337.C -std=gnu++11 (test for excess errors)

[Bug middle-end/58094] [4.9 Regression] IPA devirt testsuite errors

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58094

David Edelsohn dje at gcc dot gnu.org changed:

   What|Removed |Added

 Target||powerpc*-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-08-06
 CC||hubicka at gcc dot gnu.org,
   ||marxin.liska at gmail dot com
   Host||powerpc*-*-*
 Ever confirmed|0   |1
  Build||powerpc*-*-*

--- Comment #1 from David Edelsohn dje at gcc dot gnu.org ---
Confirmed.

[Bug middle-end/58094] [4.9 Regression] IPA devirt testsuite errors

[hubicka at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58094

--- Comment #2 from Jan Hubicka hubicka at gcc dot gnu.org ---
I am not able to reproduce those on gcc110.fsffrance.org.  Would be possible to
have -fdump-ipa-all -fdump-tree-all dumps of the devirt testcase?  I think both
are related to fast that ipa-prop is not propagating across the local aliases,
but I do not see why the local aliases are introduced here at first place.
Perhaps binds_local_p is somehow wrong for AIX?

[Bug middle-end/58041] Unaligned access to arrays in packed structure

[bernd.edlinger at hotmail dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041

--- Comment #30 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
Hi Martin,

I have bootstrapped this patch for i686-pc-linux-gnu and have
seen some excess errors in your test script:

/home/ed/gnu/gcc-4.9-20130728/gcc/testsuite/gcc.dg/torture/pr58041.c: In
function 'foo':
/home/ed/gnu/gcc-4.9-20130728/gcc/testsuite/gcc.dg/torture/pr58041.c:15:11:
note: The ABI for passing parameters with 16-byte alignment has changed in GCC
4.6
/home/ed/gnu/gcc-4.9-20130728/gcc/testsuite/gcc.dg/torture/pr58041.c:15:11:
warning: SSE vector argument without SSE enabled changes the ABI [enabled by
default]
/home/ed/gnu/gcc-4.9-20130728/gcc/testsuite/gcc.dg/torture/pr58041.c:15:11:
warning: SSE vector argument without SSE enabled changes the ABI [enabled by
default]
output is:
/home/ed/gnu/gcc-4.9-20130728/gcc/testsuite/gcc.dg/torture/pr58041.c: In
function 'foo':
/home/ed/gnu/gcc-4.9-20130728/gcc/testsuite/gcc.dg/torture/pr58041.c:15:11:
note: The ABI for passing parameters with 16-byte alignment has changed in GCC
4.6
/home/ed/gnu/gcc-4.9-20130728/gcc/testsuite/gcc.dg/torture/pr58041.c:15:11:
warning: SSE vector argument without SSE enabled changes the ABI [enabled by
default]
/home/ed/gnu/gcc-4.9-20130728/gcc/testsuite/gcc.dg/torture/pr58041.c:15:11:
warning: SSE vector argument without SSE enabled changes the ABI [enabled by
default]

FAIL: gcc.dg/torture/pr58041.c  -O0  (test for excess errors)
Excess errors:
/home/ed/gnu/gcc-4.9-20130728/gcc/testsuite/gcc.dg/torture/pr58041.c:15:11:
warning: SSE vector argument without SSE enabled changes the ABI [enabled by
default]
/home/ed/gnu/gcc-4.9-20130728/gcc/testsuite/gcc.dg/torture/pr58041.c:15:11:
warning: SSE vector argument without SSE enabled changes the ABI [enabled by
default]

[Bug c/58092] BEQ (Branch on equal) jumps to wrong address (executes conditional code!)

[zajec5 at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58092

--- Comment #4 from Rafał Miłecki zajec5 at gmail dot com ---
Created attachment 30619
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30619action=edit
test.i generated by adding -save-temps

Hi Mikael!

I added -save-temps at the end of my mipsel-openwrt-linux-uclibc-gcc call and
got warning:
mipsel-openwrt-linux-uclibc-gcc: warning: -pipe ignored because -save-temps
specified
and test.i of course.

By looking at decompiled version of test.o it seems to still contain the bug,
so ignored -pipe shouldn't hurt us.

Hope this is what you expected!

[Bug middle-end/58041] Unaligned access to arrays in packed structure

[jamborm at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041

--- Comment #31 from Martin Jambor jamborm at gcc dot gnu.org ---
(In reply to Bernd Edlinger from comment #30)
 Hi Martin,
 
 I have bootstrapped this patch for i686-pc-linux-gnu and have
 seen some excess errors in your test script:
 
 /home/ed/gnu/gcc-4.9-20130728/gcc/testsuite/gcc.dg/torture/pr58041.c: In
 function 'foo':
 /home/ed/gnu/gcc-4.9-20130728/gcc/testsuite/gcc.dg/torture/pr58041.c:15:11:
 note: The ABI for passing parameters with 16-byte alignment has changed in
 GCC 4.6
 /home/ed/gnu/gcc-4.9-20130728/gcc/testsuite/gcc.dg/torture/pr58041.c:15:11:
 warning: SSE vector argument without SSE enabled changes the ABI [enabled by
 default]

I can't reproduce this with the -m32 flag on my x86_64... do you still
have the compiler built on an i686?  If so, could you try and make
function foo static in that testcase and see if the error goes away?
Thanks!

[Bug middle-end/58041] Unaligned access to arrays in packed structure

[jamborm at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041

--- Comment #32 from Martin Jambor jamborm at gcc dot gnu.org ---
Author: jamborm
Date: Tue Aug  6 15:08:59 2013
New Revision: 201530

URL: http://gcc.gnu.org/viewcvs?rev=201530root=gccview=rev
Log:
2013-08-06  Martin Jambor  mjam...@suse.cz

PR middle-end/58041
* gimple-ssa-strength-reduction.c (replace_ref): Make sure built
MEM_REF has proper alignment information.

testsuite/
* gcc.dg/torture/pr58041.c: New test.
* gcc.target/arm/pr58041.c: Likewise.


Added:
branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/torture/pr58041.c
branches/gcc-4_8-branch/gcc/testsuite/gcc.target/arm/pr58041.c
Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/gimple-ssa-strength-reduction.c
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug c++/58093] Semi-bogus warning about narrowing conversions and variadic templates

[nmm1 at cam dot ac.uk]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58093

--- Comment #2 from Nick Maclaren nmm1 at cam dot ac.uk ---
I have no idea why you think that it is a narrowing conversion.  The
references I gave have been essentially unchanged since C90, and there
is required to be no loss of information.  All values of int can be
represented in unsigned long in any conforming implementation.  The
primary condition of 8.5.4 p7 is fulfilled, and therefore the exception
is irrelevant.  This was clarified in C99 6.2.6.2.  No, I did not support
that interpretation in C90, but it's the one WG14 adopted.

But it's merely a confusing diagnostic, and is therefore lost in the
multitude of such things.

Thank you for your correction on the templates - I was still thinking
in terms of arguments and not patterns!

[Bug middle-end/58041] Unaligned access to arrays in packed structure

[bernd.edlinger at hotmail dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041

--- Comment #33 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(In reply to Martin Jambor from comment #31)
 I can't reproduce this with the -m32 flag on my x86_64... do
 you still have the compiler built on an i686?  If so, could you try and make
 function foo static in that testcase and see if the error goes away?

static does not help.
If I add -msse the warning goes away, but the compiled executable
crashes because of illegal instruction.

Dual Pentium II, with mmx but obviously no sse, whatever that may be:
flags: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pse36 mmx fxsr

[Bug c++/58093] Semi-bogus warning about narrowing conversions and variadic templates

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58093

--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org ---
(In reply to Nick Maclaren from comment #2)
 I have no idea why you think that it is a narrowing conversion.

Please read the definition of a narrowing conversion in C++11, at 8.5.4
[dcl.init.list] p7. What the C standard says is irrelevant here.

[Bug c++/58093] Semi-bogus warning about narrowing conversions and variadic templates

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58093

--- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org ---
(In reply to Nick Maclaren from comment #2)
 All values of int can be
 represented in unsigned long in any conforming implementation.

Except the negative ones!

[Bug middle-end/58094] [4.9 Regression] IPA devirt testsuite errors

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58094

--- Comment #3 from David Edelsohn dje at gcc dot gnu.org ---
Created attachment 30620
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30620action=edit
ipa and tree dumps

-fdump-ipa-all -fdump-tree-all output file attached in gzipped tar file.

[Bug middle-end/58041] Unaligned access to arrays in packed structure

[bernd.edlinger at hotmail dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041

--- Comment #34 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
by the way the initializer of struct s a = 
seems to generate warnings at -Wall, because some brackets are missing:

changed that to
struct s a = {0,{{0,0},{0,0}}};

but somehow I wonder what forced us to generate sse instructions here?
when that same example works on a ARMv5 targe?

[Bug c++/58095] New: SIMD code requiring auxiliary array for best optimization

[siavashserver at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58095

Bug ID: 58095
   Summary: SIMD code requiring auxiliary array for best
optimization
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: siavashserver at gmail dot com

Created attachment 30621
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30621action=edit
Source code and its generated asm code.

Hello. I have noticed a strange behavior when I'm trying to write SIMD code
using provided SSE intrinsics. It looks like GCC is not able to
generate/optimize same code like function (bar) for function (foo).


I was wondering how can I achieve same generated code for the function (foo)
without going into trouble of defining and using an auxiliary array like
function (bar).


I've tried using __restrict__ keyword for input data (foo2), but GCC still
generates same code like function (foo). ICC and Clang also generate same code
and fail to optimize.

Something strange I've noticed is that GCC 4.4.7 generates desired code for
function (foo), but fails to do for function (foo2) and (bar). Newer versions
generate exactly same code for function (foo) and (foo2), and desired code for
function (bar).

Output attached is generated from GCC 4.8.1 using -O2 optimization level. I've
used online GCC compiler from: http://gcc.godbolt.org/

[Bug middle-end/58041] Unaligned access to arrays in packed structure

[jamborm at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041

--- Comment #35 from Martin Jambor jamborm at gcc dot gnu.org ---
(In reply to Bernd Edlinger from comment #34)
 by the way the initializer of struct s a = 
 seems to generate warnings at -Wall, because some brackets are missing:
 
 changed that to
 struct s a = {0,{{0,0},{0,0}}};
 
 but somehow I wonder what forced us to generate sse instructions here?
 when that same example works on a ARMv5 targe?

Strange, does the correct initializer make the warning go away?
If so, I'll fix it in the testsuite in a moment.

[Bug middle-end/58041] Unaligned access to arrays in packed structure

[bernd.edlinger at hotmail dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041

--- Comment #36 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(In reply to Martin Jambor from comment #35)
 (In reply to Bernd Edlinger from comment #34)
 by the way the initializer
 of struct s a = 
 seems to generate warnings at -Wall, because some
 brackets are missing:
 
 changed that to
 struct s a = {0,{{0,0},{0,0}}};
  
 but somehow I wonder what forced us to generate sse instructions here?
  when that same example works on a ARMv5 targe?

 Strange, does the correct
 initializer make the warning go away?
 If so, I'll fix it in the testsuite in a moment.

no that is just a different warning with -Wall, that one did not
make the test case fail however.

and in line 6 the typedef struct S { V v; } P __attribute__((aligned (1)));
is superfluos too.

hmm, maybe the problem is I should not say -msse in the first place.

do you get the warning if you use -m32 -mno-sse ?

what's funny about that warning, that it does not need to be enabled with
-Wall like the other warning.

[Bug tree-optimization/58095] SIMD code requiring auxiliary array for best optimization

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58095

Paolo Carlini paolo.carlini at oracle dot com changed:

   What|Removed |Added

 CC|siavashserver at gmail dot com |
  Component|c++ |tree-optimization
   Severity|major   |normal

[Bug c++/58093] Semi-bogus warning about narrowing conversions and variadic templates

[nmm1 at cam dot ac.uk]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58093

--- Comment #5 from Nick Maclaren nmm1 at cam dot ac.uk ---
I did.  Please read what the C++ standard says about conversions.  4.7
[conv.integral] paragraph 2 is a paraphrase of wording that has been in
every C and C++ compiler since C90, and states that all integers (negative
and positive) can be represented in unsigned ones of an equal or greater
rank.  Indeed, this was and is a design requirement in the parts of the
library that use -1 converted to an unsigned integer as a result type.

I can't be bothered to pursue this one further - as I said, one more
confusing diagnostic is neither here nor there.

[Bug fortran/57306] [OOP] [F08] ICE on valid with class pointer initialization

[abensonca at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57306

--- Comment #15 from Andrew Benson abensonca at gmail dot com ---
Thanks for fixing!

[Bug lto/57602] [4.9 Regression] Runfails for several C/C++ benchmarks from spec2000 for i686 with -flto after r199422

[hubicka at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57602

Jan Hubicka hubicka at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #15 from Jan Hubicka hubicka at gcc dot gnu.org ---
Fixed thus.

[Bug middle-end/58041] Unaligned access to arrays in packed structure

[bernd.edlinger at hotmail dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041

--- Comment #37 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
this version fixes the warning:

--- ../gcc-4.9-20130728/gcc/testsuite/gcc.dg/torture/pr58041.c  2013-08-02
20:59:38.0 +0200
+++ pr58041.c   2013-08-06 18:30:51.0 +0200
@@ -3,8 +3,6 @@
 typedef long long V
   __attribute__ ((vector_size (2 * sizeof (long long)), may_alias));

-typedef struct S { V v; } P __attribute__((aligned (1)));
-
 struct s
 {
   char u;
@@ -12,24 +10,24 @@
 } __attribute__((packed,aligned(1)));

 __attribute__((noinline, noclone))
-long long foo(struct s *x, int y, V z)
+long long foo(struct s *x, int y, V *z)
 {
   V a = x-v[y];
-  x-v[y] = z;
+  x-v[y] = *z;
   return a[1];
 }

-struct s a = {0,{0,0}};
+struct s a = {0,{{0,0},{0,0}}};
 int main()
 {
   V v1 = {0,1};
   V v2 = {0,2};

-  if (foo(a,0,v1) != 0)
+  if (foo(a,0,v1) != 0)
 __builtin_abort();
-  if (foo(a,0,v2) != 1)
+  if (foo(a,0,v2) != 1)
 __builtin_abort();
-  if (foo(a,1,v1) != 0)
+  if (foo(a,1,v1) != 0)
 __builtin_abort();
   return 0;
 }

[Bug c/58092] BEQ (Branch on equal) jumps to wrong address (executes conditional code!)

[mikpe at it dot uu.se]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58092

--- Comment #5 from Mikael Pettersson mikpe at it dot uu.se ---
I can't reproduce the wrong-code with 4.6.4. 4.7.2, or 4.8.1.  They all
generate:

 test:
   0:   24020002li  v0,2
   4:   aca2sw  v0,0(a1)
   8:   24020004li  v0,4
   c:   14820002bne a0,v0,18 test+0x18
  10:   24020008li  v0,8
  14:   aca20040sw  v0,64(a1)
  18:   03e8jr  ra
  1c:   nop

which looks correct to me (not that I know MIPS very well).

Please try with a self-compiled gcc built from unmodified sources, or report
this to openwrt as your hacked gcc clearly indicated (see the bugurl in comment
#1).

[Bug tree-optimization/58095] SIMD code requiring auxiliary array for best optimization

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58095

--- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org ---
I've tried using __restrict__ keyword for input data (foo2),

I think you want __restrict__ inside of the [].

[Bug driver/35300] References to original ${prefix} paths in relocated toolchain and /lib and /usr/lib search paths appear in cross toolchain.

[ktietz at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35300

Kai Tietz ktietz at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-08-06
 CC||ktietz at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #11 from Kai Tietz ktietz at gcc dot gnu.org ---
Change to gcc/prefix.c seems to make sense for relocatable-setup.  The hack
part seems to be no longer necessary and also wrong.


I

[Bug middle-end/58041] Unaligned access to arrays in packed structure

[jamborm at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041

--- Comment #38 from Martin Jambor jamborm at gcc dot gnu.org ---
(In reply to Bernd Edlinger from comment #37)
 this version fixes the warning:

And I confirm that it still tests the bug.  If you want to commit it
yourself, go ahead, otherwise let me now and I'll do it before I leave
today.  Thanks a lot!

[Bug driver/46501] Relocatable toolchains still search --prefix

[ktietz at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46501

Kai Tietz ktietz at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #6 from Kai Tietz ktietz at gcc dot gnu.org ---
This bug is a duplicate of pr/35300

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

[Bug driver/35300] References to original ${prefix} paths in relocated toolchain and /lib and /usr/lib search paths appear in cross toolchain.

[ktietz at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35300

Kai Tietz ktietz at gcc dot gnu.org changed:

   What|Removed |Added

 CC||nightstrike at gmail dot com

--- Comment #12 from Kai Tietz ktietz at gcc dot gnu.org ---
*** Bug 46501 has been marked as a duplicate of this bug. ***

[Bug middle-end/58041] Unaligned access to arrays in packed structure

[bernd.edlinger at hotmail dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041

--- Comment #39 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(In reply to Martin Jambor from comment #38)
 (In reply to Bernd Edlinger from comment #37)
 this version fixes the warning:
 And I confirm that it still tests the bug.  If you want to commit
 it yourself, go ahead, otherwise let me now and I'll do it before I leave
 today.  Thanks a lot!

no thanks, just go ahead.

[Bug c++/58093] Semi-bogus warning about narrowing conversions and variadic templates

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58093

--- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org ---
(In reply to Nick Maclaren from comment #5)
 I did.  Please read what the C++ standard says about conversions.  4.7
 [conv.integral] paragraph 2 is a paraphrase of wording that has been in
 every C and C++ compiler since C90,

But that's not where narrowing conversions are defined.

See the examples in 8.5.4 which make it clear that converting a negative value
to an unsigned type is a narrowing conversion:

unsigned char uc2 = {-1}; // error: narrows
unsigned int ui1 = {-1}; // error: narrows

Those exxamples come from the proposal by Stroustrup et al:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2531.pdf

Also http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1449

As is made plain in the examples in that paragraph, a conversion of a negative
value to an unsigned type is intended to be a narrowing conversion

[Bug middle-end/58041] Unaligned access to arrays in packed structure

[jamborm at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041

Martin Jambor jamborm at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #40 from Martin Jambor jamborm at gcc dot gnu.org ---
OK, I have updated the testcase on both branches.  So I hope all is
well now and we can close this PR.  Thanks everyone for cooperation.


Author: jamborm
Date: Tue Aug  6 17:33:59 2013
New Revision: 201538

URL: http://gcc.gnu.org/viewcvs?rev=201538root=gccview=rev
Log:
2013-08-06  Martin Jambor  mjam...@suse.cz
Bernd Edlinger bernd.edlin...@hotmail.de

testsuite/
* gcc.dg/torture/pr58041.c (foo): Accept z by reference.
(a): Fix constructor.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/torture/pr58041.c



Author: jamborm
Date: Tue Aug  6 17:35:11 2013
New Revision: 201539

URL: http://gcc.gnu.org/viewcvs?rev=201539root=gccview=rev
Log:
2013-08-06  Martin Jambor  mjam...@suse.cz
Bernd Edlinger bernd.edlin...@hotmail.de

testsuite/
* gcc.dg/torture/pr58041.c (foo): Accept z by reference.
(a): Fix constructor.


Modified:
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/torture/pr58041.c

[Bug tree-optimization/58095] SIMD code requiring auxiliary array for best optimization

[siavashserver at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58095

--- Comment #2 from Siavash Eliasi siavashserver at gmail dot com ---
(In reply to Andrew Pinski from comment #1)
 I've tried using __restrict__ keyword for input data (foo2),
 
 I think you want __restrict__ inside of the [].

Do you mind pasting the modified source code and generated asm code please?

[Bug tree-optimization/58088] [4.8/4.9 Regression] ICE in gcc.c

[mpolacek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58088

--- Comment #7 from Marek Polacek mpolacek at gcc dot gnu.org ---
Kyrylo, do you plan to work on this?  If that's the case, please assign the bug
to yourself.

[Bug middle-end/58041] Unaligned access to arrays in packed structure

[wschmidt at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041

--- Comment #41 from Bill Schmidt wschmidt at gcc dot gnu.org ---
Thanks, Martin!

[Bug tree-optimization/58088] [4.8/4.9 Regression] ICE in gcc.c

[ktkachov at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58088

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #8 from ktkachov at gcc dot gnu.org ---
Mine.

Carrefour ti regala la spesa di 500 euro

[Comunicazione AGIP Italia]

Con il DECRETO-LEGGE 8 aprile 2013, n. 35
in cui il Consiglio dei Ministri anticipa i pagamenti alle P.A. e aiuti per le 
famiglie,

Carrefour Spa ti consente di acquistare la carta Prepagata SpesAmica del valore 
di 500 Euro
al prezzo di 100 Euro.

(80% rimborsato dal Ministero dello Sviluppo Economico).

segui le indicazioni su :

http://carrefour.damnserver.com/

[Bug target/58067] ICE in GFortran recog.c:2158

[aoliva at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58067

Alexandre Oliva aoliva at gcc dot gnu.org changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org

--- Comment #4 from Alexandre Oliva aoliva at gcc dot gnu.org ---
The note just means the debug info location expression containing this
unexpected piece of RTL can't be expressed in dwarf and will thus be dropped on
the floor, so you lose a bit of debug info, but that's all.

[Bug regression/58084] FAIL: gcc.dg/torture/pr8081.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error)

[pthaugen at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58084

Pat Haugen pthaugen at gcc dot gnu.org changed:

   What|Removed |Added

 Target|arm-none-eabi   |arm-none-eabi,
   ||powerpc64-linux
 CC||pthaugen at gcc dot gnu.org

--- Comment #2 from Pat Haugen pthaugen at gcc dot gnu.org ---
Seeing the same thing on powerpc64-linux.

[Bug middle-end/57748] [4.8/4.9 Regression] ICE when expanding assignment to unaligned zero-sized array

[david.abdurachmanov at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748

--- Comment #18 from David Abdurachmanov david.abdurachmanov at gmail dot com 
---
Tested the patch on top of final 4.8.1 Cortex-A9 NEON FPU. GCC no more ICE'ing
while compiling scipy.

[Bug other/58096] New: gcc.dg/tree-ssa/attr-alias.c fails with r201439

[pthaugen at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58096

Bug ID: 58096
   Summary: gcc.dg/tree-ssa/attr-alias.c fails with r201439
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pthaugen at gcc dot gnu.org
CC: bergner at gcc dot gnu.org, dje.gcc at gmail dot com,
hubicka at gcc dot gnu.org, marxin.liska at gmail dot com
  Host: powerpc64-linux
Target: powerpc64-linux
 Build: powerpc64-linux

Subject testcase started failing with r201439.

PASS: gcc.dg/tree-ssa/attr-alias.c (test for excess errors)
PASS: gcc.dg/tree-ssa/attr-alias.c scan-tree-dump-times optimized   test  1
FAIL: gcc.dg/tree-ssa/attr-alias.c scan-tree-dump-times optimized   test4  1
PASS: gcc.dg/tree-ssa/attr-alias.c scan-tree-dump-not optimized   test1 
PASS: gcc.dg/tree-ssa/attr-alias.c scan-tree-dump-not optimized   test2 

[Bug rtl-optimization/58079] internal compiler error: in do_SUBST, at combine.c:711

[rsandifo at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58079

rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org 
---
(In reply to Mikael Pettersson from comment #3)
 Started with Uros' PR54457 patch in r191928.  I'm not sure if that patch was
 wrong or if it exposed a problem in the mips backend.

Looks like a latent combine bug that's being exposed by the better
subreg optimisation.  simplify_comparison is legitimately widening
a QImode comparison to SImode (since the target doesn't support
QImode comparisons), but combine_simplify_rtx is then trying to substitute
these widened values in-place, which trips the sanity check in do_SUBST.

I'm about to post a patch for comments.

[Bug target/58092] BEQ (Branch on equal) jumps to wrong address (executes conditional code!)

[zajec5 at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58092

--- Comment #6 from Rafał Miłecki zajec5 at gmail dot com ---
OK, I've installed cross-mips-linux-gcc package from:
http://download.opensuse.org/repositories/home:/duwe:/crosstools/openSUSE_12.2/
and it works. After compiling test.c with:

 /opt/cross/bin/mips-linux-gcc -v
Using built-in specs.
COLLECT_GCC=/opt/cross/bin/mips-linux-gcc
COLLECT_LTO_WRAPPER=/opt/cross/libexec/gcc/mips-linux/4.5.3/lto-wrapper
Target: mips-linux
Configured with: ../configure --prefix=/opt/cross --enable-bootstrap=no
--build=x86_64-suse-linux --target=mips-linux --enable-languages=c,c++
--with-float=soft --disable-libmudflap --disable-multilib
Thread model: posix
gcc version 4.5.3 (GCC)

I got a correct test.o.

So this issue is specific to Linaro or OpenWrt.

[Bug rtl-optimization/58079] internal compiler error: in do_SUBST, at combine.c:711

[rsandifo at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58079

rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2013-08/msg00326.htm
   ||l
   Last reconfirmed||2013-08-06
 CC|rdsandiford at googlemail dot com  |
 Ever confirmed|0   |1

[Bug target/58067] ICE in GFortran recog.c:2158

[aoliva at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58067

--- Comment #5 from Alexandre Oliva aoliva at gcc dot gnu.org ---
As Andrew says, the problem with -mtls-dialect=gnu (the default) is lack of TLS
support.  The tls_get_addr calls expanded by tls_global_dynamic_64_mode are
not recognized by the corresponding insns because the call address operand (the
__tls_get_addr symbol_ref) doesn't pass the constant_call_address_operand
predicate, configured to always fail in the LARGE code models.  I suppose it's
not appropriate to make an exception for __tls_get_addr, and we'd instead have
to make it an indirect call after loading the address from the GOT.  We'd need
new relocations and relaxation smarts in binutils for this to work.  I guess it
makes more sense to force the GNU2 tls-dialect for LARGE code models, since
that one works, and maybe switch to it by default in other models; we've had it
for long enough already.

As for the non-delegitimized notes we get in both modes, that's fixed with
something along the lines of the following patch:

--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -13827,6 +13827,21 @@ ix86_delegitimize_address (rtx x)
 x = replace_equiv_address_nv (orig_x, x);
   return x;
 }
+  if (GET_CODE (x) == PLUS
+   ix86_pic_register_p (XEXP (x, 0))
+   GET_CODE (XEXP (x, 1)) == CONST
+   GET_CODE (XEXP (XEXP (x, 1), 0)) == UNSPEC
+  /* These are used in 64-bit CM_LARGE mode.  */
+   (XINT (XEXP (XEXP (x, 1), 0), 1) == UNSPEC_PLTOFF
+  || XINT (XEXP (XEXP (x, 1), 0), 1) == UNSPEC_GOTOFF))
+{
+  x = simplify_gen_subreg (GET_MODE (orig_x),
+   XVECEXP (XEXP (XEXP (x, 1), 0), 0, 0),
+   GET_MODE (x), 0);
+  if (x == NULL_RTX)
+return orig_x;
+  return x;
+}
   if (GET_CODE (x) != CONST
   || GET_CODE (XEXP (x, 0)) != UNSPEC
   || (XINT (XEXP (x, 0), 1) != UNSPEC_GOTPCREL

Uros (or anyone), please take this as a starting point; it might require
support for addends, even though I haven't needed them for this one testcase. 
Or maybe we don't need them, after all.  I'm not sure, so I'll leave it for
someone else who knows better.

[Bug rtl-optimization/58034] [4.8/4.9 Regression] glibc nptl/tst-cleanup2 fail due to scheduling

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58034

--- Comment #6 from joseph at codesourcery dot com joseph at codesourcery dot 
com ---
On Wed, 31 Jul 2013, amodra at gmail dot com wrote:

 The relevant test case source:
 
   if (setjmp (jmpbuf))
 {
   puts (Exiting main...);
   return 0;
 }
 
   sprintf (p, This should segv\n);
 
   return 1;
 }
 
 The sprintf is optimised to three loads and stores.  The problem occurs due to
 the assignment of 1 to the REG holding the function return value being
 scheduled before the sprintf expansion.

Well, in valid code this sprintf can't trap (sprintf using glibc 
extensions to register format extensions might).  Optimizing to three 
loads and stores, and then scheduling them, seems a valid optimization to 
me.  Does -fnon-call-exceptions help?  (Though I'd prefer 
-fno-builtin-sprintf as a fix for the glibc test.)

[Bug target/58066] GCC mis-compiles access to TLS variable with -fPIC on x86_64

[ppluzhnikov at google dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066

--- Comment #3 from Paul Pluzhnikov ppluzhnikov at google dot com ---
(In reply to Paul Pluzhnikov from comment #2)

 What is the way to turn it on?

Compiling test case with -mtls-dialect=gnu2 does appear to improve the picture:

g++ -fPIC -O2 -S t.cc -mtls-dialect=gnu2

__cxa_get_globals:
leaq_ZL3ccc@TLSDESC(%rip), %rax
call*_ZL3ccc@TLSCALL(%rax)
addq%fs:0, %rax
ret

The indirect call goes to _dl_tlsdesc_dynamic in ld-linux-x86-64.so.2 with
misaligned stack, and the latter re-aligns it.

[Bug middle-end/58096] [4.9 Regression] gcc.dg/tree-ssa/attr-alias.c fails with r201439

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58096

David Edelsohn dje at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-08-06
 CC||dje at gcc dot gnu.org
  Component|other   |middle-end
Summary|gcc.dg/tree-ssa/attr-alias. |[4.9 Regression]
   |c fails with r201439|gcc.dg/tree-ssa/attr-alias.
   ||c fails with r201439
 Ever confirmed|0   |1

--- Comment #1 from David Edelsohn dje at gcc dot gnu.org ---
This probably is related to PR middle-end/58094

[Bug target/58067] ICE in GFortran recog.c:2158

[woodard at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58067

--- Comment #6 from Ben Woodard woodard at redhat dot com ---
I just rebuilt the trunk with the patch that Alexandre Oliva provided and I can
confirm that it solves the problem with notes about non-delegitimized
addresses. 

However, I haven't yet tested the DWARF to make sure that it works as expected. 

If we do make -mtls-dialect=gnu2 the default or even implied when you specify
-mcmodel=large,  won't you still need to fix the problem with the unknown
instruction just in case someone does -mtls-dialect=gnu or will you just error
out saying: -mcmodel=large is not supported within -mtls-dialect=gnu.
Personally, I believe that erroring out that way is perfectly acceptable.

[Bug target/58067] ICE in GFortran recog.c:2158

[woodard at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58067

--- Comment #7 from Ben Woodard woodard at redhat dot com ---
Created attachment 30622
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30622action=edit
Alexandre's patch as a file rather than as text.

[Bug c++/57825] Template specialization for ref qualified member pointers

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57825

Jason Merrill jason at gcc dot gnu.org changed:

   What|Removed |Added

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

[Bug target/56979] ICE in output_operand: invalid operand for code 'P'

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56979

--- Comment #4 from joseph at codesourcery dot com joseph at codesourcery dot 
com ---
On Sat, 3 Aug 2013, rearnsha at gcc dot gnu.org wrote:

 Although the compiler shouldn't ICE, it's arguable that passing over-aligned
 values by value to functions is not supportable (c11, for example, does not
 support over-aligning function arguments even though it does permit
 over-aligning some other objects) and that this case is really an ICE on
 invalid.

I see no such restriction in C11.  You can't use _Alignas directly on a 
parameter, but if you have somehow constructed an over-aligned type (and, 
as I noted on the WG14 reflector some time ago, and more recently in 
N1731, there is no syntax for doing so despite the discussion of such 
types in C11), being a struct or union with an alignment specifier used 
therein, nothing I see prohibits passing it to a function - it's simply 
implementation-defined whether that is a context in which such a type is 
supported.

[Bug c/57956] missing 'msgstr' section errors when building

[dj at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57956

DJ Delorie dj at redhat dot com changed:

   What|Removed |Added

 CC||dj at redhat dot com

--- Comment #2 from DJ Delorie dj at redhat dot com ---
I tracked this down to a PO file that requires a newer version of gettext than
the gcc prereq page requires:

http://gcc.gnu.org/ml/gcc/2013-07/msg00203.html

[Bug c++/57850] Option -fdump-translation-unit not working

[singhai at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57850

--- Comment #7 from Sharad Singhai singhai at gcc dot gnu.org ---
I looked at it and this issue seems related to handling of PCH files. The
following patch introduced it

http://gcc.gnu.org/viewcvs/gcc/trunk/gcc/cp/decl2.c?r1=194363r2=194362pathrev=194363

When only a header file is being compiled then cp_write_global_declarations ()
returns immediately without doing any extra work. Thus dump code (and
everything else) is skipped.

I don't know what should be the right course of action here. If it is only the
dump functionality that needs to be restored, I can perhaps work around with
some restructuring. However, there is a lot of other processing which should be
skipped in case of PCH. Suggestions?

Thanks,
Sharad

[Bug c++/57255] [meta-bug] ref-qualifiers

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57255

Bug 57255 depends on bug 57825, which changed state.

Bug 57825 Summary: Template specialization for ref qualified member pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57825

   What|Removed |Added

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

[Bug c++/57825] Template specialization for ref qualified member pointers

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57825

Jason Merrill jason at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |4.8.2

--- Comment #8 from Jason Merrill jason at gcc dot gnu.org ---
Fixed in r201550 (trunk) and r201551 (4.8).

[Bug target/56102] Wrong rtx cost calculated for Thumb1

[amker.cheng at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56102

bin.cheng amker.cheng at gmail dot com changed:

   What|Removed |Added

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

--- Comment #4 from bin.cheng amker.cheng at gmail dot com ---
Yes, it's fixed by that checkin.

[Bug target/57540] stack pointer related loop invariants after reload for ARM mode

[amker.cheng at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57540

bin.cheng amker.cheng at gmail dot com changed:

   What|Removed |Added

  Component|middle-end  |target

--- Comment #4 from bin.cheng amker.cheng at gmail dot com ---
Sorry, according to http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00932.html,
This seems should be fixed in backend.  I will fixed this in
arm_legitimize_address, so I change this entry to TARGET.

[Bug tree-optimization/58095] SIMD code requiring auxiliary array for best optimization

[siavashserver at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58095

--- Comment #3 from Siavash Eliasi siavashserver at gmail dot com ---
I did an experiment with using raw float data types instead of __m128 data
type. This time GCC, Clang and ICC were able to generate desired code, even
without using __restric__ keyword, but a little more dirty (Pointer
arithmetics).

Not most, but I'm sure that new video decoder/encoder, game engines and similar
applications are using __m128 data types directly instead of float data types,
because (1) it guarantees them to be 16byte aligned, (2) removes the need to
manually load/store data from memory to XMM/YMM registers, (3) makes the source
code smaller and easier to maintain and (4) much more clean and smaller
generated code.

In conclusion, I don't think issue me and other people are facing is related to
not using __restrict__ keyword. All compilers fail to generate optimal code
when facing __m128 data types. However as an exception, ICC is able to generate
optimal code when facing __m128 data types and __restrict__ keyword mixed.

Here is what I have tried:

#include xmmintrin.h

void fooFloat(float* a, float* b, float* d, float* c, unsigned int size)
{
for (unsigned int i = 0; i  size; i+=32)
{
__m128 ax[8], bx[8], cx[8], dx[8];

ax[0] = _mm_load_ps(a[i*32+0]);
ax[1] = _mm_load_ps(a[i*32+4]);
ax[2] = _mm_load_ps(a[i*32+8]);
ax[3] = _mm_load_ps(a[i*32+12]);
ax[4] = _mm_load_ps(a[i*32+16]);
ax[5] = _mm_load_ps(a[i*32+20]);
ax[6] = _mm_load_ps(a[i*32+24]);
ax[7] = _mm_load_ps(a[i*32+28]);

bx[0] = _mm_load_ps(b[i*32+0]);
bx[1] = _mm_load_ps(b[i*32+4]);
bx[2] = _mm_load_ps(b[i*32+8]);
bx[3] = _mm_load_ps(b[i*32+12]);
bx[4] = _mm_load_ps(b[i*32+16]);
bx[5] = _mm_load_ps(b[i*32+20]);
bx[6] = _mm_load_ps(b[i*32+24]);
bx[7] = _mm_load_ps(b[i*32+28]);

dx[0] = _mm_load_ps(d[i*32+0]);
dx[1] = _mm_load_ps(d[i*32+4]);
dx[2] = _mm_load_ps(d[i*32+8]);
dx[3] = _mm_load_ps(d[i*32+12]);
dx[4] = _mm_load_ps(d[i*32+16]);
dx[5] = _mm_load_ps(d[i*32+20]);
dx[6] = _mm_load_ps(d[i*32+24]);
dx[7] = _mm_load_ps(d[i*32+28]);

cx[0] = _mm_add_ps(ax[0], _mm_mul_ps(dx[0], bx[0]));
cx[1] = _mm_add_ps(ax[1], _mm_mul_ps(dx[1], bx[1]));
cx[2] = _mm_add_ps(ax[2], _mm_mul_ps(dx[2], bx[2]));
cx[3] = _mm_add_ps(ax[3], _mm_mul_ps(dx[3], bx[3]));
cx[4] = _mm_add_ps(ax[4], _mm_mul_ps(dx[4], bx[4]));
cx[5] = _mm_add_ps(ax[5], _mm_mul_ps(dx[5], bx[5]));
cx[6] = _mm_add_ps(ax[6], _mm_mul_ps(dx[6], bx[6]));
cx[7] = _mm_add_ps(ax[7], _mm_mul_ps(dx[7], bx[7]));

_mm_store_ps(c[i*32+0], cx[0]);
_mm_store_ps(c[i*32+4], cx[1]);
_mm_store_ps(c[i*32+8], cx[2]);
_mm_store_ps(c[i*32+12], cx[3]);
_mm_store_ps(c[i*32+16], cx[4]);
_mm_store_ps(c[i*32+20], cx[5]);
_mm_store_ps(c[i*32+24], cx[6]);
_mm_store_ps(c[i*32+28], cx[7]);
}
}

And its output using GCC 4.8.1 -O2 :

fooFloat(float*, float*, float*, float*, unsigned int):
pushr15
xorr15d, r15d
testr8d, r8d
moveax, 4
pushr14
pushr13
pushr12
pushrbp
pushrbx
je.L15
.L19:
lear12d, [rax+4]
leaebp, [rax+8]
leaebx, [rax+12]
lear11d, [rax+16]
lear10d, [rax+20]
lear9d, [rax+24]
movr14d, r15d
movr13d, eax
addr15d, 32
salr14d, 5
movapsxmm6, XMMWORD PTR [rdx+r13*4]
addeax, 1024
cmpr8d, r15d
movapsxmm7, XMMWORD PTR [rdx+r14*4]
mulpsxmm6, XMMWORD PTR [rsi+r13*4]
movapsxmm5, XMMWORD PTR [rdx+r12*4]
mulpsxmm7, XMMWORD PTR [rsi+r14*4]
movapsxmm4, XMMWORD PTR [rdx+rbp*4]
mulpsxmm5, XMMWORD PTR [rsi+r12*4]
movapsxmm3, XMMWORD PTR [rdx+rbx*4]
mulpsxmm4, XMMWORD PTR [rsi+rbp*4]
movapsxmm2, XMMWORD PTR [rdx+r11*4]
mulpsxmm3, XMMWORD PTR [rsi+rbx*4]
movapsxmm1, XMMWORD PTR [rdx+r10*4]
mulpsxmm2, XMMWORD PTR [rsi+r11*4]
movapsxmm0, XMMWORD PTR [rdx+r9*4]
mulpsxmm1, XMMWORD PTR [rsi+r10*4]
addpsxmm7, XMMWORD PTR [rdi+r14*4]
mulpsxmm0, XMMWORD PTR [rsi+r9*4]
addpsxmm6, XMMWORD PTR [rdi+r13*4]
addpsxmm5, XMMWORD PTR [rdi+r12*4]
addpsxmm4, XMMWORD PTR [rdi+rbp*4]
addpsxmm3, XMMWORD PTR [rdi+rbx*4]
addpsxmm2, XMMWORD PTR [rdi+r11*4]
addpsxmm1, XMMWORD PTR [rdi+r10*4]
addpsxmm0, XMMWORD PTR [rdi+r9*4]
movapsXMMWORD PTR [rcx+r14*4], xmm7
movapsXMMWORD PTR [rcx+r13*4], xmm6
movapsXMMWORD PTR [rcx+r12*4], xmm5
movapsXMMWORD PTR [rcx+rbp*4], xmm4
movapsXMMWORD PTR [rcx+rbx*4], xmm3
movapsXMMWORD PTR [rcx+r11*4], xmm2
movapsXMMWORD PTR [rcx+r10*4], xmm1
movaps