Hello!
The 16bit target that i am porting to gcc4.1.2 doesn't have any
instructions for 32bit operations. But for addition and subtraction
there is
addc
subc
instructions that consider carry bit also. Presently i have patterns
for SImode addition and subtraction such that the template will have
Seen that 4.3.1 has been released, I tried to build
i486-linux-uclibc cross-compiler.
It went fine except for the detail that none of crt.o files
are found in installation directory after make install
For comparison, gcc 4.2.1's directory has them:
# find -name 'crt*.o'
The build of gcc-4.3-20080605 snapshot on holly with Solaris2.10 generated the
following warnings.
../../gcc-4.3-20080605/gcc/expr.c: In function 'expand_expr_real_1':
../../gcc-4.3-20080605/gcc/expr.c:8024: warning: unknown conversion type
character 'K' in
format
On Sat, Jun 7, 2008 at 2:43 AM, rkiesling [EMAIL PROTECTED] wrote:
The build on holly used the native SunOS build tools, so YMMV. If not
a duplication of effort, should I submit a patch to correct these
warnings?
Are these warnings during building stage1? If so ignore them. The
different
Andrew Pinski:
On Sat, Jun 7, 2008 at 2:43 AM, rkiesling [EMAIL PROTECTED] wrote:
The build on holly used the native SunOS build tools, so YMMV. If not
a duplication of effort, should I submit a patch to correct these
warnings?
Are these warnings during building stage1? If so ignore
On Sat, Jun 7, 2008 at 11:18 AM, Mohamed Shafi [EMAIL PROTECTED] wrote:
The 16bit target that i am porting to gcc4.1.2 doesn't have any
instructions for 32bit operations. But for addition and subtraction
there is
addc
subc
instructions that consider carry bit also. Presently i have patterns
glibc 2.7 fails to build with gcc 4.3.1 (error messages given below).
Investigating the error, I stumbled upon PR 36111. Applying the patch from
http://gcc.gnu.org/viewcvs/trunk/gcc/ChangeLog?view=markuppathrev=135221
makes gcc 4.3.1 build glibc OK (and everything else that I tried).
Maybe
Hello all,
Supplement to :
http://gcc.gnu.org/ml/gcc-testresults/2008-06/msg00543.html
http://gcc.gnu.org/ml/gcc-testresults/2008-06/msg00542.html
Since this is not (AFAICT) reported by test summary;
Most of it seems to be (presumably harmless) differences in white space.
However note at the
On Jun 5, 2008, at 10:38 AM, Ian Lance Taylor wrote:
Sure. But here's the thing: the gcc LTO approach involves having a
regular object with a regular symbol table, and the IR is embedded
in
the object. In other words, we do know the symbol version
information: it's in the symbol table of
On Jun 5, 2008, at 6:18 PM, Ian Lance Taylor wrote:
How does the linker tell LTO that a symbol may be inlined, but
must
also be externally visible?
The linker just tells LTO which symbols must remain. The LTO
engine
is free to inline anything that would improve codegen, with the
exception
Hello!
glibc 2.7 fails to build with gcc 4.3.1 (error messages given below).
Investigating the error, I stumbled upon PR 36111. Applying the patch from
http://gcc.gnu.org/viewcvs/trunk/gcc/ChangeLog?view=markuppathrev=135221
Mohamed Shafi [EMAIL PROTECTED] writes:
You can look into config/i386.md, how i.e. adddi3 is expanded and split in
case of !TARGET_64BIT.
But is it scheduling safe?
I mean you can't have addc executed before add. If i am right there
will be no dependency between the two instructions. So
On Sat, Jun 07, 2008 at 11:26:05AM +0200, Denys Vlasenko wrote:
Seen that 4.3.1 has been released, I tried to build
i486-linux-uclibc cross-compiler.
You probably forgot to build libgcc. Are you using 'make all' / 'make
install' or something more specific?
Also check the libgcc configure.host
--- Comment #2 from burnus at gcc dot gnu dot org 2008-06-07 06:18 ---
CONFIRM.
Paul, as out module.c expert, do you have an idea how to solve this?
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from paolo at gcc dot gnu dot org 2008-06-07 08:07 ---
Subject: Bug 35327
Author: paolo
Date: Sat Jun 7 08:06:46 2008
New Revision: 136518
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136518
Log:
/cp
2008-06-07 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #5 from paolo dot carlini at oracle dot com 2008-06-07 08:08
---
Fixed for 4.4.0.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #1 from dfranke at gcc dot gnu dot org 2008-06-07 08:30 ---
There are two ways to solve this:
(1) move -fpch-preprocess from gcc.c(cpp_options) into, say, cpp_c_options
and add cpp_c_options everywhere where cpp_options are used but fortran
(2) duplicate
--- Comment #3 from pault at gcc dot gnu dot org 2008-06-07 09:05 ---
Index: gcc/fortran/resolve.c
===
*** gcc/fortran/resolve.c (revision 136412)
--- gcc/fortran/resolve.c (working copy)
***
make[4]: Entering directory
`/home/x/workspace/build/x86_64-unknown-linux-gnu/libstdc++-v3/src'
/bin/sh ../libtool --tag CXX --mode=compile /home/x/workspace/build/./gcc/xgcc
-shared-libgcc -B/home/x/workspace/build/./gcc -nostdinc++
--- Comment #3 from paolo dot carlini at oracle dot com 2008-06-07 11:58
---
On it.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #1 from paolo dot carlini at oracle dot com 2008-06-07 12:02
---
Reminds me 30915... Gentoo? Did any recent previous release work for you?
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #3 from dfranke at gcc dot gnu dot org 2008-06-07 12:56 ---
Traced this down to libcpp, charset.c(cpp_interpret_string). There, the 'to'
string is not properly NUL-terminated, although the comments indicate that this
is the intention of the code.
Example:
$ cat x.f90
# 1
--- Comment #2 from wbrana at gmail dot com 2008-06-07 13:33 ---
I'm using Gentoo x86_64. It seems that bug 30915 isn't fixed.
There is comment in 30915, that bug appears also on SUSE.
I tried patch from 30915. It fails:
patching file fixincludes/fixincl.x
Hunk #1 FAILED at 2.
Hunk #2
--- Comment #30 from paolo dot carlini at oracle dot com 2008-06-07 13:34
---
*** Bug 36456 has been marked as a duplicate of this bug. ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #3 from paolo dot carlini at oracle dot com 2008-06-07 13:34
---
*** This bug has been marked as a duplicate of 30915 ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #4 from paolo dot carlini at oracle dot com 2008-06-07 13:36
---
By the way, loads of people use OpenSUSE, myself included, and 10.3 at least is
certainly fine.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36456
--- Comment #4 from dirtyepic at gentoo dot org 2008-06-07 14:39 ---
Created an attachment (id=15728)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15728action=view)
smaller testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36439
http://gcc.gnu.org/ml/fortran/2008-06/msg00048.html
For the sake of completeness, I want to flag that with recent snapshots of
GFortran, on CYGWIN, there are the following warnings, also with a simple
test-case:
$ cat hello.F95
program hello
print *,'Hello World!'
end program hello
$
--- Comment #17 from hutchinsonandy at gcc dot gnu dot org 2008-06-07
15:49 ---
Subject: Bug 27386
Author: hutchinsonandy
Date: Sat Jun 7 15:48:25 2008
New Revision: 136531
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136531
Log:
Backports from 4.4
PR target/27386
*
--- Comment #7 from hutchinsonandy at gcc dot gnu dot org 2008-06-07 15:49
---
Subject: Bug 34932
Author: hutchinsonandy
Date: Sat Jun 7 15:48:25 2008
New Revision: 136531
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136531
Log:
Backports from 4.4
PR target/27386
*
--- Comment #12 from hutchinsonandy at gcc dot gnu dot org 2008-06-07
15:49 ---
Subject: Bug 30243
Author: hutchinsonandy
Date: Sat Jun 7 15:48:25 2008
New Revision: 136531
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136531
Log:
Backports from 4.4
PR target/27386
*
--- Comment #4 from dfranke at gcc dot gnu dot org 2008-06-07 16:06 ---
Some progress:
libcpp, charset.c (emit_numeric_escape): here
cvt.width != CPP_OPTION (pfile, char_precision) [0 != 8]
If the logic of the check is inverted, everything works as expected. This
indicates that
--- Comment #1 from pault at gcc dot gnu dot org 2008-06-07 16:17 ---
(In reply to comment #0)
This comes about, indirectly, because of simplification. Change the the index
of the first item in the data list for 'c' to 2, for example. This can be
tracked back to resolve.c
--- Comment #1 from burnus at gcc dot gnu dot org 2008-06-07 16:47 ---
Backtrace:
in gfc_getmem (n=40) at gcc/fortran/misc.c:37
in gfc_get_interface_mapping_charlen at gcc/fortran/trans-expr.c:1485
in gfc_apply_interface_mapping_to_expr at gcc/fortran/trans-expr.c:1920
in
--- Comment #5 from dfranke at gcc dot gnu dot org 2008-06-07 16:51 ---
This should help:
+ cpp_option-char_precision = TYPE_PRECISION (char_type_node);
However, now I'm stuck with an ordering problem ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36379
--- Comment #11 from burnus at gcc dot gnu dot org 2008-06-07 17:04 ---
rev. 136130 contains the fixes from comment #2 and comment #3, but the test
case from comment #1 is still failing.
Diff between dumped tree from comment #6 (working) and comment #1 (failing):
- f (parm.38);
+
FAIL: gfortran.fortran-torture/execute/common.f90 execution, -O2
-ftree-vectorize -msse2
FAIL: gfortran.fortran-torture/execute/common_size.f90 execution, -O2
-ftree-vectorize -msse2
FAIL: gfortran.fortran-torture/execute/forall_3.f90 execution, -O2
-ftree-vectorize -msse2
FAIL:
--- Comment #12 from burnus at gcc dot gnu dot org 2008-06-07 17:30 ---
It turned out to be a attr-related thing. f needs to be 0 in the following and
it was 1:
trans-expr.c:2525 gfc_conv_function_call
int f;
f = (fsym != NULL)
--- Comment #13 from burnus at gcc dot gnu dot org 2008-06-07 17:43 ---
MINE :-)
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|janus
The following valid program is rejected. The problem is that gfortran assigns
the interface of the INTRINSIC function cos to f and not the one of the
abstract interface. If one uses interface instead of abstract interface it
works.
abstract interface
function dim()
integer :: dim
end
--- Comment #1 from ubizjak at gmail dot com 2008-06-07 18:44 ---
Don't compile with -msse2 if your target doesn't support SSE2.
Tests works OK with:
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
--- Comment #3 from burnus at gcc dot gnu dot org 2008-06-07 18:53 ---
Subject: Bug 36437
Author: burnus
Date: Sat Jun 7 18:53:07 2008
New Revision: 136536
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136536
Log:
2008-06-04 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #4 from burnus at gcc dot gnu dot org 2008-06-07 18:57 ---
F2008's C_SIZEOF is implemented and also the simplification in trans-*.c. The
simplification for arrays in simplify.c is missing; attachment 15721 can be
used as starting point.
--
burnus at gcc dot gnu dot org
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-06-07 19:24 ---
I didn't compile it that way myself; those are testsuite failures.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from janus at gcc dot gnu dot org 2008-06-07 20:15 ---
The problem is that gfortran assigns the interface
of the INTRINSIC function cos to f
You surely mean the intrinsic function DIM ;)
If one uses interface instead of abstract interface it works.
No, for me it
template class a
class A {};
template class b
class B {};
ABvoid() x;
If you leave out the space between the two 's at the definition of x, it fails
to compile. As far as I'm aware this should work in C++0x mode. The compiler
was run with -std=c++0x.
[EMAIL PROTECTED]:~/atlantisos/kernel$ g++
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2008-06-07 20:18
---
Working on this now.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
I will firstly admit that I don't know if exception throws /should/ use rvalue
reference constructors - the proposed working at
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2118.html doesn't
mention it, but one certainly would have thought it would.
In my project I have a
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-07 20:21 ---
Really this is why think C++0x was wrong in thinking that can be used as
in the template context :).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36460
--- Comment #2 from janus at gcc dot gnu dot org 2008-06-07 21:01 ---
This patch fixes both of the test cases in comment #0 and comment#1:
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c (revision 136533)
+++
--- Comment #14 from uros at gcc dot gnu dot org 2008-06-07 21:14 ---
Subject: Bug 36111
Author: uros
Date: Sat Jun 7 21:13:29 2008
New Revision: 136538
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136538
Log:
Backport from mainline:
2008-05-12 Uros Bizjak
--- Comment #3 from burnus at gcc dot gnu dot org 2008-06-07 21:15 ---
This is the same check that's done in resolve.c (resolve_actual_arglist) for
dummy procedures.
Thanks for the quick patch.
(Do you think my patch for PR35830 is OK? Off topic: I'd really like to see
proc pointers
--- Comment #6 from spop at gcc dot gnu dot org 2008-06-07 22:58 ---
Subject: Bug 34976
Author: spop
Date: Sat Jun 7 22:57:55 2008
New Revision: 136543
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136543
Log:
2008-05-08 Sebastian Pop [EMAIL PROTECTED]
PR
--- Comment #7 from spop at gcc dot gnu dot org 2008-06-07 22:59 ---
Fixed both in 4.3 and in trunk.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2008-06-07 23:56
---
Subject: Bug 36420
Author: jvdelisle
Date: Sat Jun 7 23:55:47 2008
New Revision: 136544
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136544
Log:
2008-06-07 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2008-06-08 00:00
---
Subject: Bug 36421
Author: jvdelisle
Date: Sat Jun 7 23:59:53 2008
New Revision: 136545
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136545
Log:
2008-06-07 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2008-06-08 00:00
---
Subject: Bug 36420
Author: jvdelisle
Date: Sat Jun 7 23:59:53 2008
New Revision: 136545
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136545
Log:
2008-06-07 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-06-08 00:00
---
Subject: Bug 36422
Author: jvdelisle
Date: Sat Jun 7 23:59:53 2008
New Revision: 136545
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136545
Log:
2008-06-07 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2008-06-08 00:09
---
Subject: Bug 36421
Author: jvdelisle
Date: Sun Jun 8 00:09:01 2008
New Revision: 136547
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136547
Log:
2008-06-07 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2008-06-08 00:09
---
Subject: Bug 36420
Author: jvdelisle
Date: Sun Jun 8 00:09:01 2008
New Revision: 136547
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136547
Log:
2008-06-07 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2008-06-08 00:09
---
Subject: Bug 36422
Author: jvdelisle
Date: Sun Jun 8 00:09:01 2008
New Revision: 136547
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136547
Log:
2008-06-07 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #8 from mt-ml at gmx dot de 2008-06-08 00:17 ---
I've been able to identify the code where ilog2 is called. If I do not choose
usbcore as a module I get the following error:
drivers/built-in.o: In function `usb_submit_urb':
(.text+0xc247f): undefined reference to
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2008-06-08 00:30
---
New feature added.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2008-06-08 00:30
---
Fixed on trunk.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2008-06-08 00:31
---
Fixed on trunk.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
On Sat, Jun 7, 2008 at 5:17 PM, mt-ml at gmx dot de
[EMAIL PROTECTED] wrote:
As you can see, the argument to ilog2 is urb-interval which can't be zero at
that point IMHO.
Yes and that requires a lot of jump threading and many other
optimizations to detect that really. First PRE has to be
--- Comment #9 from pinskia at gmail dot com 2008-06-08 00:33 ---
Subject: Re: [Regression] compile error in linux-kernel 2.6.26-rc4 with -O2
On Sat, Jun 7, 2008 at 5:17 PM, mt-ml at gmx dot de
[EMAIL PROTECTED] wrote:
As you can see, the argument to ilog2 is urb-interval which can't
$ cat a.f90
character(10) string
string = 'ABCDEEDCBA'
write(*,*) index(string,'A',kind=1)
end
$ gfortran a.f90 ./a.out
10
I suspect we're passing 1 as a logical BACK argument to the library function.
Well, I do more than suspect, I checked and that's indeed what we do :)
Work
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #2 from tristan_schmelcher at alumni dot uwaterloo dot ca
2008-06-08 01:41 ---
Just a note for posterity:
Using offsetof in this particular case (and many others) will work in G++, but
the standard doesn't require that, so in theory it's not portable. That's why
G++ prints
--- Comment #15 from ubizjak at gmail dot com 2008-06-08 05:53 ---
Fixed also for 4.3.2.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Summary|[4.4
--- Comment #16 from ubizjak at gmail dot com 2008-06-08 05:55 ---
(In reply to comment #15)
Fixed also for 4.3.2.
See http://gcc.gnu.org/ml/gcc/2008-06/msg00172.html
--
ubizjak at gmail dot com changed:
What|Removed |Added
72 matches
Mail list logo