--- Comment #8 from andreast at gcc dot gnu dot org 2007-01-23 07:36
---
Created an attachment (id=12936)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12936&action=view)
patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30513
--- Comment #7 from andreast at gcc dot gnu dot org 2007-01-23 07:29
---
Currently I'm not able to attach the patch. Sent privately.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30513
--- Comment #4 from pault at gcc dot gnu dot org 2007-01-23 07:19 ---
Subject: Bug 30549
Author: pault
Date: Tue Jan 23 07:19:26 2007
New Revision: 121080
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121080
Log:
2007-01-23 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #3 from pault at gcc dot gnu dot org 2007-01-23 06:26 ---
(In reply to comment #2)
> > No, that means it is used possiable as null.
> > You need to check inside pure_function to see if there is a way that the
> > second argument does not get initialized.
>
> There is:
> i
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-01-23 06:05
---
I think there is a bug in gcj because when I run gcj under the debugger, it
works.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30454
--- Comment #4 from pault at gcc dot gnu dot org 2007-01-23 06:05 ---
Fixed on trunk and 4.2
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pault at gcc dot gnu dot org 2007-01-23 05:57 ---
It would help to mark it as fixed!
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pault at gcc dot gnu dot org 2007-01-23 05:56 ---
Partially fixed - see list.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29389
--- Comment #7 from pault at gcc dot gnu dot org 2007-01-23 05:55 ---
It helps to mark it fixed...
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pault at gcc dot gnu dot org 2007-01-23 05:55 ---
Fixed on trunk and 4.2
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28172
--- Comment #6 from pault at gcc dot gnu dot org 2007-01-23 05:54 ---
Fixed on trunk and 4.2
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29712
--- Comment #5 from pault at gcc dot gnu dot org 2007-01-23 05:53 ---
Subject: Bug 29389
Author: pault
Date: Tue Jan 23 05:53:14 2007
New Revision: 121077
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121077
Log:
2007-01-23 Paul Thomas <[EMAIL PROTECTED]>
Backports f
--- Comment #3 from pault at gcc dot gnu dot org 2007-01-23 05:53 ---
Subject: Bug 30283
Author: pault
Date: Tue Jan 23 05:53:14 2007
New Revision: 121077
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121077
Log:
2007-01-23 Paul Thomas <[EMAIL PROTECTED]>
Backports f
--- Comment #5 from pault at gcc dot gnu dot org 2007-01-23 05:53 ---
Subject: Bug 29712
Author: pault
Date: Tue Jan 23 05:53:14 2007
New Revision: 121077
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121077
Log:
2007-01-23 Paul Thomas <[EMAIL PROTECTED]>
Backports f
--- Comment #5 from pault at gcc dot gnu dot org 2007-01-23 05:53 ---
Subject: Bug 28172
Author: pault
Date: Tue Jan 23 05:53:14 2007
New Revision: 121077
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121077
Log:
2007-01-23 Paul Thomas <[EMAIL PROTECTED]>
Backports f
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-01-23 05:15
---
Subject: Bug 29410
Author: pinskia
Date: Tue Jan 23 05:15:21 2007
New Revision: 121076
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121076
Log:
2007-01-22 Andrew Pinski <[EMAIL PROTECTED]>
PR
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-01-23 05:15
---
Subject: Bug 29951
Author: pinskia
Date: Tue Jan 23 05:15:21 2007
New Revision: 121076
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121076
Log:
2007-01-22 Andrew Pinski <[EMAIL PROTECTED]>
PR
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-01-23 05:13
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #110 from pinskia at gcc dot gnu dot org 2007-01-23 05:08
---
*** Bug 30553 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-23 05:08 ---
This is a very obvious case of violating C/C++ aliasing rules.
You are accessing a double as an int which is undefined by the C/C++ aliasing
rules. either use -fno-strict-aliasing, memcpy or an union (which is only
To get the binary int of a double, it is common to cast the ptr to the double
to an int ptr and then access the data the pointer points to. However, if the
variable containing the double is a function call parameter and the parameter
is passed in registers and hasn't been spilled to the stack yet,
--- Comment #1 from hjl at lucon dot org 2007-01-23 03:56 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01847.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30550
--- Comment #4 from patchapp at dberlin dot org 2007-01-23 03:55 ---
Subject: Bug number PR30532
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01852.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #3 from muntyan at tamu dot edu 2007-01-23 03:09 ---
Is it really quite as 22456? That bug is about variable used for initializing
itself, and really strange do-nothing code, while this one is straightforward
use of unitialized variable:
int main (void)
{
int i, foo;
for
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30552
--
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
gcc crashed when compile the following example , and report "internal compiler
error: Segmentation fault".
//comandline: gcc -c a.c
/* a.c */
int main()
{
void fun(a)
int a[({void h(){}2;})];
{
}
return 0;
}
--
Summary: gcc crashed when compiling an example
Pro
--- Comment #52 from kargl at gcc dot gnu dot org 2007-01-23 00:45 ---
(In reply to comment #51)
> Sure, new security checks can be written in a compliant manner.
>
> But what plan do you suggest to find instances of non-compliant overflow
> checking in the existing body? Think somethi
--- Comment #4 from aldyh at gcc dot gnu dot org 2007-01-23 00:43 ---
I'll look at this.
--
aldyh at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|u
--- Comment #8 from pinskia at physics dot uc dot edu 2007-01-23 00:29
---
Subject: Re: -Wno-deprecated needed also for C
> manu at gcc dot gnu dot org wrote:
> > --- Comment #4 from manu at gcc dot gnu dot org 2007-01-23 00:01
> > ---
> > The testcase given is not valid any
> manu at gcc dot gnu dot org wrote:
> > --- Comment #4 from manu at gcc dot gnu dot org 2007-01-23 00:01
> > ---
> > The testcase given is not valid any more. Could you think in any other
> > testcase?
> >
> > In stmt.c (expand_asm_operands) there is:
> >
> > warning (0, "u
--- Comment #7 from hpa at zytor dot com 2007-01-23 00:24 ---
Subject: Re: -Wno-deprecated needed also for C
manu at gcc dot gnu dot org wrote:
> --- Comment #6 from manu at gcc dot gnu dot org 2007-01-23 00:20 ---
> Hey, don't look at me. I am not sure what that means, I was
--- Comment #6 from truedfx at gentoo dot org 2007-01-23 00:23 ---
Thank you, and done.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26494
Noticed while doing a test for bug #26494:
int main(char a) {}
gcc bug.c -ansi -pedantic
compiles this without any error or warning.
gcc bug.c -ansi -pedantic -Wmain
reports
bug.c:1: warning: first argument of ‘main’ should be
‘int’
bug.c:1: warning: ‘main’ takes only zero or two arguments
and c
--- Comment #6 from manu at gcc dot gnu dot org 2007-01-23 00:20 ---
Hey, don't look at me. I am not sure what that means, I was just looking for
something deprecated in C front-end to make a testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11051
--- Comment #5 from hpa at zytor dot com 2007-01-23 00:15 ---
Subject: Re: -Wno-deprecated needed also for C
manu at gcc dot gnu dot org wrote:
> --- Comment #4 from manu at gcc dot gnu dot org 2007-01-23 00:01 ---
> The testcase given is not valid any more. Could you think in
--- Comment #5 from manu at gcc dot gnu dot org 2007-01-23 00:10 ---
Open a new bug report, please. I am going to submit a patch to fix this one and
reviewers don't like patches that do many things and the same time.
Add me to the CC list of the new report and I will look at it as soon
--- Comment #4 from truedfx at gentoo dot org 2007-01-23 00:08 ---
(In reply to comment #3)
> -Wendif-labels and -Wimplicit-int don't turn errors into warnings, so
> probably,
> yes.
So probably, no, it does not happen with any other option. Sorry, I read your
question wrong.
--
h
--- Comment #3 from truedfx at gentoo dot org 2007-01-23 00:05 ---
-Wendif-labels and -Wimplicit-int don't turn errors into warnings, so probably,
yes. I did notice something else of interest while testing, though:
int main(char a) {}
gcc bug.c -ansi -pedantic
compiles this without any
--- Comment #4 from manu at gcc dot gnu dot org 2007-01-23 00:03 ---
If this is confirmed as a bug, why don't you submit the patch to gcc-patches?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14737
--- Comment #4 from manu at gcc dot gnu dot org 2007-01-23 00:01 ---
The testcase given is not valid any more. Could you think in any other
testcase?
In stmt.c (expand_asm_operands) there is:
warning (0, "use of memory input without lvalue in "
"asm o
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-01-22 23:54
---
The code that triggers the ICE enters gfc_resolve with
gfc_current_ns->cl_list->length that is:
$12 = {expr_type = 0, ts = {type = BT_UNKNOWN, kind = 0, derived = 0x0,
cl = 0x0}, rank = 0, shape = 0x0, symtr
--- Comment #15 from tg at mirbsd dot de 2007-01-22 23:54 ---
Subject: Re: Integer Overflow detection code optimised away,
-fwrapv broken
pinskia at gcc dot gnu dot org dixit:
>fold-const.c changed a lot, etc.
>Actually there are two different code, one I wrote which is does
>foldin
--- Comment #10 from dave at hiauly1 dot hia dot nrc dot ca 2007-01-22
23:53 ---
Subject: Re: [4.3 Regression]
classpath/gnu/javax/crypto/jce/GnuCrypto.java:431: error: cannot find file for
class gnu.javRO
> Running the command which failed during the build manually, still failed.
> A
--- Comment #2 from manu at gcc dot gnu dot org 2007-01-22 23:47 ---
Does it happen with any other option apart from
-Wimplicit-function-declaration?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26494
--- Comment #7 from tromey at gcc dot gnu dot org 2007-01-22 23:33 ---
Fixed in 4.2, 4.3.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #6 from tromey at gcc dot gnu dot org 2007-01-22 23:33 ---
Subject: Bug 29812
Author: tromey
Date: Mon Jan 22 23:33:24 2007
New Revision: 121066
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121066
Log:
PR java/29812:
* java/lang/natRuntime.cc (_load
--- Comment #5 from tromey at gcc dot gnu dot org 2007-01-22 23:20 ---
Subject: Bug 29812
Author: tromey
Date: Mon Jan 22 23:20:18 2007
New Revision: 121065
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121065
Log:
PR java/29812:
* testsuite/libjava.jni/pr29812.
I downloaded ecj.jar with contrib/download_ecj. During bootstrap, I
got
/export/build/gnu/gcc/build-ia64-linux/./gcc/xgcc -shared-libgcc
-B/export/build/gnu/gcc/build-ia64-linux/./gcc -nostdinc++
-L/export/build/gnu/gcc/build-ia64-linux/ia64-unknown-linux-gnu/libstdc++-v3/src
-L/export/build/gnu/
--- Comment #51 from andreas at andreas dot org 2007-01-22 23:10 ---
Sure, new security checks can be written in a compliant manner.
But what plan do you suggest to find instances of non-compliant overflow
checking in the existing body? Think something like a whole Linux
distribution.
--- Comment #4 from Ralf dot Wildenhues at gmx dot de 2007-01-22 23:06
---
Created an attachment (id=12935)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12935&action=view)
updated updated updated patch
--
Ralf dot Wildenhues at gmx dot de changed:
What|Removed
--- Comment #4 from tromey at gcc dot gnu dot org 2007-01-22 23:04 ---
Subject: Bug 29812
Author: tromey
Date: Mon Jan 22 23:04:16 2007
New Revision: 121064
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121064
Log:
PR java/29812:
* testsuite/libjava.jni/pr29812.
--- Comment #6 from andreast at gcc dot gnu dot org 2007-01-22 22:54
---
I undef'ed the sun in gcj/array.h since this was the only header I found useful
for the moment. Having done this led me to the mentioned problem with
write/read_barrier which is not implemented for sparc. Adding th
--- Comment #7 from sje at cup dot hp dot com 2007-01-22 22:45 ---
So I can see things going wrong in expand_call but I still don't know why.
With the FORTRAN example (comment #3) expand_call sets num_actuals to 2 and
n_named_args to 1. If I write the calling code in C, num_actuals is
--- Comment #50 from pinskia at gcc dot gnu dot org 2007-01-22 22:27
---
There is no nothing special about signed integer overflow in C, it is just
undefined behavior at runtime. I had forgot to mention the SPEC results
because I don't feel SPEC CPU or any benchmark is a good way to me
--- Comment #2 from burnus at gcc dot gnu dot org 2007-01-22 22:25 ---
> No, that means it is used possiable as null.
> You need to check inside pure_function to see if there is a way that the
> second argument does not get initialized.
There is:
if (e->symtree != NULL
&& e->
--- Comment #4 from burnus at gcc dot gnu dot org 2007-01-22 22:17 ---
> This fixes the PR but I have not yet determined if it is standard conforming
> behaviour
See 5.1.2.5.1 Explicit-shape array:
"If the upper bound is less than the lower bound, the range is empty, the
extent in that
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-22 22:14 ---
Can you try after:
http://gcc.gnu.org/ml/gcc-cvs/2007-01/msg00765.html
?
>and later used without extra if(name) in:
No, that means it is used possiable as null.
You need to check inside pure_function to see if ther
The compiler warns that in the function "resolve_function" of resolve.c:, the
variable "name" might be used unintialized. I think gcc is right.
Name is initialized with:
if (!pure_function (expr, &name) && name)
and later used without extra if(name) in:
if (expr->value.function.esym && !expr
--- Comment #17 from fxcoudert at gcc dot gnu dot org 2007-01-22 22:02
---
cbrt is now available in the front-end (among others), thanks again to Richard!
Closing this PR, as the optimization appears to be working fully:
$ cat a.f90
REAL*8 :: a(6),b(6)
read(*,*) a(:)
b(1)=a(1)**(1.D0/
--- Comment #5 from igodard at pacbell dot net 2007-01-22 21:53 ---
OK, found the source of the problem: there's a template function in the base
class and a non-template function of the same name in the derived class, and
the parse is resolving the call to the non-template even though th
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-01-22 21:28
---
(In reply to comment #2)
> This fixes the PR but I have not yet determined if it is standard conforming
> behaviour
I'm almost sure it is. Usually, we need to take care of the case for negative
stride, but here o
--- Comment #4 from igodard at pacbell dot net 2007-01-22 21:20 ---
p.p.s. The error depends on the kind of primary in front of the selection and
call. If the primary is a variable then no error, as shown in the previous
line. However, you can also make the error go away by wrapping the
--- Comment #2 from pault at gcc dot gnu dot org 2007-01-22 21:05 ---
This fixes the PR but I have not yet determined if it is standard conforming
behaviour:
Index: gcc/fortran/array.c
===
*** gcc/fortran/array.c (revision
--- Comment #3 from igodard at pacbell dot net 2007-01-22 20:44 ---
p.s. if the disambiguator "template" is inserted in front of the call (i.e.
"... .template MMIOize< ..." the the compiler complains that a disambiguating
template keyword can only be used in a template.
--
http://gc
--- Comment #2 from igodard at pacbell dot net 2007-01-22 20:41 ---
Created an attachment (id=12934)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12934&action=view)
source code (compressed)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30548
--- Comment #1 from igodard at pacbell dot net 2007-01-22 20:40 ---
Created an attachment (id=12933)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12933&action=view)
compiler output -v
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30548
Only the first message is relevant. The parser seems to think that it is in an
expression and "<" is a relational operator rather than the bracket in front of
a template parameter for the member template function "MMIOize". Note that if
the expression is broken in two (the previous two lines) then
--- Comment #4 from patchapp at dberlin dot org 2007-01-22 20:35 ---
Subject: Bug number PR 30389
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01808.html
--
http://gcc.gnu.org/bugzilla/s
--- Comment #49 from ian at airs dot com 2007-01-22 20:16 ---
In the C language standard "undefined behaviour" meants that the compiler can
do anything at all. It means that the program is specifically undefined.
When you say that the compiler should not eliminate the test because the
--- Comment #5 from sgk at troutmask dot apl dot washington dot edu
2007-01-22 20:16 ---
Subject: Re: MAXVAL() incorrect for zero-size int arrays, and for -HUGE-1
maximum values.
>
>- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-01-22 07:56 ---
> I don't think it's a bu
--- Comment #48 from felix-gcc at fefe dot de 2007-01-22 19:50 ---
Oh wow, another wise cracking newbie who comments without actually
understanding the issue. I AM NOT RELYING ON UNDEFINED BEHAVIOR. On the
contrary. gcc is fine to assign 23 instead of a negative number. But if it
doe
The following program never ends, after the string has been displayed the
program eats 75% of CPU forever:
--8<-8<-8<-8<-8<---
with Ada.Text_IO; use Ada.Text_IO;
with Ada.Strings.Unbounded; use Ada.Strings.Unbounded;
procedure Bug is
type A_1 is array(1..1) of Unbounded_String;
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-01-22 19:30
---
(In reply to comment #10)
> Here is a Fortran test case:
I think that Fortran issue is something unrelated to this bug.
In fact that Fortran testcase was fixed for 4.1.2 by PR 27889.
--
http://gcc.gnu.org/bugz
--- Comment #10 from geir at cray dot com 2007-01-22 19:24 ---
Here is a Fortran test case:
$ cat bug2737.f90
PROGRAM get_tst_inc_complex
implicit none
external subrrg, checkrr
complex :: vrr, trr
vrr=cmplx(1.,2.);
call subrr ( )
contains
su
--- Comment #3 from tkoenig at gcc dot gnu dot org 2007-01-22 19:18 ---
(In reply to comment #2)
scriptors (10.2.1).
>
> The following patch allows the test case in #1 to compile:
Looks good (and I agree with the reasoning).
Will you submit the patch?
Thomas
--
tkoenig at
http://pastebin.ca/324404
http://pastebin.ca/324405
Regards
--
I've probably left my head... somewhere. Please wait untill I find it.
Homepage (pl_PL): http://uzytkownik.jogger.pl/
(GNU/)Linux User: #425935 (see http://counter.li.org/)
--- Comment #47 from andreas at andreas dot org 2007-01-22 18:36 ---
It was suggested to me that this issue should be discussed on the mailing list.
If you have an opinion, come there.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
--- Comment #46 from pinskia at gcc dot gnu dot org 2007-01-22 18:33
---
> PS: Mr Simon, that link to a how-to that says "btw this doesn't work for this
> special input", is that supposed to impress anyone? It certainly does not
> impress me very much, really.
yes and the special inpu
--- Comment #3 from s__nakayama at infoseek dot jp 2007-01-22 18:28 ---
(In reply to comment #1)
> I only have the C99 standard, and there I read in 6.3.1.1 p2 that only
> those variables are promoted to int that are of smaller size.
>
> Similarly, in 6.3.1.8, integer promotion rules ar
--- Comment #45 from steven at gcc dot gnu dot org 2007-01-22 18:26 ---
Marking this as WONTFIX leaves the impression that here is a bug here at all.
This should have been closed as INVALID.
First commandment of using C: "Thou shall not rely on undefined behavior."
--
http://gcc.g
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-22 18:20 ---
>From http://gcc.gnu.org/install/prerequisites.html
Texinfo version 4.4 (or later)
Necessary to build GCC documentation during development because the
generated output files are not included in the SVN repository
--- Comment #2 from manu at gcc dot gnu dot org 2007-01-22 18:11 ---
(In reply to comment #1)
> So you have "-Wextra -Wno-unused-parameter -Wall" so the -Wno-unused-parameter
> does not have an effect as it is not turned on by -Wextra but instead by
> -Wall.
>
Humm, I disagree. -Wext
--- Comment #7 from bonzini at gnu dot org 2007-01-22 17:37 ---
However, fixing GNATBIND/GNATLINK/GNATMAKE would allow you to e.g. install 4.1
in /opt/gcc-4.1/ and then configure with GNATMAKE=/opt/gcc-4.1/bin/gnatmake.
So there is still a point in fixing this bug.
If you start from 4.
While it was bootstrapping fine on 2006-10-21, mainline now fails to build on
my mingw setup because libgomp wants to run makeinfo, which I don't have. It
says make can be buggy, but it's not (it's GNU make 3.79.1).
if /home/coudert/trunk/missing makeinfo --split-size=500 -I
../../../trunk/li
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-01-22 17:35 ---
I have a simple fix.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Assign
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-01-22 17:27 ---
Note that doing this for GNATMAKE also will make us run into PR29127 (gnatbind
seems to be unaffected by this bug). Ada people generally don't seem to care
about the FSF way to build/install gcc, so I don't expect t
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-01-22 17:27 ---
*** This bug has been marked as a duplicate of 22456 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-01-22 17:27 ---
*** Bug 30542 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-22 17:24 ---
exp can set errno as defined by the C/C++ standard so it cannot be pulled out
of the loop.
you can work around this by using -fmath-errno which says the math builtins
don't set errno.
--
pinskia at gcc dot gnu do
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-01-22 17:17 ---
Fixed so closing as such.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #44 from pinskia at gcc dot gnu dot org 2007-01-22 17:14
---
Again this really has nothing to do with security except for the fact some
developers wrote security checking code that depends on overflow being defined
as wrapping which is not what the C standard says and what G
--- Comment #8 from manu at gcc dot gnu dot org 2007-01-22 17:05 ---
*** Bug 20764 has been marked as a duplicate of this bug. ***
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from manu at gcc dot gnu dot org 2007-01-22 17:05 ---
PR 23572 has a better description of the problem and the current status.
*** This bug has been marked as a duplicate of 23572 ***
--
manu at gcc dot gnu dot org changed:
What|Removed
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-01-22 17:02 ---
I was able to reproduce this under powerpc-darwin myself.
Running the command which failed during the build manually, still failed.
Adding -save-temps to that command made it pass.
I have not looked at what is diffe
1 - 100 of 126 matches
Mail list logo
