Re: Definition of the Host, Target and Build fields in Bugzilla
On 14 September 2014 20:03, Andreas Schwab wrote: > Frédéric Buclin writes: > >> Could one of you give me a short and clear description of each of the >> Host, Target and Build fields used in GCC Bugzilla? > > It's the same as what you pass to configure as --build, --host, --target. i.e. Build is the system that the compiler is built on. Host is the system that the compiler runs on. Target is the system that the compiler generates code for.
How to access the function body of a constructor?
I am trying to access the body of a constructor.
My pass is hooked after pass_ipa_pta.
Constructor for a class is invoked as :
__comp_ctor (&b);
However the constructor body is dumped as
__base_ctor (struct B * const this)
{
:
}
I am not able to access basic blocks from __comp_ctor?
Is __comp_ctor a cloned function of __base_ctor?
Also assuming it to be a cloned function, I tried to access it using
"clones", "clones_of" fields of structure cgraph_node.
But these fields does not store anything (or at least for the functions
I tried).
What does these fields (clones, clone_of etc.) store?
Will the macro DECL_CLONED_FUNCTION give me __base_ctor from __comp_ctor ?
I tried using it but it gives an error, "undefined symbol:
_Z22decl_cloned_function_pPK9tree_nodeb".
Kindly tell me way to access the constructor body.
Regards,
Swati
Re: Issue with sub-object __builtin_object_size
Jakub Jelinek wrote:
> On Tue, Jun 10, 2014 at 07:37:50PM +0200, Ulrich Weigand wrote:
> > the following C++ test case:
> >
> > struct pollfd
> > {
> > int fd;
> > short int events;
> > short int revents;
> > };
> >
> > struct Pollfd : public pollfd { };
> >
> > struct Pollfd myfd[10];
> >
> > int test (void)
> > {
> > return __builtin_object_size ((struct pollfd *)myfd, 1);
> > }
> >
> > ends up returning 8 from the "test" routine, not 80.
>
> The thing is that the C++ FE transforms this kind of cast to
> &((struct Pollfd *) &myfd)->D.2233
> so for middle-end where __builtin_object_size is evaluated this
> is like:
> struct Pollfd { struct pollfd something; };
> struct Pollfd myfd[10];
> int test (void)
> {
> return __builtin_object_size (&myfd[0].something, 1);
> }
> and returning 8 in that case is completely correct.
> So the question is why instead of a simple cast it created
> ADDR_EXPR of a FIELD_DECL instead.
Sorry for the long delay, I finally found time to look into this
problem again. This behavior of the C++ front-end seems to trace
back to a deliberate change by Jason here:
https://gcc.gnu.org/ml/gcc-patches/2004-04/msg02000.html
"This patch changes the representation to b..i,
which is more friendly to alias analysis."
It still seems the effect of this on __builtin_object_size is
surprising and probably not what was intended. I'm not sure
whether the front-end or the middle-end is more "at fault" here.
Thoughts?
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
Re: Issue with sub-object __builtin_object_size
On Mon, Sep 15, 2014 at 05:21:50PM +0200, Ulrich Weigand wrote:
> > The thing is that the C++ FE transforms this kind of cast to
> > &((struct Pollfd *) &myfd)->D.2233
> > so for middle-end where __builtin_object_size is evaluated this
> > is like:
> > struct Pollfd { struct pollfd something; };
> > struct Pollfd myfd[10];
> > int test (void)
> > {
> > return __builtin_object_size (&myfd[0].something, 1);
> > }
> > and returning 8 in that case is completely correct.
> > So the question is why instead of a simple cast it created
> > ADDR_EXPR of a FIELD_DECL instead.
>
> Sorry for the long delay, I finally found time to look into this
> problem again. This behavior of the C++ front-end seems to trace
> back to a deliberate change by Jason here:
> https://gcc.gnu.org/ml/gcc-patches/2004-04/msg02000.html
>
> "This patch changes the representation to b..i,
> which is more friendly to alias analysis."
>
> It still seems the effect of this on __builtin_object_size is
> surprising and probably not what was intended. I'm not sure
> whether the front-end or the middle-end is more "at fault" here.
>
> Thoughts?
I'm afraid there is nothing the middle-end can do here.
It could try to ignore DECL_ARTIFICIAL fields, but that would still
mean &myfd[0] rather than what has been written in the source, which would
still give you smaller size than you are expecting.
Jakub
Re: Issue with sub-object __builtin_object_size
On 09/15/2014 11:21 AM, Ulrich Weigand wrote:
Jakub Jelinek wrote:
On Tue, Jun 10, 2014 at 07:37:50PM +0200, Ulrich Weigand wrote:
the following C++ test case:
struct pollfd
{
int fd;
short int events;
short int revents;
};
struct Pollfd : public pollfd { };
struct Pollfd myfd[10];
int test (void)
{
return __builtin_object_size ((struct pollfd *)myfd, 1);
}
ends up returning 8 from the "test" routine, not 80.
This example strikes me as strange. Why do you expect the size of a
pointer to the base class subobject to give a meaningful answer, any
more than taking the address of a data member?
Jason
Re: Issue with sub-object __builtin_object_size
Jason Merrill wrote:
> On 09/15/2014 11:21 AM, Ulrich Weigand wrote:
> > Jakub Jelinek wrote:
> >> On Tue, Jun 10, 2014 at 07:37:50PM +0200, Ulrich Weigand wrote:
> >>> the following C++ test case:
> >>>
> >>> struct pollfd
> >>>{
> >>> int fd;
> >>> short int events;
> >>> short int revents;
> >>>};
> >>>
> >>> struct Pollfd : public pollfd { };
> >>>
> >>> struct Pollfd myfd[10];
> >>>
> >>> int test (void)
> >>> {
> >>>return __builtin_object_size ((struct pollfd *)myfd, 1);
> >>> }
> >>>
> >>> ends up returning 8 from the "test" routine, not 80.
>
> This example strikes me as strange. Why do you expect the size of a
> pointer to the base class subobject to give a meaningful answer, any
> more than taking the address of a data member?
Well, it's a test case simplified from a real-world example. To quote
the original mail at the start of this thread:
>In the real-world application this test case was extracted from,
>this causes a call:
>
> poll(myfd, count, 0); // 1 < count < 10
>
>to fail with a "Buffer overflow detected" message at run-time
>when building with _FORTIFY_SOURCE = 2 against glibc. [ Here,
>there is no explicit cast, but it is implied by the prototype
>of the "poll" routine. ]
>
>(Note that in the real-world application, the derived struct Pollfd
>has some member functions to construct and pretty-print the structure,
>but has no additional data members.)
(https://gcc.gnu.org/ml/gcc/2014-06/msg00116.html)
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
Re: [PATCH] gcc parallel make check
On Fri, Sep 12, 2014 at 04:42:25PM -0700, Mike Stump wrote:
> On Sep 12, 2014, at 9:32 AM, Jakub Jelinek wrote:
> > Here is my latest version of the patch.
>
> I did a timing test:
Here is an updated version.
Changes since last version:
1) acats parallelized the same way (just, because it is in shell,
using mkdir instead of open with O_EXCL|O_CREAT);
also, as acats has pretty significant initial setup time
(up to a minute or so on not really fast box), I'm now
creating the /support stuff before spawning the parallel
jobs and let the parallel jobs use the same shared support
directory
2) I'm now using addprefix instead of patsubst where appropriate
3) I'm using $(if ...) instead of $(or ...) to make it usable
with make 3.80 (3.81 already supports or)
4) parallelization is performed for any kinds of RUNTESTFLAGS arguments now
5) struct-layout-1.exp apparently doesn't have to be performed serially,
and for gnu-encoding.exp I've used similar change as for go-test.exp
6) in libstdc++, abi.exp, pretty-printers.exp and xmethods.exp are performed
together with conformance.exp, so again parallelization for any
RUNTESTFLAGS flags; abi.exp and xmethods.exp are serially tested
by the first runtest instance to encounter them
Regtested on x86_64-linux, without the patch toplevel make -k check
took 8hrs3minutes (don't have time data for that run), without the
patch toplevel make -j48 -k check took:
real40m21.984s
user341m51.675s
sys 112m46.993s
and with the patch make -j48 -k check took:
real32m22.066s
user355m1.788s
sys 117m5.809s
I saw over 45 jobs running pretty much as the point where all the
testing was done, and test_summary run from the non-parallel testing
is the same as test_summary from the -j48 testing with the patch.
Is this version ok for trunk?
2014-09-14 Jakub Jelinek
gcc/
* Makefile.in (dg_target_exps): Remove.
(check_gcc_parallelize): Change to just an upper bound number.
(check-%-subtargets): Always print the non-parallelized goals.
(check_p_vars, check_p_comma, check_p_subwork): Remove.
(check_p_count, check_p_numbers0, check_p_numbers1, check_p_numbers2,
check_p_numbers3, check_p_numbers4, check_p_numbers5,
check_p_numbers6): New variables.
(check_p_numbers): Set to sequence from 1 to .
(check_p_subdirs): Set to sequence from 1 to minimum of
$(check_p_count) and either GCC_TEST_PARALLEL_SLOTS env var if set,
or 128.
(check-%, check-parallel-%): Rewritten so that for parallelized
testing each job runs all the *.exp files, with
GCC_RUNTEST_PARALLELIZE_DIR set in environment.
gcc/go/
* Make-lang.in (check_go_parallelize): Change to just an upper bound
number.
gcc/fortran/
* Make-lang.in (check_gfortran_parallelize): Change to just an upper
bound number.
gcc/cp/
* Make-lang.in (check_g++_parallelize): Change to just an upper bound
number.
gcc/objc/
* Make-lang.in (check_objc_parallelize): Change to just an upper
bound number.
gcc/ada/
* gcc-interface/Make-lang.in (check_acats_numbers0,
check_acats_numbers1, check_acats_numbers2, check_acats_numbers3,
check_acats_numbers4, check_acats_numbers5, check_acats_numbers6,
check_acats_numbers, check_acats_subdirs): New variables.
(check_acats_targets): Use $(check_acats_subdirs).
(check-acats, check-acats%): Rewritten so that for parallelized
testing each job runs all the chapters files, with
GCC_RUNTEST_PARALLELIZE_DIR set in environment. Prepare the support
directory sequentially and share it.
(check-acats-subtargets): Always print just check-acats.
gcc/testsuite/
* lib/gcc-defs.exp (gcc_parallel_test_run_p,
gcc_parallel_test_enable): New procedures. If
GCC_RUNTEST_PARALLELIZE_DIR is set in environment, override
runtest_file_p to invoke also gcc_parallel_test_run_p.
* g++.dg/guality/guality.exp (check_guality): Save/restore
test_counts array around the body of the procedure.
* gcc.dg/guality/guality.exp (check_guality): Likewise.
* g++.dg/plugin/plugin.exp: Run all the tests serially
by the first parallel runtest encountering it.
* gcc.dg/plugin/plugin.exp: Likewise.
* gcc.misc-tests/matrix1.exp: Likewise.
* gcc.misc-tests/dhry.exp: Likewise.
* gcc.misc-tests/acker1.exp: Likewise.
* gcc.misc-tests/linkage.exp: Likewise.
* gcc.misc-tests/mg.exp: Likewise.
* gcc.misc-tests/mg-2.exp: Likewise.
* gcc.misc-tests/sort2.exp: Likewise.
* gcc.misc-tests/sieve.exp: Likewise.
* gcc.misc-tests/options.exp: Likewise.
* gcc.misc-tests/help.exp: Likewise.
* go.test/go-test.exp (go-gc-tests): Use
gcc_parallel_test_enable {0, 1} around all handling of
each test.
* obj
Re: [PATCH] gcc parallel make check
On Sep 15, 2014, at 9:05 AM, Jakub Jelinek wrote: All the updates sound good. > Regtested on x86_64-linux, without the patch toplevel make -k check > took 8hrs3minutes (don't have time data for that run), This confuses me, but, no matter. Isn’t 8hrs time data? :-) > patch toplevel make -j48 -k check took: > real40m21.984s > user341m51.675s > sys 112m46.993s > and with the patch make -j48 -k check took: > real32m22.066s > user355m1.788s > sys 117m5.809s These numbers are useful to try and ensure the overhead (scaling factor) is reasonable, thanks. > Is this version ok for trunk? Ok. Thanks for all your work.
plugins header file
During the re-architecture session at Cauldron, I mentioned the possibility of introducing a plugin-headers.h. This would be a file which plugins could use which would protect them somewhat from header file restructuring. The idea is that it includes all the common things plugins need, (like gimple.h, rtl.h, most-of-the-world.h, etc etc),. When header files are restructured, that file would also be adjusted so that the correct include order is still maintained. This could also give plugins a little more stability across releases since header files do come and go.. I am about to start another round of flattening and shuffling, so figured this might be a good time to introduce it. Any of you plugin users have a list of includes you want to see in it, or better yet, provide me with a plugin-headers.h? ( Out of curiosity, is there a reason gcc-plugins.h doesn't include a pile of these common things? or is that simply to avoid bringing in the world?) Or would you rather just continue to deal with the pain of header file name changing/content shuffling? or is there a different solution proposal? Andrew
Re: Issue with sub-object __builtin_object_size
On 09/15/2014 11:55 AM, Ulrich Weigand wrote: (https://gcc.gnu.org/ml/gcc/2014-06/msg00116.html) From the __builtin_object_size documentation, it's not immediately clear to me whether this is supposed to work or not: If the least significant bit is clear, objects are whole variables, if it is set, a closest surrounding subobject is considered the object a pointer points to. Is the presence of the above cast (explicit or implicit) supposed to modify the notion of "closest surrounding subobject"? IMO, yes. A base class subobject is a subobject, so since the least significant bit is set, it seems to me that GCC is correctly returning the size of that subobject. Jason
Re: plugins header file
Sounds a good idea to me, here is the list I'm using: #include "params.h" #include "flags.h" #include "tree.h" #include "tree-pass.h" #include "basic-block.h" #include "function.h" #include "hash-table.h" #include "tree-ssa-alias.h" #include "tree-cfg.h" #include "tree-ssa-operands.h" #include "tree-inline.h" #include "gimple-expr.h" #include "is-a.h" #include "gimple.h" #include "tree-phinodes.h" #include "gimple-iterator.h" #include "gimple-ssa.h" #include "ssa-iterators.h" #include "tree-into-ssa.h" #include "cfgloop.h" #include "context.h" However, it does not automatically solve the missing header file issue in Makefile, any idea to solve this problem? - Joey On Tue, Sep 16, 2014 at 2:18 AM, Andrew MacLeod wrote: > During the re-architecture session at Cauldron, I mentioned the possibility > of introducing a plugin-headers.h. > > This would be a file which plugins could use which would protect them > somewhat from header file restructuring. The idea is that it includes all > the common things plugins need, (like gimple.h, rtl.h, most-of-the-world.h, > etc etc),. When header files are restructured, that file would also be > adjusted so that the correct include order is still maintained. This could > also give plugins a little more stability across releases since header files > do come and go.. > > I am about to start another round of flattening and shuffling, so figured > this might be a good time to introduce it. Any of you plugin users have a > list of includes you want to see in it, or better yet, provide me with a > plugin-headers.h? ( Out of curiosity, is there a reason gcc-plugins.h > doesn't include a pile of these common things? or is that simply to avoid > bringing in the world?) Or would you rather just continue to deal with the > pain of header file name changing/content shuffling? or is there a > different solution proposal? > > > Andrew
Re: GCC 5 snapshots produce broken kernel for powerpc-e500v2-linux-gnuspe?
On 09/09/2014 06:05 PM, pins...@gmail.com wrote: > I have a patch which I need to submit. Maybe by Friday I will do that. It > fixes the kernel on arm64 but it is generic c front-end patch. https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01146.html fixed kernel miscompilation for me. The second issue, module section related one, seems to be unrelated.
PowerPC rs6000 multilib combinations
Hi, I've recently been using a target (e200z6) where a "-mno-spe -mabi=no-spe" libgcc was required. The closest combination provided by 4.9.1 was "-mno-spe -mabi=no-spe -mno-isel". My builds disable spe, but leave isel enabled. Unfortunately, with this combination of options gcc uses an incompatible libgcc which includes spe instructions. I have attached a patch which enables the "-mno-spe -mabi=no-spe" multilib. It seems a bit broken that gcc would use an spe version of libgcc when I specify "no-spe". Hopefully someone finds the patch useful. Kind regards, Patrick --- gcc/config/rs6000/t-spe.orig 2014-09-16 13:55:57.649114878 +1000 +++ gcc/config/rs6000/t-spe 2014-09-16 13:56:37.393116284 +1000 @@ -23,6 +23,7 @@ # -mcpu=7400 -maltivec -mabi=altivec # -mcpu=7400 -msoft-float # -msoft-float +# -mno-spe -mabi=no-spe # -mno-spe -mabi=no-spe -mno-isel # so we'll need to create exceptions later below. @@ -56,7 +57,6 @@ *msoft-float/*mno-spe* \ *msoft-float/*mabi=no-spe* \ *msoft-float/*mno-isel* \ - mno-spe/mabi=no-spe \ mno-spe/mno-isel \ mabi=no-spe/mno-isel \ mno-isel/mlittle \ @@ -67,7 +67,6 @@ mcpu=7400/maltivec/mlittle \ mabi=no-spe/mlittle \ mno-spe/mno-isel/mlittle \ - mno-spe/mabi=no-spe/mlittle \ mabi=altivec/mlittle \ maltivec/mlittle \ maltivec/mabi=altivec/mlittle
