Re: fatal error: gnu/stubs-32.h: No such file

On Mon, Jul 08, 2013 at 12:55:15AM -0500, Gabriel Dos Reis wrote: > Personally, I don't see anything broken with that. The world we are > in today is very different from a decade ago. More than a decade ago, > a multilib build by default -probably- made sense; I don't see that today. But having

Re: fatal error: gnu/stubs-32.h: No such file

On Mon, Jul 08, 2013 at 08:11:03AM -0700, Bruce Korb wrote: > > But having multilib enabled by default on x86_64 is simply very highly > > desirable, > > REMEMBER: we are talking about having a multilib enableable test in > the configure. If it fails, then it is not enabled by default. This is n

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

On Wed, Jul 10, 2013 at 07:42:55AM -0700, Andi Kleen wrote: > Andrew Haley writes: > > > 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

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

On Thu, Jul 11, 2013 at 11:11:28AM +0200, Andreas Arnez wrote: > > On 07/10/2013 04:51 AM, Andreas Arnez wrote: > >> OK, I may be biased, because I have *only* seen false positives with > >> this warning so far. Others may have made better experience with it. > > It's found numerous bugs across ma

Re: -ftls-model docs/implementation inconsistency

On Fri, Jul 19, 2013 at 08:08:26PM +0400, Alexander Monakov wrote: > On Fri, 19 Jul 2013, Jakub Jelinek wrote: > > The change of memory models based on flag_shlib is completely intentional, > > it is similar to the linker TLS optimizations but at the compiler level, > > so i

Re: -ftls-model docs/implementation inconsistency

