[Bug target/19340] Compilation SEGFAULTs with -O1 -fschedule-insns2 -fsched2-use-traces on an x86 architecture.

2005-11-07 Thread uros at gcc dot gnu dot org


--- Comment #6 from uros at gcc dot gnu dot org  2005-11-08 07:59 ---
Subject: Bug 19340

Author: uros
Date: Tue Nov  8 07:58:51 2005
New Revision: 106633

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106633
Log:
PR target/19340
* reg-stack.c (reg_to_stack): Update register liveness also
for flag_sched2_use_traces.

PR target/24315
* config/i386/i386.md (*pushdi2_rex64 splitter)
(*movdi_1_rex64 splitter, *ashldi3_1 splitter)
(*ashrdi3_1 splitter, *lshrdi3_1 splitter): Delay splitting after
flow2 pass only when (optimize > 0 && flag_peephole2).

testsuite/

PR target/19340
* gcc.dg/pr19340.c: New test.

PR target/24315
* gcc.target/i386/pr24315.c: New test.


Added:
branches/gcc-4_0-branch/gcc/testsuite/gcc.dg/pr19340.c
branches/gcc-4_0-branch/gcc/testsuite/gcc.target/i386/pr24315.c
Modified:
branches/gcc-4_0-branch/gcc/ChangeLog
branches/gcc-4_0-branch/gcc/config/i386/i386.md
branches/gcc-4_0-branch/gcc/reg-stack.c
branches/gcc-4_0-branch/gcc/testsuite/ChangeLog


-- 


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



[Bug target/24315] [3.4/4.0 Regression] amd64 fails -fpeephole2

2005-11-07 Thread uros at gcc dot gnu dot org


--- Comment #14 from uros at gcc dot gnu dot org  2005-11-08 07:59 ---
Subject: Bug 24315

Author: uros
Date: Tue Nov  8 07:58:51 2005
New Revision: 106633

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106633
Log:
PR target/19340
* reg-stack.c (reg_to_stack): Update register liveness also
for flag_sched2_use_traces.

PR target/24315
* config/i386/i386.md (*pushdi2_rex64 splitter)
(*movdi_1_rex64 splitter, *ashldi3_1 splitter)
(*ashrdi3_1 splitter, *lshrdi3_1 splitter): Delay splitting after
flow2 pass only when (optimize > 0 && flag_peephole2).

testsuite/

PR target/19340
* gcc.dg/pr19340.c: New test.

PR target/24315
* gcc.target/i386/pr24315.c: New test.


Added:
branches/gcc-4_0-branch/gcc/testsuite/gcc.dg/pr19340.c
branches/gcc-4_0-branch/gcc/testsuite/gcc.target/i386/pr24315.c
Modified:
branches/gcc-4_0-branch/gcc/ChangeLog
branches/gcc-4_0-branch/gcc/config/i386/i386.md
branches/gcc-4_0-branch/gcc/reg-stack.c
branches/gcc-4_0-branch/gcc/testsuite/ChangeLog


-- 


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



[Bug tree-optimization/24653] [4.1 regression] EON regressed seriously on x86-64

2005-11-07 Thread bonzini at gcc dot gnu dot org


--- Comment #5 from bonzini at gcc dot gnu dot org  2005-11-08 07:53 ---
The approved patch is the one at
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00212.html


-- 

bonzini at gcc dot gnu dot org changed:

   What|Removed |Added

URL|http://gcc.gnu.org/ml/gcc-  |http://gcc.gnu.org/ml/gcc-
   |patches/2005-   |patches/2005-
   |11/msg00195.html|11/msg00212.html


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



[Bug middle-end/24514] [4.0/4.1 Regression] ICE on bootstrap

2005-11-07 Thread r dot emrich at de dot tecosim dot com


--- Comment #18 from r dot emrich at de dot tecosim dot com  2005-11-08 
07:47 ---
Bootstrap of gcc-4.1-20051105 succeeded for c,c++,objc,obj-c++.
Testsuite still in progress.


-- 


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



[Bug rtl-optimization/24408] [4.1 Regression] Invariant code no longer removed from loop when doing FDO.

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


--- Comment #5 from steven at gcc dot gnu dot org  2005-11-08 07:44 ---
Created an attachment (id=10170)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10170&action=view)
merge patch from the killloop-branch

With this patch applied and -fmove-loop-invariants enabled by default at -O2, I
am getting regressions in libjava on ia64. But it does bootstrap there and also
passes bootstrap&testing on i686, x86_64, ppc, and ppc64 without problems.


-- 


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



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

2005-11-07 Thread sven dot buijssen at math dot uni-dortmund dot de


--- Comment #5 from sven dot buijssen at math dot uni-dortmund dot de  
2005-11-08 07:04 ---
> Sven,
> Thanks for reporting this and narrowing it down.

You're welcome, Jerry. I reckoned this to be the most promising way to get rid
of this regression as soon as possible. :-)

> This is a warning and you can get rid of warnings with the -w flag when
> invoking gfc.

Sure, I know, perfectly works. It's just that I consider this a spurious
warning as no file (apart from /dev/zero) is of infinite length and by this,
the end-of-file condition will end this "infinite loop" branching execution to
label 99.

By the way, I'm deeply impressed by the speed you handle this regression!
Thanks a lot.

Regards,
Sven


-- 


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



[Bug rtl-optimization/19097] [3.4/4.0/4.1 regression] Quadratic behavior with many sets for the same register in gcse CPROP

2005-11-07 Thread phython at gcc dot gnu dot org


--- Comment #28 from phython at gcc dot gnu dot org  2005-11-08 06:48 
---
Steven: How long does 4.0 take to compile this function on your box?


-- 


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



[Bug c++/22172] [3.4 Regression] Internal compiler error, seg fault.

2005-11-07 Thread phython at gcc dot gnu dot org


-- 

phython at gcc dot gnu dot org changed:

   What|Removed |Added

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


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



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

2005-11-07 Thread jvdelisle at verizon dot net


--- Comment #4 from jvdelisle at verizon dot net  2005-11-08 06:37 ---
Subject: Re:  [4.1 Regression] Nonadvancing read does not
 read more than 1 line

> For sake of compliance with the bug report policy:
> * gfortran from cvs via 
> TZ=GMT cvs -q update -D'2005.10.24.03.00.00'
>   works,
> * gfortran from cvs via 
> TZ=GMT cvs -q update -D'2005.10.24.04.00.00'
>   does not.
> 

Sven,
Thanks for reporting this and narrowing it down.

> By the way, there is another small issue with the above testcase. I'm not sure
> if I should file a separate bug report for it:
> Changing line 6 of regression.f90 to 
> 
> 10read(unit = 1, fmt = '(a)', advance = 'no', end = 99, eor = 10) saux
> 
> gives the incorrect warning:
> 
>  In file regression.f90:6
> 
> 10read(unit = 1, fmt = '(a)', advance = 'no', end = 99, eor = 10) saux
>  1
> Warning: Branch at (1) causes an infinite loop
> 
> while ifort and g95 do not complain.
> 
> 

This is a warning and you can get rid of warnings with the -w flag when
invoking 
gfc.  It warns of a potential problem.  Let me know if -w does not get rid of
it 
for you.

Regards,

Jerry


-- 


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



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

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


--- Comment #3 from jvdelisle at gcc dot gnu dot org  2005-11-08 06:22 
---
I believe I have a fix for this one that works with the previous patch to
pr24489.  I am testing along with work on pr24699 to make sure we have no
conflicts or regressions.  pr24719, pr24699, pr24700, and pr24489 all relate to
io/transfer.c.


-- 


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



[Bug target/19340] Compilation SEGFAULTs with -O1 -fschedule-insns2 -fsched2-use-traces on an x86 architecture.

2005-11-07 Thread uros at gcc dot gnu dot org


--- Comment #5 from uros at gcc dot gnu dot org  2005-11-08 06:21 ---
Subject: Bug 19340

Author: uros
Date: Tue Nov  8 06:21:51 2005
New Revision: 106632

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106632
Log:
PR target/19340
* reg-stack.c (reg_to_stack): Update register liveness also
for flag_sched2_use_traces.

testsuite/

PR target/19340
* gcc.dg/pr19340.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/pr19340.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/reg-stack.c
trunk/gcc/testsuite/ChangeLog


-- 


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



[Bug rtl-optimization/23392] [4.1 Regression] foward-1.m fails with -funroll-loops -O3 -fgnu-runtime

2005-11-07 Thread amodra at bigpond dot net dot au


--- Comment #13 from amodra at bigpond dot net dot au  2005-11-08 05:24 
---
Looking at fixing REG_FRAME_RELATED_EXPR in regrename.


-- 


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



[Bug c++/13967] A warning could be emitted if a template parameter of a member template is begin shadowed by another member of the class

