Re: Re: Optional machine prefix for programs in for -B dirs, match ing Clang

Hello, On Wed, 4 Aug 2021, John Ericson wrote: > > Doesn't GCC automatically look for those commands in the --prefix > > directory that you configure GCC with? Or is that only for native > > compilers? > > It will search only if --with-*=... was not passed, and it will never > prefix the quer

Re: x86_64 - 128 bit structs not targeted to TImode: MAX_FIXED_MODE_SIZE too small?

Hi, On Wed, 16 Feb 2005, Gary Funck wrote: > struct shared_ptr_struct > { > unsigned int phase : 24; > unsigned short thread : 16; > void *addr; > }; > > On the x86_64 (ie, Opteron[tm]) platform, GCC appears to designate the > underlying mode of this type as a BLKmode, instead o

Re: Inline virtual call puzzling behaviour

Hi, On Sun, 7 Jul 2013, Thierry Lavoie wrote: > int main(int argc, char** argv) > { > A* ptr = 0; > if(argc == 1) > ptr = new B(); > else > ptr = new A(); > > ptr->blah(); > > B().blah(); > C().blah(); > } > > The

Re: Calculating instruction costs

Hi, On Tue, 9 Jul 2013, David Given wrote: > Trying 8, 9 -> 10: > Successfully matched this instruction: > (set (reg:SI 47 [ *_5 ]) > (mem:SI (plus:SI (mult:SI (reg/v:SI 43 [ b ]) > (const_int 4 [0x4])) > (reg:SI 0 r0 [ a ])) [2 *_5+0 S4 A32])) > rejecting combinat

Re: Calculating instruction costs

Hi, On Wed, 10 Jul 2013, David Given wrote: > Michael Matz wrote: > [...] > > As you didn't adjust any cost I would guess the high value comes from the > > default implementation of address_cost, which simply uses arithmetic cost, > > and the MULT in there

Re: Should -Wmaybe-uninitialized be included in -Wall?

Hi, On Thu, 11 Jul 2013, Gabriel Dos Reis wrote: > > Arg, no. -Werror is very useful for development and I'm sure that > > code quality increases because of it, but it should never be enabled > > by default for releases. I think about 80% of the bugs we've had > > filed so far for packages f

Re: Dependency confusion in sched-deps