On Fri, Jul 19, 2013 at 07:55:35PM +0400, Alexander Monakov wrote: > On Fri, 19 Jul 2013, Jakub Jelinek wrote: > > Furthermore, on Linux you can dlopen even libraries with initial-exec TLS > > model in it (as long as they don't use too big TLS sections). > > This is th

Re: -ftls-model docs/implementation inconsistency

On Fri, Jul 19, 2013 at 07:34:30PM +0400, Alexander Monakov wrote: > Suppose a user builds a non-PIC shared object for x86 target with gcc by > passing -shared but not -fPIC. This works, but internally GCC will not set > flag_shlib (as flag_shlib == flag_pic && !flag_pie). Usually it doesn't (o

Re: RFC: Gimple combine/folding interface

On Mon, Jul 22, 2013 at 01:36:17PM -0600, Jeff Law wrote: > Before designing an interface which inherently includes that > information we should think hard about if it's valuable and if a > tree combiner is the right place. > > I have high hopes that we can get the zero/sign extension > eliminatio

Re: [x86-64 psABI]: Extend x86-64 psABI to support AVX-512

On Wed, Jul 24, 2013 at 07:36:31PM +0200, Richard Biener wrote: > >Make them callee saved means we need to change ld.so to > >preserve them and we need to change unwind library to > >support them. It is certainly doable. > > IMHO it was a mistake to not have any callee saved xmm register in the >

Re: [x86-64 psABI] RFC: Extend x86-64 PLT entry to support MPX

On Tue, Jul 23, 2013 at 12:49:06PM -0700, H.J. Lu wrote: > There are 2 psABI considerations: > > 1. Should PLT entries in all binaries, with and without MPX, be changed > to 32-byte or just the necessary ones? Ugh, please don't. > 2. Only branch to PLT entry with BND prefix needs 32-byte P

Re: Questions about LTO infrastructure and pragma omp target

On Thu, Aug 15, 2013 at 05:36:39PM +0400, Ilya Verbin wrote: > 2. The second question, regarding #pragma omp target implementation. > I'm going to reuse LTO approach in a prototype, that will produce 2 > binaries - for host and target architectures. Target binary will contain > functions outlined

Re: XNEW and consorts

On Thu, Aug 22, 2013 at 02:19:39PM +0200, Richard Biener wrote: > Gabriel Dos Reis wrote: > >Now that we have transitioned to C++, do we still need to use > >placebo like XNEW and XNEWVEC in GCC source code proper? > >(I am not talking about uses in liberty.) > > > >Note that XNEW in particular do

Re: [RFC] Offloading Support in libgomp

On Thu, Aug 22, 2013 at 06:08:10PM +0400, Michael V. Zolotukhin wrote: > We're working on design for offloading support in GCC (part of OpenMP4), and I > have a question regarding libgomp part. > > Suppose we expand '#pragma omp target' like we expand '#pragma omp parallel', > i.e. the compiler ex

Re: [RFC] Offloading Support in libgomp

On Fri, Aug 23, 2013 at 01:28:10PM +0400, Michael V. Zolotukhin wrote: > Sure, I used '#pragma omp target' just for a simple example. The > question about '#pragma omp target data' is still open. As far as I > understand, all three of the pragmas could require data marshalling (but > not necessar

Re: Questions about LTO infrastructure and pragma omp target

On Fri, Aug 23, 2013 at 02:55:27PM +0400, Ilya Verbin wrote: > I'm trying to implement the approach with modified lto-wrapper. > Suppose we have a bytecode of the routine foo, streamed during ompexp pass > into some section, say .gnu.omptarget_foo. > In function lto.c:do_whole_program_analysis() a

Re: Questions about LTO infrastructure and pragma omp target

On Fri, Aug 23, 2013 at 02:24:42PM +0200, Richard Biener wrote: > >As far as I understood, in addition to the bytecode of foo, we should > >also stream extra symtab_nodes, and read them somewhere in > >lto-cgraph.c:input_symtab(). > >This means we should maintain 2 symtabs inside WPA stage - origin

Re: [RFC] Offloading Support in libgomp

On Fri, Aug 23, 2013 at 07:30:52PM +0400, Michael V. Zolotukhin wrote: > That makes sense. We could maintain a vector of descriptors for each > encountered MAP clause and push to and pop from it when needed (when > e.g. new mapping is encountered inside 'pragma omp target data'). The > desciptor

Re: Questions about LTO infrastructure and pragma omp target

On Fri, Aug 23, 2013 at 09:15:14PM +0400, Ilya Verbin wrote: > On 23 Aug 13:17, Jakub Jelinek wrote: > > I don't think we should stream into more than one target section. > > There should be just .gnu.target_lto section (or whatever other suitable > > name) and should

Re: --with-dwarf2 and default DWARF version

On Mon, Aug 26, 2013 at 01:42:18PM +0530, Senthil Kumar Selvaraj wrote: > The help text for the --with-dwarf2 configure option says it forces > the default debug format to be DWARF 2. However, the built compiler > still produces DWARF 4, unless -gdwarf-2 is explicitly specified when > compi

Re: [RFC] Offloading Support in libgomp

On Mon, Aug 26, 2013 at 03:59:11PM +0400, Michael V. Zolotukhin wrote: > As I currently see it, the given code would be expanded to something like > this: > > // Create two versions of V: for host and for target > int v; > int v_target __attribute(target); > > // The same for TGT function

Re: [RFC] Offloading Support in libgomp

On Mon, Aug 26, 2013 at 05:29:36PM +0400, Michael V. Zolotukhin wrote: > > Nope, there is only one target data pragma, so you would use here just: > > > > struct data_descriptor data_desc2[2] = { ... }; > > GOMP_target (-1, bar.omp_fn.1, "bar.omp_fn.1", data_desc2, 2); > This 'pragma target' i

Re: [RFC] Offloading Support in libgomp

On Tue, Aug 27, 2013 at 03:26:09PM +0400, Michael V. Zolotukhin wrote: > > Anyway, the GOMP_target_data implementation and part of GOMP_target would > > be something along the lines of following pseudocode: > > > > device_data = lookup_device_id (device_id); > > ... > Thanks, I've seen that simila

Re: [RFC] Offloading Support in libgomp

On Tue, Aug 27, 2013 at 03:55:38PM +0400, Michael V. Zolotukhin wrote: > > What I meant was just that if you call GOMP_target with > > num_descs N, then the structure will look like: > > struct .omp_target_data > > { > > sometype0 *var0; > > sometype1 *var1; > > ... > > sometypeNminus1 *var

Re: dynamic plugin in c++

On Wed, Aug 28, 2013 at 01:35:45PM +0530, avantikagupta wrote: > i am writing a dynamic plugin, First start with compiling the plugin with warnings, I bet the compiler would tell you: static unsigned int

Re: [RFC] Offloading Support in libgomp

On Wed, Aug 28, 2013 at 12:39:00PM +0200, Richard Biener wrote: > > So, here is the original code: > > > > #pragma omp declare target > > int v = 6; > > int tgt () > > { > > #pragma omp atomic update > > v++; > > return 0; > > } > > #pragma omp end declare target > > > >

Re: [RFC] Offloading Support in libgomp

On Wed, Aug 28, 2013 at 01:21:53PM +0200, Richard Biener wrote: > My thought was that we need to have control over scheduling and thus have > a single runtime to be able to execute the following in parallel on the > accelerator and the CPU: > > #pragma omp parallel > { > #pragma omp target >fo

Re: Questions about LTO infrastructure and pragma omp target

On Tue, Sep 03, 2013 at 05:59:35PM +0400, Michael V. Zolotukhin wrote: > Let's continue this discussion. > > Summing up what was said above, I think we need following changes in > LTO-infrastructure to enable offloading: > * [in lto_plugin] claim files with .openmp (or whatever > name) sections

Re: Questions about LTO infrastructure and pragma omp target

On Tue, Sep 03, 2013 at 10:29:56PM +0400, Michael V. Zolotukhin wrote: > > The idea, as we discussed it at the GNU Tools Cauldron's Acceleration > > BoF, is that the host program (for at least some acceleration devices) > > will be responsible for loading the acceleration device's code to the > > d

Re: Reusing OpenMP front end infrastructure for OpenACC -- how?

On Thu, Sep 05, 2013 at 04:51:14PM +0200, Thomas Schwinge wrote: > Implementing OpenACC support in GCC's frontends, there are things that I > trivially have to reimplement, that are already present for OpenMP. For > example, the infrastructure for parsing clauses (as attached to OpenACC > and Open

Re: Bootstrap broken in libobjc/sendmsg.c

On Fri, Sep 06, 2013 at 02:38:01PM +0200, Jan Hubicka wrote: > > > .. looks like this is target/58269, which therefore affects > > > x86_64-linux too. > > > > Now this reproduces to me, too. apppy_args expansion is trying to preserve > > AVX > > register in V8SF mode when AVX is disabled. This

Re: RFC: SIMD pragma independent of Cilk Plus / OpenMPv4

On Mon, Sep 09, 2013 at 10:18:20AM -0400, Tim Prince wrote: > I pulled down an update of gcc gomp-4_0-branch yesterday and see in > the not-yet-working additions to gcc testsuite there appears to be a > move toward adding more cilkplus clauses to omp simd, such as > firstprivate lastprivate (which

Re: RFC: Inlines, LTO and GCC

On Tue, Sep 10, 2013 at 10:06:04AM +0200, David Brown wrote: > This last point is crucial. I haven't looked at the code in question, > but one point to check is how the functions are called. If they are > often called with constant values, then they may be very much simplified > due to constant p

Re: [RFC] Offloading Support in libgomp

On Tue, Sep 10, 2013 at 07:01:26PM +0400, Michael V. Zolotukhin wrote: > I continued playing with plugins for libgomp, and I have several questions > regarding that: > > 1) Would it be ok, at least for the beginning, if we'd look for plugins in a > folder, specified by some environment variable?

Re: [RFC] Offloading Support in libgomp

On Tue, Sep 10, 2013 at 07:30:53PM +0400, Michael V. Zolotukhin wrote: > > > 4) We'll need to store some information about available devices: > > > - a search tree with data about mapping > > > > For the search tree, I was going to actually implement it myself, but got > > interrupted this week

Re: Auto-vectorizer and (mis-)alignment support assumptions

On Thu, Sep 12, 2013 at 11:25:31AM +0200, Richard Biener wrote: > On Thu, Sep 12, 2013 at 10:40 AM, Frederic Riss > wrote: > > Thus I'm wondering if the vectorizer makes the assumption that a > > target must be able to load/store vectors aligned on any element size > > boundary. If it's the case,

Re: [RFC] Offloading Support in libgomp

fails, return NULL for host fallback). --- libgomp/target.c.jj 2013-09-09 17:41:02.290429613 +0200 +++ libgomp/target.c2013-09-13 13:17:31.703502392 +0200 @@ -1,4 +1,4 @@ -/* Copyright (C) 2013 Free Software Foundation, Inc. +/* Copyright (C) 1998-2013 Free Software Foundation, Inc. Contribute

Re: [RFC] Offloading Support in libgomp

On Fri, Sep 13, 2013 at 05:11:09PM +0400, Michael V. Zolotukhin wrote: > > FYI, I'm attaching a WIP patch with the splay tree stuff. > Thanks, I'll take a look. By the way, isn't it better to move splay-tree > implementation to a separate file? As it is just a few routines, heavily modified from

Re: [RFC] Offloading Support in libgomp

On Fri, Sep 13, 2013 at 02:36:14PM +0200, Jakub Jelinek wrote: > FYI, I'm attaching a WIP patch with the splay tree stuff, debugging > target-1.c with OMP_DEFAULT_DEVICE=257 right now (with all tgtv related > stuff removed), but hitting some error regarding OMP_CLAUSE_MAP_POINTER

Re: [RFC] Offloading Support in libgomp

On Fri, Sep 13, 2013 at 01:34:43PM +0400, Michael Zolotukhin wrote: > 1.2. Linking > > When all source files are compiled, a linker is invoked. The linker is passed > a special option to invoke openmp-plugin. The plugin is responsible for > producing target-side executables - for each target it

Re: Questions about LTO infrastructure and pragma omp target

On Tue, Sep 17, 2013 at 03:30:10PM +0400, Ilya Verbin wrote: > On 17 Sep 10:12, Richard Biener wrote: > > It looks more like a hack ;) It certainly doesn't look scalable to multiple > > target ISAs. You also unconditionally invoke the target compiler (well, you > > invoke the same compiler ...) >

Re: Questions about LTO infrastructure and pragma omp target

On Tue, Sep 17, 2013 at 01:56:39PM +0200, Richard Biener wrote: > On Tue, Sep 17, 2013 at 1:30 PM, Ilya Verbin wrote: > > On 17 Sep 10:12, Richard Biener wrote: > >> It looks more like a hack ;) It certainly doesn't look scalable to > >> multiple > >> target ISAs. You also unconditionally invok

Re: [RFC] Offloading Support in libgomp

On Tue, Sep 17, 2013 at 04:04:54PM +0400, Michael V. Zolotukhin wrote: > > ... and the first GOMP_target, > > GOMP_target_data or GOMP_target_update from a particular shared library or > > binary (all of them will have __OPENMP_TARGET__ weak hidden symbol as one of > > the arguments) offloads the e

Re: [gomp4] GOMP_target fall back execution

On Wed, Sep 18, 2013 at 11:54:35AM +0400, Kirill Yukhin wrote: > Hello, > It seems that currently GOMP_target perform call to host variant of the > routine: > > void > GOMP_target (int device, void (*fn) (void *), const char *fnname, > size_t mapnum, void **hostaddrs, size_t *sizes,

Re: [gomp4] GOMP_target fall back execution

On Wed, Sep 18, 2013 at 12:31:18PM +0200, Richard Biener wrote: > On Wed, Sep 18, 2013 at 10:38 AM, Jakub Jelinek wrote: > > On Wed, Sep 18, 2013 at 11:54:35AM +0400, Kirill Yukhin wrote: > >> Hello, > >> It seems that currently GOMP_target perform call to host v

Re: [gomp4] GOMP_target fall back execution

On Wed, Sep 18, 2013 at 02:52:17PM +0400, Ilya Verbin wrote: > On 18 Sep 10:38, Jakub Jelinek wrote: > ICC prints: > > inp 1 > 3 0 2 1 0 > 3 0 2 1 1 That doesn't look correct, because for levels above omp_get_level () it should return -1. Either the host fallback ins

Re: Questions about LTO infrastructure and pragma omp target

On Thu, Sep 19, 2013 at 02:44:30PM +0400, Ilya Verbin wrote: > Do I understand correctly that GIMPLE IL is target dependent, but we will emit > the same IL for all targets? Yes. Some of the target dependencies are required to be inherited from the host, some can be tolerated (optimization decisio

Re: g++ -Wl,--as-needed -pthread behaviour

On Tue, Sep 24, 2013 at 01:13:53PM +0100, Jonathan Wakely wrote: > > Try compiling that testcase with -static rather than -Wl,--as-needed. > > You'll hit std::system_error just like you do here. I believe that is > > a libstdc++ bug, and can be solved by making libstdc++.a use strong > > reference

Re: g++ -Wl,--as-needed -pthread behaviour

On Tue, Sep 24, 2013 at 01:34:52PM +0100, Jonathan Wakely wrote: > On 24 September 2013 13:24, Jakub Jelinek wrote: > > On Tue, Sep 24, 2013 at 01:13:53PM +0100, Jonathan Wakely wrote: > >> It's the std::thread constructor template that needs pthread_create. > &g

Re: [gomp4, openacc-1_0-branch] Re: OpenACC branch

On Mon, Sep 30, 2013 at 12:05:55AM +0200, Thomas Schwinge wrote: > Is my understanding correct that the GCC policy regarding extensions such > as support for OpenACC or OpenMP 4 is: first develop and polish this on a > branch (such as openacc-1_0-branch or gomp-4_0-branch), and once > *everything*

Re: [x86-64 psABI] RFC: Extend x86-64 PLT entry to support MPX

On Tue, Oct 01, 2013 at 04:15:53PM +0400, Ilya Enkovich wrote: > I'd like to restart discussion on this topic. I see two viable options > in this thread for PLT entry for MPX. > > The first one is to use new relocation for calls requiring extended > PLT. Linker may decide then which PLT entries sh

Re: [x86-64 psABI] RFC: Extend x86-64 PLT entry to support MPX

On Mon, Oct 07, 2013 at 01:31:29PM +0400, Ilya Enkovich wrote: > Seems assembler may not always detect MPX relocation. For simple calls > it may check for 'bnd' prefix, but for indirect call we need to > generate MPX relocation for 'mov' instruction storing address of the > called function. This in

Re: libgcc/sync.c vs. cgraph alias tracking

On Wed, Oct 09, 2013 at 10:59:35AM +0200, Jan Hubicka wrote: > I see, the previous implementation tricked the one-declaration rule by > introducing two names. What made the difference is that the second name > is expanded as builtin... > > So you don't have __bulitin_sync_synchronize() at hand th

Re: libgcc/sync.c vs. cgraph alias tracking

On Wed, Oct 09, 2013 at 10:56:33AM +0100, Richard Sandiford wrote: > gcc/testsuite/ > * gcc.target/i386/asm-rename-1.c: New file. > > Index: gcc/testsuite/gcc.target/i386/asm-rename-1.c > === > --- /dev/null 2013-10-09 10:21:20.

GCC 4.8.2 Release Candidate available from gcc.gnu.org

The first release candidate for GCC 4.8.2 is available from ftp://gcc.gnu.org/pub/gcc/snapshots/4.8.2-RC-20131009 and shortly its mirrors. It has been generated from SVN revision 203308. I have so far bootstrapped and tested the release candidate on x86_64-linux and i686-linux. Please test it

GCC 4.8.2 Status Report (2013-10-09)

Status == The GCC 4.8.2-rc1 release candidate has been released. The branch is frozen now, all changes require release manager approval until the final release of GCC 4.8.2 which should happen roughly one week after the release candidate. Quality Data Priority # Chan

Re: GCC retargeting

On Thu, Oct 10, 2013 at 04:48:05PM +0530, Umesh Kalappa wrote: > where A has value oxff and B has value 0xee. If the 16-bit registers overlap the 8-bit ones, then IMNSHO you don't want to use different register numbers for the pairs, instead you just tell GCC that HImode values must be put into

Re: [RFC] Vectorization of indexed elements

On Fri, Oct 11, 2013 at 03:54:08PM +0100, Vidya Praveen wrote: > Here's a compilable example: > > void > foo (int *__restrict__ a, > int *__restrict__ b, > int *__restrict__ c) > { > int i; > > for (i = 0; i < 8; i++) > a[i] = b[i] * c[2]; > } > > This is vectorized by duplica

GCC 4.8.2 Released

The GNU Compiler Collection version 4.8.2 has been released. GCC 4.8.2 is the second bug-fix release containing important fixes for regressions and serious bugs in GCC 4.8.1 with over 70 bugs fixed since the previous release. This release is available from the FTP servers listed at: http://www

GCC 4.8.3 Status Report (2013-10-16)

Status == GCC 4.8.2 has been released, the branch is again open for regression bugfixes and documentation fixes. GCC 4.8.3 could be tentatively released in March next year. Quality Data Priority # Change from Last Report --- ---

Re: [gomp4] Building binaries for offload.

On Tue, Oct 15, 2013 at 02:03:48PM +0400, Kirill Yukhin wrote: > Let me somewhat summarize current understanding of > host binary linking as well as target binary building/linking. > > We put code which supposed to be offloaded to dedicated sections, > with name starting with gnu.target_lto_ > >

Re: [RFC] Detect most integer overflows.

On Sun, Oct 27, 2013 at 12:35:24PM +0100, Ondřej Bílka wrote: > On Sun, Oct 27, 2013 at 11:51:00AM +0100, Marek Polacek wrote: > > Or just wait till the integer overflow detection in ubsan is completed. > > > As these computations now are done on unsigned type which has behaviour > defined as modul

Re: Warning about __DATE__ and __TIME__

On Mon, Oct 28, 2013 at 09:10:08AM -0400, Frank Ch. Eigler wrote: > Gerald Pfeifer writes: > > > To make it easier to reproduce builds of software and entire GNU/Linux > > distributions, RMS had the idea of adding a warning to GCC that warns > > about the use of __DATE__ and __TIME__. [...] >

Re: [RFC] Offloading Support in libgomp

On Mon, Oct 28, 2013 at 02:42:37PM +0400, Ilya Verbin wrote: > We have a MIC offload runtime library (liboffload), which is an abstraction > over > COI. Currently it is a part of ICC, but there are plans of open sourcing it. > However, liboffload requires somewhat different tables comparing to wh

Re: [RFC] Target compilation for offloading

On Tue, Oct 29, 2013 at 01:33:17PM +0400, Andrey Turetskiy wrote: > I wonder how compiler is going to choose which target binaries should > be created for offload? Will compiler make choice on its own or it is > the user who should add specific options like --offload-target=... > How does compiler

Re: [PATCH] RE: libcilkrts/runtime/config/generic/cilk-abi-vla.c failure (was: [PATCH, committed] libcilkrts - Add check for availability of alloca.h (Bug Bootstrap/58918))

On Thu, Oct 31, 2013 at 03:21:14AM +, Iyer, Balaji V wrote: > It is because of this line: > > i[456]86-*-*) > config_dir="x86" > ;; > > It should include a 3 too. My bad sorry. I have fixed it. Attached, please > find a patch. It is committed as obvious. It is not just about not i

Re: [PATCH] RE: libcilkrts/runtime/config/generic/cilk-abi-vla.c failure (was: [PATCH, committed] libcilkrts - Add check for availability of alloca.h (Bug Bootstrap/58918))

On Thu, Oct 31, 2013 at 01:32:19PM +, Iyer, Balaji V wrote: > > It is not just about not including 3, but also the []s in configure.ac were > > eaten by > > m4. In any case, shouldn't you fix also config/generic? > > > > I am in the process of fixing config/generic. I also replaced [456] wi

Re: Question about a fix for PR 58925

On Thu, Oct 31, 2013 at 04:10:51PM -0400, Andrew MacLeod wrote: > On 10/31/2013 03:31 PM, Andrew MacLeod wrote: > >On 10/31/2013 01:02 PM, Andrew MacLeod wrote: > >>On 10/31/2013 12:13 PM, Andrew MacLeod wrote: > > > >but the file is in the correct directory: > >/gcc/2013-10-31/build/x86_64-unknown

Re: integer_onep vs. signed 1-bit bitfields

On Sat, Nov 02, 2013 at 03:15:44PM +, Richard Sandiford wrote: > What should integer_onep mean if we have a signed 1-bit bitfield in > which the bit is set? Seen as a 1-bit value it's "obviously" 1, > but seen as a value extended to infinite precision it's -1. > > Current mainline returns fal

Re: integer_onep vs. signed 1-bit bitfields

On Sat, Nov 02, 2013 at 05:38:53PM +, Richard Sandiford wrote: > OK, thanks. I should have realised this earlier, but we have: > > /* Return 1 if EXPR is the integer constant one or the corresponding >complex constant. */ > > int > integer_onep (const_tree expr) > ... > /* Return 1 if E

Re: Report on the bounded pointers work

On Tue, Nov 05, 2013 at 09:54:31AM -0700, Jeff Law wrote: > On 11/05/13 03:11, Yury Gribov wrote: > > > If you're referring to mudflap (Frank Eigler's work), > > > ... > > > It never reached a point where interoperability across objects with > >and without mudflap instrumentation worked > >Could y

Re: [RFC] Target compilation for offloading

On Wed, Nov 06, 2013 at 05:11:07PM +0400, Andrey Turetskiy wrote: > > Let's check my understanding: > > 1) We can configure gcc with, say, --offload-target=mic,ptx. It means Note, configure options should be either --with- or --enable- prefixed. Plus, it is probably better to use configuration tri

Re: Mothballing C11 atomic work for now.

On Wed, Nov 06, 2013 at 10:07:36PM +, Joseph S. Myers wrote: > The patch I've posted at > is intended to > be mainline-ready (with the hopes that other people may pick up the ObjC > and OpenMP issues, and floating-point handling for n

Re: Mothballing C11 atomic work for now.

On Thu, Nov 07, 2013 at 01:23:20PM +, Joseph S. Myers wrote: > On Thu, 7 Nov 2013, Jakub Jelinek wrote: > > > On Wed, Nov 06, 2013 at 10:07:36PM +, Joseph S. Myers wrote: > > > The patch I've posted at > > > <http://gcc.gnu.org/ml/gcc-patches

Re: [RFC] Target compilation for offloading

On Thu, Nov 07, 2013 at 07:36:06PM +0400, Andrey Turetskiy wrote: > > Note, configure options should be either --with- or --enable- prefixed. > > Plus, it is probably better to use configuration triplets there. > > Do you mean smth like this: > configure --build=x86 --host=x86 --target=x86,mic,ptx

Re: [RFC] Target compilation for offloading

On Fri, Nov 08, 2013 at 06:26:53PM +0400, Andrey Turetskiy wrote: > Thanks. > And a few questions about compiler options: > 1) You've mentioned two options for offloading: > -foffload-target= - to specify targets for offloading > -foffload-target-= - to specify > compiler options for differ

Re: [gomp4] libgomp.c/target-1.c failing in fn2's GOMP_target_update

On Fri, Nov 08, 2013 at 04:29:03PM +0100, Thomas Schwinge wrote: > > On the gomp-4_0-branch, when using the ID 257 device (host fallback but > with non-shared memory), I see the libgomp.c/target-1.c test fail in > fn2's GOMP_target_update call: > > libgomp: Trying to update [0x601a80..0x601a8

Re: Vectorizer/alignment

On Mon, Nov 11, 2013 at 12:29:29PM +0100, Richard Biener wrote: > On Fri, Nov 8, 2013 at 6:51 PM, Hendrik Greving > wrote: > > That didn't do it. What was the rationale w.r.t. to the relation > > between the vectorized sequenced and/or the alignment (I think these > > things are actually 2 separat

Re: Vectorizer/alignment

On Mon, Nov 11, 2013 at 02:13:24PM +0100, Richard Biener wrote: > On Mon, Nov 11, 2013 at 12:39 PM, Jakub Jelinek wrote: > > On Mon, Nov 11, 2013 at 12:29:29PM +0100, Richard Biener wrote: > >> On Fri, Nov 8, 2013 at 6:51 PM, Hendrik Greving > >> wrote: > >&g

Re: Requirements on Binutils and Linux kernel for GCC + Libsanitizer (was: Re: Bootstrap broken on x86_64 Linux?)

On Tue, Nov 12, 2013 at 11:34:41AM +0400, Kostya Serebryany wrote: > On Sun, Nov 10, 2013 at 10:34 PM, FX wrote: > > > > Unfortunately, we are not able to keep up with the old kernels. > > > Two possible ways to go: > > > - disable libsanitizer on older kernels > > > - someone needs to work wit

Re: Great example of why "everything is a tree" sucks

On Tue, Nov 12, 2013 at 12:59:47PM -0700, Jeff Law wrote: > So I lost something like 3 hrs last night due to writing a hunk of > code like this > > if (INTEGRAL_TYPE_P (gimple_assign_lhs (stmt))) INTEGRAL_TYPE_P is a macro, which accepts everything, just adding a TYPE_CHECK to that macro would be

Re: Great example of why "everything is a tree" sucks

On Wed, Nov 13, 2013 at 11:49:56AM +0100, Steven Bosscher wrote: > source language? That's still true, and one reason for it is 'tree'. > The Ada, Fortran, and even C front ends use front-end specific data > structures for most parsed entities and only produce 'tree' from it in > the process of gen

Re: [RFC] Replace Java with Go in default languages

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 > > split of the distributed tarballs, that is, no

Re: Great example of why "everything is a tree" sucks

On Wed, Nov 13, 2013 at 04:43:45PM +, Joseph S. Myers wrote: > On Wed, 13 Nov 2013, Jeff Law wrote: > > > On 11/13/13 08:59, Joseph S. Myers wrote: > > > On Wed, 13 Nov 2013, Steven Bosscher wrote: > > > > > > > Really the best place to start IMHO would be to evict 'tree' from the > > > > fro

Re: memset zero bytes at NULL - isolate-erroneous-paths

On Mon, Nov 18, 2013 at 12:08:27PM +0100, Richard Biener wrote: > I'd say that turning memset (0, '\0', 0) into a trap is bad from a QOI > perspective. Jeff, is there an easy way to avoid this? Testcase: > > void fn (void *addr, int a) > { > if (a == 0) > addr = (void *)0; > __builtin_me

Re: Frame pointer, bug or feature? (x86)

On Mon, Nov 18, 2013 at 11:22:22AM -0800, Hendrik Greving wrote: > Interesting, I just read up on it and I didn't know that. Thanks. Is > it correct to say though that it is a missing optimization and > frame_pointer_needed shouldn't evaluate to true? Certainly not unconditionally. It depends on

Re: Frame pointer, bug or feature? (x86)

On Mon, Nov 18, 2013 at 12:43:50PM -0800, Hendrik Greving wrote: > Hmm don't VLA's obey the same lifetime rules as regular automatic > arrays on the stack? In the languages yes, in GCC no. There is code to determine possibilities of sharing some stack space between variables that can't be used at

Re: Multiple local register variables w/ same register

On Wed, Nov 20, 2013 at 07:56:57AM +1000, Richard Henderson wrote: > It appears not: > > int __attribute__((noinline)) f(void) > { > { > register int x __asm__("eax"); > x = 1; > } > { > register int y __asm__("eax"); > return ++y; > } > } > > extern void abort(void); > >

Re: build broken on ppc linux?!

On Fri, Nov 22, 2013 at 12:47:17PM +0100, Arnaud Charlet wrote: > > >>> Looks like another issue for the libsanitizer maintainers. > > >> > > >> I've been doing bootstraps, but didn't see this because the > > >> kernel header linux/vt.h use on the RHEL6 system I was doing > > >> builds on has that

Re: build broken on ppc linux?!

On Fri, Nov 22, 2013 at 10:11:18AM -0800, Mike Stump wrote: > On Nov 22, 2013, at 4:31 AM, Konstantin Serebryany > wrote: > > These CFI directives were completely removed in upstream at > > http://llvm.org/viewvc/llvm-project?rev=192196&view=rev > > Strangely, this did not get into the last merge

Re: build broken on ppc linux?!

On Fri, Nov 22, 2013 at 07:21:07PM +0100, Arnaud Charlet wrote: > > This is exactly the patch referenced in the pointer to the upstream repo. > > Arno, does this fix the build for you? > > Well now I encounter: > > /users/charlet/fsf/trunk/libsanitizer/sanitizer_common/sanitizer_linux.cc: In > f

Re: one idea for next GSoC: libstdc++ locale support based on POSIX 2008 duplocale/uselocale, etc.

On Sun, Nov 24, 2013 at 11:52:49PM +0100, Václav Zeman wrote: > Here is one idea for GSoC: Implement C++ locale support in libstdc++ > based on POSIX 2008 uselocale()/duplocale() facilities. Doesn't glibc do that since 2002? Jakub

Re: one idea for next GSoC: libstdc++ locale support based on POSIX 2008 duplocale/uselocale, etc.

On Mon, Nov 25, 2013 at 04:24:35PM +0100, Václav Zeman wrote: > >> What I am proposing is that somebody takes the pure POSIX 2008 API and > >> implements `std::locale` on top of that. > > > > This would be helpful for non-GNU platforms, but would not add any > > functionality for glibc-based target

Re: C++ std headers and malloc, realloc poisoning

On Wed, Dec 04, 2013 at 03:57:43PM -0500, Jason Merrill wrote: > On 12/04/2013 03:21 PM, Oleg Endo wrote: > >Some days ago I've tried building an SH cross-GCC on OSX 10.9 with the > >latest XCode (clang) tools and its libc++ std lib. Some of the libc++ > >headers use malloc, realloc etc, which are

Libbacktrace backtrace_vector_finish

Hi! I'm trying to understand how the backtrace_vector_* APIs are meant to work and used, but at least for alloc.c don't see how it can work properly: Both backtrace_vector_grow and backtrace_vector_release use base = realloc (vec->base, alc); or vec->base = realloc (vec->base, vec->size);

Re: C++ std headers and malloc, realloc poisoning

On Thu, Dec 05, 2013 at 12:05:23PM -0500, Jason Merrill wrote: > On 12/05/2013 10:59 AM, Oleg Endo wrote: > >On Thu, 2013-12-05 at 10:45 -0500, Jason Merrill wrote: > >>A simple workaround would be to disable poisoning of malloc/realloc on > >>OS X (or when the build machine uses libc++, if that's

Re: x86 gcc lacks simple optimization

On Fri, Dec 06, 2013 at 12:30:54PM +0400, Konstantin Vladimirov wrote: > Consider code: > > int foo(char *t, char *v, int w) > { > int i; > > for (i = 1; i != w; ++i) > { > int x = i << 2; > v[x + 4] = t[x + 4]; > } > > return 0; > } This is either job of ivopts pass, dunno why it doesn't consi

Re: 3 libstdc++ tests fail at random

On Sat, Dec 07, 2013 at 05:43:12PM +0100, Paolo Carlini wrote: > On 12/07/2013 04:48 PM, H.J. Lu wrote: > >I have been seeing 3 libstdc++ tests: > > > >FAIL: 17_intro/headers/c++200x/stdc+ > >+.cc (test for excess errors) > >FAIL: 17_intro/headers/c++200x/stdc++_multiple_inclusion.cc (test for > >e

Re: break in statement expression in while condition fails to compile

On Wed, Dec 11, 2013 at 07:13:47PM +0530, Prathamesh Kulkarni wrote: > >From the bug-report (comment 4): > Here is what the c++ standard says : > "The break statement shall occur only in an iteration-statement or a switch > statement and causes termination of the smallest enclosing iteration-statem

Re: libsanitizer builds slowly

On Mon, Dec 16, 2013 at 12:04:09PM -0800, Mike Stump wrote: > I've been doing make -j70 and -j70 restrap and libasan seems to build 1 file > at a time. That is certainly not the case, look more carefully and you'll note that it will start compiling tons of sources at once, the problem is just tha

Re: libsanitizer builds slowly

On Tue, Dec 17, 2013 at 08:45:13AM +0400, Konstantin Serebryany wrote: > Indeed, the compile time is dominated by asan_interceptors.cc: > % touch ~/llvm/projects/compiler-rt/lib/asan/asan_interceptors.cc > % date; ninja libclang_rt.asan-x86_64.a libclang_rt.asan-i386.a ; date > Tue Dec 17 08:39:38

<    6   7   8   9   10   11   12   13   14   15   >