[Bug target/56564] movdqa on possibly-8-byte-aligned struct with -O3

[jakub at gcc dot gnu.org]

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

--- Comment #20 from Jakub Jelinek  ---
Author: jakub
Date: Wed Jun 12 06:43:05 2013
New Revision: 199984

URL: http://gcc.gnu.org/viewcvs?rev=199984&root=gcc&view=rev
Log:
PR target/56564
* varasm.c (decl_binds_to_current_def_p): Call binds_local_p
target hook even for !TREE_PUBLIC decls.  If no resolution info
is available, return false for common and external decls.

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

Author: jakub
Date: Wed Jun 12 06:46:53 2013
New Revision: 199985

URL: http://gcc.gnu.org/viewcvs?rev=199985&root=gcc&view=rev
Log:
PR target/56564
* gcc.target/i386/pr56564-1.c: Skip on darwin, mingw and cygwin.
* gcc.target/i386/pr56564-3.c: Likewise.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/pr56564-1.c
trunk/gcc/testsuite/gcc.target/i386/pr56564-3.c

[Bug c++/57593] New: Friendship not extended into friend member-declaration

[potswa at mac dot com]

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

Bug ID: 57593
   Summary: Friendship not extended into friend member-declaration
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: potswa at mac dot com

The access granted by friendship extends into the "member declarations of the
befriended class" (11.3/2). Friend declarations are member-declarations but not
member declarations per se, so the standard is ambiguous. But GCC is
inconsistent.

class c {
class n {};
friend struct s;
};

struct s {
friend class c::n; // OK
friend c::n g(); // OK
friend void f() { c::n(); } // Error
};

All three should go the same way, if access is granted per declaration. If the
first two were invalid, private nested classes and related functions would be
impossible to befriend.

Rejection of the third case impedes use of a friend as part of a class
implementation, akin to members, such as the common case of operator <<. Clang
does accept it.

A defect report has been submitted.

[Bug tree-optimization/57592] New: ICE in tree_unroll_loops_completely at -O3

[dhazeghi at yahoo dot com]

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

Bug ID: 57592
   Summary: ICE in tree_unroll_loops_completely at -O3
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dhazeghi at yahoo dot com

With current gcc trunk on x86_64-linux, the following code causes an ICE when
compiled at -O3.  This is a regression from 4.8.x.

$ gcc-trunk -v
gcc version 4.9.0 20130611 (experimental) [trunk revision 199947] (GCC) 
$ gcc-trunk -m32 -O2 -c ice.c 
$ gcc-4.8 -m32 -O3 -c ice.c 
$ gcc-trunk -m32 -O3 -c ice.c 
ice.c: In function ‘f’:
ice.c:4:1: internal compiler error: Segmentation fault
 f ()
 ^
0x7d419f crash_signal
../../gcc-trunk/gcc/toplev.c:333
0x7fc29b ssa_default_def(function*, tree_node*)
../../gcc-trunk/gcc/tree-dfa.c:314
0x7fc560 get_or_create_ssa_default_def(function*, tree_node*)
../../gcc-trunk/gcc/tree-dfa.c:362
0x81585a get_reaching_def
../../gcc-trunk/gcc/tree-into-ssa.c:1184
0x81b9db maybe_replace_use
../../gcc-trunk/gcc/tree-into-ssa.c:1784
0x81b9db rewrite_update_stmt
../../gcc-trunk/gcc/tree-into-ssa.c:1967
0x81b9db rewrite_update_enter_block
../../gcc-trunk/gcc/tree-into-ssa.c:2136
0xb3561a walk_dominator_tree(dom_walk_data*, basic_block_def*)
../../gcc-trunk/gcc/domwalk.c:210
0x814563 rewrite_blocks
../../gcc-trunk/gcc/tree-into-ssa.c:2216
0x81ac8e update_ssa(unsigned int)
../../gcc-trunk/gcc/tree-into-ssa.c:3303
0xb99fe4 tree_unroll_loops_completely(bool, bool)
../../gcc-trunk/gcc/tree-ssa-loop-ivcanon.c:1207
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.

-
int a, b, c;

void
f ()
{
  int d, e;
  a = 0;
  for (; a <= 1; a++)
{
  e = 4;
  for (; e; e--)
{
  d |= c < b++;
  c = 0;
}
}
  g (d);
}

[Bug testsuite/57591] New: gcc-4.8 libbacktrace btest failure on Linux ppc64

[acrux at linuxmail dot org]

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

Bug ID: 57591
   Summary: gcc-4.8 libbacktrace btest failure on Linux ppc64
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: acrux at linuxmail dot org

Created attachment 30297
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30297&action=edit
full log

btest fails building on Linux ppc64 (CRUX PPC 64bit). I tried
gcc-4.8.0,gcc-4.8.1,gcc-4.8-20130606. I also tried it on ppc but on 32bit
environment it builds fine. 

system: IBM POWER4+ ,kernel Linux-3.4.48, powerpc64-unknown-linux-gnu
toolcahin: gcc-4.7.3, binutils-2.23.2, glibc-2.16.0, libgmp-5.1.2,
libmpfr-3.1.2, libmpc-1.0.1, libcloog-0.18.0, libppl-1.1pre8


configure: --enable-bootstrap --with-cpu=default64 --prefix=/usr
--mandir=/usr/man --libexecdir=/usr/lib --enable-languages=c,c++,objc
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--enable-shared --enable-lto --disable-ppl --disable-cloog --disable-isl
--disable-nls --with-x=no --enable-long-long --with-system-zlib
'--with-pkgversion=CRUX PPC' --host=powerpc64-unknown-linux-gnu
--build=powerpc64-unknown-linux-gnu --target=powerpc64-unknown-linux-gnu


[...]
make[2]: Leaving directory `/root/1up/gcc/work/src/build/intl'
make[2]: Entering directory `/root/1up/gcc/work/src/build/libbacktrace'
true  DO=all multi-do # make
make  btest
make[3]: Entering directory `/root/1up/gcc/work/src/build/libbacktrace'
gcc -DHAVE_CONFIG_H -I. -I../../gcc-4.8.1/libbacktrace  -I
../../gcc-4.8.1/libbacktrace/../include -I
../../gcc-4.8.1/libbacktrace/../libgcc -I ../libgcc  -funwind-tables
-frandom-seed=btest-btest.o -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute
-Wcast-qual  -g -O -O2 -mcpu=powerpc64 -pipe -c -o btest-btest.o `test -f
'btest.c' || echo '../../gcc-4.8.1/libbacktrace/'`btest.c
/bin/sh ./libtool --tag=CC   --mode=link gcc -funwind-tables
-frandom-seed=btest -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute
-Wcast-qual  -g -O -O2 -mcpu=powerpc64 -pipe   -o btest btest-btest.o
libbacktrace.la 
libtool: link: gcc -funwind-tables -frandom-seed=btest -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-Wmissing-format-attribute -Wcast-qual -g -O -O2 -mcpu=powerpc64 -pipe -o btest
btest-btest.o  ./.libs/libbacktrace.a
make[3]: Leaving directory `/root/1up/gcc/work/src/build/libbacktrace'
make  check-TESTS
make[3]: Entering directory `/root/1up/gcc/work/src/build/libbacktrace'
test3: [0]: NULL syminfo name
test3: [1]: NULL syminfo name
test3: [2]: NULL syminfo name
PASS: backtrace_full noinline
PASS: backtrace_full inline
FAIL: backtrace_simple noinline
PASS: backtrace_simple inline
FAIL: btest
==
1 of 1 test failed
==
make[3]: *** [check-TESTS] Error 1
make[3]: Leaving directory `/root/1up/gcc/work/src/build/libbacktrace'
make[2]: *** [check-am] Error 2
make[2]: Target `check' not remade because of errors.
make[2]: Leaving directory `/root/1up/gcc/work/src/build/libbacktrace'
make[1]: *** [check-libbacktrace] Error 2
[...]