2005-11-07 Thread bangerth at dealii dot org


--- Comment #25 from bangerth at dealii dot org  2005-11-08 05:23 ---
*** Bug 24657 has been marked as a duplicate of this bug. ***


-- 

bangerth at dealii dot org changed:

   What|Removed |Added

 CC||igodard at pacbell dot net


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



[Bug c++/24657] [3.4/4.0/4.1 Regression] bizarre diagnostic when a member variable and a template parameter have the same name

2005-11-07 Thread bangerth at dealii dot org


--- Comment #6 from bangerth at dealii dot org  2005-11-08 05:23 ---
This is PR 13967. See in particular comment #11 in the audit trail there.

Not that that PR would be particularly enlightening, but the situation is
at least discussed at length there.

W.

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


-- 

bangerth at dealii dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


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



[Bug rtl-optimization/23392] [4.1 Regression] foward-1.m fails with -funroll-loops -O3 -fgnu-runtime

2005-11-07 Thread amodra at bigpond dot net dot au


-- 

amodra at bigpond dot net dot au changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |amodra at bigpond dot net
   |dot org |dot au
 Status|NEW |ASSIGNED
   Last reconfirmed|2005-08-15 17:49:53 |2005-11-08 05:23:05
   date||


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



[Bug c++/24657] [3.4/4.0/4.1 Regression] bizarre diagnostic on valid (?) constructor

2005-11-07 Thread bangerth at dealii dot org


--- Comment #5 from bangerth at dealii dot org  2005-11-08 05:14 ---
This can of course be made even simpler:

struct A {
template A(int (*)[i]) : j(i) {}
int * i;
int   j;
};

int i[3];
A a(&i);


g/x> /home/bangerth/bin/gcc-3.4.5-pre/bin/c++ -c x.cc
x.cc: In constructor `A::A(int (*)[i]) [with int i = 3]':
x.cc:8:   instantiated from here
x.cc:2: error: invalid conversion from `int*' to `int'

I'm pretty sure I've seen this somewhere before -- the question was indeed
which name should be looked up, the template name or the name of a member
variable.

In any case, the error message is not particularly helpful, and I know of
at least one other compiler that accepts this.

W.


-- 

bangerth at dealii dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2005-11-08 05:14:36
   date||


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



[Bug c/24727] type "const void *" produces a warning when promoting to "void *"

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


--- Comment #3 from pinskia at gcc dot gnu dot org  2005-11-08 04:34 ---
No, in C, these are two different function types.


-- 

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=24727



[Bug middle-end/24729] function calls created by builtins do not make use of inline definitions

2005-11-07 Thread ghazi at gcc dot gnu dot org


