[Bug libstdc++/45228] [C++0x] Can't copy-construct "tuple" from "const tuple" rvalue

[paolo at gcc dot gnu dot org]

--- Comment #7 from paolo at gcc dot gnu dot org  2010-08-10 07:18 ---
Subject: Bug 45228

Author: paolo
Date: Tue Aug 10 07:17:44 2010
New Revision: 163049

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163049
Log:
2010-08-10  Paolo Carlini  

PR libstdc++/45228
* include/std/tuple (tuple): Constrain
converting constructors and assignment operators with
sizeof...(_UElements) == sizeof...(_Elements).
(tuple(tuple<_UElements...>&): Remove.
(tuple): Add.
* testsuite/20_util/tuple/cons/45228.cc: New.
* testsuite/20_util/tuple/cons/converting.cc: Likewise.
* testsuite/20_util/weak_ptr/comparison/cmp_neg.cc: Adjust
dg-error line number.

* include/std/tuple (_Tuple_impl<>::_Tuple_impl(const _Tuple_impl&)):
Defaulted.

* include/std/tuple (tuple
::operator=(pair<_U1, _U2>&&)): Use forward.

Added:
trunk/libstdc++-v3/testsuite/20_util/tuple/cons/45228.cc
trunk/libstdc++-v3/testsuite/20_util/tuple/cons/converting.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/tuple
trunk/libstdc++-v3/testsuite/20_util/weak_ptr/comparison/cmp_neg.cc


-- 


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

[Bug libstdc++/45228] [C++0x] Can't copy-construct "tuple" from "const tuple" rvalue

[paolo dot carlini at oracle dot com]

--- Comment #8 from paolo dot carlini at oracle dot com  2010-08-10 07:23 
---
Fixed.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.6.0


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

[Bug c++/45246] New: optimizer dereference

[attardi at di dot unipi dot it]

Code produced using -O2 handles dereferencing incorrectly.
Here is a program that shows the bug:

#include 
#include 

class Derived : public std::vector
{
public:
   Derived() {}
};

void* foo(void* arg) {
 void* baseptr = 0;
 *(std::vector **)&baseptr = (Derived *)arg;
 return baseptr;
}

void* foo2(void* arg) {
 void* baseptr = 0;
 *(std::vector **)&baseptr = *(Derived **)&arg;
 return baseptr;
}

int main()
{
   Derived* d = new Derived();
   void* upcast = foo(d);
   void* upcast2 = foo2(d);
   std::cerr << d << ", " << upcast << ", " << upcast2 << std::endl;
}

If you compile without -O2 the two values upcast and upcast2 are the 
same, as they should be.
Using -O2 the results are different.

The bug occurrs with both:

g++ (GCC) 4.1.2 20070925 (Red Hat 4.1.2-27)
g++ (Ubuntu 4.4.1-4ubuntu9) 4.4.1

This kind of code is generated by SWIG for Java, so I can't change the source.

Curiously the bug disappears if you put a print statement before the 
assignment to baseptr.


-- 
   Summary: optimizer dereference
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: attardi at di dot unipi dot it
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug c++/45246] optimizer dereference

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2010-08-10 08:17 
---
What happens if you add -Wall to the command line? Current mainline tells me:

u.cc: In function ‘void* foo(void*)’:
u.cc:12:31: warning: dereferencing type-punned pointer will break
strict-aliasing rules
u.cc: In function ‘void* foo2(void*)’:
u.cc:18:31: warning: dereferencing type-punned pointer will break
strict-aliasing rules
u.cc:18:55: warning: dereferencing type-punned pointer will break
strict-aliasing rules

thus, aliasing violations seem more than likely, without having looked at the
code in any detail. Also, try passing -fno-strict-aliasing, if something
changes for the better, you are pretty sure the code is defective.


-- 


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

[Bug fortran/45159] Unnecessary temporaries

[dominiq at lps dot ens dot fr]

--- Comment #17 from dominiq at lps dot ens dot fr  2010-08-10 08:45 ---
With the patch in comment#16, there is no temporary created for the code in
comment #15, but one is created for

  a(10:16:1) = a(11:17)

This seems to be fixed if I replace

+  if (r_stride)
+   identical_strides = gfc_dep_compare_expr (l_stride, r_stride) == 1; 
+  else 
+   identical_strides = gfc_expr_is_one (l_stride, 0) == 0; 

with

+  if (r_stride)
+   identical_strides = gfc_dep_compare_expr (l_stride, r_stride) == 1; 
+  else 
+   identical_strides = gfc_expr_is_one (l_stride, 0) == 1; 

I think that

+   identical_strides = gfc_dep_compare_expr (l_stride, r_stride) == 1; 

should also be replaced with

+   identical_strides = gfc_dep_compare_expr (l_stride, r_stride) == 0; 


-- 


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

[Bug c++/45246] optimizer dereference

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-08-10 08:54 ---
 void* baseptr = 0;
 *(std::vector **)&baseptr = (Derived *)arg;

you are accessing an object of type void* via an lvalue of type
std::vector *.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c++/45245] Segmentation Fault

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-08-10 08:56 ---
Fixed in GCC 4.4.4.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to fail||4.4.3
  Known to work||4.4.4
 Resolution||FIXED
   Target Milestone|--- |4.4.4


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

[Bug middle-end/45182] [4.6 regression] Failed to build SPEC CPU 2000/2006

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2010-08-10 08:56 ---
Bernd, can you commit your fix please?


-- 


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

[Bug tree-optimization/45243] Non-volatile variables don't need to be constantly modified at -Os

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-08-10 08:57 ---
The some reason is that loop header copying is not performed at -Os.


-- 


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

[Bug tree-optimization/45241] CPU2006 465.tonto ICE in the vectorizer with -fno-tree-pre

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-08-10 08:58 ---
Can you attach a testcase please?


-- 


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

[Bug tree-optimization/45241] CPU2006 465.tonto ICE in the vectorizer with -fno-tree-pre

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2010-08-10 08:58 ---
*** Bug 45239 has been marked as a duplicate of this bug. ***


-- 


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

[Bug tree-optimization/45239] CPU2006 465.tonto ICE in the vectorizer with -fno-tree-pre

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2010-08-10 08:58 ---


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


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug target/45234] [4.4/4.5/4.6 Regression] ICE in expand_call, at calls.c:2845 when passing aligned function argument from unaligned stack after alloca

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.4 Regression] ICE in |[4.4/4.5/4.6 Regression] ICE
   |expand_call, at calls.c:2845|in expand_call, at
   |when passing aligned|calls.c:2845 when passing
   |function argument from  |aligned function argument
   |unaligned stack after alloca|from unaligned stack after
   ||alloca
   Target Milestone|--- |4.4.5


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

[Bug tree-optimization/45241] CPU2006 465.tonto ICE in the vectorizer with -fno-tree-pre

[irar at il dot ibm dot com]

--- Comment #4 from irar at il dot ibm dot com  2010-08-10 09:06 ---
I am testing the same patch as in comment #1.

Testcase that shows the problem:

int
foo(short x)
{
  short i, y;
  int sum;

  for (i = 0; i < x; i++)
y = x * i;

  for (i = x; i > 0; i--)
sum += y;

  return sum;
}


-- 


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

[Bug libstdc++/45226] the difference of fstream's open() in different GCC version

[redi at gcc dot gnu dot org]

--- Comment #5 from redi at gcc dot gnu dot org  2010-08-10 09:16 ---
You have not found a bug in GCC and this is not the place to learn C++.
Please find a reference on C++ iostreams or find an appropriate forum to ask
questions.

You can call is_open() to see if the stream was opened
http://gcc.gnu.org/onlinedocs/libstdc++/libstdc++-html-USERS-3.4/classstd_1_1basic__ofstream.html#std_1_1basic__ofstreama4

Please do NOT reply with more questions about using the C++ standard library,
there are lots of books and websites where you an find the information you
need.


-- 


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

[Bug fortran/45159] Unnecessary temporaries

[tkoenig at netcologne dot de]

--- Comment #18 from tkoenig at netcologne dot de  2010-08-10 09:19 ---
Subject: Re:  Unnecessary temporaries

Am Dienstag, den 10.08.2010, 08:45 + schrieb dominiq at lps dot ens
dot fr:
> I think that
> 
> +   identical_strides = gfc_dep_compare_expr (l_stride, r_stride)
> == 1; 
> 
> should also be replaced with
> 
> +   identical_strides = gfc_dep_compare_expr (l_stride, r_stride)
> == 0; 


Correct.

Although it is probably better set the stride during resolution.

Here's a tentative patch for that.  There are probably very many places
that NULL checks can be elided with this.

Index: resolve.c
===
--- resolve.c   (Revision 163041)
+++ resolve.c   (Arbeitskopie)
@@ -4378,12 +4378,19 @@
return FAILURE;
  }

