--- Comment #8 from burnus at gcc dot gnu dot org 2007-01-04 08:57 ---
Subject: Bug 30276
Author: burnus
Date: Thu Jan 4 08:57:36 2007
New Revision: 120431
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120431
Log:
2007-01-02 Tobias Burnus [EMAIL PROTECTED]
Jakub
Testcase: (compiled with -O2 at least)
int f(int a, int b)
{
if (a 0x7FF0) return 0;
if (b 0x7FF0) return 0;
int c = (a - 20) + (b - 20);
return c 0x7FF0;
}
GCC 4.1.2 and 4.3.0 (snapshot from 2006-12-17) optimizes the whole function to
a single return 0;. This would be
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #1 from guillaume dot melquiond at ens-lyon dot fr 2007-01-04
10:15 ---
Is it really a middle-end issue?
It could also be seen as a front-end issue, as it does produce a + b - 40,
doesn't it? If the front-end had given (a - 20) + (b - 20) to the middle-end,
then the
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-01-04 10:23 ---
(In reply to comment #1)
Is it really a middle-end issue?
Yes because fold is part of the middle-end that is most likely causing this
being translated into a + b - 40.
And this is the reason why the way wrote it
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-01-04 10:26 ---
This most likely comes from the associate: case in fold_binary where we
reassociate the PLUS_EXPR and MINUS_EXPR and then fold the -20 + -20 into -40.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30364
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |blocker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30364
When cross-compiling libstdc++, LFS support is turned on unconditionally, even
if the target does not support LFS.
As a result, linking fails (there is no fseeko64 for the target).
May be related to #22388
--
Summary: No possibility to disable large file support (LFS)
--- Comment #1 from aldot at gcc dot gnu dot org 2007-01-04 11:21 ---
Created an attachment (id=12854)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12854action=view)
Add configure option to en- or disable-largefile
libstdc++/ChangeLog
2007-01-04 Bernhard Fischer [EMAIL
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-01-04 11:23 ---
First uclibc really should support Large file support either the way BSD handle
it (in my mind the correct way) or the way SYSV does.
If this code can even compile, then uclibc's headers are inccorect in saying it
--- Comment #4 from guillaume dot melquiond at ens-lyon dot fr 2007-01-04
11:25 ---
Just for the sake of completeness. Wrong code is also generated when addition
and multiplication are mixed, because of distributivity:
int f(int a)
{
if (a 0x7FF0) return 0;
int b = (a - 20) *
--- Comment #3 from pcarlini at suse dot de 2007-01-04 11:27 ---
I don't understand: looking at configure.ac, GLIBCXX_CHECK_LFS is run *only* if
$GLIBCXX_IS_NATIVE is true. Otherwise, _GLIBCXX_USE_LFS remains undefined...
By the way, *when* _GLIBCXX_USE_LFS is defined, the library
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-01-04 11:31 ---
Hmm:
case $target in
*-uclinux*)
# Don't enable LFS with uClibc
;;
*)
AC_DEFINE(_GLIBCXX_USE_LFS)
esac
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #5 from aldot at gcc dot gnu dot org 2007-01-04 11:32 ---
(In reply to comment #2)
First uclibc really should support Large file support either the way BSD
handle
it (in my mind the correct way) or the way SYSV does.
The user can optionally turn it off. This is a
--- Comment #6 from pcarlini at suse dot de 2007-01-04 11:33 ---
(In reply to comment #3)
By the way, *when* _GLIBCXX_USE_LFS is defined, the library uses lseek64 (in
basic_file_stdio.cc), *not* fseeko64, and I'd like to also understand how
possibly on this target the former is
--- Comment #7 from aldot at gcc dot gnu dot org 2007-01-04 11:36 ---
removing wrong keyword link-failure
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pcarlini at suse dot de 2007-01-04 11:36 ---
(In reply to comment #4)
Hmm:
case $target in
*-uclinux*)
# Don't enable LFS with uClibc
;;
*)
AC_DEFINE(_GLIBCXX_USE_LFS)
esac
These bits in crossconfig.m4 are not
--- Comment #9 from pcarlini at suse dot de 2007-01-04 11:41 ---
By the way, the attached patch seems wrong, because changes GLIBCXX_CHECK_LFS,
which is not run at all when $GLIBCXX_IS_NATIVE is false.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30365
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-01-04 11:45
---
(In reply to comment #5)
(In reply to comment #2)
First uclibc really should support Large file support either the way BSD
handle
it (in my mind the correct way) or the way SYSV does.
The user can
--- Comment #11 from aldot at gcc dot gnu dot org 2007-01-04 11:46 ---
(In reply to comment #9)
By the way, the attached patch seems wrong, because changes GLIBCXX_CHECK_LFS,
which is not run at all when $GLIBCXX_IS_NATIVE is false.
The hunk against acinclude.m4 should perhaps be
--- Comment #12 from pcarlini at suse dot de 2007-01-04 11:46 ---
Another sparse observation: GLIBCXX_CHECK_LFS probably can be changed to be
simply an AC_TRY_COMPILE, because in C++ missing prototypes are diagnosed at
compile time.
--
pcarlini at suse dot de changed:
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-01-04 11:47
---
The question is how did JSM get uclibc to work when he patched libstdc++ for it
(PR 14939) ? Was he using a newer uclibc which actually has LFS support or
something else?
--
pinskia at gcc dot gnu dot org
--- Comment #14 from aldot at gcc dot gnu dot org 2007-01-04 11:49 ---
(In reply to comment #10)
(In reply to comment #5)
(In reply to comment #2)
First uclibc really should support Large file support either the way BSD
handle
it (in my mind the correct way) or the way SYSV
--- Comment #15 from aldot at gcc dot gnu dot org 2007-01-04 11:51 ---
(In reply to comment #13)
The question is how did JSM get uclibc to work when he patched libstdc++ for
it
(PR 14939) ? Was he using a newer uclibc which actually has LFS support or
something else?
He forced
--- Comment #16 from pcarlini at suse dot de 2007-01-04 11:53 ---
Irrespective of the other historical issues, assuming the test can be changed
to an AC_TRY_COMPILE, probably can be run also for crosses, we can pass to it
an --enable-lfs library configury argument and run it always, for
--- Comment #17 from pinskia at gcc dot gnu dot org 2007-01-04 11:54
---
Oh you can turn off LFS in uclibc :). So even disabling it for uclibc directly
is not correct.
Having a flag might be a good option but I feel it is the wrong thing to do
stuff.
I really don't think turning off
Hello everyone. Someone at the gentoo forums said i should report this here, so
i will try to provide a useful bug-report. If it isnt useful fell free to
ignore it.
After i rebuilt my whole toolchain with gcc-4.2 (which worked without problems)
i wanted to rebuild every package on my system. My
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-04 12:10 ---
First the code is undefined so the code will abort at runtime.
Second this is a dup of bug 29841.
*** This bug has been marked as a duplicate of 29841 ***
--
pinskia at gcc dot gnu dot org changed:
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-01-04 12:10
---
*** Bug 30366 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-01-04 12:12 ---
Also really you should report problems like this to the distro (or person) who
provided you the compiler.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30366
--- Comment #18 from aldot at gcc dot gnu dot org 2007-01-04 12:58 ---
(In reply to comment #10)
The comment does not match up with the actually check :).
I have a patch pending that fixes all these incorrect occurances of uclibc
where it ment to say uClinux. I intended to send it
--- Comment #19 from aldot at gcc dot gnu dot org 2007-01-04 13:00 ---
(In reply to comment #16)
Irrespective of the other historical issues, assuming the test can be
changed
to an AC_TRY_COMPILE, probably can be run also for crosses, we can pass to it
an --enable-lfs library
--- Comment #20 from joseph at codesourcery dot com 2007-01-04 13:07
---
Subject: Re: No possibility to disable large file
support (LFS)
On Thu, 4 Jan 2007, pinskia at gcc dot gnu dot org wrote:
The question is how did JSM get uclibc to work when he patched libstdc++ for
it
(PR
--- Comment #21 from pcarlini at suse dot de 2007-01-04 13:12 ---
(In reply to comment #20)
Since I made cross-Linux configurations require link tests to work in
order to build libstdc++ (because of another area where uClibc is
configurable, math.h functions), it should be possible
--- Comment #22 from joseph at codesourcery dot com 2007-01-04 13:17
---
Subject: Re: No possibility to disable large file
support (LFS)
On Thu, 4 Jan 2007, pcarlini at suse dot de wrote:
--- Comment #21 from pcarlini at suse dot de 2007-01-04 13:12 ---
(In reply to
--- Comment #23 from pcarlini at suse dot de 2007-01-04 13:19 ---
(In reply to comment #22)
uClibc has this unfortunate habit of declaring functions in the headers
even if they are configured out and so not present in the library. So for
anything involving uClibc, link tests are
Hi,
Gfortran successfully compiles our FUN3D Fortran 90 code base (~600KLOC) and
does so in comparable time to other compilers. When -Wall is turned on,
however, the compile times of certain large routines (e.g., the 12KLOC
Adjoint/residual_turbulent.f90), the compilation time increases from a
for the following example[1], it should exit with 0, but under gcc-4.0 gcc-4.1
gcc-4.2 and all optimize level(-O0, -O1, -O2, -O3), it exit with 1;
check gcc versions in [2]
[1]
/* begin */
struct A { int b; };
int main(int argc, char **argv)
{
struct A* a = 0;
if (a-b) return 1;
--- Comment #1 from lidaobing at gmail dot com 2007-01-04 14:25 ---
orignal reported by RoachCock in newsmth.net BBS
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30368
Host OS Centos release 3.8 (i.e. the public rebuild of RHEL 3 release 8) on a
1.8GHz PentiumM laptop with 512MB RAM.
Details of existing GCC version:
Configured with: ../gcc-3.4.3/configure --enable-languages=c,c++
--enable-__cxa_atexit --disable-checking --prefix=/opt/gcc/gcc-3.4.3
Thread
--- Comment #4 from tromey at gcc dot gnu dot org 2007-01-04 15:32 ---
Subject: Bug 28165
Author: tromey
Date: Thu Jan 4 15:32:26 2007
New Revision: 120441
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120441
Log:
libcpp
PR preprocessor/28165:
* internal.h
--- Comment #5 from tromey at gcc dot gnu dot org 2007-01-04 15:33 ---
I checked in a fix for this.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from patchapp at dberlin dot org 2007-01-04 15:35 ---
Subject: Bug number PR23232
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/msg00239.html
--
--- Comment #8 from pault at gcc dot gnu dot org 2007-01-04 15:46 ---
I have just submitted a patch.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from jeremy at jeremybennett dot com 2007-01-04 17:17
---
I've found it's a binutils problem - probably my own fault when installing the
original GCC 3.4.3.
--
jeremy at jeremybennett dot com changed:
What|Removed |Added
--- Comment #4 from brooks at gcc dot gnu dot org 2007-01-04 17:30 ---
Subject: Bug 30235
Author: brooks
Date: Thu Jan 4 17:30:37 2007
New Revision: 120447
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120447
Log:
fortran/
PR 30235
* interface.c
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org |
On an i686-pc-linux-gnu host, I configure GCC 4.3 (revision 120287) like this:
../../src/gcc/configure --enable-sim --with-newlib --disable-nls
--enable-e500_double --prefix=${HOME} --enable-checking=yes,rtl
--disable-threads --disable-shared --without-long-double-128
--- Comment #5 from brooks at gcc dot gnu dot org 2007-01-04 20:12 ---
Tobias: I like that idea, yes. Too much work for the moment, but I'll make a
note of it.
--
brooks at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from brooks at gcc dot gnu dot org 2007-01-04 20:14 ---
Fixed on trunk, as per commit in #4.
--
brooks at gcc dot gnu dot org changed:
What|Removed |Added
--
brooks at gcc dot gnu dot org changed:
What|Removed |Added
Status|REOPENED|ASSIGNED
Last reconfirmed|2006-12-17 08:34:15 |2007-01-04
--- Comment #24 from pcarlini at suse dot de 2007-01-04 20:25 ---
Created an attachment (id=12855)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12855action=view)
nb: includes regenerated configure
For now I'd like to go with this simple patch, per Joseph' suggestions. By the
way,
GFortran allows the kill subroutine to have array arguments for the first two
arguments, but it appears to me that libgfortran doesn't handle them as arrays.
Thus, I believe the following little code should error out, but it doesn't:
program kill1
call kill((/9, 8/), (/0, 0/))
end
If
--- Comment #25 from pcarlini at suse dot de 2007-01-04 20:31 ---
(In reply to comment #24)
For now I'd like to go with this simple patch, per Joseph' suggestions. By the
way, in the meanwhile I learned that other TRY_COMPILE tests are run under the
same heading.
Of course I meant
The kill intrinsic is only implemented in libgfortran for STATUS arguments of
types INTEGER(4) and INTEGER(8). However, the implementation in
gfc_resolve_kill_sub will attempt to link to implementations for any kind that
it's given, rather than reporting an error. Thus, the following little code
--- Comment #1 from joseph at codesourcery dot com 2007-01-04 20:34 ---
Subject: Re: New: [regression] Build failure in libgcc2
powitf2 with ICE in gen_reg_rtx
On Thu, 4 Jan 2007, rask at sygehus dot dk wrote:
-isystem ./include -specs=ldblspecs -g -DIN_LIBGCC2
There's your
--- Comment #13 from rolf dot ebert dot gcc at gmx dot de 2007-01-04 20:54
---
Why does the '--disable-libada' switch disable gnattools-cross?
libada and gnattools-cross are not related, IMHO. I consider the dependancy as
a configure/Makefile bug.
The following patch removes the
Some compilers (such as Pathscale, cf.
http://www.pathscale.com/docs/UserGuide.pdf, section 3.10.2) have an option to
check at run-time for aliasing among Fortran dummy arguments.
(This option has several friends, and when a customer sees a wrong answer, the
first thing we do (or the customer
The following program is (more or less) well-defined for the human reader, but
non-standard Fortran (which cannot be easily detected at compile time, cf. PR
30373).
gfortran outputs:
1 1 1
while ifort, NAG f95 and sunf95 output the expected:
4
--- Comment #14 from charlet at adacore dot com 2007-01-04 21:32 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] Can't compile gnattools for the
cross targets
libada and gnattools-cross are not related, IMHO. I consider the dependancy
as
a configure/Makefile bug.
The following
--- Comment #15 from charlet at adacore dot com 2007-01-04 21:39 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] Can't compile gnattools for the
cross targets
BTW, answering an old message:
Can you please describe how you tested the patch?
No test since I do not have a set up for
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-01-04 21:53 ---
They are still there:
L4:;
d.21085 = d.21085 + 1;
if (d.21085 != (int) ((unsigned int) d + 1 + (unsigned int) D.895788 +
(unsigned int) ~d)) goto L3; else goto L6;
L3:;
if (d = e0) goto L42; else goto L4;
A wine testcase started failing with the trunk compiler some days ago.
The difference is pretty obivous in the tree dump:
diff -u encode.c.056t.dce3 encode.c.057t.dse1
--- encode.c.056t.dce3 2007-01-04 23:03:14.0 +0100
+++ encode.c.057t.dse1 2007-01-04 23:03:14.0 +0100
@@ -52,7
I get the following failure trying to build aspell-0.60.5 with gcc 4.1.2
20061222 (prerelease):
bin/sh ./libtool --tag=CXX --mode=link i386-pc-linux-g++ -O3 -march=i386
-fno-strength-reduce -fno-exceptions -fno-exceptions -s -o aspell
prog/aspell.o prog/check_funs.o prog/checker_string.o
--- Comment #1 from marcus at jet dot franken dot de 2007-01-04 22:08
---
Created an attachment (id=12856)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12856action=view)
encode.i.bz2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30375
--- Comment #2 from marcus at jet dot franken dot de 2007-01-04 22:08
---
Created an attachment (id=12857)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12857action=view)
encode.c.056t.dce3
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30375
--- Comment #3 from marcus at jet dot franken dot de 2007-01-04 22:09
---
Created an attachment (id=12858)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12858action=view)
encode.c.057t.dse1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30375
--- Comment #4 from marcus at jet dot franken dot de 2007-01-04 22:10
---
generated by this cmd:
/home/marcus/projects/gcc/BIN/bin/gcc -m32 -c -I. -I. -I../../../include
-I../../../include -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing
-Wdeclaration-after-statement
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-01-04 22:21 ---
I think this was exposed/caused by the mem-ssa and the specific DSE
optimization for aggregate DSE:
2006-12-11 Aldy Hernandez [EMAIL PROTECTED]
* tree-ssa-dse.c (aggregate_vardecl_d): New.
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-04 22:25 ---
If I change the optimisation to -O2, the build completes, so I guess I have a
GCC problem.
No, not always. In fact what most likely happening is something is being
inlined (because of -O3) which was not before
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-04 22:29 ---
What GCC is doing is calling _gfortran_internal_pack/_gfortran_internal_unpack
in a different order than most other compilers.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30374
--- Comment #5 from roger at eyesopen dot com 2007-01-04 22:34 ---
Can you reduce a test case for the loop, now that the code in the PR
description is fixed? One thing that looks a bit odd is that in the condition
you describe the constant term 1, isn't on the far right, which I
--- Comment #4 from giovannibajo at libero dot it 2007-01-05 00:37 ---
Thanks Ira. What about store with gaps?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18438
--
brooks at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |brooks at gcc dot gnu dot
|dot org
The error message for the ill-formed code below is hard to read because of
the unnecessary cast and the explicit qualification of the data member. The
error becomes essentially unreadable when the code is more involved. Other
compilers manage to do better. For example, here's the diagnostic issued
I downloaded and installed (into /usr/local) gmp-4.2 and mpfr-2.2.1 on my OS X
10.4 host. I then downloaded gcc-4.2-20070102 (core only) and did 'configure'
and 'make -j2'.
It appears that the gcc build may for some reason expect that 32-bit OS X hosts
with Xcode installed have the assembler for
--- Comment #1 from brooks at gcc dot gnu dot org 2007-01-05 01:40 ---
Subject: Bug 30371
Author: brooks
Date: Fri Jan 5 01:40:06 2007
New Revision: 120468
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120468
Log:
PR 30371
* check.c (gfc_check_kill_sub): Add checks for
--- Comment #2 from brooks at gcc dot gnu dot org 2007-01-05 01:46 ---
Fixed.
--
brooks at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from kargl at gcc dot gnu dot org 2007-01-05 03:28 ---
The same problem is in 4.2, and I see no reason not to fix
it there.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30371
hello!
there is a nasty little bug in cppdefault.c in gcc 4.0.3:
wrong:
const char cpp_GCC_INCLUDE_DIR[] = GCC_INCLUDE_DIR;
const size_t cpp_GCC_INCLUDE_DIR_len = sizeof GCC_INCLUDE_DIR - 8;
correct:
const char cpp_GCC_INCLUDE_DIR[] = GCC_INCLUDE_DIR;
const size_t cpp_GCC_INCLUDE_DIR_len
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-05 04:25 ---
include is 7 characters which is what the -8 is for as I understand it.
I think you mishacked the cppdefault.c.
What is passed to cppdefault always includes include:
-DGCC_INCLUDE_DIR=\$(libsubdir)/include\ \
So
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-05 04:31 ---
It appears that the gcc build may for some reason expect that 32-bit OS X
hosts
with Xcode installed have the assembler for 64-bit OS X installed by default
(they don't). In any event, the build explodes like
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-05 04:34 ---
We could better pretty print: *((Bint*)this)-Bint::a += x to something
like:
*(this-Bint::a) += x
Which should get a better picture of things.
and the explicit qualification, I think that is actually a benifit to
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-05 04:52 ---
../../../unxfbsdi.pro/misc/dict_zh.cxx
g++-ooo: Internal error: Killed: 9 (program cc1plus)
This usually means GCC is running out of memory.
Can you do two things for us?
First can you give the output of g++-ooo
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30173
--- Comment #11 from patchapp at dberlin dot org 2007-01-05 05:00 ---
Subject: Bug number PR30162
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/msg00325.html
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-01-05 05:03 ---
This whole SPE port is a mess and needs really a different target rather than
being part of the rs6000 backend or a big rewrite (well both are big rewrites).
--
pinskia at gcc dot gnu dot org changed:
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-05 05:12 ---
First libmudflap really cannot be supported on cygwin.
Second your patch for libgomp should be sent to the gcc-patches@ list.
Third you are incorrect in saying mmap does not work because it does for so
many other
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-05 05:16 ---
building in the source directory is not well supported.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30341
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-01-05 05:23 ---
Actually this is undefined by the C standard as you are deferencing a null
pointer, yes a-b is implemented as a pointer arthematic but it is still a
deferencing according to the C standard.
--
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-01-05 05:29 ---
I am in correct in saying the problem is related to the call but instead it is
related to:
# MPT.775_180 = VDEF MPT.775_179(D)
info = {};
# MPT.775_181 = VDEF MPT.775_180
point = {};
They have the same
--- Comment #2 from chris2553 at googlemail dot com 2007-01-05 05:56
---
Subject: Re: aspell-0.60.5 fails to build with -O3 on gcc-4.1.2 20061222
(prerelease)
Thanks for the reply.
On Thursday 04 January 2007 22:25, pinskia at gcc dot gnu dot org wrote:
--- Comment #1 from
According to example in the F95 standard, this program should output 5, if
given inputs of 2 and 3. It does indeed do this.
program shiftcirc
integer i, j
read(*,*) i, j
write(*,*) ishftc( 3, i, j )
end program
However, if we replace i and j with constants, things start
--- Comment #1 from brooks at gcc dot gnu dot org 2007-01-05 06:57 ---
Currently testing a patch for this.
--
brooks at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #26 from gdr at integrable-solutions dot net 2007-01-05 07:02
---
Subject: Re: No possibility to disable large file support (LFS)
pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| I really don't think turning off LFS and using libstdc++ is a good idea
anyways
|
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2007-01-05 07:31
---
Still blocked by 25514. Mark, we badly need a decision for the latter.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
96 matches
Mail list logo
