[Bug middle-end/53510] [4.8 Regression] OOM while compile some code

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-05-29
 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #6 from Jakub Jelinek  2012-05-29 
07:30:28 UTC ---
Created attachment 27515
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27515
gcc48-pr53510.patch

Ugh, that leaks like crazy.  Not only it forgets to free buffers, but also
doubles the size of the allocation (which is fine) but only adds 2 to the
expected allocated block length, so it allocates twice as much for every 2
bytes beyond 200 characters on a line.

[Bug middle-end/38474] slow compilation at -O0 due to expand's temp slot goo

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #53 from Joost VandeVondele  
2012-05-29 07:45:36 UTC ---
For the original testcase I have for trunk (gcc version 4.8.0 20120516
(experimental) [trunk revision 187595] (GCC)) very reasonable times (1min) at
-O0, but pretty slow (20min) at -O2. At -O2, all time goes to 'alias stmt
walking  : 826.02' in the latter case. Time reports below:

gfortran -ftime-report -ffree-line-length-512 -g -c testcase.f90

Execution times (seconds)
 phase setup :   0.03 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 0%) wall 
   243 kB ( 0%) ggc
 phase parsing   :   3.59 ( 6%) usr   0.05 ( 5%) sys   3.64 ( 6%) wall 
 47592 kB ( 7%) ggc
 phase cgraph:  60.02 (94%) usr   0.90 (95%) sys  60.94 (94%) wall 
649547 kB (93%) ggc
 phase generate  :  60.03 (94%) usr   0.90 (95%) sys  60.95 (94%) wall 
649948 kB (93%) ggc
 garbage collection  :   1.04 ( 2%) usr   0.00 ( 0%) sys   1.04 ( 2%) wall 
 0 kB ( 0%) ggc
 callgraph construction  :   0.18 ( 0%) usr   0.01 ( 1%) sys   0.20 ( 0%) wall 
 15909 kB ( 2%) ggc
 callgraph optimization  :   0.02 ( 0%) usr   0.00 ( 0%) sys   0.04 ( 0%) wall 
   201 kB ( 0%) ggc
 cfg construction:   0.08 ( 0%) usr   0.00 ( 0%) sys   0.08 ( 0%) wall 
 7 kB ( 0%) ggc
 cfg cleanup :   0.03 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 0%) wall 
 0 kB ( 0%) ggc
 CFG verifier:   1.16 ( 2%) usr   0.00 ( 0%) sys   1.18 ( 2%) wall 
 0 kB ( 0%) ggc
 trivially dead code :   0.34 ( 1%) usr   0.00 ( 0%) sys   0.35 ( 1%) wall 
 0 kB ( 0%) ggc
 df scan insns   :   1.00 ( 2%) usr   0.25 (26%) sys   1.23 ( 2%) wall 
11 kB ( 0%) ggc
 df live regs:   0.46 ( 1%) usr   0.00 ( 0%) sys   0.49 ( 1%) wall 
 0 kB ( 0%) ggc
 df reg dead/unused notes:   0.45 ( 1%) usr   0.01 ( 1%) sys   0.47 ( 1%) wall 
 19416 kB ( 3%) ggc
 register information:   0.20 ( 0%) usr   0.01 ( 1%) sys   0.19 ( 0%) wall 
 0 kB ( 0%) ggc
 alias analysis  :   0.15 ( 0%) usr   0.00 ( 0%) sys   0.17 ( 0%) wall 
  8336 kB ( 1%) ggc
 rebuild jump labels :   0.22 ( 0%) usr   0.00 ( 0%) sys   0.21 ( 0%) wall 
 0 kB ( 0%) ggc
 parser (global) :   3.59 ( 6%) usr   0.05 ( 5%) sys   3.64 ( 6%) wall 
 47587 kB ( 7%) ggc
 inline heuristics   :   0.07 ( 0%) usr   0.00 ( 0%) sys   0.07 ( 0%) wall 
54 kB ( 0%) ggc
 tree gimplify   :   0.48 ( 1%) usr   0.01 ( 1%) sys   0.49 ( 1%) wall 
 26304 kB ( 4%) ggc
 tree eh :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall 
39 kB ( 0%) ggc
 tree CFG construction   :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall 
   190 kB ( 0%) ggc
 tree find ref. vars :   0.03 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 0%) wall 
  3263 kB ( 0%) ggc
 tree PHI insertion  :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall 
 0 kB ( 0%) ggc
 tree SSA rewrite:   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall 
43 kB ( 0%) ggc
 tree SSA other  :   0.04 ( 0%) usr   0.02 ( 2%) sys   0.01 ( 0%) wall 
18 kB ( 0%) ggc
 tree operand scan   :   0.01 ( 0%) usr   0.01 ( 1%) sys   0.06 ( 0%) wall 
   118 kB ( 0%) ggc
 tree SSA verifier   :   0.10 ( 0%) usr   0.00 ( 0%) sys   0.08 ( 0%) wall 
 0 kB ( 0%) ggc
 tree STMT verifier  :   0.58 ( 1%) usr   0.06 ( 6%) sys   0.62 ( 1%) wall 
 0 kB ( 0%) ggc
 callgraph verifier  :   0.28 ( 0%) usr   0.00 ( 0%) sys   0.29 ( 0%) wall 
 0 kB ( 0%) ggc
 out of ssa  :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall 
 0 kB ( 0%) ggc
 expand vars :  21.72 (34%) usr   0.02 ( 2%) sys  21.74 (34%) wall 
 10086 kB ( 1%) ggc
 expand  :   6.18 (10%) usr   0.15 (16%) sys   6.31 (10%) wall 
251886 kB (36%) ggc
 post expand cleanups:   0.14 ( 0%) usr   0.00 ( 0%) sys   0.13 ( 0%) wall 
  1744 kB ( 0%) ggc
 integrated RA   :  10.75 (17%) usr   0.16 (17%) sys  10.87 (17%) wall 
128826 kB (18%) ggc
 reload  :   5.72 ( 9%) usr   0.15 (16%) sys   5.92 ( 9%) wall 
123587 kB (18%) ggc
 thread pro- & epilogue  :   2.51 ( 4%) usr   0.00 ( 0%) sys   2.50 ( 4%) wall 
   198 kB ( 0%) ggc
 machine dep reorg   :   0.04 ( 0%) usr   0.00 ( 0%) sys   0.04 ( 0%) wall 
 0 kB ( 0%) ggc
 final   :   2.61 ( 4%) usr   0.04 ( 4%) sys   2.65 ( 4%) wall 
  7227 kB ( 1%) ggc
 symout  :   0.02 ( 0%) usr   0.00 ( 0%) sys   0.04 ( 0%) wall 
  4914 kB ( 1%) ggc
 rest of compilation :   2.36 ( 4%) usr   0.00 ( 0%) sys   2.35 ( 4%) wall 
 47578 kB ( 7%) ggc
 verify RTL sharing  :   1.02 ( 2%) usr   0.00 ( 0%) sys   1.04 ( 2%) wall 
 0 kB ( 0%) ggc
 TOTAL :  63.65 0.9564.62
697784 kB


gfortran -ftime-report -ffree-line-length-512 -O2 -g -c testcase.f90

Execution times (seconds)
 phase setup :   0.02 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 0%) wall 
   243 kB ( 0%) ggc
 phase parsin

[Bug middle-end/53510] [4.8 Regression] OOM while compile some code

[manu at gcc dot gnu.org]

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

