Hi Friend,
How’s everything going? This is Jessica of WellSucceed Embroidery Limited
which is professional custom-made merchandise supplier of *Sony Music,
Warner Music and Universal Music. *
We have our embroidery, merchandise, headwear and clothing factories. I
appreciate your merchandise of
On Mon, 8 Apr 2024, 13:00 Matheus Afonso Martins Moreira via Gcc, <
gcc@gcc.gnu.org> wrote:
>
> Compiler support for system calls help by eliminating the need for the
> system call stub functions traditionally provided by these C libraries.
> There's no need to link against the C libraries just fo
> There is quite a bit of variance in how the kernel is entered.
I assume you mean the vDSO. It is also documented and stable.
https://www.kernel.org/doc/html/latest/admin-guide/abi-stable.html#vdso
> Unless otherwise noted, the set of symbols with any given version
> and the ABI of those symbol
> What's the advantage of the _1, _2 etc. forms?
Now that you mention it... I don't believe there are any.
> The compiler knows how many arguments you're passing,
> why can't there just be one built-in handling all cases?
You're right about that.
When I started working on this I just mirrored t
01-09 16:59
To: 钟居哲
CC: richard.guenther; rdapp.gcc; gcc
Subject: Re: RE: Loop vectorizer optimization questions
Hi,
The 01/08/2024 22:46, 钟居哲 wrote:
> Oh. It's nice to see you have support min/max index reduction.
>
> I knew your patch can handle this following:
>
>
>
Hi,
The 01/08/2024 22:46, 钟居哲 wrote:
> Oh. It's nice to see you have support min/max index reduction.
>
> I knew your patch can handle this following:
>
>
> int idx = ii;
> int max = mm;
> for (int i = 0; i < n; ++i) {
> int x = a[i];
> if (max < x) {
> max = x;
> idx = i;
> }
> }
Oh. It's nice to see you have support min/max index reduction.
I knew your patch can handle this following:
int idx = ii;
int max = mm;
for (int i = 0; i < n; ++i) {
int x = a[i];
if (max < x) {
max = x;
idx = i;
}
}
But I wonder whether your patch can handle this:
int idx = ii;
in
Since you mentioned windows 7 specifically, some of the suggestions
aren't really appropriate. I don't believe msys2 supports windows 7
anymore.
I'm also not the biggest fan of msys2, I think it brings in way too much
complexity for what it is. It's useful if you would like to obtain some
har
I am sure that Master GCC has much better VSETVL strategy than GCC-13.
And recent evaluation on our internal hardware, shows that master GCC overall
is worse than previous RVV GCC I open souce in:
https://github.com/riscv-collab/riscv-gcc/tree/riscv-gcc-rvv-next (rvv-next)
It's odd, since I thin
,
> V2QI
>
> There are 11 modes.
> Should I increase the number from 8 to 11?
It will just perform dynamic allocation, no need to adjust.
> Thanks.
>
>
> juzhe.zh...@rivai.ai
>
> From: Richard Biener
> Date: 2023-08-31 19:29
> To: juzhe.zh...@rivai.ai
>
Biener
Date: 2023-08-31 19:29
To: juzhe.zh...@rivai.ai
CC: gcc; richard.sandiford
Subject: Re: Re: Question about dynamic choosing vectorization factor for RVV
On Thu, 31 Aug 2023, juzhe.zh...@rivai.ai wrote:
> Hi. Thanks Richard and Richi.
>
> Now, I figure out how to choose sma
Hi, Richi.
>> I don't think that's "good" use of the API.
You mean I should use 'better_main_loop_than_p‘ ？
Yes. I plan to use it.
Thanks.
juzhe.zh...@rivai.ai
From: Richard Biener
Date: 2023-08-31 19:29
To: juzhe.zh...@rivai.ai
CC: gcc; richard.sandiford
,v4,v8
> sub a2,a2,a5
> vsetvli zero,a5,e32,m4,ta,ma
> vse32.v v4,0(a4)
> add a0,a0,a3
> add a1,a1,a3
> add a4,a4,a3
> bne a2,zero,.L3
>
> Fantastic architecture of GCC Vector Cost model!
>
> Thanks a lot.
>
>
> juzhe.zh...@rivai.ai
>
> From: Richard Bi
diford
Subject: Re: Re: Question about dynamic choosing vectorization factor for RVV
On Thu, 31 Aug 2023, juzhe.zh...@rivai.ai wrote:
> Thanks Richi.
>
> I am trying to figure out how to adjust finish_cost to lower the LMUL
>
> For example:
>
> void
> foo (int32_t *__res
On Thu, 31 Aug 2023, juzhe.zh...@rivai.ai wrote:
> Thanks Richi.
>
> I am trying to figure out how to adjust finish_cost to lower the LMUL
>
> For example:
>
> void
> foo (int32_t *__restrict a, int32_t *__restrict b, int n)
> {
> for (int i = 0; i < n; i++)
> a[i] = a[i] + b[i];
> }
>
>
Thanks Richi.
I am trying to figure out how to adjust finish_cost to lower the LMUL
For example:
void
foo (int32_t *__restrict a, int32_t *__restrict b, int n)
{
for (int i = 0; i < n; i++)
a[i] = a[i] + b[i];
}
preferred_simd_mode pick LMUL = 8 (RVVM8SImode)
Is is possible that we can a
On Wed, 30 Aug 2023, juzhe.zh...@rivai.ai wrote:
> I am wondering whether we do have some situations that
> vec_pack/vec_unpack/vec_widen_xxx/dot_prod pattern can be beneficial for RVV ?
> I have ever met some situation that vec_unpack can be beneficial when working
> on SELECT_VL but I don't wh
I am wondering whether we do have some situations that
vec_pack/vec_unpack/vec_widen_xxx/dot_prod pattern can be beneficial for RVV ?
I have ever met some situation that vec_unpack can be beneficial when working
on SELECT_VL but I don't which case
juzhe.zh...@rivai.ai
From: Robin Dapp
Da
Thanks Richi.
>> both same units would be sext, not vec_unpacks_{lo,hi} - the vectorizer
Sorry I made a mistake here. They are not the same nunits.
wrapv-vect-reduc-dot-s8b.c:29:14: note: get vectype for scalar type: short
int
wrapv-vect-reduc-dot-s8b.c:29:14: note: vectype: vector([8,8]) s
Hi,
After reading some of this discussion, I figured I should add my own support
for this proposal. It seems to me very few (none?) of the people arguing
against this change actually have a "horse in the race", and instead are
appealing to some theoretical ancient legacy code maintainer who is b
Thanks Martin! Sounds good; I submitted my proposal unchanged for now
(i.e assuming an independent project), but as Dave mentioned in
another thread, it may be divided into several logical components,
perhaps with certain features extended, to be suited for
collaboration.
Best,
Eric
On Mon, A
Hello,
On Mon, Apr 03 2023, Eric Feng via Gcc wrote:
> Hi Steven,
>
> I’m happy to collaborate on this project together — it would be great
> to have your experience with CPython internals on the team.
>
While I normally welcome collaboration, please note that GSoC rules and
reasonable caution di
Hi Steven,
I’m happy to collaborate on this project together — it would be great
to have your experience with CPython internals on the team.
> And by the way, I can get to work long before the start-coding time point of
> GSoC timeline.
I can be involved in some capacity before the start-codin
Dear Martin Liška
Thanks for your research. I have resolved this problem by pass a ddrsize
paramters when build and cacluate the offset used by -fasan-shadow-offset
according that parameter.
Thanks!
B.R.
tao.z...@amlogic.com
Address： Building E5, 2555 Xiupu Road, Pudong District, Shang
> -原始邮件-
> 发件人: "Matthias Klose"
> 发送时间: 2022-01-28 00:18:47 (星期五)
> 收件人: jia...@iscas.ac.cn, gcc@gcc.gnu.org, binut...@sourceware.org,
g...@sourceware.org, libc-al...@sourceware.org
> 抄送: cmuell...@ventanamicro.com, si...@isrc.iscas.ac.cn,
philipp.toms...@vrull.eu, nelson@sifive.
> On Mon, 13 Dec 2021 at 05:14, Andrew Pinski wrote:
> >
> > On Sun, Dec 12, 2021 at 9:04 PM Nayan Deshmukh via Gcc
> >wrote:
> > > #include
> > > #include
> > > #include
> > > struct A {
> > > int a;
> > > uint64_t b;
> > > int c = -1;
> > > };
> >
> > The question becomes is the above
Hello,
On Wed, 4 Aug 2021, John Ericson wrote:
> > Doesn't GCC automatically look for those commands in the --prefix
> > directory that you configure GCC with? Or is that only for native
> > compilers?
>
> It will search only if --with-*=... was not passed, and it will never
> prefix the quer
> > Hi all,
> >
> > I`m using GCC 9.3 AutoFDO and the old version create_gcov on arm64
> > and it works well. Actually it support not only LBR like mode but
> > also inst_retired even cycles event, which`s the early implementation
> > of AutoFDO[1]. There is no difference in output format of cr
Hi all,
I`m using GCC 9.3 AutoFDO and the old version create_gcov on arm64
and it works well. Actually it support not only LBR like mode but
also inst_retired even cycles event, which`s the early implementation
of AutoFDO[1]. There is no difference in output format of create_gcov
between LBR
On Wed, Nov 18, 2020 at 17:43 Bin wrote:
> "Bin.Cheng" 2020-11-18 17:43:39
>
> On Tue, Nov 10, 2020 at 3:04 PM 172060045 <172060...@hdu.edu.cn> wrote:
> >
> > Hi,
> >
> > Recently, I was interested in GCC AutoFDO optimization, which works by
> > sampling specific PMU event on production machine
On Tue, Nov 17, 2020 at 09:10:53PM +, Will Deacon wrote:
> On Tue, Nov 17, 2020 at 11:31:57AM -0800, Linus Torvalds wrote:
> > On Tue, Nov 17, 2020 at 11:25 AM Jakub Jelinek wrote:
> > >
> > > It would need to be typeof( (typeof(type)) (type) ) to not be that
> > > constrained on what kind of
Am Dienstag, den 17.11.2020, 11:31 -0800 schrieb Linus Torvalds:
> On Tue, Nov 17, 2020 at 11:25 AM Jakub Jelinek wrote:
> >
> > It would need to be typeof( (typeof(type)) (type) ) to not be that
> > constrained on what kind of expressions it accepts as arguments.
>
> Yup.
>
> > Anyway, it won'
On Tue, Nov 17, 2020 at 11:31:57AM -0800, Linus Torvalds wrote:
> On Tue, Nov 17, 2020 at 11:25 AM Jakub Jelinek wrote:
> >
> > It would need to be typeof( (typeof(type)) (type) ) to not be that
> > constrained on what kind of expressions it accepts as arguments.
>
> Yup.
>
> > Anyway, it won't
On Tue, Nov 17, 2020 at 11:13 AM Linus Torvalds
wrote:
>
> > +#define __unqual_typeof(type) typeof( (typeof(type))type )
>
> that's certainly a much nicer version than the existing pre-processor
> expansion from hell.
Oh, and sparse doesn't handle this, and doesn't remove any qualifiers
for the
On Tue, Nov 17, 2020 at 11:25 AM Jakub Jelinek wrote:
>
> It would need to be typeof( (typeof(type)) (type) ) to not be that
> constrained on what kind of expressions it accepts as arguments.
Yup.
> Anyway, it won't work with array types at least,
> int a[10];
> typeof ((typeof (a)) (a)) b;
On Tue, Nov 17, 2020 at 11:13:52AM -0800, Linus Torvalds wrote:
> > +#define __unqual_typeof(type) typeof( (typeof(type))type )
> that's certainly a much nicer version than the existing pre-processor
> expansion from hell.
It would need to be typeof( (typeof(type)) (type) ) to not be that
constr
On Mon, Nov 16, 2020 at 3:11 AM Peter Zijlstra wrote:
>
> XXX: I've only verified the below actually compiles, I've not verified
> the generated code is actually 'correct'.
Well, it was mainly the arm64 code generation for load-acquire and
store-release that wanted this - so it's really the
On Mon, Nov 16, 2020 at 12:23:17PM +, Uecker, Martin wrote:
> > > > Another way to drop qualifiers is using a cast. So you
> > > > can use typeof twice:
> > > >
> > > > typeof((typeof(_var))_var) tmp__;
> > > >
> > > > This also works for non-scalars but this is a GCC extension.
>
> (That c
Am Montag, den 16.11.2020, 12:10 +0100 schrieb Peter Zijlstra:
> ( restoring at least linux-toolcha...@vger.kernel.org, since that
> seems
> to have gone missing )
>
> On Mon, Nov 16, 2020 at 10:11:50AM +0100, Richard Biener wrote:
> > On Sun, Nov 15, 2020 at 11:53 AM Uecker, Martin
> > wrote
On Mon, Nov 16, 2020 at 12:10:56PM +0100, Peter Zijlstra wrote:
> > > Another way to drop qualifiers is using a cast. So you
> > > can use typeof twice:
> > >
> > > typeof((typeof(_var))_var) tmp__;
> > >
> > > This also works for non-scalars but this is a GCC extension.
FWIW, clang seems to supp
( restoring at least linux-toolcha...@vger.kernel.org, since that seems
to have gone missing )
On Mon, Nov 16, 2020 at 10:11:50AM +0100, Richard Biener wrote:
> On Sun, Nov 15, 2020 at 11:53 AM Uecker, Martin
> wrote:
> > > On Wed, Nov 04, 2020 at 07:31:42PM +0100, Uros Bizjak wrote:
> > > >
On Sun, Nov 15, 2020 at 11:53 AM Uecker, Martin
wrote:
>
>
> > On Wed, Nov 04, 2020 at 07:31:42PM +0100, Uros Bizjak wrote:
> > > Hello!
> > >
> > > I was looking at the recent linux patch series [1] where segment
> > > qualifiers (named address spaces) were introduced to handle percpu
> > > varia
> On Wed, Nov 04, 2020 at 07:31:42PM +0100, Uros Bizjak wrote:
> > Hello!
> >
> > I was looking at the recent linux patch series [1] where segment
> > qualifiers (named address spaces) were introduced to handle percpu
> > variables. In the patch [2], the author mentions that:
> >
> > --q--
> > U
Hi,
On Wed, Jul 15 2020, Erick Ochoa wrote:
> On 15.07.20 05:03, Martin Jambor wrote:
[...]
>> At IPA time, the best way is always to look at the call graph edges,
>> something like:
>>
>> cgraph_edge *cs = caller_cgraph_node->get_edge (s);
>> examine (e->callee);
>>
>> Note that if th
On 15.07.20 05:03, Martin Jambor wrote:
Hi,
On Tue, Jul 14 2020, Erick Ochoa wrote:
On 14/07/2020 12:37, Erick Ochoa wrote:
Hello,
I have a function foo defined on a source file. Sometimes, a function
pointer pointing to foo is passed as a parameter to other functions
where foo is called i
On Wed, 2020-06-17 at 15:10 +0800, Shuai Wang via Gcc wrote:
> Dear Martin,
>
> Thanks for the information. I am tentatively experimenting some random
> gadgets; given the critical if condition belonging to each sanitizer check,
> i will do some data flow analysis and then decide whether to remove
On Wed, Jun 17, 2020 at 4:11 AM Shuai Wang via Gcc wrote:
>
> Hello,
>
> Suppose I have changed certain if condition in the GIMPLE code (generated
> by the `sanopt` pass) into the following format:
>
> if (0 == 1)
> {
>
> }
>
> Then, in order to completely remove this unnecessary if condit
On 6/17/20 9:10 AM, Shuai Wang wrote:
Dear Martin,
Thanks for the information. I am tentatively experimenting some random gadgets;
given the critical if condition belonging to each sanitizer check, i will do
some data flow analysis and then decide whether to remove that check or not
(done). I
Dear Martin,
Thanks for the information. I am tentatively experimenting some random
gadgets; given the critical if condition belonging to each sanitizer check,
i will do some data flow analysis and then decide whether to remove that
check or not (done). If so, I will rewrite that if condition into
On 6/17/20 9:00 AM, Shuai Wang wrote:
Dear Martin,
Thanks for the kind reply.
Hey.
You're welcome.
I don't have a strong preference between `asan0` vs. `sanopt`. But I note that
I am primarily working on sanitizer enabled code, where I can only find some
.ASAN_CHECK function calls in `asa
Dear Martin,
Thanks for the kind reply. I don't have a strong preference between `asan0`
vs. `sanopt`. But I note that I am primarily working on sanitizer enabled
code, where I can only find some .ASAN_CHECK function calls in `asan0`, but
those function calls seem have been inlined in `sanopt`. In
On 6/17/20 4:10 AM, Shuai Wang via Gcc wrote:
Hello,
Suppose I have changed certain if condition in the GIMPLE code (generated
by the `sanopt` pass) into the following format:
Hello.
What kind of instrumentation are you doing? Can you make the instrumentation
in a ASAN pass? Then you'll go th
On Sun, 2020-03-01 at 23:48 +0800, y...@bupt.edu.cn wrote:
> Hello, David!
>
> It's so excited to receive a reply from you directedly. My name is
> Beenle, an undergraduate student in Beijing, China.
Hello Beenle.
> I've read the analyzer internal documentation, but I'm not sure I
> understoo
Hello, David!
It's so excited to receive a reply from you directedly. My name is Beenle, an
undergraduate student in Beijing, China.
I've read the analyzer internal documentation, but I'm not sure I understood
well. The following are my thoughts about the analyzer and I’m not sure they
are
Hi Jakub,
I think the current semaphore sleep system ought to be improved.
I'm not sure how but since the GSoC deadline is approaching I'll just post the
results without the semaphores.
Instead of sleeping on a per-task basis (for example there are depend waits,
task waits, taskgroup waits etc..)
> I thought we don't want to go lock-free, the queue operations > aren't easily
> implementable lock-free, but instead with a lock for each of > the queues,
Hi,
By lock-free I meant to use locks only for the queues,
But my terminology was indeed confusing sorry about that.
> mean we don't in so
On Sat, Aug 03, 2019 at 06:11:58PM +0900, 김규래 wrote:
> I'm currently having trouble implementing the thread sleeping mechanism when
> the queue is out of tasks.
> Problem is, it's hard to maintain consistency between the thread sleeping
> routine and the queues.
> See the pseudocode below,
>
>
Hi,
I'm currently having trouble implementing the thread sleeping mechanism when
the queue is out of tasks.
Problem is, it's hard to maintain consistency between the thread sleeping
routine and the queues.
See the pseudocode below,
1. check queue is empty
2. go to sleep
if we go lock-free, th
wanted to be sure that's the general case.
Thanks.
Ray Kim
-Original Message-
From: "Jakub Jelinek"
To: "김규래";
Cc: ;
Sent: 2019-07-23 (화) 03:54:13 (GMT+09:00)
Subject: Re: Re: [GSoC'19, libgomp work-stealing] Task parallelism runtime
On Sun, Jul 21, 2019 a
On Sun, Jul 21, 2019 at 04:46:33PM +0900, 김규래 wrote:
> About the snippet below,
>
> if (gomp_barrier_last_thread (state))
> {
> if (team->task_count == 0)
> {
> gomp_team_barrier_done (&team->barrier, state);
> gomp_mutex_unlock (&team->task_lock);
> gomp_team_barrier_wake (&
Hi Jakub,
About the snippet below,
if (gomp_barrier_last_thread (state))
{
if (team->task_count == 0)
{
gomp_team_barrier_done (&team->barrier, state);
gomp_mutex_unlock (&team->task_lock);
gomp_team_barrier_wake (&team->barrier, 0);
return;
}
gomp_team_barrier_set_wa
unsubscribe
On Mon, Jun 24, 2019, at 3:55 PM, 김규래 wrote:
> Hi,
> I'm not very familiar with the gomp plugin system.
> However, looking at 'GOMP_PLUGIN_target_task_completion' seem like
> tasks have to go in and out of the runtime.
> In that case, is it right that the tasks have to know from which
On Tue, Jul 09, 2019 at 09:56:00PM +0900, 김규래 wrote:
> Hi,
> This is an update about my status.
> I've been working on unifying the three queues into a single queue.
> I'm almost finished and passed all the tests except for the dependency
> handling part.
For dependencies, I can imagine taking a
On Tue, Jun 25, 2019 at 04:55:17AM +0900, 김규래 wrote:
> I'm not very familiar with the gomp plugin system.
> However, looking at 'GOMP_PLUGIN_target_task_completion' seem like tasks have
> to go in and out of the runtime.
> In that case, is it right that the tasks have to know from which queue they
RFQ-SPRAYWAY TPR CO., LTD.xlsx
Description: Binary data
On 02/17/2017 05:09 AM, Thomas Schwinge wrote:
> On Fri, 17 Feb 2017 14:00:09 +0100, I wrote:
>> [...] for "normal" functions there is no reason to use the
>> ".param" space for passing arguments in and out of functions. We can
>> then get rid of the boilerplate code to move ".param %in_ar*" into
Opened as bug 78839
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78839
From: Jakub Jelinek [ja...@redhat.com]
Sent: Friday, December 16, 2016 6:03 PM
To: Tom O'Connor
Cc: gcc@gcc.gnu.org
Subject: EXTERNAL: Re: DWARF output different between GCC 5 and 6
On F
> I'd probably create a new exception handling model and conditionalize
> whatever code you need based on that.
That would require copy-n-paste of tons of code...
All this remains contingent on Microsoft's generosity because
they don't provide APIs for SEH on x86, unlike on x64.
So I have to reu
mcfgthread isn't a pthread implementation. Roughly, gthread is a subset of
pthread.
The gthread interfaces are defined in , which should be part of
libstdc++ headers installed.
The history of mcfgthread is a long story... Well, please bear with me.
Once upon a time I was compiling libcxx with l
On Mon, May 9, 2016 at 4:10 PM, Andrew Pinski wrote:
> This sounds like a good use of --with-build-sysroot instead of just
> --with-sysroot.
> I use the following for the candian cross:
> --with-sysroot=/ --with-build-sysroot=${SYSROOT}
Hi Andrew! Thanks for your comment.
I thought that --with-b
relocation problem.
--
Best regards,
lh_mouse
2016-05-10
-
发件人：Brett Neumeier
发送日期：2016-05-10 04:31
收件人：lh_mouse
抄送：Jonathan Wakely,gcc
主题：Re: Re: GCC 6.1 Hard-coded C++ header paths and relocation problem on Windows
On Tue, May 3, 2016 at
--
Best regards,
lh_mouse
2016-05-10
-
发件人：Andrew Pinski
发送日期：2016-05-10 05:10
收件人：Brett Neumeier
抄送：lh_mouse,Jonathan Wakely,gcc
主题：Re: Re: GCC 6.1 Hard-coded C++ header paths and relocation problem on Windows
On Mon
On Mon, May 9, 2016 at 1:31 PM, Brett Neumeier wrote:
> On Tue, May 3, 2016 at 10:01 AM, lh_mouse wrote:
>> Should I file a bug report then?
>> We need some Linux testers, though not many people on Linux relocate
>> compilers.
>
> For what it's worth -- I encountered the same problem on a GNU/Li
On Tue, May 3, 2016 at 10:01 AM, lh_mouse wrote:
> Should I file a bug report then?
> We need some Linux testers, though not many people on Linux relocate
> compilers.
For what it's worth -- I encountered the same problem on a GNU/Linux
system. In my specific situation, I'm cross-compiling GCC u
Should I file a bug report then?
We need some Linux testers, though not many people on Linux relocate compilers.
--
Best regards,
lh_mouse
2016-05-03
-
发件人：Jonathan Wakely
发送日期：2016-05-03 1
Richard, thanks for explanation. I found an option
-fmerge-all-constants, which can help me work around for now.
BIngfeng
On Thu, Apr 21, 2016 at 11:15 AM, Richard Biener
wrote:
> On Thu, Apr 21, 2016 at 11:39 AM, Jonathan Wakely
> wrote:
>> On 21 April 2016 at 03:41, lh_mouse wrote:
>>> See t
On Thu, Apr 21, 2016 at 11:39 AM, Jonathan Wakely wrote:
> On 21 April 2016 at 03:41, lh_mouse wrote:
>> See this example: http://coliru.stacked-crooked.com/a/048b4aa5046da11b
>>
>> In this example the function is called recursively.
>
> See the original email you replied to:
>
> "I understand if
On 21 April 2016 at 03:41, lh_mouse wrote:
> See this example: http://coliru.stacked-crooked.com/a/048b4aa5046da11b
>
> In this example the function is called recursively.
See the original email you replied to:
"I understand if this function is recursive and pointer of the array
is involved, GCC
I agree with you on this example.
But in my original code, as Jonathan pointed out, is not recursive and
the address of "a" does not escape the function in any way. I believe
it is valid transformation.
BTW, LLVM compiles your example still by moving const array to rodata,
which I think is wrong
See this example: http://coliru.stacked-crooked.com/a/048b4aa5046da11b
In this example the function is called recursively.
During each call a pointer to that local areay is appended to a static array of
pointers.
Should a new instance of that local array of const int be created every time,
abort
One more question about block-scoped static objects:
>From compiled assembly I have learned that GCC uses a 64-bit integer guard to
>ensure once-initialization of static objects with block scopes.
Code in gcc/libstdc++-v3/libsupc++/guard.cc uses a global mutex to protect
multiple threads from ra
Thanks to ktietz, Elieux, mingwandroid (via IRC) and jwakely (via mail),
the integration of mcfgthread and gcc has been accomplished.
This 9000- patch applies to the gcc-5-branch after all other patches from
https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-gcc-git are
applied.
Aft
>>> If the current code assumes a struct and the Windows API calls need an
>>> integer then either the existing code needs to be made more flexible,
>>> or you need to define it as a struct and then convert to an integer
>>> inside your new gthread wrapper functions.
>>
>> The Windows APIs involved
On 18 April 2016 at 10:57, Jonathan Wakely wrote:
> On 18 April 2016 at 10:18, lh_mouse wrote:
>>> I don't see why it has to be a struct, it just has to be suitable as
>>> an argument to the relevant __gthread functions.
>>
>> The type __gthread_time_t is referenced in
>> gcc/libstdc++-v3/include/
On 18 April 2016 at 10:18, lh_mouse wrote:
>> I don't see why it has to be a struct, it just has to be suitable as
>> an argument to the relevant __gthread functions.
>
> The type __gthread_time_t is referenced in
> gcc/libstdc++-v3/include/std/mutex:157
> __gthread_time_t __ts = {
>
> I don't see why it has to be a struct, it just has to be suitable as
> an argument to the relevant __gthread functions.
The type __gthread_time_t is referenced in
gcc/libstdc++-v3/include/std/mutex:157
__gthread_time_t __ts = {
static_cast(__s.time_since_epoch().count()),
-
发件人：Jonathan Wakely
发送日期：2016-04-18 16:59
收件人：lh_mouse
抄送：gcc,mingw-w64-public
主题：Re: Re: Adding a new thread model to GCC
On 18 April 2016 at 08:39, lh_mouse wrote:
> I have added a thread model and added its corresponding header files. But
On 18 April 2016 at 08:39, lh_mouse wrote:
> I have added a thread model and added its corresponding header files. But it
> failed the linker.
>
> The file 'gcc/libgcc/config/i386/t-mingw-pthread' which contained two lines:
> SHLIB_PTHREAD_CFLAG = -pthread
> SHLIB_PTHREAD_LDFLAG = -Wl,-lpthrea
On 17 April 2016 at 17:56, lh_mouse wrote:
> A glance over gthr.h reminds me __gthread_time_t. There seem few requirements
> documented in gthr.h.
> I discussed this with Adrien Nader on mingw-w64's mailing list a few days ago.
>
> Specifically, here are the two questions:
> 0) Should __gthread_t
I have added a thread model and added its corresponding header files. But it
failed the linker.
The file 'gcc/libgcc/config/i386/t-mingw-pthread' which contained two lines:
SHLIB_PTHREAD_CFLAG = -pthread
SHLIB_PTHREAD_LDFLAG = -Wl,-lpthread
I copied the file to 'gcc/libgcc/config/i386/t-ming
A glance over gthr.h reminds me __gthread_time_t. There seem few requirements
documented in gthr.h.
I discussed this with Adrien Nader on mingw-w64's mailing list a few days ago.
Specifically, here are the two questions:
0) Should __gthread_time_t be a struct or a plain integral type?
The 'struct
On Thu, 2016-04-14 at 10:24 +0800, lh_mouse wrote:
> Yes I learnt those *ByAddress* functions a few months ago and was shocked
> that Microsoft had plagiarized futex from Linux.
> As you have pointed out already, those APIs are only available on Windows 8
> and later.
Yes. On Windows 8, given
f
it.
--
Best regards,
lh_mouse
2016-04-14
-
发件人：Dongsheng Song
发送日期：2016-04-14 11:02
收件人：lh_mouse
抄送：Torvald Riegel,gcc,mingw-w64-public
主题：Re: Re: Adding a new thread model to GCC
Currently, --enable-threads=win32 map to
Currently, --enable-threads=win32 map to gthr-win32.{h|c}, could we map
--enable-threads=win32-vista
--enable-threads=win32-win7 // Windows 7 and Windows Server 2008 R2
--enable-threads=win32-win8 // Windows 8 and Windows Server 2012
--enable-threads=win32-win8.1 // Windows 8.1 and Windows Ser
Yes I learnt those *ByAddress* functions a few months ago and was shocked that
Microsoft had plagiarized futex from Linux.
As you have pointed out already, those APIs are only available on Windows 8
and later.
If we need fuex semantics on Windows 7 and earlier, we must simulate it.
However, sin
Thanks for your reply. :>
However I am still having problems building GCC. (Yesterday stage 1 was ok, but
during stage 2 autoconf just failed to find any standard headers. I am still
struggling with it.)
Once I build gcc successfully I will have a look at that configure.ac. Wish me
luck. (btw t
On 31/03/16 23:23, Jonathan Wakely wrote:
On 31 March 2016@21:10, Daniel Gutson wrote:
Hi,
many times we copy code snippets from sources that change the
Unicode quotation marks ( “ ” ) rather than " ". For example
const std::string a_string(“Hello”);
That line looks innocent but
I apologize for stating that you had reported the issue. I copy/pasted from
your comment rather than the original report.
The issue was reported by Teodor Petrov
Kevin
"Manuel López-Ibáñez" wrote:
> > On 03/28/2016 01:56 PM, Florian Weimer wrote:
> >>> In Bugzilla PR # 70275, Manuel Lóp
On 03/28/2016 01:56 PM, Florian Weimer wrote:
In Bugzilla PR # 70275, Manuel López-Ibáñez reports that even though
he provides the "-Werror=return-type" option, the compiler doesn't
flag the warning/error about a control reaching the end of a non-void
function, due to the presence of the "-w" opt
Since this is still a problem with new versions of GCC would it be
welcomed if i tried making a solution that generated a switch statement
where ever a big list of || expressions would be generated?
I have a solution now that does generate a working switch but the
formatting of completely off
1 - 100 of 242 matches
Mail list logo
