[Bug tree-optimization/40676] [4.5 Regression] internal compiler error: verify_ssa error: definition in block 5 does not dominate use in block 7

[reichelt at gcc dot gnu dot org]

--- Comment #10 from reichelt at gcc dot gnu dot org  2009-09-17 07:34 
---
Honza, can this PR be closed?


-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||reichelt at gcc dot gnu dot
   ||org


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

[Bug target/40226] gcc emits bad opcode 'ffreep' even if march=geode

[ubizjak at gmail dot com]

--- Comment #4 from ubizjak at gmail dot com  2009-09-17 08:48 ---
As per comment #3.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug target/39935] Incorrect comments for %z modifier

[ubizjak at gmail dot com]

--- Comment #3 from ubizjak at gmail dot com  2009-09-17 08:54 ---
Comment fixed in mainline.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug target/39369] ioquake3 SIGSEGVs when compiled with SSE optimizations

[ubizjak at gmail dot com]

--- Comment #4 from ubizjak at gmail dot com  2009-09-17 08:59 ---


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


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3

[ubizjak at gmail dot com]

--- Comment #69 from ubizjak at gmail dot com  2009-09-17 08:59 ---
*** Bug 39369 has been marked as a duplicate of this bug. ***


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 CC||arxeio at gmail dot com


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

[Bug target/38906] FAIL: gcc.target/i386/avx-vmovntdq-256-1.c (test for excess errors)

[ubizjak at gmail dot com]

--- Comment #4 from ubizjak at gmail dot com  2009-09-17 09:04 ---
Binutils issue.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug lto/39276] [lto] - Testsuite gcc.log shows many "getconf: Invalid argument (_NPROCESSORS_ONLN)"

[rguenth at gcc dot gnu dot org]

--- Comment #9 from rguenth at gcc dot gnu dot org  2009-09-17 09:07 ---
Mine.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|bje at gcc dot gnu dot org  |rguenth at gcc dot gnu dot
   ||org


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

[Bug tree-optimization/34011] Memory load is not eliminated from tight vectorized loop

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2009-09-17 09:08 ---
The problem is now back to the original one.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|rguenth at gcc dot gnu dot  |unassigned at gcc dot gnu
   |org |dot org
 Status|ASSIGNED|NEW
   Keywords||missed-optimization, ra


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

[Bug libfortran/41387] New: OPEN, STATUS='NEW' of a symbolic link to a non-existing file fails.

[toon at moene dot org]

The following program:

  OPEN(UNIT=1,FILE='noot',STATUS='NEW')
  END

when compiled/linked into a.out and run as follows:

$ rm aap
$ ln -s aap noot
$ ./a.out

gives:

At line 1 of file a.f (unit = 1, file = '')
Fortran runtime error: File 'noot' already exists

Other compilers (tested: xlf (IBM) and ifort (Intel)) permit to open a
non-existing file as 'NEW' this way.

The reason our run-time library doesn't is that in io/unix.c, we open a 'NEW'
file with open(, O_CREAT | O_EXCL, ...).

The man page of open says about O_EXCL:

   O_EXCL

Ensure  that  this  call creates the file: if this flag is specified in
conjunction with O_CREAT, and pathname already exists, then open() will fail.
The behavior of O_EXCL is undefined if O_CREAT is not specified.

When these two flags are specified, symbolic links are not followed: if
pathname is a symbolic link, then open() fails regardless of where the
symbolic link points to.


-- 
   Summary: OPEN, STATUS='NEW' of a symbolic link to a non-existing
file fails.
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: toon at moene dot org


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

[Bug target/38320] missed movd opcode (32bits mm -> r/m32).

[ubizjak at gmail dot com]

--- Comment #4 from ubizjak at gmail dot com  2009-09-17 09:10 ---
The problem from Comment #2 won't be fixed. Too little gain for too much pain.
And %mm registers are evil as they alias x87 regs.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX


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

[Bug target/38288] i386/i386.c: 7 * set but not used variables

[ubizjak at gmail dot com]

--- Comment #4 from ubizjak at gmail dot com  2009-09-17 09:14 ---
Is the patch from Comment #3 committed to SVN?


-- 


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

[Bug target/38015] Converting between int and vector using intrinsics goes through memory

[ubizjak at gmail dot com]

--- Comment #4 from ubizjak at gmail dot com  2009-09-17 09:20 ---
(In reply to comment #3)
> I think this was done on purpose.

Yes, use -march=core2.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug target/37003] 4.2.2 -mfpmath=sse causes movapd from non-16-byte aligned address

[ubizjak at gmail dot com]

--- Comment #3 from ubizjak at gmail dot com  2009-09-17 09:24 ---
Please try with latest version 4.4.x and reopen the bug if the test still
fails. Version 4.2 is not supported anymore.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX


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

[Bug target/36860] gcc 4.2.3 produces poor code compared to gcc-3.4.3 on xeon prestonia

[ubizjak at gmail dot com]

--- Comment #4 from ubizjak at gmail dot com  2009-09-17 09:26 ---
Not an executable testcase. Please use gcc-4.4.x, gcc-4.2 is not supported
anymore.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX


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

[Bug target/36669] Wrong versioning for __float128

[ubizjak at gmail dot com]

--- Comment #23 from ubizjak at gmail dot com  2009-09-17 09:31 ---
Fixed?


-- 


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

[Bug target/35516] option -masm=intel generates wrong assembly code with globals

[ubizjak at gmail dot com]

--- Comment #1 from ubizjak at gmail dot com  2009-09-17 09:39 ---
This is fixed in 4.4.x.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug target/35466] Different assembly codes on 32bit and 64bit hosts

[ubizjak at gmail dot com]

