On 7/11/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
On 7/11/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
>
> Summary
> ---
>
> The next scheduled GCC 4.2.x release is GCC 4.2.1 on July 13th.
>
> As of 5PM PDT tomorrow, please consider the 4.2 branch closed to all
> changes. If you have outs
Jan Hubicka wrote on 11.07.2007 02:02:13:
> > >
> > > I am on that tricky thing ;) I think I need in i386.c an global
variable
> > > "ix86_amd64_abi" which helds the the current function abi. This
> means also
> > > that I have to use instead of TARGET_64BIT_MS_ABI this variable.This
var
>
>
> I thank you very much for your great help. Currently I am stucked on
> x86_function_value_regno_p (macro FUNCTION_VALUE_REGNO_P). It is not clear
> what's to do here for the FIRST_FLOAT_REG case. Maybe I could use the
> ms_abi variant for sysv_abi as default too. But I think, it breaks 87 f
Ian Lance Taylor wrote:
Sandra Loosemore <[EMAIL PROTECTED]> writes:
The error reported here
http://gcc.gnu.org/ml/gcc/2007-07/msg00339.html
is also happening when building for target mipsisa32r2-elfoabi on
i686-pc-linux-gnu.
This should be fixed by revision 126536. Sorry for the problems
Paolo Carlini <[EMAIL PROTECTED]> writes:
| Michael Veksler wrote:
|
| > What do you think?
|
| I think that the "current" solution is very, very old, and "heaven"
| knows how many others didn't work at the time on some "exotic"
| platforms. I would suggest filing a PR and CCing Benjamin.
The "
Sandra Loosemore <[EMAIL PROTECTED]> writes:
> I'm now at revision 126547, and am getting a different ICE when
> building the same configuration:
> /scratch/sandra/mips32-mainline/src/gcc-mainline/libstdc++-v3/src/locale.cc:
> In member function 'std::string std::locale::name() const':
> /scratch
Jan Hubicka wrote on 11.07.2007 14:01:54:
> >
> > I thank you very much for your great help. Currently I am stucked on
> > x86_function_value_regno_p (macro FUNCTION_VALUE_REGNO_P). It is not
clear
> > what's to do here for the FIRST_FLOAT_REG case. Maybe I could use the
> > ms_abi variant fo
> Jan Hubicka wrote on 11.07.2007 14:01:54:
>
> > >
> > > I thank you very much for your great help. Currently I am stucked on
> > > x86_function_value_regno_p (macro FUNCTION_VALUE_REGNO_P). It is not
> clear
> > > what's to do here for the FIRST_FLOAT_REG case. Maybe I could use the
> > > m
hello,
The example provided with the -fstrict-overflow description in the
http://gcc.gnu.org/gcc-4.2/changes.html page doesn't optimize as described.
Is it only a documentation bug ? The example is optimized as expected on
the trunk.
Regards,
-c
The "current" situation was "the best" compromise we arrived at in the
very old days of GCC-3.x.x -- see the archive for discussions.
Indeed. I would resist change just for change's sake, especially when
we have not seen a detailed bug report filed.
I'd suspect that nowadays we have better way
Christian BRUEL <[EMAIL PROTECTED]> writes:
> The example provided with the -fstrict-overflow description in the
> http://gcc.gnu.org/gcc-4.2/changes.html page doesn't optimize as
> described.
>
> Is it only a documentation bug ? The example is optimized as expected
> on the trunk.
I only said t
On Tue, 2007-07-10 at 10:35 +0100, Ying Yi wrote:
> Thanks very much for your email. Will gcc add the optimization support
> in the future (method 1)? For method 2, if abs accept short/char, may
> I give the function names as sabs and qabs? Gcc does already have cabs
> as complex abs, doesn't
On Tue, Jul 10, 2007 at 10:35:01AM +0100, Ying Yi wrote:
> Hi Jim,
> >To get your special char/short abs instructions, we need one of two things
> >1) Optimization support to recognize a sign-extend followed by an abs,
> >where the target has an abs instruction that operates on the
> >pre-extended
I am pleased to announce that the GCC Steering Committee has
appointed Andreas Krebbel as s390 port co-maintainer.
Please join me in congratulating Andreas on his new role.
Andreas, please update your listing in the MAINTAINERS file.
Happy hacking!
David
"Benjamin Kosnik" <[EMAIL PROTECTED]> writes:
| I've been waiting to revisit this issue until we have correct
| alignment support for template objects (std::aligned_storage, etc.)
| in g++. Then, we can use array_allocator to deal with this stuff in a
| much more transparent and C++ friendly way.
This is i686-pc-cygwin.
The error is that tzp is unknown in system_clock.c.
Here is the output from make
___
make[3]: Entering directory `/home/bobby/gcc/o/i686-pc-cygwin/libgfortr
The test gcc.c-torture/execute/align-3.c is failing on most of my
platforms, including IA64 HP-UX and Linux. The test consists of:
void func(void) __attribute__((aligned(256)));
void func(void)
{
}
int main()
{
if (((long)func & 0xFF) != 0)
abort ();
if (__alignof__(f
On 11/07/2007, at 4:48 PM, Steve Ellcey wrote:
The test gcc.c-torture/execute/align-3.c is failing on most of my
platforms, including IA64 HP-UX and Linux. The test consists of:
void func(void) __attribute__((aligned(256)));
void func(void)
{
}
int main()
{
if (((long)func & 0xFF)
By the way, I am seeing the same failure on AIX. The test is
broken for platforms with function descriptors
David
>On 7/10/07, [EMAIL PROTECTED] writes:
>>On 7/10/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>You haven't explained what advantages CIL's IR has over GIMPLE.
>>I thought it was well explained on page:
>>_http://hal.cs.berkeley.edu/cil/cil001.html_
(http://hal.cs.berkeley.edu/cil/cil00
The GCC SC is still discussing a few of the finer points of the
transition to GPLv3.
However, here are the things that have now been decided:
1. The compiler proper (e.g., files used only in cc1, cc1plus, the
driver, etc.) should all be converted to GPLv3 ASAP.
Will someone (or someones) please
21 matches
Mail list logo
