In reviewing the PR list, I saw several (maybe 5?) PRs about problems
with -Wuninitialized.
All of these problems related to getting confused in the optimizers in
various ways; sometimes we think things are uninitialized when they
obviously aren't; other times we don't warn when we obviously shoul
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).
>
> Which is the correct line-comment symbol for arm assembl
There are quite a few missed-optimization PRs on the serious-regression
list: 25 to be exact. Clearly, performance is important; the
justification for all of the tree-ssa infrastructure is better
performance. The point is just to have more passes; it's to have better
SPEC numbers, better CSiBe nu
I've made a pass through all of the open regressions for 4.1, assigning
priorities as discussed previously.
There are 112 regressions makred P3 or higher; the lower-priority PRs
involving diagnostic nits, and such, have been downgraded to P4/P5. As
per my last status report, if we can get to 100,
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).
Which is the correct line-comment symbol for arm assembler?
Thanks,
Hanzac
Ian Lance Taylor wrote:
>>P5 bugs will be ones I consider too unimportant to block *any* future
>>release. I'm going to add links to the main web page to query for the
>>regressions I think are important enough to block a release.
>
> Could you or somebody please update the "Known regressions" b
Mark Mitchell <[EMAIL PROTECTED]> writes:
> P1 bugs will be bugs I think absolutely must be fixed before the next
> release; releasing with this bug would be diastrous.
>
> I'd like to use P2 to indicate that I've review the bug, and that it
> does not merit P1 status, but is important.
>
> P3 w
"Giovanni Bajo" <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
|
| You can always see them with the [EMAIL PROTECTED] syntax
|
| ie
| svn ls svn://gcc.gnu.org/svn/gcc/[EMAIL PROTECTED]
| >>>
| >>> Which requires remembering an arbitrary revision nu
On Mon, 2005-10-31 at 03:08 +0100, Gabriel Dos Reis wrote:
> "Giovanni Bajo" <[EMAIL PROTECTED]> writes:
>
> | Joseph S. Myers <[EMAIL PROTECTED]> wrote:
> |
> | >> You can always see them with the [EMAIL PROTECTED] syntax
> | >>
> | >> ie
> | >> svn ls svn://gcc.gnu.org/svn/gcc/[EMAIL PROTECTED]
Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
You can always see them with the [EMAIL PROTECTED] syntax
ie
svn ls svn://gcc.gnu.org/svn/gcc/[EMAIL PROTECTED]
>>>
>>> Which requires remembering an arbitrary revision number (i.e.,
>>> making life *harder* not *easier* for people
"Giovanni Bajo" <[EMAIL PROTECTED]> writes:
| Joseph S. Myers <[EMAIL PROTECTED]> wrote:
|
| >> You can always see them with the [EMAIL PROTECTED] syntax
| >>
| >> ie
| >> svn ls svn://gcc.gnu.org/svn/gcc/[EMAIL PROTECTED]
| >
| > Which requires remembering an arbitrary revision number (i.e., mak
Joseph S. Myers <[EMAIL PROTECTED]> wrote:
>> You can always see them with the [EMAIL PROTECTED] syntax
>>
>> ie
>> svn ls svn://gcc.gnu.org/svn/gcc/[EMAIL PROTECTED]
>
> Which requires remembering an arbitrary revision number (i.e., making
> life *harder* not *easier* for people looking for that
I recently had occasion to revisit the nightmare that is
the *_SPECS madness for the SCO port. I dont know who all
was responsible for it, but I want to say a huge thankyou
to whoever it was that updated the compiler driver to allow
for the if-then-else spec syntax. It has made my life SO
much eas
On Sun, 30 Oct 2005, Daniel Berlin wrote:
> > I fail to see any reason for this. When you don't need a file anymore, you
> > delete it. When you don't need a directory anymore, you delete it. I can't
> > see
> > why it should be any different for branches. Deleting a branch makes life
> > easier
On Mon, 2005-10-31 at 01:18 +0100, Giovanni Bajo wrote:
> Joseph S. Myers <[EMAIL PROTECTED]> wrote:
>
> >> For old branches that are dead and of no use (because they are
> >> merged into newer branches), I'm include to rm them, and for old
> >> branches that have ideas, but, may never see the lig
Joseph S. Myers <[EMAIL PROTECTED]> wrote:
>> For old branches that are dead and of no use (because they are
>> merged into newer branches), I'm include to rm them, and for old
>> branches that have ideas, but, may never see the light of day, be
>> conservative and leave them alone.
>
> I'd rather
On Mon, 31 Oct 2005, FX Coudert wrote:
> * gcc/c-opts.c: Add cases for all Fortran options declared as C
> and used only when preprocessing.
Someone building without Fortran (whether with it disabled, or without it
in the source tree) won't get the enumerators from fortran/lang.o
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 "-fdollar-ok" is valid for F95 but not
for C
A few (two exactly) o
On Fri, 27 Oct 2005, Tom Tromey wrote:
>> our configure/build system really should be clever enough to
>> automatically set pkgdatadir to the correct value in the first
>> place: $(prefix)/libdata/pkgconfig on FreeBSD, and $(libdir)/pkgconfig
>> elsewhere.
> Are there other places where we try to
On Sun, 2005-10-30 at 17:48 -0500, Andrew Pinski wrote:
> >> It might be better to add a flag for this istead of using the priority
> >> field.
>
> >I think it's an appropriate use of the priority field; the priority
> >field is supposed to say how important the bug is, which is another way
> >of
>> It might be better to add a flag for this istead of using the priority
>> field.
>I think it's an appropriate use of the priority field; the priority
>field is supposed to say how important the bug is, which is another way
>of saying how excited we should be about fixing it in an upcoming relea
On Sun, 30 Oct 2005, Mike Stump wrote:
> For old branches that are dead and of no use (because they are merged into
> newer branches), I'm include to rm them, and for old branches that have ideas,
> but, may never see the light of day, be conservative and leave them alone.
I'd rather put dead bra
Mike Stump wrote:
> On Oct 30, 2005, at 10:23 AM, Mark Mitchell wrote:
>
>> I'm not quite sure who can approve this, but I think probably I can.
>> So, I'll approve it, conditional on no objections for 72 hours.
>
>
> Would be nice to have a general well established policy that everyone
> can f
On Oct 30, 2005, at 10:23 AM, Mark Mitchell wrote:
I'm not quite sure who can approve this, but I think probably I can.
So, I'll approve it, conditional on no objections for 72 hours.
Would be nice to have a general well established policy that everyone
can follow, baring other reasons for no
Andrew Pinski wrote:
>>[Danny, see below for a request.]
>>
>>In my review of open PRs against the 4.1 branch, I'm going to adopt a
>>new convention.
>>
>>Until now, when I've decided something is not important enough to
>>require fixing for a particular release, I unset the target milestone.
>>Tha
>
> [Danny, see below for a request.]
>
> In my review of open PRs against the 4.1 branch, I'm going to adopt a
> new convention.
>
> Until now, when I've decided something is not important enough to
> require fixing for a particular release, I unset the target milestone.
> That's confusing beca
Joseph S. Myers wrote:
> Does this mean regressions for languages and platforms other than those in
> the release criteria should now have the milestone set, but be marked as
> P4 or P5?
Yes, as P5. But, I don't intend to try to go back and find those that
are already unmarked, and "fix" the m
On Sun, 30 Oct 2005, Mark Mitchell wrote:
> Until now, when I've decided something is not important enough to
> require fixing for a particular release, I unset the target milestone.
> That's confusing because it might seem to mean that I'm saying the bug
> *can't* be fixed for a particular releas
On Sun, 2005-10-30 at 13:42 -0800, Mark Mitchell wrote:
> [Danny, see below for a request.]
>
> In my review of open PRs against the 4.1 branch, I'm going to adopt a
> new convention.
>
> Until now, when I've decided something is not important enough to
> require fixing for a particular release,
[Danny, see below for a request.]
In my review of open PRs against the 4.1 branch, I'm going to adopt a
new convention.
Until now, when I've decided something is not important enough to
require fixing for a particular release, I unset the target milestone.
That's confusing because it might seem t
Daniel Berlin wrote:
> [ Mark, my emails to gcc-announce are dropped on the floor, can you
> forward this there? ]
I've posted a slightly more user-centric announcement. I hope that's OK.
Thanks,
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Joseph S. Myers wrote:
> On Fri, 28 Oct 2005, Daniel Berlin wrote:
>
>
>>contrib/ scripts have been updated in the new repository
>
>
> I've merged the gcc_update change to 4.0 branch, 3.4 branch and
> csl-arm-branch. In so doing, bug 20731 is fixed since the branch name is
> no longer hardc
Paul Thomas <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] gcc-svn]# svn up
> svn+ssh://[EMAIL PROTECTED]/svn/gcc/trunk svn:
> 'svn+ssh://[EMAIL PROTECTED]/svn/gcc' is not a working copy
That command makes no sense, as "svn help up" would tell you. If you are going
to checkout the trunk, you nee
Daniel Berlin wrote:
> Diego already said it was okay, and since they were his tags, i did
> it :)
Well, then. :-)
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
On Sun, 2005-10-30 at 10:23 -0800, Mark Mitchell wrote:
> Daniel Berlin wrote:
>
> > Okay, well, consider this an official proposal to remove:
> >
> > 1. the tree-ssa branch *merge* tags (IE the ones used to merge trunk
> > into tree-ssa, *not* the other way around
> > 2. the ast-optimizer-branch
On Oct 29, 2005, at 7:54 PM, Daniel Berlin wrote:
1. Apple tags should go in a subdirectory named "apple".
Hey, I already had that thought, I don't want to see all your tags in
my tags directory! :-)
Done.
2. All the old old-gcc tags should go in a subdirectory named "old-
gcc".
I'm no
Daniel Berlin wrote:
> Okay, well, consider this an official proposal to remove:
>
> 1. the tree-ssa branch *merge* tags (IE the ones used to merge trunk
> into tree-ssa, *not* the other way around
> 2. the ast-optimizer-branch merge tags
> 3. structure-aliasing-branch merge tags.
> 4. tree-clean
On Oct 30, 2005, at 10:56 AM, Paul Thomas wrote:
I will look forward to seeing it! The reason that I asked in the
first place is the responce to trying to update from trunk:
[EMAIL PROTECTED] gcc-svn]# svn up svn+ssh://[EMAIL PROTECTED]/svn/gcc/
trunk
svn: 'svn+ssh://[EMAIL PROTECTED]/svn/gc
On Sun, 2005-10-30 at 19:56 +0100, Paul Thomas wrote:
> Mike,
>
> >
> > When created, you will be able to find it with ls, and it will be called:
> >
> > branches/gcc-4_1-branch.
> >
> I will look forward to seeing it! The reason that I asked in the first
> place is the responce to trying to upda
Mike,
When created, you will be able to find it with ls, and it will be called:
branches/gcc-4_1-branch.
I will look forward to seeing it! The reason that I asked in the first
place is the responce to trying to update from trunk:
[EMAIL PROTECTED] gcc-svn]# svn up svn+ssh://[EMAIL PROTECTE
On Oct 29, 2005, at 10:19 PM, Paul Thomas wrote:
if mainline/head/gcc-4_1-branch is available from the svn repository.
When created, you will be able to find it with ls, and it will be
called:
branches/gcc-4_1-branch.
I'd like to think that we should rename all such tags, like so:
>
> Sorry abt that, my source is mcore-elf and these are the options I use
> to configure, followed by gmake and gmake install.
>
> ./im-alias-source/configure --srcdir=../im-alias-source/
> --target=mcore-elf --with-newlib --disable-threads --disable-multilib
> --disable-nls --prefix=/usr/loca
"Joseph S. Myers" <[EMAIL PROTECTED]> writes:
> The libc, make, gnumach and hurd tags are presumably mistakes - tags from
> other projects having been in the same repository
Some files (like config.{guess,gcc} and alloca.c) were once shared (via
symlinks) with various other repositories.
Andrea
Current I use:
svn export gcc-4_0-branch /tmp/gcc-4_0-branch
tar cfj gcc-4_0-branch-r105979.tar.bz2 -C /tmp gcc-4_0-branch
rm -f /tmp/gcc-4_0-branch
Is there a simplest way ?
On Sunday 30 October 2005 10:02, Daniel Berlin wrote:
> 1. the tree-ssa branch *merge* tags (IE the ones used to merge trunk
> into tree-ssa, *not* the other way around
> 2. the ast-optimizer-branch merge tags
> 4. tree-cleanup-branch merge tags
>
OK.
> along with any other mistaken tags (and branches).
>
> I think merge tags for active branches should be the responsibility of the
> branch maintainers to do as they wish with. Merge tags and branchpoint
> tags from branches that have been completely merged into mainline can
> probably go, su
On Sun, 29 Oct 2005, Ian Lance Taylor wrote:
> Daniel Berlin <[EMAIL PROTECTED]> writes:
>
> > 1. Apple tags should go in a subdirectory named "apple".
> >
> > (Whether you guys want to further subdivide your taggings, is your
> > business)
> >
> > Not to single apple out, i imagine anyone who
:ADDPATCH testsuite:
Attached patch fixes a bug (PR libfortran/22298) where the libgfortran
constructor function wasn't linked in when libgfortran was statically
linked. The patch itself is straightforward and well commented, and it
could go under the "obvious rule".
I added a test for the t
Hello,
Following to your response I tried to add -v but doesn't succsed , maybe I
locate
on the wrong place.
Please correct to following makefile exmple
-
ARCH = powerpc-eabi
CC = $(ARCH)-gcc
AS = $(ARCH)-as
LD = $
follow to your reswponse I try to add but foesn't sucsed
please correct the follwing Makefile exmple
ARCH = powerpc-eabi
CC = $(ARCH)-gcc
AS = $(ARCH)-as
LD = $(ARCH)-ld
CFLAGS = -std=gnu99 -mcpu=505 -fsingle-precision-constant -mmultiple -mstrin
50 matches
Mail list logo