+  /* Always fill in a stride of one.  */
+
+  if (ar->dimen_type[i] == DIMEN_RANGE
+ && ar->stride[i] == NULL)
+   ar->stride[i] = gfc_get_int_expr (gfc_index_integer_kind,
+ &ar->where, 1);
+
   /* Fill in the upper bound, which may be lower than the
 specified one for something like a(2:10:5), which is
 identical to a(2:7:5).  Only relevant for strides not equal
 to one.  */
   if (ar->dimen_type[i] == DIMEN_RANGE
- && ar->stride[i] != NULL && ar->stride[i]->expr_type ==
EXPR_CONSTANT
+ && ar->stride[i]->expr_type == EXPR_CONSTANT
  && mpz_cmp_si (ar->stride[i]->value.integer, 1L) != 0)
{
  mpz_t size, end;


-- 


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

[Bug tree-optimization/45232] [4.6 regression] tree reassociation introduces undefined overflow

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2010-08-10 09:24 ---
The patch doens't work - we have to disable a lot more reassociation which
isn't really allowed for types with undefined overflow.  There are a bunch
of invalid testcases in the testsuite as well.

We might be able to recover some of the regressions by teaching our tree
combiner of some tricks.  It looks like that will delay a fix for this
PR somewhat, but I'm working on it ...


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2010-08-08 22:42:06 |2010-08-10 09:24:08
   date||
   Target Milestone|--- |4.6.0


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

[Bug tree-optimization/45241] CPU2006 465.tonto ICE in the vectorizer with -fno-tree-pre

[irar at il dot ibm dot com]

--- Comment #5 from irar at il dot ibm dot com  2010-08-10 10:23 ---
(In reply to comment #1)
> This patch should be a valid fix, because the recognition of the dot_prod
> pattern is known to be fail at this point if the stmt is outside the loop.
> (I am not sure whether we should not see this case in the vectorizer at this
> point -- should previous analysis already filter out?):
> 

I don't understand this. Where do we check if the stmt (which one?) is outside
the loop? 


> diff --git a/gcc/tree-vect-patterns.c b/gcc/tree-vect-patterns.c
> index 19f0ae6..5f81a73 100644
> --- a/gcc/tree-vect-patterns.c
> +++ b/gcc/tree-vect-patterns.c
> @@ -259,6 +259,10 @@ vect_recog_dot_prod_pattern (gimple last_stmt, tree
> *type_in, tree *type_out)
>   inside the loop (in case we are analyzing an outer-loop).  */
>if (!is_gimple_assign (stmt))
>  return NULL;
> +
> +  if (!flow_bb_inside_loop_p (loop, gimple_bb (stmt)))
> +return NULL;
> +
>stmt_vinfo = vinfo_for_stmt (stmt);
>gcc_assert (stmt_vinfo);
>if (STMT_VINFO_DEF_TYPE (stmt_vinfo) != vect_internal_def)
> 

I was looking at PR 45239 and didn't notice that there is another PR and didn't
see this comment. So I tested the same fix (successfully on x86_64-suse-linux).
You can commit it if you like (just please notice, that the bug exists on 4.5
as well). 

Thanks,
Ira


-- 

irar at il dot ibm dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-08-10 10:24:00
   date||


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

[Bug c++/45246] optimizer dereference

[attardi at di dot unipi dot it]

--- Comment #3 from attardi at di dot unipi dot it  2010-08-10 10:27 ---
You are right.
SWIG does this on purpose, as the most portable way to cast a pointer into a 64
bit integer:

"For non-primitive types the "in" and "out" typemaps are responsible for
casting between the C/C++ pointer and the 64 bit jlong type. There is no
portable way to cast a pointer into a 64 bit integer type and the approach
taken by SWIG is mostly portable, but breaks C/C++ aliasing rules."

http://www.swig.org/Doc1.3/Java.html#typemaps_c_to_java_types


-- 


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

[Bug fortran/45159] Unnecessary temporaries

[dominiq at lps dot ens dot fr]

--- Comment #19 from dominiq at lps dot ens dot fr  2010-08-10 12:00 ---
(In reply to comment #18)
> Although it is probably better set the stride during resolution.

Probably.

A few comments before leaving for ten days without access to the net.

(1) I think all the changes done recently to avoid unneeded temporaries can be
extended by reversing the loops.

(2) The following code generates an unneeded temporary:

integer, parameter :: n = 10
integer :: i
integer :: a(0:n+1) = (/(i, i =0, n), 0/)
a(:6:2) = a(::3)
print *, a
end

It is in the class abs(r_stride)>max(0,abs(l_stride)) for which there is no
need for temporary if
l_startmax(0,l_stride)
or
l_start>r_start+r_stride for r_stridehttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=45159

[Bug c/45247] New: Internal error: Segmentation fault

[leledumbo_cool at yahoo dot co dot id]

Upon compiling ruby-1.9.1-p429, I got this:

gcc -s -O4 -O4 -g -Wall -Wno-parentheses   -I. -I.ext/include/i386-mingw32
-I./include -I.  -DRUBY_EXPORT   -o regexec.o -c regexec.c
regexec.c: In function 'onig_search':
regexec.c:3369:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make: *** [regexec.o] Error 1

To the best of my knowledge, an internal error is always a bug, so I'll report
it and the problematic source code:
http://old.nabble.com/file/p29394423/regexec.i.c


-- 
   Summary: Internal error: Segmentation fault
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: leledumbo_cool at yahoo dot co dot id


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

[Bug tree-optimization/45241] CPU2006 465.tonto ICE in the vectorizer with -fno-tree-pre

[dominiq at lps dot ens dot fr]

--- Comment #6 from dominiq at lps dot ens dot fr  2010-08-10 12:04 ---
This is a [4.5/4.6 Regression]: the test in comment #4 compiles with gcc
version 4.4.4 (GCC).


-- 


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

[Bug c/45247] Internal error: Segmentation fault

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2010-08-10 12:15 ---
Works for me on x86_64/32 with 4.5.0 and 4.5.1.  Sounds similar to PR39820.


-- 


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

[Bug c/45237] /usr/include/string.h:546:5: error: unknown type name �__locale_t�

[michael dot a dot richmond at nasa dot gov]

--- Comment #1 from michael dot a dot richmond at nasa dot gov  2010-08-10 
12:31 ---
There was a configuration error on my part.


-- 

michael dot a dot richmond at nasa dot gov changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

Re: [Bug c++/45246] New: optimizer dereference

[Andrew Pinski]

On Aug 10, 2010, at 1:00 AM, "attardi at di dot unipi dot it" > wrote:



Code produced using -O2 handles dereferencing incorrectly.
Here is a program that shows the bug:

#include 
#include 

class Derived : public std::vector
{
public:
  Derived() {}
};

void* foo(void* arg) {
void* baseptr = 0;
*(std::vector **)&baseptr = (Derived *)arg;
return baseptr;
}


Have it do
jlong a = 0;
memcpy(&a, &arg, sizeof(void*));

That is the most portable way of putting a pointer value in jlong.



void* foo2(void* arg) {
void* baseptr = 0;
*(std::vector **)&baseptr = *(Derived **)&arg;
return baseptr;
}

int main()
{
  Derived* d = new Derived();
  void* upcast = foo(d);
  void* upcast2 = foo2(d);
  std::cerr << d << ", " << upcast << ", " << upcast2 << std::endl;
}

If you compile without -O2 the two values upcast and upcast2 are the
same, as they should be.
Using -O2 the results are different.

The bug occurrs with both:

g++ (GCC) 4.1.2 20070925 (Red Hat 4.1.2-27)
g++ (Ubuntu 4.4.1-4ubuntu9) 4.4.1

This kind of code is generated by SWIG for Java, so I can't change  
the source.


Curiously the bug disappears if you put a print statement before the
assignment to baseptr.


--
  Summary: optimizer dereference
  Product: gcc
  Version: 4.4.1
   Status: UNCONFIRMED
 Severity: critical
 Priority: P3
Component: c++
   AssignedTo: unassigned at gcc dot gnu dot org
   ReportedBy: attardi at di dot unipi dot it
GCC build triplet: x86_64-unknown-linux-gnu
 GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug c++/45246] optimizer dereference

[pinskia at gmail dot com]

--- Comment #4 from pinskia at gmail dot com  2010-08-10 12:36 ---
Subject: Re:   New: optimizer dereference



On Aug 10, 2010, at 1:00 AM, "attardi at di dot unipi dot it"
 wrote:

> Code produced using -O2 handles dereferencing incorrectly.
> Here is a program that shows the bug:
>
> #include 
> #include 
>
> class Derived : public std::vector
> {
> public:
>   Derived() {}
> };
>
> void* foo(void* arg) {
> void* baseptr = 0;
> *(std::vector **)&baseptr = (Derived *)arg;
> return baseptr;
> }

Have it do
jlong a = 0;
memcpy(&a, &arg, sizeof(void*));

That is the most portable way of putting a pointer value in jlong.

>
> void* foo2(void* arg) {
> void* baseptr = 0;
> *(std::vector **)&baseptr = *(Derived **)&arg;
> return baseptr;
> }
>
> int main()
> {
>   Derived* d = new Derived();
>   void* upcast = foo(d);
>   void* upcast2 = foo2(d);
>   std::cerr << d << ", " << upcast << ", " << upcast2 << std::endl;
> }
>
> If you compile without -O2 the two values upcast and upcast2 are the
> same, as they should be.
> Using -O2 the results are different.
>
> The bug occurrs with both:
>
> g++ (GCC) 4.1.2 20070925 (Red Hat 4.1.2-27)
> g++ (Ubuntu 4.4.1-4ubuntu9) 4.4.1
>
> This kind of code is generated by SWIG for Java, so I can't change  
> the source.
>
> Curiously the bug disappears if you put a print statement before the
> assignment to baseptr.
>
>
> -- 
>   Summary: optimizer dereference
>   Product: gcc
>   Version: 4.4.1
>Status: UNCONFIRMED
>  Severity: critical
>  Priority: P3
> Component: c++
>AssignedTo: unassigned at gcc dot gnu dot org
>ReportedBy: attardi at di dot unipi dot it
> GCC build triplet: x86_64-unknown-linux-gnu
>  GCC host triplet: x86_64-unknown-linux-gnu
> GCC target triplet: x86_64-unknown-linux-gnu
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45246
>


-- 


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

[Bug c++/45246] optimizer dereference

[schwab at linux-m68k dot org]

--- Comment #5 from schwab at linux-m68k dot org  2010-08-10 12:42 ---
The most portable way to put a pointer value in a jlong is a = (uintptr_t)arg.


-- 


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

[Bug middle-end/45182] [4.6 regression] Failed to build SPEC CPU 2000/2006

[bernds at gcc dot gnu dot org]

--- Comment #8 from bernds at gcc dot gnu dot org  2010-08-10 12:48 ---
Subject: Bug 45182

Author: bernds
Date: Tue Aug 10 12:48:16 2010
New Revision: 163057

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163057
Log:
PR middle-end/45182
* combine.c (make_compound_operation): Don't try to convert
shifts into multiplications for modes that aren't SCALAR_INT_MODE_P.

PR middle-end/45182
* gcc.c-torture/compile/pr45182.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr45182.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/combine.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/45182] [4.6 regression] Failed to build SPEC CPU 2000/2006

[bernds at gcc dot gnu dot org]

--- Comment #9 from bernds at gcc dot gnu dot org  2010-08-10 12:53 ---
Fixed.


-- 

bernds at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug middle-end/17982] stop calling assemble_external before final assembly output time

