[Bug rtl-optimization/53495] [4.8 Regression] segmentation fault

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  2012-08-14 
07:43:15 UTC ---
Author: jakub
Date: Tue Aug 14 07:43:09 2012
New Revision: 190376

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190376
Log:
PR middle-end/53411
PR rtl-optimization/53495
* ira.c (ira): Move delete_trivially_dead_insns call before
find_moveable_pseudos call.

* gcc.c-torture/compile/pr53411.c: New test.
* gcc.c-torture/compile/pr53495.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr53411.c
trunk/gcc/testsuite/gcc.c-torture/compile/pr53495.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ira.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/53411] [4.8 Regression] ICE in move_unallocated_pseudos

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  2012-08-14 
07:43:14 UTC ---
Author: jakub
Date: Tue Aug 14 07:43:09 2012
New Revision: 190376

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190376
Log:
PR middle-end/53411
PR rtl-optimization/53495
* ira.c (ira): Move delete_trivially_dead_insns call before
find_moveable_pseudos call.

* gcc.c-torture/compile/pr53411.c: New test.
* gcc.c-torture/compile/pr53495.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr53411.c
trunk/gcc/testsuite/gcc.c-torture/compile/pr53495.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ira.c
trunk/gcc/testsuite/ChangeLog

[Bug target/54142] [4.8 regression] ppc64 build failure - Unrecognized opcode: `sldi' (and `srdi`)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #14 from Jakub Jelinek  2012-08-14 
07:49:11 UTC ---
Yeah, IMHO it should have added
  %{!mpower*: %(asm_default)}} \
line instead of
  %{!mpowerpc*: -mcom}} \

[Bug rtl-optimization/53495] [4.8 Regression] segmentation fault

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #5 from Jakub Jelinek  2012-08-14 
07:50:35 UTC ---
Fixed.

[Bug libstdc++/54248] Comment in standard library header talks about boost

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-08-14
 AssignedTo|unassigned at gcc dot   |redi at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1
   Severity|normal  |trivial

[Bug libstdc++/54248] Comment in standard library header talks about boost

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  2012-08-14 
08:01:44 UTC ---
> Should this comment really be talking about boost?

N.B. I don't see any actual harm in talking about Boost, seeing as the concept
checking code came straight from there.  We don't want to remove other
references such as the credit in 

// GCC Note:  based on version 1.12.0 of the Boost library.

So I'm in two minds whether to "fix" the other comment.

[Bug libstdc++/54249] New: [C++11] No ::nullptr_t in header

[daniel.kruegler at googlemail dot com]

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

 Bug #: 54249
   Summary: [C++11] No ::nullptr_t in header 
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com


gcc 4.8.0 20120729 (experimental) rejects the following code:

#include 

::nullptr_t n;

"3|error: 'nullptr_t' in namespace '::' does not name a type"

This code is supposed to be accepted, because [depr.c.headers] p2 says:

"Every C header, each of which has a name of the form name.h, behaves as if
each name placed in the standard library namespace by the corresponding cname
header is placed within the global namespace scope."

Paolo Carlini has suggested to perform this change near to existing C++11-aware
code in stddef.h:

#if (defined (__STDC_VERSION__) && __STDC_VERSION__ >= 201112L) \
  || (defined(__cplusplus) && __cplusplus >= 201103L)
#ifndef _GCC_MAX_ALIGN_T
#define _GCC_MAX_ALIGN_T
/* Type whose alignment is supported in every context and is at least
   as great as that of any standard type not using alignment
   specifiers.  */
typedef struct {
  long long __max_align_ll __attribute__((__aligned__(__alignof__(long
long;
  long double __max_align_ld __attribute__((__aligned__(__alignof__(long
double;
} max_align_t;
#endif
#endif /* C11 or C++11.  */

[I guess I have selected the wrong component. Please correct, if necessary]

[Bug libstdc++/54249] [C++11] No ::nullptr_t in header

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

   Keywords||rejects-valid

--- Comment #1 from Daniel Krügler  
2012-08-14 08:05:05 UTC ---
I should add that the code example was compiled in C++11 mode

[Bug middle-end/51233] [ipa-iterations] running multiple passes of early IPA on zlib produces more optimal code

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther  2012-08-14 
08:23:16 UTC ---
Multiple iterations may still paper over missed-optimization bugs in passes.
Using LTO to drive the iteration makes more sense (well, if iterating makes
any sense ...), as it will consider the whole program when iterating, not just
a single translation unit.

[Bug bootstrap/54138] [4.8 Regression] configuring --without-cloog but executable links against system cloog

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-08-14
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2012-08-14 
08:23:48 UTC ---
Mine.

[Bug fortran/54234] -Wconversion or -Wconversion-extra should warn for CMPLX(dp,dp)

[burnus at gcc dot gnu.org]

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

--- Comment #4 from Tobias Burnus  2012-08-14 
09:35:02 UTC ---
Forgot to mention in the initial report that this issue came up at c.l.f, cf.
http://www.rhinocerus.net/forum/lang-fortran/711699-quality-fortran-code-posted-rosettacode.html
But the issue has been risen before.

Submitted patch http://gcc.gnu.org/ml/fortran/2012-08/msg00064.html

[Bug libstdc++/54249] [C++11] No ::nullptr_t in header

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

 CC||glisse at gcc dot gnu.org

--- Comment #2 from Marc Glisse  2012-08-14 09:36:15 
UTC ---
(In reply to comment #0)
> "Every C header, each of which has a name of the form name.h, behaves as if
> each name placed in the standard library namespace by the corresponding cname
> header is placed within the global namespace scope."

Note that libstdc++ has this wrong for almost every header where the C++
standard deviates from the C standard (there is already a PR or two about that
somewhere). stddef.h is an exception, since it is provided by gcc, it can
indeed be fixed quite easily :-)

I believe someone (Howard maybe?) wanted to file a DR asking to remove this
paragraph.

[Bug libstdc++/54249] [C++11] No ::nullptr_t in header

[daniel.kruegler at googlemail dot com]

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

--- Comment #3 from Daniel Krügler  
2012-08-14 09:52:30 UTC ---
(In reply to comment #2)
> (In reply to comment #0)
> > "Every C header, each of which has a name of the form name.h, behaves as if
> > each name placed in the standard library namespace by the corresponding 
> > cname
> > header is placed within the global namespace scope."

[..] 

> I believe someone (Howard maybe?) wanted to file a DR asking to remove this
> paragraph.

I don't want to start a lengthy discussion here about the C++ Standard Library
specification, but it must be clear that removing above paragraph would have
the effect of making the effects of including any <*.h> header in a C++ program
undefined, because [depr.c.headers] is the only place in the Library
specification that defines the semantics.

[Bug fortran/54234] -Wconversion or -Wconversion-extra should warn for CMPLX(dp,dp)

[burnus at gcc dot gnu.org]

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

--- Comment #5 from Tobias Burnus  2012-08-14 
10:22:11 UTC ---
Author: burnus
Date: Tue Aug 14 10:22:06 2012
New Revision: 190378

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190378
Log:
2012-08-14  Tobias Burnus  

PR fortran/54234
* check.c (gfc_check_cmplx): Add -Wconversion warning
when converting higher-precision REAL to default-precision
CMPLX without kind= parameter.

2012-08-14  Tobias Burnus  

PR fortran/54234
* gfortran.dg/warn_conversion_4.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/warn_conversion_4.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/check.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/40881] warn for obsolescent features

[burnus at gcc dot gnu.org]

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

--- Comment #8 from Tobias Burnus  2012-08-14 
10:26:16 UTC ---
Author: burnus
Date: Tue Aug 14 10:26:11 2012
New Revision: 190379

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190379
Log:
2012-08-14  Tobias Burnus  

PR fortran/40881
* error.c (gfc_notify_std): Reset cur_error_buffer->flag flag
when the error/warning has been printed.
* gfortran.h (gfc_sl_type): Add ST_LABEL_DO_TARGET.
* match.c (gfc_match_do): Use ST_LABEL_DO_TARGET.
* parse.c (check_statement_label): Use ST_LABEL_DO_TARGET.
(parse_executable): Add obsolescence check for DATA.
* resolve.c (resolve_branch): Handle ST_LABEL_DO_TARGET.
* symbol.c (gfc_define_st_label, gfc_reference_st_label):
Add obsolescence diagnostics.
* trans-stmt.c (gfc_trans_label_assign): Handle
* ST_LABEL_DO_TARGET.

2012-08-14  Tobias Burnus  

PR fortran/40881
* gfortran.dg/data_constraints_3.f90: New.
* gfortran.dg/data_constraints_1.f90: Add dg-options ""
to disable -pedantic compilation.
* gfortran.dg/pr37243.f: Ditto.
* gfortran.dg/g77/19990826-3.f: Ditto.
* gfortran.dg/g77/20020307-1.f : Ditto.
* gfortran.dg/g77/980310-3.f: Ditto.


Added:
trunk/gcc/testsuite/gfortran.dg/data_constraints_3.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/error.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/match.c
trunk/gcc/fortran/parse.c
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/symbol.c
trunk/gcc/fortran/trans-stmt.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/data_constraints_1.f90
trunk/gcc/testsuite/gfortran.dg/g77/19990826-3.f
trunk/gcc/testsuite/gfortran.dg/g77/20020307-1.f
trunk/gcc/testsuite/gfortran.dg/g77/980310-3.f
trunk/gcc/testsuite/gfortran.dg/pr37243.f

[Bug fortran/40881] warn for obsolescent features

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #9 from Tobias Burnus  2012-08-14 
10:30:26 UTC ---
(In reply to comment #0)
>(2) Shared DO termination and termination
>on a statement other than END DO or CONTINUE
>(6) DATA statements amongst executable statements

Those two are now fixed.

I think the only missing item is the following:

>(8) Fixed form source

(I think one should consider to add some flag to silence the fixed-form
warning. At least I know a lot of code, which is in fixed form but otherwise
warning free.)

[Bug fortran/54234] -Wconversion or -Wconversion-extra should warn for CMPLX(dp,dp)

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #6 from Tobias Burnus  2012-08-14 
10:30:42 UTC ---
FIXED on the 4.8 trunk.

[Bug libstdc++/54249] [C++11] No ::nullptr_t in header

[glisse at gcc dot gnu.org]

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

--- Comment #4 from Marc Glisse  2012-08-14 10:35:56 
UTC ---
(In reply to comment #3)
> I don't want to start a lengthy discussion here about the C++ Standard Library
> specification, but it must be clear that removing above paragraph would have
> the effect of making the effects of including any <*.h> header in a C++ 
> program
> undefined, because [depr.c.headers] is the only place in the Library
> specification that defines the semantics.

Oups, "amend" instead of "remove". But you are right, this is not the place, I
just wanted to mention the existence of a debate about the .h headers.

[Bug libstdc++/54249] [C++11] No ::nullptr_t in header

[paolo.carlini at oracle dot com]

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

--- Comment #5 from Paolo Carlini  2012-08-14 
10:38:45 UTC ---
It's true however, that, as I mentioned already somewhere, in general our
implementation doesn't have control over the underlying *.h headers. Thus, it
seems mildly inconsistent to add things only to the *few* *.h headers over
which we do have control. And, indeed, apparently the Standard is in some sort
of half way state, because LWG already morally acknowledged that libstdc++-v3
is not special about this with the resolution of LWG 456, which allows the c*
headers to define entities both in the global namespace and in std:: exactly
because (right? Why otherwise?) it's now allowed for a c* to just include
whatever *.h it finds on the system.

[Bug libstdc++/54249] [C++11] No ::nullptr_t in header

[glisse at gcc dot gnu.org]

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

--- Comment #6 from Marc Glisse  2012-08-14 10:48:48 
UTC ---
(In reply to comment #5)
> It's true however, that, as I mentioned already somewhere, in general our
> implementation doesn't have control over the underlying *.h headers.

Although it does have control over potential *.h headers it ships and puts
first in the include path (as it does for complex.h and fenv.h for instance).

> Thus, it seems mildly inconsistent to add things only to the *few* *.h
> headers over which we do have control.

Grab the low-hanging fruits?

(sorry Daniel, conversations seems to have a way to start when we don't want
them to...)

[Bug libstdc++/54249] [C++11] No ::nullptr_t in header

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  2012-08-14 
10:50:40 UTC ---
(In reply to comment #5)
> seems mildly inconsistent to add things only to the *few* *.h headers over
> which we do have control.

Better to be mildly inconsistent than ship a knowingly non-conformant stddef.h

If we controlled all the headers we'd fix them, so we should fix the ones we do
control (and hope that the native libc is or will eventually be C++ friendly)

[Bug libstdc++/54249] [C++11] No ::nullptr_t in header

[paolo.carlini at oracle dot com]

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

--- Comment #8 from Paolo Carlini  2012-08-14 
10:52:38 UTC ---
Sure, grab the low-hanging fruits, like this one ;) But while we do that we
should also do an audit and establish what is missing from headers which we do
not control and at least talk to the glibc people about those. Assuming the
Standard doesn't change of course ;)

[Bug c++/50800] Internal compiler error in finish_member_declarations, possibly related to may_alias attribute

[mathias at gaunard dot com]

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

--- Comment #6 from Mathias Gaunard  2012-08-14 
10:53:07 UTC ---
I've had this happen with 4.7.1 without any may_alias involved.

Why is this bug still marked 'waiting'? Are more testcases necessary?

[Bug libstdc++/54249] [C++11] No ::nullptr_t in header

[paolo.carlini at oracle dot com]

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

--- Comment #9 from Paolo Carlini  2012-08-14 
10:56:02 UTC ---
I must also add that frankly personally I don't consider these issues so
serious: IMHO a new C++ project should immediately use the c* headers. I see
these issues mostly about legacy code.

[Bug c++/50800] Internal compiler error in finish_member_declarations, possibly related to may_alias attribute

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #7 from Paolo Carlini  2012-08-14 
10:58:40 UTC ---
Became "Waiting" with Comment #2 and then nobody updated the status, it's as
simple as that.

[Bug libstdc++/54249] [C++11] No ::nullptr_t in header

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  2012-08-14 
10:59:41 UTC ---
N.B. see also http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00375.html and
http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00192.html and the stdalign.h part
of http://gcc.gnu.org/ml/gcc-patches/2011-11/msg00893.html which currently
cause non-conformance even when including  or 

[Bug libstdc++/54249] [C++11] No ::nullptr_t in header

[daniel.kruegler at googlemail dot com]

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

--- Comment #11 from Daniel Krügler  
2012-08-14 11:01:47 UTC ---
(In reply to comment #9)
> I must also add that frankly personally I don't consider these issues so
> serious: IMHO a new C++ project should immediately use the c* headers. I see
> these issues mostly about legacy code.

Completely agreed and therefore reducing the priority. The main reason for this
bugzilla entry was not, because I need above code to be well-formed, but
because there often exists uncertainty in the wild about the interpretation of
the semantics of including the <*.h> headers. The issue came out of a lengthy
discussion that I had about this semantics on the std-discussion group.

[Bug c++/50800] Internal compiler error in finish_member_declarations, possibly related to may_alias attribute

[glisse at gcc dot gnu.org]

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

--- Comment #8 from Marc Glisse  2012-08-14 11:03:31 
UTC ---
Although if you have a testcase without may_alias, you should attach it.

[Bug libstdc++/54249] [C++11] No ::nullptr_t in header

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

   Severity|normal  |minor

[Bug tree-optimization/54240] Routine hoist_adjacent_loads does not work properly after r189366

[wschmidt at gcc dot gnu.org]

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

--- Comment #9 from William J. Schmidt  2012-08-14 
11:44:35 UTC ---
(In reply to comment #8)
> (In reply to comment #7)
> > Something else is broken, too, as the optab handlers for cmov on powerpc64
> > appear to have gone missing.  I'll get one of our back-end specialists to 
> > help
> > me understand that.
> 
> They are only enabled for TARGET_ISEL which is either TARGET_ISEL or 
> TARGET_ISEL64 which is correct as ppc64 does not have isel by default.

Right.  But the problem is the optab entries are no longer being built at all
when configured correctly.  Something seems to have changed recently to break
this.

[Bug tree-optimization/54240] Routine hoist_adjacent_loads does not work properly after r189366

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Guenther  2012-08-14 
11:47:01 UTC ---
(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #7)
> > > Something else is broken, too, as the optab handlers for cmov on powerpc64
> > > appear to have gone missing.  I'll get one of our back-end specialists to 
> > > help
> > > me understand that.
> > 
> > They are only enabled for TARGET_ISEL which is either TARGET_ISEL or 
> > TARGET_ISEL64 which is correct as ppc64 does not have isel by default.
> 
> Right.  But the problem is the optab entries are no longer being built at all
> when configured correctly.  Something seems to have changed recently to break
> this.

Richard changed optabs to a sparse representation IIRC.

[Bug c++/54250] New: Segmentation fault when decltype of a struct field is used in nested lambdas

[linesprower at gmail dot com]

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

 Bug #: 54250
   Summary: Segmentation fault when decltype of a struct field is
used in nested lambdas
Classification: Unclassified
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: linespro...@gmail.com


// this code causes segmentation fault during compilation
// compiled with: g++ -std=c++0x
// compiler version: 4.6.2
// note: uncommenting 'this' fixes the problem

struct T
{
int a;
int foo()
{
return [&]()->int {
return [&](decltype(/*this->*/a) _)->int {
return 1;
}(a);
}();
}
};

int main()
{
return 0;
}

[Bug c++/54250] Segmentation fault when decltype of a struct field is used in nested lambdas

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-08-14
 Ever Confirmed|0   |1

[Bug tree-optimization/54245] [4.8 regression] incorrect optimisation

[wschmidt at gcc dot gnu.org]

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

--- Comment #3 from William J. Schmidt  2012-08-14 
12:34:24 UTC ---
I'm putting together a for-now patch that disables the optimization when a
widening cast produces the stride.  In the long run this can be re-enabled so
long as we can retain the original cast and base the new multiply on that value
rather than doing it in the smaller type.  This is a bit subtle to get right so
I plan to defer that work until I have more time to concentrate on it.

I.e., there are two problems in this example: we did the multiply in a smaller
type and we introduced an extra cast that wasn't necessary if we were smart
enough (causing the longer sequence as Jakub noted).  The replacement would be
ok with a little re-design.

[Bug middle-end/54146] Very slow compile with attribute((flatten))

[rguenth at gcc dot gnu.org]

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

--- Comment #44 from Richard Guenther  2012-08-14 
12:38:41 UTC ---
Author: rguenth
Date: Tue Aug 14 12:38:32 2012
New Revision: 190382

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190382
Log:
2012-08-14  Richard Guenther  

PR tree-optimization/54146
* tree-ssa-pre.c (do_regular_insertion): Use a VEC
indexed by pred edge index for avail.
(do_partial_partial_insertion): Likewise.
(insert_into_preds_of_block): Adjust.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-pre.c

[Bug debug/54251] New: FAIL: g++.dg/debug/dwarf2/nested-4.C -std=gnu++[98,11] scan-assembler-times debug_types 2

[howarth at nitro dot med.uc.edu]

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

 Bug #: 54251
   Summary: FAIL: g++.dg/debug/dwarf2/nested-4.C -std=gnu++[98,11]
scan-assembler-times debug_types 2
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: howa...@nitro.med.uc.edu


Created attachment 28008
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28008
assembly from -m32 test of g++.dg/debug/dwarf2/nested-4.C -std=gnu++11

The regressions...

FAIL: g++.dg/debug/dwarf2/nested-4.C -std=gnu++98  scan-assembler-times
debug_types 2
FAIL: g++.dg/debug/dwarf2/nested-4.C -std=gnu++11  scan-assembler-times
debug_types 2

appeared sometime after r189637 but on or before r189751. 

The nested-4.s generated for the failing -std=gnu++11 test with...

/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/testsuite/g++/../../g++
-B/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/testsuite/g++/../../
/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20120813/gcc/testsuite/g++.dg/debug/dwarf2/nested-4.C
-fno-diagnostics-show-caret -nostdinc++
-I/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.0.0/i386/libstdc++-v3/include/x86_64-apple-darwin12.0.0
-I/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.0.0/i386/libstdc++-v3/include
-I/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20120813/libstdc++-v3/libsupc++
-I/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20120813/libstdc++-v3/include/backward
-I/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20120813/libstdc++-v3/testsuite/util
-fmessage-length=0 -std=gnu++11 -gdwarf-4 -fdebug-types-section -S -m32 -o
nested-4.s

is attached.

[Bug target/54142] [4.8 regression] ppc64 build failure - Unrecognized opcode: `sldi' (and `srdi`)