full log attached (log.0.gz)

[Bug regression/57551] [4.9 Regression]: g++.dg/ext/visibility/anon6.C scan-assembler 1BIiE1cE

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

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

--- Comment #8 from Hans-Peter Nilsson  ---
Intended fix committed as noticed by my autotester, so I'm closing this.

Looks like the svn commit <-> bugzilla interface is broken or severely delayed;
the log seems ok and should match, AFAICT:

Log:
PR c++/57551
* g++.dg/ext/visibility/anon6.C: Update testcase.
* cp/pt.c (mark_decl_instantiated): Do not export explicit
instantiations
of anonymous namespace templates.

[Bug target/57589] Linux powerpc -mcpu=native returns pointer to variable on stack in driver-rs6000.c

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

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

--- Comment #4 from Michael Meissner  ---
Fixed in subversion id 199972 for trunk.

[Bug fortran/44604] Wrong run-time checks with VALUE dummies and pointer/allocatable actuals

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-06-11
 Ever confirmed|0   |1

--- Comment #5 from Dominique d'Humieres  ---
Works for me on 4.6.4, 4.7.3, 4.8.1, and trunk. Confirmed for 4.5.4. Apparently
fixed between revisions 179850 and 17. This PR could probably be closed as
fixed.

[Bug target/57589] Linux powerpc -mcpu=native returns pointer to variable on stack in driver-rs6000.c

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

  Attachment #30295|0   |1
is obsolete||

--- Comment #3 from Michael Meissner  ---
Created attachment 30296
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30296&action=edit
Proposed patch to fix problem

[Bug target/57589] Linux powerpc -mcpu=native returns pointer to variable on stack in driver-rs6000.c

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

  Attachment #30294|0   |1
is obsolete||

--- Comment #2 from Michael Meissner  ---
Created attachment 30295
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30295&action=edit
Proposed patch to fix problem

[Bug fortran/52392] internal compiler error occurs when compilin files separately but not when all is in one file

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||mikael at gcc dot gnu.org
  Known to work||4.7.3, 4.8.1, 4.9.0
 Resolution|--- |FIXED

--- Comment #3 from Mikael Morin  ---
(In reply to Dominique d'Humieres from comment #2)
> It seems to have been fixed at revision 171654. It works with 4.7.3, 4.8.1,
> and trunk. The 4.6 version is no longer supported. I think this PR could be
> closed as fixed.

Closing then.

[Bug fortran/53951] [OOP] Later TARGET statement ignored for CLASS

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-06-11
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Still present at revision 199959.

[Bug fortran/51610] [OOP] Class container does not properly handle POINTER and TARGET

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-06-11
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
With 4.8.1 and trunk, I get

pr51610.f90:15.15:

ptr => x ! Invalid: "x" is not a TARGET
   1
Error: Pointer assignment target is neither TARGET nor POINTER at (1)
pr51610.f90:8.23:

   call test(a, b, c) !   possibly not correctly diagnosed
   1
Error: Actual argument for 'z' must be a pointer at (1)

Confirmed for 4.7.3. This PR could probably be closed as fixed.

[Bug fortran/52227] [OOP] TARGET attribute mishandled in polymorphic types

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-06-11
 Ever confirmed|0   |1

--- Comment #4 from Dominique d'Humieres  ---
Still present at revision 199959.

[Bug fortran/52392] internal compiler error occurs when compilin files separately but not when all is in one file

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  ---
It seems to have been fixed at revision 171654. It works with 4.7.3, 4.8.1, and
trunk. The 4.6 version is no longer supported. I think this PR could be closed
as fixed.

[Bug fortran/57590] [OOP] class containers are recycled between symbols more than they should be

[mikael at gcc dot gnu.org]

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

--- Comment #1 from Mikael Morin  ---
(In reply to Mikael Morin from comment #0)
> This bug was found while trying to fix pr57297.

By the way pr57297 is the reverse problem (not enough sharing instead of too
much).

[Bug c++/42021] Misleading error message when inherited typedefs cause ambiguity

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2013-06-11
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com
   Target Milestone|--- |4.9.0
 Ever confirmed|0   |1

--- Comment #1 from Paolo Carlini  ---
This is essentially fixed:

42021.C: In member function ‘void BreadSlicer::print()’:
42021.C:26:19: error: reference to ‘P3’ is ambiguous
 Policies::P3::doPrint();
   ^
42021.C:10:21: note: candidates are: typedef struct Policy1 B::P3
 typedef Policy1 P3;
 ^
42021.C:14:21: note: typedef struct Policy2 C1::P3
 typedef Policy2 P3;  
 ^

Nit: we emit the diagnostic twice. I have a patchlet for that:

[Bug fortran/57590] New: [OOP] class containers are recycled between symbols more than they should be

[mikael at gcc dot gnu.org]

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

Bug ID: 57590
   Summary: [OOP] class containers are recycled between symbols
more than they should be
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mikael at gcc dot gnu.org

This bug was found while trying to fix pr57297.
Related bugs: pr52227, pr51610, pr53951.

We (gfortran developpers) have decided to generate OOP class containers using
gfortran AST:
we generate a (fortran) fake variable of a (fortran) fake type holding the
object's meta data (virtual table, ...) and a pointer to the actual data
("_data"). Then, at translation stage OOP containers are generated as if they
were regular fortran variables.
As a result of this, the attributes and array spec of an entity become that of
the fake variable's type. So we should generate a different class container
type for any combination of rank, attribute, and array spec.  It's not the case
currently, as shown by the following testcase (which doesn't seem invalid as
far as I know).


  type t
  end type t

  type(t) :: b(3), c(5), d(10), e(11)

  call s3(b)
  call s5(c)
  call sa(d)
  call sn(size(e,dim=1), e)

 contains

  subroutine s3(a)
class(t), dimension(3) :: a
print *, shape(a)
  end subroutine s3

  subroutine s5(a)
class(t), dimension(5) :: a
print *, shape(a)
  end subroutine s5

  subroutine sa(a)
class(t), dimension(:) :: a
print *, shape(a)
  end subroutine sa

  subroutine sn(n, a)
integer :: n
class(t), dimension(n) :: a
print *, shape(a)
  end subroutine sn
end


This prints 3 four times, instead of the expected: 3, 5, 10 and 11, because
s3::a's class container is reused for every 'a' dummy argument of 's5', 'sa'
and 'sn'.
Every of the 'a' dummy argument should have its own class container type.
This means that we have to discriminate not only on the array spec type, but
also for AS_EXPLICIT on the bounds, and on the bounds' expressions (in the 'sn'
case).

[Bug fortran/55057] [OOP] wrong result with abstract type

[dominiq at lps dot ens.fr]

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

--- Comment #7 from Dominique d'Humieres  ---
It has been fixed between revisions 194721 and 195140.

[Bug target/57589] Linux powerpc -mcpu=native returns pointer to variable on stack in driver-rs6000.c

[meissner at gcc dot gnu.org]

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

--- Comment #1 from Michael Meissner  ---
Created attachment 30294
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30294&action=edit
Proposed patch to fix problem

[Bug target/57589] Linux powerpc -mcpu=native returns pointer to variable on stack in driver-rs6000.c

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2013-06-11
 Ever confirmed|0   |1

[Bug target/57589] New: Linux powerpc -mcpu=native returns pointer to variable on stack in driver-rs6000.c

[meissner at gcc dot gnu.org]

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

Bug ID: 57589
   Summary: Linux powerpc -mcpu=native returns pointer to variable
on stack in driver-rs6000.c
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org

In looking at driver-rs6000.c, I noticed that elf_platform (under Linux) reads
the auxv data structure into an auto array, and then returns a pointer to that
array.  It should either make the buffer static, or use xstrdup to get a unique
string.

[Bug c++/57588] [C++11][constexpr] static constexpr in class fails to link

[mattyclarkson at gmail dot com]

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

--- Comment #3 from Matt Clarkson  ---
Thanks for that link, its very informative :) I can see why it fails to link
now.