[iains at gcc dot gnu dot org]

--- Comment #35 from iains at gcc dot gnu dot org  2010-08-10 13:01 ---
(In reply to comment #34)

> I think the ones in calls.c are OK.  So only ObjC still calls
> assemble_external. Iain?

AFAICT, assemble_external () [no longer?] emits any assembly nor does it call
DECL_ASSEMBLER_NAME:

it seems to check for a weak function and add that to the weak functions list
and then (if the target defines ASM_OUTPUT_EXTERNAL) adds the decl to the
pending list which is output from assemble_pending_externals () called from
toplev.c.

varasm (assemble variable) says:

 /* Normally no need to say anything here for external references,
 since assemble_external is called by the language-specific code
 when a declaration is first seen.  */

  if (DECL_EXTERNAL (decl))
return;

I would imagine that if this were replaced by:

  if (DECL_EXTERNAL (decl))
   {
assemble_external (decl);
return;
   }

we should be able to remove the calls in ObjC (I'll try this later).

OTOH, I wonder if we have a case of a solved problem with the bug left
open?

[BTW, I also have checking the status of 24777 on my TODO.]


-- 


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

[Bug middle-end/45234] [4.4/4.5/4.6 Regression] ICE in expand_call, at calls.c:2845 when passing aligned function argument from unaligned stack after alloca

[hjl dot tools at gmail dot com]

--- Comment #15 from hjl dot tools at gmail dot com  2010-08-10 13:36 
---
A patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00734.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2010-
   ||08/msg00734.html
  Component|target  |middle-end


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

[Bug c++/45200] [4.5/4.6 Regression] ICE in template instantiation

[dodji at gcc dot gnu dot org]

--- Comment #8 from dodji at gcc dot gnu dot org  2010-08-10 14:37 ---
*** Bug 44301 has been marked as a duplicate of this bug. ***


-- 

dodji at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jewillco at osl dot iu dot
   ||edu


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

[Bug c++/44301] [4.5 Regression] g++ ICE on complicated template code

[dodji at gcc dot gnu dot org]

--- Comment #4 from dodji at gcc dot gnu dot org  2010-08-10 14:37 ---


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


-- 

dodji at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


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

[Bug tree-optimization/45220] [4.6 Regression] libjava/libltdl/ltdl.c:1272:1: internal compiler error: Segmenta

[danglin at gcc dot gnu dot org]

--- Comment #3 from danglin at gcc dot gnu dot org  2010-08-10 14:56 ---
Reverting 162842 restores full bootstrap.


-- 

danglin at gcc dot gnu dot org changed:

   What|Removed |Added

   GCC host triplet|hppa2.0w-hp-hpux11.11,  |hppa2.0w-hp-hpux11.11
   |hppa64-hp-hpux11.11 |


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

[Bug boehm-gc/34544] pthread_default_stacksize_np failed.

[danglin at gcc dot gnu dot org]

--- Comment #7 from danglin at gcc dot gnu dot org  2010-08-10 15:24 ---
Subject: Bug 34544

Author: danglin
Date: Tue Aug 10 15:23:07 2010
New Revision: 163071

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163071
Log:
PR boehm-gc/34544
* gthr-posix.h (__gthread_start): Delete.
(__gthread_active_init): Use pthread_default_stacksize_np instead of
pthread_create to determine if hpux pthreads are active.
* gthr-posix95.h (__gthread_start): Delete.
(__gthread_active_init): Likewise use pthread_default_stacksize_np.


Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/gthr-posix.h
branches/gcc-4_3-branch/gcc/gthr-posix95.h


-- 


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

[Bug middle-end/41551] [4.4 Regression] ia64: ICE: in instantiate_virtual_regs_in_insn, at function.c:1630

[sje at gcc dot gnu dot org]

--- Comment #7 from sje at gcc dot gnu dot org  2010-08-10 15:41 ---
Subject: Bug 41551

Author: sje
Date: Tue Aug 10 15:40:14 2010
New Revision: 163072

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163072
Log:
2010-08-10  Steve Ellcey  
Jakub Jelinek 

Backport from mainline:
PR middle-end/41551
* function.c (instantiate_virtual_regs_in_insn): Copy to new reg
before forcing mode.
* testsuite/gcc.dg/pr41551.c: New test.

Added:
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr41551.c
Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/function.c
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/41551] [4.4 Regression] ia64: ICE: in instantiate_virtual_regs_in_insn, at function.c:1630

[sje at cup dot hp dot com]

--- Comment #8 from sje at cup dot hp dot com  2010-08-10 15:58 ---
Backported to the 4.4 branch.


-- 

sje at cup dot hp dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/41881] [4.5/4.6 regression] Complete unrolling (inner) versus vectorization of reduction

[drow at gcc dot gnu dot org]

--- Comment #5 from drow at gcc dot gnu dot org  2010-08-10 16:01 ---
Verified on x86_64 using:

gcc-4.3 -O3 -o 43.s -S reduc.c -ftree-vectorizer-verbose=1
[two loops vectorized]
gcc-4.4 -O3 -o 43.s -S reduc.c -ftree-vectorizer-verbose=1
[one loop vectorized]


-- 

drow at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||irar at gcc dot gnu dot org
  Known to fail||4.4.4
  Known to work||4.3.5
Summary|Complete unrolling (inner)  |[4.5/4.6 regression]
   |versus vectorization of |Complete unrolling (inner)
   |reduction   |versus vectorization of
   ||reduction


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

[Bug bootstrap/45248] New: Stage 3 bootstrap comparison failure (powerpc-darwin8)

[fang at csl dot cornell dot edu]

My build of 4.5.1 (using Jack Howarth's fink packaging) fails comparison at
stage 3.

rm -f stage_current
Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1obj-checksum.o differs
warning: gcc/cc1objplus-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
Bootstrap comparison failure!
gcc/cp/parser.o differs
gcc/real.o differs
gcc/tree-ssa-live.o differs
gcc/tree-vectorizer.o differs
make[2]: *** [compare] Error 1
make[1]: *** [stage3-bubble] Error 2
make: *** [all] Error 2

compiler
% gcc -v
Using built-in specs.
Target: powerpc-apple-darwin8
Configured with: /var/tmp/gcc/gcc-5370~2/src/configure --disable-checking
-enable-werror --prefix=/usr --mandir=/share/man
--enable-languages=c,objc,c++,obj-c++
--program-transform-name=/^[cg][^.-]*$/s/$/-4.0/
--with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib
--build=powerpc-apple-darwin8 --host=powerpc-apple-darwin8
--target=powerpc-apple-darwin8
Thread model: posix
gcc version 4.0.1 (Apple Computer, Inc. build 5370)

Configured with (%p = /sw):
 --prefix=%p/lib/gcc4.5 --mandir=%p/share/man --infodir=%p/lib/gcc4.5/info 
--enable-languages=c,c++,fortran,objc,obj-c++,java \
 --with-gmp=%p --with-libiconv-prefix=%p --with-mpc=%p --with-system-zlib \
 --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--program-suffix=-fsf-4.5

make -j2 (one other fink maintainer reported failure with -j1)

I've kept around the failed build dir, let me know what I can provide to help
debug this.

Attaching packaging files...


-- 
   Summary: Stage 3 bootstrap comparison failure (powerpc-darwin8)
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fang at csl dot cornell dot edu
  GCC host triplet: powerpc-apple-darwin8


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

[Bug bootstrap/45248] Stage 3 bootstrap comparison failure (powerpc-darwin8)

[fang at csl dot cornell dot edu]

--- Comment #1 from fang at csl dot cornell dot edu  2010-08-10 16:59 
---
Created an attachment (id=21446)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21446&action=view)
fink package file with build script used


-- 


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

[Bug bootstrap/45248] Stage 3 bootstrap comparison failure (powerpc-darwin8)

[fang at csl dot cornell dot edu]

