. These are more such
patterns that happen to have different names; it doesn't matter whether a
pattern's name starts *movsi or *frob.
--
Joseph S. Myers
[EMAIL PROTECTED]
On Thu, 20 Mar 2008, Bernd Schmidt wrote:
Joseph S. Myers wrote:
Yes. For SPE, the subregs used in these *frob_* patterns represent concepts
including the high-part of a register (only used by certain instructions
that treat registers as 64 bits) and a DImode value stored in one 64-bit
mailing list which is probably even more out of date and
may be missing many maintainers.
--
Joseph S. Myers
[EMAIL PROTECTED]
Following comments on these lists and from Renesas, the revised ABI we
will be implementing is now available. (Further changes may be made for
issues found in the course of implementation.)
http://www.codesourcery.com/public/docs/sh-fdpic/sh-fdpic-abi.txt
--
Joseph S. Myers
[EMAIL PROTECTED]
On Wed, 26 Mar 2008, Mark Mitchell wrote:
Joseph S. Myers wrote:
On Wed, 19 Mar 2008, qunying wrote:
Hi,
I have the impression that GCC 4.3.0 has updated to GPLv3. But
http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gcc/Copying.html still using
GPLv2.
Does it need to be updated
in the kernel.
--
Joseph S. Myers
[EMAIL PROTECTED]
/restoring wcgr
registers. You may need to temporarily modify GCC to save and restore
such registers in order to test the unwinding for them.
--
Joseph S. Myers
[EMAIL PROTECTED]
I am now testing a patch for this issue.
--
Joseph S. Myers
[EMAIL PROTECTED]
working
group on defining the ABI properly.
(Whatever you do, you may wish to consider how to define flags relating to
the ABI separately from those relating to code generation.)
--
Joseph S. Myers
[EMAIL PROTECTED]
will send the next report for the 4.2 branch when making the
4.2.4-rc1 release candidate.
--
Joseph S. Myers
[EMAIL PROTECTED]
.)
--
Joseph S. Myers
[EMAIL PROTECTED]
any
knowledge of these types unless specifically configured for a particular
target - that is, defaults.h should not contain any default definitions.
--
Joseph S. Myers
[EMAIL PROTECTED]
their own if you so
wish, that uses the macros.
__INT8_T__
I'd suggest __INT8_TYPE__ for consistency with the macros such as
__SIZE_TYPE__.
--
Joseph S. Myers
[EMAIL PROTECTED]
://gcc.gnu.org/ml/gcc/2008-04/msg00688.html
The next report for the 4.3 branch will be sent by Richard.
--
Joseph S. Myers
[EMAIL PROTECTED]
.
--
Joseph S. Myers
[EMAIL PROTECTED]
S. Myers
[EMAIL PROTECTED]
or comments about
this release. Instead, use the resources available from
http://gcc.gnu.org.
As always, a vast number of people contributed to this GCC release -- far
too many to thank individually!
--
Joseph S. Myers
[EMAIL PROTECTED]
of exporting
much more structured data from GCC, and GCC variants to do so - but
nothing much that so far looks likely to enter official GCC. A
complication is that an external protoize might still need -aux-info,
unless reimplemented to avoid needing this option.
--
Joseph S. Myers
[EMAIL
branch.
--
Joseph S. Myers
[EMAIL PROTECTED]
value we got was 165 - so someone
else can't just take over where SCO left off without SCO internal
information, or guessing and leaving a large gap and hoping there isn't
too much duplication.
--
Joseph S. Myers
[EMAIL PROTECTED]
the BID
code requires the functions (which uClibc does provide on x86, though not
on most targets). So either configure uClibc with UCLIBC_HAS_FENV
enabled, or configure GCC with --disable-decimal-float.
--
Joseph S. Myers
[EMAIL PROTECTED]
between
building the first and second compilers.
However, it may be easier to use existing scripts such as crosstool to
automate the process, provided you use those scripts with versions of the
tools they support.
--
Joseph S. Myers
[EMAIL PROTECTED]
-grained control of particular
-pedantic pedwarns.
--
Joseph S. Myers
[EMAIL PROTECTED]
-bit defaults (for which mode -march=i686 is invalid) unaffected.
--
Joseph S. Myers
[EMAIL PROTECTED]
On Tue, 10 Jun 2008, H.J. Lu wrote:
On Tue, Jun 10, 2008 at 02:27:17PM +0200, Paolo Carlini wrote:
Joseph S. Myers wrote:
I hold that it is a bug that i686-* tools default to -march=i386 instead
of -march=i686 (whereas e.g. sparcv9-* tools default to -mcpu=sparcv9, and
-mcpu means
targets or
other features for deprecation in 4.4.
--
Joseph S. Myers
[EMAIL PROTECTED]
On Sun, 15 Jun 2008, DJ Delorie wrote:
Joseph S. Myers [EMAIL PROTECTED] writes:
i[34567]86-*-coff*
DJGPP is ix86-coff - how would this deprecation affect djgpp?
I thought DJGPP was i[34567]86-pc-msdosdjgpp*. I do not think having
generic CPU-*-OBJFMT triplets that really refer
by some targets) remains while no target uses it, that's also a mistake
and it should be removed.
--
Joseph S. Myers
[EMAIL PROTECTED]
compiler. The versions chosen should of course go in
gcc/doc/install.texi on the branch.
--
Joseph S. Myers
[EMAIL PROTECTED]
++
infrastructure shared between any C++ host tools in GCC and src, but think
that would best be kept separate from libiberty. Much of libiberty could
probably do with being replaced by, or merged into, gnulib anyway.)
--
Joseph S. Myers
[EMAIL PROTECTED]
112 - 2
P32 +- 0
--- ---
Total 122 - 2
Previous Report
===
http://gcc.gnu.org/ml/gcc/2008-06/msg00321.html
The next report for the 4.3 branch will be sent by Richard.
--
Joseph S. Myers
[EMAIL
DejaGnu
itself has hardcoded knowledge about how to locate bits of GCC source and
build trees, some of it long obsolete. It's unfortunate that qmtest_gcc
has such logic as well, as needed when emulating the DejaGnu logic, but at
least QMTest and qmtc don't.)
--
Joseph S. Myers
[EMAIL
only.
--
Joseph S. Myers
[EMAIL PROTECTED]
). This might be a
trap representation.
The doc patch is OK. (I think is not allowed is misleading when
describing code that is compile-time valid but had undefined behavior if
executed, but feel free to put has undefined behavior in place of might
not work if you wish.)
--
Joseph S. Myers
[EMAIL
that it can be tracked?
An error is inappropriate; undefined behavior only occurs on execution of
the call to free, not on compilation of the program. A warning would be
fine (as would converting the call to free into an abort).
--
Joseph S. Myers
[EMAIL PROTECTED]
binary to do
the same preprocessing as it does when compiling; that is, it has the same
effect as gcc -E. The better consistency in predefined macros is
deliberate.
--
Joseph S. Myers
[EMAIL PROTECTED]
be worth standardising. This does
not of course mean that anyone will produce a concrete proposal to add
appropriate words to the standard, or that such a proposal will be
accepted for C1x.
--
Joseph S. Myers
[EMAIL PROTECTED]
target), though I haven't seen
recent figures for startup costs.
We have some existing practice for feature macros (__GNUC_GNU_INLINE__,
__GNUC_STDC_INLINE__, __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1, ...).
--
Joseph S. Myers
[EMAIL PROTECTED]
open with no plans for further releases. It should
probably be closed around the time the 4.4 branch is created in the
absence of a volunteer to maintain it and build releases beyond then.
Previous 4.1 status report:
http://gcc.gnu.org/ml/gcc/2007-05/msg00669.html
--
Joseph S. Myers
[EMAIL
to be fixed by 4.4?
I would hope to remove fixproto and all deprecated targets on trunk around
the time 4.4.0 is released. If the deprecation patch is approved, the
deprecated targets will require --enable-obsolete to build them, on trunk
and 4.4 branch once created, until removed.
--
Joseph S
On Sat, 12 Jul 2008, Gerald Pfeifer wrote:
Hi Joseph,
On Fri, 4 Jul 2008, Joseph S. Myers wrote:
The GCC 4.1 branch is now closed and should have no further commits. All
open bugs at the 4.1.3 milestone, or marked as [4.1/4.2/4.3/4.4
Regression] or similar, have been updated
(with consistency, I'd have expected cases
where my patch is relevant to have caused problems before the patch as
well). If there does turn out to be a target-independent patch relevant
to fixing the SH issue, it might be relevant to the m32c issue as well.
--
Joseph S. Myers
[EMAIL PROTECTED]
as reload knows they need reloading.
--
Joseph S. Myers
[EMAIL PROTECTED]
On Tue, 22 Jul 2008, Laurent GUERBY wrote:
What triggers the passing of -imultilib to a language driver?
The handling of the %I spec. -imultilib is a preprocessor option used to
get the fixed headers corresponding to a particular multilib.
--
Joseph S. Myers
[EMAIL PROTECTED]
for string functions (that e.g.
they don't access beyond the memory they are allowed to access at the end
of a page) would be a good idea as well, and doesn't have the problems
with changing licenses that reusing the functions themselves does.
--
Joseph S. Myers
[EMAIL PROTECTED]
like this.
--
Joseph S. Myers
[EMAIL PROTECTED]
have the 32-bit-default as
the only or the normal target, e.g. Solaris and Darwin.)
--
Joseph S. Myers
[EMAIL PROTECTED]
program (on a possibly remote,
simulator, etc. target), rather than fork/exec. (For experimenting with
different approaches, assessing the current state of the compiler, etc.,
this isn't needed so much.)
--
Joseph S. Myers
[EMAIL PROTECTED]
.
--
Joseph S. Myers
[EMAIL PROTECTED]
are applied; even
for VLAs sizeof will be lowered at gimplification at the very latest.
Saving memory for malloc would require the compiler to analyse how the
malloced memory is used and deduce that a smaller value could be passed to
malloc.
--
Joseph S. Myers
[EMAIL PROTECTED]
Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
On Aug 3, 2008, at 11:23 AM, Joseph S. Myers [EMAIL PROTECTED]
wrote:
On Sat, 2 Aug 2008, Sebastian Pop wrote:
Hi,
The graphite branch has been tuplified and the port to PPL passes the
graphite testsuite. For building
to bit-rot
so we need to be quite careful when adding them, balancing the risks of
bit-rot and the costs of additional build dependencies, together with how
advantageous the option would be likely to be in -On.
--
Joseph S. Myers
[EMAIL PROTECTED]
On Mon, 4 Aug 2008, Ralf Wildenhues wrote:
* Joseph S. Myers wrote on Sun, Aug 03, 2008 at 10:00:38PM CEST:
(But the configure code also
shouldn't allow configuring with a GPLv2 version of polylib.)
Why? Use is not forbidden by incompatible free software licenses here,
only
hosts) on trunk rather than on gxx-in-cxx for now. Though it would
need to allow any later version, not just 2 and 3, to be ready for future
GCC versions moving to GPL 4-or-later.
--
Joseph S. Myers
[EMAIL PROTECTED]
multilib options (passed after
the options specific to the tests) disable NEON. Or if the combination is
simply incompatible, possibly the compiler should be giving an error for
it.
--
Joseph S. Myers
[EMAIL PROTECTED]
effectively enabled then the preprocessor macro should not be defined.
--
Joseph S. Myers
[EMAIL PROTECTED]
neon with incompatible CPUs, or accept the instructions. If it gives an
error, the compiler should not pass the .fpu neon, and not define
__ARM_NEON__, and possibly give an error itself.
--
Joseph S. Myers
[EMAIL PROTECTED]
complex expressions to be
better supported in diagnostics.
--
Joseph S. Myers
[EMAIL PROTECTED]
-name:lineno-1.column-1-lineno-2.column-2: message
source-file-name:lineno-1.column-1-column-2: message
source-file-name:lineno-1-lineno-2: message
--
Joseph S. Myers
[EMAIL PROTECTED]
.)
--
Joseph S. Myers
[EMAIL PROTECTED]
option, users liking it should find their makefiles work the same
everywhere and users not liking it can add the opposite option.
--
Joseph S. Myers
[EMAIL PROTECTED]
On Thu, 14 Aug 2008, Manuel López-Ibáñez wrote:
2008/8/14 Joseph S. Myers [EMAIL PROTECTED]:
But in any case the default should be the default with no configure
option, users liking it should find their makefiles work the same
everywhere and users not liking it can add the opposite
On Thu, 14 Aug 2008, Robert Dewar wrote:
Manuel López-Ibáñez wrote:
2008/8/14 Joseph S. Myers [EMAIL PROTECTED]:
But in any case the default should be the default with no configure
option, users liking it should find their makefiles work the same
everywhere and users not liking it can
in suitable shape for
i18n) and might have issues with using the same Ada sources with different
compiler back end versions.
--
Joseph S. Myers
[EMAIL PROTECTED]
. It will also help root out
the non-GCS-complaint tools ;)
I think making this different in development would be a mistake. It's not
like --enable-checking; it's something user-visible.
--
Joseph S. Myers
[EMAIL PROTECTED]
.
And thereby allows a post-processor to add caret diagnostics to the output
of any GCS-conforming program, or an IDE or editor to show the locations
of errors from such a program, not just GCC, for example.
--
Joseph S. Myers
[EMAIL PROTECTED]
diagnostic
messages, without needing major and incompatible stylistic changes.
--
Joseph S. Myers
[EMAIL PROTECTED]
of it.
--
Joseph S. Myers
[EMAIL PROTECTED]
the non-preprocessed source.
Indexes into a table of tokens would be one possibility; C++ already
creates such a table in the course of lexing the whole input up front.
--
Joseph S. Myers
[EMAIL PROTECTED]
--
Joseph S. Myers
[EMAIL PROTECTED]
On Sat, 16 Aug 2008, Cristi Magherusan wrote:
Hello,
It seems that gcc-4.3.1 has limits.h in the include-fixed directory,
instead of the include one.
This breaks uclibc compilation.
What could be done to fix this?
Use uClibc trunk revision 22067 or later.
--
Joseph S. Myers
[EMAIL
===
http://gcc.gnu.org/ml/gcc/2008-08/msg00132.html
I will send the next report for the 4.3 branch at the time of the
4.3.2 release or -rc2.
--
Joseph S. Myers
[EMAIL PROTECTED]
fixes for regressions from 4.2 and
earlier releases can go in 4.3.3 and later 4.3 releases, or in 4.3.2 if
they are ready on time and seem safe enough considering the severity of
the regression.
--
Joseph S. Myers
[EMAIL PROTECTED]
implementation could be used. Similarly, any other case
where there are threads but no native atomic operations can have helpers
provided in libgcc or libc using kernel support, and the libstdc++
configure test can be made to allow for this case.
--
Joseph S. Myers
[EMAIL PROTECTED]
.
--
Joseph S. Myers
[EMAIL PROTECTED]
. (If you configure
glibc for i686-linux-gnu, it will use assembly sources that require i686.)
--
Joseph S. Myers
[EMAIL PROTECTED]
a perfectly good thing to
want to do) then it should apply to all x86 targets equally. If that's
My proposal is exactly that the target triplet should imply -march on x86
- just as it implies -mcpu on SPARC where -mcpu means -march rather than
-mtune.
--
Joseph S. Myers
[EMAIL PROTECTED]
+ 6
P34 - 3
--- ---
Total 126 + 3
Previous Report
===
http://gcc.gnu.org/ml/gcc/2008-08/msg00289.html
The next report for the 4.3 branch will be sent by Richard.
--
Joseph S. Myers
[EMAIL PROTECTED]
results for
that port are not already being posted reasonably frequently.
The following targets are currently unconverted:
arc
cris
crx
fr30
frv
h8300
iq2000
m32c
m32r
m68hc11
m68k
mcore
mips
mmix
pa
pdp11
score
stormy16
v850
vax
xtensa
--
Joseph S. Myers
[EMAIL PROTECTED]
or comments about
this release. Instead, use the resources available from
http://gcc.gnu.org.
As always, a vast number of people contributed to this GCC release -- far
too many to thank individually!
--
Joseph S. Myers
[EMAIL PROTECTED]
name of the uploaded
file, which I could not decipher as relating to any problem I could find
in the files I uploaded.
--
Joseph S. Myers
[EMAIL PROTECTED]
this last part is missing or buggy.
--
Joseph S. Myers
[EMAIL PROTECTED]
-bugzilla.
--
Joseph S. Myers
[EMAIL PROTECTED]
regression.
Previous Report
===
http://gcc.gnu.org/ml/gcc/2008-09/msg00013.html
The next report for 4.4.0 will be sent by Mark.
--
Joseph S. Myers
[EMAIL PROTECTED]
in 4.3.0 (see
This is PR 36690 which has various bits of analysis.
--
Joseph S. Myers
[EMAIL PROTECTED]
out there is
a significant performance cost to the default -ftrapping-math mode and we
will need to consider whether the option can be split up so parts can be
disabled selectively.
--
Joseph S. Myers
[EMAIL PROTECTED]
install headers and the library for external plugin
projects to use?
Somewhere under libsubdir. The configure macros provided for the use of
plugins can take care of the plugins finding them.
--
Joseph S. Myers
[EMAIL PROTECTED]
of generating the same code for a
target independent of host.
--
Joseph S. Myers
[EMAIL PROTECTED]
or disabled on Alpha by default.
--
Joseph S. Myers
[EMAIL PROTECTED]
and anything else
likely to affect compatibility) and for --version and --help information
so people can use those options together with -fplugin to get the
plugin's version number and bug-reporting information, as previously
discussed.
--
Joseph S. Myers
[EMAIL PROTECTED]
, the more complicated the bootstrap
procedure becomes.
--
Joseph S. Myers
[EMAIL PROTECTED]
IRA_COVER_CLASSES and removing them
from the deprecation list) and remove them after 4.4 branches: only the
old allocator would be removed from trunk right now, not the ports
themselves.
--
Joseph S. Myers
[EMAIL PROTECTED]
configure checks changing only to update to new
bug-fix minor releases, not major feature releases, while in Stage 3.
--
Joseph S. Myers
[EMAIL PROTECTED]
On Mon, 27 Oct 2008, Richard Guenther wrote:
On Mon, Oct 27, 2008 at 1:22 PM, Joseph S. Myers
[EMAIL PROTECTED] wrote:
On Sun, 26 Oct 2008, David Edelsohn wrote:
Graphite's CLooG and PPL libraries use libgmpxx. Because cc1 is not linked
by g++, this effectively requires that libgmpxx
their changes (dumping extensively
modified sources instead of contributing individual logical patches and
discussing them with the community as needed to get them merged), but the
aim should still be to end up with one set of manual sources for all uses.
--
Joseph S. Myers
[EMAIL PROTECTED]
differences would hopefully be provided with GCC for people to copy into
their plugins.)
--
Joseph S. Myers
[EMAIL PROTECTED]
On Fri, 14 Nov 2008, Brian Dessent wrote:
Joseph S. Myers wrote:
As I understand it, there is an alternative - put all the shared code in a
DLL on Windows if configuring with plugins enabled, and link both the
plugins and cc1, cc1plus etc. with that DLL. If people wish to enable
wording allowing such
compound literals not to designate distinct objects, but each recursive
copy of a named variable with automatic storage duration must be a
distinct object where this can be detected (e.g. through the address being
taken, as here).
--
Joseph S. Myers
[EMAIL PROTECTED]
of changing to use
functions with explicit location parameters) invalidating the
translations. I plan to regenerate the .pot files and submit the next
trunk snapshot to the TP; after that, we should avoid bulk changes to
translated strings until after 4.4 branches.
--
Joseph S. Myers
[EMAIL
for occasionally reviewing bugs to see
if they are still applicable to current trunk.
Previous Report
===
http://gcc.gnu.org/ml/gcc/2008-11/msg00187.html
The next report for 4.4.0 will be sent by Mark.
--
Joseph S. Myers
[EMAIL PROTECTED]
401 - 500 of 2701 matches
Mail list logo
