Hi,
DWZ 0.14 has been released.
You can download dwz from the sourceware FTP server here:
https://sourceware.org/ftp/dwz/releases/
ftp://sourceware.org/pub/dwz/releases/
The vital stats:
Sizemd5sumName
184KiB cf60e4a65d9cc38c7cdb366e9a29ca8e
Richard,
when compiling this testcase:
...
static int __attribute__((noinline, noclone))
foo (int *a, int *b)
{
*b = 1;
*a = 2;
return *b;
}
int __attribute__((noinline, noclone))
bar (int *a, int *b)
{
return foo (a, b);
}
...
with -O2 -fipa-pta we find in the pta dumpfile:
...
Generat
On 28/10/15 12:10, Richard Biener wrote:
On Wed, 28 Oct 2015, Tom de Vries wrote:
Richard,
when compiling this testcase:
...
static int __attribute__((noinline, noclone))
foo (int *a, int *b)
{
*b = 1;
*a = 2;
return *b;
}
int __attribute__((noinline, noclone))
bar (int *a, int *b
On 12/01/16 17:10, Jakub Jelinek wrote:
Hi!
What is the reason for these notes?
From https://gcc.gnu.org/ml/gcc-patches/2013-03/msg01316.html:
...
Using the reg-note we are able to easily link call_insns to their
corresponding declaration, even after the calls may have been split into
an ins
[ cc-ing gcc ml ]
On 12/04/16 11:22, Kumar, Venkataramanan wrote:
Hi,
I am trying to build gcc with graphite enabled both on trunk and the
graphite branch.
I don't know anything about the graphite branch.
Should I need to build and install cloog , ISL PPL etc?
Trunk needs ISL.
Is ther
Denis,
when building gcc for avr with --enable-checking=yes,rtl , I run into the
following error:
...
/home/vries/gcc_versions/devel/src/libgcc/unwind-c.c: In function
‘__gcc_personality_sj0’:
/home/vries/gcc_versions/devel/src/libgcc/unwind-c.c:234:1: internal compiler
error: RTL check: expe
On 21/03/14 17:30, Thomas Schwinge wrote:
> Hi!
>
> Certain GIMPLE codes, such as OpenMP ones, have a structured block
> attached to them, for exmaple, gcc/gimple.def:GIMPLE_OMP_PARALLEL:
>
> /* GIMPLE_OMP_PARALLEL represents
>
>#pragma omp parallel [CLAUSES]
>BODY
>
Vladimir,
There are a few patterns which use both the read/write constraint modifier (+)
and the earlyclobber constraint modifier (&):
...
$ grep -c 'match_operand.*+.*&' gcc/config/*/* | grep -v :0
gcc/config/aarch64/aarch64-simd.md:1
gcc/config/arc/arc.md:1
gcc/config/arm/ldmstm.md:30
gcc/con
On 01-07-14 21:58, Marc Glisse wrote:
So my question is: is the combination of '&' and '+' supported ? If so,
what is the exact semantics ? If not, should we warn or give an error ?
I don't think we can define any reasonable semantics for &+. My
recommendation would be for this to be considered
On 02-07-14 08:23, Marc Glisse wrote:
On Tue, 1 Jul 2014, Tom de Vries wrote:
On 01-07-14 21:58, Marc Glisse wrote:
So my question is: is the combination of '&' and '+' supported ? If so,
what is the exact semantics ? If not, should we warn or give an error ?
I don&#
On 02-07-14 09:02, Marc Glisse wrote:
Still, the meaning of +&, in inline asm for instance, seems relatively clear,
no?
I can't find any testsuite examples using this construct.
Furthermore, I'd expect the same semantics and restrictions for constraints in
rtl templates and inline asm.
So
On 02-07-14 11:36, Marc Glisse wrote:
(did you drop the lists on purpose?)
That was a glitch, sorry.
[ Adds list back ]
Thanks,
- Tom
On Wed, 2 Jul 2014, Tom de Vries wrote:
An earlyclobber operand X prevents *other* input operands from using the same
register, but that does not include
[ was: Re: combination of read/write and earlyclobber constraint modifier ]
On 02-07-14 17:52, Jeff Law wrote:
(by the way, in the same aarch64-simd.md file, I noticed some
define_expand with constraints, that looks strange)
It sometimes happens when a define_insn is converted into a define_exp
Jakub,
I've looked into how to implement the openacc kernels directive in gcc.
In order to map the loopnests marked by the kernels directive efficiently on
accelerator hardware, we need parallelization and vectorization.
Focussing on paralellization for the moment, a possibility for paralelli
On 06-08-14 17:10, Tom de Vries wrote:
The place after build_ealias is early enough to be before the lto-stream
write/read. I don't see how we can do this earlier. Before ealias, there's no
alias info, and one of the loops fails to be recognized as parallel.
Furthermore, pass_ch
Hi,
I ran into this non-reproducible failure while testing a non-bootstrap build on
x86_64:
...
PASS: g++.dg/ubsan/align-2.C -Os (test for excess errors)
Setting LD_LIBRARY_PATH to
.:/data/vries/test-fix-fuse-caller-save-s390/with/nobootstrap/build/x86_64-unknown-linux-gnu/./libstdc++-v3/sr
On 18-08-14 14:16, Tom de Vries wrote:
On 06-08-14 17:10, Tom de Vries wrote:
We could insert a pass-group here that only deals with functions that have the
kernels directive, and do the auto-par thing in a pass_oacc_kernels (which
should share the majority of the infrastructure with the
On 09-09-14 12:56, Richard Biener wrote:
On Tue, 9 Sep 2014, Tom de Vries wrote:
On 18-08-14 14:16, Tom de Vries wrote:
On 06-08-14 17:10, Tom de Vries wrote:
We could insert a pass-group here that only deals with functions that have
the
kernels directive, and do the auto-par thing in a
On 22-09-14 10:28, Richard Biener wrote:
On Tue, 16 Sep 2014, Tom de Vries wrote:
On 09-09-14 12:56, Richard Biener wrote:
On Tue, 9 Sep 2014, Tom de Vries wrote:
On 18-08-14 14:16, Tom de Vries wrote:
On 06-08-14 17:10, Tom de Vries wrote:
We could insert a pass-group here that only
Hi,
in this email I'm trying to explain in detail what problem I'm running into with
reductions in oacc kernels region, and how I think it could be solved.
Any advice is welcome.
OVERALL PROBLEM
The overall problem I'm trying to solve is to implement the oacc kernels
directive in gcc, reus
ish in case the prettyprinters.exp file is
unsupported, which AFAIU is also required in that case.
Bootstrapped and reg-tested on x86_64.
OK for trunk/stage3?
Thanks,
- Tom
2014-11-25 Tom de Vries
* testsuite/libstdc++-prettyprinters/prettyprinters.exp: Add missing
dg-finish. Only print unsupport
Hi,
I've been adding an fn spec function attribute to some openacc builtin
functions:
...
diff --git a/gcc/builtin-attrs.def b/gcc/builtin-attrs.def
index 9c05a94..4e34192 100644
--- a/gcc/builtin-attrs.def
+++ b/gcc/builtin-attrs.def
@@ -64,6 +64,7 @@ DEF_ATTR_FOR_INT (6)
DEF_ATTR_TREE_LIST
On 01-12-14 09:43, Jakub Jelinek wrote:
On Mon, Dec 01, 2014 at 09:35:25AM +0100, Tom de Vries wrote:
I've been adding an fn spec function attribute to some openacc builtin
functions:
...
diff --git a/gcc/builtin-attrs.def b/gcc/builtin-attrs.def
index 9c05a94..4e34192 100644
--- a/gcc/bu
Hi Kai,
I encountered a test failure in boehm-gc (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64042 'FAIL: boehm-gc.c/gctest.c
-O2 execution test' ).
I would like to ask somebody to confirm the PR, which hopefully should be as
simple as patching a .exp for iterated running of a single tes
Jakub,
consider attached patch, which adds pass_lim after fre1 (a simplification of my
oacc kernels patch series).
The included testcase lim-before-stdarg.c fails.
The first sign of trouble is in lim-before-stdarg.c.088t.stdarg (attached):
...
gen_rtvec: va_list escapes 0, needs to save 0 GPR
On 29-01-15 18:25, Jakub Jelinek wrote:
The stdarg pass can't grok too heavy optimizations, so if at all possible,
don't schedule such passes early, and if you for some reason do, avoid
optimizing in there the va_list related accesses.
This patch work for the example.
In pass_lim1, I get:
...
On 30-01-15 09:41, Richard Biener wrote:
I don't like adding more hacks to aid the stdarg pass.
It's not required
for GCC 5 anyway and for GCC 6 we should push the lowering change.
Richard,
I agree that that's the best solution (the posted patch is just a solution that
helps me along for now)
On 30-01-15 14:11, Michael Matz wrote:
Hi,
On Fri, 30 Jan 2015, Tom de Vries wrote:
Maybe you want to pick up the work?
In principle yes, depending on the amount of work (at this point I have no
idea what remains to be done and how long that would take me).
Michael, are your patches posted
On 02-02-15 16:47, Michael Matz wrote:
Hi,
On Mon, 2 Feb 2015, Tom de Vries wrote:
I've minimized the vaarg-4a.c failure, and added it as testcase to the patch
series as gcc.target/x86_64/abi/callabi/vaarg-4.c.
The problem is in this code:
...
e = va_arg (argp, char *);
e = v
[ was: Re: pass_stdarg problem when run after pass_lim ]
On 03-02-15 14:36, Michael Matz wrote:
Hi,
On Tue, 3 Feb 2015, Tom de Vries wrote:
Ironically, that fix breaks the va_list_gpr/fpr_size optimization, so
I've disabled that by default for now.
I've done a non-bootstrap and
On 10-02-15 11:10, Richard Biener wrote:
The single failing testcase (both with and without -m32) is
>g++.dg/torture/pr45843.C:
>...
>./gcc/testsuite/g++/g++.sum:FAIL: g++.dg/torture/pr45843.C -O2 -flto
>-fno-use-linker-plugin -flto-partition=none (internal compiler error)
>...
>
>The failure
On 10-02-15 17:57, Michael Matz wrote:
Hi,
On Tue, 10 Feb 2015, Tom de Vries wrote:
I've added two modifications to gimplify_modify_expr:
- the WITH_SIZE_EXPR in which the CALL_TREE is wrapped, is dropped after
gimplification, but we need the size expression at expansion in pass_s
On 10-02-15 14:46, Richard Biener wrote:
This patch is a way to achieve that gimplification doesn't call the actual
>gimplify_expr langhook, and it fixes the failure. But I'm guessing that's
>not the proper way to fix this.
More like
Index: gcc/tree.c
===
On 12-02-15 14:57, Michael Matz wrote:
Hi,
On Wed, 11 Feb 2015, Tom de Vries wrote:
My idea was to not generate temporaries and hence copies for
non-scalar types, but rather construct the "result" of va_arg directly
into the original LHS (that would then also trivially solve the
On 13-02-15 09:57, Richard Biener wrote:
[ We're still expanding ifn_va_arg before the va_list_gpr/fpr_size
>optimization. ]
Yeah, and the point of the exercise was of course to change that;)
Well, there are two parts.
The first is postpone expansion of va_arg to before the va_list_gpr/fpr_si
On 12-02-15 23:51, Tom de Vries wrote:
On 12-02-15 14:57, Michael Matz wrote:
I'm not really sure yet why std_gimplify_va_arg_expr has a part
commented out. Michael, can you comment?
I think I did that because of SSA form. The old sequence calculated
vatmp = valist;
vatmp =
Hi,
the link for 'ACM SIGPLAN Programming Languages Software Award' in the news list
on gcc.gnu.org is http://www.sigplan.org/node/231, as discussed here (
https://gcc.gnu.org/ml/gcc/2014-06/msg00136.html ).
Following the link gives me:
...
Page Not Found
The page you were looking for was no
Thomas,
In ran into this bootstrap failure with branch gomp-4_0-branch:
...
src/gcc-gomp-4_0-branch/gcc/omp-low.c:2897:1: error: 'omp_context*
enclosing_target_ctx(omp_context*)' defined but not used [-Werror=unused-function]
enclosing_target_ctx (omp_context *ctx)
^
cc1plus: all warnings bei
[ To revisit https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00385.html ]
The current formulation for the description of Stage 4 here (
https://gcc.gnu.org/develop.html ) is:
...
During this period, the only (non-documentation) changes that may be
made are changes that fix regressions.
Other change
[ was: Re: [RFC] Update Stage 4 description ]
On 09-01-19 09:47, Richard Biener wrote:
> On Wed, 9 Jan 2019, Tom de Vries wrote:
>
>> [ To revisit https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00385.html ]
>>
>> The current formulation for the description of Stage 4 here
On 05/15/2017 03:55 PM, Martin Liška wrote:
... check_GNU_style.sh script. The script works
quite fine, but it's very unpleasant that it reports problematic lines in the
patch,
not in original patches.
Agreed.
I decided to substitute part of functionality by Python
script that uses a library
On 05/19/2017 11:51 AM, Martin Liška wrote:
Hello.
I'm sending final (slightly updated) version of the script. I'm also adding
Jakub,
because I remember he's got another regex patterns he's using for review
process?
Would it be fine to just remove the old *.sh script, or is it preferred to hav
args, we see:
...
$ ./contrib/check_GNU_style.py
usage: check_GNU_style.py [-h] [-f {stdio,quickfix}] file
check_GNU_style.py: error: the following arguments are required: file
...
OK?
Thanks,
- Tom
check_GNU_style.py: print usage if no file specified
2017-05-22 Tom de Vries
* check_GNU_styl
On 09/22/2017 08:30 PM, David Edelsohn wrote:
I am pleased to announce that the GCC Steering Committee has
appointed Tom de Vries as nvptx maintainer.
Thank you for your trust.
Tom, please update your listing in the MAINTAINERS file.
Committed as attached below.
Happy hacking
Richard,
I'm interested in implementing (some of) the new __atomic builtins using the
xlr/xlp atomic instructions ldadd and swap.
Do you perhaps have work in progress there?
Thanks,
- Tom
Hi,
I just ran into the following gcc build failure during a gcc+glibc build:
...
libtool: compile:
/home/vries/local/glibc-arm/base/obj/gcc-mainline-0-arm-none-linux-gnueabi-i686-pc-linux-gnu/./gcc/xgcc
-shared-libgcc -B/home/vries/local/glibc-arm/base/obj/\
gcc-mainline-0-arm-none-linux-gnueabi-
On 05/01/12 18:40, Jonathan Wakely wrote:
> On 5 January 2012 16:33, Marc Glisse wrote:
>> On Thu, 5 Jan 2012, Joseph S. Myers wrote:
>>
>>> If the final C++11 still requires gets in , despite it being
>>> removed in C11, that's probably also a bug in C++11. (At least the most
>>> recent draft I h
Hi,
In the context of bug 31230, I have a question about the if_marked
construct.
[DOC http://gcc.gnu.org/onlinedocs/gccint/GTY-Options.html]
if_marked ("expression")
Suppose you want some kinds of object to be unique, and so you
put them in a hash table. If garbage collection marks the
On Jun 23, 2010, at 16:49, Ian Lance Taylor wrote:
Tom de Vries writes:
static int prop(const_tree type)
{
return type == A;
}
static int type_hash_marked_p (const void *p) {
const_tree const type = ((const struct type_hash *) p)->type;
return ggc_marked_p (type) || prop (type);
}
On Jun 23, 2010, at 19:40, Ian Lance Taylor wrote:
Basile Starynkevitch writes:
On Wed, 2010-06-23 at 08:56 -0700, Ian Lance Taylor wrote:
Tom de Vries writes:
What I am really trying to do, is a bootstrap debug build of 4.3.5.
However, I ran into bug 31230. I minimized the testcase, did
Interesting. My first reaction is that this is an invalid use of the
garbage collector. I think there is really only one valid function
that can be used as an if_marked function: one which checks
ggc_marked_p on the structure.
Then how about tree_map_base_marked_p, the if_marked functi
Hi,
The tree_map_base_marked_p checks ggc_marked_p on the from field.
During
ggc_scan_cache_tab, if the from field is live, also the to field
is marked
live.
I wrote some code to do sanity testing and found a similar
scenario as
before:
- a register attribute is not marked live during roo
Hi Richard,
I can image a few ways to go from here:
- leave as is, fix this when it really bothers us (risk: exchange
a known
problem for unknown hard-to-debug and/or hard-to-reproduce problems)
- instrument if_marked functions like the one for
value_expr_for_decl to
assert if the from fie
I can image a few ways to go from here:
- leave as is, fix this when it really bothers us (risk:
exchange a known
problem for unknown hard-to-debug and/or hard-to-reproduce
problems)
- instrument if_marked functions like the one for
value_expr_for_decl to
assert if the from field is live
I'm working on improving delay-slot scheduling and would appreciate
advice on a
problem I encountered.
The problem is: how to add support for placing a CODE_LABEL on an
instruction in
a delay slot?
My impression is that this is not supported currently. One way to
implement this
would be to a
Hi Jeff,
However, that doesn't work for the second example:
...
beq$3,$0,$L14
nop
$L7:
andi$2,$2,0x
...
bne$3,$0,$L7
nop
$L14:
andi$2,$2,0x
...
...
What is different from the first example, is that here the beq owns
neither the
fall-throug
Hi all,
I would like to know if the attached patch resource-check.patch is a
good sanity check or not.
I have been working in reorg.c and running into trouble with the target
info cache in mark_target_live_regs, so I decided to write a patch that
checks consistency between cached values and recom
Richard,
I've noticed that f.i. *thumb2_alusi3_short has no explicit setting of the conds
attribute, which means the value of the conds attribute for this insn is nocond:
...
(define_insn "*thumb2_alusi3_short"
[(set (match_operand:SI 0 "s_register_operand" "=l")
(match_operator
as part of
the prologue, and the breakpoint will have the correct line number.
My preference would be to mark it as prologue code, since that's the case for
other uses of arm_load_pic_register.
What is the proper way to fix this?
Thanks,
- Tom
2013-09-15 Tom de Vries
On 03/10/13 17:17, Tom de Vries wrote:
> we need to emit it before the FUNCTION_BEG insn-note
> (rough proof-of-concept patch attached), such that no .loc will be generated
> for
> it.
I investigated further, and now I think it's a regression caused by the fix for
PR47028.
Att
On 04/07/13 14:59, Thomas Schwinge wrote:
> Hi!
>
> On Wed, 3 Jul 2013 09:54:58 -0700, Jason Merrill wrote:
>> On 07/03/2013 02:47 AM, Thomas Schwinge wrote:
>>> OK, that of course works, but from the wiki page I got the idea that it
>>> explicitly was meant to merge these together. So assuming
On 24/10/13 07:05, Andi Kleen wrote:
> Tom de Vries writes:
>> ...
>> Can you translate the last sentence into shell/git command(s)?
>
> It would be far better to just centrally mirror all branches in SVN as
> standard git branches. Then all these problems wouldn'
Hi,
When configuring a gcc build with "--disable-bootstrap --enable-languages=c" I
run into this error:
...
libtool: compile: g++
-B/home/vries/gcc_versions/devel/lean-c/install/x86_64-unknown-linux-gnu/bin/
-B/home/vries/gcc_versions/devel/lean-c/install/x86_64-unknown-linux-gnu/lib/
-isystem
/h
hanks,
>
> Balaji V. Iyer.
>
>> -Original Message-
>> From: Tom de Vries [mailto:tom_devr...@mentor.com]
>> Sent: Monday, November 4, 2013 2:15 PM
>> To: gcc@gcc.gnu.org
>> Cc: Iyer, Balaji V
>> Subject: libcilkrts breaks non-bootstrap build
>>
&
On 05/11/13 05:17, Iyer, Balaji V wrote:
> Is the following patch OK to fix this issue?
>
Balaji,
the patch fixes the problem for me, thanks.
I can't approve your patch, but it looks good to me.
FWIW, I stumbled upon this text at http://gcc.gnu.org/codingconventions.html
which is related to t
On 05/11/13 10:37, Gopalasubramanian, Ganesh wrote:
> My non-bootstrap build fails with the following message
>
> /bin/bash: ./libtool: No such file or directory
> make: *** [cilk-abi-vla.lo] Error 127
>
> I have my libtool installed in /usr/bin.
>
> I configured the build with
> configure --pr
Honza,
in calls.c:expand_call, I see the following code:
...
#ifdef REG_PARM_STACK_SPACE
/* If outgoing reg parm stack space changes, we can not do sibcall. */
|| (OUTGOING_REG_PARM_STACK_SPACE (funtype)
!= OUTGOING_REG_PARM_STACK_SPACE (TREE_TYPE (current_function_decl)))
On 2/4/22 08:21, Thomas Schwinge wrote:
Hi Tom!
Taking this one to the mailing list; not directly related to PR104364:
On 2022-02-03T13:35:55+, "vries at gcc dot gnu.org via Gcc-bugs"
wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104364
I've tested this using (recommended) drive
68 matches
Mail list logo
