On 10/1/2012 6:09 PM, Steven Bosscher wrote:
I suppose no-one would object if I commit this as obvious at some point?
Index: lra-constraints.c
===
--- lra-constraints.c (revision 191858)
+++ lra-constraints.c (working copy)
@@ -
On 10/8/2012 11:01 AM, Nathan Froyd wrote:
- Original Message -
Btw, as for Richards idea of conditionally placing the length field
in
rtx_def looks like overkill to me. These days we'd merely want to
optimize for 64bit hosts, thus unconditionally adding a 32 bit
field to rtx_def looks
On 10/3/2013 5:10 PM, Joseph S. Myers wrote:
On Wed, 2 Oct 2013, Joern Rennecke wrote:
From my understanding, the condition for adding the current Copyright year
without a source code change is to have a release in that year. Are we
sure 4.9.0 will be released this year?
"release" here incl
On 11/4/2013 2:23 PM, Vladimir Makarov wrote:
The following patch fixes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58967
The removed code is too old. To be honest, I even don't remember why I
added this. LRA has been changed a lot since this change and now it
works fine without it.
Whe
To me the issue is not what is written down about
the policy, but whether the policy works in practice,
and it seems like it does, so what's the problem?
This just seems to be making a problem where
none exists.
On 1/7/2014 8:46 PM, Andrew Pinski wrote:
Correctness over speed is better. I am sorry GCC is the only one
which gets it correct here. If people don't like there is a flag to
disable it.
Obviously in a case like this, it is the programmer who should
be able to decide between fast-and-accepta
On 8/31/2014 4:49 PM, Gerald Pfeifer wrote:
On Fri, 29 Aug 2014, Mike Stump wrote:
These errors are on purpose.
Surprising that someone would not get this obvious clever joke.
-There are many places in which this document is incomplet and incorrekt.
+There are many places in which this docu
Do we really want to quote to this level? This message has 11 levels of
quotes, the most I have ever seen. If everyone does this, the whole
thread is in every message and that seems unnecessary. I don't know if
there are gcc guidelines on this???
On 3/18/2015 9:59 AM, Ilya Enkovich wrote:
201
On 12/10/2014 11:49 AM, Richard Henderson wrote:
On 12/04/2014 01:49 AM, Ilya Tocar wrote:
+ if (!TARGET_AVX512BW || !(d->vmode == V64QImode))
Please don't over-complicate the expression.
Use x != y instead of !(x == y).
To me the original reads more clearly, since it
is of the parallel for
On 12/7/2012 1:56 PM, Mike Stump wrote:
I've noticed that:
$ grep -l '^M' gcc/testsuite/gnat.dg/*
discr36.ads
discr36_pkg.adb
discr36_pkg.ads
discr38.adb
loop_optimization11.adb
loop_optimization11_pkg.ads
loop_optimization13.adb
loop_optimization13.ads
:-( Surely these are just normal text fi
On 12/7/2012 2:09 PM, Mike Stump wrote:
On Dec 7, 2012, at 10:57 AM, Robert Dewar wrote:
On 12/7/2012 1:56 PM, Mike Stump wrote:
I've noticed that:
$ grep -l '^M' gcc/testsuite/gnat.dg/*
discr36.ads
discr36_pkg.adb
discr36_pkg.ads
discr38.adb
loop_opt
On 12/7/2012 2:16 PM, Mike Stump wrote:
Yes, you can strip them, no problem.
Since emails likely crossed paths…. I'm going to give you and Robert a change
to figure out what you'd like to do… I _only_ care about consistency between
contents as seen from svn and git. Stripping ^M can do th
On 12/7/2012 2:50 PM, Arnaud Charlet wrote:
Anyway, I'll let Robert have the final word on this one.
I'm fine with either solution (converting to LF, or marking files binary,
or a mix of both).
Arno
I would convert to LF, I think it causes less confusion
On 6/1/2013 9:52 AM, Jakub Jelinek wrote:
Sorry for nitpicking, but there are various formatting issues.
A number of these formatting issues could be easily detected by
the compiler. It might be really useful to add a switch to do
such detection. For Ada, the GNAT compiler has -gnatyg which
en
On 4/4/2013 1:14 PM, Janus Weil wrote:
As my editor shows, that file uses DOS line endings (\r\n) in some lines and
UNIX ones (\n) in others. In principle, I am for keeping such files to test the
parser.
If one keeps them, please put them into a file that tests for that feature
exclusively,
It may be interesting to look at what we have done in
Ada with regard to overflow in intermediate expressions.
Briefly we allow specification of three modes
all intermediate arithmetic is done in the base type,
with overflow signalled if an intermediate value is
outside this range.
all intermedi
On 4/8/2013 9:15 AM, Kenneth Zadeck wrote:
I think this applies to Ada constant arithmetic as well.
Ada constant arithmetic (at compile time) is always infinite
precision (for float as well as for integer).
On 4/8/2013 9:24 AM, Kenneth Zadeck wrote:
So then how does a language like ada work in gcc? My assumption is
that most of what you describe here is done in the front end and by the
time you get to the middle end of the compiler, you have chosen types
for which you are comfortable to have any
On 4/8/2013 9:23 AM, Kenneth Zadeck wrote:
On 04/08/2013 09:19 AM, Robert Dewar wrote:
On 4/8/2013 9:15 AM, Kenneth Zadeck wrote:
I think this applies to Ada constant arithmetic as well.
Ada constant arithmetic (at compile time) is always infinite
precision (for float as well as for integer
On 4/8/2013 9:58 AM, Kenneth Zadeck wrote:
yes but the relevant question for the not officially static integer
constants is "in what precision are those operations to be performed
in?I assume that you choose gcc types for these operations and you
expect the math to be done within that type,
On 4/8/2013 10:26 AM, Kenneth Zadeck wrote:
My confusion is what you mean by "we"? Do you mean "we" the writer of
the program, "we" the person invoking the compiler by the use command
line options or "we", your company's implementation of ada?
Sorry, bad usage, The gcc implementation of Ada
On 4/8/2013 5:12 PM, Lawrence Crowl wrote:
(BTW, you *really* don't need to quote entire messages, I find
it rather redundant for the entire thread to be in every message,
we all have thread following mail readers!)
Correct me if I'm wrong, but the Ada standard doesn't require any
particular ma
On 4/8/2013 5:46 PM, Kenneth Zadeck wrote:
In some sense you have to think in terms of three worlds:
1) what you call "compile-time static expressions" is one world which in
gcc is almost always done by the front ends.
2) the second world is what the optimizers can do. This is not
compile-time
On 4/8/2013 6:34 PM, Mike Stump wrote:
On Apr 8, 2013, at 2:48 PM, Robert Dewar wrote:
That may be so in C, in Ada it would be perfectly reasonable to use
infinite precision for intermediate results in some cases, since the
language standard specifically encourages this approach.
gcc lacks
On 4/8/2013 7:46 PM, Kenneth Zadeck wrote:
On 04/08/2013 06:45 PM, Robert Dewar wrote:
On 4/8/2013 6:34 PM, Mike Stump wrote:
On Apr 8, 2013, at 2:48 PM, Robert Dewar wrote:
That may be so in C, in Ada it would be perfectly reasonable to use
infinite precision for intermediate results in
On 4/9/2013 5:39 AM, Florian Weimer wrote:
On 04/09/2013 01:47 AM, Robert Dewar wrote:
Well the back end has all the information to figure this out I think!
But anyway, for Ada, the current situation is just fine, and has
the advantage that the -gnatG expanded code listing clearly shows in
Ada
On 2/9/2014 3:00 PM, Richard Sandiford wrote:
We print "[-Wfoo]" after a warning that was enabled by the -Wfoo option,
which is pretty clear. But for warnings that have no -W option we just
print "[enabled by default]", which leads to the question of _what_ is
enabled by default. As shown by:
On 2/9/2014 3:03 PM, Richard Sandiford wrote:
This switches Ada from using [enabled by default] to [warning enabled
by default] for consistency with:
http://gcc.gnu.org/ml/gcc-patches/2014-02/msg00549.html
Tested on x86_64-linux-gnu. OK if the above patch goes in?
I would say hold off on
On 2/9/2014 3:09 PM, Arnaud Charlet wrote:
IMO the natural assumption is that gnu++11 is enabled by default, which is
how Lars also read it.
There seemed to be support for using "warning enabled by default" instead,
so this patch does that. Tested on x86_64-linux-gnu. OK to install?
I'll post
On 2/9/2014 3:10 PM, Richard Sandiford wrote:
Which testsuite do you mean? I did test this with Ada enabled
and there were no regressions.
If you mean an external testsuite then I certainly don't mind
holding off the Ada part. I hope the non-Ada part could still
go in without it though.
I m
On 2/9/2014 3:23 PM, Richard Sandiford wrote:
can't we just reword the one warning where there is an ambiguity to
avoid the confusion, rather than creating such an earthquake, which
as Arno says, really has zero advantages to Ada programmers, and clear
disadvantages .. to me [enabled by default]
On 2/11/2014 4:45 AM, Richard Sandiford wrote:
OK, this version drops the "[enabled by default]" altogether.
Tested as before. OK to install?
Still a huge earthquake in terms of affecting test suites and
baselines of many users. is it really worth it? In the case of
GNAT we have only recently
On 2/11/2014 7:48 AM, Richard Sandiford wrote:
The patch deliberately didn't affect Ada's diagnostic routines given
your comments from the first round. Calling this a "huge earthquake"
for other languages seems like a gross overstatement.
Actually it's much less of an impact for Ada for two r
On 2/11/2014 9:36 AM, Richard Sandiford wrote:
I find it hard to believe that
significant numbers of users are not fixing the sources of those
warnings and are instead requiring every release of GCC to produce
warnings with a particular wording.
Good enough for me, I think it is OK to make th
There's a user's group that works with VMS engineering that wants to
keep using the "C" compiler, so let's keep the config files and non-Ada
specific "C" files. Tristan and I will stay on as maintainers of the
cross port for now.
Why should we continue to maintain these?
On 9/13/2012 8:00 AM, Richard Guenther wrote:
Because doing so would create code generation differences -g vs. -g0.
Sometimes I wonder whether the insistence on -g not changing code
generation is warranted. In practice, gdb for me is so weak in handling
-O1 or -O2, that if I want to debug some
On 9/13/2012 9:38 AM, Jakub Jelinek wrote:
On Thu, Sep 13, 2012 at 09:33:20AM -0400, Robert Dewar wrote:
On 9/13/2012 8:00 AM, Richard Guenther wrote:
Because doing so would create code generation differences -g vs. -g0.
Sometimes I wonder whether the insistence on -g not changing code
, see
my follow on message.
David
On Thu, Sep 13, 2012 at 6:33 AM, Robert Dewar wrote:
On 9/13/2012 8:00 AM, Richard Guenther wrote:
Because doing so would create code generation differences -g vs. -g0.
Sometimes I wonder whether the insistence on -g not changing code
generation is warranted
On 9/13/2012 12:46 PM, Tom Tromey wrote:
"Robert" == Robert Dewar writes:
Robert> Sometimes I wonder whether the insistence on -g not changing code
Robert> generation is warranted. In practice, gdb for me is so weak in handling
Robert> -O1 or -O2, that if I want to debug
On 9/26/2012 4:19 PM, Tom Tromey wrote:
"Florian" == Florian Weimer writes:
Florian> This patch adds support for #pragma GCC warning and #pragma GCC
Florian> error. These pragmas can be used from preprocessor macros,
Florian> unlike the existing #warning and #error directives. Library
Florian
On 7/2/2012 8:35 AM, Alexandre Oliva wrote:
On Jun 30, 2012, David Edelsohn wrote:
IBM's policy specifies a comma:
,
and not a dash range.
But this notation already means something else in our source tree.
I think using the dash is preferable, and is a VERY widely used
notation, us
On 5/14/2012 11:22 PM, Hans-Peter Nilsson wrote:
Random non-maintainer comments: I'd suggest adding a nearby
comment to avoid a future edit changing it back. The attachment
with the patch had the mime-type "Video/X-DV", maybe indicating
an issue with your mail-client setup mismatching the .dif
On 5/18/2012 4:27 PM, Ulrich Weigand wrote:
I finally got some time to look into this in detail. The various special-
case transforms in associate_plusminus all transform a plus/minus expression
tree into either a single operand, a negated operand, or a single plus or
minus of two operands. Th
On 8/18/2011 5:33 AM, Arnaud Charlet wrote:
2011-08-05 Ed Schonberg
* exp_ch4.adb (Expand_N_Type_Conversion): When expanding a
predicate
check, indicate that the copy of the original node does not come from
source, to prevent an infinite recursion of the expansio
On 8/29/2011 4:50 PM, Paolo Carlini wrote:
.. also, you forgot to add 2011 to the Copyright years.
Paolo.
In the GNAT development environment we have an SVN style
checking filter, and this is one of the things it checks
for so we prevent any checkin missing the current year in
the copyright no
On 9/2/2011 8:52 AM, Arnaud Charlet wrote:
Thanks!
In Ada, it's quite natural to end up with a dynamically sized object of
size 0. For instance, if you declare an array with a dynamic bound:
Table : Unit_Table (1 .. Last_Unit);
and Last_Unit happens to be 0 at run-time
Arno
But isn't i
On 9/2/2011 8:58 AM, Arnaud Charlet wrote:
In Ada, it's quite natural to end up with a dynamically sized object of
size 0. For instance, if you declare an array with a dynamic bound:
Table : Unit_Table (1 .. Last_Unit);
and Last_Unit happens to be 0 at run-time
But are we expected to read
On 9/2/2011 9:16 AM, Richard Guenther wrote:
The bootstrap failure showed NULL pointer dereferences (which
probably easily points to the affected part of the RTS).
Might be interesting to pursue, but we don't know that the null
pointers being dereferenced are in fact the ones returned by
alloc
On 9/2/2011 11:47 AM, Michael Matz wrote:
Hi,
On Fri, 2 Sep 2011, Robert Dewar wrote:
On 9/2/2011 9:16 AM, Richard Guenther wrote:
Might be interesting to pursue, but we don't know that the null pointers
being dereferenced are in fact the ones returned by alloca. May not be
worth the e
On 9/6/2011 7:14 AM, Duncan Sands wrote:
this means using as many processes as there are CPUs, right? It
seems pretty dubious to me to use more processes than the user maybe
asked for.
We often find that the optimum number of processes is a little bit more
than the number of physical processe
On 9/17/2011 5:38 AM, Paolo Carlini wrote:
On 09/17/2011 11:27 AM, François Dumont wrote:
Paolo, I know that using float equality comparison is not reliable in
general and I have remove the suspicious line but in this case I can't
imagine a system where it could fail.
As a general policy, in th
On 4/10/2012 1:35 AM, Mike Stump wrote:
So, I'd like to change all the ada testcases to use normal unix line endings.
testsuite/gnat.dg/taft_type2_pkg.ads
is an example if one such file, any objections?
As long as the test is not about line endings this seems fine.
On 11/23/2011 7:31 AM, Rainer Orth wrote:
Tru64 UNIX Ada bootstrap recently got broken:
s-taprop.adb:892:12: access to volatile object cannot yield
access-to-non-volatile type
make[6]: *** [s-taprop.o] Error 1
s-taprop-tru64.adb missed a patch already applied to s-taprop-{irix,
solaris}.adb.
On 1/27/2012 10:57 PM, Sandra Loosemore wrote:
I've checked in this patch as obvious. (Again, if anyone thinks these
kinds of edits are not obvious, let me know, and I'll start posting them
for review first instead.)
Following these dubious hyphenation rules slavishly is not a good idea.
It m
On 1/29/2012 3:40 PM, Richard Henderson wrote:
On 01/30/2012 05:22 AM, Uros Bizjak wrote:
2012-01-29 Uros Bizjak
* config/alpha/alpha.c (alpha_option_overrride): Default to
full IEEE compliance mode for Go language.
I'm not keen on this, but I also don't have an alternative t
On 1/28/2012 12:05 PM, Sandra Loosemore wrote:
I'm specifically asking for review of this patch by one of the docs
maintainers before checking it in, since it seems not everyone agrees
that these copyediting patches qualify as "obvious". In this particular
chunk, I had to make some judgment call
On 1/28/2012 11:33 AM, Sandra Loosemore wrote:
Sometimes the best idea is to just drop the hyphen completetly. It
seems for example (try google) that runtime is becoming much more
accepted than run-time or run time.
Coincidentally, "runtime" is the subject of my next patch chunk, and I
had to
On 2/4/2012 10:06 AM, Gerald Pfeifer wrote:
On Sun, 29 Jan 2012, Robert Dewar wrote:
* config/alpha/alpha.c (alpha_option_overrride): Default to
full IEEE compliance mode for Go language.
It's always worrisome for gcc based languages to default to horrible
performance, it
On 2/17/2012 8:00 PM, Sandra Loosemore wrote:
I've checked in this patch to consistently hyphenate "big-endian" and
"little-endian" when used as adjectives. I observe that Jonathan Swift
also hyphenated "Big-endians" when used as a noun in Gulliver's Travels,
but I did not see any uses of either
On 6/15/2011 5:58 AM, Mark Kettenis wrote:
Over my dead body. On a proper operating system filenames are
case-sensitive. Your suggestion would create spurious matches.
Yes, we all know that Unix systems chose case sensitive, and
are happy to have files differing only by case in the same
dire
60 matches
Mail list logo