> First is_gimple_min_invariant in try_to_simplify where it chooses
> DECL_INITIAL should be valid_gimple_expression_p instead.
That's a known problem, see tree-ssa-ccp.c:
/* The regular is_gimple_min_invariant does a shallow test of the object.
It assumes that full gimplification has happened
make clean-target fails at x86_64-unknown-linux-gnu/32/libjava when
doing target 'mostlyclean-local' because it tries to execute:
find . -name '*.lo' -print | xargs /bin/sh ./libtool rm -f
and we get:
libtool: error: you must specify a MODE.
when it should execute:
find . -name '*.lo' -print
> This means that the largest int on the host must be at least half the
> size of the largest int on the target. Hence, building 64-bit target
> compilers on 32-bit host systems has never been a problem.
I'm not sure I'd go as far as saying "has never been a problem". It's
"mostly worked", b
> One could of course just take a blanket view that everything on the
> site is, as of a certain moment, licensed under GPLv3 (note you
> don't have to change file headers to achieve this, the file headers
> have no particular legal significance in any case).
Given the July 31 "deadline", that's e
Rob Brown <[EMAIL PROTECTED]> writes:
> So, could there be a simultaneous release of gcc under GPLv2 and GPLv3,
> identical in all respects except for the license?
How could that be useful? That v2(+) version would already be v3
if the user wanted so (due to the "or later" clause).
Use any licen
This patch
http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00165.html
causes the regression:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32748
The only relevant change is
Index: gcc/fortran/trans-decl.c
===
--- gcc/fortran/trans-decl
H.J. Lu wrote:
It looks like gcc assumes a functon marked with DECL_IS_MALLOC won't
return an address which can alias something else. But it isn't true
for realloc. Now, the qestions are
1. Can gcc make such an assumption?
2. Can realloc be marked as DECL_IS_MALLOC.
BTW, glibc also marks reallo
The test FAIL: gcc.dg/pragma-darwin.c fails with
FAIL: gcc.dg/pragma-darwin.c (test for errors, line 15)
FAIL: gcc.dg/pragma-darwin.c (test for errors, line 16)
FAIL: gcc.dg/pragma-darwin.c (test for errors, line 17)
FAIL: gcc.dg/pragma-darwin.c (test for errors, line 18)
FAIL: gcc.dg/pragma-d
On Sat, Jul 14, 2007 at 06:03:33PM +0200, Tobias Schlüter wrote:
> H.J. Lu wrote:
> >It looks like gcc assumes a functon marked with DECL_IS_MALLOC won't
> >return an address which can alias something else. But it isn't true
> >for realloc. Now, the qestions are
> >
> >1. Can gcc make such an assum
Richard Kenner wrote:
One could of course just take a blanket view that everything on the
site is, as of a certain moment, licensed under GPLv3 (note you
don't have to change file headers to achieve this, the file headers
have no particular legal significance in any case).
Given the July 31 "de
Michael Eager wrote:
Unfortunately, as I understand it, this is not the case. If you
apply a GPLv3 patch to a previously GPLv2 branch after August 1, then
this entire branch, and all files in it, magically and silently
becomes GPLv3. (This is unless FSF agrees with Mark's proposal
to dual lice
Robert Dewar wrote:
Michael Eager wrote:
Unfortunately, as I understand it, this is not the case. If you
apply a GPLv3 patch to a previously GPLv2 branch after August 1, then
this entire branch, and all files in it, magically and silently
becomes GPLv3. (This is unless FSF agrees with Mark's
(I don't follow this list regularly, but ran into the GIMPLE tuples
proposal and had a suggestion. Apologies if you were already aware of
this technique.)
The proposed tuple structure has the fields "code" and "subcode". My
reading of its intent is to allow a simple two-level hierarchy of types.
Michael Eager <[EMAIL PROTECTED]> writes:
> Unfortunately, as I understand it, this is not the case. If you
> apply a GPLv3 patch to a previously GPLv2 branch after August 1, then
> this entire branch, and all files in it, magically and silently
> becomes GPLv3. (This is unless FSF agrees with M
Krzysztof Halasa wrote:
Michael Eager <[EMAIL PROTECTED]> writes:
Unfortunately, as I understand it, this is not the case. If you
apply a GPLv3 patch to a previously GPLv2 branch after August 1, then
this entire branch, and all files in it, magically and silently
becomes GPLv3. (This is unles
Michael Eager <[EMAIL PROTECTED]> writes:
> Not until someone updates the txt. Which should happen quickly,
> but if someone applies a GPLv3 patch to a previously GPLv2 branch,
> the entire branch becomes GPLv3, whether the COPYING file was
> updated or not.
Come on, if the FSF (the copyright ho
Krzysztof Halasa wrote:
Michael Eager <[EMAIL PROTECTED]> writes:
Not until someone updates the txt. Which should happen quickly,
but if someone applies a GPLv3 patch to a previously GPLv2 branch,
the entire branch becomes GPLv3, whether the COPYING file was
updated or not.
Come on, if the F
>Krzysztof Halasa wrote:
>> Michael Eager <[EMAIL PROTECTED]> writes:
>>
>>> Not until someone updates the txt. Which should happen quickly,
>>> but if someone applies a GPLv3 patch to a previously GPLv2 branch,
>>> the entire branch becomes GPLv3, whether the COPYING file was
>>> updated or not.
Ian Lance Taylor wrote:
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
Robert Dewar wrote:
>One could of course just take a blanket view that everything
>on the site is, as of a certain moment, licensed under GPLv3
>(note you don't have to change file headers to achieve this,
>the file headers have no particular legal significance in
>any case).
According to http://w
Sandra Loosemore <[EMAIL PROTECTED]> writes:
> #6 0x0875dc03 in rest_of_handle_combine ()
> at /scratch/sandra/mips-mainline/src/gcc-mainline/gcc/combine.c:1264
>
> ...
>
> Looks like a job for valgrind? But I'm out of time for working on
> this, at least for now. Can anyone else take a stab
> Is anyone else seeing failures on the gcc.dg/matrix tests? I am getting
> the following failures on IA64 HP-UX:
>
Hope Razya can help spot the cause, after she returns from vacation later
this week.
Ayal.
> FAIL: gcc.dg/matrix/matrix-1.c scan-ipa-dump-times Flattened 3 dimensions
1
> FAIL: g
Robert Dewar wrote:
One could of course just take a blanket view that everything
on the site is, as of a certain moment, licensed under GPLv3
(note you don't have to change file headers to achieve this,
the file headers have no particular legal significance in
any case).
I'm going to pull a Wik
23 matches
Mail list logo