--- Comment #9 from ubizjak at gmail dot com  2009-09-17 09:40 ---
(In reply to comment #5)
> 32bit HWI cannot represent 128bit constants.  If you are lucky and it works as
> far as creating code you should not be surprised that some constants might
> be forced to memory.  The only chance to generate the same code in this 
> context
> is to pessimize code generation for 64bit HWI.  We are not going to do that.

Yeah.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||WONTFIX


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

[Bug target/35425] Improve -mpcXXX handling

[ubizjak at gmail dot com]

--- Comment #2 from ubizjak at gmail dot com  2009-09-17 09:42 ---
(In reply to comment #1)
> You can put all arguments that use atoi() to this PR:
> -mregparm=aaa, -mbranch-cost=foo, -mpreferred-stack-boundary=10^5, ...

Wontfix.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX


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

[Bug target/35195] Strange effect of -msse5/-mno-sse5

[ubizjak at gmail dot com]

--- Comment #1 from ubizjak at gmail dot com  2009-09-17 09:43 ---
SSE5 is no more.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug lto/40409] [LTO] ICE in expand_shift, at expmed.c:2263

[rguenth at gcc dot gnu dot org]

--- Comment #9 from rguenth at gcc dot gnu dot org  2009-09-17 09:44 ---
I don't remember -lto-test, so it was probably never there.

Ok, so this bug is again of the sort "run cc1 with optimization, lto1 without".
We'll have to think about a solution here, fixing up all the issues that arise
will be hard, so likely we'll just force optimization level to 1 from zero if
optimization was on during cc1.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |NEW
 GCC target triplet|powerpc-unknown-linux-gnu   |powerpc-unknown-linux-gnu,
   ||i?86-*-*
   Last reconfirmed|2009-07-09 05:39:56 |2009-09-17 09:44:37
   date||


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

[Bug target/34702] 1.0 is not the inverse of 1.0 with -mrecip on x86

[ubizjak at gmail dot com]

--- Comment #8 from ubizjak at gmail dot com  2009-09-17 09:46 ---
This is just expected behavior, documented for -mrecip.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug c++/41384] initialization failure of global const variable of template class which has a constructor initializing its member which is a pointer to member data when compiled with -O2

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-09-17 09:47 ---
GCC 3.4.6 is no longer maintained.  Please report to your distributor.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug target/34653] unnecessary REX prefix

[ubizjak at gmail dot com]

--- Comment #2 from ubizjak at gmail dot com  2009-09-17 09:50 ---
(In reply to comment #1)

> and in this case the "mov %rdx,%rax" could be "mov %edx,%eax" because of the
> dominating movzbl.

32bit moves and other instructions _SIGN_EXTEND_ results to 64bits on x86_64.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug bootstrap/41386] incorrect configure results in "The following requested languages could not be built: lto"

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-09-17 09:50 ---
Is it?  I guess the check for libelf fails instead, no?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org


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

[Bug tree-optimization/40676] [4.5 Regression] internal compiler error: verify_ssa error: definition in block 5 does not dominate use in block 7

[rguenth at gcc dot gnu dot org]

--- Comment #11 from rguenth at gcc dot gnu dot org  2009-09-17 09:51 
---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug target/34501] The vector cost model does not seem suited for Intel Core2Duo

[ubizjak at gmail dot com]

--- Comment #1 from ubizjak at gmail dot com  2009-09-17 09:52 ---
Adding H.J. to CC.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 CC||hjl dot tools at gmail dot
   ||com
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-09-17 09:52:01
   date||


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

[Bug middle-end/41385] [4.5 regression] Many regressions on trunk

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-09-17 09:53 ---
Works for me (r151791).  What's your excess errors?  I bet it is
sort of "no space left on device" or so.  If lto testing runs on the same
machine it easily will fill up your disk ...


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.5.0


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

[Bug target/33524] SSE5 vectorized SI->DI conversions broken

[ubizjak at gmail dot com]

--- Comment #4 from ubizjak at gmail dot com  2009-09-17 09:58 ---
SSE5 is no more.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX


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

[Bug target/33365] GCC test 20000804-1.c with -O0

[ubizjak at gmail dot com]

--- Comment #1 from ubizjak at gmail dot com  2009-09-17 10:00 ---
gcc 4.2.x is no longer supported.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX


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

[Bug testsuite/33366] 20050316-2.c execution failure with -O0, -O1 and -O2

[ubizjak at gmail dot com]

--- Comment #1 from ubizjak at gmail dot com  2009-09-17 10:00 ---
gcc 4.2.x is no longer supported.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX


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

[Bug testsuite/33367] A few tests fail

[ubizjak at gmail dot com]

--- Comment #3 from ubizjak at gmail dot com  2009-09-17 10:01 ---
gcc 4.2.x is no longer supported.


-- 


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

[Bug testsuite/33367] A few tests fail

[ubizjak at gmail dot com]

--- Comment #4 from ubizjak at gmail dot com  2009-09-17 10:02 ---
.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX


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

[Bug target/33010] bootstrap fails with assembler error

[ubizjak at gmail dot com]

--- Comment #1 from ubizjak at gmail dot com  2009-09-17 10:04 ---
This was fixed some time ago. Your target bootstraps ok on 4.4.x and 4.5.x.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug target/32803] -Os: shorter load immediates for x86_64

[ubizjak at gmail dot com]

--- Comment #1 from ubizjak at gmail dot com  2009-09-17 10:07 ---
All these sequences are _MUCH_ slower than load immediate, so the tradeoff is
not acceptable, even for -Os.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX


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

[Bug target/31363] long long optimization problem

[ubizjak at gmail dot com]

--- Comment #4 from ubizjak at gmail dot com  2009-09-17 10:12 ---
(In reply to comment #3)
> I could reproduce this with "4.0.4 20060622" but it works on the trunk.

So, fixed.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug target/34653] unnecessary REX prefix

[dean at arctic dot org]