--- Comment #2 from fang at csl dot cornell dot edu  2010-08-10 17:00 
---
Created an attachment (id=21447)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21447&action=view)
cumulative patch used before building


-- 


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

[Bug bootstrap/45248] Stage 3 bootstrap comparison failure (powerpc-darwin8)

[howarth at nitro dot med dot uc dot edu]

--- Comment #3 from howarth at nitro dot med dot uc dot edu  2010-08-10 
17:33 ---
Does passing --with-dwarf2 fix the bootstrap failure?


-- 


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

[Bug fortran/45244] Incorrect passing of character string array argument triggers an internal compiler error

[kargl at gcc dot gnu dot org]

--- Comment #3 from kargl at gcc dot gnu dot org  2010-08-10 17:49 ---
Might as well confirm the bug.

This patch stops the segmentation fault, but I do not know
if it is the correct fix.

Index: interface.c
===
--- interface.c (revision 163075)
+++ interface.c (working copy)
@@ -1611,7 +1611,8 @@ compare_parameter (gfc_symbol *formal, g
   if (formal->ts.type == BT_CHARACTER
   && (ref == NULL
   || (actual->expr_type == EXPR_VARIABLE
- && (actual->symtree->n.sym->as->type == AS_ASSUMED_SHAPE
+ && ((actual->symtree->n.sym->as
+  && actual->symtree->n.sym->as->type == AS_ASSUMED_SHAPE)
  || actual->symtree->n.sym->attr.pointer
 {
   if (where && (gfc_option.allow_std & GFC_STD_F2003) == 0)


-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-08-10 17:49:56
   date||


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

[Bug bootstrap/45248] Stage 3 bootstrap comparison failure (powerpc-darwin8)

[fang at csl dot cornell dot edu]

--- Comment #4 from fang at csl dot cornell dot edu  2010-08-10 18:10 
---
Subject: Re:  Stage 3 bootstrap comparison failure
 (powerpc-darwin8)

> --- Comment #3 from howarth at nitro dot med dot uc dot edu  2010-08-10 
> 17:33 ---
> Does passing --with-dwarf2 fix the bootstrap failure?

I've kicked off a new build --with-dwarf2, but it's probably going to take 
all day on my Poor Old Machine (TM).  :)

FWIW, others reported that 4.5.0 (your fink packaged one) worked on 10.4, 
and I'm also building that one for comparison.

Fang


-- 


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

[Bug bootstrap/45177] [4.6 regression] cc1 runs out of memory building libgcc in ARM cross-compiler

[bernds at gcc dot gnu dot org]

--- Comment #6 from bernds at gcc dot gnu dot org  2010-08-10 18:45 ---
Subject: Bug 45177

Author: bernds
Date: Tue Aug 10 18:45:10 2010
New Revision: 163077

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163077
Log:
PR bootstrap/45177
* config/arm/arm.c (multiple_operation_profitable_p): Move xscale
test here from arm_gen_load_multiple_1.
(arm_gen_load_multiple_1, arm_gen_store_multiple_1): Use
multiple_operation_profitable_p.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c


-- 


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

[Bug fortran/45244] Incorrect passing of character string array argument triggers an internal compiler error

[kargl at gcc dot gnu dot org]

--- Comment #4 from kargl at gcc dot gnu dot org  2010-08-10 20:19 ---
The patch in comment #4 passes regression testing on x86_64-*-freebsd.


-- 


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

[Bug fortran/45244] Incorrect passing of character string array argument triggers an internal compiler error

[mikael at gcc dot gnu dot org]

--- Comment #5 from mikael at gcc dot gnu dot org  2010-08-10 20:42 ---
(In reply to comment #3)
> Might as well confirm the bug.
> 
> This patch stops the segmentation fault, but I do not know
> if it is the correct fix.
> 
I think the correct fix here is to take the array spec (and maybe the pointer
attribute as well) from the derived type component instead of the symbol. 


-- 


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

[Bug tree-optimization/45241] [4.5/4.6 Regression] CPU2006 465.tonto ICE in the vectorizer with -fno-tree-pre

[changpeng dot fang at amd dot com]

--- Comment #7 from changpeng dot fang at amd dot com  2010-08-10 21:44 
---
(In reply to comment #5)
> (In reply to comment #1)
> > This patch should be a valid fix, because the recognition of the dot_prod
> > pattern is known to be fail at this point if the stmt is outside the loop.
> > (I am not sure whether we should not see this case in the vectorizer at this
> > point -- should previous analysis already filter out?):
> > 
> 
> I don't understand this. Where do we check if the stmt (which one?) is outside
> the loop? 

Forget about this part of the comment (The vectorization analysis is correct,
and it is just that the pattern recognition traces the chain outside the loop). 

> I was looking at PR 45239 and didn't notice that there is another PR and 
> didn't
> see this comment. So I tested the same fix (successfully on 
> x86_64-suse-linux).
> You can commit it if you like (just please notice, that the bug exists on 4.5
> as well). 
> 

I am going to add your testcase (in comment #4), and doing bootstraping, and
then commit to the trunk and gcc 4.5 branch.


-- 


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

[Bug libstdc++/40974] cannot build gcc-4.4.1: fenv_t has not been declared

[pinskia at gcc dot gnu dot org]

--- Comment #36 from pinskia at gcc dot gnu dot org  2010-08-10 21:51 
---
I am running into this also when doing a candian cross to mips64-linux-gnu.  We
had locally reverted the patch for bug 3800 but I know that is wrong. 


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org


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

[Bug libstdc++/40974] [4.3/4.4/4.5/4.6 Regression] cannot build gcc-4.4.1: fenv_t has not been declared

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||build
Summary|cannot build gcc-4.4.1: |[4.3/4.4/4.5/4.6 Regression]
   |fenv_t has not been declared|cannot build gcc-4.4.1:
   ||fenv_t has not been declared
   Target Milestone|--- |4.3.6


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

[Bug c++/45249] New: Indirect variable parameters sometimes cause segmentation fault

[rogerio at rilhas dot com]

When using variable parameters indirectly (the variable-parameter function
calls another function to format its parameters giving it the original address
of the format string), the results are usually ok for non-optimized builds and
cause segmentation faults in optimized builds.

In a large project I also detected that unoptimized builds would cause
segmentation faults if the variable-parameter function declared a char buffer,
and would not fail if it declared an int buffer of the same total size. However
this is difficult to reproduce, so the test case I send you does not show this.

In the code I send you you can see "main" calling "format_direct" to format
some variable parameters, which in turn calls "format_indirect" to do the
actual work. This is a pattern I use a lot and for which I never had a problem
under Windows with any of Microsoft's Visual Studio versions (I'm fairly new to
LINUX, this is my first software port project).

If this test case is compiled with "g++ -v -save-temps
gcc_bug_format_indirect.cpp -o gcc_bug_format_indirect.exe.ok" then it works
ok, but if it is compiled with "g++ -v -save-temps -O2
gcc_bug_format_indirect.cpp -o gcc_bug_format_indirect.exe.ko" it causes a
segmentation fault (at least on my system it does, when it doesn't cause a
segmentation fault the results are just wrong).

I attach the preprocessed file, the source file, and the compilation script I
used.


-- 
   Summary: Indirect variable parameters sometimes cause
segmentation fault
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rogerio at rilhas dot com
 GCC build triplet: i686-virtualboxvm-ubuntu?
  GCC host triplet: i686-virtualboxvm-ubuntu?
GCC target triplet: i686-virtualboxvm-ubuntu?


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

[Bug libstdc++/40974] [4.3/4.4/4.5/4.6 Regression] cannot build gcc-4.4.1: fenv_t has not been declared

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-08-10 22:00:24
   date||


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

[Bug libstdc++/39238] trunk revision 144279 - cfenv:54: error: �::fenv_t� has not been declared

[pinskia at gcc dot gnu dot org]

--- Comment #14 from pinskia at gcc dot gnu dot org  2010-08-10 22:01 
---
See PR 40974 for the fenv_t issue.


-- 


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

[Bug c++/45249] Indirect variable parameters sometimes cause segmentation fault

[rogerio at rilhas dot com]

--- Comment #1 from rogerio at rilhas dot com  2010-08-10 22:03 ---
Created an attachment (id=21448)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21448&action=view)
Preprocessed file


-- 


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

[Bug c++/45249] Indirect variable parameters sometimes cause segmentation fault

[rogerio at rilhas dot com]

--- Comment #2 from rogerio at rilhas dot com  2010-08-10 22:03 ---
Created an attachment (id=21449)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21449&action=view)
Source file with comments


-- 


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

[Bug c++/45249] Indirect variable parameters sometimes cause segmentation fault

[rogerio at rilhas dot com]

--- Comment #3 from rogerio at rilhas dot com  2010-08-10 22:04 ---
Created an attachment (id=21450)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21450&action=view)
Compilation script (for the working and non-working builds)


-- 


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

[Bug c++/45249] Indirect variable parameters sometimes cause segmentation fault

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2010-08-10 22:07 ---
This code will never work as you are not using va_start/va_end to access the
arguments.  For format_indirect you should just pass around a va_list instead.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c++/45200] [4.5/4.6 Regression] ICE in template instantiation

[dodji at gcc dot gnu dot org]

--- Comment #9 from dodji at gcc dot gnu dot org  2010-08-10 22:12 ---
(In reply to comment #7)
> Created an attachment (id=21443)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21443&action=view) [edit]
> Candidate patch
> 
> I am testing this patch atm that seems to be working for now.

It turned out the patch is not correct. I am looking at another way. 


-- 


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

[Bug c++/44641] Generated constructors and destructors get wrong debug location when a typedef uses a forward declaration of the type before the definition

[danglin at gcc dot gnu dot org]

--- Comment #20 from danglin at gcc dot gnu dot org  2010-08-10 22:13 
---
Test still fails on hppa-linux.


-- 

danglin at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


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

[Bug bootstrap/45177] [4.6 regression] cc1 runs out of memory building libgcc in ARM cross-compiler

[ramana at gcc dot gnu dot org]

--- Comment #7 from ramana at gcc dot gnu dot org  2010-08-10 22:17 ---
Is this now fixed ? 


-- 

ramana at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug libstdc++/40974] [4.3/4.4/4.5/4.6 Regression] cannot build gcc-4.4.1: fenv_t has not been declared

[paolo dot carlini at oracle dot com]

--- Comment #37 from paolo dot carlini at oracle dot com  2010-08-10 22:18 
---
Thus, does adding -nostdinc++ to the PCHs flags work for you?


-- 


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

[Bug libstdc++/40974] [4.3/4.4/4.5/4.6 Regression] cannot build gcc-4.4.1: fenv_t has not been declared

[pinskia at gcc dot gnu dot org]

--- Comment #38 from pinskia at gcc dot gnu dot org  2010-08-10 22:19 
---
(In reply to comment #37)
> Thus, does adding -nostdinc++ to the PCHs flags work for you?
Testing that right now.  


-- 


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

[Bug c++/45064] friends of nested classes don't see outer classes

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2010-08-10 22:20 ---
The error message is correct f1::f2 is not accessible outside of f1 unless it
is a friend of f1 and then f1::f2::f3 is not accessible inside f1 unless f1 is
a friend of f1::f2.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c++/45064] friends of nested classes don't see outer classes

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2010-08-10 22:21 ---
This compiles:
   class f1 {
   class   f2 {
   class f3;
   friend class f1;
   friend  void bar(f1::f2::f3 arg);
   class f3 {};
   };
   friend void bar(f1::f2::f3 arg);
   };
   voidbar(f1::f2::f3 arg) {}


-- 


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

[Bug bootstrap/45177] [4.6 regression] cc1 runs out of memory building libgcc in ARM cross-compiler

[bernds at gcc dot gnu dot org]

--- Comment #8 from bernds at gcc dot gnu dot org  2010-08-10 22:31 ---
Yes.


-- 

bernds at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED


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

[Bug c++/45249] Indirect variable parameters sometimes cause segmentation fault

[rogerio at rilhas dot com]

--- Comment #5 from rogerio at rilhas dot com  2010-08-10 22:33 ---
Are you sure this is the way to resolve this issue? I think this will make GCC
an inferior product, as all other compilers I've tested produce correct
results. As GCC sometimes produces correct code (and in such cases it works) I
don't see anyway to get around the fact that this is, in fact, a bug.

Additionally, I've sent you an example of how to compile it in a way that it
works when compiled with GCC. Furthermore, I think most people would expect it
to work as I'm passing the address of the original parameter. I've also shown
the code for Windows where I can then use a va, but there doesn't seem to exist
an equivalent for LINUX. Even if there were an equivalent this bug would affect
its behaviour too, as I've checked the memory contents and the format string
seems to have been copied and its original address on the stack is no longer
preserved, which, of course, is wrong.

If you still decide to discard this problem I will end up with no way to work
around it and will have to definitively abandon LINUX as a software platform
because of this shortcomming of GCC (which, I repeat, is not found on other
compilers).

Thanks,
Rogerio


-- 

rogerio at rilhas dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug c++/45249] Indirect variable parameters sometimes cause segmentation fault

[rogerio at rilhas dot com]

--- Comment #6 from rogerio at rilhas dot com  2010-08-10 22:35 ---
Let me just add: if you can tell me what options to set to make it always work
that would already be helpful. I noticed that disabling optimizations helps,
but not everytime (adding a lot of local automatic variables to the direct
function seems to have a negative effect sometimes).


-- 


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

[Bug c++/45249] Indirect variable parameters sometimes cause segmentation fault

[pinskia at gcc dot gnu dot org]

--- Comment #7 from pinskia at gcc dot gnu dot org  2010-08-10 23:08 ---
>correct results. 

There is no correct results since you are depending on undefined behavior.  It
is not a short coming of GCC but rather the source you are trying to port.  The
code is not portable at all.  It will not work on other compilers besides GCC. 
It will not work on other targets where MS had a compiler (like their PowerPC
Windows machines [xbox and WinNT 3.5 and such]).


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug libstdc++/42925] Not possible to compare unique_ptr with 0

[paolo dot carlini at oracle dot com]

--- Comment #12 from paolo dot carlini at oracle dot com  2010-08-10 23:48 
---
Jon, is this actually GB 99? Trivially adding something like (& co, likewise
for shared_ptr):

  template
inline bool
operator!=(const unique_ptr<_Tp, _Tp_Deleter>& __x, nullptr_t)
{ return __x.get() != nullptr; }

appears to work. If you agree, I would even propose going ahead and adding the
overloads, give them some testing in mainline.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC|jason at gcc dot gnu dot org|jwakely dot gcc at gmail dot
   ||com


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

[Bug fortran/45173] internal compiler error when calling reshape

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2010-08-11 00:04 ---
Closing as fixed then.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   Keywords||ice-on-invalid-code
 Resolution||FIXED
   Target Milestone|--- |4.5.0


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

[Bug fortran/45186] [4.5/4.6 Regression] Gfortran 4.5.0 emits wrong linenumbers

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.5.2


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

[Bug libstdc++/42925] Not possible to compare unique_ptr with 0

[redi at gcc dot gnu dot org]

--- Comment #13 from redi at gcc dot gnu dot org  2010-08-11 00:15 ---
Yes, I agree. I think it would be good to add the overloads, they can always be
adjusted before 4.6 if they don't match the wording Alisdair proposes.


-- 


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

[Bug c++/45201] ICE: stack overflow

[pinskia at gcc dot gnu dot org]

--- Comment #7 from pinskia at gcc dot gnu dot org  2010-08-11 00:16 ---
(In reply to comment #6)
> Created an attachment (id=21434)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21434&action=view) [edit]
> gdb backtrace
> 

Hmm, GGC strikes again.  Well really a small stack size on windows strikes with
GGC.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||GC, ice-on-valid-code


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

[Bug other/45238] gccgo failure to build

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|critical|normal


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

[Bug target/45247] Internal error: Segmentation fault

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|critical|normal
  Component|c   |target
 GCC target triplet||i386-mingw32


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

[Bug tree-optimization/45241] [4.5/4.6 Regression] CPU2006 465.tonto ICE in the vectorizer with -fno-tree-pre

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.5.2


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

[Bug bootstrap/45119] [4.6 Regression] Bootstrap went to infinite loop

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2010-08-11 00:32 ---
Fixed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 GCC target triplet||HWI==32bits
   Keywords||build
 Resolution||FIXED


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

[Bug c++/45157] gcc with response files produces execv: Argument list too long for collect2

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2010-08-11 00:44 ---
Was fixed in 4.5.0 by the patch which fixed PR 31567.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.5.0


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

[Bug c++/45158] Nested classes

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2010-08-11 00:49 ---
This is valid code and should not be rejected I think.  Comeau C++ compiler
agrees with GCC here too.  X::X is the same as X


-- 


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

[Bug c++/45249] Indirect variable parameters sometimes cause segmentation fault

[rogerio at rilhas dot com]

--- Comment #8 from rogerio at rilhas dot com  2010-08-11 00:54 ---
I think you are wrong, I'm not depending on undefined behaviour. When I request
&format that is clearly defined: I should be getting the address of the format
pointer as placed on the stack. Just like I would when requesting the address
of an int parameter placed on the stack, I would get its stack address. If were
to write to that address I would write onto the stack. That is well defined.
Then, by another well defined attribute (the calling convention) I should be
able to navigate the stack to get the other parameters. There is no hack here!
It is all well defined. As long as the compiler doesn't "mess it up" and do
something "undocummented" or something that violates these well-defined
behaviours then everything is just fine. A compiler that doesn't verify both of
these 2 well-defined characteristics simultaneously has a bug.

I'm not coding for the Xbox nor for NT 3.5, but I assume that if I can get
Microsoft's compiler to use the calling convention that I want I will be able
to get the code to run. The reasoning is very simple: when I request
Microsoft's compilers something like &format I get the stack address for the
format variable placed on the stack (as expected, not some copy unpredictably
placed somewhere else on the stack), and as Microsoft's compilers strictly
respect the calling conventions then I'm sure it would work. Microsoft's
compilers don't "mess it up" while optimizing. The only possibility for it not
to work would be for Microsoft's compiler not to let me select the calling
convention I wanted, which I seriously doubt.

To prove this I just compiled the code to Windows Mobile and it works just fine
on an ARM platform (my mobile phone), compiled with Visual Studio 2008, despite
the fact that it is a very diferent platform from x86. In fact, it is
conceptually very close to PowerPC, so I think this code would compile
correctly on PowerPC as well.

As I stated there is no undefined behaviour here, and I know exactly what I am
doing when I'm navigating the stack based on the address of the original format
string on the stack and on the calling convention used. That is what I would do
if programming in assembly language, so the compiler must not "mess up" these 2
well defined items.

So there is nothing wrong with my source, and it works everywhere I tried
except with GCC. From your comment I suspect I'm just wasting my time, because
you seem to be missing the point altogether. But of course I respect your
position of not fixing this (as I must, since I'm not the one working on
GCC!!).

I reopened the bug just to give you this last piece of information about the
Windows Mobile (no need to reply if you don't want to). Since you are very keen
on closing this report whithout backing your claims and clearly explaining how
come you say the behaviour is not defined I don't feel the interest to persue
this issue any further (especially because I feel it shouldn't be necessary for
me to explain all this, I think it should be fairly obvious to people
developing a compiler), so I will just drop LINUX for now (until I have the
oportunity to test other compilers).

Thanks for your attention anyway!


-- 

rogerio at rilhas dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug c++/45249] Indirect variable parameters sometimes cause segmentation fault

[pinskia at gcc dot gnu dot org]

--- Comment #9 from pinskia at gcc dot gnu dot org  2010-08-11 00:58 ---
>Then, by another well defined attribute (the calling convention) I should be
able to navigate the stack to get the other parameters.

No, the C/C++ standard says doing that is undefined because the array size is
1.  That is the point I am trying to make, you are depending on undefined
behavior as defined by the C/C++ standards.  Going past the bounds of an array
is undefined.  This is well known that it causes undefined behavior.  Yes
&argument is defined but it is defined only be accessed to that address no
others.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug target/45247] Internal error: Segmentation fault

[leledumbo_cool at yahoo dot co dot id]

--- Comment #2 from leledumbo_cool at yahoo dot co dot id  2010-08-11 01:04 
---
Yeah, it works when I compile it myself. But it fails when compiling from make.

Hmm... looks very similar to PR39820, even problem source is the same: regex
(but of course they're different implementation, only some parts are the same).

Got any idea what I should do?


-- 


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

[Bug libstdc++/42925] [GB 99] Not possible to compare unique_ptr with 0

[paolo dot carlini at oracle dot com]

--- Comment #14 from paolo dot carlini at oracle dot com  2010-08-11 01:09 
---
Great, I'll do that.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |
Summary|Not possible to compare |[GB 99] Not possible to
   |unique_ptr with 0   |compare unique_ptr with 0


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

[Bug libstdc++/42925] [GB 99] Not possible to compare unique_ptr with 0

[paolo dot carlini at oracle dot com]

-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

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


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

[Bug libstdc++/40974] [4.3/4.4/4.5/4.6 Regression] cannot build gcc-4.4.1: fenv_t has not been declared

[pinskia at gcc dot gnu dot org]

--- Comment #39 from pinskia at gcc dot gnu dot org  2010-08-11 01:12 
---
(In reply to comment #38)
> (In reply to comment #37)
> > Thus, does adding -nostdinc++ to the PCHs flags work for you?
> Testing that right now.  

No it did not for uclibc:
mips64-octeon-linux-gnu-c++
-L/data/src/gcc-cavium/clean/trunk/build-linux-native/./ld  -mabi=n32 -muclibc
-Winvalid-pch -x c++-header -g -O2
--sysroot=/data/src/gcc-cavium/clean/trunk/tools/mips64-octeon-linux-gnu/sys-root
-D_GNU_SOURCE -minterlink-mips16
--sysroot=/data/src/gcc-cavium/clean/trunk/tools/mips64-octeon-linux-gnu/sys-root
 -nostdinc++
-I/data/src/gcc-cavium/clean/trunk/build-linux-native/mips64-octeon-linux-gnu/n32/uclibc/libstdc++-v3/include/mips64-octeon-linux-gnu
-I/data/src/gcc-cavium/clean/trunk/build-linux-native/mips64-octeon-linux-gnu/n32/uclibc/libstdc++-v3/include
-I/data/src/gcc-cavium/clean/trunk/src/libstdc++-v3/libsupc++ -O2 -g
/data/src/gcc-cavium/clean/trunk/src/libstdc++-v3/include/precompiled/stdtr1c++.h
-o mips64-octeon-linux-gnu/bits/stdtr1c++.h.gch/O2g.gch
In file included from
/data/src/gcc-cavium/clean/trunk/build-linux-native/mips64-octeon-linux-gnu/n32/uclibc/libstdc++-v3/include/tr1/cfenv:41,
 from
/data/src/gcc-cavium/clean/trunk/src/libstdc++-v3/include/precompiled/stdtr1c++.h:38:
/data/src/gcc-cavium/clean/trunk/build-linux-native/mips64-octeon-linux-gnu/n32/uclibc/libstdc++-v3/include/fenv.h:41:24:
error: fenv.h: No such file or directory


-- 


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

[Bug libstdc++/40974] [4.3/4.4/4.5/4.6 Regression] cannot build gcc-4.4.1: fenv_t has not been declared

[pinskia at gcc dot gnu dot org]

--- Comment #40 from pinskia at gcc dot gnu dot org  2010-08-11 01:19 
---
c++config.h:#define _GLIBCXX_HAVE_FENV_H 1

is happening for uclibc for the Canadian build but not for the cross:
c++config.h:/* #undef _GLIBCXX_HAVE_FENV_H */


-- 


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

[Bug target/45250] New: [4.6 Regression] FAIL: tr1/5_numerical_facilities/special_functions/01_assoc_laguerre/check_nan.cc

[danglin at gcc dot gnu dot org]

Executing on host: /home/dave/gnu/gcc/objdir/./gcc/g++ -shared-libgcc
-B/home/dave/gnu/gcc/objdir/./gcc -nostdinc++
-L/home/dave/gnu/gcc/objdir/hppa-linux/libstdc++-v3/src
-L/home/dave/gnu/gcc/objdir/hppa-linux/libstdc++-v3/src/.libs
-B/home/dave/opt/gnu/gcc/gcc-4.6.0/hppa-linux/bin/
-B/home/dave/opt/gnu/gcc/gcc-4.6.0/hppa-linux/lib/ -isystem
/home/dave/opt/gnu/gcc/gcc-4.6.0/hppa-linux/include -isystem
/home/dave/opt/gnu/gcc/gcc-4.6.0/hppa-linux/sys-include
-B/home/dave/gnu/gcc/objdir/hppa-linux/./libstdc++-v3/src/.libs -g -O2
-D_GLIBCXX_ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections -g -O2
-D_GNU_SOURCE -g -O2 -D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++
-I/home/dave/gnu/gcc/objdir/hppa-linux/libstdc++-v3/include/hppa-linux
-I/home/dave/gnu/gcc/objdir/hppa-linux/libstdc++-v3/include
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/include/backward
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/util
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/tr1/5_numerical_facilities/special_functions/01_assoc_laguerre/check_nan.cc
   -include bits/stdc++.h ./libtestc++.a -Wl,--gc-sections  -lm   -o
./check_nan.exe(timeout = 600)
spawn /home/dave/gnu/gcc/objdir/./gcc/g++ -shared-libgcc
-B/home/dave/gnu/gcc/objdir/./gcc -nostdinc++
-L/home/dave/gnu/gcc/objdir/hppa-linux/libstdc++-v3/src
-L/home/dave/gnu/gcc/objdir/hppa-linux/libstdc++-v3/src/.libs
-B/home/dave/opt/gnu/gcc/gcc-4.6.0/hppa-linux/bin/
-B/home/dave/opt/gnu/gcc/gcc-4.6.0/hppa-linux/lib/ -isystem
/home/dave/opt/gnu/gcc/gcc-4.6.0/hppa-linux/include -isystem
/home/dave/opt/gnu/gcc/gcc-4.6.0/hppa-linux/sys-include
-B/home/dave/gnu/gcc/objdir/hppa-linux/./libstdc++-v3/src/.libs -g -O2
-D_GLIBCXX_ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections -g -O2
-D_GNU_SOURCE -g -O2 -D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++
-I/home/dave/gnu/gcc/objdir/hppa-linux/libstdc++-v3/include/hppa-linux
-I/home/dave/gnu/gcc/objdir/hppa-linux/libstdc++-v3/include
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/include/backward
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/util
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/tr1/5_numerical_facilities/special_functions/01_assoc_laguerre/check_nan.cc
-include bits/stdc++.h ./libtestc++.a -Wl,--gc-sections -lm -o ./check_nan.exe
In file included from
/home/dave/gnu/gcc/objdir/hppa-linux/libstdc++-v3/include/tr1/cmath:95:0,
 from
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/tr1/5_numerical_facilities/special_functions/01_assoc_laguerre/check_nan.cc:25:
/home/dave/gnu/gcc/objdir/hppa-linux/libstdc++-v3/include/tr1/poly_laguerre.tcc:
In function '_Tp std::tr1::__detail::__poly_laguerre_large_n(unsigned int,
_Tpa, _Tp) [with _Tpa = unsigned int, _Tp = long double]':
/home/dave/gnu/gcc/objdir/hppa-linux/libstdc++-v3/include/tr1/poly_laguerre.tcc:106:5:
internal compiler error: in simplify_subreg, at simplify-rtx.c:5129
Please submit a full bug report,

Similar fails are:
FAIL:
tr1/5_numerical_facilities/special_functions/01_assoc_laguerre/check_value
.cc (test for excess errors)
FAIL: tr1/5_numerical_facilities/special_functions/01_assoc_laguerre/compile.cc 
(test for excess errors)
FAIL:
tr1/5_numerical_facilities/special_functions/01_assoc_laguerre/compile_2.c
c (test for excess errors)
FAIL: tr1/5_numerical_facilities/special_functions/18_laguerre/check_nan.cc
(tes
t for excess errors)
FAIL: tr1/5_numerical_facilities/special_functions/18_laguerre/check_value.cc
(t
est for excess errors)
FAIL: tr1/5_numerical_facilities/special_functions/18_laguerre/compile.cc (test 
for excess errors)
FAIL: tr1/5_numerical_facilities/special_functions/18_laguerre/compile_2.cc
(tes
t for excess errors)

According to testsuite results, 162412 was ok and 162417 fails.

Don't know how far backtrace can be trusted.  Line numbers are whacky.

Breakpoint 2, 0x00552e94 in simplify_subreg (outermode=DFmode, op=0x60293440, 
innermode=DFmode, byte=16) at ../../gcc/gcc/simplify-rtx.c:215
215   && MEM_EXPR (x)
(gdb) p debug_rtx (op)
(const_double:DF -2147483648 [0x8000] 1.0e+0 [0x0.8p+1])
$1 = void
(gdb) bt
#0  0x00552e94 in simplify_subreg (outermode=DFmode, op=0x60293440, 
innermode=DFmode, byte=16) at ../../gcc/gcc/simplify-rtx.c:215
#1  0x0055422c in avoid_constant_pool_reference (x=0x41547130)
at ../../gcc/gcc/simplify-rtx.c:215
#2  0x0051a0e8 in commutative_operand_precedence (op=)
at ../../gcc/gcc/rtlanal.c:1617
#3  0x0051a22c in swap_commutative_operands_p (x=, 
y=0x41547130) at ../../gcc/gcc/rtlanal.c:1617
#4  0x0054aef8 in simplify_rtx (x=0x41547100)
at ../../gcc/gcc/simplify-rtx.c:215
#5  0x002ec2b0 in cselib_expand_value_rtx_1 (orig=, 
evd=0xbff01f48, max_depth=)
at ../../gcc/gcc/cselib.c:2314
#6  0x002ed340 in cselib_expand_value_rtx_cb (orig=, 
regs_active=, max_depth=, 
cb=, data=0xbff01d48) at ../../gcc/gcc/cselib.c:2314
#7  0x0071dc64 in vt_expand_loc_callback (x=0xb20818, regs=0xb0