About the private destructor, I'd expect it to not compile, but it does.  I
actually didn't even realise I'd made it private as I was just hacking together
a quick testcase.  Is that a bug?

[Bug fortran/56939] [4.8/4.9 Regression] [OOP] Derived type is being used before it is defined

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #4 from Dominique d'Humieres  ---
It seems to have been fixed between revisions 197943 and 197969.
The candidates are revisions 197950 or 197961.
Closing as fixed.

[Bug fortran/57535] [OOP] ICE when allocating a CLASS function-result variable

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
*** Bug 52143 has been marked as a duplicate of this bug. ***

[Bug fortran/52143] [OOP] ICE with polymorphic function result in gfc_class_vptr_get

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Dominique d'Humieres  ---
The test compiles at revision 199960. Marking as duplicate of pr57535.

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

[Bug fortran/56939] [4.8/4.9 Regression] [OOP] Derived type is being used before it is defined

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #3 from Mikael Morin  ---
Seems to be accepted now.

[Bug fortran/55057] [OOP] wrong result with abstract type

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #6 from Mikael Morin  ---
(In reply to janus from comment #3)
> Here is a reduced test case, which is not usable as a runtime test, but
> shows the wrong dump:
> 
[...]
> 
> The dump of 'sub2' is wrong in 4.8, while 'sub1' is ok. With 4.7, both are
> wrong.

sub2's dump is now:

sub2 (struct __class_m_T2 & restrict b)
{
  {
struct __class_m_T1 class.7;

class.7._data = (struct t1 *) b->_data->work._data.data + (sizetype)
((b->_data->work._data.offset + 1) * (integer(kind=8))
b->_data->work._vptr->_size);
class.7._vptr = b->_data->work._vptr;
alt (&class.7);
  }
}

This appears correct to me. At least, it "involves _vptr->_size".
And the output of comment #0 is now:

$ ./comment_0
 All the following values should be 2.0
   2.
   2.
   2.
 All the following values should be 2.0
   2.
   2.
   2.

FIXED?

[Bug c++/57588] [C++11][constexpr] static constexpr in class fails to link

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Although shouldn't it fail to compile, due to private destructor and copy
constructor?

[Bug c++/57588] [C++11][constexpr] static constexpr in class fails to link

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Isn't this just
http://gcc.gnu.org/wiki/VerboseDiagnostics#missing_static_const_definition ?

[Bug c++/57588] New: [C++11][constexpr] static constexpr in class fails to link

[mattyclarkson at gmail dot com]

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

Bug ID: 57588
   Summary: [C++11][constexpr] static constexpr in class fails to
link
   Product: gcc
   Version: 4.7.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mattyclarkson at gmail dot com

The following code, links in optimisation modes but not others:

  #include 

 
///
  class Literal {
  private:
Literal() = delete;
Literal(const Literal&) = delete;
Literal(Literal&&) = delete;
Literal& operator=(const Literal&) = delete;
Literal& operator=(Literal&&) = delete;
~Literal() = default;

  public:
constexpr Literal(const int i);

  public:
constexpr operator int() const;

  private:
int int_;
  };

  constexpr Literal::Literal(const int i) : int_(i) {};

  constexpr Literal::operator int() const {
return int_;
  }

 
///
  class Test {
  private:
Test(const Test&) = delete;
Test(Test&&) = delete;
Test& operator=(const Test&) = delete;
Test& operator=(Test&&) = delete;
~Test() = default;

  public:
static constexpr const Literal kLiteral = Literal(99);

  public:
constexpr Test();

  public:
constexpr operator int() const;

  private:
int int_;
  };

  constexpr Test::Test() : int_(kLiteral) {};

  constexpr Test::operator int() const {
return int_;
  }

 
///
  int main() {
std::cout << Literal(15) << std::endl;
std::cout << Test() << std::endl;
return 0;
  }

Has some odd compilation on my machine:

  [matt test] uname -a
  Linux office.acer-m5810 3.8.13-100.fc17.x86_64 #1 SMP Mon May 13 13:36:17 UTC
2013 x86_64 x86_64 x86_64 GNU/Linux
  [matt test] g++ -std=c++11 test.cpp -o test -O0 -g && ./test
  /tmp/ccZtV9ku.o: In function `Test::Test()':
  /home/matt/test/test.cpp:51: undefined reference to `Test::kLiteral'
  collect2: error: ld returned 1 exit status
  [matt test] g++ -std=c++11 test.cpp -o test -O1 -g && ./test
  15
  99
  [matt test] g++ -std=c++11 test.cpp -o test -O2 -g && ./test
  15
  99
  [matt test] g++ -std=c++11 test.cpp -o test -O3 -g && ./test
  15
  99

However, on gcc.godbolt.org and ideone.com I cannot get the same compilation
error with 4.7.2.  I'm assuming I'm not being a donkey and doing something
against the standard? :/

If I can help with any debugging, please ask.

[Bug fortran/57508] [4.8/4.9 Regression] [OOP] Intrinsic assignment+defined-assignment for comps: PROCEDURE attribute of '_F.DA0' conflicts with VARIABLE attribute

[burnus at gcc dot gnu.org]

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

--- Comment #5 from Tobias Burnus  ---
Fixed on the GCC 4.8 branch. Patch pending for the trunk, cf.
http://gcc.gnu.org/ml/fortran/2013-06/msg00064.html

[Bug fortran/57508] [4.8/4.9 Regression] [OOP] Intrinsic assignment+defined-assignment for comps: PROCEDURE attribute of '_F.DA0' conflicts with VARIABLE attribute

[burnus at gcc dot gnu.org]

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

--- Comment #4 from Tobias Burnus  ---
Author: burnus
Date: Tue Jun 11 16:18:13 2013
New Revision: 199961

URL: http://gcc.gnu.org/viewcvs?rev=199961&root=gcc&view=rev
Log:
2013-06-11  Tobias Burnus  

PR fortran/57508
* resolve.c (get_temp_from_expr): Don't copy function
result attributes to temporary.

2013-06-11  Tobias Burnus  

PR fortran/57508
* gfortran.dg/defined_assignment_7.f90: New.


Added:
branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/defined_assignment_7.f90
Modified:
branches/gcc-4_8-branch/gcc/fortran/ChangeLog
branches/gcc-4_8-branch/gcc/fortran/resolve.c
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug fortran/49074] [OOP] Defined assignment w/ CLASS arrays: Incomplete error message

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

   Keywords||patch
 CC||mikael at gcc dot gnu.org

--- Comment #11 from Mikael Morin  ---
Draft patch:

Index: trans-stmt.c
===
--- trans-stmt.c(révision 199585)
+++ trans-stmt.c(copie de travail)
@@ -267,6 +267,7 @@ gfc_conv_elemental_dependencies (gfc_se * se, gfc_
 GFC_SS_SECTION);
  gfc_mark_ss_chain_used (tmp_ss, 1);
  tmp_ss->info->expr = ss->info->expr;
+ tmp_ss->info->data.array.ref = ss->info->data.array.ref;
  replace_ss (loopse, ss, tmp_ss);

  /* Obtain the argument descriptor for unpacking.  */

[Bug fortran/57305] ICE with warnings and unlimited polymorphic

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-06-11
 Ever confirmed|0   |1

--- Comment #4 from Dominique d'Humieres  ---
For the first test I get

pr57305.f90:13.8:

a(1:size(tmp)) = transfer(tmp,a)
1
Error: Variable must not be polymorphic in intrinsic assignment at (1) - check
that there is a matching specific subroutine for '=' operator
pr57305.f90:14.8:

a(size(tmp)+1) = transfer(e,a)
1
Error: Variable must not be polymorphic in intrinsic assignment at (1) - check
that there is a matching specific subroutine for '=' operator

