[Bug c/58016] stdatomic.h missing in 4.8.1

2013-07-29 Thread redi at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58016

--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org ---
Noone disputes it's not conforming. The point is the support is incomplete.
It's known to be incomplete. It's documented as incomplete.  Reporting a bug to
say it's incomplete doesn't serve any useful purpose, it will be complete when
it's completed.


[Bug target/57954] AVX missing vxorps (zeroing) before vcvtsi2s %edx, slow down AVX code

2013-07-29 Thread ubizjak at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57954

Uroš Bizjak ubizjak at gmail dot com changed:

   What|Removed |Added

 Target||x86
 Status|UNCONFIRMED |RESOLVED
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2013-07/msg01368.htm
   ||l
 Resolution|--- |FIXED
   Target Milestone|--- |4.9.0

--- Comment #6 from Uroš Bizjak ubizjak at gmail dot com ---
Author: uros
Date: Mon Jul 29 11:17:51 2013
New Revision: 201308

URL: http://gcc.gnu.org/viewcvs?rev=201308root=gccview=rev
Log:
2013-07-29  Uros Bizjak  ubiz...@gmail.com

* config/i386/i386.md (float post-reload splitters): Do not check
for subregs of SSE registers.

2013-07-29  Uros Bizjak  ubiz...@gmail.com
H.J. Lu  hongjiu...@intel.com

PR target/57954
PR target/57988
* config/i386/i386.md (post-reload splitter
to avoid partial SSE reg dependency stalls): New pattern.


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

[Bug target/57954] AVX missing vxorps (zeroing) before vcvtsi2s %edx, slow down AVX code

2013-07-29 Thread ubizjak at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57954

--- Comment #7 from Uroš Bizjak ubizjak at gmail dot com ---
Fixed.

[Bug target/57954] AVX missing vxorps (zeroing) before vcvtsi2s %edx, slow down AVX code

2013-07-29 Thread vincenzo.innocente at cern dot ch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57954

--- Comment #8 from vincenzo Innocente vincenzo.innocente at cern dot ch ---
thanks for getting in the trunk.
will be possible to back port to at least 4.8?
(this issue is there till 4.4!)


[Bug target/57954] AVX missing vxorps (zeroing) before vcvtsi2s %edx, slow down AVX code

2013-07-29 Thread ysrumyan at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57954

Yuri Rumyantsev ysrumyan at gmail dot com changed:

   What|Removed |Added

 CC||ysrumyan at gmail dot com

--- Comment #9 from Yuri Rumyantsev ysrumyan at gmail dot com ---
Uros,

I assume that this fix is not good and must be reverted - I will prepare
another fix for your reviewing. There are at least 2 problems:

1. New split for int -- fp converisons is done under TARGET_SSE2 and
TARGET_SSE_PARTIAL_REG_DEPENDENCY which include both Atom chips - SLT and SLM.
I checked that zeroing of xmm register before conversion leads to performance
slowdown on SLM (-5%) for proveded test-case. I assume that TARGET_AVX must be
used instead of TARGET_SSE2.
2. This zeroing must redundant and should not be inserted, e.g. for the
following simple test-case:

void foo (float* p, int n)
{
  int i;
  for (i=0; in; i++)
p[i] = (float) i;
}

with H.J patch we got the following assembly (I compiled it for slm but it does
not matter):

.L3:
xorps%xmm0, %xmm0
cvtsi2ss%eax, %xmm0
movss%xmm0, (%ecx,%eax,4)
addl$1, %eax
cmpl%edx, %eax
jne.L3

It is clear that zeroing is redundant for it and must be deleted.


[Bug tree-optimization/58012] Gcc bootstrap failed with cloog-isl: undefined reference to std::istream::ignore(long)

2013-07-29 Thread goughost at yahoo dot com.cn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58012

