[Bug rtl-optimization/21827] unroll misses simple elimination - works with manual unroll

[tlm at daimi dot au dot dk]

--- Additional Comments From tlm at daimi dot au dot dk  2005-05-31 05:38 
---

(In reply to comment #1)
The first testcase is fixed in 4.0.0.  (Though there is a regression on the
mainline).  I have not looked  into the full testcase.

(In reply to comment #2)
> I was not goint to close this, it was accident.

Well if it works in 4.0 I guess you can close it if you want.
I made the example from the code below to give a simple example.
I am not sure, but I guess a fix on the example would do also make the 
same huge improvement on the "chess-knight-code". 
(I wrote 400-500% - but this is of course depending on how many knights there
are on the board. I had 5 (a bit unrealistic) with the function returing 17) 

Thanks for the information ... (will download version 4.0 soon)


-- 


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

[Bug debug/21828] [4.1 Regression] stabs debug info completely broken?

[dje at gcc dot gnu dot org]

--- Additional Comments From dje at gcc dot gnu dot org  2005-05-31 04:39 
---
I see similar problems on AIX.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-05-31 04:39:15
   date||


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

[Bug other/16406] [3.4 Regression] USE_LD_AS_NEEDED undocumented

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-05-31 
04:17 ---
> Yes.  s/USE_LD_AS_NEEDED/HAVE_LD_AS_NEEDED/ will make the doc right on 3.4

Sort of.  HAVE_LD_AS_NEEDED is not a target macro per se.


-- 


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

[Bug target/19558] openssl speed compiled with 20051020 gcc-4.0 (HEAD) segfaults

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-31 
03:44 ---
(In reply to comment #17)
> See also http://marc.theaimsgroup.com/?l=openssl-dev&m=111238996923252&w=2
> which says
> 
> --- snip ---
> gcc-4 miscompiles inline assembly bn/asm/x86_64-gcc.c so that the
> functions bn_add_words and bn_sub_words are broken and segfault.

Actually the inline-asm is questionable, see PR 20718 and it is not a 
regression by the way, people just 
got lucky with older versions of GCC with that inline-asm.

-- 


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

[Bug target/19558] openssl speed compiled with 20051020 gcc-4.0 (HEAD) segfaults

[dank at kegel dot com]

--- Additional Comments From dank at kegel dot com  2005-05-31 03:41 ---
See also http://marc.theaimsgroup.com/?l=openssl-dev&m=111238996923252&w=2
which says

--- snip ---
gcc-4 miscompiles inline assembly bn/asm/x86_64-gcc.c so that the
functions bn_add_words and bn_sub_words are broken and segfault.

This applies only to the stable branch as in the devel branch there is
added initialization of the ret and i variables. However the
initialization is unnecessary instead the code should be modified this way:

@@ -164,7 +186,7 @@
"   leaq1(%2),%2\n"
"   loop1b  \n"
"   sbbq%0,%0   \n"
-   : "+a"(ret),"+c"(n),"+r"(i)
+   : "=&a"(ret),"+c"(n),"=&r"(i)
: "r"(rp),"r"(ap),"r"(bp)
: "cc"
);
@@ -187,7 +209,7 @@
"   leaq1(%2),%2\n"
"   loop1b  \n"
"   sbbq%0,%0   \n"
-   : "+a"(ret),"+c"(n),"+r"(i)
+   : "=&a"(ret),"+c"(n),"=&r"(i)
: "r"(rp),"r"(ap),"r"(bp)
: "cc"
);
--- snip ---

-- 


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

[Bug target/21834] Error when passing unsigned long long as function arguments

[ulyssesric at yahoo dot com dot tw]

--- Additional Comments From ulyssesric at yahoo dot com dot tw  2005-05-31 
03:38 ---
Sorry, typo. Compile Procedure:

avr-gcc -mmcu=atmega128 -g -Os -Wall -Wa,-adhlns=test.lst -std=gnu99 
-funsigned-char 
-funsigned-bitfields -fpack-struct -fshort-enums -ffreestanding 
-Wl,-Map=test.map -Wl,--cref  test.c 
-o test.elf
avr-objcopy -O ihex -R .eeprom test.elf test.hex
avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" 
--change-section-lma .eeprom=0 
-O ihex test.elf test.eep
avr-objdump -h -S test.elf > test.lss
avr-nm -n test.elf > test.sym


-- 


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

[Bug target/21834] Error when passing unsigned long long as function arguments

[ulyssesric at yahoo dot com dot tw]

--- Additional Comments From ulyssesric at yahoo dot com dot tw  2005-05-31 
03:35 ---
Fine, I'll list all codes if you insist:

#include 

typedef unsigned char   byte_t;
typedef unsigned long long  qword_t;

void uart_init(void)
{
// 115200 & 8N1
UBRR1H = 0x00;
UBRR1L = 0x08;
UCSR1A |= (0x01<

typedef unsigned char   byte_t;
typedef unsigned long long  qword_t;

void uart_init(void)
{
// 115200 & 8N1
UBRR1H = 0x00;
UBRR1L = 0x08;
UCSR1A |= (0x01< test.lss
avr-nm -n test.elf > test.sym

Programming with AVR Studio 4.11 build 401, JTAGICE mkII


-- 


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

[Bug target/21834] Error when passing unsigned long long as function arguments

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-31 
02:50 ---
Did you read:  because it says we don't want 
source with "...".

-- 
   What|Removed |Added

  Component|c   |target
   Keywords||wrong-code


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

[Bug target/21833] simd tests fail

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Component|c   |target
   Keywords||wrong-code


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

[Bug libfortran/19303] Unformatted record header is 4-bytes on 32-bit targets

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-31 
02:45 ---
*** Bug 21621 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||P dot Schaffnit at access
   ||dot rwth-aachen dot de


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

[Bug libfortran/21621] Inconsistency with binary sequential output

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-31 
02:45 ---


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

-- 
   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/19761] -Winit-self doesn't work anymore

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-31 
02:41 ---
No you are thinking wrong, it will be the same warning as it is uninitialized, 
the flag just turns on the 
warnings for those cases.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX


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

[Bug libfortran/19303] Unformatted record header is 4-bytes on 32-bit targets

[bdavis9659 at comcast dot net]

--- Additional Comments From bdavis9659 at comcast dot net  2005-05-31 
02:37 ---
proposed patch that should fix this problem:

http://gcc.gnu.org/ml/fortran/2005-05/msg00431.html

-- 


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

[Bug libfortran/21621] Inconsistency with binary sequential output

[bdavis9659 at comcast dot net]

--- Additional Comments From bdavis9659 at comcast dot net  2005-05-31 
02:36 ---
proposed patch here:

http://gcc.gnu.org/ml/fortran/2005-05/msg00431.html

-- 


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

[Bug c++/20350] [4.0/4.1 Regression] extern template and struct initializer and specification for a static variable

[carlo at gcc dot gnu dot org]

--- Additional Comments From carlo at gcc dot gnu dot org  2005-05-31 02:33 
---
If you remove the 'extern', the compiler still crashes:

struct a { int i, j; };
template  struct mutex_tct { static a S_mutex; };
template  a mutex_tct::S_mutex = {0,1};
template <> a mutex_tct<0>::S_mutex;
template <> a mutex_tct<0>::S_mutex = {0,1};
void g() { mutex_tct<0>::S_mutex.i = 0; }

>g++-4.0.0 -v troep.cc
Using built-in specs.
Target: i686-redhat-linux
Configured with: /usr/src/gcc/gcc-4.0.0/configure --prefix=/usr/local/gcc-4.0.0
--enable-shared --with-gnu-as --with-gnu-ld--enable-languages=c++ --enable-debug
--enable-threads=posix --disable-checking --with-system-zlib
--enable-__cxa_atexit --host=i686-redhat-linux
Thread model: posix
gcc version 4.0.0
 /usr/local/gcc-4.0.0/libexec/gcc/i686-redhat-linux/4.0.0/cc1plus -quiet -v
-D_GNU_SOURCE troep.cc -quiet -dumpbase troep.cc -mtune=pentiumpro -auxbase
troep -version -o /tmp/ccDplkLP.s
ignoring nonexistent directory
"/usr/local/gcc-4.0.0/lib/gcc/i686-redhat-linux/4.0.0/../../../../i686-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
 
/usr/local/gcc-4.0.0/lib/gcc/i686-redhat-linux/4.0.0/../../../../include/c++/4.0.0
 
/usr/local/gcc-4.0.0/lib/gcc/i686-redhat-linux/4.0.0/../../../../include/c++/4.0.0/i686-redhat-linux
 
/usr/local/gcc-4.0.0/lib/gcc/i686-redhat-linux/4.0.0/../../../../include/c++/4.0.0/backward
 /usr/local/include
 /usr/local/gcc-4.0.0/include
 /usr/local/gcc-4.0.0/lib/gcc/i686-redhat-linux/4.0.0/include
 /usr/include
End of search list.
GNU C++ version 4.0.0 (i686-redhat-linux)
compiled by GNU C version 4.0.0.
GGC heuristics: --param ggc-min-expand=90 --param ggc-min-heapsize=113235
troep.cc:5: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

-- 


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

[Bug tree-optimization/21368] VRP does not know that &s.a != NULL

[dnovillo at gcc dot gnu dot org]

--- Additional Comments From dnovillo at gcc dot gnu dot org  2005-05-31 
01:48 ---

This is caught by CCP1.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WORKSFORME


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

[Bug c++/19761] -Winit-self doesn't work anymore

[oliverst at online dot de]

--- Additional Comments From oliverst at online dot de  2005-05-31 01:29 
---
Yes, I did expect a different warning, because 

int i = i;

would be uninitialized use and self initialization.

And because of an special warnings flag I expected it to be different from the
uninitialized use warning. But if it causes the same, it should be part of
-Wuninitialized and -Winit-self would be kind of redundant then. Maybe I am just
seeing this totally wrong.

-- 


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

[Bug fastjar/21826] fastjar does not look to see if mkdir takes one or two arguments

[dannysmith at users dot sourceforge dot net]

--- Additional Comments From dannysmith at users dot sourceforge dot net  
2005-05-31 01:22 ---
The MKDIR_TAKES_ONE_ARG that is defined for mingw in auto-host.h is a host 
define.

In jartool.c (and in libgcc files - cf PR/21597) we need a target define. 
Perhap targets such as mingw should define a TARGET_MKDIR_TAKES_ONE_ARG in tm.h.

Danny


-- 


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

[Bug c/21834] New: Error when passing unsigned long long as function arguments

[ulyssesric at yahoo dot com dot tw]

I have a function that takes two usigned-long-long variables and two 
unsigned-char variables as 
argument.  Here is the sample code:

typedef unsigned char byte_t;
typedef unsigned long long qword_t;
void foo(
byte_t state,
qword_t srcAddr,
byte_t routeOptions,
qword_t dstAddr
) {
...
}
void main(void) {

foo(0x00,0x1234ll,0x01, 0x5678ll);

}

Compiled with avr-gcc 3.4.3, for Atmega 128:

avr-gcc -mmcu=atmega128 -g -Os -Wall -Wa,-adhlns=func1.o -std=gnu99 
-funsigned-char 
-funsigned-bitfields -fpack-struct -fshort-enums -ffreestanding -c func1.c -o 
func1.o

When I tried to check the values of variable srcAddr and dstAddr within foo() 
using UART, they are not 
what they should be. srcAddr is something like 0xDE001A6D,  and dstAddr 
is 
0x7856.

However, If I change the order of these arguments to :

void foo(
qword_t srcAddr,
qword_t dstAddr,
byte_t state,
byte_t routeOptions
) {
...
}

and the result would be correct.

-- 
   Summary: Error when passing unsigned long long as function
arguments
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ulyssesric at yahoo dot com dot tw
CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: X86 (Linux, Win32) and PowerPC (Darwin)
GCC target triplet: AVR, Atmega128


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

[Bug other/16406] [3.4 Regression] USE_LD_AS_NEEDED undocumented

[amodra at bigpond dot net dot au]

--- Additional Comments From amodra at bigpond dot net dot au  2005-05-30 
23:19 ---
Yes.  s/USE_LD_AS_NEEDED/HAVE_LD_AS_NEEDED/ will make the doc right on 3.4

-- 


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

[Bug middle-end/21743] Enable __builtin_clog

[giovannibajo at libero dot it]

-- 
Bug 21743 depends on bug 21784, which changed state.

Bug 21784 Summary: [3.4/4.0/4.1 Regression] Using vs builtin names
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21784

   What|Old Value   |New Value

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |

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

[Bug c++/21784] [3.4/4.0/4.1 Regression] Using vs builtin names

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2005-05-30 
22:46 ---
Reopening as a 3.4 regression.

-- 
   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |
   Target Milestone|4.0.1   |3.4.5


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

[Bug c/21833] New: simd tests fail

[tg42 at gmx dot de]

Note: AFAIKS this is NOT a problem reated to stack alignment (as in
10395) but to missing instructions.  This one IS similar to 11802 (if
not a duplicate), but if it is, that one was erroneously marked as
duplicate of 10395.

Compiling simd-1.c with -O0 -march=pentium3 and running the resulting
executable yields abort() being called and a core being thrown.

Analysing the core, the following suggests the assignment to res in
L35 being incomplete (what causes the subsequent verify() to fail):

(gdb) p k
$2 = {160, 113, 170, 230}
(gdb) p res
$3 = {v = {160, 113, 0, 0}, i = {160, 113, 0, 0}}
(gdb) x/20d &i
0x8049ae0 :  150 100 150 200
0x8049af0 :  10  13  20  30
0x8049b00 :0   0   0   0
0x8049b10 :  160 113 170 230
0x8049b20 :160 113 0   0

The following assembler code is generated:

.loc 1 34 0
movqi, %mm0
paddd   j, %mm0
movq%mm0, k
movqi+8, %mm0
paddd   j+8, %mm0
movq%mm0, k+8
.loc 1 35 0
movdqa  k, %xmm0
movdqa  %xmm0, res
.loc 1 37 0

gcc 3.3.6 generates the following code (which works):

.loc 1 34 0
movqi, %mm0
paddd   j, %mm0
movq%mm0, k
movqi+8, %mm0
paddd   j+8, %mm0
movq%mm0, k+8
.loc 1 35 0
movaps  k, %xmm0
movaps  %xmm0, res

I do not know the difference between these two instructions (movdqa
vs. movaps), but to me it seems, gcc 3.4.4 selects the wrong one.

-- 
   Summary: simd tests fail
   Product: gcc
   Version: 3.4.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tg42 at gmx dot de
CC: gcc-bugs at gcc dot gnu dot org
 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=21833

[Bug c++/21832] Linker error when taking reference of static integral data member

[bernie at develer dot com]

--- Additional Comments From bernie at develer dot com  2005-05-30 21:56 
---
(In reply to comment #1)

What a quick response!


> This is a dup of bug 14404.  I thought this was on the bug reporting web page
(maybe not), well it should be.

It's there, I just didn't see it.

> This is invalid code, see comment #1 in PR 14404 for how to fix your code.

Yeah, I'm quite astonished.


-- 


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

[Bug c++/14404] static const integral member cannot be passed as const reference

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-30 
21:48 ---
*** Bug 21832 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||bernie at develer dot com


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

[Bug c++/21832] Linker error when taking reference of static integral data member

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-30 
21:48 ---
(In reply to comment #0)
> Also happens with 3.3.5 and 4.0.0.  The test case
> is so simple I'm surprised nobody noticed before.
> Unless of course I need to take a new C++ course.

This is a dup of bug 14404.  I thought this was on the bug reporting web page 
(maybe not), well it 
should be.

This is invalid code, see comment #1 in PR 14404 for how to fix your code.

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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/21832] Linker error when taking reference of static integral data member

[bernie at develer dot com]

-- 
   What|Removed |Added

  Known to fail||4.0.0 3.3.5 3.4.3


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

[Bug c++/21832] New: Linker error when taking reference of static integral data member

[bernie at develer dot com]

Also happens with 3.3.5 and 4.0.0.  The test case
is so simple I'm surprised nobody noticed before.
Unless of course I need to take a new C++ course.

---cut---
void bar(const int &a) { }

struct Foo
{
static const int X = 10;
};

int main()
{
bar(Foo::X);
return 0;
}
---cut---

/tmp/ccYC57Zg.o(.text+0x23): In function `main':
foo.cpp: undefined reference to `Foo::X'
collect2: ld returned 1 exit status

-- 
   Summary: Linker error when taking reference of static integral
data member
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: critical
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bernie at develer dot com
CC: aleph at develer dot com,gcc-bugs at gcc dot gnu dot
org,giovannibajo at libero dot it
 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=21832

[Bug libstdc++/21830] swap_ranges must call swap instead of iter_swap

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-05-30 21:40 
---
Fixed in 4.0.0 too. Will not be fixed in 3_4-branch, sorry, not a regression.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to work||4.0.0
 Resolution||WONTFIX


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

[Bug target/19087] Overflowed address in dwarf debug line information

[bjoern dot m dot haase at web dot de]

--- Additional Comments From bjoern dot m dot haase at web dot de  
2005-05-30 21:40 ---
OK,  
 
sorry for this, but I just realized that Darcy Watkins has made a couple of 
almost exactly identical observations. Did not review all of the more recent 
comments. 
 
In case that the only remaining problem turns out to be the trailing 0x80 that 
indicate the memory space, one way to handle it could be to change the way the 
asm output is generated. I.e. there is a quite easy method for forcing gcc to 
generate 
 
   .long ((lable_referenced_within_the_dwarf_section) & 0x0001) 
 
instead of 
 
   .long lable_referenced_within_the_dwarf_section 
 
. This way, when assemling one could mask out leading bits that possibly could 
irritate avrstudio. However, IMO, the better way would be to teach avrstudio 
simply to ignore the bits that are known to be not relevant. 
 
Yours, 
 
Björn 

-- 


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

[Bug target/19087] Overflowed address in dwarf debug line information

[bjoern dot m dot haase at web dot de]

--- Additional Comments From bjoern dot m dot haase at web dot de  
2005-05-30 21:16 ---
Hi, 
 
as a step towards resolving PR19885: After looking a bit into the code of other 
ports, I found out, that switching avr-gcc to the 4-byte dwarf convention 
should not be complicated at all. It seems that the only thing to be done is 
add the lines 
 
#undef DWARF2_ADDR_SIZE 
#define DWARF2_ADDR_SIZE 4 
 
to avr.h . This is how it works for HC12, ip2k and other ports that override 
the default definition of 2 for these targets. For AVR, most probably, one 
should then expect the occurence of trailing 0x80 bytes indicating the memory 
space. 
 
Torleif has already prepared a new parser dll for avrstudio that is supposed to 
run with 4-Byte dwarf debugging info.  
 
Quote (Torleif Sandes): 
"My dwarf parser is composed of several dlls. The one governing low-level dwarf 
access (such as the size of pointers), is called libdwarf.dll and is a windows 
port of an LGPL licensed library. I have built this library with the required 
change and put it at 
http://www.atmel.no/beta_ware/as4/elfdwarfparser/libdwarf.dll"; 
 
I will unfortunately not have time to look into details during the next two 
weeks. So in case that someone else volunteers (best would be someone who has 
access to a atmega128 board). 
 
Before implementing such a change, in case that it passes tests of course, one 
should probably carefully think about how to manage the transition: There is 
possibly quite a couple of object code out there that still has 2-Byte dwarf 
information included. I am mainly thinking about the WOE users working with 
avrstudio and Eric's precompiled winavr toolchain. Maybe one should do 
implement a simultaneous change of type "For avrstudio 3.4.1 always use winavr 
6.2.8 or later." 
 
Possibly one should consider to implement the 2-Byte -> 4-Byte switching at the 
next 4.0 revision.? 
 
Yours, 
 
Bjoern 
 

-- 


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

[Bug tree-optimization/21831] [4.1 Regression] gcc.dg/vect/vect-97.c fails

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Keywords||ice-on-valid-code
   Target Milestone|--- |4.1.0


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

[Bug tree-optimization/21831] New: [4.1 Regression] gcc.dg/vect/vect-97.c fails

[jsm28 at gcc dot gnu dot org]

FAIL: gcc.dg/vect/vect-97.c (test for excess errors)
appeared on mainline on ia64-hp-hpux11.23 between 20050529 and 20050530.
gcc-testresults also indicates it failing on ia64-linux.

/home/gcc/nightlies/src-mainline-2005-05-30/gcc-mainline/gcc/testsuite/gcc.dg/vect/vect-97.c:
In function 'main1':
/home/gcc/nightlies/src-mainline-2005-05-30/gcc-mainline/gcc/testsuite/gcc.dg/vect/vect-97.c:11:
error: Definition in block 0 follows the use
for SSA_NAME: cb_147 in statement:
#   VUSE ;
vect_var_.28_99 = *vect_pcb.29_98;
/home/gcc/nightlies/src-mainline-2005-05-30/gcc-mainline/gcc/testsuite/gcc.dg/vect/vect-97.c:11:
internal compiler error: verify_ssa failed.

-- 
   Summary: [4.1 Regression] gcc.dg/vect/vect-97.c fails
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jsm28 at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c++/19761] -Winit-self doesn't work anymore

[dannysmith at users dot sourceforge dot net]

--- Additional Comments From dannysmith at users dot sourceforge dot net  
2005-05-30 21:03 ---
I can't reproduce this with either gcc-3.4.4 or 4.0.0 on mingw 

The example gives the warning
warning: 'i' might be used uninitialized in this function
iff I add -Winit-self

That is consistent with manual.

Are you expecuning a different warning?

Danny

-- 


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

[Bug libstdc++/21830] swap_ranges must call swap instead of iter_swap

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-30 
21:01 ---
This is fixed on the mainline at least.

-- 


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

[Bug libstdc++/21830] New: swap_ranges must call swap instead of iter_swap

[h dot schmid at gmx dot de]

According to ISO/IEC 14882:1998 25.2.2 std::swap_ranges must call std::swap.
This can be tested because std::swap is overloaded for std::vector. The
following program fails:


#include 
#include 
#include 

bool copy_allowed = true;

struct Foo
{
Foo() { }
Foo(const Foo&) { assert(copy_allowed); }
Foo& operator=(const Foo&) { assert(copy_allowed); return *this; }
};

int main()
{
std::vector foo[2];
foo[0].push_back(Foo());
copy_allowed = false;
std::swap_ranges(foo, foo + 1, foo + 1);
copy_allowed = true;
}


/tmp > g++-3.4 -Wall swap.cpp -o swap
/tmp > ./swap 
swap: swap.cpp:10: Foo::Foo(const Foo&): Assertion `copy_allowed' failed.
Aborted


There is the same problem with most algorithms that must call std::swap, e.g.
std::sort, std::reverse, std::rotate, ...


/tmp > g++-3.4 --version
g++-3.4 (GCC) 3.4.4 20050314 (prerelease) (Debian 3.4.3-13)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

-- 
   Summary: swap_ranges must call swap instead of iter_swap
   Product: gcc
   Version: 3.4.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: h dot schmid at gmx dot de
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug middle-end/21743] Enable __builtin_clog

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-05-30 20:19 
---
Fixed for 4.1.0

-- 
   What|Removed |Added

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


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

[Bug middle-end/21743] Enable __builtin_clog

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-30 
20:17 ---
Subject: Bug 21743

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-05-30 20:16:59

Modified files:
gcc/testsuite  : ChangeLog 
gcc/testsuite/gcc.dg: builtins-1.c 
gcc/testsuite/gcc.dg/torture: builtin-attr-1.c 

Log message:
2005-05-30  Paolo Carlini  <[EMAIL PROTECTED]>

PR middle-end/21743
* gcc.dg/builtins-1.c: Activate disabled clog test.
* gcc.dg/torture/builtin-attr-1.c: Likewise.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5561&r2=1.5562
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/builtins-1.c.diff?cvsroot=gcc&r1=1.10&r2=1.11
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/torture/builtin-attr-1.c.diff?cvsroot=gcc&r1=1.7&r2=1.8



-- 


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

[Bug middle-end/21743] Enable __builtin_clog

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-30 
20:15 ---
Subject: Bug 21743

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-05-30 20:15:48

Modified files:
gcc: ChangeLog builtins.def 
gcc/doc: extend.texi 

Log message:
2005-05-30  Paolo Carlini  <[EMAIL PROTECTED]>

PR middle-end/21743
* builtins.def (BUILT_IN_CLOG, BUILT_IN_CLOGF, BUILT_IN_CLOGL):
Enable.
* doc/extend.texi: Add clog, clogf, clogl.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8948&r2=2.8949
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/builtins.def.diff?cvsroot=gcc&r1=1.102&r2=1.103
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/doc/extend.texi.diff?cvsroot=gcc&r1=1.253&r2=1.254



-- 


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

[Bug rtl-optimization/15422] fmod loop exposes non-efficient code generation in reg-stack.c

[roger at eyesopen dot com]

--- Additional Comments From roger at eyesopen dot com  2005-05-30 20:05 
---
This should now be fixed on mainline.

-- 
   What|Removed |Added

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


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

[Bug tree-optimization/21734] [4.1 regression] ICE: -ftree-vectorize, segfault

[stefaandr at hotmail dot com]

--- Additional Comments From stefaandr at hotmail dot com  2005-05-30 19:21 
---
confirmed, I cannot reproduce with the given testcase either.  But my original
source code still triggers a (possibly the same) bug.  I've extracted a new
testcase:

struct M {
  double data[16];
  double* operator[](int row){ return &data[row*4]; };
  void set() {
for (int i=0;i<16;++i)
  data[i]=0.0;
  }
};

struct A {
  M m1;
  void test();
};

void A::test() {
  M m2;
  m2[2][2]=0.;
  m1.set();
}


-- 


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

[Bug tree-optimization/21817] [4.0 Regression] ICE in for_each_index, at tree-ssa-loop-im.c:200

[rakdver at gcc dot gnu dot org]

--- Additional Comments From rakdver at gcc dot gnu dot org  2005-05-30 
19:06 ---
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02830.html

-- 
   What|Removed |Added

   Keywords||patch


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

[Bug tree-optimization/21829] [4.1 Regression] missed jump threading after unroller

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|--- |4.1.0
Version|4.0.0   |4.1.0


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

[Bug tree-optimization/21829] New: [4.1 Regression] missed jump threading after unroller

[pinskia at gcc dot gnu dot org]

Take the following code:
int test(int v)
{
  int x = 0;
  for (int u=0;u<2;u++)
  {
if (u>v)  // v is input-arg the compiler can't deside at compiletime
{
  if (u%2==1) // can only happen for u==1 (so loops for 0 and 2 does not do
x++;  // anything. Hoped gcc would notice when unrolling.
}
  }  
  return x;
}

We get:
:
  if (v_8 < 0) goto ; else goto ;

:;
  if (v_8 <= 0) goto ; else goto ;

:;

  # x_1 = PHI <0(3), 1(1)>;
:;
  return x_1;

}

Notice that the if in L15 is always true.
The 4.0 branch gets this correct.

-- 
   Summary: [4.1 Regression] missed jump threading after unroller
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: minor
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug rtl-optimization/21827] unroll misses simple elimination - works with manual unroll

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-30 
18:56 ---
I was not goint to close this, it was accident.

-- 
   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|FIXED   |


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

[Bug c/20303] Can't push more than 16 nested visibility

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|--- |4.1.0


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

[Bug rtl-optimization/21827] unroll misses simple elimination - works with manual unroll

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-30 
18:53 ---
The first testcase is fixed in 4.0.0.  (Though there is a regression on the 
mainline).  I have not looked 
into the full testcase.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   Keywords||missed-optimization
 Resolution||FIXED


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

[Bug c/20303] Can't push more than 16 nested visibility

[hjl at lucon dot org]

--- Additional Comments From hjl at lucon dot org  2005-05-30 18:52 ---
Fixed on mainline.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug c/20303] Can't push more than 16 nested visibility

[hjl at lucon dot org]

--- Additional Comments From hjl at lucon dot org  2005-05-30 18:51 ---
Fixed on mainline.

-- 


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

[Bug c/20303] Can't push more than 16 nested visibility

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-30 
18:49 ---
Subject: Bug 20303

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-05-30 18:49:04

Modified files:
gcc: ChangeLog c-pragma.c 
gcc/doc: invoke.texi 

Log message:
2005-05-30  H.J. Lu  <[EMAIL PROTECTED]>

PR middle-end/20303
* c-pragma.c: Include "vec.h".
(handle_pragma_visibility): Use VEC.

* doc/invoke.texi: Remove the nested visibility push limit.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8947&r2=2.8948
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-pragma.c.diff?cvsroot=gcc&r1=1.85&r2=1.86
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/doc/invoke.texi.diff?cvsroot=gcc&r1=1.626&r2=1.627



-- 


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

[Bug debug/21828] New: [4.1 Regression] stabs debug info completely broken?

[bonzini at gcc dot gnu dot org]

When using gdb-309 and gdb-370 on MacOS X 10.3.9, even the simplest queries seem
broken.

On stage2 gengtype, I get

scientist:~/cvs/gcc/build/gcc bonzinip$ gdb build/gengtype
(gdb) b mangle_macro_name 
Breakpoint 5 at 0x8458: file ../../gcc/gengtype-lex.l, line 429.
(gdb) run
Breakpoint 5, mangle_macro_name ([snip]) at ../../gcc/gengtype-lex.l:429
(gdb) fini
Run till exit from #0 mangle_macro_name ([snip]) at ../../gcc/gengtype-lex.l:429
yylex () at ../../gcc/gengtype-lex.l:263
263   t = find_structure (ptr, 0);
Value returned is $1 = 0x11ccb0 "VEC_tree"
(gdb) p ptr
No symbol "ptr" in current context.

...
228   for (s = structures; s != NULL; s = s->next)
(gdb) p structures
$2 = 

...
106   for (p = typedefs; p != NULL; p = p->next)
(gdb) p typedefs
$5 = 

and so on.

Paolo

-- 
   Summary: [4.1 Regression] stabs debug info completely broken?
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: powerpc-apple-darwin7.9.0


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

[Bug rtl-optimization/21827] New: unroll misses simple elimination - works with manual unroll

[tlm at daimi dot au dot dk]

Using gentoo gcc 3.4.3

This could look like http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11707
(and they might be the same. However I think I had the problem with 3.3.4 too)

I have also had this problem in other older versions. In 2 projects I have been
on this has been really annoying. I think that if a loop is unrolled and the
variable is eliminated it should be replaced with a constant (and then always
false ifs should be removed) 

That is not the case:
int test(int v)
{
  int x = 0;
  for (int u=0;u<2;u++)
  {
if (u>v)  // v is input-arg the compiler can't deside at compiletime
{
  if (u%2==1) // can only happen for u==1 (so loops for 0 and 2 does not do
x++;  // anything. Hoped gcc would notice when unrolling.
}
  }  
  return x;
}

g++ -O3 -unroll-loops -S simple_test.cpp 

gives me the following code:
.text
.align 2
.p2align 4,,15
.globl _Z4testi
.type   _Z4testi, @function
_Z4testi:
.LFB2:
pushl   %ebp
.LCFI0:
xorl%edx, %edx
movl%esp, %ebp
.LCFI1:
xorl%eax, %eax
incl%eax
cmpl8(%ebp), %eax
jle .L4
testb   $1, %al
setne   %cl
movzbl  %cl, %eax
addl%eax, %edx
.L4:
popl%ebp
movl%edx, %eax
ret
.LFE2:
.size   _Z4testi, .-_Z4testi
.section.note.GNU-stack,"",@progbits
.ident  "GCC: (GNU) 3.4.3-20050110 (Gentoo 3.4.3.20050110-r2,
ssp-3.4.3.20050110-0, pie-8.7.7)"

If I manually unroll like :

int test(int v)
{
  int x = 0;

  if (0>v)
  {
if (0%2==1)
  x++;
  }
  if (1>v)
  {
if (1%2==1)
  x++;
  }
  if (2>v)
  {
if (2%2==1)
  x++;
  }  
  
  return x;
}

And then just with O3 I get the much nicer :
.text
.align 2
.p2align 4,,15
.globl _Z4testi
.type   _Z4testi, @function
_Z4testi:
.LFB2:
pushl   %ebp
.LCFI0:
xorl%eax, %eax
movl%esp, %ebp
.LCFI1:
cmpl$0, 8(%ebp)
popl%ebp
setle   %al
ret
.LFE2:
.size   _Z4testi, .-_Z4testi
.section.note.GNU-stack,"",@progbits
.ident  "GCC: (GNU) 3.4.3-20050110 (Gentoo 3.4.3.20050110-r2,
ssp-3.4.3.20050110-0, pie-8.7.7)"

I have had too cases where this optimization is very important. One is if you a
kind of program a chessboard "from within". The other case were a raytracer I
wrote with a friend. In that situation we had to seattle with a not that fast
switch (since we did not wanted to pollute out code with a manual unroll.)

The chessboard example (here a simple case - how many knightsmove does white
have. We do not consider check, pins or that pieces can be in the way)

int knight_square_count(unsigned char* board)
{
  int count = 0;
  for (int bp=0;bp<64;bp++)
  {
if (board[bp]==WHITE_KNIGHT)
{
  if (bp%8>1 && bp/8>0) count++;
  if (bp%8>0 && bp/8>1) count++;
  if (bp%8<6 && bp/8>0) count++;
  if (bp%8<7 && bp/8>1) count++;
  if (bp%8>1 && bp/8<7) count++;
  if (bp%8>0 && bp/8<6) count++;
  if (bp%8<6 && bp/8<7) count++;
  if (bp%8<7 && bp/8<6) count++;
}
  }
  return count;
}

In the above situation a manual unroll (with O3) is more than 400% faster.
(I have timed it and it is close to 500%) I thought that one of the main ideas
of unrolling loops was to make a kind of every loop "its own" (Without making
ugly code)

regards and thanks for the best (free) compiler
Bsc Computer Science 
Thorbjørn Martsum

PS : There might also be a reason for things being as they are. Then I just
don't understand why - please explain then

-- 
   Summary: unroll misses simple elimination - works with manual
unroll
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tlm at daimi dot au dot dk
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c++/21135] [4.0/4.1 Regression] &a[-2] ICE at the top level

[kenner at vlsi1 dot ultra dot nyu dot edu]

--- Additional Comments From kenner at vlsi1 dot ultra dot nyu dot edu  
2005-05-30 18:36 ---
Subject: Re:   [4.0/4.1 Regression] &a[-2] ICE at the top level

The difference in the handling of these two expressions is that
get_inner_reference sets the "offset" out-parameter for &a[-2], but
not for a[2].  That's at odds with its documentation, which says that
offset is only set if the offset is not a constant.

Is this because the value doesn't fit in some type?  I don't understand
why it's doing that.

Furthermore, the out-parameter "bitpos" is signed, which suggests that
negative values should be acceptable.

I think this is just consistency: bitpos is signed all over the place.
But, actually, I think there are some cases where the are negative bit
positions: the object a thin pointer in Ada points to comes to mind.

Changing get_inner_reference to use ssizetype and sbitsizetype
throughout fixes the problems -- but I'm not sure if that's 100%
correct.

Nor am I, but I can't offhand think of anything it would breajk.


-- 


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

[Bug rtl-optimization/15422] fmod loop exposes non-efficient code generation in reg-stack.c

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-30 
18:02 ---
Subject: Bug 15422

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-05-30 18:02:09

Modified files:
gcc: ChangeLog reg-stack.c 

Log message:
PR rtl-optimization/15422
* reg-stack.c (starting_stack_p): New static global.
(straighten_stack): Delete prototype. Change to update the stack
before the current insn.
(subst_stack_regs): Update call to straighten stack.
(emit_swap_insn): Delete prototype.  For the first insn in a
basic block, update stack_in instead of emitting a real swap.
(change_stack): When changing the stack before the first insn
in a basic block, update stack_in instead of emitting real code.
(compensate_edges): Clear starting_stack_p during compensation.
(convert_regs_1): Keep track of starting_stack_p whilst processing
a basic block.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8946&r2=2.8947
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/reg-stack.c.diff?cvsroot=gcc&r1=1.181&r2=1.182



-- 


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

gcc-3.4.4 build bug

[S. Sevki Dincer]

I have a laptop with pentium M centrino 1.7 ghz cpu, 512 mb ram, suse linux 
prof. 9.2 operating
system (with all required/recommended patches installed), and gcc (GCC) 3.3.4 
(pre 3.3.5
20040809).

I downloaded gcc-3.4.4 full source code from one of the mirrors specified at 
gcc.gnu.org, and
extracted the .tar.bz2 file on my Desktop (So the gcc source is at 
/jfcgauss/Desktop/gcc-3.4.4).

Then I created a directory /gecici (temporary direcroty as objdir) with full 
access to my account,
and created an executable script file named "d" in this directory. This file 
contains how I call
configure and make, and is in the attached archive.

Then, in a console I changed the curent directory to /gecici and then I typed 
the following:
./d > gccOut.txt

The gccOut.txt file is also in the attached archive. Additionally, there was 
some output in the
concole window, which I saved to a console.txt file (console output says to 
report this bug). This
is also in the attached archive file.

Can you please acknowledge whether you receive this email and whether it is a 
real bug?

---
Independent from this bug report, I don't want the "-g" flag to be used at any 
place during the
build; how can I do this? I always see it somewhere.



__ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new Resources site
http://smallbusiness.yahoo.com/resources/

gcc344Bug.tar.bz2
Description: 2662161732-gcc344Bug.tar.bz2

[Bug ada/21573] 'Valid attribute on enumeration types with holes

[fw at deneb dot enyo dot de]

--- Additional Comments From fw at deneb dot enyo dot de  2005-05-30 17:50 
---
In expand_case, we have:

 
unit size 
user align 32 symtab 0 alias set -1 precision 32 min  max  RM size >
side-effects asm_written
arg 0 
unit size 
user align 8 symtab 0 alias set -1 precision 8 min  max  RM size >
readonly unsigned QI file /tmp/bug2_p.ads line 4 size  unit size 
align 8 context 
result  unit size 
align 32 symtab 0 alias set -1 precision 32 min  max 
pointer_to_this > initial 
(reg/v:QI 60 [ A ]) arg-type 
arg-type-as-written 
incoming-rtl (mem/i:SI (reg/f:SI 53 virtual-incoming-args) [7 A+0 S1 
A32])
chain 
readonly unsigned QI file /tmp/bug2_p.ads line 4 size  unit size 
align 8 context  result
 initial 
(reg/v:QI 62 [ F ]) arg-type 
arg-type-as-written 
incoming-rtl (mem/i:SI (plus:SI (reg/f:SI 53 virtual-incoming-args)
(const_int 4 [0x4])) [2 F+0 S1 A32])>>
arg 2 
elt 1 
elt 2 
elt 3 
elt 4 >
/tmp/bug2_p.ads:4>

Please note the min and max values of the enumeral_type.  The cause seems to be
that exp_ch3.adb emits the rep-to-pos function as follows:

  --function _Rep_To_Pos (A : etype; F : Boolean) return Integer is
  --begin
  --   case ityp!(A) is
  -- when enum-lit'Enum_Rep => return posval;
  -- when enum-lit'Enum_Rep => return posval;
  -- ...
  -- when others   =>
  --   [raise Constraint_Error when F "invalid data"]
  --   return -1;
  --   end case;
  --end;

I think the argument A should be of a suitable integer type, not the enumeration
type, but this might only hide the bug.  Maybe Ada should even refrain from
setting TYPE_MIN_VALUE and TYPE_MAX_VALUE on its enumeration types.

-- 
   What|Removed |Added

  Component|rtl-optimization|ada


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

[Bug c++/21135] [4.0/4.1 Regression] &a[-2] ICE at the top level

[mmitchel at gcc dot gnu dot org]

--- Additional Comments From mmitchel at gcc dot gnu dot org  2005-05-30 
17:18 ---
I'm not sure this is really a C++ bug.

The C++ front end provides the same representation to the middle end for
"&a[-2]" as it does for "&a[2]".  It would be wrong for the middle end to say
that this expression is not a valid constant initializer, at least on platforms
where it *is* valid.

The difference in the handling of these two expressions is that
get_inner_reference sets the "offset" out-parameter for &a[-2], but not for
a[2].  That's at odds with its documentation, which says that offset is only set
if the offset is not a constant.  Furthermore, the out-parameter "bitpos" is
signed, which suggests that negative values should be acceptable.

Changing get_inner_reference to use ssizetype and sbitsizetype throughout fixes
the problems -- but I'm not sure if that's 100% correct.

-- 
   What|Removed |Added

 CC||kenner at vlsi1 dot ultra
   ||dot nyu dot edu


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

[Bug tree-optimization/21789] [4.1 regression] ICE with -ftree-vectorize

[pinskia at gcc dot gnu dot org]

-- 
Bug 21789 depends on bug 21653, which changed state.

Bug 21653 Summary: [4.1 Regression] gcc.dg/vect failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21653

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

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

[Bug tree-optimization/21155] [4.1 Regression] ICE in ssa tree check compiling crafty with -ftree-vectorize -maltivec

[pinskia at gcc dot gnu dot org]

-- 
Bug 21155 depends on bug 21653, which changed state.

Bug 21653 Summary: [4.1 Regression] gcc.dg/vect failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21653

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

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

[Bug tree-optimization/21653] [4.1 Regression] gcc.dg/vect failures

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-30 
17:06 ---
Fixed.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug fastjar/21822] fastjar/jartool.c's usage of MAXPATHLEN

[joseph at codesourcery dot com]

--- Additional Comments From joseph at codesourcery dot com  2005-05-30 
17:03 ---
Subject: Re:  fastjar/jartool.c's usage of MAXPATHLEN

On Mon, 30 May 2005, pinskia at gcc dot gnu dot org wrote:

> You should report this to the up stream as GCC just merges with fastjar see 
> the README in fastjar 
> directory.

As a practical matter fastjar and libffi do not get maintained outside of 
GCC (whereas zlib does).



-- 


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

[Bug c++/21784] [3.4/4.0/4.1 Regression] Using vs builtin names

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Known to fail|3.3.3 3.4.0 4.0.0 4.1.0 |3.3.3 3.4.0 4.0.0
  Known to work|3.2.3 3.0.4 |3.2.3 3.0.4 4.0.1 4.1.0
   Target Milestone|3.4.5   |4.0.1


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

[Bug target/21760] [4.1 Regression] Powerpc atomic builtins missing PPC405 errata

[dje at gcc dot gnu dot org]

--- Additional Comments From dje at gcc dot gnu dot org  2005-05-30 16:41 
---
See the thread related to
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02424.html .

The problem is that the new builtin atomic functionality does not support all of
the special cases that the inlined assembly supported.  libstdc++ now is using
builtins.  Paolo apparently cannot fix the breakage that he caused and is
dropping the problem on the port maintainers.

-- 


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

[Bug c++/21784] [3.4/4.0/4.1 Regression] Using vs builtin names

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2005-05-30 
16:34 ---
Isn't this a 3.4 regression as well?

-- 


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

[Bug middle-end/21743] Enable __builtin_clog

[mmitchel at gcc dot gnu dot org]

-- 
Bug 21743 depends on bug 21784, which changed state.

Bug 21784 Summary: [3.4/4.0/4.1 Regression] Using vs builtin names
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21784

   What|Old Value   |New Value

 Status|UNCONFIRMED |NEW
 Status|NEW |ASSIGNED
 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

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

[Bug c++/21784] [3.4/4.0/4.1 Regression] Using vs builtin names

[mmitchel at gcc dot gnu dot org]

--- Additional Comments From mmitchel at gcc dot gnu dot org  2005-05-30 
16:31 ---
Fixed in 4.0.1.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/21784] [3.4/4.0/4.1 Regression] Using vs builtin names

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-30 
16:29 ---
Subject: Bug 21784

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-05-30 16:29:05

Modified files:
gcc/cp : ChangeLog name-lookup.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/g++.dg/lookup: using14.C 

Log message:
PR c++/21784
* name-lookup.c (do_nonmember_using_decl): Ignore builtin
functions, even when the used name is not a function.

PR c++/21784
* g++.dg/lookup/using14.C: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.4648.2.49&r2=1.4648.2.50
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/name-lookup.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.109.4.3&r2=1.109.4.4
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.209&r2=1.5084.2.210
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/lookup/using14.C.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.2.2.1



-- 


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

[Bug libgcj/21821] MAXPATHLEN usage in libjava

[ams at gnu dot org]

--- Additional Comments From ams at gnu dot org  2005-05-30 16:23 ---
(In reply to comment #2)
> Its easy to fix this for natFileChannelImpl.cc.

Thank you for fixing it!

> For natFilePosix.cc it is not so simple - is there a portable alternative to
> realpath() that does not require the use of MAXPATHLEN / PATH_MAX ?

One can call realpath() with NULL for the second parameter on systems that do
not have MAXPATHLEN/PATH_MAX.  You could also use canonicalize_file_name(), but
this is a GNU C library specific function.

 -- Function: char * realpath (const char *restrict NAME, char
  *restrict RESOLVED)
...
 On systems which define `PATH_MAX'
 this means the buffer must be large enough for a pathname of this
 size.  For systems without limitations on the pathname length the
 requirement cannot be met and programs should not call `realpath'
 with anything but `NULL' for the second parameter.

 -- Function: char * canonicalize_file_name (const char *NAME)
 The `canonicalize_file_name' function returns the absolute name of
 the file named by NAME which contains no `.', `..' components nor
 any repeated path separators (`/') or symlinks.  The result is
 passed back as the return value of the function in a block of
 memory allocated with `malloc'.  If the result is not used anymore
 the memory should be freed with a call to `free'.


-- 


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

[Bug c++/21784] [3.4/4.0/4.1 Regression] Using vs builtin names

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-30 
16:21 ---
Subject: Bug 21784

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-05-30 16:20:29

Modified files:
gcc/cp : ChangeLog name-lookup.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/g++.dg/lookup: using14.C 

Log message:
PR c++/21784
* name-lookup.c (do_nonmember_using_decl): Ignore builtin
functions, even when the used name is not a function.

PR c++/21784
* g++.dg/lookup/using14.C: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4765&r2=1.4766
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/name-lookup.c.diff?cvsroot=gcc&r1=1.120&r2=1.121
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5559&r2=1.5560
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/lookup/using14.C.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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

[Bug libfortran/21820] Really, really, horrible IO performance

[sgk at troutmask dot apl dot washington dot edu]

--- Additional Comments From sgk at troutmask dot apl dot washington dot 
edu  2005-05-30 16:20 ---
Subject: Re:  Really, really, horrible IO performance

On Mon, May 30, 2005 at 03:20:18PM -, pinskia at gcc dot gnu dot org wrote:
> 
> I see the same thing on powerpc-darwin but it seems like on freebsd,
> it is actually paging in the memory which seems wrong, I almost want
> to say you should report it to freebsd as their performance bug
> (Yes working around in libgfortran is still a good idea).

It appears to be a faulty assumption in how gfortran uses mmap.
gfortran appears to assume Linux's behavior:

   (From some version of Redhat)
   MAP_SHARED   Share this mapping with all other processes that map this
object.  Storing to the region is equivalent to writing to
the file.  The file may not actually be updated until
msync(2) or munmap(2) are called.

   (From FreeBSD)
   MAP_SHARED   Modifications are shared.

   MAP_NOSYNC   Causes data dirtied via this VM map to be flushed to
physical media only when necessary (usually by the
pager) rather than gratuitously.  Typically this pre-
vents the update daemons from flushing pages dirtied
through such maps and thus allows efficient sharing of
memory across unassociated processes using a file-
backed shared memory map.  (Much snipped, including a
big warning about ftruncate extending a file).

   (From http://www.opengroup.org/onlinepubs/7990989775/xsh/mmap.html)
   If MAP_SHARED is specified, write references change the underlying object. 

It appears that Linux's MAP_SHARED is equivalent to FreeBSD's
(MAP_SHARED | MAP_NOSYNC).  NetBSD and OpenBSD man pages do not
have the MAP_NOSYNC flag, so they may not be affected.  Note 
POSIX doesn't state anything about when and how the underlying object 
is updated.  POSIX also doesn't include a MAP_NOSYNC flag.

I've verified that the following patch works and improves
performance, but I prefer the original O_TRUNC patch because
O_TRUNC is a POSIX flag and AFAIK most OS's implement it.

Index: unix.c
===
RCS file: /cvs/gcc/gcc/libgfortran/io/unix.c,v
retrieving revision 1.26
diff -c -p -r1.26 unix.c
*** unix.c  17 May 2005 16:54:51 -  1.26
--- unix.c  30 May 2005 16:06:54 -
*** mmap_alloc (unix_stream * s, gfc_offset 
*** 622,628 
  
length = ((where - offset) & page_mask) + 2 * page_size;
  
!   p = mmap (NULL, length, s->prot, MAP_SHARED, s->fd, offset);
if (p == (char *) MAP_FAILED)
  return FAILURE;
  
--- 622,628 
  
length = ((where - offset) & page_mask) + 2 * page_size;
  
!   p = mmap (NULL, length, s->prot, MAP_SHARED | MAP_NOSYNC, s->fd, offset);
if (p == (char *) MAP_FAILED)
  return FAILURE;




-- 


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

[Bug libgcj/21821] MAXPATHLEN usage in libjava

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-30 
16:14 ---
Subject: Bug 21821

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-05-30 16:02:40

Modified files:
libjava: ChangeLog 
libjava/gnu/java/nio/channels: natFileChannelPosix.cc 

Log message:
2005-05-30  Bryce McKinlay  <[EMAIL PROTECTED]>

PR libgcj/21821
* gnu/java/nio/channels/natFileChannelPosix.cc (open): Don't use
MAXPATHLEN. Format exception message using a StringBuffer instead.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcc&r1=1.3639&r2=1.3640
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/gnu/java/nio/channels/natFileChannelPosix.cc.diff?cvsroot=gcc&r1=1.6&r2=1.7



-- 


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

[Bug target/21760] [4.1 Regression] Powerpc atomic builtins missing PPC405 errata

[geoffk at geoffk dot org]

--- Additional Comments From geoffk at geoffk dot org  2005-05-30 15:37 
---
Subject: Re:  [4.1 Regression] Powerpc atomic builtins missing PPC405 errata


On 29/05/2005, at 6:40 PM, dje at gcc dot gnu dot org wrote:

> This is a regression because libstdc++ previously worked correctly  
> on PPC405 and
> now it does not.

That would be due to this patch:

2005-05-25  Paolo Carlini  <[EMAIL PROTECTED]>

 * config/cpu/alpha/atomicity.h: Use the builtins for
 atomic memory operations.
 * config/cpu/powerpc/atomicity.h: Likewise.
 * config/cpu/ia64/atomicity.h: Do not include ia64intrin.h.




-- 


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

[Bug libgcj/21821] MAXPATHLEN usage in libjava

[mckinlay at redhat dot com]

--- Additional Comments From mckinlay at redhat dot com  2005-05-30 15:35 
---
Its easy to fix this for natFileChannelImpl.cc.

For natFilePosix.cc it is not so simple - is there a portable alternative to
realpath() that does not require the use of MAXPATHLEN / PATH_MAX ?

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-05-30 15:35:43
   date||


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

[Bug AWT/17254] [java-gui-branch] Hang when resizing AWT window on Alpha

[fitzsim at redhat dot com]

--- Additional Comments From fitzsim at redhat dot com  2005-05-30 15:32 
---
There were some changes in how AWT threading works (as well as many other
changes) recently.  Can you retry your test and post the results here?


-- 


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

[Bug middle-end/21597] [4.1 Regression] libgcc broken on targets with MKDIR_TAKES_ONE_ARG

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-30 
15:29 ---
(In reply to comment #2)
> Looks like MKDIR_TAKES_ONE_ARG is not defined as it should be.
Which I filed as PR 21826.

-- 


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

[Bug fastjar/21826] New: fastjar does not look to see if mkdir takes one or two arguments

[pinskia at gcc dot gnu dot org]

On i386-mingw32, there is another one of those:

../../gcc/fastjar/jartool.c: In function 'extract_jar':
../../gcc/fastjar/jartool.c:1770: error: too many arguments to function 'mkdir'

Looks like MKDIR_TAKES_ONE_ARG is not defined as it should be.

-- 
   Summary: fastjar does not look to see if mkdir takes one or two
arguments
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P2
 Component: fastjar
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug fastjar/20941] Incorrect case for META-INF with fastjar

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Component|libgcj  |fastjar


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

[Bug fortran/21825] New: Segmentation fault on 2D array initialization with reshape

[enok at lysator dot liu dot se]

The following code causes segmentation fault with gfortran

PROGRAM TST
  CHARACTER(2), PARAMETER :: ETYPE(2,2) = &
   RESHAPE((/ 'a1','b1','a2','b2' /),(/2,2/))
END PROGRAM TST


> gfortran4 -c tst.f90
tst.f90:0: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
>

-- 
   Summary: Segmentation fault on 2D array initialization with
reshape
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: enok at lysator dot liu dot se
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug fastjar/13020] zip-style comments

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Component|libgcj  |fastjar


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

[Bug libfortran/21820] Really, really, horrible IO performance

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-30 
15:20 ---
I see the same thing on powerpc-darwin but it seems like on freebsd, it is 
actually paging in the 
memory which seems wrong, I almost want to say you should report it to freebsd 
as their performance 
bug (Yes working around in libgfortran is still a good idea).

-- 


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

[Bug libfortran/19216] [4.0 only] list directed read with leading slash (NIST FM923)

[kargl at gcc dot gnu dot org]

--- Additional Comments From kargl at gcc dot gnu dot org  2005-05-30 15:17 
---
FX,

Can you commit the testcase and close this PR?

steve

-- 


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

[Bug libmudflap/21724] [gcc]/libmudflap/Makefile.am, refusing to install mf-runtime.h in includedir

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

OtherBugsDependingO||21824
  nThis||


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

[Bug libmudflap/21724] [gcc]/libmudflap/Makefile.am, refusing to install mf-runtime.h in includedir

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Keywords||build


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

[Bug libfortran/21820] Really, really, horrible IO performance

[sgk at troutmask dot apl dot washington dot edu]

--- Additional Comments From sgk at troutmask dot apl dot washington dot 
edu  2005-05-30 15:15 ---
Subject: Re:  Really, really, horrible IO performance

On Mon, May 30, 2005 at 03:00:41PM -, pinskia at gcc dot gnu dot org wrote:
> 
> > Note, the use of O_TRUNC on replacing a file should 
> > not hurt performance on other OS's.
> 
> On powerpc-darwin I am using HFS+.
> Hmm, I think I should drag my firewire drive out and try it on the
> UFS partition.
> 

A little more investigate shows that this may be a mmap problem.

If foo.dat does not exist
   ktrace ./z
   kdump -f ktrace.out | grep mmap | wc -l 
   4

   If foo.dat exists, then I see
   ktrace ./z
   kdump -f ktrace.out | grep mmap | wc -l
   246054

In looking at the ktrace, I see a bunch of segments like

 95157 zCALL  mmap(0,0x2000,0x3,0x1,0x3,0,0,0)
 95157 zRET   mmap 1208418304/0x4807
 95157 zCALL  munmap(0x4807,0x2000)
 95157 zRET   munmap 0
 95157 zCALL  mmap(0,0x2000,0x3,0x1,0x3,0,0,0)
 95157 zRET   mmap 1208418304/0x4807
 95157 zCALL  munmap(0x4807,0x2000)
 95157 zRET   munmap 0
 95157 zCALL  mmap(0,0x2000,0x3,0x1,0x3,0,0,0)
 95157 zRET   mmap 1208418304/0x4807
 95157 zEvents dropped.



-- 


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

[Bug middle-end/21706] MAXPATHLEN usage in [gcc]/gcc/tlink.c

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

OtherBugsDependingO||21824
  nThis||


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

[Bug other/21823] MAXPATHLEN usage in [gcc]/fixincludes

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

OtherBugsDependingO||21824
  nThis||


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

[Bug libgcj/21821] MAXPATHLEN usage in libjava

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

OtherBugsDependingO||21824
  nThis||


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

[Bug fastjar/21822] fastjar/jartool.c's usage of MAXPATHLEN

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

OtherBugsDependingO||21824
  nThis||


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

[Bug target/21824] [meta-bug] bootstrap bugs for *-gnu*

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  BugsThisDependsOn||21706, 21821, 21822, 21823
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-05-30 15:14:44
   date||


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

[Bug target/21824] [meta-bug] bootstrap bugs for *-gnu*

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Keywords||meta-bug


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

[Bug target/21824] New: [meta-bug] bootstrap bugs for *-gnu*

[pinskia at gcc dot gnu dot org]

 

-- 
   Summary: [meta-bug]  bootstrap bugs for *-gnu*
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: build
  Severity: minor
  Priority: P2
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug fastjar/21822] fastjar/jartool.c's usage of MAXPATHLEN

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-30 
15:10 ---
You should report this to the up stream as GCC just merges with fastjar see the 
README in fastjar 
directory.

-- 
   What|Removed |Added

  Component|libgcj  |fastjar


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

[Bug other/21823] MAXPATHLEN usage in [gcc]/fixincludes

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Component|c   |other


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

[Bug c/21823] New: MAXPATHLEN usage in [gcc]/fixincludes

[ams at gnu dot org]

The way MAXPATHLEN is used in fixincludes (server.c and fixincl.c) is wrong,
instead of defining a bogus value on platforms that do not have MAXPATHLEN
defined (i.e. GNU) one should try and use getcwd as follows:

  char *dir = getcwd (NULL, 0);

instead of passing a buffer and a size.

This will only work on systems that use the GNU C Library.

-- 
   Summary: MAXPATHLEN usage in [gcc]/fixincludes
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ams at gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-gnu0.3
  GCC host triplet: i686-pc-gnu0.3
GCC target triplet: i686-pc-gnu0.3


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

[Bug tree-optimization/21789] [4.1 regression] ICE with -ftree-vectorize

[dorit at il dot ibm dot com]

--- Additional Comments From dorit at il dot ibm dot com  2005-05-30 15:08 
---
> I also checked if the follow-on fix - http://gcc.gnu.org/ml/gcc-patches/2005-
> 05/msg02478.html resolves this problem, but it doesn't.

Actually, I think the patch above
(http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02478.html)
does solve this ICE (I used a compiler without Keith's patch before).



-- 


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

[Bug libgcj/21822] fastjar/jartool.c's usage of MAXPATHLEN

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Component|java|libgcj


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

[Bug java/21822] New: fastjar/jartool.c's usage of MAXPATHLEN

[ams at gnu dot org]

The way MAXPATHLEN is used in jartool.c is wrong, instead of defining a bogus
value on platforms that do not have MAXPATHLEN defined (i.e. GNU) one should try
and use getcwd as follows:

  char *dir = getcwd (NULL, 0);

instead of passing a buffer and a size.

This will only work on systems that use the GNU C Library.

-- 
   Summary: fastjar/jartool.c's usage of MAXPATHLEN
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ams at gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
 GCC build triplet: i686-pc-gnu0.3
  GCC host triplet: i686-pc-gnu0.3
GCC target triplet: i686-pc-gnu0.3


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

[Bug libgcj/21821] MAXPATHLEN usage in libjava

[schwinge-bugzilla-gcc dot gnu dot org at nic-nac-project dot de]

-- 
   What|Removed |Added

 CC||schwinge-bugzilla-gcc dot
   ||gnu dot org at nic-nac-
   ||project dot de


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

[Bug libmudflap/21724] [gcc]/libmudflap/Makefile.am, refusing to install mf-runtime.h in includedir

[schwinge-bugzilla-gcc dot gnu dot org at nic-nac-project dot de]

-- 
   What|Removed |Added

 CC||schwinge-bugzilla-gcc dot
   ||gnu dot org at nic-nac-
   ||project dot de


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

[Bug libfortran/21820] Really, really, horrible IO performance

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-30 
15:00 ---
(In reply to comment #3)
> Note, the use of O_TRUNC on replacing a file should 
> not hurt performance on other OS's.

On powerpc-darwin I am using HFS+.
Hmm, I think I should drag my firewire drive out and try it on the UFS 
partition.

-- 


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