--- Comment #3 from dean at arctic dot org  2009-09-17 10:23 ---
(In reply to comment #2)
> (In reply to comment #1)
> 
> > and in this case the "mov %rdx,%rax" could be "mov %edx,%eax" because of the
> > dominating movzbl.
> 
> 32bit moves and other instructions _SIGN_EXTEND_ results to 64bits on x86_64.
> 

every single data type in my example was unsigned.


-- 

dean at arctic dot org changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug target/28691] missed optimization, redundant scalar SSE comparisons

[ubizjak at gmail dot com]

--- Comment #5 from ubizjak at gmail dot com  2009-09-17 10:25 ---
Actually a duplicate of PR 28685.

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


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


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

[Bug middle-end/28685] Multiple comparisons are not simplified

[ubizjak at gmail dot com]

--- Comment #9 from ubizjak at gmail dot com  2009-09-17 10:25 ---
*** Bug 28691 has been marked as a duplicate of this bug. ***


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 CC||tbptbp at gmail dot com


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

[Bug target/34653] unnecessary REX prefix

[dean at arctic dot org]

--- Comment #4 from dean at arctic dot org  2009-09-17 10:27 ---
(In reply to comment #2)
> 32bit moves and other instructions _SIGN_EXTEND_ results to 64bits on x86_64

wait i just reread your statement.

the amd64 ISA zero-extends 32-bit register writes out to 64-bits.  please go
read the documentation.

-dean


-- 


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

[Bug target/32803] -Os: shorter load immediates for x86_64

[dean at arctic dot org]

--- Comment #2 from dean at arctic dot org  2009-09-17 10:28 ---
stop closing bugs you have no understanding of.


-- 

dean at arctic dot org changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|WONTFIX |


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

[Bug target/26650] unaligned (SSE) stack access, smashing

[ubizjak at gmail dot com]

--- Comment #8 from ubizjak at gmail dot com  2009-09-17 10:29 ---
Gcc <= 4.2.x are not supported anymore (BTW: A lot of aligmnent fixes went into
gcc-4.4.x, so there is a big chance of bug being fixed there).


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX


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

[Bug target/21408] DAZ related macros are improperly guarded in pmmintrin.h

[ubizjak at gmail dot com]

--- Comment #4 from ubizjak at gmail dot com  2009-09-17 10:32 ---
So, wontfix.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX


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

[Bug middle-end/41385] [4.5 regression] Many regressions on trunk

[dominiq at lps dot ens dot fr]

--- Comment #3 from dominiq at lps dot ens dot fr  2009-09-17 10:39 ---
See also http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg01511.html .


-- 


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

[Bug target/32803] -Os: shorter load immediates for x86_64

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-09-17 10:40 ---
For the push/pop you need to add 2 bytes to the CFI which makes it useless
compared to mov $imm32,reg.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement


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

[Bug middle-end/41385] [4.5 regression] Many regressions on trunk

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2009-09-17 10:42 ---
Also not terribly useful without knowing what the excess errors are.
Again, works for me on i?86 and x86_64 linux.


-- 


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

[Bug target/32803] -Os: shorter load immediates for x86_64

[dean at arctic dot org]

--- Comment #4 from dean at arctic dot org  2009-09-17 10:51 ---
(In reply to comment #3)
> For the push/pop you need to add 2 bytes to the CFI which makes it useless
> compared to mov $imm32,reg.
> 

note that my push/pop example said -128..127 and "push $imm8"... not imm32.

GNU assembler version 2.18.0 (x86_64-linux-gnu) using BFD version (GNU Binutils
for Ubuntu) 2.18.0.20080103

% cat t.S
mov $0x7f,%eax
push $0x7f
pop %rax
% objdump -dr t.o
...
 <.text>:
   0:   b8 7f 00 00 00  mov$0x7f,%eax
   5:   6a 7f   pushq  $0x7f
   7:   58  pop%rax

i count 5 bytes vs. 3 bytes.

similarly:

   0:   b8 80 ff ff ff  mov$0xff80,%eax
   5:   6a 80   pushq  $0xff80
   7:   58  pop%rax

-dean


-- 


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

[Bug target/32803] -Os: shorter load immediates for x86_64

[dean at arctic dot org]

--- Comment #5 from dean at arctic dot org  2009-09-17 10:54 ---
(In reply to comment #4)
>0:   b8 80 ff ff ff  mov$0xff80,%eax
>5:   6a 80   pushq  $0xff80
>7:   58  pop%rax
> 

should be:

   0:   48 c7 c0 80 ff ff ffmov$0xff80,%rax
   7:   6a 80   pushq  $0xff80
   9:   58  pop%rax

7 vs. 3 bytes.

have to get that signed vs. zero-extension correct.

-dean


-- 


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

[Bug target/32803] -Os: shorter load immediates for x86_64

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2009-09-17 10:57 ---
Without accounting for the push/pop in CFI you will not be able to accurately
process asynchronous unwind events.


-- 


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

[Bug target/20952] gmake -k check failures

[ubizjak at gmail dot com]

--- Comment #1 from ubizjak at gmail dot com  2009-09-17 11:04 ---
gcc 4.0.0 is not supported anymore.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX


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

[Bug target/32803] -Os: shorter load immediates for x86_64

[dean at arctic dot org]

--- Comment #7 from dean at arctic dot org  2009-09-17 11:06 ---
(In reply to comment #6)
> Without accounting for the push/pop in CFI you will not be able to accurately
> process asynchronous unwind events.
> 

just to be sure i understand -- you're saying a %rsp modification in a binary
which requires unwind information is not a space savings.  that's fine with me,
but not all binaries have unwind information.

-dean


-- 


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

[Bug target/15319] [x86] ICE in change_stack, at reg-stack.c:2299

[ubizjak at gmail dot com]

--- Comment #3 from ubizjak at gmail dot com  2009-09-17 11:08 ---
(In reply to comment #2)

> According to these rules, your asm should be written as:
> 
>   asm ("fmulp": "=t" (ret): "0" (ret), "u" (tmp): "st(1)");

So, invalid.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID


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

[Bug middle-end/41347] [4.5 Regression] ICE with -O3 or '-O2 -finline-functions'

[matz at gcc dot gnu dot org]

--- Comment #7 from matz at gcc dot gnu dot org  2009-09-17 11:12 ---
Subject: Bug 41347

Author: matz
Date: Thu Sep 17 11:11:58 2009
New Revision: 151799

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151799
Log:
PR middle-end/41347
* tree.c (build_type_attribute_qual_variant): Export.
* tree.h (build_type_attribute_qual_variant): Declare.
* tree-inline.c (remap_type_1): Use it to build variants with
the original qualifiers and attributes.

testsuite/
* gfortran.dg/pr41347.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr41347.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-inline.c
trunk/gcc/tree.c
trunk/gcc/tree.h


-- 


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

[Bug middle-end/41347] [4.5 Regression] ICE with -O3 or '-O2 -finline-functions'

[matz at gcc dot gnu dot org]

--- Comment #8 from matz at gcc dot gnu dot org  2009-09-17 11:14 ---
Fixed.


-- 

matz at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug target/32803] -Os: shorter load immediates for x86_64

[ubizjak at gmail dot com]

--- Comment #8 from ubizjak at gmail dot com  2009-09-17 11:32 ---
(In reply to comment #2)
> stop closing bugs you have no understanding of.

Then please explain, how you plan to avoid:

a) partial register stall in the case of mov $X, al:

put your explanation here ->

b) partial flag stall in case of BTS:

put your explanation here ->


-- 


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

[Bug c/41388] New: -Wlogical-op produces a surprising message

[Denis dot Excoffier at airbus dot com]

With the following C fragment, compiled with the option -Wlogical-op,
one obtains:

main.c:1006: warning: logical '&&' with non-zero constant will always evaluate
as true

This message is surprising because a non-zero constant does not
prevent any global '&&' expression to return either true or false,
depending on the other operands.

Instead, i could have expected the following messages:

main.c: In function 'main':
main.c:1000: warning: logical '&&' with zero constant will always evaluate as
false
main.c:1009: warning: logical '||' with non-zero constant will always evaluate
as true

This behavior is consistent through at least GCC 4.3.2 and GCC 4.4.1, and also
through Cygwin-1.7, Solaris2.8 and Solaris2.10 (checked 4 configurations).
Also in C++.

Fragment is:
---
#include 

//
int main(/*unsigned*/ int const argc, char const *const *const argv) {
//
# line 1000
  if (0 && (argc != 1) && (argc != 2) && 0) {
fprintf(stderr, "argc=%u\n", argc);
  };
  if (0 || (argc == 1) || (argc == 2) || 0) {
fprintf(stderr, "argc=%u\n", argc);
  };
  if (1 && (argc != 1) && (argc != 2) && 1) {
fprintf(stderr, "argc=%u\n", argc);
  };
  if (1 || (argc == 1) || (argc == 2) || 1) {
fprintf(stderr, "argc=%u\n", argc);
  };
  return(0);
}
-


-- 
   Summary: -Wlogical-op produces a surprising message
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Denis dot Excoffier at airbus dot com
 GCC build triplet: sparc-sun-solaris2.8
  GCC host triplet: sparc-sun-solaris2.8
GCC target triplet: sparc-sun-solaris2.8


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

[Bug target/36680] ICE in spill_failure, reload1.c:1995

[ubizjak at gmail dot com]

--- Comment #3 from ubizjak at gmail dot com  2009-09-17 11:55 ---
Is this failure still triggered with recent mainline after
http://gcc.gnu.org/ml/gcc-cvs/2009-09/msg00094.html ?


-- 


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

[Bug bootstrap/41386] incorrect configure results in "The following requested languages could not be built: lto"

[marcus at jet dot franken dot de]

--- Comment #2 from marcus at jet dot franken dot de  2009-09-17 12:04 
---
Created an attachment (id=18600)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18600&action=view)
config.log

config.log from such a run (a different machine, same result).

libelf seems fine


-- 


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

[Bug target/27432] -fschedule-insns -O2 -march=athlon cause compilation error

[ubizjak at gmail dot com]

--- Comment #9 from ubizjak at gmail dot com  2009-09-17 12:04 ---
This testcase works with 4.3.4, 4.4.2 and 4.5.0.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WORKSFORME


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

[Bug target/16185] ICE: in spill_failure, at reload1.c:1892, global registers and long long

[ubizjak at gmail dot com]

--- Comment #17 from ubizjak at gmail dot com  2009-09-17 12:13 ---
A recent patch in mainline should fix this problem [1]. The testcase works OK
for 4.3.4, 4.4.2 and 4.5.0. Please re-test with current mainline SVN and open a
new PR if the test still fails.

[1] http://gcc.gnu.org/ml/gcc-patches/2009-09/msg3.html


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WORKSFORME


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

[Bug target/31006] long double constant is read as double in i386

[ubizjak at gmail dot com]

--- Comment #6 from ubizjak at gmail dot com  2009-09-17 12:46 ---
Your d_a is defined as double, so gcc truncates constant to fit in the "double"
value range. After that, you pass this double value as an argument to %Lf,
which is wrong. You should write:

printf("long double - double double = %+5.30Lf\n", (long double) d_a);

As far as your testcse is concerned, there is no error, truncation from long
double to double is what you requested with "double" intermediate register.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug target/38120] missing space in x86 assembly code for some mov instructions

[ubizjak at gmail dot com]

--- Comment #2 from ubizjak at gmail dot com  2009-09-17 12:56 ---
This is actually fixed in 4.5.0.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug middle-end/41354] g++: Inlining constructors puts wrong vtable in objects

[mikpe at it dot uu dot se]

--- Comment #4 from mikpe at it dot uu dot se  2009-09-17 13:23 ---
Confirmed with gcc-4.4.1 and gcc-4.3.4 on armv5tel-unknown-linux-gnueabi.
I've not been able to trigger it with gcc-4.4.1 on i686-linux, powerpc-linux,
or sparc64-solaris, so it looks ARM-specific.

I'll check if there's a fix upstream, or failing that, if I can identify the
commit that introduced the bug.


-- 


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

[Bug testsuite/41385] [4.5 regression] Many regressions on trunk

[hjl dot tools at gmail dot com]

--- Comment #5 from hjl dot tools at gmail dot com  2009-09-17 13:25 ---
The failure looks like

Executing on host: /export/build/gnu/gcc/build-i686-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-i686-linux/gcc/
/net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gcc.dg/tls/alias-1.c  
DEFAULT_CFLAGS  -lm   -o alias-1.exe(timeout = 300)xgcc: DEFAULT_CFLAGS: No
such file or directory^M
compiler exited with status 1
output is:
xgcc: DEFAULT_CFLAGS: No such file or directory^M


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

  Component|middle-end  |testsuite
   Target Milestone|4.5.0   |---


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

[Bug libfortran/41387] OPEN, STATUS='NEW' of a symbolic link to a non-existing file fails.

[toon at moene dot org]

--- Comment #1 from toon at moene dot org  2009-09-17 13:26 ---
Perhaps the system call 'access' can provide help here.

>From the man page (man 2 access):

access() checks whether the calling process can access the file pathname.
If pathname is a symbolic link, it is dereferenced.

The  mode  specifies the accessibility check(s) to be performed, and is either
the value F_OK, or a mask consisting of the bitwise OR of one or more of R_OK,
W_OK, and X_OK.

F_OK tests for the existence of the file.


-- 


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

[Bug middle-end/41385] [4.5 regression] Many regressions on trunk

[jakub at gcc dot gnu dot org]

--- Comment #6 from jakub at gcc dot gnu dot org  2009-09-17 13:33 ---
I also saw this with r151791, both on x86_64-linux and i686-linux, though for
far fewer testcases.
The regressions all look like:
Executing on host: /usr/src/gcc/obj427/gcc/xgcc -B/usr/src/gcc/obj427/gcc/
/usr/src/gcc/gcc/testsuite/gcc.dg/tls/diag-5.c   DEFAULT_CFLAGS -S  -o diag-5.s
   (timeout = 300)
xgcc: DEFAULT_CFLAGS: No such file or directory

so I guess this is a recent testsuite bug (I'm using make -j48 -k check).
Last working  make check was with 20090916 trunk, though I don't remember exact
revision.

I guess the bug is in:
http://gcc.gnu.org/viewcvs/trunk/gcc/testsuite/gcc.dg/dfp/dfp.exp?r1=151764&r2=151763&pathrev=151764
I'd say
set save_default_cflags DEFAULT_CFLAGS
should read
set save_default_cflags $DEFAULT_CFLAGS

Will test it.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||janis at gcc dot gnu dot org
  Component|testsuite   |middle-end
   Target Milestone|--- |4.5.0


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

[Bug middle-end/41385] [4.5 regression] Many regressions on trunk

[hjl at gcc dot gnu dot org]

--- Comment #7 from hjl at gcc dot gnu dot org  2009-09-17 13:36 ---
Subject: Bug 41385

Author: hjl
Date: Thu Sep 17 13:36:06 2009
New Revision: 151803

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151803
Log:
2009-09-17  H.J. Lu  

PR testsuite/41385
* gcc.dg/dfp/dfp.exp: Properly save DEFAULT_CFLAGS.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/dfp/dfp.exp


-- 


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

[Bug testsuite/41385] [4.5 regression] Many regressions on trunk

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
  Component|middle-end  |testsuite
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-09-17 13:36:41
   date||


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

[Bug target/34653] unnecessary REX prefix

[hjl dot tools at gmail dot com]

--- Comment #5 from hjl dot tools at gmail dot com  2009-09-17 13:47 ---
This is a dup for PR 17387.

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


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug rtl-optimization/17387] Redundant zero extension instructions in loop optimization

[hjl dot tools at gmail dot com]

--- Comment #26 from hjl dot tools at gmail dot com  2009-09-17 13:47 
---
*** Bug 34653 has been marked as a duplicate of this bug. ***


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||dean at arctic dot org


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

[Bug middle-end/41365] [4.5 Regression] gcc.dg/vect/vect-cond-[123].c abort due to bad code generation at -O1 and above

[bernds_cb1 at t-online dot de]

--- Comment #2 from bernds_cb1 at t-online dot de  2009-09-17 14:24 ---
Created an attachment (id=18601)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18601&action=view)
A patch that fixes the immediate problem

