Ollie Wild writes:
> So ... is there a valid reason for this, or is this just an accident
> of history? AFICT, this behavior dates back to 2007 as of r120429
> (http://gcc.gnu.org/viewcvs/trunk/libgcc/static-object.mk?view=markup&pathrev=120429).
No, that's not right. That change just moves th
Eric Botcazou writes:
>> So ... is there a valid reason for this, or is this just an accident
>> of history? AFICT, this behavior dates back to 2007 as of r120429
>> (http://gcc.gnu.org/viewcvs/trunk/libgcc/static-object.mk?view=markup&pathr
>>ev=120429).
>
> At least on some platforms, you cann
Eric Botcazou writes:
>> True, but not, as far as I can see, an explanation for why the symbols
>> are hidden. Hiding the symbols doesn't fix the problem of having
>> multiple libgcc_eh on those platforms.
>
> Yes, it does, as it prevents libgcc_eh from being linked in shared libraries,
> thus
ludovic.cour...@inria.fr (Ludovic Courtès) writes:
> However, this means that plug-ins must now be built with g++, except
> when GCC was configured with --disable-build-poststage1-with-cxx. This
> seems difficult to deal with, for plug-in writers.
This is an unfortunate truth during our transiti
ludovic.cour...@inria.fr (Ludovic Courtès) writes:
> Ian Lance Taylor skribis:
>
>> ludovic.cour...@inria.fr (Ludovic Courtès) writes:
>>
>>> However, this means that plug-ins must now be built with g++, except
>>> when GCC was configured with --disable-build-
ludovic.cour...@inria.fr (Ludovic Courtès) writes:
> Ian Lance Taylor skribis:
>
>> ludovic.cour...@inria.fr (Ludovic Courtès) writes:
>>
>>> Ian Lance Taylor skribis:
>>>
>>>> ludovic.cour...@inria.fr (Ludovic Courtès) writes:
>>>>
&g
Dennis Clarke writes:
> Q: is there a way to prevent a test timing out ?
>
> I see a lot of this sort of thing :
>
> Running /opt/bw/src/gcc-4.5.3/gcc/testsuite/gcc.c-torture/compile/compile.exp
> ...
> WARNING: program timed out.
> FAIL: gcc.c-torture/compile/pr46534.c -O0 (test for excess er
Andreas Schwab writes:
> When regrename runs it turns it into this:
>
> (insn 6 27 7 2 (parallel [
> (set (reg:SI 1 %d1 [35])
> (truncate:SI (lshiftrt:DI (mult:DI (sign_extend:DI (reg:SI 1
> %d1 [36]))
> (const_int -2004318071 [0x8889])
Andreas Schwab writes:
> Ian Lance Taylor writes:
>
>> But it also looks like the pattern should use a match_scratch.
>
> It is also used as input in operand 2.
Sorry, I missed that.
This still seems like a bug in regrename to me, but it also seems like
an unusual c
DJ Delorie writes:
> configure has various ways of specifying the target headers for a
> cross-compiler. However, none of these work when you're
> cross-building a native (build!=host==target). Unfortunately,
> configure looks in $target_header_dir for target headers to determine
> various bits
DJ Delorie writes:
>> My first try would be --with-build-sysroot. Does that fail in some way?
>
> It's ignored without --with-sysroot, but if you use --with-sysroot,
> the cross-built native *also* expects to use a sysroot, which means
> binutils must also be built with a sysroot, even if its "/
DJ Delorie writes:
>> OK, but what's wrong --with-sysroot=/ ?
>
> It should work, it just seems "wrong" for a native compiler to have a
> sysroot...
I agree that it's a bug, but I'm not sure I think it's the same bug that
you think it is. Every toolchain has a sysroot, really. I think it's a
Kenneth Zadeck writes:
> I have figured out what the root cause of pr52543, but i need some
> advise as to how to fix it.
> The bug only happens if the source or destination of the move is a
> hard register. lower-subreg never breaks up pseudo to pseudo moves
> that are larger than word mode.
"Paulo J. Matos" writes:
> I have builtin __function_size(foobar) that is applied to functions.
> This should be folded to a symbol foobar@size.
>
> The problem comes when I mark in the fold_builtin function in my backend
> that DECL_PRESERVE(foobar) = 1;
>
> The reason I need to do this is so t
Subrata Biswas writes:
> I want to design a new IPC(Inter Process Communication) for
> Linux(Which can be extended for windows and mac also) as a project in
> Google Summer of Code.
This seems like an interesting project but it doesn't seem to be a
compiler project. It seems like a library. I
Tomasz Borowik writes:
> The most beneficial task (for me) would be to just bring the front-end
> I've already written up to mainline quality (though not necessarily
> inclusion), and in the process update some of the documentation or
> maybe even cleanup some gcc code.
I have nothing against ne
Kenneth Zadeck writes:
> I think that the question is really bigger than finding the correct
> line to fix. The problem is, that this code assumes that machines do
> not have multiword moves or multiword shifts. My machine has both,
> and i assume that the avr and the neon have at least multi
Kenneth Zadeck writes:
> i actually care about all registers, not just the hard ones.as it
> turns out i had been wrong and lower-subregs splits pseudo to pseudo
> moves, and hard reg to and from psuedo moves.
>
> register_move_cost requires the regclasses.
>
> anyway that is not the right th
Rainer Orth writes:
> That's a Linux-only option, unfortunately. I asked the Solaris
> engineers about implementing split-stack support, but they rejected it
> for the complexity.
Wimps. The split-stack support is simpler than than TLS support.
Not that I really think gcc should use split-sta
James Murray writes:
> However, the generated code isn't as good as the output from 3.3.6. I
> swapped back to unpatched 3.4.4 and compared with unpatched 3.3.6.
I can understand why you are doing this. However, you should be aware
that the compiler internals changed significantly in version 4.
"Paulo J. Matos" writes:
> I am porting my backend to GCC47 and during libgcc configuration I get:
> configure:4511: checking whether to use setjmp/longjmp exceptions
> configure:: /home/pm18/p4ws/pm18_binutils/bc/main/result/linux/
> intermediate/FirmwareGcc47Package/./gcc/xgcc -B/home/pm18/p4ws
Stefano Lattarini writes:
>> (I think avoiding info documentation being built in the source directory,
>> so that builds could use a non-writable source directory, may have been
>> one part).
>>
> There is probably some hack to obtain this effect (it's tested in the
> testsuite
> somewhere), but
David Stone writes:
> I would like to get a form to assign all future contributions to the FSF.
Sent off-list.
Ian
"Paulo J. Matos" writes:
> I am porting my backend to GCC47 and have been jumping through some
> hurdles. libgcc is trying to compile unwind*.c files which I can't
> remember being there for GCC46.
They were there. In 4.6 they were in the gcc subdirectory. For 4.7
they moved to the libgcc di
"Paulo J. Matos" writes:
> Is there anything documenting porting backend between GCC major versions
> (GCC4.6 - GCC4.7), in order to avoid these questions?
Basically, everything related to library code should move from
gcc/config/CPU to libgcc/config/CPU. I don't know of any specific
documenta
David Malcolm writes:
> I had a go at writing a possible plugin API for GCC, and porting parts
> of my python plugin to it:
> http://git.fedorahosted.org/git/?p=gcc-python-plugin.git;a=commitdiff;h=36a0d6a45473c39db550915f8419a794f2f5653e
Seems like a good start.
> I initially attempted an unde
Romain Geissler writes:
> Using structs with some sets of function pointers may break compatibility
> between minor release.
Yes, but fortunately we have a good understanding of how not to do that.
We could also go the even safer route used for linker plugins, in which
the plugin is invoked wit
ludovic.cour...@inria.fr (Ludovic Courtès) writes:
> What about sticking to the current “API” instead, and explicitly marking
> as internal those parts that core developers know are still in flux?
>
> For instance, I would expect a large subset of and
> to be stable (it’s been the case in my exp
"张翀(Zhang Chong)" writes:
> Hi, gcc-help,
Please never send e-mail to both gcc-h...@gcc.gnu.org and
gcc@gcc.gnu.org. Please send any followups only to gcc-help. Thanks.
> Can anyone tell me that how to generate only 64bit relocations binary
> with gcc 3.3? Thanks for the help
I don't unders
stuart writes:
> I am not sure this is the right place to ask this
It's not. The right place is gcc-h...@gcc.gnu.org. Please take any
followups there. Thanks.
> I can not seem to get gcc 4.7.0 to compile; it will not complete the
> configuration stage complaining about missing packages (GMP
Stefano Lattarini writes:
>> Anyway the real use in the src tree is different, IIUC.
>> Info files are built in the build tree by developers, but put in the
>> source tree for distribution.
>>
> In such a setup, what is the issue with having the '.info' files built
> in the srcdir? It's not like
"Paulo J. Matos" writes:
> On 30/03/12 05:11, Ian Lance Taylor wrote:
>
>> There really shouldn't be anything in the exception support that uses
>> SImode. That would be a bug. And I don't see anything that uses
>> SImode. What are you loo
Paweł Sikora writes:
> On Tuesday 03 of April 2012 13:37:50 Diego Novillo wrote:
>>
>> Concurrently with this, Lawrence and Ian are working on the C++ coding
>> guidelines. The draft is stored at http://gcc.gnu.org/wiki/CppConventions.
>
> what about using http://astyle.sourceforge.net/astyle.
Stefano Lattarini writes:
> But since I'm not yet ready to publish this new feature, I intend to make
> it available only though the new, undocumented option named (literally)
> "hack!info-in-builddir". I hope this is acceptable to you.
Sure, works for me.
Thanks.
Ian
David Edelsohn writes:
> Do you expect GCC to be able to bootstrap starting from a vendor C++
> compiler or will this require G++?
In principle it should be possible to start from a vendor C++ compiler.
Of course we will have to test in order to see.
> What is the earliest release of G++ that w
Tristan Gingold writes:
> On Apr 3, 2012, at 7:37 PM, Diego Novillo wrote:
>
>>
>> We would like to start the process to make GCC 4.8 build in C++ mode by
>> default.
>>
>> The mechanics of the change are simple enough. I volunteer to test changing
>> the default on all primary targets (assu
Andrew Haley writes:
> On 04/04/2012 10:44 AM, Gabriel Dos Reis wrote:
>> For GCC-4.8, I would like to turn on -Wall by default.
>> Comments?
>
> Umm, should this really happen at exactly the same time as C++
> by default?
I assume that Gaby is talking about making -Wall the default for users
of
Andrew Haley writes:
> On 04/04/2012 03:56 PM, Ian Lance Taylor wrote:
>> Andrew Haley writes:
>>
>>> On 04/04/2012 10:44 AM, Gabriel Dos Reis wrote:
>>>> For GCC-4.8, I would like to turn on -Wall by default.
>>>> Comments?
>>>
>>
Handong Ye writes:
> Hi, I'm new in gcc, and maybe misunderstand the constraint modifier '+'.
> As the internal document says, '+' means an inout parameter. In my
> mind, it means the instruction both reads and writes the pseudo
> register.
>
> Assuming I have a pattern like:
>
> (define_insn "ls
"sa...@hederstierna.com" writes:
> GCC does warn if returning a pointer to a local variable (stack memory).
> But there are alot of more cases where GCC could possibly warn,
> eg. when references are made to local variables or stack memory.
>
> See this attached example code.
> GCC warns for firs
Andrew Haley writes:
> On 04/05/2012 01:28 PM, Michael Veksler wrote:
>
>> As for specific warnings, I hate that the the code (a&&b || c&&d),
>> which did not cause a warning on older gcc version now gives a
>> warning. I would not want it on by default since it forces users to
>> write too many
Andrew Pinski writes:
> The main reason why LLVM is the default compiler in XCode is license
> rather any technical reason.
Yes.
> And GCC usually has better diagnostic than clang except in those few
> areas which it does not (those some might say those areas are the most
> important ones).
No
Jonathan Wakely writes:
> I get my views on their relative merits from actually using GCC and
> clang, not from out of date webpages.
Me too, and I think clang's are better.
Simply having caret diagnostics and good suggestions are quite important
for people who are not C++ experts.
Ian
"Mark Galeck (CW)" writes:
> GCC has this internal include file "included/syslimits.h". This file, uses
> a non-standard C include directive "include_next" to recursively include
> "limits.h" from a second location.
>
> I need to change this syslimits.h for our internal use, since I cannot
Lawrence Crowl writes:
> On 4/12/12, Manuel López-Ibáñez wrote:
>> So given your ideal implementation, if the user-visible result
>> was exactly like the one in Clang, will you be happy with any of
>> the three things: ranges, color and fix-it hints?
>
> There are many issues with color. Does y
"H.J. Lu" writes:
> On Fri, Apr 20, 2012 at 3:10 PM, Cary Coutant wrote:
>>> We only have very few bits to in STB_XXX field.
>>
>> This is exactly why I'm not in favor of this extension. The feature
>> doesn't seem compelling enough to use up one of these precious
>> reserved values (in fact, yo
"H.J. Lu" writes:
> On Fri, Apr 20, 2012 at 3:59 PM, Ian Lance Taylor wrote:
>> "H.J. Lu" writes:
>>
>>> On Fri, Apr 20, 2012 at 3:10 PM, Cary Coutant wrote:
>>>>> We only have very few bits to in STB_XXX field.
>>>>
&
"H.J. Lu" writes:
> In our usage, the backup definition may not be at the end of
> command line since it may reference library symbols.
You could write out the backup function you need under a different name.
Then have the backup symbol at the end of the link call the new name of
the backup func
"H.J. Lu" writes:
> On Fri, Apr 20, 2012 at 5:49 PM, Ian Lance Taylor wrote:
>> "H.J. Lu" writes:
>>
>>> In our usage, the backup definition may not be at the end of
>>> command line since it may reference library symbols.
>>
Feng LI writes:
> I generate builtin function directly in the middle end and and expand
> the builtin function in the x86 backend to certain set of
> instructions.
>
> I've defined x86 builtin functions in the gcc backend like this:
>
> { OPTION_MASK_ISA_TSTAR | OPTION_MASK_ISA_64BIT,
> CODE_FOR_
"Paul Edwards" writes:
> During the GCC 2.7.2/2.8.1 timeframe I sent emails to this list (or
> some similar list) with patches. I have found evidence of the
> patches being applied:
>
> http://hg.sourceforge.jp/view/cbc/GCC/file/ec4cbc2ac877/gcc/FSFChangeLog
>
> 527 Sun Oct 4 08:37:36 1998 Paul
Feng LI writes:
> Yes, you are right. But how could I reference to a backend defined builtin
> function in the middle end (I need to generate the builtin function in the
> middle end and expand it in x86 backend)?
If the function doesn't have a machine-independent definition, then use
a target h
Feng LI writes:
> Hi Ian,
>
> 2012/4/22 Ian Lance Taylor :
>> Feng LI writes:
>>
>>> Yes, you are right. But how could I reference to a backend defined builtin
>>> function in the middle end (I need to generate the builtin function in the
>>> mi
"Peter A. Felvegi" writes:
> Should I file a bug report?
Yes, please. Thanks.
Ian
Feng LI writes:
> Yes, you are right. But how could I reference to a backend defined builtin
> function in the middle end (I need to generate the builtin function in the
> middle end and expand it in x86 backend)?
If the function doesn't have a machine-independent definition
"Paul Edwards" writes:
> It seems to me that in addition to doing a strcmp to cc1, I would
> also have needed to do a strcmp to cccp. Can someone confirm
> that GCC 2.8.1 and GCC 3.4.6 differ in that respect - ie there
> was an extra executable (cccp) in GCC 2.8.1 when doing that
> task of conver
Dennis Clarke writes:
> Has anyone seen better results from the testsuite for GO ?
Yes. I test Go more than daily on x86_64-unknown-linux-gnu, and I see
no failures at all.
> FAIL: go.go-torture/execute/go-1.go execution, -O0
To see why these tests are failing, look in gcc/testsuite/go/go.l
Richard Sandiford writes:
> nick clifton writes:
>> Hi Richard,
>>
I have just noticed that the new -fsched-pressure-algorithm= gcc
command line option is not documented in gcc/doc/invoke.texi. Was
this an oversight ?
>>>
>>> No, it was deliberate. It's not supposed to
Richard Sandiford writes:
> Well, given the replies from you, Ian and Vlad (when reviewing the patch),
> I feel once again in a minority of one here :-) but... I just don't
> think we should be advertising this sort of stuff to users. Not because
> I'm trying to be cliquey, but because any time
Ben Morgan writes:
> In a course at my university (Universität Würzburg, Germany) we have
> created a 32-bit RISC CPU architecture -- the HaDesXI-CPU -- (in VHDL)
> which we then play onto a FPGA (the Xilinx Spartan-3AN) to use. So far
> if we want to do anything with it, we have to write the ass
Aurelien Buhrig writes:
> I have an issue (gcc 4.6.3, private bacakend) when reloading operands of
> this insn:
> (set (subreg:SI (reg:QI 21 [ iftmp.1 ]) 0)
> (lshiftrt:SI (reg/v:SI 24 [ w ]) (const_int 31 [0x1f]))
>
> The register 21 is reloaded into
> (reg:QI 0 r0 [orig:21 iftmp.1 ] [21]),
"Paulo J. Matos" writes:
> Expand generates:
>
> (define_insn_and_split "movmem_long"
> [(set (match_operand:QI 2 "register_operand" "d,c") (const_int 0))
>(set (mem:BLK (match_operand:QI 0 "register_operand" "d,c"))
> (mem:BLK (match_operand:QI 1 "register_operand" "x,c")))
>(s
BELBACHIR Selim writes:
> I'm working on an architecture where the calling convention depends on the
> type of the parameter (i.e. pointers are passed into $C regs and non-pointers
> are passed into $R regs). I've implemented this difference by using the
> POINTER_TYPE_P() macro on the 'type'
writes:
> I thought that the "operand" in a mem:BLK is the pointer to the block,
> not the block itself. So if the instruction(s) generated don't touch
> the pointer -- a likely answer for a block-move instruction -- then
> the operand would be read-only. Is that the right interpretation?
Yes.
writes:
> On May 4, 2012, at 11:39 AM, Ian Lance Taylor wrote:
>
>> writes:
>>
>>> I thought that the "operand" in a mem:BLK is the pointer to the block,
>>> not the block itself. So if the instruction(s) generated don't touch
>>>
writes:
> What I was trying to describe is the handling of a memcpy operation in the
> .md file, where the operands are the memory pointers and (in my case) I want
> to tell the machinery that the registers it's using to pass in the addresses
> no longer have those addresses in them on complet
"Paulo J. Matos" writes:
> On 04/05/12 19:48, Ian Lance Taylor wrote:
>
>> The i386 rep_movqi insn is an example:
>>
>> (define_insn "*rep_movqi"
>>[(set (match_operand:P 2 "register_operand" "=c") (const_int 0))
>&
Jan Hubicka writes:
>> "Paulo J. Matos" writes:
>>
>> > On 04/05/12 19:48, Ian Lance Taylor wrote:
>> >
>> >> The i386 rep_movqi insn is an example:
>> >>
>> >> (define_insn "*rep_movqi"
>> >>
Jan Hubicka writes:
>>
>> I can accept the issue as a matter of documentation, but I don't
>> understand the rest. Remember that all the patterns are executed in
>> parallel. I don't see how adding a USE in parallel could affect
>> anything about how the operand is used.
>
>> >> >> (define_ins
Jan Hubicka writes:
>> Jan Hubicka writes:
>>
>> >>
>> >> I can accept the issue as a matter of documentation, but I don't
>> >> understand the rest. Remember that all the patterns are executed in
>> >> parallel. I don't see how adding a USE in parallel could affect
>> >> anything about how
Daniel Marschall writes:
> As I was optimizing my program, I found a few things which looked odd
> to me in the assembler code.
Thanks. It's often best to report missed optimizations at
http://gcc.gnu.org/bugzilla/ . They will tend to be forgotten on the
mailing list.
> I am on an AMD x64_32
Daniel Marschall writes:
> I did understand that the compiler used "signed" multiplication
> instead of an unsigned one because char*char needs to be extended.
>
> Maybe I am wrong, but couldn't the compiler "know" that the result
> will be at least unsigned because unsigned * unsigned = unsigned
Kenneth Zadeck writes:
> Should i change the section 16.9 doc to indicate that this pattern is
> only to be used if the machine can do this with a single rounding?
Sure.
Ian
"William J. Schmidt" writes:
> I'm investigating another build failure for Fedora 17 (based on 4.7).
> The failing compile from the build log is as follows:
>
> /bin/sh ./libtool --tag=CC
> --mode=compile
> /builddir/build/BUILD/gcc-4.7.0-20120504/obj-ppc64-redhat-linux/./gcc/xgcc
> -B/builddi
Ralf Corsepius writes:
> I am not sure, but AFAICT, -pthread is Linux-specific.
It's not properly documented, but -pthread works on a number of hosts,
including Solaris, Darwin, FreeBSD, NetBSD, OpenBSD, AIX.
Ian
"Peter A. Felvegi" writes:
> All versions I've tried (4.4, 4.5, 4.6, 4.7) compiles the code. clang
> gives proper diagnostic stating that Base::foo is private.
>
> If base::foo is not static, gcc catches the error, too:
> gccacbug.cpp: In member function ‘int DerivT::Foo() [with T = void]’:
> gcc
Joel Sherrill writes:
> On 05/18/2012 08:27 AM, Ian Lance Taylor wrote:
>> Ralf Corsepius writes:
>>
>>> I am not sure, but AFAICT, -pthread is Linux-specific.
>> It's not properly documented, but -pthread works on a number of hosts,
>> including Solar
Joel Sherrill writes:
> On 05/18/2012 09:05 AM, Ian Lance Taylor wrote:
>> Joel Sherrill writes:
>>
>>> On 05/18/2012 08:27 AM, Ian Lance Taylor wrote:
>>>> Ralf Corsepius writes:
>>>>
>>>>> I am not sure, but AFAICT, -pthread is
Joel Sherrill writes:
> I agree with you on this one. Would it be a good general
> rule that on a system with pthreads, -pthread should be
> accepted by gcc?
Yes, I think so.
Ian
Diego Novillo writes:
> I've converted vec.[hc] to C++ and this meant some subtle changes to
> how VEC(T,stack) works. We no longer need all those macro expansions.
But it took me hours to write those macros
> This means that the allocation function for vectors can detect when a
> stack v
Jonathan Wakely writes:
> On 19 May 2012 12:36, Gabriel Dos Reis wrote:
>> On Fri, May 18, 2012 at 10:53 PM, Jay K wrote:
>>>
>>> /src/gcc-4.7.0/configure -disable-bootstrap -enable-languages=go
>>>
>>>
>>> book2:gccgo-4.7 jay$ g++ -v
>>> Using built-in specs.
>>> Target: i686-apple-darwin9
>>>
Jay K writes:
> gcc-4.6.2/gcc/Makefile.in:
>
>
> tree-nomudflap.o : $(CONFIG_H) $(SYSTEM_H) $(TREE_H) $(TREE_INLINE_H) \
> $(C_TREE_H) $(C_COMMON_H) $(GIMPLE_H) $(DIAGNOSTIC_H) $(HASHTAB_H) \
> output.h langhooks.h tree-mudflap.h $(TM_H) coretypes.h \
> $(GGC_H) gt-tree-mudflap.h $(TREE_
Gabriel Dos Reis writes:
> On Sun, May 20, 2012 at 10:30 PM, Ian Lance Taylor wrote:
>
>> To be clear, as far as I can see the Go frontend isn't doing anything
>> wrong or dubious. It just happens to #include when
>> it is available but is not. It looks l
Gabriel Dos Reis writes:
> On Mon, May 21, 2012 at 12:08 AM, Ian Lance Taylor wrote:
>> Gabriel Dos Reis writes:
>>
>>> On Sun, May 20, 2012 at 10:30 PM, Ian Lance Taylor wrote:
>>>
>>>> To be clear, as far as I can see the Go frontend isn
Jay K writes:
>> --enable-stage1-languages=go. (Mail to the OP is bouncing for me, by
>> the way.)
>
> I don't know why.
> I'm getting them, at least via the list.
For every e-mail I send to jay.kr...@cornell.edu, I'm getting a bounce
from cashub03.exchange.cornell.edu saying
- The follow
Jay K writes:
> I know gccgo is actuall C++.But why was no-rtti specified? Maybe that
> is for the other code, the C code? Thank you, sorry, I'm in a rush
> right now, - Jay
I thought I answered that earlier. When building C++ code that is part
of GCC itself, we use -fno-rtti because GCC never
Jay K writes:
> I know gccgo is actually C++.
> But why was no-rtti specified? Maybe that is for the other code, the C code?
Answered previously.
> But I see:
>
> > and using -fno-rtti saves some space in the generated compiler.
>
>
>
> Is it worth it?
Sure, why not? We make similar chang
"Iyer, Balaji V" writes:
> Is there a #define in GCC that will turn on only for certain languages?
> I am trying to use build_array_ref but it is giving me a undefined reference
> for f951. This code that I am trying to use will ONLY execute if we have a
> C/C++ code. Is it possible fo
Rohit Arul Raj writes:
> Looking at the debug info and the generated assembly, the values of
> variables 'f1' and 'd1' are stored in the same register.
> Due to this, while debugging, after setting the break point at (A)
> [line no 8], if we print the value of 'f1' i get the wrong value.
> Q: I
Jay K writes:
> At the bottom of mkconfig.sh in 4.6.2 and 4.7.0:
>
>
> # Avoid changing the actual file if possible.
> if [ -f $output ] && cmp ${output}T $output >/dev/null 2>&1; then
> echo $output is unchanged >&2
> rm -f ${output}T
> else
> mv -f ${output}T $output
> fi
>
> # Touc
Georg-Johann Lay writes:
> The avr backend auto-generates a part of the texi documentation by
> means of a small C program. The relevant part of t-avr reads:
>
> s-avr-mmcu-texi: gen-avr-mmcu-texi$(build_exeext)
> $(RUN_GEN) $< | sed -e 's:\r::g' > avr-mmcu.texi
>
>
> There was a problem re
Thomas Koenig writes:
> I just got a bootstrap error on trunk, with configuration
>
> ../trunk/configure --prefix=$HOME --enable-languages=c,fortran
> --disable-build-poststage1-with-cxx
>
> The error was:
>
> ../../trunk/gcc/fortran/decl.c: In function 'match_attr_spec':
> ../../trunk/gcc/fortra
Steven Bosscher writes:
> In gcse.c:insert_insn_end_basic_block() I found the following code:
>
> #ifdef HAVE_cc0
> /* FIXME: 'twould be nice to call prev_cc0_setter here but it aborts
> if cc0 isn't set. */
> note = find_reg_note (insn, REG_CC_SETTER, NULL_RTX);
> if
TK Banks writes:
> I'm also not sure I'm directing this issue to the correct mailing list.
> If not, perhaps someone would be so kind as to point me to the right
> mailing list or forum.
In fact, gcc@gcc.gnu.org is the wrong mailing list. The right mailing
list would be gcc-h...@gcc.gnu.org. P
TK Banks writes:
> Would it be poor-form to submit a bug without first testing on the latest
> version of the compiler? (I'm just running whatever version Ubuntu doles out
> via the management system: 4.3.4)
It's OK to do that, just make clear that version of the compiler you
tested.
Ian
Brett Foster writes:
> 1) How to marking a node as visited by my algorithm (without screwing
> up the compiler!)
Use a pointer_set.
> 2) How to associate additional data (perhaps a pointer to something
> else) to a node (like a unique identifier, or a pointer to a data
> structure).
Use a poin
Steven Bosscher writes:
> I am confused by the following code in
> ifcvt.c:noce_mem_write_may_trap_or_fault_p():
>
> static bool
> noce_mem_write_may_trap_or_fault_p (const_rtx mem)
> {
> rtx addr;
>
> if (MEM_READONLY_P (mem))
> return true;
> (...)
>
> addr = XEXP (mem, 0);
>
> /* C
Satya Prakash Prasad writes:
> But the compilation process fails further on:
>
> gcc/gcc-4.1.2/host-x86_64-unknown-linux-gnu/gcc/xgcc
> -Bgcc/gcc-4.1.2/host-x86_64-unknown-linux-gnu/gcc/
> -B/usr/local/x86_64-unknown-linux-gnu/bin/
> -B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem
> /usr/loca
Vincent Torri writes:
> I would like to know if there is a way to know if a warning option
> like -Wno-initializer-overrides is supported or not by gcc. My purpose
> is to write an m4 macro that checks if an option is supported or not
> by a compiler.
This question is not appropriate for the mai
"Rick C. Hodgin" writes:
> How hard would it be to implement a "self" keyword extension which
> references the contextual function name wherein it was referenced?
>
> int foo(int a)
> {
> // recursion
> self(a + 1);
> }
>
> int food(int a)
> {
> // recursion
> self(a + 1);
> }
>
>
2401 - 2500 of 3176 matches
Mail list logo
