I have upgraded from gcc 4.2.2 to gcc 4.3.1 and it seems like the install
procedure does not work. When compiling the simple program:
#include
int main()
{
return 1;
}
I get the following output:
mises syde/MAIN/te
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-12 09:11 ---
>error: stdlib.h: No such file or directory
It should have been in:
> /usr/include
Which is included in the include path. Are you sure you have the includes
installed?
--
http://gcc.gnu.org/bugzilla/show_bug.
--- Comment #5 from martin at kfib dot org 2008-06-12 09:13 ---
Never mind, I will do it. I'm a total klutz and I apologize. This is very, very
embarrassing.
If someone ever have a similar problem, make sure they're not running
avr-objcopy with the flag -j .text...
--
martin at kfib
--- Comment #2 from pontus dot astrom at csr dot com 2008-06-12 09:16
---
Created an attachment (id=15752)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15752&action=view)
Log of the install output.
This is a log of "make install" with all references to java installs cut out
too
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-06-12 09:25 ---
We have the SHIFT_COUNT_TRUNCATED macro for this (though I'm not sure if
that says negative values are ok).
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-06-12 09:29 ---
Program received signal SIGSEGV, Segmentation fault.
0x008be25d in dr_analyze_alias (dr=0x1424660)
at /space/rguenther/src/svn/gcc-4_3-branch/gcc/tree-data-ref.c:769
769 if (DECL_P (base))
(gdb) pri
--- Comment #3 from pontus dot astrom at csr dot com 2008-06-12 09:29
---
Subject: RE: C++ inludes do not work
Yes I am completely sure it is there. I just double-checked. In addition, my
gcc-4.2.2 install, compiled and installed with identical options, does not have
the problem.
Bes
--- Comment #4 from jakub at gcc dot gnu dot org 2008-06-12 10:05 ---
Created an attachment (id=15754)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15754&action=view)
gcc44-pr36405.patch
I think the right fix is to ensure the type is complete in all cases but
VOID_TYPE. For ARRA
--- Comment #4 from jakub at gcc dot gnu dot org 2008-06-12 10:13 ---
Only partly fixed so far - we don't ICE anymore, but no warning is generated.
See http://gcc.gnu.org/ml/gcc-patches/2008-06/msg00474.html
Doug, any ideas how to differentiate between pack expansion resulting in no
tsub
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35542
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35860
--- Comment #5 from paolo dot carlini at oracle dot com 2008-06-12 10:19
---
Sure, please go ahead with submitting your patch.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
int
main (void)
{
int sum = 0;
#pragma omp parallel
#pragma omp sections reduction (+:sum)
{
#pragma omp section
sum += 2;
#pragma omp section
sum += 2;
#pragma omp section
sum += 2;
}
return sum != 6;
}
ICEs with -fopenmp since
http://gcc.gnu.org/viewcv
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-06-12 10:22 ---
Subject: Bug 36345
Author: rguenth
Date: Thu Jun 12 10:21:45 2008
New Revision: 136695
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136695
Log:
2008-06-12 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-06-12 10:23 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-06-12 10:24 ---
The patch that rewrites call-clobbering deals with this.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from ubizjak at gmail dot com 2008-06-12 10:43 ---
(In reply to comment #2)
> We have the SHIFT_COUNT_TRUNCATED macro for this (though I'm not sure if
> that says negative values are ok).
They are, but there is a comment in the documentation:
-- Macro: SHIFT_COUNT_TRUNCA
--- Comment #1 from jakub at gcc dot gnu dot org 2008-06-12 11:04 ---
Subject: Bug 36506
Author: jakub
Date: Thu Jun 12 11:03:50 2008
New Revision: 136696
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136696
Log:
PR middle-end/36506
* omp-low.c (expand_omp_secti
--- Comment #2 from jakub at gcc dot gnu dot org 2008-06-12 11:08 ---
Subject: Bug 36506
Author: jakub
Date: Thu Jun 12 11:07:20 2008
New Revision: 136697
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136697
Log:
PR middle-end/36506
* omp-low.c (expand_omp_secti
--- Comment #3 from jakub at gcc dot gnu dot org 2008-06-12 11:13 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #23 from jakub at gcc dot gnu dot org 2008-06-12 11:17 ---
Subject: Bug 36443
Author: jakub
Date: Thu Jun 12 11:17:05 2008
New Revision: 136698
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136698
Log:
PR testsuite/36443
* gcc.dg/compat/struct-layout
--- Comment #24 from jakub at gcc dot gnu dot org 2008-06-12 11:39 ---
Subject: Bug 36443
Author: jakub
Date: Thu Jun 12 11:38:55 2008
New Revision: 136700
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136700
Log:
PR testsuite/36443
* gcc.dg/compat/struct-layout
--- Comment #25 from jakub at gcc dot gnu dot org 2008-06-12 11:41 ---
Committed patch Janis approved as temporary solution.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #26 from hjl dot tools at gmail dot com 2008-06-12 12:33
---
Don't we need the same workaround in
./objc.dg/gnu-encoding/gnu-encoding.exp:set status [remote_exec host "$HOSTCC
$HOSTCFLAGS $generator_cmd"]
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36443
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36506
--- Comment #1 from linuxl4 at sohu dot com 2008-06-12 12:50 ---
definitely should.
a simple wrong typing can lead to an error even without compiler's warning.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36495
int main (void)
{
int i = 2;
inline int bar (void)
{
return i;
}
return bar () - 2;
}
doesn't link with -O0 -std=gnu99, works with -O0 -std=gnu99 -fgnu89-inline,
or -O1 -std=gnu99, or -O0 -std=gnu89. As extern inline for nested function
is rejected, I believe we need to avoid clearin
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36507
--- Comment #1 from jakub at gcc dot gnu dot org 2008-06-12 13:01 ---
I wonder if we shouldn't automatically assume gnu_inline semantics for nested
functions (given that extern inline is forbidden in nested contexts and relying
on other CUs defining the external definition can't work, as
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36507
--- Comment #2 from clerman at fuse dot net 2008-06-12 13:11 ---
Subject: Re: incorrect error when compiling
Hello,
Thank you for your quick reply. Attached is an archive, bug2.tar. Unpack it
and invoke the shell script bug2.sh. You should be able to reproduce the
problem. The file
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-06-12 13:18 ---
I think that makes sense.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-06-12 13:31 ---
Actually this is a regression.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-06-12 13:34 ---
This is a regression with -O2 -fno-tree-sra and the testcase from the initial
description.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from jakub at gcc dot gnu dot org 2008-06-12 13:50 ---
Subject: Bug 36506
Author: jakub
Date: Thu Jun 12 13:49:18 2008
New Revision: 136708
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136708
Log:
PR middle-end/36506
* omp-low.c (expand_omp_secti
--- Comment #3 from joseph at codesourcery dot com 2008-06-12 13:54 ---
Subject: Re: [4.3/4.4 Regression] ISO C99 inline semantics
doesn't play together with nested functions
On Thu, 12 Jun 2008, jakub at gcc dot gnu dot org wrote:
> I wonder if we shouldn't automatically assume gnu_
--- Comment #5 from jakub at gcc dot gnu dot org 2008-06-12 13:54 ---
Subject: Bug 36506
Author: jakub
Date: Thu Jun 12 13:53:45 2008
New Revision: 136709
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136709
Log:
PR middle-end/36506
* omp-low.c (expand_omp_secti
The attached testcase ICEs on ppc*-linux with -O2 -m32 and -O2 -m64:
internal compiler error: in compute_antic, at tree-ssa-pre.c:2020
2019 /* Theoretically possible, but *highly* unlikely. */
2020 gcc_assert (num_iterations < 50);
num_iterations is 50.
The code is distilled from
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36508
--- Comment #1 from jakub at gcc dot gnu dot org 2008-06-12 13:58 ---
Created an attachment (id=15756)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15756&action=view)
rh450889.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36508
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-06-12 14:00 ---
Probably related to PR36439.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-06-12 14:04 ---
It works for me on x86_64. Confirmed on ppc.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #110 from pepalogik at seznam dot cz 2008-06-12 14:14 ---
I used an old version of GCC documentation so I omitted some new processors
with SSE: core2, k8-sse3, opteron-sse3, athlon64-sse3, amdfam10 and barcelona.
I think you can use -march=pentium3 for all Intel's CPUs (of co
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-06-12 14:15 ---
We get different gimplification on x86_64 and ppc due to branch-cost
differences
(appearantly):
- :;
- D.1604 = i <= 125;
- D.1605 = k <= 11;
- D.1606 = D.1604 && D.1605;
- if (D.1606)
+ :;
+ if (i > 125)
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-06-12 14:20 ---
Well not branch cost differences but LOGICAL_OP_NON_SHORT_CIRCUIT is 0. Now
LOGICAL_OP_NON_SHORT_CIRCUIT should be 1 on PPC but there needs some expand
support for getting the bools using crand/crand instructions (w
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-06-12 14:21 ---
Created an attachment (id=15757)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15757&action=view)
testcase that fails on x86_64 as well
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36508
--- Comment #6 from gunnar at greyhound-data dot com 2008-06-12 14:26
---
Andreas,
Could you have a look at this?
Cheers
Gunnar
--
gunnar at greyhound-data dot com changed:
What|Removed |Added
--- Comment #6 from gunnar at greyhound-data dot com 2008-06-12 14:27
---
Andreas,
could you please have a look at this?
Cheers
Gunnar
--
gunnar at greyhound-data dot com changed:
What|Removed |Added
-
On Linux/ia32 and Linux/Intel64, revision 136695 gives:
FAIL: gcc.dg/Wstrict-aliasing-float-ptr-int-obj.c (test for warnings, line 14)
FAIL: gcc.dg/Wstrict-aliasing-float-ptr-int-obj.c (test for warnings, line 16)
Revision 136693 is OK. It may be caused by revision 136695:
http://gcc.gnu.org/m
--- Comment #3 from gunnar at greyhound-data dot com 2008-06-12 14:34
---
Andreas,
What is your opinion to this?
GCC 2.9 used to combine the move with increment in the combine step to
something like this:
***
(insn 32 30 33 (set (reg/v:SI 32)
(mem:SI (post_inc:SI (reg/v:SI 34)
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-06-12 14:38 ---
This comes down to IV-OPTs not understanding {post,pre}_{dec,inc} at all.
There is another bug about this somewhere I think for arm. PowerPC has the
same issue too ...
--
http://gcc.gnu.org/bugzilla/show_bug.c
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-06-12 14:39 ---
The following fails with -O -ftree-pre:
void
foo (short *sp)
{
int k;
k = 1;
#define SP0 *sp++ = 1;
while (1)
{
if (k > 6)
break;
SP0
k++;
}
k = 1;
while (1)
{
i
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-06-12 14:41 ---
I guess the assert is just bogus. But of course maybe Danny wants to have a
look?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-06-12 14:46 ---
This is basically PR34386
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
BugsThis
--- Comment #9 from dberlin at gcc dot gnu dot org 2008-06-12 14:51 ---
Subject: Re: [4.3 Regression] ICE in compute_antic
The assert is there because often when people break PRE, it goes into
infinite loops due to non-convergence, and eats all memory and CPU
very very very quickly.
It
--- Comment #10 from dberlin at gcc dot gnu dot org 2008-06-12 14:52
---
FWIW, the comment right above the assert has proven to be true.
In a few years and releases, this is only the second time anyone has ever hit
it :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36508
FAIL: gcc.dg/vect/costmodel/ppc/costmodel-vect-31d.c scan-tree-dump-times vect
"vectorization not profitable" 1
FAIL: gcc.dg/vect/costmodel/ppc/costmodel-vect-31d.c scan-tree-dump-times vect
"vectorized 1 loops" 0
FAIL: gcc.dg/vect/costmodel/ppc/costmodel-vect-68d.c scan-tree-dump-times vect
"vecto
--- Comment #2 from burnus at gcc dot gnu dot org 2008-06-12 16:16 ---
Fixed for INDEX and SCAN, but leaving open as reminder for the following:
> Will need auditing other intrinsics that were added a KIND argument in F2003.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36462
--- Comment #3 from burnus at gcc dot gnu dot org 2008-06-12 16:17 ---
Subject: Bug 36462
Author: burnus
Date: Thu Jun 12 16:16:39 2008
New Revision: 136712
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136712
Log:
2008-06-12 Tobias Burnus <[EMAIL PROTECTED]>
PR fort
--- Comment #4 from astrange at ithinksw dot com 2008-06-12 16:48 ---
Maybe it seemed likely to cause a warning - I haven't checked that yet, though.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36503
For the following C++ source code
typedef void * FILE;
FILE *fp;
extern int fprintf (FILE *__restrict __stream, __const char *__restrict
__format, ...);
int
bert(void)
{
const char * fred = "\n";
fprintf( fp, "%s", fred);
return 0;
}
The GNU C++ compiler version 4.4 snapshot 20080606 says
--- Comment #8 from hjl at gcc dot gnu dot org 2008-06-12 17:04 ---
Subject: Bug 36479
Author: hjl
Date: Thu Jun 12 17:03:41 2008
New Revision: 136714
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136714
Log:
2008-06-12 H.J. Lu <[EMAIL PROTECTED]>
PR preprocessor/364
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-06-12 18:16 ---
(In reply to comment #0)
> As PR 36471 shows, building libgfortran's Fortran parts with -fimplicit-none
> can help detecting programming errors in the Fortran written parts of
> libgfortran.
>
> I suggest to use suc
--- Comment #5 from tkoenig at gcc dot gnu dot org 2008-06-12 18:20 ---
This is an instance of PR 34670.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
Oth
Bootstrap compiler is
# gcc -v
Using built-in specs.
Target: powerpc-apple-darwin8.11.0
Configured with: /usr/local/gcc-4.3.0/src/gcc-4.3.0/configure
--enable-languages=c --with-gmp=/usr/local/gmp-4.2.2/G5-Darwin-gcc-4.2.3-abi32
--with-mpfr=/usr/local/mpfr-2.3.1/G5-Darwin-gmp-4.2.2-gcc-4.2.3-abi3
--- Comment #3 from burnus at gcc dot gnu dot org 2008-06-12 18:32 ---
Created an attachment (id=15758)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15758&action=view)
Patch; TODO: Create test cases (incl. for kind=4)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36476
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-12 18:34 ---
I build GCC all the time on powerpc-darwin with no issues.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #9 from hjl dot tools at gmail dot com 2008-06-12 18:39 ---
Fixed as of revision 136717:
http://gcc.gnu.org/ml/gcc-testresults/2008-06/msg00994.html
Revision 136712:
http://gcc.gnu.org/ml/gcc-testresults/2008-06/msg00993.html
FAIL: gcc.dg/pch/save-temps-1.c -O0 -g assembl
Compiling the following code with gcc-4.3 -Wlogical-op -O1
int main ()
{
char *s, t;
strchr (s, t);
}
leads to this warning:
test2.c: In function main:
test2.c:7: warning: logical && with non-zero constant will always evaluate as
true
This is because libc defines strchr to a macro in bit
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-12 19:08 ---
Well also I think glibc should not need to optimise strchr really and let the
compiler do it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36513
--- Comment #4 from burnus at gcc dot gnu dot org 2008-06-12 19:26 ---
> TODO: Create test cases (incl. for kind=4)
And with -std=f95: checking for equal string lengths. Also the initialization
by an other parameter should be checked. I will work on a test case in the next
days.
--
b
--- Comment #11 from rguenther at suse dot de 2008-06-12 20:17 ---
Subject: Re: [4.3 Regression] ICE in compute_antic
On Thu, 12 Jun 2008, dberlin at gcc dot gnu dot org wrote:
> --- Comment #10 from dberlin at gcc dot gnu dot org 2008-06-12 14:52
> ---
> FWIW, the comment r
The inline assembly I use in one function generates code which the assembler
does not understand (it generates a non existant cpu register).
This is the commandline output:
Using built-in specs.
Target: i586-elf
Configured with: ../gcc-4.3.1/configure --target=i586-elf --prefix=/usr/cross
--
disa
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-12 21:22 ---
It is wrong to use "r" constraint here really.
*** This bug has been marked as a duplicate of 23242 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-06-12 21:22 ---
*** Bug 36514 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #20 from roger at eyesopen dot com 2008-06-12 21:31 ---
Hi Ralf,
Thanks for your patch.
Sorry for the delay in replying, I needed to check out mainline on my IRIX
box and rebuild a baseline, and once that had completed "make -k check",
I tried with "--enable-fixed-point" fi
--- Comment #21 from Ralf dot Wildenhues at gmx dot de 2008-06-12 21:46
---
Subject: Re: [4.3/4.4 Regression] "Arg list too long"
building libgcc.a
* roger at eyesopen dot com wrote on Thu, Jun 12, 2008 at 11:31:02PM CEST:
> that we die just a little further on with
> a simila
Integer read from stdin yields a value overflow for a valid integer. Here's
the example program:
{{{
program int_range
integer*4 smallest
100 format(1i11)
read(5,100) smallest
print 100,smallest
end
}}}
If compiled and invoked as
{{{
echo -2147483648 | ./int_range
}}}
it yields
{{{
Fortr
--- Comment #1 from kargl at gcc dot gnu dot org 2008-06-12 22:14 ---
Sigh. This has been beaten to death.
-2147483648 is a unary minus operating on the operand 2147483648.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36515
--- Comment #2 from Walter dot Szeliga at Colorado dot EDU 2008-06-12
22:21 ---
Subject: Re: Integer read from stdin yields a value overflow for a valid
integer.
Sorry, I googled the crap out of it, but didn't find that
explanation. Maybe this should be in the one of the FAQs. Wha
--- Comment #6 from sebasmagri at gmail dot com 2008-06-13 01:28 ---
I'm getting the same message on a Gentoo/amd64 box... It's reported on gentoo
bugzilla http://bugs.gentoo.org/show_bug.cgi?id=225605
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35923
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-06-13 03:04
---
There is no "proper" way.
Use -2147483647 which is the most negative integer representable in 32 bits.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from Walter dot Szeliga at Colorado dot EDU 2008-06-13
03:09 ---
Subject: Re: Integer read from stdin yields a value overflow for a valid
integer.
OK, thanks. Not that this is something to strive for, but I have some
legacy software that works with G77 (ugh). One of
--- Comment #5 from kargl at gcc dot gnu dot org 2008-06-13 03:25 ---
(In reply to comment #3)
> There is no "proper" way.
>
> Use -2147483647 which is the most negative integer representable in 32 bits.
>
This isn't necessarily true. :)
There are a few options.
1) Add -fno-range-ch
--- Comment #6 from kargl at gcc dot gnu dot org 2008-06-13 03:30 ---
As much as I hate -huge()-1, I think this needs to be fix in some
manner. So, I'm re-opening the bug. Jerry et al, if you feel
this should be closed, then please re-close the bug.
--
kargl at gcc dot gnu dot org
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2008-06-13 04:19
---
Actually, I was just checking what g77 does and noticed that -fno-range-check
did not do the trick with gfortran as I expected, so Steve beat me to the
punch. For legacy compatibility with g77 I think we should e
--
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 4.3 crashes on the 38 megabyte file generated with:
#!/usr/bin/perl -w
print < test.c
gcc-4.3 -c test.c
Gcc-4.2 was able to handle a file 4 time bigger (4M entries),
eating only about 2 gigabytes or RAM. I was not able to confirm
that it could survive 6M, because ot the limited ram and
trash
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-06-13 04:37 ---
So people don't understand that in Fortran types are symmetric? Hasn't they
been symmetric for 20 years now? How can this be for latency programs really?
Maybe gfortran is just the first compiler which enforces th
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-13 04:57 ---
This is the same issue as PR 14179.
*** This bug has been marked as a duplicate of 14179 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #47 from pinskia at gcc dot gnu dot org 2008-06-13 04:57
---
*** Bug 36516 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #9 from kargl at gcc dot gnu dot org 2008-06-13 05:31 ---
(In reply to comment #8)
> So people don't understand that in Fortran types are symmetric? Hasn't they
> been symmetric for 20 years now? How can this be for latency programs
> really?
> Maybe gfortran is just the
Type spec support for constructors was implemented in PR27997, however, it is
not honored for the -std=f* checking for PARAMETERs.
The following program works with default options, however, using -std=f2003 one
gets the follow error message:
Error: The CHARACTER elements of the array constructor
95 matches
Mail list logo
