On 3/24/07, Dorit Nuzman <[EMAIL PROTECTED]> wrote:
the problem is that for the case of BIT_FIELD_REF fold_ternary folds only
if operand 0 is VECTOR_CST. In our case it's a CONSTRUCTOR. I'm testing the
patch below (comments?).
This patch looks correct, by the way this was caused by my patch to
Robert Dewar wrote:
Ian Lance Taylor wrote:
The new option -fstrict-overflow tells gcc that it can assume the
strict signed overflow semantics prescribed by the language standard.
This option is enabled by default at -O2 and higher. Using
-fno-strict-overflow will tell gcc that it can not assum
> One advantage of most computer languages (with the arguable exception of
> C, but even it has preprocessor macros) is that they provide high-level
> constructs that make it easier to write programs.
Constructors and destructors are quite simple functions which are
executed at particular time.
Hello All,
I am looking for anyone who is interested to develop GCC compiler
support for Freescale (ex-Motorola) 8-bit microcontrollers family
(68HC08).
Thanks in advance,
Vadim
On 3/15/07, Steven Bosscher <[EMAIL PROTECTED]> wrote:
On 3/15/07, Uros Bizjak <[EMAIL PROTECTED]> wrote:
> The testcase is:
>
> double x;
> q()
> {
> x=x<5?5:x;
> }
>
> compile this with -O2 -msse2 -mfpmath=sse, and this testcase should
> compile to maxsd.
This happens because a "fallthrough
Robert Dewar <[EMAIL PROTECTED]> writes:
> Ian Lance Taylor wrote:
>
> > The new option -fstrict-overflow tells gcc that it can assume the
> > strict signed overflow semantics prescribed by the language standard.
> > This option is enabled by default at -O2 and higher. Using
> > -fno-strict-over
I added this TODO about a year ago, because at that point I wasn't
completely sure if this particular check was needed or not. It still
looks like a no-op to me -- the only things that affect the "offset"
variable are that it's set to zero some dozen lines above the patch
region, and of course
The following change broke --disable-multilib:
2007-03-23 Michael Meissner <[EMAIL PROTECTED]>
H.J. Lu <[EMAIL PROTECTED]>
../src/configure --enable-languages=c --disable-multilib x86_64-linux-gnu
/home/tbm/build/gcc-snapshot-20070324/build/./gcc/xgcc
-B/home/t
* Martin Michlmayr <[EMAIL PROTECTED]> [2007-03-24 19:01]:
> The following change broke --disable-multilib:
Actually, it also fails without that option.
--
Martin Michlmayr
http://www.cyrius.com/
I know. I will post a patch very soon.
H.J.
[EMAIL PROTECTED]
>-Original Message-
>From: Martin Michlmayr [mailto:[EMAIL PROTECTED]
>Sent: Saturday, March 24, 2007 12:03 PM
>To: Michael Meissner; Lu, Hongjiu
>Cc: gcc@gcc.gnu.org
>Subject: Re: --disable-multilib broken on x86_64
>
>* Marti
Ian Lance Taylor wrote:
You're right, I shouldn't have said "implementation defined."
What will happen with -fno-strict-overflow is whatever the processor
ISA happens to do when a signed arithmetic operation overflows. For
ordinary machines it will just wrap.
Given that all ordinary machines
I can't duplicate the problem. It works fine for me.
H.J.
[EMAIL PROTECTED]
>-Original Message-
>From: Martin Michlmayr [mailto:[EMAIL PROTECTED]
>Sent: Saturday, March 24, 2007 12:03 PM
>To: Michael Meissner; Lu, Hongjiu
>Cc: gcc@gcc.gnu.org
>Subject: Re: --disable-multilib broken on x86
* Lu, Hongjiu <[EMAIL PROTECTED]> [2007-03-24 12:27]:
> I can't duplicate the problem. It works fine for me.
I put the complete log at
http://people.debian.org/~tbm/logs/gcc-bootstrap.bz2 in case that
helps.
--
Martin Michlmayr
http://www.cyrius.com/
Hello,
I mess around with a lot of generated code. That means I do automated
construction of libraries that use literal strings. In order to
reduce address fixups, I often put all the literal strings into one long
string with each piece separated from the others with a NUL byte.
Unfortunately, I
Do you have any local changes? Does it work on Debian/i686?
H.J.
[EMAIL PROTECTED]
>-Original Message-
>From: Martin Michlmayr [mailto:[EMAIL PROTECTED]
>Sent: Saturday, March 24, 2007 1:10 PM
>To: Lu, Hongjiu
>Cc: Michael Meissner; gcc@gcc.gnu.org
>Subject: Re: --disable-multilib broken
On Sat, Mar 24, 2007 at 12:27:32PM -0700, Lu, Hongjiu wrote:
> I can't duplicate the problem. It works fine for me.
>
> H.J.
> [EMAIL PROTECTED]
>
> >-Original Message-
> >From: Martin Michlmayr [mailto:[EMAIL PROTECTED]
> >Sent: Saturday, March 24, 2007 12:03 PM
> >To: Michael Meissner;
* Lu, Hongjiu <[EMAIL PROTECTED]> [2007-03-24 13:22]:
> Do you have any local changes? Does it work on Debian/i686?
I get the failure without any local patches applied. I don't know
about i686 but it works on ia64.
--
Martin Michlmayr
http://www.cyrius.com/
Do you have
enable_decimal_float = no
in your gcc/Makefile?
H.J.
[EMAIL PROTECTED]
>-Original Message-
>From: Martin Michlmayr [mailto:[EMAIL PROTECTED]
>Sent: Saturday, March 24, 2007 1:31 PM
>To: Lu, Hongjiu
>Cc: Michael Meissner; gcc@gcc.gnu.org
>Subject: Re: --disable-multilib broke
* Lu, Hongjiu <[EMAIL PROTECTED]> [2007-03-24 13:22]:
> Do you have any local changes? Does it work on Debian/i686?
I noticed that my build does: -I../../../src/libgcc/../libdecnumber/no
which obviously cannot work. I'm not quite sure why it's "no" though.
During configure I see
checking for dec
* Lu, Hongjiu <[EMAIL PROTECTED]> [2007-03-24 14:00]:
> Do you have
> enable_decimal_float = no
> in your gcc/Makefile?
No, gcc/Makefile says enable_decimal_float = bid
gcc/Makefile:enable_decimal_float = bid
libdecnumber/Makefile:enable_decimal_float= dpd
x86_64-linux-gnu/libgcc/Makefile:enable_
* Martin Michlmayr <[EMAIL PROTECTED]> [2007-03-24 21:04]:
> So where does enable_decimal_float = no come from? config.* doesn't
> say anyhing.
Sorry, I meant: "config.* in x86_64-linux-gnu/libgcc doesn't..."
> It checks whether decimal floating point is supported, but there's
> nothing about en
enable_decimal_float should be the same for all Makefiles. I have:
[EMAIL PROTECTED] build-x86_64-linux]$ find -name Makefile | xargs egrep
"enable_decimal_float[ \t]*="
./stage1-libdecnumber/Makefile:enable_decimal_float= bid
./x86_64-unknown-linux-gnu/libgcc/Makefile:enable_decimal_float = bid
.
* Lu, Hongjiu <[EMAIL PROTECTED]> [2007-03-24 14:11]:
> You need to find out why yours are different.
The reason is that I configure for the target x86_64-linux-gnu while
you check for x86_64*-*-linux* (which doesn't match). This means that
- libdecnumber: sets "dpd"
- gcc: sets "bid" (the matc
* Martin Michlmayr <[EMAIL PROTECTED]> [2007-03-24 22:25]:
> This can be fixed by making sure the canonical target is used in
> configure.ac so the check for the target will actually work, as below.
> OK to commit?
Actually, I should mention that I haven't fully bootstrapped GCC with
this change (
On Sat, Mar 24, 2007 at 11:04:12PM +, Martin Michlmayr wrote:
> * Martin Michlmayr <[EMAIL PROTECTED]> [2007-03-24 22:25]:
> > This can be fixed by making sure the canonical target is used in
> > configure.ac so the check for the target will actually work, as below.
> > OK to commit?
>
> Actua
Several alternatives were tried -- the sub-code approach, the 9-bit
approach, the 16-bit approach. It might be interesting to try using
Cachegrind or Callgrind to better understand why the performance changes
occurred.
Nick
Robert Dewar <[EMAIL PROTECTED]> writes:
> > You're right, I shouldn't have said "implementation defined."
> > What will happen with -fno-strict-overflow is whatever the processor
> > ISA happens to do when a signed arithmetic operation overflows. For
> > ordinary machines it will just wrap.
>
>
Ian Lance Taylor wrote:
I believe there is a comprehensible distinction between "compiler will
not assume that signed overflow is undefined behaviour" and "compiler
will cause all arithmetic to wrap around."
In any case, I have no plans to continue working on this. I described
my work in consi
This bootstraps in Linux i686 & I can use -Wno-format-contains-nul to
suppress that warning. OK?
Bruce Korb wrote:
> Hello,
>
> I mess around with a lot of generated code. That means I do automated
> construction of libraries that use literal strings. In order to
> reduce address fixups, I oft
On 22 March 2007 22:08, Brian Dessent wrote:
> The real problem seems to be that the libgcc is broken:
>
> configure:2121: /home/User/cvsroot/gcc-obj/./prev-gcc/xgcc
> -B/home/User/cvsroot/gcc-obj/./prev-gcc/
> -B/usr/local/i686-pc-cygwin/bin/
> conftest.c >&5
> /home/User/cvsroot/gcc-obj/./pre
On Sat, 24 Mar 2007, Bruce Korb wrote:
> This bootstraps in Linux i686 & I can use -Wno-format-contains-nul to
> suppress that warning. OK?
This is not a complete patch submission, I await one with documentation
and testcases (both for the option disabling the diagnostic and for the
use of -Wf
On 3/23/07, Alexander Monakov <[EMAIL PROTECTED]> wrote:
Hello,
I would be pleased to see Ayal Zaks as my mentor, because proposed
improvement is primarily targeted as modulo scheduling improvement. In
case this is not possible, I will seek guidance from Maxim Kuvyrkov.
Ayal has not signed up
On 3/23/07, Marc Espie <[EMAIL PROTECTED]> wrote:
In article <[EMAIL PROTECTED]> you write:
>On 19 Mar 2007 19:12:35 -0500, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
>> similar justifications for yet another small% of slowdown have been
>> given routinely for over 5 years now. small% build up;
Hi All,
I am writing to find out if there is any method of obtaining or
constructing a function parameter list string as it would have been
defined in the source code?
For example for the function:
int Function(std::string v1, std::string v2) {return F(v1, v2);}
I would like to obtain a string t
Dave Korn wrote:
> # 405 "/usr/include/stdio.h" 3 4
[ Which is from newlib (libc/include/stdio.h) if anyone reading this
doesn't have a Cygwin system handy. ]
> static __inline__ int __sgetc_r(struct _reent *__ptr, FILE *__p)
> {
> [...]
>
> The critical difference is the presence or absence
On 3/24/07, Brian Dessent <[EMAIL PROTECTED]> wrote:
Dave Korn wrote:
> # 405 "/usr/include/stdio.h" 3 4
[ Which is from newlib (libc/include/stdio.h) if anyone reading this
doesn't have a Cygwin system handy. ]
> static __inline__ int __sgetc_r(struct _reent *__ptr, FILE *__p)
> {
> [...]
>
Hello,
I get the following error while bootstraping mainline with -O2
-funroll-loops -funsafe-math-optimizations options on PPC.
Thanks,
Revital
make[3]: Leaving directory `/home/revitale/mainline_zero_mve/build'
Comparing stages 2 and 3
warning: ./cc1plus-checksum.o differs
warning: ./cc1obj-c
37 matches
Mail list logo
