[Bug target/24718] Shared libgcc not used for linking by default

2005-11-12 Thread ebotcazou at gcc dot gnu dot org


--- Comment #16 from ebotcazou at gcc dot gnu dot org  2005-11-12 08:17 
---
 The patch from comment 14 seems to be working fine without any other changes. 
 I have bootstrapped and am currently running the testsuite.  Looks OK so far.

Zack's patch for 4.x doesn't work as-is for 3.4.x because the multilib logic
has changed in mklibgcc.in.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu dot
   ||org


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



[Bug libstdc++/24712] [4.0 Regression] Accidental ABI change between 4.0.1 and 4.0.2?

2005-11-12 Thread debian-gcc at lists dot debian dot org


--- Comment #6 from debian-gcc at lists dot debian dot org  2005-11-12 
09:33 ---
(In reply to comment #2)
 I gather therefore that Debian
 is building GCC passing --enable-libstdcxx-allocator=mt, something absolutely
 not obvious and not trivial in its consequences.

Correct. That decision was based on a discussion on libstdc++ in April 2004.
Please see http://gcc.gnu.org/ml/libstdc++/2005-11/msg00171.html for an open
question.

  Matthias


-- 


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



[Bug java/24572] [4.0 regression] ICE in gimplify_expr, at gimplify.c:3983

2005-11-12 Thread debian-gcc at lists dot debian dot org


--- Comment #4 from debian-gcc at lists dot debian dot org  2005-11-12 
09:35 ---
works with HEAD 2005


-- 

debian-gcc at lists dot debian dot org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
  Known to fail||4.0.3
  Known to work||4.1.0


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



[Bug libstdc++/24800] tr1::mem_fn returns a function object that does not inherit from std::unary_function/binary_function

2005-11-12 Thread pcarlini at suse dot de


--- Comment #3 from pcarlini at suse dot de  2005-11-12 11:27 ---
(In reply to comment #2)
 As for the original bug report: it's easy to verify by inspecting the source
 that _Mem_fn has no base class as required.

I beg to disagree. Have you really checked the actual versions of it for
member function taking no argument and taking one argument? If I do that
in the straightforward way, that is looking at the -E output, the expected
bases are there. In other terms, functional_iterate.h looks fine to me.

 Hope this gives you what you need.

Well, to date, not really, to be honest. I would appreciate a decently
sized testcase (eventually, what are we going to put in the testsuite,
otherwise?!?) or at least reaching a minimum of consensus about the matter
by looking at the sources...

Thanks in advance for your help.


-- 


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



[Bug libstdc++/24800] tr1::mem_fn returns a function object that does not inherit from std::unary_function/binary_function

2005-11-12 Thread doug dot gregor at gmail dot com


--- Comment #4 from doug dot gregor at gmail dot com  2005-11-12 11:33 
---
This is not a bug. TR1 3.5 refers to member function pointers, not member data
pointers as in the submitted test case. mem_fn has no result_type for member
data pointers because the constness of the result type depends on the constness
of the argument type; use result_of to get the appropriate result type given
the argument type. See also TR1 DR 10.24 Mem_fn result_type for pointer to
data member.


-- 

doug dot gregor at gmail dot com changed:

   What|Removed |Added

 CC||doug dot gregor at gmail dot
   ||com


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



[Bug target/24743] NaN or correct result after divrp with 3 FPU registers

2005-11-12 Thread sraa at kse dot nl


--- Comment #3 from sraa at kse dot nl  2005-11-12 12:07 ---
We found out that the stackpointer was unbalanced at a given point. Via a small
program in assembly wich reads the stackpointer that I placed at suspicious
points in the code I found a function that didn't restore the stackpointer
correctly.

This function was of type float and returned a float but this result was not
assigned to any variable... So this has to be it. I know this for sure on
monday since the production has stopped now and I cannot test it.

Example of the false code:

   partijlocmut_kg(geleverd1);  /* returns a float . */

Instead of:

   geleverd1 = partijlocmut_kg(geleverd1);

So a Sun hadn't this problem because the stack is managed differently and the
floating point calculations are done by the software instead of a FPU with
using of the stack registers. Or has something smart or by coincidence to
return the float to a register anyhow. I think it returned the value to the
parameter with which the function was called. Otherwise the software wouldn't
have worked.

If our software was written, in ANSI-C, with correct prototyping of functions,
the compiler would have been able to signal the error. Unfortunalely it isn't.
But now we know how to seatch or what we have to do.

The cause for my problems was not a buggy OS or compiler but just bad written
code.


-- 

sraa at kse dot nl changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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



[Bug libstdc++/24803] tr1::reference_wrapper and pointers to member functions

2005-11-12 Thread pcarlini at suse dot de


--- Comment #1 from pcarlini at suse dot de  2005-11-12 12:45 ---
Doug, can you look a bit into this one too? Thanks!


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 CC||doug dot gregor at gmail dot
   ||com


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



[Bug libstdc++/24803] tr1::reference_wrapper and pointers to member functions

2005-11-12 Thread doug dot gregor at gmail dot com


--- Comment #2 from doug dot gregor at gmail dot com  2005-11-12 13:23 
---
I don't know how to classify this. The basic problem is one that isn't
really solveable without rvalue references: you can't pass a literal
(e.g., 0) into the operator() of a reference_wrapper or any other
function object in TR1, because the arguments are accepted by
T. Strictly speaking, this is not a bug. 

However, there are several ways that we could make this work, because
John is doing some very sensible things here [*]. Some ideas are:

  (1) Strong-arm a C++ front-end guru into implementing rvalue references,
  then use them in the TR1 function objects. Heck, we'll need 'em
  for C++0x anyway :)

  (2) When we know the argument types (e.g., when the T in reference_wrapperT
  is a function pointer, member function pointer, or class that is derived 
  from unary_function or binary_function), we could inject operator() 
  overloads that have precise type signatures, e.g.,

T::result_type operator()(T::argument_type const);

  That's really messy and would require quite a bit of refactoring in 
  reference_wrapper to get right.

  (3) Provide variants of operator() that accept const T arguments in 
  addition to those that accept T arguments. This makes 
  bind/mem_fn/reference_wrapper easier to use, but the number of overloads 
  blows up exponentially. Since we've already run into compilation time 
  issues, we'd have stop doing this once we hit four to five
  arguments (then we get the I just added one more argument and
  everything blew up! bug reports).

  (4) Strong-arm a C++ front-end guru into allowing the conversion
  operator (operator T() const) to actually work for function
  call expressions, making most of reference_wrapperT::operator()
  magically go away. (Peter Dimov has suggested this before, but
  it hasn't really worked its way through the committee).


(1) is the forward-looking solution; (2) and (3) are hacks that could
make the code even uglier (ick!). (4) only fixes the problem for
reference_wrapper. At this point, I favor (1) strongly, but I'm not in
a position to strong-arm nor am I in a position to implement rvalue
references myself.

[*] One thing in the code that perhaps shouldn't work is passing the
literal 0 as the argument to 

  reference_wrapperint (test_type::*)()::operator()

That means that we need to be able to realize that it's a literal 0
(tricky, messy, but doable; see the construction-from-literal-zero
trick in tr1::function) and then convert that to a NULL test_type*.
I don't think John meant to test that, and I don't really think we
should care if it's broken.

A slightly simplified version of John's test case that does work
properly follows. Replace any of null_tt, null_ttc, or zero in the
calls to reference_wrapper objects to trigger compiler errors.

#include tr1/functional

struct test_type
{
   int member();
   int cmember()const;
   int member2(char);
   int cmember2(char)const;
};

struct functor1 : public std::unary_functionint, double
{
   double operator()(int)const;
};

struct functor2 : public std::binary_functionint, char, double
{
   double operator()(int, char)const;
};

template class T
void verify_return_type(T, T)
{
}

int main()
{
   test_type* null_tt = 0;
   const test_type* null_ttc = 0;
   int zero;

   std::tr1::reference_wrapperdouble (int)* pr1;
   verify_return_type((*pr1)(0), double());
   std::tr1::reference_wrapperdouble (*)(int)* pr2;
   verify_return_type((*pr2)(0), double());
   std::tr1::reference_wrapperint (test_type::*)()* pr3;
   verify_return_type((*pr3)(null_tt), int());
   std::tr1::reference_wrapperint (test_type::*)()const* pr4;
   verify_return_type((*pr4)(null_ttc), int());
   std::tr1::reference_wrapperfunctor1* pr5;
   verify_return_type((*pr5)(zero), double());

   std::tr1::reference_wrapperdouble (int, char)* pr1b;
   verify_return_type((*pr1b)(0,0), double());
   std::tr1::reference_wrapperdouble (*)(int, char)* pr2b;
   verify_return_type((*pr2b)(0,0), double());
   std::tr1::reference_wrapperint (test_type::*)(char)* pr3b;
   verify_return_type((*pr3b)(null_tt,zero), int());
   std::tr1::reference_wrapperint (test_type::*)()const* pr4b;
   verify_return_type((*pr4b)(null_ttc), int());
   std::tr1::reference_wrapperfunctor2* pr5b;
   verify_return_type((*pr5b)(zero,zero), double());
}


-- 


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



[Bug libstdc++/24803] tr1::reference_wrapper and pointers to member functions

2005-11-12 Thread pcarlini at suse dot de


--- Comment #3 from pcarlini at suse dot de  2005-11-12 13:27 ---
Hi Doug. First thing to do, before actually studying your extremely useful and
detailed reply (THANKS), is adding Howard in CC...


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 CC||hhinnant at apple dot com


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



[Bug libstdc++/24818] New: tr1::reference_wrapper improperly calls nullary function objects

2005-11-12 Thread doug dot gregor at gmail dot com
tr1::reference_wrapperT::operator()() should not dereference get() before
calling the function object, because get() returns a reference (not a pointer).


-- 
   Summary: tr1::reference_wrapper improperly calls nullary function
objects
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: doug dot gregor at gmail dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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



[Bug libstdc++/24818] tr1::reference_wrapper improperly calls nullary function objects

2005-11-12 Thread doug dot gregor at gmail dot com


--- Comment #1 from doug dot gregor at gmail dot com  2005-11-12 13:31 
---
Created an attachment (id=10225)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10225action=view)
Mainline (4.1.0) patch to test and fix this problem

The fix is trivial. The changes to the test case cause failures that are fixed
by the patch to ref_wrap_iterate.h. All of the tr1/3_function_objects tests
still pass on i686-pc-linux-gnu.

2005-11-12  Douglas Gregor  [EMAIL PROTECTED]

* include/tr1/ref_wrap_iterate.h
(reference_wrapper::operator()()): Don't dereferene the result of
get() before calling it; it's already a reference.
* testsuite/tr1/3_function_objects/reference_wrapper/invoke.cc:
Test nullary calls to reference_wrappers.


-- 


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



[Bug libstdc++/24818] tr1::reference_wrapper improperly calls nullary function objects

2005-11-12 Thread pcarlini at suse dot de


--- Comment #2 from pcarlini at suse dot de  2005-11-12 13:33 ---
Thanks a lot. I will take care of applying the patch asap.


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pcarlini at suse dot de
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2005-11-12 13:33:55
   date||


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



[Bug regression/24819] New: glibc math tests miscompiled with gcc-4.1

2005-11-12 Thread olh at suse dot de
make check fails with -O2 on powerpc64-linux and powerpc-linux with gcc-4.1
Works ok with gcc-4.0, and also with 4.1 and -O1.

ppc64:
make[2]: *** [/usr/src/packages/BUILD/glibc-2.3/cc-nptl/math/test-float.out]
Error 1
make[2]: *** [/usr/src/packages/BUILD/glibc-2.3/cc-nptl/math/test-double.out]
Error 1
make[2]: *** [/usr/src/packages/BUILD/glibc-2.3/cc-nptl/math/test-ifloat.out]
Error 1
make[2]: *** [/usr/src/packages/BUILD/glibc-2.3/cc-nptl/math/test-idouble.out]
Error 1
make[1]: *** [math/tests] Error 2

ppc:
make[2]: *** [/usr/src/packages/BUILD/glibc-2.3/cc-nptl/math/test-float.out]
Error 1
make[1]: *** [math/tests] Error 2

(make check runs without -k on ppc, the failure rate might be the same as on
ppc64).

Will post details and possible a testcase, later.


-- 
   Summary: glibc math tests miscompiled with gcc-4.1
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: olh at suse dot de
 GCC build triplet: powerpc-linux
  GCC host triplet: powerpc-linux
GCC target triplet: powerpc-linux


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



[Bug regression/24819] glibc math tests miscompiled with gcc-4.1

2005-11-12 Thread olh at suse dot de


--- Comment #1 from olh at suse dot de  2005-11-12 14:07 ---
Created an attachment (id=10226)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10226action=view)
pr24819-failure.txt

