In a private port I had the problem that reg_equiv_alt_mem_list did
contain the
same RTL as reg_equiv_memory_loc. This caused an assert in
delete_output_reload,
where these are compared with equal_rtx_p.
The list is build with push_reg_equiv_alt_mem, but only when tem !=
orig. The
value tem is
On 3/12/07, Unruh, Erwin [EMAIL PROTECTED] wrote:
In a private port I had the problem that reg_equiv_alt_mem_list did
contain the
same RTL as reg_equiv_memory_loc. This caused an assert in
delete_output_reload,
where these are compared with equal_rtx_p.
The list is build with
It would seem we need to change...
Index: gcc/config/darwin.c
===
/usr/local/bin/gccdiff: line 1: i#!/bin/bash: No such file or directory
--- gcc/config/darwin.c (revision 122839)
+++ gcc/config/darwin.c (working copy)
@@ -1112,7
Hi all,
i have a very little question for you. I have a basic block and by a
statement iterator i can obtain a tree structure in the following
manner:
tree stmt = bsi_stmt (si);
I want to use this tree structure to manipulate the statement, for
example i 'd like to know if
On 3/12/07, Unruh, Erwin [EMAIL PROTECTED] wrote:
In a private port I had the problem that reg_equiv_alt_mem_list did
contain the same RTL as reg_equiv_memory_loc. This caused an assert
in
delete_output_reload, where these are compared with equal_rtx_p.
The list is build with
[EMAIL PROTECTED] wrote on 12/03/2007 16:56:53:
Hi all,
i have a very little question for you. I have a basic block and by a
statement iterator i can obtain a tree structure in the following
manner:
tree stmt = bsi_stmt (si);
I want to use this tree structure to manipulate the
Andrea Callia D'Iddio wrote on 12/03/2007 16:56:53:
Hi all,
i have a very little question for you. I have a basic block and by a
statement iterator i can obtain a tree structure in the following
manner:
tree stmt = bsi_stmt (si);
I want to use this tree structure to manipulate the
Hi,
gcc currently doesn't boostrap on s390 and s390x:
/build2/gcc-4.3-build/s390x-ibm-linux-gnu/libstdc++-v3/include/bits/locale_facets.tcc:2025:
internal compiler error: in cse_find_path, at cse.c:5930
Please submit a full bug report,
with preprocessed source if appropriate.
See
On 3/12/07, Andreas Krebbel [EMAIL PROTECTED] wrote:
Hi,
gcc currently doesn't boostrap on s390 and s390x:
See http://gcc.gnu.org/ml/gcc-bugs/2007-03/msg00930.html
Gr.
Steven
On Mon, Mar 12, 2007 at 08:32:43AM -0400, Jack Howarth wrote:
- else if (decl_readonly_section_1 (exp, reloc, MACHOPIC_INDIRECT))
+ else if (decl_readonly_section (exp, reloc))
Not just that. Try this.
* config/darwin.c (machopic_reloc_rw_mask): New.
On 3/3/07, Grigory Zagorodnev [EMAIL PROTECTED] wrote:
Hi,
Trunk GCC shows massive (2 compile-time and 6 run-time) failures on SPEC
CPU2000 and CPU2006 at i386 and x86_64 on -O2 optimization level.
Regression introduced somewhere between revision 122487 and 122478.
There are three checkins,
Great! thank you! I tested with your code and it works... but I'm
still a bit confused.
Could you help me with this simple example?
Suppose that I obtained a tree structure with the following command:
tree stmt = bsi_stmt (si);
and suppose I want to execute the following task:
For each tree
On Mon, Mar 12, 2007 at 05:27:21PM +0100, Richard Guenther wrote:
Most of the problems are fixed, dealII remains with:
/gcc/spec/sb-balakirew-head-64-2006/x86_64/install-hack/bin/g++ -c -o
quadrature.o -DSPEC_CPU -DNDEBUG -Iinclude -DBOOST_DISABLE_THREADS
-Ddeal_II_dimension=3 -O2
Ross Ridge wrote:
Any library that needs to be able to be called from VisualBasic 6 or some
other stdcall only environment should explictly declare it's exported
functions with the stdcall calling convention.
Tobias Burnus writes:
Thus, if I understood you correctly, you recommend that we
On 3/12/07, Andrea Callia D'Iddio [EMAIL PROTECTED] wrote:
Great! thank you! I tested with your code and it works... but I'm
still a bit confused.
Could you help me with this simple example?
Suppose that I obtained a tree structure with the following command:
tree stmt = bsi_stmt (si);
and
[This is a re-send of my previous e-mail; my apologies, yet again, for
the e-mail mangling on my end. Those responsible have been sacked.]
With the introduction of the variadic templates patch, we now have
more than 255 tree codes in GCC. This causes the mainline
Objective-C++ compiler to fail
Doug Gregor [EMAIL PROTECTED] writes:
Am I the only one to receive Doug's recent messages with empty body?
-- Gaby
I thought that the Tuples conversion was suppose to address this
in the long term.
David
Here are some GCC 4.2.0 P1s which I think it would be good for GCC to
have resolved before the release, together with names of people I'd like
to volunteer to help. (Naturally, I have no command authority, and I'd
encourage anyone else who wants to help to pitch in, but I'm trying to
tap a few
On 3/12/07, Mark Mitchell [EMAIL PROTECTED] wrote:
* PR 30132 (Pinski, Berlin) -- This is an aliasing crash on complex
numbers. Andrew, you mentioned you might have a patch.
Yes I have a patch but I need to go back and look at the sources
again, I can get to this bug tomorrow as the sources
On 3/12/07, Mark Mitchell [EMAIL PROTECTED] wrote:
Here are some GCC 4.2.0 P1s which I think it would be good for GCC to
have resolved before the release, together with names of people I'd like
to volunteer to help. (Naturally, I have no command authority, and I'd
encourage anyone else who
Mark Mitchell wrote:
* PR 28544 (Brook, Weigand) -- this is an ARM ICE which Paul has tracked
to reload, but he's not sure what to do there. Perhaps Ulrich can help.
This description doesn't appear to match the bugzilla record. Maybe you're
referring to PR 28675? I can have a look at that
On 3/12/07, David Edelsohn [EMAIL PROTECTED] wrote:
I thought that the Tuples conversion was suppose to address this
in the long term.
The tuples conversion is only going to make things worse in the short term.
Doug, isn't there a lang_tree bit you can make available, and use it
to
Ulrich Weigand wrote:
Mark Mitchell wrote:
* PR 28544 (Brook, Weigand) -- this is an ARM ICE which Paul has tracked
to reload, but he's not sure what to do there. Perhaps Ulrich can help.
This description doesn't appear to match the bugzilla record. Maybe you're
referring to PR 28675?
Dave Korn wrote:
Was this description perhaps written in pre-RISC days?
Yes. You can find identical text in the gcc-1.42 documentation, when
almost every port was a CISC.
The docs in rtl.texi for the call expression is a bit clearer about the
intent here for FUNCTION_MODE.
--
Jim
On Monday 12 of March 2007 19:47:21 Mark Mitchell wrote:
* PR 29906 (Oliva) -- This is a crash during DWARF generation for a
small C++ test case.
+= PR 29202.
ps).
the PR 30052 (aliasing related) is still unconfirmed.
Hi,
just wanted to say explicitely that I'm supporting completely Doug'
efforts at fixing this issue. Well, I'm a little biased, because I'm
working on C++/26099 and I will need at least one new tree code, but
that's not the point, the point is that where we are implementing C++0x
features
On 3/12/07, Paolo Carlini [EMAIL PROTECTED] wrote:
Hi,
just wanted to say explicitely that I'm supporting completely Doug'
efforts at fixing this issue. Well, I'm a little biased, because I'm
working on C++/26099 and I will need at least one new tree code, but
that's not the point, the point is
On 3/12/07, Paolo Carlini [EMAIL PROTECTED] wrote:
we are unavoidably
adding tree codes and we must solve the issue, one way or another.
Another real solution would perhaps be to not use 'tree' for front end
specific data structures in C++, and instead just define g++ specific
data structures
On 3/12/07, Andrew Pinski [EMAIL PROTECTED] wrote:
Can I recommend something just crazy, rewrite the C and C++ front-ends
so they don't use the tree structure at all except when lowering until
gimple like the rest of the GCC front-ends?
The C front end already emits generic, so there's almost
On 3/12/07, Steven Bosscher [EMAIL PROTECTED] wrote:
On 3/12/07, Andrew Pinski [EMAIL PROTECTED] wrote:
Can I recommend something just crazy, rewrite the C and C++ front-ends
so they don't use the tree structure at all except when lowering until
gimple like the rest of the GCC front-ends?
Steven Bosscher [EMAIL PROTECTED] writes:
| On 3/12/07, Paolo Carlini [EMAIL PROTECTED] wrote:
| we are unavoidably
| adding tree codes and we must solve the issue, one way or another.
|
| Another real solution would perhaps be to not use 'tree' for front end
| specific data structures in C++,
On Mar 12, 2007, at 1:47 PM, Andrew Pinski wrote:
Can I recommend something just crazy, rewrite the C++ front-end so
they don't use the tree structure at all except when lowering until
gimple like the rest of the GCC front-ends?
:-) I don't have any objections, as long as people can keep
Steven Bosscher wrote:
Another real solution would perhaps be to not use 'tree' for front end
specific data structures in C++, and instead just define g++ specific
data structures to represent all the language details ;-)
When I said, let's support Doug, I meant let's support Doug from a
Paolo Carlini [EMAIL PROTECTED] writes:
| In my opinion, visions for a better future do not help here.
And here we are. :-)
-- Gaby
On 3/12/07, Andrew Pinski [EMAIL PROTECTED] wrote:
On 3/12/07, Steven Bosscher [EMAIL PROTECTED] wrote:
On 3/12/07, Andrew Pinski [EMAIL PROTECTED] wrote:
Can I recommend something just crazy, rewrite the C and C++ front-ends
so they don't use the tree structure at all except when lowering
On Mon, 12 Mar 2007, Mike Stump wrote:
:-) I don't have any objections, as long as people can keep the compilation
speed up, though, sounds like a bit of work. I'd look towards a project
architect to help steer us towards goodness and keep us out of trouble. I can
see some advantage to
Mike Stump wrote:
On Mar 12, 2007, at 11:13 AM, Doug Gregor wrote:
With the introduction of the variadic templates patch, we now have
more than 255 tree codes in GCC.
I do wonder about compilation speed for C++ code. Barring some other
innovative approach, even with a slow down, which I'd
On 3/12/07, Paolo Carlini [EMAIL PROTECTED] wrote:
In my opinion, visions for a better
future do not help here.
No, I fully agree. I mean, imagine we'd have a long term plan for
GCC. That would be so out of line!
;-)
I'm not arguing against a practical solution. But to me at least it is
It's going to have a big performance impact. To extract a 9-bit value,
the compiler will need to do a lot of masking every time it accesses
the TREE_CODE.
a lot masking means at most two additional instructions, one if we
put it in the right place. I'd be shocked if we could even measure
On Mar 12, 2007, at 2:14 PM, Paolo Carlini wrote:
When I said, let's support Doug, I meant let's support Doug from a
*practical* point of view. Either we suggest something doable with
a realistically sized effort or a little larger and at the same
time we volunteer to actually do it. In my
Snapshot gcc-4.1-20070312 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20070312/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
So, you need to run aclocal with:
$ aclocal -I ../config -I ..
--
albert chin ([EMAIL PROTECTED])
Thanks, that helps a lot. For libstdc++-v3 I actually needed -I . as
well in order to find linkage.m4 so maybe -I . -I .. -I ../config is
the best option list to use on aclocal calls in the
On 3/12/07, Mike Stump [EMAIL PROTECTED] wrote:
That said, we
all realize we are _not_ asking Doug to please re-implement the C++
frontend to our design to fix this issue. I'd be against that.
Thank you :)
I'm hoping that might allow us to reduce the pressure enough so that
we can fit back
On 3/12/07, Mike Stump [EMAIL PROTECTED] wrote:
On Mar 12, 2007, at 2:14 PM, Paolo Carlini wrote:
When I said, let's support Doug, I meant let's support Doug from a
*practical* point of view. Either we suggest something doable with
a realistically sized effort or a little larger and at the
Hi,
We are pleased to announce the release of AspeCt-oriented C (ACC) V
0.5, formerly known as AspectC.
Besides some new features, the ACC 0.5 release also includes a set of
experimental weave adapters that
help integrate aspeCts in the build process of large C-based software
projects.
For
Hello
My name is Lara Thynne and I am a PhD candidate at Deakin University
Australia. I am currently researching the boundary between work and
leisure activities directly related to the open source community and
open source program development.
As part of this I am running a survey at the
[EMAIL PROTECTED] wrote:
I sincerely apologize for the spammish nature of this e-mail - I
don't mean to abuse this list. I am trying to collect responses
from as many open source developers and users as possible and a
mailing list like can be the only way to reach many developers.
FWIW, one
I've noticed some behavior with make_relative_prefix that surprised
me. In particular, consider this program:
#include stdio.h
extern char * make_relative_prefix (const char *progname,
const char *bin_prefix,
const
As I'm now building GCC 4.2.0 RC1 (*), and am thereby beginning the
release cycle for 4.2.0, I've disabled the 4.2 branch snapshots. It
seems confusing to have both the prereleases (which I build) and the
snapshots (which robots build) available simultaneously, and I would
prefer to focus
--- Comment #2 from kargl at gcc dot gnu dot org 2007-03-12 07:05 ---
(In reply to comment #1)
I don't think underscores are part of Fortran's identifier character space.
An underscore can appear in a symbol except as the first character.
--
--- Comment #5 from burnus at gcc dot gnu dot org 2007-03-12 07:58 ---
complex * complex is not a simple cross product in FP world.
Well, the program calculates: real * complex
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31139
--- Comment #6 from burnus at gcc dot gnu dot org 2007-03-12 08:16 ---
Can someone try instead of doing __real__ a += w[j] *__real__ mfi[*index];
Use a+= xxx* yyy and also use -std=c99 to get the correct multiplication?
Well, -std=c99 was used already and the real(!) * complex
--- Comment #3 from burnus at gcc dot gnu dot org 2007-03-12 08:50 ---
Created an attachment (id=13193)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13193action=view)
Patch draft (by Paul Thomas)
Notes by Paul:
(i) gfc_find_symbol searches via proc_name-ns to
--- Comment #8 from pcarlini at suse dot de 2007-03-12 09:07 ---
(In reply to comment #7)
Also adding new features should not break old features
Here we are not talking about trade-offs, that should be rather clear by now.
We are talking about fixing for real the underlying very
--- Comment #15 from pcarlini at suse dot de 2007-03-12 09:26 ---
Actually in the latest mailing there are two new papers, N2151 and N2152.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20599
--- Comment #10 from Andreas dot Kowarz at tu-dresden dot de 2007-03-12
09:30 ---
THS (The Holy Standard :-) ) 3.7.4.2/3 reads to me that for standard library
implementations the delete operators must be called in any case but return
immediately if the first argument is NULL =
--- Comment #7 from Woebbeking at web dot de 2007-03-12 09:37 ---
Any news on this? It's really annoying if you've many pimpls which often use
anonymous namespace.
--
Woebbeking at web dot de changed:
What|Removed |Added
-allocator=mt --enable-clocale=gnu
--enable-libstdcxx-debug i486-linux-gnu --enable-libmudflap
--enable-checking=release
Thread model: posix
gcc version 4.3.0 20070312 (experimental)
--
Summary: ICE: in cse_find_path, at cse.c:5930with -O3 -
ftracer
--- Comment #6 from manu at gcc dot gnu dot org 2007-03-12 12:10 ---
This seems a duplicate of PR 14710.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28774
The following two testcases should produce the same code after forwprop1:
struct foo { int i[3]; };
void bar (void)
{
struct foo Foo;
int i;
for (i=0; i3; ++i)
{
void *p = Foo.i[i];
int *pi = (int *)p;
if (pi != 0)
{
*pi = 0;
}
}
}
---
Hi,
compared to 4.1.2 the size increased by 50% and more. E.g. Qt 4.2.2
libQtGui.so.4.2.2.debug
- 4.2.0 97902763 bytes
- 4.1.2 62435403 bytes
We compile with -O2 -g. Is this a regression or just more (useful?)
information?
--
Summary: increased size of debug information
--- Comment #30 from amacleod at redhat dot com 2007-03-12 13:11 ---
Err, yeah. thats right. TER doesn't run without optimization, and I forgot this
was more than just an optimization issue. Where is that work to do basic SSA
optimizations at -O0 when you need it?? :-)
--
--- Comment #10 from amacleod at redhat dot com 2007-03-12 13:33 ---
They do all have the (ab) next to them, I was just indicating that they all
occurred in a PHI together, and hence needed to be coalesced. I should have
been more precise.
Well, _t_3 definately does have the (ab) flag,
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-12 14:03 ---
It's more information - whether it's useful depends.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31147
--- Comment #2 from Woebbeking at web dot de 2007-03-12 14:22 ---
Subject: Re: increased size of debug information
On Monday 12 March 2007, rguenth at gcc dot gnu dot org wrote:
It's more information - whether it's useful depends.
Wow, more than 50%. Are there any docs to this
--- Comment #5 from ingo dot donasch at L-3com dot com 2007-03-12 14:32
---
Subject: RE: ptr to member func __delta is 0 if ptr declar
ation does not match function porototype
I know our code is wrong, but my point is that gcc34 generated correct code
and gcc4x is not. A
--- Comment #4 from patchapp at dberlin dot org 2007-03-12 14:50 ---
Subject: Bug number PR30922
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-03/msg00728.html
--
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-03-12 14:51 ---
Figure out which source causes the increase and then attach the preprocessed
source and then we might be able to decide.
It could be that in 4.1.2, that we were not emitting enums and some other types
which should
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-12 14:56 ---
*** This bug has been marked as a duplicate of 31127 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-03-12 14:56 ---
*** Bug 31145 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-12 14:59 ---
forwprop should NOT, I repeat should NOT look through casts for conditional if
the SSA_NAME that defines the cast is still used after the conditional.
Really this non zero optimization should be done by VRP.
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-12 15:09 ---
I should mention, unless it can produce a constant result.
For an example this function:
void bar (void * a)
{
struct foo Foo;
int i;
for (i=0; i3; ++i)
{
void *p = a;
int *pi = (int *)p;
--- Comment #5 from pault at gcc dot gnu dot org 2007-03-12 15:24 ---
The testcase in comment 1 should be lifted and deposited in another PR; it is
going to be quite difficult to fix because the type and kind of an interface
function is established before the specification statements
--- Comment #3 from pault at gcc dot gnu dot org 2007-03-12 15:25 ---
I just submitted a patch for this PR.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30870
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-03-12 15:35 ---
The problem is that for example FRE value numbers
void *p_4 = a[0];
int *q_1 = (int *)p_4;
p_4 with void* type (even if a[0] is of int* type) and so re-generates the
conversion to int* even though it is about
--- Comment #2 from pault at gcc dot gnu dot org 2007-03-12 15:40 ---
I just submitted a patch for this PR.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
Since ivec is not passed to sub, I think the two calls
to set_optional should be equivalent, but gfortran crashes
upon the second call.
u:\vrao\fortran type xopt_bug.f90
module sub_mod
contains
elemental subroutine set_optional(i,idef,iopt)
! set i to (iopt,idef) if iopt (is,is not) PRESENT
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-03-12 15:41 ---
I think really this comes down to our type system, I remember posting a patch
for the LTO branch which adds back the explict cast to void*, I can test
that, it should fix this testcase also :).
--
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-03-12 16:01 ---
Well sure - if we then would get
int *p_1 = a[0];
void *q_1 = (void *)p_1;
int *r_1 = (int *)q_1;
if (r_1 != NULL)
...
then FRE would figure out that r_1 == p_1 and the forwprop pass after FRE will
fold the
Consider this code:
SUBROUTINE FOO(I)
I=0
END
SUBROUTINE BAR()
CALL FOO(1,2)
END
compiled with g77 3.4.6:
f77.f: In subroutine `bar':
f77.f:1:
SUBROUTINE FOO(I)
1
f77.f:6: (continued):
CALL FOO(1,2)
2
Too
--- Comment #10 from mmitchel at gcc dot gnu dot org 2007-03-12 16:24
---
Subject: Bug 30108
Author: mmitchel
Date: Mon Mar 12 16:24:18 2007
New Revision: 122844
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122844
Log:
PR c++/30108
* call.c
--- Comment #4 from Woebbeking at web dot de 2007-03-12 16:46 ---
Created an attachment (id=13194)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13194action=view)
preprocessed qcombobox.cpp
I added both versions (4.2.0 and 4.1.2). It's compiled with
-c -fno-exceptions -pipe -O2
Take:
int main()
{
char str[2][34] = {a,b};
__builtin_puts(str[0]);
return 0;
}
In 4.0.2, we used to get:
static char C.0[2][34] = {a, b};
char str[2][34];
str = C.0;
__builtin_puts (str[0][0]);
But in 4.1.1 and above, we get:
char str[2][34];
str = {};
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31150
--- Comment #3 from manu at gcc dot gnu dot org 2007-03-12 16:47 ---
It would be helpful if you could reduce the testcase. Thanks.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Am receiving following error during 'make bootstrap' for GCC v4.1.2 on AIX 5.3:
srcdir=/usr/local/gcc-4.1.2/fixincludes /bin/sh
/usr/local/gcc-4.1.2/f
ixincludes/mkfixinc.sh powerpc-ibm-aix5.3.0.0
sed -e 's/@gcc_version@//'mkheadersT
/bin/sh: 0403-057 Syntax error at line 1 :
--- Comment #1 from jkurpa at co dot volusia dot fl dot us 2007-03-12
16:51 ---
Created an attachment (id=13195)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13195action=view)
Screen output from 'make bootstrap'
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31151
--- Comment #2 from jkurpa at co dot volusia dot fl dot us 2007-03-12
16:52 ---
Created an attachment (id=13196)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13196action=view)
Screen output from configure
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31151
--- Comment #4 from ian at airs dot com 2007-03-12 17:08 ---
First test case:
int f(int a)
{
if (a 0)
a = -a;
return a 0;
}
As far as I can tell the behaviour of this test case in VRP is unchanged by the
patch in this PR. And the code is still fully optimized.
Second test
--- Comment #5 from ian at airs dot com 2007-03-12 17:21 ---
Unfortunately my patch in comment #1 doesn't handle this test case correctly:
extern void abort (void);
void
foo (int a)
{
if (a = (int) 0x8001)
{
a = - a;
if (a 0)
abort ();
}
}
It turns
--- Comment #14 from manu at gcc dot gnu dot org 2007-03-12 17:22 ---
Tom,
your patch
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01853.html
will also fix this by adding Wdeprecated to the C front-end.
--
manu at gcc dot gnu dot org changed:
What|Removed
--- Comment #6 from rth at gcc dot gnu dot org 2007-03-12 17:15 ---
Subject: Bug 26090
Author: rth
Date: Mon Mar 12 17:15:44 2007
New Revision: 122847
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122847
Log:
PR target/26090
* config/alpha/alpha.c
--- Comment #19 from manu at gcc dot gnu dot org 2007-03-12 17:31 ---
(In reply to comment #18)
Created an attachment (id=13025)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13025action=view) [edit]
Updated patch, output from svn diff as of 2007-02-07
Joerg, as Andrew said,
The actual gcc version is
gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
When compiled and run with this gcc version, using the command line
gcc -O xxx.c a.out
the attached program outputs -1, whereas the correct output is 0. If
I use gcc 3.3.6 or leave away the -O flag, the
--- Comment #5 from manu at gcc dot gnu dot org 2007-03-12 17:39 ---
(In reply to comment #4)
See also PR 23281
[snip]
Consequently I'm filing this as a DR against the gcc DR reporting machinery
itself, rather than against the compiler in particular. There needs to be
categories for
--- Comment #1 from anton at mips dot complang dot tuwien dot ac dot at
2007-03-12 17:43 ---
Subject: Re: New: -(xy) generates wrong code
I cannot create an attachment in Bugzilla, so I'll just append the
test program here:
#include stdio.h
#include limits.h
long foo(long x, long
--- Comment #6 from janis at gcc dot gnu dot org 2007-03-12 17:45 ---
The link in comment #5 is to David Edelsohn's message that RMS had approved the
license change. Ben Elliston changed the license in the decNumber files for
mainline and the 4.2 branch.
--
janis at gcc dot gnu dot
--- Comment #2 from manu at gcc dot gnu dot org 2007-03-12 17:48 ---
(In reply to comment #1)
It is, however, at least unspecified order of evaluation and a warning
here would still make sense.
A candidate for -Wsequence-points ?
--
1 - 100 of 166 matches
Mail list logo