Hi, On Thu, 5 Dec 2013, Maxim Kuvyrkov wrote: > Output dependency is the right type (write after write). Anti > dependency is write after read, and true dependency is read after write. > > Dependency type plays a role for estimating costs and latencies between > instructions (which affects pe

Re: [RFC][PATCH 0/5] arch: atomic rework

Hi, On Thu, 20 Feb 2014, Linus Torvalds wrote: > But I'm pretty sure that any compiler guy must *hate* that current odd > dependency-generation part, and if I was a gcc person, seeing that > bugzilla entry Torvald pointed at, I would personally want to > dismember somebody with a rusty spoon.. Y

Re: [RFC][PATCH 0/5] arch: atomic rework

Hi, On Fri, 21 Feb 2014, Paul E. McKenney wrote: > > And with conservative I mean "everything is a source of a dependency, and > > hence can't be removed, reordered or otherwise fiddled with", and that > > includes code sequences where no atomic objects are anywhere in sight [1]. > > In the lig

Re: [RFC][PATCH 0/5] arch: atomic rework

Hi, On Mon, 24 Feb 2014, Linus Torvalds wrote: > > To me that reads like > > > > int i; > > int *q = &i; > > int **p = &q; > > > > atomic_XXX (p, CONSUME); > > > > orders against accesses '*p', '**p', '*q' and 'i'. Thus it seems they > > want to say that it orders against aliased storage

Re: Memory outputs in inline asm

Hi, On Wed, 26 Feb 2014, Richard Biener wrote: > > "\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]. Is it > > possible to tell GCC t

Re: Asm volatile causing performance regressions on ARM

Hi, On Thu, 27 Feb 2014, Richard Sandiford wrote: > [... many cases where 'volatile' in asm doesn't inhibit optimizations > ...] > > We do nothing this draconian for a normal function call, which could > easily use a volatile asm internally. IMO anything that isn't flushed > for a call shouldn

Re: LRA Stuck in a loop until aborting

Hi, On Thu, 17 Apr 2014, Richard Sandiford wrote: > > "The constraints on a ‘movm’ must permit moving any hard register to > > any other hard register provided..." > > > > by providing a define_expand that assigns from a general_operand to a > > nonimmediate_operand and ... > > > > *ldsi instru

Re: weird optimization in sin+cos, x86 backend

Hi, On Thu, 9 Feb 2012, Andrew Haley wrote: > On 02/09/2012 03:28 PM, Richard Guenther wrote: > > So - do you have an idea what routines we can start off with to get > > a full C99 set of routines for float, double and long double? The last > > time I was exploring the idea again I was looking a

Re: weird optimization in sin+cos, x86 backend

Hi, On Thu, 9 Feb 2012, James Courtier-Dutton wrote: > Results when compiled for 32bit x86. > gcc -m32 -g -O0 -c -o sincos1.o sincos1.c > gcc -m32 -static -g -o sincos1 sincos1.o -lm > > ./sincos1 > sin = 4.62613040764601746e-01 > sinl = 0.46261304076460176 > sincos = 4.62613040764601746e-01 > s

Re: weird optimization in sin+cos, x86 backend

Hi, On Thu, 9 Feb 2012, Andrew Haley wrote: > >>> So - do you have an idea what routines we can start off with to get > >>> a full C99 set of routines for float, double and long double? The > >>> last time I was exploring the idea again I was looking at the BSD > >>> libm. > >> > >> I'd start

Re: Iterating over RTL in Graphite

Hi, On Mon, 5 Mar 2012, Arnaldo wrote: > I couldn't get cfgexpand.c:basic_block expand_gimple_basic_block > (basic_block bb) to work by calling it directly because there is some > preprocessing in gimple_expand_cfg() that has to be done first. But > calling gimple_expand_cfg() modifies the CF

Re: C++: Letting compiler know asm block can call function that can throw?

Hi, On Thu, 29 Mar 2012, Stephan Bergmann wrote: > > > Anyway, would it be worthwhile filing an RFE for an asm annotation > > > telling the compiler that it contains code that can throw? > > > > I suppose yes. > > "RFE: Letting > compiler kno

Re: C++: Letting compiler know asm block can call function that can throw?

Hi, On Thu, 29 Mar 2012, Andrew Haley wrote: > On 03/29/2012 02:59 PM, Michael Matz wrote: > > Actually, with -fnon-call-exceptions volatile asms are already supposed to > > be throwing. It's just that this got lost with tree-ssa. With the patch > > and -fno

Re: C++: Letting compiler know asm block can call function that can throw?

Hi, On Fri, 30 Mar 2012, Jan Hubicka wrote: > > Motion across hardreg sets/uses are not restricted. And I would not expect > > an optimizing compiler to do that (it's your own fault to use hardregs in > > complex C code). > > Well, the syscall sequence is an example of somehting that should be

Re: Proposed plugin API for GCC

Hi, On Fri, 30 Mar 2012, Gabriel Dos Reis wrote: > On Fri, Mar 30, 2012 at 7:45 PM, David Malcolm wrote: > > > Here's another proposal then: actually use GObject introspection - > > provide a GObject-based API to GCC. > > > > In this approach, GCC would gain a dependency on glib and gobject, an

Re: C++: Letting compiler know asm block can call function that can throw?

Hi, On Mon, 2 Apr 2012, Jakub Jelinek wrote: > > inline int syscall1(int number, long arg1) { > > register int ax __asm__("eax"); > > register long di __asm__("rdi"); > > ax = number; > > di = arg1; > > __asm__ volatile ("syscall"); > > } > > > > _then_ we would probably get miscompila

Re: Switching to C++ by default in 4.8

Hi, On Tue, 10 Apr 2012, Jakub Jelinek wrote: > >*) gcc implementation has lots of hard coded TREE_OPERAND (exp, nn) > > > > e.g. > > exp->as_component_ref().get_field() .. > > exp->as_mem_access().get_base() ... > > exp->as_mem_acesss().get_address()

Re: RFC: -Wall by default

Hi, On Tue, 10 Apr 2012, Gabriel Dos Reis wrote: > > To be honest, all of those sound fine to me... > > > > bike-sheddin', > > -miles > > at the risk of more bike sheds: -Wcommon ? To use a variant of your own counterargument against -Wdefault: "common" also has a special commonly (ahem :) u

Re: Switching to C++ by default in 4.8

Hi, On Tue, 10 Apr 2012, Xinliang David Li wrote: > >> >             exp->as_component_ref().get_field() .. > > Actually it's not questionable.  The above stuff is _horrible_. > > Specifics please. It is _horrible_ because you are more used to the > existing way and the new style does not mat

Re: [x86-64 psABI] Document STT_GNU_IFUNC and R_X86_64_IRELATIVE

Hi, On Mon, 16 Apr 2012, H.J. Lu wrote: > Hi Michael, > > Can you apply IFUNC spec to x86-64 psABI? Yes, ... > BTW, where can I find the latest x86-64 psABI source? The svn > site: > > https://www.x86-64.org/svn/trunk/x86-64-ABI > > is down. ... once I find out what the problem with that is

Re: gimple vs gimple_seq in 4.8 trunk

Hi, On Fri, 11 May 2012, Basile Starynkevitch wrote: > However, the type gimple_seq still appears in a lot of source files > (mostly gcc/gimple*.c & gcc/tree*.c) > > Is this intended, or is this a temporary situation, and > further patches would remove all occurrences of gimple_seq everywhere?

Re: [discuss] [x86-64 psABI] RFC: Extend x86-64 psABI to support x32

Hi, On Mon, 14 May 2012, H.J. Lu wrote: > > As a minor nitpick, I have always used x32 with a lower case x.  The > > capital X32 looks odd to me. > > > > I used X32 together with LP64. I can use ILP32 instead of X32 when LP64 > is mentioned at the same time. I'd prefer that. x32 is a nice s

Re: a fork of gcc is sold for $26k?

Hi, On Sat, 16 Jun 2012, Jonathan Wakely wrote: > On 16 June 2012 12:01, Arch hvv wrote: > > Have anybody inspected it? Is GPL violated in this case or not (e.g. > > do they provide all patches they've made to gcc)? > > If it's based on llvm-gcc then it only uses GCC as the front-end so > there

Re: C++98/C++11 ABI compatibility for gcc-4.7

Hi, On Fri, 15 Jun 2012, Gabriel Dos Reis wrote: > On Fri, Jun 15, 2012 at 3:12 PM, James Y Knight wrote: > > > IMO, at the /very least/, libstdc++ should go ahead and change std::string > > to be the new implementation. Once std::string is ABI-incompatible between > > the modes, there's basica

Re: C++98/C++11 ABI compatibility for gcc-4.7

Hi, On Mon, 18 Jun 2012, Gabriel Dos Reis wrote: > Jeff, please note that the path that Michael took from what was said > ealier (in particular the quote he provided in his message) and the > conclusion of "enthusiasm for soname bump" is still a mystery. The quoted part suggested switching std

Re: Graphite news

Hi, On Fri, 22 Jun 2012, Tobias Grosser wrote: > There are two areas that do not yet have an isl counterpart. The > openscop import/export and the loop interchange heuristic. I think you > can safely crop the openscop import/export, as it is currently unused > and can later be added back if ne

Re: libstdc++ c++98 & c++11 ABI incompatibility

Hi, On Mon, 2 Jul 2012, Jeff Law wrote: > On 07/02/2012 11:53 AM, Paolo Carlini wrote: > > > > I also want to mention (I don't think somebody did already in the > > thread) that at some point, with Jason too, we discussed the idea of > > adding to each binary a marker about the ABI version which

Re: Dealing with C++98/11 ABI incompatibilities

Hi, On Wed, 4 Jul 2012, Richard Guenther wrote: > > [... mangling change ...] > > That would not address the issue of interoperability of a C++03 library > with a C++11 program or vice versa if they are using any of the changed > interfaces for interoperability. Passing pointers to such objec

Re: Dealing with C++98/11 ABI incompatibilities

On Wed, 4 Jul 2012, Michael Matz wrote: > It will by the way not break unnoticed: interfaces using the problematic > types would be mangled differently, and hence c++98 code would silently ... would _not_ silently ... > be resolved to a c++11 variant expecting a different layout.

Re: GCC Cauldron: Notes from the C++ ABI BOF

Hi, On Wed, 11 Jul 2012, Ian Lance Taylor wrote: > We will modify g++ to support a type attribute indicating the version of > the type, as a string. This type attribute will be inherited by any > other type that uses it, as a class/struct member or via inheritance. > Type attributes will be

Re: C++ and gather-detailed-mem-stats

Hi, On Wed, 15 Aug 2012, Richard Guenther wrote: > Prototype below - fire away on bikeshedding names. Make it mirror the preprocessor names that people are used to, and do away with the _loc_: __builtin_FILE, __builtin_FUNCTION, __builtin_LINE. Ciao, Michael.

Re: Reproducible gcc builds, gfortran, and -grecord-gcc-switches

Hi, On Thu, 16 Aug 2012, Simon Baldwin wrote: > Thanks for the note. > > To make things more concrete I've appended a prototype patch below. I > don't know if any other languages are affected, but if they are this > patch should extend reasonably well to cover those also. Does anyone > have

Re: C++ and gather-detailed-mem-stats

Hi, On Fri, 24 Aug 2012, Diego Novillo wrote: > > void foo (int bar) __attribute__((add_location_pack)); > > > > that directs GNU C++ to add a __Gcc_call_location_pack typed > > argument at each call site (properly constructed of course)? > > I really like this idea. > > Couldn't we make it ev

Re: C++ conversion? Why still .c (not .cc) files and CC (not CXX) in Makefile.in?

Hi, On Tue, 28 Aug 2012, Ian Lance Taylor wrote: > > Or do we have a rule than any file using C++ specific feature should > > be renamed from *.c to *.cc at the moment the C++ feature goes inside? > > We do not have such a rule and I would not recommend it. I think we > should rename all the

Re: GCC stack backtraces

Hi, On Wed, 29 Aug 2012, Ian Lance Taylor wrote: > Does this seem like something we could usefully add to GCC? Does > anybody see any big problems with it? Does it work without unwind tables? I suspect it doesn't as it's using libgccs unwinder, so that would be a problem if we were to use it

Re: gcc-c-api

Hi, On Mon, 10 Sep 2012, Richard Guenther wrote: > > Thoughts? > > Micha was also working on the proposed introspection API, I blame him > for not posting anything about this despite it's being "ready" since a > few months... He. I didn't yet come to make the changes about operand inspectors

Re: gcc-c-api

Hi David, On Mon, 10 Sep 2012, David Malcolm wrote: > Is it possible for you to post your work-in-progress code somewhere? Attached. > I know that you don't feel it's ready for committing, but I would find > it helpful - I'm interested in understanding the general approach, > rather than seei

Re: C++'ization of cp/parser.c/h, limited C++ parsing support for gengtype, Remove dependency of cp/cp-lang.c on cp/parser.h

Hi, On Mon, 10 Sep 2012, Gabriel Dos Reis wrote: > > You could also do this with an explicit pointer-to-context-struct > > parameter that's passed around (and that version of the patch I > > posted), but the class-based approached seems nicer to me. > > Are we talking about encapsulation or "l

Re: Cgraph Modification Plan

Hi, On Tue, 11 Sep 2012, Lawrence Crowl wrote: > change > node->symbol.whatever > to > node->ref_symbol().whatever Please don't uglify the compiler with this. If GTY deficiencies force you to do that, then hold off on it until GTY doesn't force you anymore. Ciao, Michael.

Re: Normalizing the bitmap APIs.

Hi, On Sat, 13 Oct 2012, Lawrence Crowl wrote: > > > I have no problem in always returning a status change, if you are OK > > > with that. > > > > I am ok with that. > > There is some rationale for being concerned about performance, as the > checking routines need to read memory locations that

Re: Build/Makefile question

Hi, On Sat, 27 Oct 2012, Ian Lance Taylor wrote: > On Sat, Oct 27, 2012 at 1:45 PM, Caroline Tice wrote: > > Ian Tayler (in private communication) asked that I get the part of the > > build log that shows the .so and .a files being built and send it to > > the list. Here it is. > > I see the p

Re: lto is streamable?

Hi, On Wed, 14 Nov 2012, Paulo Matos wrote: > There's a function in lto-streamer-out.c which determines if a tree is > streamable. > This is lto_is_streamable? I have a LANG_TYPE that I want to stream and > adding to that function: > #ifdef TARGET_MYPORT > if (code == LANG_TYPE) >return tr

Re: Simplifying Gimple Generation

Hi Lawrence, On Wed, 14 Nov 2012, Lawrence Crowl wrote: > Diego and I seek your comments on the following (loose) proposal. In principle I agree with the goal, I'm not sure I like the specific way yet, and even if I do I have some suggestions: > We will add a set of helper classes to be used a

Re: Simplifying Gimple Generation

Hi, On Thu, 15 Nov 2012, Gabriel Dos Reis wrote: > On Thu, Nov 15, 2012 at 8:48 AM, Michael Matz wrote: > [...] > > The method name should imply the action, e.g. 'add_stmt' or append_stmt > > or the like. > > strongly agreed. > [...] > > >

Re: Simplifying Gimple Generation

Hi, On Thu, 15 Nov 2012, Lawrence Crowl wrote: > They allow us to use the same name for the same actions in two > different contexts. In particular, distinguishing between statement > construction in SSA and non-SSA. I don't see the difference, and I don't see where you need context data to di

Re: Simplifying Gimple Generation

Hi, On Fri, 16 Nov 2012, Diego Novillo wrote: > > I think consistency should trump brevity here, so also add a tree code for > > the converter, i.e. > > ssa_stmt b = q.stmt (NOP_EXPR, shadow_type, a); > > Ah, yes. This one was amusing. When we were drafting the proposal, > Lawrence kept wond

Re: Unifying the GCC Debugging Interface

Hi, On Mon, 19 Nov 2012, Martin Jambor wrote: > Well, this is what I was actually afraid of. If things like generic > or tree dump of a tree value is selected by new TDF_ flags, then you > are in danger of just replacing current mess in function names by a > mess of constants. I'd much rather h

Re: Unused Field in graphite-poly.h?

Hi, On Fri, 16 Nov 2012, Lawrence Crowl wrote: > I think the field "htab_t original_pddrs" in struct scop in > graphite-poly.h is unused. Seems I overlooked it during my post-isl cleanups. Yes, remove it. Ciao, Michael.

Re: Unused DSE Functions

Hi, On Tue, 20 Nov 2012, Steven Bosscher wrote: > On Mon, 19 Nov 2012 18:31:27 -0800, Lawrence Crowl wrote: > > > Richi, ping? > > Just guessing... isn't he simply out on Honeymoon? Yes, he'll be back next week. Ciao, Michael.

Re: Unifying the GCC Debugging Interface

Hi, On Tue, 20 Nov 2012, Lawrence Crowl wrote: > On 11/19/12, Diego Novillo wrote: > > On Nov 19, 2012 Michael Matz wrote: > > > So, yes, the larger layouting should be determined by name of the > > > dump function. A flag argument might look nice from an interfa

Re: Hash table iterators.

Hi, On Thu, 22 Nov 2012, Lawrence Crowl wrote: > I have found that tree-flow.h implements iteration over htab_t, > while there is no current facility to do that with hash_table. > Unfortunately, the specific form does not match the standard C++ > approach to iterators. We have several choices. >

Re: System V Application Binary Interface 0.99.5

Hi, On Wed, 30 Jan 2013, Andrew Haley wrote: > I'm looking at Section 3.2.3, Parameter Passing. > http://artfiles.org/kernel.org/pub/scm/devel/binutils/hjl/x86-64-psabi.git/ > > I still cannot tell whether parameters should or should not be sign- or > zero-extended when they are moved into regis

Re: System V Application Binary Interface 0.99.5

Hi, On Wed, 30 Jan 2013, Andrew Haley wrote: > >>> It's an optimization to do so to avoid partial register stalls. > >> > >> Well, it's hardly an optimization if it's incorrect, and it seems to > >> be incorrect. Hmm? GCC generates code that doesn't rely on the extension taking place. > >> As

Re: Global Value Numbering and dependence on SSA in GCC

Hi, On Sun, 10 Feb 2013, Richard Biener wrote: > >> Consider the following example: > >> > >> if (...) > >>a_1 = 5; > >> else if (...) > >>a_2 = 2; > >> else > >>a_3 = 13; > >> > >> # a_4 = PHI > >> return a_4; > >> > >> Do you mean that I treat a

RE: genattrtab regression: infinite loop

Hi, On Mon, 11 Feb 2013, Paulo Matos wrote: > The following self-contained md file generates an infinite loop in genattrtab: > (define_attr "fpsize" "short,long" (const_string "short")) > > (define_attr "fplength" "" > (if_then_else > (eq_attr "fpsize" "long") > (const_int

Re: C/C++ Option to Initialize Variables?

Hi, On Mon, 18 Feb 2013, Jeffrey Walton wrote: > On Mon, Feb 18, 2013 at 10:34 AM, Andrew Haley wrote: > > On 02/18/2013 03:07 PM, Jeffrey Walton wrote: > >> On Mon, Feb 18, 2013 at 9:43 AM, Jonathan Wakely > >> wrote: > >>> On 18 February 2013 13:28, Jeffrey Walton wrote: > > > What if t

Re: C/C++ Option to Initialize Variables?

Hi, On Mon, 18 Feb 2013, Alexander Monakov wrote: > On Mon, 18 Feb 2013, Michael Matz wrote: > > Automatic variables, as they are on the stack, are unlikely to usually get > > the value 0 out of pure luck, so an option to initialize them to 0xDEADBEAF > > doesn't mak

Re: How does _ZNSs4_Rep20_S_empty_rep_storageE (not) become a unique global symbol?

Hi, On Tue, 19 Feb 2013, Stephan Bergmann wrote: > I'm puzzled by the following on Linux, where I don't understand what causes it > that a given symbol is exported as "u" (when viewed with nm, which documents > "u" as "a unique global symbol. This is a GNU extension...") or not: > > * On an olde

Re: How does _ZNSs4_Rep20_S_empty_rep_storageE (not) become a unique global symbol?

Hi, On Wed, 20 Feb 2013, Michael Matz wrote: > I.e. it looks like as if a following reference once the link editor saw > the definition of the symbol resets it's unique status. I can make both > symbols wrong/non-unique by placing wlocale-inst.o last in the linker > cmdlin

Re: [RFC] IL verification reorg

Hi, On Thu, 21 Feb 2013, Richard Biener wrote: > Do people think that the fine-grained verification control > is actually useful or do you agree with me that it leads to > sloppiness? I agree with you ... > --- 1955,1982 > return; > > #if defined ENABLE_CHECKING > ! if (flags

Re: Rant and proposal about bitfield semantics in our IL and the C/C++ Frontend

Hi, On Tue, 15 Jan 2008, Joseph S. Myers wrote: > On Mon, 14 Jan 2008, Richard Guenther wrote: > > > Can you clarify on the resulting promotions? As I remember the > > standard defines promotions based on the representable values, so > > long : 15 gets promoted to int, but long : 33 doesn't get

Re: [discuss] When is RBX used for base pointer?

Hi, On Wed, 13 Feb 2008, H.J. Lu wrote: > We need a callee-saved register for stack alignment. Can you expand on why? > In 64bit, our choices are rbx, and r12-r15. r12-r15 need the REX byte > and r12 also needs the SIB byte. So I'd like to use rbx. x86-64 psABI > says rbx is callee-saved and

Re: [discuss] When is RBX used for base pointer?

Hi, On Wed, 13 Feb 2008, H.J. Lu wrote: > Our proposal is at > > http://gcc.gnu.org/ml/gcc/2007-12/msg00567.html > > For most cases, we can align stack with RBP/RSP. But > we need an extra register when there is dynamic stack > allocation or nested functions. It has to be callee-saved > to work

Re: [PATCH] Make alias_sets_conflict_p less conservative

Hi, On Wed, 5 Mar 2008, Richard Kenner wrote: > I moved this to the main list because I think it's of general interest. > > I fail to understand how the issue of which alias set is used has any > appreciable effect on the amount of memory used at compile time. > > The issue here is with somethi

Re: Linux doesn't follow x86/x86-64 ABI wrt direction flag

Hi, On Wed, 5 Mar 2008, Aurelien Jarno wrote: > > So I think gcc at least needs an *option* to revert to the old behavior, > > and there's a good argument to make it the default for now, at least for > > x86/x86-64 on Linux. > > And for other kernels. I tested OpenBSD 4.1, FreeBSD 6.3, NetBSD 4.

Re: [PATCH] Make alias_sets_conflict_p less conservative

Hi, On Wed, 5 Mar 2008, Richard Kenner wrote: > > The problem lies in the way how we represent load and store dependencies > > as virtual operands. Conflicts between a pair of mem accesses are not > > evaluated by asking alias_set_conflicts_p() on both accesses, but instead > > via a chain of

Re: Linux doesn't follow x86/x86-64 ABI wrt direction flag

Hi, On Wed, 5 Mar 2008, Jan Hubicka wrote: > Kernels almost never follow ABI used by applications to last detail. But we aren't talking about the ABI the kernel uses internally, but about what is exposed to user-space via signal handlers. _That_ part needs to be followed, and if it isn't it'

Re: [PATCH] Make alias_sets_conflict_p less conservative

Hi, On Wed, 5 Mar 2008, Richard Kenner wrote: > > alias_sets_conflict_p() is used to determine if an addressable variable > > and a type conflict also from the tree-ssa alias machinery (in effect to > > determine which virtual variables need to be clobbered). It just isn't > > feed COMPONENT_

Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag

fix on kernel side in signal handling, or by > > > removing std usage completely > > On Wed, Mar 05, 2008 at 10:02:07PM +0100, Michael Matz wrote: > > That is true. But it requires updating the kernel to a fixed one if you > > want to run your programs compiled by 4

Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag

Hi, On Wed, 5 Mar 2008, Chris Lattner wrote: > > On Mar 5, 2008, at 1:34 PM, H. Peter Anvin wrote: > > >Richard Guenther wrote: > > >We didn't yet run into this issue and build openSUSE with 4.3 since more > > >than > > >three month. > > > >Well, how often do you take a trap inside an overlappi

Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag

Hi, On Wed, 5 Mar 2008, David Miller wrote: > I will be sure to hunt you down to help debug when someone reports that > once every few weeks their multi-day simulation gives incorrect results > :-) Give them a LD_PRELOADable DSO that intercepts signal() and sig_action(), installing a trampoli

Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag

Hi, On Wed, 5 Mar 2008, H. Peter Anvin wrote: > Michael Matz wrote: > > > > Many bugs are a big issue to people who actually hit them, and we had (and > > probably still have) far nastier corner case miscompilations here and there > > and nevertheless released.

Re: Linux doesn't follow x86/x86-64 ABI wrt direction flag

Hi, On Thu, 6 Mar 2008, Andi Kleen wrote: > To be realistic it is very unlikely anybody will measure a difference > from a few more or a few less clds in a program. Only an assumption, and in fact wrong. See upthread for a benchmark. IIRC Uros also made measurements to justify the removal of

Re: GSOC Student application

Hi, On Mon, 31 Mar 2008, Tom Tromey wrote: > > "Joe" == Joe Buck <[EMAIL PROTECTED]> writes: > > Joe> It's best to ignore J.C. Pizarro. He's an attention-seeking troll, > Joe> who has just enough technical knowledge to derail conversation. > > I think that if we've reached the point where

Re: [lto] Streaming out language-specific DECL/TYPEs

Hi, On Tue, 3 Jun 2008, Diego Novillo wrote: > On Tue, Jun 3, 2008 at 04:51, Richard Guenther > <[EMAIL PROTECTED]> wrote: > > > You may want to read > > > > http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00349.html > > Thanks. I think I will try to incorporate this in LTO so we won't > even nee

Re: lto gimple types and debug info

Hi, On Fri, 25 Jul 2008, Chris Lattner wrote: > >the frontends, but can concentrate on what is useful and needed for the > >middle-end right now. > > Sure, this makes plenty of sense to me (and sounds very *very* > familiar). Do you intend to include things like TBAA in the initial > type sy

Re: lto gimple types and debug info

Hi, On Fri, 25 Jul 2008, Chris Lattner wrote: > >But not all the trees implementing those types (and all the > >cross-references between those, that are important for parsing but not > >interesting at all for the middle-end). All you need is a tag (alias > >set number) per type and a graph gi

Re: gcc will become the best optimizing x86 compiler

Hi, On Mon, 28 Jul 2008, Agner Fog wrote: > Glibc 2.8 is still almost 5 times slower than the best function > libraries for unaligned data on Intel Core 2, and the default builtin > function is slower than any other implementation I have seen (copies 1 > byte at a time!). You must be doing so

Re: gcc will become the best optimizing x86 compiler

Hi, On Tue, 29 Jul 2008, Agner Fog wrote: > g++ (v. 4.2.3) without any options converts memcpy with unknown size to rep > movsb Use newer GCCs. They will (1) not expand memcpy inline for unknown sizes (without special options, also make sure you don't get the glibc inlines) and (2) won't exp

Re: [lto] C++. streaming, front-end specific tree nodes, IR types, and assembler names

Hi Bill, On Fri, 1 Aug 2008, Diego Novillo wrote: > > Finding that DECL_CONTEXT might include portions of what looked like > > template definitions, and surmising that lexical nesting was a > > language artifact that should no longer be of significance beyond the > > front-end, I attempted to cl

Re: Resuming SPEC performance tracking at RedHat

Hi, On Fri, 15 Jun 2007, Richard Guenther wrote: > so, no PPC testing from us (the old testing machine died and we don't > have a replacement for it). Actually it's back, and just needs to be partitioned and set up. Ciao, Michael.

Re: [PATCH][RFC] Re-structure tree_ssa_useless_type_conversion_1 to work towards a middle-end type system

Hi, On Wed, 20 Jun 2007, Richard Guenther wrote: > /* If the outer type is (void *), then the conversion is not > necessary. > ??? This makes tree_ssa_useless_type_conversion_1 not > transitive. */ Not this line itself makes it not transitive, but the fact that

Re: [PATCH][RFC] Re-structure tree_ssa_useless_type_conversion_1 to work towards a middle-end type system

Hi, On Wed, 20 Jun 2007, Andrew Pinski wrote: > On 6/20/07, Michael Matz <[EMAIL PROTECTED]> wrote: > > Hi, > > > > On Wed, 20 Jun 2007, Richard Guenther wrote: > > > > > /* If the outer type is (void *), then the conversion is not > > >

Re: [PATCH][RFC] Re-structure tree_ssa_useless_type_conversion_1 to work towards a middle-end type system

Hi, On Wed, 20 Jun 2007, Eric Botcazou wrote: > > ! 2) tree_ssa_useless_type_conversion_1 is not communtative. > > ! From a < b does not follow a > b. > > ! > > ! 3) Conversions are useless only if with the resulting type > > ! can be used in a subset of the operations the original

Re: [RFC] Improve Tree-SSA if-conversion - convergence of efforts

Hi, On Tue, 31 Jul 2007, Daniel Berlin wrote: > > 2. Store-sinking/load hoisting may have an overhead and may degrade > > performance unless the relevant conditional branch gets if-converted. > > I agree with you for conditional stores/loads. > > The unconditional store/load stuff, however, is

Re: [RFC] Improve Tree-SSA if-conversion - convergence of efforts

Hi, On Mon, 6 Aug 2007, Tehila Meyzels wrote: > > in if-conv (or phi-opt), but in ssa-sink (or some similar transformation > > which can or can not use value numbers and the like). > > OK. > > And what's your opinion WRT conditional loads/stores? > Since you've sent your conditional store trans

Re: [RFC] Migrate pointers to members to the middle end

Hi, On Tue, 7 Aug 2007, Ollie Wild wrote: > In response to a suggestion from Mark Mitchell, I've been attempting to > migrate pointers to members to the GCC middle end. The goal of this is > twofold: (a) to enable conversion of pointer to member dereferences to > direct function calls and mem

Re: x86_64 ABI

Hi, On Wed, 8 Aug 2007, Maurizio Vitale wrote: > with reference to the following: > > struct data { > data (long v) : m_data (v) {} > data (const data&) {} > long m_data; > }; > > data foo (data v) { > return v; > } > > my reading of the x86_64 ABI (v .98, sept 2006) o

Re: [RFC] Migrate pointers to members to the middle end

Hi, On Thu, 8 Aug 2007, Ian Lance Taylor wrote: those whose runtime type can be any derived one) can not. E.g. I wouldn't try to model the inheritance relationship. There is some advantage to knowing class heirarchy relationships in LTO. Some C++ programs implement different virtual subclas

Re: [RFC] Migrate pointers to members to the middle end

Hi, On Thu, 9 Aug 2007, Tom Tromey wrote: Michael> Yes, devirtualization. But I wonder if you really need class Michael> hierarchies for this (actually I'm fairly sure you don't). However, I'm not sure I agree with the above assertion. Specifically, for Java I think it is sometimes possible

Re: ipa for fortran question

Hi, On Sun, 12 Aug 2007, Jan Hubicka wrote: > > Recently I have tried to run Spec2000 fortran benchmarks with > > -fwhole-program and -combine flags. It looks like there was no effect > > of really combining files into one program, i.e. they are processed > > separately at ipa level. > > > >

Re: recent troubles with float vectors & bitwise ops

Hi, On Thu, 23 Aug 2007, Paul Brook wrote: > > There seem to be solid reasons to permit this, and no very strong ones > > to prohibit it. We can consider it to be a GNU extension for vectors. > > Vectors are of course themselves an extension already. > > How are you suggesting it be implemented

Re: question about rtl loop-iv analysis

On Tue, 28 Aug 2007, Kenneth Zadeck wrote: > And finally at the stage of rtl unrolling it looks like this: > [6] r186 = r2 + C; > r318 = r186 + 160; > loop: > r186 = r186 + 16 > if (r186 != r318) then goto loop else exit > > > > > regard

Re: question about rtl loop-iv analysis

Hi, On Wed, 29 Aug 2007, Bernd Schmidt wrote: > > Apart from that I agree that in the case of conditional defs multiple > > ones might reach a use. I disagree for partial defs, if one dominates > > the other. For most cases (except register allocation) a partial def > > is just a complete kil

<    1   2   3   4   5   >