[Bug tree-optimization/59789] [4.9 Regression] ICE in in convert_move, at expr.c:333

[aivchenk at gmail dot com]

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

--- Comment #7 from Alexander Ivchenko  ---
(In reply to H.J. Lu from comment #3)
> (In reply to Alexander Ivchenko from comment #2)
> > lets just say that my code is valid and I forgot to add "-msse2" :).
> > 
> 
> Does GCC ICE with -msse2?

No, you were right when you said that the code is incorrect. Seems that I
accidentally found this bug when compiling the initial code without "-msse2".

[Bug target/59797] GCC doesn't warn AVX-512 ABI change

[kirill.yukhin at intel dot com]

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

--- Comment #1 from Yukhin Kirill  ---
Sorry, didn't get the problem.

According to output you provided - GCC warns ABI changes

Here is analogue for AVX2:
$ cat 2.c
typedef long long __m256i __attribute__ ((__vector_size__ (32),
__may_alias__));

__m256i
f1(__m256i x, __m256i y)
{
  return y;
}
$ gcc -S 2.c
2.c: In function ‘f1’:
2.c:4:1: note: The ABI for passing parameters with 32-byte alignment has
changed in GCC 4.6
 f1(__m256i x, __m256i y)
 ^
2.c:4:1: warning: AVX vector argument without AVX enabled changes the ABI
[enabled by default]

Difference is that AVX[2] warns about using data types without enabling
AVX2. Is that the case

[Bug c++/59800] New: Compilation with g++ fails when -Ofast -flto is used to compile code using some distribution

[rionda at gmail dot com]

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

Bug ID: 59800
   Summary: Compilation with g++ fails when -Ofast -flto is used
to compile code using some  distribution
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rionda at gmail dot com

Created attachment 31828
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31828&action=edit
Code that fails

The attached code compiles cleanly when using 
g++ -Ofast -Wall -Wextra -Wno-unused-parameter test.cpp test.cpp
and when using
g++ -flto -Wall -Wextra -Wno-unused-parameter test.cpp
but fails when using "g++8 -std=c++11 -Ofast -flto -Wall -Wextra
-Wno-unused-parameter test.cpp" (i.e., when using both -Ofast and -flto).

The reported error is:
test.cpp: In function 'main':
/opt/local/include/gcc48/c++/bits/random.h:2404:60: warning: 'MEM[(struct
normal_distribution *)&my_lognormal + 16B]._M_saved' may be used uninitialized
in this function [-Wmaybe-uninitialized]
 { return std::exp(__p.s() * _M_nd(__urng) + __p.m()); }
^
test.cpp:11:33: note: 'MEM[(struct normal_distribution *)&my_lognormal +
16B]._M_saved' was declared here
  lognormal_distribution my_lognormal(0.0, 1.0);
 ^

I am running 
g++-mp-4.8 (MacPorts gcc48 4.8.2_0) 4.8.2
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
on Mac OS X 10.6.8
(uname -a : darwin .local 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun  7
16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386)

[Bug target/59794] [4.7/4.8/4.9 Regression] i386 backend fails to detect MMX/SSE/AVX return value

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

  Attachment #31826|0   |1
is obsolete||

--- Comment #5 from H.J. Lu  ---
Created attachment 31827
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31827&action=edit
An updated patch

[Bug target/59794] [4.7/4.8/4.9 Regression] i386 backend fails to detect MMX/SSE/AVX return value

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||rth at gcc dot gnu.org
Summary|i386 backend fails to   |[4.7/4.8/4.9 Regression]
   |detect SSE/AVX return value |i386 backend fails to
   ||detect MMX/SSE/AVX return
   ||value

--- Comment #4 from H.J. Lu  ---
This is a regression:

[hjl@gnu-6 tmp]$ cat m1.i
typedef int __v2si __attribute__ ((__vector_size__ (8)));

extern __v2si y;

__v2si
foo ()
{
  return y;
}
[hjl@gnu-6 tmp]$ cc -S -mno-mmx m1.i -m32
[hjl@gnu-6 tmp]$ 

This may be caused by r83533.  ix86_struct_value_rtx sees BLKmode
when SSE is disabled and DImode when MMX is disabled.

[Bug target/59799] aarch64_pass_by_reference never passes arrays by value, contrary to ABI documentation

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

 CC||ian at airs dot com