make check errors on powerpc-linux


-- 


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



[Bug libstdc++/24595] std::tr1::get_deleter not declared

2005-11-12 Thread gcc-bugzilla at kayari dot org


--- Comment #6 from gcc-bugzilla at kayari dot org  2005-11-12 14:12 ---
Created an attachment (id=10227)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10227action=view)
alternative fix

This is a fixed version of the previous patch that passes tests on
linux-x86_64.

This patch makes all specialisations of get_deleter friends, not just the ones
where _Tp == _Tp1 ... but that's probably not a big deal.  


-- 

gcc-bugzilla at kayari dot org changed:

   What|Removed |Added

  Attachment #10194|0   |1
is obsolete||


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



[Bug target/24475] gcc.dg/tls/pr24428.c execution test and gcc.dg/tls/pr24428-2.c execution test fail on IA32

2005-11-12 Thread joseph at codesourcery dot com


--- Comment #4 from joseph at codesourcery dot com  2005-11-12 14:24 ---
Subject: Re:  gcc.dg/tls/pr24428.c execution test and
 gcc.dg/tls/pr24428-2.c execution test fail on IA32

On Thu, 10 Nov 2005, jakub at gcc dot gnu dot org wrote:

 Does even a trivial __thread using program break fail at runtime?
 __thread int thr;
 int main (void) { return thr; }

Yes, it segfaults on the system in question; it also seems to segfault 
with more recent glibc configured with --without-tls.


-- 


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



[Bug ada/18434] [4.0/4.1 Regression] Ada: cannot build gnattools on Tru64 UNIX V5.1B

2005-11-12 Thread debian-gcc at lists dot debian dot org


--- Comment #15 from debian-gcc at lists dot debian dot org  2005-11-12 
14:59 ---
workaround works with 4.0.3 on alpha-linux as well, 4.1 build currently fails
in stage3

  Matthias


-- 


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



[Bug tree-optimization/24819] [4.1 Regression] glibc math tests miscompiled with gcc-4.1

2005-11-12 Thread pinskia at gcc dot gnu dot org


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
  Component|regression  |tree-optimization
   Keywords||wrong-code
Summary|glibc math tests miscompiled|[4.1 Regression] glibc math
   |with gcc-4.1|tests miscompiled with gcc-
   ||4.1


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



[Bug middle-end/24819] [4.1 Regression] glibc math tests miscompiled with gcc-4.1

2005-11-12 Thread pinskia at gcc dot gnu dot org


--- Comment #2 from pinskia at gcc dot gnu dot org  2005-11-12 15:31 ---
Waiting for a testcase.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|tree-optimization   |middle-end


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



[Bug middle-end/24819] [4.1 Regression] glibc math tests miscompiled with gcc-4.1

2005-11-12 Thread pinskia at gcc dot gnu dot org


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.1.0


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



[Bug c/23397] Compilation Ghostscript gs_init.c file failed on mipsel-linux machine

2005-11-12 Thread pinskia at gcc dot gnu dot org


--- Comment #4 from pinskia at gcc dot gnu dot org  2005-11-12 15:36 ---
No feedback in 3 months (T-3 days).


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID


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



[Bug middle-end/23785] [4.1 Regression] 197.parser performance drop

2005-11-12 Thread pinskia at gcc dot gnu dot org


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P2  |P3
Summary|197.parser performance drop |[4.1 Regression] 197.parser
   ||performance drop
   Target Milestone|--- |4.1.0


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



[Bug ada/18434] [4.0/4.1 Regression] Ada: cannot build gnattools on Tru64 UNIX V5.1B

2005-11-12 Thread laurent at guerby dot net


--- Comment #16 from laurent at guerby dot net  2005-11-12 16:11 ---
Arnaud has a patch for this issue on trunk and a better workaround patch for
4.0.

Could you post your stage3 failure?


-- 

laurent at guerby dot net changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |charlet at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED


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



[Bug middle-end/24820] New: [4.1 regression] SEGV in integer_valued_real_p at gcc/builtins.c:6711

2005-11-12 Thread belyshev at depni dot sinp dot msu dot ru
// Compile this with -O2 -ffast-math to get segfault

double floor (double);
double bar (double sum)
{
  int i;
  for (i = 0; i  256; i++)
sum += floor (0.5 + (i - 128));
  return sum;
}


-- 
   Summary: [4.1 regression] SEGV in integer_valued_real_p at
gcc/builtins.c:6711
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: belyshev at depni dot sinp dot msu dot ru
GCC target triplet: x86_64-*-*, i?86-*-*


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



[Bug middle-end/24820] [4.1 regression] SEGV in integer_valued_real_p at gcc/builtins.c:6711

2005-11-12 Thread laurent at guerby dot net


--- Comment #1 from laurent at guerby dot net  2005-11-12 16:36 ---
confirmed on x86_64-linux gcc version 4.1.0 2005 (experimental)

z.c: In function 'bar':
z.c:3: internal compiler error: tree check: expected class 'expression', have
'constant' (real_cst) in integer_valued_real_p, at builtins.c:6710


-- 

laurent at guerby dot net changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2005-11-12 16:36:26
   date||


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



[Bug bootstrap/24821] New: [4.1 regression] [alpha-linux] ada bootstrap error in stage3

2005-11-12 Thread debian-gcc at lists dot debian dot org
trunk 2005, configured for alpha-linux-gnu

  Matthias

stage1/xgcc -Bstage1/ -B/usr/lib/gcc-snapshot/alpha-linux-gnu/bin/ -c -O2 
-gnatpg -gnata -g -O1 -fno-inline \
 -I- -I. -Iada -I../../src/gcc/ada ../../src/gcc/ada/a-except.adb -o
ada/a-except.o
built-in:0: warning: 'const' attribute directive ignored
built-in:0: warning: 'nothrow' attribute directive ignored
built-in:0: warning: 'nothrow' attribute directive ignored
built-in:0: warning: 'const' attribute directive ignored
built-in:0: warning: 'nothrow' attribute directive ignored
built-in:0: warning: 'const' attribute directive ignored
built-in:0: warning: 'nothrow' attribute directive ignored
built-in:0: warning: 'const' attribute directive ignored
built-in:0: warning: 'nothrow' attribute directive ignored
built-in:0: warning: 'const' attribute directive ignored
built-in:0: warning: 'nothrow' attribute directive ignored
built-in:0: warning: 'const' attribute directive ignored
built-in:0: warning: 'nothrow' attribute directive ignored
built-in:0: warning: 'const' attribute directive ignored
built-in:0: warning: 'nothrow' attribute directive ignored
built-in:0: warning: 'const' attribute directive ignored
built-in:0: warning: 'nothrow' attribute directive ignored
built-in:0: warning: 'const' attribute directive ignored
built-in:0: warning: 'nothrow' attribute directive ignored
built-in:0: warning: 'const' attribute directive ignored
built-in:0: warning: 'nothrow' attribute directive ignored
built-in:0: warning: 'const' attribute directive ignored
built-in:0: warning: 'nothrow' attribute directive ignored
built-in:0: warning: 'const' attribute directive ignored
built-in:0: warning: 'nothrow' attribute directive ignored
built-in:0: warning: 'const' attribute directive ignored
built-in:0: warning: 'nothrow' attribute directive ignored
built-in:0: warning: 'const' attribute directive ignored
built-in:0: warning: 'nothrow' attribute directive ignored
built-in:0: warning: 'const' attribute directive ignored
built-in:0: warning: 'nothrow' attribute directive ignored
built-in:0: warning: 'const' attribute directive ignored
built-in:0: warning: 'nothrow' attribute directive ignored
built-in:0: warning: 'const' attribute directive ignored
built-in:0: warning: 'nothrow' attribute directive ignored
built-in:0: warning: 'const' attribute directive ignored
built-in:0: warning: 'nothrow' attribute directive ignored
built-in:0: warning: 'const' attribute directive ignored
built-in:0: warning: 'nothrow' attribute directive ignored
built-in:0: warning: 'const' attribute directive ignored
built-in:0: warning: 'nothrow' attribute directive ignored
built-in:0: warning: 'const' attribute directive ignored
built-in:0: warning: 'nothrow' attribute directive ignored
built-in:0: warning: 'const' attribute directive ignored
built-in:0: warning: 'nothrow' attribute directive ignored
built-in:0: warning: 'const' attribute directive ignored
built-in:0: warning: 'nothrow' attribute directive ignored
built-in:0: warning: 'const' attribute directive ignored
built-in:0: warning: 'nothrow' attribute directive ignored
built-in:0: warning: 'const' attribute directive ignored
built-in:0: warning: 'nothrow' attribute directive ignored
built-in:0: warning: 'const' attribute directive ignored
built-in:0: warning: 'nothrow' attribute directive ignored built-in:0:
warning: 'const' attribute directive ignored
built-in:0: warning: 'nothrow' attribute directive ignored
built-in:0: warning: 'nothrow' attribute directive ignored
built-in:0: warning: 'nothrow' attribute directive ignored
+===GNAT BUG DETECTED==+
| 4.1.0 2005 (experimental) (alpha-unknown-linux-gnu) GCC error:   |
| tree check: expected class   |
| Error detected at a-except.adb:1387:1|
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.|
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact gcc or gnatmake command that you entered.  |
| Also include sources listed below in gnatchop format |
| (concatenated together with no headers between files).   |
+==+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.



raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:380
make[4]: *** [ada/a-except.o] Error 1
make[4]: Leaving directory
`/home/doko/gcc/snap/gcc-snapshot-2005/build/gcc'make[3]: ***
[stage2_build] Error 2
make[3]: Leaving directory
`/home/doko/gcc/snap/gcc-snapshot-2005/build/gcc'make[2]: *** [bootstrap]
Error 2


-- 
   Summary: [4.1 regression] [alpha-linux] ada 

[Bug ada/18434] [4.0/4.1 Regression] Ada: cannot build gnattools on Tru64 UNIX V5.1B

2005-11-12 Thread debian-gcc at lists dot debian dot org


--- Comment #17 from debian-gcc at lists dot debian dot org  2005-11-12 
16:41 ---
(In reply to comment #16)
 Arnaud has a patch for this issue on trunk and a better workaround patch for
 4.0.
 
 Could you post your stage3 failure?

actually, it's a stage2 failure, files as PR24821

  Matthias


-- 


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



[Bug ada/24822] New: make[2]: *** [ada/einfo.h] Error 1

2005-11-12 Thread danglin at gcc dot gnu dot org
(cd ada/bldtools/sinfo; gnatmake -q xsinfo ; ./xsinfo ../../sinfo.h )
mkdir -p ada/bldtools/einfo
cp -p ../../gcc/gcc/ada/einfo.ads ../../gcc/gcc/ada/einfo.adb
../../gcc/gcc/ada/
xeinfo.adb ada/bldtools/einfo
(cd ada/bldtools/einfo; gnatmake -q xeinfo ; ./xeinfo ../../einfo.h )

raised STORAGE_ERROR : stack overflow or erroneous memory access
make[2]: *** [ada/einfo.h] Error 1

# gdb-6.3 xeinfo
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB.  Type show warranty for details.
This GDB was configured as hppa2.0w-hp-hpux11.11...
(gdb) r ../../einfo.h
Starting program: /mnt/gnu/gcc-3.3/objdir/gcc/ada/bldtools/einfo/xeinfo
../../einfo.h

Program received signal SIGSEGV, Segmentation fault.
0x00060db8 in system__finalization_implementation__get_deep_controller ()
(gdb) disass 0x00060d98 0x00060dd8
Dump of assembler code from 0x60d98 to 0x60dd8:
0x00060d98 system__finalization_implementation__detach_from_final_list+528: 
copy r31,rp
0x00060d9c system__finalization_implementation__detach_from_final_list+532: 
b,l 0x22920 ada__exceptions__reraise_occurrence_always,rp
0x00060da0 system__finalization_implementation__detach_from_final_list+536: 
ldo -2f8(sp),r26
0x00060da4 system__finalization_implementation__detach_from_final_list+540: 
nop
0x00060da8 system__finalization_implementation__get_deep_controller+0:  
stw rp,-14(,sp)
0x00060dac system__finalization_implementation__get_deep_controller+4:  
stw,ma r4,40(,sp)
0x00060db0 system__finalization_implementation__get_deep_controller+8:  
copy r26,r4
0x00060db4 system__finalization_implementation__get_deep_controller+12: 
stw r3,-3c(,sp)
0x00060db8 system__finalization_implementation__get_deep_controller+16: 
ldw 0(,r26),r3
0x00060dbc system__finalization_implementation__get_deep_controller+20: 
b,l 0x2eef0 ada__tags__get_rc_offset,rp
0x00060dc0 system__finalization_implementation__get_deep_controller+24: 
copy r3,r26
---Type return to continue, or q return to quit---
0x00060dc4 system__finalization_implementation__get_deep_controller+28: 
cmpib,=,n -2,ret0,0x60dec
system__finalization_implementation__get_deep_controller+68
0x00060dc8 system__finalization_implementation__get_deep_controller+32: 
cmpib,= 0,ret0,0x60dd8
system__finalization_implementation__get_deep_controller+48
0x00060dcc system__finalization_implementation__get_deep_controller+36: 
ldi 0,r19
0x00060dd0 system__finalization_implementation__get_deep_controller+40: 
cmpib,= 0,ret0,0x60e28
system__finalization_implementation__get_deep_controller+128
0x00060dd4 system__finalization_implementation__get_deep_controller+44: 
add,l r4,ret0,r19
End of assembler dump.
(gdb) p/x $r26
$1 = 0x0
(gdb) bt
#0  0x00060db8 in system__finalization_implementation__get_deep_controller ()
#1  0x00060f7c in system__finalization_implementation__deep_tag_attach ()
#2  0x00015594 in _ada_xeinfo ()
#3  0xf0dc in main ()

The segmentation fault is caused by
system__finalization_implementation__deep_tag_attach ()
calling system__finalization_implementation__get_deep_controller ()
with a zero first argument.

I used gcc 4.0.2 as the bootstrap compiler.  I believe that the error
doesn't occur when gcc-3.4.4 is used.


-- 
   Summary: make[2]: *** [ada/einfo.h] Error 1
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
 GCC build triplet: hppa*-*-hpux*
  GCC host triplet: hppa*-*-hpux*
GCC target triplet: hppa*-*-hpux*


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



[Bug bootstrap/24821] [4.1 regression] [alpha-linux] ada bootstrap error in stage3

2005-11-12 Thread laurent at guerby dot net


--- Comment #1 from laurent at guerby dot net  2005-11-12 16:51 ---
Likely to be the same problem than mips/powerpc. Note there's a negatively
reviewed patch that solves this problem.

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


-- 

laurent at guerby dot net changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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



[Bug middle-end/24820] [4.1 regression] SEGV in integer_valued_real_p at gcc/builtins.c:6711

2005-11-12 Thread pinskia at gcc dot gnu dot org


--- Comment #2 from pinskia at gcc dot gnu dot org  2005-11-12 16:58 ---
integer_valued_real_p is missing a break or something.  Looking more into it.


-- 


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



[Bug middle-end/24820] [3.4/4.0/4.1 regression] SEGV in integer_valued_real_p at gcc/builtins.c:6711

2005-11-12 Thread pinskia at gcc dot gnu dot org


--- Comment #3 from pinskia at gcc dot gnu dot org  2005-11-12 17:03 ---
This is a latent bug from 2003 (3.4 time frame):
* builtins.c (integer_valued_real_p): New function to test if
a floating point expression has an integer valued result.
(fold_trunc_transparent_mathfn): Optimize foo(foo(x)) as
foo(x) where foo is an integer rounding function.  Similarly,
optimize foo(bar(x)) as bar(x), and foo((double)(int)x) as
(double)(int)x when both foo and bar are integer rounding
functions and we don't need to honor errno.
(fold_builtin_trunc, fold_builtin_floor, fold_builtin_ceil):
New functions to fold trunc, floor and ceil.
(fold_builtin): Use fold_builtin_trunc to fold BUILT_IN_TRUNC*,
fold_builtin_floor to fold BUILT_IN_FLOOR* and fold_builtin_ceil
to fold BUILT_IN_CEIL*.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||sayle at gcc dot gnu dot org
  Known to work||3.3.3
Summary|[4.1 regression] SEGV in|[3.4/4.0/4.1 regression]
   |integer_valued_real_p at|SEGV in
   |gcc/builtins.c:6711 |integer_valued_real_p at
   ||gcc/builtins.c:6711
   Target Milestone|4.1.0   |4.0.3


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



[Bug middle-end/24703] [GOMP] Unable to compile OpenMP program with omp parallel for schedule(dynamic) directive

2005-11-12 Thread dnovillo at gcc dot gnu dot org


--- Comment #3 from dnovillo at gcc dot gnu dot org  2005-11-12 17:47 
---

Testing new patch.


-- 


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



[Bug libstdc++/24800] tr1::mem_fn returns a function object that does not inherit from std::unary_function/binary_function

2005-11-12 Thread john at johnmaddock dot co dot uk


--- Comment #5 from john at johnmaddock dot co dot uk  2005-11-12 17:53 
---
Thanks for the clarification Doug: having re-read the text, the issues list,
and scratched my head for a while I agree with you.  I'll update the Boost test
case appropriately.

Feel free to close this one down as invalid (it appears I don't have permission
to do that).

Regards, John.


-- 


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



[Bug middle-end/24820] [3.4/4.0/4.1 regression] SEGV in integer_valued_real_p at gcc/builtins.c:6711

2005-11-12 Thread pinskia at gcc dot gnu dot org


--- Comment #4 from pinskia at gcc dot gnu dot org  2005-11-12 18:27 ---
I will take care of this one, it is a simple matter of a break missing.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pinskia at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED


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



[Bug rtl-optimization/24823] New: [4.1 Regression] ICE

2005-11-12 Thread rguenth at gcc dot gnu dot org
We ICE building lapack on x86_64 with

/usr/lib64/gcc/x86_64-suse-linux/4.1.0/f951 zlatmr.f -ffixed-form -quiet
-dumpbase zlatmr.f -mtune=k8 -auxbase zlatmr -O3 -version -funroll-all-loops -o
/tmp/cclbQYB1.s
zlatmr.min.f:69: internal compiler error: in insert_save, at caller-save.c:719


-- 
   Summary: [4.1 Regression] ICE
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
GCC target triplet: x86_64-*-linux-gnu


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



[Bug libstdc++/24803] tr1::reference_wrapper and pointers to member functions

2005-11-12 Thread john at johnmaddock dot co dot uk


--- Comment #4 from john at johnmaddock dot co dot uk  2005-11-12 18:32 
---
Doug's right: according to 3.4p4 passing an rvalue results in implementation
defined behaviour.  So you can support it or not as you wish.  I'll update the
Boost test case accordingly.

However... I predict that that I won't be the first to try and pass an rvalue
through a call-wrapper :-)

Regards, John.


-- 


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



[Bug rtl-optimization/24823] [4.1 Regression] ICE

2005-11-12 Thread rguenth at gcc dot gnu dot org