--- Comment #7 from Manuel López-Ibáñez  2012-05-29 
07:53:37 UTC ---
(In reply to comment #6)
> Created attachment 27515 [details]
> gcc48-pr53510.patch
> 
> Ugh, that leaks like crazy.  Not only it forgets to free buffers, but also
> doubles the size of the allocation (which is fine) but only adds 2 to the
> expected allocated block length, so it allocates twice as much for every 2
> bytes beyond 200 characters on a line.

You are right. It is very weird what that code is doing. FWIW, I copied the
function from gcov.c:read_line, so I guess that code has the same bug.

[Bug c++/25137] Warning "missing braces around initializer" causing problems with tr1::array

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #21 from Manuel López-Ibáñez  2012-05-29 
08:03:07 UTC ---
Hi Paolo (cc. Jason),

for options that enable other options only in specific languages, it would be
good to use the new LangEnabledBy in the .opt files. (For example, this will
make -Wno-missing-braces -Wall work as expected).

[Bug libstdc++/53515] New: InputIterator version std::advance needs positive check

[faithandbrave at gmail dot com]

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

 Bug #: 53515
   Summary: InputIterator version std::advance needs positive
check
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: faithandbr...@gmail.com


C++11 specification 24.4.4

template 
void advance(InputIterator& i, Distance n);

Requires: n shall be negative only for bidirectional and random access
iterators.

==
libstdc++ std::advance is nothing positive check.
I think InputIterator version std::advance needs positive check.


before code:

template
inline void
__advance(_InputIterator& __i, _Distance __n, input_iterator_tag)
{
  // concept requirements
  __glibcxx_function_requires(_InputIteratorConcept<_InputIterator>)
  while (__n--)
++__i;
}


after code (add assert):

template
inline void
__advance(_InputIterator& __i, _Distance __n, input_iterator_tag)
{
  // concept requirements
  __glibcxx_function_requires(_InputIteratorConcept<_InputIterator>)
  _GLIBCXX_DEBUG_ASSERT(__n >= 0);
  while (__n--)
++__i;
}

[Bug c++/16166] -Weffc++ finer granularity

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  2012-05-29 
08:34:32 UTC ---
(In reply to comment #4)
> * Item 11: Define a copy constructor and an assignment operator for classes
> with dynamically allocated memory.
> 
> -Wcopy-resource-class

IMHO this warning should just go. With deleted copy ctor/assign and move
ctor/assign there are even more places where a hard and fast rule isn't useful.

> * Item 12: Prefer initialization to assignment in constructors.
> 
> -Wassignment-in-constructor

If I ever get my -Wmeminit patch working properly it would provide this.

> * Item 14: Make destructors virtual in base classes.
> 
> Already covered by -Wnon-virtual-dtor

And the more useful -Wdelete-non-virtual-dtor

> In summary, you could simulate exactly the behavior of -Weffc++ by turning on
> each of these warnings individually, or you could turn on -Weffc++ and
> selectively turn off a few warnings that you don't want.

Yep, that would be much better

[Bug c++/25137] Warning "missing braces around initializer" causing problems with tr1::array

[paolo.carlini at oracle dot com]

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

--- Comment #22 from Paolo Carlini  2012-05-29 
09:05:51 UTC ---
Oops, sorry, I think at some point I wondered if something was in order but
then forgot. If you can tell me the right syntax, I can add it, must be quite
simple, right?

[Bug c/53502] [4.8 Regression] Bootstrap broken with --disable-build-poststage1-with-cxx

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #7 from Tobias Burnus  2012-05-29 
09:24:01 UTC ---
I have no comment regarding the C/C++ warning, but I think on the gfortran side
the following patch makes sense.

--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -3266,3 +3266,3 @@ match_attr_spec (void)
   /* Modifiers that can exist in a type statement.  */
-  typedef enum
+  enum
   { GFC_DECL_BEGIN = 0,


I was thinking of the following patch, but it won't work as g++ doesn't like
the "d++" in
  for (d = GFC_DECL_BEGIN; d != GFC_DECL_END; d++)
seen[d] = 0;
(One could introduce another variable for the zero initialization, but the
patch above should be sufficient.)

--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -3282,3 +3282,3 @@ match_attr_spec (void)
   int seen[NUM_DECL];
-  unsigned int d;
+  decl_types d;
   const char *attr;

[Bug c++/25137] Warning "missing braces around initializer" causing problems with tr1::array

[manu at gcc dot gnu.org]

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

--- Comment #23 from Manuel López-Ibáñez  2012-05-29 
09:22:05 UTC ---
It is explained here
http://gcc.gnu.org/onlinedocs/gccint/Option-properties.html#Option-properties

A patch like the following should work (plus removing the special handling in
c-opts.c)

Index: c.opt
===
--- c.opt(revision 187628)
+++ c.opt(working copy)
@@ -463,7 +463,7 @@
 Warn about suspicious declarations of \"main\"

 Wmissing-braces
-C ObjC C++ ObjC++ Var(warn_missing_braces) Warning
+C ObjC C++ ObjC++ Var(warn_missing_braces) Warning LangEnabledBy(C ObjC, Wall)
 Warn about possibly missing braces around initializers


There is also EnabledBy, which is unconditional. The plan is to convert
sub-options to use this infrastructure. There is also some functionality
missing:

* An option enabled only if two options are combined. (-Wextra && -Wunused
enable -Wunused-parameter).

* An option enabled by some arbitrary condition.

And some options are problematic because they currently have bugs: warn_format
is 0 by default but the value of -Wformat in the gcc_opts structure is -1, thus
calling warning(OPT_Wformat) without checking warn_format means enabled by
default. Some tests expect such diagnostics to be enabled by default. :-(

[Bug c++/52892] Function pointer loses constexpr qualification

[adrien at guinet dot me]

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

Adrien Guinet  changed:

   What|Removed |Added

 CC||adrien at guinet dot me

--- Comment #2 from Adrien Guinet  2012-05-29 09:26:29 
UTC ---
Hello everyone,

Im ay have an issue related to this issue, if that can help:

#include 

struct A
{
void f(int i) { std::cout << "f " << i << " " << _i << std::endl; }
void f2(int i) { std::cout << "f2 " << i << " " << _i << std::endl; }
int _i; 
};

template 
struct class_f
{
typedef F f_type;
static constexpr f_type f_value = f;
static constexpr f_type get() { return f; }
};


int main()
{
typedef class_f ff_t;

// This does not compile
class_f ff; 

// This does not compile either
class_f(&A::f)> ff2;

// This does
class_f ff_works;
}

It looks like using a function pointer that has been "instantiated" as an
"f_type" makes the compilation fails. here is the output of g++-4.7 with the
first "failing" tests :

$ g++-4.7 -std=c++0x ftempl.cpp
ftempl.cpp: In function ‘int main()’:
ftempl.cpp:24:37: error: could not convert template argument ‘class_f::f_value’ to ‘void (A::*)(int)’
ftempl.cpp:24:41: error: invalid type in declaration before ‘;’ token


$ g++-4.7 --version
g++-4.7 (Debian 4.7.0-8) 4.7.0

[Bug libstdc++/53515] InputIterator version std::advance needs negative check

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-05-29
 Ever Confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #1 from Jonathan Wakely  2012-05-29 
09:27:34 UTC ---
Good idea, thanks

[Bug preprocessor/53229] Fix diagnostics location when pasting tokens

[dodji at gcc dot gnu.org]

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

--- Comment #2 from Dodji Seketeli  2012-05-29 
09:36:34 UTC ---
Author: dodji
Date: Tue May 29 09:36:29 2012
New Revision: 187945

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187945
Log:
PR preprocessor/53229 - Fix diagnostics location when pasting tokens

As stated in the audit trail of this problem report, consider this
test case:

$ cat test.c
 1struct x {
 2  int i;
 3};
 4struct x x;
 5
 6#define TEST(X) x.##X
 7
 8void foo (void)
 9{
10  TEST(i) = 0;
11}
$

$ cc1 -quiet test.c
test.c: In function 'foo':
test.c:10:1: error: pasting "." and "i" does not give a valid preprocessing
token
   TEST(i) = 0;
 ^
$

So, when pasting tokens, the error diagnostic uses the global and
imprecise input_location variable, leading to an imprecise output.

To properly fix this, I think libcpp should keep the token of the
pasting operator '##', instead of representing it with flag on the LHS
operand's token.  That way, it could use its location.  Doing that
would be quite intrusive though.  So this patch just uses the location
of the LHS of the pasting operator, for now.  It's IMHO better than
the current situation.

The patch makes paste_tokens take a location parameter that is used in
the diagnostics.  This change can still be useful later when we can
use the location of the pasting operator, because paste_tokens will
just be passed the new, more precise location.

Incidentally, it appeared that when getting tokens from within
preprocessor directives (like what is done in gcc.dg/cpp/paste12.c),
with -ftrack-macro-expansion disabled, the location of the expansion
point of macros was being lost because
cpp_reader::set_invocation_location wasn't being properly set.  It's
because when cpp_get_token_1 calls enter_macro_context, there is a
little period of time between the beginning of that later function and
when the macro is really pushed (and thus when the macro is really
expanded) where we wrongly consider that we are not expanding the
macro because macro_of_context is still NULL.  In that period of time,
in the occurrences of indirect recursive calls to cpp_get_token_1,
this later function wrongly sets cpp_reader::invocation_location
because cpp_reader::set_invocation_location is not being properly set.

To avoid that confusion the patch does away with
cpp_reader::set_invocation_location and introduces a new flag
cpp_reader::about_to_expand_macro_p that is set in the small time
interval exposed earlier.  A new in_macro_expansion_p is introduced as
well, so that cpp_get_token_1 can now accurately detect when we are in
the process of expanding a macro, and thus correctly collect the
location of the expansion point.

People seem to like screenshots.

Thus, after the patch, we now have:

$ cc1 -quiet test.c
test.c: In function 'foo':
test.c:6:18: error: pasting "." and "i" does not give a valid preprocessing
token
 #define TEST(X) x.##X
  ^
test.c:10:3: note: in expansion of macro 'TEST'
   TEST(i) = 0;
   ^
$

Bootstrapped and tested on x86_64-unknown-linux-gnu against trunk.

libcpp/

PR preprocessor/53229
* internal.h (cpp_reader::set_invocation_location): Remove.
(cpp_reader::about_to_expand_macro_p): New member flag.
* directives.c (do_pragma):  Remove Kludge as
pfile->set_invocation_location is no more.
* macro.c (cpp_get_token_1): Do away with the use of
cpp_reader::set_invocation_location.  Just collect the macro
expansion point when we are about to expand the top-most macro.
Do not override cpp_reader::about_to_expand_macro_p.
This fixes gcc.dg/cpp/paste12.c by making get_token_no_padding
properly handle locations of expansion points.
(cpp_get_token_with_location): Adjust, as
cpp_reader::set_invocation_location is no more.
(paste_tokens): Take a virtual location parameter for
the LHS of the pasting operator.  Use it in diagnostics.  Update
comments.
(paste_all_tokens): Tighten the assert.  Propagate the location of
the expansion point when no virtual locations are available.
Pass the virtual location to paste_tokens.
(in_macro_expansion_p): New static function.
(enter_macro_context): Set the cpp_reader::about_to_expand_macro_p
flag until we really start expanding the macro.

gcc/testsuite/

PR preprocessor/53229
* gcc.dg/cpp/paste6.c: Force to run without
-ftrack-macro-expansion.
* gcc.dg/cpp/paste8.c: Likewise.
* gcc.dg/cpp/paste8-2.c: New test, like paste8.c but run with
-ftrack-macro-expansion.
* gcc.dg/cpp/paste12.c: Force to run without
-ftrack-macro-expansion.
* gcc.dg/cpp/paste12-2.c: New test, like paste12.c but run with
-ftrack-macro-expansion.
* gcc.dg/cpp/paste13.c: Likewise.
* gcc.dg/cpp/paste14.c: Likewise.
* gcc.dg/cpp/paste14-2.c: New test, like pas

[Bug c++/25137] Warning "missing braces around initializer" causing problems with tr1::array

[paolo.carlini at oracle dot com]

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

--- Comment #24 from Paolo Carlini  2012-05-29 
09:41:01 UTC ---
Thanks. I'm going to test the patchlet momentarily, I think it qualifies as
obvious.

[Bug bootstrap/53459] ../../work/libcpp/lex.c:593:18: error: typedef 'check_count' locally defined but not used

[dodji at gcc dot gnu.org]

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

--- Comment #6 from Dodji Seketeli  2012-05-29 
09:42:44 UTC ---
Author: dodji
Date: Tue May 29 09:42:39 2012
New Revision: 187947

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187947
Log:
PR bootstrap/53459 - unused local typedef when building on altivec

PR bootstrap/53459
* lex.c (search_line_fast): Avoid unused local typedefs to simulate
a static assertion.

Modified:
trunk/libcpp/ChangeLog
trunk/libcpp/lex.c

[Bug bootstrap/53459] ../../work/libcpp/lex.c:593:18: error: typedef 'check_count' locally defined but not used

[dodji at gcc dot gnu.org]

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

Dodji Seketeli  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #7 from Dodji Seketeli  2012-05-29 
09:49:42 UTC ---
Hopefully properly fixed for 4.8 now.

[Bug c++/16166] -Weffc++ finer granularity

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #6 from Manuel López-Ibáñez  2012-05-29 
09:58:08 UTC ---
(In reply to comment #4)
> I would recommend against naming each warning -Weffc++[n], but rather, give a
> more descriptive name. My suggestion is to create a few warnings, so that
> -Weffc++ would map to the following set of warnings (with their current
> description for reference and my suggested name):
> 

David, if you wish to implement such a patch (or, even better, series of
patches, one for each new option), the only changes needed are:

* In the particular warning () calls, replace OPT_Weffc__ with the appropriate
OPT_W option.

* In c-family/c.opt, add a new entry for the new Wfoo option and use
EnabledBy(Weffc++)

* In doc/invoke.texi, document the new options.

* Bootstrap+regression test and submit to gcc-patches.

Profit!

[Bug preprocessor/53229] Fix diagnostics location when pasting tokens

[dodji at gcc dot gnu.org]

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

Dodji Seketeli  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #3 from Dodji Seketeli  2012-05-29 
10:03:03 UTC ---
Fixed in trunk (4.8)

[Bug preprocessor/53469] #pragma GCC diagnostic works, but using _Pragma doesn't for -Wunused-local-typedefs

[dodji at gcc dot gnu.org]

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

--- Comment #1 from Dodji Seketeli  2012-05-29 
10:20:52 UTC ---
I candidate fix was proposed to
http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01899.html

[Bug middle-end/51389] GCC uses up to 75GB of virtual memory

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

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

--- Comment #7 from Richard Guenther  2012-05-29 
10:25:24 UTC ---
Fixed.

[Bug c++/53500] [4.7 Regression] internal compiler error in joust()

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED
   Target Milestone|--- |4.7.1
 Ever Confirmed|1   |0

[Bug middle-end/53496] gcc segfaults when compiling glic

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2012-05-29
 Ever Confirmed|0   |1

[Bug c++/53494] [4.7/4.8 Regression] ICE with invalid initializer list

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.1

[Bug c++/53492] [g++ (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1 ] internal compiler error: in retrieve_specialization, at cp/pt.c:985

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code

--- Comment #2 from Richard Guenther  2012-05-29 
10:29:17 UTC ---
3.4.6 rejects it with

t.C: In function `int main()':
t.C:24: error: no matching function for call to `foo::quux::quux()'
t.C:14: note: candidates are: foo::quux::quux(const
foo::quux&)
t.C:15: note: foo::quux::quux(foo::bat*) [with T =
int]

[Bug c++/53491] [4.7 Regression] ICE in build_target_expr_with_type, at cp/tree.c:587

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.1

[Bug c++/53486] ICE compiling code using lambdas as default argument

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed|2012-05-25 00:00:00 |2012-05-29
Version|unknown |4.7.0
 Ever Confirmed|0   |1

--- Comment #7 from Richard Guenther  2012-05-29 
10:31:24 UTC ---
Confirmed.

[Bug c++/52725] error: "capture of non-variable" for new-expression incorrectly parsed as lambda-expression

[steffen_moeller at gmx dot de]

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

--- Comment #4 from Steffen Möller  2012-05-29 
10:33:36 UTC ---
Hello, this took me a while.

It seems like the problem is in (or in the interaction with) nvcc, the NVidia
compiler. For that you program for the graphics card and the host processor at
the same time. The .cu files indicate such files that are not meant to be seen
by the regular compiler at a first sight. It then generates preprocessed files
for gcc to digest.

$ rm -f t.cu_OpenMMCuda_generated.cpp; /usr/bin/nvcc t.cu -cuda -o
t.cu_OpenMMCuda_generated.cpp && g++ -c t.cu_OpenMMCuda_generated.cpp
t.cu: In member function ‘void CUDAStream::Allocate()’:
t.cu:12:27: error: capture of non-variable ‘CUDAStream::_subStreams’ 
t.cu:4:10: note: ‘unsigned int CUDAStream::_subStreams’ declared here

$ cat t.cu
template 
struct CUDAStream
{
unsigned int_subStreams;
T** _pSysStream;
void Allocate();
};

template 
void CUDAStream::Allocate()
{
_pSysStream =   new T*[_subStreams];
}


The NVCC-generated code now has the ()s again:

# 9 "t.cu"
template< class T> void
# 10 "t.cu"
CUDAStream< T> ::Allocate()
# 11 "t.cu"
{
# 12 "t.cu"
(_pSysStream) = (new (T *[_subStreams]));
# 13 "t.cu"
}

4.6 crunges it, 4.7 does not. Sounds like we should prepare an email to NVidia.
Anybody with any direct contacts?

Thanks

Steffen

[Bug debug/53470] [4.8 Regression] ICE when linking with -g in splice_child_die, at dwarf2out.c:4264

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

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

--- Comment #6 from Richard Guenther  2012-05-29 
10:33:56 UTC ---
I'll have a look.

[Bug middle-end/53496] gcc segfaults when compiling glib

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

Summary|gcc segfaults when  |gcc segfaults when
   |compiling glic  |compiling glib

--- Comment #4 from Jonathan Wakely  2012-05-29 
10:46:44 UTC ---
http://gcc.gnu.org/bugs/

[Bug c++/53491] [4.7 Regression] ICE in build_target_expr_with_type, at cp/tree.c:587

[paolo at gcc dot gnu.org]

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

--- Comment #7 from paolo at gcc dot gnu.org  
2012-05-29 10:56:57 UTC ---
Author: paolo
Date: Tue May 29 10:56:53 2012
New Revision: 187950

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187950
Log:
/cp
2012-05-29  Paolo Carlini  

PR c++/53491
* tree.c (stabilize_expr): Handle exp of void type.

/testsuite
2012-05-29  Paolo Carlini  

PR c++/53491
* g++.dg/parse/crash60.C: New.

Added:
branches/gcc-4_7-branch/gcc/testsuite/g++.dg/parse/crash60.C
Modified:
branches/gcc-4_7-branch/gcc/cp/ChangeLog
branches/gcc-4_7-branch/gcc/cp/tree.c
branches/gcc-4_7-branch/gcc/testsuite/ChangeLog

[Bug c++/53491] [4.7 Regression] ICE in build_target_expr_with_type, at cp/tree.c:587

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #7 from paolo at gcc dot gnu.org  
2012-05-29 10:56:57 UTC ---
Author: paolo
Date: Tue May 29 10:56:53 2012
New Revision: 187950

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187950
Log:
/cp
2012-05-29  Paolo Carlini  

PR c++/53491
* tree.c (stabilize_expr): Handle exp of void type.

/testsuite
2012-05-29  Paolo Carlini  

PR c++/53491
* g++.dg/parse/crash60.C: New.

Added:
branches/gcc-4_7-branch/gcc/testsuite/g++.dg/parse/crash60.C
Modified:
branches/gcc-4_7-branch/gcc/cp/ChangeLog
branches/gcc-4_7-branch/gcc/cp/tree.c
branches/gcc-4_7-branch/gcc/testsuite/ChangeLog

--- Comment #8 from Paolo Carlini  2012-05-29 
10:57:38 UTC ---
Fixed mainline and 4.7.1.

[Bug c++/53491] [4.7 Regression] ICE in build_target_expr_with_type, at cp/tree.c:587

[paolo at gcc dot gnu.org]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #8 from Paolo Carlini  2012-05-29 
10:57:38 UTC ---
Fixed mainline and 4.7.1.

[Bug c++/52725] error: "capture of non-variable" for new-expression incorrectly parsed as lambda-expression

[steffen_moeller at gmx dot de]

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

--- Comment #5 from Steffen Möller  2012-05-29 
11:31:04 UTC ---
$ nvcc --version
nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2012 NVIDIA Corporation
Built on Thu_Apr__5_00:24:31_PDT_2012
Cuda compilation tools, release 4.2, V0.2.1221

as shipping with Debian unstable in package version 4.2.9-1.

[Bug middle-end/53510] [4.8 Regression] OOM while compile some code

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  2012-05-29 
11:34:42 UTC ---
Author: jakub
Date: Tue May 29 11:34:38 2012
New Revision: 187952

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187952
Log:
PR middle-end/53510
* input.c (read_line): Use XRESIZEVEC instead of XNEWVEC
to avoid leaking memory.  No need to handle memory allocation
failure.  Double string_len on each reallocation instead of
adding 2.
* gcov.c (read_line): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gcov.c
trunk/gcc/input.c

[Bug c++/45492] G++ permits function-to-data pointer conversions with __extension__ in functions, but not function templates

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC|gcc-bugs at gcc dot gnu.org |
 Resolution||DUPLICATE

--- Comment #2 from Paolo Carlini  2012-05-29 
11:52:52 UTC ---
It's the same issue.

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

[Bug c++/21385] __extension__ lost inside template

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||j...@red-bean.com

--- Comment #5 from Paolo Carlini  2012-05-29 
11:52:52 UTC ---
*** Bug 45492 has been marked as a duplicate of this bug. ***

[Bug c++/52725] [4.7/4.8 Regression] error: "capture of non-variable" for new-expression incorrectly parsed as lambda-expression

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-05-29
  Known to work||4.1.2, 4.4.3, 4.6.3
Summary|error: "capture of  |[4.7/4.8 Regression] error:
   |non-variable" for   |"capture of non-variable"
   |new-expression incorrectly  |for new-expression
   |parsed as lambda-expression |incorrectly parsed as
   ||lambda-expression
 Ever Confirmed|0   |1

--- Comment #6 from Jonathan Wakely  2012-05-29 
11:55:06 UTC ---
Anything to do with the cuda compiler is irrelevant here, this report is for a
GCC bug not for other programs, even if they generate code that triggers the
bug.

Anyway, I'm confirming this, here's a reduced testcase that produces a slightly
different eror, due to using a global instead of a data member:

struct A { };

extern int n;

void f()
{
A** p = new (A*[n]);
}

Accepted by 4.6 and earlier, rejected by 4.7 and later

$ g++-4.7 -c t.cc
t.cc: In function 'void f()':
t.cc:7:21: warning: capture of variable 'n' with non-automatic storage duration
[enabled by default]
t.cc:3:5: note: 'int n' declared here


N.B. 4.5 says

t.cc: In function ‘void f()’:
t.cc:7:19: warning: lambda expressions only available with -std=c++0x or
-std=gnu++0x

But that was fixed for 4.6

[Bug c++/45606] [4.5 Regression] match a method prototyped a typedef alias with the original type (using stdlib)

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC|gcc-bugs at gcc dot gnu.org |
 Resolution||FIXED

--- Comment #11 from Paolo Carlini  2012-05-29 
11:55:27 UTC ---
I guess we can close this one.

[Bug c++/47398] [4.5 Regression] tree check: accessed elt 10 of tree_vec with 9 elts in tsubst, at cp/pt.c:10500

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #8 from Paolo Carlini  2012-05-29 
11:58:27 UTC ---
And this one.

[Bug c++/52725] [4.7/4.8 Regression] error: "capture of non-variable" for new-expression incorrectly parsed as lambda-expression

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  2012-05-29 
11:59:26 UTC ---
(In reply to comment #6)
> N.B. 4.5 says
> 
> t.cc: In function ‘void f()’:
> t.cc:7:19: warning: lambda expressions only available with -std=c++0x or
> -std=gnu++0x
> 
> But that was fixed for 4.6

I tested 4.5.2, that should be fixed in 4.5.3, see Bug 46159 and its dup Bug
47651

[Bug c++/46836] reporting locations for names in std namespace could be improved

[paolo.carlini at oracle dot com]

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

--- Comment #4 from Paolo Carlini  2012-05-29 
12:02:58 UTC ---
Jon, is this a duplicate? A couple of weeks ago I saw a patch related to this
issue but I don't see it mentioned here?!?

[Bug middle-end/53476] [4.8 Regression] FAIL: gcc.dg/attr-weakref-1.c

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot   |hubicka at gcc dot gnu.org
   |gnu.org |

--- Comment #4 from Jan Hubicka  2012-05-29 
12:05:55 UTC ---
Mine.

[Bug c++/53475] [4.8 Regression] Section type conflict errors in libstdc++ testsuite

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-05-29
 AssignedTo|unassigned at gcc dot   |hubicka at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #6 from Jan Hubicka  2012-05-29 
12:07:13 UTC ---
apparently mine ;)

[Bug c++/46836] reporting locations for names in std namespace could be improved

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  2012-05-29 
12:08:24 UTC ---
For PR 52974 Manu made a huge improvement, so that we only get
/some/ugly/path/the/user/didn't/include instead of
/some/ugly/path/the/user/can't/even/parse/../../../didn't/include, but this PR
suggests printing the name of a standard header instead of a physical path.

This would make it harder to go and look at the relevant code, so there should
be an option to display the physical path, but most users don't need to look in
standard headers and can't read the uglified code anyway

[Bug c++/46836] reporting locations for names in std namespace could be improved

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  2012-05-29 
12:14:18 UTC ---
(In reply to comment #2)
> #pragma GCC canonical_header [header-name] [identifier]

I don't think we even need to do it per-identifier.

If each standard header started with:

#pragma GCC canonical_header push [header-name]

and ended with:

#pragma GCC canonical_header pop

then we'd always know which header we're "in" when an error occurs, even for
nested headers (e.g.  includes ) and helper files that are
included from many places (e.g. bits/stl_tree.h gets included by both  and
)

[Bug middle-end/38474] slow compilation at -O0 due to expand's temp slot goo

[matz at gcc dot gnu.org]

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

--- Comment #54 from Michael Matz  2012-05-29 12:47:29 
UTC ---
Yes, only the expand vars problem is attacked by my patch.  The alias walking
seems to come from an IPA analysis via ipa_compute_jump_functions.

detect_type_change uses the walker from all call statements, and that's
used by compute_known_type_jump_func, from compute_scalar_jump_functions,
from ipa_compute_jump_functions_for_edge.  And the latter is called for each
callee.  The yukawa_gn_full function has very many calls, so this
seems to make out for an quadratic problem.

[Bug middle-end/38474] slow compilation at -O0 due to expand's temp slot goo

[matz at gcc dot gnu.org]

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

--- Comment #55 from Michael Matz  2012-05-29 13:08:52 
UTC ---
FWIW the node->callees list in yukawa_gn_full has 25076 entries.

[Bug tree-optimization/53516] New: Vectorization and memset recognition miscompile bitfield stores

[rguenth at gcc dot gnu.org]

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

 Bug #: 53516
   Summary: Vectorization and memset recognition miscompile
bitfield stores
Classification: Unclassified
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: rgue...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org


The following is miscompiled at -O3.

extern void abort (void);

struct Foo
{
  char a : 1;
  char b : 7;
};

struct Foo x[256];
int y[256];

void __attribute__((noinline,noclone)) bar (int n)
{
  int i;
  for (i = 0; i < n; ++i)
{
  x[i].a = 0;
  y[i] = 3;
}
}

int main()
{
  x[5].b = 7;
  bar (256);
  if (x[5].b != 7)
abort ();
  return 0;
}

[Bug target/47333] [4.6 regression] g++.dg/lto/20091219 FAILs on Solaris 2 with SUN as

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

Version|4.6.0   |4.8.0

--- Comment #27 from Rainer Orth  2012-05-29 13:13:28 
UTC ---
Between 20120518 and 20120524, this failure has reoccured, doubtless due to the
recent rewrite of the aliasing code.  Jan, could you please have a look?

Thanks.

  Rainer

[Bug tree-optimization/53516] [4.6/4.7/4.8 Regression] Vectorization and memset recognition miscompile bitfield stores

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-05-29
  Known to work||4.5.3
   Target Milestone|--- |4.6.4
Summary|Vectorization and memset|[4.6/4.7/4.8 Regression]
   |recognition miscompile  |Vectorization and memset
   |bitfield stores |recognition miscompile
   ||bitfield stores
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2012-05-29 
13:13:42 UTC ---
4.5 works.

[Bug middle-end/53476] [4.8 Regression] FAIL: gcc.dg/attr-weakref-1.c

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-05-29
 CC||ro at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #5 from Rainer Orth  2012-05-29 13:19:32 UTC 
---
Right: same on Solaris both with native assembler/linker and gas/gld.

  Rainer

[Bug ada/53517] New: gnat.dg/lto14.adb FAILs

[ro at gcc dot gnu.org]

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

 Bug #: 53517
   Summary: gnat.dg/lto14.adb FAILs
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: ebotca...@gcc.gnu.org
  Host: *-*-solaris2.*
Target: *-*-solaris2.*
 Build: *-*-solaris2.*


Since 20120525, gnat.dg/lto14.adb FAILs on Solaris with Sun ld:

FAIL: gnat.dg/lto14.adb (test for excess errors)
Excess errors:
gnatlink: Object list file not supported on this target

  Rainer

[Bug ada/53517] gnat.dg/lto14.adb FAILs

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |4.8.0

[Bug c++/46836] reporting locations for names in std namespace could be improved

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #7 from Manuel López-Ibáñez  2012-05-29 
13:50:17 UTC ---
(In reply to comment #6)
> (In reply to comment #2)
> > #pragma GCC canonical_header [header-name] [identifier]
> 
> I don't think we even need to do it per-identifier.
> 
> If each standard header started with:
> 
> #pragma GCC canonical_header push [header-name]
> 
> and ended with:
> 
> #pragma GCC canonical_header pop
> 
> then we'd always know which header we're "in" when an error occurs, even for
> nested headers (e.g.  includes ) and helper files that are
> included from many places (e.g. bits/stl_tree.h gets included by both  
> and
> )

Well, we already have pragma system_header, we could extend it with an optional
parameter.

#pragma GCC system_header "canonical_name"

and when the pragma is read, save "canonical_name". Then when printing the name
of a file, we could check that it is a system-header and there is a saved
canonical_name. System-headerness is reset when leaving a file (but I think not
when including something from a system header), so you don't need explicit
push/pop.

[Bug libstdc++/53518] New: [4.8 regression] testsuite_abi_check.cc doesn't compile

[ro at gcc dot gnu.org]

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

 Bug #: 53518
   Summary: [4.8 regression] testsuite_abi_check.cc doesn't
compile
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
  Host: *-*-solaris2.9
Target: *-*-solaris2.9
 Build: *-*-solaris2.9


Between 20120518 and 20120525, many libstdc++ testcases started to fail.  
The root cause is

output is:
Undefined   first referenced^M
 symbol in file^M
construction vtable for std::basic_istream
>-in-std
::basic_ifstream >
./libtestc++.a(testsuite_abi.o)^
M
construction vtable for std::basic_istream
>-in-std
::basic_istringstream, std::allocator >
./lib
testc++.a(testsuite_abi.o)^M
ld: fatal: Symbol referencing errors. No output written to abi_check^M
collect2: error: ld returned 1 exit status^M

ERROR: tcl error sourcing
/vol/gcc/src/hg/trunk/local/libstdc++-v3/testsuite/lib
stdc++-abi/abi.exp.
ERROR: could not compile testsuite_abi_check.cc
while executing

  Rainer

[Bug c++/51912] [C++11] G++ accepts floating point case labels

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||paolo.carlini at oracle dot
   ||com

--- Comment #2 from Paolo Carlini  2012-05-29 
13:58:21 UTC ---
Jason, I'm thinking that this should be doable rather easily by adding a new
LOOKUP_NO_NON_INTEGRAL mask and passing it down to standard_conversion from 
case_conversion via perform_implicit_conversion_flags.

Then standard_conversion can exclude all such non-integral conversions, eg, for
this specific testcase, return NULL from line #1332 because fcode == REALTYPE
&& (flags & LOOKUP_NO_NON_INTEGRAL)).

Makes sense?

[Bug libstdc++/53518] [4.8 regression] testsuite_abi_check.cc doesn't compile

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  2012-05-29 
14:02:17 UTC ---
(In reply to comment #0)
> Between 20120518 and 20120525, many libstdc++ testcases started to fail. 

>From the libstdc++-v3/ChangeLog for that period I'd say it's unlikely to be
caused by a libstdc++ change.

[Bug libstdc++/53518] [4.8 regression] testsuite_abi_check.cc doesn't compile

[paolo.carlini at oracle dot com]

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

--- Comment #1 from Jonathan Wakely  2012-05-29 
14:02:17 UTC ---
(In reply to comment #0)
> Between 20120518 and 20120525, many libstdc++ testcases started to fail. 

>From the libstdc++-v3/ChangeLog for that period I'd say it's unlikely to be
caused by a libstdc++ change.

--- Comment #2 from Paolo Carlini  2012-05-29 
14:02:59 UTC ---
Please try to figure out which patch broke this and adjust accordingly the
component, because evidently this isn't a library proper issue (eh, nothing
substantive went in!)

[Bug middle-end/48493] [4.6/4.7/4.8 Regression] ice in expand_expr_addr_expr_1 with complex types and mem_ref

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug middle-end/48493] [4.6/4.7/4.8 Regression] ice in expand_expr_addr_expr_1 with complex types and mem_ref

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

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

--- Comment #10 from Richard Guenther  2012-05-29 
14:07:06 UTC ---
Mine.

[Bug target/52122] [4.6/4.7/4.8 Regression] incorrect ln -s replacement for mingw like targets in configure files

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug bootstrap/52674] [4.7 regression] segfault during profiled LTO bootstrap

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||WONTFIX

--- Comment #4 from Richard Guenther  2012-05-29 
14:12:44 UTC ---
According to sparc maintainer this is not going to be fixed.

[Bug target/52911] [4.5/4.6/4.7/4.8 Regression] gcc 4.7.0 (ppc32 e500mc) when compile a c file, after a lot of time, gcc failed and internal compiler error occurs.

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther  2012-05-29 
14:14:54 UTC ---
The testcase needs reduction.

[Bug c++/53137] [4.7/4.8 Regression] g++ segfault

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug lto/53471] [4.7/4.8 Regression] ICE in pp_base_format, at pretty-print.c:510 (-flto -g)

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Guenther  2012-05-29 
14:18:35 UTC ---
Mine.

[Bug c++/53494] [4.7/4.8 Regression] ICE with invalid initializer list

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P5

[Bug c++/53500] [4.7 Regression] internal compiler error in joust()

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P2
  Known to work||4.8.0

[Bug tree-optimization/53516] [4.6/4.7/4.8 Regression] Vectorization and memset recognition miscompile bitfield stores

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug ada/53517] gnat.dg/lto14.adb FAILs

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-05-29
 Ever Confirmed|0   |1

--- Comment #1 from Eric Botcazou  2012-05-29 
14:30:08 UTC ---
> Since 20120525, gnat.dg/lto14.adb FAILs on Solaris with Sun ld:
> 
> FAIL: gnat.dg/lto14.adb (test for excess errors)
> Excess errors:
> gnatlink: Object list file not supported on this target

Sure, feel free to XFAIL it on Solaris.

[Bug c++/53484] [4.7/4.8 Regression] [c++11] Wrong auto in lambdas in function templates

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |4.7.1

[Bug c++/52725] [4.7/4.8 Regression] error: "capture of non-variable" for new-expression incorrectly parsed as lambda-expression

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |4.7.1

[Bug tree-optimization/53198] [4.6/4.7 Regression] gcc wrongly emits "array subscript is above array bounds" for simple arrays

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |4.6.4

[Bug middle-end/53204] [4.7 regression] ICE during final link of large codebase with -O2 -finline-functions -flto, adding -flto-partition=none fixes the problem

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2012-05-29
   Target Milestone|--- |4.7.1
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2012-05-29 
14:33:26 UTC ---
We need some sort of a testcase.

[Bug libstdc++/53218] [4.7 regression] cmake segfaults on sparcv9

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.1

[Bug c++/53356] [4.7/4.8 Regression] ICE in verify_gimple_stmt, at tree-cfg.c:4258

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |4.7.1

[Bug fortran/53379] [4.7/4.8 Regression] No backtrace generated for array bounds violation

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |4.7.1

[Bug tree-optimization/53516] [4.6/4.7/4.8 Regression] Vectorization and memset recognition miscompile bitfield stores

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2012-05-29 
14:40:23 UTC ---
Author: rguenth
Date: Tue May 29 14:40:16 2012
New Revision: 187961

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187961
Log:
2012-05-29  Richard Guenther  

PR tree-optimization/53516
* tree-data-ref.c (stmt_with_adjacent_zero_store_dr_p): Reject
bitfield accesses.
* tree-vect-data-refs.c (vect_analyze_data_refs): Likewise.

* gcc.dg/torture/pr53516.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr53516.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-data-ref.c
trunk/gcc/tree-vect-data-refs.c

[Bug tree-optimization/53516] [4.6/4.7/4.8 Regression] Vectorization and memset recognition miscompile bitfield stores

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther  2012-05-29 
14:44:13 UTC ---
Author: rguenth
Date: Tue May 29 14:44:08 2012
New Revision: 187964

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187964
Log:
2012-05-29  Richard Guenther  

PR tree-optimization/53516
* tree-data-ref.c (stmt_with_adjacent_zero_store_dr_p): Reject
bitfield accesses.
* tree-vect-data-refs.c (vect_analyze_data_refs): Likewise.

* gcc.dg/torture/pr53516.c: New testcase.

Added:
branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr53516.c
Modified:
branches/gcc-4_7-branch/gcc/ChangeLog
branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
branches/gcc-4_7-branch/gcc/tree-data-ref.c
branches/gcc-4_7-branch/gcc/tree-vect-data-refs.c

[Bug tree-optimization/53516] [4.6 Regression] Vectorization and memset recognition miscompile bitfield stores

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P2  |P3
  Known to work||4.7.1, 4.8.0
Summary|[4.6/4.7/4.8 Regression]|[4.6 Regression]
   |Vectorization and memset|Vectorization and memset
   |recognition miscompile  |recognition miscompile
   |bitfield stores |bitfield stores
  Known to fail||4.6.3, 4.7.0

--- Comment #4 from Richard Guenther  2012-05-29 
14:44:50 UTC ---
Fixed on the trunk and the 4.7 branch for now.

[Bug middle-end/38474] slow compilation at -O0 due to expand's temp slot goo

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||mjambor at suse dot cz

--- Comment #56 from Jan Hubicka  2012-05-29 
14:57:30 UTC ---
That functions is Martin's. Martin, can you please take a look?

[Bug middle-end/38474] slow compilation at -O0 due to expand's temp slot goo

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu.org

--- Comment #57 from Martin Jambor  2012-05-29 
15:08:39 UTC ---
(In reply to comment #56)
> That functions is Martin's. Martin, can you please take a look?

I will, on Monday.

[Bug tree-optimization/53501] [4.5/4.6/4.7/4.8 Regression] scev introduces signed overflow

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-05-29
 CC||amonakov at gcc dot gnu.org
  Known to work||4.3.2
Summary|incorrect loop optimization |[4.5/4.6/4.7/4.8
   |with -O2|Regression] scev introduces
   ||signed overflow
 Ever Confirmed|0   |1

--- Comment #1 from Alexander Monakov  2012-05-29 
16:00:01 UTC ---
Confirmed, thanks for the report.

This is a regression relative to 4.3 on all active branches (I haven't tested
latest trunk though).

GCC optimizes out the second loop when VRP proves that its upper bound k is
negative.  This is due to scev-cprop performing final value replacement, which
obtains the final value of k after the first loop based on scalar evolution {2,
+, 2} for n-1 latch executions as:

((int) ((unsigned int) n.0_28 + 2147483647) + 1) * 2

(which is a very roundabout way to get n*2, but that's beside the point ;) )
AFAICT forcing the signed type happens in chrec-apply:
  /* "{a, +, b} (x)"  ->  "a + b*x".  */
  x = chrec_convert_rhs (type, x, NULL);
  res = chrec_fold_multiply (TREE_TYPE (x), CHREC_RIGHT (chrec), x);
  res = chrec_fold_plus (type, CHREC_LEFT (chrec), res);

Apropos, I find it quite strange that fold-const folds (n+0x)*2 to
(n+0x7fff)*2, as opposed to n*2+0xfffe.

Stopping my investigation here.

[Bug c++/26155] ICE after error with namespace alias

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |paolo.carlini at oracle dot
   |gnu.org |com
   Target Milestone|--- |4.8.0

--- Comment #6 from Paolo Carlini  2012-05-29 
16:14:58 UTC ---
On it.

[Bug c/53519] New: ice in do_SUBST, at combine.c:707

[regehr at cs dot utah.edu]

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

 Bug #: 53519
   Summary: ice in do_SUBST, at combine.c:707
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reg...@cs.utah.edu
CC: cheny...@cs.utah.edu


[regehr@dyson r62]$ current-gcc -c -Os small.c
small.c: In function 'fn3':
small.c:24:1: internal compiler error: in do_SUBST, at combine.c:707
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
[regehr@dyson r62]$   
[regehr@dyson r62]$ 
[regehr@dyson r62]$ current-gcc -v
Using built-in specs.
COLLECT_GCC=current-gcc
COLLECT_LTO_WRAPPER=/uusoc/exports/scratch/regehr/z/compiler-install/gcc-r187937-install/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --with-libelf=/usr/local --enable-lto
--prefix=/home/regehr/z/compiler-install/gcc-r187937-install
--program-prefix=r187937- --enable-languages=c,c++
Thread model: posix
gcc version 4.8.0 20120528 (experimental) (GCC) 
[regehr@dyson r62]$ 
[regehr@dyson r62]$ 
[regehr@dyson r62]$ 
[regehr@dyson r62]$ cat small.c
int a, b, c, d, e;
short
fn1 (short p1)
{
return a == 0 ? p1 : 0;
}
short
fn2 (int p1, int p2)
{
return p1 + p2;
}
void
fn3 ()
{
int f;
if (e)
;
else
{
f = fn1 (65535 ^ b);
if (fn2 (!6L <= ~f, ~e) == c)
d = 0;
}
}

[Bug c++/53520] New: ICE in timevar_start with -ftime-report and constexpr

[pinskia at gcc dot gnu.org]

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

 Bug #: 53520
   Summary: ICE in timevar_start with -ftime-report and constexpr
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pins...@gcc.gnu.org


Short testcase:
 template class allocator;
 template struct __alloctr_rebind_helper {
template static constexpr bool _S_chk(...) { return 0; 
 }
static const bool __value = _S_chk<_Alloc, _Tp>(nullptr);
};
 template::__value> struct __alloctr_rebind;
 template struct allocator_traits {
template using rebind_alloc = typename
__alloctr_rebind<_Alloc, _Tp>::__type;
};
 template > class vector 
 {
typedef typename allocator_traits<_Alloc> ::template
rebind_alloc<_Tp>::other _Tp_alloc_type;
};
  template  struct Data {
 static const vector & values1 () {}
 };
  void f() {
typedef Data  value_data;
range_begin (value_data::values1 ());
}

--- CUT ---
This was a valid program to begin with

[Bug c++/53520] ICE in timevar_start with -ftime-report and constexpr

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  2012-05-29 
17:25:36 UTC ---
This happens as of "4.8.0 20120518" [trunk revision 187657].

[Bug fortran/53521] New: Memory leak with zero sized array constructor

[Joost.VandeVondele at mat dot ethz.ch]

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

 Bug #: 53521
   Summary: Memory leak with zero sized array constructor
Classification: Unclassified
   Product: gcc
   Version: 4.6.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: joost.vandevond...@mat.ethz.ch


The following testcase (as reduced from CP2K) leaks memory when compiled with
gfortran 4.6 - 4.8 :

MODULE TEST
 IMPLICIT NONE
CONTAINS
 SUBROUTINE T(n1)
  INTEGER :: n1(:)
 END SUBROUTINE T
 SUBROUTINE T2(n)
   INTEGER :: n
   INTEGER :: k
   CALL T((/(k,k=1,n-1)/))
 END SUBROUTINE
END MODULE
USE TEST
  CALL T2(1)
END 

as can be verified with valgrind or putting a loop around call t2. The issue
seems to be the zero-sized array constructor.

[Bug rtl-optimization/53519] [4.7/4.8 Regression] ice in do_SUBST, at combine.c:707

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-05-29
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |4.7.1
Summary|ice in do_SUBST, at |[4.7/4.8 Regression] ice in
   |combine.c:707   |do_SUBST, at combine.c:707
 Ever Confirmed|0   |1

--- Comment #1 from Jakub Jelinek  2012-05-29 
19:27:09 UTC ---
Apparently started with my
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179238
Will have a look.

[Bug rtl-optimization/53519] [4.7/4.8 Regression] ice in do_SUBST, at combine.c:707

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |

--- Comment #2 from Jakub Jelinek  2012-05-29 
20:07:48 UTC ---
Created attachment 27516
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27516
gcc48-pr53519.patch

Untested fix.

[Bug target/52941] SH Target: Add support for movco.l / movli.l atomics on SH4A

[olegendo at gcc dot gnu.org]

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

--- Comment #11 from Oleg Endo  2012-05-29 
20:26:46 UTC ---
Author: olegendo
Date: Tue May 29 20:26:41 2012
New Revision: 187987

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187987
Log:
PR target/52941
* config/sh/predicates.md (atomic_arith_operand,
atomic_logical_operand): New predicates.
* config/sh/sh.c (sh_option_override): Check atomic options.
* config/sh/sh.h (TARGET_ANY_ATOMIC, UNSUPPORTED_ATOMIC_OPTIONS,
UNSUPPORTED_HARD_ATOMIC_CPU): New macros.
(DRIVER_SELF_SPECS): Use UNSUPPORTED_ATOMIC_OPTIONS and
UNSUPPORTED_HARD_ATOMIC_CPU.
* config/sh/sync.md: Update description comments.
(I12): New mode iterator.
(fetchop_predicate, fetchop_constraint): New code attributes.
(atomic_compare_and_swapsi_hard, atomic_compare_and_swap_hard,
atomic_exchangesi_hard, atomic_exchange_hard,
atomic_fetch_si_hard,
atomic_fetch__hard,
atomic_fetch_nandsi_hard, atomic_fetch_nand_hard,
atomic__fetchsi_hard,
atomic__fetch_hard,
atomic_nand_fetchsi_hard, atomic_nand_fetch_hard,
atomic_test_and_set_hard): New insns.
(atomic_compare_and_swap_soft, atomic_exchange_soft,
atomic_fetch__soft, atomic_fetch_nand_soft,
atomic__fetch_soft, atomic_nand_fetch_soft,
atomic_test_and_set_soft): Use same formatting for the first line of
the asm block as in new insns above.
(atomic_compare_and_swap, atomic_exchange,
atomic_fetch_, atomic__fetch,
atomic_test_and_set): Integrate new *_hard insns into expanders.
* config/sh/sh.opt (mhard-atomic): New option.
* doc/invoke.texi (SH Options): Document it.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/predicates.md
trunk/gcc/config/sh/sh.c
trunk/gcc/config/sh/sh.h
trunk/gcc/config/sh/sh.opt
trunk/gcc/config/sh/sync.md
trunk/gcc/doc/invoke.texi

[Bug bootstrap/52700] lib* configure fails on --enable-symvers=gnu-versioned-namespace.

[bkoz at gcc dot gnu.org]

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

Benjamin Kosnik  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |

--- Comment #10 from Benjamin Kosnik  2012-05-29 
20:36:19 UTC ---

Ugh, you are right. Sorry. It looks like

libgfortran/libssp/libquadmath

need a simple fix. Working on it...

[Bug target/51340] SH Target: Make -mfused-madd enabled by default

[olegendo at gcc dot gnu.org]

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

--- Comment #6 from Oleg Endo  2012-05-29 20:56:02 
UTC ---
Author: olegendo
Date: Tue May 29 20:55:58 2012
New Revision: 187988

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187988
Log:
PR target/51340
* config/sh/sh.c (sh_option_override): Set TARGET_FMAC if
flag_unsafe_math_optimizations is set.
* doc/invoke.texi (SH Options): Add -mno-fused-madd description.
Update description of -mfused-madd.

PR target/51340
* gcc.target/sh/pr51340-1.c: New.
* gcc.target/sh/pr51340-2.c: New.
* gcc.target/sh/pr51340-3.c: New.


Added:
trunk/gcc/testsuite/gcc.target/sh/pr51340-1.c
trunk/gcc/testsuite/gcc.target/sh/pr51340-2.c
trunk/gcc/testsuite/gcc.target/sh/pr51340-3.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/sh.c
trunk/gcc/doc/invoke.texi
trunk/gcc/testsuite/ChangeLog

[Bug c++/16166] -Weffc++ finer granularity

[david at doublewise dot net]

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

--- Comment #7 from David Stone  2012-05-29 
20:57:22 UTC ---
(In reply to comment #5)
> (In reply to comment #4)
> > * Item 11: Define a copy constructor and an assignment operator for classes
> > with dynamically allocated memory.
> > 
> > -Wcopy-resource-class
> 
> IMHO this warning should just go. With deleted copy ctor/assign and move
> ctor/assign there are even more places where a hard and fast rule isn't 
> useful.
> 

And in general, classes should just use a smart pointer from boost / the
standard library, rather than managing their own memory directly. I agree that
this warning probably isn't that useful, and I wouldn't be sad to see it go.

> > * Item 12: Prefer initialization to assignment in constructors.
> > 
> > -Wassignment-in-constructor
> 
> If I ever get my -Wmeminit patch working properly it would provide this.

Is the issue just finding the time to do it, or are there subtle issues
involved?

> > * Item 14: Make destructors virtual in base classes.
> > 
> > Already covered by -Wnon-virtual-dtor
> 
> And the more useful -Wdelete-non-virtual-dtor

Yeah, my only thought for the usefulness of -Wnon-virtual-dtor over
-Wdelete-non-virtual-dtor is that a library author may wish to have a class
that users are supposed to derive from, but doesn't actually call delete
anywhere in the library code. They may want to ensure that users of the library
(who may not have any warnings turned on at all) do not run into any surprising
bugs.

(In reply to comment #6)
> David, if you wish to implement such a patch (or, even better, series of
> patches, one for each new option), the only changes needed are:
> 

I am currently writing up a patch to update doc/invoke.texi for warnings, to
try and make it easier to see what is turned on by -Wall and -Wextra and what
isn't. Do you think it would be best for me to submit a patch based on the
current documentation, my updated documentation (as a separate patch, of
course), or some combination of the two?

[Bug target/51340] SH Target: Make -mfused-madd enabled by default

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #7 from Oleg Endo  2012-05-29 21:01:30 
UTC ---
-mfused-madd option is now automatically enabled when
-funsafe-math-optimizations is enabled.

[Bug libstdc++/29366] atomics config for sh is weird

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

 Depends on|52941   |

--- Comment #4 from Oleg Endo  2012-05-29 21:15:27 
UTC ---
I've just committed the essential patch for PR 52941 which should allow us to
remove config/cpu/sh/atomicity.h now.

Is is enough to simply delete the whole config/cpu/sh dir, or is there more to
be done?

[Bug c++/53494] [4.7/4.8 Regression] ICE with invalid initializer list

[daniel.kruegler at googlemail dot com]

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

--- Comment #14 from Daniel Krügler  
2012-05-29 21:16:57 UTC ---
(In reply to comment #13)
> Am I interpreting correctly that double braces are /required/ for std::array
> init lists but only when the subtype has has a multivariable initializer too?

I must agree that the compiler behaviour does not look correct to me. Initially
I thought that the reason is due to the fact, that brace-elision does not apply
here, but then I noticed that this code does not compile either:

struct pair
{
  pair(const char*, int) { }
};

struct array_p
{
  pair data[1];
};

array_p a  = { { "smile", 1 } };

Here we have definitively brace elision in action, but I get the same error as
from Jonathan's example. My impression is that the compiler incorrectly does
not see the brace-elision case here.

Here is an example that works (with an expected [-Wmissing-braces] warning):

struct string
{
  string(const char*) { }
};

struct array_s
{
  string data[1];
};

array_s b{ "smile" };

From this I see that gcc already implements

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1270

so I must conclude that the compiler should also accept the original example.

[Bug c++/53494] [4.7/4.8 Regression] ICE with invalid initializer list

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

[Bug bootstrap/53522] New: [4.8 Summary] Bootstrap is broken for x86_64-apple-darwin10 at r187977

[dominiq at lps dot ens.fr]

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

 Bug #: 53522
   Summary: [4.8 Summary] Bootstrap is broken for
x86_64-apple-darwin10 at r187977
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: domi...@lps.ens.fr
CC: ia...@gcc.gnu.org, rgue...@gcc.gnu.org
  Host: x86_64-apple-darwin10
Target: x86_64-apple-darwin10
 Build: x86_64-apple-darwin10


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

Bootstrap fails on x86_64-apple-darwin10 at revision 187977:

...
libtool: compile:  /opt/gcc/build_w/./gcc/g++ -B/opt/gcc/build_w/./gcc/
-nostdinc++ -nostdinc++
-I/opt/gcc/build_w/x86_64-apple-darwin10.8.0/libstdc++-v3/include/x86_64-apple-darwin10.8.0
-I/opt/gcc/build_w/x86_64-apple-darwin10.8.0/libstdc++-v3/include
-I/opt/gcc/work/libstdc++-v3/libsupc++
-I/opt/gcc/work/libstdc++-v3/include/backward
-I/opt/gcc/work/libstdc++-v3/testsuite/util
-L/opt/gcc/build_w/x86_64-apple-darwin10.8.0/libstdc++-v3/src
-L/opt/gcc/build_w/x86_64-apple-darwin10.8.0/libstdc++-v3/src/.libs
-B/opt/gcc/gcc4.8w/x86_64-apple-darwin10.8.0/bin/
-B/opt/gcc/gcc4.8w/x86_64-apple-darwin10.8.0/lib/ -isystem
/opt/gcc/gcc4.8w/x86_64-apple-darwin10.8.0/include -isystem
/opt/gcc/gcc4.8w/x86_64-apple-darwin10.8.0/sys-include -DHAVE_CONFIG_H -I.
-I../../../work/libitm -I../../../work/libitm/config/x86
-I../../../work/libitm/config/posix -I../../../work/libitm/config/generic
-I../../../work/libitm -Wall -pthread -Werror -std=gnu++0x -funwind-tables
-fno-exceptions -fno-rtti -fabi-version=4 -g -O2 -MT alloc_c.lo -MD -MP -MF
.deps/alloc_c.Tpo -c ../../../work/libitm/alloc_c.cc  -fno-common -DPIC -o
.libs/alloc_c.o
../../../work/libitm/alloc_c.cc: In function 'void _ITM_free(void*)':
../../../work/libitm/alloc_c.cc:72:1: internal compiler error: in
add_referenced_var_1, at tree-dfa.c:568
 } // extern "C"

The ICE occurs in the assert introduced in r187955. The preprocessed source is
attached and generate the error when compiled with

/opt/gcc/build_w/gcc/cc1plus -nostdinc++ -DHAVE_CONFIG_H -std=gnu++0x
-funwind-tables -fno-exceptions -fno-rtti -fabi-version=4 -g -O2 alloc_c.ii
-fno-common -DPIC

The backtrace is

#0  fancy_abort (file=0x100c06c63 "../../work/gcc/tree-dfa.c", line=568,
function=0x100cd70c0 "add_referenced_var_1")
at ../../work/gcc/diagnostic.c:1010
#1  0x0001008ba3f0 in add_referenced_var_1 (var=,
fn=) at ../../work/gcc/tree-dfa.c:566
#2  0x0001008ce8e5 in lower_emutls_1 (ptr=,
walk_subtrees=, cb_data=)
at ../../work/gcc/tree-emutls.c:437
#3  0x000100ab2f64 in walk_tree_1 (tp=, func=, data=, pset=, 
lh=) at ../../work/gcc/tree.c:10548
#4  0x000100ab3a2b in walk_tree_1 (tp=, func=, data=, pset=, 
lh=) at ../../work/gcc/tree.c:10804
#5  0x00010063aabe in walk_gimple_op (stmt=,
callback_op=, wi=)
at ../../work/gcc/gimple.c:1445
#6  0x0001008ce284 in ipa_lower_emutls () at
../../work/gcc/tree-emutls.c:571
#7  0x0001007aa819 in execute_one_pass (pass=) at
../../work/gcc/passes.c:2182
#8  0x0001007ab0d2 in execute_ipa_pass_list (pass=) at
../../work/gcc/passes.c:2549
#9  0x0001004aa22e in compile () at ../../work/gcc/cgraphunit.c:1844
#10 0x0001004aaa1f in finalize_compilation_unit () at
../../work/gcc/cgraphunit.c:2095
#11 0x0001000f4b4b in cp_write_global_declarations () at
../../work/gcc/cp/decl2.c:4023
#12 0x00010086d1ba in toplev_main (argc=13, argv=0x7fff5fbfd720) at
../../work/gcc/toplev.c:567
#13 0x00011af4 in start ()

[Bug bootstrap/53522] [4.8 Regression] Bootstrap is broken for x86_64-apple-darwin10 at r187977

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

Summary|[4.8 Summary] Bootstrap is  |[4.8 Regression] Bootstrap
   |broken for  |is broken for
   |x86_64-apple-darwin10 at|x86_64-apple-darwin10 at
   |r187977 |r187977

--- Comment #1 from Dominique d'Humieres  2012-05-29 
22:34:58 UTC ---
It was too late;-(

[Bug c++/53494] [4.7/4.8 Regression] ICE with invalid initializer list

[paolo.carlini at oracle dot com]

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

--- Comment #15 from Paolo Carlini  2012-05-29 
23:00:34 UTC ---
Thanks Daniel. Let's see if Jon agrees with your analysis. To be honest, at
first, when I figured out the workaround, it seemed a brace-elision issue to me
too, but then I haven't been able to spend enough time on the details of the
issue, unfortunately.

[Bug bootstrap/53523] New: i686 compiler with multilib ( x86_64 target ) included fails on linker

[kphillisjr at gmail dot com]

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

 Bug #: 53523
   Summary: i686 compiler with multilib ( x86_64 target ) included
fails on linker
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kphilli...@gmail.com


Created attachment 27518
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27518
Simple Shell containing the commands I used ran.

I was trying to build a compiler where the default output is i686 ( 32-bit),
but the compiler can handle building 64-bit libraries. This occurs when trying
to link the  libgcc_s.a (64-bit version )


Attached is a simple text file outlining all of the commands I ran. 

Host Computer: Linux Mint 13

Host Computer Prep:
sudo apt-get install g++ && sudo apt-get build-dep gcc

Host Compiler:
$gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object
--enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i686
--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.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) 

Compiler being built:
i686-w64-mingw32-gcc -v
Using built-in specs.
COLLECT_GCC=i686-w64-mingw32-gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i686-w64-mingw32/4.7.0/lto-wrapper
Target: i686-w64-mingw32
Configured with: ../gcc-4.7.0/configure --target=i686-w64-mingw32
--enable-targets=all --enable-languages=c,c++,fortran,objc,obj-c++,lto
Thread model: win32
gcc version 4.7.0 (GCC)