[Bug c++/54111] New: function return type template deduction

[leonid at volnitsky dot com]

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

 Bug #: 54111
   Summary: function return type template deduction
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: leo...@volnitsky.com


Created attachment 27882
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27882
4 source code files.

Possible regression. 

There are 4 version of slightly different versions of below code (file
bug-u2.cc): 

-
#include 

template 
U operator* (T x,  U& (*f)(T&) ) {  
return (*f)(x);
}; 

int main() {
std::tuple  tpl(42,43);
return   tpl * std::get<0,int,int>;
}  


These 4 versions are combination of 2 variants:
- if template parameter U  or hardcoded type int is used (codes int or u) 
- if get<0,int,int>  or get<0> is used (codes 2 and 0)

4 version of above code are attached. 

For 3 versions of GCC that I have:

   453 471 480-pre 
--
bug-int0.ccaccpaccpaccp
bug-int2.ccaccprej rej 
bug-u0.cc  rej rej rej 
bug-u2.cc  accprej rej   

It seems that gcc463 behave the same as 453.

[Bug libstdc++/54112] New: including complex.h and complex fails in C++03

[glisse at gcc dot gnu.org]

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

 Bug #: 54112
   Summary: including complex.h and complex fails in C++03
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gli...@gcc.gnu.org


#include 
#ifdef FIX
#undef complex
#endif
#include 

fails to compile with glibc. Since libstdc++ already installs a complex.h
wrapper that #include_next complex.h, I guess it could easily #undef complex
afterwards.

Note that you can include tr1/complex instead of complex if you prefer.

I guess I could also ask glibc to protect their #define with #ifndef
__cplusplus.

It is strange that in C++11 it is impossible to have access to the C99
functions cacos and others, since C++11 hijacks their header. g++ accepts
_Complex, I expect we should still have access to those functions.

[Bug fortran/45586] [4.8 Regression] ICE non-trivial conversion at assignment

[mikael at gcc dot gnu.org]

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

--- Comment #69 from Mikael Morin  2012-07-28 
09:46:00 UTC ---
(In reply to comment #63)
> With a (seemingly) unrelated patch (attached to PR52097) I'm back on ICEing
> for the gfortran.dg/lto/pr45586*.f90 testcases ...
> 
> Even before the adjusted type merging we have (at compile-time)
> 
[...]
> 
> _BUT_(!) its main-variant is
> 
[...]
> 
> thus has a restrict-qualified data field.  That's bogus as TYPE_FIELDS
> is supposed to be shared amongst variant types.

So, is this a fortran front-end bug, a middle-end bug, or a lto bug ?
(Hint: PR 51765 is a marked as a lto bug ;-) )

[Bug libstdc++/54112] including complex.h and complex fails in C++03

[paolo.carlini at oracle dot com]

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

--- Comment #1 from Paolo Carlini  2012-07-28 
10:11:04 UTC ---
Why it happens only in C++03 mode? I'm asking because if the issue isn't a
regression and we are sure that it doesn't happen in C++11 mode, I don't think
it can be considered high priority.

[Bug libstdc++/54112] including complex.h and complex fails in C++03

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  2012-07-28 10:26:42 
UTC ---
(In reply to comment #1)
> Why it happens only in C++03 mode?

Because the complex.h wrapper distributed with libstdc++ does:

#ifdef __GXX_EXPERIMENTAL_CXX0X__
# include 
#else
# if _GLIBCXX_HAVE_COMPLEX_H
#  include_next 
# endif
#endif

That's what I meant by "hijack", the system's complex.h can never be included
in C++11.

> I'm asking because if the issue isn't a
> regression and we are sure that it doesn't happen in C++11 mode, I don't think
> it can be considered high priority.

I am not saying it is high priority (on the other hand, it is rather easy).
Note that there are 2 issues (I should have been clearer):

1) we can't include both complex.h and complex in C++03 mode. The fix is
trivial, #undef complex after the #include_next quoted above. The other headers
all have a long list of #undef, that's just one more.

2) In C++11, there is no way to have cacos declared. A solution would be to
move the _GLIBCXX_HAVE_COMPLEX_H block outside of the
__GXX_EXPERIMENTAL_CXX0X__ condition.

[Bug libstdc++/54112] including complex.h and complex fails in C++03

[paolo.carlini at oracle dot com]

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

--- Comment #3 from Paolo Carlini  2012-07-28 
10:50:15 UTC ---
Sure, sure. I'm still thinking that unless we have a regression, the less we do
for C++03 mode, the better. But if you can already see simple enough fixes for
both issues you are welcome to post them to the mailing list!

PS: to be honest, I can't remember at the moment to have written the
"hijacking", which seems indeed a little weird now. Maybe some svn blame is in
order ;)

[Bug c/54088] ICE at dwarf2out.c:20632 with -O1 -g

[jengelh at medozas dot de]

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