This is a bug in the ia64 backend, which puts autoinc addressing modes into
COND_EXECs, failing to notice that they have side effects.

This part of the problem can be fixed with the patch I'm attaching, but it
doesn't work: the rest of the ia64 backend expects that this kind of insn can
always be split.

At this point I'm leaving it for an ia64 maintainer to fix.


-- 


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

[Bug libfortran/41387] OPEN, STATUS='NEW' of a symbolic link to a non-existing file fails.

[kargl at gcc dot gnu dot org]

--- Comment #2 from kargl at gcc dot gnu dot org  2009-09-17 14:59 ---
This is opening a can of worms.

ln -s aap noot
touch app

program a
  open(unit=10, file='noot', status='old')
  write(10,'(A)') 'Deleted file'
  close(10, status='delete')
end program a

Please audit all Fortran constructs that operate on a
unit= or file=.  You'll also need to audit all of the intrinsic
procedures in libgfortran that operate on a unit= or file=
entity.  When/if an intrinsic procedure is changed to give
consistent behavior on a symlink, please make sure that you
maintain backwards compatibility with g77.

The behavior of a symlink is not specified in any Fortran standard.
This is clearly processor dependent behavior, and should be left
alone.  I'll also note that a symlink does not need to point to
a file to be useful.  See FreeBSD's malloc/free implementation for
an example.