--- Comment #1 from rguenth at gcc dot gnu dot org  2005-11-12 18:32 ---
Created an attachment (id=10228)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10228action=view)
reduced testcase

testcase


-- 


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



[Bug rtl-optimization/24823] [4.1 Regression] ICE

2005-11-12 Thread pinskia at gcc dot gnu dot org


--- Comment #2 from pinskia at gcc dot gnu dot org  2005-11-12 18:40 ---
This is a recent regression.  This worked with PR 20051106 but not with
2005.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |critical
Summary|[4.1 Regression] ICE|[4.1 Regression] ICE
   Target Milestone|--- |4.1.0


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



[Bug libstdc++/24803] tr1::reference_wrapper and pointers to member functions

2005-11-12 Thread hhinnant at apple dot com


--- Comment #5 from hhinnant at apple dot com  2005-11-12 19:02 ---
   (1) Strong-arm a C++ front-end guru into implementing rvalue references,
   then use them in the TR1 function objects. Heck, we'll need 'em
   for C++0x anyway :)

At the risk of being reckless.  Yes...  well, more like YES!!!  ;-)

I know very little about gcc at this point.  But if the feature is implemented
under a pragma (say rvalue_refs), default off, and if library code can test the
pragma (at the preprocessor level), then we could really move forward (let the
puns lie where they may).  N1855 went through core review in Mont Tremblant. 
There were several good suggestions on rewording the proposed words, but
absolutely nothing against the functionality or even the syntax.  That doesn't
mean the syntax is set in concrete.  But it does mean the mud is firming up. 
(I am guessing) It will take effort now for N1855 to not be accepted as is, or
pretty darn close to it.  The lwg also voiced no complaints and indeed strong
support for N1856 - N1862.  Almost irritation that I was taking up committee
time with this stuff again (just do it!).

If the language and library work goes under a pragma, default off, we can do
the following:

1.  Code like (for reference_wrapper):

#ifdef _GCC_MOVE
operator()(T1 t1) const {return (*data_)(std::forwardT1(t1));}
#else
operator()(T1 t1) const {return (*data_)(t1);}
#endif

2.  When bug reports like this come in, say try turning on rvalue reference
(give instructions for doing that).

3.  If the syntax or functionality of the language changes, we are relatively
free to change the compiler/lib, documenting as appropriate, since this is not
default behavior, and should be documented as an extension - which could change
in the future.

4.  When it becomes standard, we set the pragma to default on.

Dealing with bugs like this via hacks is more work than doing it right with
rvalue reference.

So who are going to get?  I'd love to do it.  But I'm slightly worse than a
newbie in this area.  I could write language tests for it though.  I also
wouldn't mind following someone more experienced just for my own education.

How about Russell Yanofsky?

http://russ.hn.org/rref/

It would be best if one did not have to recompile libstdc++ when flipping this
pragma.  In order to achieve that you have to be committed to keeping as much
out of the binary lib as possible.  To date the direction of libstdc++ has been
just the opposite.


-- 


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



[Bug c++/24824] New: ICE: in build_abbrev_table, at dwarf2out.c:6427 with -feliminate-dwarf2-dups

2005-11-12 Thread wanderer at rsu dot ru
g++ ICE with error message:

test.cc:24: internal compiler error: in build_abbrev_table, at dwarf2out.c:6427
Please submit a full bug report,

g++ call: g++ -c -gdwarf-2 -feliminate-dwarf2-dups test.cc -o test.o

testcase:
---8X--
namespace N {

  struct I {};

  templatetypename _Tp
  struct _V_base {
I _impl;
  };

  templatetypename _Tp 
  struct V : _V_base_Tp {
using _V_base_Tp::_impl;
  };

} // namespace N

struct S {};

struct T {
  T();
  N::VS* _l;
};

T::T() {}
---X8--

ICE with:
gcc version 4.1.0 20051104 (experimental)
gcc version 4.1.0 20051110 (experimental)

OK with:
gcc version 3.4.4 [FreeBSD] 20050518 (system compiler)
gcc version 3.4.4 20050513 (prerelease)
gcc version 3.5.0 20040712 (experimental)
gcc version 4.0.2


-- 
   Summary: ICE: in build_abbrev_table, at dwarf2out.c:6427 with -
feliminate-dwarf2-dups
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wanderer at rsu dot ru
 GCC build triplet: i386-unknown-freebsd6.0
  GCC host triplet: i386-unknown-freebsd6.0
GCC target triplet: i386-unknown-freebsd6.0


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



[Bug c++/24824] ICE: in build_abbrev_table, at dwarf2out.c:6427 with -feliminate-dwarf2-dups

2005-11-12 Thread wanderer at rsu dot ru


--- Comment #1 from wanderer at rsu dot ru  2005-11-12 19:04 ---
Created an attachment (id=10229)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10229action=view)
testcase source


-- 


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



[Bug debug/24824] [4.1 Regression] ICE: in build_abbrev_table, at dwarf2out.c:6427 with -feliminate-dwarf2-dups

2005-11-12 Thread pinskia at gcc dot gnu dot org


--- Comment #2 from pinskia at gcc dot gnu dot org  2005-11-12 19:09 ---
Confirmed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  GCC build triplet|i386-unknown-freebsd6.0 |
   GCC host triplet|i386-unknown-freebsd6.0 |
 GCC target triplet|i386-unknown-freebsd6.0 |i?86-*-* with dwarf2
   Keywords||ice-on-valid-code
  Known to fail||4.1.0
  Known to work||3.4.0 3.3.3 4.0.0
   Last reconfirmed|-00-00 00:00:00 |2005-11-12 19:09:06
   date||
Summary|ICE: in build_abbrev_table, |[4.1 Regression] ICE: in
   |at dwarf2out.c:6427 with -  |build_abbrev_table, at
   |feliminate-dwarf2-dups  |dwarf2out.c:6427 with -
   ||feliminate-dwarf2-dups
   Target Milestone|--- |4.1.0


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



[Bug rtl-optimization/24823] [4.1 Regression] ICE

2005-11-12 Thread pinskia at gcc dot gnu dot org


--- Comment #3 from pinskia at gcc dot gnu dot org  2005-11-12 19:10 ---
Confirmed.
ssb 106665 works, 106727 fails


-- 


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



[Bug rtl-optimization/24823] [4.1 Regression] ICE

2005-11-12 Thread pinskia at gcc dot gnu dot org


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2005-11-12 19:12:07
   date||


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



[Bug libfortran/24787] [libfortran] SCAN is broken

2005-11-12 Thread kargl at gcc dot gnu dot org


--- Comment #3 from kargl at gcc dot gnu dot org  2005-11-12 19:16 ---
Subject: Bug 24787

Author: kargl
Date: Sat Nov 12 19:16:40 2005
New Revision: 106828

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106828
Log:
PR libfortran/24787
* intrinsics/string_intrinsics.c (string_scan): Off by one; Fix
  typos in nearby comment.

* gfortran.dg/scan_1.f90: New test.



Added:
trunk/gcc/testsuite/gfortran.dg/scan_1.f90
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libgfortran/ChangeLog
trunk/libgfortran/intrinsics/string_intrinsics.c


-- 


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



[Bug c/20318] RFE: add attribute to specify that a function never returns NULL

2005-11-12 Thread pinskia at gcc dot gnu dot org


--- Comment #8 from pinskia at gcc dot gnu dot org  2005-11-12 19:26 ---
I have a patch already.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|dnovillo at gcc dot gnu dot |pinskia at gcc dot gnu dot
   |org |org
 Status|NEW |ASSIGNED


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



[Bug libfortran/24787] [libfortran] SCAN is broken

2005-11-12 Thread kargl at gcc dot gnu dot org


--- Comment #4 from kargl at gcc dot gnu dot org  2005-11-12 19:48 ---
Subject: Bug 24787

Author: kargl
Date: Sat Nov 12 19:48:25 2005
New Revision: 106830

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106830
Log:
PR libgfortran/24787
* gfortran.dg/scan_1.f90: New test.

* intrinsics/string_intrinsics.c (string_scan): Off by one; Fix typos
  in nearby comment.


Added:
branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/scan_1.f90
Modified:
branches/gcc-4_0-branch/gcc/testsuite/ChangeLog
branches/gcc-4_0-branch/libgfortran/ChangeLog
branches/gcc-4_0-branch/libgfortran/intrinsics/string_intrinsics.c


-- 


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



[Bug libfortran/24787] [libfortran] SCAN is broken

2005-11-12 Thread kargl at gcc dot gnu dot org


--- Comment #5 from kargl at gcc dot gnu dot org  2005-11-12 19:50 ---
Fixed on mainline and 4.0.x


-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

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


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



[Bug c++/19476] Missed null checking elimination with new

2005-11-12 Thread pinskia at gcc dot gnu dot org


--- Comment #4 from pinskia at gcc dot gnu dot org  2005-11-12 20:05 ---
This is an easy extension on top of PR 20318.  Mine.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|dnovillo at gcc dot gnu dot |pinskia at gcc dot gnu dot
   |org |org


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



[Bug java/24242] Redundant null pointer checks generated on refrerences returned by new operator.

2005-11-12 Thread pinskia at gcc dot gnu dot org


--- Comment #2 from pinskia at gcc dot gnu dot org  2005-11-12 20:06 ---
Will look into marking _Jv_AllocObjectNoFinalizer with the non zero attribute
which is added with PR 20318.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pinskia at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED


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



[Bug java/21856] null pointer check elimination

2005-11-12 Thread pinskia at gcc dot gnu dot org


--- Comment #2 from pinskia at gcc dot gnu dot org  2005-11-12 20:08 ---
Mine.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|dnovillo at gcc dot gnu dot |pinskia at gcc dot gnu dot
   |org |org


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



[Bug java/24242] Redundant null pointer checks generated on refrerences returned by new operator.

2005-11-12 Thread pinskia at gcc dot gnu dot org


--- Comment #3 from pinskia at gcc dot gnu dot org  2005-11-12 20:09 ---
This is actually a dup of bug 21856.

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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||DUPLICATE


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



[Bug java/21856] null pointer check elimination

2005-11-12 Thread pinskia at gcc dot gnu dot org


--- Comment #3 from pinskia at gcc dot gnu dot org  2005-11-12 20:09 ---
*** Bug 24242 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||daney at gcc dot gnu dot org


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



[Bug c++/24761] [4.0/4.1 Regression] templates and inline-asm and +

2005-11-12 Thread jakub at gcc dot gnu dot org


--- Comment #6 from jakub at gcc dot gnu dot org  2005-11-12 20:42 ---
Subject: Bug 24761

Author: jakub
Date: Sat Nov 12 20:42:23 2005
New Revision: 106831

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106831
Log:
PR c++/24761
* pt.c (tsubst_copy_asm_operands): New function.
(tsubst_expr) case ASM_EXPR: Use it.

