On 03/03/2011 05:26 PM, Diego Novillo wrote:
On Thu, Mar 3, 2011 at 00:27, Paolo Bonzini wrote:
On 03/02/2011 10:00 PM, Ian Lance Taylor wrote:
That does not sound like the right approach to me. Why not add the new
flags to GCC_FOR_TARGET at top-level? It seems to me that
GCC_FOR_TARGET
On 03/04/2011 04:03 PM, Diego Novillo wrote:
Sure, but my question was whether I should prepare a patch to fix the
current lack of consistency between the two definitions.
Certainly. I'm not sure it would be acceptable for 4.6, but it is worth
posting it.
Paolo
On 03/03/2011 05:31 PM, Joern Rennecke wrote:
CUMULATIVE_ARGS is a target-dependent type, and thus every use of it
in the interface of target hooks should be considered a bug.
The very presence of CUMULATIVE_ARGS in the interface is a bug, but I
don't see why introducing more uses should be f
On 03/10/2011 04:47 PM, Nathan Froyd wrote:
[moving to gcc@ to get input from a wider audience]
On Thu, Mar 10, 2011 at 06:47:20AM +0100, Hans-Peter Nilsson wrote:
From: Nathan Froyd
On Thu, Mar 10, 2011 at 04:02:27AM +0100, Hans-Peter Nilsson wrote:
PS. If you really feel for it, I won't stop
On 03/22/2011 08:51 PM, Joseph S. Myers wrote:
Why do a great many targets disable libgcj by default in the toplevel
configure.ac?
Because that dates to before 2004, which IIRC is when toplevel
configure.ac started looking at config-lang.in files.
Paolo
These targets are using -Os to build target libraries. Perhaps the
right thing to do instead would be to disable some optimizations
selectively in the compiler?
Thanks!
Paolo
On 03/27/2011 06:27 AM, Ian Lance Taylor wrote:
Nathan Boley writes:
In a much larger application, I was getting a weird segfault that an
assignment to a temporary variable fixed. I distilled the example into
the attached "test_case.c". When I run test_case.c under valgrind I
get a memory read
On 03/28/2011 01:06 PM, Richard Guenther wrote:
/* GCC uses 8-byte loads and register passing even though sizeof = 6 */
typedef struct __attribute__((__packed__))
{
unsigned chr:16;
unsigned loc:32;
} GENOME_LOC_TYPE_2;
//#define GENOME_LOC_TYPE GENOME_LOC_TYPE_1
#d
On 03/28/2011 02:27 PM, Michael Matz wrote:
unit size
align 8 symtab 0 alias set -1 canonical type 0x75b29540
which looks ok to me.
It already isn't, why is the alignment 8 if __alignof__
(GENOME_LOC_TYPE_2) is 1?
The aligns are printed in bits. It really is okay
On 03/29/2011 01:33 PM, Joseph S. Myers wrote:
But some of
those bug reports refer to target libiberty - which I still maintain
should never be built by GCC - and some to target zlib, which I think
should only be relevant when building Java.
Agreed on both counts.
Paolo
On 03/30/2011 05:54 PM, Joseph S. Myers wrote:
Thanks. My inclination is to say that this should be considered an
independent tool in its own repository, as something not required in the
build of any of the other tools. More specifically, utils/mep and
utils/wince look like independent tools ea
On 03/30/2011 05:15 PM, Joseph S. Myers wrote:
On Tue, 29 Mar 2011, Joseph S. Myers wrote:
Specifically, I propose removal of all support for building: ash autoconf
automake bash byacc bzip2 diff dosutils fileutils findutils find gawk
gettext gnuserv gzip hello indent libiconv libtool make mmal
On 04/27/2011 03:28 PM, Yuan Pengfei wrote:
Any other advice will be appreciated.
I think you can look into llvm-clang. It compiles faster and uses
much less memory than gcc.
It is also a completely different compiler. It doesn't make sense to
compare the two, unless Dimitrios wants to rewr
On 04/29/2011 04:15 PM, Nathan Froyd wrote:
> * cxx_binding should be 16 bytes, not 20.
Not your fault, but comments like this on SpeedupAreas are so opaque as
to be useless. *Why* should cxx_binding be 16 bytes? Should we take
the next member out and have a VEC someplace instead of chaining?
On 05/21/2011 08:07 AM, Matt Turner wrote:
I suppose this is a missed optimization. Is this known, or should I
make a new bug report?
It's always better to do that. In this case, the bug is that when we
compute a range from an ASSERT_EXPR, and the base variable has a known
but symbolic range
On 06/28/2011 03:52 PM, Vladimir Makarov wrote:
They are complicated, solving NP-problems in heuristic ways.
I totally trust that people like Eric or Richard would _not_ approve
changes to those heuristics without contacting you or others.
On the other hand, I would totally trust them to app
On 07/05/2011 06:58 PM, Dimitrios Apostolou wrote:
The level of my understanding of this part is still basic, I've now only
scratched the surface of Dataflow Analysis.
Well you're not looking at df proper, which is mostly a textbook
implementation with some quirks; you're looking at RTL operan
On 07/11/2011 07:56 PM, David Malcolm wrote:
Hope this is fun/helpful (and that I'm correctly interpreting the data!)
You are, and it shows some bugs even. gimple_lcx is obviously destroyed
by expand, and I find it unlikely that no pass ever introduces a
critical edge...
Paolo
On 07/12/2011 08:54 AM, Arnaud Charlet wrote:
>> I'm not sure because I don't think we want to compile the C files of the Ada
>> > runtime with the C++ compiler. We want to do that only for the compiler.
>
> Right, we definitely don't want to use the C++ compiler for building the
> Ada run-time.
On 07/12/2011 10:00 AM, Eric Botcazou wrote:
But your patch isn't necessary to do that, the C files are already compiled
with the C++ compiler as of today; the only issue is at the linking stage.
The problem is that the patches links gnattools unconditionally with
g++. It should depend on --e
On 07/12/2011 10:43 AM, Paulo J. Matos wrote:
Hope this is fun/helpful (and that I'm correctly interpreting the data!)
You are, and it shows some bugs even. gimple_lcx is obviously destroyed
by expand, and I find it unlikely that no pass ever introduces a
critical edge...
But the diagram s
On 07/12/2011 06:07 PM, David Malcolm wrote:
On this build of GCC (standard Fedora 15 gcc package of 4.6.0), the
relevant part of cfgexpand.c looks like this:
struct rtl_opt_pass pass_expand =
{
{
RTL_PASS,
"expand", /* name */
[...snip...]
PROP_ssa | PROP_g
On 07/13/2011 12:54 PM, Richard Guenther wrote:
> Yes, PROP_gimple_lcx needs to be added to PROP_trees. I cannot approve the
> patch, unfortunately.
Hm, why? complex operations are lowered after a complex lowering pass
has executed. they are still lowered on RTL, so I don't see why we need
On 07/14/2011 11:11 AM, Richard Guenther wrote:
>> Hm, why? complex operations are lowered after a complex lowering pass
>> has executed. they are still lowered on RTL, so I don't see why we need
>> to destroy them technically.
>
> Because it's PROP_*gimple*_lcx.:)
Shouldn't it then be PR
On 07/25/2011 06:42 AM, Xinliang David Li wrote:
FYI the performance impact of this option with SPEC06 (built with
google_46 compiler and measured on a core2 box). The base line number
is FDO, and ref number is FDO + reorder_with_partitioning.
xalancbmk improves> 3.5%
perlbench improves> 1.5
On 07/27/2011 06:51 AM, Xinliang David Li wrote:
> If we could retain most of the speedups when the optimization works well
> but avoid most of the slowdown in the benchmarks that are currently hurt,
> we could improve the overall SPEC06 score. And hopefully, this would
> also be beneficial
On 07/27/2011 06:42 PM, H.J. Lu wrote:
+ if (max == 64)
+ var_mask_1[var] = "1LL"
This must be ((HOST_WIDE_INT)1).
Paolo
On 08/04/2011 01:10 PM, Andrew Haley wrote:
>> It's the sort of thing that gets done in threaded interpreters,
>> where you really need to keep a few pointers in registers and
>> the interpreter itself is a very long function. gcc has always
>> done a dreadful job of register allocation in s
On 08/08/2011 10:06 AM, Richard Guenther wrote:
Like if
register unsigned char *ip;
would increase spill cost of ip compared to
unsigned char *ip;
?
Remember we're talking about a function with 11000 pseudos and 4000
allocnos (not to mention a 1500 basic blocks). You cannot really blame
On 08/17/2011 07:52 AM, Richard Sandiford wrote:
cost = rtx_cost (SET_SRC (set), SET, speed);
return cost> 0 ? cost : COSTS_N_INSNS (1);
This ignores SET_DEST (the problem I'm trying to fix). It also means
that constants that are slightly more expensive than a register --
somewhere in th
Hi all,
sync builtins are described in the documentations as being full memory
barriers, with the possible exception of __sync_lock_test_and_set.
However, GCC is not enforcing the fact that they are also full
_optimization_ barriers. The RTL produced by builtins does not in
general include a
On 09/09/2011 10:17 AM, Jakub Jelinek wrote:
> Is the above analysis correct? Or should the users put explicit
> compiler barriers?
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
On 09/09/2011 04:22 PM, Andrew MacLeod wrote:
Yeah, some of this is part of the ongoing C++0x work... the memory model
parameter is going to allow certain types of code movement in optimizers
based on whether its an acquire operation, a release operation, neither,
or both.It is ongoing and
On Sat, Sep 10, 2011 at 03:09, Geert Bosch wrote:
> For example, for atomic objects accessed only from a single processor
> (but possibly multiple threads), you'd not want the compiler to reorder
> memory accesses to global variables across the atomic operations, but
> you wouldn't have to emit
On 09/11/2011 04:12 PM, Andrew MacLeod wrote:
tail->value = othervalue // global variable write
atomic_exchange (&var, tail) // acquire operation
although the optimizer moving the store of tail->value to AFTER the
exchange seems very wrong on the surface, it's really
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_cst we'll need a full
barrier, and for the others there is a partial barrier.
If
On 09/12/2011 01:22 AM, Andrew MacLeod wrote:
You're right that using lock_test_and_set as an exchange is very wrong
because of the compiler barrier semantics, but I think this is
entirely a red herring in this case. The same problem could happen
with a fetch_and_add or even a lock_release opera
On Mon, Sep 12, 2011 at 20:40, Geert Bosch wrote:
> Assuming that statement is true, that would imply that even for relaxed
> ordering there has to be an optimization barrier. Clearly fences need to be
> used for any atomic accesses, including those with relaxed memory order.
>
> Consider 4 threa
On Tue, Sep 13, 2011 at 03:52, Geert Bosch wrote:
> No, it is possible, and actually likely. Basically, the issue is write
> buffers.
> The coherency mechanisms come into play at a lower level in the
> hierarchy (typically at the last-level cache), which is why we need fences
> to start with to i
On 09/15/2011 06:19 PM, Richard Henderson wrote:
I wouldn't go that far. They *used* to be compiler barriers,
but clearly something broke at some point without anyone noticing.
We don't know how many versions are affected until we debug it.
For all we know it broke in 4.5 and 4.4 is fine.
4.4
On 09/15/2011 06:26 PM, Paolo Bonzini wrote:
There's no reference to a GCC bug report about this in the thread.
Did the folks over at the libdispatch project never think to file one?
I asked them to attach a preprocessed testcase somewhere, but they
haven't done so yet. :(
On 09/28/2011 02:14 PM, Georg-Johann Lay wrote:
This leads to unpleasant code. The machine can access all RAM locations by
direct addressing. However, the resulting code is:
foo:
ldi r24,lo8(-86) ; 6 *movqi/2[length = 1]
ldi r30,lo8(-64) ; 34 *movhi/5
On 10/20/2011 07:46 PM, Paulo J. Matos wrote:
However, it failed to compile libgcc with:
../../../../../../../devHost/gcc46/gcc/libgcc/../gcc/libgcc2.c:272:1:
internal compiler error: in df_uses_record, at df-scan.c:3178
This feels like a GCC bug. I will try to get a better look at it tomorrow.
On 11/21/2011 01:54 AM, Richard Henderson wrote:
> Emulating TLS has nothing to do with exception-handling, nor is
> there something that might throw while calling one of its
> functions.
>
> Ok to fix that?
Not without further study. There was a reason we wanted these
in libgcc_eh.a. I c
On 01/03/2012 09:48 AM, Jim Meyering wrote:
Paolo Bonzini wrote:
* bootstrap.conf: Add isatty module.
* gnulib: Update to latest.
* lib/colorize.h: Remove argument from should_colorize.
* lib/ms/colorize.h: Likewise.
* lib/colorize-impl.c: Factor isatty call out of here...
* lib/ms/colorize
As you can see, the compiler uses r9 to store data and then uses that
for data[0] but also loads in r7 data+8 instead of directly using r9.
If I remove the loop then it does not do this.
This optimization is done by CSE only, currently. That's why it cannot
look through loops.
Paolo
On 07/14/2009 10:31 PM, Jean Christophe Beyler wrote:
Ok, so actually, my cpu.h file had some of those included. I've
removed them and am now filling in the constraints.md file with what
is needed. I also so that they were obsolete in the GCC internals,
I'll be moving everything to the constraint
On 07/14/2009 09:17 PM, Benjamin Kosnik wrote:
Hey Ralf! Saw your message about updating gcc/src to current auto
tools, in favor. But, it looks like the autoconf 2.64 release is not
out, last I see is 2.63b at the end of March. This and
confirmation of --with-build-sysroot working seem to be the
On 07/15/2009 09:36 PM, Joseph S. Myers wrote:
Before moving something out to a plugin (if we think that is technically
appropriate for the particular code in question) we should have a way to
build code, set up to be built as a plugin, into the compiler so that the
-fplugin options find the buil
On 07/15/2009 10:47 PM, Joseph S. Myers wrote:
Unless libltdl can be statically linked in, using it is a bad idea for
other reasons as previously discussed at length.
I know of no program that dynamically links to libltdl, actually.
Paolo
Gregory Casamento wrote:
> All,
>
> Hey guys I'm wondering if there's a timeline for incorporating the
> Objective-C 2.0 changes from Apple into the trunk of GCC.
>
> If not, I would like to know what the GNUstep project can do to help
> make this happen.
No. But you just have to take patch
Gregory Casamento wrote:
> As far as I'm aware apple has an assignment for changes to gcc, so it
> should be possible to pull them in.
You're not forced to assign changes that you do not want to assign.
Paolo
On 07/22/2009 10:57 AM, Richard Guenther wrote:
On Tue, Jul 21, 2009 at 11:14 PM, Paolo Bonzini wrote:
Gregory Casamento wrote:
As far as I'm aware apple has an assignment for changes to gcc, so it
should be possible to pull them in.
You're not forced to assign changes that you d
What is the process for getting a blob of code assigned to the FSF that
is not just being committed into the tree?
Creating a branch on gcc.gnu.org and committing it there should be enough.
Paolo
On 07/22/2009 09:17 PM, Kai Tietz wrote:
Hello,
Possibly somebody could give me a hint what the issue here is. In the
patch I attached, I enable multilib for x86 default mingw target
(i686-w64-mingw32). The core compilers are translating nicely. But
when it tries to build libgcc by -m64 it throw
Am i missing something?
No, it is a bug due to the build-with-C++ patches. Please file a PR
and, in the meanwhile, try --enable-stage1-languages=c,c++ or
--enable-build-with-cxx.
Thanks!
Paolo
Am i missing something?
No, it is a bug due to the build-with-C++ patches. Please file a PR
and, in the meanwhile, try --enable-stage1-languages=c,c++
That seemed to work, thanks, bootstrap has gotten past my old problem.
Ah, I was too quick, it failed again at the next bootstrap stage.
But if I change the run-time library, I still have to license those
changes under the GPLv3 if I want to distribute them, right?
Yes. But if you change the runtime library and link something else with
the modified runtime library, the "something else" does not fall
automatically under the G
b) you should ignore all such discussions, since they invariablly
include lots of legal-sounding opinions from people who are not
lawyers and don't know, and often have significant misconceptions.
Indeed I'm not answering to Florian's latest message, because I'm not
sure what he misunderstood o
On 07/27/2009 12:25 PM, Robert Dewar wrote:
Laurent GUERBY wrote:
if Dynamic_N >= T'First and Dynamic_N > T'Last then
Huh? I can't understand the first comparison.
Actually Ada is not Fortran-66 and allows empty loops, no?
Ada for loop over "A .. B" will be empty if "A > B" and we obviously
On 07/25/2009 10:53 PM, Florian Weimer wrote:
The run-time library is GPL version 3 or
later, which is incompatible with GPL version 2, so it is not
permitted to link this with the GPLv2-only program and distribute the
result. (Previous discussions have centered on infringing GCC's
license, so t
For example, gdb has function that in the past could return null, but
which now cannot. So, I'd like to find all places where the return
result is checked.
Or, gdb has a TRY_CATCH macro which expands to a couple of nested loops.
It is not ok to 'return' or 'goto' from inside the inner loop, as t
Tom> I looked into this a little. It looks like the PPL checks don't work
Tom> properly in the case where PPL is a system library. I guess I need
Tom> --with-ppl=/usr ... I will try that later.
I don"t know really how to fix that quickly! I must confess that
autoconf related files in GCC scare
On 08/03/2009 03:52 PM, Unruh, Erwin wrote:
2) Is this a bug?
I think it's a bug in the specification.
User-specified CFLAGS are always passed last in the Makefiles (at least
for Automake, but it is a good practice in general) so that the user can
override options like -D, -U, -O, -g, -f, -m
In any case, if you build with -g and use in addition the "debug
assembler output" flag -dA the assembler output should contain
human-readable comments containing line number information.
Regardless, if line number notes are interspersed in the stream,
maybe whenever I write out an assembler i
Ok, after a few false leads, I found something that produced a
pleasing result. Fantastic I should say!
With this mod:
C:\devel\gcc\gcc>cvs diff debug.c
Index: debug.c
===
RCS file: c:\cvsroot/gcc/gcc/debug.c,v
retrieving revision 1
I chose to define Pmode as PDImode, and write PDI patterns for pointer
moves & arithmetic. POINTER_SIZE is 64 bits, UNITS_PER_WORD is 4.
FUNCTION_ARG_ADVANCE arranges for both SImode and PDImode values to
occupy a single register. I have the port mostly working (passes 90% of
execution tests), b
On 08/16/2009 06:02 PM, Martin Guy wrote:
Yes, GCC is bigger and slower and for several architectures generates
bigger, slower code with every release, though saying so won't make
you very popular on this list! :)
But surprise, if you report a bug, chances are it will be fixed
(especially for
On 08/17/2009 02:32 PM, ami_stuff wrote:
Hi,
Works fine for me. gcc.dg/tree-ssa/loop-6.c is unswitched with -O3
but not with -O3 -fno-unswitch-loops.
This one works for me too.
Could you try to compile "deflate.c" from libz?
Here are my results:
-m68060 -O3 -fno-unswitch-loops
On 08/17/2009 03:33 PM, ami_stuff wrote:
-m68060 -O3 -fno-unswitch-loops
and
-m68060 -O2 -finline-functions -fgcse-after-reload -ftree-vectorize
-fpredictive-commoning
Some heuristics are tuned differently for -O2 and -O3. The only way to
know is to look at the dumps.
Paolo
My experience is that fold-const.c requires 20 MB of memory (not
including the size of the executable) to compile with -Os. That's
the biggest.
Is that typical/expected?
It doesn't seem too big.
Because it just occurred to me that maybe the lack of a "normal"
implementation of alloca() is cau
1) Stop abusing current GC by allocating structures there that GC
knows nothing about, i.e. there is never a path from GC roots to any
variables of that type and so gengtype does not produce markers it.
That's good.
BTW, it does not deal with types that in some instances have variables
alloc
On 08/21/2009 10:52 AM, Laurynas Biveinis wrote:
Trees and rtxes mostly. I haven't got around to taking a closer look,
but for example folders love allocating temporary trees. For example,
in tree-ssa-ccp.c:fold_gimple_assign,
if (COMPARISON_CLASS_P (op0))
{
Argh. Very sorry for the breakage, I'll get straight onto it. What
versions of the mingw+msys tools are you using? Can you please send me a copy
of the generated libtool script, and the output you get when re-running the
failing libtool command manually after adding the "--debug" (non-modal)
On 08/26/2009 12:38 PM, Dave Korn wrote:
Oops. Looks like there are different versions of SED that have different
requirements, because on cygwin SED 4.1.5, you*have* to quote the comma in
the curly-braces {min,max} repetitions specifier or it is interpreted as a
separator.
Right. I also
On 08/26/2009 12:48 PM, Dave Korn wrote:
Dave Korn wrote:
Also please single-quote the commands.
Ok, why?
BTW should I do that for all four of the patterns? And what about $dirname
and $basename, and the couple of dozen other locations in ltmain.sh that use
quoted sed scripts? (You
Patterns should not include the separator (unless escaped), even
as part of a character class. In conformance with Posix, the Cray
`sed' rejects `s/[^/]*$//': use `s,[^/]*$,,'.
[...]
Portable `sed' regular expressions should use `\' only to escape
characters in the s
When I worked at AMD, I was starting to suspect that it may be more beneficial
to re-enable the first schedule insns pass if you were compiling in 64-bit
mode, since you have more registers available, and the new registers do not
have hard wired uses, which in the past always meant a lot of spil
On 08/31/2009 08:54 PM, Ralf Wildenhues wrote:
While still working to prove Bob wrong on the fixincludes sed issues,
Bob?
- require a better sed,
- split the script in two inside Autoconf (if $extrasub is nonempty),
- allow for extra sed scripts here.
Like a new variable $ac_presub, that is
In fact, I think this API shouldn't be even more encouraged. It doesn't
really fix things in an elegant way, and it doesn't help for other
pending issues in the GCC tree (such as the multilib fixups that aren't
applied in all cases; report coming up).
I agree. However, I did not have any alter
On 08/31/2009 10:41 PM, Ralf Wildenhues wrote:
* Paolo Bonzini wrote on Mon, Aug 31, 2009 at 10:00:01PM CEST:
In fact, I think this API shouldn't be even more encouraged. It doesn't
really fix things in an elegant way, and it doesn't help for other
pending issues in the GCC tr
On 08/31/2009 11:11 PM, Ralf Wildenhues wrote:
The easiest for now would be (3), the coolest, most difficult and
probably most dangerous one would be (2). Something like
AC_CONFIG_FILES_COMMANDS(some/Makefile, more-user-commands,
[more-init-cmds])
but then the ord
Currently I still have these problems:
*) There is apparently some plugin framework in the works. Can this
functionality implemented as a plugin?
No, plugins do not affect the backend.
*) The stack alignment code + msvc_prologue is used by Wine on osx though.
Currently I pop %ebp after the 5 b
On 09/03/2009 12:27 AM, Kai Tietz wrote:
2009/9/3 Paolo Bonzini:
if (TARGET_64BIT
? !is_attribute_p ("msvc_prologue", name))
: is_attribute_p ("msvc_prologue", name))
{
warning (OPT_Wattributes, "%qE attribute not available for "
I don't know, I was just reworking Stefan's patch. He didn't include
function names (-p) in the patch so I don't know what function this is
part of.
It was ix86_handle_abi_attribute. I'm usually using git, and don't like cvs
and svn too much. It seems svn diff doesn't support a -p option here. M
#include
void foo (int a, int b, void (*hook) (int aa, int bb, int cc))
{
b += a;
hook (a, b, a + b);
}
void qq (int a)
{
auto void q1 (int aa, int bb, int cc);
void q1 (int aa, int bb, int cc)
{
printf ("%d %d %d\n", a, aa + bb, cc);
}
foo (a, a + 1, q1);
}
int main(
I guess the error isn't about the const_int 0, but about operand 0. Any ideas?
Yes, you need this:
[(set (match_operand:SI 0 "register_operand" "=r")
(match_operand:SI 1 "register_operand" "r"))
(unspec_volatile [(const_int 0)] UNSPECV_VSWAPMOV)]
Paolo
Yes, you need this:
[(set (match_operand:SI 0 "register_operand" "=r")
(match_operand:SI 1 "register_operand" "r"))
(unspec_volatile [(const_int 0)] UNSPECV_VSWAPMOV)]
That works, thanks!
I just found the "=r" and "r" stuff myself almost at the same time your mail
arriv
On Fri, Sep 4, 2009 at 16:35, Stefan Dösinger wrote:
> Am Friday 04 September 2009 14:49:42 schrieb Stefan Dösinger:
>> I attached another version of the patch - I restarted the compile, so I
>> still don't know if it fully works.
> Seems to be working - gcc compiles fine, my test function has the
On 09/06/2009 11:15 AM, Stefan Dösinger wrote:
Am Saturday 05 September 2009 17:08:19 schrieb Ross Ridge:
If this patch is essentially only for one application, maybe the idea
of implementing a more generally useful naked attribute would be the
way to go. I implemented a naked attribute in my p
Hopefully the combined wisdom on this list can help getting this
addressed (one way or the other). :-)
I can see five cases:
1) Some of these have requested gcc.gnu.org access only to be
"bugmasters", for example they have no commits.
>dalecki (Marcin Dalecki )2006-1
On 09/14/2009 02:13 PM, Ryan Mansfield wrote:
Paolo Bonzini wrote:
4) some might fall under 2 or 3. Actually just one; he used to be at
QNX, couldn't find any data after 2005 on qnx.com but I'm CCing him:
> gp (Graeme Peterson ) 2003-08-06 3
Graeme left QNX back in 2006. He re
And http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39886
This one is relatively rare, so no. Feel free to pick up the patch, I
already have too many approved patches that I cannot get round to test
and commit.
Paolo
reg.field1 = val1, reg.field2 = val2;
would then turn into fetch, mask with a combined mask of field1 and
field2, or val1, or val2, store.
You can also do the RMW yourself: declare the register volatile, but not
the fields of it, and copy in/out of the register manually.
volatile struct re
On 09/20/2009 06:31 PM, Richard Guenther wrote:
On Sun, Sep 20, 2009 at 6:10 PM, Andreas Schwab wrote:
Why is postreload converting (set (REGX) (CONST_INT A)) ... (set (REGX)
(CONST_INT B)) into (set (STRICT_LOW_PART (REGX)) (CONST_INT B))? That
looks like a pessimisation especially if the con
On 09/23/2009 10:44 AM, Yuri Gribov wrote:
Hi all,
This is my first post to the list so do not be too harsh)
I have expected all c-torture tests to be highly portable but I have
recently ran into test which relies on int being 32-bit
(execute/980526-2.c).
Yes, it's possible that 64-bit ints a
On 08/08/2009 11:59 PM, Sriraman Tallam wrote:
Hi,
Here is a patch to eliminate redundant zero-extension instructions
on x86_64.
The code looks nice! However, since it is very specific to x86 (and x86
patterns), I'd rather see it in the i386 machine-dependent reorg pass.
Thanks!
Paol
On 09/24/2009 08:14 AM, Ian Lance Taylor wrote:
I don't agree with this. If we want this code to be x86_64 specific,
then it should be done by having the i386 backend add the pass to the
pass manager, much as plugins can add a pass. Adding stuff to
md-reorg is a step backward.
That's true. H
On 09/24/2009 08:24 AM, Ian Lance Taylor wrote:
We already have the hooks, they have just been stuck in plugin.c when
they should really be in the generic backend. See register_pass.
(Sigh, every time I looked at this I said "the pass control has to be
generic" but it still wound up in plugin.c
On 09/24/2009 02:41 PM, Mohamed Shafi wrote:
How can i overcome this error?
Remove the guilty alternatives, for example the d/L alternative, and
make operand 2 a register_operand.
Paolo
301 - 400 of 1079 matches
Mail list logo
