On Tue, Oct 18, 2016 at 8:59 AM, Ludovic Courtès via cfe-dev
wrote:
> Shea Levy skribis:
>
>> Your patches look good! My biggest concern is how the ld wrapper behaves
>> in the presence of response files. Have you tested that?
>
> It surely doesn’t (yet?).
>
> However, GCC does not pass “@file” a
On Fri, Jan 28, 2011 at 01:11:10AM +, Joseph S. Myers wrote:
> Here is a concrete list I propose for deprecation in 4.6; please send
> any other suggestions...
score-* doesn't have a maintainer and score-elf couldn't build libgcc
last I checked (it was also mentioned in your previous message).
On Sat, Feb 12, 2011 at 08:11:07AM -0500, David Edelsohn wrote:
> On Fri, Feb 11, 2011 at 9:15 PM, Joseph S. Myers
> wrote:
> > appear to involve a simultaneously maintained set of upstream components
> > that are usable together in their current upstream forms; they got Linux
> > kernel support u
On Mon, Feb 14, 2011 at 09:41:50AM -0800, Nathan Froyd wrote:
> Patch for adding score-* and crx-* to obsolete ports below. Last
> contact for SCORE and current crx maintainer CC'd.
I have committed this patch. The crx maintainer (Pompapathi Gadad)
contacted me via private mail and i
On Wed, Mar 02, 2011 at 07:14:53AM -0800, Ian Lance Taylor wrote:
> This patch should at least cause genrecog to crash for you rather than
> generating bogus output. I've verified that this patch bootstraps on
> x86_64 and makes no difference in the generated insn-recog.c. Can you
> see whether t
[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'
On Fri, Apr 29, 2011 at 09:18:56AM +0200, Paolo Bonzini wrote:
> * Get rid of EXPR_LIST and INSN_LIST
This is reasonably difficult, though particular subprojects may be easy
enough. Notable uses of EXPR_LIST:
- loop-iv.c
- the interface to TARGET_FUNCTION_VALUE
- the scheduler
- REG_NOTES
-
On Fri, Apr 29, 2011 at 04:20:15PM +0200, Paolo Bonzini wrote:
> 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. *Wh
On Fri, May 27, 2011 at 06:30:21AM -0700, Ian Lance Taylor wrote:
> Jonathan Wakely writes:
> > It's an additional maintenance burden.
>
> It's not a maintenance burden on gcc, though.
>
> I think we should have the gcc configure script provide a way to add a
> preprocessor macro.
FWIW, we decide
On Fri, Jul 24, 2009 at 05:20:16AM -0700, pms wrote:
> But I want to know what are the TREE_CODEs for other remaing constructs
> viz declration stmt, conditions, count for constants and how to use them in
> the gimple pass. Can anybody help in this regard
The names are defined in tree.def.
-Na
On Wed, Nov 04, 2009 at 11:24:34AM -0500, Jean Christophe Beyler wrote:
> However, I've been going through the first step : running GDB, setting
> a break-point and doing a continue to see what I get and try to get
> the information right for O3 too.
>
> In O0, I get:
> Breakpoint @@ 1, foo (a=4,
On Mon, Jan 04, 2010 at 04:08:17PM +, Andrew Haley wrote:
> On 01/04/2010 12:07 PM, Jakub Jelinek wrote:
> > IMHO we really should have some late tree pass that converts adjacent
> > bitfield operations into integral operations on non-bitfields (likely with
> > alias set of the whole containing
On Thu, Feb 11, 2010 at 09:43:31AM -0800, Douglas B Rupp wrote:
> A pointer would be much appreciated!
>
> In ia64.md for *cmpdi_normal this is found:
> "cmp.%C1 %0, %I0 = %3, %r2"
>
> Where are %C, %I, %r described?
Above gcc/config/ia64/ia64.c:ia64_print_operand.
-Nathan
On Mon, Feb 22, 2010 at 03:23:52PM -0600, Jon Turner wrote:
> In it, you will find a directory with all the source code
> needed to observe the problem for yourself.
> The top level directory contains a linux executable called
> maxFlo, which you should be able to run on a linux box
> as is. But if
On Wed, Mar 10, 2010 at 01:30:36PM +, Nick Fielding wrote:
> The first syntax error the compiler complains about I think is the main
> problem:
> /tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp:673: error: expected ',' or '...'
> before numeric constant
>
> However, when I look at the line of code
On Thu, Mar 18, 2010 at 04:34:56PM +0100, Vincent Lefevre wrote:
> On 2010-03-18 15:32:04 +0100, Michael Matz wrote:
> > But unfortunately you are right, this expansion can only be done for
> > -fno-signed-zeros. (FWIW the general expandsion of pow(x,N/2) where
> > N!=1 is already guarded by unsafe
On Mon, Apr 05, 2010 at 10:29:07AM -0430, Kofi Doku Atuah wrote:
> The process of building a simply, plain vanilla cross compiler for
> arch-fmt-no_os is really probably overdone. To build, for example, a
> GCC cross compiler for an i586-elf target, the build process requires
> you to have a libc f
On Tue, Apr 06, 2010 at 09:58:23AM -0700, Ian Lance Taylor wrote:
> In the code the register is always accessed via a subreg, so the
> lower-subregs pass thinks that it is OK to decompose the register.
> Once it is decomposed, nothing is expected to put it back together.
>
> To fix this, you shoul
On Tue, Apr 06, 2010 at 11:55:01AM -0700, Ian Lance Taylor wrote:
> Nathan Froyd writes:
> > Compiling anything that uses doubles on powerpc e500v2 produces awful
> > code due in part to lower-subregs (the register allocator doesn't help,
> > either, but that's a
On Mon, Apr 12, 2010 at 09:47:04AM -0500, Joel Sherrill wrote:
> qemu with no cpu argument specified. So qemu32.
> It does run OK when I change the cpu model to 486
> or pentium.
>
> Is qemu reporting that it supports SSE and not doing a good
> enough job to make gcc happen?
I think that's quite
On Wed, Apr 14, 2010 at 11:30:44AM -0400, Diego Novillo wrote:
> On Wed, Apr 14, 2010 at 11:18, Manuel López-Ibáñez
> wrote:
> > Otherwise, as Ian said in another topic [2]: "I have a different fear:
> > that gcc will become increasing irrelevant".
>
> That's my impression, as well. It is true o
On Wed, Apr 14, 2010 at 09:49:08PM +0200, Basile Starynkevitch wrote:
> Toon Moene wrote:
>>
>> Mutatis mutandis, the same goes for GCC: There might be too many
>> hurdles to use GCC in academia.
>
> This is probably true, however, the plugin ability of the just released
> GCC 4.5 (or is it re
On Mon, Apr 19, 2010 at 09:35:44AM -0400, Jack Howarth wrote:
>The annoucement should probably note that targets which lack
> objdump currently can't build plugins. I've had about as much
> luck getting the patch to fix this...
>
> http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00610.html
>
> .
On Fri, Apr 23, 2010 at 01:55:48PM -0400, Jean Christophe Beyler wrote:
> I know we can pass -Wl,option, -Wa,option from gcc down to as and ld
> however if I have to write :
>
> gcc -mArch2 -Wl,--arch2 -Wa,--arch2 hello.c
>
> it gets a bit redundant, I must be blind because I can't seem to find
>
On Tue, Dec 16, 2008 at 12:28:10PM +0700, Ha Luong wrote:
> I used gcc-4.3.2 to compile the c source(*) and it generated
> "vmhraddshs" instruction when I compiled with -mcpu=8540.
> 000103A4: 11EB0321 vmhraddshs vr15,vr11,vr0,vr12
You are running into the problem that the Altivec and SPE opcode
On Wed, Dec 17, 2008 at 01:33:38PM +0700, Ha Luong wrote:
> Thanks for your guide. When I debugged the exe file or make it ran on
> 8548 board, the vmhaddshs makes the exe file hang out. Could I compile
> the source for 8540 (e500v1 instructions) only?
Sure. But evstdd{,x} are e500v1 instructions
On Thu, Jan 29, 2009 at 04:46:37PM -0500, Rodrigo Dominguez wrote:
> I am looking at binary auto-vectorization or taking a binary and rewriting
> it to use SIMD instructions (either statically or dynamically). I was
> wondering if anyone knew of similar work and could help me with some links.
Ansh
On Wed, Feb 18, 2009 at 06:03:58PM +0800, JCX wrote:
> Hello,
> After I compile the following file for testing, I check the dump
> file called "129t.final_cleanup". I doubt about why the type "short
> int" changes into "short unsigned int" during the array operations,
> and at last changes bac
On Wed, Feb 18, 2009 at 05:55:43AM -0800, Nathan Froyd wrote:
> On Wed, Feb 18, 2009 at 06:03:58PM +0800, JCX wrote:
> > Hello,
> > After I compile the following file for testing, I check the dump
> > file called "129t.final_cleanup". I doubt about why the ty
On Thu, Mar 05, 2009 at 11:39:45AM +, charfi asma wrote:
> intc;
> int main()
>
> {
>
> Calcul ca;
>
> c=3;
>
> ca.affich();
>
> ca.inc(c);
>
> cout << "the value of c is" << c << endl;
>
> return 0;
>
> }
[...]
> int main()
>
> {
>
> Calcul ca;
>
> ca.affich();
>
> c=3;
>
> ca.in
On Fri, Apr 03, 2009 at 08:05:47PM +0100, Dave Korn wrote:
> Ian Lance Taylor wrote:
> > No fundamental difficulty that I know of. Lots of tedious work for
> > every backend setting RTX_FRAME_RELATED_P and adding
> > REG_FRAME_RELATED_EXPR notes to the manually constructed epilogue insns.
>
> I
On Thu, May 20, 2010 at 08:59:32PM -0700, Mark Mitchell wrote:
> David Edelsohn wrote:
> > No one disagrees with the potential benefit of the feature.
>
> OK; I must have misremembered.
>
> I believe our current implementation keeps track of FP usage through the
> front-end, and then disables any
On Fri, Jun 04, 2010 at 01:44:02PM +, Art Haas wrote:
> This morning's i386 build fails with the following error:
>
> libbackend.a(sol2.o): In function `solaris_output_init_fini':
> /home/ahaas/gnu/gcc.git/gcc/config/sol2.c:109: undefined reference to
> `print_operand'
> /home/ahaas/gnu/gcc.g
On Fri, Jun 04, 2010 at 07:45:20AM -0700, Ian Lance Taylor wrote:
> Nathan Froyd writes:
> > * config/i386/i386-protos.h (ix86_print_operand): Declare.
> > * config/i386/i386.c (ix86_print_operand): Make non-static.
> > * config/i386/sol2.h (ASM_OUTPUT_CALL): Ca
On Fri, Jun 04, 2010 at 08:32:26AM -0700, Ian Lance Taylor wrote:
> Nathan Froyd writes:
> > Looking at things a little more closely, output_address is exported in
> > output.h. I suppose output_operand should be exported there as well?
>
> Yes, put the
On Fri, Aug 27, 2010 at 09:44:25AM -0400, Corey Kasten wrote:
> I find that the executable compiled on system A runs faster (on both
> systems) than the executable compiled on system B (on both system), by a
> factor about approximately 4 times. I have attempted to play with the
> GCC optimizer fla
On Sun, Sep 26, 2010 at 06:09:34PM -0700, ir_idjit wrote:
> i can seem to get this to work:
>
> #define PREFIX "p_"
> #define HIGHER_INTERFACE(id) LOWER_INTERFACE(PREFIX, id)
>
> #define LOWER_INTERFACE(prefix, id) struct prefix##id \
> { \
> int i; \
> }
>
> int main(void)
> {
> HIG
On Mon, Oct 18, 2010 at 02:49:21PM +0800, Jie Zhang wrote:
> 3. The aforementioned rs6000 hack rs6000_issue_rate was added by
>
> 2003-03-03 David Edelsohn
>
> * config/rs6000/rs6000.c (rs6000_multipass_dfa_lookahead): Delete.
> (TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD
On Thu, Oct 21, 2010 at 02:14:15PM +0200, Frederic Riss wrote:
> On 19 October 2010 15:31, Ian Lance Taylor wrote:
> > However, I agree that it does seem that it should be added to or
> > subtracted from hard_frame_pointer_rtx before setting
> > virtual_stack_vars_rtx, or something. I only see on
On Tue, Oct 26, 2010 at 01:07:26PM +0100, Jon Beniston wrote:
> > lm32 has a gdb simulator available, so it should be fairly easy to write
> > a board file for it if one doesn't already exist.
> >
> > Unfortunately, building lm32-elf is broken in several different ways
> > right now.
>
> What pro
The easiest way to deal with the use of LIBGCC2_FLOAT_WORDS_BIG_ENDIAN
in libgcc is to define a preprocessor macro __FLOAT_WORD_ORDER__ similar
to how WORDS_BIG_ENDIAN was converted. That is, cppbuiltin.c will do:
cpp_define_formatted (FOO, "__FLOAT_WORD_ORDER__=%s",
(FL
On Wed, Nov 17, 2010 at 03:40:39AM +0100, Paolo Bonzini wrote:
> True, but you can hide that cast in a base class. For example you
> can use a hierarchy
>
> Target // abstract base
> TargetImplBase // provides strong typing
> TargetI386
On Tue, Nov 16, 2010 at 10:22:00PM -0500, Joern Rennecke wrote:
> Quoting Nathan Froyd :
> >I am admittedly a C++ newbie; the first thing I thought of was:
> >
> >class gcc::cumulative_args {
> > virtual void advance (...) = 0;
> > virtual rtx arg (...) =
On Tue, Nov 16, 2010 at 06:23:32AM -0800, Ian Lance Taylor wrote:
> Joern Rennecke writes:
> > Before I go and make all these target changes & test them, is there at
> > least agreemwent that this is the right approach, i.e replacing
> > CUMULATIVE_ARG *
> > with void *, and splitting up x_rtl int
On Wed, Nov 24, 2010 at 02:48:01PM +, Pedro Alves wrote:
> On Wednesday 24 November 2010 13:45:40, Joern Rennecke wrote:
> > Quoting Pedro Alves :
> > Also, these separate hooks for common operations can make the code more
> > readable, particularly in the bits_in_units_ceil case.
> > I.e.
> >
On Tue, Nov 30, 2010 at 08:04:06PM +0100, Joakim Tjernlund wrote:
> Why is not
> const char cstr[] = "mystr";
> const int myint = 3;
> added to a read only section?
> Especially since
> const int myarr[]={1,2,3};
> is placed in .rodata.
>
> hmm, -G 0 does place these in .rodata but why do I
On Thu, Jan 06, 2011 at 09:59:08AM +0200, Revital1 Eres wrote:
> Index: loop-doloop.c
> + Some targets (ARM) do the comparison before the branch, as in the
> + folloring form:
^
"following"
> + /* In case the pattern is not PARALLEL we expect two forms
> + of dol
Since people are starting to post interesting patches for 4.7, I thought
it would be good to talk about bits I plan to cleanup in 4.7. Comments
on other ugly things would also be welcome.
TREE_LIST related things:
- TREE_VECTOR_CST_ELTS. I have a patch for this.
- ASM_EXPR operands, clobbers,
On Sat, Jan 22, 2011 at 08:02:33PM +0100, Michael Matz wrote:
> On Sat, 22 Jan 2011, Nathan Froyd wrote:
> > - Similarly to the work I did for s/TREE_CHAIN/DECL_CHAIN/, I'd like to
> > replace TREE_TYPE for things like {POINTER,FUNCTION,ARRAY}_TYPE, etc.
> > This
On Tue, Feb 12, 2008 at 02:47:39AM +0100, Hans-Peter Nilsson wrote:
> Is it as simple as nobody having tested cross-gcc setups for
> targets with dynamic linking, or are they incorrectly using the
> wrong (the installed, not the newly compiled) libgcc_s.so.1?
>
> Or how did you do it? NFS mounts
On Tue, Feb 12, 2008 at 05:13:45AM +0100, Hans-Peter Nilsson wrote:
> > From: Nathan Froyd <[EMAIL PROTECTED]>
> > One way to do it is with NFS mounts and setting -Wl,-dynamic-linker
> > -Wl,-rpath for your ldflags.
>
> Thanks to you and David Daney. Have you
On Mon, Mar 10, 2008 at 03:22:13PM +0300, Sergei Poselenov wrote:
> I've got the ICE on the gcc.c-torture/compile/2718.c test:
> powerpc-linux-gnuspe-gcc -c -O3 -funroll-loops 2718.c
> 2718.c: In function 'baz':
> 2718.c:14: internal compiler error: Segmentation fault
> Please submi
t/library files are identical to what they were
previously.
OK to commit as is? Or should I do a testing run as well?
-Nathan
libgcc/
2008-06-24 Nathan Froyd <[EMAIL PROTECTED]>
* config/rs6000/t-ppccomm: Remove rules that conflict with
auto-generated
On Fri, Aug 03, 2007 at 06:24:06PM +0100, Paul Brook wrote:
> On Friday 03 August 2007, Jonathan S. Shapiro wrote:
> > Then it seems very curious that the constant folding should fail on this
> > platform. Any idea what may be going on here?
>
> You're exploiting a hole in the C aliasing rules by
The LTO driver requires libelf and currently grovels around in the
system directories looking for it, which may not always be the right
place to find it. (This bit me when building LTO on our new Linux
machines, which do not have libelf installed.) The Right Thing would be
to add a --with-libelf
In one of my recent messages about a patch to the LTO branch, I
mentioned that we could compile and successfully run all of the C
SPECint benchmarks except 176.gcc. Chris Lattner asked if I had done
any benchmarking now that real programs could be run; I said that I
hadn't but would try to do some
56 matches
Mail list logo
