date:20130423

On Tue, Apr 23, 2013 at 8:15 AM, Allan Sandfeld Jensen
carew...@gmail.com wrote:
 On Sunday 21 April 2013, Jonathan Wakely wrote:
 I'm starting to implement some new library features voted into C++14
 at the Bristol meeting and am wondering what feature check to use.

 Will there be a macro like _GXX_EXPERIMENTAL_CXX1Y__ to correspond to
 -std=c++1y?

 Alternatively we could set the value of __cplusplus to 201400L but I'm
 not sure that's strictly allowed.

 Isn't C++14 only an update of the standard library not the language,

As explained in numerous postings, that isn't the case.  See

   http://isocpp.org/blog/2013/04/trip-report-iso-c-spring-2013-meeting

-- Gaby

Re: Macro for C++14 support

On Tue, Apr 23, 2013 at 9:01 AM, Piotr Wyderski
piotr.wyder...@gmail.com wrote:
 Gabriel Dos Reis wrote:

 C++03 was essentially bug fixes to C++98 so we did not make the
 distinction.
 C++14 is more than bug fixes to C++11, it contains many new extensions.
 So I am unsure the situations are similar.

 Where can I find more about the upcoming standard? Google seems to be
 confused by a popular isotope of carbon... :-/

 Best regards, Piotr

Until WG21 releases the post-Bristol mailing, you can check

http://isocpp.org/blog/2013/04/trip-report-iso-c-spring-2013-meeting

In general, http://www.isocpp.org/ is the official website of WG21;
you can find more information there about C++ and more.

-- Gaby

Re: RFD: Should __builtin_constant_p approximate CONSTANT_P ?

2013-04-23 Thread Andi Kleen

Joern Rennecke joern.renne...@embecosm.com writes:

 More importantly. addresses that becomes a SYMBOL_REF should be considered
 constant.  I.e. In particular, the addresses of variables with static storage.
 I have a simple patch to recognize these as constants;
 do people agree that this is the right thing to do?

if someone writes

if (__builtin_constant_p(x)  x == 1) ... and assume the compiler can
collapse at compile time then a SYMBOL_REF wouldn't DTRT.
I've seen quite a bit such code. So I would prefer to accept only numbers known
at compile time already.

-Andi


-- 
a...@linux.intel.com -- Speaking for myself only

Re: Macro for C++14 support

Hi,

Gabriel Dos Reis g...@integrable-solutions.net ha scritto:

There appear to be two targets: C++14 and C++17.  Personally, I am
inclined
to have CXX14 and CXX1Y, where CXX1Y is for the presumed C++17 target.

This clarified - thanks - I'm wondering if it's safe to assume that the C++14 
library is a superset of the C++11 one: in that case passing -std=c++14 would 
also automatically define the C++11 macro and I see a tiny front-end patch 
going in followed by smooth progress in library. Otherwise - if -std=c++14 does 
*not* automatically define the C++11 macro too - we also need a ton of boring 
changes in the library, where things become wrapped in C++11 macro || C++14 
macro. Did I explain myself clearly enough?

Paolo

Re: RFD: Should __builtin_constant_p approximate CONSTANT_P ?

2013-04-23 Thread Joern Rennecke


Quoting Andi Kleen a...@firstfloor.org:


if (__builtin_constant_p(x)  x == 1) ... and assume the compiler can
collapse at compile time then a SYMBOL_REF wouldn't DTRT.


Unless you set x to the address of a variable / function and this is
constant-propagated, x will not become a SYMBOL_REF.
If x is a variable with static storage, it will be a MEM (symbol_ref).
x will be a SYMBOL_REF.

Re: Macro for C++14 support

Hi again,

Paolo Carlini paolo.carl...@oracle.com ha scritto:

Hi,

Gabriel Dos Reis g...@integrable-solutions.net ha scritto:

There appear to be two targets: C++14 and C++17.  Personally, I am
inclined
to have CXX14 and CXX1Y, where CXX1Y is for the presumed C++17 target.

This clarified - thanks - I'm wondering if it's safe to assume that the
C++14 library is a superset of the C++11 one: in that case passing
-std=c++14 would also automatically define the C++11 macro

Well, on second thought, I think we could do this anyway and be done in the 
wast majority of cases. Then, in special cases, where say the same facility is 
different in the two standards, we can always check both macros. I see now the 
issue mostly as a documentation issue: we would have to explain the users that 
-std=c++14 defines the C++11 macro too. This is *not* the same as -std=c++11 vs 
-std=c++98. If it's a problem, back to the huge searchreplace ;)

Paolo

setjmp/longjmp: Wrong code generation

2013-04-23 Thread Andreas Krebbel

Hi,

with GCC 4.1 and GCC 4.4 (RHEL 5.9) the example below prints a value
of 1 for netwait (on x86_64 and s390x).  The problem is that the
assignment at /* 2 */ is moved to /* 1 */ during instruction
scheduling.

The quick fix is to make netwait volatile.  But according to the C
standard (7.13.2.1) this should only be necessary if the value is
modified between setjmp and longjmp.

http://gcc.gnu.org/onlinedocs/gcc/Incompatibilities.html#Incompatibilities
shows an example which also modifies the variable between
setjmp/longjmp. However, a sentence in the same section is more
general and suggests to always use volatile: When you use setjmp and
longjmp, the only automatic variables guaranteed to remain valid are
those declared volatile.

I'm wondering whether the behaviour in the example below is accepted
and is supposed to be covered by the paragraph on the
incompatibilies page or whether we should try to fix this?  In the
end it is still a standard violation so I think we should?!

A possible fix might be to consider all function calls in the function
scope of setjmp to be full scheduling barriers.

I was not able to reproduce the problem with head GCC. But I couldn't
find anything which addresses the problem either.  So I assume that a
different situation before the scheduling pass hides the problem.

Bye,

-Andreas-


#include setjmp.h
#include stdio.h

jmp_buf jmpbuf;

void __attribute__((noinline))
  calls_longjmp()
{
  longjmp(jmpbuf, 2);
}

int __attribute__((noinline))
foo ()
{
  return 42;
}

void __attribute__((noinline))
bar (int netwait, int cnt)
{
  int i;
  int err;

  while (netwait)
{
  netwait = 0;

  for (i = cnt; --i = 0;)
{
  if (setjmp(jmpbuf) == 0)
{
  err = foo ();
  /* 1 */
  if (err != 2344)
calls_longjmp();
  netwait = 1; /* 2 */
}
  else
{
  printf (netwait: %d\n, netwait);
  netwait = 0;
}
}
}
} 

int
main ()
{
  bar (1, 1);
}

Re: Macro for C++14 support

2013-04-23 Thread Jonathan Wakely

On 23 April 2013 15:29, Paolo Carlini wrote:
 Hi,

 Gabriel Dos Reis g...@integrable-solutions.net ha scritto:

There appear to be two targets: C++14 and C++17.  Personally, I am
inclined
to have CXX14 and CXX1Y, where CXX1Y is for the presumed C++17 target.

 This clarified - thanks - I'm wondering if it's safe to assume that the C++14 
 library is a superset of the C++11 one: in that case passing -std=c++14 would 
 also automatically define the C++11 macro and I see a tiny front-end patch 
 going in followed by smooth progress in library. Otherwise - if -std=c++14 
 does *not* automatically define the C++11 macro too - we also need a ton of 
 boring changes in the library, where things become wrapped in C++11 macro || 
 C++14 macro. Did I explain myself clearly enough?

If the ~thread motion, N3636, passed then the C++11 and C++14
libraries are incompatible.