-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu dot org
   Severity|normal  |enhancement
   Priority|P3  |P5


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

[Bug middle-end/41354] g++: Inlining constructors puts wrong vtable in objects

[mikpe at it dot uu dot se]

--- Comment #5 from mikpe at it dot uu dot se  2009-09-17 16:18 ---
Appears fixed in gcc-4.5-20090910, but not in gcc-4.4-20090915. I'll start a
binary search to see what fixed it (I have a suspicion already).


-- 


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

[Bug bootstrap/38591] erratic comparison failures on very fast machines

[rwild at gcc dot gnu dot org]

--- Comment #8 from rwild at gcc dot gnu dot org  2009-09-17 16:27 ---
Does this also happen on trunk, or with branch-4_3 only?  AFAICS 4.3.3 had
  sparseset.o: sparseset.c $(SYSTEM_H) sparseset.h

in gcc/Makefile.in, which means it was lacking $(CONFIG_H) thus lacking
dependency on auto-host.h.  This was fixed in

and glancing at that patch, there may be quite a few other dependency issues
in branch-4_3.

No idea why the borked build does not fail but pick up auto-host.h from
elsewhere or so.  Or do you know for sure that auto-host.h was picked up
from the current directory?


-- 

rwild at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rwild at gcc dot gnu dot org


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

[Bug bootstrap/38591] erratic comparison failures on very fast machines

[ebotcazou at gcc dot gnu dot org]

--- Comment #9 from ebotcazou at gcc dot gnu dot org  2009-09-17 16:58 
---
> in gcc/Makefile.in, which means it was lacking $(CONFIG_H) thus lacking
> dependency on auto-host.h.  This was fixed in
> 
> and glancing at that patch, there may be quite a few other dependency issues
> in branch-4_3.

Thanks, will try to add the missing dependency.

> No idea why the borked build does not fail but pick up auto-host.h from
> elsewhere or so.  Or do you know for sure that auto-host.h was picked up
> from the current directory?

Couldn't a truncated auto-host.h have been picked up?


-- 


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

[Bug target/35294] iwmmxt intrinsics, internal compiler error

[rearnsha at gcc dot gnu dot org]

--- Comment #8 from rearnsha at gcc dot gnu dot org  2009-09-17 17:03 
---
The assertion in the source is clearly broken if a constant can legally be
passed to it.  If a constant can't legally be passed, then the caller needs to
be fixed to diagnose it before we reach this point.


-- 

rearnsha at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|FIXED   |


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

[Bug target/35294] iwmmxt intrinsics, internal compiler error

[rearnsha at gcc dot gnu dot org]

-- 

rearnsha at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-09-17 17:04:07
   date||


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

[Bug fortran/41389] New: problem compiling file

