On Mar 16, 2005, at 11:23, Richard Stallman wrote:
But what are you saying to those users who don't like it that GNU
programs
abort silently when they discover bugs in themselves? Aren't you
saying
"tough" in a somewhat more polite way?
No, because nobody has complained about it. T
On Apr 16, 2005, at 15:45, Nathan Sidwell wrote:
It's not clear to me which is the best approach. (b) allows threads to
be supported via copious uses of volatile (but probably introduces
pessimizations), whereas (a) forces the thread interactions to be
compiler
visible (but shows more promise for
On Apr 18, 2005, at 18:17, Robert Dewar wrote:
Is there anything in the language specifications (mainly C++ in this
context, but is this an area where C and C++ are going to diverge, or
is C likely to follow suit?) that prohibits spurious writes to a
location?
Surely the deal is that spurious wr
Maybe I should avoid making suggestions that would make the project
more complex, especially since I'm not implementing it, but...
If we can describe the argument types expected for a given format
string, then we can produce warnings for values used but not yet set
(%s with an uninitialized
On Sep 12, 2011, at 19:19, Andrew MacLeod wrote:
> lets say the order of the writes turns out to be 2,4... is it possible for
> both writes to be travelling around some bus and have thread 4 actually read
> the second one first, followed by the first one? It would imply a lack of
> memory co
On Jul 2, 2009, at 06:02, Paul Chavent wrote:
Hi.
I already have posted about the endianess attribute (http://gcc.gnu.org/ml/gcc/2008-11/threads.html#00146
).
For some year, i really need this feature on c projects.
Today i would like to go inside the internals of gcc, and i would
like to
On Jul 2, 2009, at 16:44, Michael Meissner wrote:
Anyway I had some time during the summit, and I decided to see how
hard it
would be to add explicit big/little endian support to the powerpc
port. It
only took a few hours to add the support for __little and __big
qualifier
keywords, and in
On Feb 29, 2008, at 19:13, Richard Guenther wrote:
We wrap the libcalls inside libcall notes using REG_EQUAL notes
which indicate the libcalls compute non-trapping +-* (there's no
RTX code for the trappingness), so we combine and simplify the
operations making the libcall possibly dead and remove
This looks like interesting work, and I hope something like this gets
folded into a release soon. A few things occurred to me when reading
the writeup at google (sorry, I haven't started looking through the
code much yet):
All the examples seem to be C++ oriented; is it, in fact, a goal fo
- compile with the loop unrolled 1x, 2x, 4x, 8x, 16x, 32x and
measure the time the benchmark takes
The optimal unrolling factor may not be a power of two, depending on
icache size (11 times the loop body size?), iteration count (13*n for
some unknown n?), and whether there are actions perf
On Jul 27, 2007, at 07:54, Diego Novillo wrote:
+Note that individuals who maintain parts of the compiler as reviewers
+need approval changes outside of the parts of the compiler they
+maintain and also need approval for their own patches.
s/approval changes/approval for changes/ ?
I've been looking at -ftrapv and some simple cases it doesn't work
right in. (I've got a patch coming soon to address one case where
__addvsi3 libcalls and the like get optimized away in RTL.)
I see a few reports in Bugzilla, many marked as duplicates of PR
19020 though they cover a few di
12 matches
Mail list logo