* g++.dg/template/asm1.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/template/asm1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog


-- 


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



[Bug c++/24761] [4.0/4.1 Regression] templates and inline-asm and +

2005-11-12 Thread jakub at gcc dot gnu dot org


--- Comment #7 from jakub at gcc dot gnu dot org  2005-11-12 20:43 ---
Subject: Bug 24761

Author: jakub
Date: Sat Nov 12 20:43:27 2005
New Revision: 106832

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106832
Log:
PR c++/24761
* pt.c (tsubst_copy_asm_operands): New function.
(tsubst_expr) case ASM_EXPR: Use it.

* g++.dg/template/asm1.C: New test.

Added:
branches/gcc-4_0-branch/gcc/testsuite/g++.dg/template/asm1.C
Modified:
branches/gcc-4_0-branch/gcc/cp/ChangeLog
branches/gcc-4_0-branch/gcc/cp/pt.c
branches/gcc-4_0-branch/gcc/testsuite/ChangeLog


-- 


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



[Bug c++/24780] [4.0/4.1 Regression] ICE set_mem_attributes_minus_bitpos

2005-11-12 Thread jakub at gcc dot gnu dot org


--- Comment #8 from jakub at gcc dot gnu dot org  2005-11-12 20:44 ---
Subject: Bug 24780

Author: jakub
Date: Sat Nov 12 20:44:55 2005
New Revision: 106833

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106833
Log:
PR c++/24780
* typeck.c (complete_type): Set TYPE_NEEDS_CONSTRUCTING
and TYPE_HAS_NONTRIVIAL_DESTRUCTOR flags for all variants
of array type.

* g++.dg/opt/pr24780.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/opt/pr24780.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog


-- 


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



[Bug c++/24780] [4.0/4.1 Regression] ICE set_mem_attributes_minus_bitpos

2005-11-12 Thread jakub at gcc dot gnu dot org


--- Comment #9 from jakub at gcc dot gnu dot org  2005-11-12 20:45 ---
Subject: Bug 24780

Author: jakub
Date: Sat Nov 12 20:45:47 2005
New Revision: 106834

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106834
Log:
PR c++/24780
* typeck.c (complete_type): Set TYPE_NEEDS_CONSTRUCTING
and TYPE_HAS_NONTRIVIAL_DESTRUCTOR flags for all variants
of array type.

* g++.dg/opt/pr24780.C: New test.

Added:
branches/gcc-4_0-branch/gcc/testsuite/g++.dg/opt/pr24780.C
Modified:
branches/gcc-4_0-branch/gcc/cp/ChangeLog
branches/gcc-4_0-branch/gcc/cp/typeck.c
branches/gcc-4_0-branch/gcc/testsuite/ChangeLog


-- 


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



[Bug java/24825] New: Standard runtime methods that are known to not return null should not trigger null checks.

2005-11-12 Thread daney at gcc dot gnu dot org
As pointed out in this thread:

http://gcc.gnu.org/ml/java/2005-11/msg00124.html

Once we have the capability to annotate methods as returning 'not null', we
have a win if standard runtime methods are so annotated as appropiate.


-- 
   Summary: Standard runtime methods that are known to not return
null should not trigger null checks.
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: daney at gcc dot gnu dot org
 BugsThisDependsOn: 20318


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



[Bug testsuite/16230] Spurious test failures with --disable-static

2005-11-12 Thread andreast at gcc dot gnu dot org


--- Comment #3 from andreast at gcc dot gnu dot org  2005-11-12 21:06 
---
The other languages like g++, gfortran, obj-c++ and objc should be fixed with
this patch which is applied on trunk.

http://gcc.gnu.org/ml/gcc-cvs/2005-11/msg00503.html

So, the question is now, can you reproduce this one for libgcj?


-- 


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



[Bug target/24826] New: Incorrect default options

2005-11-12 Thread mlist at ml-solutions dot co dot uk
At some point between 4.0 and 4.1 the mechanism for option handling was
changed over to the new style using the .opt file but the default setting of
quickcall seems to have been lost in the process.

adding the following 2 lines into h8300.c

#undef TARGET_DEFAULT_TARGET_FLAGS
#define TARGET_DEFAULT_TARGET_FLAGS (MASK_QUICKCALL)

immediately before the line

struct gcc_target targetm = TARGET_INITIALIZER;

appears to fix the problem allthough I am not sure that this is completely
the correct way to do this.


-- 
   Summary: Incorrect default options
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mlist at ml-solutions dot co dot uk
  GCC host triplet: i686-pc-cygwin
GCC target triplet: h8300-hitachi-elf


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



[Bug target/24826] [4.1 Regression] Incorrect default options

2005-11-12 Thread pinskia at gcc dot gnu dot org


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||kazu at gcc dot gnu dot org
   Priority|P3  |P5
Summary|Incorrect default options   |[4.1 Regression] Incorrect
   ||default options
   Target Milestone|--- |4.1.0


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



[Bug c++/24761] [4.0/4.1 Regression] templates and inline-asm and +

2005-11-12 Thread pinskia at gcc dot gnu dot org


--- Comment #8 from pinskia at gcc dot gnu dot org  2005-11-12 22:13 ---
Fixed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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



[Bug c++/24780] [4.0/4.1 Regression] ICE set_mem_attributes_minus_bitpos

2005-11-12 Thread pinskia at gcc dot gnu dot org


--- Comment #10 from pinskia at gcc dot gnu dot org  2005-11-12 22:14 
---
Fixed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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



[Bug java/24825] Standard runtime methods that are known to not return null should not trigger null checks.

2005-11-12 Thread pinskia at gcc dot gnu dot org


--- Comment #1 from pinskia at gcc dot gnu dot org  2005-11-12 22:14 ---
Confirmed, this one is harder than the new operator.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2005-11-12 22:14:44
   date||


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



[Bug libfortran/24584] Segfault when reading empty string in namelist file

2005-11-12 Thread jvdelisle at gcc dot gnu dot org


--- Comment #8 from jvdelisle at gcc dot gnu dot org  2005-11-12 22:22 
---
Subject: Bug 24584

Author: jvdelisle
Date: Sat Nov 12 22:22:53 2005
New Revision: 106838

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106838
Log:
2005-11-12  Jerry DeLisle [EMAIL PROTECTED]

PR libgfortran/24699, 24700, 24719, 24785
* io/transfer.c (read_sf): Remove incorrect statement that was
clearing bytes_left.
(formatted_transfer_scalar): Add handling of end-of-record
condition, setting values correctly to backup.  Handle x format
when doing non-advancing write.
(st_read): Initialize current_record.

PR libgfortran/24584
* io/list_read.c (free_saved): Set saved_used to zero.

Modified:
branches/gcc-4_0-branch/libgfortran/ChangeLog
branches/gcc-4_0-branch/libgfortran/io/list_read.c
branches/gcc-4_0-branch/libgfortran/io/transfer.c


-- 


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



[Bug libfortran/24699] READ with T format specifier fails on end-of-record condition

2005-11-12 Thread jvdelisle at gcc dot gnu dot org


--- Comment #3 from jvdelisle at gcc dot gnu dot org  2005-11-12 22:22 
---
Subject: Bug 24699

Author: jvdelisle
Date: Sat Nov 12 22:22:53 2005
New Revision: 106838

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106838
Log:
2005-11-12  Jerry DeLisle [EMAIL PROTECTED]

PR libgfortran/24699, 24700, 24719, 24785
* io/transfer.c (read_sf): Remove incorrect statement that was
clearing bytes_left.
(formatted_transfer_scalar): Add handling of end-of-record
condition, setting values correctly to backup.  Handle x format
when doing non-advancing write.
(st_read): Initialize current_record.

PR libgfortran/24584
* io/list_read.c (free_saved): Set saved_used to zero.

Modified:
branches/gcc-4_0-branch/libgfortran/ChangeLog
branches/gcc-4_0-branch/libgfortran/io/list_read.c
branches/gcc-4_0-branch/libgfortran/io/transfer.c


-- 


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



[Bug libfortran/24719] [4.1 Regression] Nonadvancing read does not read more than 1 line

2005-11-12 Thread jvdelisle at gcc dot gnu dot org


--- Comment #8 from jvdelisle at gcc dot gnu dot org  2005-11-12 22:31 
---
Subject: Bug 24719

Author: jvdelisle
Date: Sat Nov 12 22:31:18 2005
New Revision: 106839

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106839
Log:
2005-11-12  Jerry DeLisle [EMAIL PROTECTED]

PR libgfortran/24719
*gfortran.dg/read_noadvance.f90: New test.

PR libgfortran/24699
*gfortran.dg/fmt_t_2.f90: New test.

PR libgfortran/24785
*gfortran.dg/read_x_eor.f90: New test.

PR libgfortran/24584
*gfortran.dg/namelist_empty.f90: Rename test.

*gfortran.dg/f77/1832.f: Backport from 4.1.

Added:
branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/fmt_t_2.f90
branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/namelist_empty.f90
branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/read_noadvance.f90
branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/read_x_eor.f90
Modified:
branches/gcc-4_0-branch/gcc/testsuite/ChangeLog
branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/g77/1832.f


-- 


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



[Bug libfortran/24785] X edit descriptor lost with ADVANCE=NO

2005-11-12 Thread jvdelisle at gcc dot gnu dot org


--- Comment #4 from jvdelisle at gcc dot gnu dot org  2005-11-12 22:31 
---
Subject: Bug 24785

Author: jvdelisle
Date: Sat Nov 12 22:31:18 2005
New Revision: 106839

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106839
Log:
2005-11-12  Jerry DeLisle [EMAIL PROTECTED]

PR libgfortran/24719
*gfortran.dg/read_noadvance.f90: New test.

PR libgfortran/24699
*gfortran.dg/fmt_t_2.f90: New test.

PR libgfortran/24785
*gfortran.dg/read_x_eor.f90: New test.

PR libgfortran/24584
*gfortran.dg/namelist_empty.f90: Rename test.

*gfortran.dg/f77/1832.f: Backport from 4.1.

Added:
branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/fmt_t_2.f90
branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/namelist_empty.f90
branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/read_noadvance.f90
branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/read_x_eor.f90
Modified:
branches/gcc-4_0-branch/gcc/testsuite/ChangeLog
branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/g77/1832.f


-- 


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



[Bug libfortran/24699] READ with T format specifier fails on end-of-record condition

2005-11-12 Thread jvdelisle at gcc dot gnu dot org


--- Comment #4 from jvdelisle at gcc dot gnu dot org  2005-11-12 22:31 
---
Subject: Bug 24699