[clerman at fuse dot net]

to the gfortran development team,

  Here is a file that I am trying to compile:

module exceptions

  ! Purpose: module for the program-wide exceptions

  ! Author: N. S. Clerman

  ! Notes:
  ! =

  ! N. S. Clerman, 5 Sept. 2009: there is a problem here. Calls are made to
Set_flag, which is not pure. No procedure that
  ! invokes it can be pure. I need to check the Fortran exception handling to
see what happens. (I would think that not
  ! the case.) The exceptions themselves -- exception_array -- are private, so
I think I could potentially be calling
  ! this simultaneously from more than one thread, but how do I handle the case
where one thread is setting the flag to
  ! SIGNALLING and another to QUIET?

  implicit none
  private

  public :: Get_flag, Set_flag

!  public :: UNKNOWN_INDEX, BAD_YEAR_INDEX, BAD_MONTH_INDEX, BAD_DAY_INDEX,
BAD_DATE_INDEX
!  public :: READ_ERROR_INDEX, FILE_OPEN_ERROR_INDEX, BAD_PRICE_INDEX,
BAD_NO_OF_SHARES_INDEX
!  public :: BAD_TRANSACTION_INDEX, UNOPENED_PORTFOLIO_INDEX,
EMPTY_PORTFOLIO_INDEX
!  public :: PORTFOLIO_OPENED_INDEX, BAD_PORTFOLIO_NAME_INDEX
!  public :: LAST_INDEX, ALLOCATION_ERROR_INDEX

  logical, public, parameter :: QUIET = .false., SIGNALLING = .true.

  type, public :: exception_t
logical :: flag = QUIET
  end type exception_t

  type, private :: exception_flag_t
integer :: flag_index
  end type exception_flag_t

  enum, bind(c)
enumerator :: UNKNOWN_INDEX, BAD_YEAR_INDEX, BAD_MONTH_INDEX,
BAD_DAY_INDEX, BAD_DATE_INDEX , &
 READ_ERROR_INDEX, FILE_OPEN_ERROR_INDEX, BAD_PRICE_INDEX,
BAD_NO_OF_SHARES_INDEX, &
 BAD_TRANSACTION_INDEX, UNOPENED_PORTFOLIO_INDEX,
EMPTY_PORTFOLIO_INDEX, &
 PORTFOLIO_OPENED_INDEX, BAD_PORTFOLIO_NAME_INDEX,
ALLOCATION_ERROR_INDEX, EMPTY_INVESTOR_INDEX, &

 LAST_INDEX
  end enum

  ! UNKNOWN_FLAG -
  ! BAD_YEAR_FLAG - year is out of exceptable range
  ! BAD_MONTH_FLAG - month is out of range
  ! BAD_DAY_FLAG - day is out of range
  ! BAD_DATE_FLAG - date is out of range
  ! READ_ERROR_FLAG - problem reading with read statement
  ! FILE_OPEN_ERROR_FLAG - problem opening a file with the open statement.
  ! BAD_PRICE_FLAG - negative price
  ! BAD_NO_OF_SHARES_FLAG -
  ! BAD_TRANSACTION_FLAG -
  !

  type (exception_flag_t), public, parameter :: &
   UNKNOWN_FLAG= exception_flag_t (UNKNOWN_INDEX),   &
   BAD_YEAR_FLAG   = exception_flag_t (BAD_YEAR_INDEX),  &
   BAD_MONTH_FLAG  = exception_flag_t (BAD_MONTH_INDEX), &
   BAD_DAY_FLAG= exception_flag_t (BAD_DAY_INDEX),   &
   BAD_DATE_FLAG   = exception_flag_t (BAD_DATE_INDEX),  &
   READ_ERROR_FLAG = exception_flag_t (READ_ERROR_INDEX), &
   FILE_OPEN_ERROR_FLAG = exception_flag_t (FILE_OPEN_ERROR_INDEX), &
   BAD_PRICE_FLAG   = exception_flag_t (BAD_PRICE_INDEX), &
   BAD_NO_OF_SHARES_FLAG   = exception_flag_t (BAD_NO_OF_SHARES_INDEX), &
   BAD_TRANSACTION_FLAG= exception_flag_t (BAD_TRANSACTION_INDEX), &
   EMPTY_PORTFOLIO_FLAG= exception_flag_t (EMPTY_PORTFOLIO_INDEX), &
   PORTFOLIO_OPENED_FLAG   = exception_flag_t (PORTFOLIO_OPENED_INDEX), &
   BAD_PORTFOLIO_NAME_FLAG = exception_flag_t (BAD_PORTFOLIO_NAME_INDEX), &
   ALLOCATION_ERROR_FLAG   = exception_flag_t (ALLOCATION_ERROR_INDEX), &
   EMPTY_INVESTOR_FLAG = exception_flag_t (EMPTY_INVESTOR_INDEX)

  type (exception_t), save :: exception_array(0: LAST_INDEX - 1)

contains

  elemental function Get_flag (flag_) result (return_value)

type (exception_flag_t), intent (in) :: flag_
logical :: return_value

if (lbound (exception_array, dim = 1) <= flag_% flag_index .and. flag_%
flag_index <= ubound (exception_array, dim = 1) ) &
 return_value = exception_array (flag_% flag_index) % flag

  end function Get_flag

  subroutine Set_flag (flag_, passed_value_)

type (exception_flag_t), intent (in) :: flag_
logical, intent (in) :: passed_value_

if (lbound (exception_array, dim = 1) <= flag_% flag_index .and. flag_%
flag_index <= ubound (exception_array, dim = 1) ) &
 exception_array(flag_% flag_index) = exception_t (passed_value_)

  end subroutine Set_flag

end module exceptions

here is the output of the compilaton:

n...@oxford:~/allocator> cat exceptions.gfortran.xyz
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /home/tob/projects/gcc-trunk-checkout/configure
--with-gmp-lib=/home/tob/projects/gcc-build/lib-aux
--with-mpfr-lib=/home/tob/projects/gcc-build/lib-aux
--with-mpc-lib=/home/tob/projects/gcc-build/lib-aux
--enable-languages=c,fortran,c++ --prefix=/projects/tob/gcc-trunk
Thread model: posix
gcc version 4.5.0 20090917 (experimental) [trunk revision 151786] (GCC)
COLLECT_GCC_OPTIONS='-c' '-g' '-Wall' '-std=f2003' '-O0' '-v' '-mtune=generic'
 /opt/gfortran/gcc-