[Bug libstdc++/40974] [4.3/4.4/4.5/4.6 Regression] cannot build gcc-4.4.1: fenv_t has not been declared

[paolo dot carlini at oracle dot com]

--- Comment #41 from paolo dot carlini at oracle dot com  2010-08-11 01:23 
---
We need a build system expert here.


-- 


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

[Bug libstdc++/40974] [4.3/4.4/4.5/4.6 Regression] cannot build gcc-4.4.1: fenv_t has not been declared

[pinskia at gcc dot gnu dot org]

--- Comment #42 from pinskia at gcc dot gnu dot org  2010-08-11 01:28 
---
Actually looks like a bug in our specs somehow; it is not related to this issue
at all.  But the fix for using -nostdinc++ fixed the real issue.


-- 


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

[Bug c++/45249] Indirect variable parameters sometimes cause segmentation fault

[rogerio at rilhas dot com]

--- Comment #10 from rogerio at rilhas dot com  2010-08-11 01:57 ---
I'm replying now not in the context of the bug (since as I mentioned I must
move on), but just as a conversation between 2 persons. So please don't getting
me wrong for insisting.

The cdecl calling convention on x86-32 machines says that for any function call
the arguments are placed on the stack as a series of 4-byte pushed values. I've
checked that GCC respects this convention when calling a function and not
optimized. So, for a typical GCC functiona call GCC pushes the parameters
correctly according to the cdecl calling convention:

