On Wed, Sep 17, 2014 at 09:08:44PM +0400, Yury Gribov wrote:
[ Use a proper mime type and target-disposition inline, as contribute.html
tells you. Or use a saner email client; since you're using git, try git
send-email perhaps? Thanks. ]
> index f7c7e38..ee2321f 100644
> --- a/Makefile.tpl
> ++
On Thu, 18 Sep 2014, Janne Blomqvist wrote:
> On Thu, Sep 18, 2014 at 12:57 AM, Hans-Peter Nilsson
> wrote:
> > 'k so we'll track the regressions in a PR.
>
> Do you prefer to tack on to 62768 or a new PR?
Hijacking 62768 for the purposes of reporting a regression for
its fix would not be proper
I've written documentation for the JIT API, in the form of a tutorial
together with a more in-depth set of topic guides.
I greatly prefer to use Sphinx over Texinfo, both for the ease of
editing, and the quality of the generated HTML; I already use it for
both the Python bindings to libgccjit, and
Am 17.09.2014 um 15:14 schrieb Matthias Klose:
> Am 17.09.2014 um 00:03 schrieb James Greenhalgh:
>> If you have any other suggestions, or if "=&r" is actually correct and
>> I am misreading the documentation please let me know.
>
> with this patch I see a lot of ICEs in the testsuite for test cas
On Thu, Sep 18, 2014 at 12:57 AM, Hans-Peter Nilsson wrote:
> On Thu, 18 Sep 2014, Janne Blomqvist wrote:
>> On Wed, Sep 17, 2014 at 11:36 PM, Hans-Peter Nilsson
>> wrote:
>> > On the other hand, the tree *is* broken for some ports; I'd
>> > prefer regressions to that. So, unless you're onto th
On 09/17/14 09:10, Joel Sherrill wrote:
Is there anyone else from GCC who needs to approve this?
I think you're OK is all we need here.
As RTEMS maintainer for GCC, I am ok with it.
Then it's good to go :-)
Thanks,
jeff
On Thu, 18 Sep 2014, Janne Blomqvist wrote:
> On Wed, Sep 17, 2014 at 11:36 PM, Hans-Peter Nilsson
> wrote:
> > On the other hand, the tree *is* broken for some ports; I'd
> > prefer regressions to that. So, unless you're onto this, how do
> > you feel about me committing the posted patch and op
On Wed, Sep 17, 2014 at 11:36 PM, Hans-Peter Nilsson wrote:
> On Wed, 17 Sep 2014, Hans-Peter Nilsson wrote:
>> On Wed, 17 Sep 2014, Hans-Peter Nilsson wrote:
>> > On Wed, 17 Sep 2014, Janne Blomqvist wrote:
>> > > Oops, I forgot to update some parts in an #ifdef branch that isn't
>> > > taken on
On Wed, 17 Sep 2014, Marek Polacek wrote:
> Sure, updated.
>
> Bootstrap in progress, regtested on x86_64-linux, ok for trunk?
>
> 2014-09-17 Marek Polacek
>
> PR c/61854
> libcpp/
> * init.c (struct lang_flags): Remove cplusplus_comments.
> (cpp_set_lang): Likewise.
>
On 09/17/2014 02:02 PM, Jason Merrill wrote:
On 09/17/2014 11:40 AM, Jakub Jelinek wrote:
And for the last one, should we before dynamic_cast verify the object
passed to dynamic_cast has the expected vptr?
Perhaps we should just add checking to the dynamic_cast code. I'm not
sure if that wou
On Wed, 17 Sep 2014, Hans-Peter Nilsson wrote:
> On Wed, 17 Sep 2014, Hans-Peter Nilsson wrote:
> > On Wed, 17 Sep 2014, Janne Blomqvist wrote:
> > > Oops, I forgot to update some parts in an #ifdef branch that isn't
> > > taken on my target. I'll try to find time to fix it later tonight. If
> > >
On 09/11/2014 01:41 PM, Richard Biener wrote:
On Thu, Sep 11, 2014 at 12:12 PM, Bernd Schmidt wrote:
This one isn't a wrong-code issue, just a missed optimization. The strlen
optimizations need to be made to look through ADDR_SPACE_CONVERT_EXPR to
work on ptx.
Bootstrapped and tested together
I've committed this patch, last in my current series. It teaches the gcov
machinery about shared objects that are also built with coverage information.
The basic idea is to chain gcov_root structures together onto a single global
chain -- checking the GCOV_VERSION number so that only compatible
Hi,
I got an ICE while building libstdc++ of a cross compiler x86 to aarch64. I
have a testcase that ICEs on current GCC trunk. I was trying to painfully
reduce it with creduce, and it is still several thousand lines of c++.
Frustrated
that it does not reduce anymore, I decided to have a look w
The i386 sfp-machine.h defines FP_TRAPPING_EXCEPTIONS in a way that is
always wrong: it treats a set bit as indicating the exception is
trapping, when actually a set bit (both for 387 and SSE floating
point) indicates it is masked, and a clear bit indicates it is
trapping. This patch fixes this bu
On Sep 17, 2014, at 12:16 PM, Jakub Jelinek wrote:
> On Wed, Sep 17, 2014 at 12:13:51PM -0700, Mike Stump wrote:
>> On Sep 17, 2014, at 11:25 AM, Jakub Jelinek wrote:
>>> - if mkdir $GCC_RUNTEST_PARALLELIZE_DIR/$par_count; then
>>> + if mkdir $GCC_RUNTEST_PARALLELIZE_DIR/$
On Wed, Sep 17, 2014 at 12:13:51PM -0700, Mike Stump wrote:
> On Sep 17, 2014, at 11:25 AM, Jakub Jelinek wrote:
> > - if mkdir $GCC_RUNTEST_PARALLELIZE_DIR/$par_count; then
> > + if mkdir $GCC_RUNTEST_PARALLELIZE_DIR/$par_count 2>/dev/null;
> > then
>
> So, I can’t help
On Tue, Sep 16, 2014 at 10:32:51PM +, Joseph S. Myers wrote:
> This is getting closer, but it looks like you still treat it as a line
> comment when being skipped for C90, when actually it's not safe to treat
> it like that; you have to produce a '/' preprocessing token and continue
> tokeni
On Sep 17, 2014, at 11:25 AM, Jakub Jelinek wrote:
> - if mkdir $GCC_RUNTEST_PARALLELIZE_DIR/$par_count; then
> + if mkdir $GCC_RUNTEST_PARALLELIZE_DIR/$par_count 2>/dev/null;
> then
So, I can’t help but think we should just do a mkdir -p for this and be done
with it
On Wed, Sep 17, 2014 at 8:35 PM, Ilya Enkovich wrote:
> On 16 Sep 12:22, Uros Bizjak wrote:
>> On Tue, Sep 16, 2014 at 11:37 AM, Ilya Enkovich
>> wrote:
>> > 2014-09-16 13:08 GMT+04:00 Uros Bizjak :
>> >>
>> >> Can x86_64_immediate_operand predicate be used here?
>> >
>> > I think it cannot be u
On 16 Sep 12:22, Uros Bizjak wrote:
> On Tue, Sep 16, 2014 at 11:37 AM, Ilya Enkovich
> wrote:
> > 2014-09-16 13:08 GMT+04:00 Uros Bizjak :
> >>
> >> Can x86_64_immediate_operand predicate be used here?
> >
> > I think it cannot be used because of TLS symbols not counting as immediate.
>
> OK, p
On Wed, 17 Sep 2014, Hans-Peter Nilsson wrote:
> On Wed, 17 Sep 2014, Janne Blomqvist wrote:
> > Oops, I forgot to update some parts in an #ifdef branch that isn't
> > taken on my target. I'll try to find time to fix it later tonight. If
> > you're in a hurry, just replace
> >
> > fstrcpy (iqp->nam
Hi!
I've committed following fix as obvious, to avoid thousands of
mkdir: cannot create directory
`/usr/src/gcc/obj084/gcc/testsuite/ada/acats-parallel/10': File exists
lines in output when checking acats in parallel.
2014-09-17 Jakub Jelinek
On September 17, 2014 8:20:41 PM CEST, Jakub Jelinek wrote:
>Hi!
>
>The following testcase fails on 4.9 branch (shows
>undesirable difference in *.optimized dump on the trunk, but
>doesn't report -fcompare-debug failure there, and in 4.8 is latent).
>The problem is that if we have a noreturn stmt
Hi!
The following testcase fails on 4.9 branch (shows
undesirable difference in *.optimized dump on the trunk, but
doesn't report -fcompare-debug failure there, and in 4.8 is latent).
The problem is that if we have a noreturn stmt followed by only
debug stmt, fixup_noreturn_call will try to split_
On Wed, Sep 17, 2014 at 6:31 PM, Ilya Enkovich wrote:
>> >> I don't like the way arguments are prepared. For the case above,
>> >> bnd_ldx should have index_register_operand predicate in its pattern,
>> >> and this predicate (and its mode) should be checked in the expander
>> >> code. There are m
On 09/17/2014 11:40 AM, Jakub Jelinek wrote:
build_base_path seems to be used in lots of places though, apparently
including member access, etc. The ubsan library right now has just these
const char *TypeCheckKinds[] = {
"load of", "store to", "reference binding to", "member access withi
Hi,
this patch renames types reported by Wodr during LTO bootstrap.
Bootrapping/regtesting in progress, OK if it passes?
Honza
* tree-ssa-ccp.c (prop_value_d): Rename to ...
(ccp_prop_value_t): ... this one to avoid ODR violation; update uses.
* ipa-prop.c (struct type_ch
Applied, thanks.
Jason
The test in pr62128 is exactly TEST 22 from
gcc.dg/torture/vshuf-v32qi.c. It will check if the pattern is correct
or not.
Resubmitting patch looks good as current mail thread is already too complicated.
On Wed, Sep 17, 2014 at 6:49 PM, H.J. Lu wrote:
> On Wed, Sep 17, 2014 at 6:01 AM, Evgeny Stup
On 09/16/2014 08:38 PM, Yury Gribov wrote:
Hi all,
This is the third version of the patch. A list of changes since last
version:
* move config to contrib so that it's _not_ enabled by default (current
score is 2/1 in favor of no Vim config by default)
* update Makefile.in to make .local.vimrc if
This patch is an intermediate step of what I want to do to improve power8
fusion.
In the current trunk, the fusion support for gpr loads is done by a peephole2
to find the addis followed by the load instruction where the only consumer of
the addis instruction is the load, and it rewrites the addis
On 17 Sep 11:42, Uros Bizjak wrote:
> On Wed, Sep 17, 2014 at 10:11 AM, Ilya Enkovich
> wrote:
> > On 16 Sep 12:02, Uros Bizjak wrote:
> >>
> >> Hm, can this patch be compiled as part of the series? The expanders
> >> refer to various gen_bnd patterns that I don't see. Also, I don't see
> >> BND
> Well, so why does
Yo're right. It's actually not supported. I'll use the method you
suggested earlier.
-Andi
Hi,
this patch fixes some issues with ODR type comparsions I noticed while looking
into different applications. There are some additional warnings output now
instead of ICE because comparsions is done recursively when given ODR type is
known
to have violation in it.
More informative warnings are
On Wed, 17 Sep 2014, Kito Cheng wrote:
> Updated patch
OK except for the changes to target-def.h and target-hooks-macros.h.
(Those aren't exactly normal headers that could reasonably be included
more than once in a source file; they have dependencies on where they get
included and what's defi
On Wed, 17 Sep 2014, Janne Blomqvist wrote:
> > /tmp/hpautotest-gcc1/gcc/libgfortran/io/inquire.c:97:41: error: 'gfc_unit'
> > has no member named 'file'
> > fstrcpy (iqp->name, iqp->name_len, u->file, u->file_len);
> > ^
> > /tmp/hpautotest-gcc1/gcc/l
On Wed, 17 Sep 2014, Alan Lawrence wrote:
> We've just noticed this patch causes an ICE in
> gcc.c-torture/execute/scal-to-vec1.c at -O3 when running with -fPIC on
> arm-none-linux-gnueabi and arm-none-linux-gnueabihf; test logs:
Which part causes the ICE? The arm_hard_regno_mode_ok change relat
Il 17/09/2014 16:09, Jakub Jelinek ha scritto:
>> > Is the offloading compiler built together with GCC or previously? If
>> > the latter, what's the difference between the offloading compiler and
>> > say gmp? Setting the LD_LIBRARY_PATH would be the responsibility of
>> > whoever builds GCC; it
On 9/17/2014 10:41 AM, Sebastian Huber wrote:
> On 09/17/2014 04:45 PM, Jan-Benedict Glaw wrote:
>> On Wed, 2014-09-17 15:37:32 +0200, Sebastian
>> Huber wrote:
contrib/ChangeLog
2014-09-17 Sebastian Huber
* config-list.mk (LIST): Add arm-rtems.
Add nios2-rtems.
On Wed, Sep 17, 2014 at 05:46:45PM +0200, Andi Kleen wrote:
> On Wed, Sep 17, 2014 at 04:51:33PM +0200, Jakub Jelinek wrote:
> > On Wed, Sep 17, 2014 at 04:39:00PM +0200, Andi Kleen wrote:
> > > Ok, this should fix it:
> > >
> > > I'll commit it as obvious after testing unless there are objections
On Wed, Sep 17, 2014 at 04:51:33PM +0200, Jakub Jelinek wrote:
> On Wed, Sep 17, 2014 at 04:39:00PM +0200, Andi Kleen wrote:
> > Ok, this should fix it:
> >
> > I'll commit it as obvious after testing unless there are objections.
>
> This isn't sufficient.
> If -mfentry isn't compatible with -m32
On 09/17/2014 04:45 PM, Jan-Benedict Glaw wrote:
On Wed, 2014-09-17 15:37:32 +0200, Sebastian
Huber wrote:
>contrib/ChangeLog
>2014-09-17 Sebastian Huber
>
>* config-list.mk (LIST): Add arm-rtems.
>Add nios2-rtems. Remove extra option from powerpc-rtems.
What's the rationale for rem
On Wed, Sep 17, 2014 at 10:27:02AM -0400, Jason Merrill wrote:
> On 09/16/2014 10:56 AM, Jakub Jelinek wrote:
> >vptr-5.C is one Jason mailed me yesterday, clang++ doesn't instrument this
> >and g++ right now doesn't either, build_static_cast_1 certainly isn't called
> >in that case, and I must say
Hi,
clang recently, in 3.5.0 if I remember correctly, stopped
-Wnon-virtual-dtor warning for final classes. I think it makes sense to
do the same.
Tested x86_64-linux.
Thanks,
Paolo.
7
/cp
2014-09-17 Paolo Carlini
PR c++/62232
* class.c (finish_struct
Is there anyone else from GCC who needs to approve this?
As RTEMS maintainer for GCC, I am ok with it.
--joel
On 9/17/2014 8:37 AM, Sebastian Huber wrote:
> contrib/ChangeLog
> 2014-09-17 Sebastian Huber
>
> * config-list.mk (LIST): Add arm-rtems.
> Add nios2-rtems. Remove extra
On Tue, Sep 16, 2014 at 01:03:50PM +, Joseph S. Myers wrote:
> The point of testsuite additions is to verify the visible changes in
Understood. A long time ago I worked on mil-spec systems..
> > Come to think of it, what if I decline to make any testsuite
> > additions?
>
> Then the patch
Thanks for the ping.
I updated the date on the ChangeLog and committed this.
--joel
On 9/17/2014 8:26 AM, Sebastian Huber wrote:
Ping^2.
On 02/05/14 10:46, Sebastian Huber wrote:
Ping.
On 2014-04-18 12:11, Sebastian Huber wrote:
From: Sebastian Huber
The command line to build a GCC for
On Wed, Sep 17, 2014 at 04:39:00PM +0200, Andi Kleen wrote:
> Ok, this should fix it:
>
> I'll commit it as obvious after testing unless there are objections.
This isn't sufficient.
If -mfentry isn't compatible with -m32 -fpic, supposedly you need
something like (untested):
/* { dg-do compile { t
> On Sep 17, 2014, at 7:43 AM, James Greenhalgh
> wrote:
>
>
>> On Wed, Sep 17, 2014 at 09:30:31AM +0100, Richard Earnshaw wrote:
>> "=&r" is correct for an early-clobbered scratch.
>>
>> R.
>
> In that case...
>
> How is the attached patch for trunk? I've bootstrapped it on AArch64
> with
On Wed, Sep 17, 2014 at 6:01 AM, Evgeny Stupachenko wrote:
> It fix "gcc.target/i386/pr52252-atom.c" in core-avx2 make check and pr62128.
>
I suggest you resubmit the patch as a bug fix for pr62128 with
testcases from pr62128 as well as gcc.target/i386/pr52252-atom.c.
--
H.J.
On Wed, 2014-09-17 15:37:32 +0200, Sebastian Huber
wrote:
> contrib/ChangeLog
> 2014-09-17 Sebastian Huber
>
> * config-list.mk (LIST): Add arm-rtems.
> Add nios2-rtems. Remove extra option from powerpc-rtems.
What's the rationale for removing --enable-threads=yes here, as well
On Wed, Sep 17, 2014 at 09:30:31AM +0100, Richard Earnshaw wrote:
> "=&r" is correct for an early-clobbered scratch.
>
> R.
In that case...
How is the attached patch for trunk? I've bootstrapped it on AArch64
with -fstack-protector-strong and -frename-registers in the BOOT_CFLAGS
without seeing
On Wed, Sep 17, 2014 at 04:32:21PM +0200, Andi Kleen wrote:
> On Wed, Sep 17, 2014 at 03:42:37PM +0200, Dominique Dhumieres wrote:
> >
> > On darwin I get
> >
> > FAIL: gcc.target/i386/fentry-override.c (test for excess errors)
> > UNRESOLVED: gcc.target/i386/fentry-override.c scan-assembler-not
Ping for https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00206.html
Adding a few maintainers in copy... Thanks in advance!
--
Pierre-Marie de Rodat
On Wed, Sep 17, 2014 at 03:42:37PM +0200, Dominique Dhumieres wrote:
>
> On darwin I get
>
> FAIL: gcc.target/i386/fentry-override.c (test for excess errors)
> UNRESOLVED: gcc.target/i386/fentry-override.c scan-assembler-not __fentry__
> FAIL: gcc.target/i386/fentry.c (test for excess errors)
> U
On 09/16/2014 10:56 AM, Jakub Jelinek wrote:
vptr-5.C is one Jason mailed me yesterday, clang++ doesn't instrument this
and g++ right now doesn't either, build_static_cast_1 certainly isn't called
in that case, and I must say I have no idea what should be checked there,
where etc.
What needs to
On Wed, Sep 17, 2014 at 04:04:25PM +0200, Paolo Bonzini wrote:
> Il 17/09/2014 15:31, Jakub Jelinek ha scritto:
> > It seems building of the host compiler requires the offloading compiler
> > to be installed directly in the prefix, which is something really
> > undesirable e.g. for distro builds wh
On Sun, 14 Sep 2014 17:07:05 +0200, Manuel López-Ibáñez wrote:
> What happened with this? I don't see any libcc1 in the gcc repository
> and this patch was never committed.
It was discussed internally and the patches are going to be updated, rebased
and later checked in.
Thanks,
Jan
On 09/17/2014 01:49 AM, Jakub Jelinek wrote:
> On Wed, Sep 17, 2014 at 10:44:12AM +0200, Tobias Burnus wrote:
>> Cesar Philippidis wrote:
>>> The patch introduces the following OpenACC/PTX-specific built-ins:
>> ...
>>
>> It is not completely clear how they are supposed to get used. Should the
>> u
Sure. If you have the localrc thing installed, anyone who can write
files
you can read can make your vim do *anything* (and I mean *anything*).
I thought that modern versions of localrc run .local.vimrc scripts in a
sandbox?
Ok, looks like Markus Braun's
http://www.vim.org/scripts/script.php
On Wed, Jul 2, 2014 at 2:58 PM, Marcos Díaz
wrote:
> On Tue, Jul 1, 2014 at 6:34 PM, Daniel Gutson
> wrote:
>> On Tue, Jul 1, 2014 at 2:25 PM, Jeff Law wrote:
>>> On 03/19/14 08:06, Marcos Díaz wrote:
Well, finally I have the assignment, could you please review this patch?
>>>
>>> Than
On 09/17/2014 05:01 PM, Segher Boessenkool wrote:
You can make Vim automatically adapt settings, but you cannot make the Vim
user adapt to that.
How about making Vim user adapt to GNU coding style though?
Not that I want to start flame again.
Sure. If you have the localrc thing installed, an
Il 17/09/2014 15:31, Jakub Jelinek ha scritto:
> It seems building of the host compiler requires the offloading compiler
> to be installed directly in the prefix, which is something really
> undesirable e.g. for distro builds where things are installed with
> non-empty $(DESTDIR).
Is the offloadin
On Mon, Sep 15, 2014 at 08:52:27PM +0400, Ilya Verbin wrote:
> This patch contains necessary changes for the build system to support
> offloading.
> It adds 2 new options for configure:
> * --enable-as-accelerator-for=ARG is intended for the offload target compiler.
> * --enable-offload-targets=LI
On darwin I get
FAIL: gcc.target/i386/fentry-override.c (test for excess errors)
UNRESOLVED: gcc.target/i386/fentry-override.c scan-assembler-not __fentry__
FAIL: gcc.target/i386/fentry.c (test for excess errors)
UNRESOLVED: gcc.target/i386/fentry.c scan-assembler __fentry__
with -m32. The error
contrib/ChangeLog
2014-09-17 Sebastian Huber
* config-list.mk (LIST): Add arm-rtems.
Add nios2-rtems. Remove extra option from powerpc-rtems.
---
contrib/config-list.mk | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/contrib/config-list.mk b/contrib/c
Hi!
It seems building of the host compiler requires the offloading compiler
to be installed directly in the prefix, which is something really
undesirable e.g. for distro builds where things are installed with
non-empty $(DESTDIR).
Right now it seems that for building all that is needed is
main_tar
Ping^2.
On 02/05/14 10:46, Sebastian Huber wrote:
Ping.
On 2014-04-18 12:11, Sebastian Huber wrote:
From: Sebastian Huber
The command line to build a GCC for RTEMS contained virtually always a
'--enable-threads'. This patch helps to avoid this extra configuration
command line parameter and
Updated patch
On Wed, Sep 17, 2014 at 9:17 PM, Kito Cheng wrote:
> Updated patch
>
> On Mon, Sep 8, 2014 at 9:46 PM, Kito Cheng wrote:
>>
>> ping!
>>
>> On Tue, Sep 2, 2014 at 12:37 AM, Kito Cheng wrote:
>> > Hi Joseph:
>> >
>> > Thanks for your review, I've reverted the part of gsyslimits.h,
>
Am 17.09.2014 um 00:03 schrieb James Greenhalgh:
> If you have any other suggestions, or if "=&r" is actually correct and
> I am misreading the documentation please let me know.
with this patch I see a lot of ICEs in the testsuite for test cases built with
-O3 (and a build defaulting to -fstack-pr
On Wed, Sep 17, 2014 at 3:42 PM, Jakub Jelinek wrote:
> I don't like the == in there. Doesn't , being a target triplet
> or something like that, always have to start with alphanumeric character,
> and options always have to start with -? Thus, can't you decide from the
> first character after -f
On Tue, Sep 16, 2014 at 05:58:58PM -0400, Trevor Saunders wrote:
> fwiw, I think enabling it by default especially when that really means
> enable it if you've enabled the localrc plugin makes sense.
Enabling it by default means enabling it for all users. That is a really
really bad plan; many of
It fix "gcc.target/i386/pr52252-atom.c" in core-avx2 make check and pr62128.
On Tue, Sep 16, 2014 at 6:51 PM, H.J. Lu wrote:
> On Tue, Sep 16, 2014 at 6:15 AM, Evgeny Stupachenko
> wrote:
>> PING 2
>>
>> On Mon, Sep 8, 2014 at 2:03 PM, Evgeny Stupachenko
>> wrote:
>>> PING
>>>
>>> On Wed, Aug
On Sep 17, 2014, at 12:55 , Kai Tietz wrote:
>> We probably could twist our configuration scripts to experiment the -w64-
>> variant as well. Might take a bit of time though.
>
> Well, would be interesting.
Yes, I agree. I'll open an internal discussion to pursue this track.
> As you are u
We've just noticed this patch causes an ICE in
gcc.c-torture/execute/scal-to-vec1.c at -O3 when running with -fPIC on
arm-none-linux-gnueabi and arm-none-linux-gnueabihf; test logs:
spawn /tmp/alan/buildarm-none-linux-gnueabi/obj/gcc4/gcc/xgcc -B/tmp/alan/builda
rm-none-linux-gnueabi/obj/gcc4/g
The following fixes PR63152 zeroing the data field only for allocatables, not
pointers. The benefit of the patch is a small speedup, and it avoids that code
starts to rely on behavior that is undefined in the standard. With this patch,
something like
INTEGER, DIMENSION(:), POINTER :: foo
IF (AS
On Wed, Sep 17, 2014 at 03:16:52PM +0400, Andrey Turetskiy wrote:
> Hi,
> This patch (attached) contains the prototype of mechanism for passing
> options to offload target compiler.
> If one need to pass additional options for target compiler, one may
> add option ‘–ftarget-options==’ to host
> com
On Wed, Sep 17, 2014 at 2:22 PM, Hans-Peter Nilsson wrote:
> On Wed, 17 Sep 2014, Janne Blomqvist wrote:
>> On Tue, Sep 16, 2014 at 11:17 AM, FX wrote:
>> >>> 2014-09-05 Janne Blomqvist
>> >>>
>> >>>PR libfortran/62768
>> >>>* io/io.h (gfc_unit): Store C string for the filename.
>> >>>
On Wed, 17 Sep 2014, Janne Blomqvist wrote:
> On Tue, Sep 16, 2014 at 11:17 AM, FX wrote:
> >>> 2014-09-05 Janne Blomqvist
> >>>
> >>>PR libfortran/62768
> >>>* io/io.h (gfc_unit): Store C string for the filename.
> >>>* io/close.c (st_close): Use gfc_unit.filename.
> >>>* io/in
On 09/17/2014 01:16 PM, Andrey Turetskiy wrote:
How does this look? Do you agree with the approach?
I have no objections to supporting a -ftarget-options switch. I had
posted a patch a while ago that looked somewhat similar, but also
contained an automatic translation step from things like -
Hi,
This patch (attached) contains the prototype of mechanism for passing
options to offload target compiler.
If one need to pass additional options for target compiler, one may
add option ‘–ftarget-options==’ to host
compiler (target name can be skipped, that will append specified
options for ever
On 15/09/14 14:29, Richard Earnshaw wrote:
Yep, that's fine.
Committed, thanks.
Andrew
2014-09-17 12:38 GMT+02:00 Olivier Hainque :
> Hello Kai,
>
> On Sep 17, 2014, at 10:52 , Kai Tietz wrote:
>
>> Sorry for the delay in review.
>
> No problem at all. Thanks for your feedback :)
>
>> Patch looks ok. Have you just tested
>> -pc- variant, or also -w64- one?
>
> Just the -pc- vari
On 9 September 2014 13:08, Christophe Lyon wrote:
> On 9 September 2014 12:03, wrote:
>>
>>
>>> On Sep 9, 2014, at 2:50 AM, Marcus Shawcroft
>>> wrote:
>>>
>>> +static unsigned HOST_WIDE_INT
>>> +aarch64_asan_shadow_offset (void)
>>> +{
>>> + return (HOST_WIDE_INT_1 << 36);
>>> +}
>>> +
>>>
>
Hello Kai,
On Sep 17, 2014, at 10:52 , Kai Tietz wrote:
> Sorry for the delay in review.
No problem at all. Thanks for your feedback :)
> Patch looks ok. Have you just tested
> -pc- variant, or also -w64- one?
Just the -pc- variant, by our nightly builders.
We probably could twist our c
2014-09-17 13:46 GMT+04:00 Uros Bizjak :
> On Wed, Sep 17, 2014 at 10:17 AM, Ilya Enkovich
> wrote:
>
>>> >>>This patch introduces Intel MPX bound registers and instructions. It
>>> >>>was approved earlier for 4.9 and had no significant changes since then.
>>> >>>I'll assume patch is OK if no
On Wed, Sep 17, 2014 at 10:17 AM, Ilya Enkovich wrote:
>> >>>This patch introduces Intel MPX bound registers and instructions. It was
>> >>>approved earlier for 4.9 and had no significant changes since then. I'll
>> >>>assume patch is OK if no objections arise.
>> >>>
>> >>>Patch was bootstra
On Wed, Sep 17, 2014 at 10:11 AM, Ilya Enkovich wrote:
> On 16 Sep 12:02, Uros Bizjak wrote:
>>
>> Hm, can this patch be compiled as part of the series? The expanders
>> refer to various gen_bnd patterns that I don't see. Also, I don't see
>> BND mode introduced.
>
> Hi,
>
> Here is a patch from t
On Wed, Sep 17, 2014 at 05:18:27PM +0800, Zhenqiang Chen wrote:
> Hi,
>
> When assign_hard_reg, we always check_hard_reg_p, which has code
>
> if (! TEST_HARD_REG_BIT (profitable_regs, hard_regno))
> return false;
>
> i.e. If a hard_regno is not in profitable_regs, we can not allocate it to
>
Hello Joseph,
On Sep 16, 2014, at 23:01 , Joseph S. Myers wrote:
> config.sub patches have to go to config-patches first, we only ever import
> the latest unmodified config.sub and config.guess from config.git, without
> making local changes.
Ok, will start there then. Thanks for your prompt
Hi,
When assign_hard_reg, we always check_hard_reg_p, which has code
if (! TEST_HARD_REG_BIT (profitable_regs, hard_regno))
return false;
i.e. If a hard_regno is not in profitable_regs, we can not allocate it to
the ira_allocno_t A.
So the conflict on a hard_regno, which does not belong to th
Hello Oliver,
Sorry for the delay in review. Patch looks ok. Have you just tested
-pc- variant, or also -w64- one?
Thanks,
Kai
On Wed, Sep 17, 2014 at 10:44:12AM +0200, Tobias Burnus wrote:
> Cesar Philippidis wrote:
> > The patch introduces the following OpenACC/PTX-specific built-ins:
> ...
>
> It is not completely clear how they are supposed to get used. Should the
> user call them directly in some cases? Or are they o
Hi,
Cesar Philippidis wrote:
> The patch introduces the following OpenACC/PTX-specific built-ins:
...
It is not completely clear how they are supposed to get used. Should the
user call them directly in some cases? Or are they only used internally?
acc_on_device sounds like a function which would
On 16/09/14 23:03, James Greenhalgh wrote:
> On Tue, Sep 16, 2014 at 10:36:08PM +0100, Andrew Pinski wrote:
>> On Thu, Sep 4, 2014 at 1:18 AM, James Greenhalgh
>> wrote:
>>> On Thu, Sep 04, 2014 at 08:42:31AM +0100, Venkataramanan Kumar wrote:
Hi maintainers,
I just added "=r" and r
On 19 May 11:23, Jeff Law wrote:
> On 05/19/14 02:19, Ilya Enkovich wrote:
> >On 16 May 13:39, Jeff Law wrote:
> >>On 04/16/14 05:35, Ilya Enkovich wrote:
> >>>Hi,
> >>>
> >>>This patch introduces Intel MPX bound registers and instructions. It was
> >>>approved earlier for 4.9 and had no signific
On 16 Sep 12:02, Uros Bizjak wrote:
>
> Hm, can this patch be compiled as part of the series? The expanders
> refer to various gen_bnd patterns that I don't see. Also, I don't see
> BND mode introduced.
Hi,
Here is a patch from the series that introduces modes and instructions:
https://gcc.gnu.
98 matches
Mail list logo
