[EMAIL PROTECTED] wrote:
Plugins features. This addresses Richard Stallman's concerns, so he
no
longer objects to a Plugins feature.
That is GREAT news!!!
I add my enthusiasm to the one of Brendon, this is really a great news !
Please, keep us informed of the progress of the plugins !
I got negative feedback on that patch (no, not regression
results :) on IRC from David Edelsohn and understandably you
held off your testing because of this, as for one the patch
affects the rs6000 backend.
What kind of negative feedback?
For CRIS (as well as other targets IIUC) the cause
Date: Fri, 05 Sep 2008 12:55:17 +0200
From: Paolo Bonzini [EMAIL PROTECTED]
I got negative feedback on that patch (no, not regression
results :) on IRC from David Edelsohn and understandably you
held off your testing because of this, as for one the patch
affects the rs6000 backend.
On Fri, Sep 5, 2008 at 7:25 AM, Hans-Peter Nilsson
[EMAIL PROTECTED] wrote:
Date: Fri, 05 Sep 2008 12:55:17 +0200
From: Paolo Bonzini [EMAIL PROTECTED]
Nope, not if it's a (MINUS (symbol_ref sym2) (symbol_ref sym1)).
*If* valid, that's a constant expression and *should* be wrapped
in a
3) adding a check that the MINUS is a legitimate address, and only wrap
it in CONST if it is.
s/address/constant/; it's not clear that it's used as an address
at that point; it's just two expressions that gcc tries to
reduce.
Right.
But I get the point; I'm leaning towards something
Date: Fri, 05 Sep 2008 14:42:11 +0200
From: Paolo Bonzini [EMAIL PROTECTED]
We can do it incrementally. For now, only redefine
LEGITIMATE_CONSTANT_P on CRIS and in the documentation, and use it in
simplify_plus_minus. For 4.5, we can look at other places using
gen_rtx_CONST and strengthen
Date: Fri, 5 Sep 2008 14:57:00 +0200
From: Hans-Peter Nilsson [EMAIL PROTECTED]
Maybe as part of a change from target macro to target hook, with
LEGITIMATE_CONSTANT_P as a default would fit, even at this
stage?
Sorry, I mean CONSTANT_P, not LEGITIMATE_CONSTANT_P. Or maybe a
new macro or
Hi Vladimir,
I was just going through some benchmarks on PPC and noticed that your
patch from 08/26 (http://gcc.gnu.org/ml/gcc-cvs/2008-08/msg01152.html)
caused a significant regression on both facerec (~17%) and applu (~4%)
for 64-bit PPC.
There are other degradations that i'm still working on
On Fri, Sep 5, 2008 at 6:59 AM, Luis Machado [EMAIL PROTECTED] wrote:
Hi Vladimir,
I was just going through some benchmarks on PPC and noticed that your
patch from 08/26 (http://gcc.gnu.org/ml/gcc-cvs/2008-08/msg01152.html)
caused a significant regression on both facerec (~17%) and applu
Adam Nemet wrote:
haifa-sched.c:
2302/* Let the target filter the search space. */
2303for (i = 1; i ready-n_ready; i++)
2304 if (!ready_try[i])
2305{
2306 insn = ready_element (ready, i);
2307
2308 gcc_assert
On Fri, 2008-09-05 at 07:16 -0700, H.J. Lu wrote:
On Fri, Sep 5, 2008 at 6:59 AM, Luis Machado [EMAIL PROTECTED] wrote:
Hi Vladimir,
I was just going through some benchmarks on PPC and noticed that your
patch from 08/26 (http://gcc.gnu.org/ml/gcc-cvs/2008-08/msg01152.html)
caused a
David Edelsohn wrote:
On Thu, Sep 4, 2008 at 7:39 PM, Vladimir Makarov [EMAIL PROTECTED] wrote:
Meanwhile I am going to submit your second patch with an added
comment. The patch permits gcc to generate the same quality code as
before your first patch.
Why?
As Richard said before:
Luis Machado wrote:
Hi Vladimir,
I was just going through some benchmarks on PPC and noticed that your
patch from 08/26 (http://gcc.gnu.org/ml/gcc-cvs/2008-08/msg01152.html)
caused a significant regression on both facerec (~17%) and applu (~4%)
for 64-bit PPC.
There are other degradations that
Hi.
My build attempts on sparc-sun-solaris2.10 haven't been working well
since the IRA merge, but given the scope of that change and the fixes
applied since the merge I'm certain the build will be in good shape
soon.
This morning's build attempt failed while compiling libgcc:
On Fri, 2008-09-05 at 09:03 -0700, H.J. Lu wrote:
On Fri, Sep 5, 2008 at 8:01 AM, Luis Machado [EMAIL PROTECTED] wrote:
On Fri, 2008-09-05 at 07:16 -0700, H.J. Lu wrote:
On Fri, Sep 5, 2008 at 6:59 AM, Luis Machado [EMAIL PROTECTED] wrote:
Hi Vladimir,
I was just going through some
2008/9/5 Christopher Faylor [EMAIL PROTECTED]:
On Sun, Aug 17, 2008 at 03:01:03PM -0500, John Freeman wrote:
Daniel Berlin wrote:
It's listed on the wiki that explains how to maintain branches :)
I had no idea such a wiki even existed. It would really help future
contributors, I'm sure,
On Fri, 2008-09-05 at 12:36 -0400, Vladimir Makarov wrote:
Luis Machado wrote:
Hi Vladimir,
I was just going through some benchmarks on PPC and noticed that your
patch from 08/26 (http://gcc.gnu.org/ml/gcc-cvs/2008-08/msg01152.html)
caused a significant regression on both facerec (~17%)
On Fri, Sep 5, 2008 at 8:01 AM, Luis Machado [EMAIL PROTECTED] wrote:
On Fri, 2008-09-05 at 07:16 -0700, H.J. Lu wrote:
On Fri, Sep 5, 2008 at 6:59 AM, Luis Machado [EMAIL PROTECTED] wrote:
Hi Vladimir,
I was just going through some benchmarks on PPC and noticed that your
patch from
Luis Machado wrote:
This is a Power6 4.7Ghz (altivec supported)
Great. Now I have an access to power6. So I am going to try it too.
What options (especially march or mtune) you are using? IRA is very
sensitive to correct times of ld/st/moves in machine description.
I'm
On Fri, Sep 5, 2008 at 10:24 AM, Vladimir Makarov [EMAIL PROTECTED] wrote:
H.J. Lu keeps ira-branch merge more fresh than trunk. But the lag is only
I won't apply any non-IRA related patches to ira-merge branch so
that you can get a fair comparison for IRA without regressions
introduced by
Art Haas [EMAIL PROTECTED] writes:
My build attempts on sparc-sun-solaris2.10 haven't been working well
since the IRA merge, but given the scope of that change and the fixes
applied since the merge I'm certain the build will be in good shape
soon.
This morning's build attempt failed while
Hi Doug, Jason suggested that I write to you about this. There seems
to be some confusion in the code in cp/pt.c between enum
unification_kind_t (DEDUCE_xxx) and a bitmask of UNIFY_ALLOW_xxx
values. The parameters are named strict for all functions, but in
some cases they are unification_kind_t
Christopher Faylor wrote:
On Sun, Aug 17, 2008 at 03:01:03PM -0500, John Freeman wrote:
Daniel Berlin wrote:
It's listed on the wiki that explains how to maintain branches :)
I had no idea such a wiki even existed. It would really help future
contributors, I'm sure, if,
Rainer Orth wrote:
Looks like a code generation bug to me. I'll try to start a reghunt asap.
Start around the 25/26th of August. IRA.
Since then it is borked.
Andreas
Maxim Kuvyrkov writes:
Yes, the assert is really checking exactly that. Several pieces of
haifa-sched.c assume that the instruction has been recognized during
scheduler initialization to speed up checking if instruction is normal
or some kind of use/clobber/asm.
Thanks for the info but I
I'll commit your patch.
On Fri, Sep 5, 2008 at 12:42 PM, Manuel López-Ibáñez
[EMAIL PROTECTED] wrote:
2008/9/5 Christopher Faylor [EMAIL PROTECTED]:
On Sun, Aug 17, 2008 at 03:01:03PM -0500, John Freeman wrote:
Daniel Berlin wrote:
It's listed on the wiki that explains how to maintain
H.J. Lu wrote:
On Fri, Sep 5, 2008 at 12:15 PM, Andreas Tobler [EMAIL PROTECTED] wrote:
Rainer Orth wrote:
Looks like a code generation bug to me. I'll try to start a reghunt asap.
Start around the 25/26th of August. IRA.
Since then it is borked.
Can you try ira-merge branch? It has all
On Fri, Sep 5, 2008 at 12:36 PM, Andreas Tobler [EMAIL PROTECTED] wrote:
H.J. Lu wrote:
On Fri, Sep 5, 2008 at 12:15 PM, Andreas Tobler [EMAIL PROTECTED]
wrote:
Rainer Orth wrote:
Looks like a code generation bug to me. I'll try to start a reghunt
asap.
Start around the 25/26th of
H.J. Lu wrote:
Can you try ira-merge branch? It has all IRA bug fixes without non-IRA
changes.
How is it named? ira-merge? If, I can't find it on
http://gcc.gnu.org/svn.html.
It is a temporary branch, branches/ira-merge, to track
IRA related problems.
Thanks, co right now.
Andreas
Adam Nemet wrote:
Maxim Kuvyrkov writes:
Yes, the assert is really checking exactly that. Several pieces of
haifa-sched.c assume that the instruction has been recognized during
scheduler initialization to speed up checking if instruction is normal
or some kind of use/clobber/asm.
Thanks
Maxim Kuvyrkov writes:
I'm not 100% sure about current state of things, considering recent
merge of sel-sched, but before that it was:
set_priorities() - priority() - dep_cost() - recog_memoized().
I don't think that was the case for all insns even before the patch. The only
new thing is
H.J. Lu wrote:
On Fri, Sep 5, 2008 at 12:36 PM, Andreas Tobler [EMAIL PROTECTED] wrote:
H.J. Lu wrote:
On Fri, Sep 5, 2008 at 12:15 PM, Andreas Tobler [EMAIL PROTECTED]
wrote:
Rainer Orth wrote:
Looks like a code generation bug to me. I'll try to start a reghunt
asap.
Start around the
On Fri, Sep 5, 2008 at 2:43 PM, Andreas Tobler [EMAIL PROTECTED] wrote:
H.J. Lu wrote:
On Fri, Sep 5, 2008 at 12:36 PM, Andreas Tobler [EMAIL PROTECTED]
wrote:
H.J. Lu wrote:
On Fri, Sep 5, 2008 at 12:15 PM, Andreas Tobler
[EMAIL PROTECTED]
wrote:
Rainer Orth wrote:
Looks like a code
H.J. Lu wrote:
It is a temporary branch, branches/ira-merge, to track
IRA related problems.
Same issue.
Does trunk bootstrap with revision 139589?
No, gcc version 4.4.0 20080905 (experimental) [trunk revision 140042] (GCC)
Andreas
On Fri, Sep 5, 2008 at 2:57 PM, Andreas Tobler [EMAIL PROTECTED] wrote:
H.J. Lu wrote:
It is a temporary branch, branches/ira-merge, to track
IRA related problems.
Same issue.
Does trunk bootstrap with revision 139589?
No, gcc version 4.4.0 20080905 (experimental) [trunk revision 140042
Snapshot gcc-4.4-20080905 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20080905/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
On Fri, Sep 05, 2008 at 01:34:08PM -0500, John Freeman wrote:
Christopher Faylor wrote:
On Sun, Aug 17, 2008 at 03:01:03PM -0500, John Freeman wrote:
Daniel Berlin wrote:
It's listed on the wiki that explains how to maintain branches :)
I had no idea such a wiki even
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2008-09-05 06:24
---
I tried revision 140023 on RHEL4U6. I can bootstrap
with --enable-languages=c i586-linux.
Which branch? I still get the failure on mainline at revision 140025.
--
I get the following ICE with trunk from 20080903 (revision 127646). This
doesn't happen with 4.4.0 20080802
(sid)[EMAIL PROTECTED]:~$ /usr/lib/gcc-snapshot/bin/gcc -O2 -c wmtv-wmtv.c
wmtv-wmtv.c: In function 'DoFullScreen':
wmtv-wmtv.c:97: internal compiler error: in ia64_speculate_insn, at
--- Comment #1 from tbm at cyrius dot com 2008-09-05 08:04 ---
Created an attachment (id=16228)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16228action=view)
Preprocessed code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37381
--- Comment #2 from tbm at cyrius dot com 2008-09-05 08:04 ---
Created an attachment (id=16229)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16229action=view)
Slightly reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37381
With current trunk (20080905, revision 127646):
(sid)973:[EMAIL PROTECTED]: ..4.3-2008-09-05-r140029/gcc] ./cc1 -quiet -O3
~/hamlib-hamlibtcl_wrap.i
hamlibtcl_wrap.c: In function 'T.4796':
hamlibtcl_wrap.c:1186: error: unrecognizable insn:
(insn 146 18 20 2 hamlibtcl_wrap.c:604 (set (reg:HI 141
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||abel at ispras dot ru
Target Milestone|---
--- Comment #1 from tbm at cyrius dot com 2008-09-05 09:06 ---
Created an attachment (id=16230)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16230action=view)
Preprocessed code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37382
--- Comment #2 from tbm at gcc dot gnu dot org 2008-09-05 09:11 ---
Confirmed.
--
tbm at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #11 from abel at ispras dot ru 2008-09-05 09:16 ---
I was unable to trigger the assert on the given testcase even with the
cross-compiler configured exactly like the one in the bug report. However, I
was able to reproduce the ICE on a longer plain C test case.
The assert
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-09-05 09:34 ---
Reducing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37382
--- Comment #12 from rguenth at gcc dot gnu dot org 2008-09-05 09:37
---
I think it's reasonable to disable the assert with a comment for now and
file a separate bugreport for the targets who lie about their issue rate.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37360
--- Comment #5 from jwakely dot gcc at gmail dot com 2008-09-05 10:23
---
this seems pretty easy to fix with decltype and variadic templates, patch
coming soon ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37351
--- Comment #6 from paolo dot carlini at oracle dot com 2008-09-05 10:29
---
Great. I'm assigning it to yourself, then.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #13 from abel at ispras dot ru 2008-09-05 10:32 ---
(In reply to comment #12)
I think it's reasonable to disable the assert with a comment for now and
file a separate bugreport for the targets who lie about their issue rate.
Ok, with the below patch my failing test case
--- Comment #14 from abel at ispras dot ru 2008-09-05 10:33 ---
Created an attachment (id=16231)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16231action=view)
Proposed patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37360
--- Comment #7 from domob at gcc dot gnu dot org 2008-09-05 11:57 ---
Subject: Bug 36746
Author: domob
Date: Fri Sep 5 11:56:23 2008
New Revision: 140034
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140034
Log:
2008-09-05 Daniel Kraft [EMAIL PROTECTED]
PR
--- Comment #8 from domob at gcc dot gnu dot org 2008-09-05 11:58 ---
Fixed on trunk.
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from jh at suse dot cz 2008-09-05 12:39 ---
Subject: Re: [4.4 Regression] Divide_X
All failures have
-2147483648
-2147483648
0
0
0
java.lang.ArithmeticException: / by zero
java.lang.ArithmeticException: / by zero
I've caused bug in expand_divmod that
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org
|dot org
--- Comment #6 from fabien dot chene at gmail dot com 2008-09-05 13:22
---
There is a patch here:
http://gcc.gnu.org/ml/gcc-patches/2008-09/msg00474.html
--
fabien dot chene at gmail dot com changed:
What|Removed |Added
--- Comment #7 from hjl dot tools at gmail dot com 2008-09-05 13:46 ---
(In reply to comment #6)
I tried revision 140023 on RHEL4U6. I can bootstrap
with --enable-languages=c i586-linux.
Which branch? I still get the failure on mainline at revision 140025.
See
Compiler crashed with these lines
g++ main.cpp expenditure_category.h expenditure_category.cpp -O4
expenditure_category.h: In member function bool
expenditure::category_compare::operator()(const expenditure::category, const
expenditure::category) const:
expenditure_category.h:33: error:
--- Comment #1 from dckorah at gmail dot com 2008-09-05 13:49 ---
Created an attachment (id=16232)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16232action=view)
the temporary file /tmp/ccZFb4sl.out
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37383
--- Comment #2 from dckorah at gmail dot com 2008-09-05 13:50 ---
Here is the output without the optimization options
g++ main.cpp expenditure_category.h expenditure_category.cpp
expenditure_category.h: In member function bool
expenditure::category_compare::operator()(const
--- Comment #7 from hjl dot tools at gmail dot com 2008-09-05 13:51 ---
(In reply to comment #6)
Subject: Re: [4.4 Regression] Divide_X
All failures have
-2147483648
-2147483648
0
0
0
java.lang.ArithmeticException: / by zero
java.lang.ArithmeticException: / by
--- Comment #3 from paolo dot carlini at oracle dot com 2008-09-05 14:00
---
Target? x86_64-linux?
I can't reproduce the problem on FSF 4.1.3, neither with 4.2.5, 4.3.2 or
mainline. I suspect it's a Debian modification at fault, not to be reported
here...
PS: -OX, with X = 3 are all
--- Comment #4 from paolo dot carlini at oracle dot com 2008-09-05 14:02
---
Figured out from the attachment...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
When building version 0.9.0 or 0.9.1 of the videolan client application with
gcc-4.3.2 or the 20080904 snapshot of version 4.3 I get the following error:
gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I../include -I../include -DSYS_LINUX
-D_FILE_OFFSET_BITS=64 -D__USE_UNIX98 -D_LARGEFILE64_SOURCE
--- Comment #1 from chris2553 at googlemail dot com 2008-09-05 14:54
---
Created an attachment (id=16233)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16233action=view)
Preprocessed file that triggers the problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37384
--- Comment #1 from tbm at cyrius dot com 2008-09-05 15:50 ---
Created an attachment (id=16234)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16234action=view)
Preprocessed code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37385
With current trunk (r140029):
(sid)985:[EMAIL PROTECTED]: ..4.3-2008-09-05-r140029/gcc] ./cc1 -quiet -O3
~/libsdl-erlang-esdl_wrapper.i
esdl_wrapper.c: In function 'init_fps':
esdl_wrapper.c:77: internal compiler error: in set_mem_alias_set, at
emit-rtl.c:1789
Please submit a full bug report,
--- Comment #1 from manu at gcc dot gnu dot org 2008-09-05 15:45 ---
This may be the same issue (or one of the two issues) of PR 36296. Although I
would need to check the dumps before and after VRP.
Wuninitialized got some fixes in GCC 4.4, so we also need to test whether this
has
--- Comment #1 from spop at gcc dot gnu dot org 2008-09-05 16:19 ---
(In reply to comment #0)
During SCoP detection we split bbs (e.g. in scopdet_edge_info), but the SCoP
detection should only detect SCoPs and not modify anything.
No, we want to split BBs to increase the scop
--- Comment #2 from tbm at cyrius dot com 2008-09-05 16:26 ---
/* Testcase by Martin Michlmayr [EMAIL PROTECTED] */
typedef struct sdl_data_def
{
}
sdl_data;
typedef void (*sdl_fun) (struct sdl_data_def *);
void undefined_function (sdl_data * sd)
{
}
void init_fps (sdl_fun *fun_tab)
{
--- Comment #7 from dgregor at gcc dot gnu dot org 2008-09-05 17:05 ---
Subject: Bug 37342
Author: dgregor
Date: Fri Sep 5 17:04:12 2008
New Revision: 140037
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140037
Log:
2008-09-05 Douglas Gregor [EMAIL PROTECTED]
PR
--- Comment #8 from dgregor at gcc dot gnu dot org 2008-09-05 17:06 ---
Fixed on mainline
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from janis at gcc dot gnu dot org 2008-09-05 17:15 ---
Subject: Bug 37283
Author: janis
Date: Fri Sep 5 17:13:52 2008
New Revision: 140040
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140040
Log:
PR target/37283
* opts.c (decode_options): Handle
Trying to compile this code:
#define U0THR (*((volatile unsigned char *) 0xE000C000))
template typename T, unsigned int len
class Queue
{
public:
/**
Constructor, create a new queue.
*/
Queue()
{
put_pos=get_pos=num_elem=0;
--- Comment #15 from daney at gcc dot gnu dot org 2008-09-05 18:29 ---
Thanks for the patch.
With the patch applied to the trunk my bootstrap has made it into stage 2,
indicating that it has corrected the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37360
--- Comment #1 from fede dot tft at hotmail dot it 2008-09-05 18:40 ---
After searching the bug database, it looks like this bug is similar to bug
#27859 and bug #16634, but in this case occurs only with -Os
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37386
--- Comment #2 from hjl dot tools at gmail dot com 2008-09-05 19:43 ---
This regression was introduced between revisions 139822 and 139853.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37384
--- Comment #3 from hjl dot tools at gmail dot com 2008-09-05 19:44 ---
(In reply to comment #2)
This regression was introduced between revisions 139822 and 139853.
Ooops. Please ignore this comments.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37384
--- Comment #8 from hjl dot tools at gmail dot com 2008-09-05 19:44 ---
his regression was introduced between revisions 139822 and 139853.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37378
With current trunk (r140043) on powerpc (but not on x86_64):
(sid)2492:[EMAIL PROTECTED]: ..4.3-2008-09-05-r140043/gcc] ./cc1 -quiet -O2
~/gap-costab.i
../../src/costab.c: In function 'FuncStandardizeTable2C':
../../src/costab.c:2780: internal compiler error: in
extract_range_from_binary_expr, at
--- Comment #1 from tbm at cyrius dot com 2008-09-05 20:07 ---
Created an attachment (id=16235)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16235action=view)
Preprocessed code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37387
--- Comment #2 from tbm at cyrius dot com 2008-09-05 20:25 ---
/* Testcase by Martin Michlmayr [EMAIL PROTECTED] */
typedef long int Int;
typedef Int **Bag;
FuncMakeConsequencesPres (Bag self, Bag list)
{
Bag objDefs1;
Bag objDefs2;
if (! ( (((Int) 0) + 13) =
(((Int)
--- Comment #1 from g0dsowncountry at yahoo dot com 2008-09-05 20:46
---
Noticed that if GCC is configured with additional parameters
'--with-arch=5kc --with-tune=5kc', PASS 1 build completes (gcc version 4.4.0
20080904 (experimental)).
mipsisa64-linux-* builds fine w/o these extra
--- Comment #2 from domob at gcc dot gnu dot org 2008-09-05 20:53 ---
Subject: Bug 35837
Author: domob
Date: Fri Sep 5 20:51:50 2008
New Revision: 140046
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140046
Log:
2008-09-05 Daniel Kraft [EMAIL PROTECTED]
PR
--- Comment #3 from domob at gcc dot gnu dot org 2008-09-05 20:55 ---
Fixed for trunk.
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
GCC does not fail at -O0 when -fgraphite is used and support for
graphite is not built in the compiler.
--
Summary: [graphite] No warn with -O0 -fgraphite when cloog or
ppl are not present
Product: gcc
Version: 4.4.0
Status:
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #1 from spop at gcc dot gnu dot org 2008-09-05 21:22 ---
Created an attachment (id=16236)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16236action=view)
fix
This patch fixes the bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37388
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-09-05 21:25 ---
Confirmed, on PowerPC, you need -maltivec.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from hjl dot tools at gmail dot com 2008-09-05 21:43 ---
Revision 139832 is bad.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37378
seen with 4.2.4, 4.3.2 and trunk 20080904
g++ -c -mtune=generic -g foo.ii
In file included from utNativePackedCoDec.cc:5:
../../src/pers/RecBuf.hh: At global scope:
../../src/pers/RecBuf.hh: In instantiation of
'pers::RecBufpers::NativePackedCoDec, long unsigned int':
utNativePackedCoDec.cc:11:
--- Comment #1 from doko at ubuntu dot com 2008-09-05 22:29 ---
Created an attachment (id=16237)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16237action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37389
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-09-05 22:37 ---
Confirmed reduced testcase:
enum { OFFSET_MAX = (9223372036854775807L * 2UL + 1UL) };
enum {
OFFSET_MAX = OFFSET_MAX,
STRING_SZ = CoDec::Type::FIXED_SIZE,
STRING_DYN = CoDec::Type::DYN_PARTS,
--
pinskia at
this is the example from
http://gcc.gnu.org/ml/gcc/2008-08/msg00376.html
seen with 4.2.4 and 4.3.2
[EMAIL PROTECTED]:/home/junk/prog/tju# gcc bug_short.c -lm -O2
[EMAIL PROTECTED]:/home/junk/prog/tju# ./a.out
2383,1
31727,1
132265613,1
3145439247023686464
[EMAIL PROTECTED]:/home/junk/prog/tju#
--- Comment #1 from doko at ubuntu dot com 2008-09-05 22:43 ---
Created an attachment (id=16238)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16238action=view)
example
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37390
--- Comment #1 from spop at gcc dot gnu dot org 2008-09-05 22:45 ---
Created an attachment (id=16239)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16239action=view)
fix
the attached patch fixes PR37375 by changing instantiate_scev to take
a basic block above which all the
--- Comment #10 from hjl dot tools at gmail dot com 2008-09-05 22:53
---
Revision 139827 is bad.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37378
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-09-05 22:54 ---
I think this is really PR 323. Using -ffloat-store gives the correct answer.
D.2639 = pow ((double) a, (double) b + 1.0e+0);
num = (ull) D.2639 - 1.0e+0;
So I don't know what else to say, except -ffloat-store
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-09-05 22:56 ---
Most likely fixed for 4.4 with
http://gcc.gnu.org/ml/gcc-patches/2008-08/msg01461.html.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37329
1 - 100 of 114 matches
Mail list logo
