On Wed, Jun 24, 2020 at 03:33:28PM +0300, Alexander Popov wrote:
> Don't use gcc plugins for building arch/arm64/kernel/vdso/vgettimeofday.c
> to avoid unneeded instrumentation.
>
> Signed-off-by: Alexander Popov
> ---
> arch/arm64/kernel/vdso/Makefile | 2 +-
> 1
On Wed, Jun 24, 2020 at 03:33:27PM +0300, Alexander Popov wrote:
> Don't use gcc plugins for building arch/arm/vdso/vgettimeofday.c to
> avoid unneeded instrumentation.
>
> Signed-off-by: Alexander Popov
But why is skipping it safe?
Luis
On Wed, Jun 24, 2020 at 03:33:30PM +0300, Alexander Popov wrote:
> Add 'verbose' plugin parameter for stackleak gcc plugin.
> It can be used for printing additional info about the kernel code
> instrumentation.
>
> For using it add the following to scripts/Makefile.gc
On Wed, 24 Jun 2020 15:33:25 +0300, Alexander Popov wrote:
> This is the v2 of the patch series with various improvements of the
> stackleak gcc plugin.
>
> The first three patches disable unneeded gcc plugin instrumentation for
> some files.
>
> The fourth patch is the
On Wed, Jun 24, 2020 at 04:09:20PM +0300, Alexander Popov wrote:
> On 24.06.2020 15:53, Luis Chamberlain wrote:
> > On Wed, Jun 24, 2020 at 03:33:30PM +0300, Alexander Popov wrote:
> >> Add 'verbose' plugin parameter for stackleak gcc plugin.
> >> It can be us
On Wed, Jun 24, 2020 at 03:33:28PM +0300, Alexander Popov wrote:
> Don't use gcc plugins for building arch/arm64/kernel/vdso/vgettimeofday.c
> to avoid unneeded instrumentation.
>
> Signed-off-by: Alexander Popov
It looks like Will has taken this already, but:
Acked-by: Kee
On Wed, Jun 24, 2020 at 03:33:26PM +0300, Alexander Popov wrote:
> There is no need to try instrumenting functions in kernel/stackleak.c.
> Otherwise that can cause issues if the cleanup pass of stackleak gcc plugin
> is disabled.
>
> Signed-off-by: Alexander Popov
> Acked-by:
On Wed, Jun 24, 2020 at 03:33:27PM +0300, Alexander Popov wrote:
> Don't use gcc plugins for building arch/arm/vdso/vgettimeofday.c to
> avoid unneeded instrumentation.
>
> Signed-off-by: Alexander Popov
Applied to for-next/gcc-plugins.
--
Kees Cook
On Wed, Jun 24, 2020 at 03:33:30PM +0300, Alexander Popov wrote:
> Add 'verbose' plugin parameter for stackleak gcc plugin.
> It can be used for printing additional info about the kernel code
> instrumentation.
>
> For using it add the following to scripts/Makefile.gc
Richard,
First off I did suspect INDIRECT_REF wasn't supported, thanks for
confirming that.
I tried what you said in the original code before I posted
but I suspect how I went at it is the problem. I'm probably
doing something(s) in a glaringly stupid way.
Can you spot it, because everything I'm
Hello GCC Steering Committee and fellow GCC developers,
I was wondering whether now might be a sensible time to graft GNU
Modula-2 into the GCC tree? (on the master branch only). At present
gm2 fully implements PIM2, PIM3, PIM4 and ISO dialects of Modula-2. All
the ISO libraries are
Hi, Gaius
Thanks for your diligent effort to complete this port of Modula-2 and
prepare it for inclusion in GCC. I have forwarded the proposal to the
GCC Steering Committee.
Thanks, David
On Wed, Jun 24, 2020 at 5:03 PM Gaius Mulley via Gcc wrote:
>
>
> Hello GCC Steering Comm
On Wed, Jun 24, 2020 at 9:05 PM Gary Oblock via Gcc wrote:
>
> Richard,
>
> First off I did suspect INDIRECT_REF wasn't supported, thanks for
> confirming that.
>
> I tried what you said in the original code before I posted
> but I suspect how I went at it is the
Hello,
I am working on a basic block coverage counter which
mimics -fsanitize-coverage=trace-pc but has more features. My problem is
that when instrumenting multiple C files (e.g., test1.c test2.c test3.c), I
want to generate correspondingly three coverage logs (test1.log, test2.log,
test3.log), s
David Edelsohn writes:
> Hi, Gaius
>
> Thanks for your diligent effort to complete this port of Modula-2 and
> prepare it for inclusion in GCC. I have forwarded the proposal to the
> GCC Steering Committee.
>
> Thanks, David
Hi David,
many thanks for forwarding the propos
; > ensure
> > > that TLS is supported on all rather than just a handful of popular ones
> > > (arm, x86, powerpc, sparc, etc). I know of Ulrich Drepper's document (
> > > https://www.akkadia.org/drepper/tls.pdf) but it is a few years old and
> > > covers
On Thu, 2020-06-25 at 15:46 -0400, Alan Lehotsky wrote:
> I’m working on a GCC 8.3 port to a load/store architecture with a 32-bit
> data-path between registers and memory;
>
> looking at the gcc.dg/loop-9.c test, I fail to pass because I have split the
> move of a double con
On June 26, 2020 3:24:24 AM GMT+02:00, Alan Lehotsky wrote:
>On Jun 25, 2020, at 6:37 PM, Jeff Law
>mailto:l...@redhat.com>> wrote:
>
>On Thu, 2020-06-25 at 15:46 -0400, Alan Lehotsky wrote:
>I’m working on a GCC 8.3 port to a load/store architecture with a
>32-bit data-pa
On Fri, Jun 26, 2020 at 9:12 AM Georg-Johann Lay wrote:
>
> Andrew Pinski via Gcc schrieb:
> > On Wed, Jun 3, 2020 at 2:32 PM Max Ruttenberg via Gcc
> > wrote:
> >> Hi all,
> >>
> >> I’ve added a named address space to our backend and I noticed
git to add ports to gcc. Just email the changes into
the patches list and someone will approve them, then you check them in. All
pretty trivial and standard. The hard part, the base port to the CPU is
already done, so mainly just finishing touches and polishing. If you want to
do the work
Sent from my iPhone
On Fri, 2020-06-26 at 01:24 +, Alan Lehotsky wrote:
> > On Jun 25, 2020, at 6:37 PM, Jeff Law wrote:
> >
> > On Thu, 2020-06-25 at 15:46 -0400, Alan Lehotsky wrote:
> > > I’m working on a GCC 8.3 port to a load/store architecture with a 32-bit
> > > da
Any idea on that? I just cannot find a way of using GIMPLE to analyze
multiple .C files. All my analysis is still start from the following
function:
virtual unsigned int execute(function *fun) override
which has no idea about the .C file information. In LLVM all .C files are
roughly maintained in
Hello,
I am writing the following statement to make a GIMPLE call:
tree function_fn_type = build_function_type_list(void_type_node,
void_type_node, integer_type_node, NULL_TREE);
tree sancov_fndecl = build_fn_decl("my_instrumentation_function",
function_fn_type);
auto gcall = gi
On June 27, 2020 6:21:12 AM GMT+02:00, Shuai Wang via Gcc
wrote:
>Hello,
>
>I am writing the following statement to make a GIMPLE call:
>
> tree function_fn_type = build_function_type_list(void_type_node,
>void_type_node, integer_type_node, NULL_TREE);
>
ing? Can I somehow get the name
of the C file? I don't find a corresponding pointer in the function struct.
Best,
Shuai
On Sat, Jun 27, 2020 at 9:12 PM Richard Biener
wrote:
> On June 27, 2020 6:21:12 AM GMT+02:00, Shuai Wang via Gcc
> wrote:
> >Hello,
> >
> >I am wr
On Sat, 2020-06-27 at 21:27 +0800, Shuai Wang via Gcc wrote:
> Dear Richard,
>
> Thanks for the info. My bad, I will need to append "\0" at the end of
> the
> string. Also, a follow-up question which I just cannot find an
> answer:
> typically in the plugin entry p
On June 27, 2020 11:15:50 PM GMT+02:00, David Malcolm
wrote:
>On Sat, 2020-06-27 at 21:27 +0800, Shuai Wang via Gcc wrote:
>> Dear Richard,
>>
>> Thanks for the info. My bad, I will need to append "\0" at the end of
>> the
>> string. Also, a fol
file
>* No C code generation and then compile and link gen code at the end.
>
> So, I've been thinking about multiple options:
>
> * Extending gimple to add support for a sizeof statement
> * A function per struct generated during compilation (sizeof & offsetof)
&
;* in gimple we can have an identifier we a dot in it.
> > * Disable constant propagation and other optimizations:
> >* possibly __attribute__((noipa))
> > * Be able to work with parallel compilation (make -j)
> > * Be able to work with any Makefile
> >*
On Mon, Jun 29, 2020 at 01:05:20PM +0200, Richard Biener via Gcc wrote:
> > // source code
> > struct astruct a;
> > memset(a, 0, sizeof(a));
> >
> > // parse time
> > memset(a, 0, 64);
Actually, I don't see the point at all, it doesn't matter if
Hello,
I am working on a gcc patch for asan. The patch is almost ready except one
thing. To make sure that the user has applied this patch before using asan
feature, I want to declare an additional variable in gcc which is reference
by our source code so that if this patch is missing, the user
On Tue, Jun 30, 2020 at 10:45:27AM +0200, Martin Liška wrote:
> Hello.
>
> After a brief discussion with Jakub, I was convinced to support 'git revert'
> where
> a ChangeLog is created from the commit the was reverted.
Ok.
Jakub
Hey Martin,
Thanks for your reply. Actually I am trying to have a callback function
allowing gcc to fetch shadow offset from runtime code.
In order to make sure that my users have applied this patch before using
asan feature, I want to define a variable in gcc (could be an integer)
which will be
On Tue, Jun 30, 2020 at 06:50:54PM -0400, y2s1982 . via Gcc wrote:
> 2020-06-30 Tony Sim
>
> libgomp/ChangeLog:
>
> * libgompd.h : Add gompd_callbacks variable.
No space before :, but generally, you should be exact on what changed.
So
* libgompd.h: Incl
I'm trying to generate calls to "free" on the fly at ipa time.
I've tried several things (given below) but they both fail
in expand_call_inline in tree-inline.c on this gcc_checking_assert:
cg_edge = id->dst_node->get_edge (stmt);
gcc_checking_assert (cg_edge);
Now, I've tried using the buil
On Wed, Jul 1, 2020 at 7:49 AM Gary Oblock via Gcc wrote:
>
> I'm trying to generate calls to "free" on the fly at ipa time.
>
> I've tried several things (given below) but they both fail
> in expand_call_inline in tree-inline.c on this gcc_checking_assert:
>
Actually these are two separate things. My callback function to fetch
shadow offset from user code is ready. This function is defined in my user
code and will be called by compiler (quite similar to how
__asan_stack_malloc_ function is implemented in gcc/asan.c).
Now in order to make sure that my
Hello,
Hope this mail finds you well. I am writing this to ask about one extension in
GCC, which is “Conditionals with Omitted Operands”.
From the document at https://gcc.gnu.org/onlinedocs/gcc/Conditionals.html , we
learn that this extension could be useful in terms of avoiding the side
On Wed, 2020-07-01 at 11:19 +0100, Matthew Malcomson wrote:
> Hello,
>
> I asked on IRC on Monday but since it didn't get any responses and the
> mailing list doesn't require someone paying attention at the moment I
> ask I'm asking here too.
>
>
> I've seen that `expand_builtin_init_trampoli
Thank you Richard.
I feel a bit dumb because I'm well aware of the GCC philosophy to have
any new code produced update the state. Of course I didn't know the
commands to do this for the call graph (which I really appreciate you giving.)
However, the real reason I'm sending a rep
On Wed, Jul 01, 2020 at 11:53:05AM -0400, Nathan Sidwell wrote:
> On 7/1/20 10:11 AM, Gong, Sishuai via Gcc wrote:
> > Hope this mail finds you well. I am writing this to ask about one extension
> > in GCC, which is “Conditionals with Omitted Operands”.
> >
> >
Thanks Martin. I liked your idea of using
__builtin___asan_version_mismatch_check_v8().
But now, I am getting a compile error. ( error: implicit declaration of
function '__builtin___asan_version_mismatch_check_v8'; )
It means the reference to this function is not resolved. So, I guess
On Wed, Jul 01, 2020 at 10:50:44PM -0400, y2s1982 . via Gcc wrote:
> per-process functions defined in 5.5.2.
> I have some questions on defining or at least using some of the data types.
The standard makes those intentionally not defined, it is up to the
implementation to put in there whate
On Thu, Jul 02, 2020 at 10:57:11AM -0400, y2s1982 . wrote:
> > On Wed, Jul 01, 2020 at 10:50:44PM -0400, y2s1982 . via Gcc wrote:
> > > per-process functions defined in 5.5.2.
> > > I have some questions on defining or at least using some of the data
> > types.
&g
Martin,
What about immediate dominators?
Thanks,
Gary
From: Martin Jambor
Sent: Wednesday, July 1, 2020 3:40 PM
To: Gary Oblock ; Richard Biener
Cc: gcc@gcc.gnu.org
Subject: Re: An problematic interaction between a call created by
gimple_build_call and
mpiler.
2. Update the compiler to partition the program, and fork on each
partition, generating one asm file per partition. The compiler should
compile some programs correctly at this point.
Both of these tasks were completed at this point, as we have a version
of GCC that bootstraps and have a sma
At IPA time I'm creating GIMPLE statements. I've noticed during dumps
that gotos and labels don't seem to exist. In fact when I tried
introducing them, at least the gotos, failed. I assume that at this
point in compilation GCC relies on the control flow graph (which I'm
upda
On Fri, Jul 3, 2020 at 6:04 AM Gary Oblock via Gcc wrote:
>
> At IPA time I'm creating GIMPLE statements. I've noticed during dumps
> that gotos and labels don't seem to exist. In fact when I tried
> introducing them, at least the gotos, failed. I assume that at this
On Thu, Jul 02, 2020 at 06:58:49PM -0400, y2s1982 . via Gcc wrote:
> This is giving me more clarity on what I have to do. At the moment, I am
> storing the
> information in the handle.
>
> I do have one problem: in 5.5.2.1 (
> https://www.openmp.org/spec-html/5.0/ope
On Fri, Jul 03, 2020 at 10:26:27AM -0400, y2s1982 . wrote:
> Still, following the documentation 5.5.2.1, how should I extract version
> information from ompd_address_space_context_t that is owned by the
> debugger instead of the OMPD to check for compatibility , especially
> when it is not currentl
Richard Biener
Cc: gcc@gcc.gnu.org
Subject: Re: An problematic interaction between a call created by
gimple_build_call and inlining
Hi,
On Thu, Jul 02 2020, Gary Oblock wrote:
> Martin,
>
> What about immediate dominators?
I'm afraid I don't understand your question, what
n DWARF4/5,
just read the description in there.
And as you found, in some cases it is possible to represent the value by
either of those, in which case GCC tries to use the shorter one.
For __int128, to use DW_OP_stack_value one would need to use the typed DWARF
stack DWARF5 features (so e.g. in
On July 4, 2020 11:30:05 AM GMT+02:00, "Thomas König" wrote:
>Hi,
>
>in Fortran, it would sometimes be useful to have a different
>optimization
>depending on whether we generate inlined code for intrinsics (where we
>know when it is OK to „go wild“) or user code, where we need to
>adhere (for ex
On July 5, 2020 12:37:58 PM GMT+02:00, "Thomas König" wrote:
>
>> Am 04.07.2020 um 19:11 schrieb Richard Biener
>:
>>
>> On July 4, 2020 11:30:05 AM GMT+02:00, "Thomas König"
> wrote:
>>>
>>> What could be a preferred way to achieve that? Could optimization
>>> options like -ffast-math be appli
ith internal functions, with an extra
> operand to specify various behaviors (rounding, exception, etc). Although
> at least in the beginning, I was thinking of only using those functions in
> safe mode, to avoid perf regressions.
>
> https://gcc.gnu.org/pipermail/gcc-patches/2019-
osed.
>
> One small doubt still remains. It seems(to me) that DW_OP_stack_value and
> DW_OP_implicit_value both can be used to describe most optimized
> location/value of a variable. Then representing/choosing appropriate
> operation involves matter like space/compactness(just li
The top line in
https://gcc.gnu.org/onlinedocs/gcc-4.6.3/gfortran/BOZ-literal-constants.html
says " The syntax is: `prefix quote digits quote', were the prefix is
either b, o or z,"
Here, 'were' must be 'where'
HTH,
Nino
On Tue, 7 Jul 2020 at 15:41, Nino Pereira via Gcc wrote:
>
> The top line in
> https://gcc.gnu.org/onlinedocs/gcc-4.6.3/gfortran/BOZ-literal-constants.html
>
> says " The syntax is: `prefix quote digits quote', were the prefix is
> either b, o or z,"
>
> Her
On Thu, Jul 9, 2020 at 7:03 AM Matthias Klose wrote:
>
> https://gcc.gnu.org/gcc-8/criteria.html lists the little endian platform first
> as a primary target, however it's not mentioned for GCC 9 and GCC 10. Just an
> omission?
>
> https://gcc.gnu.org/legacy-ml/gcc-patche
On Thu, Jul 9, 2020 at 9:07 AM Matthias Klose wrote:
>
> On 7/9/20 1:58 PM, David Edelsohn via Gcc wrote:
> > On Thu, Jul 9, 2020 at 7:03 AM Matthias Klose wrote:
> >>
> >> https://gcc.gnu.org/gcc-8/criteria.html lists the little endian platform
> >> first
On July 9, 2020 3:43:19 PM GMT+02:00, David Edelsohn via Gcc
wrote:
>On Thu, Jul 9, 2020 at 9:07 AM Matthias Klose wrote:
>>
>> On 7/9/20 1:58 PM, David Edelsohn via Gcc wrote:
>> > On Thu, Jul 9, 2020 at 7:03 AM Matthias Klose
>wrote:
>> >>
>> >
Both GCC and Clang have implemented many debugging options under -f and
-g. Whether options go to -f or -g appears to be pretty arbitrary decisions.
A non-complete list of GCC supported debug options is documented here at
https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html
I think there
* David Edelsohn via Gcc:
> No, it's not dropped. Some people are being pedantic about the name,
> which is why Bill added {,le}. powerpc64-unknown-linux-gnu means
> everything. If you want to add {,le} back, that's fine. But there
> always is some variant omitted, and t
Fix email addresses:)
On 2020-07-09, Fangrui Song wrote:
Both GCC and Clang have implemented many debugging options under -f and
-g. Whether options go to -f or -g appears to be pretty arbitrary decisions.
A non-complete list of GCC supported debug options is documented here at
https
On Thu, Jul 9, 2020 at 12:03 PM Fangrui Song wrote:
>
> Both GCC and Clang have implemented many debugging options under -f and
> -g. Whether options go to -f or -g appears to be pretty arbitrary decisions.
>
> A non-complete list of GCC supported debug options is documented
On 7/9/20 12:13 PM, Richard Biener via Gcc wrote:
On July 9, 2020 3:43:19 PM GMT+02:00, David Edelsohn via Gcc
wrote:
On Thu, Jul 9, 2020 at 9:07 AM Matthias Klose wrote:
On 7/9/20 1:58 PM, David Edelsohn via Gcc wrote:
On Thu, Jul 9, 2020 at 7:03 AM Matthias Klose
wrote:
https
On Fri, 10 Jul 2020 at 09:25, Unidef Defshrizzle wrote:
>
> What would happen?
This doesn't seem like a question about GCC development, so is
off-topic on this mailing list.
The C language says what should happen, GCC follows that.
rom GCC's -march=haswell (and presumably other compilers):
Definition of "haswell" platform is inconsistent with GCC
<https://sourceware.org/bugzilla/show_bug.cgi?id=24080>
And that the selection criteria are not what people expect:
Epyc and other current AMD CPUs
20-May/113757.html>
>
> We also have the problem that the glibc version of "haswell" is distinct
> from GCC's -march=haswell (and presumably other compilers):
>
> Definition of "haswell" platform is inconsistent with GCC
> <https://sourceware
oined
-march= Generate code for given RISC-V ISA (e.g. RV64IM). ISA strings must
be
lower-case.
I assume that this information is stored somewhere, as I read somewhere
online that GCC generates different assembly for different ISA strings,
though I suppose this could be referring to previous versions o
On Fri, Jul 10, 2020 at 11:45 PM H.J. Lu via Gcc wrote:
>
> On Fri, Jul 10, 2020 at 10:30 AM Florian Weimer wrote:
> >
> > Most Linux distributions still compile against the original x86-64
> > baseline that was based on the AMD K8 (minus the 3DNow! parts, for Intel
the
recommended directory. But I think this is something that could come
later.
We can also write a GCC header which looks at macros such as __AVX2__
and prints a #warning with the recommended directory name. Checking for
excess flags will be tricky in this context, though, and if we miss
somethin
* Allan Sandfeld Jensen:
> On Freitag, 10. Juli 2020 19:30:09 CEST Florian Weimer via Gcc wrote:
>> glibc (or an alternative loader implementation) would search for
>> libraries starting at level D, going back to level A, and finally the
>> baseline implementation in the def
* Richard Biener:
>> Looks good. I like it.
>
> Likewise. Btw, did you check that VIA family chips slot into Level A
> at least?
Those seem to lack SSE4.2, so they land in the baseline.
> Where do AMD bdverN slot in?
bdver1 to bdver3 (as defined by GCC) should land in Leve
* Joseph Myers:
> On Fri, 10 Jul 2020, Florian Weimer via Gcc wrote:
>
>> * Level A
>>
>> CMPXCHG16B, LAHF/SAHF, POPCNT, SSE3, SSE4.1, SSE4.2, SSSE3
>>
>> This is one step above the K8 baseline and corresponds to a mainline CPU
>> model ca. 2008 to 2
aseline.
>
> > Where do AMD bdverN slot in?
>
> bdver1 to bdver3 (as defined by GCC) should land in Level B (so Level A
> if that is dropped). bdver4 and znver1 (and later) should land in
> Level C.
>
> >> My only concerns are
> >>
> >> 1. Names l
* Bill Schmidt via Gcc:
> Matthias, if you want to post a patch for GCC 9 and GCC 10, I'm sure
> that would be accepted (though I do not have the power to pre-approve
> it). Or I can put it on my list for later in the summer when my life
> settles down. Your choice.
I posted a
On 7/13/20 7:08 AM, Florian Weimer wrote:
* Bill Schmidt via Gcc:
Matthias, if you want to post a patch for GCC 9 and GCC 10, I'm sure
that would be accepted (though I do not have the power to pre-approve
it). Or I can put it on my list for later in the summer when my life
settles down.
ERTY_X86_ISA_1_NEEDED
property.
> something to binutils or indeed ld.so to analyze them and print the
> recommended directory. But I think this is something that could come
> later.
>
> We can also write a GCC header which looks at macros such as __AVX2__
> and prints a #warning
On Mon, Jul 13, 2020 at 12:48 AM Jan Beulich wrote:
>
> On 13.07.2020 09:40, Florian Weimer wrote:
> > * Richard Biener:
> >>> 2. I have a library with AVX2 and FMA, which directory should it go?
> >>
> >> Eventually GCC/gas can annotate objects with
On Mon, Jul 13, 2020 at 06:31:31AM -0700, H.J. Lu via Gcc wrote:
> > > H.J. has patches for ELF program properties. I think
> > > GNU_PROPERTY_X86_ISA_1_NEEDED would convey this information. This
> > > proposal and the glibc patches are independent of that.
> &
s/releases/gcc-10
To git+ssh://gcc.gnu.org/git/gcc.git
Thanks
Martin
ote: error: hook declined to update refs/heads/releases/gcc-10
To git+ssh://gcc.gnu.org/git/gcc.git
The cause of the error turned out to be that for some reason,
after a rebase, the diff I was trying to push also contained
upstream ChangeLog updates that I didn't scroll far enough in
the commit
On Mon, 2020-07-13 at 08:39 +0200, Hans-Peter Nilsson via Gcc wrote:
> Again, Debian 9. Doing "git gcc-backport a4aca1edaf37d43" on
> releases/gcc-10 gave me:
>
> [releases/gcc-10 83cf5a7c6a5] PR94600: fix volatile access to the
> whole of a compound object.
> D
ver, when the program is compiled with PGO the compiler does not
> >> specialize the function calls.
> >>
> >> I printing the program just after materializing all clones.
> >>
> >> I am running this version of GCC:
> >> Author: GCC Administrator
On Tue, Jul 14, 2020 at 7:24 AM Andreas Schwab wrote:
>
> On Jul 14 2020, Maciej W. Rozycki wrote:
>
> > Arguably this might probably be called a deficiency in libgcc, however
> > the objects are built with `-fexceptions -fnon-call-exceptions'
>
> I consider that broken. It doesn't make any sens
Hello,
I am trying to traverse the GIMPlE statements and identify all pointer
differences (i.e., memory load and store). For instance, something like:
**_4* = 0;
...
_108 = (signed char *) _107;
_109 = **_108*;
After some quick searches in the GCC codebase, I am thinking to use the
On Tue, Jul 14, 2020 at 9:17 AM Shuai Wang via Gcc wrote:
>
> Hello,
>
> I am trying to traverse the GIMPlE statements and identify all pointer
> differences (i.e., memory load and store). For instance, something like:
>
> **_4* = 0;
>...
> _108 = (signed char
Thank you. Yes, I think gimple_store_p and gimple_assign_load_p should be
what I am looking for.
Best,
Shuai
On Tue, Jul 14, 2020 at 5:38 PM Richard Biener
wrote:
> On Tue, Jul 14, 2020 at 9:17 AM Shuai Wang via Gcc
> wrote:
> >
> > Hello,
> >
> > I am trying to
Hi everyone,
I'm trying to autovectorize the loop, and Thank you for the omnipotent
macros, everything goes alright. But recently I need to further optimize the
loop, I had some problems.
As our vector instruction can process 16 numbers at the same time, if the for
loop counter is equal or l
, it successfully
passes the two if checks and reaches the gimple_code(def_stmt), but still
caused an exception:
0xb5cd5f crash_signal
../../gcc-10.1.0/gcc/toplev.c:328
0x7f4214557838 gimple_code
/export/d1/shuaiw/gcc-build-10/gcc-install/lib/gcc/x86_64-pc-linux-gnu/10.1.0/plugin/include
> pass to print the statements of the code and by executing this pass after
> the previous pass (that injects the code), I see correct results (i.e., the
> injected code is correctly generated and inserted into the right location).
> But when I debug the sample code, I see that only the last injected statement
> (fclose) is executed with NULL in the f_decl variable which causes the
> segmentation fault. I searched everywhere, read all the documentations I
> could find, and digged into the gcc code for other pragmas (i.e. omp
> parallel, etc.). But still I have no success in doing this correctly. Could
> you please point me where the problem is?
>
> Thanks,
> M. Gholami
>
>
On Wed, Jul 15, 2020 at 9:30 AM Shuai Wang via Gcc wrote:
>
> Hello,
>
> I am using the following code to iterate different gimple statements:
>
> ...
> gimple* stmt = gsi_stmt(gsi);
> if (gimple_assign_load_p(stmt)) {
> tree rhs = gimple_assign_rhs1 (stm
cy of _314...? Thanks
a lot!
Best,
Shuai
On Wed, Jul 15, 2020 at 6:49 PM Martin Jambor wrote:
> Hi,
>
> On Wed, Jul 15 2020, Shuai Wang via Gcc wrote:
> > Hello,
> >
> > I am using the following code to iterate different gimple statements:
> >
> > .
On Wed, Jul 15, 2020 at 10:07 AM Shuai Wang via Gcc wrote:
>
> Hello!
>
> Thank you very much. I use the following statement to check and I confirm
> that it's not SSA_NAME:
>
> if (TREE_CODE(operand) != SSA_NAME) return;
>
> But considering the followi
and of course we can generate SIGILL for unsupported
> instructions. We currently don't intercept /proc/cpuinfo (but could).
In library, we can use :
https://sourceware.org/pipermail/libc-alpha/2020-June/115546.html
In GCC, we can use __builtin_cpu_supports.
supports all features
* Mark Wielaard:
> One thing that wasn't clear to me from this proposal is how the glibc
> dynamic loader checks for the CPU feature flags. This is important for
> valgrind since it can communicate those through different means. cpuid
> interception, auxv AT_HWCAP/AT_HWCAP2 interception (but not A
I tested the release candidate on powerpc64 power 7 BE, power 8 BE,
power 8 LE, and power 9 LE and everything looked OK.
On 7/15/20 6:50 AM, Richard Biener wrote:
The first release candidate for GCC 10.2 is available from
https://gcc.gnu.org/pub/gcc/snapshots/10.2.0-RC-20200715/
ftp
nline
dump file: ./exe.ltrans0.ltrans.079i.inline
main.c: In function ‘main’:
main.c:18:11: internal compiler error: Segmentation fault
18 | max_y = max_of_y( data, len);
| ^
0xcbb4af crash_signal
../../source/gcc/toplev.c:328
0xd24d66 hash_table::find_with_hash(tree_node* const
2001 - 2100 of 10345 matches
Mail list logo
