> breaks libstdc++ for powerpc*-unknown-linux-gnu on systems where long
> double is 128 bits, resulting in lots of "undefined reference" errors
> during linking. The change from "# undef" to "#undef" causes a match
> in a sed command in libstdc++-v3/include/Makefile, which looks for
> "^#undef _G
Benjamin,
Your change for revision 134805,
2008-04-29 Benjamin Kosnik <[EMAIL PROTECTED]>
* include/bits/c++config: Remove space between '#' and 'undef' for
_GLIBCXX_LONG_DOUBLE_COMPAT.
breaks libstdc++ for powerpc*-unknown-linux-gnu on systems where long
double is 128 bits, r
Martin Guy wrote:
I confess I know little about Ada except that it has a formal syntax
longer than the bible...
I hate to tell you, but your Bible must be severely abridged if it
has less than 1400 lines!
Zdenek,
I can't bootstrap the tuples branch on 64bit hosts because pass_ch is
miscompiling stage2/ifcvt.o and stage2/df-scan.o. This causes a
segmentation fault while compiling 32/libgcc/bid128_fma.o.
By disabling pass_ch I can get past that failure. Would you have time
to check it out?
Snapshot gcc-4.3-20080501 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20080501/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Thu, May 1, 2008 at 5:10 PM, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> > Sure, a malloc call has side-effects, so a DCE pass cannot just remove it.
> > Only struct-reorg knows that it has replaced all side-effects with others.
>
> Malloc only has side effects if the result is used.
>
>
> F
> Sure, a malloc call has side-effects, so a DCE pass cannot just remove it.
> Only struct-reorg knows that it has replaced all side-effects with others.
Malloc only has side effects if the result is used.
For example, LLVM will transform
int main(int argc, char** argv){
if(malloc(sizeof(i
Richard Sandiford wrote:
Michael Eager <[EMAIL PROTECTED]> writes:
I have a processor which does not have hardware
register interlocks, somewhat like the MIPS I.
A register used in one instruction may not be
referenced for a certain number of instructions.
If I recall correctly, for the MIPS I,
On Thu, May 1, 2008 at 10:42 PM, Olga Golovanevsky <[EMAIL PROTECTED]> wrote:
> Richard Guenther <[EMAIL PROTECTED]> wrote on 01/05/2008 16:00:44:
>
>
>
> > On Thu, May 1, 2008 at 2:19 PM, Olga Golovanevsky <[EMAIL PROTECTED]>
> wrote:
> > >
> > >
> > > [EMAIL PROTECTED] wrote on 28/04/2008 1
Richard Guenther <[EMAIL PROTECTED]> wrote on 01/05/2008 16:00:44:
> On Thu, May 1, 2008 at 2:19 PM, Olga Golovanevsky <[EMAIL PROTECTED]>
wrote:
> >
> >
> > [EMAIL PROTECTED] wrote on 28/04/2008 12:36:44:
> >
> >
> > > Hello,
> > > I am looking at a testsuite failure (wo_prof_global_var.c) in
> I confess I know little about Ada except that it has a formal syntax
> longer than the bible...
That's probably true. And the C++ one is about 30 or 40% bigger.
Arno
> I wasn't under those recipients.
For the sake of completeness, I wasn't among them either. But I can only
offer diligent review of SPARC specific patches these days and help for
severe problem reports.
--
Eric Botcazou
Benjamin Kosnik wrote:
We are seeing tests posted, at least, even if the volume isn't what
it probably should be for a primary.
sparc-solaris2.10+ has been tested twice on trunk since
stage one for gcc-4.4 opened. This is unacceptable, and in the lower
bounds even for a secondary target. (All o
On Thu, 2008-05-01 at 19:10 +0100, Martin Guy wrote:
> Hi!
> I'm about to lower the gangplanks to get a native gnat on ARM EABI
> through an unholy succession of cross-compilers, with the object of
> getting gnat-4.1 4.2 and 4.3 into the new Debian port for ARM EABI.
>
> The only arm-targetted
Michael Eager <[EMAIL PROTECTED]> writes:
> I have a processor which does not have hardware
> register interlocks, somewhat like the MIPS I.
> A register used in one instruction may not be
> referenced for a certain number of instructions.
>
> If I recall correctly, for the MIPS I, the assembler
>
"Bingfeng Mei" <[EMAIL PROTECTED]> wrote on 01/05/2008 16:02:16:
> Olga,
> Yes, I agree the "p" is global. But how p is going to be accessed if
> another file uses p? D.2215 represents the original "p", but it is not
> initialized as "p.0.4" and "p.0.3" do. It won't be correct if other file
> t
Benjamin Kosnik wrote:
Please keep it as primary. I try to give my best to help out.
I do daily testing on 2.8/2.10. Currently 2.8 is broken.
You do seem to be the most active solaris contributor at the moment,
and that is encouraging. Thanks for your hard work.
Any chance you could post the
Hi!
I'm about to lower the gangplanks to get a native gnat on ARM EABI
through an unholy succession of cross-compilers, with the object of
getting gnat-4.1 4.2 and 4.3 into the new Debian port for ARM EABI.
The only arm-targetted gnat I could find is adacore's Windows
cross-compiler for xscale
> We are seeing tests posted, at least, even if the volume isn't what
> it probably should be for a primary.
sparc-solaris2.10+ has been tested twice on trunk since
stage one for gcc-4.4 opened. This is unacceptable, and in the lower
bounds even for a secondary target. (All of which have more reg
> Are there any targets with register interlock where
> gcc handles moving instructions between conflicting
> instructions?
>
> Any suggestions on how this might be represented
> in .md files? It doesn't seem that the pipeline
> description would seem appropriate.
This is approximately what ia64
> What was the issue?
Incorrect (too-lenient) config for OpenMP in other target libraries
besides libgomp.
I reverted to the too-permissive behavior, which is still wrong but at
least won't break stuff.
This is now bugzilla
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36101
-benjamin
I have a processor which does not have hardware
register interlocks, somewhat like the MIPS I.
A register used in one instruction may not be
referenced for a certain number of instructions.
If I recall correctly, for the MIPS I, the assembler
handled inserting nop instructions when it found a
reg
On Thu, May 1, 2008 at 3:17 AM, Benjamin Kosnik <[EMAIL PROTECTED]> wrote:
> > Given that the set of posted solaris test results for trunk during the
> > last four months barely requires two hands:
> >...
> > I propose moving
> >
> > sparc-sun-solaris2.10
> >
> > from primary to secondary on
> Please keep it as primary. I try to give my best to help out.
>
> I do daily testing on 2.8/2.10. Currently 2.8 is broken.
You do seem to be the most active solaris contributor at the moment,
and that is encouraging. Thanks for your hard work.
Any chance you could post the results of your dai
But how can a function outside of the file use "p" here after
struct_reorg optmization. It isn't correct.
p = malloc (N * sizeof (str_t));
for (i = 0; i < N; i++)
p[i].a = p[i].b + 1;
foo();<-- Assume foo() in another file access p here. It will
either access uninitialized mem
Bingfeng Mei wrote:
Olga,
Yes, I agree the "p" is global. But how p is going to be accessed if
another file uses p? D.2215 represents the original "p", but it is not
initialized as "p.0.4" and "p.0.3" do. It won't be correct if other file
tried to use it. Am I right?
Cheers,
Bingfeng
I wo
Olga,
Yes, I agree the "p" is global. But how p is going to be accessed if
another file uses p? D.2215 represents the original "p", but it is not
initialized as "p.0.4" and "p.0.3" do. It won't be correct if other file
tried to use it. Am I right?
Cheers,
Bingfeng
> D.2215 = malloc (8000);
>
On Thu, May 1, 2008 at 2:19 PM, Olga Golovanevsky <[EMAIL PROTECTED]> wrote:
>
>
> [EMAIL PROTECTED] wrote on 28/04/2008 12:36:44:
>
>
> > Hello,
> > I am looking at a testsuite failure (wo_prof_global_var.c) in my
> > porting. Somehow, I found GCC 4.3.0 seems to generate unnecessary malloc
>
[EMAIL PROTECTED] wrote on 28/04/2008 12:36:44:
> Hello,
> I am looking at a testsuite failure (wo_prof_global_var.c) in my
> porting. Somehow, I found GCC 4.3.0 seems to generate unnecessary malloc
> during structure optimization. In the code, the structure is split into
> two individual fields
>Benjamin Kosnik <[EMAIL PROTECTED]> writes:
>
>Given that the set of posted solaris test results for trunk during the
>last four months barely requires two hands:
>
>2008-01
>http://gcc.gnu.org/ml/gcc-testresults/2008-01/msg01474.html
>http://gcc.gnu.org/ml/gcc-testresults/2008-01/msg01460.html
H.J. Lu wrote:
We currently define __builtin_ia32_palignr as
long long __builtin_ia32_palignr (long long, long long, int)
But it really should be
v1di __builtin_ia32_palignr (v1di, v1di, int)
Fix it won't affect sources which use intrinsics defined
in tmmintrin.h. But it may affect codes whi
On Wed, 2008-04-30 at 11:01 +0200, Fabien Baron wrote:
> I'm working on a big project in C code, and I want to profile it so I
> used gcc with the options -ftest-coverage and -fprofile-arcs, and gcov
> to analyze the results. It works very well but on the whole project
> and the whole execution !!
Benjamin Kosnik wrote:
I propose moving
sparc-sun-solaris2.10
from primary to secondary on this page:
http://gcc.gnu.org/gcc-4.4/criteria.html
Thoughts?
Please keep it as primary. I try to give my best to help out.
I do daily testing on 2.8/2.10. Currently 2.8 is broken.
I work in a comp
33 matches
Mail list logo