Author: jvdelisle
Date: Sat Nov 12 22:31:18 2005
New Revision: 106839

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106839
Log:
2005-11-12  Jerry DeLisle [EMAIL PROTECTED]

PR libgfortran/24719
*gfortran.dg/read_noadvance.f90: New test.

PR libgfortran/24699
*gfortran.dg/fmt_t_2.f90: New test.

PR libgfortran/24785
*gfortran.dg/read_x_eor.f90: New test.

PR libgfortran/24584
*gfortran.dg/namelist_empty.f90: Rename test.

*gfortran.dg/f77/1832.f: Backport from 4.1.

Added:
branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/fmt_t_2.f90
branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/namelist_empty.f90
branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/read_noadvance.f90
branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/read_x_eor.f90
Modified:
branches/gcc-4_0-branch/gcc/testsuite/ChangeLog
branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/g77/1832.f


-- 


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



[Bug libfortran/24584] Segfault when reading empty string in namelist file

2005-11-12 Thread jvdelisle at gcc dot gnu dot org


--- Comment #9 from jvdelisle at gcc dot gnu dot org  2005-11-12 22:31 
---
Subject: Bug 24584

Author: jvdelisle
Date: Sat Nov 12 22:31:18 2005
New Revision: 106839

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106839
Log:
2005-11-12  Jerry DeLisle [EMAIL PROTECTED]

PR libgfortran/24719
*gfortran.dg/read_noadvance.f90: New test.

PR libgfortran/24699
*gfortran.dg/fmt_t_2.f90: New test.

PR libgfortran/24785
*gfortran.dg/read_x_eor.f90: New test.

PR libgfortran/24584
*gfortran.dg/namelist_empty.f90: Rename test.

*gfortran.dg/f77/1832.f: Backport from 4.1.

Added:
branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/fmt_t_2.f90
branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/namelist_empty.f90
branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/read_noadvance.f90
branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/read_x_eor.f90
Modified:
branches/gcc-4_0-branch/gcc/testsuite/ChangeLog
branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/g77/1832.f


-- 


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



[Bug middle-end/24827] New: FAIL: gcc.dg/attr-weakref-1.c

2005-11-12 Thread danglin at gcc dot gnu dot org
Executing on host: /test/gnu/gcc-3.3/objdir/gcc/xgcc
-B/test/gnu/gcc-3.3/objdir/
gcc/ /test/gnu/gcc-3.3/gcc/gcc/testsuite/gcc.dg/attr-weakref-1.c   -O2
-fno-show
-column  /test/gnu/gcc-3.3/gcc/gcc/testsuite/gcc.dg/attr-weakref-1a.c  -lm   -o
./attr-weakref-1.exe(timeout = 300)
ld: Unsatisfied symbol wf1 in file /var/tmp//ccNG756H.o
ld: Unsatisfied symbol wf6 in file /var/tmp//ccNG756H.o
ld: Unsatisfied symbol wf9 in file /var/tmp//ccNG756H.o
ld: Unsatisfied symbol wv1 in file /var/tmp//ccNG756H.o
ld: Unsatisfied symbol wv6 in file /var/tmp//ccNG756H.o
ld: Unsatisfied symbol wv9 in file /var/tmp//ccNG756H.o
ld: Unsatisfied symbol wf10 in file /var/tmp//ccNG756H.o
ld: Unsatisfied symbol wf11 in file /var/tmp//ccNG756H.o
ld: Unsatisfied symbol wf12 in file /var/tmp//ccNG756H.o
ld: Unsatisfied symbol wf13 in file /var/tmp//ccNG756H.o
ld: Unsatisfied symbol wf14 in file /var/tmp//ccNG756H.o
ld: Unsatisfied symbol wv10 in file /var/tmp//ccNG756H.o
ld: Unsatisfied symbol wv11 in file /var/tmp//ccNG756H.o
ld: Unsatisfied symbol wv12 in file /var/tmp//ccNG756H.o
ld: Unsatisfied symbol wv13 in file /var/tmp//ccNG756H.o
ld: Unsatisfied symbol wv14 in file /var/tmp//ccNG756H.o
16 errors.
collect2: ld returned 1 exit status
compiler exited with status 1
output is:
ld: Unsatisfied symbol wf1 in file /var/tmp//ccNG756H.o
ld: Unsatisfied symbol wf6 in file /var/tmp//ccNG756H.o
ld: Unsatisfied symbol wf9 in file /var/tmp//ccNG756H.o
ld: Unsatisfied symbol wv1 in file /var/tmp//ccNG756H.o
ld: Unsatisfied symbol wv6 in file /var/tmp//ccNG756H.o
ld: Unsatisfied symbol wv9 in file /var/tmp//ccNG756H.o
ld: Unsatisfied symbol wf10 in file /var/tmp//ccNG756H.o
ld: Unsatisfied symbol wf11 in file /var/tmp//ccNG756H.o
ld: Unsatisfied symbol wf12 in file /var/tmp//ccNG756H.o
ld: Unsatisfied symbol wf13 in file /var/tmp//ccNG756H.o
ld: Unsatisfied symbol wf14 in file /var/tmp//ccNG756H.o
ld: Unsatisfied symbol wv10 in file /var/tmp//ccNG756H.o
ld: Unsatisfied symbol wv11 in file /var/tmp//ccNG756H.o
ld: Unsatisfied symbol wv12 in file /var/tmp//ccNG756H.o
ld: Unsatisfied symbol wv13 in file /var/tmp//ccNG756H.o
ld: Unsatisfied symbol wv14 in file /var/tmp//ccNG756H.o
16 errors.
collect2: ld returned 1 exit status

FAIL: gcc.dg/attr-weakref-1.c (test for excess errors)
Excess errors:
ld: Unsatisfied symbol wf1 in file /var/tmp//ccNG756H.o
ld: Unsatisfied symbol wf6 in file /var/tmp//ccNG756H.o
ld: Unsatisfied symbol wf9 in file /var/tmp//ccNG756H.o
ld: Unsatisfied symbol wv1 in file /var/tmp//ccNG756H.o
ld: Unsatisfied symbol wv6 in file /var/tmp//ccNG756H.o
ld: Unsatisfied symbol wv9 in file /var/tmp//ccNG756H.o
ld: Unsatisfied symbol wf10 in file /var/tmp//ccNG756H.o
ld: Unsatisfied symbol wf11 in file /var/tmp//ccNG756H.o
ld: Unsatisfied symbol wf12 in file /var/tmp//ccNG756H.o
ld: Unsatisfied symbol wf13 in file /var/tmp//ccNG756H.o
ld: Unsatisfied symbol wf14 in file /var/tmp//ccNG756H.o
ld: Unsatisfied symbol wv10 in file /var/tmp//ccNG756H.o
ld: Unsatisfied symbol wv11 in file /var/tmp//ccNG756H.o
ld: Unsatisfied symbol wv12 in file /var/tmp//ccNG756H.o
ld: Unsatisfied symbol wv13 in file /var/tmp//ccNG756H.o
ld: Unsatisfied symbol wv14 in file /var/tmp//ccNG756H.o

WARNING: gcc.dg/attr-weakref-1.c compilation failed to produce executable


-- 
   Summary: FAIL: gcc.dg/attr-weakref-1.c
   Product: gcc
   Version: 4.1.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: hppa64-hp-hpux11.11
  GCC host triplet: hppa64-hp-hpux11.11
GCC target triplet: hppa64-hp-hpux11.11


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



[Bug target/24626] [4.1 Regression] internal compiler error: verify_flow_info failed

2005-11-12 Thread rguenth at gcc dot gnu dot org


--- Comment #3 from rguenth at gcc dot gnu dot org  2005-11-12 23:03 ---
works with 3.3, so a regression.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail||4.1.0
  Known to work||3.3.3
Summary|internal compiler error:|[4.1 Regression] internal
   |verify_flow_info failed |compiler error:
   ||verify_flow_info failed


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



[Bug libfortran/24699] READ with T format specifier fails on end-of-record condition

2005-11-12 Thread jvdelisle at gcc dot gnu dot org


--- Comment #5 from jvdelisle at gcc dot gnu dot org  2005-11-12 23:13 
---
Fixed in 4.0.3 and 4.1


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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



[Bug libfortran/24700] Bad write after backing up from end of file

2005-11-12 Thread jvdelisle at gcc dot gnu dot org


--- Comment #3 from jvdelisle at gcc dot gnu dot org  2005-11-12 23:13 
---
Fixed in 4.0.3 and 4.1.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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



[Bug libfortran/24719] [4.1 Regression] Nonadvancing read does not read more than 1 line

2005-11-12 Thread jvdelisle at gcc dot gnu dot org


--- Comment #9 from jvdelisle at gcc dot gnu dot org  2005-11-12 23:20 
---
Fixed in 4.0.3 and 4.1


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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



[Bug libfortran/24785] X edit descriptor lost with ADVANCE=NO

2005-11-12 Thread jvdelisle at gcc dot gnu dot org


--- Comment #5 from jvdelisle at gcc dot gnu dot org  2005-11-12 23:21 
---
Fixed in 4.0.3 and 4.1 .


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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



[Bug libfortran/24584] Segfault when reading empty string in namelist file

2005-11-12 Thread jvdelisle at gcc dot gnu dot org


--- Comment #10 from jvdelisle at gcc dot gnu dot org  2005-11-12 23:22 
---
Fixed in 4.0.3


-- 


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



[Bug fortran/19292] [meta-bug] g77 features lacking in gfortran

2005-11-12 Thread fxcoudert at gcc dot gnu dot org


--- Comment #7 from fxcoudert at gcc dot gnu dot org  2005-11-12 23:29 
---
With my last patch () that I am currently commiting, the list of unimplemented
intrinsics is now:

Access,   fcn,   Check file accessibility.
ChMod,sub,   Change file modes.
FSeek,fcn,   Position file (low-level).
GMTime,   fcn,   Convert time to GMT time info.
IDate,sub,   Get local time info.
Int2, fcn,   Convert to `INTEGER(KIND=6)' value truncated to whole number.
Int8, fcn,   Convert to `INTEGER(KIND=2)' value truncated to whole number.
ITime,sub,   Get local time of day.
Long, fcn,   Conversion to `INTEGER(KIND=1)' (archaic).
LShift,   fcn,   Left-shift bits
LStat,sub and fcn,   Get file information.
LTime,sub,   Convert time to local time info.
MClock,   fcn,   Get number of clock ticks for process.
MClock8,  fcn,   Get number of clock ticks for process.
RShift,   fcn,   Right-shift bits.
Short,fcn,   Convert to `INTEGER(KIND=6)' value truncated to whole number.

