On 07/05/2011 01:54 AM, Alan Modra wrote:
Before that, fwprop never tries to work on hard registers.
I question this claim. It seems to me that fwprop did look at
paradoxical subregs of hard regs before my change.
That wasn't part of the design anyway. The main purpose of fwprop's
On 07/05/2011 10:51 AM, Richard Sandiford wrote:
The patch is okay as far as I'm concerned, but I'm not a maintainer of
fwprop.
You probably should be:-)
I'd have no problem with that!
Paolo
On 07/05/2011 01:52 PM, Rainer Orth wrote:
Instead of nested cases, I'd rather use one i[34567]86-*-linux* case and
another for the rest, duplicating extra_parts and tmake_file. Same for
x86_64-*-linux* vs. the rest.
But that's just me.
I agree.
Paolo
On 07/05/2011 02:13 PM, Thomas Schwinge wrote:
Hallo!
On Tue, 05 Jul 2011 13:52:08 +0200, Rainer Orthr...@cebitec.uni-bielefeld.de
wrote:
Like this? [...]
Instead of nested cases, I'd rather use one i[34567]86-*-linux* case and
another for the rest, duplicating extra_parts and tmake_file.
On 07/01/2011 01:58 PM, Stubbs, Andrew wrote:
Given this test case:
unsigned long long
foo (unsigned long long a, signed char *b, signed char *c)
{
return a + *b * *c;
}
Those rules say that it should not be suitable for optimization because
there's an implicit cast from
On 07/01/2011 03:30 PM, Stubbs, Andrew wrote:
However, perhaps there is a catch. We can do the following thought
experiment. What would happen if you had multiple widening multiplies?
Like 8-bit signed to 64-bit unsigned and then 64-bit unsigned to 128-bit
unsigned? I believe in this
On 07/01/2011 04:55 PM, Stubbs, Andrew wrote:
What about (u128)c + (u64)((s8)a * (s8)b)? You cannot convert this to
(u128)c + (u128)((s8)a * (s8)b).
Oh I see, sorry. Yes, that's exactly what I'm trying to do here.
No, wait, I don't see. Where are these multiple widening multiplies
you're
On 06/27/2011 01:32 PM, Rainer Orth wrote:
Support libmudflap on Solaris (PR libmudflap/38738)
http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01446.html
This needs the mudflap maintainer.
Build changes are okay, the rest is pretty obvious.
For pass-stratcliff I'd rather use
On 06/21/2011 12:04 PM, Rainer Orth wrote:
For md_unwind_header on the other hand, you'd have almost as many cases
as in the general case. I fear it's hard to have the configuration
split over too many places. So I'd suggest to split the affected cases
into Linux and non-Linux ones, with the
On 06/20/2011 02:24 PM, Rainer Orth wrote:
* The only unwinder-related macro I haven't moved is
LIBGCC2_UNWIND_ATTRIBUTE. It is only defined gcc/config/mips/mips.h.
I suppose we would need a libgcc equivalent of tm.h for that,
something I didn't want to attack at this point.
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
On 06/23/2011 04:41 PM, Andrew Stubbs wrote:
I believe this should be legal as long as the top bit of both inputs is
guaranteed to be zero. The code achieves this guarantee by
zero-extending the inputs to a wider mode (which must still be narrower
than the output mode).
Yes, that's correct.
Ok without the commented info evaluation, and with the per-target
macro renamed to c_flags-$.
Thanks,
Paolo
2011/6/20, Rainer Orth r...@cebitec.uni-bielefeld.de:
The following patch
[build, libgcc] Correctly apply c_flags in shared-object.mk
Why are you not changing the gcc_AC_ macro and instead introducing
duplicate code? Perhaps the right solution is to add a final argument
to the AC_RUN_IFELSE macro (don't know, I should be on holiday and
hence I do not have the source code at hand :)); in any case this is
_not_ how you add tests
On 06/08/2011 08:02 AM, Douglas B Rupp wrote:
Reformulated as per your suggestion, and retested.
OK to commit?
Yes, thanks!
Paolo
On 06/07/2011 05:30 PM, Rainer Orth wrote:
So my view is that you should define __LIBGCC_TRAMPOLINE_SIZE__, only if
-fbuilding-libgcc.
I can give it a try if I can figure out how to define -fbuilding-libgcc
via the option handling machinery. I just want to avoid having to
implement too
On 06/06/2011 04:17 AM, Bruce Korb wrote:
It also caused a code analysis tool to wander off into the weeds.
And x, break; didn't? :)
(First time I see it, I swear).
Paolo
On 06/06/2011 11:17 AM, Rainer Orth wrote:
* Instead of __FreeBSD__, one could use HAVE_SYSCTLBYNAME instead, but
that would need a new libgcc config.h header. In addition, we might
have to check for kern.stackprot to make sure the code really works.
* Similarly, instead of testing
On 06/06/2011 11:32 AM, Rainer Orth wrote:
On top of the IRIX 6 toplevel libgcc move, I noticed that IRIX doesn't
use crtfastmath.o yet. This patch corrects this, bootstrapped without
regressions on mips-sgi-irix6.5.
While doing this, I noticed that libgcc/config/mips/t-crtfm is identical
On 06/03/2011 04:35 PM, Rainer Orth wrote:
Apart from those changes, the patch addresses the PowerPC Darwin and
Windows32 issues as suggested:
* rs6000/darwin-unwind.h is wrapped in !__LP64__, while removing the
need for the !DARWIN_LIBSYSTEM_HAS_UNWIND test (only defined on Darwin
9 and
On 06/03/2011 05:45 PM, Rainer Orth wrote:
Paolo Bonzinibonz...@gnu.org writes:
Seems like a plan, but I didn't go in this direction since I couldn't
test anything like this.
As long as you test the general configury on 1-2 platforms, it's not any
less tested than what you have now.
On 06/03/2011 05:11 PM, Rainer Orth wrote:
Bootstrapped without regressions on i386-pc-solaris2.11, ok for
mainline? I suppose this is obvious.
The patch is okay, I'll look at the rest next week.
Paolo
On 05/30/2011 07:54 PM, Kai Tietz wrote:
-/* For 64-bit Windows we can't use DW2 unwind info. Also for multilib
- builds we can't use it, too. */
-#if !TARGET_64BIT_DEFAULT !defined (TARGET_BI_ARCH)
-#define MD_UNWIND_SUPPORT config/i386/w32-unwind.h
-#endif
-
/* This matches
On 05/30/2011 05:43 PM, Rainer Orth wrote:
+md-unwind-support.h: config.status
+ if test -n $(md_unwind_header); then \
+ echo #include \config/$(md_unwind_header)\ $@; \
+ else \
+ : $@; \
+ fi
Can you add a default file md-unwind-none.h and use
On 05/30/2011 05:59 PM, Rainer Orth wrote:
This is my hopefully last patch for toplevel libgcc moves: it moves
ENABLE_EXECUTE_STACK to $target-lib.h headers in libgcc/config. Since
gcc/config/sol2.h is only used on Solaris targets anymore and Solaris 8
is the minimal supported version, I've
On 05/30/2011 04:29 PM, Rainer Orth wrote:
* Non-Solaris SPARC changes:
After I had moved sparc/sol2-c[in].asm to libgcc, I noticed that
despite the name a few non-Solaris targets uses those files, too:
sparc-*-elf*, sparc-*-rtems*, sparc64-*-elf*, sparc64-*-rtems*
Yes, I
On 05/30/2011 05:12 PM, Rainer Orth wrote:
Ok for mainline after a fresh bootstrap?
Ok. This depends on the t-slibgcc-dummy file from the Solaris patch, so
feel free to move it to this patch (together with
s/t-slibgcc-darwin/t-slibgcc-dummy/).
Paolo
On 05/31/2011 11:30 AM, Kai Tietz wrote:
The issue is that in
combination of 32-bit and 64-bit we need to default here to SjLj,
Ok, then what you're testing is actually whether you're using sjlj or
dw2 unwinding. config/i386/cygming.h will ensure that this is the same
as testing
Seems like a plan, but I didn't go in this direction since I couldn't
test anything like this.
As long as you test the general configury on 1-2 platforms, it's not any
less tested than what you have now.
The various __enable_execute_stack
implementations differ in minor ways that would have
On 05/29/2011 06:14 PM, Richard Guenther wrote:
-/* Returns a hash code for P. */
+/* Returns a hash code for P.
+ Shamelessly*/
... stolen from libiberty.
?
Ok with that comment adjusted.
Why steal it :) if you can instead add the code to libiberty?
Paolo
On 05/24/2011 01:42 PM, Joseph S. Myers wrote:
This patch continues preparing for a target structure shared by the
driver (including for this purpose collect2 and gnatbind) and the core
compilers by creating a library libcommon-target.a to contain the
shared code that may have such target
On 05/23/2011 12:33 PM, Rainer Orth wrote:
Certainly looks good to me, although I probably can't officially approve it.
I think you can since this only affects Ada. I'll wait a day or two if
anyone objects, then install the patch.
It's okay for me too.
Paolo
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
On 05/20/2011 02:21 PM, Joseph S. Myers wrote:
2011-05-20 Joseph Myersjos...@codesourcery.com
* Makefile.in (LIBDEPS): Add libcommon.a.
(LIBS): Likewise.
(GCC_OBJS): Remove diagnostic.o, pretty-print.o and input.o.
(OBJS-common): Remove diagnostic.o, input.o,
On 05/20/2011 03:49 PM, Michael Matz wrote:
Hi,
On Fri, 20 May 2011, Joseph S. Myers wrote:
(Apart from the arbitrary division between GCC_OBJS and the xgcc link
rule, mentioned above, there are other arbitrary divisions that don't
make sense to me. In particular, the separation between
On 05/12/2011 05:40 PM, Bernd Schmidt wrote:
+ if (targetm.calls.function_arg_round_to_arg_boundary (passed_mode, type))
+round_boundary = boundary;
+ else
+round_boundary = PARM_BOUNDARY;
Why add an if, instead of making the new target hook
function_arg_round_boundary? The default
On 05/13/2011 03:40 PM, Bernd Schmidt wrote:
gcc/
* libgcc2.h (__NW, __NDW): Define using a __gnu_ prefix if
LIBGCC2_GNU_PREFIX is defined.
(__N): New macro.
(__powisf2, __powidf2, __powitf2, __powixf2, __bswapsi2, __bswapdi2,
__mulsc3, __muldc3,
On 05/13/2011 03:03 AM, Rong Xu wrote:
* gcc/coverage.c(revision 173717): set a flag if building for
Linux kernel.
* gcc/tree-profile.c(revision 173717): don't emit TLS declarations
for Linux kernel builds.
I think this should be done without touching at all the
On 05/10/2011 05:23 PM, Richard Guenther wrote:
I suppose you have testcases for all the cases you looked at, please
add some that cover these corner cases.
Also, there is quite some tree-vrp.c dead code with these changes.
Removing the TRUTH_*_CODE handling in VRP will help finding more
On 05/09/2011 04:38 AM, Doug Kwan (關振德) wrote:
Sorry, forgot the patch and the ChangeLog
2011-05-08 Doug Kwandougk...@google.com
* configure.ac: Propagate LDFLAGS_FOR_TARGET.
* configure: Regenerated.
* Makefile.tpl (LDFLAGS_FOR_TARGET): Use LDFLAGS_FOR_TARGET
On 05/09/2011 05:59 PM, Paul Pluzhnikov wrote:
Ping? Ping? Ping? Ping? Ping?
http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00246.html
CC'ing the rest of build system maintainers.
None of the build system maintainers can approve gcc.c changes. And
those can be approved only by either a
On Mon, May 9, 2011 at 18:45, Joseph S. Myers jos...@codesourcery.com wrote:
On Mon, 9 May 2011, Paolo Bonzini wrote:
On 05/09/2011 05:59 PM, Paul Pluzhnikov wrote:
Ping? Ping? Ping? Ping? Ping?
http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00246.html
CC'ing the rest of build system
On 04/22/2011 05:21 PM, Chung-Lin Tang wrote:
Also, instead of testing for XEXP(SET_SRC(PATTERN(i3)),1) == const0_rtx
at the top, it now allows CONST_INT_P(XEXP(SET_SRC(PATTERN(i3)),1)),
tries to adjust it by simplify_compare_const() from the last patch, and
then tests if op1 == const0_rtx. This
On 05/06/2011 12:56 PM, Chung-Lin Tang wrote:
I'm not sure why it doesn't allow both?
Paolo
Hi Paolo, I'm not sure I understand your meaning of 'both', but before
this patch, it only tested for == const0_rtx, without any attempt of
other cases.
Now it tests
There is indeed more simplification possible (alpha-vms for example
caught my attention while reviewing), but proceeding incrementally
does not hurt.
This patch is okay, thanks.
Paolo
2011/5/4, Joseph S. Myers jos...@codesourcery.com:
This patch separates cases disabling newlib and libgloss
On 05/04/2011 09:12 PM, Joseph S. Myers wrote:
-# hpux11 in 64bit mode has libraries in a weird place. Arrange to find
-# them automatically.
-
-# The Solaris /usr/ucb/cc compiler does not appear to work.
Ok.
Paolo
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
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 04/27/2011 05:50 PM, Joseph S. Myers wrote:
Continuing the toplevel cleanups separating the cases disabling
different subdirectories - on the basis that eventually this
information should come from the subdirectories, and that as
previously discussed much of the default disabling of ${libgcj}
On 04/27/2011 06:33 PM, Joseph S. Myers wrote:
This patch, relative to a tree with
http://gcc.gnu.org/ml/gcc-patches/2011-04/msg02123.html applied,
continues the cleanup of toplevel cases relating to disabling Java or
Java libraries by arranging for Java to be disabled (via
On 04/28/2011 06:17 PM, Joseph S. Myers wrote:
This patch cleans up the libgcj-disabling case statement at toplevel,
removing the default disabling for *-*-* (which allows other empty
cases to be removed) and disabling based on architecture, or most
cases of architecture-OS combination where the
On 04/26/2011 05:25 PM, Rainer Orth wrote:
David,
Thanks Rainer, if you cons up a patch to add the .align directive I'll ACK
that as well.
here's the patch that I've been testing over the weekend. It caused no
change for HAVE_AS_SPARC_GOTDATA_OP on anything but Solaris 10 with gas
and Sun
On 04/06/2011 02:07 PM, Joseph S. Myers wrote:
This patch removes toplevel support for various subdirectories not
present in the gcc or src repositories, as agreed in the thread
includinghttp://gcc.gnu.org/ml/gcc/2011-03/msg00501.html. Some
other directories may in fact also be no longer useful
On 04/01/2011 02:34 PM, Joseph S. Myers wrote:
This patch does some more toplevel configure cleanup related to targets no
longer supported by GCC:
* The code to enable libgomp on hosted POSIX systems handled *-*-sysv4*;
GCC no longer supports any such targets.
* The md_exec_prefix code covered
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
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
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/27/2011 06:27 AM, Ian Lance Taylor wrote:
Nathan Boleynpbo...@gmail.com 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
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
On 03/28/2011 02:27 PM, Michael Matz wrote:
mem_ref 0x77ff9118
typerecord_type 0x75b295e8 GENOME_LOC_TYPE_2 packed type_0 BLK
sizeinteger_cst 0x75b256b8 constant 48
unit sizeinteger_cst 0x75b25708 constant 6
align 8 symtab 0 alias set -1
On 03/24/2011 08:49 PM, Joseph S. Myers wrote:
Related to that point, I notice a piece of code starting we might need to
use some other shell than /bin/sh for running subshells that tries to
determine a shell on Windows hosts. It's autoconf's job to find a
suitable shell, so if this code is
On 03/21/2011 01:59 PM, Rainer Orth wrote:
diff -r 8efcb4b03d45 boehm-gc/Makefile.am
--- a/boehm-gc/Makefile.am Sun Mar 20 14:28:11 2011 +0100
+++ b/boehm-gc/Makefile.am Sun Mar 20 21:37:14 2011 +0100
@@ -4,10 +4,10 @@
## files that should be in the distribution are not mentioned in
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/24/2011 03:11 PM, Joseph S. Myers wrote:
Furthermore, the whole idea of the toplevel configure tentative_cc
setting code is dubious since this is an autoconf-generated script and
it's autoconf's job to deal with finding a working compiler, putting
it in ANSI C mode, etc. - so if someone
AR_CFLAGS = cr is already the default.
Committed to gcc and src.
Paolo
2011-03-24 Paolo Bonzini bonz...@gnu.org
* mh-sysv4: Remove AR_CFLAGS.
Index: mh-sysv4
===
--- mh-sysv4(revision 171413)
+++ mh-sysv4
Yet another relic of cygnus configure. Eliminate.
Committed to gcc and (shortly) to src.
Paolo
2011-03-24 Paolo Bonzini bonz...@gnu.org
* configure.ac: Remove all mentions of mh-sysv4 and mh-solaris.
* configure: Regenerate.
* Makefile.def: Remove all mentions
This enables omit-frame-pointer for i386-solaris. I honestly haven't
bootstrapped it, but I don't expect any problems (and if they appear,
it's much better to fix them ;).
Committed to gcc and (shortly) to src.
Paolo
2011-03-24 Paolo Bonzini bonz...@gnu.org
* configure.ac: Remove
On 03/24/2011 06:18 PM, Joseph S. Myers wrote:
On Thu, 24 Mar 2011, Paolo Bonzini wrote:
This enables omit-frame-pointer for i386-solaris. I honestly haven't
bootstrapped it, but I don't expect any problems (and if they appear, it's
much better to fix them;).
How about killing mh
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
On 03/21/2011 12:48 PM, Rainer Orth wrote:
As reported in the PR, the toplevel configure test for libpwl doesn't
work since it fails to link with libstdc++. The following patch
corrects this.
There were a couple of issues:
* One cannot use LDFLAGS here since that is passed to $CC before
On 03/21/2011 01:40 PM, Rainer Orth wrote:
Paolo Bonzinibonz...@gnu.org writes:
On 03/21/2011 12:48 PM, Rainer Orth wrote:
As reported in the PR, the toplevel configure test for libpwl doesn't
work since it fails to link with libstdc++. The following patch
corrects this.
There were a
On Fri, Mar 18, 2011 at 17:23, Kenneth Zadeck zad...@naturalbridge.com wrote:
I believe that this is not the right way to go.
if someone specifies -fcrossjumping, then the pass should turn on live for
the duration of the pass just as ifcvt does. If they ask for crossjumping
you should give
On Fri, Mar 18, 2011 at 17:31, Jakub Jelinek ja...@redhat.com wrote:
On Fri, Mar 18, 2011 at 12:23:11PM -0400, Kenneth Zadeck wrote:
I believe that this is not the right way to go.
if someone specifies -fcrossjumping, then the pass should turn on
live for the duration of the pass just as
On 03/15/2011 10:37 PM, Jeff Law wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I noticed that VRP was missing many obvious jump threading
opportunities; investigation showed that it wasn't threading through
conditionals with pointer types, just those with integral types.
Fix is rather
On 03/16/2011 12:59 PM, Richard Guenther wrote:
On Wed, Mar 16, 2011 at 12:52 PM, Jakub Jelinekja...@redhat.com wrote:
On Wed, Mar 16, 2011 at 09:46:20AM +0100, Paolo Bonzini wrote:
On 03/16/2011 12:12 AM, Kenneth Zadeck wrote:
so how much time does this save?
I agree that this is a useful
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 Froydfroy...@codesourcery.com
On Thu, Mar 10, 2011 at 04:02:27AM +0100, Hans-Peter Nilsson wrote:
PS. If you really
On 03/10/2011 12:26 PM, Rainer Orth wrote:
+ # GNU gold (GNU Binutils 2.21.51.20110225) 1.11
+ #
+ # We extract the binutils version which is more familiar and specific
+ # than the gold version.
+ ld_vers=`echo $ld_ver | sed -n \
+ -e 's,^.*[
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
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/04/2011 02:57 PM, Tom de Vries wrote:
The MAX_EXPR however
expands into control flow, and is not hoisted out of the outer loop,
while the rest of the bound calculation is.
That looks like a pass-ordering problem too (both on the tree level, for
ivopts versus invariant motion, and on the
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 should mean the same thing at all levels.
I agree. Why is it incorrect to use those flags when,
On 03/03/2011 05:26 PM, Diego Novillo wrote:
On Thu, Mar 3, 2011 at 00:27, Paolo Bonzinibonz...@gnu.org 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
On 02/24/2011 06:04 PM, Michael Matz wrote:
Funny. As far back as I remember we consistently said that bits of the
same word, but outside the subreg are left with undefined values after
storing into the subreg, except if wrapped with a strict_low_part. In
fact that's the whole point of
On 01/26/2011 03:55 PM, James Murray wrote:
On Wed, 2011-01-26 at 15:40 +0100, Richard Guenther wrote:
Stephane Carrez is listed as maintainer of the port, so he should
know how to contribute fixes to the port upstream.
Yes, but as I said... he is no longer active on this port. His last
On 01/26/2011 08:56 PM, Diego Novillo wrote:
At Google we use a code review tool which was open sourced a couple of
years ago: Rietveld
(http://code.google.com/appengine/articles/rietveld.html).
The best way of thinking about it is bugzilla for patches. The
system creates an entry for every
On 01/26/2011 08:56 PM, Diego Novillo wrote:
At Google we use a code review tool which was open sourced a couple of
years ago: Rietveld
(http://code.google.com/appengine/articles/rietveld.html).
The best way of thinking about it is bugzilla for patches. The
system creates an entry for every
On 12/20/2010 12:43 PM, Claudiu Zissulescu wrote:
Hi,
Why don't you use a define_insn zero_extendbisi2 which generates
your conversion instruction.
You're right that this should be a valid workaround, but Bingfeng
reported a bug indeed.
(zero_extend:SI (reg:BI 120))
should have been
On 12/22/2010 03:43 PM, Bingfeng Mei wrote:
Thanks for letting me know this. Since only our target experiences such
issue, I guess no other processors have such requirements of manipulating
BImode. I can live with the workaround now.
Perhaps Blackfin, but it has a BI-SI extension instruction
Is there sufficient interest to post the branch patches to gcc-patches as I
go?
If not that could be a substantial review headache at merge time.
On 18/12/2010, Joern Rennecke amyl...@spamcop.net wrote:
I have created the branch:
svn://gcc.gnu.org/svn/gcc/branches/pr46489-20101217-branch
On 11/16/2010 10:17 PM, Ian Lance Taylor wrote:
I don't know how we want to get there, but it seems to me that the place
we want to end up is with the target hooks defined to take an argument
of type struct cumulative_args * (or a better name if we can think of
one).
Actually, this doesn't
On 11/17/2010 03:10 AM, Ian Lance Taylor wrote:
Joern Renneckeamyl...@spamcop.net writes:
I don't see how going to a struct cumulative_args gets us closer
to a viable solution for a multi-target executable, even if you
threw in C++. Having the target describe a type, and shoe-horning
this
The only targets that are using textual prologues and epilogues are now
arc, cris, pdp11 and vax. ARC should probably have been deprecated long
ago, any plans to convert the others or (for cris) to flip the default?
Paolo
We currently have 3 non-algorithmic maintainers:
loop optimizer Zdenek Dvorak o...@ucw.cz
loop optimizer Daniel Berlin dber...@dberlin.org
libcpp Tom Tromey tro...@redhat.com
Especially for the loop optimizer, the situation is
On 11/15/2010 04:48 PM, Joseph S. Myers wrote:
* The macro is tested with #if/#ifdef/#ifndef/#elif in a source file
outside of config/ (but including front-end subdirectories). Care is
needed in identifying such macros through grep because of
backslash-newline line continuations and because
On 11/15/2010 11:10 PM, Hans-Peter Nilsson wrote:
There *is* an option to omit the prologue and epologue
controlling the TARGET_PROLOGUE_EPILOGUE; I'm guessing that
could cause confusion.
That's what confused me.
Is that getting in the way of something?
Yes, there is code conditionalized
On 11/12/2010 03:25 PM, H.J. Lu wrote:
IRA may move instructions across an unspec_volatile,
Do you have a testcase?
Paolo
On 11/13/2010 03:34 PM, H.J. Lu wrote:
On Sat, Nov 13, 2010 at 2:27 AM, Paolo Bonzinibonz...@gnu.org wrote:
On 11/12/2010 03:25 PM, H.J. Lu wrote:
IRA may move instructions across an unspec_volatile,
Do you have a testcase?
x86 has
;; Clear the upper 128bits of AVX registers,
On 11/13/2010 04:28 PM, H.J. Lu wrote:
VZEROUPPER is no-nop to executions. But it isn't no-nop for performance.
IIUC it's a noop as GCC uses it. You could use it in 256-bit mode and
it would be valid, but not a noop.
Paolo
On 11/13/2010 05:10 PM, H.J. Lu wrote:
On Sat, Nov 13, 2010 at 8:01 AM, Paolo Bonzinibonz...@gnu.org wrote:
On 11/13/2010 04:28 PM, H.J. Lu wrote:
VZEROUPPER is no-nop to executions. But it isn't no-nop for performance.
IIUC it's a noop as GCC uses it. You could use it in 256-bit mode and
On 11/13/2010 10:08 PM, Xinliang David Li wrote:
Though gcc leads LLVM in performance overrall, there are a couple of
benchmarks gcc is worse: vpr and crafty (64bit and 32bit), parser and
twolf (32bit), vortex (64bit). This needs to be triaged. gcc
miscompiles gcc and eon in 32bit -- is there
501 - 600 of 1512 matches
Mail list logo