[Bug c/41049] conversion from integer to decimal float loses trailing zeros

[janis at gcc dot gnu dot org]

--- Comment #1 from janis at gcc dot gnu dot org  2009-09-17 17:07 ---
Subject: Bug 41049

Author: janis
Date: Thu Sep 17 17:07:24 2009
New Revision: 151806

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151806
Log:
gcc/
PR c/41049
* real.c decimal_from_integer, decimal_integer_string): New.
(real_from_integer): Use them as special case for decimal float.
* config/dfp-bit.c (_si_to_sd, _usi_to_sd): Use default rounding.
(_di_to_sd, _di_to_dd, _di_to_td, _udi_to_sd, _udi_to_dd, _udi_to_td):
Do not append zero after the decimal point in string to convert.
gcc/testsuite/
PR c/41049
* dfp/pr41049.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/dfp/pr41049.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/dfp-bit.c
trunk/gcc/real.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug bootstrap/38591] erratic comparison failures on very fast machines

[Ralf dot Wildenhues at gmx dot de]

--- Comment #10 from Ralf dot Wildenhues at gmx dot de  2009-09-17 17:40 
---
Subject: Re:  erratic comparison failures on very fast
 machines

* ebotcazou at gcc dot gnu dot org wrote on Thu, Sep 17, 2009 at 06:58:37PM
CEST:
> > No idea why the borked build does not fail but pick up auto-host.h from
> > elsewhere or so.  Or do you know for sure that auto-host.h was picked up
> > from the current directory?
> 
> Couldn't a truncated auto-host.h have been picked up?

config.status uses mv from a temporary subdirectory to the final
location of the file, thus create it created atomically.  Autoconf 2.59
did this too.


-- 


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

[Bug libfortran/41387] OPEN, STATUS='NEW' of a symbolic link to a non-existing file fails.

[jvdelisle at gcc dot gnu dot org]

--- Comment #3 from jvdelisle at gcc dot gnu dot org  2009-09-17 19:15 
---
I agree, this is enhancement only.  Code that relies on or expects consistent
behavior when the users has created and symlink is likely not protable.  See

http://gcc.gnu.org/ml/fortran/2009-09/msg00107.html as examples


-- 


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

[Bug lto/41390] New: [LTO] ICE in lto_output_tree_pointers, at lto-streamer-out.c:1285

[rmansfield at qnx dot com]

$ cat t.c
int t() __attribute__ ((optimize("O1")));

int t() { }

$ ./xgcc -v
Using built-in specs.
COLLECT_GCC=./xgcc
Target: i686-pc-linux-gnu
Configured with: ../configure --enable-languages=c++ --enable-lto
--disable-bootstrap
Thread model: posix
gcc version 4.5.0 20090914 (experimental) [lto revision 151812] (lto merged
with rev 150842)

$ ./xgcc -B. -flto t.c
t.c:3:1: internal compiler error: in lto_output_tree_pointers, at
lto-streamer-out.c:1285
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: [LTO] ICE in lto_output_tree_pointers, at lto-streamer-
out.c:1285
   Product: gcc
   Version: lto
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rmansfield at qnx dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug libfortran/41387] OPEN, STATUS='NEW' of a symbolic link to a non-existing file fails.

[toon at moene dot org]

--- Comment #4 from toon at moene dot org  2009-09-17 19:57 ---
In response to reply 2 (thanks Steve), we might be able to exploit the system
call access to at least solve the inconsistency between INQUIRE and OPEN:

man 2 access

   ENOENT A component of pathname does not exist or is a dangling symbolic
  link.

IOW, if we check for this (instead of requesting a stat buffer), we might be
able to answer the question consistently with OPEN.

See libgfortran/io/unix.c:

   1376 /* file_exists()-- Returns nonzero if the current filename exists on
   1377  * the system */
   1378 
   1379 int
   1380 file_exists (const char *file, gfc_charlen_type file_len)
   1381 {
   1382   char path[PATH_MAX + 1];
   1383   struct stat statbuf;
   1384 
   1385   if (unpack_filename (path, file, file_len))
   1386 return 0;
   1387 
   1388   if (stat (path, &statbuf) < 0)
   1389 return 0;
   1390 
   1391   return 1;


-- 


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

[Bug fortran/41389] problem compiling file

[dominiq at lps dot ens dot fr]

--- Comment #1 from dominiq at lps dot ens dot fr  2009-09-17 20:08 ---
4.2.4 gives

pr41389.f90:19.20:

  public :: Get_flag, Set_flag
   1
Error: 'flag_' is of a PRIVATE type and cannot be a dummy argument of
'get_flag', which is PUBLIC at (1)

probably a bug fixed since then, but the code compiles for me
(i686-apple-darwin9) with 4.3.4, 4.4.1 and trunk revision 151771.


-- 


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

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[dominiq at lps dot ens dot fr]

--- Comment #4 from dominiq at lps dot ens dot fr  2009-09-17 20:34 ---
Between revisions 151150 (-m64 only) and 151446 (both -m32 and -m64) the test
has started to fail also in 32 bit mode with a different wrong result:

karma] f90/bug% gfc -O3 where_2.f90
[karma] f90/bug% a.out 
 100 100 100 210 210 210   
 310 337 310 310
Abort

(see also http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg00830.html).

Now between revision 151644 (both for sure, but probably up to 151730 IIRC) and
151771 (-m32 only) the test now passes with -m64:

[karma] f90/bug% gfc -m64 -O3 where_2.f90
[karma] f90/bug% a.out
 100 100 100 210 210 210   
 310 310 337 337


-- 


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

[Bug target/38288] i386/i386.c: 7 * set but not used variables

[dcb314 at hotmail dot com]

