Re: A question about acquire/release semantic in the wiki page
On Wed, 1 Aug 2018 at 01:32, Bramandia Ramadhana wrote: > > Hi, > > I am reading the gcc wiki page about atomic Acquire/Release memory > model: https://gcc.gnu.org/wiki/Atomic/GCCMM/AtomicSync. > > It is mentioned: > > "Both of these asserts can pass since there is no ordering imposed > between the stores in thread 1 and thread 2. > > If this example were written using the sequentially consistent model, > then one of the stores must happen-before the other (although the > order isn't determined until run-time), the values are synchronized > between threads, and if one assert passes, the other assert must > therefore fail." > > > The code snippet is as follows: > -Thread 1- > y.store (20, memory_order_release); > > -Thread 2- > x.store (10, memory_order_release); > > -Thread 3- > assert (y.load (memory_order_acquire) == 20 && x.load > (memory_order_acquire) == 0) > > -Thread 4- > assert (y.load (memory_order_acquire) == 0 && x.load > (memory_order_acquire) == 10) > > In my limited understanding of the C++ memory model, it is possible > the 2 asserts can pass even in sequentially consistent model. > > Consider the following interleaving: > - First check of thread 4 runs, it passes since y is 0 > - Thread 1 runs, y is now 20 > - Thread 3 runs, the assert passed since y = 20 and x = 0 > - Thread 2 runs, x is now 10 > - The second check of thread 4 runs, it also passes since x is now 10. > Hence, the assert passed. > > Am I missing something? Can someone shed a light? >From a quick read, I think you're right. The wiki example seems to assume that both branches of the && conditions in the assertions happen atomically.
Static sem_item_optimizer instance in ipa-icf pass
Hi, I stumbled across this during my work on a gcc compiler plugin [1]. During the ipa-icf pass semantic items (`sem_function` and `sem_variable`) are generated to find potential candidates for function or variable merging. In `ipa-icf.c` there is a static variable `optimizer` (of type `sem_item_optimizer`) which is initialized before and destroyed after the ipa-icf pass. This variable is used by the semantic items. Therefore it is not possible to use `sem_function` or `sem_variable` outside of the icf pass (as the static optimizer is NULL). E.g. create a `sem_function` variable with `sem_function::parse`. Is this intended? I would like to use `sem_function` objects (independently from the icf pass) to compare functions that were generated by our gcc plugin (or is this a bad idea). It seems that (non-static) member functions like `sem_item_optimizer::parse_func_and_vars` use this static `optimizer` instance (through some indirections [2]) which looks kinda wrong to me. Regards, Flo [1] https://github.com/luhsra/multiverse [2] Calls: sem_item_optimizer::parse_funcs_and_vars [ipa_icf.c:2666] sem_function::parse [ipa_icf.c:1691] sem_function::init[ipa_icf.c:1387] sem_function::hash_stmt [ipa_icf.c:1617] sem_function::add_type[ipa_icf.c:1547] uses static sem_item_optimizer optimzer [ipa_icf.c:94]
EMAAR Special Offer - Book With Only 5% Today!
View this email in your browser (https://mailchi.mp/3cd69155979a/emaar-special-offer-book-with-only-5-today-147507?e=900c0908eb) https://aquaproperties.com/downtown-views/kc.html We’re delighted to offer you a special promotion on 3 bedroom apartments at the opulent Downtown Views II Tower in Downtown Dubai. A 55 storey, luxury tower, Downtown Views boasts spectacular views of Downtown Dubai, Burj Khalifa and Burj Lake, as well as a 360 degree view of the Dubai landscape. This residential flagship tower that will set a new standard of living will be completed in December 2020. Register your interest (https://aquaproperties.com/downtown-views/kc.html) ** 75% POST-HANDOVER 5 YEAR PAYMENT PLAN ** 100% OFF REGISTRATION FEES ** 3-YEAR SERVICE CHARGE WAIVER https://aquaproperties.com/downtown-views/ https://aquaproperties.com/downtown-views/ Register now (https://aquaproperties.com/downtown-views/kc.html) https://aquaproperties.com/downtown-views/kc.html For more information: Khusro Sales Director +971 55 899 24 29 khu...@aquaproperties.com ** (https://aquaproperties.com/) ** (https://www.facebook.com/aquaproperties) ** (https://www.instagram.com/aquapropertiesdubai/) ** (https://www.linkedin.com/company/aqua-properties) ** (https://twitter.com/aquaproperties) ** (https://aquaproperties.com/) Want to change how you receive these emails? You can ** update your preferences (https://aquaproperties.us18.list-manage.com/profile?u=57709ba3f7bfded8dfe1df62e&id=7ca9b7db8f&e=900c0908eb) or ** unsubscribe from this list (https://aquaproperties.us18.list-manage.com/unsubscribe?u=57709ba3f7bfded8dfe1df62e&id=7ca9b7db8f&e=900c0908eb&c=34d710fbf7) .
[GSOC] LTO dump tool project - feedback
Hi.
I decided to come up with a new sub-thread that will be linked
to a root of email discussion. First, thank you for working on
the project and there's a feedback that I can provide now:
1) options of lto-dump:
a) no-demangle - does not make sense because it's default
b) you should exit after one command, you probably don't want to support:
-list bzlib.o -tree-stats
c) following should be maybe handled:
$ lto-dump -list bzlib.o bzlib.o
bzlib.c:468:5: note: previously defined here
bzlib.c:407:5: error: ‘BZ2_bzCompress’ has already been defined
int BZ_API(BZ2_bzCompress) ( bz_stream *strm, int action )
^
bzlib.c:407:5: note: previously defined here
bzlib.c:148:5: error: ‘BZ2_bzCompressInit’ has already been defined
int BZ_API(BZ2_bzCompressInit)
d) you should add --help option, take a look at gcov-dump --help, or gcov
--help,
or gcov-tool --help.
e) alpha-sort - maybe name-sort, or alphabetic-sort?
2) output formatting
a) you mix usage of tabulars and fixed columns (%10d), please use the later
at all places
b) I see a lot of extra output when using the tool:
...
Reading object files: bzlib.o {GC start 2164k}
Reading the callgraph
Merging declarations
Reading summaries
Reading function bodies:
Performing interprocedural optimizations
in:BZ2_bzCompressEnd
in:BZ2_bzDecompressEnd
Assembling functions:
add_pair_to_block in:add_pair_to_block
default_bzfree in:default_bzfree default_bzalloc in:default_bzalloc
handle_compress.isra.2 in:handle_compress.isra.2 in:copy_output_until_stop
in:copy_input_until_stop BZ2_bz__AssertH__fail in:BZ2_bz__AssertH__fail
BZ2_bzCompressInit in:BZ2_bzCompressInit BZ2_bzCompress in:BZ2_bzCompress
BZ2_bzCompressEnd BZ2_bzDecompressInit in:BZ2_bzDecompressInit BZ2_indexIntoF
in:BZ2_indexIntoF BZ2_bzDecompress in:BZ2_bzDecompress
in:unRLE_obuf_to_output_SMALL in:unRLE_obuf_to_output_FAST {GC 5331k -> 2747k}
BZ2_bzDecompressEnd BZ2_bzWriteOpen in:BZ2_bzWriteOpen
in:BZ2_bzWriteOpen.part.3 BZ2_bzWrite in:BZ2_bzWrite in:BZ2_bzWrite.part.4
BZ2_bzWriteClose64 in:BZ2_bzWriteClose64 in:BZ2_bzWriteClose64.part.5
BZ2_bzWriteClose in:BZ2_bzWriteClose BZ2_bzReadOpen in:BZ2_bzReadOpen
in:BZ2_bzReadOpen.part.6 {GC 5332k -> 2307k} bzopen_or_bzdopen
in:bzopen_or_bzdopen BZ2_bzReadClose in:BZ2_bzReadClose
in:BZ2_bzReadClose.part.7 BZ2_bzRead in:BZ2_bzRead in:BZ2_bzRead.part.8
in:myfeof BZ2_bzReadGetUnused in:BZ2_bzReadGetUnused
in:BZ2_bzReadGetUnused.part.9 BZ2_bzBuffToBuffCompress
in:BZ2_bzBuffToBuffCompress BZ2_bzBuffToBuffDecompress
in:BZ2_bzBuffToBuffDecompress BZ2_bzlibVersion in:BZ2_bzlibVersion BZ2_bzopen
in:BZ2_bzopen BZ2_bzdopen in:BZ2_bzdopen BZ2_bzread in:BZ2_bzread
in:BZ2_bzread.part.10 BZ2_bzwrite in:BZ2_bzwrite BZ2_bzflush in:BZ2_bzflush
BZ2_bzclose in:BZ2_bzclose BZ2_bzerror in:BZ2_bzerror in:bzerrorstrings
...
please remove it
c) you mix all upper letters in header of lists, please unify that
(Visibility, SECTION NAME)
d) -gimple-stats does not work for me, no output and -tree-stats definitely
not print all trees used
e) you should not require -fdump-level for -fdump-body, select a default
value for the level please
f) why -fdump-level and -fdump-body start with '-f'
3) written source code
a) I need following patch to build it:
diff --git a/gcc/lto/lto-dump.c b/gcc/lto/lto-dump.c
index 9a1ff61852c..48fc7d9a181 100644
--- a/gcc/lto/lto-dump.c
+++ b/gcc/lto/lto-dump.c
@@ -370,4 +370,4 @@ lto_main (void)
timevar_push (TV_PARSE_GLOBAL);
}
-#include "gt-lto-lto.h"
+//#include "gt-lto-lto.h"
diff --git a/gcc/lto/lto.c b/gcc/lto/lto.c
index bc61d25f61d..301ed4b2e25 100644
--- a/gcc/lto/lto.c
+++ b/gcc/lto/lto.c
@@ -143,4 +143,4 @@ lto_main (void)
timevar_push (TV_PARSE_GLOBAL);
}
-#include "gt-lto-lto.h"
+//#include "gt-lto-lto.h"
can you please check it?
b) you added parse_dump_option, but it's used only in dump-lto.c, why not in
dumpfile.c?
c) lto-dump.c still contains a lot of code in lto_main that's not needed
(and is responsible
for extra output)
e) you moved all to lto-common.c, but functionality exclusively used only in
lto.c should remain there
f) you should probably dump to stdout, rather that stderr
g) there are still quite some functions in lto-dump.c that are missing
comment, lto_main comment should
be rewritten
4) misc
a) lto-dump should be installed with 'make install', similarly as lto1 is
b) lto-dump command option should be documentation, again take a look for
gcov-dump, gcov, gcov-tool (*.texi file)
c) would be nice to have some test-cases for that, but it's probably out of
scope of the project
d) I bet there will be quite some extra includes of header file in
lto-dump.c, please adjust file comment and
year of creation
Martin
Re: How to easily identify that a FUNCTION_DECL is a lambda
PING^1
On 07/18/2018 03:49 PM, Martin Liška wrote:
> On 07/18/2018 02:40 PM, Jason Merrill wrote:
>> On Wed, Jul 18, 2018 at 7:03 PM, Martin Liška wrote:
>>> On 07/18/2018 03:45 AM, Jason Merrill wrote:
On Mon, Jul 16, 2018 at 5:23 PM, Martin Liška wrote:
> For purpose of --coverage I would like to distinguish lambda functions
> among DECL_ARTIFICIAL functions.
I'm curious, why?
>>>
>>> It's important for GCOV to report coverage for functions that are
>>> really present in a source file. Lambdas are such functions.
>>> On the other hand functions like
>>> _Z41__static_initialization_and_destruction_*
>>> or some implicit constructors (Centering<3>::Centering(Centering<3> const&))
>>> should not be reported. It confuses a user. Note that both have a valid
>>> location and one can't distinguish them.
>>
>> Those other functions may have *a* location, but only
>> DECL_SOURCE_LOCATION; could we distinguish on that basis?
>>
>> Jason
>>
>
> I don't know how to distinguish them. Consider:
>
> type type align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
> 0x767c0f18
> pointer_to_this reference_to_this
> >
> QI
> size
> unit-size
> align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
> 0x7fffe82f62a0 method basetype
> arg-types 0x7fffe82af000>
> chain void>>>
> throws purpose >
> pointer_to_this >
> nothrow public static weak autoinline decl_3 decl_5 QI
> tramp3d-v4.cpp:867:7 align:16 warn_if_not_align:0 context 0x7fffe829abd0 BinaryNode> initial abstract_origin
>
> result 0x767c0f18 void>
> ignored VOID tramp3d-v4.cpp:867:7
> align:8 warn_if_not_align:0 context __dt_base >>
> full-name "BinaryNode double, UniformRectilinearTag, CartesianTag, 3> >, double, BrickView>,
> Scalar >::~BinaryNode() noexcept"
> pending-inline-info 0x7fffe8341510
> arguments type BinaryNode>
> readonly unsigned DI
> size
> unit-size
> align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
> 0x7fffe82af150>
> readonly unsigned read DI tramp3d-v4.cpp:34712:13 size 0x767a2e70 64> unit-size
> align:64 warn_if_not_align:0 context __dt_base > abstract_origin arg-type
> >
> struct-function 0x7fffe833e580 chain __dt_comp >>
>
> it's DECL_SOURCE_LOCATION is:
> $2 = 200862249
>
> and expand_location (DECL_SOURCE_LOCATION (current_function_decl)) is:
> (gdb) p xloc
> $1 = {
> file = 0x2a58df0 "tramp3d-v4.cpp",
> line = 867,
> column = 7,
> data = 0x0,
> sysp = false
> }
>
> Martin
>
Re: ChangeLog's: do we have to?
On Tue, Jul 31, 2018 at 08:18:33PM -0400, Trevor Saunders wrote: > And that's ignoring the much larger amount of busywork involved in > generating the changelog in the first place which if you follow the GNU > rules about describing the diff without explaining it is basically by > definition mechanical. The changelog *should* describe and explain the patch. It should not describe or explain why we want this patch and not another. Segher
gcc-6-20180801 is now available
Snapshot gcc-6-20180801 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/6-20180801/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-6-branch revision 263238 You'll find: gcc-6-20180801.tar.xzComplete GCC SHA256=e09814c2e8b16b2f6663406ee106f669d2c3005ca570a06d6827cadded3cdbc1 SHA1=9cb8736adb09e29d81f4629e9f4629e438a0f0f2 Diffs from 6-20180725 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-6 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