func(a, b, c, d)

... the parameters will pushed right-to-left like:

push d (4-byte)
push c (4-byte)
push b (4-byte)
push a (4-byte)
call func

Obviously there are exceptions for doubles and structs, but this is not the
case here as char* and int are pushed exactly the same way, as 4-byte values.
This is well defined, right? The cdecl calling convention defines this clearly,
correct? Or does GCC somehow uses another calling convention?

Another thing well-defined in C is that when I request the address of a
variable I get the address of it. So, inside func, when I request &a I get the
stack address where "a" was pushed to. This is also well defined, right?

Another thing well defined in C is what happens when navigating an array out of
its bounds. Unlinke what you say, the behaviour is deterministic in absolutely
every machine: if my PTR4 pointer to a 4-byte value contains the value X, then
PTR4[1] accesses address memory X+4. The same way, if my PTR2 points to a
2-byte value at address Y, then PTR2[1] will access address Y+2. There is no
hack here either, the behaviour is very well defined, and C doesn't care about
or check the bounds of the array.

So, if the calling convention states (in the example above) that "b" is placed
4 bytes after "a", and that "c" is placed 4 bytes after "b", and so on, it
follows, without any doubt, that if I get a PTR4 to point to "a", and the
address of "a" on the stack is X, then PTR4[0] accesses "a", PTR4[1] accesses
"b", PTR4[2] accesses "c", and so on. It doesn't mater the size of the array, C
will not check nor care about it, I can navigate the stack with it. That is
what I do with format_address, since it is a char** and char** has size 4 then
format_address is a PTR4. So, format_address[0] is "a" (or it should be if
&format returned the true address of "a"), and *without any doubt or hack*
format_address[1] is "b", and *with exactly the same confidence*,
format_address[2] is "c", and so on. This is one of the most well established
bases in C, for several decades now, so there is really no arguing about it.