--- Comment #2 from ghazi at gcc dot gnu dot org  2005-11-08 04:28 ---
I'm not convinced it's the same issue.  With regard to 17402, comment #6 by
Joseph there refers specifically to static inlines in that builtins shouldn't
generate calls to "file-scope statics".  However in my case glibc is
instantiating *extern inlines* and it seems legitimate that gcc could (should)
generate calls which take advantage of them.  (Plus they're much much faster!)


-- 


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



[Bug c/24727] type "const void *" produces a warning when promoting to "void *"

2005-11-07 Thread joshudson at gmail dot com


--- Comment #2 from joshudson at gmail dot com  2005-11-08 04:25 ---
Aren't function arguments contravariant rather than covariant?


-- 

joshudson at gmail dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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



[Bug middle-end/24729] function calls created by builtins do not make use of inline definitions

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


--- Comment #1 from pinskia at gcc dot gnu dot org  2005-11-08 03:52 ---
I want to say this is dup of bug 17402 which was marked as will not fix.


-- 


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



[Bug middle-end/24729] New: function calls created by builtins do not make use of inline definitions

2005-11-07 Thread ghazi at gcc dot gnu dot org
When doing transformations on builtins, if the builtin results in a function
call that has an inline expansion, GCC emits a library call not the inline
function body.  E.g. glibc defines an inline for fputc_unlocked.  Given this
code:

#define _GNU_SOURCE
#include 
#define MAX 1

int main ()
{
  int i;
  for (i=0; ihttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=24729



[Bug target/23704] gcc.dg/rs6000-fpint.c fails

2005-11-07 Thread amodra at bigpond dot net dot au


--- Comment #6 from amodra at bigpond dot net dot au  2005-11-08 03:17 
---
I meant, fixed on 3.4 and 4.0 by patch for pr20277


-- 


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



[Bug target/23704] gcc.dg/rs6000-fpint.c fails

2005-11-07 Thread amodra at bigpond dot net dot au


--- Comment #5 from amodra at bigpond dot net dot au  2005-11-08 03:15 
---
Fixed mainline.  Bug fixed on 3.4 and 4.0 branch by patch for pr20227


-- 

amodra at bigpond dot net dot au changed:

   What|Removed |Added

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


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



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

2005-11-07 Thread bugzilla-gcc at thewrittenword dot com


--- Comment #2 from bugzilla-gcc at thewrittenword dot com  2005-11-08 
03:15 ---
(In reply to comment #1)
> See the thread on the gcc list discussing this bug.
> http://gcc.gnu.org/ml/gcc/2005-11/msg00331.html
> 
> I suspect this is a bug in patches applied to the gcc-3.4.x sources as I do 
> not
> see this problem in the FSF sources.

Note the HP gcc-3.4.4 binary had the same problem. I just built gcc-3.4.4 with
just one patch to fix the sco_math issue in PR24688:
  http://gcc.gnu.org/ml/gcc-patches/2004-11/msg00985.html

The new binary exhibits the same problem.


-- 


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



[Bug target/23704] gcc.dg/rs6000-fpint.c fails

2005-11-07 Thread amodra at gcc dot gnu dot org


--- Comment #4 from amodra at gcc dot gnu dot org  2005-11-08 03:09 ---
Subject: Bug 23704

Author: amodra
Date: Tue Nov  8 03:08:43 2005
New Revision: 106631

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106631
Log:
PR target/23704
* config/rs6000/rs6000.c (rs6000_handle_option ): Don't
override prior explicit -mno-powerpc-gfxopt.


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


-- 


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



[Bug c/8268] no compile time array index checking

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


--- Comment #16 from pinskia at gcc dot gnu dot org  2005-11-08 02:41 
---
*** Bug 24728 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||Larry dot Finger at lwfinger
   ||dot net


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



[Bug c/24728] Constant array index past end does not generate compile-time error

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


--- Comment #1 from pinskia at gcc dot gnu dot org  2005-11-08 02:41 ---
First this is only undefined code which means that we have to accept the code.
Second this is a dup of bug 8268.

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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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



[Bug c/24728] New: Constant array index past end does not generate compile-time error

2005-11-07 Thread Larry dot Finger at lwfinger dot net
A constant reference to an array element past the end of the array does not
generate an error. Included are the output from gcc -v and a test program that
mimics the real-world case where the coding error corrupted the stack: 

Using built-in specs.
Target: i586-suse-linux
Configured with: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib
--enable-languages=c,c++,objc,f95,java,ada --disable-checking
--with-gxx-include-dir=/usr/include/c++/4.0.2 --enable-java-awt=gtk
--disable-libjava-multilib --with-slibdir=/lib --with-system-zlib
--enable-shared --enable-__cxa_atexit --without-system-libunwind
--host=i586-suse-linux
Thread model: posix
gcc version 4.0.2 20050901 (prerelease) (SUSE Linux)


Test Program:
=
int sub1(int);
int main(int argc, char **argv) {
int i,j = 0;
i = sub1(j);
return i;
}
int sub1(int j ) {
int b[13];
b[13] = j;
return 0;
}


-- 
   Summary: Constant array index past end does not generate compile-
time error
   Product: gcc
   Version: 4.0.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Larry dot Finger at lwfinger dot net
  GCC host triplet: i586-suse-linux
GCC target triplet: i586-suse-linux


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



[Bug tree-optimization/23115] [4.1 Regression] -ftree-vectorize generates wrong code

2005-11-07 Thread dpatel at apple dot com


--- Comment #8 from dpatel at apple dot com  2005-11-08 02:22 ---
tree if-conversion  was expecting perfect dimond, but it is not always true
after tree-cleanup-branch work. I've started overnight patch test run.
Hopefully, I'll send patch tomorrow for review.


-- 


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



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

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


--- Comment #2 from jvdelisle at gcc dot gnu dot org  2005-11-08 02:18 
---
I have confirmed that when I revert the patch to pr24489 that this bug goes
away.  Isn't life wonderful!


-- 

jvdelisle 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-08 02:18:31
   date||


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



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

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


--- Comment #1 from jvdelisle at gcc dot gnu dot org  2005-11-08 01:46 
---
This is precisly when I committed the patch to pr24489.  I am also seeing some
possible connections with pr24699.  I will investigate further.


-- 


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



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

2005-11-07 Thread wilson at gcc dot gnu dot org


--- Comment #1 from wilson at gcc dot gnu dot org  2005-11-08 01:41 ---
See the thread on the gcc list discussing this bug.
http://gcc.gnu.org/ml/gcc/2005-11/msg00331.html

I suspect this is a bug in patches applied to the gcc-3.4.x sources as I do not
see this problem in the FSF sources.

I do not have an ia64-hpux machine, so I can not easily investigate this.


-- 


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



[Bug tree-optimization/18595] [4.0/4.1 Regression] IV-OPTS is O(N^3)

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


--- Comment #60 from pinskia at gcc dot gnu dot org  2005-11-08 01:40 
---
Fixed on the mainline.


-- 

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=18595



[Bug c++/24687] [4.1 Regression] ICE after error

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


--- Comment #7 from pinskia at gcc dot gnu dot org  2005-11-08 01:34 ---
Actually I don't think my patch is the right one.
Here is the patch:
svn diff
Index: tree.c
===
--- tree.c  (revision 106572)
+++ tree.c  (working copy)
@@ -2168,7 +2168,12 @@ decl_linkage (tree decl)
   /* Linkage of a CONST_DECL depends on the linkage of the enumeration 
  type.  */
   if (TREE_CODE (decl) == CONST_DECL)
-return decl_linkage (TYPE_NAME (TREE_TYPE (decl)));
+{
+  /* If we are inside a template, the type will be null. */
+  if (!TREE_TYPE (decl))
+   return lk_external;
+  return decl_linkage (TYPE_NAME (TREE_TYPE (decl)));
+}

   /* Some things that are not TREE_PUBLIC have external linkage, too.
  For example, on targets that don't have weak symbols, we make all


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

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


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



[Bug other/24724] _Unwind_Backtrace() calls malloc

2005-11-07 Thread arun dot sharma at google dot com


--- Comment #12 from arun dot sharma at google dot com  2005-11-08 01:30 
---
(In reply to comment #10)
> (In reply to comment #9)
> > Yes and the ones against gcc are only about eplogue or prologue so it should
> > not matter for what you are doing.
> 
> PR 18748 and PR 18749 both are about prologue and eplogue code which should 
> not
> matter with the backtrace at all.
> 

ok, will try to root cause our problems with libunwind (they show up as bad
pointer dereferences in libunwind) and get back to you.

Thanks.


-- 


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



[Bug other/24724] _Unwind_Backtrace() calls malloc

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


--- Comment #11 from pinskia at gcc dot gnu dot org  2005-11-08 01:23 
---
(In reply to comment #7)
> The particular malloc in question is coming from start_fde_sort() in
> unwind-dw2-fde.c. Perhaps the sorting can be done earlier i.e. before
> _Unwind_Backtrace() is called?

If you do that, the start up time is high and every time you load a shared
library it stalls and you keep around stuff which you don't need at all.


-- 


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



[Bug other/24724] _Unwind_Backtrace() calls malloc

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


--- Comment #10 from pinskia at gcc dot gnu dot org  2005-11-08 01:12 
---
(In reply to comment #9)
> Yes and the ones against gcc are only about eplogue or prologue so it should
> not matter for what you are doing.

PR 18748 and PR 18749 both are about prologue and eplogue code which should not
matter with the backtrace at all.


-- 


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



[Bug other/24724] _Unwind_Backtrace() calls malloc

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


--- Comment #9 from pinskia at gcc dot gnu dot org  2005-11-08 01:10 ---
(In reply to comment #8)
> libunwind doesn't pass unit tests on amd64. davidm thinks that the problems 
> are
> outside of libunwind. I think he has a couple of bugs open against gcc/glibc.

Yes and the ones against gcc are only about eplogue or prologue so it should
not matter for what you are doing.


-- 


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



[Bug other/24724] _Unwind_Backtrace() calls malloc

2005-11-07 Thread arun dot sharma at google dot com


--- Comment #8 from arun dot sharma at google dot com  2005-11-08 01:09 
---
(In reply to comment #6)
> Hmm, You could try libunwind instead, it should work on x86_64:
> http://www.hpl.hp.com/research/linux/libunwind/
> 
> They show you how to use libunwind to generate a normal backtrace:
> http://www.hpl.hp.com/research/linux/libunwind/man/libunwind(3).php
> 
> Though I doubt that none of these will remove the use of malloc though.
> 

libunwind doesn't pass unit tests on amd64. davidm thinks that the problems are
outside of libunwind. I think he has a couple of bugs open against gcc/glibc.


-- 


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



[Bug other/24724] _Unwind_Backtrace() calls malloc

2005-11-07 Thread arun dot sharma at google dot com


--- Comment #7 from arun dot sharma at google dot com  2005-11-08 01:07 
---
(In reply to comment #4)
> I really doubt we can remove it because this is also used in the undwinding 
> for
> exceptions.
> 

It must be possible to do stack unwinding without any mallocs. If the exception
throwing code path requires mallocs, that's fine by us.

The particular malloc in question is coming from start_fde_sort() in
unwind-dw2-fde.c. Perhaps the sorting can be done earlier i.e. before
_Unwind_Backtrace() is called?


-- 


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



[Bug other/24724] _Unwind_Backtrace() calls malloc

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


--- Comment #6 from pinskia at gcc dot gnu dot org  2005-11-08 01:02 ---
Hmm, You could try libunwind instead, it should work on x86_64:
http://www.hpl.hp.com/research/linux/libunwind/

They show you how to use libunwind to generate a normal backtrace:
http://www.hpl.hp.com/research/linux/libunwind/man/libunwind(3).php

Though I doubt that none of these will remove the use of malloc though.


-- 


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



[Bug other/24724] _Unwind_Backtrace() calls malloc

2005-11-07 Thread arun dot sharma at google dot com


--- Comment #5 from arun dot sharma at google dot com  2005-11-08 00:55 
---
(In reply to comment #3)
> You know that glibc has an backtrace function which might be more friendly for
> your purpose?
> 

glibc backtrace dlopens libgcc and uses _Unwind_Backtrace() on amd64. glibc
backtrace has it's own problems (i.e. mallocs) which is why we're not using it.

See: 

http://sources.redhat.com/bugzilla/show_bug.cgi?id=1579


-- 


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



[Bug other/24724] _Unwind_Backtrace() calls malloc

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


--- Comment #4 from pinskia at gcc dot gnu dot org  2005-11-08 00:53 ---
I really doubt we can remove it because this is also used in the undwinding for
exceptions.


-- 


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



[Bug other/24724] _Unwind_Backtrace() calls malloc

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


--- Comment #3 from pinskia at gcc dot gnu dot org  2005-11-08 00:51 ---
You know that glibc has an backtrace function which might be more friendly for
your purpose?


-- 


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



[Bug other/24724] _Unwind_Backtrace() calls malloc

2005-11-07 Thread arun dot sharma at google dot com


--- Comment #2 from arun dot sharma at google dot com  2005-11-08 00:48 
---

It deadlocks because malloc is holding a lock and then calls the unwinder.
No, we're not throwing exceptions. One reason why malloc might want to use the
unwinder is to do heap profiling.

http://goog-perftools.sourceforge.net/doc/heap_profiler.html


-- 


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



[Bug tree-optimization/20656] No strength reduction for a simple testcase

2005-11-07 Thread hp at gcc dot gnu dot org


--- Comment #2 from hp at gcc dot gnu dot org  2005-11-08 00:30 ---
Seen at test-case reduction also for code of the form:
int i; for (i = 1; i <= shift_size; i++) { }
not producing the same ICE as for:
int i; i = 1 <= shift_size ? shift_size : 1;
(I'll put a pointer here to the complete test-case in due time.)


-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||hp at gcc dot gnu dot org


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



[Bug other/24724] _Unwind_Backtrace() calls malloc

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


--- Comment #1 from pinskia at gcc dot gnu dot org  2005-11-08 00:23 ---
What is your malloc doing special and why would it dead lock?  (if you are
throwing from inside malloc I think that is an invalid thing to do).


-- 


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



[Bug rtl-optimization/19097] [3.4/4.0/4.1 regression] Quadratic behavior with many sets for the same register in gcse CPROP

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


--- Comment #27 from steven at gcc dot gnu dot org  2005-11-08 00:18 ---
On AMD64, revision 106596M (the M is for a local loop-invariant.c
patch, nothing special), compiler built with --enable-checking=release:

at -O1:
 tree operand scan :   1.50 (10%) usr   0.09 (17%) sys   1.62 (10%) wall
 dominance frontiers   :   9.09 (60%) usr   0.00 ( 0%) sys   9.20 (58%) wall
 TOTAL :  15.05 0.5315.80

at -O2:
 tree VRP  :  12.20 (23%) usr   0.03 ( 3%) sys  12.44 (23%) wall
 dominance frontiers   :   9.17 (18%) usr   0.01 ( 1%) sys   9.30 (17%) wall
 CPROP 1   :   8.17 (16%) usr   0.16 (16%) sys   8.44 (16%) wall
 CPROP 2   :   5.54 (11%) usr   0.11 (11%) sys   5.72 (11%) wall
 bypass jumps  :   5.57 (11%) usr   0.11 (11%) sys   5.75 (11%) wall
 TOTAL :  52.31 1.0053.98

For GCC 3.3.5 at -O1 the total time is 26s, and at -O2 it is 31s.



For AMD64 -m32 -march=i686:

at -O1:
 tree operand scan :   1.48 (10%) usr   0.09 (18%) sys   1.59 (10%) wall
 dominance frontiers   :   9.03 (61%) usr   0.00 ( 0%) sys   9.14 (59%) wall
 TOTAL :  14.70 0.4915.39

at -O2:
 tree VRP  :  11.84 (24%) usr   0.04 ( 4%) sys  12.02 (24%) wall
 dominance frontiers   :   9.11 (19%) usr   0.02 ( 2%) sys   9.25 (18%) wall
 CPROP 1   :   7.54 (15%) usr   0.10 (11%) sys   7.74 (15%) wall
 CPROP 2   :   4.99 (10%) usr   0.10 (11%) sys   5.15 (10%) wall
 bypass jumps  :   4.96 (10%) usr   0.10 (11%) sys   5.12 (10%) wall
 TOTAL :  48.97 0.9350.54

For GCC 3.3.5 at -O1 the total time is 25s, and at -O2 it is 28s.

Compared to my measurements from comment #17, this is good progress.  James, do
you think we can close this bug now?


-- 


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



[Bug ada/24726] Gigi abort, Code=508

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


--- Comment #1 from pinskia at gcc dot gnu dot org  2005-11-08 00:09 ---
*** Bug 24725 has been marked as a duplicate of this bug. ***


-- 


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



[Bug ada/24725] Gigi abort, Code=508

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


--- Comment #1 from pinskia at gcc dot gnu dot org  2005-11-08 00:09 ---


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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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



[Bug c/24727] type "const void *" produces a warning when promoting to "void *"

2005-11-07 Thread schwab at suse dot de


--- Comment #1 from schwab at suse dot de  2005-11-08 00:07 ---
The warning is correct.  The type of x_write is incompatible with x_io, because
"const void *" is incompatible with "void *".  Argument promotion does not come
into play here.


-- 

schwab at suse dot de changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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



[Bug libfortran/24342] [4.1 regression] testsuite failure:gfortran.fortran-torture/execute/in-pack.f90 exe

2005-11-07 Thread tobi at gcc dot gnu dot org


--- Comment #3 from tobi at gcc dot gnu dot org  2005-11-07 23:56 ---
I'm adding FX to the CC list, because this looks like it's related to his patch
for FPU exceptions.


-- 

tobi at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu dot
   ||org


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



[Bug fortran/24643] Unclassifiable statement on implicitly typed character substring

2005-11-07 Thread Tobias dot Schlueter at physik dot uni-muenchen dot de


--- Comment #9 from Tobias dot Schlueter at physik dot uni-muenchen dot de  
2005-11-07 23:43 ---
Subject: Re:  Unclassifiable statement on implicitly typed
 character substring

steven at gcc dot gnu dot org wrote:
> --- Comment #8 from steven at gcc dot gnu dot org  2005-11-07 23:29 
> ---
> We get to "check_substring:" in match_varspec:
> 
> PROGRAM P
> IMPLICIT CHARACTER*8 (Y)
> YLOCAL='A'
> YBTABLE=YLOCAL(1:2)
> END
> 
> check_substring:
>   if (primary->ts.type == BT_CHARACTER)
> {
>   switch (match_substring (primary->ts.cl, equiv_flag, &substring))
> {
> case MATCH_YES:
>   if (tail == NULL)
> primary->ref = substring;
> 
> But at this point, while we have matched YLOCAL in the second assignment, we
> still haven't picked up a type for it.  So primary->ts.type == BT_UNKNOWN and
> we never even try to match the substring.
> 
> I'm not sure if YLOCAL should have just picked up a type earlier.  Thoughts,
> Tobi?

It should have picked up a type in the first assignment.  Why it doesn't, I
don't know.  Apparently, the failure is conditional on the facts that A) there
already exists a symbol and B) this symbol doesn't have a type at that point.

I'll look into this in more depth tomorrow.  I remember that last time I
looked into these issues (back before Jakub fixed PR18833), I noticed that the
matching of primaries had been completely reworked in g95, and I can't think
of any other bug relating to that than this one, so this bug might well turn
out to be a snake pit.


-- 


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



[Bug c/24727] New: type "const void *" produces a warning when promoting to "void *"

2005-11-07 Thread joshudson at gmail dot com
Tried this on two machines:

SunOS hornet 5.10 Generic sun4u sparc SUNW,Ultra-4
with GCC 4.0.1
Linux numenor 2.6.13 #9 Mon Sep 19 19:03:35 PDT 2005 i686 unknown unknown
GNU/Linux
with GCC 3.3.6

The following code produces spurios warning:
/* Cut here */
int x_read(int h, void *buf, unsigned len);
int x_write(int h, const void *buf, unsigned len);

typedef int (*x_io)(int h, void *buf, unsigned len);
int blockio(int h, long long offset, void *buf, x_io action);

int bug(int h, unsigned where, void *buf)
{
return blockio(h, (long long)where << 10, buf, x_write);
}
/* Cut here */
sample.c: In function `bug':
sample.c:9: warning: passing arg 4 of `blockio' from incompatible pointer type


-- 
   Summary: type "const void *" produces a warning when promoting to
"void *"
   Product: gcc
   Version: 4.0.1
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joshudson at gmail dot com
  GCC host triplet: Multiple


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



[Bug fortran/24643] Unclassifiable statement on implicitly typed character substring

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


--- Comment #8 from steven at gcc dot gnu dot org  2005-11-07 23:29 ---
We get to "check_substring:" in match_varspec:

PROGRAM P
IMPLICIT CHARACTER*8 (Y)
YLOCAL='A'
YBTABLE=YLOCAL(1:2)
END

check_substring:
  if (primary->ts.type == BT_CHARACTER)
{
  switch (match_substring (primary->ts.cl, equiv_flag, &substring))
{
case MATCH_YES:
  if (tail == NULL)
primary->ref = substring;

But at this point, while we have matched YLOCAL in the second assignment, we
still haven't picked up a type for it.  So primary->ts.type == BT_UNKNOWN and
we never even try to match the substring.

I'm not sure if YLOCAL should have just picked up a type earlier.  Thoughts,
Tobi?


-- 


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



[Bug ada/24726] New: Gigi abort, Code=508

2005-11-07 Thread ture dot andersen at zenon dot se
Ture-Andersens-dator:~/Documents/Privat/programutveckling/ada/sudoku ture$
gnatmake sudoku
gcc -c elements-sets.adb
+===GNAT BUG DETECTED==+
| 3.3 20040913 (GNAT for Mac OS X build 1650) (powerpc-unknown-darwin) |
| Gigi abort, Code=508 |
| Error detected at elements-sets.adb:95:21|
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.|
| 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

elements-sets.adb
elements-sets.ads
elements.ads

compilation abandoned
gnatmake: "elements-sets.adb" compilation error


--  *  Body name elements.sets.adb
--  *  Project name sudoku
--  *
--  *  Version 1.0
--  *  Last update 2005-11-06
--  *
--  *  Created by Ture Andersen on 2005-11-06.
--  *  Copyright (c) 2005 __MyCompanyName__.
--  *  GNAT modified GNU General Public License
--  *

with ada.text_io; use ada.text_io;
with ada.unchecked_conversion;
package body elements.sets is

function member (e : element; s : set) return boolean is
begin
return (set_of (e) and s) > null_set;
end;

function member (e : element; s : set) return Natural is
c : constant array (boolean) of natural :=
(false => 0, true => 1);
begin
return c (member (e, s));
end;

function cardinality (s : set) return natural is
C : natural := 0;
begin
for e in element loop
c := c + member (e, s);
end loop;
return c;
end cardinality;

function empty_set (s : set) return boolean is
begin
return s = null_set;
end empty_set;

function set_of (m : element) return set is
function uc is new ada.unchecked_conversion
(Source => element,
Target => set);
begin
return uc (m);
end set_of;

function union (l, r : element) return set is
begin
return set_of (l) or set_of (r);
end union;

function union (L : element; R : set) return set is
begin
return set_of (L) or R;
end union;

function union (L : set; R : element) return set is
begin
return L or set_of (R);
end;

function union (L, R : set) return set is
begin
return L or R;
end;

function disjoint (l, r : set) return boolean is
begin
return (l and r) = null_set;
end disjoint;

function proper_subset (subset, the_set : set) return boolean is
begin
return 
((subset and the_set) = subset) and then
(subset < the_set);
end proper_subset;

function improper_subset (subset, the_set : set) return boolean is
begin
return (subset and the_set) = subset;
end improper_subset;

function intersection (l, r : set) return set is
begin
return l and r;
end;

function complement (s : set) return set is
begin
return (not s) and universal_set;
end complement;

function difference (l, r : set) return set is
begin
return l - (l and r);
end difference;

function image (s : set) return string is
i : string (int (one) .. int (nine)) := (others => ' ');
begin
for m in element loop
if (set_of (m) and s) > 0 then
i (int (m)) := image (m);
end if;
end loop;
return i;
end image;

end elements.sets;

--  *  Spec. name elements.sets.ads
--  *  Project name sudoku
--  *
--  *  Version 1.0
--  *  Last update 2005-11-06
--  *
--  *  Created by Ture Andersen on 2005-11-06.
--  *  Copyright (c) 2005 __MyCompanyName__.
--  *  All rights reserved.
--  *or (keep only one line or write your own)
--  *  GNAT modified GNU General Public License
--  *


package elements.sets is
type set is private;
null_set : constant set;
universal_set : constant set;
function set_of (m : element) return set;
function image (s : set) return string;
function union (l, r : element) return set;
function "+" (l, r : element) return set renames union;
function union (L : element; R : set) return set;
function "+" (L : element; R : set) return set renames union;
function union (L : set; R : element) r

[Bug ada/24725] New: Gigi abort, Code=508

2005-11-07 Thread ture dot andersen at zenon dot se



-- 
   Summary: Gigi abort, Code=508
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ture dot andersen at zenon dot se


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



[Bug c/24724] New: _Unwind_Backtrace() calls malloc

2005-11-07 Thread arun dot sharma at google dot com
As this stacktrace shows:

#3  0x004044e2 in malloc (size=36024) at tcmalloc.cc:1314
#4  0x0047a938 in search_object ()
#5  0x0047b189 in _Unwind_Find_FDE ()
#6  0x00478049 in uw_frame_state_for ()
#7  0x00478eca in uw_init_context_1 ()
#8  0x004790b0 in _Unwind_Backtrace ()

there are code paths from _Unwind_Backtrace to malloc. This makes the unwinder
deadlock prone when called from applications that have their own customized
malloc.


-- 
   Summary: _Unwind_Backtrace() calls malloc
   Product: gcc
   Version: 4.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: arun dot sharma at google dot com
 GCC build triplet: x86_64-linux-gnu
  GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu


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



[Bug libfortran/24342] [4.1 regression] testsuite failure:gfortran.fortran-torture/execute/in-pack.f90 exe

2005-11-07 Thread hp at gcc dot gnu dot org


--- Comment #2 from hp at gcc dot gnu dot org  2005-11-07 23:24 ---
In reply to comment #1, yes.  The message in the log for -O3 and -Os is now:

Executing on host: /home/hp/combined/crislinux-sim/gcc/testsuite/../gfortran
-B/home/hp/combined/crislinux-sim/gcc/testsuite/../ \
/home/hp/combined/combined/gcc/testsuite/gfortran.fortran-torture/execute/in-pack.f90
 -w  -O3 -fomit-frame-pointer -L/home/h\
p/combined/crislinux-sim/ld -static 
-L/home/hp/combined/crislinux-sim/cris-axis-linux-gnu/./libgfortran/.libs
-L/home/hp/combine\
d/crislinux-sim/cris-axis-linux-gnu/./libiberty  -lm   -o
/home/hp/combined/crislinux-sim/gcc/testsuite/in-pack.x(timeout = 3\
00)
/home/hp/combined/crislinux-sim/cris-axis-linux-gnu/./libgfortran/.libs/libgfortran.a(fpu.o):
In function `*_gfortrani_set_fpu':.\
/fpu-target.h:42: warning: warning: fedisableexcept is not implemented and will
always fail^M
output is:
/home/hp/combined/crislinux-sim/cris-axis-linux-gnu/./libgfortran/.libs/libgfortran.a(fpu.o):
In function `*_gfortrani_set_fpu':.\
/fpu-target.h:42: warning: warning: fedisableexcept is not implemented and will
always fail^M

PASS: gfortran.fortran-torture/execute/in-pack.f90 compilation,  -O3
-fomit-frame-pointer
program stopped with signal 6.^M

So I guess you'd see it for targets where floating point rounding cannot be
changed (usually, no hardware support and implemented through fp-bit.c).


-- 

hp 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-07 23:24:28
   date||


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



[Bug c++/21308] [3.4/4.0 Regression] Very high compile time

2005-11-07 Thread mmitchel at gcc dot gnu dot org


--- Comment #15 from mmitchel at gcc dot gnu dot org  2005-11-07 23:10 
---
*** Bug 23457 has been marked as a duplicate of this bug. ***


-- 

mmitchel at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||laurent dot deniau at cern
   ||dot ch


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



[Bug c++/23457] [3.4/4.0/4.1 Regression] compiler crash on huge object size with virtual base

2005-11-07 Thread mmitchel at gcc dot gnu dot org


--- Comment #4 from mmitchel at gcc dot gnu dot org  2005-11-07 23:10 
---


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


-- 

mmitchel at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


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



[Bug libstdc++/24704] __gnu_cxx::__exchange_and_add is called even for single threaded applications

2005-11-07 Thread pcarlini at suse dot de


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pcarlini at suse dot de
   |dot org |
   Severity|normal  |enhancement
 Status|REOPENED|ASSIGNED
   Last reconfirmed|2005-11-07 15:15:56 |2005-11-07 23:06:57
   date||
Summary|[3.4/4.0/4.1 Regression]|__gnu_cxx::__exchange_and_ad
   |__gnu_cxx::__exchange_and_ad|d is called even for single
   |d is out of line and called |threaded applications
   |even for single threaded|
   |applications using  |
   |std::string |


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



[Bug libstdc++/24720] poorly named include guard in stl_tree.h

2005-11-07 Thread pcarlini at suse dot de


--- Comment #2 from pcarlini at suse dot de  2005-11-07 21:54 ---
(In reply to comment #1)
> Note _TREE_H is reserved by the standard for implementations so this is a
> correct use really.  Anyone using _TREE_H in their headers are asking for
> troubles as they are using a reserved identifier.

Indeed. Please read closely 17.4.3.1.2.


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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



[Bug libstdc++/24720] poorly named include guard in stl_tree.h

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


--- Comment #1 from pinskia at gcc dot gnu dot org  2005-11-07 21:51 ---
Note _TREE_H is reserved by the standard for implementations so this is a
correct use really.  Anyone using _TREE_H in their headers are asking for
troubles as they are using a reserved identifier.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|c++ |libstdc++


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



[Bug c++/24720] New: poorly named include guard in stl_tree.h

2005-11-07 Thread carmelo dot piccione at gmail dot com
Due to the global nature of macros, the include guard at the top of stl_tree.h:

#ifndef _TREE_H 
...

should be renamed to something more specific such as _STL_TREE_H. _TREE_H
shouldn't really be defined by anyone, especially the STL library. I noticed
this header from someone else who wrote code with a C include guard of the same
name which caused a compiler error when using #include . This convention
of being as specific as possible for any include guard macro should be
pervasive through the entire C++ header collection.


-- 
   Summary: poorly named include guard in stl_tree.h
   Product: gcc
   Version: 3.4.4
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carmelo dot piccione at gmail dot com


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



[Bug fortran/24719] New: Summary: [4.1 Regression] Nonadvancing read does not read more than 1 line

2005-11-07 Thread sven dot buijssen at math dot uni-dortmund dot de
Revision 1.64 of libgfortran/io/transfer.c causes a regression for the
following testcase:

% cat < regression.f90
program demonstration
implicit none
character(len=1) :: saux
open(unit = 1, FILE = "foo.conf", STATUS = 'OLD', ACTION = 'READ')
do
10read(unit = 1, fmt = '(a)', advance = 'no', end = 99, eor = 11) saux
  print *, "'", saux, "'"
  cycle
11print *, "Newline"
end do
99  close(1)
end program
EOF

% cat < foo.conf
foo1: bar
1.2
EOF


ifort and g95 compiled binaries give:
 'f'
 'o'
 'o'
 '1'
 ':'
 ' '
 'b'
 'a'
 'r'
 Newline
 '1'
 '.'
 '2'
 Newline

while gfortran 4.1.0 20051024 gives only the characters from the first line of
'foo.conf', all characters after the first 'end of record' are whitespace:
 'f'
 'o'
 'o'
 '1'
 ':'
 ' '
 'b'
 'a'
 'r'
 Newline
 ' '
 ' '
 ' '
 Newline


For sake of compliance with the bug report policy:
* gfortran from cvs via 
TZ=GMT cvs -q update -D'2005.10.24.03.00.00'
  works,
* gfortran from cvs via 
TZ=GMT cvs -q update -D'2005.10.24.04.00.00'
  does not.



By the way, there is another small issue with the above testcase. I'm not sure
if I should file a separate bug report for it:
Changing line 6 of regression.f90 to 

10read(unit = 1, fmt = '(a)', advance = 'no', end = 99, eor = 10) saux

gives the incorrect warning:

 In file regression.f90:6

10read(unit = 1, fmt = '(a)', advance = 'no', end = 99, eor = 10) saux
 1
Warning: Branch at (1) causes an infinite loop

while ifort and g95 do not complain.


-- 
   Summary: Summary: [4.1 Regression] Nonadvancing read does not
read more than 1 line
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sven dot buijssen at math dot uni-dortmund dot de
 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=24719



[Bug bootstrap/24710] gfortran - fails to build on Mac OSX -10.4.3

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


--- Comment #9 from pinskia at gcc dot gnu dot org  2005-11-07 21:16 ---
(In reply to comment #8)
> If -
> 
> cvs -d :ext:[EMAIL PROTECTED]:/cvsroot/gcc co gcc
> 
> is now wrong, what is the correct CVS command to use ?

GCC does not use cvs any more.

Read http://gcc.gnu.org/svn.html


What happens if you do "make bootstrap" instead of make?


-- 


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



[Bug bootstrap/24710] gfortran - fails to build on Mac OSX -10.4.3

2005-11-07 Thread dir at lanl dot gov


--- Comment #8 from dir at lanl dot gov  2005-11-07 21:14 ---
If -

cvs -d :ext:[EMAIL PROTECTED]:/cvsroot/gcc co gcc

is now wrong, what is the correct CVS command to use ?


Changing the directory make no difference, I have done exactly the same thing
for the last year or so and I had trouble building gfortran on the macintosh
only one other time -

configure --prefix=/Users/dir/bin --enable-languages=c,f95
make -j 4
...
...



for mlib in '' $MLIBS ; do \
  strip -o libgcc_s.10.4.dylib_T${mlib} \
-s ../.././gcc/config/rs6000/darwin-libgcc.10.4.ver -c -u \
libgcc_s${mlib}.1.dylib || exit 1 ; \
done
MLIBS=`/Users/dir/gfortran/gcc/host-powerpc-apple-darwin8.3.0/gcc/xgcc
-B/Users/dir/gfortran/gcc/host-powerpc-apple-darwin8.3.0/gcc/
-B/Users/dir/bin/powerpc-apple-darwin8.3.0/bin/
-B/Users/dir/bin/powerpc-apple-darwin8.3.0/lib/ -isystem
/Users/dir/bin/powerpc-apple-darwin8.3.0/include -isystem
/Users/dir/bin/powerpc-apple-darwin8.3.0/sys-include --print-multi-lib \
| sed -e 's/;.*$//' -e '/^\.$/d' -e 's/^/_/'` ; \
for mlib in '' $MLIBS ; do \
  strip -o libgcc_s.10.5.dylib_T${mlib} \
-s ../.././gcc/config/rs6000/darwin-libgcc.10.5.ver -c -u \
libgcc_s${mlib}.1.dylib || exit 1 ; \
done
Could Not Open (-o) To Read
make[2]: *** [libgcc_s.10.4.dylib] Error 1
make[2]: *** Waiting for unfinished jobs
Could Not Open (-o) To Read
make[2]: *** [libgcc_s.10.5.dylib] Error 1
rm cpp.pod gfortran.pod fsf-funding.pod gpl.pod gcc.pod gcov.pod gfdl.pod
make[1]: *** [all-gcc] Error 2
make: *** [all] Error 2


-- 


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



[Bug c++/24717] spurious error

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


--- Comment #1 from pinskia at gcc dot gnu dot org  2005-11-07 21:00 ---
Fixed in 4.0.0 and above.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to fail||2.95.3 3.2.3 3.4.0 3.4.5
  Known to work||4.0.0 4.1.0 4.0.3
 Resolution||FIXED
   Target Milestone|--- |4.0.0


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



[Bug rtl-optimization/23490] [3.4/4.0 Regression] Long compile time for array initializer with inlined constructor

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


--- Comment #13 from pinskia at gcc dot gnu dot org  2005-11-07 20:56 
---
Fixed at least on the mainline.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[3.4/4.0/4.1 Regression]|[3.4/4.0 Regression] Long
   |Long compile time for array |compile time for array
   |initializer with inlined|initializer with inlined
   |constructor |constructor


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



[Bug middle-end/24716] [4.1 Regression] Wrong code generated when optimising

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


--- Comment #4 from pinskia at gcc dot gnu dot org  2005-11-07 20:43 ---
-O1 -fno-tree-ccp -fno-tree-store-ccp -fno-tree-dominator-opts works  (maybe
this will give a hint on how to reduce the issue).


-- 


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



[Bug middle-end/24716] [4.1 Regression] Wrong code generated when optimising

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


--- Comment #3 from pinskia at gcc dot gnu dot org  2005-11-07 20:39 ---
A little more info, umf_analyze.i is being miscompiled.  I don't know which one
yet.


-- 


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



[Bug fortran/24409] ICE on module name vs dummy argument name

2005-11-07 Thread pault at gcc dot gnu dot org


--- Comment #5 from pault at gcc dot gnu dot org  2005-11-07 20:14 ---
> Did this patch ever get posted?

Tobi, that's a coincidence; I just found it whilst working on dot_product!

I'll submit in the next 24 hours.  I've found another patch that I just forgot
about too


-- 


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



[Bug libgcj/24616] linking BC-compiled classes: NoClassDefFoundErrors should be deferred

2005-11-07 Thread thebohemian at gmx dot net


--- Comment #13 from thebohemian at gmx dot net  2005-11-07 20:03 ---
anthony you're right. It should work without ffi_call invocation.

Thanks for the review. I try to find out whether this fixes my segfault too,
tomorrow.


-- 


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



[Bug bootstrap/24710] gfortran - fails to build on Mac OSX -10.4.3

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


--- Comment #7 from pinskia at gcc dot gnu dot org  2005-11-07 20:03 ---
Can you try first by not building in the source directory?
Second that CVS repro is no longer being updated.


-- 


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



[Bug libstdc++/21072] base allocator change shared object issues

2005-11-07 Thread matz at suse dot de


--- Comment #7 from matz at suse dot de  2005-11-07 19:59 ---
Of course not.  But unaware people trying trunk currently on distros which
provided 3.4 or 4.0 will get non-obvious problems, and I'm not sure if that's
a good idea (ignoring this problem 4.0 and trunk are nearly compatible, and
4.0 compiled programs work with the trunk libstc++, which has the same
SOname like the 4.0 one).  I think the only way to switch to the 'mt'
allocator by default for the future without API issues would be to rename
it to 'new', and not via some configure arguments.

Another reason is that this switching back of the default allocator is
not forgotten when 4.1 branches, which I think is necessary anyway, so that
4.1 libs are compatible with 4.0 programs.


-- 


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



[Bug preprocessor/15220] [3.4 regression] "gcc -E -MM -MG" reports missing system headers in source directory

2005-11-07 Thread wilson at gcc dot gnu dot org


--- Comment #19 from wilson at gcc dot gnu dot org  2005-11-07 19:52 ---
Fixed on gcc-3.4.x branch, gcc-4.0.x branch, and mainline.


-- 

wilson at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work|4.0.3 4.1.0 |4.0.3 4.1.0 3.4.5
 Resolution||FIXED


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



[Bug preprocessor/15220] [3.4 regression] "gcc -E -MM -MG" reports missing system headers in source directory

2005-11-07 Thread wilson at gcc dot gnu dot org


--- Comment #18 from wilson at gcc dot gnu dot org  2005-11-07 19:51 ---
Mine.


-- 

wilson at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |wilson at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2004-04-30 12:53:54 |2005-11-07 19:51:09
   date||


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



[Bug preprocessor/15220] [3.4 regression] "gcc -E -MM -MG" reports missing system headers in source directory

2005-11-07 Thread wilson at gcc dot gnu dot org


--- Comment #17 from wilson at gcc dot gnu dot org  2005-11-07 19:49 ---
Subject: Bug 15220

Author: wilson
Date: Mon Nov  7 19:49:04 2005
New Revision: 106608

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106608
Log:
Fix problem with -MM -MG and missing system header files.
PR preprocessor/15220
* cppfiles.c (_cpp_find_file): New parameter angle_brackets.  Fix all
callers.  Pass to open_file_failed.
(open_file_failed): New parameter angle_brackets.  Fix
all callers.  use in print_dep assignment.
* cpphash.h (_cpp_find_file): Add new parm to declaration.
* cppinit.c (cpp_read_main_file): Pass another arg to _cpp_find_file.

Modified:
branches/gcc-3_4-branch/gcc/ChangeLog
branches/gcc-3_4-branch/gcc/cppfiles.c
branches/gcc-3_4-branch/gcc/cpphash.h
branches/gcc-3_4-branch/gcc/cppinit.c


-- 


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



[Bug c++/21123] [4.0/4.1 regression] ICE in cp_expr_size, at cp/cp-objcp-common.c:101

2005-11-07 Thread jason at gcc dot gnu dot org


--- Comment #24 from jason at gcc dot gnu dot org  2005-11-07 19:35 ---
This is a bug in the generic thunk support; it doesn't show up on x86 because
it uses asm thunks.  Continuing to investigate.


-- 


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



[Bug driver/24718] New: Shared libgcc not used for linking by default

2005-11-07 Thread bugzilla-gcc at thewrittenword dot com
I've built gcc-3.4.3 for HP-UX 11.23/IA-64 and used the pre-compiled
gcc-3.4.4 binary from the http://www.hp.com/go/gcc site. Both exhibit
the same problem. While trying to build Perl 5.8.6:
  $ gmake
  ...  
  gcc -v -o libperl.so -shared -fPIC perl.o  gv.o toke.o perly.o op.o
pad.o regcomp.o dump.o util.o mg.o reentr.o hv.o av.o run.o pp_hot.o
sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o
taint.o deb.o universal.o xsutils.o globals.o perlio.o perlapi.o
numeric.o locale.o pp_pack.o pp_sort.o  -lcl -lnsl -lnm -ldl -ldld -lm
-lsec -lpthread -lc
  ...
 /opt/TWWfsw/gcc343/libexec/gcc/ia64-hp-hpux11.23/3.4.3/collect2
+Accept TypeMismatch -b -o libperl.so -L/opt/TWWfsw/gcc343r/lib
-L/opt/TWWfsw/gcc343/lib/gcc/ia64-hp-hpux11.23/3.4.3 -L/usr/ccs/bin
-L/usr/ccs/lib
-L/opt/TWWfsw/gcc343/lib/gcc/ia64-hp-hpux11.23/3.4.3/../../.. perl.o
gv.o toke.o perly.o op.o pad.o regcomp.o dump.o util.o mg.o reentr.o
hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o
doio.o regexec.o utf8.o taint.o deb.o universal.o xsutils.o globals.o
perlio.o perlapi.o numeric.o locale.o pp_pack.o pp_sort.o -lcl -lnsl
-lnm -ldl -ldld -lm -lsec -lpthread -lc -lgcc -lgcc
^^^

Notice the "-lgcc -lgcc" at the end of the collect2 command-line, not "-lgcc_s
-lgcc_s".

On HP-UX 11.23/PA-RISC, I get:
  /opt/TWWfsw/gcc343/libexec/gcc/hppa2.0-hp-hpux11.23/3.4.3/collect2
-z -b -o libperl.sl -L/opt/TWWfsw/gcc343r/lib
-L/opt/TWWfsw/gcc343r/lib
-L/opt/TWWfsw/gcc343/lib/gcc/hppa2.0-hp-hpux11.23/3.4.3 -L/usr/ccs/bin
-L/usr/ccs/lib -L/opt/langtools/lib -L/opt/TWWfsw/gcc343/lib perl.o
gv.o toke.o perly.o op.o pad.o regcomp.o dump.o util.o mg.o reentr.o
hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o
doio.o regexec.o utf8.o taint.o deb.o universal.o xsutils.o globals.o
perlio.o perlapi.o numeric.o locale.o pp_pack.o pp_sort.o -lcl -lnsl
-lnm -lmalloc -ldld -lm -lcrypt -lsec -lpthread -lc -lgcc_s -lgcc_s

Using the HP pre-compiled binary of gcc-4.0.2, I get:
 /opt/hp-gcc/4.0.2/bin/../libexec/gcc/ia64-hp-hpux11.23/4.0.2/collect2
-z +Accept TypeMismatch -b -o libperl.so
-L/opt/hp-gcc/4.0.2/bin/../lib/gcc/ia64-hp-hpux11.23/4.0.2
-L/opt/hp-gcc/4.0.2/bin/../lib/gcc
-L/opt/hp-gcc/4.0.2//lib/gcc/ia64-hp-hpux11.23/4.0.2 -L/usr/ccs/bin
-L/usr/ccs/lib
-L/opt/hp-gcc/4.0.2/bin/../lib/gcc/ia64-hp-hpux11.23/4.0.2/../../..
-L/opt/hp-gcc/4.0.2//lib/gcc/ia64-hp-hpux11.23/4.0.2/../../.. perl.o
gv.o toke.o perly.o op.o pad.o regcomp.o dump.o util.o mg.o reentr.o
hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o
doio.o regexec.o utf8.o taint.o deb.o universal.o xsutils.o globals.o
perlio.o perlapi.o numeric.o locale.o pp_pack.o pp_sort.o -lcl -lnsl
-lnm -ldl -ldld -lm -lsec -lpthread -lc -lgcc_s -lunwind -lgcc_s
-lunwind

The "*libgcc" line from the 3.4.3/3.4.4 specs file:
  *libgcc:
  %{shared-libgcc:%{!mlp64:-lgcc_s}%{mlp64:-lgcc_s_hpux64}
%{static|static-libgcc:-lgcc -lgcc_eh
-lunwind}%{!static:%{!static-libgcc:%{!shared:%{!shared-libgcc:-lgcc -lgcc_eh
-lunwind}%{shared-libgcc:-lgcc_s%M -lunwind -lgcc}}%{shared:-lgcc_s%M
-lunwind%{!shared-libgcc:-lgcc}

The "*libgcc" line from the 4.0.2 specs file (via -dumpspecs):
  *libgcc:
  %{static|static-libgcc:-lgcc -lgcc_eh
-lunwind}%{!static:%{!static-libgcc:%{!shared:%{!shared-libgcc:-lgcc -lgcc_eh
-lunwind}%{shared-libgcc:-lgcc_s -lunwind -lgcc}}%{shared:-lgcc_s -lunwind}}}

Is the problem in the "*libgcc" entry? It seems !shared-libgcc is true, though
I don't know why.
  $ /opt/TWWfsw/gcc343/bin/gcc -v
  Reading specs from
  /opt/TWWfsw/gcc343/lib/gcc/ia64-hp-hpux11.23/3.4.3/specs
  Configured with: /opt/build/gcc-3.4.3/configure --with-gnu-as
  --with-as=/opt/TWWfsw/gcc343/ia64-hp-hpux11.23/bin/as
  --with-included-gettext --enable-shared
  --datadir=/opt/TWWfsw/gcc343/share --enable-languages=c,c++,f77
  --with-local-prefix=/opt/TWWfsw/gcc343 --prefix=/opt/TWWfsw/gcc343
  Thread model: single
  gcc version 3.4.3 (TWW)


-- 
   Summary: Shared libgcc not used for linking by default
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bugzilla-gcc at thewrittenword dot com
 GCC build triplet: ia64-hp-hpux11.23
  GCC host triplet: ia64-hp-hpux11.23
GCC target triplet: ia64-hp-hpux11.23


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



[Bug bootstrap/24710] gfortran - fails to build on Mac OSX -10.4.3

2005-11-07 Thread dir at lanl dot gov


--- Comment #6 from dir at lanl dot gov  2005-11-07 19:19 ---
I have a dual 2.5 GHZ PowerPC G5


-- 


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



[Bug bootstrap/24710] gfortran - fails to build on Mac OSX -10.4.3

2005-11-07 Thread dir at lanl dot gov


--- Comment #5 from dir at lanl dot gov  2005-11-07 19:17 ---
I do the get with -

[dranta:~/utlib] dir% cat gfortranGet
cvs -d :ext:[EMAIL PROTECTED]:/cvsroot/gcc co gcc

I do the configure with -

[dranta:~/utlib] dir% cat gfortranConfig
configure --prefix=/Users/dir/gfortran --enable-languages=c,f95


-- 


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



[Bug driver/24684] No flag documentation for gomp (openmp)

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


--- Comment #2 from dnovillo at gcc dot gnu dot org  2005-11-07 19:06 
---

Fixed.  http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00458.html


-- 

dnovillo at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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



[Bug c++/24717] New: spurious error

2005-11-07 Thread igodard at pacbell dot net
enum A{a,b,c};
template void f(const U&, int) {}
template void f(const U&, int) {}
template void f(const U&, int) {}
template void f(const U&, int, int) {}
template void f(const U&, int, int) {}
template void f(const U&, int, int) {}

int main() {
bool b;
f(b, 5);
f(b, 5);
f<>(b, 5);
f(b, 5, 10);
f(b, 5, 10);
f<>(b, 5, 10);
}


gets you:

~/ootbc/members/src$ g++ foo.cc
foo.cc: In function `int main()':
foo.cc:11: error: invalid conversion from `int' to `A'
foo.cc:12: error: invalid conversion from `int' to `A'


Ivan


-- 
   Summary: spurious error
   Product: gcc
   Version: 3.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net


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



[Bug rtl-optimization/24683] [3.4/4.0/4.1 Regression] ICE in in extract_insn, at recog.c:2084

2005-11-07 Thread ian at airs dot com


--- Comment #24 from ian at airs dot com  2005-11-07 18:58 ---
Fixed on 4.0 branch and on mainline.

The 3.4 branch breaks in a slightly different way.  I'm not going to worry
about it since you can only create this problem by building implausible
addresses that include offsets of more than 2GB.


-- 

ian at airs dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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



[Bug rtl-optimization/24683] [3.4/4.0/4.1 Regression] ICE in in extract_insn, at recog.c:2084

2005-11-07 Thread ian at gcc dot gnu dot org


--- Comment #23 from ian at gcc dot gnu dot org  2005-11-07 18:55 ---
Subject: Bug 24683

Author: ian
Date: Mon Nov  7 18:55:03 2005
New Revision: 106602

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106602
Log:
./:
PR rtl-optimization/24683
* config/i386/i386.c (legitimize_pic_address): If constant operand
to PLUS is too large, put it in a register.
testsuite/:
PR rtl-optimization/24683
* gcc.dg/pr24683.c: New test.

Added:
branches/gcc-4_0-branch/gcc/testsuite/gcc.dg/pr24683.c
Modified:
branches/gcc-4_0-branch/gcc/ChangeLog
branches/gcc-4_0-branch/gcc/config/i386/i386.c
branches/gcc-4_0-branch/gcc/testsuite/ChangeLog


-- 


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



[Bug rtl-optimization/24683] [3.4/4.0/4.1 Regression] ICE in in extract_insn, at recog.c:2084

2005-11-07 Thread ian at gcc dot gnu dot org


--- Comment #22 from ian at gcc dot gnu dot org  2005-11-07 18:52 ---
Subject: Bug 24683

Author: ian
Date: Mon Nov  7 18:52:24 2005
New Revision: 106601

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106601
Log:
./:
PR rtl-optimization/24683
* config/i386/i386.c (legitimize_pic_address): If constant operand
to PLUS is too large, put it in a register.
testsuite/:
PR rtl-optimization/24683
* gcc.dg/pr24683.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr24683.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog


-- 


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



[Bug middle-end/24716] [4.1 Regression] Wrong code generated when optimising

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


--- Comment #2 from pinskia at gcc dot gnu dot org  2005-11-07 18:49 ---
(In reply to comment #0)
> The error seems to be specific to powerpc; it does not happen on i386.
It does fail for me on i686 with 4.1.0 20051026.


-- 


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



[Bug rtl-optimization/24683] [3.4/4.0/4.1 Regression] ICE in in extract_insn, at recog.c:2084

2005-11-07 Thread mueller at kde dot org


--- Comment #21 from mueller at kde dot org  2005-11-07 18:45 ---
its an error in the testcase, the original code initializes i: 

  if((j + len) > 63) {
562 memcpy(&context->buffer[j], data, (i = 64-j));
563 transform(context->state, context->buffer);
564 for ( ; i + 63 < len; i += 64) {
565 transform(context->state, &data[i]);
566 }


-- 


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



[Bug middle-end/24716] [4.1 Regression] Wrong code generated when optimising

2005-11-07 Thread schnetter at aei dot mpg dot de


--- Comment #1 from schnetter at aei dot mpg dot de  2005-11-07 18:42 
---
Created an attachment (id=10165)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10165&action=view)
Tarball with source code demonstrating the problem


-- 


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



[Bug middle-end/24716] [4.1 Regression] Wrong code generated when optimising

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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||wrong-code
Summary|Wrong code generated when   |[4.1 Regression] Wrong code
   |optimising  |generated when optimising
   Target Milestone|--- |4.1.0


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



[Bug rtl-optimization/24683] [3.4/4.0/4.1 Regression] ICE in in extract_insn, at recog.c:2084

2005-11-07 Thread ian at airs dot com


--- Comment #20 from ian at airs dot com  2005-11-07 18:41 ---
By the way, Richard, I just want to note that while this is obviously a
compiler bug, it is only being triggered for the original test case because of
the uninitialized variable i in sha1_update:

  void sha1_update(SHA1_CONTEXT* context, unsigned char* data, Q_UINT32
len)  {
 Q_UINT32 i, j;
 if((j + len) > 63) {
 for ( ;
  i + 63 < len;
  i += 64) {  transform(context->state, &data[i]); }
}
}

I don't know if that was a consequence of your test case reduction or not.


-- 


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



[Bug bootstrap/24688] [3.4 Regression] sco_math fixincl breaks math.h

2005-11-07 Thread sje at cup dot hp dot com


--- Comment #4 from sje at cup dot hp dot com  2005-11-07 18:40 ---
Original patch submittal is at

http://gcc.gnu.org/ml/gcc-patches/2004-11/msg00985.html

I will apply this to the 3.4 branch and test it.


-- 


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



[Bug c/24716] New: Wrong code generated when optimising

2005-11-07 Thread schnetter at aei dot mpg dot de
In a large application, a certain routine from the UMFPACK library is
miscompiled when -O is specified.  Without optimisation, the routine works
fine.  This triggers an assertion failure in the code.

I use gcc (GCC) 4.1.0 20051030 (experimental).  The problem can be reproduced
with the attached source files.  To see the error, compile them with

/gcc/bin/gcc -g -O -o umfpack-bug umfpack-call.c umf_analyze.i
umf_apply_order.i umf_order_front_tree.i umf_dump.i

When run, the executable aborts with an assertion failure:

/Users/eschnett/Calpha/arrangements/AEIThorns/AHFinderDirect/src/sparse-matrix/umfpack/umf_analyze.c:500:
failed assertion `parent == j+1'
Abort trap (core dumped)

To make the error go away, omit the "-O" option.  In this case, the executable
runs without producing any output.

The error seems to be the following.  The routine UMF_analyze contains a large
loop in which the local variable pdest is changed.  In the next iteration,
pdest is reset to the value it had before the loop.  This happens only for
local variables, not for static or global variables.

The error seems to be specific to powerpc; it does not happen on i386.

gcc 3.3 does not have this problem.


-- 
   Summary: Wrong code generated when optimising
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schnetter at aei dot mpg dot de
 GCC build triplet: powerpc-apple-darwin8.2.0
  GCC host triplet: powerpc-apple-darwin8.2.0
GCC target triplet: powerpc-apple-darwin8.2.0


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



[Bug bootstrap/24688] [3.4 Regression] sco_math fixincl breaks math.h

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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|sco_math fixincl breaks |[3.4 Regression] sco_math
   |math.h  |fixincl breaks math.h
   Target Milestone|--- |3.4.5


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



[Bug bootstrap/24688] sco_math fixincl breaks math.h

2005-11-07 Thread sje at cup dot hp dot com


--- Comment #3 from sje at cup dot hp dot com  2005-11-07 18:26 ---
It looks like this is fixed on the mainline and on the 4.0 branch by the
addition of

bypass   = "__GNUG__";

This patch was done in revision 90550 by jsm28.  We should do this for the 3.4
branch as well.


-- 

sje at cup dot hp dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2005-11-07 18:26:51
   date||


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



[Bug rtl-optimization/22509] [4.1 regression] elemental.f90 testsuite failure (-fweb)

2005-11-07 Thread bonzini at gcc dot gnu dot org


--- Comment #21 from bonzini at gcc dot gnu dot org  2005-11-07 18:22 
---
Is this a 4.0 regression too?


-- 


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



[Bug bootstrap/17269] make install doesn't work after --enable-bootstrap enabled bootstrap

2005-11-07 Thread bonzini at gcc dot gnu dot org


--- Comment #3 from bonzini at gcc dot gnu dot org  2005-11-07 18:19 ---
it works now


-- 

bonzini at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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



[Bug c/24599] [4.0 regression] Overflow for true value

2005-11-07 Thread bonzini at gcc dot gnu dot org


--- Comment #9 from bonzini at gcc dot gnu dot org  2005-11-07 18:18 ---
fixed on 4.0 branch too


-- 

bonzini at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to fail|4.0.3   |4.0.2
  Known to work|3.4.0 4.1.0 |3.4.0 4.0.3 4.1.0
 Resolution||FIXED


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



  1   2   >