[gary at intrepid dot com]

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

--- Comment #15 from Gary Funck  2012-08-14 13:17:26 
UTC ---
(In reply to comment #14)
> Yeah, IMHO it should have added
>   %{!mpower*: %(asm_default)}} \
> line instead of
>   %{!mpowerpc*: -mcom}} \

That change fixed the build failure on a POWER7 system running RHEL 6.2 that I
tried it on, where it failed without the patch.

[Bug middle-end/54201] XMM constant duplicated

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

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

--- Comment #7 from Richard Guenther  2012-08-14 
13:20:26 UTC ---
The following works.

Index: gcc/varasm.c
===
--- gcc/varasm.c(revision 190381)
+++ gcc/varasm.c(working copy)
@@ -3482,8 +3482,9 @@ force_const_mem (enum machine_mode mode,
 {
   struct constant_descriptor_rtx *desc, tmp;
   struct rtx_constant_pool *pool;
+  enum machine_mode orig_mode = mode;
   char label[256];
-  rtx def, symbol;
+  rtx def, symbol, res;
   hashval_t hash;
   unsigned int align;
   void **slot;
@@ -3500,6 +3501,18 @@ force_const_mem (enum machine_mode mode,
  ? shared_constant_pool
  : crtl->varasm.pool);

+  /* Canonicalize CONST_VECTORs to the mode with the least number of
+ elements assuming that alignment requirements are not worse
+ for the original mode.  */
+  if (GET_CODE (x) == CONST_VECTOR)
+{
+  while (GET_MODE_SIZE (mode)
+== GET_MODE_SIZE (GET_MODE_WIDER_MODE (mode)))
+   mode = GET_MODE_WIDER_MODE (mode);
+  x = simplify_subreg (mode, x, orig_mode, 0);
+  gcc_assert (x != NULL_RTX);
+}
+
   /* Lookup the value in the hashtable.  */
   tmp.constant = x;
   tmp.mode = mode;
@@ -3509,7 +3522,11 @@ force_const_mem (enum machine_mode mode,

   /* If the constant was already present, return its memory.  */
   if (desc)
-return copy_rtx (desc->mem);
+{
+  res = copy_rtx (desc->mem);
+  PUT_MODE (res, orig_mode);
+  return res;
+}

   /* Otherwise, create a new descriptor.  */
   desc = ggc_alloc_constant_descriptor_rtx ();
@@ -3573,7 +3590,9 @@ force_const_mem (enum machine_mode mode,
   if (GET_CODE (x) == LABEL_REF)
 LABEL_PRESERVE_P (XEXP (x, 0)) = 1;

-  return copy_rtx (def);
+  res = copy_rtx (def);
+  PUT_MODE (res, orig_mode);
+  return res;
 }


but we still create two references to the constant pool:

test:
.LFB517:
.cfi_startproc
pand.LC0(%rip), %xmm0
pcmpeqb .LC0(%rip), %xmm0
ret

Mine again.

[Bug middle-end/54146] Very slow compile with attribute((flatten))

[glisse at gcc dot gnu.org]

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

--- Comment #45 from Marc Glisse  2012-08-14 
13:20:55 UTC ---
(In reply to comment #11)
> > Marc, do you know where the use of the
> > flatten attribute comes from in your code?
> Comes from the Eigen library, I'll talk to them about it and see if they can
> comment. They mostly deal with simple number types (double, float), so the
> behavior with heavy types might have been unnoticed.

For the record:
after doing some benchmarks, they have removed the attribute, it didn't improve
performance anymore (though it probably used to in the past).

I have to say I am extremely impressed by all the improvements you guys have
done based on this bad code (which I realize is now just a handy example of big
code with the flatten attribute high enough in the call chain). If you keep at
it, next time I might not even notice there is something wrong with the code
;-)

[Bug debug/54251] FAIL: g++.dg/debug/dwarf2/nested-4.C -std=gnu++[98,11] scan-assembler-times debug_types 2

[howarth at nitro dot med.uc.edu]

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

--- Comment #1 from Jack Howarth  2012-08-14 
13:25:47 UTC ---
Appears these failures have been present since the addition of the
g++.dg/debug/dwarf2/nested-4.C test case in...

r189676 | jason | 2012-07-19 16:01:56 -0400 (Thu, 19 Jul 2012) | 3 lines

PR debug/53235
* dwarf2out.c (generate_type_signature): Handle the case of DIE
being nested, rather than its declaration..

Note that the svn log doesn't clearly indicate that a new file,
g++.dg/debug/dwarf2/nested-4.C, was added.

[Bug target/54252] New: [Neon] Bad alignment code generated for Neon loads

[eric.batut at allegorithmic dot com]

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

 Bug #: 54252
   Summary: [Neon] Bad alignment code generated for Neon loads
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: eric.ba...@allegorithmic.com


Created attachment 28009
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28009
Small repro case

Using gcc trunk at rev 190381, compiled with the Android NDK r8b build-gcc.sh
script (so an arm-linux-androideabi target) and the command line below, the
attached repro case does not compile, and spits the following error messages:

Erics-Mac:src batut$
/Users/batut/android-ndk-r8b/toolchains/arm-linux-androideabi-4.8.0/prebuilt/darwin-x86/bin/arm-linux-androideabi-gcc
-mfloat-abi=hard -mfpu=vfp -mfpu=neon -marm -O1 -c test.c
/var/folders/nr/l7qlwr295379gn7tqyv61jx8gn/T//cc9BgV0B.s: Assembler
messages:
/var/folders/nr/l7qlwr295379gn7tqyv61jx8gn/T//cc9BgV0B.s:29: Error: bad
alignment -- `vld1.32 {d16},[r3:128]!'
/var/folders/nr/l7qlwr295379gn7tqyv61jx8gn/T//cc9BgV0B.s:32: Error: bad
alignment -- `vld1.32 {d7},[r2:128]'

The assembly code generated is:
algNEON:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
ldr r3, .L2
.LPIC0:
add r3, pc, r3
ldr r2, .L2+4
ldr r2, [r3, r2]
mov r3, r2
vld1.32 {d16}, [r3:128]!  <= Offending load
vld1.32 {d6}, [r3:64]
add r2, r2, #16
vld1.32 {d7}, [r2:128]<= Offending load
vadd.f32d16, d0, d16
vmov.f32d0, #0.0  @ v2sf
vmla.f32d0, d16, d6[0]
vmls.f32d0, d16, d6[1]
vmla.f32d0, d16, d7[0]
vmls.f32d0, d16, d7[1]
bx  lr

This does not happen at -O0.
This also happens with gcc 4.7.1.


arm-linux-androideabi-gcc -v
Using built-in specs.
COLLECT_GCC=/Users/batut/android-ndk-r8b/toolchains/arm-linux-androideabi-4.8.0/prebuilt/darwin-x86/bin/arm-linux-androideabi-gcc
COLLECT_LTO_WRAPPER=/Users/batut/android-ndk-r8b/toolchains/arm-linux-androideabi-4.8.0/prebuilt/darwin-x86/bin/../libexec/gcc/arm-linux-androideabi/4.8.0/lto-wrapper
Target: arm-linux-androideabi
Configured with:
/Users/batut/android-ndk-r8b/src/build/../gcc/gcc-4.8.0/configure
--prefix=/tmp/ndk-batut/build/toolchain/prefix --target=arm-linux-androideabi
--host=x86_64-apple-darwin --build=x86_64-apple-darwin --with-gnu-as
--with-gnu-ld --enable-languages=c,c++
--with-gmp=/tmp/ndk-batut/build/toolchain/temp-install
--with-mpfr=/tmp/ndk-batut/build/toolchain/temp-install
--with-mpc=/tmp/ndk-batut/build/toolchain/temp-install --without-ppl
--without-cloog --disable-libssp --enable-threads --disable-nls
--disable-libmudflap --disable-libgomp --disable-libstdc__-v3
--disable-sjlj-exceptions --disable-shared --disable-tls --disable-libitm
--with-float=soft --with-fpu=vfp --with-arch=armv5te --enable-target-optspace
--enable-initfini-array --disable-nls
--prefix=/tmp/ndk-batut/build/toolchain/prefix
--with-sysroot=/tmp/ndk-batut/build/toolchain/prefix/sysroot
--with-binutils-version=2.22 --with-mpfr-version=2.4.1 --with-mpc-version=0.8.1
--with-gmp-version=5.0.5 --with-gcc-version=4.8.0 --with-gdb-version=7.3.x
--disable-bootstrap --disable-libquadmath --disable-plugin --with-arch=armv5te
--program-transform-name='s&^&arm-linux-androideabi-&'
Thread model: posix
gcc version 4.8.0 20120814 (experimental) (GCC)

[Bug libstdc++/54005] Use __atomic_always_lock_free in libstdc++ is_lock_free instead of __atomic_is_lock_free

[amacleod at redhat dot com]

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

--- Comment #7 from Andrew Macleod  2012-08-14 
13:45:50 UTC ---
If NULL is passed as the second parameter, *both* functions are per type.  They
only become per-object based when an object is actually passed as the second
parameter.   libstdc++ could simply pass NULL as the second parameter rather
than the object, but it shouldn't matter since the C11/C++11 types will have
the atomic attribute set and thus will always be either lock free or not
anyway.  We don't even look at the object pointer in this case. 

Type and size are combined by the first parameter, so the meaning is now
changed to whether something {is|always} lock free for a type of SIZE with the
new atomic attribute (which is to be added soonish).  Since both C++11 and C11
will have the atomic attribute set on memory for their atomic types, this will
work fine.  

If the memory does not have the atomic attribute, then the answer can only be
resolved by using the (second parameter) pointer to the actual object. We'll
look at the type at compile time to see if the size/alignment of that type is
always good, and proceed from there to either generate instructions or call
into libatomic.

__atomic_is_lock_free() is the compiler implementation of the standard method.
This is the one which *must* be used since then answer cannot always be
provided at compile time.  The library MAY provide a lock free implementation
for a type which the compiler cannot, and thus a type may be always lock free
at runtime even if it isn't at compile time.  Thats why the query exists. 
Think of an old binary running on new hardware that provides new lock free
instructions which are utilized in a new library.  __atomic_always_lock_free()
would return the incorrect result and lock free algorithms wouldn't be able to
utilize the new instructions.

__atomic_always_lock_free() is a compiler creation to answer the question of
whether we know at compile time if a type/object is always lock free or not.
This is then resolved early in compilation so the preprocessor can resolve the
set of predefined ATOMIC_*_LOCK_FREE macros.  It is *identical* to
__atomic_is_lock_free except resolves to a FALSE at compile time rather than
turning into a call into libatomic.  

In fact, the compiler implements __atomic_is_lock_free() by (paraphrased):

  if (__atomic_always_lock_free (size, ptr))
return TRUE;
  else
emit_call_to_atomic_is_lock_free(size, ptr)



So if a code change is desired (but it isn't required), the 2nd parameter could
be passed as NULL to __atomic_is_lock_free().

[Bug c++/54253] New: [C++11] constexpr constructor crashes with polymorphic base classes

[mrks at koios dot de]

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

 Bug #: 54253
   Summary: [C++11] constexpr constructor crashes with polymorphic
base classes
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@koios.de


Created attachment 28010
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28010
preprocessed source

In _some_ constellations, g++ exits with a segmentation fault:
I could not figure out a pattern to reduce all to a common 'sourceproblem', so
here is a list of what I tried:

* One polymorphic base class:
** implicit base constructor, explicitly called (as in the example): crashes
** implicit base constructor (even with default non-static member assignments),
implicitly called: works
** explicit constexpr base constructor, explicitly called: works
** explicit constexpr base constructor, implicitly called: works

* Multiple Inhertiance, first Base is polymorphic:
nearly the same as above, except that it doesn't crash in the first case but
says
const3.cc: In constructor 'constexpr Derived::Derived()':
const3.cc:15:42: error: uninitialized member 'Derived::' in
'constexpr' constructor
const3.cc:15: confused by earlier errors, bailing out

* Multiple Inhertiance, second Base is polymorphic:
crashes always

gcc-bugs@gcc.gnu.org

[dtemirbulatov at gmail dot com]

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

 Bug #: 54254
   Summary: libiberty: demangling is broken since r167781
(http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=1677
81)
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dtemirbula...@gmail.com


Created attachment 28011
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28011
proposed fix for the issue

After the r167781 revision c++filt for
gcc/testsuite/g++.dg/other/first-global.C shows following demangling
information for "foo" constructor:

0029 t _GLOBAL__sub_I_foobar

and after fix was applied c++filt shows this output:
0029 t global constructors keyed to foobar
 t __static_initialization_and_destruction_0(int, int)
 U foo::foo()
 B foobar

[Bug c++/54253] [C++11] constexpr constructor crashes with polymorphic base classes

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-08-14
 Ever Confirmed|0   |1

--- Comment #1 from Paolo Carlini  2012-08-14 
14:20:18 UTC ---
Confirmed.

[Bug c++/54253] [C++11] constexpr constructor crashes with polymorphic base classes

[paolo.carlini at oracle dot com]

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

--- Comment #2 from Paolo Carlini  2012-08-14 
14:34:00 UTC ---
It would be nice to have 2 slightly more complex testcases too, like const3.cc
and one for your third case. Care to add something? Thanks in advance.

[Bug middle-end/54201] XMM constant duplicated

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Guenther  2012-08-14 
14:37:42 UTC ---
Does not help the 2nd testcase btw, because we do not CSE the loads:

movdqa  .LC0, %xmm3
movdqa  .LC0, %xmm2
pand%xmm3, %xmm0
pcmpeqb %xmm2, %xmm0
pand%xmm0, %xmm1
pand%xmm3, %xmm1
movdqa  %xmm1, %xmm0
pcmpeqb %xmm2, %xmm0
ret

so it's only half of the issue.

[Bug c++/54253] [C++11] constexpr constructor crashes with polymorphic base classes

[mrks at koios dot de]

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

--- Comment #3 from mrks at koios dot de 2012-08-14 14:45:31 UTC ---
Created attachment 28012
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28012
first base polymorphic

multiple inheritance, first base class is polymorphic
-> complains about uninitialized member Derived::
If Base::Base is the default ctor (no arguments), it doesn't complain but
segfaults.

[Bug c++/54253] [C++11] constexpr constructor crashes with polymorphic base classes

[paolo.carlini at oracle dot com]

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

--- Comment #4 from Paolo Carlini  2012-08-14 
14:48:45 UTC ---
Thanks!

[Bug c++/54253] [C++11] constexpr constructor crashes with polymorphic base classes

[mrks at koios dot de]

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

mrks at koios dot de changed:

   What|Removed |Added

  Attachment #28012|application/octet-stream|text/plain
  mime type||

--- Comment #4 from Paolo Carlini  2012-08-14 
14:48:45 UTC ---
Thanks!

[Bug c++/54253] [C++11] constexpr constructor crashes with polymorphic base classes

[mrks at koios dot de]

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

mrks at koios dot de changed:

   What|Removed |Added

  Attachment #28012|application/octet-stream|text/plain
  mime type||

--- Comment #5 from mrks at koios dot de 2012-08-14 14:51:02 UTC ---
Created attachment 28013
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28013
second base polymorphic

multiple inheritance, second base class is polymorphic
-> crashes if the first base class has a member (int x)

[Bug target/54255] New: FAIL: gcc.target/i386/asm-dialect-1.c (test for excess errors) fails on x86_64/i686 darwin

[howarth at nitro dot med.uc.edu]

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

 Bug #: 54255
   Summary: FAIL: gcc.target/i386/asm-dialect-1.c (test for excess
errors) fails on x86_64/i686 darwin
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: howa...@nitro.med.uc.edu


The test gcc.target/i386/asm-dialect-1.c fails on [x86_64,i686]-apple-darwin*
as...

Executing on host: /sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/
/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20120813/gcc/testsuite/gcc.target/i386/asm-dialect-1.c
 -fno-diagnostics-show-caret   -masm=intel -S  -m32 -o asm-dialect-1.s   
(timeout = 300)
/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20120813/gcc/testsuite/gcc.target/i386/asm-dialect-1.c:1:0:
error: -masm=intel not supported in this configuration^M
compiler exited with status 1
output is:
/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20120813/gcc/testsuite/gcc.target/i386/asm-dialect-1.c:1:0:
error: -masm=intel not supported in this configuration^M

FAIL: gcc.target/i386/asm-dialect-1.c (test for excess errors)
Excess errors:
/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20120813/gcc/testsuite/gcc.target/i386/asm-dialect-1.c:1:0:
error: -masm=intel not supported in this configuration

for both -m32 and -m64.

[Bug target/54212] ARM: invalid instruction (vdupeq.32) generated

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

   Keywords||wrong-code
   Target Milestone|--- |4.7.2

[Bug debug/54256] New: IPA-SRA debug info issues

[jakub at gcc dot gnu.org]

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

 Bug #: 54256
   Summary: IPA-SRA debug info issues
Classification: Unclassified
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
CC: jamb...@gcc.gnu.org, jan.kratoch...@redhat.com


struct A
{
#ifdef PAD
  void *c;
#endif
  struct A *a;
  void *b;
};

typedef int FN (struct A *);
extern void *v;
struct A *fn (void);

void
foo (FN *y, int z)
{
  struct A *x = fn ();
  baz (x, y, z);
}

static int
bar (FN *x, struct A *y, int z, int w)
{
  if (v)
undef (8, v);
  (*x) (y->a);
}

int
baz (struct A *x, FN *y, int z)
{
  bar (y, x, z, 0);
  return 0;
}

at -g -O2 doesn't provide debug info for the foo y parameter, eventhough it
actually is passed.  The reason for that seems to be that IPA-SRA? decides to
not pass struct A *, but actually struct A ** instead (address of the a field
of a, i.e. essentially the exactly same pointer), we generate
DW_OP_GNU_parameter_ref but in the end at the call site the argument isn't
available (it is only available in the called function).
Not sure why IPA-SRA does this change (and with -DPAD it is actually a code
pessimization), supposedly because it hopes for scalarization opportunities in
the caller which at the end don't come though.

I've tried:
struct A { void *c; struct A *a; void *b; };
typedef int FN (struct A *);
extern void *v;
struct A *fn (void);

void
foo (FN *y, int z)
{
  struct A x = { fn (), 0 };
  baz (&x, y, z);
}

static int
bar (FN *x, struct A *y, int z, int w)
{
  if (v)
undef (8, v);
  (*x) (y->a);
}

int
baz (struct A *x, FN *y, int z)
{
  bar (y, x, z, 0);
  return 0;
}

but even that isn't scalarized in the caller, so I wonder when it is actually
useful this way.

[Bug target/54255] FAIL: gcc.target/i386/asm-dialect-1.c (test for excess errors) fails on x86_64/i686 darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #1 from Jack Howarth  2012-08-14 
15:00:04 UTC ---
Issue appeared with the introduction of the new test case at...

r189854 | rth | 2012-07-25 12:01:17 -0400 (Wed, 25 Jul 2012) | 8 lines

Split out do_assembler_dialects.

* final.c [ASSEMBLER_DIALECT](do_assembler_dialects): New
function to implement assembler dialects.
(output_asm_insn): Use do_assembler_dialects.
(asm_fprintf): Likewise.

* gcc.target/i386/asm-dialect-1.c: New test case.

[Bug target/54257] New: gcc.target/i386/pr53249.c failure at -m64 on x86_64-apple-darwin

[howarth at nitro dot med.uc.edu]

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

 Bug #: 54257
   Summary: gcc.target/i386/pr53249.c failure at -m64 on
x86_64-apple-darwin
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: howa...@nitro.med.uc.edu


The new test case gcc.target/i386/pr53249.c introduced in...

Author: hjl
Date: Wed May  9 13:32:13 2012
New Revision: 187331

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187331
Log:
Add a test for PR middle-end/53249

PR middle-end/53249
* gcc.target/i386/pr53249.c: New.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr53249.c
Modified:
trunk/gcc/testsuite/ChangeLog

fails at -m64 on x86_64-apple-darwin12 with...

Executing on host: /sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/
/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20120813/gcc/testsuite/gcc.target/i386/pr53249.c
 -fno-diagnostics-show-caret   -O2 -mx32 -ftls-model=initial-exec
-maddress-mode=short -S  -m64 -o pr53249.s(timeout = 300)
/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20120813/gcc/testsuite/gcc.target/i386/pr53249.c:1:0:
error: address mode 'short' not supported in the 64 bit mode^M
compiler exited with status 1
output is:
/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20120813/gcc/testsuite/gcc.target/i386/pr53249.c:1:0:
error: address mode 'short' not supported in the 64 bit mode^M

FAIL: gcc.target/i386/pr53249.c (test for excess errors)

[Bug target/54257] gcc.target/i386/pr53249.c failure at -m64 on x86_64-apple-darwin

[hjl.tools at gmail dot com]

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

--- Comment #1 from H.J. Lu  2012-08-14 15:57:34 
UTC ---
The problem is -m64 overrides -mx32.

[Bug c++/54053] [4.7 Regression] g++ accepts (invalid?) ""0; expression.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  2012-08-14 
15:57:34 UTC ---
Fixed on the trunk with http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186909

[Bug c++/54258] New: Wrong size of a named union.

[karolmdv at gazeta dot pl]

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

 Bug #: 54258
   Summary: Wrong size of a named union.
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: karol...@gazeta.pl


Created attachment 28014
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28014
Compiler's output.

I tried to find it in the current list of open bugs and have seen many similar
union-specific ones.

The problem was detected when using std::aligned_storage, when noticed that
sizeof(std::aligned_storage) yields 1 for any "x".

The following code demonstrates the problem.



int main()
{
// If "type" is removed (making the union anonymous),
// it works and returns 18.
struct my_aligned_storage
{
union type
{
unsigned char __data[18];
};
};
return sizeof(my_aligned_storage); // Returns 1.
}



It has been compiled with (GCC 4.7.0):

g++ -v -save-temps -o bug.exe -std=gnu++11 bug.cpp

Full compiler's output is in the attachment.

[Bug libstdc++/54259] New: Regression in move construction for std::pair

[oleg at smolsky dot net]

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

 Bug #: 54259
   Summary: Regression in move construction for std::pair
Classification: Unclassified
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: o...@smolsky.net


I've just attempted to move my project from g++ v4.6.3 to v4.7.1 and hit an
issue when using move semantics.

I have a templated class LockGuard that is move-constructable and not copyable.
This is accomplished (in the conventional C++98 way) by making the copy
constructor "private". The code creates an instance of std::pair<...,
LockGuard<...>> and returns it to the caller.

The code compiles and runs on g++ 4.6.3 and VS2010/sp1, yet g++ 4.7.1 emits a
bunch of errors (below). The point, as far as I can tell, is that it wants to
call the copy constructor which is private. I can fix the issue by explicitly
removing the copy constructor:

LockGuard(const LockGuard &) = delete;

Could someone clarify if this behavior is conforming to the standard? Normally
I would not worry about such a thing, but VS2010 does not understand "= delete"
specs and the behavior appears to be a breaking change w.r.t. copy constructor
invocations... (well, breaking is too strong a word as move constructors and
rvalue references are new, but I am sure you see what I mean)

[Bug libstdc++/54259] Regression in move construction for std::pair

[oleg at smolsky dot net]

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

--- Comment #1 from oleg at smolsky dot net 2012-08-14 16:27:35 UTC ---
Created attachment 28015
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28015
minimal expressive test case

Compiles correctly in g++ 4.6.3, 4.8/Trunk and VS2010/sp1.

[Bug c++/54258] Wrong size of a named union.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #1 from Jonathan Wakely  2012-08-14 
16:38:32 UTC ---
my_aligned_storage is an empty type, i.e. has no members, so has size 1.

my_aligned_storage::type is not a member, it's a declaration of a type.

If you remove the name 'type' then the anon union is a member, not a type
declaration.

[Bug target/54142] [4.8 regression] ppc64 build failure - Unrecognized opcode: `sldi' (and `srdi`)

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||segher at gcc dot gnu.org
 AssignedTo|unassigned at gcc dot   |segher at gcc dot gnu.org
   |gnu.org |

--- Comment #16 from Segher Boessenkool  2012-08-14 
16:44:09 UTC ---
Mine.

[Bug fortran/47586] [F03] allocatable components: deep copy missing

[mikael at gcc dot gnu.org]

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

--- Comment #1 from Mikael Morin  2012-08-14 
16:46:07 UTC ---
Author: mikael
Date: Tue Aug 14 16:45:55 2012
New Revision: 190394

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190394
Log:
fortran/
PR fortran/47586
* trans-expr.c (expr_is_variable): Handle regular, procedure pointer,
and typebound functions returning a data pointer.

testsuite/
PR fortran/47586
* gfortran.dg/typebound_proc_20.f90: Enable runtime test.
* gfortran.dg/typebound_proc_27.f03: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/typebound_proc_27.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-expr.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/typebound_proc_20.f90

[Bug libstdc++/54259] Regression in move construction for std::pair

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Target|debian on amd64 |
   Host|debian on amd64 |

--- Comment #2 from Jonathan Wakely  2012-08-14 
16:51:56 UTC ---
It looks like a problem caused by 4.7 not implementing access control for
SFINAE, which is fixed on trunk. 

You can workaround it by removing your private copy constructor and inheriting
from a type like boost::noncopyable:

struct noncopyable
{
noncopyable() { }
private:
noncopyable(const noncopyable&);
};


template 
class LockGuard : noncopyable
{
  // ...
private:
  // LockGuard(const LockGuard &);
};

Now LockGuard's copy constructor will be deleted, and works well with SFINAE.

[Bug fortran/47586] [F03] allocatable components: deep copy missing

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||mikael at gcc dot gnu.org
 Resolution||FIXED

--- Comment #2 from Mikael Morin  2012-08-14 
16:52:33 UTC ---
Fixed for 4.8.0.

[Bug bootstrap/54260] New: GCC 4.7.1 fails to build.

[Fetrovsky at gmail dot com]

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

 Bug #: 54260
   Summary: GCC 4.7.1 fails to build.
Classification: Unclassified
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: fetrov...@gmail.com


I don't know where to report this problem --- apologies if this is the wrong
place.  GCC 4.7.1 is not building for me.  I ran configure without any
arguments and this is what I get when I do make:

mkdir -p -- x86_64-unknown-linux-gnu/libgcc
Checking multilib configuration for libgcc...
Configuring stage 1 in x86_64-unknown-linux-gnu/libgcc
configure: creating cache ./config.cache
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking for --enable-version-specific-runtime-libs... no
checking for a BSD-compatible install... /usr/bin/install -c
checking for gawk... gawk
checking for x86_64-unknown-linux-gnu-ar... ar
checking for x86_64-unknown-linux-gnu-lipo... lipo
checking for x86_64-unknown-linux-gnu-nm...
/home/Feto/sw/gcc/host-x86_64-unknown-linux-gnu/gcc/nm
checking for x86_64-unknown-linux-gnu-ranlib... ranlib
checking for x86_64-unknown-linux-gnu-strip... strip
checking whether ln -s works... yes
checking for x86_64-unknown-linux-gnu-gcc...
/home/Feto/sw/gcc/host-x86_64-unknown-linux-gnu/gcc/xgcc
-B/home/Feto/sw/gcc/host-x86_64-unknown-linux-gnu/gcc/
-B/usr/local/x86_64-unknown-linux-gnu/bin/
-B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem
/usr/local/x86_64-unknown-linux-gnu/include -isystem
/usr/local/x86_64-unknown-linux-gnu/sys-include
checking for suffix of object files... configure: error: in
`/home/Feto/sw/gcc/x86_64-unknown-linux-gnu/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
make[2]: *** [configure-stage1-target-libgcc] Error 1
make[2]: Leaving directory `/home/Feto/sw/gcc'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/home/Feto/sw/gcc'
make: *** [all] Error 2
[Feto@fet gcc]$


Thank you!


- Daniel

[Bug target/54142] [4.8 regression] ppc64 build failure - Unrecognized opcode: `sldi' (and `srdi`)

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 CC||dje at gcc dot gnu.org

--- Comment #17 from David Edelsohn  2012-08-14 
17:09:57 UTC ---
Jakub's fix looks right.

[Bug bootstrap/54260] GCC 4.7.1 fails to build.

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  2012-08-14 
17:14:09 UTC ---
Can you attach x86_64-unknown-linux-gnu/libgcc/config.log ?

[Bug bootstrap/54260] GCC 4.7.1 fails to build.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2012-08-14
 Ever Confirmed|0   |1

--- Comment #2 from Jonathan Wakely  2012-08-14 
17:16:58 UTC ---
Did you read http://gcc.gnu.org/wiki/FAQ#configure_suffix ?

http://gcc.gnu.org/wiki/InstallingGCC explains how to avoid that issue

[Bug rtl-optimization/53533] [4.7/4.8 regression] vectorization causes loop unrolling test slowdown as measured by Adobe's C++Benchmark

[matt at use dot net]

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

--- Comment #19 from Matt Hargett  2012-08-14 17:25:40 UTC 
---
Does this mean there will be a fix for this regression committed for 4.7.2? If
there's a patch I can test ahead of time, please let me know. Thanks!

[Bug middle-end/51233] [ipa-iterations] running multiple passes of early IPA on zlib produces more optimal code

[matt at use dot net]

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

--- Comment #4 from Matt Hargett  2012-08-14 17:43:30 UTC 
---
I agree it's more appropriate in LTO, but can still provide measurable benefit
for template-heavy C++ applications where lots of implementation bodies are in
header files by necessity.

With regard to zlib performance improving with multiple iterations, is there a
multiple iterations patch against trunk you'd like me to retest on this
specific testcase? We never did an RTL/tree dump in the 4.6/4.7 case for each
iteration to see if the improvements could have been caught in a single
iteration.

[Bug target/50751] SH Target: Displacement addressing does not work for QImode and HImode

[olegendo at gcc dot gnu.org]

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

--- Comment #31 from Oleg Endo  2012-08-14 
17:54:35 UTC ---
Author: olegendo
Date: Tue Aug 14 17:54:28 2012
New Revision: 190395

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190395
Log:
PR target/50751
* config/sh/constraints.md (Sra): New constraint.
* config/sh/predicates.md (simple_mem_operand,
displacement_mem_operand, zero_extend_movu_operand): New predicates.
(zero_extend_operand): Check zero_extend_movu_operand for SH2A.
* config/sh/sh.md (*zero_extendqisi2_disp_mem,
*zero_extendhisi2_disp_mem): Add new insns and two new related
peephole2 patterns.

PR target/50751
* gcc.target/sh/pr50751-8.c: New.


Added:
trunk/gcc/testsuite/gcc.target/sh/pr50751-8.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/constraints.md
trunk/gcc/config/sh/predicates.md
trunk/gcc/config/sh/sh.md
trunk/gcc/testsuite/ChangeLog

[Bug target/52933] SH Target: Use div0s for integer sign comparisons

[olegendo at gcc dot gnu.org]

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

--- Comment #2 from Oleg Endo  2012-08-14 17:59:11 
UTC ---
Author: olegendo
Date: Tue Aug 14 17:59:03 2012
New Revision: 190396

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190396
Log:
PR target/52933
* config/sh/sh.md (cmp_div0s_0, cmp_div0s_1, *cmp_div0s_0,
*cmp_div0s_1, *cbranch_div0s, *movsicc_div0s): New insns.
* config/sh/sh.c (sh_rtx_costs): Handle div0s patterns.

PR target/52933
* gcc.target/sh/pr52933-1.c: New.
* gcc.target/sh/pr52933-2.c: New.


Added:
trunk/gcc/testsuite/gcc.target/sh/pr52933-1.c
trunk/gcc/testsuite/gcc.target/sh/pr52933-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/sh.c
trunk/gcc/config/sh/sh.md
trunk/gcc/testsuite/ChangeLog

[Bug c/54037] Warn pointer to signed integer cast for ilp32

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

  Attachment #27836|0   |1
is obsolete||

--- Comment #5 from H.J. Lu  2012-08-14 18:04:35 
UTC ---
Created attachment 28016
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28016
A patch to add -Wpointer-to-signed-int-cast

This patch only warns when ptr_mode != word_mode.

[Bug middle-end/53518] [4.8 regression] testsuite_abi_check.cc doesn't compile

[jojelino at gmail dot com]

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

--- Comment #4 from gee  2012-08-14 18:49:53 UTC ---
cppcheck fails to compile because of this bug.

cli/cmdlineparser.o: In function `~basic_istream':
/usr/include/c++/4.8.0/istream:106: undefined reference to `construction vtable
for std::basic_istream
>-in-std::basic_ifstream >'
/usr/include/c++/4.8.0/istream:106: undefined reference to `construction vtable
for std::basic_istream
>-in-std::basic_ifstream >'
/usr/include/c++/4.8.0/istream:106: undefined reference to `construction vtable
for std::basic_istream
>-in-std::basic_ifstream >'

it says that 'construction vtable for std::basic_istream >-in-std::basic_ifstream >'
cannot be found, but it exists. 

$ nm -sn /lib/libstdc++.a |c++filt |grep "construction vtable for
std::basic_istream >-in-std::basic_ifstream >"
construction vtable for std::basic_istream
>-in-std::basic_ifstream > in fstream-inst.o
 R construction vtable for std::basic_istream >-in-std::basic_ifstream >

[Bug middle-end/54261] New: reverse sync/atomic operators when only sync_compare_and_swap_optab libfuncs implemented

[hp at gcc dot gnu.org]

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

 Bug #: 54261
   Summary: reverse sync/atomic operators when only
sync_compare_and_swap_optab libfuncs implemented
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: h...@gcc.gnu.org
Target: cris*-*-linux-gnu


If a target implements atomics by only setting sync_compare_and_swap_optab
libfuncs (see cris.c:cris_init_libfuncs), a path less travelled is used, on
which a bug lies, causing sync/atomic operators to be implemented with the
reverse operator, e.g. minus instead of plus.  See test-case to be added and
patch to be posted and referenced.

[Bug web/52239] Upgrade GCC Bugzilla to 4.2

[LpSolit at netscape dot net]

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

--- Comment #3 from Frédéric Buclin  2012-08-14 
18:58:00 UTC ---
Another reason why I cannot simply download the 4.2 tarball and install it till
bzr is available: Bugzilla 4.2 requires MySQL 5.0.15, but the version available
is 4.1.22, a way too old version of MySQL.

[Bug web/53632] [bugzilla] Bugzilla being very slow to submit changes, sending duplicate emails

[LpSolit at netscape dot net]

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

--- Comment #10 from Frédéric Buclin  2012-08-14 
19:01:12 UTC ---
(In reply to comment #9)
> I don't know if anything was changed, but the speed seems OK now

It seems very slow to me. It took a while to send 3 bugmails only.

[Bug tree-optimization/54240] Routine hoist_adjacent_loads does not work properly after r189366

[wschmidt at gcc dot gnu.org]

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

--- Comment #11 from William J. Schmidt  
2012-08-14 19:48:40 UTC ---
Well.  It turns out that cmov_optab was a red herring.  Apparently no ports are
generating this, and actually movcc_optab is what's being used instead.  My
guess is that cmov_optab should probably be removed as unused.  Thanks to Mike
for helping me sort that out.  Patch (with testcase) coming soon.

[Bug middle-end/54261] reverse sync/atomic operators when only sync_compare_and_swap_optab libfuncs implemented

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-08-14
 AssignedTo|unassigned at gcc dot   |hp at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #1 from Hans-Peter Nilsson  2012-08-14 
19:55:02 UTC ---
Created attachment 28017
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28017
test-case suitable as gcc.dg/torture/pr54261-1.c

The lack of non-cas_int test-cases except in the libstdc++ testsuite helped
this trivial bug survive a test-run.

[Bug fortran/54262] New: LOC shouldn't use copy-in/copy-out

[burnus at gcc dot gnu.org]

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

 Bug #: 54262
   Summary: LOC shouldn't use copy-in/copy-out
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org


With CONTIGUOUS, the following program assigns the address of x->data to the C
pointer. However, without CONTIGUOUS one gets a copy-in/copy-out.

Expected: Also without CONTIGUOUS, one obtains the x->data address – and no
array is packed.

The expected result is in line with F2008/TS29113's handling of C_LOC.

Implementation: It might be possible to generate an interface for LOC where the
dummy is of "type(*), dimension(..)" – that could be sufficient, but for
scalars it requires a wrapper.


Test case:

subroutine foo(x, p)
  use iso_c_binding
  type(*), target, CONTIGUOUS :: x(..) ! or x(:)
  type(c_ptr) :: p
  p = transfer (loc(x), p)
end subroutine foo

[Bug libstdc++/54259] Regression in move construction for std::pair

[oleg at smolsky dot net]

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

--- Comment #3 from oleg at smolsky dot net 2012-08-14 21:09:03 UTC ---
Thank you Jonathan. The workaround works on all three compilers and I can move
forward.

[Bug fortran/54263] New: C_F_POINTER wrongly accepts a SHAPE= for scalar pointers

[burnus at gcc dot gnu.org]

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

 Bug #: 54263
   Summary: C_F_POINTER wrongly accepts a SHAPE= for scalar
pointers
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org


C_F_POINTER wrongly accepts a SHAPE= for scalar pointers

use iso_c_binding
type(c_ptr) :: cp
integer, pointer :: p
call c_f_pointer (cp, p, shape=[2])
end

[Bug fortran/54243] [OOP] ICE (segfault) in gfc_type_compatible for invalid BT_CLASS

[janus at gcc dot gnu.org]

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

--- Comment #3 from janus at gcc dot gnu.org 2012-08-14 21:27:25 UTC ---
The patch in comment 2 regresses on typebound_operator_11.f90, which can be
fixed by the following:

Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c(revision 190186)
+++ gcc/fortran/resolve.c(working copy)
@@ -237,6 +237,7 @@ resolve_procedure_interface (gfc_symbol *sym)
   sym->attr.always_explicit = ifc->attr.always_explicit;
   sym->attr.ext_attr |= ifc->attr.ext_attr;
   sym->attr.is_bind_c = ifc->attr.is_bind_c;
+  sym->attr.class_ok = ifc->attr.class_ok;
   /* Copy array spec.  */
   sym->as = gfc_copy_array_spec (ifc->as);
   if (sym->as)
@@ -11982,6 +11986,7 @@ resolve_fl_derived0 (gfc_symbol *sym)
   c->attr.recursive = ifc->attr.recursive;
   c->attr.always_explicit = ifc->attr.always_explicit;
   c->attr.ext_attr |= ifc->attr.ext_attr;
+  c->attr.class_ok = ifc->attr.class_ok;
   /* Replace symbols in array spec.  */
   if (c->as)
 {

[Bug middle-end/52650] [4.8 Regression] FAIL: gcc.dg/torture/pr51106-2.c * (internal compiler error)

[sje at gcc dot gnu.org]

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

Steve Ellcey  changed:

   What|Removed |Added

 CC||sje at gcc dot gnu.org

--- Comment #10 from Steve Ellcey  2012-08-14 21:31:44 
UTC ---
Is anything happening with this bug?  I see it on mips as well.

[Bug c++/54264] New: internal compiler error on sample program from the C++ standard

[meng at g dot clemson.edu]

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

 Bug #: 54264
   Summary: internal compiler error on sample program from the C++
standard
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@g.clemson.edu


g++-4.7.0 gave me "Internal compiler error" for the program below, which is
slightly adapted from the C++11 standard 7.1.6.2/5 sample program.

template  struct A { ~A () = delete; };
template  auto h () -> A;
template  auto i (T) -> T;
template  auto f (T) -> decltype(i(h()));

int main ()
{
 f(0);
 return 0;
}

The standard requires an error for the declaration of f because A::~A is
implicitly used and it is deleted. g++-4.7.0 captures the error but then
stopped working.

[Bug c++/54264] internal compiler error on sample program from the C++ standard

[meng at g dot clemson.edu]

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

--- Comment #1 from meng at g dot clemson.edu 2012-08-14 21:44:31 UTC ---
here is my command line:
~/gcc/4.7.0/bin/c++ -std=c++11 -Wall -O3 t1.cc

and its output:
t1.cc: In substitution of ‘template decltype (i(h())) f(T) [with T
= int]’:
t1.cc:8:5:   required from here
t1.cc:4:28: error: use of deleted function ‘A<  >::~A()
[with  = int]’
t1.cc:1:32: error: declared here
t1.cc:4:28: error: use of deleted function ‘A<  >::~A()
[with  = int]’
t1.cc:1:32: error: declared here
t1.cc:4:28: error: use of deleted function ‘A<  >::~A()
[with  = int]’
t1.cc:1:32: error: declared here
t1.cc:4:28: error: use of deleted function ‘A<  >::~A()
[with  = int]’
t1.cc:1:32: error: declared here
t1.cc: In function ‘int main()’:
t1.cc:8:5: error: use of deleted function ‘A<  >::~A()
[with  = int]’
t1.cc:1:32: error: declared here
‘
Internal compiler error: Error reporting routines re-entered.
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

here is my compiler version info:
~/gcc/4.7.0/bin/c++ -v
Reading specs from /home/meng/gcc/4.7.0/lib/gcc/i686-pc-linux-gnu/4.7.0/specs
COLLECT_GCC=/home/meng/gcc/4.7.0/bin/c++
COLLECT_LTO_WRAPPER=/home/meng/gcc/4.7.0/libexec/gcc/i686-pc-linux-gnu/4.7.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ./configure --prefix=/home/meng/gcc/4.7.0/
--enable-languages=c,c++
Thread model: posix
gcc version 4.7.0 (GCC)

[Bug libstdc++/54005] Use __atomic_always_lock_free in libstdc++ is_lock_free instead of __atomic_is_lock_free

[hp at gcc dot gnu.org]

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

--- Comment #8 from Hans-Peter Nilsson  2012-08-14 
22:16:00 UTC ---
(In reply to comment #7)
> ,,,
> In fact, the compiler implements __atomic_is_lock_free() by (paraphrased):

ITYM *will* implement. :)  Right now we still have PR54004.

> So if a code change is desired (but it isn't required), the 2nd parameter 
> could
> be passed as NULL to __atomic_is_lock_free().

Since a lot of code changes will happen in this area soonish (hopefully), I
guess it's no actual use quoting current documentation or implementation.  I'll
leave it to you and bkoz to fight out whether you want his change reverted
before that happens.

[Bug libstdc++/54005] Use __atomic_always_lock_free in libstdc++ is_lock_free instead of __atomic_is_lock_free

[amacleod at redhat dot com]

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

--- Comment #9 from Andrew Macleod  2012-08-14 
22:44:53 UTC ---
Actually, that's the way __atomic_is_lock_free()  has always been implemented
(even in 4.7).  

The change is simply wrong and needs to be reverted.  __atomic_is_lock_free()
*must* call the library routine of the same name if the compiler can't generate
the lock free sequence.  That's the way the 2 routines were designed to
inter-operate. The current code introduces an new upgrade path bug, so its
fixing a problem in the wrong place and introducing another.

And yes, 54004 is legitimate and separate from this issue. Fixing that by
giving targets a say in what atomic alignment is will resolve this one without
any changes.

[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode

[chip at pobox dot com]

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

--- Comment #31 from Chip Salzenberg  2012-08-14 
22:46:12 UTC ---
I've tested the attached patch, and I find that it succeeds in preventing the
current missed optimizations in structs passed by value from affecting 128-bit
structs.

IOW: Works for me.  Thanks!

[Bug middle-end/28831] [4.6/4.7/4.8 Regression] Aggregate copy not elided when using a return value as a pass-by-value parameter

[chip at pobox dot com]

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

--- Comment #17 from Chip Salzenberg  2012-08-14 
22:50:01 UTC ---
The patch posted in Bug 20020 prevents missed optimization for 128-bit
structures on x86_64.  So this bug does seem to be all about the BLKmode.

[Bug target/54142] [4.8 regression] ppc64 build failure - Unrecognized opcode: `sldi' (and `srdi`)

[segher at gcc dot gnu.org]

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

--- Comment #18 from Segher Boessenkool  2012-08-14 
22:54:35 UTC ---
Right, but

  %{!mpowerpc*: %(asm_default)}} \

instead, since the -mpower option is no more.

I didn't even pick the wrong condition branch there: the original
code does not do the right thing for "gcc -mno-power", which is
effectively always on after my patch.  But let's not always do
the wrong thing; patch coming up (it needs changing in a few places
more).

[Bug other/54265] New: Documentation of "preferred attribute syntax for Types" contradicts examples in info.

[rwhite at pobox dot com]

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

 Bug #: 54265
   Summary: Documentation of "preferred attribute syntax for
Types" contradicts examples in info.
Classification: Unclassified
   Product: gcc
   Version: 4.6.3
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rwh...@pobox.com


In the GCC info section 6.37 paragraph 4 reads:

[quote]For an enum, struct or union type, you may specify attributes either
between the enum, struct or union tag and the name of the type, or just
past the closing curly brace of the _definition_.  The former syntax is
preferred.[/quote]

This implies that the preferred syntax is:

struct __attribute__ ((aligned (8))) S { short f[3]; };

Unfortunately all of the examples in the remaining documentation are formatted
as the the allegedly inferior:

struct S { short f[3]; } __attribute__ ((aligned (8)));

So either the word "former" in paragraph 4 should be "latter" or all the
examples are given in the non-preferred syntax, which is confusing.

[Bug c/54266] New: atomic / sync preprocessor macros inconsistent with (does not reflect) functionality of atomic / sync support.

[hp at gcc dot gnu.org]

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

 Bug #: 54266
   Summary: atomic / sync preprocessor macros inconsistent with
(does not reflect) functionality of atomic / sync
support.
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: h...@gcc.gnu.org
CC: amacl...@redhat.com


The preprocessor macros defined in c-family/c-cppbuiltin.c:cpp_atomic_builtins
don't correctly reflect whether atomic builtins work (can be linked and
executed). They just check for presence of certain MD patterns, while library
calls are just as valid.

This PR is similar to PR54006, but just intended to track the issue of
usability of the preprocessor macros.  For example, the cas_int target; the
check_effective_target_cas_int function doesn't catch targets implementing
atomics by calling library functions because __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2
and __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 are unusable for this purpose.  See also
the test-case in PR54261.

[Bug middle-end/54261] reverse sync/atomic operators when only sync_compare_and_swap_optab libfuncs implemented

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode

[chip at pobox dot com]

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

--- Comment #32 from Chip Salzenberg  2012-08-14 
23:09:01 UTC ---
More good data: this patch reduces the size of libstdc++.so by .5%

$ size usr/lib/libstdc++.so.6.0.17 /usr/lib/libstdc++.so.6.0.17
   textdata bss dec hex filename
 949608   36200   85088 1070896  105730 usr/lib/libstdc++.so.6.0.17
 955484   36200   85088 1076772  106e24 /usr/lib/libstdc++.so.6.0.17

[Bug bootstrap/54128] GCC does not bootstrap on little endian mips due to mis-compare on tree-data-ref.c

[sje at gcc dot gnu.org]

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

--- Comment #7 from Steve Ellcey  2012-08-14 23:35:03 
UTC ---
The cutdown test case only shows the difference in code generation (between
"-O2" and "-O2 -g") in big-endian mode.  The original larger test case had
differences in both big-endian and little-endian modes.

[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode

[hjl.tools at gmail dot com]

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

--- Comment #33 from H.J. Lu  2012-08-14 23:43:24 
UTC ---
We must make sure that

---
union S160
{
  long double a;
};
extern union S160 check160 (void);
extern void checkx160 (union S160);
void
test160 (void)
{
  checkx160 (check160 ());
}
---

compiles.

[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode

[gary at intrepid dot com]

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

--- Comment #34 from Gary Funck  2012-08-14 23:55:57 
UTC ---
(In reply to comment #33)
> We must make sure that
> 
> ---
> union S160
> {
>   long double a;
> };
> extern union S160 check160 (void);
> extern void checkx160 (union S160);
> void
> test160 (void)
> {
>   checkx160 (check160 ());
> }
> ---
> 
> compiles.

I agree.  I looked into this briefly, but was unsure how to fix the issue.

What I can do is incorporate whatever fix is agreed upon into the patch, and
add this as an explicit test case.  Even though it is slightly duplicative, it
will be clearer what's going on if a regression occurs later on.