I see the following files in my subversion directory:
./gcc/.cvsignore
./libstdc++-v3/.cvsignore
./zlib/.cvsignore
./libobjc/.cvsignore
./intl/.cvsignore
./libgfortran/.cvsignore
./libmudflap/.cvsignore
./boehm-gc/.cvsignore
./fastjar/.cvsignore
./libffi/.cvsignore
./libssp/.cvsignore
I've uploaded cctools-590.12 to
ftp://gcc.gnu.org/pub/gcc/infrastructure/cctools-590.12.dmg
and the source for it as
ftp://gcc.gnu.org/pub/gcc/infrastructure/cctools-590.12.tar.bz2
Their md5 checksums are:
410dd3c1471d31e24a193c674432a7f5 cctools-590.12.tar.bz2
New version of the patch attached, to answer Joseph's remark. Original
questions still apply, including:
What should gfortran -fdollar-ok a.f b.c do, if -fdollar-ok if a
fortran-only option?
FX
./gcc/.cvsignore
./libstdc++-v3/.cvsignore
./zlib/.cvsignore
./libobjc/.cvsignore
./intl/.cvsignore
./libgfortran/.cvsignore
./libmudflap/.cvsignore
./boehm-gc/.cvsignore
./fastjar/.cvsignore
./libffi/.cvsignore
./libssp/.cvsignore
./libjava/libltdl/.cvsignore
Hi all,
Can someone give me a rough indication of when this contribution might
be reviewed, please?
Since submitting the patch, I have got DejaGNU working with my
simulator, so once I've ironed out a few problems this has highlighted,
I'll submit some test results to the test-results
Daniel Berlin [EMAIL PROTECTED] writes:
[...]
./.cvsignore
Shouldn't we delete all of them?
Yes.
I thought i fixed cvs2svn to remove them, but apparently missed some
cases where they were added.
Shall I issue a simple svn rm or do you want to do some other magic?
Andreas
--
Andreas
On Monday 31 October 2005 07:32, Hanzac Chen wrote:
On 10/31/05, Hanzac Chen wrote:
Hi,
Is the comment symbol for arm @? But the intermediate code
(assembler code) generated by GCC 4.1.0 (gcc-4.1-20051022) can't be
assembled by the latest release of binutils (binutils-2.16.1).
On Mon, 2005-10-31 at 15:19 +0100, Andreas Jaeger wrote:
Daniel Berlin [EMAIL PROTECTED] writes:
[...]
./.cvsignore
Shouldn't we delete all of them?
Yes.
I thought i fixed cvs2svn to remove them, but apparently missed some
cases where they were added.
Shall I issue a
On Sun, 16 Oct 2005, Daniel Berlin wrote:
I should probably note again that i don't plan to convert wwwdocs to svn
right now, because the checkout scripts are a bit hard to follow, etc.
Per se there doesn't seem to be as much of an advantage for wwwdocs
as we had for gcc (no branches, most
On Mon, 31 Oct 2005, Gerald Pfeifer wrote:
On Sun, 16 Oct 2005, Daniel Berlin wrote:
I should probably note again that i don't plan to convert wwwdocs to svn
right now, because the checkout scripts are a bit hard to follow, etc.
Per se there doesn't seem to be as much of an advantage
On Mon, Oct 31, 2005 at 12:51:40AM +0100, FX Coudert wrote:
This is a patch proposal about PR fortran/18452. In short, to preprocess
fortran source files, gfortran calls cc1 with its own options, which
gives warnings like:
$ gfortran -fdollar-ok a.F90
cc1: warning: command line option
Dan == Daniel Berlin [EMAIL PROTECTED] writes:
Shall I issue a simple svn rm or do you want to do some other magic?
Dan Just svn rm them all
The ones in libjava/classpath come from upstream imports. They will
most likely just show up again next time we import Classpath.
Tom
On Mon, Oct 31, 2005 at 09:47:59AM -0500, Daniel Berlin wrote:
On Mon, 2005-10-31 at 15:19 +0100, Andreas Jaeger wrote:
Daniel Berlin [EMAIL PROTECTED] writes:
[...]
./.cvsignore
Shouldn't we delete all of them?
Yes.
I thought i fixed cvs2svn to remove them, but
On Sat, Oct 29, 2005 at 11:12:07AM +, Joseph S. Myers wrote:
The Post-Mont-Tremblant WG14 mailing is now available from the WG14
website. Particular points of note:
* The current decimal FP draft is now N1150 (no longer N1107 which is the
version mentioned in svn.html); I don't what
On Mon, Oct 31, 2005 at 01:20:48PM +0100, FX Coudert wrote:
New version of the patch attached, to answer Joseph's remark.
Actually, no :-)
What should gfortran -fdollar-ok a.f b.c do, if -fdollar-ok if a
fortran-only option?
It shouldn't pass -fdollar-ok to cc1, IMHO.
New version of the patch attached (this time), to answer Joseph's
remark. Original questions still apply, including:
What should gfortran -fdollar-ok a.f b.c do, if -fdollar-ok if a
fortran-only option?
FX
2005-10-31 Francois-Xavier Coudert [EMAIL PROTECTED]
PR fortran/18452
What should gfortran -fdollar-ok a.f b.c do, if -fdollar-ok if a
fortran-only option?
It shouldn't pass -fdollar-ok to cc1, IMHO.
I'm not sure about how other languages handle that. Trying to mix java
and C gives:
$ gcj -c Example.java a.c -Wredundant-modifiers
cc1: warning: command line
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
See:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24514
Rainer
- --
Rainer Emrich
TECOSIM GmbH
Im Eichsfeld 3
65428 Rüsselsheim
Phone: +49(0)6142/8272 12
Mobile: +49(0)163/56 949 20
Fax.: +49(0)6142/8272 49
Web: www.tecosim.com
-BEGIN PGP
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
See:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24514
Most people don't have access to MIPS IRIX so it is hard
to figure out what is going on.
Giving the backtrace of where the trap happens might help
figure it out but it might not.
--
On Mon, Oct 31, 2005 at 05:31:51PM +0100, Gerald Pfeifer wrote:
Per se there doesn't seem to be as much of an advantage for wwwdocs
as we had for gcc (no branches, most changes only to one or two files,
no need for binary regression search, no tagging,...) so it's not
urgent.
Well, maybe.
On Sat, Oct 29, 2005 at 03:45:33AM -0700, Per Bothner wrote:
Rather than adding new flags, I'd think I'd prefer:
1. Change the behavior (back) so only '\\$', not '\\ *$', causes a
line to be continued.
2. Make -Wcomment more useful to it only warns when it might matter:
The following
On Sun, Oct 30, 2005 at 12:24:56PM +0100, FX Coudert wrote:
I added a test for the testsuite, conditionnal on a new effective
target. Could someone OK this part?
How does the test in check_effective_target_static_libgfortran check for
use of static libgfortran? Shouldn't it pass -static or
* Joe Buck:
Well, maybe. But what about a revision that modifies code and that
also modifies the WWW to describe the code modification? If everything
were in the same subversion repository, it could be one change.
Only if you check out a common parent directory, which is probably not
a
If I compile source code using GCC, that does not require me to open-source the
resulting program under the GPL, correct?
--
Sent from the gcc - General forum at Nabble.com:
http://www.nabble.com/GPL-question-t472890.html#a1287328
* dfhgjwetgtry:
If I compile source code using GCC, that does not require me to
open-source the resulting program under the GPL, correct?
Compiling a program with GCC does not by itself cause the resulting
executable to be covered by the GNU General Public License. This does
not however
Joe Buck wrote:
On Sat, Oct 29, 2005 at 03:45:33AM -0700, Per Bothner wrote:
1. Change the behavior (back) so only '\\$', not '\\ *$', causes a
line to be continued.
The problem with your item #1 is that there is then no way of flagging
code that won't work with the large numbers of
On Mon, 31 Oct 2005, Florian Weimer wrote:
If I compile source code using GCC, that does not require me to
open-source the resulting program under the GPL, correct?
Compiling a program with GCC does not by itself cause the resulting
executable to be covered by the GNU General Public License.
On Mon, Oct 31, 2005 at 11:35:45AM -0800, Per Bothner wrote:
Joe Buck wrote:
On Sat, Oct 29, 2005 at 03:45:33AM -0700, Per Bothner wrote:
1. Change the behavior (back) so only '\\$', not '\\ *$', causes a
line to be continued.
The problem with your item #1 is that there is then no way
(experimental)
+/Volumes/export/gcc/gcc-svn/head/objdir/gcc/xgcc version 4.1.0
20051031 (experimental)
Next to check link times on libjava ;)
Andreas
Joe Buck wrote:
So you want the compiler to only consider '\\$ a continuation,
Not my preference, but that is my proposal, in the interest
of compatibility.
but to have an unsilenceable warning about '\\ *$'?
Not unsilenceable - but on-by-default. It could be silenced with
an explicit
I've placed an svk tarball that contains trunk/ from 3.4 onward at
ftp://gcc.gnu.org/pub/gcc/infrastructure/svk-trunk-3.4-onward.tar.rz
Note:
People expecting this to be massively faster (IE 100x) at some things
like annotate are going to discover that unless you have a slow network
connection,
On Sun, 2005-10-30 at 23:40 -0800, Mark Mitchell wrote:
In reviewing the PR list, I saw several (maybe 5?) PRs about problems
with -Wuninitialized.
Joys...
All of these problems related to getting confused in the optimizers in
various ways; sometimes we think things are uninitialized when
On Sun, 2005-10-30 at 23:40 -0800, Mark Mitchell wrote:
In reviewing the PR list, I saw several (maybe 5?) PRs about problems
with -Wuninitialized.
[ ... ]
After pondering this some more I almost wonder if what we need is a
separate warning for variables which were potentially uninitialized
but
On Mon, Oct 31, 2005 at 04:49:43PM -0700, Jeffrey A Law wrote:
On Sun, 2005-10-30 at 23:40 -0800, Mark Mitchell wrote:
In reviewing the PR list, I saw several (maybe 5?) PRs about problems
with -Wuninitialized.
[ ... ]
After pondering this some more I almost wonder if what we need is a
moshed (sent by Nabble.com) wrote:
Following to your response I tried to add -v but doesn't succsed , maybe I locate
on the wrong place.
It is a gcc option. Just put it in CFLAGS, or just run gcc manually
with -v added to your other command line options.
also if u can replay me ragarding
Hi,
(1) if I want to dump a gimple tree representation of a program, where
should I start to look at? And I read gcc internal manual, the control flow
graph information is represented by BB data structure. If I want to walk
through a control flow graph, where should I start to look at?
(2)
Jeffrey A Law wrote:
On Sun, 2005-10-30 at 23:40 -0800, Mark Mitchell wrote:
In reviewing the PR list, I saw several (maybe 5?) PRs about problems
with -Wuninitialized.
Where I suspect we're falling down more often is not issuing warnings
because the uninitialized variable was optimized away
On Mon, 2005-10-31 at 17:11 -0800, Mark Mitchell wrote:
Certainly if we can't prove f always returns a nonzero value, then a
warning should be issued. If we do prove f always returns a nonzero
value, then I think it becomes unclear if we should generate a warning.
I don't think it's
On Mon, 2005-10-31 at 18:52 -0500, Daniel Jacobowitz wrote:
On Mon, Oct 31, 2005 at 04:49:43PM -0700, Jeffrey A Law wrote:
On Sun, 2005-10-30 at 23:40 -0800, Mark Mitchell wrote:
In reviewing the PR list, I saw several (maybe 5?) PRs about problems
with -Wuninitialized.
[ ... ]
After
Hello,
Such a problem is difficult to find the reason. But can you give some
suggestion about the possible matter? This is the information on my
port. Thanks a lot.
dp-bit.c: In function `__muldf3':
dp-bit.c:957: error: unable to generate reloads for:
(insn 416 415 417 20 dp-bit.c:874 (set
Jeffrey A Law wrote:
On Mon, 2005-10-31 at 17:11 -0800, Mark Mitchell wrote:
Certainly if we can't prove f always returns a nonzero value, then a
warning should be issued. If we do prove f always returns a nonzero
value, then I think it becomes unclear if we should generate a warning.
I
Jeffrey A Law [EMAIL PROTECTED] writes:
We clearly disagree then. Though my 15+ years of working with GCC I've
seen far more complaints about false positives than missing instances
of this warning.
I think that most of the false positives are of the form
int x, f, y;
f = foo ();
Eric Fisher [EMAIL PROTECTED] writes:
Such a problem is difficult to find the reason. But can you give some
suggestion about the possible matter? This is the information on my
port. Thanks a lot.
dp-bit.c: In function `__muldf3':
dp-bit.c:957: error: unable to generate reloads for:
(insn
Ian Lance Taylor wrote:
Jeffrey A Law [EMAIL PROTECTED] writes:
We clearly disagree then. Though my 15+ years of working with GCC I've
seen far more complaints about false positives than missing instances
of this warning.
I think that most of the false positives are of the form
On Mon, 2005-10-31 at 20:46 -0800, Ian Lance Taylor wrote:
Jeffrey A Law [EMAIL PROTECTED] writes:
We clearly disagree then. Though my 15+ years of working with GCC I've
seen far more complaints about false positives than missing instances
of this warning.
I think that most of the
--- Comment #4 from anlauf at gmx dot de 2005-10-31 08:09 ---
(In reply to comment #2)
How can this possibly be a GCC 4.0/4.1 regression?!
It works with a GCC 4.1.0 20050913 snapshot, but not recent ones.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24534
templatetypename T class A
public:
int i;
};
gets you:
~/ootbc/members/src$ g++ foo.cc
foo.cc:2: error: expected unqualified-id before public
foo.cc:2: error: expected `;' before public
foo.cc:4: error: expected declaration before '}' token
Actually, I think the only thing that is
The code:
templatetypename T
struct b1 {
protected:
voidinc() {}
T* dummy;
};
templatetypename T, templatetypenameclass F
struct b2 {
voidf() {
FT* s = static_castFT*(this);
s-inc();
}
};
templatetypename T
struct G : public b1T, public
--- Comment #1 from igodard at pacbell dot net 2005-10-31 10:32 ---
Sorry, screwed up the explanation. Should be:
The access to inc is s-inc(). s is a FT*, which after parameter
substitution is a Gint*. b1T is a public base of GT, which after
substitution means that b1int is a public
--- Comment #23 from jaffe at broad dot mit dot edu 2005-10-31 10:47
---
When is this problem likely to be resolved? I understand that you have to
prioritize. I just want to understand what the prospects are. Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23835
Following source code doesn't compile using a 64-bit GNU compiler (it
works fine using a 32-bit compiler);
# 1 va_list_bug.cc
# 1 built-in
# 1 command line
# 1 va_list_bug.cc
# 1 /usr/lib/gcc-lib/x86_64-linux/3.3.5/include/stdarg.h 1 3 4
# 43 /usr/lib/gcc-lib/x86_64-linux/3.3.5/include/stdarg.h 3
--- Comment #1 from schwab at suse dot de 2005-10-31 11:04 ---
Why do you think va_list is compatible with pointer to char?
--
schwab at suse dot de changed:
What|Removed |Added
hello,
the following program fails to correctly find the right overloaded global
template function f(). clearly ::f() called within test::f() depends on a
template parameter so lookup should be postponed to the point of instantiation
which is not the case.
if template class X void f(X x, const
--- Comment #2 from wh at ciphirelabs dot com 2005-10-31 11:22 ---
Subject: Re: problem with va_list function-parameter [u] [signed]
I don't, but this is a piece of a third-party code we're using and which
compiled fine with the GNU 32-bit compiler so far;
so I'm wondering about the
Version information:
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--- Comment #1 from pcarlini at suse dot de 2005-10-31 12:06 ---
Humpf, we are missing some free functions! Thanks.
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #6 from gkajmowi at tbaytel dot net 2005-10-31 12:26 ---
Subject: Re: [3.4/4.0/4.1 Regression] invalid inline warning with ctor and
dtor
On October 30, 2005 10:37 pm, mmitchel at gcc dot gnu dot org wrote:
--- Comment #5 from mmitchel at gcc dot gnu dot org
--- Comment #1 from aldyh at gcc dot gnu dot org 2005-10-31 12:43 ---
Subject: Bug 24505
Author: aldyh
Date: Mon Oct 31 12:43:44 2005
New Revision: 106269
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106269
Log:
PR gomp/24505
* c-omp.c (c_finish_omp_for):
--- Comment #20 from aldyh at gcc dot gnu dot org 2005-10-31 12:48 ---
I'll take this.
--
aldyh at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from aldyh at gcc dot gnu dot org 2005-10-31 12:52 ---
http://gcc.gnu.org/ml/gcc-patches/2005-10/msg01718.html
--
aldyh at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from pinskia at gcc dot gnu dot org 2005-10-31 12:52
---
(In reply to comment #9)
Should this be marked as fixed, or as 4.0-only, given the patch in Comment #8?
No because it still fails after that one with an ICE. See comment #6.
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-31 13:16 ---
Patch posted:
http://gcc.gnu.org/ml/gcc-patches/2005-10/msg01783.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-10-31 13:22 ---
Subject: Bug 23492
Author: pinskia
Date: Mon Oct 31 13:22:20 2005
New Revision: 106270
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106270
Log:
2005-10-31 Andrew Pinski [EMAIL PROTECTED]
PR
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-10-31 13:22 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #22 from amacleod at redhat dot com 2005-10-31 13:33 ---
It will be checked in shortly. I got your OK for this stage last week, and I
was merely waiting for the SVN switchover freeze to expire, trying a new build
and getting back to work today.
--
--- Comment #10 from dberlin at gcc dot gnu dot org 2005-10-31 13:53
---
Subject: Re: [4.1 Regression] ICE in
do_simple_structure_copy with some C++ code
On Mon, 2005-10-31 at 06:16 +, mmitchel at gcc dot gnu dot org
wrote:
--- Comment #9 from mmitchel at gcc dot
--- Comment #23 from amacleod at redhat dot com 2005-10-31 14:41 ---
Hmm. This has been committed, but the commit hasn't shown up yet. Perhaps
because I tagged it as a tree-optimization PR and I now notice that its marked
as rtl-optimization?
--
--- Comment #6 from hubicka at gcc dot gnu dot org 2005-10-31 14:49 ---
Subject: Bug 24487
Author: hubicka
Date: Mon Oct 31 14:48:57 2005
New Revision: 106276
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106276
Log:
PR profile/24487
* predict.c (predict_loops):
--- Comment #7 from hubicka at gcc dot gnu dot org 2005-10-31 14:54 ---
Concerning Mark's comment (I noticed only after committing the patch). I am not
sure what exactly Mark has in mind - this situation is not actually dependend
on inlining - easilly
we might just have funcition with
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.1.0 |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22488
--- Comment #24 from dberlin at gcc dot gnu dot org 2005-10-31 15:04
---
I fixed the bug that was preventing it from sending it to this bug, it should
pop up in a second
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19097
--- Comment #25 from amacleod at redhat dot com 2005-10-31 15:19 ---
Subject: Bug 19097
Author: amacleod
Date: Mon Oct 31 13:38:05 2005
New Revision: 106272
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106272
Log:
2005-10-31 Andrew MacLeod [EMAIL PROTECTED]
PR
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-31 15:32 ---
No, you cannot get around access checking like this.
b2 does not know anything about its super classes at all, and it should not
know anything about them.
Also the following applies:
b2 cannot access the stuff in
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-31 15:36 ---
(In reply to comment #0)
Actually, I think the only thing that is syntactically valid before public:
here is a {.
No, it could be : classname.
But anyways confirmed, we should be able to do better.
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-31 15:41 ---
I think this is invalid as the name is fully qualified:
::f(*this,y);
So it looks up the overloaded set __while__ parsing. This is required for the
two stage name lookup rule for templates. I
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-31 15:45 ---
Hmm:
http://gcc.gnu.org/ml/gcc/2004-10/msg00038.html
So maybe this is undefined. I think we should wait for the committe to decide
this one before changing anything here.
--
I'm currently on the way writing a smallish libm for VAX, using GCC from SVN
plus some (mostly configury) patches. The code attached (it's hackish)
doesn't work. Basically, this flow of code is broken:
long double sinl (long double x) {
if (x 0.0)
return -sin (-x)
:
:
}
--- Comment #1 from jbglaw at lug-owl dot de 2005-10-31 15:49 ---
Created an attachment (id=10084)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10084action=view)
My sine and cosine implementation serving as testcase.
The attached .tar.gz contains my start of a libm. Don't laugh
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-31 15:53 ---
Use -fno-builtin-sin as we are expecting at this point to have a full sin
function.
If you don't want optimizations like this for other functions, use
-fno-builtin.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #11 from bangerth at dealii dot org 2005-10-31 16:10 ---
(In reply to comment #8)
How do you generate all these snippets?
By sheer determination. I pick some topic like pointers-to-members or
destructors for example and try to find some bugs. Over time you get
a good
--- Comment #76 from bkoz at gcc dot gnu dot org 2005-10-31 16:47 ---
Created an attachment (id=10085)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10085action=view)
hidden visibility for __gnu_internal
Without per-namespace visibility attributes, this is what we will have to do
--- Comment #5 from bothner at gcc dot gnu dot org 2005-10-31 16:58 ---
The two test cases appear to be unrelated problems.
The inital report is because an invalid line marker is seen before debug_hooks
is set in process_options. fe_enter doesn't normally see an LC_ENTER during
--- Comment #77 from pcarlini at suse dot de 2005-10-31 16:59 ---
Thanks Benjamin! Indeed, if you want to take care of this entire issue, you
are welcome (just reassign)! In any case, I'm not sure whether it's suited
for 4.1, at this point...
--
--- Comment #26 from steven at gcc dot gnu dot org 2005-10-31 17:12 ---
Moving back to new, because I don't know if the GCSE CPROP issue with implicit
sets is also already fixed.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #18 from steven at gcc dot gnu dot org 2005-10-31 17:14 ---
See comment #16 for a patch.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #19 from pinskia at gcc dot gnu dot org 2005-10-31 17:16
---
(In reply to comment #18)
See comment #16 for a patch.
More than that, it has been posted:
http://gcc.gnu.org/ml/gcc-patches/2005-10/msg01792.html
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #10 from pinskia at gcc dot gnu dot org 2005-10-31 17:18
---
Patch posted:
http://gcc.gnu.org/ml/gcc-patches/2005-10/msg01691.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from steven at gcc dot gnu dot org 2005-10-31 17:31 ---
Right, I didn't know this wasn't opened until July of this year, sorry.
I should have looked.
I still am not sure whether this does break a documented ABI. Relevant
texts in C99 are 6.2.6.1 sub 4, and 6.7.2.1 sub
--- Comment #1 from r dot emrich at de dot tecosim dot com 2005-10-31
17:37 ---
same for gcc-4.1-20051029
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24514
--- Comment #3 from tromey at gcc dot gnu dot org 2005-10-31 17:48 ---
I'll handle this.
I agree, we need this alias.
That particular part of the code is generated by
the script libjava/scripts/encodings.pl.
Looking at the current IANA character-sets file, I see
there is only this:
--- Comment #4 from tromey at gcc dot gnu dot org 2005-10-31 17:51 ---
I'll handle this.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from hubicka at gcc dot gnu dot org 2005-10-31 18:15 ---
Actually the cited 4.0 sequence do not obey the const int x86_read_modify =
~(m_PENT | m_PPRO);
setting -march=athlon or using -Os makes the move go away. Additionally I get
following sequence out of 4.0 in SUSE
--- Comment #2 from echristo at apple dot com 2005-10-31 18:17 ---
Since I don't have access to an irix box anymore I'd really need the
instruction it fails on at the least, some annotated assembly would be a good
start (compile the failing file with -dap and attach the .s output).
--
--- Comment #6 from hubicka at gcc dot gnu dot org 2005-10-31 18:24 ---
I don't have P4 to test handy. Can you re-test whether fixing 23302 (23303 is
invalid) make any difference?
I doubt these two make actual runtime changes - the sequence would translate to
same uops for P4 and
--- Comment #28 from hubicka at gcc dot gnu dot org 2005-10-31 18:36
---
I get 0m8.052s on 3.4 and 0m8.127s on mainline on Athlon. This hardly counts
as an regression.
This is actually effect of some cost tweaks we did relatie to gimplifier a
while ago.
Reduced testcase fits in limits
--- Comment #78 from ismail at uludag dot org dot tr 2005-10-31 18:37
---
Paolo, this is surely a bug fix. Why can't it make it to 4.1 ? Waiting for 4.2
means that unpatched gcc's will suffer for more.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
--- Comment #20 from hubicka at gcc dot gnu dot org 2005-10-31 18:45
---
Patch comitted. For some reason don't seem to appear in logs?
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from hubicka at gcc dot gnu dot org 2005-10-31 18:47
---
I tested only simplified testcase, but the issue should be resolved pretty
safely.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
GCC needs support for odcctools and --prefix ablity. The finding of libtool is
the main issue.
I don't know what else is needed right now but when my laptop comes back alive,
I will look more into this.
--
Summary: Need to support odcctools and its ablity to use --prefix
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-31 18:58 ---
I will take this for now.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
1 - 100 of 184 matches
Mail list logo