for 4.8.1 and trunk. I get the ICE for the second test at revision 199959.

[Bug fortran/52143] [OOP] ICE with polymorphic function result in gfc_class_vptr_get

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  ---
It looks like a duplicate of pr57535.

[Bug c++/50436] Crash or hang on invalid template code

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-06-11
 Ever confirmed|0   |1
  Known to fail||4.8.1, 4.9.0

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

[Bug c++/50390] gcc hangs while compiling invalid c++ code

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||4.7.3, 4.8.1, 4.9.0
 Resolution|--- |FIXED

--- Comment #8 from Paolo Carlini  ---
Fixed in 4.7.0.

[Bug target/57586] ICE when expanding volatile asm using unaligned pointer

[rguenther at suse dot de]

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

--- Comment #5 from rguenther at suse dot de  ---
On Tue, 11 Jun 2013, jgreenhalgh at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57586
> 
> --- Comment #4 from jgreenhalgh at gcc dot gnu.org ---
> Created attachment 30293
>   --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30293&action=edit
> Less reduced failing testcase
> 
> Yes, the same thing happens for packed versions of those structs. Perhaps the
> attached, less-reduced, version of the testcase will make the issue more 
> clear.
> This expanded testcase fails with the same error and ICE:
> 
> ../build-arm-none-eabi/install/bin/arm-none-eabi-gcc
> ../testcases/pr-less-reduced.c -O1 -Wall
> ../testcases/pr-less-reduced.c: In function 'inet_rtm_getroute':
> ../testcases/pr-less-reduced.c:22:3: error: output number 0 not directly
> addressable
>__asm__ __volatile__(""
>^
> ../testcases/pr-less-reduced.c:22:3: internal compiler error: in
> expand_asm_operands, at stmt.c:910
> 0x8c1be8 expand_asm_operands
> /work/oban-dev/src/gcc/gcc/stmt.c:910
> 0x8c28a7 expand_asm_stmt(gimple_statement_d*)
> /work/oban-dev/src/gcc/gcc/stmt.c:1151
> 0x5dfe5f expand_gimple_stmt_1
> /work/oban-dev/src/gcc/gcc/cfgexpand.c:2154
> 0x5dfe5f expand_gimple_stmt
> /work/oban-dev/src/gcc/gcc/cfgexpand.c:2309
> 0x5e1b69 expand_gimple_basic_block
> /work/oban-dev/src/gcc/gcc/cfgexpand.c:4143
> 0x5e4a33 gimple_expand_cfg
> /work/oban-dev/src/gcc/gcc/cfgexpand.c:4662
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See  for instructions.

I suppose the question is why

  /* EXPAND_INITIALIZER will not generate code for valid initializer
 constants, but will still generate code for other types of 
operand.
 This is the behavior we want for constant constraints.  */
  op = expand_expr (val, NULL_RTX, VOIDmode,
allows_reg ? EXPAND_NORMAL
: allows_mem ? EXPAND_MEMORY
: EXPAND_INITIALIZER);

thus, EXPAND_MEMORY returns a non-MEM_P (does it?).

[Bug target/56564] movdqa on possibly-8-byte-aligned struct with -O3

[jakub at gcc dot gnu.org]

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

--- Comment #19 from Jakub Jelinek  ---
The mingw/cygwin stuff.  The testcases assume that the symbols have
decl_binds_to_current_def_p false, if that isn't the case (because darwin/mingw
apparently don't allow symbol interposition), then the testcase can't work on
those.

[Bug fortran/57535] [OOP] ICE when allocating a CLASS function-result variable

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #3 from Tobias Burnus  ---
FIXED on the trunk (4.9).

[Bug fortran/57535] [OOP] ICE when allocating a CLASS function-result variable

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus  ---
Author: burnus
Date: Tue Jun 11 14:58:55 2013
New Revision: 199958

URL: http://gcc.gnu.org/viewcvs?rev=199958&root=gcc&view=rev
Log:
2013-06-11  Tobias Burnus  

PR fortran/57535
* trans-array.c (build_class_array_ref): Fix ICE for
function result variables.

2013-06-11  Tobias Burnus  

PR fortran/57535
* gfortran.dg/class_array_18.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/class_array_18.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-array.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/18918] Eventually support Fortran 2008's coarrays [co-arrays]

[mikael at gcc dot gnu.org]

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

Bug 18918 depends on bug 43412, which changed state.

Bug 43412 Summary: [OOP] BT_CLASS does not does not set array spec
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43412

   What|Removed |Added

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

[Bug fortran/43412] [OOP] BT_CLASS does not does not set array spec

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||mikael at gcc dot gnu.org
  Known to work||4.7.4, 4.8.0, 4.9.0
 Resolution|--- |FIXED