N3657 adds new member function overloads to existing library types,
but should do so in a backward-compatible way (that was the point of
the final revision of Joaquin's paper.)

But remember we no longer use __GXX_EXPERIMENTAL_CXX0X__ anyway, we
check __cplusplus = 201103L, and so within those chunks we could
additionally check for some C++14 macro.

Re: Macro for C++14 support

Hi,


Jonathan Wakely jwakely@gmail.com ha scritto:

But remember we no longer use __GXX_EXPERIMENTAL_CXX0X__ anyway, we
check __cplusplus = 201103L, and so within those chunks we could
additionally check for some C++14 macro.

Right, forgot that. Great. The = check we have got now makes things much 
easier in the C++11 - C++14 transition. Thus fine, just = 201103L + the macro 
is all we need.

Paolo

Re: Macro for C++14 support

On Tue, Apr 23, 2013 at 9:29 AM, Paolo Carlini paolo.carl...@oracle.com wrote:
 Hi,

 Gabriel Dos Reis g...@integrable-solutions.net ha scritto:

There appear to be two targets: C++14 and C++17.  Personally, I am
inclined
to have CXX14 and CXX1Y, where CXX1Y is for the presumed C++17 target.

 This clarified - thanks - I'm wondering if it's safe to assume that the C++14 
 library is a superset of the C++11 one: in that case passing -std=c++14 would 
 also automatically define the C++11 macro and I see a tiny front-end patch 
 going in followed by smooth progress in library. Otherwise - if -std=c++14 
 does *not* automatically define the C++11 macro too - we also need a ton of 
 boring changes in the library, where things become wrapped in C++11 macro || 
 C++14 macro. Did I explain myself clearly enough?

 Paolo



There was the drama about thread::~thread; I don't know how it was
finally resolved.
But I was under the impression that that issue and another from
library broke some
ABI.  Benjamin might have more information.

-- Gaby

Re: Macro for C++14 support

On Tue, Apr 23, 2013 at 9:47 AM, Jonathan Wakely jwakely@gmail.com wrote:

 But remember we no longer use __GXX_EXPERIMENTAL_CXX0X__ anyway,

yes, this was a great move; kudos to whoever did it.

 we
 check __cplusplus = 201103L, and so within those chunks we could
 additionally check for some C++14 macro.

Agreed.

-- Gaby

Re: Macro for C++14 support

2013-04-23 Thread Jonathan Wakely

On 23 April 2013 15:54, Gabriel Dos Reis wrote:
 On Tue, Apr 23, 2013 at 9:47 AM, Jonathan Wakely jwakely@gmail.com 
 wrote:

 But remember we no longer use __GXX_EXPERIMENTAL_CXX0X__ anyway,

 yes, this was a great move; kudos to whoever did it.

That was Jason, when he changed the front end to set __cplusplus correctly.

Re: setjmp/longjmp: Wrong code generation

2013-04-23 Thread Florian Weimer


On 04/23/2013 04:45 PM, Andreas Krebbel wrote:

I was not able to reproduce the problem with head GCC. But I couldn't
find anything which addresses the problem either.  So I assume that a
different situation before the scheduling pass hides the problem.


The fix for PR56982 might address this one in a reliable fashion, too.

--
Florian Weimer / Red Hat Product Security Team

[GSoC] Does this proposal look good?

2013-04-23 Thread Tim Shen

I've made a proposal under the guide of application. Is it detailed
and realistic?

By the way, here is a naive version of my implementation of
lookup_name in regex_traits :
https://gist.github.com/innocentim/5445457

It's not GCC style but will be, if everything else's fine. So, am I in
the right direction?

Thanks!

--
Tim Shen
Completing C++11 regex

* The Project

This proposal aims to implement regex interfaces required by the C++11 standard
as much as the student can.
Besides, I get a clear status
here(http://stackoverflow.com/questions/12530406/is-gcc4-7-buggy-about-regular-expressions)
and here(http://gcc.gnu.org/bugzilla/show%5C_bug.cgi?id=53631) :)

* Goal

To finish:

regex_traits
format in match_results
regex_iterator
regex_token_iterator
different styles in basic_regex

* Time-line

May 27 - June 30
Read basic regex and regex nfa, try submit small patches, get familiar with GCC
workflow, coding and documenting style

July 1 - July 7
Complete regex traits

July 8 - July 14
Implement format in match results

July 15 - July 21
Implement regex iterator

July 22 - July 28
Implement regex token iterator

July 29 - Aug 31
Implement different styles(basic, extended, awk, grep and egrep)

Sep 1 - Sep 16
Undefined so far. Must have some ideas at that time.

* Details

** regex_traits
Not tough. However on how to implement transform_primary for all platform, I
need to ask in the mail list or ask the mentor.

** Format string, iterators
Shouldn't be tough. This is a deeper practicing.

** Different regex styles
It's the core part. I should already know anything about basic_regex and
regex_nfa(even have made changes, I'm very interested in algorithms of
compiling to NFA/DFAs and executing approaches). Then get to know all flavors
of regular expressions. My experiences of compilers may help.

How do I modify SSA and copy basic blocks?

2013-04-23 Thread Steve Ellcey

I decided to take a crack at the coremark optimization (PR 54742) for switch
statements.  Since I couldn't figure out the existing jump threading
optimization enough to extend it properly, I decided to try a plugin
optimization pass just for this case and see if I could get that to work.

The basic idea is to find a path from where a variable is assigned a constant
value to where that variable is used in a switch statement.  Then I want to
duplicate the blocks in that path (thus removing any alternative entry points
into the path that may give the variable a different value) and plug it into
the cfg.

I think I have code that finds the path that I am interested in, but when
I try to use copy_bbs to copy the basic blocks in order to create my new path,
I get segfaults.  I was wondering if anyone could help me understand what I
need to do, in addition to calling copy_bbs, to create my new path and keep
the various ssa and cfg information up to date, either by modifying it or by
blowing it away and regenerating it, I am not worried about compilation speed
at this point so if regenerating all the SSA/cfg data is easiest, I am happy
to do that.

Attached is my plugin as it exists right now and a simple test case using a
switch statement.  I am not including the actual coremark code because it is
copyrighted.  If you run my example you will see output showing 4 places where
I think I can do my optimization.  For example we assign t the value of 0 in
block 2 and from there we go to block 8 and (possibly) to block 3 where we have
our switch statement.

So what I try to do is copy blocks 8 and 3 and change the edge from block
2 to block 8 to go from block 2 to my new copy of block 8 which should
then go to the new copy of block 3.  After this we should be able to
optimize the new copy of block 3 to finish with a goto to the 'case 0'
label instead of with a switch/goto.

If you remove the '#if 0' in my code where I comment out the call to
copy_bbs, you will get a seg fault, this is the code that I need help
with.  For example, If I copy block 8 and block 3, and there is an edge
from 8 to 3, does copy_bbs automatically create a new edge pointing from the
copy of block 8 to block 3 and replace that in the copied blocks?  I think it
does, but I am not sure. 

Steve Ellcey
sell...@imgtec.com



Output from the test program using my new optimization phase.

In plugin, registering new pass
Block 2 assigns variable t a constant value of 0
Basic blocks (leading from basic block 2 to switch) are:
  8
  3
Block 4 assigns variable t a constant value of 1
Basic blocks (leading from basic block 4 to switch) are:
  7
  8
  3
Block 5 assigns variable t a constant value of 2
Basic blocks (leading from basic block 5 to switch) are:
  7
  8
  3
Block 6 assigns variable t a constant value of 1
Basic blocks (leading from basic block 6 to switch) are:
  7
  8
  3

/* This file implements an optimization where, when a variable is set
   to a constant value and there is a path that leads from this definition
   to a switch statement that uses that variable as its controlling expression
   we duplicate the blocks on this path and change the switch goto to a
   direct goto to the label of the switch block that control would goto based
   on the value of the variable.  */

#include gcc-plugin.h
#include plugin-version.h
#include tree-pass.h
#include tree.h
#include tree-flow.h
#include tree-flow-inline.h
#include basic-block.h
#include pointer-set.h
#include gimple.h

int plugin_is_GPL_compatible;

/* Helper function for find_path, visited_bbs is used to make sure we don't
   fall into an infinite loop.  */

static int
find_path_1(basic_block start_bb, basic_block end_bb, struct pointer_set_t *visited_bbs)
{
  edge_iterator ei;
  edge e;

  if (start_bb == end_bb) return 1;
  if (!pointer_set_insert (visited_bbs, start_bb))
{
  FOR_EACH_EDGE (e, ei, start_bb-succs)
	if (find_path_1 (e-dest, end_bb, visited_bbs)) return 1;
}
return 0;
}

/* Return 1 if there is a path from start_bb to end_bb and 0 if there
   is not.  */

static int
find_path(basic_block start_bb, basic_block end_bb)
{
  edge_iterator ei;
  edge e;
  struct pointer_set_t *visited_bbs;
  int p = 0;

  if (start_bb == end_bb) return 1;

  visited_bbs = pointer_set_create ();
  if (!pointer_set_insert (visited_bbs, start_bb))
{
  FOR_EACH_EDGE (e, ei, start_bb-succs)
	if (find_path_1 (e-dest, end_bb, visited_bbs))
	  {
	p = 1;
	break;
	  }
}
  pointer_set_destroy (visited_bbs);
  return p;
}

/* bbs_list[0] is the block with the switch statement,
   bbs_list[n-1] is the block where the switch statement variable is assigned
 a constant value,
   The entries in between make a (reverse) path between the two.

   We don't want to copy bb_list[n-1], we want to leave that alone and
   copy bb_list[n-2]...bb_list[0], and change the edge from bb_list[n-1]
   to bb_list[n-2] to point to the copy of bb_list[n-2].  Then we 
   should change the

Re: How do I modify SSA and copy basic blocks?

2013-04-23 Thread Jeff Law


On 04/23/2013 02:43 PM, Steve Ellcey wrote:


I think I have code that finds the path that I am interested in, but when
I try to use copy_bbs to copy the basic blocks in order to create my new path,
I get segfaults.  I was wondering if anyone could help me understand what I
need to do, in addition to calling copy_bbs, to create my new path and keep
the various ssa and cfg information up to date, either by modifying it or by
blowing it away and regenerating it, I am not worried about compilation speed
at this point so if regenerating all the SSA/cfg data is easiest, I am happy
to do that.
Well, you have to copy the blocks, adjust the edges and rewrite the SSA 
graph.  I'd use duplicate_block to help.


You really want to look at tree-ssa-threadupdate.c.  There's a nice big 
block comment which gives the high level view of what needs to happen 
when you copy a block for this kind of optimization.  Feel free to 
ignore the implementation which has to be fairly efficient when there's 
a large number of edges to update.


Jeff

std::count leaked outside namespace std?

2013-04-23 Thread bd satish

Hi,

Here's a simple program:

#include algorithm
#include vector

int main()
{
  std::vectorint  vec;
  count(vec.begin(), vec.end(), 0);   // shouldn't this be std::count ?
}

The above compiles successfully, but I think it shouldn't. I expect a
message like error: `count` not declared in scope because I meant to
say std::count. Isn't this a bug, or am I missing something?

Behaviour is reproducible with both GCC 4.7 and 4.8.

PS: I'm not subscribed to mailing list, please keep me in cc.

Thanks,
Satish

Re: std::count leaked outside namespace std?


On 04/23/2013 11:26 PM, bd satish wrote:

Hi,

Here's a simple program:

#include algorithm
#include vector

int main()
{
   std::vectorint  vec;
   count(vec.begin(), vec.end(), 0);   // shouldn't this be std::count ?
}

The above compiles successfully, but I think it shouldn't. I expect a
message like error: `count` not declared in scope because I meant to
say std::count. Isn't this a bug, or am I missing something?

You are: https://en.wikipedia.org/wiki/Argument-dependent_name_lookup

Paolo.

Re: std::count leaked outside namespace std?

2013-04-23 Thread bd satish

Thanks Paolo, ADL is news to me.


On 24 April 2013 01:43, Paolo Carlini paolo.carl...@oracle.com wrote:
 You are: https://en.wikipedia.org/wiki/Argument-dependent_name_lookup

 Paolo.

RE: std::count leaked outside namespace std?

2013-04-23 Thread Nathan Ridge

 Here's a simple program:

 #include algorithm
 #include vector

 int main()
 {
 std::vectorint vec;
 count(vec.begin(), vec.end(), 0); // shouldn't this be std::count ?
 }

 The above compiles successfully, but I think it shouldn't. I expect a
 message like error: `count` not declared in scope because I meant to
 say std::count. Isn't this a bug, or am I missing something?

It is not a bug. std::count is being found by argument-dependent lookup [1].

Regards,
Nate

[1] http://en.wikipedia.org/wiki/Argument-dependent_name_lookup

[Bug target/55445] Always defined SEH when build from trunk

2013-04-23 Thread ktietz at gcc dot gnu.org



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



--- Comment #5 from Kai Tietz ktietz at gcc dot gnu.org 2013-04-23 07:25:49 
UTC ---

*** Bug 57040 has been marked as a duplicate of this bug. ***

[Bug target/57040] SEH Exception defined is conflicted with SJLJ Exception within several files

2013-04-23 Thread ktietz at gcc dot gnu.org



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



Kai Tietz ktietz at gcc dot gnu.org changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 CC||ktietz at gcc dot gnu.org

 Resolution||DUPLICATE



--- Comment #1 from Kai Tietz ktietz at gcc dot gnu.org 2013-04-23 07:25:49 
UTC ---

This issue is a dup.  It seems that Ada is the only code-path still having this

error, but anyway it isn't helpful to open n-times a bug report for the same

issue.



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

[Bug c++/56895] [4.8/4.9 Regression] ICE: unexpected expression of kind arrow_expr

2013-04-23 Thread Woebbeking at web dot de


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

André Wöbbeking Woebbeking at web dot de changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #17 from André Wöbbeking Woebbeking at web dot de 2013-04-23 
08:07:27 UTC ---
Thanks!

[Bug middle-end/57026] [4.9 Regression] ice: SSA corruption



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



Richard Biener rguenth at gcc dot gnu.org changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #4 from Richard Biener rguenth at gcc dot gnu.org 2013-04-23 
08:08:55 UTC ---

Author: rguenth

Date: Tue Apr 23 08:08:25 2013

New Revision: 198175



URL: http://gcc.gnu.org/viewcvs?rev=198175root=gccview=rev

Log:

2013-04-23  Richard Biener  rguent...@suse.de



PR tree-optimization/57026

* tree-vrp.c (simplify_conversion_using_ranges): Do not propagate

from SSA names occuring in abnormal PHI nodes.



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



Added:

trunk/gcc/testsuite/gcc.dg/torture/pr57026.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/testsuite/ChangeLog

trunk/gcc/tree-vrp.c

[Bug c++/57041] New: ICE in lookup_field_1, at cp/search.c:376 (with dot-prefixed structure initialisation)

2013-04-23 Thread slayoo at staszic dot waw.pl



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



 Bug #: 57041

   Summary: ICE in lookup_field_1, at cp/search.c:376 (with

dot-prefixed structure initialisation)

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: sla...@staszic.waw.pl





Hi,





$ cat bug.cpp 

#include map

#include string



template class T

void setopts(T p)

{

  p.outvars = {{0, {.name = psi, .unit = 1}}};

}



int main()

{

  struct 

  {

struct info { std::string name, unit; };

std::mapint, info outvars;

  } p;

  setopts(p);

}







$ /usr/lib/gcc-snapshot/bin/g++ -std=c++11 bug.cpp 

bug.cpp: In instantiation of 'void setopts(T) [with T = main()::anonymous

struct]':

bug.cpp:17:12:   required from here

bug.cpp:7:13: error: 'name' was not declared in this scope

   p.outvars = {{0, {.name = psi, .unit = 1}}};

 ^

bug.cpp:7:13: error: 'unit' was not declared in this scope

bug.cpp:7:13: internal compiler error: in lookup_field_1, at cp/search.c:376

Please submit a full bug report,

with preprocessed source if appropriate.

See file:///usr/share/doc/gcc-snapshot/README.Bugs for instructions.

Preprocessed source stored into /tmp/ccLInnuE.out file, please attach this to

your bugreport.







$ /usr/lib/gcc-snapshot/bin/g++ --version

g++ (Debian 20130209-1) 4.8.0 20130209 





Clang compiles it with no warnings or errors.



HTH,

Sylwester

[Bug c++/57041] ICE in lookup_field_1, at cp/search.c:376 (with dot-prefixed structure initialisation)



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



Marek Polacek mpolacek at gcc dot gnu.org changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-04-23

 CC||mpolacek at gcc dot gnu.org

   Target Milestone|--- |4.9.0

 Ever Confirmed|0   |1

  Known to fail||4.8.0, 4.9.0



--- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org 2013-04-23 
08:56:52 UTC ---

Confirmed.

[Bug c++/57041] [4.7/4.8 Regression] ICE in lookup_field_1, at cp/search.c:376 (with dot-prefixed structure initialisation)



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



Jakub Jelinek jakub at gcc dot gnu.org changed:



   What|Removed |Added



 CC||jakub at gcc dot gnu.org,

   ||jason at gcc dot gnu.org

Summary|ICE in lookup_field_1, at   |[4.7/4.8 Regression] ICE in

   |cp/search.c:376 (with   |lookup_field_1, at

   |dot-prefixed structure  |cp/search.c:376 (with

   |initialisation) |dot-prefixed structure

   ||initialisation)



--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2013-04-23 
09:41:49 UTC ---

Reduced testcase:

namespace std

{

  template class T1, class T2

  struct pair

  {

T1 first;

T2 second;

  };

  template class T

  struct initializer_list

  {

  };

  template typename T1, typename T2

  struct map

  {

map () {}

map (initializer_list pair T1, T2 l) {}

  };

}

template class T

void

foo (T p)

{

  p.v = { { 0, { .a = 0, .b = 1 } } };

}

int

main ()

{

  struct { struct A { int a, b; }; std::map int, A v; } p;

  foo (p);

}



Started to ICE with http://gcc.gnu.org/r176530 .

[Bug middle-end/57003] gcc-4.8.0 breaks -O2 optimization with Wine(64) - links/info/bisect of commits included

2013-04-23 Thread kirill.k.smirnov at math dot spbu.ru



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



Kirill Smirnov kirill.k.smirnov at math dot spbu.ru changed:



   What|Removed |Added



 CC||kirill.k.smirnov at math

   ||dot spbu.ru



--- Comment #7 from Kirill Smirnov kirill.k.smirnov at math dot spbu.ru 
2013-04-23 09:44:03 UTC ---

It seems gcc over-optimizes series of memcpy() function calls one after

another. The piece of code does not work:



memcpy( buffer, DIR_Windows, len * sizeof(WCHAR) );

memcpy( buffer + len, default_syswow64W, sizeof(default_syswow64W)



There is a wrapper around memcpy() called memcpy_unaligned() to avoid

builtin/inlining.

And these pieces of code work:



memcpy( buffer, DIR_Windows, len * sizeof(WCHAR) );

memcpy_unaligned( buffer + len, default_syswow64W, sizeof(default_syswow64W) );



and



memcpy_unaligned( buffer, DIR_Windows, len * sizeof(WCHAR) );

memcpy( buffer + len, default_syswow64W, sizeof(default_syswow64W) );



I'm sorry for copy-and-pasting wine code as is, I tried but failed to create a

refined test case.





So this case is opposite as previously suggested: the memcpy_unaligned()

wrapper is OK, but native memcpy() is failing.

[Bug middle-end/57003] gcc-4.8.0 breaks -O2 optimization with Wine(64) - links/info/bisect of commits included



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



Jakub Jelinek jakub at gcc dot gnu.org changed:



   What|Removed |Added



 CC||jakub at gcc dot gnu.org



--- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2013-04-23 
09:51:23 UTC ---

The important question is what that

   memcpy( buffer, DIR_Windows, len * sizeof(WCHAR) );

   memcpy( buffer + len, default_syswow64W, sizeof(default_syswow64W) );

compiles to.  If it is

...

call memcpy

leal (%rax, ...), %rdi ! or similar, the important is that buffer is preserved

in return value of the previous memcpy call

...

call memcpy

Then if it doesn't work, you need to look at whatever memcpy implementation you

are calling and see whether it correctly returns the first argument it has been

passed to it in all cases.

[Bug middle-end/56988] ipa-cp incorrectly propagates a field of an aggregate

2013-04-23 Thread jamborm at gcc dot gnu.org



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



Martin Jambor jamborm at gcc dot gnu.org changed:



   What|Removed |Added



  Known to work||4.7.3

  Known to fail||4.8.0, 4.9.0



--- Comment #4 from Martin Jambor jamborm at gcc dot gnu.org 2013-04-23 
10:05:00 UTC ---

The 4.8 patch is the same except the ipa_get_indirect_edge_target_1

hunk because that code is not present on the branch.

[Bug c++/57041] [4.7/4.8/4.9 Regression] ICE in lookup_field_1, at cp/search.c:376 (with dot-prefixed structure initialisation)



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



--- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org 2013-04-23 
10:06:37 UTC ---

lookup_field_1 instead of IDENTIFIER_NODE gets the error_mark_node, and the

following assert chokes on it:

  gcc_assert (identifier_p (name));



It seems that if we just return NULL_TREE in that case, everything is fine.



--- a/gcc/cp/search.c

+++ b/gcc/cp/search.c

@@ -381,7 +381,7 @@ lookup_field_1 (tree type, tree name, bool want_type)

 {

   tree field;



-  gcc_assert (identifier_p (name));

+  gcc_assert (identifier_p (name) || name == error_mark_node);



   if (TREE_CODE (type) == TEMPLATE_TYPE_PARM

   || TREE_CODE (type) == BOUND_TEMPLATE_TEMPLATE_PARM

[Bug fortran/57042] New: ICE/Segfault with -fdump-parse-tree

2013-04-23 Thread burnus at gcc dot gnu.org



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



 Bug #: 57042

   Summary: ICE/Segfault with -fdump-parse-tree

Classification: Unclassified

   Product: gcc

   Version: 4.9.0

Status: UNCONFIRMED

  Keywords: ice-on-valid-code

  Severity: normal

  Priority: P3

 Component: fortran

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: bur...@gcc.gnu.org





use iso_fortran_env; print *, real_kinds ; end



fails with:

f951: internal compiler error: Segmentation fault

0x9a43af crash_signal

../../gcc/toplev.c:332

0x56e974 show_typespec

../../gcc/fortran/dump-parse-tree.c:113

[Bug libstdc++/57043] New: converting overloaded complex function pow in C++11 is ambiguous

2013-04-23 Thread frederic.hecht at upmc dot fr


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

 Bug #: 57043
   Summary: converting overloaded complex function pow in C++11 is
ambiguous
Classification: Unclassified
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: frederic.he...@upmc.fr


problem template the code is trivial 2 lines:
do not  compile in version 4.9, 4.8.1 4.9  with 
/usr/local/bin/g++ -v -save-temps -std=c++11 -c bugcc.cpp 

the code: 

#include complex 
std::complexdouble  (* powcc  )( const  std::complexdouble  , const
std::complexdouble  ) =std::pow;

the output is 

COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.8.3' '-v' '-save-temps'
'-std=c++11' '-c' '-shared-libgcc' '-mtune=core2'
 /usr/local/libexec/gcc/x86_64-apple-darwin12.3.0/4.8.1/cc1plus -fpreprocessed
bugcc.ii -fPIC -quiet -dumpbase bugcc.cpp -mmacosx-version-min=10.8.3
-mtune=core2 -auxbase bugcc -std=c++11 -version -o bugcc.s
GNU C++ (GCC) version 4.8.1 20130404 (prerelease) (x86_64-apple-darwin12.3.0)
compiled by GNU C version 4.8.1 20130404 (prerelease), GMP version 4.3.1,
MPFR version 2.4.1, MPC version 0.8.1
heuristiques GGC: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (GCC) version 4.8.1 20130404 (prerelease) (x86_64-apple-darwin12.3.0)
compiled by GNU C version 4.8.1 20130404 (prerelease), GMP version 4.3.1,
MPFR version 2.4.1, MPC version 0.8.1
heuristiques GGC: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 848d439cd6121247863767d4caeedace
bugcc.cpp:2:100: erreur: converting overloaded function ‘pow’ to type ‘struct
std::complexdouble (*)(const struct std::complexdouble, const struct
std::complexdouble)’ is ambiguous
 std::complexdouble  (* powcc  )( const  std::complexdouble  , const
std::complexdouble  ) =std::pow;
   
^
In file included from bugcc.cpp:1:0:
/usr/local/include/c++/4.8.1/complex:1023:5: note: candidats sont:
std::complex_Tp std::pow(const std::complex_Tp, const std::complex_Tp)
[with _Tp = double]
 pow(const complex_Tp __x, const complex_Tp __y)
 ^
In file included from bugcc.cpp:1:0:
/usr/local/include/c++/4.8.1/complex:1871:5: note:
std::complextypename __gnu_cxx::__promote_2_Tp, _Up::__type std::pow(const
std::complex_Tp, const std::complex_Up) [with _Tp = double; _Up = double;
typename __gnu_cxx::__promote_2_Tp, _Up::__type = double]
 pow(const std::complex_Tp __x, const std::complex_Up __y)
 ^

[Bug c++/57044] New: The following code won't compile with -std=c++0x



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



 Bug #: 57044

   Summary: The following code won't compile with -std=c++0x

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: major

  Priority: P3

 Component: c++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: pber...@yahoo.com





The following code causes a GCC internal error Segmentation fault:



class myclass

{

public:

   templatetypename T_

   inline explicit myclass(T_ *s)

   {

  char buf[mylib::someclass::some_const]; // this line causes the fault

  // ... do something useful with buf

   }



   ...  

};



// somewhere else:

nemaspace mylib

{

   class someclass

   {

   public:

  static const uint32_t some_const;

   }

}



// other info:

all GCC versions from 4.5.3 and below compile that code fine. Not tested with

other gcc versions before 4.7.2.

compile flags are CXXFLAGS=-g -O0 -pipe -std=c++0x



Thank you.

[Bug go/57045] New: Build failure in libgo/runtime/proc.c: error: ‘({anonymous})’ may be used uninitialized in this function

2013-04-23 Thread ubizjak at gmail dot com


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

 Bug #: 57045
   Summary: Build failure in libgo/runtime/proc.c: error:
‘({anonymous})’ may be used uninitialized in this
function
Classification: Unclassified
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
AssignedTo: i...@airs.com
ReportedBy: ubiz...@gmail.com
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
 Build: x86_64-pc-linux-gnu


Building libgo on Centos 5.9 fails in proc.c due to warning promoted to error:

../../../gcc-svn/trunk/libgo/runtime/proc.c: In function
‘runtime_entersyscall’:
../../../gcc-svn/trunk/libgo/runtime/proc.c:1414:12: error: ‘({anonymous})’ may
be used uninitialized in this function [-Werror=maybe-uninitialized]
  getcontext(g-gcregs);
^

../../../gcc-svn/trunk/libgo/runtime/proc.c: In function ‘__go_go’:
../../../gcc-svn/trunk/libgo/runtime/proc.c:1608:13: error: ‘({anonymous})’ may
be used uninitialized in this function [-Werror=maybe-uninitialized]
   getcontext(vnewg-context);
 ^

[Bug go/57045] Build failure in libgo/runtime/proc.c: error: ‘({anonymous})’ may be used uninitialized in this function



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



Richard Biener rguenth at gcc dot gnu.org changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-04-23

 Ever Confirmed|0   |1



--- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2013-04-23 
10:36:14 UTC ---

Reported on the ml as well, caused by extra abnormal edges into getcontext.

[Bug c/57036] ice in update_ssa_across_abnormal_edges



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



Richard Biener rguenth at gcc dot gnu.org changed:



   What|Removed |Added



 Status|UNCONFIRMED |ASSIGNED

   Last reconfirmed||2013-04-23

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

   |gnu.org |

 Ever Confirmed|0   |1



--- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2013-04-23 
10:36:40 UTC ---

I will have a look.

[Bug c++/57044] The following code won't compile



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



--- Comment #1 from Piergiorgio Beruto pberuto at yahoo dot com 2013-04-23 
10:36:46 UTC ---

Work Around is the following (add an intermediate const variable):



templatetypename T_

inline explicit myclass(T_ *s)

{

   const uint32_t sz = mylib::someclass::some_const;

   char buf[sz];



   // ... do something useful with buf

}

[Bug c++/57044] The following code won't compile



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



Jonathan Wakely redi at gcc dot gnu.org changed:



   What|Removed |Added



 Status|UNCONFIRMED |WAITING

   Last reconfirmed||2013-04-23

 Ever Confirmed|0   |1

   Severity|major   |normal



--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2013-04-23 
10:38:27 UTC ---

Please read http://gcc.gnu.org/bugs



Is this really what you're compiling?

nemaspace and ... should not be there and uint32_t is not declared.



Please provide the *real* source you're compiling, as well as the output of

'g++ -v'





When I fix those obvious errors in your code I get a correct diagnostic with no

segfault from G++ 4.7.2



c.cc: In constructor 'myclass::myclass(T_*)':

c.cc:7:16: error: 'mylib' has not been declared

[Bug c/57046] New: wrong code generated by gcc 4.8.0 on i686

2013-04-23 Thread mattiase at acm dot org



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



 Bug #: 57046

   Summary: wrong code generated by gcc 4.8.0 on i686

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: matti...@acm.org





Created attachment 29917

  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29917

Test case including driver demonstrating the bug



Gcc 4.8.0 silently miscompiles the attached short test case (emac.c) on 32-bit

x86 with -O2. It appears that the value returned from get_value is thrown away.



gcc -V output:

Using built-in specs.

COLLECT_GCC=/usr/local/gcc/4.8.0/bin/gcc

COLLECT_LTO_WRAPPER=/home/local/linux/gcc/4.8.0/bin/../libexec/gcc/i686-pc-linux-gnu/4.8.0/lto-wrapper

Target: i686-pc-linux-gnu

Configured with: ../gcc-4.8.0/configure --prefix=/usr/local/gcc/4.8.0

--with-mpc=/tmp/extra --with-gmp=/tmp/extra --with-mpfr=/tmp/extra

--with-isl=/tmp/extra --with-cloog=/tmp/extra

--with-as=/usr/local/binutils/2.23.2/bin/as

--with-ld=/usr/local/binutils/2.23.2/bin/ld.gold

--enable-languages=c,c++,objc,go

Thread model: posix

gcc version 4.8.0 (GCC)

[Bug c++/57044] The following code won't compile



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



--- Comment #3 from Piergiorgio Beruto pberuto at yahoo dot com 2013-04-23 
10:48:19 UTC ---

(In reply to comment #2)

 Please read http://gcc.gnu.org/bugs

 

 Is this really what you're compiling?

 nemaspace and ... should not be there and uint32_t is not declared.

 

 Please provide the *real* source you're compiling, as well as the output of

 'g++ -v'

 

 

 When I fix those obvious errors in your code I get a correct diagnostic with 
 no

 segfault from G++ 4.7.2

 

 c.cc: In constructor 'myclass::myclass(T_*)':

 c.cc:7:16: error: 'mylib' has not been declared



Ok sorry I'm new to GCC bugzilla, If you need real code I'll provide it.

[Bug c++/57044] The following code won't compile



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



--- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2013-04-23 
10:54:49 UTC ---

(In reply to comment #3)

 Ok sorry I'm new to GCC bugzilla, If you need real code I'll provide it.



That's why you should read http://gcc.gnu.org/bugs



It explains what we need.

[Bug c/57036] ice in update_ssa_across_abnormal_edges



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



--- Comment #2 from Richard Biener rguenth at gcc dot gnu.org 2013-04-23 
11:06:50 UTC ---

Reduced testcase:



extern void g (void);

extern __inline __attribute__ ((__always_inline__,__leaf__))

f ()

{

  g ();

}

struct __jmp_buf_tag *b;

int jpgDecode_convert (unsigned i)

{

  if (i != 0)

f ();

  read_buf_open ();

  return _setjmp (b);

}



marking 'g' leaf as well fixes the ICE.



The inliner doesn't handle new abnormal edges appearing this way from

a 'leaf' function which isn't considered as possibly causing abnormal

goto edges.



I suppose all these setjmp ICEs are latent with carefully constructed

non-local goto testcases.

[Bug c++/57043] converting overloaded complex function pow in C++11 is ambiguous



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



Jonathan Wakely redi at gcc dot gnu.org changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-04-23

  Component|libstdc++   |c++

  Known to work||4.6.3

 Ever Confirmed|0   |1

  Known to fail||4.7.3, 4.8.0, 4.9.0



--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2013-04-23 
11:12:21 UTC ---

I think this is a front-end issue, the following compiles OK with G++ 4.6,

Clang 3.3 and ICC 13, but not G++ 4.7+ (in c++98 or c++11 mode)





templatetypename D struct complex { };



templatetypename Tp

inline complexTp

pow(const complexTp x, const complexTp y)

{ return x; }



templatetypename T, typename U

struct promote_2

{

typedef T type;

};



templatetypename Tp, typename Up

inline complextypename promote_2Tp, Up::type

pow(const complexTp x, const complexUp y)

{ return x; }





complexdouble (*powcc)(const complexdouble, const complexdouble) = pow;

[Bug go/57045] Build failure in libgo/runtime/proc.c: error: ‘({anonymous})’ may be used uninitialized in this function

2013-04-23 Thread ubizjak at gmail dot com



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



--- Comment #2 from Uros Bizjak ubizjak at gmail dot com 2013-04-23 11:20:09 
UTC ---

(In reply to comment #1)

 Reported on the ml as well, caused by extra abnormal edges into getcontext.



http://gcc.gnu.org/ml/gcc-patches/2013-04/msg01186.html

[Bug middle-end/57036] [4.9 Regression] ice in update_ssa_across_abnormal_edges



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



Richard Biener rguenth at gcc dot gnu.org changed:



   What|Removed |Added



 CC||hubicka at gcc dot gnu.org

  Component|c   |middle-end

 Blocks||56982

   Target Milestone|--- |4.9.0

Summary|ice in  |[4.9 Regression] ice in

   |update_ssa_across_abnormal_ |update_ssa_across_abnormal_

   |edges   |edges



--- Comment #3 from Richard Biener rguenth at gcc dot gnu.org 2013-04-23 
11:27:49 UTC ---

Closest equivalent non-local goto testcase that ICEs:



int j_;

int jpgDecode_convert (unsigned i)

{

  __label__ label;

  int j;



  inline void __attribute__((always_inline,leaf)) f(void)

  {

 g();

  }



  void __attribute__((noinline)) read_buf_open (void)

  {

goto label;

  }



  if (i != 0)

f ();

  j = j_;

  read_buf_open ();

label:

  return j;

}



 ./cc1 -quiet -O0 t.i

t.i: In function 'jpgDecode_convert':

t.i:23:1: error: definition in block 4 does not dominate use in block 7

 }

 ^

for SSA_NAME: j_2 in statement:

_3 = j_2;

t.i:23:1: internal compiler error: verify_ssa failed



same underlying issue I believe.

[Bug c/57046] wrong code generated by gcc 4.8.0 on i686

2013-04-23 Thread mikpe at it dot uu.se



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



--- Comment #1 from Mikael Pettersson mikpe at it dot uu.se 2013-04-23 
11:31:06 UTC ---

Created attachment 29918

  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29918

Single-file test case.



I can reproduce the wrong-code on x86_64-linux with gcc 4.9-20130421 and

4.8-20130418, using -m32 -O2 -Wall.  gcc 4.7 and 4.6 generate correct code.

[Bug middle-end/57036] [4.9 Regression] ice in update_ssa_across_abnormal_edges



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



--- Comment #4 from Richard Biener rguenth at gcc dot gnu.org 2013-04-23 
11:32:08 UTC ---

Either don't inline into functions receiving non-local gotos or remove

the ECF_LEAF handling from the call-may-do-longjmp predicate.

[Bug c++/57034] ternary operator with float infinity in O0

2013-04-23 Thread christopher.hite at jpmorgan dot com



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



--- Comment #4 from Christopher Hite christopher.hite at jpmorgan dot com 
2013-04-23 11:35:25 UTC ---

64-bit.



Thanks for pointing out I was converting to float and back.  Both of the

following work:

int32_t z3=(qFuture = double(MAX) ? MAX : double(qFuture) );  //works

int32_t z4=(qFuture = double(MAX) ? MAX : int32_t(qFuture) );  // works



The following also works:

int32_t z5=(qFuture = MAX ? MAX : int32_t(qFuture) );  //works



which seems to contradict what you were saying that if the integral value can't

be perfectly represented by the float it fails.



const float   fMAX=std::numeric_limitsint32_t::max();

(gdb) fMAX = 2.14748365e+09



Is this bad code?  Should I convert to double before float?  What about larger

ints?



All I'm tring to do is convert float to int clipping at max int.  What's the

best way to do it?  Can I calculate the highest float that is convertible to an

int?  Or do I have to check that the conversion fails.

[Bug middle-end/57036] [4.9 Regression] ice in update_ssa_across_abnormal_edges



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



--- Comment #5 from Richard Biener rguenth at gcc dot gnu.org 2013-04-23 
11:56:47 UTC ---

One idea was to mark calls with whether they may induce abnormal control flow

and when inlining, do not make abnormal edges off any calls in the function.

We still have to copy existing abnormal edges as within the callee there can

be abnormal control flow, too.  So there will be no way to later verify CFG

correctness because we lose scoping information of abnormal control flow.



Thus, the following simple patch is probably as good as we can get here ...

(in testing).



@@ -1866,7 +1870,8 @@ update_ssa_across_abnormal_edges (basic_

debug stmts are left after a statement that must end the basic block.  */



 static bool

-copy_edges_for_bb (basic_block bb, gcov_type count_scale, basic_block ret_bb)

+copy_edges_for_bb (basic_block bb, gcov_type count_scale, basic_block ret_bb,

+  bool can_make_abnormal_goto)

 {

   basic_block new_bb = (basic_block) bb-aux;

   edge_iterator ei;

@@ -1921,7 +1926,11 @@ copy_edges_for_bb (basic_block bb, gcov_

  into a COMPONENT_REF which doesn't.  If the copy

  can throw, the original could also throw.  */

   can_throw = stmt_can_throw_internal (copy_stmt);

-  nonlocal_goto = stmt_can_make_abnormal_goto (copy_stmt);

+  /* If the call we inline cannot make abnormal goto do not add

+ additional abnormal edges but only retain those already present

+in the original function body.  */

+  nonlocal_goto

+   = can_make_abnormal_goto  stmt_can_make_abnormal_goto (copy_stmt);



   if (can_throw || nonlocal_goto)

{

@@ -2270,10 +2279,12 @@ copy_cfg_body (copy_body_data * id, gcov

   last = last_basic_block;



   /* Now that we've duplicated the blocks, duplicate their edges.  */

+  bool can_make_abormal_goto = stmt_can_make_abnormal_goto (id-gimple_call);

   FOR_ALL_BB_FN (bb, cfun_to_copy)

 if (!blocks_to_copy

 || (bb-index  0  bitmap_bit_p (blocks_to_copy, bb-index)))

-  need_debug_cleanup |= copy_edges_for_bb (bb, count_scale,

exit_block_map);

+  need_debug_cleanup |= copy_edges_for_bb (bb, count_scale,

exit_block_map,

+  can_make_abormal_goto);



   if (new_entry)

 {

[Bug c++/57034] ternary operator with float infinity in O0



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



--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2013-04-23 
11:59:35 UTC ---

Guess you should read something about floating point.

0x7fff of course can't be represented exactly in IEEE 754 single precision

format, so when you convert 2147483647 to float, you get 2147483648.0f (1

higher than that), and that doesn't fit into int range, so [conv.fpint]/1

applies and it is undefined behavior.  IEEE 754 double precision format has

bigger mantissa, so

if you convert 2147483647 to double, you get 2147483647.0 and can convert it

back to int, but if you try the same with long long maximum, it won't work

again.

[Bug c/57046] [4.8/4.9 Regression] wrong code generated by gcc 4.8.0 on i686



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



Richard Biener rguenth at gcc dot gnu.org changed:



   What|Removed |Added



 Target||i?86-*-*

 Status|UNCONFIRMED |NEW

   Keywords||wrong-code

   Last reconfirmed||2013-04-23

 Ever Confirmed|0   |1

Summary|wrong code generated by gcc |[4.8/4.9 Regression] wrong

   |4.8.0 on i686   |code generated by gcc 4.8.0

   ||on i686

   Target Milestone|--- |4.8.1



--- Comment #2 from Richard Biener rguenth at gcc dot gnu.org 2013-04-23 
12:04:18 UTC ---

Confirmed.

[Bug rtl-optimization/57046] [4.8/4.9 Regression] wrong code generated by gcc 4.8.0 on i686



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



Jakub Jelinek jakub at gcc dot gnu.org changed:



   What|Removed |Added



   Priority|P3  |P1

 CC||jakub at gcc dot gnu.org,

   ||vmakarov at gcc dot gnu.org

  Component|c   |rtl-optimization



--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2013-04-23 
12:09:58 UTC ---

Started with http://gcc.gnu.org/r192719 aka LRA merge, the problematic function

is emac_operation.

[Bug rtl-optimization/57046] [4.8/4.9 Regression] wrong code generated by gcc 4.8.0 on i686



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



--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2013-04-23 
12:26:35 UTC ---

We have after the get_value call:

(insn 73 30 32 6 (set (reg:SI 76 [ D.1441 ])

(reg:SI 0 ax)) pr57046.c:42 85 {*movsi_internal}

 (expr_list:REG_DEAD (reg:SI 0 ax)

(nil)))

(insn 32 73 33 6 (parallel [

(set (reg:SI 73 [ D.1443 ])

(ashift:SI (subreg:SI (reg:DI 60 [ D.1441 ]) 0)

(const_int 2 [0x2])))

(clobber (reg:CC 17 flags))

]) 502 {*ashlsi3_1}

 (expr_list:REG_DEAD (reg:DI 60 [ D.1441 ])

(expr_list:REG_UNUSED (reg:CC 17 flags)

(nil



and IRA decides to put pseudo 76 into %ebx and pseudo 60 into %ecx.  Either it

is an IRA bug, or IRA takes into account that we only really need the low

32-bits of pseudo 60 at that point.  In any case, reload loads SImode %ecx from

the stack and uses it in the shift, while LRA loads full DImode %ecx (i.e. %ecx

and %ebx) from the stack, then uses just the low bits from that (i.e. %ecx) in

the shift.  So the LRA generated code clobbers the value in %ebx, and get_value

call is even later on DCEd because of it.

[Bug libstdc++/57047] New: [C++11] stl_pair.h:137:64: internal compiler error: Segmentation fault in constexpr constructor


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

 Bug #: 57047
   Summary: [C++11] stl_pair.h:137:64: internal compiler error:
Segmentation fault in constexpr constructor
Classification: Unclassified
   Product: gcc
   Version: 4.7.2
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mattyclark...@gmail.com


templateclass _U1, class _U2, class = typename
   enable_if__and_is_convertible_U1, _T1,
  is_convertible_U2, _T2::value::type
constexpr pair(_U1 __x, _U2 __y)
: first(std::forward_U1(__x)), second(std::forward_U2(__y)) { }

Fails for my program when compiled with the following command line:

/usr/lib64/ccache/g++ -m64 -std=c++11 -Wall -Wextra -pedantic -pthread -flto
-DNDEBUG -O3 -Werror -pedantic-errors -fvisibility=hidden
-fvisibility-inlines-hidden -I/home/matt/svn/KS/lib
-I/home/matt/svn/KS/build/release/lib -I/home/matt/svn/KS/build/release/include
-I/home/matt/svn/KS/include -I/usr/include ../../lib/messaging/tests/task.cpp
-c -o lib/messaging/tests/task.cpp.4.o

With the following error:

In file included from
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/bits/stl_algobase.h:65:0,
 from
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/bits/char_traits.h:41,
 from
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/string:42,
 from
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/stdexcept:40,
 from ../../lib/messaging/tests/task.cpp:15:
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/bits/stl_pair.h:
In instantiation of ‘constexpr std::pair_T1, _T2::pair(_U1, _U2) [with
_U1 = const char ()[35]; _U2 = const char ()[11]; template-parameter-2-3 =
void; _T1 = udp::ks::messaging::Id; _T2 = udp::ks::messaging::Id]’:
../../lib/messaging/tests/task.cpp:371:7:   required from here
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/bits/stl_pair.h:137:64:
  in constexpr expansion of ‘((std::pairudp::ks::messaging::Id,
udp::ks::messaging::Id*)this)-std::pairudp::ks::messaging::Id,
udp::ks::messaging::Id::first.udp::ks::messaging::Id::Id(((const
char*)std::forwardconst char ()[35]((*  __x’
/home/matt/svn/KS/include/udp/keystone/messaging/id.hpp:260:30:   in constexpr
expansion of ‘udp::ks::messaging::Name::Validate(((const Char*)string))’
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/bits/stl_pair.h:137:64:
internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://bugzilla.redhat.com/bugzilla for instructions.
Preprocessed source stored into /tmp/cc99Hnms.out file, please attach this to
your bugreport.

Have attached the preprocessed output.

[Bug libstdc++/57047] [C++11] stl_pair.h:137:64: internal compiler error: Segmentation fault in constexpr constructor



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



--- Comment #1 from Matt Clarkson mattyclarkson at gmail dot com 2013-04-23 
12:53:18 UTC ---

Created attachment 29919

  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29919

The preprocessed output before the ICE

[Bug fortran/57048] New: [4.9 Regression] Handling of C_PTR and C_FUNPTR leads to reject valid

2013-04-23 Thread burnus at gcc dot gnu.org



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



 Bug #: 57048

   Summary: [4.9 Regression] Handling of C_PTR and C_FUNPTR leads

to reject valid

Classification: Unclassified

   Product: gcc

   Version: 4.9.0

Status: UNCONFIRMED

  Keywords: rejects-valid

  Severity: normal

  Priority: P3

 Component: fortran

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: bur...@gcc.gnu.org





Reported by Angelo Graziosi at

http://gcc.gnu.org/ml/fortran/2013-04/msg00210.html



Using in file1:

  module m

  ...

type t

  type(c_funptr) :: funptr

end type



and in file2:

   use iso_c_binding, ONLY: c_funloc

   use m

   type(t) :: x

   ...

   x%funptr = c_funloc(proc)



fails with:

  Error: Can't convert TYPE(c_funptr) to INTEGER(4) at (1)





The problem is that the .mod file only contains:

  win32_types.mod:5 'C_funptr' '__iso_c_binding' '' 1 ((DERIVED UNKNOWN-INTENT

while the symtree is searched for c_funptr.



Workaround: Editing the .mod file and changing C_funptr to c_funptr.

[Bug fortran/57048] [4.9 Regression] Handling of C_PTR and C_FUNPTR leads to reject valid

2013-04-23 Thread burnus at gcc dot gnu.org



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



Tobias Burnus burnus at gcc dot gnu.org changed:



   What|Removed |Added



 CC||burnus at gcc dot gnu.org

   Target Milestone|--- |4.9.0

[Bug ada/56909] [4.8 regression] s-atopri.adb:multiple undefined references on mingw32

2013-04-23 Thread nightstrike at gmail dot com



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



nightstrike nightstrike at gmail dot com changed:



   What|Removed |Added



 CC||nightstrike at gmail dot

   ||com



--- Comment #17 from nightstrike nightstrike at gmail dot com 2013-04-23 
13:09:40 UTC ---

What is the driving factor that is causing you to want to make the gcc build so

complicated?  We at http://mingw-w64.sf.net have gone to great lengths to make

the windows build process simple, and to support many configurations.



Perhaps you shuld take a step back and look at your overall objective.  You

shouldn't need many configure options at all.

[Bug c++/57047] [C++11] stl_pair.h:137:64: internal compiler error: Segmentation fault in constexpr constructor



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



Jonathan Wakely redi at gcc dot gnu.org changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-04-23

  Component|libstdc++   |c++

 Ever Confirmed|0   |1

   Severity|blocker |normal



--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2013-04-23 
13:19:41 UTC ---

A segfault in the compiler cannot be a library issue.



Priority=blocker means this should block a GCC release, not I need this to

work





Can you try to reduce the code to less than 70kloc?



The error happens on line 15 of task.cpp, so you could at least remove

everything after that, and anything else not necessary to reproduce the

failure.

[Bug c++/57047] [C++11] stl_pair.h:137:64: internal compiler error: Segmentation fault in constexpr constructor



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



Jakub Jelinek jakub at gcc dot gnu.org changed:



   What|Removed |Added



 CC||jakub at gcc dot gnu.org



--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2013-04-23 
13:22:05 UTC ---

I'm already delta reducing it.

[Bug c++/57047] [C++11] stl_pair.h:137:64: internal compiler error: Segmentation fault in constexpr constructor



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



--- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2013-04-23 
13:26:46 UTC ---

(In reply to comment #2)

 The error happens on line 15 of task.cpp, so you could at least remove

 everything after that, and anything else not necessary to reproduce the

 failure.



Sorry, should have said line 371:



../../lib/messaging/tests/task.cpp:371:7:   required from here

[Bug c++/57047] [C++11] stl_pair.h:137:64: internal compiler error: Segmentation fault in constexpr constructor



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



--- Comment #5 from Matt Clarkson mattyclarkson at gmail dot com 2013-04-23 
13:42:50 UTC ---

Jonathan, apologies for putting it under libstdc++ and also for putting it as a

blocker.  I didn't do that because I thought it was blocking my work but more

because I thought an ICE is a blocker for a release.  Will make sure to

remember this with any future bug reports.



I am currently trying to get this down to a nice reproducible test case. 

Currently trying to get a single main.cpp that reproduces.  Will post if I can

get that, otherwise I'll reduce the code.



Get the same error with tuple.  So I'm sure it is in the Name::Validate

constexpr function.

[Bug c++/57047] [C++11] stl_pair.h:137:64: internal compiler error: Segmentation fault in constexpr constructor



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



--- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org 2013-04-23 
13:47:52 UTC ---

We have lots of ICEs, they can't all block a release :)

[Bug c++/57047] [C++11] stl_pair.h:137:64: internal compiler error: Segmentation fault in constexpr constructor



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



--- Comment #7 from Matt Clarkson mattyclarkson at gmail dot com 2013-04-23 
13:53:04 UTC ---

Created attachment 29920

  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29920

A simplified reproducible test case

[Bug c++/57047] [C++11] stl_pair.h:137:64: internal compiler error: Segmentation fault in constexpr constructor



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



--- Comment #8 from Matt Clarkson mattyclarkson at gmail dot com 2013-04-23 
14:07:44 UTC ---

Created attachment 29921

  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29921

A very short reproducible test case (85 loc)

[Bug c++/57047] [C++11] stl_pair.h:137:64: internal compiler error: Segmentation fault in constexpr constructor



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



--- Comment #9 from Matt Clarkson mattyclarkson at gmail dot com 2013-04-23 
14:17:10 UTC ---

This is a problem with both 4.7.2 and 4.8.0.  Checked on

http://coliru.stacked-crooked.com/

[Bug middle-end/55308] /usr/ports/lang/gcc48/work/build/sparc64-portbld-freebsd10.0/libstdc++-v3/src/.libs/libstdc++.so.6: Undefined symbol __emutls_v._ThreadRuneLocale

2013-04-23 Thread mexas at bristol dot ac.uk



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



--- Comment #11 from Anton Shterenlikht mexas at bristol dot ac.uk 2013-04-23 
14:20:11 UTC ---

The same error on the same sparc64/FreeBSD -current system

building 4.9:



gmake[5]: Leaving directory

`/usr/ports/lang/gcc49/work/build/sparc64-portbld-freebsd10.0/libgomp/testsuite'

gmake[5]: Entering directory

`/usr/ports/lang/gcc49/work/build/sparc64-portbld-freebsd10.0/libgomp'

makeinfo --no-split --split-size=500 --split-size=500  -I

../.././../gcc-4.9-20130414/libgomp/../gcc/doc/include -I

../.././../gcc-4.9-20130414/libgomp -o libgomp.info

../.././../gcc-4.9-20130414/libgomp/libgomp.texi

/bin/sh ./libtool --tag=CC   --mode=compile

/usr/ports/lang/gcc49/work/build/./gcc/xgcc

-B/usr/ports/lang/gcc49/work/build/./gcc/

-B/usr/local/sparc64-portbld-freebsd10.0/bin/

-B/usr/local/sparc64-portbld-freebsd10.0/lib/ -isystem

/usr/local/sparc64-portbld-freebsd10.0/include -isystem

/usr/local/sparc64-portbld-freebsd10.0/sys-include-DHAVE_CONFIG_H -I.

-I../.././../gcc-4.9-20130414/libgomp 

-I../.././../gcc-4.9-20130414/libgomp/config/posix

-I../.././../gcc-4.9-20130414/libgomp  -Wall -Werror -Wc,-pthread -g -O2 -pipe

-I/usr/local/include -fno-strict-aliasing -MT alloc.lo -MD -MP -MF

.deps/alloc.Tpo -c -o alloc.lo ../.././../gcc-4.9-20130414/libgomp/alloc.c

libtool: compile:  /usr/ports/lang/gcc49/work/build/./gcc/xgcc

-B/usr/ports/lang/gcc49/work/build/./gcc/

-B/usr/local/sparc64-portbld-freebsd10.0/bin/

-B/usr/local/sparc64-portbld-freebsd10.0/lib/ -isystem

/usr/local/sparc64-portbld-freebsd10.0/include -isystem

/usr/local/sparc64-portbld-freebsd10.0/sys-include -DHAVE_CONFIG_H -I.

-I../.././../gcc-4.9-20130414/libgomp

-I../.././../gcc-4.9-20130414/libgomp/config/posix

-I../.././../gcc-4.9-20130414/libgomp -Wall -pthread -Werror -g -O2 -pipe

-I/usr/local/include -fno-strict-aliasing -MT alloc.lo -MD -MP -MF

.deps/alloc.Tpo -c ../.././../gcc-4.9-20130414/libgomp/alloc.c  -fPIC -DPIC -o

.libs/alloc.o

/usr/ports/lang/gcc49/work/build/sparc64-portbld-freebsd10.0/libstdc++-v3/src/.libs/libstdc++.so.6:

Undefined symbol __emutls_v._ThreadRuneLocale

gmake[5]: *** [alloc.lo] Error 1

gmake[5]: Leaving directory

`/usr/ports/lang/gcc49/work/build/sparc64-portbld-freebsd10.0/libgomp'

gmake[4]: *** [all-recursive] Error 1

[Bug ada/56909] [4.8 regression] s-atopri.adb:multiple undefined references on mingw32

2013-04-23 Thread mail2arthur at gmail dot com



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



--- Comment #18 from Arthur Zhang mail2arthur at gmail dot com 2013-04-23 
14:31:12 UTC ---

(In reply to comment #17)

 What is the driving factor that is causing you to want to make the gcc build 
 so

 complicated?  



I am building release packages for MinGW project. I'd like to keep as more as

gcc4.7.2 release from building/packaging point of view.



 We at http://mingw-w64.sf.net have gone to great lengths to make

 the windows build process simple, and to support many configurations.



Thanks for maintaining mingw-w64 project! I will try it for sure.



 Perhaps you shuld take a step back and look at your overall objective.  You

 shouldn't need many configure options at all.



Before I learn the details of mingw-w64, can you share how mingw-w64 configure

the gcc 4.8.0 Ada build. Thanks.

[Bug middle-end/57036] [4.9 Regression] ice in update_ssa_across_abnormal_edges



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



Richard Biener rguenth at gcc dot gnu.org changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #6 from Richard Biener rguenth at gcc dot gnu.org 2013-04-23 
14:52:33 UTC ---

Author: rguenth

Date: Tue Apr 23 14:36:02 2013

New Revision: 198192



URL: http://gcc.gnu.org/viewcvs?rev=198192root=gccview=rev

Log:

2013-04-23  Richard Biener  rguent...@suse.de



PR middle-end/57036

* tree-inline.c (copy_edges_for_bb): Add can_make_abnormal_goto

parameter, only add abnormal goto edges from the copied body

if the call could perform abnormal gotos.

(copy_cfg_body): Adjust.



* gcc.dg/torture/pr57036-1.c: New testcase.

* gcc.dg/torture/pr57036-2.c: Likewise.



Added:

trunk/gcc/testsuite/gcc.dg/torture/pr57036-1.c

trunk/gcc/testsuite/gcc.dg/torture/pr57036-2.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/testsuite/ChangeLog

trunk/gcc/tree-inline.c

[Bug c++/57047] [4.7/4.8/4.9 Regression] [C++11] stl_pair.h:137:64: internal compiler error: Segmentation fault in constexpr constructor



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



Jakub Jelinek jakub at gcc dot gnu.org changed:



   What|Removed |Added



 CC||jason at gcc dot gnu.org

   Target Milestone|--- |4.7.4

Summary|[C++11] stl_pair.h:137:64:  |[4.7/4.8/4.9 Regression]

   |internal compiler error:|[C++11] stl_pair.h:137:64:

   |Segmentation fault in   |internal compiler error:

   |constexpr constructor   |Segmentation fault in

   ||constexpr constructor



--- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2013-04-23 
15:10:32 UTC ---

Reduced testcase:

template typename

struct A;

template typename T

struct A T 

{

  typedef T type;

};

template typename T

constexpr T  foo (typename A T::type  __t) noexcept

{

  return static_cast T (__t);

}

template class T1, class T2

struct B

{

  T1 t1;

  T2 t2;

  template class U

  constexpr B (U  __x, const T2  __y) : t1 (foo U (__x)), t2 (__y) {}

};

static inline constexpr bool

fn1 (const char c)

{

  return ('0' = c)  (c = '9');

}

static inline constexpr bool

fn2 (const char c)

{

  return (('A' = c)  (c = 'Z')) || (('a' = c)  (c = 'z'));

}

static constexpr bool

fn3 (const char *const x)

{

  return (x[1] == '\0'  x[0] == ']') ? true : (!fn1 (x[0])) ? false : fn3

(x[1]);

}

static constexpr bool

fn4 (const char *const x)

{

  return (x[0] == '\0') ? fn3 (x[1]) : fn4 (x[1]);

}

static inline constexpr bool

fn5 (const char *const x)

{

  return fn2 (x[0]) ? fn4 (x) : false;

}

struct C final

{

  constexpr C (const char *const t1) : c (fn5 (t1) ? 199 : 69) {}

  unsigned c;

};

B C, C p (a, b);



Started to ICE in between r175000 and r175062.

[Bug rtl-optimization/57046] [4.8/4.9 Regression] wrong code generated by gcc 4.8.0 on i686

2013-04-23 Thread vmakarov at redhat dot com



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



Vladimir Makarov vmakarov at redhat dot com changed:



   What|Removed |Added



 CC||vmakarov at redhat dot com



--- Comment #5 from Vladimir Makarov vmakarov at redhat dot com 2013-04-23 
15:34:40 UTC ---

(In reply to comment #4)

 We have after the get_value call:

 (insn 73 30 32 6 (set (reg:SI 76 [ D.1441 ])

 (reg:SI 0 ax)) pr57046.c:42 85 {*movsi_internal}

  (expr_list:REG_DEAD (reg:SI 0 ax)

 (nil)))

 (insn 32 73 33 6 (parallel [

 (set (reg:SI 73 [ D.1443 ])

 (ashift:SI (subreg:SI (reg:DI 60 [ D.1441 ]) 0)

 (const_int 2 [0x2])))

 (clobber (reg:CC 17 flags))

 ]) 502 {*ashlsi3_1}

  (expr_list:REG_DEAD (reg:DI 60 [ D.1441 ])

 (expr_list:REG_UNUSED (reg:CC 17 flags)

 (nil

 

 and IRA decides to put pseudo 76 into %ebx and pseudo 60 into %ecx.  Either it

 is an IRA bug, or IRA takes into account that we only really need the low

 32-bits of pseudo 60 at that point.  In any case, reload loads SImode %ecx 
 from

 the stack and uses it in the shift, while LRA loads full DImode %ecx (i.e. 
 %ecx

 and %ebx) from the stack, then uses just the low bits from that (i.e. %ecx) in

 the shift.  So the LRA generated code clobbers the value in %ebx, and 
 get_value

 call is even later on DCEd because of it.



It seems like a discrepancy in IRA which allocates in terms of subregisters and

LRA splitting (including call save/restore as in this case) in terms of

pseudos.  I guess fixing this might take about week.

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

2013-04-23 Thread tudorb at fb dot com



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



 Bug #: 57049

   Summary: std::swap does self move assignment, which is illegal

Classification: Unclassified

   Product: gcc

   Version: 4.7.1

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: libstdc++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: tud...@fb.com





Created attachment 29922

  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29922

sample program that illustrates incorrect behavior



The default implementation of std::swap does self-move-assignment when calling

swap(a, a), which is illegal according to 17.6.4.9.

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

2013-04-23 Thread tudorb at fb dot com



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



--- Comment #1 from Tudor Bosman tudorb at fb dot com 2013-04-23 15:54:18 UTC 
---

Actually, I'll take this back.  I don't believe this is a bug.



17.6.4.9 constraints arguments passed to STL functions.  So if there is a

library function that takes a rvalue argument (such as

string::operator=(string other)), then the library is free to assume that the

argument doesn't alias (so other != this).  So the assertion in basic_fbstring

is correct.



The default implementation of swap() does self-move assignment.  That would be

illegal if the types were MoveAssignable STL types (because then they'd call

T::operator=(T) which would be illegal according to 17.6.4.9) BUT ALL STL

TYPES HAVE SPECIALIZED IMPLEMENTATIONS OF SWAP which don't do self move

assignment.



So the default swap() will do self-move-assignment on user types, but there's

no language in the standard that bans self-move-assignment there.

[Bug testsuite/57050] New: FAIL: gcc.c-torture/execute/pr56982.c compilation, -O0

2013-04-23 Thread gretay at gcc dot gnu.org



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



 Bug #: 57050

   Summary: FAIL: gcc.c-torture/execute/pr56982.c compilation,

-O0

Classification: Unclassified

   Product: gcc

   Version: 4.9.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: testsuite

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: gre...@gcc.gnu.org

CC: rgue...@gcc.gnu.org

Target: arm-none-eabi





The new testcase gcc.c-torture/execute/pr56982.c fails to compile on

arm-none-eabi configured with newlib. 



Missing effective target?



$ /work/apr-builds/tmp/install/bin/arm-none-eabi-gcc -S

/work/local-checkouts/gcc-git/gcc/testsuite/gcc.c-torture/execute/pr56982.c -O2 

/work/local-checkouts/gcc-git/gcc/testsuite/gcc.c-torture/execute/pr56982.c:4:1:

error: unknown type name 'sigjmp_buf'

 static sigjmp_buf env;

 ^



Configured with: /work/local-checkouts/gcc-git//configure

--target=arm-none-eabi  --with-newlib --with-gnu-as --with-gnu-ld

--enable-languages=c,c++ --disable-shared --disable-nls --disable-threads

--disable-lto --disable-plugin --disable-tls --enable-checking=yes

--disable-libssp --disable-libgomp --disable-libmudflap --with-cpu=cortex-a15

--with-fpu=neon-vfpv4 --with-float=softfp 

Thread model: single

gcc version 4.9.0 20130423 (experimental) (GCC) 



Thanks,

Greta

[Bug middle-end/57003] gcc-4.8.0 breaks -O2 optimization with Wine(64) - links/info/bisect of commits included

2013-04-23 Thread kirill.k.smirnov at math dot spbu.ru



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



--- Comment #9 from Kirill Smirnov kirill.k.smirnov at math dot spbu.ru 
2013-04-23 15:56:59 UTC ---



... whatever memcpy implementation you are calling and see whether it 
correctly returns the first argument it has been passed to it in all cases.



Fails (gcc version of memcpy):

   __builtin_memcpy( buffer, DIR_Windows, len * sizeof(WCHAR) );

   __builtin_memcpy( buffer + len, default_syswow64W, sizeof(default_syswow64W)

);





Works (glibc version of memcpy):

   memcpy( buffer, DIR_Windows, len * sizeof(WCHAR) );

   memcpy( buffer + len, default_syswow64W, sizeof(default_syswow64W) );

[Bug middle-end/57003] gcc-4.8.0 breaks -O2 optimization with Wine(64) - links/info/bisect of commits included

2013-04-23 Thread tony.howard-co84udjx at yopmail dot com



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



--- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2013-04-23 
16:00:52 UTC ---

But __builtin_memcpy isn't necessarily the inline memcpy code, it can very well

be a library call too.

Anyway, this bugreport doesn't have a preprocessed source attached to it, nor

list of all gcc options to compile it, so there is nothing to look at.

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

2013-04-23 Thread mexas at bristol dot ac.uk



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



--- Comment #1 from Anton Shterenlikht mexas at bristol dot ac.uk 2013-04-23 
16:11:33 UTC ---

building gcc-4.9-20130414 gives different error:



libtool: compile:  /usr/ports/lang/gcc49/work/build/./gcc/xgcc

-B/usr/ports/lang/gcc49/work/build/./gcc/

-B/usr/local/ia64-portbld-freebsd10.0/bin/

-B/usr/local/ia64-portbld-freebsd10.0/lib/ -isystem

/usr/local/ia64-portbld-freebsd10.0/include -isystem

/usr/local/ia64-portbld-freebsd10.0/sys-include -DHAVE_CONFIG_H -I.

-I../.././../gcc-4.9-20130414/libgfortran

-iquote../.././../gcc-4.9-20130414/libgfortran/io

-I../.././../gcc-4.9-20130414/libgfortran/../gcc

-I../.././../gcc-4.9-20130414/libgfortran/../gcc/config -I../.././gcc

-I../.././../gcc-4.9-20130414/libgfortran/../libgcc -I../libgcc -std=gnu99

-Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra

-Wwrite-strings -fcx-fortran-rules -ffunction-sections -fdata-sections

-ftree-vectorize -funroll-loops -g -O2 -pipe -I/usr/local/include

-fno-strict-aliasing -MT matmul_i8.lo -MD -MP -MF .deps/matmul_i8.Tpo -c

../.././../gcc-4.9-20130414/libgfortran/generated/matmul_i8.c  -fPIC -DPIC -o

.libs/matmul_i8.o

../.././../gcc-4.9-20130414/libgfortran/generated/matmul_i4.c: In function

'matmul_i4':

../.././../gcc-4.9-20130414/libgfortran/generated/matmul_i4.c:374:1: internal

compiler error: Segmentation fault

 }

 ^

libbacktrace could not find executable to open

Please submit a full bug report,

with preprocessed source if appropriate.

See http://gcc.gnu.org/bugs.html for instructions.

gmake[3]: *** [matmul_i4.lo] Error 1

gmake[3]: *** Waiting for unfinished jobs

libtool: compile:  /usr/ports/lang/gcc49/work/build/./gcc/xgcc

-B/usr/ports/lang/gcc49/work/build/./gcc/

-B/usr/local/ia64-portbld-freebsd10.0/bin/

-B/usr/local/ia64-portbld-freebsd10.0/lib/ -isystem

/usr/local/ia64-portbld-freebsd10.0/include -isystem

/usr/local/ia64-portbld-freebsd10.0/sys-include -DHAVE_CONFIG_H -I.

-I../.././../gcc-4.9-20130414/libgfortran

-iquote../.././../gcc-4.9-20130414/libgfortran/io

-I../.././../gcc-4.9-20130414/libgfortran/../gcc

-I../.././../gcc-4.9-20130414/libgfortran/../gcc/config -I../.././gcc

-I../.././../gcc-4.9-20130414/libgfortran/../libgcc -I../libgcc -std=gnu99

-Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra

-Wwrite-strings -fcx-fortran-rules -ffunction-sections -fdata-sections

-ftree-vectorize -funroll-loops -g -O2 -pipe -I/usr/local/include

-fno-strict-aliasing -MT matmul_i8.lo -MD -MP -MF .deps/matmul_i8.Tpo -c

../.././../gcc-4.9-20130414/libgfortran/generated/matmul_i8.c -o matmul_i8.o

/dev/null 21

mv -f .deps/matmul_i8.Tpo .deps/matmul_i8.Plo

gmake[3]: Leaving directory

`/usr/ports/lang/gcc49/work/build/ia64-portbld-freebsd10.0/libgfortran'

gmake[2]: *** [all] Error 2



Shall I open a new PR for this?

[Bug c/57051] New: Optimization regression in 4.8.0 from 4.7.2



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



 Bug #: 57051

   Summary: Optimization regression in 4.8.0 from 4.7.2

Classification: Unclassified

   Product: gcc

   Version: unknown

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: tony.howard-co84u...@yopmail.com





The problem can be exhibited using the following snippet of code:



/* begin */

int total = 0;





inline void foo(int bar)

{

   total += bar*10;

}



void hello()

{

   for(int i = 0; i  10; ++i)

   {

  foo(i);

   }

}

/* end */



With the option -O3,

gcc 4.7.2 and previous versions produce the following assembly code:

hello():

addl$450, total(%rip)

ret



gcc 4.8.0 fails to optimize the code:

hello():

movdqa.LC0(%rip), %xmm0

movdqa%xmm0, %xmm2

psrldq$8, %xmm2

paddd%xmm2, %xmm0

movdqa%xmm0, %xmm3

psrldq$4, %xmm3

paddd%xmm3, %xmm0

movdqa%xmm0, %xmm4

movd%xmm4, -12(%rsp)

movl-12(%rsp), %eax

addltotal(%rip), %eax

addl$170, %eax

movl%eax, total(%rip)

ret





The results can be easily reproduced using http://gcc.godbolt.org/



The 4.7.2's configure options are:

Target: x86_64-linux-gnu



Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro

4.7.2-11precise2' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs

--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr

--program-suffix=-4.7 --enable-shared --enable-linker-build-id

--with-system-zlib --libexecdir=/usr/lib --without-included-gettext

--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7

--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu

--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object

--enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i686

--with-abi=m64 --with-multilib-list=m32,m64 --with-tune=generic

--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu

--target=x86_64-linux-gnu



The 4.8.0's configure options are:

Target: x86_64-linux-gnu



Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro

4.8.0-3ubuntu3~12.04' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs

--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr

--program-suffix=-4.8 --enable-shared --enable-linker-build-id

--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix

--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls

--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug

--enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin

--with-system-zlib --enable-objc-gc --enable-multiarch --disable-werror

--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64

--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu

--host=x86_64-linux-gnu --target=x86_64-linux-gnu



The problem is not linked to Linaro or Ubuntu patches as it can be reproduced

as well on a stock version of gcc 4.8.0

[Bug c++/57044] The following code won't compile



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



--- Comment #5 from Piergiorgio Beruto pberuto at yahoo dot com 2013-04-23 
17:04:01 UTC ---

Created attachment 29923

  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29923

preprocessed source

[Bug c++/57044] The following code won't compile


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

--- Comment #6 from Piergiorgio Beruto pberuto at yahoo dot com 2013-04-23 
17:06:46 UTC ---
Ok, my fault for missing the instructions.
However, I hope to have included everything you need now.

SYSTEM:
Linux sabayon 3.5.0-sabayon #1 SMP Tue Sep 11 08:32:37 UTC 2012 i686 Intel(R)
Core(TM) i7 CPU 950 @ 3.07GHz GenuineIntel GNU/Linux

COMMAND:
g++ -v -save-temps -DHAVE_CONFIG_H -I.
-I../../../../pem-1.0.0/ask_modules/pem_pmon-1.0.0
-I../../../../pem-1.0.0/ask_modules/pem_pmon-1.0.0/src   -std=c++0x
-I/home/karagul/projects/build/pem/ask_modules/pem_sal-1.0.0/../../../../pem-1.0.0/ask_modules/pem_sal-1.0.0/src
-I/home/karagul/projects/build/pem/ask_modules/pem_sal-1.0.0/../../../../pem-1.0.0/ask_modules/pem_sal-1.0.0/src/os/linux-gnu
-I/home/karagul/projects/build/pem/ask_modules/pem_sal-1.0.0  
-I/home/karagul/projects/build/pem/ask_modules/pem_logger-1.0.0/../../../../pem-1.0.0/ask_modules/pem_logger-1.0.0/src
-I/home/karagul/projects/build/pem/ask_modules/pem_logger-1.0.0  
-D__PEM_LOGGER_PRINT_PRETTY_FUNCTION__ -g -O0 -Wall -Werror -pipe -DDEBUG  -MT
pem_iomond-pem_iomon_visitors.o -MD -MP -MF
.deps/pem_iomond-pem_iomon_visitors.Tpo -c -o pem_iomond-pem_iomon_visitors.o
`test -f 'src/pem_iomon_visitors.cc' || echo
'../../../../pem-1.0.0/ask_modules/pem_pmon-1.0.0/'`src/pem_iomon_visitors.cc

OUTPUT:
g++: warning: -pipe ignored because -save-temps specified
Using built-in specs.
COLLECT_GCC=/usr/i686-pc-linux-gnu/gcc-bin/4.7.2/g++
Target: i686-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.7.2-r1/work/gcc-4.7.2/configure --prefix=/usr
--bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.7.2
--includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.7.2/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.7.2
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.7.2/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.7.2/info
--with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.7.2/include/g++-v4
--host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec
--disable-fixed-point --with-ppl --with-cloog --disable-ppl-version-check
--with-cloog-include=/usr/include/cloog-ppl --enable-lto --enable-nls
--without-included-gettext --with-system-zlib --enable-obsolete
--disable-werror --enable-secureplt --disable-multilib --enable-libmudflap
--disable-libssp --enable-esp --enable-libgomp
--with-python-dir=/share/gcc-data/i686-pc-linux-gnu/4.7.2/python
--enable-checking=release --enable-libstdcxx-time --with-arch=i686
--enable-objc-gc --enable-languages=c,c++,java,go,objc,obj-c++,fortran
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --enable-targets=all --with-bugurl=http://bugs.gentoo.org/
--with-pkgversion='Gentoo Hardened 4.7.2-r1 p1.5, pie-0.5.5'
Thread model: posix
gcc version 4.7.2 (Gentoo Hardened 4.7.2-r1 p1.5, pie-0.5.5) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-D' 'HAVE_CONFIG_H' '-I' '.' '-I'
'../../../../pem-1.0.0/ask_modules/pem_pmon-1.0.0' '-I'
'../../../../pem-1.0.0/ask_modules/pem_pmon-1.0.0/src' '-std=c++11' '-I'
'/home/karagul/projects/build/pem/ask_modules/pem_sal-1.0.0/../../../../pem-1.0.0/ask_modules/pem_sal-1.0.0/src'
'-I'
'/home/karagul/projects/build/pem/ask_modules/pem_sal-1.0.0/../../../../pem-1.0.0/ask_modules/pem_sal-1.0.0/src/os/linux-gnu'
'-I' '/home/karagul/projects/build/pem/ask_modules/pem_sal-1.0.0' '-I'
'/home/karagul/projects/build/pem/ask_modules/pem_logger-1.0.0/../../../../pem-1.0.0/ask_modules/pem_logger-1.0.0/src'
'-I' '/home/karagul/projects/build/pem/ask_modules/pem_logger-1.0.0' '-D'
'__PEM_LOGGER_PRINT_PRETTY_FUNCTION__' '-g' '-O0' '-Wall' '-Werror' '-pipe'
'-D' 'DEBUG' '-MT' 'pem_iomond-pem_iomon_visitors.o' '-MD' '-MP' '-MF'
'.deps/pem_iomond-pem_iomon_visitors.Tpo' '-c' '-o'
'pem_iomond-pem_iomon_visitors.o' '-shared-libgcc' '-mtune=generic'
'-march=i686' '-fPIE' '-pie'
 /usr/libexec/gcc/i686-pc-linux-gnu/4.7.2/cc1plus -E -quiet -v -I . -I
../../../../pem-1.0.0/ask_modules/pem_pmon-1.0.0 -I
../../../../pem-1.0.0/ask_modules/pem_pmon-1.0.0/src -I
/home/karagul/projects/build/pem/ask_modules/pem_sal-1.0.0/../../../../pem-1.0.0/ask_modules/pem_sal-1.0.0/src
-I
/home/karagul/projects/build/pem/ask_modules/pem_sal-1.0.0/../../../../pem-1.0.0/ask_modules/pem_sal-1.0.0/src/os/linux-gnu
-I /home/karagul/projects/build/pem/ask_modules/pem_sal-1.0.0 -I
/home/karagul/projects/build/pem/ask_modules/pem_logger-1.0.0/../../../../pem-1.0.0/ask_modules/pem_logger-1.0.0/src
-I /home/karagul/projects/build/pem/ask_modules/pem_logger-1.0.0 -MD
pem_iomond-pem_iomon_visitors.d -MF .deps/pem_iomond-pem_iomon_visitors.Tpo -MP
-MT pem_iomond-pem_iomon_visitors.o -D_GNU_SOURCE -D HAVE_CONFIG_H -D
__PEM_LOGGER_PRINT_PRETTY_FUNCTION__ -D DEBUG
../../../../pem-1.0.0/ask_modules/pem_pmon-1.0.0/src/pem_iomon_visitors.cc
-fno-strict-overflow -mtune=generic -march=i686 -std=c++11 -Wall -Werror -fPIE
-g -fworking-directory -O0 -fpch-preprocess -fstack-protector-all -o
pem_iomon_visitors.ii
ignoring

[Bug c++/57044] The following code won't compile



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



--- Comment #7 from Piergiorgio Beruto pberuto at yahoo dot com 2013-04-23 
17:08:17 UTC ---

Sorry for posting an archive, but the size of the .ii file was too big for

being submitted to bugzilla.

[Bug c++/57034] ternary operator with float infinity in O0

2013-04-23 Thread christopher.hite at jpmorgan dot com



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



--- Comment #6 from Christopher Hite christopher.hite at jpmorgan dot com 
2013-04-23 17:26:26 UTC ---

Good, I was a big worried I couldn't convert ints to floats unless the int was

safely mappable.  It rounds which is what I'd expect.



I now think z5 is safe, since int32_t(float(MAX)) wouldn't be evaluated.

const float   fMAX=std::numeric_limitsint32_t::max();

Any (positive) float less than fMax, must be representable in int32_t, though

z5 will never equal MAX-1 or MAX-2



Do you agree?



z5 is definately clearer code than playing with fetestexcept().  I'd guess it's

also faster.

[Bug c++/57044] The following code won't compile



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



Jonathan Wakely redi at gcc dot gnu.org changed:



   What|Removed |Added



 Status|WAITING |UNCONFIRMED

  Known to work||4.7.3, 4.8.0, 4.9.0

 Ever Confirmed|1   |0



--- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org 2013-04-23 
17:33:29 UTC ---

Thank you.



ICE confirmed with -g



based_loc_descr (reg=0x776634a0, offset=-4, initialized=optimized out) at

/home/wakelj/src/gcc/gcc-4.7.2/gcc/dwarf2out.c:10560



seems to be already fixed in 4.7.3 and later, probably a dup of PR 54828

[Bug c++/57034] ternary operator with float infinity in O0



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



--- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2013-04-23 
17:42:25 UTC ---

GCC bugzilla is a bug reporting mechanism, not a C++ discussion forum, so

better follow-up elsewhere.  That said, yes, if qFuture isn't negative and is

smaller than INT_MAX converted to float (aka 2147483648.0f), then it will

convert fine from float to int and will be smaller than INT_MAX.

[Bug c++/57016] [4.9 Regression] [C++0x] ICE: unexpected expression '__is_final(hashint)' of kind trait_expr



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



Marek Polacek mpolacek at gcc dot gnu.org changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-04-23

 CC||mpolacek at gcc dot gnu.org

 Ever Confirmed|0   |1



--- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org 2013-04-23 
18:39:42 UTC ---

Confirmed.

[Bug rtl-optimization/56605] Redundant branch introduced during loop2 phases

2013-04-23 Thread wschmidt at gcc dot gnu.org



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



Bill Schmidt wschmidt at gcc dot gnu.org changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED



--- Comment #5 from Bill Schmidt wschmidt at gcc dot gnu.org 2013-04-23 
19:49:08 UTC ---

Fixed.

[Bug middle-end/57003] gcc-4.8.0 breaks -O2 optimization with Wine(64) - links/info/bisect of commits included

2013-04-23 Thread kirill.k.smirnov at math dot spbu.ru



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



--- Comment #11 from Kirill Smirnov kirill.k.smirnov at math dot spbu.ru 
2013-04-23 21:33:10 UTC ---

I'm sorry I cannot reproduce invalid behaviour within a refined test case.



Instead I can provide commented asm dump from wine.



This block of code works: the returned value (rax register) is used as a

pointer to destination buffer.



// memcpy( buffer, DIR_Windows, len * sizeof(WCHAR) );

  movrsi,QWORD PTR [rip+0x3e80aa]  # 455c30 DIR_Windows

  movrdx,rbx

  movrdi,rax

  call   26000 memcpy@plt

// HERE rax points to destination buffer and rdi is corrupted by memcpy

  movrcx,rax

// memcpy( buffer + len, default_syswow64W, sizeof(default_syswow64W) );

  movrax,QWORD PTR [rip+0x33d95]   # a1930 default_syswow64W.21831

  xoredx,edx

  movQWORD PTR [rcx+rbx*1],rax

  movrax,QWORD PTR [rip+0x33d90]   # a1938default_syswow64W.21831+0x8

  movQWORD PTR [rip+0x3e8071],rcx  # 455c20 DIR_SysWow64

  movQWORD PTR [rcx+rbx*1+0x8],rax







This block of code does not work: the returned value (rax) is immediately

overwritten and rdi (corrupted by memcpy()) is used as a destination buffer.



// memcpy( buffer, DIR_Windows, len * sizeof(WCHAR) );

  movrsi,QWORD PTR [rip+0x3e296a]# 455d10 DIR_Windows

  movrdi,rax

  movrdx,rbx

  call   26060 memcpy@plt

// memcpy( buffer + len, default_syswow64W, sizeof(default_syswow64W) );

// HERE rdi is corrupted my GLIBC memcpy and rax is going to be overwritten

  movrax,QWORD PTR [rip+0x2e698]# a1a50 default_syswow64W.21831

  xoredx,edx

  movrcx,rdi

  movQWORD PTR [rdi+rbx*1],rax





I'm not sure whether registers with arguments must be kept intact after

function returns, but it seems the bug is found - in gcc or glibc.

[Bug c++/57016] [4.9 Regression] [C++0x] ICE: unexpected expression '__is_final(hashint)' of kind trait_expr