"Kaveh R. GHAZI" <[EMAIL PROTECTED]> writes:
> 2008-07-04 Kaveh R. Ghazi <[EMAIL PROTECTED]>
>
> * ggc-zone.c (lookup_page_table_if_allocated,
> set_page_table_entry, zone_find_object_size, alloc_small_page,
> alloc_large_page, ggc_free, gt_ggc_m_S, ggc_marked_p, init_ggc,
>
"Cary Coutant" <[EMAIL PROTECTED]> writes:
>> We've started working on the driver and WPA components for whopr.
>> These are some of our initial thoughts and implementation strategy. I
>> have linked these to the WHOPR page as well. I'm hoping we can
>> discuss these at the Summit BoF, so I'm po
"Cary Coutant" <[EMAIL PROTECTED]> writes:
>> * GOLD_VERSION should perhaps say something about the format of the
>> string.
>
> OK. What would be reasonable to say here? Just a string of the form
> "n.m"? Is it reasonable to require that later versions are lexically
> greater than earlier versio
"Kaveh R. GHAZI" <[EMAIL PROTECTED]> writes:
> 2008-07-07 Kaveh R. Ghazi <[EMAIL PROTECTED]>
>
> * gcc.c (execute): Fix -Wc++-compat warning.
This is OK.
Thanks.
Ian
Angelo Graziosi <[EMAIL PROTECTED]> writes:
> Could this be valid?
It's valid, but it's not the right patch. The right patch is to use
XNEW and XCNEW from include/libiberty.h.
Ian
Angelo Graziosi <[EMAIL PROTECTED]> writes:
> Ian Lance Taylor wrote:
>> It's valid, but it's not the right patch. The right patch is to use
>> XNEW and XCNEW from include/libiberty.h.
>>
>
> Gabriel Dos Reis in [1] wrote:
>> The idiom is to use
Angelo Graziosi <[EMAIL PROTECTED]> writes:
> --- gcc-4.4-20080704.orig/gcc/ggc-page.c 2008-06-29 06:39:16.0 +0200
> +++ gcc-4.4-20080704/gcc/ggc-page.c 2008-07-05 12:00:20.90625 +0200
> @@ -799,7 +799,7 @@
> alloc_size = GGC_QUIRE_SIZE * G.pagesize;
>else
> alloc_s
[EMAIL PROTECTED] writes:
> I've read that allocating objects on the stack is faster than on the
> heap. What about deletion? Is deleting an object from the heap a lot
> less efficient? Are the performance differences so negligible that they
> won't matter?
>
> Are there any papers or articles
NightStrike <[EMAIL PROTECTED]> writes:
> I was under the impression that these would be cleaned up before the
> -W options were applied to the trunk.
It's pretty hard to clean up all the warnings for every possible
target. Also these are only warnings--this code is not compiled with
-Werror.
I
NightStrike <[EMAIL PROTECTED]> writes:
> On 7/8/08, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
>> NightStrike <[EMAIL PROTECTED]> writes:
>>
>> > I was under the impression that these would be cleaned up before the
>> > -W options were appli
NightStrike <[EMAIL PROTECTED]> writes:
> On 7/8/08, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
>> NightStrike <[EMAIL PROTECTED]> writes:
>>
>> > I was under the impression that these would be cleaned up before the
>> > -W options were appli
"Peng Yu" <[EMAIL PROTECTED]> writes:
> There is an options -ansi to make g++ ANSI compatible. I'm wondering
> if there is an option to make g++ POSIX compatible. Or g++ is already
> POSIX compatible without an option?
POSIX itself specifies features macros which you may define to compile
your so
"Peng Yu" <[EMAIL PROTECTED]> writes:
I should have said in reply to your last message: this is the wrong
mailing list for this question. Please take any followups to
[EMAIL PROTECTED] Thanks.
> Isn't ANSI C++ a subset of POSIX C++. Why do I need to specify
> _POSIX_SOURCE, _POSIX_C_SOURCE and
"Mohamed Shafi" <[EMAIL PROTECTED]> writes:
> I am involved in the porting of gcc 4.1.2 for 16 bit target. For this
> target size of long long is 32bits. For the following code
>
> #define VALUE 0x1B4E81B4E81B4DLL
That is not a 32-bit value.
> #define AFTER 0x55
>
> //void test (int n, long lon
"Bingfeng Mei" <[EMAIL PROTECTED]> writes:
> I tried to use doloop_end pattern to reduce loop overhead for our target
> processor, which features a dedicated loop instruction. Somehow even a
> simple loop just cannot pass the test of doloop_condition_get, which
> requires following canonical patt
"Mohamed Shafi" <[EMAIL PROTECTED]> writes:
>> The value is too big for a long long. When you specify the type, gcc
>> is forced to convert (I hope you can get a warning for that). When
>> you don't specify the type, gcc does not convert. The resulting value
>> has a type which can only be expr
"Mohamed Shafi" <[EMAIL PROTECTED]> writes:
> I am involved in porting gcc 4.1.2.
> For some processing i need to know whether a register is being defined
> and used in a particular instruction. Till now i have been using
> 'refers_to_regno_p()' to know whether a register is being used in a
> inst
"Kaveh R. Ghazi" <[EMAIL PROTECTED]> writes:
> Jeez, I didn't realize people felt so viscerally against this. I thought
> the impact on users would be small. I.e. I'm curious who actually
> subscribes to the gcc-cvs list. Is it a large list? (I don't know.)
There are 105 subscribers to the gc
"Dennis Clarke" <[EMAIL PROTECTED]> writes:
> hold on .. on the NEWS page I see ... okay .. how very user friendly.
> Sort of the thing one would put on the project homepage I would think.
The glibc project has their own special approach to user friendliness.
Ian
Alexandre Oliva <[EMAIL PROTECTED]> writes:
> Here's my first cut at trying to tell how well or how bad we perform
> in terms of debug info, that can be dropped into the GCC run-time test
> infrastructure and used by means of #include in new tests that add
> GUALCHK* annotations (or with separate
"Bo Yang" <[EMAIL PROTECTED]> writes:
> Could anybody give some advice on this? Thanks!
The mailing list gcc@gcc.gnu.org is for gcc developers, who mostly do
not use cygwin. Try asking on [EMAIL PROTECTED] and/or
[EMAIL PROTECTED]
Ian
Hariharan <[EMAIL PROTECTED]> writes:
> I found something rather strange with the unsigned comparison warnings
> in GCC.
This is the wrong mailing list. The mailing list gcc@gcc.gnu.org is
for gcc developers. The mailing list [EMAIL PROTECTED] is for
questions about using gcc. Please take any
"ingmar wirths" <[EMAIL PROTECTED]> writes:
> I hope you don't consider this as flaming or something, just critics
> to improve this wonderful compiler
> and make hacking easier for people like me without an expert
> understanding of C++.
Thanks for your note. Unfortunately it is too vague for u
Andreas Krebbel1 <[EMAIL PROTECTED]> writes:
> it is important for the testcase that the array is that big. In order to
> avoid breaking other targets with that I've moved the testcase to the s390
> specific directory. I've already committed the patch. Sorry for the
> breakage.
If the test will r
"Dave Korn" <[EMAIL PROTECTED]> writes:
> Ian Lance Taylor wrote on 07 August 2008 19:20:
>
>> If the test will run on most normal targets, then a better approach is
>> to add something like
>>
>> #if defined(STACK_SIZE) && STACK_SIZ
"Andreas Krebbel" <[EMAIL PROTECTED]> writes:
> I've decided not to disable the testcase completely for small stack
> sizes. Although it is unlikely that it triggers the reload problem in
> some way the testcase is weird enough to trigger something else.
>
> Ok for mainline?
OK.
Thanks.
Ian
"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes:
> Let's try to focus on what needs to be done looking for specific
> features (or fixes) and how we could do it:
Thanks for writing this up.
> A) Printing the input expression instead of re-constructing it. As
>Joseph explained, this will fix
"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes:
> 2008/8/15 Ian Lance Taylor <[EMAIL PROTECTED]>:
>> "Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes:
>>
>>> A) Printing the input expression instead of re-constructing it. As
Balthasar Biedermann <[EMAIL PROTECTED]> writes:
> #0 0x081c5d48 in mark_jump_label_1 (x=0x0, insn=0xb7b77118, in_mem=0
> '\0', is_target=0 '\0') at ../.././gcc/jump.c:987
> #1 0x081c60e0 in mark_jump_label_1 (x=0xb7b70e28, insn=0xb7b77118,
> in_mem=0 '\0', is_target=0 '\0') at ../.././gcc/jump.
Joe Buck <[EMAIL PROTECTED]> writes:
> On Wed, Aug 20, 2008 at 06:31:11AM -0700, Ian Lance Taylor wrote:
>> Writing your own gcc backend requires digging into the code and
>> figuring it out. It's not simple. We can't answer precise and
>> detailed quest
"Dasgupta, Romit" <[EMAIL PROTECTED]> writes:
> I came across the -mpcu=cortex-a8 option in the codesourcery
> gcc. When I added that to build the Linux kernel, I found that
> there are no differences in the kernel code with and without
> the options. The following are the gcc
Jeff Law <[EMAIL PROTECTED]> writes:
> Joseph S. Myers wrote:
>> The new Integrated Register Allocator is now in GCC trunk, and the
>> old allocator is scheduled for removal on or shortly after 25
>> September.
> [ ... ]
> One more note, I would strongly recommend we tag the trunk when we
> remove
"M R Swami Reddy" <[EMAIL PROTECTED]> writes:
> I am trying to build the gcc tools on cygwin host. But the build
> failed with below errors:
>
> $ gcc -I../../../trunk/libdecnumber -I. -g -O2 -W -Wall -Wwrite-strings
> -Wstr
> ict-prototypes -Wmissing-prototypes -Wold-style-definition
> -
Joe Buck <[EMAIL PROTECTED]> writes:
> But ia64-unknown-linux-gnu/libgcc/config.log doesn't have any useful
> details. It has
>
> CC='/remote/atg5/jbuck/gcc-4.3.2-ia64build/./gcc/xgcc
> -B/remote/atg5/jbuck/gcc-4.3.2-ia64build/./gcc/
> -B/u/jbuck/cvs.ia64/4.3.2/ia64-unknown-linux-gnu/bin/
> -B
Hi Doug, Jason suggested that I write to you about this. There seems
to be some confusion in the code in cp/pt.c between enum
unification_kind_t (DEDUCE_xxx) and a bitmask of UNIFY_ALLOW_xxx
values. The parameters are named "strict" for all functions, but in
some cases they are unification_kind_t
"Thomas A.M. Bernard" <[EMAIL PROTECTED]> writes:
> I guess I am missing something here. I've tried the following as Paolo
> suggested,
>
> (define_insn "setallocate"
> [(unspec_volatile:DI [(match_operand:DI 0 "general_operand" "r")]
> UNSPEC_ALLOCATE)]
> ""
> "a
"Thomas A.M. Bernard" <[EMAIL PROTECTED]> writes:
> Ian Lance Taylor wrote:
>> "Thomas A.M. Bernard" <[EMAIL PROTECTED]> writes:
>>
>>
>>> I guess I am missing something here. I've tried the following as Paolo
>>
Brendon Costa <[EMAIL PROTECTED]> writes:
> I have control over my project: foo, however i do not have control over
> project blah. The problem is with badly defined build system that do NOT
> allow a user to pass flags they want to to the compiler. This will
> likely result in having to edit the
Brian Dessent <[EMAIL PROTECTED]> writes:
> Is it really that far fetched to have the plugin not directly access
> anything from the executable's symbol table but instead be passed a
> structure that contains a defined set of interfaces and callbacks?
Yes, that is pretty far fetched. Simply writ
Basile STARYNKEVITCH <[EMAIL PROTECTED]> writes:
> I am much more worried about passes and plugins (and I am very
> surprised to be almost the only one mentioning passes in plugin
> discussions). I feel it is a major issue (not a matter of coding, much
> more a matter of convention & understanding
Chris Lattner <[EMAIL PROTECTED]> writes:
> On Sep 19, 2008, at 3:25 PM, Ian Lance Taylor wrote:
>
>> Basile STARYNKEVITCH <[EMAIL PROTECTED]> writes:
>>
>>> I am much more worried about passes and plugins (and I am very
>>> surprised to be
DJ Delorie <[EMAIL PROTECTED]> writes:
>> Does the following fix it?
>
> Nope, sorry. I was looking at this code in c-common.c, where the expr
> is first created, but I don't know what that ends up calling:
>
> /* Create the sum or difference. */
> if (resultcode == MINUS_EXPR)
> intop =
"Yuhong Bao" <[EMAIL PROTECTED]> writes:
> Off-topic, but I feel this is important, since Apple contributed to gcc, and
> it is licensed under GPLv3 now.
> In particular, this was inspired by this thread on the gcc mailing lists:
> http://gcc.gnu.org/ml/gcc/2008-02/msg00520.html
> Notice that I CC
"Yuhong Bao" <[EMAIL PROTECTED]> writes:
>> 1) This is offtopic.
> Yeah, but I want to bring this up because I can tell it is affecting GCC
> development.
>
>>From http://gcc.gnu.org/ml/gcc/2008-02/msg00523.html:
> "> If someone steps forward, are you allowed to follow the patches list
> We can't
Paolo Bonzini <[EMAIL PROTECTED]> writes:
> Ah, actually I think I now see the OP's point. Apple is scared of the
> GPLv3 because the iPhone might violate it, so they are not contributing
> to anything that falls under the GPLv3.
...
> 1) does it make sense to keep a maintainer category that is
Basile STARYNKEVITCH <[EMAIL PROTECTED]> writes:
> Is it top secret information only available to some few members of the
> Steering Committee, or is some information sharable on this list? Just
> knowing that indeed a runtime library license will be finalized before
> Christmas (ie in 2008) and t
NightStrike <[EMAIL PROTECTED]> writes:
>> There is a simple technique which anybody is free to use to make this
>> happen much faster: make a large donation to the SFLC and/or the FSF,
>> contingent on this issue being finished. In the absence of that, it
>> will happen in the time that people h
Chris Lattner <[EMAIL PROTECTED]> writes:
> On Sep 24, 2008, at 7:06 AM, Ian Lance Taylor wrote:
>> fix the problem. My understanding of Apple's current position is that
>> they won't take any action until they see the final version of the gcc
>> runtime li
Yuhong Bao <[EMAIL PROTECTED]> writes:
> BTW, one of the reason I posted this was that I wanted to privately
> talk about the politics behind this issue with someone internal to
> Apple, and forward some of that to RMS and the FSF. Can this be done
> or is the politics all under NDA?
Well, good l
Chris Lattner <[EMAIL PROTECTED]> writes:
> My personal feeling on the matter is that it seems very strange to
> talk about *compiler plugins* in the license for *runtime libraries*.
> Considering that there are already widely available alternative
> libraries (e.g. the apache stdc++ library and m
Chris Lattner <[EMAIL PROTECTED]> writes:
> On Sep 24, 2008, at 12:57 PM, Ian Lance Taylor wrote:
>
>> Chris Lattner <[EMAIL PROTECTED]> writes:
>>
>>> My personal feeling on the matter is that it seems very strange to
>>> talk about *compile
that if (num <
0), - num is > 0. My patch let VRP notice this. So the special case
is never handled.
This patch appears to fix the problem. I'm running the libjava tests
now. Does this look OK to the java maintainers for 4.2 branch and
mainline? Mark, should I commit to 4.2 br
Mark Mitchell <[EMAIL PROTECTED]> writes:
> Ian Lance Taylor wrote:
>
> > This patch appears to fix the problem. I'm running the libjava tests
> > now. Does this look OK to the java maintainers for 4.2 branch and
> > mainline? Mark, should I commit to 4.2
Tom Tromey <[EMAIL PROTECTED]> writes:
> >>>>> "Ian" == Ian Lance Taylor <[EMAIL PROTECTED]> writes:
>
> Ian> This is a bug in C++ code in libjava.
>
> Thanks. We enabled -fwrapv for the interpreter but, I think, thought
> that perhaps
Rask Ingemann Lambertsen <[EMAIL PROTECTED]> writes:
> I'm seeing miscompilation of newlib's memcmp() for my 16-bit ix86 port. The
> REG_RETVAL and REG_LIBCALL notes seem to play an important part in the
> failure. From the first subreg dump:
Try this:
Index: gcc/lower-subreg.c
=
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> Rask Ingemann Lambertsen <[EMAIL PROTECTED]> writes:
>
> > I'm seeing miscompilation of newlib's memcmp() for my 16-bit ix86 port. The
> > REG_RETVAL and REG_LIBCALL notes seem to play an important part in the
"Mohamed Shafi" <[EMAIL PROTECTED]> writes:
> gmon.out file is created in mcleanup function.This function however
> doesn't dump the data in the grof gmon.out data format. When i looked
> into the code for i386 and sparc in the backend nothing has been done
> to store the profiling info the requir
Matt Thomas <[EMAIL PROTECTED]> writes:
> In handle_aligned_attributes in c-common.c, at line 5146, it does
>
> type = &TREE_TYPE (decl);
>
> Then at 5179 it does
>
> TREE_TYPE (decl) = *type;
>
> In between, type doesn't change so that's really
>
> TREE_TYPE (decl) = * &TRE
Tehila Meyzels <[EMAIL PROTECTED]> writes:
> I'd like to get an explanation why ifcvt.c checks whether 1 of the 2
> successors of the IF-header block has a stmt that exits from the loop?
> Why does it prevent the if-conversion?
> I'm referring to the following code:
>
> /* Nor exit the loop. */
"François-Xavier Coudert" <[EMAIL PROTECTED]> writes:
> When the commit which introduced the regression is known, why not
> simply assign the bug to the committer? Surely, people do follow
> regularly the bugs that are assigned to them, don't they?
In practice, no, they don't.
> In my opinion, a
"Rohit Arul Raj" <[EMAIL PROTECTED]> writes:
> 1. Is the REG NOTE provided for the dwarf code proper?
Yes.
> 2. What is the reason for readelf error?
I don't know. Sounds like a bug somewhere.
Ian
I just noticed a problem with our use of GMP and MPFR. If you
carefully install the appropriate versions of GMP and MPFR on one
machine in the normal way, and build gcc on that machine,
cc1/cc1plus/etc. wind up dynamically linked against libgmp.so and
libmpfr.so. If you then copy the compiler to
Tim Prince <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] wrote:
> > If you
> > carefully install the appropriate versions of GMP and MPFR on one
> > machine in the normal way, and build gcc on that machine,
> > cc1/cc1plus/etc. wind up dynamically linked against libgmp.so and
> > libmpfr.so. If
"Rohit Arul Raj" <[EMAIL PROTECTED]> writes:
> I have defined a target hook TARGET_EXPAND_BUILTIN_SAVEREGS (GCC
> 4.1.1) as an alternative to TARGET_SETUP_INCOMING_VARARGS so as to
> code ___builtin_saveregs as per my target. But this target hook is not
> getting recognized.
>
> Is there anything
Yaakov Yaari <[EMAIL PROTECTED]> writes:
> LSDA (Language Specific Data Area) is used to store exception handling
> information at the exception catch site, see
> http://www.codesourcery.com/cxx-abi/exceptions.pdf.
>
> For various kinds of binary analyzers (translators, optimizers) it is
> useful
"sfora dim" <[EMAIL PROTECTED]> writes:
> I read that the eh_frame is for exceptions support,
> for languages like C++ for instance.
Yes.
> I wonder why when I compile standard C programs using "gcc -v simple.c"
> I can see that the linker adds the "--eh-frame-hdr" parameter ?
That option is al
FX Coudert <[EMAIL PROTECTED]> writes:
> Bootstrapping today's trunk (rev. 125180) on i386-mingw32 (native)
> leads me to the following error at the end of stage3:
>
> > make[3]: Leaving directory `/home/coudert/ibin/i386-pc-mingw32/
> > libiberty/testsuite'
> > make[3]: Entering directory `/home
http://gcc.gnu.org/PR32102 is about the fact that -Wall
-Wstrict-overflow is not the same as -Wstrict-overflow -Wall (i.e.,
the order of the options matter). The reason is that -Wall sets
warn_strict_overflow to 1 and -Wstrict-overflow sets
warn_strict_overflow to 2.
It is normal and expected tha
Joe Buck <[EMAIL PROTECTED]> writes:
> How about: have -Wall still set warn_strict_overflow
> to 1, but to have -Wall -Wstrict-overflow *or* -Wstrict-overflow -Wall
> *or* just -Wstrict-overflow set it to 2? The only change would be
> to prevent -Wall from *decreasing* the value.
Sure, makes sen
Sergei Organov <[EMAIL PROTECTED]> writes:
> I like the idea. I'd also suggest that group options won't do anything
> else but affecting [default values of] simple options. It means that one
> will be able to substitute a set of simple options for a "group option"
> without change in behavior (for
"Prasad, Kamal R" <[EMAIL PROTECTED]> writes:
> Can someone tell me the back-end optimizations available for itanium
> (IA64)?
> We (HP) may be able to contribute to this from our side.
GCC implements more or less the same set of optimizations for all
targets. I don't think there are any IA64 s
"Mohamed Shafi" <[EMAIL PROTECTED]> writes:
> I am working with a private target(GCC v4.1.1).
> For my target the function arguments are passed through registers.
> For this purpose 4 registers are used. If the no. of arguments are
> more than 4, the remaining arguments are passed through stack.
>
Roman Zippel <[EMAIL PROTECTED]> writes:
> While working on a vdso for Linux/m68k I stumbled again on a problem, I
> already had with the fallback unwind handler in gcc, where I'd like to
> hear some opinions.
> I'm looking at the i386 unwind handler and that doesn't bother to restore
> any fp
"Mohamed Shafi" <[EMAIL PROTECTED]> writes:
> On 01 Jun 2007 07:22:39 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> > "Mohamed Shafi" <[EMAIL PROTECTED]> writes:
> >
> > > I am working with a private target(GCC v4.1.1).
"Timothy C Prince" <[EMAIL PROTECTED]> writes:
> So, am I correct to believe that we need to use plain 'inline' for c99
> after gcc 4.4, and 'extern inline' before that? That is, I think I need to
> write a test that looks like...
>
>
> #if ((__GNUC__ > 4) || ((__GNUC__ == 4) && (__GNUC_MIN
Tim Prince <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] wrote:
> > ../../gcc/libcpp/traditional.c: In function â_cpp_scan_out_logical_lineâ:
> > ../../gcc/libcpp/traditional.c:349: error: âfmacro.argsâ may be used
> > uninitialized in this function
> > ../../gcc/libcpp/traditional.c:349: error
"Andrew Pinski" <[EMAIL PROTECTED]> writes:
> On 6/5/07, Aaron Gray <[EMAIL PROTECTED]> wrote:
> > There is something weird with the switch statement in cp/decl.c:7105.
> > I dont think it will effect the decl.c's logic, but what does it say about
> > the GCC's C parser, is this legal C ?
>
> Yes
Olivier Hainque <[EMAIL PROTECTED]> writes:
> genmodes.c uses the %n capabilities of printf to compute the width of
> pieces it outputs. This causes troubles on Windows Vista, because ...
>
><< Because of security reasons, support for the %n format specifier is
> disabled by default in
Florian Weimer <[EMAIL PROTECTED]> writes:
> The issue arrases in programs that pass attacker-controlled data as
> the format string. They use
>
> printf(some_string);
> syslog(LOG_INFO, some_string);
>
> instead of
>
> printf("%s", some_string);
> syslog(LOG_INFO, "%s", some_string);
Zdenek Dvorak <[EMAIL PROTECTED]> writes:
> The problem is, that it does not give any speedups (it is almost
> completely compile-time neutral for compilation of preprocessed
> gcc sources). I will check whether moving also edges to pools
> changes anything, but so far it does not seem very promi
Andrey Belevantsev <[EMAIL PROTECTED]> writes:
> Is this intentional, or do we want to have 'return hash;' instead of
> 'return 0;' in all places when *do_not_record_p is set to 1? Is there
> a better hash_rtx somewhere, which I don't know about?
It should be fine to "return hash" instead of "re
Matt Fago <[EMAIL PROTECTED]> writes:
> > I would say that gets is much more dangerous than %n in printf, but
> > presumably Microsoft does not disable gets
>
> Actually, for gets, and essentially the entire stdio.h, Visual Studio 2005
> generates:
>
> warning C4996: 'gets': This function
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> Zdenek Dvorak <[EMAIL PROTECTED]> writes:
>
> > The problem is, that it does not give any speedups (it is almost
> > completely compile-time neutral for compilation of preprocessed
> > gcc sources). I will chec
Rask Ingemann Lambertsen <[EMAIL PROTECTED]> writes:
>The comment for note_stores() (in rtlanal.c) says:
>
> /* Call FUN on each register or MEM that is stored into or clobbered by X.
>(X would be the pattern of an insn).
>
>But this doesn't happen when a register is modified by e.g.
"Pompapathi V Gadad" <[EMAIL PROTECTED]> writes:
> My GCC assignment/disclaimer process with the FSF is complete. It
> would be greatly appreciated, if someone can provide information about
> the following:
> a) Can the write permissions to port specific files can be obtained
> even before submitt
"Mohamed Shafi" <[EMAIL PROTECTED]> writes:
> I am working for a private GCC target.
> The target has 4 registers, each 32 bits reserved for arguments.
> When passing arguments depending on the type of the argument either
> registers or stack + registers will be used Sometimes the arguments
> wil
ase update your listings in the MAINTAINERS file.
Thanks!
Updated as follows.
Ian
2007-06-14 Ian Lance Taylor <[EMAIL PROTECTED]>
* MAINTAINERS: Add myself as non-algorithmic global write
ma
"Vladimir N. Makarov" <[EMAIL PROTECTED]> writes:
> For example, about latest appointments of Diego and Ian as GWP. They
> are good guys but I don't see Diego actively working on RTL or Ian
> actively working on tree-SSA.
Just for the record, I was already a full middle-end maintainer before
the
"Vladimir N. Makarov" <[EMAIL PROTECTED]> writes:
> Ian Lance Taylor wrote:
>
> >I've been lobbying for some time, on IRC, for more people to be able
> >to fill in the holes in the maintainership patterns. Most of the
> >existing global maintaine
Eric Botcazou <[EMAIL PROTECTED]> writes:
> > Please, just look at those charts
> >
> > https://vmakarov.108.redhat.com/nonav/spec/comparison.html
> >
> > The compilation speed decrease without a performance improving (at least
> > for the default case) is really scary.
>
> Right, I also found th
"Vladimir N. Makarov" <[EMAIL PROTECTED]> writes:
> >>>I've been lobbying for some time, on IRC, for more people to be able
> >>>to fill in the holes in the maintainership patterns. Most of the
> >>>existing global maintainers are inactive. There are areas of the code
> >>>which are not covered
"J.C. Pizarro" <[EMAIL PROTECTED]> writes:
> The optimizing stages of GCC's backend are big, fragmented and complex.
>
> I think that the GCC's commitee goes to the wrong direction.
It's an error to blame the steering committee for the ugliness of
gcc's optimization passes. The steering committ
"J.C. Pizarro" <[EMAIL PROTECTED]> writes:
> 1. Stop developing new features to GCJ
> and start to develop the more advanced IcedTea (a.k.a. OpenJDK).
>
> http://icedtea.classpath.org/wiki//Main_Page
>
>
> 2. Stop developing new features to GCC's backend
> and start to develop the more advanced
Diego Novillo <[EMAIL PROTECTED]> writes:
> On 6/20/07 9:09 AM, Bokhanko, Andrey S wrote:
>
> > Yes, but one can write something like this:
> >
> > p2 = (S1 *)&p1->s1_m2;
> >
> > Of course, this is a blatant violation of ANSI C standard, etc. Still, a
> > perfectly acceptable C code.
>
> No, i
Brooks Moses <[EMAIL PROTECTED]> writes:
> Indeed. It would be interesting to confirm whether or not a copy of
> gcc bootstrapped with a non-gcc compiler matched byte-for-byte with a
> copy of gcc bootstrapped from gcc. Not so much to look for
> intentional things like this, but to see whether t
Diego Novillo <[EMAIL PROTECTED]> writes:
> But, first, I'd like to know what folks think about this. Would it be
> generally useful for us to have the IL data structures auto-generated
> this way? I can see the benefits in the reader/writer. But also, we
> are going to have to re-implement the
Kenneth Zadeck <[EMAIL PROTECTED]> writes:
> In the lto world we will be reading in a function and then hacking on
> it. Many (most) of those hacks are not in place changes, but adding,
> deleting and rearranging instructions into the stream.
>
> Doing in place mapping puts severe restrictions
Kenneth Zadeck <[EMAIL PROTECTED]> writes:
> The issue is not the io. The current organization, with each function
> arranged in its own section is designed to so that that section can be
> memory mapped in. The question how much work is it going to be to
> transform what is mapped in into the w
dodegy <[EMAIL PROTECTED]> writes:
> I have a little question. I need to know where in the gcc source the
> functions for reading input source files are. I want to substitute this to
> use a fix string instead reading file.
Look at libcpp/files.c.
> Also the output must be written to a
> string.
Kenneth Zadeck <[EMAIL PROTECTED]> writes:
> There appears to be an idiom, (or at least a chunk of code that has been
> heavily copied) where *_output_mi_thunk sets reload_completed and
> no_new_pseudos at the top and clears them at the bottom.
>
> This appears to be the majority of the not triv
2801 - 2900 of 3176 matches
Mail list logo
