Hi All,
GCC 4.1.1
This small bit of code from one of the test suites (
gcc.c-torture/execute/20020611-1.c)worked fine with all optimization
except size optimization -Os.
unsigned int p;
unsigned int n = 30;
void x ()
{
unsigned int h;
h = n <= 30; // Line 1
if (h)
p = 1;
else
p = 0;
Michael James wrote:
Conceptually, the code is:
double sum = 0;
for(i=0; i
I have tried a half dozen variants at the source level in attempt to
get gcc to do this without branching (and without calling a helper
function isnan). I was not really able to succeed at either of these.
You
I keeping getting this error, though it gets less and less each day.
platform it i686-pc-cygwin.
I am not sure if this has been discussed before or similar discussions.
gmp 4.2.1 and mpfr 2.2, up to date as of today.
main.o tree-browser.o libbackend.a ../libcpp/libcpp.a
../libdecnumb
Ben,
I believe I have puzzled out my problem. Geoff's multilib
changes needs a patch for the zlib and libjava configure.ac
(matching what he did for that file in libobjc). I have been
able to obtain a complete build for c, c++, objc and fortran
now on a G4 under Darwin8 after patching the config
> What might be functional specifications for a GCC porting
> project.Output format and ABI might be included in functional
> specification.
Yes--output format would include the object file format and debugging
format. Something else that might wish to be thought about upfront is
machine-dep
>I am having difficulty getting configure properly regenerated in
> libjava so that Geoff's multilib changes will take effect. What
> versions of automake and libtool is required by the current gcc 4.2
> branch?
The safest thing to do is to always look at the top of the file you're
trying to r
Hello,
I am trying to get gcc to optimize an inner math loop. The first part
of the loop computes a single precision float expression (which may or
may not be NAN), and the second part sums all of these results into a
double precision total:
Conceptually, the code is:
double sum = 0;
for(i=0;
Snapshot gcc-4.0-20061102 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20061102/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.0 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Nov 1, 2006, at 8:10 PM, Andrew Pinski wrote:
We don't reject this TU during compiling but the assembler does. Is
this correct or should we actually reject this during compiling?
If you add any checking code, also consider:
int i asm("r1");
int j asm("r1");
Ian Lance Taylor wrote:
I would vote for: break the code, but provide an option to restore the
old behaviour, and mention the option in the error message.
I like this -- I shall prepare a patch and circulate it for review.
Mark
>
> Hello!
>
> Does anybody else get these errors in libgfortran during clean bootstrap:
>
> ...
>
> This happens on x86_64-pc-linux-gnu and i686-pc-linux-gnu, FC4.
Yes and it was already discussed in
http://gcc.gnu.org/ml/gcc/2006-11/msg6.html
-- Pinski
Hello!
Does anybody else get these errors in libgfortran during clean bootstrap:
...
...
.libs/environ.o(.text+0x10d0):/usr/include/stdlib.h:401: first defined here
.libs/in_unpack_generic.o(.text+0x730): In function `atol':
/usr/include/stdlib.h:336: multiple definition of `atol'
.libs/environ
On Nov 2, 2006, at 5:33 AM, Mark Shinwell wrote:
Ian Ollmann wrote:
stronger type checking seems like a good idea to me in general.
I agree, but I don't really want to break lots of code all at once,
even if that code is being slightly more slack than it perhaps ought
to be :-)
Given that n
PR 29145 is about an over-aggressive use of restrict. So far it's had
only one response, and it was left in the UNCONFIRMED state.
tree-data-ref.c says this:
/* An instruction writing through a restricted pointer is "independent" of
any
instruction reading or writing through a different
Mark Shinwell <[EMAIL PROTECTED]> writes:
> Ian Ollmann wrote:
> > stronger type checking seems like a good idea to me in general.
>
> I agree, but I don't really want to break lots of code all at once,
> even if that code is being slightly more slack than it perhaps ought
> to be :-)
>
> Given
On Thu, 2 Nov 2006, Gerald Pfeifer wrote:
> Kaveh, would you mind looking into whether we could referine the autoconf
> magic you added? Something like first checking for the libraries being
> present, and then for headers, and in the case we've got the former but
> not the latter issue an approp
Paolo Bonzini wrote:
Assuming I understand the proposal properly, this sounds to me like
it amounts reversing the change we experienced in the Apple GCC
from 3.3 -> 4.0. Type checking became a lot more lax for us in 4.0.
This was a bug and has been fixed recently. I cannot recall if the
fi
On 02 November 2006 13:12, Gerald Pfeifer wrote:
> On Thu, 26 Oct 2006, Brooks Moses wrote:
>> I would say, on looking at it, that the order of items under "Status" is
>> slightly confusing; it seems to me that "Active Development" ought go
>> next to "Next Release Series".
>
> That's a good poin
Assuming I understand the proposal properly, this sounds to me like
it amounts reversing the change we experienced in the Apple GCC
from 3.3 -> 4.0. Type checking became a lot more lax for us in 4.0.
This was a bug and has been fixed recently. I cannot recall if the
fix has been backporte
Ian Ollmann wrote:
stronger type checking seems like a good idea to me in general.
I agree, but I don't really want to break lots of code all at once,
even if that code is being slightly more slack than it perhaps ought
to be :-)
Given that no-one has really objected to stronger type-checking
Paolo Bonzini wrote:
Ian Ollmann wrote:
Assuming I understand the proposal properly, this sounds to me like it
amounts reversing the change we experienced in the Apple GCC from 3.3
-> 4.0. Type checking became a lot more lax for us in 4.0.
This was a bug and has been fixed recently. I ca
On Thu, 26 Oct 2006, Brooks Moses wrote:
> I would say, on looking at it, that the order of items under "Status" is
> slightly confusing; it seems to me that "Active Development" ought go
> next to "Next Release Series".
That's a good point.
>From a user perspective, how about
Current (4.1)
On Mon, 30 Oct 2006, Geoffrey Keating wrote:
> configure: error: Building GCC requires GMP 4.1+ and MPFR 2.2+. Try the
> --with-gmp and/or --with-mpfr options.
Indeed, as a user I ran into problems with this on a system where both of
these actually were installed.
This is because I had the run-t
On Wed, Nov 01, 2006 at 03:05:33PM -0800, Mark Mitchell wrote:
> I think it would be better to have GLIBC changed before changing the
> behavior of the compiler. It might even be better to have a released
> version of GLIBC with the changes. fixincludes causes sufficient
> problems for people
On 02 November 2006 06:10, Steven Bosscher wrote:
> On 11/2/06, Roger Sayle <[EMAIL PROTECTED]> wrote:
>> Steven Bosscher might even have plans for reorganizing jump bypassing
>> already as part of his CSE/GCSE overhaul?
>
> Yes, and one part of that plan is to pre-split all critical edges so
> t
On Wed, Nov 01, 2006 at 08:02:55AM -0800, Ian Lance Taylor wrote:
> 1) Implement a function attribute which is the equivalent of "extern
>inline". Backport support for this attribute to all open branches.
>Try to persuade the glibc developers to use this feature instead of
>"extern inl
On 02 November 2006 01:38, Roger Sayle wrote:
> On Tue, 31 Oct 2006, Dave Korn wrote:
>> Tracking down a gcse bug while unrolling a loop where the count is
>> known to be one, I've narrowed the problem down to the actions of
>> commit_edge_insertions and bypass_conditional_jumps, and I could use
>
Ian Ollmann wrote:
Assuming I understand the proposal properly, this sounds to me like it
amounts reversing the change we experienced in the Apple GCC from 3.3
-> 4.0. Type checking became a lot more lax for us in 4.0.
This was a bug and has been fixed recently. I cannot recall if the fix
28 matches
Mail list logo
