date:20060306



On Mar 6, 2006, at 8:12 AM, Pierre Chatelier wrote:


Hello,

I cannot compile a code that seems correct to me. I have tried with 
gcc 3.3 and gcc 4.0.1 on MacOS X-ppc, and gcc 4.0.1 on Linux i686.


Here is the code, that uses pure virtual functions and simple 
inheritance.


//-
struct a
{
  virtual int foo() =0;
  virtual ~a(){}
};

struct b : public a
{
  virtual int foo(int a) =0;
  virtual ~b(){}
};

struct c : public b
{
  int test()
   {
 return (foo() + // --- the compiler claims here that it cannot 
find foo()

 foo(2));
  }
  virtual ~c(){}
};

This is not a bug in gcc.  foo in b hides the one from a.
You can fix the source by:
struct b : public a
{
  virtual int foo(int a) =0;
  using a::foo;
  virtual ~b(){}
};

Which interjects foo from a into b's namespace.

-- Pinski

Re: Is this a bug of gcc ?

2006-03-06 Thread Pierre Chatelier


Thanks for the quick answer.

This is ok to fix the source, but I do not understand why it is  
normal behaviour that the foo() in b hides the one from a. They have  
different prototypes.


Regards,

Pierre Chatelier


This is not a bug in gcc.  foo in b hides the one from a.
You can fix the source by:
struct b : public a
{
  virtual int foo(int a) =0;
  using a::foo;
  virtual ~b(){}
};

Re: GCC Internals Wikibook

2006-03-06 Thread Alexey Smirnov


There is a wikibook that describes the internals of GCC and GEM, an
extensibility framework.


Your internals documentation looks pretty good, so I have made a link
to it from gcc.gnu.org/readings.html.  Thanks,


It describes AST part of GCC source code. We would like to ask developers to 
work on the intermediate representation and backends. When the book gets 
comprehensive enough we will generate a PDF from it for a convenient 
distribution.


Alexey

Re: gcc-4.2-20060304 is now available

2006-03-06 Thread Joseph S. Myers

On Mon, 6 Mar 2006, Paolo Bonzini wrote:

 It is a bit weird that objcp is included in the gcc-core download.  It could
 be included in the gcc-objc download (or in a separate objcp download).  But

It should go in an objcp download.  sourcebuild.texi includes updating the 
release script as one of the things to do when contributing a new front 
end.

-- 
Joseph S. Myers   http://www.srcf.ucam.org/~jsm28/gcc/
[EMAIL PROTECTED] (personal mail)
[EMAIL PROTECTED] (CodeSourcery mail)
[EMAIL PROTECTED] (Bugzilla assignments and CCs)

Re: GCC 4.0.3 RC1

2006-03-06 Thread Kaz Kojima

Mark Mitchell [EMAIL PROTECTED] wrote:
 GCC 4.0.3 RC1 is available here:
 
 ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.3-20060303
 
 Please download and test!

There are failures on sh4-*-linux-gnu during libjava build and 65
unusual regressions for C++ testsuite.  I don't file PRs for them
because it looks these are the same problems as PR target/22553
and PR target/23706 which are the target issues for the exception
solved at 4.1:

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

It seems that the recent changes on 4.0 branch reveal these target
problems which are latent on 4.0.  There are patches for these PRs,
though the patch for 23706 touches the middle end file.  I'm unsure
whether to backport it to 4.0.3 is appropriate or not at this last
stage.

Anyway the attached backport patches are tested with bootstrap and
make -k check on i686-pc-linux-gnu with no new failures.
Although bootstrap on sh4-unknown-linux-gnu is on going, the result
of the toplevel make -k check on x86 cross sh4-unknown-linux-gnu
looks fine.

Regards,
kaz
--
2006-03-06Kaz Kojima  [EMAIL PROTECTED]

PR target 23706
Backport from 4.1:
* lcm.c (optimize_mode_switching): Clear transp bit for
block with incomming abnormal edges.

PR target 22553
Backport from 4.1:
* config/sh/sh.h (OPTIMIZATION_OPTIONS): Set flag_schedule_insns
to 2 if it's already non-zero.
(OVERRIDE_OPTIONS): Clear flag_schedule_insns if flag_exceptions
is set and warn about it if flag_schedule_insns is 1.

diff -uprN ORIG/gcc-4.0.3-20060303/gcc/lcm.c TMP/gcc-4.0.3-20060303/gcc/lcm.c
--- ORIG/gcc-4.0.3-20060303/gcc/lcm.c   2005-01-18 20:36:31.0 +0900
+++ TMP/gcc-4.0.3-20060303/gcc/lcm.c2006-03-06 10:07:51.0 +0900
@@ -1223,6 +1223,18 @@ optimize_mode_switching (FILE *file)
 
  REG_SET_TO_HARD_REG_SET (live_now,
   bb-global_live_at_start);
+
+ /* Pretend the mode is clobbered across abnormal edges.  */
+ {
+   edge_iterator ei;
+   edge e;
+   FOR_EACH_EDGE (e, ei, bb-preds)
+ if (e-flags  EDGE_COMPLEX)
+   break;
+   if (e)
+ RESET_BIT (transp[bb-index], j);
+ }
+
  for (insn = BB_HEAD (bb);
   insn != NULL  insn != NEXT_INSN (BB_END (bb));
   insn = NEXT_INSN (insn))
diff -uprN ORIG/gcc-4.0.3-20060303/gcc/config/sh/sh.h 
TMP/gcc-4.0.3-20060303/gcc/config/sh/sh.h
--- ORIG/gcc-4.0.3-20060303/gcc/config/sh/sh.h  2006-01-05 08:07:24.0 
+0900
+++ TMP/gcc-4.0.3-20060303/gcc/config/sh/sh.h   2006-03-06 10:30:51.0 
+0900
@@ -695,6 +695,10 @@ do {   
\
   if (! (SIZE))\
target_flags |= SAVE_ALL_TR_BIT;\
 }  \
+  /* If flag_schedule_insns is 1, we set it to 2 here so we know if\
+ the user explicitly requested this to be on or off.  */   \
+  if (flag_schedule_insns  0) \
+flag_schedule_insns = 2;   \
 } while (0)
 
 #define ASSEMBLER_DIALECT assembler_dialect
@@ -796,6 +800,17 @@ do {   
\
 SH3 and lower as they give spill failures for R0.  */  \
   if (!TARGET_HARD_SH4)\
 flag_schedule_insns = 0;   \
+  /* ??? Current exception handling places basic block boundaries  \
+after call_insns.  It causes the high pressure on R0 and gives \
+spill failures for R0 in reload.  See PR 22553 and the thread  \
+on gcc-patches \
+ http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00816.html.  */
\
+  else if (flag_exceptions)
\
+   {   \
+ if (flag_schedule_insns == 1) \
+   warning (0, ignoring -fschedule-insns because of exception 
handling bug); \
+ flag_schedule_insns = 0;  \
+   }   \
 }  \
\
   if (align_loops == 0)
\

Re: gcc-4.2-20060304 is now available

2006-03-06 Thread Salvatore Filippone

Paolo Bonzini's patch appears to work. 
What the best solution is long term, is not really my province. 

Regards
Salvatore

Re: GCC Port (gcc backend) for Microchip PICMicro microcontroller

2006-03-06 Thread François Poulain

Hello,

Le lundi 06 mars 2006 à 13:39 +, Colm O' Flaherty a écrit :
 Francois,
 
 I'm really interested in getting a gcc port (gcc backend) for the Microchip 
 PIC16F family (14 bit instruction, 8 bit word) up and running.  I've seen 
 various mails to the gcc list that refer to this, the most recent being from 
 you.
It a good question. I think 18F is clearly C-oriented architecture,
whereas coding C on 16F is not very efficient. In the other hand, 16F is
quite simple,it could be a good example, and I better know 16F assembly
than 18F assembly (I always coded 18F in C).
 
 Can you summarise the current status of your port, or any other active gcc 
 PIC ports that you are aware of?
For the moment, I am only studying internal gcc documentation. I will be
quite busy until june month, so I don't planned anything for the moment.

About this subject, if a french people know well gcc machine descriptor
language, I am interessed in being mailled by him, to learn more about
that.
 
 There is an existing open-source C compiler with PIC support (SDCC) that 
 I've used, but my experience with this is that it isn't as scalable as I 
 would like (particularly for device support), whereas gcc is a well known 
 compiler with a solid code base, great platform support, and comes with 
 pretty much every Linux distribution I've ever seen.
I think so.
 
 Am I mistaken in thinking that if we got a gcc PIC backend up and running, 
 that we would be able to code for PICs in C, C++, Fortran, Ada, and Java 
 (subject to memory limitations, etc)???  Thats a dream...
I think so, and it's also the dream of a friend. Really, gcc seems have
a different behaviour for C-C++ and the others. I can't tell more about
that subject, and as far I am concerned, I don't have the competences
and the will to use Java on Pic.
 
 Colm O' Flaherty

Francois Poulain

reload problem in GCC 4.1

2006-03-06 Thread Rajkishore Barik

Hi,

I was trying to feed the reload phase with a different hardware
register assignment to pseudo registers (using reg_renumber array)
than the ones produced by local-alloc or global-alloc. However, I get
problems with the following instruction in post-reload.c:391 in
reload_cse_simplify_operands function stating that the insn does
not satisfy constraint.
Can someone please help me if the following instruction has any
specific constraint requirement during register allocation phase?