The problem is that GCC, when optimizing, places "a" somewhere on the stack
which is not contiguous to "b". I think (although I'm not sure) that GCC does
something like this:

push d
push c
push b
push a
call format_direct

format_direct:
push some varied stuff
push [a copy of the original "a" again somewhere]
push [address of the above copy of "a"]
call format_indirect

format_indirect: (example)
mov eax,[address of the copy of "a"+0] // not the original "a", but the copy
mov ebx,[address of the copy of "a"+4] // contains some varied stuff, not "b"

I'm not sure if GCC does exactly this, but I'm sure that, when optimizing, GCC
does not place "a" adjacent to "b", and it should. Since I cannot get to "b"
I'm not sure if the same happens to "c".

This clearly violates the calling convention. If the calling convention were
respected then "a", "b", "c", and "d" would all be adjacent, so I could
navigate the 1-entry (4-byte) array using format_address[0], format_address[1],
format_address[2], and format_address[3]. I don't see how you can refute one of
the most well established properties of C, as the language allows me to
populate any memory buffer with whichever stuff and then navigate with a 4-byte
pointer (as long as properly aligned, which is the case here). I'm just doing
that with the stack, wich should be (by the calling convention) a 4-byte
aligned memory buffer with 4 adjacent 4-byte values "abcd".

So, my point is: if - req1) GCC placed the parameters on the stack adjacent to
one another (as it should as a result of the selected calling convention) *AND*
- req2) if it gave me the address of the original format parameter on the stack
(as it should by the definition of getting the address of a function parameter)
then the code would work correctly, since - req3) is well established that C
does not perform array boundary checking and, thus, PTR4[1] accesses memory
location exactly 4 bytes after memory location PTR4[0].

Since I believe none of these 3 requirements is refutable, and since they are
all well established, then - bug1) GCC is not putting the parameters adjacent
on the stack as it should *OR* - bug2) GCC is not giving me the correct address
when I ask for &format. The - bug3) of not doing pointer arithmetic correctly
because the array has s

[Bug middle-end/45251] New: [4.6 Regression] Java testsuite regressions on hppa-linux

[danglin at gcc dot gnu dot org]

The following new fails appeared between revision 162917 and 162948:
FAIL: pr29812 execution - gij test
FAIL: ExtraClassLoader execution - source compiled test
FAIL: ExtraClassLoader -findirect-dispatch execution - source compiled test
FAIL: ExtraClassLoader -O3 execution - source compiled test
FAIL: ExtraClassLoader -O3 -findirect-dispatch execution - source compiled test

Executing on host: /home/dave/gnu/gcc/objdir/gcc/xgcc
-B/home/dave/gnu/gcc/objdi
r/gcc/ /home/dave/gnu/gcc/gcc/libjava/testsuite/libjava.jni/pr29812_injar.c 
-sh
ared -fPIC -I. -I.. -I/home/dave/gnu/gcc/gcc/libjava/testsuite/libjava.jni
-fdol
lars-in-identifiers -Wmissing-prototypes
-I/home/dave/gnu/gcc/gcc/libjava/testsu
ite/../include -I/home/dave/gnu/gcc/gcc/libjava/testsuite/../classpath/include  
 -lm   -o libpr29812_injar.so(timeout = 300)
