--- Comment #22 from ghazi at gcc dot gnu dot org 2008-01-12 08:35 ---
Thanks, testsuite patch posted here:
http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00530.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29256
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2008-01-12 08:36
---
Subject: Bug 34722
Author: jvdelisle
Date: Sat Jan 12 08:35:25 2008
New Revision: 131487
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131487
Log:
2008-01-12 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2008-01-12 08:37
---
Subject: Bug 34432
Author: jvdelisle
Date: Sat Jan 12 08:36:52 2008
New Revision: 131488
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131488
Log:
2008-01-12 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2008-01-12 08:39
---
Ignore comment #13, copy paste error on commit for 34432.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34722
--- Comment #2 from andry at inbox dot ru 2008-01-12 08:42 ---
(In reply to comment #1)
I think this is really just PR 10179 which was fixed for 4.3.0.
Could you test it on 4.3?
I tried to make trunk, but stopped with error:
configure: failed program was:
| /* confdefs.h. */
|
|
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2008-01-12 08:48
---
Subject: Bug 34432
Author: jvdelisle
Date: Sat Jan 12 08:47:27 2008
New Revision: 131489
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131489
Log:
2008-01-12 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2008-01-12 08:49
---
Fixed on trunk.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
In a gcc invocation, cc1 fails with a Not a directory error when compiling a
trivial file if there is a file (not a directory) named lib in the parent to
the working directory.
To recreate it:
bash-3.2# mkdir temp
bash-3.2# cd temp
bash-3.2# mkdir temp1
bash-3.2# touch lib
bash-3.2# cd temp1
--- Comment #7 from dominiq at lps dot ens dot fr 2008-01-12 09:19 ---
I forgot to say that the patch in #5 fixed this PR, but you can add to the list
of regressions:
[ibook-dhum] f90/bug% gfc
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/char_result_6.f90
--- Comment #8 from pault at gcc dot gnu dot org 2008-01-12 09:43 ---
(In reply to comment #4)
Dominique,
Indeed - I found all those regressions when I got up this morning. However,
the patch indicates which way to go. The compiler is repeatedly trying to
expand an array that it
--- Comment #15 from rguenth at gcc dot gnu dot org 2008-01-12 10:49
---
I think symbolic substitutions should be only done if the resulting stmt can
be simplified to a constant. Now for VRP my long-term plan is to get rid of
symbolic ranges altogether to make it cheaper and easier to
--- Comment #16 from pinskia at gmail dot com 2008-01-12 12:26 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] DOM and VRP creating harder to
optimize code
--- Comment #15 from rguenth at gcc dot gnu dot org 2008-01-12 10:49
---
I think symbolic substitutions should be only
--- Comment #17 from rguenth at gcc dot gnu dot org 2008-01-12 12:29
---
Can you point me to those?
I still think we should separate VRP of constant and symbolic ranges. For
symbolic stuff we eventually want to utilize a theorem prover.
--
--- Comment #18 from pinskia at gcc dot gnu dot org 2008-01-12 12:36
---
(In reply to comment #17)
Can you point me to those?
PR25643 and PR25145 .
Thanks,
Andrew Pinski
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23821
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-01-12 12:38 ---
ifcombine fixes this.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25643
--- Comment #9 from pinskia at gcc dot gnu dot org 2008-01-12 12:44 ---
This is not fixed for me with
gcc version 4.3.0 20071110 (experimental) [trunk revision 130075] (GCC)
or with Sun Jan 6 02:53:41 UTC 2008 (revision 131347)
--
pinskia at gcc dot gnu dot org changed:
--- Comment #10 from pinskia at gcc dot gnu dot org 2008-01-12 12:48
---
There should be no call to _gfortran_runtime_error_at and I still get one:
# i_2 = PHI 1(3), i_27(6)
if (i_2 size.1_4)
goto bb 5;
else
goto bb 6;
bb 5:
# i_32 = PHI i_2(4)
--- Comment #11 from pinskia at gcc dot gnu dot org 2008-01-12 12:49
---
Compile with -fbounds-checking -O2, and notice that there is still
That should be just -fbounds-check .
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25643
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-01-12 12:42 ---
Actually VRP1 catches both the fortran and the C testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25643
--- Comment #10 from rguenth at gcc dot gnu dot org 2008-01-12 13:05
---
The first testcase in the original report is fixed by comparison
canonicalization,
even if a temporary is used (forwprop re-instantiates the canonicalized
comparison).
The testcase in comment #1 is fixed by FRE
--- Comment #1 from zadeck at naturalbridge dot com 2008-01-12 13:16
---
I know what this bug is but i do not actually know how to find it. The bug is
caused by someone abandoning a basic block without going thur the api to
properly delete it or merge it into another block.
any
--- Comment #12 from hubicka at gcc dot gnu dot org 2008-01-12 13:34
---
Fixed on mainline (at least checking number of references from cross compiler).
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from ludovic at ludovic-brenta dot org 2008-01-12 13:52
---
By adding one line to the test case, we can see the bug reappears:
procedure Test_244942 is
function f1 return integer is begin return 1; end f1;
generic
with function foo return integer;
--- Comment #8 from hubicka at gcc dot gnu dot org 2008-01-12 13:55 ---
I can definitely commit the patch to silence the (IMO valid) diagnostics.
However, why programs are using always_inline and extern inline combination at
all? Just extern inline should be enough.
/* For GNU C
--- Comment #2 from hubicka at gcc dot gnu dot org 2008-01-12 14:03 ---
Subject: Bug 28023
Author: hubicka
Date: Sat Jan 12 14:02:06 2008
New Revision: 131492
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131492
Log:
PR other/28023
* invoke.texi
I was playing with some code and got a warning about dllimport in some
headers. I looked around a bit and came up with this test case.
The warning seems to imply that dllimport is ignored on bar(), but looking at
the output the call to bar() is indeed mangled with __imp prefix.
I'm using MinGW
--- Comment #12 from rguenth at gcc dot gnu dot org 2008-01-12 14:23
---
Simplified C testcase (omitting the parts that are optimized). We cannot
figure out the number of iterations of this loop:
void f(int n, float *v)
{
int i;
if (n = 0)
return;
else
{
i = 1;
--- Comment #3 from hubicka at gcc dot gnu dot org 2008-01-12 14:04 ---
Fixed in mainline.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from burnus at gcc dot gnu dot org 2008-01-12 14:04 ---
../../../gcc-4.3-work/libgfortran/generated/maxval_i4.c:322: warning: format
'%d' expects type 'int', but argument 2 has type 'long int'
../../../gcc-4.3-work/libgfortran/generated/minloc0_8_r8.c:86: warning: format
--- Comment #13 from steven at gcc dot gnu dot org 2008-01-12 14:34 ---
Re. comment #7, Assignment to sum should be moved before if...
This is called code hoisting, and it is not performed in GCC except with -Os.
See bug 24001, bug 33315, and other reports about the same issue in
--- Comment #5 from burnus at gcc dot gnu dot org 2008-01-12 14:36 ---
A related but slightly separate issue is illustrated by the following example.
The argument of the second call to FOO is an expression; however, expressions
involving assumed-size arrays are evil. This is detected
--- Comment #9 from rguenther at suse dot de 2008-01-12 15:13 ---
Subject: Re: [4.1/4.2/4.3 Regression] Bogus
inlining failed in call to `xxx': redefined extern inline functions are not
considered for inlining
On Sat, 12 Jan 2008, hubicka at gcc dot gnu dot org wrote:
---
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-01-12 15:14 ---
(In reply to comment #1)
s/%d/%ld%/g and prefixing the argument with (long) should be enough, shouldn't
it?
That's what I will do.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed
compiling gccfolderr.cc like this:
g++-4.1 -g -Wall -Wdeprecated -Wno-cast-qual -pipe -O2 -ftracer \
-finline-functions -fno-keep-static-consts gccfolderr.cc
yields:
gccfolderr.cc: In function voidunnamed::test_array():
gccfolderr.cc:34571: internal compiler error: in fold_convert, at
--- Comment #1 from timj at gtk dot org 2008-01-12 15:34 ---
Created an attachment (id=14929)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14929action=view)
compressed C++ preprocessor output
the preprocessed code was spewed out by gcc in the middle of development, it is
not
--- Comment #7 from steven at gcc dot gnu dot org 2008-01-12 16:22 ---
Patch of comment #3 looks good to me.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from zadeck at naturalbridge dot com 2008-01-12 16:34
---
i personally think that this patch in #8 is not the right way to go.
unless there is a compelling argument that initializing this is going to have
some negative performance effect, we should properly initialize
--- Comment #10 from bonzini at gnu dot org 2008-01-12 16:52 ---
an alternative is to prepare a suppression file for valgrind, and distribute it
with gcc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33796
--- Comment #11 from zadeck at naturalbridge dot com 2008-01-12 17:05
---
until someone has the slightest bit of evidence that initializing the
datastructure is costly, this is just a waste of time.
peter wrote the code this way to be cute, not because there was any reason to
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-01-12 17:47 ---
Can you please retain line directives so we can bring this up to current
development versions? Thanks.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-01-12 17:53 ---
P2.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3
The following (IMHO valid) code snippet triggers an ICE on mainline:
struct A {};
templateint, typename T = A, int T::*...p = 0 struct B {};
B0 b;
bug.cc:5:
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34751
--- Comment #22 from rguenth at gcc dot gnu dot org 2008-01-12 17:56
---
I'm downgrading this to P2.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
The following (IMHO valid) code snippet is rejected on mainline:
struct A {};
templateint*...p struct B1; // OK
templateint*... struct B2; // OK
templateint A::*...p struct B3; // OK
templateint A::*... struct B4; //
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34752
--- Comment #1 from burnus at gcc dot gnu dot org 2008-01-12 18:01 ---
gfortran does only create a check for ptr itself and not for ptr -
constructor; the created check looks (with some temporary variables added) as
follows:
if (prt.lbound ptr.lbound || ptr.lbound ptr.ubound)
(It
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-01-12 18:02 ---
Also ICEs cc1plus with plain -O2 the same way.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34648
--- Comment #13 from pcarlini at suse dot de 2008-01-12 18:06 ---
Anyway... The issue, after all, seems pretty academic to me, for the simple
reason that, per your report, the only known example of a named locale showing
'\0' as thousands separator is bg_BG, and most likely the data
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|NEW |SUSPENDED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34733
The following invalid code snippet triggers an ICE on mainline:
templatetypename... T struct A
{
templateT struct B {};
};
Aint::B0 b;
bug.cc:3: error: parameter
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34753
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-01-12 18:09 ---
Note this may be invalid code, g++ 3.4 reports:
gccfolderr.cc: In constructor `Rapicorn0752::Model::AutoValue::AutoValue(const
Rapicorn0752::Model::Array)':
gccfolderr.cc:34571: error: invalid use of undefined type
--- Comment #6 from pcarlini at suse dot de 2008-01-12 18:12 ---
Thanks for the suggestion, Benjamin. Actually, I don't think we can much better
*without* concepts... Anyway, was thinking that the ordering check is already
impossible to do in other circumstances, like real (single pass)
The following invalid code snippet triggers an ICE on mainline:
templatetemplateint class... T struct A
{
void foo(T0);
void bar(T0);
};
bug.cc:3: error:
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34754
The following invalid code snippet triggers an ICE on mainline:
templatetypename struct A {};
templatetemplatetypename class... T void foo(Tint) {}
template void fooA(Aint);
--- Comment #7 from pcarlini at suse dot de 2008-01-12 18:23 ---
Eh! Interestingly, conceptgcc explicitly enforces the concept that the two
value types must equal! Exactly the case that is covered but my almost-ready
patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34730
--- Comment #1 from reichelt at gcc dot gnu dot org 2008-01-12 18:23
---
Here's a similar testcase with a function instead of a nested class
that also segfaults:
templatetypename... T struct A
{
templateT A();
};
Aint
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-01-12 18:24 ---
Reduced testcase:
namespace std {
templatetypename _CharT
class basic_string {
public:
basic_string(const _CharT* __s);
};
typedef basic_stringchar string;
}
typedef signed long long int int64;
The following invalid code snippet triggers an ICE on mainline:
templatetypename... class A {};
templateint class A {};
templatetypename T, typename...U struct AT,U... : AU...
{
A() {}
};
Aint a;
The following invalid code snippet triggers an ICE on mainline:
templatetypename int M, int N, int (*... p)[N] struct A {};
A0 a;
bug.cc:1: error: expected
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34757
The diagnostic for the following invalid code snippet degraded in GCC 3.4.0:
===
struct A
{
A (const A = A());
};
===
Since GCC 3.4.0 we get:
bug.cc:3: error: the default argument for parameter 0 of 'A::A(const A)' has
not yet been parsed
But before we
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34758
--- Comment #5 from andreasmeier80 at gmx dot de 2008-01-12 19:06 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00482.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33964
--- Comment #6 from andreasmeier80 at gmx dot de 2008-01-12 19:08 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00491.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34052
--- Comment #7 from andreasmeier80 at gmx dot de 2008-01-12 19:09 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2007-12/msg00149.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34051
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-01-12 19:13 ---
Danny, maybe you mis-understood. We try to generate *VH.98, but VH.98 is
indeed
not in avail_out[19], but created for example as
exp_gen[4] := { x_7(D) (VH.72) , D.1661_4 (VH.98) , *VH.74 (VH.75) , a.1_6
(VH.76) ,
--- Comment #5 from reichelt at gcc dot gnu dot org 2008-01-12 19:23
---
Even further reduced testcase:
=
struct A
{
templatetypename T A(T);
};
class C;
struct B : A
{
B(const C c) : A(c) {}
};
struct C
{
C(const C);
C();
C operator=
--- Comment #9 from hubicka at gcc dot gnu dot org 2008-01-12 19:00 ---
Created an attachment (id=14930)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14930action=view)
tentative fix
I am testing the attached patch. It is obvious that we should use profile
here. The PR is most
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-01-12 19:41 ---
How is this a regression?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-01-12 19:42 ---
ICE-after-error for non c++0x mode.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-01-12 19:43 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-01-12 19:44 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-01-12 19:44 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-01-12 19:46 ---
Confirmed. With the better diagnostic we had accepts-invalid, so lowering
priority as regression status is not exactly clear.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-01-12 19:48 ---
Maybe sth for steven, as he was asking for bugs to look at... ;)
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from dberlin at gcc dot gnu dot org 2008-01-12 19:33 ---
Subject: Re: [4.3 Regression] ICE in find_or_generate_expression
On 12 Jan 2008 19:13:56 -, rguenth at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
--- Comment #5 from rguenth at gcc dot gnu dot org
With gfortran 4.3.0 20080109 I get an incorrect error message
Error: 'source' argument of 'shape' intrinsic at (1) must not
be an assumed size array with the following little test case
subroutine j_assumed_size(A,N)
dimension A(10,11,12,*)
k = shape(A(:,:,:,N))
l =
With gfortran 4.3.0 20080109 I get the error message
ALLOCATE (RLA1(NF10), STAT = ISTAT)
1
Error: STAT expression at (1) must be a variable
With the following program.
MODULE TESTS
INTEGER, PRIVATE :: ISTAT !this one FAILS
!
Extracted from PR 34741 :
$ cat bar.f90
character, pointer :: ptr(:)
allocate(ptr(1))
ptr = transfer('a',ptr)
end
$ gfortran bar.f90
f951: internal compiler error: Floating point exception
Please submit a full bug report,
with preprocessed source if appropriate.
See
While building RPM on hppa with gcc-4.2, build fails with the captioned error.
Somewhat reduced testcase attached.
Builds fine with -O1 or without -fPIC, or with older compilers.
ffmpeg and squashfs also fail to build with a similar error (not always built
with -fPIC)
--
Summary:
--- Comment #1 from burnus at gcc dot gnu dot org 2008-01-12 20:53 ---
Works for me. I think it is a duplicate of the very recently fixed PR 34537.
Can you check?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34761
--- Comment #1 from tausq at debian dot org 2008-01-12 20:54 ---
Created an attachment (id=14931)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14931action=view)
Testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34762
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO||32834
nThis||
With gfortran 4.3.0 20080109 I get the error message
n_interface.f:7.12:
END
1
Error: END SUBROUTINE statement expected at (1)
with the following program
module n
contains
subroutine n_interface
INTERFACE
SUBROUTINE NGSXDY(TLS1,TLS2)
--- Comment #12 from bonzini at gnu dot org 2008-01-12 21:09 ---
well if you can enjoy O(n) initialization (and O(1) clearing as in Peter's
code), you had better rewrite the code completely to query an item with one
(not two) memory accesses.
--
--- Comment #6 from burnus at gcc dot gnu dot org 2008-01-12 21:13 ---
One has to be careful not to to get the same problem as with SHAPE in PR 34759,
i.e. passing a rank-2 array A(:,:,5) defined as rank-3 assumed-shape array
A(:,:,*).
--
--- Comment #1 from burnus at gcc dot gnu dot org 2008-01-12 21:13 ---
Confirm, though your reduced test case is invalid (the variables k and l need
to be arrays. Corrected test case:
subroutine j_assumed_size(A,N)
dimension A(10,11,12,*), k(3), l(3)
k =
--- Comment #1 from burnus at gcc dot gnu dot org 2008-01-12 21:23 ---
Confirm. (Though you missed subroutine for end subroutine n_interface in
your example.)
The Fortran 2003 references are:
C1243 (R1230) FUNCTION shall appear in the end-function-stmt of an internal
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-01-12 21:53 ---
(In reply to comment #1)
Works for me. I think it is a duplicate of the very recently fixed PR 34537.
Can you check?
Bootstrapping right now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34761
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-01-12 21:44 ---
Probably a dup of PR32889.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34762
--- Comment #2 from steven at gcc dot gnu dot org 2008-01-12 22:03 ---
Created an attachment (id=14932)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14932action=view)
Robustify C/objC parser
Tested (objc only) on cygwin.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28050
(Please note this is a copy paste from Donald E. Knuth's homepage:
http://www-cs-faculty.stanford.edu/~uno/news.html - Given who he is, I think
the issue should receive a bit of love)
It is absolutely idiotic to have 64-bit pointers when I compile a program that
uses less than 4 gigabytes of
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-01-12 22:15 ---
Well first Knuth did read full the documentation because -mlong32 is only for
MIPS.
Second don't post flames.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from dcb314 at hotmail dot com 2008-01-12 22:17 ---
(In reply to comment #9)
i personally think that this patch in #8 is not the right way to go.
unless there is a compelling argument that initializing this is going to have
some negative performance effect, we should
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-01-12 22:27 ---
bla
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
1 - 100 of 137 matches
Mail list logo
