--- Comment #8 from martin at mpa-garching dot mpg dot de 2005-11-11 07:46
---
The bug seems to have disappeared from current mainline and is not present
on gomp branch either. Should it be closed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19669
--- Comment #25 from ebotcazou at gcc dot gnu dot org 2005-11-11 07:44
---
Created an attachment (id=10212)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10212&action=view)
C testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24003
--- Comment #24 from ebotcazou at gcc dot gnu dot org 2005-11-11 07:43
---
> Do we have a C/C++ testcase for this problem?
Yes, we do, attached.
> I'm going to leave this as P2 for now, given that we think it's not
> language-dependent, and given that we seem close to a fix.
Pretty s
Consider
program b
integer w
character(len=2) s
s = 'xi'
w = scan(s, 'iI')
print *, s, w
end program b
When compiled and executed, this should produce "xi 2".
Here is NAG's F95 results.
kargl[280] f95 -o z scan1.f90
kargl[281] ./z
xi 2
Here's the incorrect gfortran results.
kar
--- Comment #6 from philippe_ribet at hotmail dot com 2005-11-11 07:22
---
Removed this email, someone added it by error.
--
philippe_ribet at hotmail dot com changed:
What|Removed |Added
---
gcc only warns on blah1 on the following code:
const char *blah1() {
char x = 7;
return &x;
}
const char *blah2() {
char x = 7;
static const char *names[1] = { &x };
return names[0];
}
returnlocal.cc: In function 'const char* blah1()':
returnlocal.cc:2: warning: address of local
--- Comment #5 from mark at codesourcery dot com 2005-11-11 06:26 ---
Subject: Re: [4.0/4.1 Regression] ICE set_mem_attributes_minus_bitpos
pinskia at gcc dot gnu dot org wrote:
> --- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-10 23:20
> ---
> Mark do you know if
--- Comment #10 from hp at gcc dot gnu dot org 2005-11-11 06:03 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00790.html>.
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from pault at gcc dot gnu dot org 2005-11-11 05:42 ---
Fixed on mainline and 4.0
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
S
--- Comment #31 from pault at gcc dot gnu dot org 2005-11-11 05:41 ---
For some reason, this never got fixed on 4.0. It is now!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16861
--- Comment #9 from pault at gcc dot gnu dot org 2005-11-11 05:40 ---
Fixed on mainline and 4.0
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
S
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-11-11 05:40 ---
(In reply to comment #8)
> For some reason we are calling cp_parser_pre_parsed_nested_name_specifier.
Actually that is fine.
Though we got the wrong answer already in there.
--
http://gcc.gnu.org/bugzilla/show_
--- Comment #5 from pault at gcc dot gnu dot org 2005-11-11 05:37 ---
Subject: Bug 24655
Author: pault
Date: Fri Nov 11 05:37:40 2005
New Revision: 106779
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106779
Log:
2005-11-11 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #30 from pault at gcc dot gnu dot org 2005-11-11 05:37 ---
Subject: Bug 16861
Author: pault
Date: Fri Nov 11 05:37:40 2005
New Revision: 106779
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106779
Log:
2005-11-11 Paul Thomas <[EMAIL PROTECTED]>
PR fortran
--- Comment #8 from pault at gcc dot gnu dot org 2005-11-11 05:37 ---
Subject: Bug 24409
Author: pault
Date: Fri Nov 11 05:37:40 2005
New Revision: 106779
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106779
Log:
2005-11-11 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #6 from pault at gcc dot gnu dot org 2005-11-11 05:37 ---
Subject: Bug 24755
Author: pault
Date: Fri Nov 11 05:37:40 2005
New Revision: 106779
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106779
Log:
2005-11-11 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-11-11 05:35 ---
For some reason we are calling cp_parser_pre_parsed_nested_name_specifier.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22136
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-11-11 05:22 ---
parser->scope is wrong when we call make_id_declarator.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22136
--- Comment #14 from kargl at gcc dot gnu dot org 2005-11-11 04:52 ---
Thomas,
I'm not in favor of environmental variables, which I think would
also be Paul Brook's position. It's too easy to have the variables
set or unset at the wrong time.
OTOH, you're working on a patch, so it's u
--- Comment #6 from kargl at gcc dot gnu dot org 2005-11-11 04:49 ---
Fixed.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #5 from kargl at gcc dot gnu dot org 2005-11-11 04:46 ---
Subject: Bug 15976
Author: kargl
Date: Fri Nov 11 04:46:50 2005
New Revision: 106778
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106778
Log:
PR fortran/15976
* resolve.c (resolve_symbol): Disallow a
--- Comment #4 from kargl at gcc dot gnu dot org 2005-11-11 04:44 ---
Subject: Bug 15976
Author: kargl
Date: Fri Nov 11 04:44:16 2005
New Revision: 106777
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106777
Log:
PR fortran/15976
* resolve.c (resolve_symbol): Disallow automatic
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-11 04:30 ---
The difference between having the use and the no use case is that we get
a nondependent name for naming the struct B which is just wrong.
Hmm, I think I found related rejects valid for before 4.1.0:
struct B {
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-11 03:36 ---
For some reason we get the record B and not just I::B which would be
dependent.
Looking more into it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22136
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot
|dot org
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2005-11-11 02:16
---
Confirmed on 4.1 and 4.0.3
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from kkojima at gcc dot gnu dot org 2005-11-11 02:12
---
Subject: Bug 24445
Author: kkojima
Date: Fri Nov 11 02:12:42 2005
New Revision: 106774
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106774
Log:
PR target/24445
* calls.c (expand_call): Co
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2005-11-11 02:07
---
Another trasnfer.c bug possibly. I will investigate.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24785
--- Comment #24 from tkho at ucla dot edu 2005-11-11 01:26 ---
For comparison, here's the code from gcc 2.95.3. It generates the same 18
instructions for both march=i386 and march=pentiumpro.
`gcc -c test3.c -save-temps -O2 -momit-leaf-frame-pointer -march=pentiumpro`:
pushl %ebx
--- Comment #9 from hp at bitrange dot com 2005-11-11 01:06 ---
Subject: Re: [4.1 regression] global-alloc (reload)
trips over own confusion for unexpected addressing modes
On Thu, 10 Nov 2005, janis at gcc dot gnu dot org wrote:
> --- Comment #8 from janis at gcc dot gnu dot org
--- Comment #10 from bill dot thompsons at gmail dot com 2005-11-11 00:56
---
Subject: Re: Stack corruption in ARM arch. if 64bit variable is passed to a
function of which the low 32 use the register and the up 32 use the stack
> What is the procedure for getting fixes in 3.4.x and 4.
--- Comment #8 from janis at gcc dot gnu dot org 2005-11-10 23:40 ---
A regression hunt using a cris-axis-elf cross compiler on powerpc-linux
identified this patch:
r95823 | hp | 2005-03-03 03:53:29 + (Thu, 03 Mar 2005) | 40 lines
http://gcc.gnu.org/viewcvs?view=rev&rev=95823
--
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-10 23:20 ---
Mark do you know if your patch for PR 20912 would fix this?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #15 from tobi at gcc dot gnu dot org 2005-11-10 23:15 ---
*** Bug 22048 has been marked as a duplicate of this bug. ***
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from tobi at gcc dot gnu dot org 2005-11-10 23:15 ---
*** This bug has been marked as a duplicate of 24643 ***
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-10 23:13 ---
I think this is related to PR 19340.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15439
--- Comment #14 from tobi at gcc dot gnu dot org 2005-11-10 23:11 ---
Fixed.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #13 from tobi at gcc dot gnu dot org 2005-11-10 23:10 ---
Subject: Bug 24643
Author: tobi
Date: Thu Nov 10 23:10:51 2005
New Revision: 106757
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106757
Log:
Backport r106753
fortran/
PR fortran/24643
* primary.c (match_var
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |3.4.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15535
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |3.4.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14532
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Known to work|3.4.0 |
Priority|P2 |P3
http://gcc.gnu.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |3.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16702
--- Comment #13 from tkoenig at gcc dot gnu dot org 2005-11-10 22:53
---
Also, little_endian and big_endian have
to be converted to native or swap, depending on
the architecture.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23815
--- Comment #3 from janis at gcc dot gnu dot org 2005-11-10 22:53 ---
A regression hunt identified this patch:
r95217 | jakub | 2005-02-18 06:58:40 + (Fri, 18 Feb 2005) | 9 lines
PR c++/19813
* emit-rtl.c (set_mem_attributes_minus_bitpos): Add assertion
that
--- Comment #23 from tkho at ucla dot edu 2005-11-10 22:43 ---
Created an attachment (id=10211)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10211&action=view)
Another long long rotate test case
Hi Michael,
I tried your patch in comment #16, and it didn't optimize our code. Atta
--- Comment #12 from tkoenig at gcc dot gnu dot org 2005-11-10 22:39
---
Created an attachment (id=10210)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10210&action=view)
proposed patch, without docs (so far)
Here's a partial solution, which implements the CONVERT keyword
in the
--- Comment #4 from pault at gcc dot gnu dot org 2005-11-10 22:24 ---
Subject: Bug 24655
Author: pault
Date: Thu Nov 10 22:24:28 2005
New Revision: 106756
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106756
Log:
2005-11-10 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #5 from pault at gcc dot gnu dot org 2005-11-10 22:24 ---
Subject: Bug 24755
Author: pault
Date: Thu Nov 10 22:24:28 2005
New Revision: 106756
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106756
Log:
2005-11-10 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #7 from pault at gcc dot gnu dot org 2005-11-10 22:24 ---
Subject: Bug 24409
Author: pault
Date: Thu Nov 10 22:24:28 2005
New Revision: 106756
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106756
Log:
2005-11-10 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
Hi,
the following program shows that the X edit descriptor
can get "lost" when splitting a WRITE with ADVANCE="NO":
program x_with_advance_bug
c This variant works as expected,
write (*,'(A," ")',advance="no") "<"
write (*,'(A)') ">"
c while this one misses the 2X:
write
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.0.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22607
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #7 from eedelman at gcc dot gnu dot org 2005-11-10 21:51
---
*** Bug 19766 has been marked as a duplicate of this bug. ***
--
eedelman at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from eedelman at gcc dot gnu dot org 2005-11-10 21:51
---
This bug and PR 22607, which was fixed recently, appears to be duplicates.
*** This bug has been marked as a duplicate of 22607 ***
--
eedelman at gcc dot gnu dot org changed:
What|Removed
--- Comment #6 from eedelman at gcc dot gnu dot org 2005-11-10 21:50
---
Fixed on both 4.1 and 4.0
--
eedelman at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from tobi at gcc dot gnu dot org 2005-11-10 21:49 ---
Subject: Bug 24643
Author: tobi
Date: Thu Nov 10 21:49:29 2005
New Revision: 106753
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106753
Log:
fortran/
PR fortran/24643
* primary.c (match_varspec): Check for i
--- Comment #5 from redi at gcc dot gnu dot org 2005-11-10 21:42 ---
I'm building the compiler now, will test a.s.a.p
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-10 21:35 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-10 21:24 ---
Hmm, there is something weird going on here.
If I do -W -Wall, then I get:
t.f90: In function 'a':
t.f90:1: warning: unused parameter 'x'
t.f90: At top level:
t.f90:1: warning: unused parameter 'x'
But if I just do
--- Comment #5 from eedelman at gcc dot gnu dot org 2005-11-10 21:24
---
Subject: Bug 22607
Author: eedelman
Date: Thu Nov 10 21:24:12 2005
New Revision: 106751
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106751
Log:
fortran/
2005-11-10 Erik Edelmann <[EMAIL PROTECTED]>
--- Comment #9 from janis at gcc dot gnu dot org 2005-11-10 21:22 ---
I can't reproduce the segfault using a cross compiler on a powerpc64-linux
system. The second testcase compiles successfully there using several very
recent checkouts from the trunk, including the date the PR was file
The Fortran code
$ cat unused.f90
subroutine a(x)
implicit none
real x
end subroutine a
gives the warning
$ ~/gcc/bin/gfortran -c unused.f90 -Wall
unused.f90: In function a:
unused.f90:1: warning: unused variable x
when compiled with
$ ~/gcc/bin/gfortran --version
GNU Fortran 95 (GCC)
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-10 21:11 ---
Confirmed, reduced testcase:
template
struct Move {
Move();
static Move const MOVES[2][2];
};
template
Move const Move::MOVES[2][2]={};
typedef Move const MoveClass;
void moves(int x, int y) {
&MoveClass::MOV
The small program given do not compile with gfortran: Compiler complains:
"Error: Symbol 'ny' at (1) has no IMPLICIT type"
- Removing "IMPLICIT NONE" for the module allows compilation.
or
- removing the "DIMENSION vec(ny)" allows compilation.
The problem seems to be related to implicit ny variabl
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-10 20:31 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
class Foo { public: typedef int type1; };
class Bar { private: typedef Foo type2; };
void f(Bar::type2 ) {} // rejected, OK
void g(Bar::type2::type1) {} // accepted ???
gcc-3.2.3 and 3.3.6 reject both lines
3.4.5 4.0.3 and CVS snapshot wrongly(?) accept the last line
--
Summa
--- Comment #7 from aoliva at gcc dot gnu dot org 2005-11-10 20:04 ---
Fixed
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from aoliva at gcc dot gnu dot org 2005-11-10 19:54 ---
Subject: Bug 24778
Author: aoliva
Date: Thu Nov 10 19:54:06 2005
New Revision: 106749
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106749
Log:
PR target/24778
* varasm.c (assemble_name): Recompute name only
GCC version:
Using builtin specs.
gcc version 2.95.2 19991024 (release)
System Type:
iBSD4
GCC Options:
--prefix=/usr/bin/gcc4
During install of gcc version 4.0.2
Configure Command:
/usr/home/joelk/ftp/gcc-4.0.2/configure --prefix=/usr/bin/gcc4
During Make command, Locks Up after the following
--- Comment #16 from jason at gcc dot gnu dot org 2005-11-10 18:32 ---
The patch breaks the 4.0 branch compiler, and I don't think this is a serious
enough bug to put more work into coming up with a different fix for older
releases.
--
jason at gcc dot gnu dot org changed:
--- Comment #17 from law at redhat dot com 2005-11-10 18:30 ---
Subject: Re: [4.1 Regression] Slowdown of the
bresenham line drawing by roughly 20%
On Wed, 2005-11-02 at 14:32 +, hubicka at ucw dot cz wrote:
> Hmm, perhaps restricting the reassociation + simplification into
--- Comment #16 from law at redhat dot com 2005-11-10 18:26 ---
Subject: Re: [4.1 Regression] Slowdown of the
bresenham line drawing by roughly 20%
On Wed, 2005-11-02 at 14:32 +, hubicka at ucw dot cz wrote:
> Hmm, perhaps restricting the reassociation + simplification int
--- Comment #10 from sje at cup dot hp dot com 2005-11-10 18:20 ---
I can't believe I configured with --disable-shared. OK, without that things
look better. I changed LIBGCC to "%{shared-libgcc:%{mlp64:-lgcc_s_hpux64}}
-lgcc" and I get -lgcc_s on the link command. I am doing a bootstr
--- Comment #5 from aoliva at gcc dot gnu dot org 2005-11-10 18:11 ---
Mine. I'll try to get the failure with a cross compiler.
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-10 18:03 ---
Caused by:
http://gcc.gnu.org/viewcvs?view=rev&rev=106703
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24778
--- Comment #2 from gbeauchesne at mandriva dot com 2005-11-10 18:02
---
Created an attachment (id=10206)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10206&action=view)
Self-contained testcase
Fails with gcc 4.0.3 20051103 (prerelease) -O2 -fno-unit-at-a-time
--
http://gcc
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Ever Confirmed|0 |1
Last reconfi
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |blocker
Summary|Assembler errors during |[4.1 Regressi
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-10 17:52 ---
Reducing (this means I can reproduce it).
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from gbeauchesne at mandriva dot com 2005-11-10 17:51
---
Created an attachment (id=10205)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10205&action=view)
Reduced testcase
I will attach a variant which is self-contained but it's a little messay as it
requires some
In a file that defined several templates, I received the following error
message:
internal compiler error: in set_mem_attributes_minus_bitpos, at emit-rtl.c:1539
Bug 20073 involved the same error message, but that was marked "fixed" last
February. The .ii file compiles in 3.4.4 but fails in 4.0.
Hi,
The following testcase reduced from Python's mathmodule.c is miscompiled with
gcc 3.3-hammer at -O2 and FSF gcc version 4.0.3 20051103 at -O2
-fno-unit-at-a-time as otherwise gcc is smart enough to optimize out the
function descriptor and the problem disappears.
Looking at the generated assem
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-10 17:32 ---
Something is really wrong:
beq- cr7,_L13070
There should be no underscore there.
Some get it correct:
b L12781
What gcc are you starting with?
What happens if you remove -mlongcall from the CFLAGS
--- Comment #2 from schnetter at aei dot mpg dot de 2005-11-10 17:24
---
Created an attachment (id=10204)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10204&action=view)
Failing assembler output
This is from a different invokation of the compiler, i.e., the auto-generated
file n
--- Comment #3 from jakub at gcc dot gnu dot org 2005-11-10 17:23 ---
Fixed in CVS.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONF
--- Comment #1 from schnetter at aei dot mpg dot de 2005-11-10 17:22
---
Created an attachment (id=10203)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10203&action=view)
Complete error message
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24778
--- Comment #2 from jakub at gcc dot gnu dot org 2005-11-10 17:18 ---
Subject: Bug 24774
Author: jakub
Date: Thu Nov 10 17:18:12 2005
New Revision: 106742
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106742
Log:
PR fortran/24774
* io/inquire.c (inquire_via_file
I checked out gcc from svn; I have version
$ svn info
Path: .
URL: svn://gcc.gnu.org/svn/gcc/trunk
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 106735
Node Kind: directory
Schedule: normal
Last Changed Author: jakub
Last Changed Rev: 106735
Last Changed Date: 2005-11-10 07:14:05
--- Comment #15 from ebotcazou at gcc dot gnu dot org 2005-11-10 17:05
---
See http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00663.html.
Fixed in 4.0.3 and up.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #14 from ebotcazou at gcc dot gnu dot org 2005-11-10 17:00
---
Subject: Bug 22127
Author: ebotcazou
Date: Thu Nov 10 17:00:41 2005
New Revision: 106740
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106740
Log:
PR middle-end/22127
* calls.c (special_
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2005-11-10 16:58
---
Subject: Bug 22127
Author: ebotcazou
Date: Thu Nov 10 16:58:56 2005
New Revision: 106739
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106739
Log:
PR middle-end/22127
* calls.c (special_
Couple of the FIXME's in c-decl.c:
/* A conflicting function declaration for a predeclared
function that isn't actually built in. Objective C uses
these. The new declaration silently overrides everything
but the volatility (i.e. noreturn) indicatio
--- Comment #2 from paul dot richard dot thomas at cea dot fr 2005-11-10
15:54 ---
The following patch fixes this PR. Please note that it has yet to be regtested
but I do not see any problems with it. I do not thank that PR15809 has
anything to do with this one.
Index: gcc/gcc/fortra
Right now if TLS is disable (or if a target does not support TLS) the thread
private testcase fail. There should be a way to enable thread private and non
TLS targets.
--
Summary: [GOMP] non-TLS and thread private
Product: gcc
Version: 4.1.0
Status:
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-10 15:45 ---
Mine, I am working on this.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
The issue here is that libobjc current includes GCC's target headers like
config/rs6000/rs6000.h and config/i386/i386.h This needs to be changed so that
libobjc no longer includes them.
--
Summary: libobjc should not include GCC's target headers
Product: gcc
Ver
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2005-11-10 15:35
---
On mips-irix6.5, the libgfortran config.h contains:
#define HAVE_CABSF 1
and
/* #undef HAVE_COMPLEX_H */
and in math.h it does have the following:
struct __cabsl_s { long double a,b; };
extern long double cabsl(
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-10 14:58 ---
(In reply to comment #3)
> Reducing (which means I can reproduce it).
Note I am still reducing this one. It is just taking a long time. Also I lost
connection to the machine I was reducing on last night.
--
h
--- Comment #5 from paul dot richard dot thomas at cea dot fr 2005-11-10
14:46 ---
A give-away here is that inverting the order of the equivalence members, makes
the problem go away. The path below cures the problem but I have not regtested
yet.
Paul T
Index: gcc/gcc/fortran/tran
1 - 100 of 127 matches
Mail list logo