goughost goughost at yahoo dot com.cn changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #1 from goughost goughost at yahoo dot com.cn ---
It's not the function definition, but `#include iostream' that caused the
error. Either isl should get patched to `#include ostream'; or gcc provide a
bigger libstdc++convenience.a that has the missing bits. The previous is
easier, as long as only std::ostream is used in that header.


[Bug libfortran/37634] Fix libgfortran compiling to support GCC_NO_EXECUTABLES

2013-07-29 Thread fxcoudert at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37634

Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu.org

--- Comment #5 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org ---
I think this bug was fixed by Steve Ellcey in revision 200374:

r200374 | sje | 2013-06-24 17:24:19 +0200 (Mon, 24 Jun 2013) | 5 lines

2013-06-24  Steve Ellcey  sell...@mips.com

* configure.ac (AC_CHECK_FUNCS_ONCE): Put into if statement.
* configure: Regenerate.

(though, for some reason, this commit message cannot be found in
libgfortran/ChangeLog). I'm closing, please reopen if it is not actually fixed
(with current explanation of what goes wrong).


[Bug c/58016] stdatomic.h missing in 4.8.1

2013-07-29 Thread joseph at codesourcery dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58016

--- Comment #4 from joseph at codesourcery dot com joseph at codesourcery dot 
com ---
__STDC_VERSION__ describes *intent* of command-line options (as regards 
differences between standard versions, to the extent that those are 
implemented).  This is the same principle that has been documented for 
__STDC__ since at least GCC 2.0.

  Sometimes people say that defining @code{__STDC__} in a compiler that
  does not completely conform to the ANSI C standard somehow violates the
  standard.  This is illogical.  The standard is a standard for compilers
  that are supposed to conform.  It says nothing about what any other
  compilers should do.  Whatever the ANSI C standard says is relevant to
  the design of plain @samp{gcc} without @samp{-ansi} only for pragmatic
  reasons, not as a requirement.

(quoted from the GCC 2.0 manual).

As a pragmatic matter, it's useful for users of standards modes that are 
incomplete to be able to tell which of those modes is in use, and 
__STDC_VERSION__ is the natural macro to define to distinguish between 
them.  gcc -std=c11 is a compiler explicitly claimed not to conform.


[Bug libstdc++/57997] Segmentation fault after returning valarray expression from an auto function

2013-07-29 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57997

--- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com ---
In my opinion it would be great if you could concretely propose a patch. I'm
sure that both Gaby and the other library maintainers, like me, would be fast
at reviewing it. Of course, if large it would require a Copyright assignment,
but maybe not.


[Bug libstdc++/57997] Segmentation fault after returning valarray expression from an auto function

2013-07-29 Thread roystgnr at ices dot utexas.edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57997

--- Comment #4 from Roy Stogner roystgnr at ices dot utexas.edu ---
I oversimplified the code here to try and make the failure as easy to
reproduce as possible.  The term here isn't con-fusion, it's kernel
fusion, which the original user code is trying to do with libstdc++
valarray expressions (and VexCL expressions, and Eigen expressions,
etc; those cases work); this is essentially the opposite of assuming
that expression templates match their input types.  To keep equations
in their own functions (for maintainability) while still doing
parallel evaluation in a single loop (for efficiency), those functions
need to return the expression templates which embody their equations.

However, this does assume that expression template move constructors
(or copy constructors if move constructors aren't defined) don't do a
shallow copy of the representations of subexpression objects, and I
can't see anything in C++2011 or C++2014 standards drafts *mandating*
anything about those constructors.  If my amateur standards-lawyering
is correct, it would be fair for you to mark this as wontfix or
whatever bugzilla term signifies go_bug_standards_committee_instead.

On the third hand, there's nothing in the current standard mandating
that the implementation *not* be robust when doing kernel fusion with
user functions, either.  Storing subexpressions by value in _BinBase
(specializing to store by reference when the subexpression is just a
valarray) might be a sufficient fix.


[Bug target/57954] AVX missing vxorps (zeroing) before vcvtsi2s %edx, slow down AVX code

2013-07-29 Thread ubizjak at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57954

--- Comment #10 from Uroš Bizjak ubizjak at gmail dot com ---
(In reply to Yuri Rumyantsev from comment #9)

 I assume that this fix is not good and must be reverted - I will prepare
 another fix for your reviewing. There are at least 2 problems:
 
 1. New split for int -- fp converisons is done under TARGET_SSE2 and
 TARGET_SSE_PARTIAL_REG_DEPENDENCY which include both Atom chips - SLT and
 SLM.
 I checked that zeroing of xmm register before conversion leads to
 performance slowdown on SLM (-5%) for proveded test-case. I assume that
 TARGET_AVX must be used instead of TARGET_SSE2.

The patch is effective for my target (IvyBridge), but I see no problem to
fine-tune the split condition for other targets. Perhaps Atom should be taken
out od TARGET_SSE_PARTIAL_REG_DEPENDENCY ?

 2. This zeroing must redundant and should not be inserted, e.g. for the
 following simple test-case:
 
 void foo (float* p, int n)
 {
   int i;
   for (i=0; in; i++)
 p[i] = (float) i;
 }
 
 with H.J patch we got the following assembly (I compiled it for slm but it
 does not matter):
 
 .L3:
   xorps   %xmm0, %xmm0
   cvtsi2ss%eax, %xmm0
   movss   %xmm0, (%ecx,%eax,4)
   addl$1, %eax
   cmpl%edx, %eax
   jne .L3
 
 It is clear that zeroing is redundant for it and must be deleted.

Hm, it is not that clear. If the stall is happening in cvtsi2ss, then following
movss shouldn't matter, or at least it shouldn't make things any worse. Of
course, you have much more information at hand, so instead of the patch revert
(the patch *is* effective for certain targets), I suggest to submit a follow-up
patch that fine-tunes the split condition.

[Bug rtl-optimization/51041] g++ strange optimisation behaviour

2013-07-29 Thread vmakarov at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51041

Vladimir Makarov vmakarov at redhat dot com changed:

   What|Removed |Added

 CC||vmakarov at redhat dot com

--- Comment #3 from Vladimir Makarov vmakarov at redhat dot com ---
I guess RA is doing right thing.  Pseudo 84 corresponding to variable sum when
the second printf is uncommented lives through insn throwing an
exception.  The code affecting p84 allocation (putting it into memory
as SSE_REGS have no caller-saved regs) is

ira-lives.c::process_bb_node_lives:

  if (can_throw_internal (insn))
{
  IOR_HARD_REG_SET (OBJECT_CONFLICT_HARD_REGS (obj),
call_used_reg_set);
  IOR_HARD_REG_SET (OBJECT_TOTAL_CONFLICT_HARD_REGS (obj),
call_used_reg_set);
}
Where insn is:

(call_insn 141 140 142 22 (call (mem:QI (symbol_ref:DI (_ZdlPv) [flags 0x41]
function_decl 0x71ae2400 operator delete) [0 operator delete S1 A8])
(const_int 0 [0]))
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/ext/new_allocator.h:100
648 {*call}
 (expr_list:REG_DEAD (reg:DI 5 di)
(expr_list:REG_EH_REGION (const_int 0 [0])
(nil)))
(expr_list:REG_FRAME_RELATED_EXPR (use (reg:DI 5 di))
(nil)))

it is a destructor in new_allocator.h:

  void
  deallocate(pointer __p, size_type)
  { ::operator delete(__p); }

The problem could be solved by p84 live range splitting.  By default IRA does
live range splitting only when the register pressure is high.  This is not the
case for the test where max pressure for GENERAL_REGS and SSE_REGS is only 4.

We can modify semantics -fira-region=all to form a region for any loop on which
border live range splitting is done.  I tried that and with -fira-region=all
the same speed is achieved for the test.  Unfortunately, with the new semantics
permitting too aggressive spilling, the generated code is about 0.5% worse on
SPEC2000 for x86-64.

I guess we should pay more attention in optimizations to deal with code with EH
regions, as C++ code have a lot of such code.

I'll think what can I do more with the problem.


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

2013-07-29 Thread jamborm at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57987

--- Comment #3 from Martin Jambor jamborm at gcc dot gnu.org ---
Uh oh, but I do not really feel comfortable submitting a patch like
this that I do not understand at all but happens to pass the testsuite :-)


[Bug c/58019] New: Problem with -O3 optimization

2013-07-29 Thread william.jordan at vbrick dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58019

Bug ID: 58019
   Summary: Problem with -O3 optimization
   Product: gcc
   Version: 4.7.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: william.jordan at vbrick dot com

I wrote a simple program to solve the 8 queens chess problem (i.e. put 8 queens
on a chessboard so that no queen can take any other queen).  When I compile the
program normally or with -O1 -O2 optimization it finds solutions and prints
them out.  When I compile with -O3 optimization it finds no solutions.

Below is the compiler version and source code.  This was also reproduced using
gcc 4.1.2.

gcc -v output:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.7.3-1ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs
--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.7 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.7 --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 --enable-objc-gc --with-cloog --enable-cloog-backend=ppl
--disable-cloog-version-check --disable-ppl-version-check --enable-multiarch
--disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --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.7.3 (Ubuntu/Linaro 4.7.3-1ubuntu1) 


Source code to reproduce problem:
#include stdio.h


int TestPiece(int ipos, int jpos, int board[8][8])
{
  int i, j;

  for (i = 0; i  8; i++) {
for (j = 0; j  8; j++) {
  if (board[i][j]  (i != ipos || j!= jpos)) {
if (i == ipos) {
  return(1);
} else if (j == jpos) {
  return(2);
} else if ((ipos - i == jpos - j) || (i - ipos == jpos - j)) {
  return(3);
}
  }
}
  }
  return(0);
}


int TestBoard(int board[8][8])
{
  int i, j;

  for (i = 0; i  8; i++) {
for (j = 0; j  8; j++) {
  if (board[i][j]) {
if (TestPiece(i, j, board)) {
  return(1);
}
  }
}
  }
}


int PrintBoard(int board[8][8])
{
  int i, j;

  printf(Solution found\n\n);
  for (i = 0; i  8; i++) {
for (j = 0; j  8; j++) {
  if (board[i][j]) {
printf(Q);
  } else {
printf(-);
  }
}
printf(\n);
  }
  printf(\n);
}


int main(int argc, char *argv[])
{
  int board[8][8];
  int i, j, k, numchecks = 1;

  for (i = 0; i  8; i++) {
numchecks *= 8;
for (j = 0; j  8; j++) {
  if (j == 0) {
board[i][j] = 1;
  } else {
board[i][j] = 0;
  }
}
  }


  for (i = 0; i  numchecks; i++) {
if (!TestBoard(board)) {
  PrintBoard(board);
}
for (j = 7; j = 0; j--) {
  if (board[j][7]) {
board[j][7] = 0;
board[j][0] = 1;
  } else {
for (k = 0; k  7; k++) {
  if (board[j][k]) {
board[j][k] = 0;
board[j][k + 1] = 1;
break;
  }
}
break;
  }
}
  }
}


[Bug c/58016] stdatomic.h missing in 4.8.1

2013-07-29 Thread jeff.science at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58016

--- Comment #5 from Jeff Hammond jeff.science at gmail dot com ---
Can someone tell me where the appropriate place to define __STDC_NO_ATOMICS__
and __STDC_NO_THREADS__ in GCC so I can submit a patch?  I'd rather solve the
problem and take 1-2 steps forward towards C11 compliance rather than debate
the philosophical aspects of the problem.


[Bug c/58019] Problem with -O3 optimization

2013-07-29 Thread glisse at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58019

Marc Glisse glisse at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2013-07-29
 Ever confirmed|0   |1

--- Comment #1 from Marc Glisse glisse at gcc dot gnu.org ---
Your testcase produces obvious warnings with -Wall -Wextra. Please provide a
fixed testcase (or close the bug if following the warnings solves your issue).


[Bug c/58016] stdatomic.h missing in 4.8.1

2013-07-29 Thread jeff.science at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58016

Jeff Hammond jeff.science at gmail dot com changed:

   What|Removed |Added

 CC||jeff.science at gmail dot com

--- Comment #6 from Jeff Hammond jeff.science at gmail dot com ---
Created attachment 30568
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30568action=edit
patch to define macros indicating missing C11 support

If GCC defines __STDC_NO_ATOMICS__ and __STDC_NO_THREADS__, it is no longer
non-compliant w.r.t. C11 to not provide stdatomic.h and threads.h.  This would
resolve bugs 53769 and 58016, albeit in a trivial way.

I will not be surprised at all if this patch is rejected, if for no other
reason than my institution has not signed a contributor agreement with FSF
(they almost certainly will if I ask).  My goal is to inspire someone else to
do it properly since it seems trivial and arguably necessary.


[Bug c/58016] stdatomic.h missing in 4.8.1

2013-07-29 Thread joseph at codesourcery dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58016

--- Comment #7 from joseph at codesourcery dot com joseph at codesourcery dot 
com ---
__STDC_NO_THREADS__ is defined in glibc's stdc-predef.h because it 
describes combination compiler and library properties.

The correct fix for atomics for 4.9 will be to implement them - see Andrew 
MacLeod's patches and recent discussion on gcc-patches - and the state of 
C11 in 4.8 is what it is and 4.8 is subject to normal release branch rules 
(regression and documentation fixes only, generally).


[Bug c/58019] Problem with -O3 optimization

2013-07-29 Thread william.jordan at vbrick dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58019

Bill william.jordan at vbrick dot com changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Bill william.jordan at vbrick dot com ---
Close the bug.  I fixed the warnings produced by -Wall and it worked correctly.


[Bug libfortran/58020] New: Code for handling IEEE exceptions

2013-07-29 Thread fkrogh#gcc at mathalacarte dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58020

Bug ID: 58020
   Summary: Code for handling IEEE exceptions
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fkrogh#gcc at mathalacarte dot com

Dr. Richard Hanson has written code to provide IEEE exception handling to
gfortran.  He is the sole owner of that code and it could be used by gcc as
they wish.  The code is on my server at http://mathalacarte.com/hpcconsult
He can be contacted at richard.koolh...@gmail.com.  This feature is one of the
oldest language features not available in gfortran, and can be a real
impediment portability.


[Bug c/58016] stdatomic.h missing in 4.8.1

2013-07-29 Thread jeff.science at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58016

Jeff Hammond jeff.science at gmail dot com changed:

   What|Removed |Added

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

--- Comment #8 from Jeff Hammond jeff.science at gmail dot com ---
My patch was w.r.t. the trunk as of earlier today, not 4.8 but that's fine.  I
just subscribed to various GCC lists to track these developments.

I'll apply my patch locally so that I can use 4.8.1 and get the desired
behavior.


[Bug target/57954] AVX missing vxorps (zeroing) before vcvtsi2s %edx, slow down AVX code

2013-07-29 Thread dushistov at mail dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57954

--- Comment #11 from Evgeniy Dushistov dushistov at mail dot ru ---
(In reply to Yuri Rumyantsev from comment #9)
 I checked that zeroing of xmm register before conversion leads to
 performance slowdown on SLM (-5%) for proveded test-case. I assume that
 
 with H.J patch we got the following assembly (I compiled it for slm but it
 does not matter):
 
 .L3:
   xorps   %xmm0, %xmm0
   cvtsi2ss%eax, %xmm0
   movss   %xmm0, (%ecx,%eax,4)
   addl$1, %eax
   cmpl%edx, %eax
   jne .L3
 

By the way, I tried compile my sample
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57988) for atom, icc(13.1.3
20130607) produce:


xorps  %xmm2,%xmm2
cvtsi2sd %rax,%xmm2

may be 5% measuring error?

[Bug fortran/57800] Wasted work in gfc_match_call()

2013-07-29 Thread law at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57800

Jeffrey A. Law law at redhat dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #3 from Jeffrey A. Law law at redhat dot com ---
Patch installed on trunk.


[Bug fortran/57801] Wasted work in resolve_variable()

2013-07-29 Thread law at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57801

Jeffrey A. Law law at redhat dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #3 from Jeffrey A. Law law at redhat dot com ---
Patch installed on trunk.


[Bug fortran/57791] Wasted work in gfc_check_pointer_assign()

2013-07-29 Thread law at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57791

Jeffrey A. Law law at redhat dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #3 from Jeffrey A. Law law at redhat dot com ---
Patch installed on trunk.


[Bug fortran/57802] Wasted work in set_loop_bounds()

2013-07-29 Thread law at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57802

Jeffrey A. Law law at redhat dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #3 from Jeffrey A. Law law at redhat dot com ---
Patch installed on trunk.


[Bug fortran/57804] Wasted work in gfc_trans_transfer()

2013-07-29 Thread law at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57804

Jeffrey A. Law law at redhat dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #3 from Jeffrey A. Law law at redhat dot com ---
Patch installed on trunk.


[Bug libfortran/58020] Code for handling IEEE exceptions

2013-07-29 Thread kargl at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58020

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
1) Hanson needs to have a copyright assignment on file with FSF
   before the code can be used.

2) More importantly, the code appears to only support the i386
   and amd64 architectures.  gfortran runs are far more processors
   than these.

3) messy_m.f90 includes the statement:

   ! This code is free for noncommercial use as long as this source
   ! file is included.  It is recommended that the test file, tmessy
   ! be included as well.

   I haven't looked at the code to determine if messy_m.f90 is actually
   needed.


[Bug rtl-optimization/58021] New: MODE_EXIT switches at NOTE_INSN_DELETED

2013-07-29 Thread amylaar at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58021

Bug ID: 58021
   Summary: MODE_EXIT switches at NOTE_INSN_DELETED
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amylaar at gcc dot gnu.org

The last function of gcc.dg/fold-mulconj-1.c:

_Complex int bar(_Complex int z)
{
  return z * ~z;
}

gets miscompiled for epiphany-elf.

In compute_pre_exit, we break the do .. while (nregs).. loop with
last_insn pointing to a NOTE_INSN_DELETED, above which there are
two multiplies - needing a mode different than the exit.

However, because the NOTE_INSN_DELETED fails the INSN_P test,
the code that does the first split_block call is not executed,
and pre_exit ends up containing the multiplies.


[Bug c++/58022] New: Compiler rejects abstract class in template class with friend operator

2013-07-29 Thread scovich at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58022

Bug ID: 58022
   Summary: Compiler rejects abstract class in template class with
friend operator
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: scovich at gmail dot com

First, apologies for the vague subject line, I really don't know what to call
this bug...

Consider the following test case:

// --- begin bug.cpp ---
#include iostream
using namespace std;
template class T class foo;
template class T ostream  operator(ostream o, const fooT l);
template class T class foo  {
friend ostream operator T (ostream o, const fooT l);
};
class bar;
foobar fb;
class bar { virtual void baz()=0; };
// --- end bug.cpp ---

The test case was isolated using multidelta on a large code base that compiles
cleanly with gcc-4.7 and earlier.

Compiling it with gcc-4.8.1 gives the error: cannot allocate an object of
abstract type ‘bar’, and identifying this function in ostream:

  templatetypename _CharT, typename _Traits
inline basic_ostream_CharT, _Traits
operator(basic_ostream_CharT, _Traits __out, _CharT __c)
{ return __ostream_insert(__out, __c, 1); }

Replacing using namespace std with std::ostream everywhere allows it to
compile, as does moving the definition of bar above the friend declaration.

I'm not 100% certain the code is valid C++, seeing as how it instantiates a
template using an incomplete type, but there are still several issues:

1. The compiler gives no hint whatsoever where the real problem is, leaving the
user to infer the context in some other way; it took 2h with multidelta to
isolate the above test case and finally see what had happened.

2. The declaration of operator (which accepts a const ref) should not
interfere with the one in ostream (which accepts a value); without the const
ref declaration the compiler (rightfully!) complains that template-id
‘operator bar’ for ‘std::ostream operator(std::ostream, const
foobar)’ does not match any template declaration

3. At no point is bar actually instantiated, passed by value, or its members
accessed; even if operator did do one of those things, operator is never
actually called with foobar as an argument, so the template shouldn't be
instantiated.

For now, the workaround seems to be ensuring that bar is fully defined before
any template class mentions it, but that's not going to be easy given how hard
it is to find the problem (and the fact that the foo template is in a utility
library and really should be included first under normal circumstances).

[Bug c++/57948] internal compiler error: in initialize_reference, at cp/call.c:9285

2013-07-29 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57948

Paolo Carlini paolo.carlini at oracle dot com changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0
 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com

--- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com ---
Fixed for 4.9.0.


[Bug c++/58022] Compiler rejects abstract class in template class with friend operator

2013-07-29 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58022

--- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com ---
Please try to reduce the testcase further, no includes. You have a number of
options here: http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction


[Bug c++/58022] Compiler rejects abstract class in template class with friend operator

2013-07-29 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58022

--- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com ---
This compiles fine in mainline, doesn't with current 4_8-branch.


[Bug c++/57901] [4.8/4.9 Regression] Cannot call-by-value such that class has non-trivial (constexpr) move constructor

2013-07-29 Thread jason at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57901

Jason Merrill jason at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||jason at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
   Target Milestone|--- |4.8.2


[Bug c++/58022] [4.8 Regression] Compiler rejects abstract class in template class with friend operator

2013-07-29 Thread scovich at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58022

--- Comment #3 from Ryan Johnson scovich at gmail dot com ---
(In reply to Paolo Carlini from comment #1)
 Please try to reduce the testcase further, no includes. You have a number of
 options here: http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction

Sorry, I thought ostream was an important part of the bug and did some work
to put it back in... Here's the fully reduced case:

// --- begin bug.cpp ---
templatetypename _CharT
class basic_ostream;

typedef basic_ostreamchar ostream;

templatetypename T
basic_ostreamT operator(basic_ostreamT, T);

template class T class foo;

template class T ostream  operator(ostream, const fooT);

template class T class foo  {
friend ostream operator T (ostream, const fooT);
};

class bar;

foobar fb;

class bar { virtual void baz()=0; };
// --- end bug.cpp ---


[Bug c++/58022] [4.8 Regression] Compiler rejects abstract class in template class with friend operator

2013-07-29 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58022

Paolo Carlini paolo.carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-07-29
   Target Milestone|--- |4.8.2
 Ever confirmed|0   |1

--- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com ---
Thanks. Confirmed as a regression present only in 4_8-branch.


[Bug middle-end/57748] [4.8/4.9 Regression] ICE on ARM with -mfloat-abi=softfp -mfpu=neon

2013-07-29 Thread bernd.edlinger at hotmail dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748

--- Comment #6 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(In reply to Martin Jambor from comment #5)
 expand_assignment, offset as filled in get_inner_reference is the same,
 however get_object_alignment (tem) used to return 64, and now only returns
 32 which then pushes us the wrong path which does not handle this case.  So
 now I guess I should figure out why get_object_alignment thinks the
 alignment is so small...

hhmm..

set_ptr_info_alignment is always called with align=4,
and by the way, the crash goes away if I change this line
(but I cannot tell if the code is correct):

--- builtins.c.jj   2013-07-06 11:34:17.0 +0200
+++ builtins.c  2013-07-29 21:50:56.0 +0200
@@ -503,7 +503,7 @@ get_pointer_alignment_1 (tree exp, unsig
  *bitposp = ptr_misalign * BITS_PER_UNIT;
  *alignp = ptr_align * BITS_PER_UNIT;
  /* We cannot really tell whether this result is an approximation.  */
- return true;
+ return false;
}
   else
{


[Bug rtl-optimization/49847] [4.7/4.8/4.9 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)

2013-07-29 Thread tg at mirbsd dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847

Thorsten Glaser tg at mirbsd dot org changed:

   What|Removed |Added

 CC||tg at mirbsd dot org

--- Comment #23 from Thorsten Glaser tg at mirbsd dot org ---
Can this please be committed, it definitely fixes gcc-4.8 on Debian/m68k
(applied it locally for now and asked the maintainer to include it in the
source package).


[Bug libfortran/58020] Code for handling IEEE exceptions

2013-07-29 Thread fkrogh#gcc at mathalacarte dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58020

--- Comment #2 from Fred Krogh fkrogh#gcc at mathalacarte dot com ---
1. Hanson is willing to assign the copyright if you expect to be using this
work.  There were thoughts to include this work on a SIAM website where we
think SIAM would want the copyright, but if gfortran wants to use this work it
could be posted someplace that does not require copyright.  Perhaps you could
provide a link that describe how this assignment can be done.  The SIAM
publication is still work in progress and the package can be noted as
copyrighted in accordance with your standards.

2. There are no plans to support other architectures.  The code is useful for
the most prevalent one, and it is hoped would be useful there, as well as
helpful to people interested in ports to other platforms.  The Fortran standard
says it is ok to *not* implement the IEEE modules, but there should be a module
present on non-x86 machines that indicates this lack of support.  Presently
there is no support and no IEEE module of any kind.

3. The messy code is code I wrote, and is currently (I think) likely to be
published in the Transactions on Mathematical Software.  That code is used only
in the testing code and is not used in what should be considered the main
submission.  It does nothing more that give pretty output of results.

Please let us know, if given the above, you have an interest in pursuing this
further.
Fred


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

2013-07-29 Thread janus at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57306

janus at gcc dot gnu.org changed:

   What|Removed |Added

Summary|[OOP] ICE on valid with |[OOP] [F08] ICE on valid
   |class pointer   |with class pointer
   |initialization  |initialization

--- Comment #5 from janus at gcc dot gnu.org ---
Btw, pointer init is an F08 feature ...


[Bug libfortran/58020] Code for handling IEEE exceptions

2013-07-29 Thread sgk at troutmask dot apl.washington.edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58020

--- Comment #3 from Steve Kargl sgk at troutmask dot apl.washington.edu ---
On Mon, Jul 29, 2013 at 09:03:53PM +, fkrogh#gcc at mathalacarte dot com
wrote:
 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58020
 
 --- Comment #2 from Fred Krogh fkrogh#gcc at mathalacarte dot com ---
 1. Hanson is willing to assign the copyright if you expect to be using this
 work.  There were thoughts to include this work on a SIAM website where we
 think SIAM would want the copyright, but if gfortran wants to use this work it
 could be posted someplace that does not require copyright.  Perhaps you could
 provide a link that describe how this assignment can be done.  The SIAM
 publication is still work in progress and the package can be noted as
 copyrighted in accordance with your standards.

Given your 2) below, I suspect that the code would not be used
within gfortran.  If the code appears on the SIAM site or some
other (semi-)permanent websire, then adding a link from the 
gfortran wiki under Using gfortran may be appropriate.

 2. There are no plans to support other architectures.

The problem is that gfortran works on a large selection of
architectures.  We cannot simply pick to support i386/x86_64
and ignore all the others.  At the very least, IEEE_FEATURES
should report that IEEE 754 is not supported for these lesser
archs.

 The Fortran standard says it is ok to *not* implement the IEEE modules,

This is sort of true.

 but there should be a module present on non-x86 machines that indicates
 this lack of support.

This is not required by the standard.

 Presently there is no support and no IEEE module of any kind.

Yep, which is permitted by the standard.

The standard actually states:

Whether the modules are provided is processor dependent.

 3. The messy code is code I wrote, and is currently (I think) likely
to be published in the Transactions on Mathematical Software.  That
code is used only in the testing code and is not used in what should
be considered the main submission.  It does nothing more that give
pretty output of results.

Thanks for the clarification on the messy code.


[Bug tree-optimization/14741] graphite with loop blocking and interchanging doesn't optimize a matrix multiplication loop

2013-07-29 Thread spop at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14741

--- Comment #28 from Sebastian Pop spop at gcc dot gnu.org ---
(In reply to Evgeniy Dushistov from comment #26)
 void mult(const double * const __restrict__ A, const double * const
 __restrict__ B, double * const __restrict__ C, const size_t N)
 {
   for (size_t j = 0; j  N; ++j)
   for (size_t i = 0; i  N; ++i)
   for (size_t k = 0; k  N; ++k)
   C[i * N + j] += A[i * N + k] + B[k * N + j];

This code has the same problem as the Fortran program: it has linearized memory
access functions.  This code won't be transformed by Graphite unless you
instantiate N with a compile time constant, or otherwise you'll have to
delinearize the array accesses, and we don't have code to do that yet.

[Bug fortran/58023] New: ICE on invalid with missing NOPASS

2013-07-29 Thread abensonca at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58023

Bug ID: 58023
   Summary: ICE on invalid with missing NOPASS
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abensonca at gmail dot com

The following causes and ICE using gfortran 4.9.0 (r201320):

module m
  implicit none

  abstract interface
 double precision function mr()
 end function mr
  end interface

  type :: sfd
 procedure(mr), pointer :: mr1
 procedure(mr), pointer :: mr2
  end type sfd

contains

  subroutine go()
implicit none
type(sfd):: d

write (0,*) d%mr2()
return
  end subroutine go

end module m



$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/home/abenson/Galacticus/Tools
--enable-languages=c,c++,fortran --disable-multilib
--with-gmp=/home/abenson/Galacticus/Tools
Thread model: posix
gcc version 4.9.0 20130729 (experimental) (GCC) 

$ gfortran -c bug.F90 -o bug.o
bug.F90:10.34:

 procedure(mr), pointer :: mr1
  1
Error: Procedure pointer component 'mr1' with PASS at (1) must have at least
one argument
f951: internal compiler error: in update_ppc_arglist, at fortran/resolve.c:5346
0x58332a update_ppc_arglist
../../gcc-trunk/gcc/fortran/resolve.c:5346
0x57f63c resolve_expr_ppc
../../gcc-trunk/gcc/fortran/resolve.c:6020
0x57f63c gfc_resolve_expr(gfc_expr*)
../../gcc-trunk/gcc/fortran/resolve.c:6119
0x5860bb resolve_code
../../gcc-trunk/gcc/fortran/resolve.c:9692
0x585e0b gfc_resolve_blocks(gfc_code*, gfc_namespace*)
../../gcc-trunk/gcc/fortran/resolve.c:9006
0x586099 resolve_code
../../gcc-trunk/gcc/fortran/resolve.c:9682
0x588c8e resolve_codes
../../gcc-trunk/gcc/fortran/resolve.c:14471
0x588b97 resolve_codes
../../gcc-trunk/gcc/fortran/resolve.c:14457
0x588d72 gfc_resolve
../../gcc-trunk/gcc/fortran/resolve.c:14499
0x5755bf gfc_parse_file()
../../gcc-trunk/gcc/fortran/parse.c:4645
0x5b1545 gfc_be_parse_file
../../gcc-trunk/gcc/fortran/f95-lang.c:189
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.

The code is invalid because both procedure pointers in the sfd derived type
should have the NOPASS attribute (since the mr abstract interface declares no
arguments). 

The ICE only occurs if two (or more) procedure points are declared in this way,
AND the procedure pointer is accessed (via the write statement in this
example).


[Bug tree-optimization/57993] [4.9 Regression] ICE: verify_ssa failed (definition in block n does not dominate use in block m)

2013-07-29 Thread wschmidt at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57993

Bill Schmidt wschmidt at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #8 from Bill Schmidt wschmidt at gcc dot gnu.org ---
Fixed as r201325.


[Bug libstdc++/58025] New: Cannot use std::hash without setting off -Wmismatched-tags

2013-07-29 Thread whatmannerofburgeristhis at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58025

Bug ID: 58025
   Summary: Cannot use std::hash without setting off
-Wmismatched-tags
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: whatmannerofburgeristhis at gmail dot com

The headers inconsistently declare / forward declare std::hash using struct and
class, resulting in this warning when you try to use either. They should be
made to consistently use struct.

Testcase attached.

$ clang++ -std=c++11 -Wmismatched-tags -c libstdcpp_mismatched_tags_warning.cpp
-o /dev/null
libstdcpp_mismatched_tags_warning.cpp:42:5: warning: 'hash' defined as a struct
template here but
  previously declared as a class template [-Wmismatched-tags]
struct hashFooB
^
/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.8.1/../../../../include/c++/4.8.1/bits/stl_bvector.h:523:31:
note: 
  did you mean struct here?
templatetypename friend class hash;
  ^
libstdcpp_mismatched_tags_warning.cpp:51:5: warning: 'hash' defined as a class
template here but
  previously declared as a struct template [-Wmismatched-tags]
class hashFooA
^
/usr/lib64/gcc/x86_64-unknown-linux-gnu/4.8.1/../../../../include/c++/4.8.1/bits/functional_hash.h:58:5:
note: 
  did you mean class here?
struct hash;
^
2 warnings generated.


[Bug libstdc++/58025] Cannot use std::hash without setting off -Wmismatched-tags

2013-07-29 Thread whatmannerofburgeristhis at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58025

--- Comment #1 from Matt Arsenault whatmannerofburgeristhis at gmail dot com 
---
Created attachment 30570
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30570action=edit
Testcase


[Bug libstdc++/56627] class hash instead of struct hash

2013-07-29 Thread pinskia at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56627

Andrew Pinski pinskia at gcc dot gnu.org changed:

   What|Removed |Added

 CC||whatmannerofburgeristhis@gm
   ||ail.com

--- Comment #8 from Andrew Pinski pinskia at gcc dot gnu.org ---
*** Bug 58025 has been marked as a duplicate of this bug. ***


[Bug libstdc++/58025] Cannot use std::hash without setting off -Wmismatched-tags

2013-07-29 Thread pinskia at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58025

Andrew Pinski pinskia at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org ---
This is one of the most questionable warnings that clang added.
They should be made to consistently use struct.

No they don't have to be consistent at using struct vs class in standard C++.

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


[Bug libstdc++/56627] class hash instead of struct hash

2013-07-29 Thread whatmannerofburgeristhis at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56627

--- Comment #9 from Matt Arsenault whatmannerofburgeristhis at gmail dot com 
---
(In reply to Andrew Pinski from comment #8)
 *** Bug 58025 has been marked as a duplicate of this bug. ***

They don't have to be consistent by the standard, but the purpose of warnings
is not to strictly report deviations from the standard. Many point out likely
mistakes or inconsistencies in standard conforming code (e.g. -Wlogical-op).
This is an absolutely trivial fix.


[Bug libstdc++/56627] class hash instead of struct hash

2013-07-29 Thread pinskia at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56627

--- Comment #10 from Andrew Pinski pinskia at gcc dot gnu.org ---
(In reply to Matt Arsenault from comment #9)
 (In reply to Andrew Pinski from comment #8)
  *** Bug 58025 has been marked as a duplicate of this bug. ***
 
 They don't have to be consistent by the standard, but the purpose of
 warnings is not to strictly report deviations from the standard. Many point
 out likely mistakes or inconsistencies in standard conforming code (e.g.
 -Wlogical-op). This is an absolutely trivial fix.

Actually this warning makes less sense than -Wlogical-op due to the way struct
and class are defined.  -Wlogical-op makes sense since due to forgetting how ||
and  interact, there is no interaction here, only using struct in one case
and class in another which is valid and known what happens even without looking
up what happens.  The real reason why they added this option is due to another
compiler which implements non-standard behavior for struct and class (not
naming the company here but they also don't care about C99).