> On Oct 1, 2015, at 11:34 AM, Alexander Monakov wrote:
>
> Can you expand on the "etc." a bit, i.e., may the compiler ...
>
> - move a call to a "const" function above a conditional branch,
>causing a conditional throw to happen unconditionally?
No, calls may only be omitted, not moved.
On Jul 23, 2014, at 10:56 AM, Thomas Mertes wrote:
> One such feature is the detection of signed integer overflow. It is
> not hard, to detect signed integer overflow with a generated C
> program, but the performance is certainly not optimal. Signed integer
> overflow is undefined behavior in C
On Jul 20, 2014, at 5:55 PM, Jakub Jelinek wrote:
> So, what versioning scheme have we actually agreed on, before I change it in
> wwwdocs? Is that
> 5.0.0 in ~ April 2015, 5.0.1 in ~ June-July 2015 and 5.1.0 in ~ April 2016,
> or
> 5.0 in ~ April 2015, 5.1 in ~ June-July 2015 and 6.0 in ~ Apri
On Jun 2, 2014, at 10:06 AM, Vincent Lefevre wrote:
> I've looked at
>
> https://gcc.gnu.org/wiki/FloatingPointMath
>
> and there may be some mistakes or missing info.
That’s quite possible. I created the page many years ago, based on my
understanding of GCC at that time.
>
> First, it is
On Nov 9, 2013, at 02:48, Ondřej Bílka wrote:
>> I've done the overflow checking in Gigi (Ada front end). Benchmarking
>> real world large Ada programs (where every integer operation is checked,
>> including array index computations etc.), I found the performance cost
>> *very* small (less than
On Oct 29, 2013, at 05:41, Richard Biener wrote:
> For reference those
> (http://clang.llvm.org/docs/LanguageExtensions.html) look like
>
> if (__builtin_umul_overflow(x, y, &result))
>return kErrorCodeHackers;
>
> which should be reasonably easy to support in GCC (if you factor out
> gen
On May 3, 2013, at 00:15, reed kotler wrote:
> There was some confusion on the llvm list because some tests were run on
> targets that did not support the naked attribute.
>
> I think we are thinking now that the return statement should not be emitted
> unless explicitly requested.
>
> It's
On Apr 9, 2013, at 22:19, Segher Boessenkool wrote:
> Some numbers, 16-core 64-thread POWER7, c,c++,fortran bootstrap:
> -j6: real57m32.245s
> -j60: real38m18.583s
Yes, these confirm mine. It doesn't make sense to look at more
parallelization before we address the serial bottlenecks.
T
On Apr 3, 2013, at 23:44, Joern Rennecke wrote:
> How does that work?
> The binaries have to get the all the machines of the clusters somewhere.
> Does this assume you are using NFS or similar for your build directory?
> Won't the overhead of using that instead of local disk kill most of the
> p
On Apr 3, 2013, at 11:27, Simon Baldwin wrote:
> Suppose you had a month in which to reorganise gcc so that it builds
> its 3-stage bootstrap and runtime libraries in some massively parallel
> fashion, without hardware or resource constraints(*). How might you
> approach this?
One of the main pr
On May 13, 2012, at 21:17, amyl...@spamcop.net wrote:
> The expectation is wrap-around. Note that loop strenght reduction can
> cause assumed wrap-around semantics in RTL for strictly conforming C input
> where no such wrap-around is in evidence.
Really, we should define signed integer arithmeti
On Feb 13, 2012, at 09:59, Vincent Lefevre wrote:
> On 2012-02-09 15:49:37 +, Andrew Haley wrote:
>> I'd start with INRIA's crlibm.
>
> I point I'd like to correct. GNU MPFR has mainly (> 95%) been
> developed by researchers and engineers paid by INRIA. But this
> is not the case of CRlibm.
On Feb 14, 2012, at 11:44, Andrew Haley wrote:
> On 02/14/2012 04:41 PM, Geert Bosch wrote:
>> Right now we don't have a library either that conforms to C99
>
> Are you sure? As far as I know we do. We might not meet
> C99 Annex F, but that's not required.
>
&g
On Feb 14, 2012, at 08:22, Vincent Lefevre wrote:
> Please do not use the term binary80, as it is confusing (and
> there is a difference between this format and the formats of
> the IEEE binary{k} class concerning the implicit bit).
Yes, I first wrote extended precision, though that really is
a ge
> On 2012-02-09 12:36:01 -0500, Geert Bosch wrote:
>> I think it would make sense to have a check list of properties, and
>> use configure-based tests to categorize implementations. These tests
>> would be added as we go along.
>>
>> Criteria:
>>
>&g
On Feb 10, 2012, at 05:07, Richard Guenther wrote:
> On Thu, Feb 9, 2012 at 8:16 PM, Geert Bosch wrote:
>> I don't agree having such a libm is the ultimate goal. It could be
>> a first step along the way, addressing correctness issues. This
>> would be great progres
On Feb 9, 2012, at 15:33, Joseph S. Myers wrote:
> For a few, yes, inline support (such as already exists for some functions
> on some targets) makes sense. But for some more complicated cases it
> seems plausible that LTO information in a library might be an appropriate
> way of inlining whil
On Feb 9, 2012, at 12:55, Joseph S. Myers wrote:
> No, that's not the case. Rather, the point would be that both GCC's
> library and glibc's end up being based on the new GNU project (which might
> take some code from glibc and some from elsewhere - and quite possibly
> write some from scratc
On Feb 9, 2012, at 10:28, Richard Guenther wrote:
> Yes, definitely! OTOH last time I added the toplevel libgcc-math directory
> and populated it with sources from glibc RMS objected violently and I had
> to remove it again. So we at least need to find a different source of
> math routines to st
On Feb 9, 2012, at 08:46, Andrew Haley wrote:
> n 02/09/2012 01:38 PM, Tim Prince wrote:
>> x87 built-ins should be a fair compromise between speed, code size, and
>> accuracy, for long double, on most CPUs. As Richard says, it's
>> certainly possible to do better in the context of SSE, but gcc
On Feb 5, 2012, at 11:08, James Courtier-Dutton wrote:
> But, r should be
> 5.26300791462049950360708478127784... or
> -1.020177392559086973318201985281...
> according to wolfram alpha and most arbitrary maths libs I tried.
>
> I need to do a bit more digging, but this might point to a bug in th
On Sep 13, 2011, at 08:08, Andrew MacLeod wrote:
> On 09/12/2011 09:52 PM, Geert Bosch wrote:
>> No that's false. Even on systems with nice memory models, such as x86 and
>> SPARC with a TSO model, you need a fence to avoid that a write-load of the
>> same location i
On Sep 12, 2011, at 19:19, Andrew MacLeod wrote:
> Lets simplify it slightly. The compiler can optimize away x=1 and x=3 as
> dead stores (even valid on atomics!), leaving us with 2 modification orders..
> 2,4 or 4,2
> and what you are getting at is you don't think we should ever see
> r1==
On Sep 12, 2011, at 03:02, Paolo Bonzini wrote:
> On 09/11/2011 09:00 PM, Geert Bosch wrote:
>> So, if I understand correctly, then operations using relaxed memory
>> order will still need fences, but indeed do not require any
>> optimization barrier. For memory_order_seq_
On Sep 11, 2011, at 15:11, Jakub Jelinek wrote:
> On Sun, Sep 11, 2011 at 03:00:11PM -0400, Geert Bosch wrote:
>> Also, for relaxed order atomic operations we would only need a single
>> fence between two accesses (by a thread) to the same atomic object.
>
> I'm not aw
On Sep 11, 2011, at 10:12, Andrew MacLeod wrote:
>> To be honest, I can't quite see the use of completely unordered
>> atomic operations, where we not even prohibit compiler optimizations.
>> It would seem if we guarantee that a variable will not be accessed
>> concurrently from any other thread,
On Sep 9, 2011, at 04:17, Jakub Jelinek wrote:
> I'd say they should be optimization barriers too (and at the tree level
> they I think work that way, being represented as function calls), so if
> they don't act as memory barriers in RTL, the *.md patterns should be
> fixed. The only exception s
On Nov 19, 2010, at 11:53, Eric Botcazou wrote:
>> Yes, if all the people who want only one set of libraries agree on what
>> that set shall be (or this can be selected with existing configure flags),
>> this is the simplest way.
>
> Yes, this can be selected at configure time with --with-cpu and
On Nov 1, 2010, at 00:30, Joern Rennecke wrote:
>> Feel free to enable Ada. Builds and tests faster than Java,
>> and is known to expose many more middle end bugs, including
>> ones that require non-call exceptions.
>
> But to get that coverage, testers will need to have gnat installed.
> Will th
On Oct 31, 2010, at 15:33, Steven Bosscher wrote:
> The argument against disabling java as a default language always was
> that there should be at least one default language that requires
> non-call exceptions. I recall testing many patches without trouble if
> I did experimental builds with just
On Oct 8, 2010, at 18:18, Manuel López-Ibáñez wrote:
> It is possible to do it quite fast. Clang implements all warnings,
> including Wuninitialized, in the FE using fast analysis and they claim
> very low false positives.
> However, there are various reasons why it has not been attempted in GCC:
On Jun 23, 2010, at 22:53, Tomás Touceda wrote:
> I'm starting to dig a little bit in what gcc does to protect the stack
> from overflows and attacks of that kind. I've found some docs and
> patches, but they aren't really up to date. I thought I could get some
> diffs for the parts that manage t
On Jun 1, 2010, at 17:41, DJ Delorie wrote:
> It assumes your editor can do block-reformatting while preserving the
> comment syntax. I've had too many // cases of Emacs guessing wrong //
> and putting // throughout a reformatted // block.
With Ada we have no choice, and only have -- comments.
On May 31, 2010, at 14:25, Mark Mitchell wrote:
> That doesn't necessarily mean that we have to use lots of C++ features
> everywhere. We can use the C (almost) subset of C++ if we want to in
> some places. As an example, if the Fortran folks want to use C in the
> Fortran front-end, then -- exc
On Mar 29, 2010, at 16:30, Tim Prince wrote:
> gcc used to have the ability to replace division by a power of 2 by an fscale
> instruction, for appropriate targets (maybe still does).
The problem (again) is that floating point multiplication is
just too damn fast. On x86, even though the latency
On Mar 29, 2010, at 13:19, Jeroen Van Der Bossche wrote:
> 've recently written a program where taking the average of 2 floating
> point numbers was a real bottleneck. I've looked into the assembly
> generated by gcc -O3 and apparently gcc treats multiplication and
> division by a hard-coded 2 li
On Feb 21, 2010, at 20:57, Joseph S. Myers wrote:
> I know some people have claimed (e.g. glibc bug 6981) that you can't
> conform to Annex F when you have excess precision, but this does not
> appear to be the view of WG14.
That may be the case, but I really wonder how much sense it
can make t
On Feb 21, 2010, at 07:13, Richard Guenther wrote:
> The present discussion is about defaulting to at least 486 when not
> configured for i386-linux. That sounds entirely reasonable to me.
I fully agree with the "at least 486" part. However,
if we only change the default once every 20 years, it
On Feb 21, 2010, at 12:34, Joseph S. Myers wrote:
> Correct - I said API, not ABI. The API for C programs on x86 GNU/Linux
> involves FLT_EVAL_METHOD == 2, whereas that on x86 Darwin involves
> FLT_EVAL_METHOD == 0 and that on FreeBSD involves FLT_EVAL_METHOD == 2
> but with FPU rounding prec
On Feb 21, 2010, at 17:42, Erik Trulsson wrote:
> Newer compilers usually have better generic optimizations that are not
> CPU-dependent. Newer compilers also typically have improved support
> for new language-features (and new languages for that matter.)
This is exactly where CPU dependence com
On Feb 21, 2010, at 09:58, Joseph S. Myers wrote:
> On Sun, 21 Feb 2010, Richard Guenther wrote:
>>> The biggest change we need to make for x86 is to enable SSE2,
>>> so we can get proper rounding behavior for float and double,
>>> as well as significant performance increases.
>>
>> I think Josep
On Feb 21, 2010, at 06:18, Steven Bosscher wrote:
> My point: gcc may fail to attract users (and/or may be losing users)
> when it tries to tailor to the needs of minorities.
>
> IMHO it would be much more reasonable to change the defaults to
> generate code that can run on, say, 95% of the compu
On Nov 23, 2009, at 10:17, Ian Bolton wrote:
> Regardless of the architecture, I can't see how an unbalanced tree would
> ever be a good thing. With a balanced tree, you can still choose to
> process it in either direction (broad versus deep) - whichever is better
> for your architecture - but,
On Sep 19, 2009, at 18:02, Steven Bosscher wrote:
* GDB test suite should pass with -O1
Apparently, the current GDB test suite can only work at -O0,
because code reorganization messes up the scripting.
-Geert
If you pass -v to gnatmake, it will output the gcc invocations.
This should be sufficient to find the problem.
Basically, just go to the directory containing c35502i.adb, and
execute the gnatmake command as listed below, with -v added in.
If you only have the 35502i.ada file available, use "gnatc
On Aug 21, 2009, at 18:40, Paul Smedley wrote:
Hi All,
I'm wanting to update the GNU ADA compiler for OS/2... I'm currently
building GCC 4.3.x and 4.4.x on OS/2 (C/C++/fortran) but for ADA
configure complains about not finding gnat. The problem is that the
only gnat compiled for OS/2 was year
On Aug 12, 2009, at 10:32, Joel Sherrill wrote:
Hi,
GNAT doesn't build for arm-rtems on 4.4.x or
SVN (PR40775). I went back to 4.3.x since I
remembered it building.
I have run the ACATS on an ep7312 target and
get a number of generic test failures that
don't look RTEMS specific. Has anyone r
On Apr 20, 2009, at 14:45, Oliver Kellogg wrote:
It would be best to first contemplate what output a single
invocation of the compiler, with multiple compilation units
as arguments, should produce.
For an invocation
gnat1 a.adb b.adb c.adb
, the files a.{s,ali} b.{s,ali} c.{s,ali} are produced
On Apr 12, 2009, at 13:29, Oliver Kellogg wrote:
On Tue, 4 Mar 2003, Geert Bosch wrote:
[...]
Best would be to first post a design overview,
before doing a lot of work in order to prevent spending time
on implementing something that may turn out to have fundamental
problems.
I've d
On Mar 6, 2009, at 12:22, Joseph S. Myers wrote:
If you add new trapping codes to GENERIC I'd recommend *not* making
fold()
handle them. I don't think much folding is safe for the trapping
codes
when you want to avoid either removing or introducing traps. Either
lower
the codes in gimpli
On Mar 6, 2009, at 04:11, Richard Guenther wrote:
I didn't spend too much time thinking about the trapping variants
(well, I believe it isn't that important ;)). But in general we would
have to expand the non-NV variants via the trapping expanders
if flag_trapv was true (so yeah, combining TUs
On Mar 6, 2009, at 09:15, Joseph S. Myers wrote:
It looks like only alpha and pa presently have insn patterns such as
addvsi3 that would be used by the present -ftrapv code, but I expect
several other processors also have instructions that would help in
overflow-checking code. (For example, Pow
Hi Richard,
Great to see that you're addressing this issue. If I understand
correctly,
for RTL all operations are always wrapping, right?
I have been considering adding "V" variants for operations that trap on
overflow. The main reason I have not (yet) pursued this, is the daunting
task of te
On Mar 27, 2008, at 02:58, Joern Rennecke wrote:
I'm trying to write a test to check I get all the subnormal
corner cases for ieee-754 double precision floating point division
right.
The usual thing to do with a new test is to try it on a known good
platform. Unfortunately, the x86 processor
On Dec 26, 2007, at 14:24, Mark Mitchell wrote:
Geert Bosch wrote:
Nested functions aren't used that much in C indeed... :)
Paul, would you please review this patch?
This patch isn't good. While it addressed the alignment
issue, it didn't correctly adjust all n
On Dec 16, 2007, at 20:27, Joe Buck wrote:
I have some sympathy for going in Alexandre's direction, in that it
would be nice to have a mode that provided optimization as well as
accurate debugging. However, since preserving accurate debug
information
has a cost, I think it would be better to
On Nov 21, 2007, at 16:34, Daniel Jacobowitz wrote:
>Did you mean to send this to the list? If so, feel free to reply
>there.
Indeed, I did. I now Cc-ed the list as well.
>>Here's the first few lines of a-textio.adb disassembly:
>>Dump of assembler code for function ada__text_io__put_line:
>>0x800
On Nov 14, 2007, at 05:27, Vincent Lefevre wrote:
Initially, float could simply use double and cast the result.
For double->float the results will remain correctly rounded.
Yes, very probably, but this needs to be proven for each supported
function, due to the double rounding problem (this ma
On Nov 13, 2007, at 08:17, Michael Matz wrote:
You don't have to preach to the choir, I know why I looked at several
libms in the past :-)
I just say that crlibm is not it. There are libms which would impose
much less work, are more complete, faster and more proven in the real
world.
Do you
On Nov 12, 2007, at 12:37, Michael Matz wrote:
At the time we discussed and evaluated a bundled libm I've looked at
several ones. I rules out crlibm relatively quickly for these
reasons:
* only double is implemented, hence long double and float are
missing at
least, at least the long do
On Jun 24, 2007, at 16:20, Eric Botcazou wrote:
Indeed. It would be interesting to confirm whether or not a copy
of gcc
bootstrapped with a non-gcc compiler matched byte-for-byte with a
copy
of gcc bootstrapped from gcc.
I just made the experiment on an old SPARC/Solaris 2.5.1 machine
a
On May 11, 2007, at 11:31, Andrew Haley wrote:
It shouldn't have. All args are ints, and if we are assuming (as the
C standard says) that int overflow is undefined, the transformation is
valid.
Aarghh..! I even quoted the part that mentioned ints, but still thought
it was about float. Sure,
On May 11, 2007, at 08:26, Rahul wrote:
But for the following example
int a = 1;
int b = 2;
int c = 3;
c = c + a * b;
the MAC pattern is not getting recognized, instead it is still using
PLUS and MULT patterns.
In general, this transformation is not valid, as it has
different rounding beha
On Apr 27, 2007, at 06:12, Janne Blomqvist wrote:
I agree it can be an issue, but OTOH people who care about
precision probably 1. avoid -ffast-math 2. use double precision
(where these reciprocal instrs are not available). Intel calls it -
no-prec-div, but it's enabled for the "-fast" catch
In 3.1, you write:
The statistics gathered over the programs mentioned in the
previous section show that about 43% of all statements contain 0 or
more
register operands
I'd assume 100% contain 0 or more register operands.
Did you mean 43% contain 1 or more?
-Geert
On Mar 19, 2007, at 05:44, François-Xavier Coudert wrote:
I have the three following questions, probably best directed to
middle-end experts and Ada maintainers:
* How can I know the longest float type? My first patch uses the
long_double_type_node unconditionally, but it surely isn't a generic
On Jan 1, 2007, at 21:14, Ian Lance Taylor wrote:
[...]
extern void bar (void);
void
foo (int m)
{
int i;
for (i = 1; i < m; ++i)
{
if (i > 0)
bar ();
}
}
Here the limit for i without -fwrapv becomes (1, INF]. This enables
VRP to eliminate the test "i > 0". With -fwra
On Jan 1, 2007, at 12:16, Joseph S. Myers wrote:
For a program to be secure in the face of overflow, it will
generally need
explicit checks for overflow, and so -fwrapv will only help if such
checks
have been written under the presumption of -fwrapv semantics.
Yes, but often people do writ
On Dec 31, 2006, at 19:13, Daniel Berlin wrote:
Note the distinct drop in performance across almost all the benchmarks
on Dec 30, including popular programs like bzip2 and gzip.
Not so.
To my eyes, the specint 2000 mean went UP by about 1% for the
base -O3 compilation. The peak enabled more un
On Dec 13, 2006, at 17:09, Denis Vlasenko wrote:
# g++ -c -O3 toto.cpp -o toto.o
# g++ -DUNROLL -O3 toto.cpp -o toto_unroll.o -c
# size toto.o toto_unroll.o
textdata bss dec hex filename
525 8 1 534 216 toto.o
359 8 1 368 170 to
On Dec 20, 2006, at 09:38, Bruno Haible wrote:
But the other way around? Without -fwrapv the compiler can assume more
about the program being compiled (namely that signed integer overflows
don't occur), and therefore has more freedom for optimizations. All
optimizations that are possible with -f
On Dec 4, 2006, at 20:19, Howard Hinnant wrote:
If that is the question, I'm afraid your answer is not accurate.
In the example I showed the difference is 2 ulp. The difference
appears to grow with the magnitude of the argument. On my systems,
when the argument is DBL_MAX, the difference
On Dec 3, 2006, at 12:44, Kaveh R. GHAZI wrote:
In case i370 support is revived or a format not using base==2 is
introduced, I could proactively fix the MPFR precision setting for any
base that is a power of 2 by multiplying the target float precision by
log2(base). In the i370 case I would mu
On Nov 14, 2006, at 12:49, Bill Wendling wrote:
I'll mention a case where compilation was wickedly slow even
when using -j#. At The MathWorks, the system could take >45 minutes
to compile. (This was partially due to the fact that the files were
located on an NFS mounted drive. But also because C
On Nov 13, 2006, at 21:27, Dave Korn wrote:
To be fair, Mike was talking about multi-core SMP, not threading
on a single
cpu, so given that CPU usage is at 100% now for most jobs, there is
an Nx100%
speedup to gain from using 1 thread on each of N cores.
I'm mostly building GCC on multip
On Nov 11, 2006, at 03:21, Mike Stump wrote:
The cost of my assembler is around 1.0% (ppc) to 1.4% (x86)
overhead as measured with -pipe -O2 on expr.c,. If it was
converted, what type of speedup would you expect?
Given that CPU usage is at 100% now for most jobs, such as
bootstrapping GCC,
Most people aren't waiting for compilation of single files.
If they do, it is because a single compilation unit requires
parsing/compilation of too many unchanging files, in which case
the primary concern is avoiding redoing useless compilation.
The common case is that people just don't use the -
On Nov 5, 2006, at 08:46, Kenneth Zadeck wrote:
The thing is that even as memories get larger, something has to give.
There are and will always be programs that are too large for the most
aggressive techniques and my proposal is simply a way to gracefully
shed
the most expensive techniques as
On May 25, 2006, at 13:21, Jon Smirl wrote:
jmp *4($esp)
This is slightly faster than addl, ret.
The point is that this is only executed in the error case.
But my micro scale benchmarks are extremely influenced by changes in
branch prediction. I still wonder how this would perfor
On May 23, 2006, at 11:21, Jon Smirl wrote:
A new calling convention could push two return addresses for functions
that return their status in EAX. On EAX=0 you take the first return,
EAX != 0 you take the second.
This seems the same as passing an extra function pointer
argument and calling t
On Apr 3, 2006, at 09:34, Waldek Hebisch wrote:
2) Adjusting gpc development model. In particular, gpc uses rather
short
feedback loop: new features are released (as alphas) when they
are ready.
This is possible because gpc uses stable backend, so that users are
exposed only to fron
On Mar 16, 2006, at 10:43, Richard Guenther wrote:
Uh - what do you expect here?? Does the Ada standard
require a out-of-range exception upon the first use of N?
In this case, the frontend needs to insert a proper check.
You cannot expect the middle-end to avoid the above
transformation, so thi
On Mar 16, 2006, at 05:09, Robert Dewar wrote:
Not quite right. If you have an uninitialized variable, the value is
invalid and may be out of bounds, but this is a bounded error
situation,
not an erroneous program. So the possible effects are definitely NOT
unbounded, and the use of such valu
On Feb 15, 2006, at 13:28, John David Anglin wrote:
Understood. My question was what should the define for
WIDEST_HARDWARE_FP_SIZE be when generating code for a target
with no hardware floating point support (e.g., when
TARGET_SOFT_FLOAT is true)?
Practically, I'd say it should be 64, as it'
On Feb 15, 2006, at 11:44, John David Anglin wrote:
I missed this "new" define and will try it. Perhaps, this should
take account of the situation when TARGET_SOFT_FLOAT is true. For
example,
When emulating all software floating-point, we still don't want to
use 128-bit floats. The whole idea
On Nov 17, 2005, at 21:33, Dale Johannesen wrote:
When I arrived at Apple around 5 years ago, I was told of some recent
measurements that showed the assembler took around 5% of the time.
Don't know if that's still accurate. Of course the speed of the
assembler
is also relevant, and our stubs a
On Nov 15, 2005, at 18:11, Laurent GUERBY wrote:
What about moving s-auxdec from ada/Makefile.rtl
GNATRTL_NONTASKING_OBJS
into EXTRA_GNATRTL_NONTASKING_OBJS so it can be set for VMS targets
only
in ada/Makefile.in?
This is not ideal, because some people are migrating from DEC Ada
to GNAT o
On Nov 14, 2005, at 19:59, Jim Wilson wrote:
Joel Sherrill <[EMAIL PROTECTED]> wrote:
s-auxdec.ads:286:13: alignment for "Aligned_Word" must be at least 4
Any ideas?
I'm guessing this is because ARM sets STRUCTURE_SIZE_BOUNDARY to 32
instead of 8, and this confuses the Ada front end.
Note
On Oct 27, 2005, at 17:25, Steve Ellcey wrote:
It would be easy enough to add an option that turned off the use of
the
fused multiply and add in GCC but I would hate to see its use
turned off
by default.
Code that cares should be able to express barriers across which no
contraction is poss
On Oct 27, 2005, at 17:19, Andreas Schwab wrote:
I think this is what the FP_CONTRACT pragma is supposed to provide.
Yes, but it seems there is no way in the middle end / back end to
express this. Or am I just hopelessly behind the times? :)
-Geert
On Oct 27, 2005, at 14:12, Eric Botcazou wrote:
I'm under the impression that it's worse on IA-64 because of the
"infinite
precision", but I might be wrong.
Fused multiply-add always uses "infinite precision" in the intermediate
result. Only a single rounding is performed at the end. We real
This is http://gcc.gnu.org/PR22319.
On Jul 6, 2005, at 06:17, Andreas Schwab wrote:
Andreas Jaeger <[EMAIL PROTECTED]> writes:
Building ada with the patch for flag_wrapv fails now with a new
error:
+===GNAT BUG
DETECTED==+
| 4.1.0 20050
On Jun 3, 2005, at 09:02, Florian Weimer wrote:
It probably makes sense to turn on -fwrapv for Ada because even
without -gnato, the behavior is not really undefined:
| The reason that we distinguish overflow checking from other kinds of
| range constraint checking is that a failure of an overfl
On May 30, 2005, at 02:57, Victor STINNER wrote:
I'm using gcc "long long" type for my calculator. I have to check
integer overflow. I'm using sign compare to check overflow, but it
doesn't work for 10^16 * 10^4 :
1 * 1
I see your question went unanswered, however I do th
On May 30, 2005, at 16:50, Florian Weimer wrote:
I'll try to phrase it differently: If you access an object whose bit
pattern does not represent a value in the range given by
TYPE_MIN_VALUE .. TYPE_MAX_VALUE of the corresponding type, does this
result in erroneous execution/undefined behavior?
On Apr 7, 2005, at 13:54, Steve Kargl wrote:
I missed that part of the output. The exceeding
long string of digits caught my attention. Can
you submit a PR?
These routines should really be done as builtins, as almost all
front ends need this facility and we'd fit in with the common
frameworks for
On Apr 7, 2005, at 13:27, Steve Kargl wrote:
Try -fdump-parse-tree. You've given more digits in y than
its precision. This is permitted by the standard. It appears
the gfortran frontend is taking y = 0.49 and the closest
representable nubmer is y = 0.5.
So, why does the test y < 0.5 yield tr
On Apr 7, 2005, at 10:12, Steve Kargl wrote:
On Thu, Apr 07, 2005 at 08:08:15AM -0400, Geert Bosch wrote:
As far as I can seem from this patch, it rounds incorrectly.
This is a problem with the library version as well, I believe.
Which library?
libgfortran, or whatever is used to implement NINT
As far as I can seem from this patch, it rounds incorrectly.
This is a problem with the library version as well, I believe.
The issue is that one cannot round a positive float to int
by adding 0.5 and truncating. (Same issues with negative values
and subtracting 0.5, of course). This gives an error
On Apr 1, 2005, at 16:36, Mark Mitchell wrote:
In fact, I've long said that GCC had too many knobs.
(For example, I just had a discussion with a customer where I
explained that the various optimization passes, while theoretically
orthogonal, are not entirely orthogonal in practice, and that truni
1 - 100 of 111 matches
Mail list logo