--- Comment #5 from dcb314 at hotmail dot com  2009-09-17 20:35 ---
(In reply to comment #4)
> Is the patch from Comment #3 committed to SVN?

I don't think so. I wouldn't know how to do that,
and I don't think anyone has done it for me.


-- 


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

[Bug target/18274] Documentation for -mhard-float on arm platforms is incorrect

[ramana at gcc dot gnu dot org]

--- Comment #2 from ramana at gcc dot gnu dot org  2009-09-17 20:43 ---
This is now fixed given that we now have in trunk.


@item -mhard-float
@opindex mhard-float
Equivalent to @option{-mfloat-abi=hard}.

 I believe this was fixed in the 4.4.0 release by this commit 
http://gcc.gnu.org/viewcvs?view=revision&revision=140179 .


-- 

ramana at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[dominiq at lps dot ens dot fr]

--- Comment #5 from dominiq at lps dot ens dot fr  2009-09-17 20:54 ---
At revision 151771 the test in the test suite still fails at -m64, but passes
with the addition of the print:

--- where_2.f90 2005-07-04 08:24:26.0 +0200
+++
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.fortran-torture/execute/where_2.f90 
2007-11-21 20:23:35.0 +0100
@@ -17,7 +17,6 @@
   temp = 300 + temp
END WHERE

-   print *, temp
if (any (temp .ne. (/100, 100, 100, 210, 210, 210, 310, 310, 337, 337/))) &
   call abort
 end program


-- 


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

[Bug testsuite/32843] [4.3 Regression] : libffi.call/return_sc.c

[ljrittle at gcc dot gnu dot org]

--- Comment #18 from ljrittle at gcc dot gnu dot org  2009-09-17 20:55 
---
Subject: Bug 32843

Author: ljrittle
Date: Thu Sep 17 20:54:56 2009
New Revision: 151819

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151819
Log:
2009-09-17  Loren J. Rittle  

PR testsuite/32843 (strikes again)
* src/x86/ffi.c (ffi_prep_cif_machdep): Add X86_FREEBSD to
enable proper extension on char and short.

Modified:
trunk/libffi/ChangeLog
trunk/libffi/src/x86/ffi.c


-- 


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

[Bug c++/39365] ++ operator with volatile bool increments

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2009-09-17 23:04 ---
Subject: Bug 39365

Author: pinskia
Date: Thu Sep 17 23:03:55 2009
New Revision: 151823

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151823
Log:
2009-09-17  Andrew Pinski  

PR c++/39365
* typeck.c (cp_build_unary_op): Check TREE_CODE for bools instead of
using same_type_p.
(convert_for_assignment): Likewise.
* cvt.c (type_promotes_to): Likewise.

2009-09-17  Andrew Pinski  

PR c++/39365
* g++.dg/expr/bool3.C: New test.
* g++.dg/expr/bool4.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/expr/bool3.C
trunk/gcc/testsuite/g++.dg/expr/bool4.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cvt.c
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/39365] ++ operator with volatile bool increments

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2009-09-17 23:10 ---
Fixed.  


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug bootstrap/41391] New: gcc fails to compile because of missung fenv.h

[niki dot waibel at gmx dot net]

gcc fails to compile, because solaris8/9 do not have fenv.h. funnily enough gcc
compiles after 'touch /usr/include/fenv.h', but i feel that can't be a
solution. 

i am currently trying to reproduce this to report the exact error message. it
will take a while, as i have only pretty old hw available.


-- 
   Summary: gcc fails to compile because of missung fenv.h
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: niki dot waibel at gmx dot net
 GCC build triplet: sparc-sun-solaris2.9 and sparc-sun-solaris2.8
  GCC host triplet: sparc-sun-solaris2.9 and sparc-sun-solaris2.8
GCC target triplet: sparc-sun-solaris2.9 and sparc-sun-solaris2.8


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

[Bug target/40913] hppa-hpux: libgcc_s.sl does not have the 'internal name' (=soname) set

[danglin at gcc dot gnu dot org]

--- Comment #1 from danglin at gcc dot gnu dot org  2009-09-18 00:03 ---
Subject: Bug 40913

Author: danglin
Date: Fri Sep 18 00:03:19 2009
New Revision: 151826

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151826
Log:
PR target/40913
* config/pa/t-hpux-shlib: Set soname in libgcc_s.sl.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/pa/t-hpux-shlib


-- 


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

[Bug target/40913] hppa-hpux: libgcc_s.sl does not have the 'internal name' (=soname) set

[danglin at gcc dot gnu dot org]

--- Comment #2 from danglin at gcc dot gnu dot org  2009-09-18 00:09 ---
Fixed on trunk.  Might backport to 4.3 and 4.4 later.


-- 

danglin at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug testsuite/40534] FAIL: gcc.dg/vector-4.c (test for excess errors)

[danglin at gcc dot gnu dot org]

--- Comment #1 from danglin at gcc dot gnu dot org  2009-09-18 00:18 ---
No longer fails.


-- 

danglin at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug testsuite/40531] FAIL: gcc.c-torture/execute/20090618-1.c compilation, -O0

[danglin at gcc dot gnu dot org]

--- Comment #2 from danglin at gcc dot gnu dot org  2009-09-18 00:23 ---
Test is now skipped at -O0.


-- 

danglin at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug bootstrap/41391] gcc fails to compile because of missung fenv.h

[niki dot waibel at gmx dot net]

--- Comment #1 from niki dot waibel at gmx dot net  2009-09-18 00:36 ---
sorry, but i can't reproduce this. on another solaris8 system (without fenv.h)
gcc compiled fine -- this time with (initial) gcc-4.4.1 (which was built using
'touch /usr/include/fenv.h')


-- 

niki dot waibel at gmx dot net changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug target/40535] [4.5 regression] Invalid conversion from 'T' to 'T' error when compiling C++ code

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2009-09-18 00:36 ---
I think this deals with how the attribute __stdcall__ is handled on types.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|c++ |target


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

[Bug middle-end/21374] [4.3/4.4/4.5 regression] ICE with nested function

[pinskia at gcc dot gnu dot org]

--- Comment #12 from pinskia at gcc dot gnu dot org  2009-09-18 00:38 
---
We get a different ICE on the trunk:
unhandled expression in get_expr_operands():
 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21374

[Bug middle-end/21374] [4.3/4.4/4.5 regression] ICE with nested function

[pinskia at gcc dot gnu dot org]

--- Comment #13 from pinskia at gcc dot gnu dot org  2009-09-18 00:40 
---
  *b.9 = [with_size_expr] WITH_SIZE_EXPR ;

When is WITH_SIZE_EXPR supposed to be resolved?


-- 


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

[Bug c/41392] New: gcc.dg/torture/stackalign/builtin-apply-4.c fails with -march=pentium3

[ppluzhnikov at google dot com]

GCC built from @151825:

gcc-svn-install/bin/gcc  -m32 builtin-apply-4.c  -O0 -march=pentium3 && ./a.out
 Aborted (core dumped)


-- 
   Summary: gcc.dg/torture/stackalign/builtin-apply-4.c fails with -
march=pentium3
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ppluzhnikov at google dot com
 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=41392