> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> Jiangning Liu
> Sent: Tuesday, December 27, 2011 5:10 PM
> To: 'Richard Guenther'
> Cc: Michael Matz; gcc@gcc.gnu.org
> Subject: RE: A case exposing code sink
> -Original Message-
> From: Jiangning Liu
> Sent: Wednesday, December 28, 2011 5:38 PM
> To: Jiangning Liu; 'Richard Guenther'
> Cc: Michael Matz; gcc@gcc.gnu.org
> Subject: RE: A case exposing code sink issue
>
>
>
> > -Original M
> >> > In final value replacement, expression "&a + D." can be
> figured
> >> out,
> >> > while "&a[i_xxx]" failed to be CHRECed, so I'm wondering if we
> should
> >> > lower
> >> > &a[i_xxx] to "&a + unitsize(a) * i_xxx" first? It seems GCC
> intends
> >> to
> >> > keep
> >> > &a[i_xxx] until
> -Original Message-
> From: Richard Guenther [mailto:richard.guent...@gmail.com]
> Sent: Thursday, January 05, 2012 5:32 PM
> To: Jiangning Liu
> Cc: Michael Matz; gcc@gcc.gnu.org
> Subject: Re: A case exposing code sink issue
>
> On Thu, Jan 5, 2012 at 9:34 AM
Hi,
I wanted to use bb->count, so I expected that -fprofile-arcs and
-fbranch-probabilities would help. I added printf just before
peephole2 optimization and ran the following.
$gcc -O3 -fprofile-arcs test.c -o test
$./test (which produced test.gcno only, but no test.gcda)
$gcc -O3 -fprofile-arcs
, I can do some configuration, so that
the executable will be able to output to Host PC through normal fputs
or fwrite.
So is it feasible that I can make executable to output gcda file to my
Host PC via fputs or fwrite?
Regards,
Haibin
On 2/21/06, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
&g
Hi,
For this small test case,
int *l, *r;
int test_func(void)
{
int i;
int direction;
static int pos;
pos = 0;
direction = 1;
for ( i = 0; i <= 400; i++ )
{
if ( direction == 0 )
pos = l[pos];
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> Jiangning Liu
> Sent: Friday, February 17, 2012 5:53 PM
> To: gcc@gcc.gnu.org
> Subject: A problem about loop store motion
>
> Hi,
>
> For this small tes
> The MEM form is more "canonical", so the loop SM machinery to detect
> equality should be adjusted accordingly. Alternatively you can teach
> PRE insertion to strip off the MEM if possible (though
> fold_stmt_inplace should
> arelady do this if possible).
Richard,
Thank you! You are right. I n
> -Original Message-
> From: Richard Guenther [mailto:richard.guent...@gmail.com]
> Sent: Tuesday, February 21, 2012 5:40 PM
> To: Jiangning Liu
> Cc: gcc@gcc.gnu.org
> Subject: Re: A problem about loop store motion
>
> On Tue, Feb 21, 2012 at 9:54 AM, Jiangnin
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> Richard Guenther
> Sent: Tuesday, February 21, 2012 6:19 PM
> To: Jiangning Liu
> Cc: gcc@gcc.gnu.org
> Subject: Re: A problem about loop store motion
>
> On Tu
Hi,
For the small case below, there are some redundant PHI expression stmt
generated, and finally cause back-end generates redundant copy instructions
due to some reasons around IRA.
int *l, *r, *g;
void test_func(int n)
{
int i;
static int j;
static int pos, direction, di
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> William J. Schmidt
> Sent: Monday, February 27, 2012 11:32 PM
> To: Jiangning Liu
> Cc: gcc@gcc.gnu.org; wschm...@gcc.gnu.org
> Subject: Re: A question about redundan
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> Jiangning Liu
> Sent: Tuesday, February 28, 2012 11:19 AM
> To: 'William J. Schmidt'
> Cc: gcc@gcc.gnu.org; wschm...@gcc.gnu.org
> Subject: RE: A question abou
> -Original Message-
> From: Jiangning Liu
> Sent: Tuesday, February 28, 2012 4:07 PM
> To: Jiangning Liu; 'William J. Schmidt'
> Cc: gcc@gcc.gnu.org; wschm...@gcc.gnu.org
> Subject: RE: A question about redundant PHI expression stmt
>
>
>
> &g
Hi,
For this small case,
char garr[100];
void f(void)
{
unsigned short h, s;
s = 20;
for (h = 1; h < (s-1); h++)
{
garr[h] = 0;
}
}
After copyrename3, we have the following dump,
f ()
{
short unsigned int h;
int D.4066;
:
D.4066_
Hi,
Why can't we replace function force_expr_to_var_cost directly with function
computation_cost in tree-ssa-loop-ivopt.c?
Actually I think it is inaccurate for the current recursive algorithm in
force_expr_to_var_cost to estimate expr cost. Instead computation_cost can
count some back-end factor
> -Original Message-
> From: Richard Guenther [mailto:richard.guent...@gmail.com]
> Sent: Tuesday, May 15, 2012 10:17 PM
> To: Zdenek Dvorak
> Cc: Jiangning Liu; gcc@gcc.gnu.org; Jiangning Liu
> Subject: Re: A question about loop ivopt
>
> On Tue, May 15, 2012 a
> -Original Message-
> From: Richard Guenther [mailto:richard.guent...@gmail.com]
> Sent: Tuesday, May 22, 2012 6:36 PM
> To: Jiangning Liu
> Cc: Zdenek Dvorak; Jiangning Liu; gcc@gcc.gnu.org
> Subject: Re: A question about loop ivopt
>
> On Tue, May 22, 2012 at
Hello,
Would it be possible to have fix for PR 55171 backported to 4.6 branch?
I am having an issue with the attached test case not working using
MinGW-w64 GCC 4.6.3 64-bit.
Thanks.
Regards,
Jonathan
class Base {
public:
virtual ~Base() { }
};
class Derived : public Base
{
public:
De
I noticed that in fortran/convert.c the convert() function calls
convert_to_vector() if the target type is VECTOR_TYPE. When is that
function triggered in Fortran frontend? Since Fortran language doesn't
support vector type, why does it convert something to a vector expression?
Thanks!
Sa
t; : "(FAIL)");
printf(" %e / %e = %e\n", a.f, b.f, z.f);
}
int main()
{
union fu fa,fb,fe;
fa.u = 0xc0843fff;
fb.u = 0x80ff;
fe.u = 0x7f044000;
fdiv(fa,fb,fe);
}
---
Signed-off-by: Liu Yu <[EMAIL PROTECTED]>
---
gcc/l
There are 2 bugs existing in __udiv_qrnnd_c:
1. remainder could not be counted correctly
__r1 and __r0 are not adding enough, so I use do..while to replace
former if
2. the case of overflow of __m are not considered
so I add a couple of lines to handle it
I found the bugs from Linux kernel,
for
Hi Ian,
Thanks a lot for your detailed explanation.
> -Original Message-
> From: Ian Lance Taylor [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 13, 2008 1:45 PM
> To: Liu Yu
> Cc: gcc@gcc.gnu.org
> Subject: Re: [PATCH] Fix bug on soft emulation of float point
&
I have a question regarding GCC4 version compatibility? In general,
should two versions with same major version number be compatible?
Specifically, I want to confirm whether a C++ library built with gcc
4.1.X will link correctly using gcc 4.2.2?
Thanks,
Xiaoxiang
The advisory tool aims to give high-level suggestions, mostly focuses on
the access pattern and size of STL.
Such as, shown in example, we want to decide the right initial size for
the container to reduce execution time as much as possible.
Another case is we can suggest that a hash-map is more
Hi,
I'm working on GCC 4.1.1 on spu target and get following problem:
After splitting an insn with a note REG_LIBCALL, the insn is replaced by
some other insns, which don't attach REG_LIBCALL note any more, and the
original one is then deleted. While the insn REG_RETVAL still points to
the LIB
Hi all,
I have detected a bug in C++ frontend.
When compiling a function with parameter of a pointer to a vector constant
type, the compiler calls a recursive function and is not able to get out.
Concretely, in gcc/cp/mangle.c file, in function write_type:
if (write_CV_qualifiers_for_type
"Andrew Pinski" <[EMAIL PROTECTED]> wrote on 02.08.2007 19:36:30:
> This used to work. Can you file a bug at the very least?
>
> Thanks,
> Andrew Pinski
I have opened a bug against it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32970
Sa
Ian Lance Taylor <[EMAIL PROTECTED]> wrote on 03.08.2007 17:24:45:
> Thanks. The general idea looks right, but the implementation is
> incorrect.
>
Thank you! I have made the correction:
Index: gcc/emit-rtl.c
===
--- gcc.orig/emit
Ian Lance Taylor <[EMAIL PROTECTED]> wrote on 30.07.2007 18:59:28:
> If the compiler splits an insn with a REG_LIBCALL note, it needs to
> remove the corresponding REG_RETVAL note, or it needs to relink the
> insns. This looks like a compiler bug, in that try_split doesn't
> handle REG_LIBCALL no
"Andrew Pinski" <[EMAIL PROTECTED]> wrote on 02.08.2007 19:36:30:
> On 8/2/07, Sa Liu <[EMAIL PROTECTED]> wrote:
> > Hi all,
> >
> > I have detected a bug in C++ frontend.
>
> This used to work. Can you file a bug at the very least?
>
Hi
up the performance on Itanium in order to keep
its competitiveness.
Regards,
Shin-Ming Liu
Wen-mei W. Hwu wrote:
I agree with Vladimir wholeheartedly. After working on OpenIMPACT for
years, I reached the conclusion that the ONLY way to make a real
difference
for Linux Itanium users is to
On Tue, May 26, 2020 at 6:49 AM Jakub Jelinek via Gcc-patches
wrote:
>
> Hi!
>
> I've turned the strict mode of Martin Liška's hook changes,
> which means that from now on no commits to the trunk or release branches
> should be changing any ChangeLog files together with the other files,
> ChangeLo
Great, thanks!
On Tue, May 26, 2020 at 2:08 PM Martin Liška wrote:
>
> On 5/26/20 7:22 AM, Hongtao Liu via Gcc wrote:
> > i commit a separate patch alone only for ChangeLog files, should i revert
> > it?
>
> Hello.
>
> I've just done it.
>
> Martin
--
BR,
Hongtao
在 2020/5/29 18:35, Andreas Schwab 写道:
> On Mai 29 2020, David Brown wrote:
>
>> So my counter-proposal for you would be to recommend gcc's "typeof" as a
>> new keyword (spelt "_Typeof", with "typeof" as a macro in ,
>> in solid C tradition).
>
> Or call it _Decltype/decltype, following C++.
>
>
在 2020/8/11 下午9:55, Nathan Sidwell 写道:
>
> I agree, it's the way I use auto. I particularly like the
> auto *foo = expr;
> idiom, when you're getting a pointer, but the type of the pointee is clear.
> It informs how you use 'foo'.
>
>
Personally I dislike this syntax. Pointers are objects
在 2020/8/13 上午2:40, David Blaikie 写道:
>
> Then use of `auto*` would make it easier for you to spot use of plain
> pointers in your projects & scrutinize them further?
>
My point is that `auto*` conveys no more information than `auto`. The absence
of `*` does not imply the object (pointer)
being
在 2020/11/19 上午2:31, sotrdg sotrdg via Gcc 写道:
> The locale shit is not thread safe. printf(“Hello World %d”,3) is undefined
> behavior under none-UTF-8 exec-charset. WTF WTF WTF.
>
> This is purely garbage tbh. Just remove this toggle. I want encoding, I can
> use another library. I do not need
在 2020/11/27 上午7:50, Jonathan Wakely via Gcc 写道:
> I've touched on the subject a few times, e.g.
> https://gcc.gnu.org/pipermail/gcc/2019-December/230993.html
> and https://gcc.gnu.org/pipermail/gcc/2019-December/231013.html
>
> Libstdc++ code is indented by 2 columns for the enclosing namespace,
在 2020/11/27 下午4:14, Richard Biener 写道:
>
> I prefer the ( on the next line. The argument list can be two spaces
> indented from
> the function name or "right justified" (I think the latter looks
> visually better).
>
The right justification thing looks reasonable. For example, I think this
``
On Mon, Dec 7, 2020 at 5:47 PM Richard Biener wrote:
>
> On Mon, 7 Dec 2020, Prathamesh Kulkarni wrote:
>
> > On Mon, 7 Dec 2020 at 13:01, Richard Biener wrote:
> > >
> > > On Mon, 7 Dec 2020, Prathamesh Kulkarni wrote:
> > >
> > > > On Fri, 4 Dec 2020 at 17:18, Richard Biener wrote:
> > > > >
>
On Mon, Dec 7, 2020 at 7:11 PM Prathamesh Kulkarni
wrote:
>
> On Mon, 7 Dec 2020 at 16:15, Hongtao Liu wrote:
> >
> > On Mon, Dec 7, 2020 at 5:47 PM Richard Biener wrote:
> > >
> > > On Mon, 7 Dec 2020, Prathamesh Kulkarni wrote:
> > >
> > >
>
> > On Mon, 7 Dec 2020 at 17:37, Hongtao Liu wrote:
> > >
> > > On Mon, Dec 7, 2020 at 7:11 PM Prathamesh Kulkarni
> > > wrote:
> > > >
> > > > On Mon, 7 Dec 2020 at 16:15, Hongtao Liu wrote:
> > > > >
> > > &g
在 2021/1/14 上午9:47, Roy Qu via Gcc 写道:
> I use "gcc -finput-charset=utf-8 -fexec-charset=gb2312" to compile utf-8
> encoding source files under windows. Most of the time it works well, but
> when the source file contains some characters such as "—", gcc will fail
> and the error message is: "[Err
regards,
Liu Hao
OpenPGP_signature
Description: OpenPGP digital signature
nese society and has almost eradicated sexism. It's something I can hardly understand why you
(singular) still have a very vicious opinion on that.
[I am not meant to participate in the discussion about the history and future
of GCC.]
--
Best regards,
Liu Hao
OpenPGP_signature
Des
table, and whether a disclaimer from an employer is
needed, doesn't need to be done in public. The contributor might not want to discuss who their
employer is on the public list, for example.
Thanks for your information.
--
Best regards,
Liu Hao
OpenPGP_signature
Description:
在 17/04/2021 16.27, Aaron Gyes 写道:
As far as I understand it Chris Punches lives in North America.
Only 2% of the world population lives in the US, indeed, most live in China.
It’s interesting the unkind reaction Liu Hao received in this very thread
when they encountered the arguments making
;
else
return INT_MIN;
}
return res;
}
which can be optimized further as
int f (int a, int b)
{
int res;
if (__builtin_add_overflow (a, b, &res))
res = (a >> sizeof(int) * CHAR_BIT - 1) ^ INT_MAX;
return res;
}
--
Best regards,
Liu
hor), then rebased the modified commit
onto ee52bf609bac. Git is smart enough to drop duplicate changes, but the leftovers formed a new
commit, which was exactly a325bdd195e.
--
Best regards,
Liu Hao
OpenPGP_signature
Description: OpenPGP digital signature
>-Original Message-
>From: Jason Merrill
>Sent: Monday, June 21, 2021 10:07 AM
>To: Liu, Hongtao
>Cc: gcc Mailing List ; Marek Polacek
>Subject: Hongtao Liu as x86 vectorization maintainer
>
>I am pleased to announce that the GCC Steering Committee has a
On Tue, Jun 22, 2021 at 3:58 PM Jakub Jelinek via Gcc wrote:
>
> On Mon, Jun 21, 2021 at 02:49:56AM +0000, Liu, Hongtao via Gcc wrote:
> > >-Original Message-
> > >From: Jason Merrill
> > >Sent: Monday, June 21, 2021 10:07 AM
> > >To: Liu,
void* ptr = 0;
if(sscanf(buf, "%p", &ptr))
*(int*)ptr = 100;
fprintf(stderr, "value = %d\n", value); // 100 instead of 42
}
```
--
Best regards,
Liu Hao
OpenPGP_signature
Description: OpenPGP digital signature
have attached the build log in case you
need it.
--
Best regards,
LIU Hao
mingw-w64-gcc-mcf-11.1.1.d20210708.c11.g35aca8e9b45-1-x86_64-build.log.gz
Description: application/gzip
OpenPGP_signature
Description: OpenPGP digital signature
t would be great as well.
Thank you for the information. Reverting cfc9fdcec8861be0d11ec4493cca518bf5b4c32d made the build
proceed again. I have created PR 101377 for it [1].
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101377
--
Best regards,
LIU Hao
OpenPGP_signature
Descriptio
Hi:
The original problem was that some users wanted the cmdline option
-ffast-math not to act on intrinsic production code. .i.e for codes
like
#include
__m256d
foo2 (__m256d a, __m256d b, __m256d c, __m256d d)
{
__m256d tmp = _mm256_add_pd (a, b);
tmp = _mm256_sub_pd (tmp, c);
tmp = _mm256_sub_
On Wed, Jul 14, 2021 at 1:15 PM Hongtao Liu wrote:
>
> Hi:
> The original problem was that some users wanted the cmdline option
> -ffast-math not to act on intrinsic production code. .i.e for codes
> like
>
> #include
> __m256d
> foo2 (__m256d a, __m256d b, __m256d
On Wed, Jul 14, 2021 at 2:39 PM Matthias Kretz wrote:
>
> On Wednesday, 14 July 2021 07:18:29 CEST Hongtao Liu via Gcc-help wrote:
> > On Wed, Jul 14, 2021 at 1:15 PM Hongtao Liu wrote:
> > > Hi:
> > > The original problem was that some users wanted the cmdline
On Wed, Jul 14, 2021 at 3:49 PM Matthias Kretz wrote:
>
> On Wednesday, 14 July 2021 09:39:42 CEST Richard Biener wrote:
> > -ffast-math decomposes to quite some flag_* and those generally are not
> > reflected into the IL but can be different per function (and then
> > prevent inlining).
>
> Is t
On Wed, Jul 14, 2021 at 4:17 PM Richard Biener
wrote:
>
> On Wed, Jul 14, 2021 at 10:11 AM Hongtao Liu wrote:
> >
> > On Wed, Jul 14, 2021 at 3:49 PM Matthias Kretz wrote:
> > >
> > > On Wednesday, 14 July 2021 09:39:42 CEST Richard Biener wrote:
> >
On Thu, Jul 29, 2021 at 10:49 AM unlvsur unlvsur via Gcc
wrote:
>
> What I mean is that what macro GCC sets when it compiles -masm=intel
>
>
> Int main()
> {
> #ifdef /*__INTEL_ASM*/
> printf(“intel”);
> #else
> printf(“at&t”);
> #endif
> }
not fully understand
Could you file a bugzilla for that?
https://gcc.gnu.org/bugzilla/enter_bug.cgi?product=gcc
On Thu, Aug 5, 2021 at 3:34 PM Stefan Kanthak wrote:
>
> Hi,
>
> targeting AMD64 alias x86_64 with -O3, GCC 10.2.0 generates the
> following code (17 instructions using 78 bytes, plus 6 quadwords
> using 48
On Thu, Aug 5, 2021 at 5:20 AM Segher Boessenkool
wrote:
>
> On Wed, Aug 04, 2021 at 11:22:53AM +0100, Richard Sandiford wrote:
> > Segher Boessenkool writes:
> > > On Wed, Aug 04, 2021 at 10:10:36AM +0100, Richard Sandiford wrote:
> > >> Richard Biener writes:
> > >> > Alternatively only enable
included in the proforma invoice.
Thanks and best regards. we await your earliest reply.
David Liu
IMEX Sourcing service
E-mail:
o-lightin...@ovovs.com mailto:o-lightin...@ovovs.com
Phone: +86 1326532 2461
Wechat: markkyyo
https://imexsourcingservices.com/
On Tue, Aug 31, 2021 at 11:11 AM Kewen.Lin via Gcc wrote:
>
> on 2021/8/30 下午10:11, Bill Schmidt wrote:
> > On 8/30/21 8:04 AM, Florian Weimer wrote:
> >> There has been a discussion, both off-list and on the gcc-help mailing
> >> list (“Why vectorization didn't turn on by -O2”, spread across seve
via Gcc
> > Sent: Monday, August 30, 2021 2:05 PM
> > To: gcc@gcc.gnu.org
> > Cc: ja...@redhat.com; Richard Earnshaw ;
> > Segher Boessenkool ; Richard Sandiford
> > ; premachandra.malla...@amd.com;
> > Hongtao Liu
> > Subject: Enable the vectorizer at -O2
Thomas Schwinge
>Sent: Wednesday, September 15, 2021 12:57 AM
>To: gcc@gcc.gnu.org
>Cc: Jakub Jelinek ; Tobias Burnus
>; Kirill Yukhin ; Liu,
>Hongtao
>Subject: GCC/OpenMP offloading for Intel GPUs?
>
>Hi!
>
>I've had a person ask about GCC/OpenMP offloadi
>From: Thomas Schwinge
>Sent: Wednesday, September 15, 2021 7:20 PM
>To: Liu, Hongtao
>Cc: gcc@gcc.gnu.org; Jakub Jelinek ; Tobias Burnus
>; Kirill Yukhin ; Richard
>Biener
>Subject: RE: GCC/OpenMP offloading for Intel GPUs?
>
>Hi!
>
>On 2021-09-15T02:00:33+, &qu
gcc define __FLT_EVAL_METHOD__ according to
builtin_define_with_int_value ("__FLT_EVAL_METHOD__",
c_flt_eval_method (true));
and guess we need to handle things like:
/* GCC only supports one interchange type right now, _Float16. If
we're evaluating _Float16 in 16-bit precision, then
On Mon, Feb 7, 2022 at 11:16 AM LiYancheng via Gcc wrote:
>
>
> On 2022/2/7 10:03, Andrew Pinski wrote:
> > On Sun, Feb 6, 2022 at 5:59 PM LiYancheng via Gcc wrote:
> >> Hello everyone!
> >>
> >> I have some questions to ask:
> >>
> >> 1. How does GCC support Sapphrie Rapids CPU now?
> >>
> >> 2.
ike that. `China, Taiwan, Hsinchu` is acceptable;
`Taiwan` is not.
--
Best regards,
LIU Hao
OpenPGP_signature
Description: OpenPGP digital signature
en no problems.
--
Best regards,
LIU Hao
OpenPGP_signature
Description: OpenPGP digital signature
://twdev.blog/2021/08/cmake/
--
Best regards,
LIU Hao
OpenPGP_signature
Description: OpenPGP digital signature
n is being defined in a DLL, `__dllexport__` should be used in place of
`__gnu_inline__`. This may require another macro, similar to `GLIB_API`.
--
Best regards,
LIU Hao
OpenPGP_signature
Description: OpenPGP digital signature
在 2022/10/11 21:10, xclae...@gmail.com 写道:
Le mardi 11 octobre 2022 à 13:00 +0800, LIU Hao a écrit :
you may try
```
__attribute__((__gnu_inline__))
extern inline
int g_strcmp0(const char*, const char*)
{ ...
```
Thanks, I gave that a try but I get many: multiple
在 2022/10/11 21:28, LIU Hao via Gcc 写道:
Did you have any declarations that had no `__gnu_inline__`? GNU inline functions are supposed to be
emitted out of line, even when its address is taken.
This should be 'to be never emitted out of line'. Sorry for that.
--
Best regard
it, it should be seen as
```
__attribute__((__dllexport__))
extern inline
int g_strcmp0(const char*, const char*)
```
There is no `gnu_inline` in this case. GCC always generates a COMDAT/weak/linkonce definition, which
will not cause multiple definition errors.
line%60
--
Best regards,
LIU Hao
OpenPGP_signature
Description: OpenPGP digital signature
could be causing
it? Thanks in advance.
--
Best regards,
LIU Hao
OpenPGP_signature
Description: OpenPGP digital signature
在 2022-10-29 20:15, Eric Botcazou 写道:
So what could be causing it?
An oversight in https://gcc.gnu.org/pipermail/gcc-cvs/2022-August/370830.html
has broken --disable-sjlj-exceptions. That's now fixed.
Thank you. Rebuilding now.
--
Best regards,
LIU Hao
OpenPGP_signature
Descri
27;:
```
#ifndef INSIDE_FOO_C
__attribute__((__gnu_inline__)) __inline__
#endif
extern
int g_strcmp0(const char*str1, const char*str2) {
...
```
'foo.c':
```
__attribute__((__dllexport__)) /* This is optional. */
extern int g_strcmp0 (const char *str1, const
ttribute__((__gnu_inline__)) __inline__
#endif
extern
int g_strcmp0(const char*str1, const char*str2);
#ifndef INSIDE_FOO_C
__attribute__((__gnu_inline__)) __inline__
#endif
extern
int g_strcmp0(const char*str1, const char*str2) {
...
```
--
Best regards,
LIU Hao
OpenPGP
x27;gcc' subdirectory, so I suspect it isn't an option there?
--
Best regards,
LIU Hao
OpenPGP_signature
Description: OpenPGP digital signature
lto,c++,fortran,objc,obj-c++` and with the `mcf` thread model; no errors observed. The built
`libgccjit-0.dll` does not have imports from winpthread any more.
Please review.
--
Best regards,
LIU Hao
From ceb65f21b5ac23ce218efee82f40f641ebe44361 Mon Sep 17 00:00:00 2001
From: LIU Hao
Date: Mon,
e not used inside GCC and the include of mutex should be
done early.
Well I am not familiar with such behavior. Feel free to amend the patch, until it looks good to you.
I hope we can check this in before GCC 13 RC.
--
Best regards,
LIU Hao
OpenPGP_signature
Description: OpenPGP digital signature
ccess to
GCC repo, and it takes a couple of hours for me to bootstrap GCC just for this tiny change.
--
Best regards,
LIU Hao
OpenPGP_signature
Description: OpenPGP digital signature
.
Thanks, I've pushed it to trunk now.
Thank you for taking care of it!
--
Best regards,
LIU Hao
OpenPGP_signature
Description: OpenPGP digital signature
= strcspn (role, ":");
```
--
Best regards,
LIU Hao
OpenPGP_signature
Description: OpenPGP digital signature
efault-msvcrt=`, so
they always match.
[1] https://sourceforge.net/p/mingw-w64/mailman/message/36030072/
--
Best regards,
LIU Hao
OpenPGP_signature
Description: OpenPGP digital signature
aultlibs` to
GCC, and specify desired libraries explicitly.
--
Best regards,
LIU Hao
OpenPGP_signature
Description: OpenPGP digital signature
to you, please consider how to write VFMADD231PD in
AT&T syntax, really.
I have been tired of such inconsistency. For God's sake, please deprecate it.
--
Best regards,
LIU Hao
OpenPGP_signature
Description: OpenPGP digital signature
year-old evilness and refusing to move
forward. Upgrading the compiler is always a big change, and updating sources should be expected,
when we take `-Werror` into account.
--
Best regards,
LIU Hao
OpenPGP_signature
Description: OpenPGP digital signature
a lot of work to keep up with
it all.
I hope that, if we decide to make Intel syntax the default since GCC 14, then such crud will be
eventually got rid of since GCC 24. OTOH, if we don't do that, we would have to live with it forever.
--
Best regards,
LIU Hao
OpenPGP_signature
Descri
在 2022/11/25 16:50, Marc Glisse 写道:
On Fri, 25 Nov 2022, LIU Hao via Gcc wrote:
I am a Windows developer and I have been writing x86 and amd64 assembly for more than ten years.
One annoying thing about GCC is that, for x86 if I need to write I piece of inline assembly then I
have to do it
ell, if that's your decision, fair enough. I can maintain my own distribution.
Patch attached [1]; bootstrapped on {x86_64,1686}-w64-mingw32 without any
issues so far.
[1]
https://github.com/lhmouse/MINGW-packages/blob/gcc-13/mingw-w64-gcc/9000-Deprecate-the-nonsense-AT-T-synax.patch
--
Be
在 2022-11-26 17:20, Dave Blanchard 写道:
No, I'm not trolling, just venting here for a moment. So sick of garbage ass,
crusty junkware that's always a battle to the death to accomplish anything.
I really understand where Liu Hao was coming from yesterday when he was in here
raging a
this parameter is useful for more people.
I vote +1 for this in GCC 14.
GCC 13 (i.e. current master branch) is at stage3 so it's not an option at this
moment.
--
Best regards,
LIU Hao
OpenPGP_signature
Description: OpenPGP digital signature
Would you please do the same to libgomp too?
--
Best regards,
LIU Hao
OpenPGP_signature
Description: OpenPGP digital signature
al
ret
```
--
Best regards,
LIU Hao
OpenPGP_signature
Description: OpenPGP digital signature
101 - 200 of 251 matches
Mail list logo
