To whom it may concern:
I'm writing to let you know that the GCC Bugzilla appears to be
misconfigured such that it sends the following MAIL FROM line:
MAIL FROM:<"bugzilla-admin-daemon\n"@sourceware.org>
where the "\n" is a literal newline character (ASCII 10). This violates
RFC 2821 section 4.
Thank you Ian Lance Taylor. Your reply helps me a lot :)
Ling Kun
On Tue, May 25, 2010 at 1:10 PM, Ian Lance Taylor wrote:
> Ling Kun writes:
>
>> when deeply looking into the libgcc.a of
>> mips64el-unknown-linux-gnu-gcc-4.4.3, I found a object file
>> _udivdi3.o. but when objdump this obje
Ling Kun writes:
> when deeply looking into the libgcc.a of
> mips64el-unknown-linux-gnu-gcc-4.4.3, I found a object file
> _udivdi3.o. but when objdump this object file, no entry for function
> _udivdi3 is found, only a __udivti3 function entry, and there are also
> some other *di3.o file whi
Philip Pemberton writes:
> 1) Who's the current maintainer for the lm32 port? Jon Beniston?
> I can't see anything on the gcc website that says definitively "target
> X is maintained by $PERSON", and I really don't want to step on
> his/her toes and start a flame war, turf war or any other kind o
Hi all,
when deeply looking into the libgcc.a of
mips64el-unknown-linux-gnu-gcc-4.4.3, I found a object file
_udivdi3.o. but when objdump this object file, no entry for function
_udivdi3 is found, only a __udivti3 function entry, and there are also
some other *di3.o file which only *ti3 can f
Hi guys,
About a month ago I opened a bug on Bugzilla:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43805
This relates to gcc crashing out with an Internal Compiler Error when
doing a build of Linux kernel 2.6.34-rc4. Basically, as soon as the
build hits fs/timerfd.c, an ICE is thrown:
fs/ti
I am pleased to announce that the GCC Steering Committee has
appointed Sterling Augustine as maintainer of the Xtensa port.
Please join me in congratulating Sterling on his new role.
Sterling, please update your listing in the MAINTAINERS file.
Happy hacking!
David
On Mon, 24 May 2010, Mark Mitchell wrote:
> As to whether this is a better choice than working on GIMPLE back-ends,
> I think that's unclear. There's no question that a GIMPLE back-end
> would be prettier. I think it's a question of what your goals are. If
I don't think of the two as being mut
Steven Bosscher wrote:
> The GIMPLE tuples work took man-years (note: plural). There was less
> code to convert and the process of conversion was easier, relatively,
> than the conversion of RTL would be. So your one person-year seems
> grossly underestimated.
I dunno. To get good project estima
On 5/24/10, Mark Mitchell wrote:
> > Certainly removing support for FPA (and any targets that require it) as
> > a first step would be an option; but we should also focus on where we
> > want to get to.
>
> I agree with that. But, it would also be interesting to know just how
> broken that c
On Sun, 23 May 2010, Kai Wang wrote:
>> Based on this, it will be great if you can apply your patch to
>> -CURRENT, 8-STABLE and 7-STABLE.
> I'll see what I can do.
Thanks!
> The elf_update() failure is caused by an alignment check inside
> FreeBSD elf_update(). [...]
> Anyway, I attached a patc
On Mon, May 24, 2010 at 6:20 PM, Mark Mitchell wrote:
> Joseph S. Myers wrote:
>
>>> All in all, perhaps not the most efficient representation for memory
>>> foot print, and the pointer chasing probably doesn't help (cache!).
>>> But changing it is a lot more difficult than the GIMPLE tuples
>>> p
On Mon, 24 May 2010, James Miller wrote:
> We have raised a new GCC mirror at http://gcc.parentinginformed.com.
> The mirror is located in Canada and I am the contact point for it.
Thanks for setting up a mirror and letting us now. I just added this
to our mirrors list at http://gcc.gnu.org/mirro
Jeff Kuskin writes:
> I'm trying to remove *all* single-letter constraints from my cpu.md
> file and replace them with define_constraint entries that define
> *multi-letter* constraint names. Example: (define_constraint "aFOO"
> ...)
> Am I *required* to define at least some of the single-lett
Dear Sir/Madam,
We have raised a new GCC mirror at http://gcc.parentinginformed.com.
The mirror is located in Canada and I am the contact point for it.
Thank you.
Best wishes,
James Miller
On Mon, 24 May 2010, FX wrote:
>1. assume that the user has compiled compile separately a quad-prec
> math library (says libmathq; possible relying on MPFR, as the
> implementation I propose) and arrange specs so that an option triggers
> linking to it
>2. assume that the user has an MP
I've got a local port of GCC 4.5.0 to an in-house CPU.
I'm trying to remove *all* single-letter constraints from my cpu.md file and
replace them with define_constraint entries that define *multi-letter*
constraint names. Example: (define_constraint "aFOO" ...)
But I've found that when I remov
Joseph S. Myers wrote:
>> All in all, perhaps not the most efficient representation for memory
>> foot print, and the pointer chasing probably doesn't help (cache!).
>> But changing it is a lot more difficult than the GIMPLE tuples
>> project. I don't think it can be done.
>
> I don't see any rea
Jeff Law wrote:
On 05/24/10 05:46, Hariharan wrote:
Hello all,
I found something a little odd with delay slot scheduling. If i had
the following bit of code (Note that "get" builtin functions in
picochip stand for port communication)
int mytest ()
{
int a[5];
int i;
for (i = 0; i < 5; i
> int mytest ()
> {
> int a[5];
> int i;
> for (i = 0; i < 5; i++)
> {
> a[i] = (int) getctrlIn();
> }
> switch (a[3])
> {
> case 0:
> return 4;
> default:
> return 13;
> }
> }
>
> The relevant bit of assembly for this compiled at -Os is
>
> _L2:
>
On Mon, May 24, 2010 at 08:14:13AM -0600, Jeff Law wrote:
> From a correctness standpoint, the uninitialized value will never be
> used, so it should cause no ill effects on your code. The biggest
> effect would be tools like valgrind & purify (if supported on your
> architecture) would repo
On 05/24/10 05:46, Hariharan wrote:
Hello all,
I found something a little odd with delay slot scheduling. If i had
the following bit of code (Note that "get" builtin functions in
picochip stand for port communication)
int mytest ()
{
int a[5];
int i;
for (i = 0; i < 5; i++)
{
a[i] = (i
Richard Earnshaw wrote:
> Don't know. Does a document specifying it even exist? If we are
> supporting an ABI, then I think we need to have a publicly available
> SPEC.
I disagree with that statement. If a system is sufficiently popular, we
probably want to support it -- with or without a spec
> What's different is that there is a well-maintained arm-eabi port. The
> arm-elf port and all its legacy just gets in the way.
>
> The vax back-end only affects VAX; likewise for the PDP11 port.
I think that's a critical distinction. I can't see removing a port
just because it's not used much
On Mon, 2010-05-24 at 06:40 -0500, Joel Sherrill wrote:
> The question we would like answered is what impact this
> has on our code base. What changes will we have to
> make to accomodate this? Register usage changes, stack
> frame changes, etc.
By far the biggest change is to the layout of 64-
On Mon, 2010-05-24 at 11:33 +, Joseph S. Myers wrote:
> (I've CC:ed the listed GCC maintainers for various OS ports whose ARM
> configurations in GCC do not appear to be using EABI, as well as Pedro for
> WinCE, given the discussions of deprecation.) Deprecations are generally
> a matter f
On Mon, 24 May 2010, Joel Sherrill wrote:
> The question we would like answered is what impact this
> has on our code base. What changes will we have to
> make to accomodate this? Register usage changes, stack
> frame changes, etc.
For ARM Linux, one change was dealing with __arm__ conditionals
Hello all,
I found something a little odd with delay slot scheduling. If i had the
following bit of code (Note that "get" builtin functions in picochip
stand for port communication)
int mytest ()
{
int a[5];
int i;
for (i = 0; i < 5; i++)
{
a[i] = (int) getctrlIn();
}
switch (a[3])
{
On Mon, May 24, 2010 at 1:50 AM, FX wrote:
>> The current trunk does require flex.
>> The build dies pretty quickly unless flex is available.
>>
>
>
> Was the flex dependency recently reintroduced? It used to be that if you
> update trunk with contrib/gcc_update (instead of svn up), it sets the
>
On Mon, May 24, 2010 at 4:52 AM, Steve Kargl
wrote:
> Kai,
>
> I tested your patch posted here:
>
> http://gcc.gnu.org/ml/gcc/2010-05/msg00445.html
>
> to address the issue
>
> % cat x.c
> int main() { }
> % gccvs -flto x.c
> % gccvs -fwhopr x.c
> lto1: fatal error: elf_update() failed:
On 05/24/2010 06:33 AM, Joseph S. Myers wrote:
(I've CC:ed the listed GCC maintainers for various OS ports whose ARM
configurations in GCC do not appear to be using EABI, as well as Pedro for
WinCE, given the discussions of deprecation.) Deprecations are generally
a matter for the relevant maint
On Mon, 24 May 2010, Steven Bosscher wrote:
> > The vax back-end only affects VAX; likewise for the PDP11 port.
>
> ...all this legacy just gets in the way of gcc as a whole. So I still
> don't see the difference.
>
> Nb, I don't oppose deprecating any arm stuff, but I just would like to
> know
(I've CC:ed the listed GCC maintainers for various OS ports whose ARM
configurations in GCC do not appear to be using EABI, as well as Pedro for
WinCE, given the discussions of deprecation.) Deprecations are generally
a matter for the relevant maintainers, which in this case means target
maint
The release of GNU MPFR 3.0.0 ("boudin aux pommes") is imminent.
Please help to make this major release as good as possible by
downloading and testing this release candidate:
http://www.mpfr.org/mpfr-3.0.0/mpfr-3.0.0-rc1.tar.xz
http://www.mpfr.org/mpfr-3.0.0/mpfr-3.0.0-rc1.tar.bz2
http://www.mpfr.
2010/5/24 FX :
> Dear gfortranners,
>
> For some work-related issue, I find the need to switch my code regularly
> between double precision real arithmetics and quad-float. I currently do that
> with a proprietary compiler whose brand name matches the regexp
> "^In{1,}[t]\x65l$", but I'd be even
On Mon, 2010-05-24 at 12:42 +0200, Steven Bosscher wrote:
> On 5/24/10, Richard Earnshaw wrote:
> >
> > On Sun, 2010-05-23 at 23:15 +0200, Steven Bosscher wrote:
> >> On Sun, May 23, 2010 at 10:27 PM, Mark Mitchell
> >> wrote:
> >> > Martin Guy wrote:
> >> >
> >> >> Dropping FPA support from GCC
On 5/24/10, Richard Earnshaw wrote:
>
> On Sun, 2010-05-23 at 23:15 +0200, Steven Bosscher wrote:
>> On Sun, May 23, 2010 at 10:27 PM, Mark Mitchell
>> wrote:
>> > Martin Guy wrote:
>> >
>> >> Dropping FPA support from GCC effectively makes the OABI unusable, and
>> >> often we are forced to use
On Sun, 2010-05-23 at 23:15 +0200, Steven Bosscher wrote:
> On Sun, May 23, 2010 at 10:27 PM, Mark Mitchell wrote:
> > Martin Guy wrote:
> >
> >> Dropping FPA support from GCC effectively makes the OABI unusable, and
> >> often we are forced to use that by the environment supplied to us. Are
> >>
On Sun, 2010-05-23 at 05:11 +0100, Martin Guy wrote:
> On 5/11/10, Mark Mitchell wrote:
> > Richard Earnshaw wrote:
> >
> > > Speaking of which, we should probably formally deprecate the old arm-elf
> > > derived targets in 4.6 so that we can remove them in 4.7.
> >
> > > Similarly, we should
39 matches
Mail list logo
