Rainer Emrich [EMAIL PROTECTED] writes:
Does anybody else sees this?
Comparing stages 2 and 3
Bootstrap comparison failure!
See http://gcc.gnu.org/ml/gcc-patches/2008-07/msg00973.html.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5,
Mohamed Shafi wrote:
2008/7/15 Ramana Radhakrishnan [EMAIL PROTECTED]:
snipped parts of the last mail
I agree with you, but what about when there are still caller save
register are available and there are no register restrictions for any
instructions? In my case i find that GCC has used
Hello all,
I am involved in the porting of gcc 4.1.2 for 16 bit target. For this
target size of long long is 32bits. For the following code
#define VALUE 0x1B4E81B4E81B4DLL
#define AFTER 0x55
//void test (int n, long long q, int y);
void test (int n, ...);
int
main ()
{
test (1, VALUE,
Hello,
I tried to use doloop_end pattern to reduce loop overhead for our target
processor, which features a dedicated loop instruction. Somehow even a
simple loop just cannot pass the test of doloop_condition_get, which
requires following canonical pattern.
/* The canonical doloop pattern we
Mohamed Shafi [EMAIL PROTECTED] writes:
I am involved in the porting of gcc 4.1.2 for 16 bit target. For this
target size of long long is 32bits. For the following code
#define VALUE 0x1B4E81B4E81B4DLL
That is not a 32-bit value.
#define AFTER 0x55
//void test (int n, long long q, int
Bingfeng Mei [EMAIL PROTECTED] writes:
I tried to use doloop_end pattern to reduce loop overhead for our target
processor, which features a dedicated loop instruction. Somehow even a
simple loop just cannot pass the test of doloop_condition_get, which
requires following canonical pattern.
2008/7/16 Ian Lance Taylor [EMAIL PROTECTED]:
Mohamed Shafi [EMAIL PROTECTED] writes:
I am involved in the porting of gcc 4.1.2 for 16 bit target. For this
target size of long long is 32bits. For the following code
#define VALUE 0x1B4E81B4E81B4DLL
That is not a 32-bit value.
#define
On Mon, 14 Jul 2008, Diego Novillo wrote:
You've been doing great work on the branch, so Aldy and I think that
you don't really need patch approval for branch patches anymore. So,
from now on, feel free to commit your patches without waiting for an
explicit approval.
Hear, hear. ;-) Do you
Mohamed Shafi [EMAIL PROTECTED] writes:
The value is too big for a long long. When you specify the type, gcc
is forced to convert (I hope you can get a warning for that). When
you don't specify the type, gcc does not convert. The resulting value
has a type which can only be expressed using
I can confirm that the doloop optimization is applied for ARC600 / ARC700
in a compiler based on gcc 4.4.0 20080606 (experimental) .
OTOH, it doesn't use any of the PRE_INC, POST_INC, PRE_MODIFY or
POST_MODIFY addressing modes.
lp .L__GCC__LP2
.align 4
.L2:
add r0,r1,r4
Thanks. I just checked the latest mainline version and couldn't find
doloop related stuff in config/arc/arc.md. Will you merge your code
into mainline? Did you also get modulo scheduling work properly?
Bingfeng
-Original Message-
From: Joern Rennecke [mailto:[EMAIL PROTECTED]
libmudflap tests set a environment MUDFLAP_OPTIONS=-viol-segv before
testing such that violations are promoted to SIGSEGV signals in testing.
Otherwise, the exit value would be 0 even the test has violations.
libmudflap testsuite depends on the exit value of tests to decide if the
test PASS or
Jie Zhang [EMAIL PROTECTED] writes:
@@ -261,7 +262,11 @@ proc rsh_exec { boardname program pargs inp outp } {
set inp /dev/null
}
-set ret [local_exec $RSH $rsh_useropts $hostname sh -c '$program $pargs
\\; echo XYZ\\\${?}ZYX' $inp $outp $timeout]
+set remote_envs
+
Hi Bingfeng,
Hello,
I tried to use doloop_end pattern to reduce loop overhead for our target
processor, which features a dedicated loop instruction. Somehow even a
simple loop just cannot pass the test of doloop_condition_get, which
requires following canonical pattern.
I checked this on
Snapshot gcc-4.2-20080716 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20080716/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.2 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Andreas Schwab wrote:
Jie Zhang [EMAIL PROTECTED] writes:
@@ -261,7 +262,11 @@ proc rsh_exec { boardname program pargs inp outp } {
set inp /dev/null
}
-set ret [local_exec $RSH $rsh_useropts $hostname sh -c '$program $pargs \\; echo XYZ\\\${?}ZYX' $inp $outp $timeout]
+
--- Comment #5 from irar at il dot ibm dot com 2008-07-16 06:19 ---
This seems to fix the problem:
Index: tree-chrec.c
===
--- tree-chrec.c(revision 137271)
+++ tree-chrec.c(working copy)
@@ -696,6 +696,8
I recently came across a subtle bug in my program that probably deserves a
warning from the compiler. It involves virtual functions in base/derived
classes where one is const and the other is not. The behavior under these
circumstances makes sense, but this situation should be easy to detect and
--- Comment #2 from andreasmeier80 at gmx dot de 2008-07-16 09:52 ---
For me it was working in revision 137687
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36830
--- Comment #9 from jsm28 at gcc dot gnu dot org 2008-07-16 10:46 ---
Subject: Bug 36827
Author: jsm28
Date: Wed Jul 16 10:45:57 2008
New Revision: 137875
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=137875
Log:
PR target/36827
* config/m32c/m32c.c (BIG_FB_ADJ):
--- Comment #10 from jsm28 at gcc dot gnu dot org 2008-07-16 10:47 ---
Subject: Bug 36827
Author: jsm28
Date: Wed Jul 16 10:46:32 2008
New Revision: 137876
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=137876
Log:
PR target/36827
* config/m32c/m32c.c
--- Comment #15 from aldot at gcc dot gnu dot org 2008-07-16 12:48 ---
Fixed on trunk, thanks!
Can we have the testcase in the testsuite and the fix applied to the
4_3-branch, too?
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
$ cat m.h -EOF
typedef long unsigned int size_t;
#define __THROW
/* Remap pages mapped by the range [ADDR,ADDR+OLD_LEN) to new length
NEW_LEN. If MREMAP_MAYMOVE is set in FLAGS the returned address
may differ from ADDR. If MREMAP_FIXED is set in FLAGS the function
takes another
--- Comment #1 from Joey dot ye at intel dot com 2008-07-16 13:14 ---
Fixed by revision 137859
--
Joey dot ye at intel dot com changed:
What|Removed |Added
--- Comment #6 from dodji at gcc dot gnu dot org 2008-07-16 13:39 ---
Created an attachment (id=15916)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15916action=view)
more work in the matter
This patch performs a more accurate lookup of the extern C functions to be able
to emit
--- Comment #3 from mmokrejs at ribosome dot natur dot cuni dot cz
2008-07-16 13:59 ---
This gave me a working bootstrapped compiler:
AS=/usr/ccs/bin/as LD=/usr/ccs/bin/ld NM=/usr/local/bin/nm
RANLIB=/usr/local/bin/ranlib STRIP=/usr/local/bin/strip BOOT_CFLAGS=-pipe
--- Comment #9 from cnstar9988 at gmail dot com 2008-07-16 14:24 ---
Target Milestone is 4.3.3?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36546
--- Comment #7 from cnstar9988 at gmail dot com 2008-07-16 14:24 ---
Target Milestone is 4.3.3?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36657
--- Comment #10 from aldot at gcc dot gnu dot org 2008-07-16 14:33 ---
Will be in the next 4.3.x release which will be 4.3.2, from the looks.
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from aldot at gcc dot gnu dot org 2008-07-16 14:35 ---
The target milestone does not matter in this case.
The fix will be in the next 4.3.x release which will be 4.3.2, from the looks.
--
aldot at gcc dot gnu dot org changed:
What|Removed
--- Comment #6 from dodji at gcc dot gnu dot org 2008-07-16 15:02 ---
Reproced on trunk. I'd like to look into this bug, if nobody is working on it
already.
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
http://gcc.gnu.org/onlinedocs/
only carries docs for 4.3.0 but not for the current 4.3.1-release.
Generating the onlinedocs is rumored to be the person's duty who rolled the
release (apparently jakub for 4.3.1).
--
Summary: missing onlinedocs for 4.3.1
Product: gcc
Bootstrapping mainline on Tru64 UNIX V5.1B fails as of 20080613:
libtool: compile: /vol/gccsrc/obj/gcc-4.4.0-20080613/5.1b-gcc/./gcc/xgcc
-shared-libgcc -B/vol/gccsrc/obj/gcc-4.4.0-20080613/5.1b-gcc/./gcc -nostdinc++
We have a class more or less like this: (please bear with me, this is only an
approximation.
class A
{
template class T static T determinant4(T matrix[4][4]);
template class T static T determinant3(T matrix[3][3]);
template class T static T determinant2(T matrix[2][2]);
};
template
--- Comment #1 from paolo dot carlini at oracle dot com 2008-07-16 16:37
---
We badly need a self-contained testcase (per our general guidelines) because
something trivial inspired by your PR, like the below compiles just fine.
template class T
T A::determinant3(T matrix[3][3])
{
Compiling gcc 4.3.1 on my machine fails with the following error message:
--
make profiledbootstrap
...
/tmp/bitti/gccobj/./prev-gcc/xgcc -B/tmp/bitti/gccobj/./prev-gcc/
-B/share/gcc/gcc-4.3.1/i686-pc-linux-gnu/bin/ -c -g -O2 -fomit-frame-pointer
-fprofile-generate
This is just a collector of optimizations that the
front end could do before generating tree codes.
--
Summary: [meta] fortran front-end optimization
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: meta-bug
Severity:
--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-07-16 18:43 ---
Created an attachment (id=15917)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15917action=view)
proposed patch
--
tkoenig at gcc dot gnu dot org changed:
What|Removed
__has_trivial_destructor() returns false for all reference types, but
should return true according to documentation. The documented behavior
is consistent with what is required by the c++0x draft.
Environment:
System: Linux cranium 2.6.18-8.el5xen #1 SMP Fri Jan 26 14:29:35 EST 2007
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-07-16 18:51 ---
(In reply to comment #1)
Created an attachment (id=15917)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15917action=view) [edit]
proposed patch
... which doesn't work in all cases. Still investigating.
--
The __is_pod() built-in returns false for pod class types that have base
classes, which is allowed by c++0x.
Environment:
System: Linux cranium 2.6.18-8.el5xen #1 SMP Fri Jan 26 14:29:35 EST 2007
x86_64 x86_64 x86_64 GNU/Linux
Architecture: x86_64
host: x86_64-unknown-linux-gnu
build:
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle
|dot org
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle
|dot org
--- Comment #2 from paolo dot carlini at oracle dot com 2008-07-16 19:00
---
Note, I'm going to suspend this, because, besides the traits builtins we are
not implementing anything in the front-end having to do with the new
characterization in C++0x of POD.
--
paolo dot carlini at
--- Comment #11 from dj at redhat dot com 2008-07-16 19:08 ---
Subject: Re: [4.3/4.4 Regression] newlib:libm/math/k_rem_pio2.c fails in
reload
Last night's builds showed a flaw in the patch. The ++rii address
created by m32c_legitimize_reload_address is *not* legitimate, it's
used
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-07-16 19:10 ---
derived_pod_t is still a non POD type according to the C++98/C++03 standard.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from sebor at roguewave dot com 2008-07-16 19:26 ---
We're using -std=gnu++0x, so we're expecting the implementation to follow
C++ 0x rules.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36856
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-07-16 19:30 ---
(In reply to comment #4)
We're using -std=gnu++0x, so we're expecting the implementation to follow
C++ 0x rules.
Except the ABI says something different from C++0x ...
--
--- Comment #6 from paolo dot carlini at oracle dot com 2008-07-16 19:30
---
Of course, but really doesn't make sense trying now implementing that, simply
there is no infrastructure in the front-end for C++0x POD-ness, sorry.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36856
GFortran float printing breaks when a non-English locale is selected. Instead,
Internal error: printf is broken appears. The failing part is a sanity check
in libgfortran, where it was forgotten that in some non-English locales,
sprintf will format floats using a comma instead of a period as the
--- Comment #12 from joseph at codesourcery dot com 2008-07-16 20:25
---
Subject: Re: [4.3/4.4 Regression] newlib:libm/math/k_rem_pio2.c
fails in reload
On Wed, 16 Jul 2008, dj at redhat dot com wrote:
Last night's builds showed a flaw in the patch. The ++rii address
created by
--- Comment #2 from burnus at gcc dot gnu dot org 2008-07-16 20:36 ---
Jerry, you know libgfortran better than me. Can one simply change in
libgfortran.h:
#define GFC_DTYPE_RANK_MASK 0x07
to 0x0F (= 15) or does this cause some problems with the gcc 4.3
compatibility or ... ?
--- Comment #1 from burnus at gcc dot gnu dot org 2008-07-16 20:45 ---
program main
CALL badlocale()
WRITE(*,'(G2.4)') 1.2345
end program main
If the code executed correctly, the expected output would be
1,235
No, the expected output would be 1.235 according to the
locate_and_pad_parm has
where_pad = FUNCTION_ARG_PADDING (passed_mode, type);
boundary = FUNCTION_ARG_BOUNDARY (passed_mode, type);
locate-where_pad = where_pad;
locate-boundary = boundary;
/* Remember if the outgoing parameter requires extra alignment on the
calling function
--- Comment #3 from tkoenig at gcc dot gnu dot org 2008-07-16 21:24 ---
Created an attachment (id=15918)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15918action=view)
better patch
This one actually works for eoshift and passes
all zero* and *shift* tests in gfortran.dg.
--
locate_and_pad_parm never align parameters on stack for
callers. It only caps parameter alignment to
PREFERRED_STACK_BOUNDARY. But std_gimplify_va_arg_expr
tries to align stack for callee:
/* va_list pointer is aligned to PARM_BOUNDARY. If argument actually
requires greater alignment,
--- Comment #3 from hubicka at gcc dot gnu dot org 2008-07-16 23:14 ---
Fix comitted.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from dodji at gcc dot gnu dot org 2008-07-16 23:44 ---
Subject: Bug 13699
Author: dodji
Date: Wed Jul 16 23:44:02 2008
New Revision: 137904
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=137904
Log:
2008-07-16 Dodji Seketeli [EMAIL PROTECTED]
PR
--- Comment #8 from dodji at gcc dot gnu dot org 2008-07-16 23:52 ---
fixed in trunk.
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
I have a subroutine that is heavily used by a program I frequently run called
UKKA_Dist_With_Max. I had benchmarked it using mandriva linux 2005LE. When I
ran it using mandriva 2008.1, it ran much slower. Using the compiler from
mandriva linux 2005LE (gcc-3.4.3) and mandriva 2008.1, I was able to
--- Comment #1 from jeff at jeffunit dot com 2008-07-17 01:57 ---
Created an attachment (id=15919)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15919action=view)
this is the preprocessed subroutine that is poorly optimized
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36860
--- Comment #2 from jeff at jeffunit dot com 2008-07-17 01:59 ---
In order to run the entire program, you will need a fair amount of code.
All needed code can be found at the above URL, along with test data.
--
jeff at jeffunit dot com changed:
What|Removed
--- Comment #3 from jeff at jeffunit dot com 2008-07-17 02:07 ---
Created an attachment (id=15920)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15920action=view)
Here is the subroutine, run throuh the preprocessor using gcc-3.4.3
--
--- Comment #13 from kkojima at gcc dot gnu dot org 2008-07-17 02:08
---
Try changing the reloaded != 1 condition in find_reloads_subreg_address
to reloaded == 0 (as a replacement for my m32c patch, and probably for
the SH patch as well). I hope that should avoid these problems
--- Comment #28 from hjl at gcc dot gnu dot org 2008-07-17 05:14 ---
Subject: Bug 36443
Author: hjl
Date: Thu Jul 17 05:13:27 2008
New Revision: 137909
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=137909
Log:
2008-07-17 H.J. Lu [EMAIL PROTECTED]
PR testsuite/36443
--- Comment #1 from hjl dot tools at gmail dot com 2008-07-17 05:19 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2008-07/msg01241.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #1 from hjl dot tools at gmail dot com 2008-07-17 05:25 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2008-07/msg01247.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #3 from burnus at gcc dot gnu dot org 2008-07-17 05:55 ---
Subject: Bug 36825
Author: burnus
Date: Thu Jul 17 05:54:42 2008
New Revision: 137910
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=137910
Log:
2008-07-17 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #2 from burnus at gcc dot gnu dot org 2008-07-17 05:55 ---
Subject: Bug 36824
Author: burnus
Date: Thu Jul 17 05:54:42 2008
New Revision: 137910
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=137910
Log:
2008-07-17 Tobias Burnus [EMAIL PROTECTED]
PR
69 matches
Mail list logo