--- Comment #3 from Mikael Morin  ---
(In reply to Dominique d'Humieres from comment #2)
> while the test in comment #1 compiles without error. AFAIU this is the
> expected behavior, isn't it?
It seems so.
Closing.

[Bug target/57586] ICE when expanding volatile asm using unaligned pointer

[jgreenhalgh at gcc dot gnu.org]

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

--- Comment #4 from jgreenhalgh at gcc dot gnu.org ---
Created attachment 30293
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30293&action=edit
Less reduced failing testcase

Yes, the same thing happens for packed versions of those structs. Perhaps the
attached, less-reduced, version of the testcase will make the issue more clear.
This expanded testcase fails with the same error and ICE:

../build-arm-none-eabi/install/bin/arm-none-eabi-gcc
../testcases/pr-less-reduced.c -O1 -Wall
../testcases/pr-less-reduced.c: In function 'inet_rtm_getroute':
../testcases/pr-less-reduced.c:22:3: error: output number 0 not directly
addressable
   __asm__ __volatile__(""
   ^
../testcases/pr-less-reduced.c:22:3: internal compiler error: in
expand_asm_operands, at stmt.c:910
0x8c1be8 expand_asm_operands
/work/oban-dev/src/gcc/gcc/stmt.c:910
0x8c28a7 expand_asm_stmt(gimple_statement_d*)
/work/oban-dev/src/gcc/gcc/stmt.c:1151
0x5dfe5f expand_gimple_stmt_1
/work/oban-dev/src/gcc/gcc/cfgexpand.c:2154
0x5dfe5f expand_gimple_stmt
/work/oban-dev/src/gcc/gcc/cfgexpand.c:2309
0x5e1b69 expand_gimple_basic_block
/work/oban-dev/src/gcc/gcc/cfgexpand.c:4143
0x5e4a33 gimple_expand_cfg
/work/oban-dev/src/gcc/gcc/cfgexpand.c:4662
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/56564] movdqa on possibly-8-byte-aligned struct with -O3

[dominiq at lps dot ens.fr]

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

--- Comment #18 from Dominique d'Humieres  ---
(In reply to comment #17)
> Yeah, MachO is broken by design, guess the tests need to be restricted 
> to non-darwin non-PE.

Questions:
(1) What is PE?
(2) Is the second "return 0;" wrong code or valid optimization? If the former,
why?
(3) Is the decoration "__emutls_v." the same for all the emutls platforms? If
not, where can I find the variants?

[Bug c++/57581] abi_tag vs. demangler

[bkoz at gcc dot gnu.org]

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

Benjamin Kosnik  changed:

   What|Removed |Added

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

--- Comment #2 from Benjamin Kosnik  ---
confirmed, it works, thanks!

[Bug target/57586] ICE when expanding volatile asm using unaligned pointer

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2013-06-11
 CC|rguenther at suse dot de   |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
Well, the testcase is simply invalid for a STRICT_ALIGNMENT target I suppose.

Does the same thing happen for a packed struct counter/counter_wrapper?

[Bug target/57586] ICE when expanding volatile asm using unaligned pointer

[jgreenhalgh at gcc dot gnu.org]

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

jgreenhalgh at gcc dot gnu.org changed:

   What|Removed |Added

 CC||jgreenhalgh at gcc dot gnu.org

--- Comment #2 from jgreenhalgh at gcc dot gnu.org ---
Created attachment 30292
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30292&action=edit
Working testcase

Modifying the '1' in:

  counter *c = &((counter_wrapper *)(1))->y; 

To something more aligned like a '4' as in the attached file and in:

  counter *c = &((counter_wrapper *)(4))->y; 

causes compilation to proceed as expected without an ICE.

[Bug c/57584] ice: SSA corruption: Unable to coalesce ssa_names

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
Created attachment 30291
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30291&action=edit
autoreduced testcase

Mine anyway.

[Bug c/57587] New: RFE: 'maybenull' attribute.

[dwmw2 at infradead dot org]

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

Bug ID: 57587
   Summary: RFE: 'maybenull' attribute.
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dwmw2 at infradead dot org

I'd like an attribute analogous to __attribute__((nonnull)) for function
arguments, except that it should indicate that an argument is *expected* to be
NULL. Or preferably, it could be applied to a *type* or a function member...

It is common, in glib-based software, to have functions which return
success/failure and also take an *optional* 'GError **' argument which can be
populated with more detailed error information on failure. This error pointer
is usually passed through to inferior functions, and a failure of such a
function will cause the parent function to immediately return 'FALSE', with the
detailed error having already been populated.

However, the 'error' argument may often be NULL, if a failure is not going to
be reported to the user.

It is a common bug, when such a function calls another function, to use the
'error' function to detect whether an error happens — instead of checking the
return value of the function as we should. To make that slightly clearer...

This code bad:

gboolean my_foo(GError **error)
{
my_bar(error);
if (*error)
   return FALSE;

return my_baz(error);
}

This code good:

gboolean my_foo(GError **error)
{
if (!my_bar(error))
return FALSE;

return my_baz(error);
}

This bug is distressingly common. There may be other ways to catch this common
coding error, but if we could ensure that the compiler would *warn* about any
untested assumption that the pointer is non-NULL, that would be useful.

Having it done along the lines of the __attribute__((nonnull)) function
attribute may be simpler, but it would require every function declaration to
carry the attribute. And if we could rely on codemonkeys do to that, we could
probably rely on them to get it right in the first place.

So if there's a way we can mark the *GError* type with an attribute that says
"pointers to this are probably NULL", that would be useful. I'm not entirely
sure how that would work.

It might also be useful to mark struct members with the same attribute. The
definition of 'struct foo' would effectively be able to enforce the rule "Thou
shalt not assume that foo_s->bar is non-NULL. Always check before dereferencing
it".

[Bug target/57586] ICE when expanding volatile asm using unaligned pointer

[jgreenhalgh at gcc dot gnu.org]

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

--- Comment #1 from jgreenhalgh at gcc dot gnu.org ---
A bisect shows that this bug first occurs after r197095:

2013-03-26  Richard Biener  

* emit-rtl.c (set_mem_attributes_minus_bitpos): Remove
alignment computations and rely on get_object_alignment_1
for the !TYPE_P case.
Commonize DECL/COMPONENT_REF handling in the ARRAY_REF path.

[Bug target/57586] New: ICE when expanding volatile asm using unaligned pointer

[jgreenhalgh at gcc dot gnu.org]

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

Bug ID: 57586
   Summary: ICE when expanding volatile asm using unaligned
pointer
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jgreenhalgh at gcc dot gnu.org

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

Using built-in specs.
COLLECT_GCC=../build-arm-none-eabi/install/bin/arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/work/build-arm-none-eabi/install/libexec/gcc/arm-none-eabi/4.9.0/lto-wrapper
Target: arm-none-eabi
Configured with: /work/src/gcc/configure --target=arm-none-eabi
--prefix=/work/build-arm-none-eabi/install
--with-gmp=/work/build-arm-none-eabi/host-tools
--with-mpfr=/work/build-arm-none-eabi/host-tools
--with-mpc=/work/build-arm-none-eabi/host-tools --with-pkgversion=unknown
--disable-shared --disable-nls --disable-threads --disable-tls
--enable-checking=yes --enable-languages=c,c++ --with-newlib
Thread model: single
gcc version 4.9.0 20130326 (experimental) (unknown)

../build-arm-none-eabi/install/bin/arm-none-eabi-gcc ../testcases/pr-reduced.c
-O1
../testcases/pr-reduced.c: In function 'foo':
../testcases/pr-reduced.c:12:3: error: output number 0 not directly addressable
   __asm__ __volatile__("": "+m" (c->x) : "r" (&c->x) : );
   ^
../testcases/pr-reduced.c:12:3: internal compiler error: in
expand_asm_operands, at stmt.c:910
0x8c1be8 expand_asm_operands
/work/oban-dev/src/gcc/gcc/stmt.c:910
0x8c28a7 expand_asm_stmt(gimple_statement_d*)
/work/oban-dev/src/gcc/gcc/stmt.c:1151
0x5dfe5f expand_gimple_stmt_1
/work/oban-dev/src/gcc/gcc/cfgexpand.c:2154
0x5dfe5f expand_gimple_stmt
/work/oban-dev/src/gcc/gcc/cfgexpand.c:2309
0x5e1b69 expand_gimple_basic_block
/work/oban-dev/src/gcc/gcc/cfgexpand.c:4143
0x5e4a33 gimple_expand_cfg
/work/oban-dev/src/gcc/gcc/cfgexpand.c:4662
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

No difference with -mno-unaligned-access or -maligned-access.

A manifestation of this bug prevents a Linux Kernel build.

[Bug rtl-optimization/57569] [4.8/4.9 Regression] wrong code for struct copy at -O3 on x86_64-linux

[matz at gcc dot gnu.org]

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

--- Comment #3 from Michael Matz  ---
It's cse, and it's because it indeed uses the wrong dependence test.
The CSE tables holds values read from memory which are supposed to be
clobbered by following writes, i.e. write-after-read, which has to use
anti_dependence.  This fixes the testcase:

Index: cse.c
===
--- cse.c   (revision 199694)
+++ cse.c   (working copy)
@@ -1837,7 +1837,7 @@ check_dependence (rtx *x, void *data)
 {
   struct check_dependence_data *d = (struct check_dependence_data *) data;
   if (*x && MEM_P (*x))
-return canon_true_dependence (d->exp, d->mode, d->addr, *x, NULL_RTX);
+return anti_dependence (*x, d->exp);
   else
 return 0;
 }

[Bug regression/57551] [4.9 Regression]: g++.dg/ext/visibility/anon6.C scan-assembler 1BIiE1cE

[jason at gcc dot gnu.org]

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

--- Comment #7 from Jason Merrill  ---
(In reply to Jan Hubicka from comment #6)
> Jason, can you please look at
> http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00433.html

I approved it the same day you posted it. :)

[Bug c++/43745] [avr] g++ puts VTABLES in SRAM

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

  Component|target  |c++

--- Comment #8 from Georg-Johann Lay  ---
This needs extensions in the C++ front => Component = c++

[Bug c/57584] ice: SSA corruption: Unable to coalesce ssa_names

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-06-11
 Blocks||56982
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed, reducing.

[Bug target/57583] large switches with jump tables are horribly broken on m68k

[mikpe at it dot uu.se]

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

--- Comment #2 from Mikael Pettersson  ---
 is the corresponding
binutils/gas bug.

[Bug tree-optimization/57358] segmentation fault with attribute(optimize(O0))

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2013-06-11
 Ever confirmed|0   |1

[Bug tree-optimization/57358] segmentation fault with attribute(optimize(O0))

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Jambor  ---
I'll take a look.

[Bug preprocessor/57580] Repeated _Pragma message directives in macro causes problems

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #1 from Manuel López-Ibáñez  ---
I don't see this in GCC 4.9. I haven't tested GCC 4.8 or 4.7.

[Bug target/50807] [avr] Constructor writing to RAM for variable in Flash

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #5 from Georg-Johann Lay  ---
(In reply to Jakub Jelinek from comment #4)
> Is this reproduceable with 4.7.3, 4.8.0 or the trunk?

With the test case from above and 4.8.0, no code is generated at all.

With an extended test case as follows, the constructor still writes to RAM in
insn 6:

const char __attribute__((progmem)) var = "Hallo"[0];

const char *foo (void)
{
return &var;
}

_GLOBAL__sub_I__Z3foov:
ldi r24,lo8(72) ;  5movqi_insn/2[length = 1]
sts _ZL3var,r24 ;  6movqi_insn/3[length = 2]
ret ;  13return[length = 1]

And there is a warning from the back end:

foo.c: In function 'const char* foo()':
foo.c:1:37: warning: uninitialized variable 'var' put into program memory area
[-Wuninitialized]
 const char __attribute__((progmem)) var = "Hallo"[0];

[Bug libstdc++/51749] Including pollutes global namespace

[jakub at gcc dot gnu.org]

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

--- Comment #26 from Jakub Jelinek  ---
No, I mean what I wrote, see
http://pubs.opengroup.org/onlinepubs/007904975/functions/xsh_chap02_02.html
info libc 'Feature Test Macros'
etc.

[Bug libstdc++/51749] Including pollutes global namespace

[nmm1 at cam dot ac.uk]

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

--- Comment #25 from Nick Maclaren  ---
Strictly, don't you mean feature selection macros?

It isn't worth being too perfectionist on this, as the standards (both
de jure and de facto) are an ungodly mess, and it is getting steadily
harder to write portable code in C/C++/POSIX/etc.  However, I strongly
agree that taking the hard line (especially with -std=)
is the best way to go.

On the other hand, it is quite likely that a stricter line may require
new options or feature selection macros - because, for example, there
are codes that need a specific version of the language but also the
extensions of a specific version of POSIX.  Ugh.

[Bug rtl-optimization/57430] Redundant move instruction is produced after function inlining

[ysrumyan at gmail dot com]

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

--- Comment #4 from Yuri Rumyantsev  ---
I have not seen any comments about my latest note - have you any ideas about
this issue?

Thanks ahead.

[Bug libstdc++/51749] Including pollutes global namespace

[redi at gcc dot gnu.org]

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

--- Comment #24 from Jonathan Wakely  ---
(In reply to Jakub Jelinek from comment #23)
> changed, the question would be what should be the new G++ feature test macro
> defaults, for -std=gnu++{98,11,1y} I guess it should include the POSIX etc.
> stuff by default too, for -std=c++{98,11,1y} perhaps it should be strict and
> require users to use feature test macros explicitly.

That sounds good to me.

[Bug c++/53096] [DR 1333] [c++11] should be possible to default a copy ctor that takes non-const arg

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

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

[Bug libstdc++/51749] Including pollutes global namespace

[jakub at gcc dot gnu.org]

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

--- Comment #23 from Jakub Jelinek  ---
So, perhaps this is solveable only through cooperation with glibc folks.
I guess a start for that would be to do an audit of the libstdc++ headers, what
symbols does it need from the glibc headers, and categorize them (symbols that
are defined in the C headers unconditionally, not guarded by any feature test
macros, symbols guarded by feature test macros that C++ wants to have visible
in the *.h headers (candidates for _ISOCXX98_SOURCE, _ISOCXX11_SOURCE,
_ISOCXX14_SOURCE feature test macros?), symbols we don't want to be visible in
the C headers but libstdc++ headers use privately for the implementation
(export as __ prefixed alternatives?).  If glibc is changed, the question would
be what should be the new G++ feature test macro defaults, for
-std=gnu++{98,11,1y} I guess it should include the POSIX etc. stuff by default
too, for -std=c++{98,11,1y} perhaps it should be strict and require users to
use feature test macros explicitly.

[Bug libstdc++/57585] New: New --enable-clocale model using POSIX 2008

[redi at gcc dot gnu.org]

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

Bug ID: 57585
   Summary: New --enable-clocale model using POSIX 2008
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org

Now that uselocale() is in POSIX we should consider a new
--enable-clocale=ieee_1003.1-2008 based on the gnu model, which could be used
on any POSIX-2008 OS and would reduce differences between targets.

[Bug target/57583] large switches with jump tables are horribly broken on m68k

[sch...@linux-m68k.org]

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

--- Comment #1 from Andreas Schwab  ---
Apparently GAS has lost its BROKEN_DOT_WORD handing.

[Bug libstdc++/51749] Including pollutes global namespace

[paolo.carlini at oracle dot com]

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

--- Comment #22 from Paolo Carlini  ---
If I remember correctly, the gthr.h included by ext/atomicity.h is also a big
issue. If we switch to a non-reference-counted basic_string we can make
progress but another usage is in , global locale & co.

[Bug tree-optimization/30604] Unable to coalesce ssa_names and which are marked as MUST COALESCE

[dcb314 at hotmail dot com]

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

--- Comment #17 from David Binderman  ---
(In reply to rguent...@suse.de from comment #16)
> Can you open a new bugreport please?  It's very likely a different
> reason than this one.

After a lot of fiddling about, please see #57584

Redhat package guile went to a lot of work to hide
the compiler command line ;-|

[Bug c/57584] New: ice: SSA corruption: Unable to coalesce ssa_names

[dcb314 at hotmail dot com]

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

Bug ID: 57584
   Summary: ice: SSA corruption: Unable to coalesce ssa_names
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com

Created attachment 30289
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30289&action=edit
gzipped C source code

The attached source code causes the following crash
on gcc-4.9 trunk dated 20130605 on an AMD x86_64 box
when compiled with -O3.

Unable to coalesce ssa_names 45 and 3671 which are marked as MUST COALESCE.
sp_45(ab) and  sp_3671(ab)
In file included from vm.c:661:0:
vm-engine.c: In function ‘vm_debug_engine’:
vm-engine.c:39:1: internal compiler error: SSA corruption
0x9ca5bf fail_abnormal_edge_coalesce
../../src/trunk/gcc/tree-ssa-coalesce.c:898
0x9ca5bf coalesce_partitions
../../src/trunk/gcc/tree-ssa-coalesce.c:1200
0x9ca5bf coalesce_ssa_name()
../../src/trunk/gcc/tree-ssa-coalesce.c:1337
0x981cee remove_ssa_form
../../src/trunk/gcc/tree-outof-ssa.c:900
0x981cee rewrite_out_of_ssa(ssaexpand*)
../../src/trunk/gcc/tree-outof-ssa.c:1133
0x60c694 gimple_expand_cfg
../../src/trunk/gcc/cfgexpand.c:4541
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug libstdc++/51749] Including pollutes global namespace

[jakub at gcc dot gnu.org]

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

--- Comment #21 from Jakub Jelinek  ---
(In reply to Jonathan Wakely from comment #20)
> (In reply to Jakub Jelinek from comment #19)
> > Has anyone checked recently what exactly we still need -D_GNU_SOURCE for in
> > the public headers (as opposed to just the libstdc++ code), as compared to
> > say _ISOC99_SOURCE for glibc, at least for C++11?
> 
> I haven't checked, it would be useful to do so.  There is some stuff used by
> the --enable-clocale=gnu code such as uselocale (which is now part of POSIX
> but not C99) but it might be possible to only require that from .cc files
> not in headers.

In __gnu_cxx namespace:
  extern "C" __typeof(uselocale) __uselocale;
and in std namespace:
  typedef __locale_t__c_locale;

suggests that it really is looking for the uselocale function just to get the
prototype and declares the function itself, and we need an alternative to
__locale_t.  We can't include xlocale.h, because that would make locale_t
symbol visible, and can't typedef __locale_t, because that could clash with

definition -D_GNU_SOURCE etc.
Thus it would need to be something like:
// Hackish forward declaration in global namespace.
struct __locale_struct;
and then just do:
  extern "C" __locale_struct *__uselocale (__locale_struct *);
in __gnu_cxx namespace and
  typedef __locale_struct *  __c_locale;
in std namespace.

[Bug target/57583] New: large switches with jump tables are horribly broken on m68k

[mikpe at it dot uu.se]

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

Bug ID: 57583
   Summary: large switches with jump tables are horribly broken on
m68k
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mikpe at it dot uu.se

Created attachment 30288
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30288&action=edit
test case and generator program

Switch jump tables on m68k-linux use 16-bit PC-relative offsets.  No
verification is made that the offsets actually fit in 16 bits, instead they are
silently truncated.  As a result, a large switch may branch to a wrong address;
in my case it branches into the jump table itself causing a SIGILL.

There are two bugs here:

1. GCC seems to hard-code the use of 16-bit offsets in its jump tables on
m68k-linux.  It should have an option to use 32-bit offsets instead.

2. GAS (not part of GCC I know) truncates ".word" operands to 16 bits without
warning or error when significant bits are lost.  I'll file that separately at
the sourceware/binutils bugzilla.

The test case contains a for (;;) loop with a switch () with 64K cases 0 ..
64K-1, each case containing a function call and a break. That switch becomes
the following assembly code on m68k-linux with gcc-4.8.1:

.L259:
move.l (%a2),-(%sp)
move.l %a2,-(%sp)
jsr fetch
addq.l #8,%sp
and.l #65535,%d0
move.w .L262(%pc,%d0.l*2),%d0
jmp %pc@(2,%d0:w)
.balignw 2,0x284c
.L262:
.word .L260-.L262
(64K - 1 more of these with varying labels in the first operand)

When run on the target the code SIGILLs:

0x8402 in fetch ()
1: x/i $pc
=> 0x8402 :   rts
(gdb)
0x80001c0c in loop ()
1: x/i $pc
=> 0x80001c0c :addql #8,%sp
(gdb)
0x80001c0e in loop ()
1: x/i $pc
=> 0x80001c0e :andil #65535,%d0
(gdb)
0x80001c14 in loop ()
1: x/i $pc
=> 0x80001c14 :movew %pc@(0x80001c1c ,%d0:l:2),%d0
(gdb)
0x80001c18 in loop ()
1: x/i $pc
=> 0x80001c18 :jmp %pc@(0x80001c1c ,%d0:w)
(gdb) print $d0
$3 = 4

*** THIS "4" SHOWS THAT THE JUMP TABLE ENTRY HAS BEEN TRUNCATED

(gdb) stepi
0x80001c20 in loop ()
1: x/i $pc
=> 0x80001c20 :.short 0xfff2
(gdb) stepi

Program received signal SIGILL, Illegal instruction.

I'm attaching the test case (bug.c) and the program used to generate it
(genbug.c).

Classifying as a target bug since the code works on x86_64 and powerpc64.

[Bug libstdc++/56019] max_align_t should be in std namespace

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #3 from Paolo Carlini  ---
Fixed for 4.9.0. If somebody is interested in 4.8.x too, backporting the patch
should not be a big deal.

[Bug libstdc++/51749] Including pollutes global namespace

[redi at gcc dot gnu.org]

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

--- Comment #20 from Jonathan Wakely  ---
(In reply to Jakub Jelinek from comment #19)
> Has anyone checked recently what exactly we still need -D_GNU_SOURCE for in
> the public headers (as opposed to just the libstdc++ code), as compared to
> say _ISOC99_SOURCE for glibc, at least for C++11?

I haven't checked, it would be useful to do so.  There is some stuff used by
the --enable-clocale=gnu code such as uselocale (which is now part of POSIX but
not C99) but it might be possible to only require that from .cc files not in
headers.

[Bug libstdc++/51749] Including pollutes global namespace

[jakub at gcc dot gnu.org]

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

--- Comment #19 from Jakub Jelinek  ---
(In reply to Jonathan Wakely from comment #18)
> Comment 8 is only referring to  et al putting standard C names in
> the global namespace as well as in namespace std, which is legal. We all
> agree it's not legal to also put names that aren't from ISO C (e.g. POSIX
> names) in the global namespace.

Has anyone checked recently what exactly we still need -D_GNU_SOURCE for in the
public headers (as opposed to just the libstdc++ code), as compared to say
_ISOC99_SOURCE for glibc, at least for C++11?

[Bug libstdc++/51749] Including pollutes global namespace

[redi at gcc dot gnu.org]

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

--- Comment #18 from Jonathan Wakely  ---
Comment 8 is only referring to  et al putting standard C names in the
global namespace as well as in namespace std, which is legal. We all agree it's
not legal to also put names that aren't from ISO C (e.g. POSIX names) in the
global namespace.

[Bug libstdc++/51749] Including pollutes global namespace

[nmm1 at cam dot ac.uk]

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

--- Comment #17 from Nick Maclaren  ---
I will just add to comment 8 that dumping large chunks of the POSIX
namespace in isn't legal, unless WG21 have completely lost their
marbles :-)

But, as people have said, this isn't fixable by hacking - not least
because it would have to be done in translation phase 4, not 8, so
namespaces would not be a permissable tool.  We shall have to wait
for a proper fix.

[Bug target/56564] movdqa on possibly-8-byte-aligned struct with -O3

[jakub at gcc dot gnu.org]

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

--- Comment #17 from Jakub Jelinek  ---
(In reply to Dominique d'Humieres from comment #16)
> On x86_64-apple-darwin10.8 at revision 199935, I get the following failures
> for the tests added at revision 199898:
> 
> FAIL: gcc.target/i386/pr56564-1.c scan-tree-dump-times optimized "&s" 1
> FAIL: gcc.target/i386/pr56564-1.c scan-tree-dump-times optimized "return 0" 1
> FAIL: gcc.target/i386/pr56564-3.c scan-tree-dump-times optimized "&s" 1
> FAIL: gcc.target/i386/pr56564-3.c scan-tree-dump-times optimized "&t" 1

Yeah, MachO is broken by design, guess the tests need to be restricted to
non-darwin non-PE.

[Bug libstdc++/56019] max_align_t should be in std namespace

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com

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

[Bug target/56564] movdqa on possibly-8-byte-aligned struct with -O3

[dominiq at lps dot ens.fr]

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

--- Comment #16 from Dominique d'Humieres  ---
On x86_64-apple-darwin10.8 at revision 199935, I get the following failures for
the tests added at revision 199898:

FAIL: gcc.target/i386/pr56564-1.c scan-tree-dump-times optimized "&s" 1
FAIL: gcc.target/i386/pr56564-1.c scan-tree-dump-times optimized "return 0" 1
FAIL: gcc.target/i386/pr56564-3.c scan-tree-dump-times optimized "&s" 1
FAIL: gcc.target/i386/pr56564-3.c scan-tree-dump-times optimized "&t" 1

The optimized dumps are (blank lines removed):

[macbook] f90/bug% cat pr56564-1.c.165t.optimized
;; Function foo (foo, funcdef_no=0, decl_uid=1741, symbol_order=2)
foo ()
{
  :
  return 0;
}
;; Function bar (bar, funcdef_no=1, decl_uid=1744, symbol_order=3)
bar ()
{
  :
  return 0;
}

[macbook] f90/bug% cat pr56564-3.c.165t.optimized
;; Function foo (foo, funcdef_no=0, decl_uid=1741, symbol_order=2)
foo ()
{
  struct S * D.1770;
  long int s.0;
  int _2;
  int _3;
  :
  _5 = __builtin___emutls_get_address (&__emutls_v.s);
  s.0_1 = (long int) _5;
  _2 = (int) s.0_1;
  _3 = _2 & 15;
  return _3;
}
;; Function bar (bar, funcdef_no=1, decl_uid=1744, symbol_order=3)
bar ()
{
  char * D.1769;
  char[16] * D.1768;
  long int _1;
  int _2;
  int _3;
  :
  _5 = __builtin___emutls_get_address (&__emutls_v.t);
  _6 = &*_5[0];
  _1 = (long int) _6;
  _2 = (int) _1;
  _3 = _2 & 15;
  return _3;
}

[Bug libstdc++/56430] In __airy: return-statement with a value, in function returning 'void'.

[paolo.carlini at oracle dot com]

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

--- Comment #3 from Paolo Carlini  ---
What happened to this issue?

[Bug libstdc++/56677] [ratio] : ratio_multiply, ratio_divide, etc results doesnt verify as __is_ratio

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #5 from Paolo Carlini  ---
Fixed for 4.8.0.

[Bug libstdc++/57049] std::swap does self move assignment, which is illegal

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #3 from Paolo Carlini  ---
Closing then.

[Bug libstdc++/51749] Including pollutes global namespace

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||nmm1 at cam dot ac.uk

--- Comment #16 from Paolo Carlini  ---
*** Bug 57582 has been marked as a duplicate of this bug. ***

[Bug libstdc++/57582] clone is effectively reserved by and should not be

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #1 from Paolo Carlini  ---
Dup.

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

[Bug tree-optimization/57579] Problem with vectorization

[federico.carminati at cern dot ch]

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

--- Comment #3 from Federico Carminati  ---
Hello Richard,
   thanks a lot!! I would have never figured this out by myself. However let me
repeat my question, is there a place where this can be learnt without relying
on kind (and knowledgeable) souls like you? Thanks!

[Bug libstdc++/57582] New: clone is effectively reserved by and should not be

[nmm1 at cam dot ac.uk]

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

Bug ID: 57582
   Summary: clone is effectively reserved by  and should
not be
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nmm1 at cam dot ac.uk

This is probably java leaking into C++, or something of that nature.
The word "clone" does not occur in the C++ standard.

Under OpenSUSE 11.1, gcc 4.8.0 fails on the following code:

/home/nmm/GCC/bin/g++ -std=c++11 -Wall -Wextra -c -O3 junk.cpp

#include 
using namespace std;

class run;
class clone;

class cell {
cell (clone * c, run * r) {}
};

junk.cpp:8:17: error: expected ')' before '*' token
 cell (clone * c, run * r) {}

Changing clone to clown and removing  both cure it.

[Bug tree-optimization/57579] Problem with vectorization

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
(In reply to Federico Carminati from comment #0)
> Good evening,
>all my apologises if this is a stupid question, however I have a terribly
> simple loop
> 
> 
> include 
> 
> typedef struct
> {
>double x,y,z;
>double dummy;
> } P;
> 
> 
> void foo(const P * __restrict__ points, double * __restrict__ d)
> {
>for(int i=0;i<100;++i) {
>   d[i]=points[i].x*points[i].x*points[i].x*points[i].x+
>points[i].y*points[i].y*points[i].y+
>points[i].z*points[i].z*points[i].z;
>}
> }
>  
> if I compile with
> 
> /opt/gcc-4.8.1/bin/g++ -c -std=c++0x -O3 -msse4.1 -Wall -Wstrict-aliasing=2
> -ftree-vectorizer-verbose=2
> 
> I obtain the diagnostic at the bottom of the page. Is there a place where I
> can find an explanation for the g++ vectorizer diagnostic messages? I
> frankly do not understand what it is talking about and google does not seem
> to be willing to help me this time. Any help in deciphering these messages
> would be greatly appreciated. Thanks and sorry for the bother
> 
> Analyzing loop at testvec1.cxx:12
> 
> testvec1.cxx:12: note: Data access with gaps requires scalar epilogue loop
> testvec1.cxx:12: note: vector alignment may not be reachable
> testvec1.cxx:12: note: virtual phi. skip.
> testvec1.cxx:12: note: not ssa-name.
> testvec1.cxx:12: note: use not simple.
> testvec1.cxx:12: note: not ssa-name.
> testvec1.cxx:12: note: use not simple.
> testvec1.cxx:12: note: no array mode for V2DF[4]
> testvec1.cxx:12: note: not ssa-name.
> testvec1.cxx:12: note: use not simple.
> testvec1.cxx:12: note: not ssa-name.
> testvec1.cxx:12: note: use not simple.
> testvec1.cxx:12: note: no array mode for V2DF[4]
> testvec1.cxx:12: note: not ssa-name.
> testvec1.cxx:12: note: use not simple.
> testvec1.cxx:12: note: not ssa-name.
> testvec1.cxx:12: note: use not simple.
> testvec1.cxx:12: note: no array mode for V2DF[4]
> 
> Vectorizing loop at testvec1.cxx:12



the loop is vectorized.

> testvec1.cxx:12: note: virtual phi. skip.
> testvec1.cxx:12: note: no array mode for V2DF[4]
> testvec1.cxx:12: note: no array mode for V2DF[4]
> testvec1.cxx:12: note: no array mode for V2DF[4]
> testvec1.cxx:10: note: vectorized 1 loops in function.
> 
> testvec1.cxx:10: note: not vectorized: not enough data-refs in basic block.
> 
> testvec1.cxx:13: note: not vectorized: no vectype for stmt: vect_var_.10_29
> = MEM[(const struct P *)vect_ppoints.6_31];
>  scalar_type: const vector(2) double
> testvec1.cxx:13: note: Failed to SLP the basic block.
> testvec1.cxx:13: note: not vectorized: failed to find SLP opportunities in
> basic block.
> 
> testvec1.cxx:13: note: Build SLP failed: grouped loads have gaps _59 =
> _60->x;
> 
> testvec1.cxx:13: note: Failed to SLP the basic block.
> testvec1.cxx:13: note: not vectorized: failed to find SLP opportunities in
> basic block.
> 
> testvec1.cxx:10: note: not vectorized: not enough data-refs in basic block.

the rest of the "complaints" are from basic-block vectorization trying to
vectorize the loop body again.  Which of course fails, it is already
vectorized.

[Bug target/57578] SPE detection broken on Linux (bits/predefs.h: No such file or directory)

[doko at gcc dot gnu.org]

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

Matthias Klose  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-06-11
 Ever confirmed|0   |1

[Bug target/57578] SPE detection broken on Linux (bits/predefs.h: No such file or directory)

[doko at gcc dot gnu.org]

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

Matthias Klose  changed:

   What|Removed |Added

 CC||doko at gcc dot gnu.org

--- Comment #1 from Matthias Klose  ---
looks ok to me, but please send this to the gcc-patches ML and CC the powerpc
maintainers.

[Bug regression/57551] [4.9 Regression]: g++.dg/ext/visibility/anon6.C scan-assembler 1BIiE1cE

[hubicka at ucw dot cz]

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

--- Comment #6 from Jan Hubicka  ---
Good to be assigned.  I posted the patch 
Jason, can you please look at
http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00433.html

Honza

[Bug target/56739] FreeBSD ia64: gcc49/work/build/ia64-portbld-freebsd10.0/libstdc++-v3/include/mutex:781:41: internl compiler error: Segmentation fault

[mexas at bristol dot ac.uk]

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

Anton Shterenlikht  changed:

   What|Removed |Added

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

--- Comment #2 from Anton Shterenlikht  ---
I can build gcc-4.9.0.20130526 on
FreeBSD 10.0-CURRENT #4 r248493 ia64

[Bug middle-end/54582] gap in FORTIFY checking of buffer lengths

[dcb314 at hotmail dot com]

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

--- Comment #16 from David Binderman  ---
Created attachment 30287
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30287&action=edit
C++ source code

Latest version understands NUM1.NUM2, 53 formatting specifiers
and a bunch of prefixes like %#

It seems to work well over the source code of Fedora Linux.