--- Comment #2 from mishabear at gmail dot com 2005-11-29 07:44 ---
Subject: Re: GCC issues warnings to a syntactically correct expression.
In fact I want to do something lik this:
int main()
{
int ia[10];
int *pi, i;
i=10;
pi = ( ((i>=0) && (i<10)) ? (
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-29 06:28 ---
Note the warning is to warn things like:
a = a++;
which is syntactically correct but semantically questionable.
Note there are a lot of things which are syntactially correct but are
semantically questionable
--
Put the following code in a file tt.c and compile tt.c with command "gcc -Wall
tt.c", then the compiler will complain.
int main()
{
void *pv;
pv = (pv=0);
return 0;
}
The compiler complains:
tt.c: In function `main':
tt.c:5: warning: operation on `pv' may be undefined
Th
--- Comment #3 from wilson at gcc dot gnu dot org 2005-11-29 06:10 ---
This is indeed a gcse problem. It is a problem with the load motion support.
There are some similarities to PR 24804 here. We have multiple overlapping
objects on the stack, that have mems with different MEM_EXPR f
--- Comment #6 from wilson at gcc dot gnu dot org 2005-11-29 05:57 ---
PR 25130 is a gcse problem, and there are some curious similarities. We have
two objects on the stack with the same address, and gcse is emitting new RTL
referring to the "wrong" one, which means we have mems with ba
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2005-11-29 05:53
---
Subject: Bug 25149
Author: jvdelisle
Date: Tue Nov 29 05:52:57 2005
New Revision: 107655
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107655
Log:
2005-11-28 Steven G. Kargl <[EMAIL PROTECTED]>
--- Comment #5 from ghazi at gcc dot gnu dot org 2005-11-29 05:18 ---
Subject: Bug 20109
Author: ghazi
Date: Tue Nov 29 05:18:13 2005
New Revision: 107654
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107654
Log:
PR middle-end/20109
PR middle-end/25120
*
--- Comment #10 from ghazi at gcc dot gnu dot org 2005-11-29 05:18 ---
Subject: Bug 25120
Author: ghazi
Date: Tue Nov 29 05:18:13 2005
New Revision: 107654
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107654
Log:
PR middle-end/20109
PR middle-end/25120
--- Comment #9 from ghazi at gcc dot gnu dot org 2005-11-29 05:18 ---
Subject: Bug 25120
Author: ghazi
Date: Tue Nov 29 05:17:56 2005
New Revision: 107653
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107653
Log:
PR middle-end/20109
PR middle-end/25120
*
--- Comment #4 from ghazi at gcc dot gnu dot org 2005-11-29 05:18 ---
Subject: Bug 20109
Author: ghazi
Date: Tue Nov 29 05:17:56 2005
New Revision: 107653
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107653
Log:
PR middle-end/20109
PR middle-end/25120
*
--- Comment #8 from ghazi at gcc dot gnu dot org 2005-11-29 05:17 ---
Subject: Bug 25120
Author: ghazi
Date: Tue Nov 29 05:17:20 2005
New Revision: 107652
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107652
Log:
PR middle-end/20109
PR middle-end/25120
*
--- Comment #3 from ghazi at gcc dot gnu dot org 2005-11-29 05:17 ---
Subject: Bug 20109
Author: ghazi
Date: Tue Nov 29 05:17:20 2005
New Revision: 107652
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107652
Log:
PR middle-end/20109
PR middle-end/25120
*
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-29 05:00 ---
Confirmed fixed in 4.0.0, it is not a regression as 3.3 added TLS and it failed
until 4.0.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Bug seen with the RH version of gcc (gcc-3.4.4-2.fc3) but Jim Wilson says
he can reproduce this with the FSF gcc-3.4.4.
See Message-ID: <[EMAIL PROTECTED]> on gcc mailing list
and https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174061
$ gcc -g -O2 -c -DSHOWBUG bug.c
bug.c: In function `bug':
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-29 04:15 ---
This is most likely a dup of bug 20248 (hopefully I was clear in my email to
fortran@, maybe I was not).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25149
The following compiles fine with no parameters but fails to compile with
-std=f95:
program fabort
implicit none
integer :: i1, i2, i3
open(10, status="scratch")
write(10,'(a)') "1,2 35"
rewind(10)
read(10,'(3i9)') i1,i2,i3
if(i1.ne.1) call abor
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-29 04:04 ---
Subject: Re: [3.4 Regression] Produces wrong code
> --- Comment #4 from wilson at gcc dot gnu dot org 2005-11-29 03:39
> ---
> The testcase doesn't fail with gcc-4.0 and up, because after tree-ssa opts
>
> --- Comment #4 from wilson at gcc dot gnu dot org 2005-11-29 03:39
> ---
> The testcase doesn't fail with gcc-4.0 and up, because after tree-ssa opts
> there isn't anything left for the RTL gcse pass to do. However, I believe the
> bug is still there in the code, it is just very much h
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-29 04:03 ---
(In reply to comment #3)
> To repsond to this one, with -fpic/PIC we don't inline functions which can be
> overridden by other TUs.
More to the point, this testcase is only testing when inlining which means with
-f
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2005-11-29 03:50
---
Dang, I just noticed that Iwan had proposed a patch in comment #5 so I did my
own.
My apologies please.
Does Iwan have copyright assignment in place?
I took a different approach with my patch because I did not
--- Comment #4 from wilson at gcc dot gnu dot org 2005-11-29 03:39 ---
The failure happens in store_motion in gcse.c.
We have two objects on the stack with disjoint lifetimes that overlap. They
have different MEM_EXPRS, and some of the mems also have different alias sets.
They have di
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2005-11-29 02:28
---
Yes, I have a patch under review right now that fixes this. However, I am
going to add a requirement that -std=legacy or similar be invoked, otherwise we
would be non-compliant with F95 Standard which disallows c
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2005-11-29 02:16
---
Reduced test case:
program test
dimension data(100)
read(11,end=1000 )data
1000 continue
backspace 11
backspace 11
end
I will have to check to see if this is l
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-29 02:07 ---
Actually you can produce the missed optimization for g++.dg/tree-ssa/pr18178.C
with -fwrapv, we know that the range is [0, a-1] so that it has to be less than
a.
The code for ASSERTS:
i_2 = ASSERT_EXPR ;
D.2100_2
--- Comment #8 from kargl at gcc dot gnu dot org 2005-11-29 01:55 ---
(In reply to comment #7)
> (In reply to comment #6)
> I'm not sure what the "correct" behavior is.
> But it is a fact that gfortran is the first
> compiler I have seen to respond with a runtime error,
> given this f
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-29 01:32 ---
This is for ffast-math, for non fast-math, we already do it correctly.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #10 from pinskia at gcc dot gnu dot org 2005-11-29 01:03
---
(In reply to comment #5)
> Once fold is able to do (int)(a+b) into (int)a + (int)b, the combine pass
> (15459) should be able to fix this.
I should note this is only valid for unsigned types and when -fwrapv is
su
--- Comment #38 from aoliva at gcc dot gnu dot org 2005-11-29 00:56 ---
Subject: Bug 24991
Author: aoliva
Date: Tue Nov 29 00:56:16 2005
New Revision: 107640
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107640
Log:
PR libfortran/24991
* config/darwin.c (machopic_indirection_na
--- Comment #37 from aoliva at gcc dot gnu dot org 2005-11-29 00:47 ---
Subject: Bug 24991
Author: aoliva
Date: Tue Nov 29 00:47:28 2005
New Revision: 107639
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107639
Log:
PR libfortran/24991
* config/darwin.c (machopic_indirection_na
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-11-29 00:39 ---
I am not going to fix this now as it exposes too many VRP issues and other
issues.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-29 00:38 ---
Note this was the simple fix which exposes those latent bugs as far as I can
see that should work, we get the correct range but the rest of VRP goes
bonkers:
Index: tree-vrp.c
--- Comment #7 from iwan at irs dot phy dot nrc dot ca 2005-11-29 00:35
---
(In reply to comment #6)
I'm not sure what the "correct" behavior is.
But it is a fact that gfortran is the first
compiler I have seen to respond with a runtime error,
given this format and input. This is ext
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-29 00:34 ---
I run into a different regression if we try to compile the first example in
comment #0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25145
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-29 00:29 ---
This causes wrong code when fixing PR 25145, comment #1.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from law at redhat dot com 2005-11-29 00:22 ---
Subject: Re: [4.1/4.2 Regression] ICE in
coalesce_abnormal_edges, at tree-outof-ssa.c:646
On Mon, 2005-11-28 at 23:26 +, janis at gcc dot gnu dot org wrote:
>
> --- Comment #4 from janis at gcc dot gnu dot
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-29 00:21 ---
This needs PR 25148 fixed to do the correct thing for comment #1 as we get the
wrong answer for a + -1 < a, we get false when we should get true.
--
pinskia at gcc dot gnu dot org changed:
What|Re
--- Comment #3 from janis at gcc dot gnu dot org 2005-11-29 00:13 ---
A regression hunt identified the following patch:
http://gcc.gnu.org/viewcvs?view=rev&rev=104103
r104103 | mmitchel | 2005-09-09 18:56:16 + (Fri, 09 Sep 2005) | 15 lines
PR c++/22252
* decl.c (st
--- Comment #6 from kargl at gcc dot gnu dot org 2005-11-29 00:08 ---
The error is actually correct behavior. The comma is
not a valid character in an integer and the '(2I9)'
format is telling the compiler that you are inputting
2 integers with 9 digits each. The comma does not
short-c
--- Comment #17 from joseph at codesourcery dot com 2005-11-28 23:43
---
Subject: Re: [4.2 Regression] Build failure on
sparc-sun-solaris2.9/arm: undefined symbol __floatunsitf
Current status:
PA needs fixing, probably similarly to ia64-hpux.
So does MIPS16.
FRV may need fixing, p
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[m68k] undefined reference |[4.2 Regression] [m68k]
|to `__floatunsidf'
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-28 23:43 ---
extract_range_from_binary_expr should do symbolic ranges for stuff like this
(or at least it seems like it should).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25145
--- Comment #7 from amodra at bigpond dot net dot au 2005-11-28 23:37
---
Hmm, yes, you are probably correct that optimization level should not help
correct a header/library mismatch. Still, the fact remains that I can't
reproduce your problem. For good measure, I compiled both the C
--- Comment #4 from janis at gcc dot gnu dot org 2005-11-28 23:26 ---
A regression hunt using the reduced testcase from comment #3 identified the
following patch:
http://gcc.gnu.org/viewcvs?view=rev&rev=98066
r98066 | law | 2005-04-13 04:29:40 + (Wed, 13 Apr 2005)
--
http://gc
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-28 22:56 ---
Even the simple code like:
int f(int i, int j )
{
int k;
k = i+ - 1;
return k < i;
}
Does not get VRP to optimize it which means we don't do that much symbolic
ranges as we should. From looking at things,
--- Comment #5 from eedelman at gcc dot gnu dot org 2005-11-28 22:36
---
*** Bug 25081 has been marked as a duplicate of this bug. ***
--
eedelman at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from eedelman at gcc dot gnu dot org 2005-11-28 22:36
---
This a duplicate of PR 24705, which was recently fixed on 4.2 and 4.0, but not
(yet?) on 4.1.
*** This bug has been marked as a duplicate of 24705 ***
--
eedelman at gcc dot gnu dot org changed:
Wh
--- Comment #1 from eedelman at gcc dot gnu dot org 2005-11-28 22:27
---
I can reproduce this with gfortran 4.1.0 20051128, but gfortran 4.2.0 20051128
correctly gives an error:
erik:~$ gfortran huj.f90
In file huj.f90:6
CHARACTER(LEN=*) FUNCTION F1
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |echristo at gcc dot gnu dot
|dot org
--- Comment #1 from eedelman at gcc dot gnu dot org 2005-11-28 22:13
---
With gfortran 4.2.0 20051128 I get an ICE for this code.
This slightly different code (but with basically the same error), however,
compiles and outputs 10, when we should get an error:
integer :: a
a=T1
--- Comment #1 from eedelman at gcc dot gnu dot org 2005-11-28 21:57
---
Confirmed. (Relevant section of the F2003 draft standard: 12.3.2.1.2).
--
eedelman at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #6 from janis at gcc dot gnu dot org 2005-11-28 21:48 ---
A regression hunt identified this large patch of many VPR fixes:
http://gcc.gnu.org/viewcvs?view=rev&rev=100478
r100478 | dnovillo | 2005-06-02 02:57:15 + (Thu, 02 Jun 2005) | 141 lines
--
janis at gcc dot gn
--- Comment #1 from eedelman at gcc dot gnu dot org 2005-11-28 21:44
---
Confirmed.
The F2003 (draft) standard says, in 7.4.4.1:
"C736 (R755) A subscript or stride in a foral l-triplet-spec shall not contain
a
reference to any index-name in the foral l-triplet-spec -list in which i
I am filing this right now even though I don't have a testcase because I am
running into it while trying to fix PR 23666. I don't know if this will cause
wrong code or not. I do know it will cause a missed optimization while
compiling "g++.dg/tree-ssa/pr18178.C" I have to find a testcase which f
--- Comment #1 from eedelman at gcc dot gnu dot org 2005-11-28 21:33
---
Confirmed.
--
eedelman at gcc dot gnu dot org changed:
What|Removed |Added
Status|UN
--- Comment #1 from eedelman at gcc dot gnu dot org 2005-11-28 21:27
---
Confirmed. Reminds a bit of PR 15809.
--
eedelman at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from eedelman at gcc dot gnu dot org 2005-11-28 21:19
---
Confirmed.
--
eedelman at gcc dot gnu dot org changed:
What|Removed |Added
Status|UN
--- Comment #8 from jvdelisle at verizon dot net 2005-11-28 21:07 ---
Subject: Re: namelist read from non-opened file
fxcoudert at gcc dot gnu dot org wrote:
> +
> /* Is it unformatted? */
> - if (!(cf & (IOPARM_DT_HAS_FORMAT | IOPARM_DT_LIST_FORMAT)))
> + if (!(cf & (IO
--- Comment #5 from iwan at irs dot phy dot nrc dot ca 2005-11-28 20:22
---
Created an attachment (id=10358)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10358&action=view)
Fixes bug 25039
The patch is against revision 107612 on gcc trunc,
to be applied in gcc/libgfortran/io.
I
--- Comment #7 from tromey at gcc dot gnu dot org 2005-11-28 20:06 ---
I'm handling this
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|
[EMAIL PROTECTED]:~/src/work> cat testint.f90
module integrator
interface
function integrate(f,xmin,xmax)
implicit none
interface
function f(x)
real*8 :: f,x
intent(in) :: x
end function f
end interface
real*8 :: xmin,
--- Comment #3 from geoffk at geoffk dot org 2005-11-28 19:22 ---
Subject: Re: aliases, including weakref, break alias analysis
On 28/11/2005, at 10:40 AM, aoliva at gcc dot gnu dot org wrote:
> --- Comment #2 from aoliva at gcc dot gnu dot org 2005-11-28
> 18:40 ---
> I'd
$ cat invalid_nullify.F
program ice_on_error_diagnostics
implicit none
TYPE (nonexisting_type1) t1 !, TARGET :: t1
nullify(t1%something)
end program
$ gfortran-4.0 invalid_nullify.F
In file invalid_nullify.F:3
TYPE (nonexisting_type1) t1 !, TARGET :: t1
Take the following example:
int f(int i, int j)
{
if (i <= j - 1)
if (i >= 0)
{
return i >= j;
}
return 0;
}
Note this might show up somewhere but I don't know if it actually does (I made
this up while looking into some missed optimizations due the patch which fixes
PR 2366
--- Comment #7 from gdr at integrable-solutions dot net 2005-11-28 18:46
---
Subject: Re: Warning "missing braces around initializer" causing problems with
tr1::array
"chris at bubblescope dot net" <[EMAIL PROTECTED]> writes:
| Actually, is a report really approriate? Writing array =
--- Comment #2 from aoliva at gcc dot gnu dot org 2005-11-28 18:40 ---
I'd change the testcase s/weakref/alias/, so as to make it clear that the error
has nothing to do with the newly-introduced weakref, but rather with regular
aliases, that weakref builds upon.
--
http://gcc.gnu.or
--- Comment #13 from nekkar at libero dot it 2005-11-28 18:14 ---
Hi Richard
Could you explain us in details what would be in your opinion the best solution
to this problem?
Should we create a new maverick crunch target with specific division code or
what else?
--
http://gcc.gnu.o
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-28 17:52 ---
This is fixed in 4.1.0 by removing the mmap code.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
I get a segmentation fault when trying to execute the
following simple program:
>cat junk2.f
program junk
character*28000 s
do i=1,28000
s(i:i) = 'a'
end do
open(3,file='junk_file',form='unformatted',access='direct',
& recl=28000)
write(3,rec=1)
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-28 17:06 ---
Confirmed, the problem is that middle-end does not know that x and y are really
the same variable
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
The following program:
extern void abort (void);
int x = 0;
extern int y __attribute((weakref("x")));
int main(void)
{
x = 1;
y = 2;
if (x != 2)
abort ();
return 0;
}
when compiled with -O2 on powerpc-darwin, unconditionally calls abort(). It
should not.
--
Summary: a
I have been getting this error on one of my programs that does extremely
complex I/O operations for a few months now, but I have been unable to isolate
it. I finally got the same error message from a program that generates random
I/O patterns. About half of the FORTRANS that I run this program with
--- Comment #6 from johannes at sipsolutions dot net 2005-11-28 16:34
---
And shouldn't a header/library mismatch segfault without optimisation as well?
But if it works for you I'll just see with the next gcc version I get.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25118
--- Comment #6 from chris at bubblescope dot net 2005-11-28 16:33 ---
Actually, is a report really approriate? Writing array = {1,2,3} is
perfectly valid C++, just warned about with -Wmissing-braces
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25137
--- Comment #5 from chris at bubblescope dot net 2005-11-28 16:28 ---
I'll make a report. Don't worry, I'm clear on the difference between tr1::array
and a C array, I just wanted to check that we agree this should produce a
warning (in which case I will go through the tr1::array testcase
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-28 16:28 ---
fold_range_test is wrong, around fold-const.c:4635
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23518
--- Comment #4 from gdr at integrable-solutions dot net 2005-11-28 16:18
---
Subject: Re: New: Warning "missing braces around initializer" causing
problems with tr1::array
"chris at bubblescope dot net" <[EMAIL PROTECTED]> writes:
| The following code:
|
| struct S
| { int x[3]; };
--- Comment #3 from gdr at integrable-solutions dot net 2005-11-28 16:15
---
Subject: Re: Warning "missing braces around initializer" causing problems with
tr1::array
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| I don't see why the warning is not useful at all, in f
--- Comment #1 from rearnsha at gcc dot gnu dot org 2005-11-28 16:03
---
Confirmed. This appears to be a bug in noce_try_abs, which is substituting an
abs() expansion into the RTL, but the substitution clobbers a hard register
that is live (the condition code register).
--
rearnsha
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2005-11-28 15:59
---
I think the following patch (no time yet to regtest it, and won't have time
soon, please feel free to test it) fixes it:
Index: transfer.c
===
--- t
--- Comment #36 from dir at lanl dot gov 2005-11-28 15:53 ---
With patches "gcc41-pr24991.patch" (I also need this to build on LINUX) and
"gcc-weakref-darwin.patch" (the patch gcc/ChangeLog failed, but that did not
matter) installed and a fresh down load of gfortran, gfortran builds and
--- Comment #6 from toon at moene dot indiv dot nluug dot nl 2005-11-28
15:36 ---
> I think you are right. I have been putting in debug statements all over and
> find that we are asking the wrong length of reads, 8 characters, instead of 1
> in the failing case. I will get back to th
--- Comment #6 from krebbel at gcc dot gnu dot org 2005-11-28 15:34 ---
Created an attachment (id=10354)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10354&action=view)
Testcase which failes on S/390 64bit with -O2
This testcase is reduced from gengtype-lex.c. Due to this bug it
--- Comment #2 from chris at bubblescope dot net 2005-11-28 15:17 ---
Thats an option too, but I thought I'd see about gcc's opinion first, as I
expected a much faster reply than I would get from the C++ steering committee
:)
I find the warning helpful for constructs like:
struct S { i
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-28 14:49 ---
I think this is a 4.2 regression cause by JSM's patch, could you check to see
if this is a regression?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25138
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-28 14:52 ---
I don't see why the warning is not useful at all, in fact I rather have the C++
standard fix their wording of TR1's array.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25137
Consider
double
foo (unsigned int a)
{
return a;
}
int
main (void)
{
return 0;
}
When I compile and link this like so
m68k-elf-gcc -Wl,-T,sim.ld -o test test.c
I get
undefined reference to `__floatunsidf'
Inspection of m5200/libgcc.a reveals that it does not contain __floatunsidf.
The following code:
struct S
{ int x[3]; };
void f()
{ S s = {1,2,3};}
With -Wmissing-braces (which is implied by -Wall, among others) gives:
warning: missing braces around initializer for 'int [3]'
In the specific case where a struct contains only a single array, adding the
extra braces doesn
gcc.c-torture/compile/20050303-1.c fails when it is compiled with
m68k-elf-gcc -m5200 -O0.
gcc.c-torture/compile/20050303-1.c:10: error: insn does not satisfy its
constraints:
(insn 17 45 18 (set (mem/c/i:SI (plus:SI (reg/f:SI 14 %a6)
(const_int -12 [0xfff4])) [0 toread+0 S4 A1
--- Comment #35 from aoliva at gcc dot gnu dot org 2005-11-28 14:15 ---
Created an attachment (id=10353)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10353&action=view)
Pach that fixes the weakref behavior on darwin
Could someone with access to the affected OS please try this pat
--- Comment #34 from marc dot waeckerlin at siemens dot com 2005-11-28
13:37 ---
What now? What happened since July? There's not even a new trouble report open
asking for "__GCC_PTHREADS__".
What can I as library writer now do, if I want to know whether or not I am in
valid multithread
--- Comment #5 from kkojima at gcc dot gnu dot org 2005-11-28 13:33 ---
Argh. I've got the results other way around.
Before patch:
--
.global foo
.type foo, @function
foo:
mov.l r12,@-r15
mov.l r14,@-r15
mov r15,r14
mov.l .L16
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-28 13:19 ---
Confirmed, IFC gives:
fortcom: Error: The same named entity from different modules and/or program
units cannot be referenced. [FOO]
in file (null), line 0, column 0
compilation aborted for t.f90 (code 1)
--
pi
--- Comment #4 from giovannibajo at libero dot it 2005-11-28 13:01 ---
Out of curiosity, can you show the code before and after Paolo's patches?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25115
--- Comment #2 from zerocool at modemsoft dot it 2005-11-28 12:48 ---
Subject: GCC Java not compile
> --- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-25
> 20:14 ---
> Can you attach the source you are trying to compile?
I have taken the source of the gcc 4.02 from
--- Comment #5 from johannes at sipsolutions dot net 2005-11-28 12:39
---
Hm. I didn't use -lrtgcc, that must have been a typo/copy&paste error, I
definitely used -lrt
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25118
--- Comment #3 from kkojima at gcc dot gnu dot org 2005-11-28 12:30 ---
It fixes the ICE and produces better codes. Thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25115
The following program should occur an error since the same named
entity from different modules cannot be referenced.
However, I compiled successfully, and got output "foo".
I think it is wrong behavior.
module m_foo
contains
subroutine foo
print *, "foo"
end subroutine
end module
module
--- Comment #2 from bonzini at gnu dot org 2005-11-28 10:53 ---
Created an attachment (id=10352)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10352&action=view)
patch to fix the bug
Kaz, can you please test this patch?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25115
--- Comment #3 from nathan at gcc dot gnu dot org 2005-11-28 10:34 ---
Subject: Bug 21166
Author: nathan
Date: Mon Nov 28 10:34:30 2005
New Revision: 107599
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107599
Log:
.:
PR c++/21166
* c-decl.c (finish_struct): On
--- Comment #7 from gdr at gcc dot gnu dot org 2005-11-28 10:22 ---
Postpone until 3.4.6
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|3.4
1 - 100 of 107 matches
Mail list logo
