Where in the manual are the machine specific print operand modifiers
documented? I've looked around, and just can seem to find them; surely, I
can't be the first to document such a modifier.
On Sep 6, 2012, at 1:09 PM, David Daney ddaney.c...@gmail.com wrote:
On 09/06/2012 01:00 PM, Ian Lance Taylor wrote:
On Thu, Sep 6, 2012 at 11:56 AM, Mike Stump mikest...@comcast.net wrote:
Where in the manual are the machine specific print operand modifiers
documented? I've looked around
On Sep 6, 2012, at 1:00 PM, Ian Lance Taylor i...@google.com wrote:
On Thu, Sep 6, 2012 at 11:56 AM, Mike Stump mikest...@comcast.net wrote:
Where in the manual are the machine specific print operand modifiers
documented? I've looked around, and just can seem to find them; surely, I
can't
This:
Verify that you have permission to grant a GFDL license for all
new text in tm.texi, then copy it to ../../gcc/gcc/doc/tm.texi.
make[3]: *** [s-tm-texi] Error 1
make[3]: *** Waiting for unfinished jobs….
is one of the stupidest build errors I've seen all decade. Can someone fix it
On Nov 27, 2012, at 1:22 PM, Andrew Pinski pins...@gmail.com wrote:
On Tue, Nov 27, 2012 at 12:55 PM, Mike Stump mikest...@comcast.net wrote:
This:
Verify that you have permission to grant a GFDL license for all
new text in tm.texi, then copy it to ../../gcc/gcc/doc/tm.texi.
make[3]: *** [s
On Nov 27, 2012, at 4:50 PM, Joseph S. Myers jos...@codesourcery.com wrote:
On Tue, 27 Nov 2012, Mike Stump wrote:
A review of the change and approval of the change should be enough to
catch issues going into the FSF tree. The build should just copy the
generated file to the source tree
Someone removed isl-0.10.tar.bz2 and cloog-0.17.0.tar.gz from
ftp://gcc.gnu.org/pub/gcc/infrastructure. I'd hoping this was in error and the
files can be restored. If there is some compelling reason, I am interested.
On Mar 27, 2013, at 1:02 AM, Senthil Kumar Selvaraj
senthil_kumar.selva...@atmel.com wrote:
global-used-types.c in gcc/testsuite/gcc.dg/debug/dwarf2 only specifies
-g in dg-options. For a target that is not configured to generate
dwarf-2 by default, the test fails looking for specific DWARF
On Apr 1, 2013, at 6:43 PM, Jason Merrill ja...@redhat.com wrote:
On 03/30/2013 02:23 AM, Senthil Kumar Selvaraj wrote:
I couldn't find a way to ask gcc to just generate DWARF (default
version) either. How should this be fixed?
Maybe we could use -gdwarf for that now, since we stopped using
On Apr 25, 2013, at 7:44 AM, Senthil Kumar Selvaraj
senthil_kumar.selva...@atmel.com wrote:
What is right way to fix these? I saw one testcase that did
typedef int int32_t __attribute__ ((__mode__ (__SI__)));
Is this the right way to go?
I like this. Pre-approved.
A make clean followed by a make in the libgcc directory results in:
../../../../gcc/libgcc/config/i386/cpuinfo.c:23:25: fatal error: auto-target.h:
No such file or directory
#include auto-target.h
Oh, the the old days, we'd just add a dependancy… If someone knows where to add
just the right
It is the intent for all_ones_mask_p to return true when 64 bits of ones in an
unsigned type of width 64 when size is 64, right? Currently the code uses a
signed type for tmask, which sets the upper bits to 1, when the value includes
the sign bit set and the equality code does check all 128
On Aug 27, 2013, at 3:23 AM, Richard Biener richard.guent...@gmail.com wrote:
+++ b/gcc/fold-const.c
@@ -3702,12 +3702,23 @@ all_ones_mask_p (const_tree mask, int size)
This should instead use
return tree_to_double_int (mask) == double_int::mask (size)
|| (TYPE_PRECISION (mask) ==
On Aug 28, 2013, at 2:40 AM, Richard Biener richard.guent...@gmail.com wrote:
Digging shows I at one point removed all this code - but people objected and I
had to revert it :/
[ oh,, sorry to hear ] I got rid of it as well, and then the test suite beat
on me til I relented.
I suppose this
So, here is a comparison of the time required to do a make -j15 of a
--disable-bootstrap --enable-checking=none --enable-languages=c,c++ style
compiler. The base compiler is a --enable-checking=none
--enable-languages=c,c++,lto style compiler, which is
1b2bf75690af8115739ebba710a44d05388c7a1a
On Oct 15, 2013, at 5:41 AM, Richard Biener richard.guent...@gmail.com wrote:
That said, how do cc1 binary sizes compare branch vs. trunk at
the last merge point?
$ size /tmp/gcc-*/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/cc1plus
textdata bss dec hex filename
14224227
On Nov 3, 2013, at 8:49 PM, pins...@gmail.com wrote:
What benefits does blocks have over nested functions in C and over lambas in
C++?
The ability to compile existing code. The ability to compile code that uses
system header files on macosx. The ability to use third party libraries on
On Nov 3, 2013, at 8:28 PM, Maxim Kuvyrkov ma...@kugelworks.com wrote:
I am considering a project to add Apple's blocks [*] extension to GCC.
I have a funny story about that one… I was just about ready to submit the
work, the GPLv3 happened. Ah… life goes on.
On Nov 3, 2013, at 8:28 PM, Maxim Kuvyrkov ma...@kugelworks.com wrote:
Mike, as Obj-C/C++ front-end maintainers, would you be supportive of Blocks
extension implemented for Obj-C/C++ front-ends?
Sure.
Though, I'd really love a front-end extension to allow one to implement Blocks
as a pure
On Nov 22, 2013, at 4:31 AM, Konstantin Serebryany
konstantin.s.serebry...@gmail.com wrote:
These CFI directives were completely removed in upstream at
http://llvm.org/viewvc/llvm-project?rev=192196view=rev
Strangely, this did not get into the last merge...
Anyway, these cfi_* will (should,
On Nov 22, 2013, at 10:13 AM, Jakub Jelinek ja...@redhat.com wrote:
This is exactly the patch referenced in the pointer to the upstream repo.
Arno, does this fix the build for you?
Ok?
Yes
Committed revision 205285.
I've been doing make -j70 and -j70 restrap and libasan seems to build 1 file at
a time. I'm chasing other bits right now, so I didn't track down what did it.
I looked at how it is wired up and didn't just spot it, and it seems to copy
other runtime libraries we have. Not sure if they suffer
Since we are nearing release, I thought I’d mention I see:
../../gcc/gcc/doc/invoke.texi:1114: warning: node next `Overall Options' in
menu `C Dialect Options' and in sectioning `Invoking G++' differ
../../gcc/gcc/doc/invoke.texi:1114: warning: node up `Overall Options' in menu
`Option Summary'
On Apr 22, 2014, at 12:48 PM, Kenneth Zadeck zad...@naturalbridge.com wrote:
While of course one hopes that there will be no issues with wide-int, a
change of this size will have some pain no matter how well we have
tested it. Having three reviewers will assure problems are resolved
I am seeing the below on wide-int. The go teststsuite violates one of the
principals of goo test suite hygiene, the names thought arbitrary, should be
stable. These names are not stable across differing build locations.
s,.*/testsuite/,,g is approximately what it needs. Thanks.
New tests
On Feb 13, 2014, at 1:18 AM, Richard Sandiford rdsandif...@googlemail.com
wrote:
This patch tries to reduce that by providing an alternative single-script
version.
Python isn't yet required and I'm pretty sure this script needs 2.6
or later.
I'm also worried that the seek/tell stuff might
On May 6, 2014, at 8:19 AM, Kenneth Zadeck zad...@naturalbridge.com wrote:
please hold off on committing patches for the next couple of hours as we have
a very large merge to do.
thanks.
All done… It is in.
So, I was wondering about patterns like:
(define_insn_and_split *setcc_di_1
[(set (match_operand:DI 0 register_operand =q)
(match_operator:DI 1 ix86_comparison_operator
[(reg FLAGS_REG) (const_int 0)]))]
TARGET_64BIT !TARGET_PARTIAL_REG_STALL
#
reload_completed
[(set
On May 26, 2014, at 4:26 AM, FX fxcoud...@gmail.com wrote:
Here’s a patch that removes all the casts on output operands in x86/x86_64
code in longlong.h.
I’d love for someone to explain why the casts were there in the first place… I
like the idea of removing them.
On May 26, 2014, at 2:22 AM, FX fxcoud...@gmail.com wrote:
This causes GCC bootstrap to fail on Darwin systems (whose system compiler
is clang-based). Since PR 61146 was resolved as INVALID (but I’m not sure
it’s the right call, see below), I’ve filed a separate report for the
bootstrap
Ping?
Or, I can ask, any objections? In https://gcc.gnu.org/PR61146 it is stated
that GMP removed the casts in 2005.
On May 26, 2014, at 4:26 AM, FX fxcoud...@gmail.com wrote:
So changing just 2 of them doesn't feel right to me…
[Again, with the patch actually attached… sorry]
Here’s a
Gosh, https://gcc.gnu.org/projects/cxx0x.html and
https://gcc.gnu.org/gcc-4.8/cxx0x_status.html seem to old and dated now.
First, the standard before last has been published. Second, at some point, it
can’t be experimental anymore. Would be nice if someone could update the
content. The
On Sep 5, 2014, at 4:05 AM, Thomas Schwinge tho...@codesourcery.com wrote:
Updating my GCC trunk working tree from r212389 (2014-07-09) to r214918
(2014-09-04), I notice that (only) in libstdc++ testing, and only for the
second multilib of »RUNTESTFLAGS='--target_board=unix\{,-m32\}'« (so, the
On Sep 9, 2014, at 8:14 AM, VandeVondele Joost joost.vandevond...@mat.ethz.ch
wrote:
Attached is a further revision of the patch, now dealing with check-c++.
So when last I played in this area, I wanted a command line tool that would
bin-pack from the command line. I would then grab the
On Sep 10, 2014, at 1:38 PM, David Malcolm dmalc...@redhat.com wrote:
Perhaps this is a silly question, but has anyone tried going the whole
way and not having buckets, going to an extremely fine-grained approach
No, we fear the overhead, but do not know what it is.
On Sep 10, 2014, at 2:23 PM, Jakub Jelinek ja...@redhat.com wrote:
Seems file mkdir in tcl doesn't error on pre-existing directory,
shell mkdir will. :-)
On Sep 11, 2014, at 3:15 PM, Jakub Jelinek ja...@redhat.com wrote:
That is news to me, but given the amount of test -a/-o uses e.g. in
gcc/configure and hundreds of places, I'd say what we care is what is more
portable to old shells.
No, we can’t care about that. If that were true, the _ _
On Sep 12, 2014, at 9:32 AM, Jakub Jelinek ja...@redhat.com wrote:
Here is my latest version of the patch.
With this patch I get identical test_summary output on make -k check
(completely serial testing) and make -j48 -k check from toplevel directory.
Major changes since last version:
1)
On Sep 12, 2014, at 9:32 AM, Jakub Jelinek ja...@redhat.com wrote:
Here is my latest version of the patch.
I did a timing test:
Before:
real0m57.198s
user1m24.736s
sys 0m19.816s
after:
real0m28.224s
user1m27.823s
sys 0m22.374s
This is a -j70 run on a 64 core power7
On Sep 15, 2014, at 9:05 AM, Jakub Jelinek ja...@redhat.com wrote:
All the updates sound good.
Regtested on x86_64-linux, without the patch toplevel make -k check
took 8hrs3minutes (don't have time data for that run),
This confuses me, but, no matter. Isn’t 8hrs time data? :-)
patch
On Oct 7, 2014, at 2:07 PM, Marek Polacek pola...@redhat.com wrote:
I'd like to kick off a discussion about moving the default standard
for C from gnu89 to gnu11.
I endorse the change of default.
The things I had to fix in the testsuite nicely reflect what we can expect
in the real life:
A
On Nov 23, 2014, at 4:06 PM, FX fxcoud...@gmail.com wrote:
One question to build maintainers, and one patch submitted to top-level
configure.ac
So, not sure who wants to review this. From the darwin perspective, Ok.
On Nov 25, 2014, at 12:15 PM, Jakub Jelinek ja...@redhat.com wrote:
On Tue, Nov 25, 2014 at 03:27:40PM +0100, Tom de Vries wrote:
This patch fixes that by ensuring that we print that unsupported message
only once.
The resulting test result comparison diff is:
2014-11-25 Tom de Vries
On Dec 16, 2014, at 12:46 PM, Iain Sandoe i...@codesourcery.com wrote:
On 16 Dec 2014, at 20:40, Dominique d'Humières wrote:
Another testsuite issue on darwin is that testsuite doesn’t clean up the
.dSYM directories it generates. This gets really annoying on my autotester
:(
I have a
On Dec 16, 2014, at 1:24 PM, Dominique d'Humières domi...@lps.ens.fr wrote:
My patch is different and I am attaching it (it is quite old, so it may not
apply cleanly). The problem for more evolved form is that *.dSYM are
directories and ASAICT there is no command in derange to remove them.
On Dec 17, 2014, at 2:21 AM, FX fxcoud...@gmail.com wrote:
Currently gcc 4.8.4 does not bootstrap on darwin14 (Yosemite) due to pr61407.
Would it be possible to apply the patch at
https://gcc.gnu.org/bugzilla/attachment.cgi?id=33932
before 4.8.4 is released? Results with the patch are posted
On Dec 17, 2014, at 3:44 AM, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Dec 17, 2014 at 11:16:18AM +0100, Dominique Dhumieres wrote:
Currently gcc 4.8.4 does not bootstrap on darwin14 (Yosemite) due to pr61407.
Why has it not been pushed in earlier?
No good reason. No one checked it into
On Jun 20, 2007, at 4:57 AM, Bokhanko, Andrey S wrote:
Actually, I'm interested in how to force conservative analysis
*without*
source code modifications (only with compiler's options).
While we'd recommend using a language called C, you might be able to
use -O0 or older compilers (3.3 and
On Jun 23, 2007, at 2:38 PM, Robert Dewar wrote:
On the contrary, since gcc can always be built using third party C
compilers, it would be much easier to smoke out and eliminate any
such behavior (indeed this example shows the merit of maintaining
the property that gcc can be compiled by
On Jun 24, 2007, at 9:32 PM, ganesh subramonian wrote:
I have a very basic doubt regarding gcc,binutils and kernel.
How closely tied are the linux kernel version and the gcc/glibc
versions?
Versions of gcc are never (much) dependent on kernel versions. They
are rarely dependent on glibc
On Jun 25, 2007, at 10:59 AM, Eric Botcazou wrote:
Probably. But, as Mike told me privately, STABS are sensitive to
the build
directory, so I tried again and got identical executables byte-for-
byte:
Cool. Glad you could verify them on a byte for byte basis. This
helps keep your
On Jun 25, 2007, at 3:31 PM, Hui-May Chang via RT wrote:
I thought I have completed it earlier. Can you check for me? Thanks!
Don't worry, they just spammed the entire list with a seemingly off-
list issue I think they just meant to ping Francois.
On Jul 2, 2007, at 2:48 AM, allozano wrote:
I need get the param type. For example
void f (std::string){...}
with Macros TYPE_NAME, TYPE_DECL,... i find the param is string
but I need std::string
Look for CONTEXT in *.h.
On Jul 9, 2007, at 11:04 AM, Ian Lance Taylor wrote:
OK, what do you think of this patch?
In hopes of ending this thread, I like this color of red... :-)
On Jul 12, 2007, at 9:23 AM, Michael Eager wrote:
I was looking through dwarf2out.c, tracking down the
cause for different assembly code being generated
when gcc was run on 32-bit and 64-bit hosts.
When QAing, it is very useful to be able to compare two .s files.
This means that we should
On Jul 13, 2007, at 2:05 PM, Tom Tromey wrote:
I've started work on a project to turn GCC into an incremental
compiler.
Sounds neat. :-)
The basic idea of the project is to run GCC as a server (similar in a
way to the old compile server branch) and try to minimize the amount
of
On Dec 17, 2007, at 9:45 PM, Sven Herzberg wrote:
I was just browsing the gcc-list to see if there are any updates on
the Objective-C 2.0 extensions. Can you please send and email to the
gcc-list with the current state?
I hope to be able to contribute them in the next year, but exactly
On Dec 18, 2007, at 10:08 AM, Ismail Dönmez wrote:
Any schedule for fixing Obj-C++ regressions on mainline?
Same answer. My hope would be that people that introduce regressions
would fix them...
On Feb 6, 2008, at 9:58 AM, Kaveh R. GHAZI wrote:
Is there any interest in getting the testsuite failures in objc++
fixed?
Yes, but, if you have other, more important things... :-)
http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00401.html
I generally include it in my testsuite results
On Feb 21, 2008, at 6:10 AM, FX wrote:
Use of long double math builtins on powerpc-darwin
My question is simple: are there any plans to fix?
I don't know of anyone working on it. The issue is trivial enough to
fix, if people want to fix it. Essentially, the various builtins need
to
On Feb 21, 2008, at 8:31 PM, Kaveh R. GHAZI wrote:
Are current Darwin maintainers working on fixing anything in the FSF
sources?
Currently no. The transition to GPL v3 is problematic for us in the
short/mid term. :-( Longer term, we'll see how it goes.
If not, maybe we need more
On Feb 22, 2008, at 12:14 PM, Kaveh R. Ghazi wrote:
If someone steps forward, are you allowed to follow the patches list
We can't read the patches nor gcc list.
and give feedback and/or approve patches for new contributors? I
assume this is possible since you helped out with objc++ review
On Feb 22, 2008, at 12:50 PM, Joe Buck wrote:
I guess that I'm still not clear on the restrictions you are under.
We could ask people to cc proposed darwin patches to you, but if
we ask people to do that routinely, then you're effectively on the
list
again.
Not really, the list is much
On Feb 23, 2008, at 2:57 AM, FX Coudert wrote:
1. the target part, in gcc/config/darwin* and gcc/config/rs6000,
that takes care of setting correct assembler names for the builtins,
if needed
The patch was bootstrapped on powerpc-apple-darwin9.2.0 with C and
Fortran, and regtested with
On Aug 15, 2011, at 5:42 AM, Richard Guenther wrote:
The argument still holds that no reasonable memcpy implementation
will reject the src == dest case.
Hum... Sounds like if that's the case that we should document it in the manual
as something we expect (requirement) of the memcpy
On Mar 26, 2012, at 1:56 PM, Steven Bosscher wrote:
This patch is one way to address PR44982.
That's a great idea, I like it. There is only one problem that I know of that
prevents it from going in now. We emit errors/warnings from below finalize and
there is a feature in which we emit all
On Jun 5, 2012, at 1:23 PM, Steven Bosscher wrote:
On Tue, Jun 5, 2012 at 8:55 PM, Iain Sandoe i...@codesourcery.com wrote:
I would welcome a simple solution if one is available, although I don't
quite see what you have in mind at present.
This is what I have in mind. Untested, but it shows
On Jun 25, 2012, at 6:48 AM, Steven Bosscher wrote:
In fact darwin does follow the
naming convention, the only difference is that it wraps the section
name in a segment label (always __DWARF__) and adds some flags
(always regular,debug). I would have expected there to be a way to
change a
On Jun 27, 2012, at 2:07 AM, Alexandre Oliva wrote:
Why? We don't demand a working plugin. Indeed, we disable the use of
the plugin if we find a linker that doesn't support it. We just don't
account for the possibility of finding a linker that supports plugins,
but that doesn't support the
On Jun 28, 2012, at 12:16 AM, Alexandre Oliva aol...@redhat.com wrote:
On Jun 27, 2012, Mike Stump mikest...@comcast.net wrote:
On Jun 27, 2012, at 2:07 AM, Alexandre Oliva wrote:
Why? We don't demand a working plugin. Indeed, we disable the use of
the plugin if we find a linker that doesn't
On Jun 28, 2012, at 4:39 AM, Alexandre Oliva aol...@redhat.com wrote:
On Jun 28, 2012, Jakub Jelinek ja...@redhat.com wrote:
On Thu, Jun 28, 2012 at 04:16:55AM -0300, Alexandre Oliva wrote:
I'd very be surprised if I asked for an i686 native build to package and
install elsewhere, and didn't
On Jun 28, 2012, at 3:19 PM, Alexandre Oliva wrote:
On Jun 28, 2012, Mike Stump mikest...@comcast.net wrote:
The next would be because it would be a speed hit to re-check at
runtime the qualities of the linker and do something different.
But then, our testsuite *does* re-check at runtime
On Jul 2, 2012, at 4:06 AM, Alexandre Oliva wrote:
On Jun 29, 2012, Mike Stump mikest...@comcast.net wrote:
First, let get to the heart of the matter. That is the behavior of
compiler.
That's a distraction in the context of a patch to improve a feature
that's already present
In doing up the mods for the constant wide int code, we found a nasty including
ordering problem that seems only tangentially related to our code. In
options.h this is generated:
/* Anything that includes tm.h, does not necessarily need this. */
#if !defined(GCC_TM_H)
#include input.h /* for
On Jun 18, 2008, at 6:58 AM, Jack Howarth wrote:
someone has proposed a patch to allow static linkage of libgfortran
into fortran programs on darwin. One of the Darwin maintainers
should review this since it touches the gcc/config/x-darwin
file. FYI.
On Dec 10, 2008, at 9:43 AM, Jack Howarth wrote:
If I now understand correctly, the symbols present in updated
versions of
libgcc that are not in the stock system libgcc on darwin - need
to be
mentioned in the stub libraries (ligcc_s.10.{4,5,...} ). The
emutls ones
were not present causing
On Dec 10, 2008, at 10:23 AM, IainS wrote:
I wonder what a good long-term solution would be?
You can try something like:
#define
REAL_LIBGCC_SPEC \
%{static-libgcc|static: -lgcc_eh -
lgcc;\
On Dec 10, 2008, at 7:03 PM, Jack Howarth wrote:
I am confused. Assuming one builds FSF gcc configured with
--enable-threads, shouldn't that create a libgcc.a for FSF gcc
containing the ___emutls_get_address and ___emutls_get_address
symbols?
No, the people that wrote ___emutls_get_address
On Dec 10, 2008, at 3:24 PM, IainS wrote:
if one did -lgcc_s.10.x -lgcc_s.1 would that break it?
... should it not pick up only the unresolved symbols from s.1
I think this is the best long term solution. Things that can be found
from the system are, those that aren't, come from the newly
On Dec 19, 2008, at 6:24 PM, Jack Howarth wrote:
Could you comment on...
http://gcc.gnu.org/ml/gcc/2008-12/msg00310.html
Is there some specific reason it's done this way?
Yes, libgcc_s is carefully built with carefully controlled exports.
They are controlled by:
gcc/libgcc-std.ver
On Jan 20, 2009, at 11:22 PM, Jack Howarth wrote:
Are there any observations that you could make concerning
the thread...
http://gcc.gnu.org/ml/gcc/2009-01/msg00297.html
Sure, in i386/darwin.h we have:
/* Since we'll never want a stack boundary less aligned than 128 bits
we need the
On Jan 21, 2009, at 8:40 PM, Uros Bizjak wrote:
Sure, in i386/darwin.h we have:
/* Since we'll never want a stack boundary less aligned than 128 bits
we need the extra work here otherwise bits of gcc get very grumpy
when we ask for lower alignment. We could just reject values less
than
On Jan 21, 2009, at 3:43 PM, Jack Howarth wrote:
So that invalidates your previously proposed patch? Or should I
still test it?
No need to test, I was wrong about that being the bit that causes it.
The description I last posted should be about right however, one just
needs a bit of time
On Jan 28, 2006, at 10:22 AM, Carlos Barros wrote:
anyone can explain me this??
Wrong list, you might try gcc-help, otherwise you can find the
answers in the source code to the compiler, if you wish to dig into
it. In short, gcc has lots of latitude to do just about anything it
wants
On Jan 30, 2006, at 9:50 AM, murali wrote:
I am trying to change the number of registers for simplescalar's gcc
(2.7.2.3) compiler.
It is unlikely we're going to help much with 2.7.2.3, we'd recommend
up-porting to gcc 4.2 to start with.
I'm trying to get:
void foo() {
int rowfraclo[2];
rowfraclo[1] = 42;
asm (movd mm6, %a0 : : p (rowfraclo+1));
}
to generate:
movd mm6, -4(%ebp)
at -O0. Currently we generate:
leal-8(%ebp), %eax
addl$4, %eax
movd mm6, (%eax)
With the below patch (still running
I was looking through the altivec.md file and found the below. Seems
like either they should all be , or i; my guess, they should all
be i.
(define_insn altivec_vspltb
[(set (match_operand:V16QI 0 register_operand =v)
(vec_duplicate:V16QI
(vec_select:QI
On Feb 2, 2006, at 1:04 PM, Gabriel Dos Reis wrote:
Can someone help Lee with SSH and SVN checking issues?
I'd recommend contacting [EMAIL PROTECTED]
He has a read+write access to GCC sources.
Apparently not.
When bulk merging trunk to local release branch, svn reports whole
file conflicts as 'A'. :-(
svn status
after the merge is necessary to find the conflicts.
I'm using svn client:
mrs $ svn --version
svn, version 1.3.0 (r17949)
compiled Jan 4 2006, 12:42:53
and the server was either
On Jan 30, 2006, at 11:50 AM, Andrew Pinski wrote:
I'm trying to get:
void foo() {
int rowfraclo[2];
rowfraclo[1] = 42;
asm (movd mm6, %a0 : : p (rowfraclo+1));
}
With the below patch (still running the testsuite) I can get the
compiler to generate that code. So, the question is how
On Feb 8, 2006, at 5:51 AM, [EMAIL PROTECTED] wrote:
I think the idea of matrix linking is quite different
You could have saved all the space and just said, yeah, but mine can
rebind printf. My response would be, yes, so can we. So, I've yet
to see much of a difference.
On Feb 10, 2006, at 5:22 AM, Sapojnikova T.F. wrote:
Can I use c++ (g++) and fortran (g77) together in one
multilanguage application?
Wrong list, gcc-help is more appropriate, thanks.
On Feb 13, 2006, at 7:28 PM, Eric Fisher wrote:
Suppose I have only pc-relative branch instructions such as 'b offset'
and don't have pc-region branch instructions such as 'j target'. So
what the function call should be translated? Do I have to always use
two instructions such as 'la reg,
On Feb 15, 2006, at 7:27 AM, Perry Smith wrote:
I am assuming I am doing something wrong but I am hoping someone can
give me a clue as to where to look.
I'd fire up a debugger and type up a couple of times from a
breakpoint in the dtor. If you want to randomly try things, if you
inserted
On Feb 17, 2006, at 8:04 PM, Serge Dundich wrote:
I need to define the constant memory address/offset in i386 gcc
inline asm,
i.e. immediate value without $ prefix, so I can use it as a
constant offset for
some memory address statement.
Is there any way to do that?
Sure, the manual
On Feb 21, 2006, at 7:40 PM, Amarnath wrote:
I am in need of the following version of Bison tool's installation
package available with CYGWIN.
We are not cygwin. You can go over to the cygwin site and install it
and it will let you grab and install this. Try google, if you can't
find the
On Feb 22, 2006, at 6:46 AM, Florian Radulescu wrote:
Please I would need some instructions on how to compile and install
gcc for Intel XScale.
You would need to use google to find the gcc documentation that
describes this in detail. If you do that, you should find http://
On Feb 23, 2006, at 5:03 PM, Frank Cusack wrote:
#include signal.h
int CS;
$ g++ ll.cc
ll.cc:2: error: expected unqualified-id before numeric constant
It works correctly on Solaris/sparc. My system is amd64, using the
Sun gcc. /usr/include/sys/regset.h #define's CS on x86/amd64 only ...
hence
On Feb 23, 2006, at 9:05 PM, Dan Kegel wrote:
it seems to be slow at preprocessing C++ source.
This matters quite a bit when running distcc.
One way to mitigate this would be to use a precompiled header, and
use -fpch-preprocess with distcc and ship the .gch across instead.
This saves the
On Feb 24, 2006, at 2:08 AM, Nemanja Popov wrote:
Is it possible to workaround this problem in my port files.
Sounds like a bug, I'd recommend just finding and fixing the bug.
Can't imagine it is more than a line to fix.
Watch for TREE_USED, SYMBOL_REF_USED, mark_referenced,
1 - 100 of 3045 matches
Mail list logo