I plan to work on ACCESS and CHMOD (I already have them half-implemented in one
of my trees) and FSEEK is though to get (it has a label as optional argument,
which I don't know how to handle). GMTIME, IDATE, ITIME, LSTAT and LTIME need
some library part and should be easy, if someone wants to have a go at them,
feel free!


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

   Last reconfirmed|2005-01-06 14:49:20 |2005-11-12 23:29:51
   date||


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



[Bug fortran/20244] internal compiler error: in fold_convert, at fold-const.c:2003

2005-11-12 Thread pinskia at gcc dot gnu dot org


--- Comment #9 from pinskia at gcc dot gnu dot org  2005-11-12 23:43 ---
(In reply to comment #8)
 I got the same ICE with one of the SPEC2006 candidate benchmarks on
 x86_64-linux-gnu.

Was this before or after my fix for PR 18157 went in?  Because this and that
bug had the same ICE but are really different bugs.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||aj at gcc dot gnu dot org


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



[Bug fortran/24828] New: Z and negative integers

2005-11-12 Thread tkoenig at gcc dot gnu dot org
$ cat z.f
  program z
  i = Z'80203040'
  if (i .ne. Z'80203040') call abort
  end
$ gfortran z.f
$ ./a.out
Aborted
$ g77 z.f
$ ./a.out
$ 

This is a signedness/cast issue.  .t02.original shows:

  int4 i;

  i = 080203040;
  if ((int8) i != 080203040)
{
  _gfortran_abort ();
}
  else
{
  (void) 0;
}

(And why is hexadecimal shown as 0 in the dump?)


-- 
   Summary: Z and negative integers
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot org
OtherBugsDependingO 19292
 nThis:


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



[Bug fortran/24828] Z and negative integers

2005-11-12 Thread pinskia at gcc dot gnu dot org


--- Comment #1 from pinskia at gcc dot gnu dot org  2005-11-12 23:53 ---
(In reply to comment #0)
 (And why is hexadecimal shown as 0 in the dump?)

Because that means TREE_OVERFLOW is set for some reason.

Confirmed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2005-11-12 23:53:06
   date||


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



[Bug libfortran/23419] unformatted complex I/O with kind=10

2005-11-12 Thread tkoenig at gcc dot gnu dot org


--- Comment #9 from tkoenig at gcc dot gnu dot org  2005-11-12 23:56 ---
Yes, this is fixed for mainline.  Great!


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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



[Bug java/24825] Standard runtime methods that are known to not return null should not trigger null checks.

2005-11-12 Thread pinskia at gcc dot gnu dot org


--- Comment #2 from pinskia at gcc dot gnu dot org  2005-11-13 00:16 ---
The way we can mark the function/function type is in build_method_invocation,
we have to change how BUILD_APPEND calls build_method_invocation and add a new
argument or something like that (we build the real call expression later on).


-- 


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



[Bug c++/19476] Missed null checking elimination with new

2005-11-12 Thread sabre at nondot dot org


--- Comment #5 from sabre at nondot dot org  2005-11-13 01:24 ---
Is this safe?  People can define their own operator new's, some of which may
return null...

-Chris


-- 


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



[Bug tree-optimization/21488] [4.0/4.1 regression] Not copy propagating single-argument PHIs causes out-of-ssa coalescing failure

2005-11-12 Thread steven at gcc dot gnu dot org


--- Comment #13 from steven at gcc dot gnu dot org  2005-11-13 01:38 ---
Doesn't happen anymore on current mainline.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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



[Bug middle-end/19207] Suggestion for speeding up data flow analysis

2005-11-12 Thread steven at gcc dot gnu dot org


--- Comment #1 from steven at gcc dot gnu dot org  2005-11-13 01:41 ---
IIUC, this is one of the things that's being worked on in the dataflow-branch.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dberlin at gcc dot gnu dot
   ||org


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



[Bug tree-optimization/19590] IVs with the same evolution not eliminated

2005-11-12 Thread steven at gcc dot gnu dot org


--- Comment #2 from steven at gcc dot gnu dot org  2005-11-13 01:43 ---
This hasn't been addressed yet in r106784.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

   Last reconfirmed|2005-09-21 01:43:19 |2005-11-13 01:43:25
   date||


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



[Bug c++/19476] Missed null checking elimination with new

2005-11-12 Thread pinskia at gcc dot gnu dot org


--- Comment #6 from pinskia at gcc dot gnu dot org  2005-11-13 02:10 ---
(In reply to comment #5)
 Is this safe?  People can define their own operator new's, some of which may
 return null...

Yes because the normal operator new guarante not to return NULL by the C++
standard.  And if it returns a NULL that is undefined behavior, it should be
throwing an exception when memory could not be allocated (there is a nonthrow
version which can and will return NULL).


-- 


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



[Bug c++/19476] Missed null checking elimination with new

2005-11-12 Thread sabre at nondot dot org


--- Comment #7 from sabre at nondot dot org  2005-11-13 02:13 ---
 Yes because the normal operator new guarante not to return NULL by the C++
 standard.

Sure.

 And if it returns a NULL that is undefined behavior, it should be
 throwing an exception when memory could not be allocated (there is a nonthrow
 version which can and will return NULL).

Sure, fine, but you need not be calling the default/normal operator new.  I can
define an overload for operator new in a different translation unit, or even by
dynamically loading a library with a different one.  This is similar to
replacing malloc.  AFAICT, the C++ std does not say that the replacement
operator new may not return null.

-Chris 


-- 


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



[Bug c++/19476] Missed null checking elimination with new

2005-11-12 Thread pinskia at gcc dot gnu dot org


--- Comment #8 from pinskia at gcc dot gnu dot org  2005-11-13 02:24 ---
(In reply to comment #7)
From 3.7.3/3:
Any allocation and/or deallocation functions defined in a C++ program shall
conform to the sematics specified in 3.7.3.1 and 3.7.3.2.
---


-- 


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



[Bug rtl-optimization/24810] [4.1 Regression] mov + mov + testl generated instead of testb

2005-11-12 Thread dann at godzilla dot ics dot uci dot edu


--- Comment #2 from dann at godzilla dot ics dot uci dot edu  2005-11-13 
02:47 ---
Simplified testcase: 
struct cpuinfo_x86 {
  unsigned char x86;
  unsigned char x86_vendor;
  unsigned char x86_model;
  unsigned char x86_mask;
  char wp_works_ok;
  char hlt_works_ok;
  char hard_math;
  char rfu;
  int cpuid_level;
  unsigned long x86_capability[7];
} __attribute__((__aligned__((1  (7);

struct task_struct;
extern void foo (struct task_struct *tsk);
extern void bar (struct task_struct *tsk);

extern struct cpuinfo_x86 boot_cpu_data;

static inline __attribute__((always_inline)) int
constant_test_bit(int nr, const volatile unsigned long *addr)
{
 return ((1UL  (nr  31))  (addr[nr  5])) != 0;
}

void
restore_fpu(struct task_struct *tsk)
{
  if (constant_test_bit(24, boot_cpu_data.x86_capability))
foo (tsk);
  else
bar (tsk);
}

The generated code for this simplified tescase shows one additional issue:

restore_fpu:
movl%eax, %edx
movlboot_cpu_data+12, %eax  ; edx could be used here
testl   $16777216, %eax ; and here
je  .L2
movl%edx, %eax  ; then all the mov %eax, %edx and mov %edx, %eax
jmp foo ; instructions could be eliminated.
.p2align 4,,7
.L2:
movl%edx, %eax
jmp bar


-- 

dann at godzilla dot ics dot uci dot edu changed:

   What|Removed |Added

Summary|mov + mov + testl generated |[4.1 Regression] mov + mov +
   |instead of testb|testl generated instead of
   ||testb


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



[Bug c++/19476] Missed null checking elimination with new

2005-11-12 Thread sabre at nondot dot org


--- Comment #9 from sabre at nondot dot org  2005-11-13 02:51 ---
yup, you're right.  Great!

-Chris


-- 


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



[Bug libobjc/24829] New: libobjc testsuite failures

2005-11-12 Thread danglin at gcc dot gnu dot org
Running /test/gnu/gcc-3.3/gcc/gcc/testsuite/objc.dg/dg.exp ...
FAIL: objc.dg/bitfield-1.m (test for excess errors)
FAIL: objc.dg/bitfield-1.m execution test
FAIL: objc.dg/bitfield-3.m (test for excess errors)
FAIL: objc.dg/bitfield-3.m execution test
FAIL: objc.dg/bitfield-5.m (test for excess errors)
FAIL: objc.dg/bitfield-5.m execution test
FAIL: objc.dg/call-super-1.m (test for excess errors)
FAIL: objc.dg/call-super-1.m execution test
FAIL: objc.dg/call-super-3.m (test for excess errors)
FAIL: objc.dg/call-super-3.m execution test
FAIL: objc.dg/category-1.m (test for excess errors)
FAIL: objc.dg/category-1.m execution test
FAIL: objc.dg/defs.m (test for excess errors)
FAIL: objc.dg/defs.m execution test
FAIL: objc.dg/desig-init-1.m (test for excess errors)
FAIL: objc.dg/desig-init-1.m execution test
FAIL: objc.dg/encode-1.m (test for excess errors)
FAIL: objc.dg/encode-1.m execution test
FAIL: objc.dg/encode-2.m (test for excess errors)
FAIL: objc.dg/encode-2.m execution test
FAIL: objc.dg/encode-3.m (test for excess errors)
FAIL: objc.dg/encode-3.m execution test
FAIL: objc.dg/encode-4.m (test for excess errors)
FAIL: objc.dg/encode-4.m execution test
FAIL: objc.dg/func-ptr-1.m (test for excess errors)
FAIL: objc.dg/func-ptr-1.m execution test
FAIL: objc.dg/func-ptr-2.m (test for excess errors)
FAIL: objc.dg/func-ptr-2.m execution test
FAIL: objc.dg/method-10.m (test for excess errors)
FAIL: objc.dg/method-10.m execution test
FAIL: objc.dg/method-13.m (test for excess errors)
FAIL: objc.dg/method-13.m execution test
FAIL: objc.dg/method-3.m (test for excess errors)
FAIL: objc.dg/method-3.m execution test
FAIL: objc.dg/proto-lossage-3.m (test for excess errors)
FAIL: objc.dg/proto-lossage-3.m execution test
FAIL: objc.dg/proto-qual-1.m (test for excess errors)
FAIL: objc.dg/proto-qual-1.m execution test
FAIL: objc.dg/sizeof-1.m (test for excess errors)
FAIL: objc.dg/sizeof-1.m execution test
FAIL: objc.dg/stret-1.m (test for excess errors)
FAIL: objc.dg/stret-1.m execution test
FAIL: objc.dg/super-class-3.m (test for excess errors)
FAIL: objc.dg/super-class-3.m execution test
FAIL: objc.dg/type-size-2.m (test for excess errors)
FAIL: objc.dg/type-size-2.m execution test
FAIL: objc.dg/type-stream-1.m (test for excess errors)
FAIL: objc.dg/type-stream-1.m execution test
FAIL: objc.dg/va-meth-1.m (test for excess errors)
FAIL: objc.dg/va-meth-1.m execution test
Running /test/gnu/gcc-3.3/gcc/gcc/testsuite/objc.dg/special/special.exp ...
FAIL: objc.dg/special/unclaimed-category-1.m unclaimed-category-1a.o (test for
e
xcess errors)
FAIL: objc.dg/special/unclaimed-category-1.m unclaimed-category-1a.o execution
t
est

Executing on host: /test/gnu/gcc-3.3/objdir/gcc/xgcc
-B/test/gnu/gcc-3.3/objdir/
gcc/ /test/gnu/gcc-3.3/gcc/gcc/testsuite/objc.dg/bitfield-1.m   
-I/test/gnu/gcc
-3.3/gcc/gcc/testsuite/../../libobjc
-L/test/gnu/gcc-3.3/objdir/hppa64-hp-hpux11
.11/./libobjc/.libs  -lobjc -lm   -o ./bitfield-1.exe(timeout = 300)
ld: (Warning) Unsatisfied symbol pthread_create in file
/test/gnu/gcc-3.3/objd
ir/hppa64-hp-hpux11.11/./libobjc/.libs/libobjc.sl
ld: (Warning) Unsatisfied symbol pthread_attr_init in file
/test/gnu/gcc-3.3/o
bjdir/hppa64-hp-hpux11.11/./libobjc/.libs/libobjc.sl
2 warnings.

Symbols from
/test/gnu/gcc-3.3/objdir/hppa64-hp-hpux11.11/./libobjc/.libs/libobj
c.sl.1:

[Index]Value  SizeType  Bind  O ShndxName
...
[742]| 0|   0|FUNC |GLOB |0|  
UNDEF|pthread_attr_in
...
[593]| 0|   0|FUNC |GLOB |0|   UNDEF|pthread_create

We have in sys/pthread.h:

#ifdef __lint
extern int pthread_attr_init(pthread_attr_t *);
#else /* ! __lint */
extern int __pthread_attr_init_system(pthread_attr_t *attr);

#ifdef __cplusplus
inline int pthread_attr_init(
#else /* !__cplusplus */
static int pthread_attr_init(
#endif /* !__cplusplus */
 pthread_attr_t *attr)
   { return(__pthread_attr_init_system(attr)); }

#endif /* ! __lint */

and

#ifdef __lint
extern int pthread_create(pthread_t *tid,
  const pthread_attr_t *attr,
  void *(*start_routine)(void *),
  void *arg);
#else /* ! __lint */
extern int __pthread_create_system(pthread_t *tid,
   const pthread_attr_t *attr,
   void *(*start_routine)(void *),
   void *arg);

#ifdef __cplusplus
inline int pthread_create(
#else /* !__cplusplus */
static int pthread_create(
#endif /* !__cplusplus */
  pthread_t *tid,
  const pthread_attr_t *attr,
  void *(*start_routine)(void *),
  void *arg)
{ 

[Bug other/24829] libobjc testsuite failures

2005-11-12 Thread pinskia at gcc dot gnu dot org


--- Comment #1 from pinskia at gcc dot gnu dot org  2005-11-13 03:25 ---
Is this a regression?  If this is a regression, was this caused by:
2005-11-09  Alexandre Oliva  [EMAIL PROTECTED]

PR other/4372
* gthr-dce.h, gthr-posix.h, gthr-posix95.h, gthr-solaris.h,
gthr-tpf.h: Define __gthrw.  For all identifiers that might
be weak, introduce weakrefs or non-weak aliases with __gthrw,
and prefix all uses with __ghtrw.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
  Component|libobjc |other


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



[Bug other/24829] libobjc testsuite failures

2005-11-12 Thread dave at hiauly1 dot hia dot nrc dot ca


--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca  2005-11-13 
03:32 ---
Subject: Re:  libobjc testsuite failures

 Is this a regression?  If this is a regression, was this caused by:

Yes, things were ok on 2005-11-07.

 2005-11-09  Alexandre Oliva  [EMAIL PROTECTED]
 
 PR other/4372
 * gthr-dce.h, gthr-posix.h, gthr-posix95.h, gthr-solaris.h,
 gthr-tpf.h: Define __gthrw.  For all identifiers that might
 be weak, introduce weakrefs or non-weak aliases with __gthrw,
 and prefix all uses with __ghtrw.

This is probably the cause.  gcc.dg/attr-weakref-1.c also fails on this
target.  I'm using GNU as and HP ld.

Dave


-- 


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



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

2005-11-12 Thread danglin at gcc dot gnu dot org


--- Comment #1 from danglin at gcc dot gnu dot org  2005-11-13 03:46 ---
Also fails on hppa2.0w-hp-hpux11.11.  So, probably fails on all hppa*-*-hpux*
targets.


-- 


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



[Bug c/24830] New: Duplicate constructors with -fmudflap

2005-11-12 Thread dgraham at nortel dot com
The only way I know how to reproduce this is with -fmudflap, but
that's only because *C* code doesn't normally generate constructors.

With -fmudflap, each of the mudflap constructors are run twice.  An objdump
run on the object files shows two ctor sections, one named .ctor and
one named .ctor.65436.  default_named_section_asm_out_constructor() is
being called twice from cgraph_build_static_cdtor(), once directly, and
once indirectly.  The first (indirect) call is here:

#0  default_named_section_asm_out_constructor (symbol=0xb7a5a660,
priority=65535)
at ../../gcc-4.0.2.bounds/gcc/varasm.c:1133
#1  0x0805b237 in c_expand_body (fndecl=0xb7a45dec)
at ../../gcc-4.0.2.bounds/gcc/c-decl.c:6634
#2  0x0832f012 in cgraph_expand_function (node=0xb7a45f30)
at ../../gcc-4.0.2.bounds/gcc/cgraphunit.c:835
#3  0x0832f0f5 in cgraph_assemble_pending_functions ()
at ../../gcc-4.0.2.bounds/gcc/cgraphunit.c:307
#4  0x0832f78a in cgraph_finalize_function (decl=0xb7a45dec, nested=0 '\0')
at ../../gcc-4.0.2.bounds/gcc/cgraphunit.c:399
#5  0x083309ae in cgraph_build_static_cdtor (which=73 'I', body=0xb7a5a660,
priority=99)
at ../../gcc-4.0.2.bounds/gcc/cgraphunit.c:1901
#6  0x080941a2 in mudflap_finish_file () at
../../gcc-4.0.2.bounds/gcc/tree-mudflap.c:1374
#7  0x082eea55 in toplev_main (argc=3081086560, argv=0xbfb75a84)
at ../../gcc-4.0.2.bounds/gcc/toplev.c:1050

The second (direct) call is here:

#0  default_named_section_asm_out_constructor (symbol=0xb7a5a660, priority=99)
at ../../gcc-4.0.2.bounds/gcc/varasm.c:1133
#1  0x08330997 in cgraph_build_static_cdtor (which=73 'I', body=0xb7a5a660,
priority=99)
at ../../gcc-4.0.2.bounds/gcc/cgraphunit.c:1911
#2  0x080941a2 in mudflap_finish_file () at
../../gcc-4.0.2.bounds/gcc/tree-mudflap.c:1374
#3  0x082eea55 in toplev_main (argc=3081086560, argv=0xbfb75a84)
at ../../gcc-4.0.2.bounds/gcc/toplev.c:1050

The first call looks wrong, as it is not being passed the correct
priority.

--Doug.


-- 
   Summary: Duplicate constructors with -fmudflap
   Product: gcc
   Version: 4.0.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dgraham at nortel dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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



[Bug other/24829] libobjc testsuite failures

2005-11-12 Thread pinskia at gcc dot gnu dot org


--- Comment #3 from pinskia at gcc dot gnu dot org  2005-11-13 04:07 ---
Alexandre could you look into this one and PR 24827?


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu dot
   ||org


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



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

2005-11-12 Thread pinskia at gcc dot gnu dot org


--- Comment #2 from pinskia at gcc dot gnu dot org  2005-11-13 04:10 ---
This blocks PR 24829.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

OtherBugsDependingO||24829
  nThis||


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



[Bug target/24831] New: [4.1 regression] gthr-dce.h:77: error: expected expression before '{' token

2005-11-12 Thread danglin at gcc dot gnu dot org
./xgcc -B./ -B/opt/gnu/gcc/gcc-4.1.0/hppa1.1-hp-hpux10.20/bin/ -isystem
/opt/gnu
/gcc/gcc-4.1.0/hppa1.1-hp-hpux10.20/include -isystem
/opt/gnu/gcc/gcc-4.1.0/hppa
1.1-hp-hpux10.20/sys-include -L/xxx/gnu/gcc-3.3/objdir/gcc/../ld -O2   -DIN_GCC
   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style
-definition  -isystem ./include  -fPIC -g  -DIN_LIBGCC2
-D__GCC_FLOAT_NOT_NEEDED
  -I. -I -I../../gcc/gcc -I../../gcc/gcc/ -I../../gcc/gcc/../include
-I../../gcc
/gcc/../libcpp/include -I/opt/gnu/gcc/gcc-4.1.0/include  -threads -fexceptions
-c ../../gcc/gcc/unwind-dw2.c -o libgcc/threads/unwind-dw2.o
In file included from ../../gcc/gcc/gthr.h:103,
 from ../../gcc/gcc/unwind-dw2.c:42:
../../gcc/gcc/gthr-dce.h:77: error: expected expression before '{' token
../../gcc/gcc/gthr-dce.h:77: warning: type defaults to 'int' in declaration of
'
__gthrw_pthread_once_init'
../../gcc/gcc/gthr-dce.h:79: error: 'pthread_key_delete' undeclared here (not
in
 a function)
../../gcc/gcc/gthr-dce.h:79: warning: type defaults to 'int' in declaration of
'
__gthrw_pthread_key_delete'
../../gcc/gcc/unwind-dw2.c: In function 'uw_init_context_1':
../../gcc/gcc/unwind-dw2.c:1253: error: invalid initializer
make[3]: *** [libgcc/threads/unwind-dw2.o] Error 1


-- 
   Summary: [4.1 regression] gthr-dce.h:77: error: expected
expression before '{' token
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
 GCC build triplet: hppa1.1-hp-hpux10.20
  GCC host triplet: hppa1.1-hp-hpux10.20
GCC target triplet: hppa1.1-hp-hpux10.20


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



  1   2   >