Richard Guenther writes:
> On 6/12/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > On Mon, Jun 12, 2006 at 01:01:47PM +0100, Andrew Haley wrote:
> > >
> > > I'm starting to be a little suspicious about host2little(). I wonder
> > > if that&
[EMAIL PROTECTED] writes:
> On Mon, Jun 12, 2006 at 02:21:21PM +0200, Richard Guenther wrote:
> > On 6/12/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > >On Mon, Jun 12, 2006 at 01:01:47PM +0100, Andrew Haley wrote:
> > >>
> > >> I'm
[EMAIL PROTECTED] writes:
> On Mon, Jun 12, 2006 at 12:30:50PM +, [EMAIL PROTECTED] wrote:
> > On Mon, Jun 12, 2006 at 02:21:21PM +0200, Richard Guenther wrote:
> > > On 6/12/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > > >On Mon, Jun 12, 20
[EMAIL PROTECTED] writes:
>
> Well, my point above was that -strict-aliasing is included in -O2 and
> my code works fine at -O2. Only -O3 causes problems, so I didn't expect
> -fno-strict-aliasing to make any difference.
That doesn't follow at all. -O3 exposes much more information to the
co
Roberto COSTA writes:
>
> By the way, from the previous messages, I understand that the
> inclusion of a CIL back-end into gcc cannot be taken as granted
> until the issue is discussed and an approval is obtained.
Right. And I wouldn't hold my breath waiting.
> In the meantime, I hope this
[EMAIL PROTECTED] writes:
> On Tue, Jun 13, 2006 at 10:37:29AM +, [EMAIL PROTECTED] wrote:
> > On Mon, Jun 12, 2006 at 04:59:04PM -0700, Ian Lance Taylor wrote:
> > >
> > > Probably better to say that these are read-write operands, using the
> > > '+' constraint.
> > >
> > > > Now ever
Etienne Lorrain writes:
> > The correct version is I think,
> >
> > void longcpy(long* _dst, long* _src, unsigned _numwords)
> > {
> > asm volatile (
> > "cld \n\t"
> > "rep \n\t"
> > "movsl \n\t"
> >// Outputs (read/write)
> >
[EMAIL PROTECTED] writes:
> On Tue, Jun 13, 2006 at 12:01:39PM +0100, Andrew Haley wrote:
> >
> > All you've got here is an inline asm version of
> >
> > inline void longcpy(long* _dst, long* _src, unsigned _numwords)
> > {
> > __builtin_
kernel coder writes:
> hi,
> I'm trying to figure out the code flow of gcc.But i'm not been
> able to locate the location at which an expression is compared with
> pattern given in .md file.
>
> I think .md file is resposible fo generation of emit-insn.c
> file.But again at whic
Dustin Laurence writes:
> On Fri, Jun 16, 2006 at 02:05:13PM -0700, Mike Stump wrote:
>
> > If every language were going to have the feature, then, moving it
> > down into the mid-end or back-end might make sense, but I don't think
> > it does in this case.
>
> Personally, I'd like, an
Does using fields of auto variables of union type generate code that
is less efficient than it would be using scalars?
That is, if in C++ I declare my variables as
foo()
{
union
{
int n;
};
...
}
as opposed to simply
foo()
{
int n;
...
}
would gcc generate inferior code? Or,
Andrew Pinski writes:
>
> On Jun 20, 2006, at 7:20 AM, Andrew Haley wrote:
>
> > Does using fields of auto variables of union type generate code that
> > is less efficient than it would be using scalars?
>
> If it is only one used field at a time (and the add
Shaun Jackman writes:
> Hello Richard, Dan,
>
> I'm trying to track down which part of the GCC source tree makes the
> decision to emit either a R_ARM_GOT32 or a R_ARM_GOTOFF32 relocation.
> A new feature in GCC 4.1 emits a R_ARM_GOTOFF32 relocation for a
> reference to a static function. I
Andreas Schwab writes:
> "Dave Korn" <[EMAIL PROTECTED]> writes:
>
> > But it's really legal to cast away const?
>
> All that matters is the effective type of the accessed object, see 6.5#7.
It's not clear to me that it's legal to convert (const int*) to
(int*). 6.3.2.3, Pointers, says
2
Elmar Krieger writes:
>
> I searched hard, but couldn't determine conclusively if the C standard
> allows to alias a void* pointer with a char* pointer.
>
> If that's not undefined behavior, then the following may be a glitch in
> GCC 4.1.0 when compiled with -O2.
>
> Here's the ugly m
Ian Lance Taylor writes:
> Yuri Pudgorodsky <[EMAIL PROTECTED]> writes:
>
> > Compiling openssl-0.9.8b with gcc-4.2 snapshots, I found gcc 4.2
> > fortifies its check for function pointer conversion and generates
> > abort for PEM_read_X509_AUX() and similar wrappers.
>
> Personally speaki
Ian Lance Taylor writes:
> Andrew Haley <[EMAIL PROTECTED]> writes:
>
> > Ian Lance Taylor writes:
> > > Yuri Pudgorodsky <[EMAIL PROTECTED]> writes:
> > >
> > > > Compiling openssl-0.9.8b with gcc-4.2 snapshots, I found gcc
Ian Lance Taylor writes:
> Andrew Haley <[EMAIL PROTECTED]> writes:
>
> > If we're going to guarantee this stuff for the future, we'll have
> > to fix the bug, make sure it's doesn't destabilize the compiler
> > and write some test cases. If
Ian Lance Taylor writes:
> Andrew Haley <[EMAIL PROTECTED]> writes:
>
> > If we make a change for openssh to allow this undefined behaviour,
> > then do we agree to keep it working or not? If we agree that we will,
> > then we have to at least add some test
Joern RENNECKE writes:
> Joern Rennecke wrote:
>
> > Eric Botcazou wrote:
> >
> >>> make[3]: Leaving directory `/mnt/scratch/nightly/2006-07-04/i686'
> >>> Comparing stages 2 and 3
> >>> warning: ./cc1-checksum.o differs
> >>> warning: ./cc1plus-checksum.o differs
> >>> warning: ./cc1obj-
Mark Mitchell writes:
>
> I also agree with Gaby that we should document this as an extension. If
> we go to the work of putting it back in, we should ensure that it
> continues to work for the foreseeable future. Part of that is writing
> down what we've decided.
We can't make function po
Yuri Pudgorodsky writes:
>
> > We can say something like:
> >
> > "In GNU C, you may cast a function pointer of one type to a function
> > pointer of another type. If you use a function pointer to call a
> > function, and the dynamic type of the function pointed to by the
> > function poin
jacob navia writes:
> Hi
>
> I want to use the function
>
> __register_frame_info
>
> to dynamically register DWARF2 unwind frames.
>
> Where is the library I should link with??
>
> Environment: linux 64 bits
prefix/lib64/libgcc_s.so.1; but you shouldn't specify this library becau
jacob navia writes:
> Hi
>
> I have now everything in place for dynamically register the
> debug frame information that my JIT (Just in time compiler)
> generates.
>
> I generate a CIE (Common information block), followed by
> a series of FDE (Frame Description Entries) describing
> each
jacob navia writes:
> Hi
>
> Context:
>
> I am writing a JIT and need to register the frame information about
> the generated program within the context of a larger C++ program
> compiled with g++. Stack layout is like this:
>
> catch established by C++
> JITTED code ge
jacob navia writes:
> Andrew Haley wrote:
>
> >I suspect that the gcc unwinder is relying on __dl_iterate_phdr to
> >scan the loaded libraries and isn't using the region that you have
> >registered.
> >
> >But this is odd, becasue when I look
jacob navia writes:
> This is just to tell you that now it is working.
>
> I have suceeded in making my JIT generate the right tables for gcc
Excellent.
> As it seems, both gcc 4.1 and gcc 3.3 seem to work OK.
> Can anyone confirm this?
That they work OK? No, you are the only person who h
Gabriel Dos Reis writes:
> "Rafael Espíndola" <[EMAIL PROTECTED]> writes:
>
> | I am trying to build a table with offsets of global pointers from a
> | given pointer:
> |
> | void *fs[] = {f1 - f1, f2 - f1};
> |
> | where f1 and f2 are functions.
> |
> | GCC is able to figure out that
Rafael Espíndola writes:
> > because that is what the language standard says.
> >
> > In general, the difference between two global pointers is something
> > known only to the linker -- too late to evaluate as constant
> > expression.
> In the particular case of two static functions or two st
Juerg Lehni writes:
> I compiled the lastest GCJ from SVN head today, and when linking to
> my application that uses JNI invocation and worked well before, I
> recieved a "undefined symbols" error about _JNI_CreateJavaVM and
> _JNI_GetDefaultJavaVMInitArgs.
>
> And indeed, these symbol
Christian Joensson writes:
> This is on a cygwin/winxp system... while building gcc trunk,
> currently, and for quite some time, I have been getting this warning:
>
> /usr/local/src/trunk/objdir/./gcc/xgcc
> -B/usr/local/src/trunk/objdir/./gcc/ -B/usr/local/i686-pc-cygwin/bin/
> -B/usr/local
Geoffrey Keating writes:
>
> On 11/09/2006, at 3:59 PM, Andrew Pinski wrote:
>
> >>
> >> Geoff,
> >>Did you notice that a new libjava regression occured today on
> >> Darwin
> >> apparently after revision 116838 but by revision 116843? The
> >> testcase...
> >>
> >> FAIL: Threa
Jack Howarth writes:
>I noticed that on Darwin PPC we get warnings of the form...
>
> symbol _fabsf used from dynamic library /usr/lib/libm.dylib(fabs.o) not from
> earlier dynamic library /sw/lib/gcc4/lib/libgcj.8.dylib(sf_fabs.o)
> symbol _fabs used from dynamic library /usr/lib/libm.d
Kai Tietz writes:
> I am currently on to build the gcc target support for x86_64-pc-mingw64.
> While this porting I found a strange register truncation, I do not believe
> it is valid. For the c code:
>
> int foo(char *,...);
> int doo(char *h) { return foo("abc ",h); }
>
Jack Howarth writes:
> What is the situation with multilib builds of libffi and
> libjava in gcc 4.2 on architectures like x86_64 and ppc64 linux?
It works fine.
> I ask because I noticed that Fedora's gcc 4.1.1 specfile explicitly
> disables the multilib builds in libjava and doesn't se
Paul Biggar writes:
> I've come to a bit of an impasse in the (java) escape analysis. In
> order to do interprocedural analysis effectively, I need to know what
> methods are called. However, it is rarely the case that this
> information is available. For example, a call to System.out.println
Ian Lance Taylor writes:
> Andrew Haley <[EMAIL PROTECTED]> writes:
>
> > Yes. You'll need to represent virtual function calls at the GIMPLE
> > level, or to keep track of which calls are associated with which
> > methods. This is key to getting IPA to w
Nathan Sidwell writes:
>
> I question if it is better to fold early. As I've said before, I think
> the optimizations that fold performs should be turned into a proper SSA
> optimization phase% -- that can be repeatedly applied as necessary. In the
> front end, folding should not generally
This is about DWARF 2 unwinding through shared libraries.
As far as I can see, on current x86 GNU/Linux targets we don't call
__register_frame_info() or __register_frame_info_bases() from the
library startup code in crtbegin. There is code to do it, but it's
disabled.
When _Unwind_Find_FDE() is
Richard Henderson writes:
> On Tue, Feb 15, 2005 at 05:27:15PM +0000, Andrew Haley wrote:
> > So, now for my question: why do we not call __register_frame_info() or
> > __register_frame_info_bases() ?
>
> Because in the normal case for C/C++, folks don't use tha
Mark Mitchell writes:
> >
> 1. Front ends should build up trees, calling fold only when/if they
> want. For example, in C++, we would want to call fold when we finish
> processing an "integral constant expression", which is a term of art in
> C++. (Though that operation would be recursi
Roger Sayle writes:
>
> On Tue, 15 Feb 2005, Andrew Haley wrote:
> > There's one other thing to bear in mind when considering the way that
> > fold relates to language front ends. We've seen problems in Java
> > where fold() returned tree nodes that Java di
Jakub Jelinek writes:
> > > While I still like using dl_iterate_phdr instead of
> > > __register_frame_info_bases for totally aesthetic reasons, there
> > > have been changes made to the dl_iterate_phdr interface since the
> > > gcc support was written that would allow the dl_iterate_phdr
Patrick McFarland writes:
> Today lilo (the FreeNode network owner) has decided to make one step away in
> a
> direction opposite of freedom, and banned all Tor users from the FreeNode
> network.
I can't find a statement from FreeNode.
This would be a more appropriate discussion for GNU, w
Andrew Haley writes:
> Jakub Jelinek writes:
>
> > > > While I still like using dl_iterate_phdr instead of
> > > > __register_frame_info_bases for totally aesthetic reasons, there
> > > > have been changes made to the dl_iterate_phdr inte
On 03/29/2013 06:55 PM, Alexander Ivchenko wrote:
> When compiling a shared library with "-mandroid -shared" the option
> -Bsymbolic for linker is turned on by default. What was the reason
> behind that default? Isn't using of -Bsymbolic somehow dangerous and
> should be avoided..?
Yes indeed, -
On 04/03/2013 11:02 AM, Alexander Ivchenko wrote:
> Thank you for your answers, seems that the question about the reason
> with default -Bsymbolic is still open.. we are not clairvoyant, but it
> is implemented in GCC so we should understand the reason :)
I suppose so, but we always follow the pl
On 05/07/2013 08:18 AM, Jens Bauer wrote:
> Please let me know if I need to provide more information.
I'm afraid you have sent this to the wrong place. The assembler doesn't
use gcc, and this is the gcc list. Please send it to the binutils list.
Andrew.
On 05/30/2013 03:03 PM, Raphael Clifford wrote:
> Thank you for this. My question was about something more specific
> however. I am interested specifically in branch prediction. For
> example one could add __builtin_expect or the compiler can use the
> information it finds in its profiling. How
On 06/01/2013 10:08 PM, Jens Bauer wrote:
> I would expect gcc to complain when it meets the second loop as well as the
> third loop, but it didn't detect that there is something wrong with the
> second loop.
>
> ...Is this a bug ?
C allows you to index one element beyond the end of an array.
On 06/28/2013 08:53 AM, Shiva Chen wrote:
> I have a case which will generate abs instructions.
>
> int main(int argc)
> {
> if (argc < 0)
>argc = -(unsigned int)argc;
> return argc;
> }
>
> To my understanding, given that argc=0x8000 in 32bit int plaform,
> the result of
On 07/06/2013 04:41 PM, Bruce Korb wrote:
> Why is it that configure worked but stubs-32.h was not found?
> Googling leads me to:
>> > You're missing the 32 bit libc dev package:
> but the configure step should detect that
The trouble with making suggestions like this is that someone will ask
you
On 07/08/2013 06:17 AM, Gabriel Dos Reis wrote:
> On Sun, Jul 7, 2013 at 6:02 PM, Jonathan Wakely wrote:
>> On 7 July 2013 21:33, Gabriel Dos Reis wrote:
>>> How about not enabling multi lib build by default on targets we now that
>>> will fail anyway? I have the suspicion this problem is unique
On 07/08/2013 07:33 AM, Gabriel Dos Reis wrote:
> I strongly disagree. We (GCC) are at fault here. We implicitly
> enable a feature at configure time without knowing its builds
> will succeed (despite having repeated reports that it does often
> fail) without much input from the builder (who migh
On 07/09/2013 12:59 PM, Andreas Arnez wrote:
> With this situation at hand, I wonder whether it's a good idea to keep
> maybe-uninitialized included in -Wall. Projects which have been using
> "-Wall -Werror" successfully for many years are now forced to
> investigate non-existing bugs in their cod
On 07/09/2013 02:56 PM, Andreas Arnez wrote:
> What matters is whether *some* stages of production code development use
> this combination of options. It could certainly be argued whether it
> should also be a project's "configure" default, like currently the case
> for gdb.
It's not a problem fo
On 07/10/2013 05:11 PM, Andi Kleen wrote:
> FWIW basically -Werror -Wall defines a compiler version specific
> variant of C. May be great for individual developers, but it's always
> a serious mistake in any distributed Makefile.
I could not have put it any better.
Andrew.
On 07/10/2013 05:48 PM, paul_kon...@dell.com wrote:
> It seems to me there are two cases. One is releases, where you want to
> maximize the odds that an install will work. For that you clearly don't want
> -Werror, and you might want to trim back the warnings. The other is the
> development p
On 07/22/2013 10:07 AM, Evgeny Gavrin wrote:
> Hi, all!
>
> Earlier we (Samsung R&D Institute Rus) proposed to implement OpenACC for
> GCC: http://gcc.gnu.org/ml/gcc/2013-05/msg00060.html
>
> We got our assignment form, now. I can attach signed and approved pdf,
> if needed.
>
> What should we
On 07/24/2013 01:48 AM, David Starner wrote:
> I'd like to mention that I too was bit by this one on Debian. I don't
> have a 32-bit development environment installed; why would I? I'm
> building primarily for myself, and if I did have to target a 32-bit
> environment, I'd likely have to mess with
On 07/24/2013 09:35 AM, Florian Weimer wrote:
> On 07/24/2013 10:17 AM, Andrew Haley wrote:
>> On 07/24/2013 01:48 AM, David Starner wrote:
>>> I'd like to mention that I too was bit by this one on Debian. I don't
>>> have a 32-bit development environment ins
On 07/24/2013 10:04 AM, Florian Weimer wrote:
> On 07/24/2013 10:39 AM, Andrew Haley wrote:
>
>> Well, of course. It's a prerequisite for building GCC. I presume that
>> Debian has the same abilities as Fedora, where if you want to build GCC
>> you just type
>&g
On 07/24/2013 11:32 AM, David Starner wrote:
> On Wed, Jul 24, 2013 at 1:17 AM, Andrew Haley wrote:
>> On 07/24/2013 01:48 AM, David Starner wrote:
>>> I'd like to mention that I too was bit by this one on Debian. I don't
>>> have a 32-bit development en
On 07/24/2013 01:26 PM, David Starner wrote:
> On Wed, Jul 24, 2013 at 4:14 AM, Andrew Haley wrote:
>> I would just install GCC's build dependencies and build with the
>> defaults.
>
> I'm glad you have infinite hard-drive space. I rather wish fewer
> developer
On 07/24/2013 01:36 PM, Gabriel Dos Reis wrote:
>> There is no resistance whatsoever to making it work with real systems
>> and real workloads.
>
> It does not sound or look like that way.
>
>> The problem is that you don't know that people
>> running on 64-bit hardware often choose to compile -
On 07/24/2013 04:38 PM, Gabriel Dos Reis wrote:
> On Wed, Jul 24, 2013 at 8:44 AM, Andrew Haley wrote:
>> On 07/24/2013 01:36 PM, Gabriel Dos Reis wrote:
>>>> There is no resistance whatsoever to making it work with real systems
>>>> and real workloads.
>>&g
On 07/24/2013 11:51 PM, David Starner wrote:
> On Wed, Jul 24, 2013 at 8:50 AM, Andrew Haley wrote:
>> Not at all: we're just disagreeing about what a real system with
>> a real workload looks like.
>
> No, we aren't. We're disagreeing about whether it&#
On 07/26/2013 01:00 AM, David Starner wrote:
> On Thu, Jul 25, 2013 at 1:17 AM, Andrew Haley wrote:
>> On 07/24/2013 11:51 PM, David Starner wrote:
>>> On Wed, Jul 24, 2013 at 8:50 AM, Andrew Haley wrote:
>>>> Not at all: we're just disagreeing about what a re
On 07/27/2013 08:36 PM, Kiefmann Bernhard wrote:
> As you can read below, I need some information regarding the development of
> the GCC's. Some of the questions below were answered me already but I can not
> find any references to the use of formal or semi-formal methods. as
> - Logic / function
On 07/29/2013 02:06 PM, FX wrote:
> +build of a native compiler on @samp{x86_64-unknown-linux-gnu}, beware of
> +either:
> +
> +@itemize @bullet
> +@item having 32-bit libc developer package properly installed (the exact
> +name of the package depends on your distro); otherwise, you may encounter a
On 07/29/2013 02:55 PM, Bruce Korb wrote:
> On Mon, Jul 29, 2013 at 6:22 AM, Andrew Haley wrote:
>
>> There should be a better diagnostic.
>
> If you remember, the start of this thread was:
>
>> Why is it that configure worked but stubs-32.h was not found?
>
>
On 07/30/2013 05:50 AM, David Starner wrote:
> Sorry about the blank message; I accidentally hit the wrong button.
>
> On Mon, Jul 29, 2013 at 7:19 AM, Andrew Haley wrote:
>> It was "This is possible, but it's tricky, and it's really important
>> to get i
On 07/30/2013 01:52 PM, David Starner wrote:
> On Tue, Jul 30, 2013 at 12:56 AM, Andrew Haley wrote:
>> "We" is the GCC community. "We" really want multilibs to be built so
>> they get tested as much as possible. It's in the best interest of
>> all
On 08/12/2013 05:22 AM, sravan megan wrote:
> Anyone please help me to get out of this issue
It's hard for anyone to do that because we don't have your code.
Did you step through insn-output.c with GDB when compiling your
test case? What happened?
Andrew.
On 10/01/2013 09:11 AM, Richard Biener wrote:
> On Mon, Sep 30, 2013 at 6:09 PM, Jeremy Bennett
> wrote:
>> Hi all,
>>
>> You've probably seen that Joern Rennecke (amylaar) has been pinging
>> repeatedly for help reviewing the ARC port:
>>
>> http://gcc.gnu.org/ml/gcc-patches/2013-09/msg02072.ht
On 10/01/2013 11:32 AM, Richard Biener wrote:
Well, I want clarification as of whether assigning maintainership of the
port is equivalent to getting approval for checking in the port specific
parts. Which_I_ would think is reasonable (for the maintainer being
Joern even more so).
Well, sure i
On 10/01/2013 03:19 PM, Joern Rennecke wrote:
Quoting Richard Biener:
Good. So what remains is the configure parts, the libgcc parts and
the documentation parts. Though for all of them they look ARC
specific so maybe the maintainership covers these as well.
I suppose this automatism when bei
On 10/02/2013 12:47 AM, David Edelsohn wrote:
> It is unfortunate that global reviewers are so busy that they cannot
> review the few, infrequent new port submissions. But I find it very
> distasteful for someone to hyperventilate because other, busy people
> don't do something that appears obvious
On 10/02/2013 01:46 PM, David Edelsohn wrote:
On Wed, Oct 2, 2013 at 4:31 AM, Andrew Haley wrote:
On 10/02/2013 12:47 AM, David Edelsohn wrote:
It is unfortunate that global reviewers are so busy that they cannot
review the few, infrequent new port submissions. But I find it very
distasteful
On 10/30/2013 08:34 AM, Ondřej Bílka wrote:
>>
> The reasons of adding builtins is performance. Without that one can
> write a simple template to generically check overflows like
>
> template class overflow {
> public:
> C val;
> overflow operator + (overflow &y) {
> overflow ret;
>
On 10/30/2013 03:23 PM, David Brown wrote:
> I believe that's only a minor reason for making signed overflows
> undefined behaviour. If it were a matter of implementation, I think it
> would have been made "implementation defined" rather than "undefined",
> so that two's complement machines could
On 10/31/2013 08:02 AM, David Brown wrote:
> On 30/10/13 16:56, Andrew Haley wrote:
>> On 10/30/2013 03:23 PM, David Brown wrote:
>>> I believe that's only a minor reason for making signed overflows
>>> undefined behaviour. If it were a matter of implementation
On 11/09/2013 03:44 PM, Alec Teal wrote:
> If Java must go, and it must have a replacement Ada makes sense. The
> issues with Go (sadly, you guys are doing superb work) do make sense.
>
> I don't know enough about Java (the GCC front end and such) to know if
> it should go, if it does go why sho
On 11/11/2013 03:22 AM, Jeff Law wrote:
> On 11/09/13 08:55, Andrew Haley wrote:
>> On 11/09/2013 03:44 PM, Alec Teal wrote:
>>> If Java must go, and it must have a replacement Ada makes sense. The
>>> issues with Go (sadly, you guys are doing superb work) do make
On 11/11/2013 09:27 PM, Matthias Klose wrote:
> Am 11.11.2013 11:06, schrieb Andrew Haley:
>> On 11/11/2013 03:22 AM, Jeff Law wrote:
>>> On 11/09/13 08:55, Andrew Haley wrote:
>>>> On 11/09/2013 03:44 PM, Alec Teal wrote:
>>>>> If Java must go, and it
On 11/13/2013 10:56 AM, Richard Biener wrote:
> At least we don't need a Java source code frontend, no? Just keeping
> the bytecode compiler and GIJ should be enough? That way we can
> strip the classpath copy of everything that isn't needed, thus not
> provide a Java library. Reduces testing co
On 11/13/2013 11:29 AM, Richard Biener wrote:
> On Wed, Nov 13, 2013 at 12:24 PM, Andrew Haley wrote:
>> On 11/13/2013 10:56 AM, Richard Biener wrote:
>>> At least we don't need a Java source code frontend, no? Just keeping
>>> the bytecode compiler and GIJ sh
On 11/13/2013 12:37 PM, Richard Biener wrote:
> On Wed, Nov 13, 2013 at 12:52 PM, Andrew Haley wrote:
>> On 11/13/2013 11:29 AM, Richard Biener wrote:
>>> On Wed, Nov 13, 2013 at 12:24 PM, Andrew Haley wrote:
>>>> On 11/13/2013 10:56 AM, Richard Biener wrote:
>&
On 11/13/2013 01:22 PM, Jakub Jelinek wrote:
> On Wed, Nov 13, 2013 at 02:01:52PM +0100, Richard Biener wrote:
Really? Wouldn't it make more sense for people to check out what they
need? Is this a mayor issue?
>>>
>>> It was one of the major complaints we received when dropping the
>>>
On 11/13/2013 03:48 PM, Paulo Matos wrote:
> I cannot understand GCC's reasoning that the second loop is not
> simple. The only source code difference is that unsigned int b is
> extern. However, it will always be higher than 'a' (unsigned int)
> and the loop can't possibly be infinite.
>
> Does
On 11/22/2013 04:43 PM, BELBACHIR Selim wrote:
>
> So, to build libgcc I would need --without-header to compensate for my small
> libc, and to build libstdc++ I would have to use --with-header in order to
> provide stdio.h ...
>
>
> Do you know a better way to solve that than building gcc, li
On 11/22/2013 04:54 PM, BELBACHIR Selim wrote:
>>>
>>> So, to build libgcc I would need --without-header to compensate for my
>>> small libc, and to build libstdc++ I would have to use --with-header in
>>> order to provide stdio.h ...
>>>
>>>
>>> Do you know a better way to solve that than buildi
On 12/06/2013 10:41 AM, Umesh Kalappa wrote:
> I’m bit confused or i'm missing something here .
The first of these is implementation-defined behaviour, and the second
is (potentially) undefined behaviour.
This is more of a generic C question than a GCC question.
Andrew.
On 01/07/2014 02:48 PM, Joseph S. Myers wrote:
> On Tue, 7 Jan 2014, Joseph S. Myers wrote:
>
>> The IEEE 754 operations are corrected rounded. However, the C bindings
>
> (Except that the IEEE 754 reduction operations - subclause 9.4 - return
> "an implementation-defined approximation". But
On 01/29/2014 09:36 AM, Umesh Kalappa wrote:
> I was in impression using option -g in the commandline by defualt
> ,will emit the dwarf debugging symbols and the info ,But i was wrong
> here.
It usually does.
Andrew.
On 02/04/2014 11:03 PM, Jeffrey Walton wrote:
> That's basically what others have told me without the reference to
> ix86_md_asm_clobber.
>
> Perhaps that would be a good topic to add to
> http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html.
This is a heads up: dw (with a little help from me) is
Say you have a pointer:
int *p;
and an inline asm that writes to a block of memory
__asm__("\t0:\n"
"\tstr wzr, [%2, #4]!\n"
"\tsub %1, %1, #1\n"
"\tcbnz %1, 0b\n"
: "=m"(*p), "+r"(len) : "r"(p));
I presume this is wrong because *p only refers to p[0].
On 02/26/2014 10:51 AM, Richard Biener wrote:
> But yes, technically you write p[0] here but as "m" merely builds
> an address to the memory I'd say that we have to treat any "m"
> operand as possibly reading from / writing to / clobbering the
> whole object that can be refered to using that addres
On 02/26/2014 12:24 PM, Richard Biener wrote:
> An additional question that immediately pops up here is that
> of TBAA - may we use the alias-set of the memory reference
> to disambiguate other loads/stores against the asm?
I would certainly hope so: I don't think the rule here should be any
diffe
On 02/26/2014 04:43 PM, Segher Boessenkool wrote:
> "+r"(p) as well, you're modifying %2.
Yes, yes, OK. :-)
Andrew.
701 - 800 of 1072 matches
Mail list logo