--- Comment #3 from Ian Lance Taylor  ---
Go supports passing arrays by value.  That's where Michael ran into this issue
(http://golang.org/issue/7120).

[Bug target/59799] aarch64_pass_by_reference never passes arrays by value, contrary to ABI documentation

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> Does go or Ada allow passing arrays by value?

I know fortran does not at least directly.  In that the front-end creates a
structure for the argument instead.

[Bug target/59799] aarch64_pass_by_reference never passes arrays by value, contrary to ABI documentation

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
"It should be noted that the above algorithm makes provision for languages
other than C and C++ in that it provides 
for passing arrays by value and for passing arguments of dynamic size."

Note the other than C/C++ part here.  This means it only effects non C/C++
languages.

Does go or Ada allow passing arrays by value?

[Bug target/59799] New: aarch64_pass_by_reference never passes arrays by value, contrary to ABI documentation

[michael.hudson at linaro dot org]

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

Bug ID: 59799
   Summary: aarch64_pass_by_reference never passes arrays by
value, contrary to ABI documentation
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: michael.hudson at linaro dot org

It's always possible I'm totally misunderstanding something here, but it seems
that this code:

  /* Arrays always passed by reference.  */
  if (TREE_CODE (type) == ARRAY_TYPE)
return true;

in gcc/config/aarch64/aarch64.c does not agree with the rules from "Procedure
Call Standard for the ARM 64-bit Architecture"
(http://infocenter.arm.com/help/topic/com.arm.doc.ihi0055b/IHI0055B_aapcs64.pdf).
 As far as I can see the rules on page 18 and 19 make no distinction between
arrays and structs and they can both be passed in registers when small enough.

[Bug preprocessor/59782] libcpp does not avoid bug #48326 when compiled by older GCC

[michael at talosis dot ca]

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

--- Comment #4 from Michael Deutschmann  ---
> According to [1], 4.7.1 is already OK, so > 4007 should be enough.

But 4.7.0 isn't OK, so >= 4007 isn't enough.  (> 4007 is functionally
equivalent to >= 4008.)

Note that this does make fixing 4.7.4 (which I suggest should be done otherwise
a person starting with 4.7.0, no C++, and a cmov-less processor will face a
circuitous route up to the current version.) a little more complicated. 
GCC_VERSION >= 4007 isn't good enough, but GCC_VERSION >= 4008 would mean that
4.7.4 would never include the MMX code when compiled with itself.  Some would
call that a regression.

It's a simple matter of preprocessor programming to check the patchlevel too,
but it will be an ugly #if statement

If only there was a NOT_STAGE_1 macro... (is there?).

[Bug c/59785] atomic_store should load source operand atomically?

[ma.jiang at zte dot com.cn]

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

--- Comment #2 from ma.jiang at zte dot com.cn ---
Ok, Thanks for the reply. I know what you mean. A atomic_store is not
responsible for loading the source operand atomically as it is just a store.

[Bug fortran/59796] Deallocate aborts even with STAT=

[w6ws at earthlink dot net]

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

--- Comment #3 from Walter Spector  ---
My initial reaction is that yes, 6.7.3.3 in F08 states what you quoted.  And I
agree that it is a programming error to pass a dangling pointer into
deallocate.  But that does not preclude gfortran from returning some sort of
error back to the user when stat= is present.  In fact, 6.7.4 seems to
*require* it - at least in the case of co-arrays.  (... "If any other error
condition occurs...")  So I don't see a conflict in the Standard.

[Bug c++/59798] New: ICE befriending an inheriting constructor template specialization

[richard-gccbugzilla at metafoo dot co.uk]

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

Bug ID: 59798
   Summary: ICE befriending an inheriting constructor template
specialization
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: richard-gccbugzilla at metafoo dot co.uk

This:

  struct A { template A(T); };
  struct B : A { using A::A; };
  struct C { friend B::B(int); };
  B b(0);

gives this:

:3:21: internal compiler error: tree check: expected record_type or
union_type or qual_union_type, have integer_type in lookup_base, at
cp/search.c:215
0xd619a4 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../src/gcc/tree.c:9192
0x6be836 tree_check3
../../src/gcc/tree.h:2747
0x6be836 lookup_base(tree_node*, tree_node*, int, base_kind*, int)
../../src/gcc/cp/search.c:215
0x619b21 build_base_path(tree_code, tree_node*, tree_node*, int, int)
../../src/gcc/cp/class.c:281
0x6b1273 add_one_base_init
../../src/gcc/cp/method.c:515
0x6b7ad1 do_build_copy_constructor
../../src/gcc/cp/method.c:574
0x6b7ad1 synthesize_method(tree_node*)
../../src/gcc/cp/method.c:796
0x628444 mark_used(tree_node*, int)
../../src/gcc/cp/decl2.c:4779
0x5554a9 build_over_call
../../src/gcc/cp/call.c:7119
0x550e85 build_new_method_call_1
../../src/gcc/cp/call.c:7818
0x550e85 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
../../src/gcc/cp/call.c:7888
0x551f67 build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
../../src/gcc/cp/call.c:7444
0x6a9739 expand_default_init
../../src/gcc/cp/init.c:1673
0x6a9739 expand_aggr_init_1
../../src/gcc/cp/init.c:1774
0x6ac403 build_aggr_init(tree_node*, tree_node*, int, int)
../../src/gcc/cp/init.c:1525
0x5663f4 build_aggr_init_full_exprs
../../src/gcc/cp/decl.c:5591
0x5663f4 check_initializer
../../src/gcc/cp/decl.c:5727
0x578c8d cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../src/gcc/cp/decl.c:6396
0x668fbd cp_parser_init_declarator
../../src/gcc/cp/parser.c:16804
0x66a76f cp_parser_simple_declaration
../../src/gcc/cp/parser.c:11195

[Bug target/59794] i386 backend fails to detect SSE/AVX return value

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  ---
Created attachment 31826
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31826&action=edit
A patch

I am testing this patch.

[Bug target/59744] miscompilation of unsigned comparison on aarch64

[michael.hudson at linaro dot org]

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

--- Comment #7 from Michael Hudson-Doyle  ---
I saw the problem with Linaro GCC 4.8, but haven't tried the vanilla 4.8
branch.  If the committed test case doesn't fail, I'll believe that it is not a
problem.  Sorry for the noise.

[Bug target/59794] i386 backend fails to detect SSE/AVX return value

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.4

--- Comment #2 from H.J. Lu  ---
For -m32, the same warning is issued twice:

[hjl@gnu-6 gcc]$ gcc -mno-sse
/export/gnu/import/git/gcc/gcc/testsuite/gcc.target/i386/pr53425-1.c -m32 -S
-Wno-psabi
/export/gnu/import/git/gcc/gcc/testsuite/gcc.target/i386/pr53425-1.c: In
function ‘foo’:
/export/gnu/import/git/gcc/gcc/testsuite/gcc.target/i386/pr53425-1.c:14:7:
warning: SSE vector argument without SSE enabled changes the ABI [enabled by
default]
   bar (x); /* { dg-message "warning: SSE vector argument without SSE enabled
changes the ABI" } */
   ^
/export/gnu/import/git/gcc/gcc/testsuite/gcc.target/i386/pr53425-1.c:14:7:
warning: SSE vector argument without SSE enabled changes the ABI [enabled by
default]
[hjl@gnu-6 gcc]$ gcc -mno-sse
/export/gnu/import/git/gcc/gcc/testsuite/gcc.target/i386/pr53425-1.c -S
-Wno-psabi
/export/gnu/import/git/gcc/gcc/testsuite/gcc.target/i386/pr53425-1.c: In
function ‘foo’:
/export/gnu/import/git/gcc/gcc/testsuite/gcc.target/i386/pr53425-1.c:14:7:
warning: SSE vector argument without SSE enabled changes the ABI [enabled by
default]
   bar (x); /* { dg-message "warning: SSE vector argument without SSE enabled
changes the ABI" } */
   ^
[hjl@gnu-6 gcc]$

[Bug target/59794] i386 backend fails to detect SSE/AVX return value

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-01-13
Version|4.9.0   |4.7.0
Summary|i386 backend fails to   |i386 backend fails to
   |detect SSE return value |detect SSE/AVX return value
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
The same problem with AVX for both -m32/-m64:

[hjl@gnu-6 gcc]$ cat /tmp/a.i 
typedef long long __m256i __attribute__ ((__vector_size__ (32),
__may_alias__));

extern __m256i y;

__m256i
f1()
{
  return y;
}
[hjl@gnu-6 gcc]$ gcc -mno-avx /tmp/a.i -S -O
[hjl@gnu-6 gcc]$ gcc -mno-avx /tmp/a.i -S -O -m32
[hjl@gnu-6 gcc]$

[Bug fortran/59796] Deallocate aborts even with STAT=

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to Walter Spector from comment #0)
> Yes, this is probably a duplicate of the now-closed bug 44504.
> 
> The following code returns a stat of 0 from g95, PGI (v13.8), and NAG
> (v5.3.1).  However Intel and gfortran abend - which is not very friendly. 
> Who is right?
> 
> program double_dealloc
>   implicit none
> 
>   integer, pointer :: ip1(:), ip2(:)
>   integer :: memstat
> 
>   allocate (ip1(42))
>   ip2 => ip1
>   deallocate (ip1)
>   deallocate (ip2, stat=memstat)
>   print *, 'memstat =', memstat
> 
> end program
> 
> The Fortran 2008 Standard, in section 6.7.4 pertaining to the STAT=
> specifier, starts off somewhat vague with respect to STAT= when there is an
> error.  In paragraph 2 it only states that upon success, a value of 0 is set.

I believe the code is invalid, so gfortran can do whatever it wants.
6.7.3.3 in F08 states:

   If a pointer appears in a DEALLOCATE statement, its association
   status shall be defined.

When you deallocate ip1, doesn't the associate status of ip2 become
undefined?  If fact, 16.5.2.8 appears to muddy the waters.  It states

   If the association status of a pointer is disassociated or undefined,
   the pointer shall not be referenced or deallocated.  Whatever its
   association status, a pointer always may be nullified, allocated, or
   pointer assigned.  A nullified pointer is disassociated.  When a
   pointer is allocated, it becomes associated but undefined.

One might argue about quality of implementation of gfortran, but in 
the end it seems to be the programmers responsibility to ensure the
pointer is not undefined.

[Bug middle-end/59776] [4.8/4.9 Regression] gcc -g -O1 ICE in expand_debug_locations, at cfgexpand.c:3865

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu.org

--- Comment #6 from Marek Polacek  ---
Started with r195015.

[Bug target/59797] New: GCC doesn't warn AVX-512 ABI change

[hjl.tools at gmail dot com]

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

Bug ID: 59797
   Summary: GCC doesn't warn AVX-512 ABI change
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: kirill.yukhin at intel dot com

[hjl@gnu-6 gcc]$ cat /tmp/z.i
typedef long long __m512i __attribute__ ((__vector_size__ (64),
__may_alias__));

__m512i
f1(__m512i x, __m512i y)
{
  return y;
}
[hjl@gnu-6 gcc]$ ./xgcc -B./ -S -O /tmp/z.i
/tmp/z.i: In function ‘f1’:
/tmp/z.i:4:1: note: The ABI for passing parameters with 64-byte alignment has
changed in GCC 4.6
 f1(__m512i x, __m512i y)
 ^
[hjl@gnu-6 gcc]$ ./xgcc -B./ -S -O /tmp/z.i -mavx512f
[hjl@gnu-6 gcc]$ 

When -mavx512f isn't used, GCC should warn ABI changes for passing/returning
AVX vector values.

[Bug target/59797] GCC doesn't warn AVX-512 ABI change

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-01-13
   Target Milestone|--- |4.9.0
 Ever confirmed|0   |1

[Bug fortran/59796] Deallocate aborts even with STAT=

[w6ws at earthlink dot net]

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

--- Comment #1 from Walter Spector  ---
Forgot to mention: The test case was tested with gfortran 4.7.3 and 4.8.2.

[Bug fortran/59796] New: Deallocate aborts even with STAT=

[w6ws at earthlink dot net]

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

Bug ID: 59796
   Summary: Deallocate aborts even with STAT=
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: w6ws at earthlink dot net

Yes, this is probably a duplicate of the now-closed bug 44504.

The following code returns a stat of 0 from g95, PGI (v13.8), and NAG (v5.3.1).
 However Intel and gfortran abend - which is not very friendly.  Who is right?

program double_dealloc
  implicit none

  integer, pointer :: ip1(:), ip2(:)
  integer :: memstat

  allocate (ip1(42))
  ip2 => ip1
  deallocate (ip1)
  deallocate (ip2, stat=memstat)
  print *, 'memstat =', memstat

end program

The Fortran 2008 Standard, in section 6.7.4 pertaining to the STAT= specifier,
starts off somewhat vague with respect to STAT= when there is an error.  In
paragraph 2 it only states that upon success, a value of 0 is set.

However in paragraph 3, which pertains to co-array allocation, it does
explicitly state that "...  If any other error condition occurs during
execution of the ALLOCATE or DEALLOCATE statement, the stat-variable becomes de
ned with a processor-dependent positive integer value different from
STAT STOPPED IMAGE. In either case, each allocate-object has a
processor-dependent status..."

Also in the following Note 6.25, it states "The status of objects that were not
successfully allocated or deallocated can be individually checked with
the intrinsic functions ALLOCATED or ASSOCIATED."

>From these last two sets of statements, it seems clear that the intent of the
Standard is that no deallocation should cause an abend when stat= is present.

[Bug c++/59606] Internal compiler error: Error reporting routines re-entered.

[vyf at princeton dot edu]

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

vyf at princeton dot edu changed:

   What|Removed |Added

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

--- Comment #3 from vyf at princeton dot edu ---
It seems there are two bug reports for the same thing.

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

[Bug c++/59607] Internal compiler error: Error reporting routines re-entered.

[vyf at princeton dot edu]

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

--- Comment #2 from vyf at princeton dot edu ---
*** Bug 59606 has been marked as a duplicate of this bug. ***

[Bug c++/59606] Internal compiler error: Error reporting routines re-entered.

[vyf at princeton dot edu]

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

--- Comment #2 from vyf at princeton dot edu ---
(In reply to Daniel Krügler from comment #1)
> It seems that you missed the attachment.

It seems two bug reports have been made by accident - I don't know why, I only
filed one (Bug #59607, http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59607). I'll
mark this one as a duplicate.

[Bug c++/59606] Internal compiler error: Error reporting routines re-entered.

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #1 from Daniel Krügler  ---
It seems that you missed the attachment.

[Bug c++/59795] New: Invalid use of "this" in a local class not diagnosed

[hstong at ca dot ibm.com]

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

Bug ID: 59795
   Summary: Invalid use of "this" in a local class not diagnosed
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hstong at ca dot ibm.com

The following is reduced from the example in N3290 subclause 5.1.1
[expr.prim.general] paragraph 5:

class Outer {
   void f() {
  struct Inner {
 int c[sizeof(*this)]; // error: not inside a member function of Inner
  };
   }
};

GCC does not provide a diagnostic for this although, the declaration in
question runs afoul of the constraint in paragraph 4 for the subclause by using
"this" elsewhere in the member-declarator.

## Compile command:
g++-4.8 -std=c++11 nestedClassThisNonStaticDataMemDiag.cc

## Actual output:
(No diagnostics; clean compile).

## Expected output:
(Error message).

## g++ -v:
Using built-in specs.
COLLECT_GCC=/usr/bin/g++-4.8
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.8.1-2ubuntu1~12.04' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.1 (Ubuntu 4.8.1-2ubuntu1~12.04)

[Bug target/59794] New: i386 backend fails to detect SSE return value

[hjl.tools at gmail dot com]

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

Bug ID: 59794
   Summary: i386 backend fails to detect SSE return value
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: ubizjak at gmail dot com

[hjl@gnu-6 gcc]$ cat /tmp/f.i
typedef int __v4si __attribute__ ((__vector_size__ (16)));
typedef long long __m128i __attribute__ ((__vector_size__ (16),
__may_alias__));

__m128i
f1(void)
{
  return __extension__ (__m128i)(__v4si){ 0, 0, 0, 0 };
}
[hjl@gnu-6 gcc]$ gcc -S -O /tmp/f.i -mno-sse -m32
[hjl@gnu-6 gcc]$ gcc -S -O /tmp/f.i -mno-sse 
/tmp/f.i: In function ‘f1’:
/tmp/f.i:6:1: error: SSE register return with SSE disabled
 {
 ^
[hjl@gnu-6 gcc]$ 

Both -m32 and -m64 should issue the same warning.

[Bug fortran/59781] [4.7/4.8/4.9 Regression] [F03] Incorrect initialisation of derived type

[janus at gcc dot gnu.org]

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

--- Comment #6 from janus at gcc dot gnu.org ---
(In reply to janus from comment #5)
> Here is a draft patch which seems to fix comment 1 to 3:

Unfortunately it does produce a few failures in the coarray sector:

FAIL: gfortran.dg/coarray/alloc_comp_1.f90 -fcoarray=single  -O2  (internal
compiler error)
FAIL: gfortran.dg/coarray/lib_realloc_1.f90 -fcoarray=single  -O2  (internal
compiler error)
FAIL: gfortran.dg/coarray/subobject_1.f90 -fcoarray=single  -O2  (internal
compiler error)
FAIL: gfortran.dg/coarray_lib_realloc_1.f90  -O  (internal compiler error)

[Bug fortran/31124] Warn of unused PRIVATE module variables/procedures

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||4.8.2, 4.9.0
 Resolution|--- |FIXED
  Known to fail||4.4.7, 4.5.5, 4.6.4, 4.7.3

--- Comment #4 from Dominique d'Humieres  ---
Compiling the test with gfortran 4.8 r190335 (2012-08-13) and -Wunused gives
the warning

pr31124.f90:11:0: warning: 'bar' defined but not used [-Wunused-function]
 subroutine bar()
 ^

r190335 (2012-08-13) does not give any warning. This has been fixed likely by
r190325

Author:burnus
Date:Sun Aug 12 09:52:33 2012 UTC (17 months ago)
Changed paths:5
Log Message:
2012-08-12  Tobias Burnus  

PR fortran/54221
* trans-decl.c (gfc_finish_var_decl, build_function_decl):
Fix setting private module vars/procs as TREE_PUBLIC(...) = 0.

2012-08-12  Tobias Burnus  

PR fortran/54221
* vect/vect-gems.f90: Don't mark module vars as PRIVATE as
they appear uninitialized on the RHS.
* gfortran.dg/public_private_module_6.f90: New.


Closing as FIXED.

[Bug middle-end/56344] ICE for program with very large structs returned by value

[mpolacek at gcc dot gnu.org]

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

--- Comment #12 from Marek Polacek  ---
(In reply to Georg from comment #11)
> For clarity, just asking: Does this mean that
> 
> 1.  if I compile a program on HOST with bit size N,
> for a TARGET with bit size M, then gcc will sorry()
> just in case the object passed is larger than 1<<30,
> irrespective of N and M?

Here we are looking at HOST bits-per-int.

> 2. Would this need to be documented per implementation?

I don't believe so, it's not implementation-defined behavior.

[Bug debug/54694] [4.7/4.8/4.9 Regression] internal compiler error: in dwarf2out_frame_debug_expr, at dwarf2out.c:2387

[toralf.foerster at gmx dot de]

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

--- Comment #16 from Toralf Förster  ---
(In reply to Richard Henderson from comment #15)
> So one
> can also fix the "problem" by upgrading from qemu-kvm-1.1 to qemu-1.7.
app-emulation/qemu1.4.2 doesn't show the error

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

[hjl at gcc dot gnu.org]

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

--- Comment #24 from hjl at gcc dot gnu.org  ---
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

[Bug debug/54694] [4.7/4.8/4.9 Regression] internal compiler error: in dwarf2out_frame_debug_expr, at dwarf2out.c:2387

[rth at gcc dot gnu.org]

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

--- Comment #15 from Richard Henderson  ---
I'm tempted to simply say this is user-error.  It's the use of the global
register of EBP that's causing the problem.  And honestly I don't see a
way around it.

The only possible resolution I could see is to generate an error or sorry
earlier, before the ICE.  But it still wouldn't let the test case compile.

Anyway that's exactly why current QEMU does not do this anymore.  So one
can also fix the "problem" by upgrading from qemu-kvm-1.1 to qemu-1.7.

[Bug tree-optimization/59617] [vectorizer] ICE in vectorizable_mask_load_store with AVX-512F's gathers enabled.

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Author: jakub
Date: Mon Jan 13 19:16:30 2014
New Revision: 206585

URL: http://gcc.gnu.org/viewcvs?rev=206585&root=gcc&view=rev
Log:
PR target/59617
* config/i386/i386.c (ix86_vectorize_builtin_gather): Uncomment
AVX512F gather builtins.
* tree-vect-stmts.c (vectorizable_mask_load_store): For now punt
on gather decls with INTEGER_TYPE masktype.
(vectorizable_load): For INTEGER_TYPE masktype, put the INTEGER_CST
directly into the builtin rather than hoisting it before loop.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/tree-vect-stmts.c

[Bug tree-optimization/59387] [4.9 Regression] wrong code (hangs) at -Os on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Author: jakub
Date: Mon Jan 13 19:14:03 2014
New Revision: 206583

URL: http://gcc.gnu.org/viewcvs?rev=206583&root=gcc&view=rev
Log:
PR tree-optimization/59387
* tree-scalar-evolution.c: Include gimple-fold.h and gimplify-me.h.
(scev_const_prop): If folded_casts and type has undefined overflow,
use force_gimple_operand instead of force_gimple_operand_gsi and
for each added stmt if it is assign with
arith_code_with_undefined_signed_overflow, call
rewrite_to_defined_overflow.
* tree-ssa-loop-im.c: Don't include gimplify-me.h, include
gimple-fold.h instead.
(arith_code_with_undefined_signed_overflow,
rewrite_to_defined_overflow): Moved to ...
* gimple-fold.c (arith_code_with_undefined_signed_overflow,
rewrite_to_defined_overflow): ... here.  No longer static.
Include gimplify-me.h.
* gimple-fold.h (arith_code_with_undefined_signed_overflow,
rewrite_to_defined_overflow): New prototypes.

* gcc.c-torture/execute/pr59387.c: New test.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-fold.c
trunk/gcc/gimple-fold.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-scalar-evolution.c
trunk/gcc/tree-ssa-loop-im.c

[Bug c++/59793] New: Warning to suggest making trivial non-virtual method inline

[eugene.zelenko at gmail dot com]

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

Bug ID: 59793
   Summary: Warning to suggest making trivial non-virtual method
inline
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eugene.zelenko at gmail dot com

Hi!

I think will be great to have warning which will suggest to make trivial
non-vuirtual method inline and move to class declaration. Possible criteria of
trivial: 1 line of code dealing only with trivial data types (pointer, integer,
float, etc).

Eugene.

[Bug c++/59792] New: Warning to suggest making non-virtual method const

[eugene.zelenko at gmail dot com]

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

Bug ID: 59792
   Summary: Warning to suggest making non-virtual method const
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eugene.zelenko at gmail dot com

Hi!

I think will be great to have warning which will suggest to make non-vuirtual
method const if doesn't modify object's state and/or call only other const
methods.

Eugene.

[Bug c++/59791] New: [4.9 Regression] ICE: Error reporting routines re-entered. with -fcompare-debug

[zsojka at seznam dot cz]

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

Bug ID: 59791
   Summary: [4.9 Regression] ICE: Error reporting routines
re-entered. with -fcompare-debug
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz

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

Compiler output:
$ gcc -std=c++0x -fcompare-debug testcase.C 


Internal compiler error: Error reporting routines re-entered.
0x6bddca tsubst_copy
/mnt/svn/gcc-trunk/gcc/cp/pt.c:12480
0x6987c9 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/mnt/svn/gcc-trunk/gcc/cp/pt.c:14961
0x698b43 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/mnt/svn/gcc-trunk/gcc/cp/pt.c:14175
0x6ad4b8 tsubst(tree_node*, tree_node*, int, tree_node*)
/mnt/svn/gcc-trunk/gcc/cp/pt.c:12057
0x728525 dump_template_bindings
/mnt/svn/gcc-trunk/gcc/cp/error.c:330
0x728525 dump_substitution
/mnt/svn/gcc-trunk/gcc/cp/error.c:1386
0x72af9e decl_as_string_translate(tree_node*, int)
/mnt/svn/gcc-trunk/gcc/cp/error.c:2740
0x7de4eb cxx_printable_name_internal
/mnt/svn/gcc-trunk/gcc/cp/tree.c:1979
0x72a612 cp_print_error_function
/mnt/svn/gcc-trunk/gcc/cp/error.c:3081
0x72a612 cp_diagnostic_starter
/mnt/svn/gcc-trunk/gcc/cp/error.c:3026
0x15cc538 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
/mnt/svn/gcc-trunk/gcc/diagnostic.c:791
0x15cd29f internal_error(char const*, ...)
/mnt/svn/gcc-trunk/gcc/diagnostic.c:1129
0x15cbaf3 fancy_abort(char const*, int, char const*)
/mnt/svn/gcc-trunk/gcc/diagnostic.c:1183
0x6bddca tsubst_copy
/mnt/svn/gcc-trunk/gcc/cp/pt.c:12480
0x6987c9 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/mnt/svn/gcc-trunk/gcc/cp/pt.c:14961
0x698b43 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/mnt/svn/gcc-trunk/gcc/cp/pt.c:14175
0x6ad4b8 tsubst(tree_node*, tree_node*, int, tree_node*)
/mnt/svn/gcc-trunk/gcc/cp/pt.c:12057
0x728525 dump_template_bindings
/mnt/svn/gcc-trunk/gcc/cp/error.c:330
0x728525 dump_substitution
/mnt/svn/gcc-trunk/gcc/cp/error.c:1386
0x72af9e decl_as_string_translate(tree_node*, int)
/mnt/svn/gcc-trunk/gcc/cp/error.c:2740
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.


$ gcc -v   
Using built-in specs.
COLLECT_GCC=/mnt/svn/gcc-trunk/binary-latest/bin/gcc
COLLECT_LTO_WRAPPER=/mnt/svn/gcc-trunk/binary-206575-lto-fortran-checking-yes-rtl-df/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /mnt/svn/gcc-trunk//configure --enable-checking=yes,rtl,df
--enable-languages=c,c++,lto,fortran
--prefix=/mnt/svn/gcc-trunk/binary-206575-lto-fortran-checking-yes-rtl-df/
--without-cloog --without-ppl
Thread model: posix
gcc version 4.9.0 20140113 (experimental) (GCC)

[Bug target/59789] [4.9 Regression] ICE in in convert_move, at expr.c:333

[hjl.tools at gmail dot com]

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

--- Comment #6 from H.J. Lu  ---
Created attachment 31824
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31824&action=edit
A patch

This is a patch based on

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57698#c7

[Bug target/59789] [4.9 Regression] ICE in in convert_move, at expr.c:333

[hjl.tools at gmail dot com]

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

--- Comment #5 from H.J. Lu  ---
A smaller testcase:

[hjl@gnu-6 gcc]$ cat /tmp/x.c
#pragma GCC push_options
#pragma GCC target("sse2")
typedef int __v4si __attribute__ ((__vector_size__ (16)));
typedef long long __m128i __attribute__ ((__vector_size__ (16),
__may_alias__));

extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm_set_epi32 (int __q3, int __q2, int __q1, int __q0)
{
  return __extension__ (__m128i)(__v4si){ __q0, __q1, __q2, __q3 };
}
#pragma GCC pop_options

__m128i
f1(void)
{
  return _mm_set_epi32 (0, 0, 0, 0);
}
[hjl@gnu-6 gcc]$ ./xgcc -B./ -S /tmp/x.c -m32   -O2 -march=i686 
/tmp/x.c: In function ‘f1’:
/tmp/x.c:14:1: warning: SSE vector return without SSE enabled changes the ABI
[enabled by default]
 f1(void)
 ^
/tmp/x.c:7:1: error: inlining failed in call to always_inline ‘_mm_set_epi32’:
target specific option mismatch
 _mm_set_epi32 (int __q3, int __q2, int __q1, int __q0)
 ^
/tmp/x.c:16:24: error: called from here
   return _mm_set_epi32 (0, 0, 0, 0);
^
/tmp/x.c:16:3: internal compiler error: in convert_move, at expr.c:333
   return _mm_set_epi32 (0, 0, 0, 0);
   ^
0x7da639 convert_move(rtx_def*, rtx_def*, int)
/export/gnu/import/git/gcc/gcc/expr.c:333
0x7e8e77 store_expr(tree_node*, rtx_def*, int, bool)
/export/gnu/import/git/gcc/gcc/expr.c:5389
0x7e787a expand_assignment(tree_node*, tree_node*, bool)
/export/gnu/import/git/gcc/gcc/expr.c:5114
0x6e0645 expand_gimple_stmt_1
/export/gnu/import/git/gcc/gcc/cfgexpand.c:3213
0x6e0a3f expand_gimple_stmt
/export/gnu/import/git/gcc/gcc/cfgexpand.c:3309
0x6e6e58 expand_gimple_basic_block
/export/gnu/import/git/gcc/gcc/cfgexpand.c:5149
0x6e88fc gimple_expand_cfg
/export/gnu/import/git/gcc/gcc/cfgexpand.c:5715
0x6e8f76 execute
/export/gnu/import/git/gcc/gcc/cfgexpand.c:5935
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
[hjl@gnu-6 gcc]$

[Bug middle-end/28865] Structures with a flexible arrray member have wrong .size

[nickc at gcc dot gnu.org]

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

Nick Clifton  changed:

   What|Removed |Added

  Attachment #31802|0   |1
is obsolete||

--- Comment #23 from Nick Clifton  ---
Created attachment 31823
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31823&action=edit
Revised patch, with testcases

Hi Guys,

I have uploaded a revised patch with two changes:

  1. I have removed the assertion from
 output_constructor_regular_field() and changed the code so that
 extra zeros are emitted only if fieldpos is more than the current
 byte total.  I made this change because I feel that we should avoid
 ICEs even on invalid code.

  2. I have added two tests to the testsuite, based on comments 3 and
 13.

  Still no regressions with an i686-pc-linux-gnu toolchain and an
  aarch64-elf toolchain.

  OK to apply ?

Cheers
  Nick

gcc/ChangeLog
2014-01-13  Nick Clifton  

PR middle-end/28865
* varasm.c (output_consant): Return the number of bytes actually
emitted.
(output_constructor_array_range): Update the field size with the
number of bytes emitted by output_constant.
(output_constructor_regular_field): Likewise.  Also do not
complain if the total number of bytes emitted is now greater
than the expected fieldpos.
* output.h (output_constant): Update prototype and descriptive
comment.

gcc/testsuite/ChangeLog
2014-01-13  Nick Clifton  

PR middle-end/28865
* gcc.c-torture/compile/pr28865.c: New.
* gcc.c-torture/execute/pr28865.c: New.

[Bug sanitizer/59402] bootstrap failure on x32

[hjl.tools at gmail dot com]

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

--- Comment #9 from H.J. Lu  ---
(In reply to Kostya Serebryany from comment #8)
> H.J., may I ask you to repost the patches
> (that apply to the current upstream trunk) to llvm-commits?

Done.

[Bug middle-end/56344] ICE for program with very large structs returned by value

[georggcc at googlemail dot com]

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

--- Comment #11 from Georg  ---
(In reply to Marek Polacek from comment #10)
> Fixed.

For clarity, just asking: Does this mean that

1.  if I compile a program on HOST with bit size N,
for a TARGET with bit size M, then gcc will sorry()
just in case the object passed is larger than 1<<30,
irrespective of N and M?

2. Would this need to be documented per implementation?

[Bug bootstrap/59496] [4.9 Regression] Bootstrap fails on powerpc-apple-darwin9 after r205685

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P1  |P4

--- Comment #5 from Jakub Jelinek  ---
Also, ppc*-darwin* isn't primary nor secondary target and the only one
affected, downgrading to P4.

[Bug bootstrap/59496] [4.9 Regression] Bootstrap fails on powerpc-apple-darwin9 after r205685

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
(In reply to Iain Sandoe from comment #3)
> (In reply to Richard Biener from comment #2)
> > darwin should simply add a dummy use of field, like via ((field), (...))
> 
> well, I thought of doing that, but it seems a kludge - is the target obliged
> to use the macro values?

Given that all other targets use it, I'd say yes in this case.

[Bug middle-end/28865] Structures with a flexible arrray member have wrong .size

[jakub at gcc dot gnu.org]

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

--- Comment #22 from Jakub Jelinek  ---
But the glibc headers case you're mentioning wasn't initializing the flexible
array members, right?  (Or even initialization with {} initializer is fine I
guess).  I mean, while C doesn't allow it, if you don't initialize the flexible
array member followed by something else, it should still work fine as if it was
a zero-sized array.  But even in the struct A { struct B { int a; char b[]; };
int c; }; case, I'd say we should error when trying to initialize b to
something non-empty, because we shouldn't be changing the types (thus offsets
in the type fields, type sizes etc.) based on the initializer, only DECL_SIZE
can.
So IMHO we should accept:
struct A { int a; char b[]; };
struct B { struct A a; int c; } b;
struct A p[24];
struct B c = { { 5, {} }, 6 };
struct A q[2] = { { 5, {} }, { 6, {} } };
but reject:
struct B d = { { 1, { 2 } }, 3 };
struct B e = { { 2, "abc" }, 4 };
struct A r[2] = { { 5, "a" }, { 6, "b" } };

[Bug target/59789] [4.9 Regression] ICE in in convert_move, at expr.c:333

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||tmsriram at google dot com

--- Comment #4 from H.J. Lu  ---
ICE without -msse2 is caused by r201039.

[Bug c++/59790] Inner template class specialization has no direct access to outer template class typedefs

[blaffablaffa at gmail dot com]

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

Lorenzo Pistone  changed:

   What|Removed |Added

 CC||blaffablaffa at gmail dot com

--- Comment #1 from Lorenzo Pistone  ---
Created attachment 31822
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31822&action=edit
test case

[Bug c++/59790] New: Inner template class specialization has no direct access to outer template class typedefs

[blaffablaffa at gmail dot com]

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

Bug ID: 59790
   Summary: Inner template class specialization has no direct
access to outer template class typedefs
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: blaffablaffa at gmail dot com

See the attached testcase, Compile simply with `g++ -c test.cpp`. The code
compiles with the latest clang.

[Bug middle-end/28865] Structures with a flexible arrray member have wrong .size

[joseph at codesourcery dot com]

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

--- Comment #21 from joseph at codesourcery dot com  ---
The reason for laxity about flexible array member constraints is existing 
code violating them, as in the glibc header code quoted in 
.  I don't know 
whether there is existing such code for the array case or not.

[Bug target/59789] [4.9 Regression] ICE in in convert_move, at expr.c:333

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  ---
(In reply to Alexander Ivchenko from comment #2)
> lets just say that my code is valid and I forgot to add "-msse2" :).
> 

Does GCC ICE with -msse2?

[Bug target/59789] [4.9 Regression] ICE in in convert_move, at expr.c:333

[aivchenk at gmail dot com]

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

--- Comment #2 from Alexander Ivchenko  ---
lets just say that my code is valid and I forgot to add "-msse2" :).


(In reply to H.J. Lu from comment #1)
> The code is invalid since -march=i686 doesn't support SSE.
> The older GCC issues:
> 
> In file included from /tmp/pr59789.c:2:0:
> /usr/lib/gcc/x86_64-redhat-linux/4.8.2/include/emmintrin.h:31:3: error:
> #error "SSE2 instruction set not enabled"
>  # error "SSE2 instruction set not enabled"
>^
> /tmp/pr59789.c: In function ‘f1’:
> /tmp/pr59789.c:9:5: error: unknown type name ‘__m128i’
>  __m128i bar  = _mm_set1_epi32(0);

[Bug fortran/59781] [4.7/4.8/4.9 Regression] [F03] Incorrect initialisation of derived type

[janus at gcc dot gnu.org]

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

--- Comment #5 from janus at gcc dot gnu.org ---
Here is a draft patch which seems to fix comment 1 to 3:


Index: gcc/fortran/trans-decl.c
===
--- gcc/fortran/trans-decl.c(revision 206579)
+++ gcc/fortran/trans-decl.c(working copy)
@@ -4005,8 +4005,6 @@ gfc_trans_deferred_vars (gfc_symbol * proc_sym, gf
 }
   else if (sym->ts.deferred)
 gfc_fatal_error ("Deferred type parameter not yet supported");
-  else if (alloc_comp_or_fini)
-gfc_trans_deferred_array (sym, block);
   else if (sym->ts.type == BT_CHARACTER)
 {
   gfc_save_backend_locus (&loc);
@@ -4017,6 +4015,18 @@ gfc_trans_deferred_vars (gfc_symbol * proc_sym, gf
 gfc_trans_auto_character_variable (sym, block);
   gfc_restore_backend_locus (&loc);
 }
+  else if (sym->ts.type == BT_DERIVED)
+{
+  if (alloc_comp_or_fini)
+gfc_trans_deferred_array (sym, block);
+  if (sym->value && !sym->attr.data && sym->attr.save == SAVE_NONE)
+{
+  gfc_start_block (&tmpblock);
+  gfc_init_default_dt (sym, &tmpblock, false);
+  gfc_add_init_cleanup (block, gfc_finish_block (&tmpblock),
+NULL_TREE);
+}
+}
   else if (sym->attr.assign)
 {
   gfc_save_backend_locus (&loc);
@@ -4024,16 +4034,6 @@ gfc_trans_deferred_vars (gfc_symbol * proc_sym, gf
   gfc_trans_assign_aux_var (sym, block);
   gfc_restore_backend_locus (&loc);
 }
-  else if (sym->ts.type == BT_DERIVED
- && sym->value
- && !sym->attr.data
- && sym->attr.save == SAVE_NONE)
-{
-  gfc_start_block (&tmpblock);
-  gfc_init_default_dt (sym, &tmpblock, false);
-  gfc_add_init_cleanup (block, gfc_finish_block (&tmpblock),
-NULL_TREE);
-}
   else if (!(UNLIMITED_POLY(sym)))
 gcc_unreachable ();
 }


I have not regtested it yet. One minor remaining problem is that the
allocatable component is nullified twice now.

[Bug fortran/45044] Different named COMMON block size: No warning

[dominiq at lps dot ens.fr]

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

--- Comment #9 from Dominique d'Humieres  ---
Revision 178344

Author:burnus
Date:Tue Aug 30 22:09:49 2011 UTC (2 years, 4 months ago)
Changed paths:5
Log Message:
2011-08-30  Tobias Burnus  

PR fortran/45044
* trans-common.c (build_common_decl): Warn if named common
block's size is not everywhere the same.

2011-08-30  Tobias Burnus  

PR fortran/45044
* gfortran.dg/common_14.f90: New.
* gfortran.dg/common_resize_1.f: Add two dg-warning.

[Bug target/59789] [4.9 Regression] ICE in in convert_move, at expr.c:333

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com
   Target Milestone|--- |4.9.0

[Bug target/59789] [4.9 Regression] ICE in in convert_move, at expr.c:333

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-01-13
 Ever confirmed|0   |1

[Bug bootstrap/59770] [4.9 Regression] bootstrap failure for arm-linux-gnueabi targeting armv4t

[martinwguy at gmail dot com]

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

Martin Guy  changed:

   What|Removed |Added

 CC||martinwguy at gmail dot com

--- Comment #1 from Martin Guy  ---
Duplicate of #59595 which also fails on armv5t host-built-target

[Bug target/59789] [4.9 Regression] ICE in in convert_move, at expr.c:333

[hjl.tools at gmail dot com]

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

--- Comment #1 from H.J. Lu  ---
The code is invalid since -march=i686 doesn't support SSE.
The older GCC issues:

In file included from /tmp/pr59789.c:2:0:
/usr/lib/gcc/x86_64-redhat-linux/4.8.2/include/emmintrin.h:31:3: error: #error
"SSE2 instruction set not enabled"
 # error "SSE2 instruction set not enabled"
   ^
/tmp/pr59789.c: In function ‘f1’:
/tmp/pr59789.c:9:5: error: unknown type name ‘__m128i’
 __m128i bar  = _mm_set1_epi32(0);

[Bug fortran/45044] Different named COMMON block size: No warning

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||4.7.3, 4.8.2, 4.9.0
 Resolution|--- |FIXED
  Known to fail||4.6.4

--- Comment #8 from Dominique d'Humieres  ---
Starting with 4.7 (r178509, 2011-09-04) one gets

common /com/ a, b
1
Warning: Named COMMON block 'com' at (1) shall be of the same size as elsewhere
(8 vs 12 bytes)

r177649 (2011-08-11) doe give the warning.

Closing as FIXED.

[Bug target/59789] New: [4.9 Regression] ICE in in convert_move, at expr.c:333

[aivchenk at gmail dot com]

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

Bug ID: 59789
   Summary: [4.9 Regression] ICE in in convert_move, at expr.c:333
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aivchenk at gmail dot com

Android build is currently broken due to this bug:

>gcc expr_ice.c -c   -O2 -fPIC -m32 -march=i686

expr_ice.c:9:13: internal compiler error: in convert_move, at expr.c:333
 __m128i bar  = _mm_set1_epi32(0);
 ^
0x73a66e convert_move(rtx_def*, rtx_def*, int)
/export/users/aivchenk/src/gcc/gcc/expr.c:333
0x73dae5 store_expr(tree_node*, rtx_def*, int, bool)
/export/users/aivchenk/src/gcc/gcc/expr.c:5389
0x73fbb9 expand_assignment(tree_node*, tree_node*, bool)
/export/users/aivchenk/src/gcc/gcc/expr.c:5114
0x65f28d expand_gimple_stmt_1
/export/users/aivchenk/src/gcc/gcc/cfgexpand.c:3213
0x65f28d expand_gimple_stmt
/export/users/aivchenk/src/gcc/gcc/cfgexpand.c:3309
0x660f17 expand_gimple_basic_block
/export/users/aivchenk/src/gcc/gcc/cfgexpand.c:5149
0x6637c9 gimple_expand_cfg
/export/users/aivchenk/src/gcc/gcc/cfgexpand.c:5715
0x6637c9 execute
/export/users/aivchenk/src/gcc/gcc/cfgexpand.c:5935
Please submit a full bug report,


>cat expr_ice.c
#include 
#include 

typedef void (*func_type)();
extern func_type f;

static void f1()
{
__m128i bar  = _mm_set1_epi32(0);
_mm_storel_epi64(&bar, bar);
}


void foo(void)
{
  f = f1;
}

[Bug c++/59760] use_thunk internal error on default destructor declarations

[sshannin at gmail dot com]

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

--- Comment #3 from sshannin at gmail dot com ---
Created attachment 31821
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31821&action=edit
Preprocessed source

Preprocessed source of compilation from example in previous link.

Source (no includes):
template  struct A {
virtual ~A();
};
template  struct B : A... {
~B() = default;
};
struct C : B {
C() {}
};

int main( int , char **)
{
C c;
}

Compiled with:
g++-4.8.2 -std=c++0x -O0 -g3 -Wall -c -o sample.o sample.cpp

[Bug target/59788] New: Mixing libc and libgcc_s unwinders on 64-bit Solaris 10+/x86 breaks EH

[ro at gcc dot gnu.org]

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

Bug ID: 59788
   Summary: Mixing libc and libgcc_s unwinders on 64-bit Solaris
10+/x86 breaks EH
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: ro at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
  Host: i386-pc-solaris2.1[01]
Target: i386-pc-solaris2.1[01]
 Build: i386-pc-solaris2.1[01]

I've received a few reports in private mail that exception handling on 64-bit
Solaris 10+/x86 is broken when linking with -Bdirect.

The following testcase shows this:

$ cat unwind-direct.cc
#include 

int
main(void)
{
  try
{ throw std::runtime_error( "Catch me if you can!"); }
  catch(...)
{ return 0; }
  return 1;
}
$ g++ -Wl,-Bdirect -m64 -o unwind-direct unwind-direct.cc
$ ./unwind-direct
terminate called after throwing an instance of 'std::runtime_error'
Segmentation Fault (core dumped)

Investigating this with LD_DEBUG=bindings, one finds

$ LD_DEBUG=bindings ./unwind-direct 2>&1 | grep Unwind
03243: 1: binding
file=../../../i386-pc-solaris2.11/amd64/libstdc++-v3/src/.libs/libstdc++.so.6
to file=/lib/64/libc.so.1: symbol '_Unwind_RaiseException'
03243: 1: binding
file=../../../i386-pc-solaris2.11/amd64/libstdc++-v3/src/.libs/libstdc++.so.6
to file=/lib/64/libc.so.1: symbol '_Unwind_GetLanguageSpecificData'
03243: 1: binding
file=../../../i386-pc-solaris2.11/amd64/libstdc++-v3/src/.libs/libstdc++.so.6
to file=/lib/64/libc.so.1: symbol '_Unwind_GetRegionStart'
03243: 1: binding
file=../../../i386-pc-solaris2.11/amd64/libstdc++-v3/src/.libs/libstdc++.so.6
to file=../../amd64/libgcc_s.so.1: symbol '_Unwind_GetIPInfo'
03243: 1: binding
file=../../../i386-pc-solaris2.11/amd64/libstdc++-v3/src/.libs/libstdc++.so.6
to file=../../amd64/libgcc_s.so.1: symbol '_Unwind_Resume_or_Rethrow'
03243: 1: binding file=../../amd64/libgcc_s.so.1 to file=/lib/64/libc.so.1:
symbol '_Unwind_RaiseException'

The problem is that the amd64 Solaris 10+ libc contains an implementation of
the amd64 unwinder, as prescribed by the amd64 ABI, but only those functions
that are listed there.  libgcc_s contains some more, and both implementations
use different internal datastructures, so mixing them wreaks havoc.

This problem has been seen several times during gcc development when it
affected
gcc runtime libraries.

I'm working on a patch to avoid this once and for all by forcing all gcc-built
executables to bind to the unwinder in libgcc_s.

  Rainer

[Bug target/59788] Mixing libc and libgcc_s unwinders on 64-bit Solaris 10+/x86 breaks EH

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-01-13
   Target Milestone|--- |4.9.0
 Ever confirmed|0   |1

--- Comment #1 from Rainer Orth  ---
Mine, patch in progress.

[Bug fortran/33056] [Meta-bug] Data - statement related bugs

[dominiq at lps dot ens.fr]

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

Bug 33056 depends on bug 25096, which changed state.

Bug 25096 Summary: Non-conforming shapes of DATA object and data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25096

   What|Removed |Added

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

[Bug fortran/25096] Non-conforming shapes of DATA object and data

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #5 from Dominique d'Humieres  ---
(In reply to comment #4)
> > just a question. why is this illegal ?
>
> it is R528 in the section on the data statement of the F2003 standard 
> that suggests this has to be a scalar-structure-component. Not so obvious 
> why, 
> if you ask me.

R528 for F2003 is

> R528 data-i-do-object is array-element
>   or scalar-structure-component
>   or data-implied-do

It differs from F95

> R534 data-stmt-object is variable
>   or data-implied-do

None of them rules out data-implied-do, so I think g95 is wrong (it still
rejects the code if I replace '8*0' with '4*0'.

I have no doubt that

 TYPE T1
  INTEGER :: I(2)
 END TYPE T1
 TYPE(T1) :: D(4)
 DATA (D(i)%I,i=1,4) /4*0/
 END

is valid and I did not find where n*v for n>'number of elements to initialize'
is forbidden by the standards.

Closing as INVALID.

[Bug fortran/31392] [meta-bug] gfortran problems with initialization

[dominiq at lps dot ens.fr]

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

Bug 31392 depends on bug 25096, which changed state.

Bug 25096 Summary: Non-conforming shapes of DATA object and data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25096

   What|Removed |Added

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

[Bug tree-optimization/59594] [4.9 Regression] wrong code (by tree vectorizer) at -O3 on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
You're right, r206180 fixed this (i.e. that it FAILs at runtime even for
-mtune=generic).  In any case, sounds like this is a problem in determination
of the aliasing, we should have refused to vectorize this (of course unless we
are smart enough to find out all the b[a] = 1; stores but the b[0] = 1; is
redundant, but I suppose the vectorizer isn't the right place to do that
optimization.

[Bug target/59787] New: [ARM] mmx-2.c causes ICE when GCC is configured for cortex-a5/vfpv3-d16-fp16

[christophe.lyon at st dot com]

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

Bug ID: 59787
   Summary: [ARM] mmx-2.c causes ICE when GCC is configured for
cortex-a5/vfpv3-d16-fp16
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: christophe.lyon at st dot com

I've noticed that gcc.target/arm/mmx-2 causes GCC to crash when GCC is
configured as:
--target=arm-none-linux-gnueabihf
--with-cpu=cortex-a5
--with-fpu=vfpv3-d16-fp16

testsuite/gcc.target/arm/mmx-2.c:166:1: internal compiler error: Max. number of
generated reload insns per insn is achieved (90)

0x9a5a32 lra_constraints(bool)
/aci-gcc-fsf/sources/gcc-fsf/trunk/gcc/lra-constraints.c:4017
0x98e1f2 lra(_IO_FILE*)
/aci-gcc-fsf/sources/gcc-fsf/trunk/gcc/lra.c:2339
0x9322b7 do_reload
/aci-gcc-fsf/sources/gcc-fsf/trunk/gcc/ira.c:5455
0x932496 rest_of_handle_reload
/aci-gcc-fsf/sources/gcc-fsf/trunk/gcc/ira.c:5584
0x9324ae execute
/aci-gcc-fsf/sources/gcc-fsf/trunk/gcc/ira.c:5613

[Bug fortran/34136] Add entry point and symbol for linker

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #21 from Dominique d'Humieres  ---
> This issue was radr://5613343 and has been fixed for darwin10 and later.

Confirmed and it seems that it is also fixed by the latest version of Xcode for
darwin9. So I am closing this PR as FIXED leaving pr42568 open (WAITING) for
CYGWIN.

[Bug tree-optimization/59594] [4.9 Regression] wrong code (by tree vectorizer) at -O3 on x86_64-linux-gnu

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  ---
(In reply to Jakub Jelinek from comment #2)
> (In reply to H.J. Lu from comment #1)
> > It is caused by r204062.
> 
> That is only a part of the story, this testcase seems to be interesting.
> 
> Starting with r204062 until r204560 this has been broken because of an ldist
> bug.
> r204561 fixed that again and the testcase worked until r206147.
> r206148 (aka negative step vectorization support) started to ICE on this.
> With r206178 it stopped ICEing and works again with -O3 -mtune=generic, not
> sure if that has been intentional to change the generic tuning with that
> patch.  H.J.?

There was a typo in r206178 and was fixed by r206180:

http://gcc.gnu.org/git/?p=gcc.git;a=commit;h=ff385162ee38caf3100ba4a0f682241c3b0d681d

Can you try r206180 on this?

> Anyway, with -O3 -mtune=core-avx2 e.g. r206178 still ICEs and r206179 (which
> fixed the ICE) starts the miscompilation.

[Bug tree-optimization/59786] New: GIMPLE invariant motion misses opportunity to reduce register pressure

[rguenth at gcc dot gnu.org]

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

Bug ID: 59786
   Summary: GIMPLE invariant motion misses opportunity to reduce
register pressure
   Product: gcc
   Version: 4.9.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

For the following testcase LIM doesn't hoist a + b out of the loop (use -O1)

int x[1024];
void foo (int a, int b)
{
  int i;
  for (i = 0; i < 1024; ++i)
x[i] = a + b;
}

_6 = a_4(D) + b_5(D);
  invariant up to level 1, cost 1.

but

/* The cost of expression in loop invariant motion that is considered
   expensive.  */
DEFPARAM(PARAM_LIM_EXPENSIVE,
 "lim-expensive",
 "The minimum cost of an expensive expression in the loop invariant
motion",
 20, 0, 0)

and we only hoist "expensive" computations.  What is considered expensive
should consider the effect on register pressure.

Note that PRE happily moves all invariants without cost consideration.

For the testcase later RTL invariant motion hoists the addition.

[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|REOPENED|WAITING

--- Comment #26 from Dominique d'Humieres  ---
Is it still true on recent versions of Cygwin (it has been fixed on darwin
since darwin10, see pr34136)?

[Bug other/59783] inline expansion stack when attribute error/warning triggered is displayed incorrectly

[daniel.santos at pobox dot com]

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

--- Comment #3 from Daniel Santos  ---
(In reply to Jakub Jelinek from comment #2)
> If you want precise call trace in the diagnostics, you need to use -g.

holy backtrace batman!

[Bug tree-optimization/58921] [4.9 Regression] ICE with segfault on valid code at -O3 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 Depends on||59006
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #3 from Richard Biener  ---
Related to PR59006.

[Bug testsuite/59494] [4.9 Regression] FAIL: gfortran.dg/vect/fast-math-mgrid-resid.f scan-tree-dump-times optimized "vect_[^\\n]*\\+ " 13

[dominiq at lps dot ens.fr]

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

--- Comment #8 from Dominique d'Humieres  ---
With the patch in comment 7 the test succeeds for

Target: x86_64-apple-darwin10.8.0
Configured with: ../work/configure --prefix=/opt/gcc/gcc4.9w
--enable-languages=c,c++,fortran,objc,obj-c++,ada,java,lto --with-gmp=/opt/mp
--with-system-zlib --with-isl=/opt/mp --enable-lto --enable-plugin

and

Target: x86_64-apple-darwin13.0.0
Configured with: ../work/configure --prefix=/opt/gcc/gcc4.9w
--enable-languages=c,c++,fortran,objc,obj-c++,ada,java,lto --with-gmp=/opt/mp
--with-system-zlib --with-isl=/opt/mp --enable-lto --enable-plugin
--with-arch=corei7 --with-cpu=corei7

(tested with
make -k check-gfortran RUNTESTFLAGS="vect.exp=fast-math-mgrid-resid.f
--target_board=unix'{-m32,-m64}'").

[Bug c/59785] atomic_store should load source operand atomically?

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #1 from Jakub Jelinek  ---
It is atomic store, not atomic load, what do you expect?
The only reason for taking val as a pointer rather than the value itself is
that some values really need to live in memory and the API is generic.  If you
are trying to pass an address of a var that is modified by other threads, it is
just a bug in your source code, you likely want to do an atomic load into a
temporary automatic variable etc. which won't be modified by other threads and
only then atomic_store it.

[Bug testsuite/59494] [4.9 Regression] FAIL: gfortran.dg/vect/fast-math-mgrid-resid.f scan-tree-dump-times optimized "vect_[^\\n]*\\+ " 13

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Created attachment 31820
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31820&action=edit
gcc49-pr59494.patch

Fix that tries to capture the r156042 to r156043 changes in the *.pcom dump
details.

[Bug tree-optimization/59757] Unexpected VN_TOP in SSCVN

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
That is,

Index: gcc/tree-ssa-sccvn.c
===
--- gcc/tree-ssa-sccvn.c(revision 206576)
+++ gcc/tree-ssa-sccvn.c(working copy)
@@ -3605,6 +3605,7 @@ visit_use (tree use)
changed = defs_to_varying (stmt);
 }
  done:
+  gcc_assert (!virtual_operand_p (use) || SSA_VAL (use) != VN_TOP);
   return changed;
 }

should help catching the bug.

[Bug tree-optimization/59757] Unexpected VN_TOP in SSCVN

[rguenther at suse dot de]

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

--- Comment #6 from rguenther at suse dot de  ---
On Mon, 13 Jan 2014, joey.ye at arm dot com wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59757
> 
> --- Comment #5 from Joey Ye  ---
> Here are some debug and log that might help to investigate.
> 
> Following one is suspecious to me, .MEM_18 is said to be defined a stmt that
> doesn't look like it should do
> (gdb) call debug_tree((*cfun->gimple_df->ssa_names).m_vecdata[18] )
>   type  align 8 symtab 0 alias set -1 canonical type 0x89c08a0
> pointer_to_this >
> visited var def_stmt _11 = _10 (258);
> 
> version 18>

This is an indirect call which clobbers memory and thus has to
define .MEM.

> dump.pre:
> SCC consists of: .MEM_18

.MEM_18 should get a value-number (.MEM_18 itself) during
processing of this stmt.  I suppose that the value-number of
_10 is not _10 but a const/pure function decl.  You can
put a breakpoint on visit_use if use->base.u.version == 18
and follow what happens.  It seems that there must be a path
in its is_gimple_call () handling where it fails to assign
a value-number to the virtual operand.

> SCC consists of: _12
> Value numbering _12 stmt = _12 = d_2(D)->core.get_parameter;
> 
> 
> Last good dump:
> univision_ug2828gfeff01_init (struct CTL_GFX_SEP_DRIVER_t * d, int depth)
> {
>   struct CTL_GFX_DRIVER_t * _7;
>   long int _9;
>   long int (*) (int) _10;
>   long int _11;
>   long int (*) (int) _12;
>   long int _13;
> 
>   :
>   d_2(D)->core.get_parameter = univision_ug2828gfeff01_get_parameter;
>   _7 = &d_2(D)->core;
>   ctl_gfx_driver = _7;
>   MEM[(struct CTL_GFX_DRIVER_t *)d_2(D)].draw_pixel = 0B;
>   _9 = univision_ug2828gfeff01_get_parameter (258);
>   if (_9 == 8)
> goto ;
>   else
> goto ;
> 
>   :
>   d_2(D)->set_bounding = sep_set_bounding_8b;
>   goto ;
> 
>   :
>   _10 = d_2(D)->core.get_parameter;
>   _11 = _10 (258);
>   if (_11 == 16)
> goto ;
>   else
> goto ;
> 
>   :
>   d_2(D)->set_bounding = sep_set_bounding_16b;
>   goto ;
> 
>   :
>   _12 = d_2(D)->core.get_parameter;
>   _13 = _12 (512);
>   if (_13 > 255)
> goto ;
>   else
> goto ;
> 
>   :
>   d_2(D)->set_bounding = sep_set_bounding_16b;
>   goto ;
> 
>   :
>   d_2(D)->set_bounding = sep_set_bounding_8b;
> 
>   :
>   return;
> 
> }
> 
> Any hint to continue investigating?
> 
>

[Bug middle-end/28865] Structures with a flexible arrray member have wrong .size

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jsm28 at gcc dot gnu.org

--- Comment #20 from Jakub Jelinek  ---
(In reply to Alan Modra from comment #19)
> Jakub, you're correct.  I should have read the standard on flexible array
> members before poking at this bug last year.  Nick's patch is looking good
> to me.
> 
> ISO/IEC 9899:1999 is quite clear that the answer to comment #2 is that
> sizeof does *not* include the flexible array component (but it does include
> any padding needed to align the start of the flexible array).  I think it is
> reasonable to do the same for .size and not include the flexible array
> component there too.

Well, sizeof is clear, but .size doesn't need to be the same thing, IMHO .size
really should be DECL_SIZE of the decl and we do adjust that for the flexible
array member in there.  If .size would be just e.g. TYPE_SIZE, then there could
be e.g. problems with copy relocations.
> 
> The testcase (which is invalid code IMO) in comment #3 hits this assert in
> varasm.c:

The #c3 is invalid, I agree, how can you have an array if each array entry has
a different size?  I mean, the C standard allows flexible array members only at
the toplevel and not initialized, as GNU extension we allow it to be
initialized and allow it even in some cases where it is not toplevel, but where
it is still reasonable (e.g. the case where it is at the end of struct which is
inside a union is reasonable, so would be placing it at the end of another
structure, but placing it in an array is IMHO something that should be rejected
by the FE).
CCing Joseph on it.

[Bug middle-end/28865] Structures with a flexible arrray member have wrong .size

[amodra at gmail dot com]

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

--- Comment #19 from Alan Modra  ---
Jakub, you're correct.  I should have read the standard on flexible array
members before poking at this bug last year.  Nick's patch is looking good to
me.

ISO/IEC 9899:1999 is quite clear that the answer to comment #2 is that sizeof
does *not* include the flexible array component (but it does include any
padding needed to align the start of the flexible array).  I think it is
reasonable to do the same for .size and not include the flexible array
component there too.

The testcase (which is invalid code IMO) in comment #3 hits this assert in
varasm.c:

  /* Advance to offset of this element.
 Note no alignment needed in an array, since that is guaranteed
 if each element has the proper size.  */
  if ((local->field != NULL_TREE || local->index != NULL_TREE)
  && fieldpos != local->total_bytes)
{
  gcc_assert (fieldpos >= local->total_bytes);

[Bug tree-optimization/59757] Unexpected VN_TOP in SSCVN

[joey.ye at arm dot com]

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

--- Comment #5 from Joey Ye  ---
Here are some debug and log that might help to investigate.

Following one is suspecious to me, .MEM_18 is said to be defined a stmt that
doesn't look like it should do
(gdb) call debug_tree((*cfun->gimple_df->ssa_names).m_vecdata[18] )
 >
visited var def_stmt _11 = _10 (258);

version 18>

dump.pre:
SCC consists of: .MEM_18
SCC consists of: _12
Value numbering _12 stmt = _12 = d_2(D)->core.get_parameter;


Last good dump:
univision_ug2828gfeff01_init (struct CTL_GFX_SEP_DRIVER_t * d, int depth)
{
  struct CTL_GFX_DRIVER_t * _7;
  long int _9;
  long int (*) (int) _10;
  long int _11;
  long int (*) (int) _12;
  long int _13;

  :
  d_2(D)->core.get_parameter = univision_ug2828gfeff01_get_parameter;
  _7 = &d_2(D)->core;
  ctl_gfx_driver = _7;
  MEM[(struct CTL_GFX_DRIVER_t *)d_2(D)].draw_pixel = 0B;
  _9 = univision_ug2828gfeff01_get_parameter (258);
  if (_9 == 8)
goto ;
  else
goto ;

  :
  d_2(D)->set_bounding = sep_set_bounding_8b;
  goto ;

  :
  _10 = d_2(D)->core.get_parameter;
  _11 = _10 (258);
  if (_11 == 16)
goto ;
  else
goto ;

  :
  d_2(D)->set_bounding = sep_set_bounding_16b;
  goto ;

  :
  _12 = d_2(D)->core.get_parameter;
  _13 = _12 (512);
  if (_13 > 255)
goto ;
  else
goto ;

  :
  d_2(D)->set_bounding = sep_set_bounding_16b;
  goto ;

  :
  d_2(D)->set_bounding = sep_set_bounding_8b;

  :
  return;

}

Any hint to continue investigating?

[Bug c/59785] New: atomic_store should load source operand atomically?

[ma.jiang at zte dot com.cn]

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

Bug ID: 59785
   Summary: atomic_store should load  source operand atomically?
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ma.jiang at zte dot com.cn

gcc  provide a atomic_store interface as below.
void __atomic_store (type *ptr, type *val, int memmodel)

In manual, There is only a simple description ---"This is the generic version
of an atomic store. It stores the value of *val into *ptr."

But it seemed that this interface could not do what the description said when
*val is a global memory which might be messed up by other threads. 

unsigned long long int ta=123;
unsigned long long int tb=321;
int test()
{
__atomic_store(&tb, &ta, __ATOMIC_RELAXED);
return 0;
}
On ARM,the codes above give out a assembly instruction sequence as below.
movwr3, #:lower16:ta
movtr3, #:upper16:ta
ldrdr0, [r3]
movwr3, #:lower16:tb
movtr3, #:upper16:tb
.L3:
ldrexd  r4, r5, [r3]
strexd  r2, r0, r1, [r3]
cmp r2, #0
bne .L3

the source operand ta was not fetched atomically, so we might get a totally
wrong num from tb when ta were modified by other threads. 

I guess the atomic_store interface only provide a function as--"fetch val
non-atomically ,and then store it into ptr atomically."
This is exactlly what the gimple tree shows.
test ()
{
  long long unsigned int ta.0;
  int D.4127;

  ta.0 = ta;
  __atomic_store_8 (&tb, ta.0, 0);
  D.4127 = 0;
  return D.4127;
}

I think it would be better to give a more detailed desctription in the manual.
Or make a atomical load in the atomic_store.

[Bug sanitizer/59402] bootstrap failure on x32

[kcc at gcc dot gnu.org]

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

--- Comment #8 from Kostya Serebryany  ---
H.J., may I ask you to repost the patches
(that apply to the current upstream trunk) to llvm-commits?

[Bug testsuite/59494] [4.9 Regression] FAIL: gfortran.dg/vect/fast-math-mgrid-resid.f scan-tree-dump-times optimized "vect_[^\\n]*\\+ " 13

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #5)
> Alternatively we should just remove that scan-tree-dump-times from the test
> altogether, counting additions where either lhs or rhs1 of addition has
> vect_ in name is quite flawed, we have lots of other vector additions that
> just use anonymous SSA_NAMEs without any name (_114 etc.), but still have
> vector types.
> 
> Counting addps etc. insns doesn't work though, there are 23 before and after
> the r156043 change.
> 
> Richard, what is your preference here?

Well,

! we want to check that predictive commoning did something on the
! vectorized loop, which means we have to have exactly 13 vector
! additions.

which means to look at the pcom dump (and maybe enhance it).  On
x86_64 the interesting line in -details is

"Unrolling 2 times."

dumped from

  /* Execute the predictive commoning transformations, and possibly unroll the
 loop.  */
  if (unroll)
{
  struct epcc_data dta;

  if (dump_file && (dump_flags & TDF_DETAILS))
fprintf (dump_file, "Unrolling %u times.\n", unroll_factor);
...
}
  else
{
  if (dump_file && (dump_flags & TDF_DETAILS))
fprintf (dump_file,
 "Executing predictive commoning without unrolling.\n");
  execute_pred_commoning (loop, chains, tmp_vars);
}

a common "Executing predictive commoning on loop %d" would be possibly
useful.  Eventually with "on %d chains" as well.  All of this even without
-details and within the opt-dumping framework (MSG_OPTIMIZED_LOCATIONS).

[Bug preprocessor/59782] libcpp does not avoid bug #48326 when compiled by older GCC

[ubizjak at gmail dot com]

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

--- Comment #3 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #2)
> I'd say for GCC 4.8 we should just replace the conditional with GCC_VERSION
> >= 4008 and for 4.9 with >= 4009, better trust only the latest version for
> target attribute.  libcpp is bootstrapped and thus for bootstraps it will
> DTRT.

According to [1], 4.7.1 is already OK, so > 4007 should be enough.

[1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48326#c3

[Bug libgomp/59194] tsan detects race for real variables in an OMP reduction clause

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #13 from Jakub Jelinek  ---
Fixed then.

[Bug libgomp/59194] tsan detects race for real variables in an OMP reduction clause

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #12 from Joost VandeVondele  
---
(In reply to Jakub Jelinek from comment #11)
> Author: jakub
> Date: Mon Jan 13 07:56:40 2014
> New Revision: 206572
> 
> URL: http://gcc.gnu.org/viewcvs?rev=206572&root=gcc&view=rev
> Log:
>   PR libgomp/59194
>   * omp-low.c (expand_omp_atomic_pipeline): Expand the initial
>   load as __atomic_load_N if possible.
> 
> Modified:
> trunk/gcc/ChangeLog
> trunk/gcc/omp-low.c

I have verified that this patch fixes the reported issues. From my point of
view, the PR can be closed as fixed. Thanks!

[Bug target/59784] New: Nios2: Wrong code generation for fextsd custom instruction

[savin.zlobec at gmail dot com]

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

Bug ID: 59784
   Summary: Nios2: Wrong code generation for fextsd custom
instruction
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: savin.zlobec at gmail dot com

Created attachment 31819
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31819&action=edit
Fix

The following code:

double f2d(float x) { return (double)x; }

Compiled with -O2 ... -mcustom-frdy=2 ... -mcustom-fextsd=37

Compiles to:

   0: 2009c972  custom 37,r4,r4,zero
   4: 0009c0b2  custom 2,r4,zero,zero
   8: 2005883a  mov r2,r4
   c: 2807883a  mov r3,r5
  10: f800283a  ret

Note the 'custom 37,r4,r4,zero', should be 'custom 37,r5,r4,zero'.

Patch attached.

[Bug target/58694] Support intrinsic functions for ARMv8 Crypto extension

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||belagod at gcc dot gnu.org,
   ||ktkachov at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Support for the Crypto intrinsics through arm_neon.h has been added to arm
(r206130) and aarch64 (r206115 - r206120)

[Bug sanitizer/59758] [4.9 Regression] bootstrap failure in libsanitizer/asan on sparc-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug tree-optimization/59594] [4.9 Regression] wrong code (by tree vectorizer) at -O3 on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com,
   ||jakub at gcc dot gnu.org,
   ||meibf at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
(In reply to H.J. Lu from comment #1)
> It is caused by r204062.

That is only a part of the story, this testcase seems to be interesting.

Starting with r204062 until r204560 this has been broken because of an ldist
bug.
r204561 fixed that again and the testcase worked until r206147.
r206148 (aka negative step vectorization support) started to ICE on this.
With r206178 it stopped ICEing and works again with -O3 -mtune=generic, not
sure if that has been intentional to change the generic tuning with that patch.
 H.J.?
Anyway, with -O3 -mtune=core-avx2 e.g. r206178 still ICEs and r206179 (which
fixed the ICE) starts the miscompilation.

[Bug sanitizer/59758] [4.9 Regression] bootstrap failure in libsanitizer/asan on sparc-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||davem at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Someone who can reproduce it (not me any longer, my SPARC boxes are dead) needs
to debug this and write a patch, or drop SPARC from libsanitizer list of
supported targets.

[Bug preprocessor/59782] libcpp does not avoid bug #48326 when compiled by older GCC

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
I'd say for GCC 4.8 we should just replace the conditional with GCC_VERSION >=
4008 and for 4.9 with >= 4009, better trust only the latest version for target
attribute.  libcpp is bootstrapped and thus for bootstraps it will DTRT.

Note, rs6000 now supports the target attribute, so I'd say that lex.c should
start to use it on ppc*.

[Bug other/59783] inline expansion stack when attribute error/warning triggered is displayed incorrectly

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
If you want precise call trace in the diagnostics, you need to use -g.

[Bug sanitizer/59758] [4.9 Regression] bootstrap failure in libsanitizer/asan on sparc-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0

[Bug c++/59760] use_thunk internal error on default destructor declarations

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2014-01-13
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
Please provide preprocessed source.

[Bug target/59762] [4.9 Regression] func-vararg-mixed.c fails on PowerPC starting with revision 204079

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0
Summary|func-vararg-mixed.c fails   |[4.9 Regression]
   |on PowerPC starting with|func-vararg-mixed.c fails
   |revision 204079 |on PowerPC starting with
   ||revision 204079