(insn:HI 100 99 102 8 (parallel [
(set (reg:SI 108)
(div:SI (reg:SI 75 [ prephitmp.6 ])
(reg:SI 74 [ prephitmp.8 ])))
(set (reg:SI 109)
(mod:SI (reg:SI 75 [ prephitmp.6 ])
(reg:SI 74 [ prephitmp.8 ])))
(clobber (reg:CC 17 flags))
]) 196 {*divmodsi4_cltd} (insn_list:REG_DEP_TRUE 99 (nil))
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_UNUSED (reg:SI 109)
(expr_list:REG_DEAD (reg:SI 74 [ prephitmp.8 ])
(expr_list:REG_DEAD (reg:SI 75 [ prephitmp.6 ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_UNUSED (reg:SI 109)
(nil

regards,
~R

Re: reload problem in GCC 4.1

2006-03-06 Thread Rajkishore Barik

The architecture for which I generate code is Intel x86.

On 3/6/06, Rajkishore Barik [EMAIL PROTECTED] wrote:
 Hi,

 I was trying to feed the reload phase with a different hardware
 register assignment to pseudo registers (using reg_renumber array)
 than the ones produced by local-alloc or global-alloc. However, I get
 problems with the following instruction in post-reload.c:391 in
 reload_cse_simplify_operands function stating that the insn does
 not satisfy constraint.
 Can someone please help me if the following instruction has any
 specific constraint requirement during register allocation phase?

 (insn:HI 100 99 102 8 (parallel [
 (set (reg:SI 108)
 (div:SI (reg:SI 75 [ prephitmp.6 ])
 (reg:SI 74 [ prephitmp.8 ])))
 (set (reg:SI 109)
 (mod:SI (reg:SI 75 [ prephitmp.6 ])
 (reg:SI 74 [ prephitmp.8 ])))
 (clobber (reg:CC 17 flags))
 ]) 196 {*divmodsi4_cltd} (insn_list:REG_DEP_TRUE 99 (nil))
 (expr_list:REG_UNUSED (reg:CC 17 flags)
 (expr_list:REG_UNUSED (reg:SI 109)
 (expr_list:REG_DEAD (reg:SI 74 [ prephitmp.8 ])
 (expr_list:REG_DEAD (reg:SI 75 [ prephitmp.6 ])
 (expr_list:REG_UNUSED (reg:CC 17 flags)
 (expr_list:REG_UNUSED (reg:SI 109)
 (nil

 regards,
 ~R

Request for testsuite regression period

I noticed that some testsuite regressions were not getting fixed.
There are 3 failures in the gcc.dg/tree-ssa (PR 26344).
And 5 in g++.dg (PR 26115 and PR 26114).
All of these testsuite regressions have been there for almost
three weeks (the C++ have been there over a month now).  The
patch which caused them has been identified over 48 hours ago.

What is the policy for testsuite regressions that have been
there for over 48 hours and effect all targets and have not
been fixed yet?

Should we cause the mainline to go into stage3 until these
regressions have been fixed?

Since the testsuite helps people know instantaneous if they
patch is wrong, having known FAILs stay too long just causes confusion.

Thanks,
Andrew Pinski

Re: Request for testsuite regression period

2006-03-06 Thread Jeffrey A Law

On Mon, 2006-03-06 at 12:34 -0500, Andrew Pinski wrote:
 I noticed that some testsuite regressions were not getting fixed.
 There are 3 failures in the gcc.dg/tree-ssa (PR 26344).
 And 5 in g++.dg (PR 26115 and PR 26114).
 All of these testsuite regressions have been there for almost
 three weeks (the C++ have been there over a month now).  The
 patch which caused them has been identified over 48 hours ago.
 
 What is the policy for testsuite regressions that have been
 there for over 48 hours and effect all targets and have not
 been fixed yet?
 
 Should we cause the mainline to go into stage3 until these
 regressions have been fixed?
 
 Since the testsuite helps people know instantaneous if they
 patch is wrong, having known FAILs stay too long just causes confusion.
If you're that bothered by the failures, then xfail them
until I can fix them.  

Revering the patch would be a giant PITA and would actually
make it *HARDER* to fix the Ada problems.

You're really not helping here.  I'm dealing with things as
quickly as I can and prioritizing the incorrect code issues
over minor performance issues.

\Jeff

Re: Request for testsuite regression period

 You're really not helping here.  I'm dealing with things as
 quickly as I can and prioritizing the incorrect code issues
 over minor performance issues.

If you noticed I pointed out other testsuite regressions than
just yours.  If I had posted the patch (not being a global write
maintainer) and it caused the regressions, people would be on my
back right now asking for them to be fixed.  I reported the failures
3 weeks ago thinking they would be fixed right away.  I did the
same for the C++ testsuite failures I saw too.  Lets look at this a
different way.  So you missed a couple of failures while bootstrapping
and testing, right.  The normal term of action is to fix them within
48 as mentioned on the policy page.  Now maybe you don't want to follow
the policy as you see your self higher than the Steering committee but 
that is not true.

Testsuite failures are annoying as make people quickly think they patch
is causing regressions.  I can already point one example with the tree-ssa
testsuite failures already.  In PR 26406, comment #6 and 7:
(In reply to comment #6)
 Patch that apart from regressing gcc.dg/tree-ssa/20030807-2.c bootstrapped and
 tested ok.
There is no regressions here as this test is already failing before your patch,
see PR 26344.




-- Pinski

Re: GCC 4.0.3 RC1

2006-03-06 Thread Eric Botcazou

On Sunday 05 March 2006 17:47, Mark Mitchell wrote:
 GCC 4.0.3 RC1 is available here:

 ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.3-20060303

OK on SPARC/Solaris:
http://gcc.gnu.org/ml/gcc-testresults/2006-03/msg00347.html
http://gcc.gnu.org/ml/gcc-testresults/2006-03/msg00346.html
http://gcc.gnu.org/ml/gcc-testresults/2006-03/msg00345.html
http://gcc.gnu.org/ml/gcc-testresults/2006-03/msg00344.html
http://gcc.gnu.org/ml/gcc-testresults/2006-03/msg00343.html
http://gcc.gnu.org/ml/gcc-testresults/2006-03/msg00342.html

-- 
Eric Botcazou

Re: Bogus trees from Ada front-end (more VRP vs Ada) stuff)

2006-03-06 Thread Jeffrey A Law

On Mon, 2006-03-06 at 00:31 +0100, Eric Botcazou wrote:

 
 
 cxa4025 and cxa4033 are very likely yours, originating in a miscompilation of
 the runtime (a-stwifi.adb) at -O2.  They succeed if the aforementioned unit 
 is compiled at -O2 -fno-tree-vrp.  You can pass -a to gnatmake to cause the 
 units to be recompiled locally.  Same for cxa4028 but with a-strsup.adb.
Here's the relevant bits from the .original dump for
Ada.Strings.Wide_Fixed.Trim:

Ada.Strings.Wide_Fixed.Trim (source, side)
[ ... ]

  if (side - 1 = 1)
{
   Unknown tree: loop_stmt
  (integer) high = (integer) low 
VIEW_CONVERT_EXPRwide_character[(long int) SAVE_EXPR
source.P_BOUNDS-LB0:MAX_EXPR (long int) SAVE_EXPR
source.P_BOUNDS-UB0, (long int) SAVE_EXPR source.P_BOUNDS-LB0 -
1](*source.P_ARRAY)[(unnamed type) (integer) high]{lb: (long int)
SAVE_EXPR source.P_BOUNDS-LB0 sz: 2} == 32


  high = (natural___XDLU_0__2147483647) ((integer) high - 1);
  D5436 
;
}
 
Of particular interest is the (side - 1 = 1) conditional which is
implementing this hunk of code from the Trim function:

 
  if Side = Right or else Side = Both then
 while High = Low and then Source (High) = Wide_Space loop
High := High - 1;
 end loop;
  end if;


side is an enumerated type with the following values


Symbolic name   Integer value
left0
right   1
both2

The min/max values associated with the type specify that side
should have the values [0, 2].

Note carefully that the expression (side - 1) will produce a value
outside the defined min/max values for side's type [0, 2] when side
has the value left.

Not surprisingly, we turn the .original code into this gimple code:

  D.5765 = side - 1;
  if (D.5765 = 1)


Where D.5765 is of type ada__strings_trim_end, ie, it's got a range
of [0, 2].  So the computation will produce a result outside the
defined range of the type in the case where side == left.

Not surprisingly, the VRP code optimizes this test.  If we know that
D.5765's type has the values [0, 2], then the test is equivalent to
D.5765 != 2, and it's all downhill from there when side == left.

I think it's time to hand this one to the Ada guys :-0

Jeff

Re: [Ada] Fix problem in convert_with_check

2006-03-06 Thread Jeffrey A Law

On Mon, 2006-03-06 at 00:31 +0100, Eric Botcazou wrote:

 cxa4025 and cxa4033 are very likely yours, originating in a miscompilation of
 the runtime (a-stwifi.adb) at -O2.  They succeed if the aforementioned unit 
 is compiled at -O2 -fno-tree-vrp.  You can pass -a to gnatmake to cause the 
 units to be recompiled locally.  Same for cxa4028 but with a-strsup.adb.
One more note, we see the same kind of conditional and test 
simplification with for cxa4028 in Ada.Strings.Superbounded.Super_Trim.
So I'm pretty confident that if we fix the bogus trees generated for
a-stwifi.adb that all three of these regressions will be fixed.

Jeff

Re: GCC Port (gcc backend) for Microchip PICMicro microcontroller

2006-03-06 Thread François Poulain

 Like you, I'm still studying the internals of gcc, but I'm close to
 being confident enough to start making some changes.

Nice !

Le lundi 06 mars 2006 à 17:17 +, Colm O' Flaherty a écrit :
 Francois,
 
 There are only 35 instructions in the 14 bit instruction set, and given 
 that, in gcc, the main initial work seems to be in describing the targets 
 instruction set, it might not take much to find out what implementation 
 issues will occur, by just taking to the time to describe the instructions. 
 For me, the things that I suspect to be issues are:
 
 -8 bit ALU
 -small memory space
 -limited stack space (8 levels on 16F)
 -the number of PIC devices (configurations) that would need to be supported 
 (with the various number of banks, and memory configs)
 
 Like you, I'm still studying the internals of gcc, but I'm close to being 
 confident enough to start making some changes.
 
 Colm

Re: Bogus trees from Ada front-end (more VRP vs Ada) stuff)



On Mar 6, 2006, at 1:39 PM, Jeffrey A Law wrote:

I think it's time to hand this one to the Ada guys :-0



I bet this is actually a fold issue rather than an Ada front-end issue.

-- Pinski

Re: Request for testsuite regression period

2006-03-06 Thread Joe Buck

On Mon, Mar 06, 2006 at 12:34:42PM -0500, Andrew Pinski wrote:
 What is the policy for testsuite regressions that have been
 there for over 48 hours and effect all targets and have not
 been fixed yet?

In this case, wouldn't removing the patch just move breakage from C++
to Ada?  Or do I misunderstand?

Re: Request for testsuite regression period



On Mar 6, 2006, at 2:21 PM, Joe Buck wrote:


On Mon, Mar 06, 2006 at 12:34:42PM -0500, Andrew Pinski wrote:

What is the policy for testsuite regressions that have been
there for over 48 hours and effect all targets and have not
been fixed yet?


In this case, wouldn't removing the patch just move breakage from C++
to Ada?  Or do I misunderstand?


You are misunderstanding, there are a couple different sets of testsuite
regressions. One in gcc.dg/tree-ssa and one in g++.dg.  Ada also has a
couple too.  Reverting Jeff's patch will fix the gcc.dg/tree-ssa 
regresions

and one of Ada's.  Rest of Ada testsuite regressions are due to Roger's
fold patch.  The C++ testsuite regressions are due to Lee Millward's
patch on 2006-02-03.

Thanks,
Andrew Pinski

Re: GCC 4.0.3 RC1

2006-03-06 Thread Mark Mitchell

Kaz Kojima wrote:

 It seems that the recent changes on 4.0 branch reveal these target
 problems which are latent on 4.0.  There are patches for these PRs,
 though the patch for 23706 touches the middle end file.  I'm unsure
 whether to backport it to 4.0.3 is appropriate or not at this last
 stage.
 
 Anyway the attached backport patches are tested with bootstrap and
 make -k check on i686-pc-linux-gnu with no new failures.
 Although bootstrap on sh4-unknown-linux-gnu is on going, the result
 of the toplevel make -k check on x86 cross sh4-unknown-linux-gnu
 looks fine.

If these patches show an improvement on SH4, please go ahead and check
them in.  Please inform me of the status ASAP.

Thanks,

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Linking with libgomp (ia64-hp-hpux11.23)

2006-03-06 Thread Steve Ellcey

I have run into a couple of linking problems trying to test/use -fopenmp
and libgomp and I was hoping for some help on where to look and how to
fix these problems.

Test failures:

I get a lot of test failures with:

| FAIL: libgomp.c/appendix-a/a.15.1.c (test for excess errors)
| Excess errors:
| ld: (Warning) Symbol __udivsi3 is not exported but is imported by a shared
library
| ld: (Warning) Symbol __divsi3 is not exported but is imported by a shared
library
| 2 warnings.

__udivsi3 and __divsi3 are of course the integer divide routines that
are in libgcc. I can make the test pass by running it with
-shared-libgcc, but I am not sure if I should just be trying to add
-shared-libgcc when I run libgomp tests or if -shared-libgcc needs to be
used when building libgomp itself. Nor am I sure how to do either.

The other thing I found was that when I tried to compile a program
with -fopenmp outside of the test harness it fails.

| $ gcc -fopenmp loop-3.c -o x
| ld: Can't find library or mismatched ABI for -lgomp
| Fatal error.

When I add -v I see:

| collect2 -z +Accept TypeMismatch -u main -o x -lgomp
-L/proj/opensrc/nightly/gcc-ia64-hp-hpux11.23-trunk/lib/gcc/ia64-hp-hpux11.23/4.2.0
-L/usr/ccs/lib
-L/proj/opensrc/nightly/gcc-ia64-hp-hpux11.23-trunk/lib/gcc/ia64-hp-hpux11.23/4.2.0/../../..
/var/tmp//ccGr80UQ.o -lgcc -lgcc_eh -lunwind -lpthread -lc -lgcc -lgcc_eh
-lunwind

Notice that the -lgomp comes in front of the -L flags. With the HP
linker this means that those directories will not be searched for
libgomp. If I move the -lgomp to after the -L options then I find
libgomp.

When I do move -lgomp later in the link though I get the messages about
__divsi3 and __udivsi3, so I think that means that I need to have
libgomp built with the -lgcc_s option.

Any Help/Advice?

Steve Ellcey
[EMAIL PROTECTED]

Re: GCC 4.0.3 RC1

2006-03-06 Thread Bob Wilson


Looks OK for xtensa-elf:

http://gcc.gnu.org/ml/gcc-testresults/2006-03/msg00356.html

--Bob

Re: Is this a bug of gcc ?

2006-03-06 Thread Pierre Chatelier

That's just how C++ is designed/defined, any book on C++ should be  
able to explain this in more detail.
Since it was not a bug, I have posted related questions on the gcc- 
help list, and I have had valuable answers.

http://gcc.gnu.org/ml/gcc-help/2006-03/msg00026.html

Now I have understood :-)

Thanks for taking the time to answer !

Regards,

Pierre Chatelier

Pre-Berlin WG14 mailing and updated DRs available

2006-03-06 Thread Joseph S. Myers

The pre-Berlin WG14 mailing, and the updated C99 DR logs, are now 
available from the WG14 website.  There's an updated decimal float draft 
TR in there, among other items.

http://www.open-std.org/JTC1/SC22/WG14/www/docs/pre-berlin.htm
http://www.open-std.org/JTC1/SC22/WG14/www/docs/pre-berlin.tar.gz
http://www.open-std.org/JTC1/SC22/WG14/www/docs/dr_log-0603.tar.gz

-- 
Joseph S. Myers   http://www.srcf.ucam.org/~jsm28/gcc/
[EMAIL PROTECTED] (personal mail)
[EMAIL PROTECTED] (CodeSourcery mail)
[EMAIL PROTECTED] (Bugzilla assignments and CCs)

Re: Bogus trees from Ada front-end (more VRP vs Ada) stuff)

2006-03-06 Thread Richard Kenner

Here's the relevant bits from the .original dump

  if (side - 1 = 1)

Of particular interest is the (side - 1 = 1) conditional which is
implementing this hunk of code from the Trim function:

  if Side = Right or else Side = Both then

I think it's time to hand this one to the Ada guys :-0

I don't.  This sounds like fold is merging the two comparisons above
incorrectly into the one upper comparison.  It can do the merge, but it
needs to convert to base types first.

Update bug 15020: Bugtracking complains unreasonably

2006-03-06 Thread sampo

When trying to submit further information for gcc bug 15020 I get 


Not allowed
You tried to change the Assignee field from [EMAIL PROTECTED] to 
__UNKNOWN__, but only the assignee of the bug, or a sufficiently empowered 
user may change that field. 


I can not figure which field of the form is causing this message or
what I should change to get past the message, thus I burden you
with this complaint mail. The submission attempt happened
approcimately Tue Mar  7 02:53:17 GMT 2006. 


Whatever the problem, please add following to bug 15020 titled
[win32] -mcpu=pentium4 generates wrong code: 


Not sure if this the same bug, but I have observed that gcc 3.4.5 compiled
as a cross compiler targetting i586-pc-mingw32 definitely miscompiles.
Apparently in a 3000 line C function with nearly 100 local variables the
stack for preparing a function call collides (stomps on) with the stack
based local variables. 

Specifically, when push instructions to prepare for function call are 
executed

some of the local variables get overwritten with disastrous consequences
later (i.e. a core). 


Workaround: Using `-g -O2 -fno-defer-pop -fno-strict-aliasing' apparently
makes the problem go away, though it might just reduce incidence since the
first locals on line to be stomped might not be used in my test case.
I think it was the -fno-defer-pop that made the difference. Using just
`-g -fno-strict-aliasing' without any optimization still reproduces the
problem. 


If there is interest I can try to prepare a case that reproduces, but
this is rather difficult as said 3000 line funcion is in context of
a 7 line virtual machine :-) 


This cropped up in porting the virtual machine to Windows. On Linux,
Mac OS X, Solaris, and some BSD platforms the code works OK and
passes extensive test suites. Thus this would seem to be specific
to MinGW platform or the way the cross compiler is built. 


Cheers,
--Sampo

Sampo Kellomaki --- Chief Architect --- DirectoryScript
M: +351-918.731.007  F: +351-213.422.185  W: www.symlabs.com
Customize directories - LDAP SOAP Liberty SIP - Directory Extender

[Bug libfortran/26564] ../.././libgfortran/mk-kinds-h.sh: Unknown type

2006-03-06 Thread diskman at kc dot rr dot com



--- Comment #11 from diskman at kc dot rr dot com  2006-03-06 08:03 ---
The AlphaPC 164SX is basically the same as the AlphaPC 164LX just minus the 96k
L1 cache but with additional MVI instructions.

[EMAIL PROTECTED] gcc-4.1.0]# gdb -args
/usr2/www/linux-related/programming/compilers/gcc-4.1.0/gcc-4.1.0/host-alphapca56-alpha-linux-gnu/gcc/gfortran
-B/usr2/www/linux-related/programming/compilers/gcc-4.1.0/gcc-4.1.0/host-alphapca56-alpha-linux-gnu/gcc/
-B/usr/alphapca56-alpha-linux-gnu/bin/ -B/usr/alphapca56-alpha-linux-gnu/lib/
-isystem /usr/alphapca56-alpha-linux-gnu/include -isystem a.f90
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 alphapca56-alpha-linux-gnu...
(no debugging symbols found)
Using host libthread_db library /lib/libthread_db.so.1.

(gdb) run
Starting program:
/usr2/www/pub/alpha-RH7/programming/compilers/gcc-4.1.0/gcc-4.1.0/host-alphapca56-alpha-linux-gnu/gcc/gfortran
-B/usr2/www/linux-related/programming/compilers/gcc-4.1.0/gcc-4.1.0/host-alphapca56-alpha-linux-gnu/gcc/
-B/usr/alphapca56-alpha-linux-gnu/bin/ -B/usr/alphapca56-alpha-linux-gnu/lib/
-isystem /usr/alphapca56-alpha-linux-gnu/include -isystem a.f90
Detaching after fork from child process 24853.
/usr/bin/ld: cannot find -lgfortranbegin
collect2: ld returned 1 exit status

Program exited with code 01.

[EMAIL PROTECTED] gcc-4.1.0]# find . -name *.so.*
./host-alphapca56-alpha-linux-gnu/gcc/libgcc_s.so.1.backup
./host-alphapca56-alpha-linux-gnu/gcc/libgcc_s.so.1
./alphapca56-alpha-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6.0.7
./alphapca56-alpha-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6
./alphapca56-alpha-linux-gnu/libmudflap/.libs/libmudflap.so.0.0.0
./alphapca56-alpha-linux-gnu/libmudflap/.libs/libmudflap.so.0
./alphapca56-alpha-linux-gnu/libmudflap/.libs/libmudflapth.so.0.0.0
./alphapca56-alpha-linux-gnu/libmudflap/.libs/libmudflapth.so.0
./alphapca56-alpha-linux-gnu/libssp/.libs/libssp.so.0.0.0
./alphapca56-alpha-linux-gnu/libssp/.libs/libssp.so.0


-- 

diskman at kc dot rr dot com changed:

   What|Removed |Added

 CC||diskman at kc dot rr dot com


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

[Bug c++/26577] New: [4.0/4.1/4.2 regression] ICE in cp_expr_size with volatile

2006-03-06 Thread reichelt at gcc dot gnu dot org

As reported here:

  http://gcc.gnu.org/ml/gcc-bugs/2006-03/msg00589.html

Confirmed. Fails since GCC 4.0.0.

However, this has nothing to do with templates or inline asm as the
reduced testcase shows:

==
struct A
{
A(const A);
A operator=(const A);
static void bar();
void foo() volatile {}
void baz() volatile;
};

void A::baz() volatile
{
foo();
bar();
}
==


-- 
   Summary: [4.0/4.1/4.2 regression] ICE in cp_expr_size with
volatile
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, monitored
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


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

[Bug c++/26577] [4.0/4.1/4.2 regression] ICE in cp_expr_size with volatile

2006-03-06 Thread reichelt at gcc dot gnu dot org



-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2006-03-06 08:06:57
   date||


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

[Bug c++/26577] [4.0/4.1/4.2 regression] ICE in cp_expr_size with volatile

2006-03-06 Thread reichelt at gcc dot gnu dot org



-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.0.3


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

[Bug libgcj/26574] libjava configration error

2006-03-06 Thread shanwill44 at yahoo dot com



--- Comment #3 from shanwill44 at yahoo dot com  2006-03-06 08:36 ---
(In reply to comment #1)
Thank you for your support. After setting CONFIG_SHELL to
/bin/ksh, the compilation was successful. I am sorry that
I did not noticed the existence of the Solaris specific
documentation, because the compilation had been almost straight-forward.


-- 

shanwill44 at yahoo dot com changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID


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

[Bug bootstrap/26578] New: nothing appenning at the end of my make bootstrap

2006-03-06 Thread mpoirier at laas dot fr

the make bootstrap finish with a Error but no precise thing to do
or to operate on  it's look

make[2]: *** No rule to make target `all'.  Stop.
make[1]: *** [all-subdir] Error 2
make: *** [all-libiberty] Error 2

don't know what to do ...

I tryed make install BUT
it failed on  :

gcc: makeUser.c: No such file or directory
gcc: no input files
make[1]: *** [makeUser.o] Error 1
make: *** [install-gcc] Error 2


-- 
   Summary: nothing appenning at the end of my make bootstrap
   Product: gcc
   Version: 2.95.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mpoirier at laas dot fr
  GCC host triplet: powerpc-*-darwin


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

[Bug middle-end/26561] [4.2 Regression] ACATS failures c34004a, c46033a and cxg2024 at -O0

2006-03-06 Thread ebotcazou at gcc dot gnu dot org



--- Comment #4 from ebotcazou at gcc dot gnu dot org  2006-03-06 09:14 
---
In Roger's court now.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 CC|roger at eyesopen dot com   |
 AssignedTo|ebotcazou at gcc dot gnu dot|sayle at gcc dot gnu dot org
   |org |


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

[Bug bootstrap/26578] nothing appenning at the end of my make bootstrap



--- Comment #1 from rguenth at gcc dot gnu dot org  2006-03-06 10:26 ---
First, 2.95.2 is waay outdated, second, you don't provide any information
on how you configured gcc.


-- 


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

[Bug c++/26577] [4.0/4.1/4.2 regression] ICE in cp_expr_size with volatile



--- Comment #1 from rguenth at gcc dot gnu dot org  2006-03-06 10:39 ---
  gcc_assert (!TYPE_HAS_COMPLEX_INIT_REF (type)
  || !TYPE_HAS_COMPLEX_ASSIGN_REF (type)
  /* But storing a CONSTRUCTOR isn't a copy.  */
  || TREE_CODE (exp) == CONSTRUCTOR
  /* And, the gimplifier will sometimes make a copy of
 an aggregate.  In particular, for a case like:

struct S { S(); };
struct X { int a; S s; };
X x = { 0 };

 the gimplifier will create a temporary with
 static storage duration, perform static
 initialization of the temporary, and then copy
 the result.  Since the s subobject is never
 constructed, this is a valid transformation.  */
  || CP_AGGREGATE_TYPE_P (type));

(gdb) call debug_tree(0x40247958)
 record_type 0x40247958 A addressable volatile needs-constructing type_1
type_5 BLK
size integer_cst 0x4018d1e0 type integer_type 0x4019e05c bit_size_type
constant invariant 8
unit size integer_cst 0x4018d1f8 type integer_type 0x4019e000 unsigned
int constant invariant 1
align 8 symtab 0 alias set -1
fields type_decl 0x402149c0 A
type record_type 0x40247450 A addressable needs-constructing type_1
type_5 BLK size integer_cst 0x4018d1e0 8 unit size integer_cst 0x4018d1f8 1
align 8 symtab 0 alias set -1 fields type_decl 0x402149c0 A
   needs-constructor X(constX) this=(X) n_parents=0 use_template=0
interface-unknown
pointer_to_this pointer_type 0x4024761c reference_to_this
reference_type 0x402476d4 chain type_decl 0x40214958 A
nonlocal decl_4 VOID file /tmp/t.C line 2
align 1 context record_type 0x40247450 A
   
   needs-constructor X(constX) this=(X) n_parents=0 use_template=0
interface-unknown
pointer_to_this pointer_type 0x40247a10

(gdb) call debug_tree(exp)
 indirect_ref 0x4020eb00
...
arg 0 parm_decl 0x40196c30 this
type pointer_type 0x40247a6c type record_type 0x40247958 A
readonly unsigned SI
size integer_cst 0x4018d3d8 constant invariant 32
unit size integer_cst 0x4018d168 constant invariant 4
align 32 symtab 0 alias set -1
readonly used unsigned SI file /tmp/t.C line 10 size integer_cst
0x4018d3d8 32 unit size integer_cst 0x4018d168 4
align 32 context function_decl 0x40245d80 baz initial pointer_type
0x40247a6c
(mem/f/c/i:SI (reg/f:SI 53 virtual-incoming-args) [0 this+0 S4 A32])
arg-type pointer_type 0x40247a6c
incoming-rtl (mem/f/c/i:SI (reg/f:SI 53 virtual-incoming-args) [0
this+0 S4 A32])

The last conditional should probably apply here:

  CP_AGGREGATE_TYPE_P (type)

but it doesn't due to CLASSTYPE_NON_AGGREGATE (TYPE)


-- 


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

[Bug middle-end/26565] Unaligned accesses with attribute(packed) and memcpy



--- Comment #3 from rguenth at gcc dot gnu dot org  2006-03-06 10:58 ---
We indeed lose alignment information of outdata-tv.  We start expanding

 memcpy (outdataD.1529-tvD.1528, tpD.1530, 4) [tail call]

with

(gdb) print dest_align
$1 = 32

so, builtins.c:get_pointer_alignment returns wrong (non conservative) results.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2006-03-06 10:58:47
   date||


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

[Bug bootstrap/26578] nothing appenning at the end of my make bootstrap

2006-03-06 Thread mpoirier at laas dot fr



--- Comment #2 from mpoirier at laas dot fr  2006-03-06 11:09 ---
Of course I know that gcc 2.95 is out  but I need it for some prog that
only compil on gcc 2.95

I used the folloowing command to configure :
../gcc2/configure --program-suffix=-2.95 --enable-shared --enable-threads
--host=powerpc-*-darwin --enable-haifa --with-gnu-as --with-gnu-ld --with-stabs
--with-cpu=powerpc

Created Makefile in /Users/Shamok/Travail/gcc2bin using mh-frag and
mt-frag
./config.status is unchanged
Configuring libiberty...
loading cache ../config.cache
checking host system type... powerpc-*-darwin
checking build system type... powerpc-*-darwin
checking for ar... (cached) ar
checking for ranlib... (cached) ranlib
checking for gcc... (cached) gcc
checking whether we are using GNU C... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for POSIXized ISC... no
checking for a BSD compatible install... (cached) /usr/bin/install -c
Appending ../../gcc2/libiberty/config/../../config/mh-ppcpic to xhost-mkfrag
xhost-mkfrag is unchanged
checking how to run the C preprocessor... (cached) gcc -E
checking for sys/file.h... (cached) yes
checking for sys/param.h... (cached) yes
checking for stdlib.h... (cached) yes
checking for string.h... (cached) yes
checking for unistd.h... (cached) yes
checking for strings.h... (cached) yes
checking for sys/time.h... (cached) yes
checking for sys/resource.h... (cached) yes
checking for sys/wait.h that is POSIX.1 compatible... (cached) yes
checking whether the C compiler (gcc -g -O2 ) works... yes
checking whether the C compiler (gcc -g -O2 ) is a cross-compiler... no
checking for asprintf... (cached) yes
checking for atexit... (cached) yes
checking for basename... (cached) yes
checking for bcmp... (cached) yes
checking for bcopy... (cached) yes
checking for bzero... (cached) yes
checking for calloc... (cached) yes
checking for clock... (cached) yes
checking for getcwd... (cached) yes
checking for getpagesize... (cached) yes
checking for index... (cached) yes
checking for insque... (cached) yes
checking for memchr... (cached) yes
checking for memcmp... (cached) yes
checking for memcpy... (cached) yes
checking for memmove... (cached) yes
checking for memset... (cached) yes
checking for mkstemps... (cached) yes
checking for putenv... (cached) yes
checking for random... (cached) yes
checking for rename... (cached) yes
checking for rindex... (cached) yes
checking for setenv... (cached) yes
checking for sigsetmask... (cached) yes
checking for strcasecmp... (cached) yes
checking for strchr... (cached) yes
checking for strdup... (cached) yes
checking for strncasecmp... (cached) yes
checking for strrchr... (cached) yes
checking for strstr... (cached) yes
checking for strtod... (cached) yes
checking for strtol... (cached) yes
checking for strtoul... (cached) yes
checking for tmpnam... (cached) yes
checking for vasprintf... (cached) yes
checking for vfprintf... (cached) yes
checking for vprintf... (cached) yes
checking for vsprintf... (cached) yes
checking for waitpid... (cached) yes
checking for working alloca.h... (cached) yes
checking for alloca... (cached) yes
checking for ANSI C header files... (cached) yes
checking for pid_t... (cached) yes
checking for vfork.h... (cached) no
checking for working vfork... (cached) yes
checking for sys_errlist... (cached) yes
checking for sys_nerr... (cached) yes
checking for sys_siglist... (cached) yes
checking for getrusage... (cached) yes
checking for on_exit... (cached) no
checking for psignal... (cached) yes
checking for strerror... (cached) yes
checking for strsignal... (cached) yes
checking for sysconf... (cached) yes
checking for times... (cached) yes
checking for sbrk... (cached) yes
checking for gettimeofday... (cached) yes
creating ./config.status
creating Makefile
creating testsuite/Makefile
creating config.h
config.h is unchanged
Configuring texinfo...
loading cache ../config.cache
checking for a BSD compatible install... (cached) /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... (cached) yes
checking for working aclocal... found
checking for working autoconf... found
checking for working automake... found
checking for working autoheader... found
checking for working makeinfo... found
checking for gcc... (cached) gcc
checking whether the C compiler (gcc -g -O2 ) works... yes
checking whether the C compiler (gcc -g -O2 ) is a cross-compiler... no
checking whether we are using GNU C... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking how to run the C preprocessor... (cached) gcc -E
checking whether gcc needs -traditional... (cached) no
checking for a BSD compatible install... /usr/bin/install -c
checking for ranlib... (cached) ranlib
checking for texconfig... (cached) false
checking for POSIXized ISC... no
checking for minix/config.h... (cached) no
checking whether to enable maintainer-specific portions of Makefiles... no
checking for Cygwin32

[Bug middle-end/26565] Unaligned accesses with attribute(packed) and memcpy



--- Comment #4 from rguenth at gcc dot gnu dot org  2006-03-06 11:58 ---
I have a patch.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2006-03-06 10:58:47 |2006-03-06 11:58:08
   date||


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

[Bug fortran/26554] [gfortran] incorrect behaviour when reading a logical variable from a string

2006-03-06 Thread martin at mpa-garching dot mpg dot de



--- Comment #8 from martin at mpa-garching dot mpg dot de  2006-03-06 12:10 
---
Mainline works correctly again, thanks!
Do you plan to commit to the 4.1-branch too?


-- 


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

[Bug middle-end/26565] [4.1/4.2 Regression] Unaligned accesses with attribute(packed) and memcpy



--- Comment #5 from rguenth at gcc dot gnu dot org  2006-03-06 12:17 ---
Works with 3.3.3, 3.4.2, fails with 4.1.0 and 4.2.0 (didn't check 4.0.x, but I
guess it's another tree-ssa fallout)


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail||4.1.0 4.2.0
  Known to work||3.3.3 3.4.2
Summary|Unaligned accesses with |[4.1/4.2 Regression]
   |__attribute__(packed) and   |Unaligned accesses with
   |memcpy  |__attribute__(packed) and
   ||memcpy


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

[Bug middle-end/26565] [4.1/4.2 Regression] Unaligned accesses with attribute(packed) and memcpy



--- Comment #6 from rguenth at gcc dot gnu dot org  2006-03-06 12:23 ---
It also affects ia64 and s390(x)


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  GCC build triplet|alphaev68-linux-gnu |
   GCC host triplet|alphaev68-linux-gnu |
 GCC target triplet|alphaev68-linux-gnu |alphaev68-linux-gnu, ia64-*-
   ||*, s390-*-*, s390x-*-*


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

[Bug bootstrap/26578] nothing appenning at the end of my make bootstrap



--- Comment #3 from pinskia at gcc dot gnu dot org  2006-03-06 12:31 ---
2.9.5.2 did not have support for Darwin as either the host or the target.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX


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

[Bug c++/26577] [4.0/4.1/4.2 regression] ICE in cp_expr_size with volatile and call to static



--- Comment #2 from pinskia at gcc dot gnu dot org  2006-03-06 12:42 ---
Reduced testcase which shows the real issue:
struct A
{
A(const A);
A operator=(const A);
static void bar();
void baz() volatile;
};
void A::baz() volatile
{
bar();
}


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.0/4.1/4.2 regression] ICE|[4.0/4.1/4.2 regression] ICE
   |in cp_expr_size with|in cp_expr_size with
   |volatile|volatile and call to static


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

[Bug c++/26577] [4.0/4.1/4.2 regression] ICE in cp_expr_size with volatile and call to static



--- Comment #3 from pinskia at gcc dot gnu dot org  2006-03-06 12:45 ---
Related to PR 23167.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn||23167


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

[Bug bootstrap/26578] nothing appenning at the end of my make bootstrap

2006-03-06 Thread mpoirier at laas dot fr



--- Comment #4 from mpoirier at laas dot fr  2006-03-06 12:45 ---
and 2.95.3 ??

which one was on panther or Xcode 1 and 1.5

else thanx for the info


-- 


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

[Bug c++/26577] [4.0/4.1/4.2 regression] ICE in cp_expr_size with volatile and call to static



--- Comment #4 from pinskia at gcc dot gnu dot org  2006-03-06 12:47 ---
(In reply to comment #3)
 Related to PR 23167.
One more comment about this, the fix for that PR moved the ICE from
create_tmp_var to cp_expr_size.


-- 


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

[Bug bootstrap/26578] nothing appenning at the end of my make bootstrap



--- Comment #5 from pinskia at gcc dot gnu dot org  2006-03-06 12:48 ---
(In reply to comment #4)
 and 2.95.3 ??

All FSF 2.95.x did not have support for Darwin.  The 2.95.3 you were referring
to came modified to you from Apple.


-- 


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

[Bug middle-end/26565] [4.1/4.2 Regression] Unaligned accesses with attribute(packed) and memcpy



--- Comment #7 from rguenth at gcc dot gnu dot org  2006-03-06 12:49 ---
A workaround is to do

  memcpy ((char*)outdata + 1, ...);


-- 


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

[Bug fortran/16136] Conflicting attributes ALLOCATABLE, DUMMY (F2003)

2006-03-06 Thread eedelman at gcc dot gnu dot org



--- Comment #5 from eedelman at gcc dot gnu dot org  2006-03-06 12:52 
---
Works on mainline (will become 4.2).  Will (probably) not be backported to 4.1.


-- 

eedelman at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/26573] [4.0/4.1/4.2 regression] Duplicate message for static member in local class



--- Comment #1 from pinskia at gcc dot gnu dot org  2006-03-06 13:02 ---
Confirmed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  Known to fail||3.2.3 3.3.3 3.4.0 4.0.0
   ||4.1.0 4.2.0 3.2.2
  Known to work||3.0.4
   Last reconfirmed|-00-00 00:00:00 |2006-03-06 13:02:59
   date||
   Target Milestone|--- |4.0.4


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

[Bug c++/26571] [4.0/4.1/4.2 regression] Bad diagnostic using type modifier with struct



--- Comment #1 from pinskia at gcc dot gnu dot org  2006-03-06 13:05 ---
Confirmed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  Known to fail||3.4.0 4.0.0 4.1.0 4.2.0
  Known to work||3.3.3
   Last reconfirmed|-00-00 00:00:00 |2006-03-06 13:05:49
   date||
   Target Milestone|--- |4.0.3


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

[Bug c++/26572] Invalid local class definition not diagnosed



--- Comment #1 from pinskia at gcc dot gnu dot org  2006-03-06 13:06 ---
Confirmed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  Known to fail||2.95.3 3.2.3 3.3.2 3.3.3
   ||3.4.0 3.0.4 4.0.0
   Last reconfirmed|-00-00 00:00:00 |2006-03-06 13:06:50
   date||


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

[Bug target/26532] libmudflap failures on ia64

2006-03-06 Thread pcarlini at suse dot de



--- Comment #8 from pcarlini at suse dot de  2006-03-06 13:17 ---
Working on it.


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pcarlini at suse dot de
   |dot org |
 Status|WAITING |ASSIGNED


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

[Bug middle-end/26565] [4.0/4.1/4.2 Regression] Unaligned accesses with attribute(packed) and memcpy

2006-03-06 Thread bernard at brenda-arkle dot demon dot co dot uk



-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
 GCC target triplet|alphaev68-linux-gnu, ia64-*-|STRICT_ALIGNMENT
   |*, s390-*-*, s390x-*-*  |
Summary|[4.1/4.2 Regression]|[4.0/4.1/4.2 Regression]
   |Unaligned accesses with |Unaligned accesses with
   |__attribute__(packed) and   |__attribute__(packed) and
   |memcpy  |memcpy
   Target Milestone|--- |4.0.4


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

[Bug fortran/26554] [gfortran] incorrect behaviour when reading a logical variable from a string

2006-03-06 Thread martin at mpa-garching dot mpg dot de



--- Comment #9 from martin at mpa-garching dot mpg dot de  2006-03-06 13:22 
---
I just noticed another (probably related) problem:

The following Fortran code is derived from some autoconf test:

  PROGRAM TESTRECL
  IMPLICIT NONE

  OPEN(UNIT = 10,FILE = 'conftest.rcl1', FORM = 'UNFORMATTED',
 :  ACCESS = 'DIRECT', RECL = 1, ERR = 101)

 WRITE(UNIT=10,REC=1,ERR=101) 1d0
 PRINT *,OK
 STOP

 101 PRINT *,error

 CLOSE(UNIT=10, STATUS='DELETE')
  END


[EMAIL PROTECTED]:~/tmp gfortran -v conf.f
Driving: gfortran -v conf.f -lgfortranbegin -lgfortran -lm -shared-libgcc
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /home/martin/software/gcc/configure --disable-multilib
--with-gmp=/home/martin/software/mygmp --with-mpfr=/home/martin/software/mympfr
--prefix=/home/martin/software/ugcc --enable-languages=c++,fortran
--enable-checking=release
Thread model: posix
gcc version 4.2.0 20060306 (experimental)
 /home/martin/software/ugcc/libexec/gcc/x86_64-unknown-linux-gnu/4.2.0/f951
conf.f -ffixed-form -quiet -dumpbase conf.f -mtune=generic -auxbase conf
-version -I
/home/martin/software/ugcc/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/finclude -o
/tmp/ccS0dlhV.s
GNU F95 version 4.2.0 20060306 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.2.0 20060306 (experimental).
GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128005
 as -V -Qy -o /tmp/cciwdHBI.o /tmp/ccS0dlhV.s
GNU assembler version 2.16.91.0.2 (x86_64-suse-linux) using BFD version
2.16.91.0.2 20050720 (SuSE Linux)
 /home/martin/software/ugcc/libexec/gcc/x86_64-unknown-linux-gnu/4.2.0/collect2
--eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2
/usr/lib/../lib64/crt1.o /usr/lib/../lib64/crti.o
/home/martin/software/ugcc/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/crtbegin.o
-L/home/martin/software/ugcc/lib/gcc/x86_64-unknown-linux-gnu/4.2.0
-L/home/martin/software/ugcc/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/../../../../lib64
-L/lib/../lib64 -L/usr/lib/../lib64
-L/home/martin/software/ugcc/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/../../..
/tmp/cciwdHBI.o -lgfortranbegin -lgfortran -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
/home/martin/software/ugcc/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/crtend.o
/usr/lib/../lib64/crtn.o
[EMAIL PROTECTED]:~/tmp ./a.out
At line 7 of file conf.f
Fortran runtime error: End of record


-- 


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

[Bug c/26581] New: incomplete (unsized) static array types cannot be completed

If this is (as I am fairly sure) a bug, then it will
surely be a bug in the C front end, and as such be
architecture-independent.

The behaviour here complained of is peculiar to -pedantic,
which chucks an error for what I believe is correct code.
It's not even a warning otherwise, and I think rightly.
The behaviour is seen in gcc-4.0.2 and gcc-4.1, an
may well be older, as I have only recently started to use
-pedantic by default.

BS ISO/IEC 9899:1999 6.2.5 para.22 (first two sentences)
An array type of unknown size is an incomplete type.  It is completed, for an
identifier of
that type, by specifying the size in a later declaration (with internal or
external linkage).

There's a great deal of murk in the Standard, some of which is relevant, but
in this cases at least, m'lud, the law is clear.  Just as one may have

extern int thingy1[];
extern int thingy1[1];

one may have (with file scope, not block scope)

static int thingy2[];
static int thingy2[1];

gcc is happy with the 'extern' version, but not with the 'static' ones:
it gags, claiming that the first declaration is bad (array size missing)
and the second is inconsistent with it (conflicting types).
Perhaps the much stricter rules for block-scope declarations confused
the implementers?  Specifically, objects other than function parameters
declared in a block which are not explicitly given the storage-class
'extern' have no linkage  (Standard 6.2.2 para. 6), and an object with
no linkage may not have an incomplete type declaration (6.7 para. 7).
The reason for this restriction escapes me (why on earth not allow
deferred type completion here too?).

This is not the end of the story, but I'm steering clear of the
full horrors of 'extern' in this particular bug report.

I have not found a comparable problem with other incomplete types
(pointers to incompletely defined struct types, c.), irrespective
of linkage.

Bernard Leak
--
What's wrong with a recursive dmalloc, anyway?


-- 
   Summary: incomplete (unsized) static array types cannot be
completed
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bernard at brenda-arkle dot demon dot co dot uk
 GCC build triplet: (same)
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: (same)


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

[Bug c/26581] incomplete (unsized) static array types cannot be completed



--- Comment #1 from pinskia at gcc dot gnu dot org  2006-03-06 13:53 ---
Comeau C front-end also rejects this code:
Comeau C/C++ 4.3.3 (Aug  6 2003 15:13:37) for ONLINE_EVALUATION_BETA1
Copyright 1988-2003 Comeau Computing.  All rights reserved.
MODE:strict errors C99 

ComeauTest.c, line 1: error: incomplete type is not allowed
  static int thingy2[];
 ^

http://www.comeaucomputing.com/tryitout/


-- 


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

[Bug libfortran/26499] gfortran - End of File incorrectly positioned after binary I/O.

2006-03-06 Thread dir at lanl dot gov



--- Comment #12 from dir at lanl dot gov  2006-03-06 14:06 ---
It works great on the Macintosh. Now, if someone could just get the windows
version of gfortran under MinGW to pass these I/O tests, it might become
usuable. My programs compile under MinGW, but they all crash when I try to run
them - mostly with I/O problems.


-- 


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

[Bug c/26581] incomplete (unsized) static array types cannot be completed



--- Comment #2 from pinskia at gcc dot gnu dot org  2006-03-06 14:06 ---
Not a bug:
From C99, 6.9.2/3 says:
If the declaration of an identifier for an object is a tentative definition and
has internal 
linkage, the declared type shall not be an incomplete type. 
--
This is a tentative definition and is internal linkage and in this case the
type incomplete so it is invalid code which is correctly rejected.


-- 

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

[Bug c/26581] incomplete (unsized) static array types cannot be completed

2006-03-06 Thread joseph at codesourcery dot com



--- Comment #3 from joseph at codesourcery dot com  2006-03-06 14:10 ---
Subject: Re:   New: incomplete (unsized) static array types
 cannot be completed

On Mon, 6 Mar 2006, bernard at brenda-arkle dot demon dot co dot uk wrote:

 static int thingy2[];
 static int thingy2[1];

This contradicts 6.9.2 paragraph 3: If the declaration of an identifier 
for an object is a tentative definition and has internal linkage, the 
declared type shall not be an incomplete type..  (Undefined behavior 
since it's not in a Constraints section, so diagnostic not required, but 
as a quality of implementation matter it should be diagnosed at least with 
-pedantic.)


-- 


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

[Bug target/26505] Storing float to int into two different pointers requires stack space



--- Comment #2 from pinskia at gcc dot gnu dot org  2006-03-06 14:20 ---
Confirmed.  Also happens on x86 too.


-- 

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 |2006-03-06 14:20:02
   date||


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

[Bug fortran/26554] [gfortran] incorrect behaviour when reading a logical variable from a string

2006-03-06 Thread jvdelisle at gcc dot gnu dot org



--- Comment #10 from jvdelisle at gcc dot gnu dot org  2006-03-06 14:22 
---
On Comment #8:  Yes I will be committing the logical patch to 4.1 branch soon.

On Comment #9:  This is not really a bug depending on how one interprets the
f95 standard.  The three error families, EOR, END, and ERR are each treated
separately.  EOR and END are not considered the same as ERR.  This is probably
processor dependant behavior.  Regardless, it is PR26509 which we are still
evaluating.


-- 


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

[Bug middle-end/26561] [4.2 Regression] ACATS failures c34004a, c46033a and cxg2024 at -O0



--- Comment #5 from pinskia at gcc dot gnu dot org  2006-03-06 14:26 ---
Just for future reference, here is the C testcase that Eric B. posted to the
list:
/* PR middle-end/26561 */

extern void abort(void);

int always_one_1 (int a)
{
  if (a/100 = -9)
return 1;
  else
return 0;
}

int always_one_2 (int a)
{
  if (a/100  -9)
return 0;
  else
return 1;
}

int main(void)
{
  if (always_one_1 (0) != 1)
abort ();

  if (always_one_2 (0) != 1)
abort ();

  return 0;
}


-- 


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

[Bug tree-optimization/18754] unrolling happens too late/SRA does not happen late enough



--- Comment #16 from rguenth at gcc dot gnu dot org  2006-03-06 14:30 
---
Or with a pass recovering loops before vectorization.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

OtherBugsDependingO||22501
  nThis||


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

[Bug bootstrap/26582] New: [4.2 Regression] warning with cross build

2006-03-06 Thread paolo dot bonzini at lu dot unisi dot ch

I get the following warnings when doing a cross (any kind of cross really)
Makefile:13366: warning: overriding commands for target `restrap'
Makefile:12658: warning: ignoring old commands for target `restrap'


-- 
   Summary: [4.2 Regression] warning with cross build
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org


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

[Bug fortran/26509] incorrect behaviour of error-handler for internal read

2006-03-06 Thread martin at mpa-garching dot mpg dot de



--- Comment #7 from martin at mpa-garching dot mpg dot de  2006-03-06 14:33 
---
When trying to compile the Starlink sources with gfortran I stumbled across
this too. Unfortunately it seems that one of their autoconf tests called
AC_FC_RECL_UNIT relies on the jump to the ERR label when EOR occurs. If you
decide that gfortran is currently doing the right thing, I'll ask them to fix
the test.


-- 

martin at mpa-garching dot mpg dot de changed:

   What|Removed |Added

 CC||martin at mpa-garching dot
   ||mpg dot de


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

[Bug bootstrap/26582] [4.2 Regression] warning with cross build



--- Comment #1 from paolo dot bonzini at lu dot unisi dot ch  2006-03-06 
14:35 ---
Subject: Re:   New: [4.2 Regression] warning with cross
 build

pinskia at gcc dot gnu dot org wrote:
 I get the following warnings when doing a cross (any kind of cross really)
 Makefile:13366: warning: overriding commands for target `restrap'
 Makefile:12658: warning: ignoring old commands for target `restrap'
   
I was aware of this, did nothing so far because Dan Jacobowitz said he 
would rip old bootstrap bits soon (including this one).

Paolo


-- 


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

[Bug bootstrap/26582] [4.2 Regression] warning with cross build

2006-03-06 Thread pinskia at physics dot uc dot edu



--- Comment #2 from pinskia at gcc dot gnu dot org  2006-03-06 14:37 ---
Subject: Re:  [4.2 Regression] warning with cross build

 
 
 
 --- Comment #1 from paolo dot bonzini at lu dot unisi dot ch  2006-03-06 
 14:35 ---
 Subject: Re:   New: [4.2 Regression] warning with cross
  build
 
 pinskia at gcc dot gnu dot org wrote:
  I get the following warnings when doing a cross (any kind of cross really)
  Makefile:13366: warning: overriding commands for target `restrap'
  Makefile:12658: warning: ignoring old commands for target `restrap'

 I was aware of this, did nothing so far because Dan Jacobowitz said he 
 would rip old bootstrap bits soon (including this one).

I should note that I filed this because I was tried of seeing the warning
when I built the compiler.

-- Pinski


-- 


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

[Bug tree-optimization/13761] [tree-ssa] component refs to the same struct should not alias



--- Comment #15 from rguenth at gcc dot gnu dot org  2006-03-06 14:39 
---
The problem for the original testcase is that we don't even try to build SFTs
required for structure aliasing analysis for incoming pointers:

foo0 (f)
{
  int D.1529;

bb 2:
  #   SMT.4_4 = V_MAY_DEF SMT.4_3;
  f_1-s = 1;
  #   SMT.4_5 = V_MAY_DEF SMT.4_4;
  f_1-s2 = 2;

which is required to turn these into V_MUST_DEFs.  Of course we still can do
propagation of the values in ccp or copyprop if we walk the virtual use-def
chains there and disabmiguate the offsets.


-- 


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

[Bug fortran/26554] [gfortran] incorrect behaviour when reading a logical variable from a string

2006-03-06 Thread martin at mpa-garching dot mpg dot de



--- Comment #11 from martin at mpa-garching dot mpg dot de  2006-03-06 
14:41 ---
 On Comment #9:  This is not really a bug depending on how one interprets the
 f95 standard.  The three error families, EOR, END, and ERR are each treated
 separately.  EOR and END are not considered the same as ERR.

I see. But in a WRITE statement, EOR and END must not be specified; how should
I try to catch the error condition then?


-- 


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

[Bug c++/13954] [tree-ssa] SRA does not work for classes that use inheritance with an empty base



--- Comment #12 from rguenth at gcc dot gnu dot org  2006-03-06 14:41 
---
In principle this blocks optimization of tramp3d domain operations (if it were
not structure-aliasing fixing most of the problems).


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

OtherBugsDependingO||22501
  nThis||


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

[Bug middle-end/26565] [4.0/4.1/4.2 Regression] Unaligned accesses with attribute(packed) and memcpy



--- Comment #8 from patchapp at dberlin dot org  2006-03-06 14:55 ---
Subject: Bug number PR middle-end/26565

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00324.html


-- 


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

[Bug rtl-optimization/25569] [4.2 Regression] FAIL: gfortran.dg/g77/20010610.f -O3 -fomit-frame-pointer -funroll-loops



--- Comment #3 from pinskia at gcc dot gnu dot org  2006-03-06 15:00 ---
(In reply to comment #1)
 (gdb) p debug_rtx (insn)
 (insn 41 39 42 5 (set (reg:DI 71 [ D.775 ])
 (zero_extend:DI (subreg:QI (reg/v:DI 70 [ i ]) 7))) 129 {*pa.md:4636}
 (nil)
 (nil))
 $9 = void

This is a similar instruction which effects ppc64 also.  It also fails the same
way on powerpc64-darwin.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 GCC target triplet|hppa64-hp-hpux11.11,|hppa64-hp-hpux11.11,
   |powerpc64-linux |powerpc64-*-*


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

[Bug bootstrap/18058] [4.2 Regression] Sun CC cannot bootstrap GCC (static inline)



--- Comment #28 from patchapp at dberlin dot org  2006-03-06 15:07 ---
Subject: Bug number PR bootstrap/18058

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00297.html


-- 


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

[Bug bootstrap/26582] [4.2 Regression] warning with cross build



-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.2.0


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

[Bug tree-optimization/26447] [4.2 Regression] verify_flow_info failed, load PRE



--- Comment #11 from pinskia at gcc dot gnu dot org  2006-03-06 15:24 
---
I might look into fix this later this week,  the problem is the creating of
loads which could cause an trap/exception but not putting them into different
BB's.


-- 


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

[Bug testsuite/26344] [4.2 Regression] three testsuite failures in gcc.dg/tree-ssa/



--- Comment #8 from pinskia at gcc dot gnu dot org  2006-03-06 15:29 ---
Any news on these three testsuite failures?  It is getting annoying to have
testsuite regressions.


-- 


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

[Bug bootstrap/26500] [4.2 Regression] info/gfortran.info is no longer being installed



--- Comment #3 from patchapp at dberlin dot org  2006-03-06 15:30 ---
Subject: Bug number PR bootstrap/26500

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00124.html


-- 


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

[Bug testsuite/26344] [4.2 Regression] three testsuite failures in gcc.dg/tree-ssa/

2006-03-06 Thread law at redhat dot com



--- Comment #9 from law at redhat dot com  2006-03-06 15:35 ---
Subject: Re:  [4.2 Regression] three testsuite
failures in gcc.dg/tree-ssa/

On Mon, 2006-03-06 at 15:29 +, pinskia at gcc dot gnu dot org wrote:
 
 --- Comment #8 from pinskia at gcc dot gnu dot org  2006-03-06 15:29 
 ---
 Any news on these three testsuite failures?  It is getting annoying to have
 testsuite regressions.
As I've mentioned at least 3 times now, the Ada mis-compilations
have priority.  I'm working on these between fixing Ada issues.

When there's status worth mentioning, I'll certainly add the
status to his PR.  Until then, bugging me about it isn't
helping.

jeff


-- 


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

[Bug rtl-optimization/25569] [4.2 Regression] FAIL: gfortran.dg/g77/20010610.f -O3 -fomit-frame-pointer -funroll-loops



--- Comment #4 from pinskia at gcc dot gnu dot org  2006-03-06 15:49 ---
Janis could you do a regression hunt on what caused this testcase to start to
fail?
The C testcase is:
int f(void)
{
  int i;
  for(i=0;i256;i++)
  {
char a = i;
int ii = a;
if (ii != i)  __builtin_abort();
  }
}


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||janis at gcc dot gnu dot org


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

[Bug libstdc++/26526] [4.1/4.2 Regression] std::__copy_streambufs link failure when _GLIBCXX_DEBUG is defined

2006-03-06 Thread bkoz at gcc dot gnu dot org



--- Comment #7 from bkoz at gcc dot gnu dot org  2006-03-06 16:10 ---

Paolo, versioning bits look fine. 

lm

cw

ij

are the usual rules you need to keep in mind for this stuff

but fixing this is not a big deal.

-benjamin


-- 


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

[Bug libgcj/26483] Wrong parsing of doubles when interpreted on ia64

2006-03-06 Thread tromey at gcc dot gnu dot org



--- Comment #9 from tromey at gcc dot gnu dot org  2006-03-06 17:08 ---
You can read about the java programming language's requirements
for floating point here:

http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3

Relevant quote:

  In particular, the Java programming language requires support of IEEE 754
  denormalized floating-point numbers and gradual underflow


-- 

tromey at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||tromey at gcc dot gnu dot
   ||org


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

[Bug testsuite/26344] [4.2 Regression] three testsuite failures in gcc.dg/tree-ssa/



--- Comment #10 from pinskia at gcc dot gnu dot org  2006-03-06 17:10 
---
(In reply to comment #9)
 As I've mentioned at least 3 times now, the Ada mis-compilations
 have priority.  I'm working on these between fixing Ada issues.
 When there's status worth mentioning, I'll certainly add the
 status to his PR.  Until then, bugging me about it isn't
 helping.

These are older regressions than the Ada regressions and they show up as
testsuite failures and also it has been 3 weeks since this has been reported
enough time to fix them, yes it might be a minor regression to you but it is an
annoying regression to the people who are testing their patches as they see the
fails and think it was their patch (this has already happened with these
testsuite failures already, see PR 26406).


-- 


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

[Bug testsuite/26344] [4.2 Regression] three testsuite failures in gcc.dg/tree-ssa/

2006-03-06 Thread law at redhat dot com



--- Comment #11 from law at redhat dot com  2006-03-06 17:21 ---
Subject: Re:  [4.2 Regression] three testsuite
failures in gcc.dg/tree-ssa/

On Mon, 2006-03-06 at 17:10 +, pinskia at gcc dot gnu dot org wrote:
 
 --- Comment #10 from pinskia at gcc dot gnu dot org  2006-03-06 17:10 
 ---
 (In reply to comment #9)
  As I've mentioned at least 3 times now, the Ada mis-compilations
  have priority.  I'm working on these between fixing Ada issues.
  When there's status worth mentioning, I'll certainly add the
  status to his PR.  Until then, bugging me about it isn't
  helping.
 
 These are older regressions than the Ada regressions and they show up as
 testsuite failures and also it has been 3 weeks since this has been reported
 enough time to fix them, yes it might be a minor regression to you but it is 
 an
 annoying regression to the people who are testing their patches as they see 
 the
 fails and think it was their patch (this has already happened with these
 testsuite failures already, see PR 26406).
They are minor performance related regressions.  The Ada
regresions are incorrect code.  The Ada regressions have priority.

You're not helping here.  As I've said before, be patient.  The
problems will be addressed.  The more you bug me the longer this
process takes.  When there's something worth reporting, I'll
report it.

Jeff


-- 


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

[Bug c++/6634] wrong parsing of long long double

2006-03-06 Thread bernard at brenda-arkle dot demon dot co dot uk



--- Comment #8 from patchapp at dberlin dot org  2006-03-06 17:45 ---
Subject: Bug number PR c++/6634

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00334.html


-- 


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

[Bug target/26532] libmudflap failures on ia64

2006-03-06 Thread paolo at gcc dot gnu dot org

--- Comment #9 from paolo at gcc dot gnu dot org  2006-03-06 18:06 ---
Subject: Bug 26532

Author: paolo
Date: Mon Mar  6 18:06:47 2006
New Revision: 111789

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111789
Log:
2006-03-06  Paolo Carlini  [EMAIL PROTECTED]

PR target/26532
* config/io/c_io_stdio.h (struct __ios_flags): Remove.
* include/bits/ios_base.h: Adjust consistently.
(ios_base::_S_local_word_size): Change to an anonymous enum.
* src/ios.cc: Do not define static const data of __ios_flags,
likewise for ios_base::_S_local_word_size.  
* include/bits/locale_classes.h (locale::_S_categories_size):
Change to an anonymous enum.
* src/locale.cc: Don't define.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/config/io/c_io_stdio.h
trunk/libstdc++-v3/include/bits/ios_base.h
trunk/libstdc++-v3/include/bits/locale_classes.h
trunk/libstdc++-v3/src/ios.cc
trunk/libstdc++-v3/src/locale.cc

-- 

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

[Bug target/26532] libmudflap failures on ia64

2006-03-06 Thread pcarlini at suse dot de



-- 

pcarlini at suse dot de changed:

   What|Removed |Added

   Target Milestone|--- |4.1.1


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

[Bug c/26581] incomplete (unsized) static array types cannot be completed



--- Comment #4 from bernard at brenda-arkle dot demon dot co dot uk  
2006-03-06 18:35 ---
Thanks - I'd forgotten that 'static' declarations can be 
tentative definitions too.  But now I'm even more confused!
As I wrote, unsized arrays do one thing, undefined structs do another
(this is a gcc fact whatever its ANSI-legal status).

Consider this:
struct poo; /* declares an incomplete structure type, 6.7.2.3 para. 7 */
static struct poo thingy; /* a tentative definition, 6.9.2 para. 2 */
/* The structure type is still incomplete, 6.7.2.3 para. 3 */
/* any subsequent definition of struct poo is too late */

Shouldn't this now be flagged as an error, at least if '-pedantic'
is requested?

If I'm wrong again about this, I'll shut up...

Bernard Leak
--
I remember when the Standard had fewer than 8 bits' worth of confusing pages!


-- 

bernard at brenda-arkle dot demon dot co dot uk changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug c/26581] incomplete (unsized) static array types cannot be completed

2006-03-06 Thread joseph at codesourcery dot com



--- Comment #5 from joseph at codesourcery dot com  2006-03-06 18:58 ---
Subject: Re:  incomplete (unsized) static array types cannot be
 completed

On Mon, 6 Mar 2006, bernard at brenda-arkle dot demon dot co dot uk wrote:

 struct poo; /* declares an incomplete structure type, 6.7.2.3 para. 7 */
 static struct poo thingy; /* a tentative definition, 6.9.2 para. 2 */
 /* The structure type is still incomplete, 6.7.2.3 para. 3 */
 /* any subsequent definition of struct poo is too late */
 
 Shouldn't this now be flagged as an error, at least if '-pedantic'
 is requested?

Yes.  Again, this is a quality-of-implementation issue since the 
requirement is not a Constraint.  I'm already aware of the issue that if 
the struct is subsequently defined there isn't an error here, though I 
don't think there's a bug filed (bug 24293 is related but not the same).


-- 


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

[Bug fortran/22038] Forall with mask broken

2006-03-06 Thread pault at gcc dot gnu dot org



--- Comment #6 from pault at gcc dot gnu dot org  2006-03-06 20:33 ---
This one was fixed a long time since but does not seem to have been cleared. 
The recent flurry of activity on the dependency checking has made keeping it
open unnecessary IMHO.

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug fortran/22038] Forall with mask broken

2006-03-06 Thread jakub at gcc dot gnu dot org



--- Comment #7 from jakub at gcc dot gnu dot org  2006-03-06 20:44 ---
Are you sure?  forall_8.f90 testcase still fails for me with gfortran
as of a few days ago.
If the problem is fixed and the testcases aren't invalid, they should be
added to the testsuite, otherwise this needs to be reopened.


-- 


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

[Bug fortran/20405] [meta-bug] equivalenced variable problems

2006-03-06 Thread pault at gcc dot gnu dot org



--- Comment #1 from pault at gcc dot gnu dot org  2006-03-06 20:58 ---
(In reply to comment #0)
 There are currently two equivalenced variable problems but I suspect there are
 more which is why I am 
 creating this meta-bug.
 
I believe that 24406 has fixed itself and that both can be closed.


-- 


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

[Bug fortran/24406] EQUIVALENCE broken in 32-bit code with optimization -O2



--- Comment #12 from pinskia at gcc dot gnu dot org  2006-03-06 21:03 
---
(In reply to comment #11)
  Even though the final tree dump looks correct this is a still a front-end 
  issue
  as the front-end communicates the aliasing sets to the rtl optimizers.
  I am going to take it too.
 
 I have either missed something, the PR has fixed itself or it is not a
 front-end problem. See below.

The symptom of this testcase passing might work but the bug is still there and
most likely cannot expose it at the tree level and it is semi hard to expose it
even on the RTL level.
Comment #5 shows what needs to be added to the Fortran front-end which I will
do sometime this week when I get some time (but note I have two papers to write
which is what is right now taking up my time).


-- 


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

[Bug fortran/20405] [meta-bug] equivalenced variable problems