--- Comment #2 from Jan Engelhardt  2012-07-28 
12:09:24 UTC ---
Created attachment 27883
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27883
Full preprocessed output

Thanks for reminding me about the standard procedure :)

The minimal command is

gcc -c -O1 -g -Wno-narrowing -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -fno-common c-parser.i -o c-parser.o

Both -O1 and -g are required; changing the g or O level will not trigger the
issue.

[Bug c/54088] ICE at dwarf2out.c:20632 with -O1 -g

[mikpe at it dot uu.se]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpe at it dot uu.se

--- Comment #3 from Mikael Pettersson  2012-07-28 
13:08:39 UTC ---
I can reproduce the ICE with gcc 4.8-20120722 and 4.7-20120721, but not with
4.6-20120720, on sparc64-linux.

[Bug c++/54104] Parser error for lambda expression if function template has default parameter.

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE

--- Comment #8 from Paolo Carlini  2012-07-28 
13:17:35 UTC ---
Indeed, dup.

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

[Bug c++/53624] GCC rejects function local types in template function with default template arguments

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||likan_999.student at sina
   ||dot com

--- Comment #4 from Paolo Carlini  2012-07-28 
13:17:35 UTC ---
*** Bug 54104 has been marked as a duplicate of this bug. ***

[Bug c++/53624] GCC rejects function local types in template function with default template arguments

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-07-28
 AssignedTo|unassigned at gcc dot   |paolo.carlini at oracle dot
   |gnu.org |com
   Target Milestone|--- |4.8.0
 Ever Confirmed|0   |1

--- Comment #5 from Paolo Carlini  2012-07-28 
13:20:08 UTC ---
Looking into it.

[Bug c/54113] New: -Wmissing-prototypes cries wolf for C99 inline functions

[eggert at gnu dot org]

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

 Bug #: 54113
   Summary: -Wmissing-prototypes cries wolf for C99 inline
functions
Classification: Unclassified
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: egg...@gnu.org


-Wmissing-prototypes produces false alarms for C99-style
inline functions.  Here's a simple example, taken from
.
Suppose foo.h contains this:

  inline float square(float x) {return x*x;}
  inline float cube(float x) {return x*x*x;}

and foo.c contains this:

  #include "foo.h"
  extern float square(float x);
  extern float cube(float x);

Then the command:

  gcc -c -Wmissing-prototypes foo.c

outputs:

  In file included from foo.c:1:0:
  foo.h:1:14: warning: no previous prototype for 'square'
[-Wmissing-prototypes]
  foo.h:2:14: warning: no previous prototype for 'cube' [-Wmissing-prototypes]

The diagnostics should not be output, as this is the normal
way to use inline functions in C.

The simplest way to work around the problem is to avoid
the use of -Wmissing-prototypes, but that disables the
diagnostic for non-inline functions, where it's useful.

To fix this, I suggest that the diagnostic be suppressed
for inline functions, at least for C99 mode.

[Bug middle-end/54109] [4.8 Regression] ICE at tree-ssa-structalias.c:3049 in get_constraint_for_component_ref

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-07-28
  Known to work||4.7.0
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |
   Target Milestone|--- |4.8.0
Summary|ICE at  |[4.8 Regression] ICE at
   |tree-ssa-structalias.c:3049 |tree-ssa-structalias.c:3049
   |in  |in
   |get_constraint_for_componen |get_constraint_for_componen
   |t_ref   |t_ref
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2012-07-28 
14:19:50 UTC ---
I'll have a look.

[Bug middle-end/54114] New: variable-tracking performance regression from 4.8-20120610 to 4.8-20120701

[jimis at gmx dot net]

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

 Bug #: 54114
   Summary: variable-tracking performance regression from
4.8-20120610 to 4.8-20120701
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ji...@gmx.net


Compiling the XPath.cpp from xalanc shows significant performance regression
because of variable tracking, between GCC 4.8-20120610 to 4.8-20120701.
Tracking it down is hard since var-tracking.c changed a lot in the past month,
CC'ing lxo for better ideas. :-)

It seems to apply mostly to C++ code, see the graph and the last annotation at
http://teras-ics.mooo.com:8003/

[Bug c/54088] ICE at dwarf2out.c:20632 with -O1 -g

[jengelh at medozas dot de]

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

--- Comment #4 from Jan Engelhardt  2012-07-28 
19:42:50 UTC ---
Created attachment 27884
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27884
somewhat reduced testcase

it's not a minimal one, but still lost a good deal of lines.

[Bug middle-end/54114] variable-tracking performance regression from 4.8-20120610 to 4.8-20120701

[jimis at gmx dot net]

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

--- Comment #1 from jimis  2012-07-28 20:49:55 UTC ---
Sorry guys my machine died an ugly death, so the web interface for my profiling
runs is unfortunately offline. :-( From memory I remember that this regression
is more than 0.5s overhead out of ~5s. For more details I'll have to repair my
equipment.