PASS: pr29812_injar.c compilation
set_ld_library_path_env_vars:
ld_library_path=.:/home/dave/gnu/gcc/objdir/hppa-l
inux/./libjava/.libs:/home/dave/gnu/gcc/objdir/gcc
invoke: /home/dave/gnu/gcc/objdir/hppa-linux/./libjava/gij -classpath
/home/dave
/gnu/gcc/gcc/libjava/testsuite/libjava.jni/pr29812.jar pr29812
/home/dave/gnu/gc
c/gcc/libjava/testsuite/libjava.jni/pr29812_injar.jar 
Setting LD_LIBRARY_PATH to
.:/home/dave/gnu/gcc/objdir/hppa-linux/./libjava/.lib
s:/home/dave/gnu/gcc/objdir/gcc:.:/home/dave/gnu/gcc/objdir/hppa-linux/./libjava
/.libs:/home/dave/gnu/gcc/objdir/gcc:/home/dave/gnu/gcc/objdir/hppa-linux/libstd
c++-v3/.libs:/home/dave/gnu/gcc/objdir/hppa-linux/libmudflap/.libs:/home/dave/gn
u/gcc/objdir/hppa-linux/libssp/.libs:/home/dave/gnu/gcc/objdir/hppa-linux/libgom
p/.libs:/home/dave/gnu/gcc/objdir/./gcc:/home/dave/gnu/gcc/objdir/./prev-gcc
lt-gij:
/home/dave/gnu/gcc/gcc/libjava/testsuite/libjava.jni/pr29812_injar.c:16:
 JNI_OnLoad: Assertion `k != ((void *)0)' failed.
FAIL: pr29812 execution - gij test
UNTESTED: pr29812 output - gij test

The others are like the following:
Exception in thread "main" java.lang.ClassNotFoundException: C not found in
gnu.
gcj.runtime.SystemClassLoader{urls=[file:./,file:/home/dave/gnu/gcc/gcc/libjava/
testsuite/libjava.lang/,file:/home/dave/gnu/gcc/objdir/hppa-linux/libjava/testsu
ite/,file:/home/dave/gnu/gcc/objdir/hppa-linux/libjava/testsuite/../libgcj-4.6.0
.jar], parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
   at java.net.URLClassLoader.findClass(URLClassLoader.java:531)
   at java.lang.ClassLoader.loadClass(ClassLoader.java:452)
   at java.lang.ClassLoader.loadClass(ClassLoader.java:387)
   at java.lang.Class.forName(natClass.cc:105)
   at java.lang.Class.newInstance(natClass.cc:664)
   at ExtraClassLoader.main(ExtraClassLoader.java:9)
FAIL: ExtraClassLoader execution - source compiled test
UNTESTED: ExtraClassLoader output - source compiled test


-- 
   Summary: [4.6 Regression] Java testsuite regressions on hppa-
linux
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
 GCC build triplet: hppa-unknown-linux-gnu
  GCC host triplet: hppa-unknown-linux-gnu
GCC target triplet: hppa-unknown-linux-gnu


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

[Bug target/45252] New: unnecessary register move

[carrot at google dot com]

Compile the following code with options -march=armv7-a -mthumb -Os

struct S{
int f1;
int reserved[3];
};

void ts()
{
struct S map;
map.f1 = 0;
foo(&map);
}

GCC 4.6 generates:

ts:
push{r0, r1, r2, r3, r4, lr}
add r0, sp, #16// A
movsr3, #0
str r3, [r0, #-16]!// B
mov r0, sp // C
bl  foo
add sp, sp, #20
pop {pc}

After instruction B, register r0 already contains the value of sp, so
instruction C is not required, as shown in following.

ts:
push{r0, r1, r2, r3, r4, lr}
add r0, sp, #16
movsr3, #0
str r3, [r0, #-16]!
bl  foo
add sp, sp, #20
pop {pc}

The RTL insns before IRA

(insn 12 5 6 2 (set (reg/f:SI 134)
(reg/f:SI 25 sfp)) src/ts.c:9 694 {*thumb2_movsi_insn}
 (nil))

(insn 6 12 8 2 (set (mem/s/c:SI (pre_modify:SI (reg/f:SI 134)
(plus:SI (reg/f:SI 134)
(const_int -16 [0xfff0]))) [3 map.f1+0 S4 A64])
(reg:SI 133)) src/ts.c:9 694 {*thumb2_movsi_insn}
 (expr_list:REG_DEAD (reg:SI 133)
(expr_list:REG_INC (reg/f:SI 134)
(expr_list:REG_EQUAL (const_int 0 [0])
(nil)

(insn 8 6 9 2 (set (reg:SI 0 r0)
(reg/f:SI 134)) src/ts.c:10 694 {*thumb2_movsi_insn}
 (expr_list:REG_DEAD (reg/f:SI 134)
(expr_list:REG_EQUAL (plus:SI (reg/f:SI 25 sfp)
(const_int -16 [0xfff0]))
(nil

It shows the address register in insn 6 can be used in insn 8 directly. At RA
stage, physical register r0 is assigned to pseudo register r134, so insn 8
should be
mov  r0, r0
which should be removed in later pass.

But gcc also finds out from note that r134 is equal to (sfp - 16) which is
equal to sp at the same time. So it generates 
mov r0, sp


There is even better result:

ts:
push{r0, r1, r2, r3, r4, lr}
movsr3, #0
str r3, [sp]
mov r0, sp
bl  foo
add sp, sp, #20
pop {pc}

It contains same number of instructions, but the instructions are simpler and
shorter. Actually the IL was in this form after expand

(insn 5 2 6 2 (set (reg:SI 133)
(const_int 0 [0])) src/ts.c:9 694 {*thumb2_movsi_insn}
 (nil))

(insn 6 5 7 2 (set (mem/s/c:SI (plus:SI (reg/f:SI 25 sfp)
(const_int -16 [0xfff0])) [3 map.f1+0 S4 A64])
(reg:SI 133)) src/ts.c:9 694 {*thumb2_movsi_insn}
 (expr_list:REG_DEAD (reg:SI 133)
(expr_list:REG_EQUAL (const_int 0 [0])
(nil

(insn 7 6 8 2 (set (reg/f:SI 134)
(plus:SI (reg/f:SI 25 sfp)
(const_int -16 [0xfff0]))) src/ts.c:10 4 {*arm_addsi3}
 (nil))

(insn 8 7 9 2 (set (reg:SI 0 r0)
(reg/f:SI 134)) src/ts.c:10 694 {*thumb2_movsi_insn}
 (expr_list:REG_DEAD (reg/f:SI 134)
(expr_list:REG_EQUAL (plus:SI (reg/f:SI 25 sfp)
(const_int -16 [0xfff0]))
(nil

After pass auto_inc_dec, (sfp - 16) is identified as an opportunity for
auto_inc_dec optimization. But it doesn't bring any benefit for this case, and
causes more complex instructions.


-- 
   Summary: unnecessary register move
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
 GCC build triplet: i686-linux
  GCC host triplet: i686-linux
GCC target triplet: arm-eabi


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

[Bug bootstrap/45206] [4.6 regression] ICE in ix86_expand_epilogue compiling libgcc

[sgk at troutmask dot apl dot washington dot edu]

--- Comment #7 from sgk at troutmask dot apl dot washington dot edu  
2010-08-11 03:48 ---
Subject: Re:  [4.6 regression] ICE in ix86_expand_epilogue compiling libgcc

On Tue, Aug 10, 2010 at 05:49:40AM -, ebotcazou at gcc dot gnu dot org
wrote:
> > Does anyone know which combination of recent commits is causing this 
> > problem?
> 
> The set of RTH's patches.  Configure --with-tune=i686 to work around it.
> 

Thanks, Eric.  The --with-tune=i686 has me back in the
hacking business.


-- 


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

[Bug c++/45249] Indirect variable parameters sometimes cause segmentation fault

[pinskia at gcc dot gnu dot org]

--- Comment #11 from pinskia at gcc dot gnu dot org  2010-08-11 03:52 
---
The ABI is not of concern here really.  The issue comes down to you have:
char *a;
char **b = &a;
use(b[1]);

It is undefined what happens when you access b[1].  It does not matter if the
ABI defines that the arguments are passed via the stack in ascending order or
not.  It could pass them via descending order.  Accessing an out of bounds
array is causing the issue here.

This is not about GCC vs MS Visual studio issue, this is a C/C++ standard issue
saying what you are doing is undefined.

>Another thing well defined in C is what happens when navigating an array out of
its bounds.

Kinda, you can go one past the array bounds for the address but you cannot
access it.  That is what the C/C++ standard says.  I can quote the standard if
needed.  Anything else is undefined.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug bootstrap/45053] libgcc_s link command misses crtsavgpr_s and crtresgpr_s for powerpc

[ian at airs dot com]

--- Comment #6 from ian at airs dot com  2010-08-11 04:28 ---
Yes, this is a libgcc issue.  This kind of target-specific issue is normally
handled by the relevant backend maintainers.

I'm surprised that it doesn't work, as libgcc/config/rs6000/t-ppccomm includes
crtsavgpr.S and crtresgpr.S in LIB2ADD_ST.  I would expect that to include the
required functions.  But I haven't tried it, and apparently something goes
wrong.


-- 


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

gcc-bugs@gcc.gnu.org

[pluto at agmk dot net]

#include 
struct S { unsigned addr : 31; };
struct X { static S s; };
int main() { std::make_pair( X::s.addr, true ); }

$ g++ -c t.cpp -std=c++0x 
t.cpp: In function 'int main()':
t.cpp:4:46: error: cannot bind bitfield 'X::s.S::addr' to 'unsigned int&'

comeau online accepts this code.


-- 
   Summary: [c++0x] make_pair / cannot bind bitfield to unsigned&.
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at agmk dot net
 GCC build triplet: x86_64-gnu-linux
  GCC host triplet: x86_64-gnu-linux
GCC target triplet: x86_64-gnu-linux


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