on't want to defend this position, I'm just
explaining a possible motivation). Even if the attribute didn't work, they
could revert to pthread_setspecific and co. for TLS. I don't see why make
using GCC harder for them.
Thanks again.
Alexander
e anything to fix.
The problem is that -ftls-model flag allows forcing local-exec TLS in
shared objects, but does not allow forcing global-dynamic TLS. I don't see
the rationale for providing one but not the other. It seems inconsistent.
Thanks.
Alexander
ng something here? Could somebody clarify that peace
of code please.
--Alexander
2013/7/29 Andreas Schwab :
> Alexander Ivchenko writes:
>
>> BTW: First the check was "|| context == NULL", then it was removed by
>> r149964 and then came back as "|| context != NULL" by r153768.
>
> Looks like r153734 got it wrong first. It was sup
a/gcc/ChangeLog b/gcc/ChangeLog
index 56e6fd4..6bb18f8 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,8 @@
+2013-08-20 Alexander Ivchenko
+
+ * config/linux-android.c (linux_android_libc_has_function): Fix
+ checks for libc.
+
2013-08-20 Zhouyi Zhou
* tree-ssa
rticular function in the test so to flexibly define whether
the test should be unsupported or not?
E.g. by adding some debug options for gcc that will return the result
of the hook? But I doubt that such option would be a pretty solution
thanks
--Alexander
!TREE_CONSTANT (maxindex)
+ && flag_exceptions)
length_check = fold_build2 (LT_EXPR, boolean_type_node, maxindex,
size_int (CONSTRUCTOR_NELTS (init) - 1));
thanks,
Alexander
*ping*
thanks,
Alexander
2013/9/23 Alexander Ivchenko :
> Hi,
>
> When I compile the following code (modified version of
> g++.dg/cpp0x/bad_array_new1.C without try/catch):
>
> // { dg-options -std=c++11 }
> // { dg-do run }
>
> #include
>
> void *
float and long double forms of math functions. */
#undef TARGET_C99_FUNCTIONS
#define TARGET_C99_FUNCTIONS 1
And since now we assume that by default c99 functions are present, the
correct version of the hook would be exactly the default one.
> I approved a patch today that I think will fix this.
> Jeff
That's right, it is committed:
http://gcc.gnu.org/ml/gcc-cvs/2013-11/msg01158.html
thanks,
Alexander
-82ee72b054a4
to fix http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60644 and cure
i686-pc-linux-android build?
thanks,
Alexander
2014-04-17 14:25 GMT+04:00 Paweł Sikora :
> W dniu 2014-04-17 12:13, Jonathan Wakely napisał(a):
>
>> On 17 April 2014 10:38, Paweł Sikora wrote:
>>>
>>>
k with fixing it in trunk later as
well, depending on your decision.
2014-04-17 15:31 GMT+04:00 Jakub Jelinek :
> On Thu, Apr 17, 2014 at 02:47:50PM +0400, Alexander Ivchenko wrote:
>> Is it ok to port this patch to 4.9 branch:
>
> If it always fails to bootstrap with cilkrts on Andr
d via:
svn co svn://gcc.gnu.org/svn/gcc/branches/graphite
(or it can be browsed online; see http://gcc.gnu.org/svn.html for details).
Unfortunately, no new developments have happened since then.
Alexander
when processing outer loops.
In any case, I recommend to create a bug report in the GCC bugzilla for this
problem.
Hope that helps,
Alexander
g/ggx,
but at the moment you'll have to browse it via The Internet Archive
( http://web.archive.org/web/20100117171845/http://spindazzle.org/ggx/ ).
Apart from that, the GCC wiki has accumulated many resources, especially
in the GettingStarted section ( http://gcc.gnu.org/wiki/GettingStarted ).
Alexander
ves",
linked in my other response in this thread; when the port was functional,
the architecture was renamed to 'moxie' and a new blog was started. The new
http://moxielogic.org/blog does not contain all those posts about porting.
Alexander
> As a consequence inside sel_remove_empty_bb I hit on the following assert:
> gcc_assert (in_current_region_p (merge_bb));
Sounds like your GCC tree does not have Andrey's fix for PR 52250 (SVN
revision 184975).
Alexander
n't understand. You said earlier that the assert in move_bb_info
failed, but the patch removes that assert. So how does the failure
look now? Can you provide a reproducible testcase?
Alexander
On Wed, Jul 18, 2012 at 1:05 AM, Alex Turjan wrote:
> I found the patch from the following link:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52250
See comment 9. The patch pasted in the audit trail is not what has
been committed.
Alexander
By default in Android we always compile with -fpic or -fPIC, even when
compiling executable. Because of that we have some test fails on
Android:
For example:
gcc/testsuite/gcc.target/i386/pr47312.c
/* { dg-do run } */
/* { dg-options "-O2" } */
void exit (int);
void noreturn_autodetection_failed
built
with -fPIC now. What do you think?
2012/11/15 H.J. Lu :
> On Wed, Nov 14, 2012 at 5:26 AM, Alexander Ivchenko
> wrote:
>> By default in Android we always compile with -fpic or -fPIC, even when
>> compiling executable. Because of that we have some test fails on
>> A
e -fpic default? I'm not
quite sure which one is better for Android; -fPIE will
give us all the security advantages of the position independent code
and probably is a better option.
2012/11/16 Maxim Kuvyrkov :
> On 15/11/2012, at 10:39 PM, Alexander Ivchenko wrote:
>
>>>> The can
r head in the sand.
Considering all that, I believe that we are left with only one
solution: to carefully add "-fno-pic" or
"{ target nonpic }" to the affected tests as we discussed above.
Thank you very much for your help!
2012/11/18 Maxim Kuvyrkov :
> On 18/11/2012, at 7
tors and makes small ASan
tests pass, but this solution is far from a complete one.
Is my understanding of the current problem with
machopic_asm_out_constructor() correct? If so, any chance it can be
fixed?
Thanks,
Alexander Potapenko
Software Engineer
Google Moscow
. */
However this seems to not touch variables with only may-uninitialized
accesses.
> And to initialize allocated variables with some bit pattern you can simply
> override malloc.
Or use MALLOC_PERTURB_ environment variable.
--
Alexander
(mem/c:DI (plus:DI (reg/f:DI 111 r119)
(const_int -1456 [0xfa50])) [64 ivtmp.1640+0 S8 A64])
Does IRA support stack slot sharing described in the comment?
Thanks.
--
Alexander Monakov
function.h") at gengtype-lex.l:608
#3 0x2000d050 in main (argc=23, argv=0x17)
at .././..//gcc-4.2.0-20070501/gcc/gengtype.c:3070
(gdb) x/i $ip
0x2000a5a0 : [MMI] st8 [r16]=r17
The instruction below appears to be the problematic one, but I cannot
tell why:
[MMI] st8 [r16]=r17
--
Alexander Kabaev
signature.asc
Description: PGP signature
On Sun, 13 May 2007 10:53:44 +0200
Andreas Schwab <[EMAIL PROTECTED]> wrote:
> Alexander Kabaev <[EMAIL PROTECTED]> writes:
>
> > The instruction below appears to be the problematic one, but I
> > cannot tell why:
> >
> > [MMI] st8 [r16]=r17
>
&g
hanks in advance for comments
--
Alexander Monakov
diff -puN trunk/gcc/cfgexpand.c export-ddg/gcc/cfgexpand.c
--- trunk/gcc/cfgexpand.c 2007-06-22 20:19:52.0 +0400
+++ export-ddg/gcc/cfgexpand.c 2007-06-29 17:34:20.0 +0400
@@ -1988,6 +1988,7 @@ tree_expand_cfg (void)
/* T
ported data, or discarding the irrelevant
information?
I mentioned before that I would need to take care of basic block
duplication on tree level, but I have seen no example of that
happening after iv-opts so far. Does anyone know offhand whether it
is possible?
Thanks
--
Alexander Monakov
---
his, but I was trying to keep
the patch as small and self-contained as possible.
Doing it right requires deeper understanding of the operand cache
implementation than I have. I'm not trying to get this into GCC, but perhaps
somebody will find this patch useful.
Take care,
Alexander Sotirov
your answers will provide helpful directions for other
students who want a GCC-related term/graduation project.
Thanks.
--
Alexander Monakov
#x27;no', but
just in case :) Again, this is needed to support data speculation before
register allocation: register that is speculatively loaded must be same
for speculative load and check.
Thanks.
Alexander Monakov
Diego Novillo wrote:
> Richard Kenner wrote:
>
> > I don't see that. Why is it that much harder to link in with GCC
> than doing
> > it as a plugin?
>
> Limited time and steep learning curves. Typically, researchers are
> interested in rapid-prototyping to keep the paper mill going. Plug-ins
ssibly improving it (hey, Alexander, what
were your problems, someone might answer them on Wiki for others!)
and, in particular, staying as friendly and forgiving community as you
are (especially on IRC anyway :-).
I certainly agree with this! The same effort spent on documentation
rather tha
On Fri, 07 Dec 2007 23:49:28 +0300, Daniel Berlin <[EMAIL PROTECTED]>
wrote:
On 12/7/07, Alexander Monakov <[EMAIL PROTECTED]> wrote:
Hi.
Attached is the patch that allows to save dependence info obtained on
tree
level by data-reference analysis for usage on RTL level (fo
e, and operand_equal_p
will discard that (since trees will look the same after out-of-SSA). I do
not see a better way to provide flow-sensitive annotations for MEMs.
DDR will mark them as data refs
Come again? :)
Thanks.
--
Alexander Monakov
at the source, but they do not issue the warning if the value is exactly
representable in the format (but they warn if it was implicitly cast from an
integer, like in 'x == 0', which is probably a bug). They also suppress the
warning in some other cases, e.g. for 'x == x'.
Alexander
; Any idea how to drop that branch again from the main gcc.gnu.org repo?
You have to use the name of the branch in the remote repo, "python-formatting":
git push --delete origin python-formatting
(or using the colon syntax:)
git push origin :python-formatting
Alexander
On Tue, 24 Dec 2024, Florian Weimer wrote:
> * Alexander Monakov:
>
> > Well, the first paragraph in your initial mail was talking very explicitly
> > about making a tailcall from the wrapper, so I guess the goalpost has moved.
>
> Uhm, I meant a tailcall from the tra
^~~:
This is the only approach I'm aware of, apart of generating wrappers
in asm (speaking of, is there some reason that wouldn't work for you?).
HTH
Alexander
On Mon, 23 Dec 2024, Florian Weimer via Gcc wrote:
> * Alexander Monakov:
>
> > On Mon, 16 Dec 2024, Florian Weimer via Gcc wrote:
> >
> >> I would like to provide a facility to create wrapper functions without
> >> lots of argument shuffling. To ach
On Mon, 23 Dec 2024, Florian Weimer via Gcc wrote:
> * Alexander Monakov:
> >> Does this work on all primary GCC targets?
> >
> > Yes? I'm not sure why you think it might not work. What are your
> > concerns?
>
> Targets not setting up REGISTER_NAMES,
appropriate
to treat it like .shared memory (exposed in nvptx via an attribute).
Alexander
ations that
> could be allowed by default?
-fallow-store-data-races guards transforms that we know to be incorrect
for source code that may become a part of a multithreaded program.
Are you asking about something else?
Alexander
Introducing racing loads is generally not harmful, see note 14.
Alexander
does not reside
in read-only memory. And then, as Richi said, this may be a de-optimization
if you consider the costs of dirtying a cache line conditionally or always
(or, for a more dramatic case, triggering a page fault or not).
Alexander
tml
I'm surprised it's an issue for you: normally your email client
would transform quoted-printable and copying would do the right thing
(i.e. select actual patch contents, without whitespace munging).
Are you trying to copy from the raw message representation?
Alexander
On Mon, 24 Aug 2020, Richard Biener via Gcc wrote:
> Whether or not the conditional branch sequence is faster depends on whether
> the branch is well-predicted which very much depends on the data you
> feed the isWhitespace function with but I guess since this is the
> c == ' ' test it _will_ be a
ryone is on the same page about that.
I also suspect that the dramatic slowdown has to do with the extra branch.
Your CPU might have some specialized counters for branch prediction, see
'perf list'.
Alexander
ot; the result as needed towards
higher ILP or whatever the concrete machine prefers :)
Alexander
p only covers about 46-48% of overall time.
High count on the initial ldur instruction could be explained if the loop
is not entered by "fallthru" from the preceding block, or if its backedge
is mispredicted. Sampling mispredictions should be possible with perf record,
and you may be able to check if loop entry is fallthrough by inspecting
assembly.
It may also be possible to check if code alignment matters, by compiling with
-falign-loops=32.
Alexander
tand the kernel wants to pass qualified
lvalues to inline assembly to get
lea , %fs:
LEA without the %fs will produce the offset within the segment, which
you can obtain simply by casting the pointer to intptr_t in the first place.
Alexander
%0" :: "m"(strip_as(x[1])));
}
yields
foo:
# %fs:4(%rdi)
# 4(%rdi)
ret
I think a clean future solution is adding a operand modifier that would
print the memory operand without the segment prefix.
Alexander
On Thu, 5 Nov 2020, Uros Bizjak wrote:
> On Thu, Nov 5, 2020 at 12:38 PM Alexander Monakov wrote:
> >
> > On Thu, 5 Nov 2020, Uros Bizjak via Gcc wrote:
> >
> > > > What is the usecase for stripping the address space for asm operands?
> > >
> >
ith lea is
avoiding base+offset computation outside the asm. If you're okay with one
extra register tied up by the asm, just pass the address to the asm directly:
void foo(__seg_fs int *x)
{
asm("# %0 (%1)" :: "m"(x[1]), "r"(&x[1]));
asm("# %0 (%1)" :: "m"(x[0]), "r"(&x[0]));
}
foo:
leaq4(%rdi), %rax
# %fs:4(%rdi) (%rax)
# %fs:(%rdi) (%rdi)
ret
Alexander
On Thu, 5 Nov 2020, Alexander Monakov via Gcc wrote:
> On Thu, 5 Nov 2020, Uros Bizjak via Gcc wrote:
>
> > > No, this is not how LEA operates. It needs a memory input operand. The
> > > above will report "operand type mismatch for 'lea'" error.
>
Hello
On llvm side of compiler world there has been work done by Igor Kudrin to
enable DWARF64.
I am trying to add a flag to Clang to enable DWARF64 generation.
https://reviews.llvm.org/D90507
In review David Blaikie pointed out that there has been a discussion on what to
call this flag:
https:
s just asking to end up with debug level that might not be
what user expects.
Thank You
Alex
From: David Blaikie
Sent: Wednesday, November 25, 2020 1:46 PM
To: Richard Biener
Cc: Jakub Jelinek ; Mark Wielaard ;
gcc@gcc.gnu.org ; ikud...@accesssoftek.com
From: David Blaikie
Sent: Monday, November 30, 2020 12:09 PM
To: Alexander Yermolovich
Cc: Richard Biener ; Jakub Jelinek
; Mark Wielaard ; gcc@gcc.gnu.org
; ikud...@accesssoftek.com ;
mask...@google.com
Subject: Re: DWARF64 gcc/clang flag discussion
On
From: David Blaikie
Sent: Tuesday, December 1, 2020 10:33 AM
To: Alexander Yermolovich
Cc: Richard Biener ; Jakub Jelinek
; Mark Wielaard ; gcc@gcc.gnu.org
; ikud...@accesssoftek.com ;
mask...@google.com
Subject: Re: DWARF64 gcc/clang flag discussion
On
From: David Blaikie
Sent: Wednesday, December 2, 2020 1:12 PM
To: Alexander Yermolovich
Cc: Richard Biener ; Jakub Jelinek
; Mark Wielaard ; gcc@gcc.gnu.org
; ikud...@accesssoftek.com ;
mask...@google.com
Subject: Re: DWARF64 gcc/clang flag discussion
On
From: Richard Biener
Sent: Friday, December 4, 2020 12:36 AM
To: David Blaikie
Cc: Alexander Yermolovich ; Jakub Jelinek ;
Mark Wielaard ; gcc@gcc.gnu.org ;
ikud...@accesssoftek.com ; mask...@google.com
Subject: Re: DWARF64 gcc/clang flag discussion
On Thu
es undefined behavior.
The x86 'idiv' instruction, however, will raise a divide error if the result
does not fit in a register, so e.g. dividing INT64_MAX by 1 would trap.
Alexander
tion-defined signal may be raised if the result
would not fit in int32_t, but GCC defines the behavior as bitwise truncation
in all cases.
Alexander
an "imaginary" empty GOT somewhere, just to have a stable anchor
against which to resolve GOTOFF relocations)
Please consider filing a bug against binutils on sourceware.org, this looks
like a QoI issue in the linker: it should emit a diagnostic rather than
non-sensical code.
Alexander
y
> the current C behavior is what OpenCL specifies.
Where does OpenCL specify that? Checking the 1.2 OpenCL standard I see the
opposite (the code would fail to compile):
6.2.1
Implicit Conversions
[...]
Implicit conversions between built-in vector data types are disallowed.
Alexander
rmal scheduling), not control speculation.
I think GCC may have correctness issues with ia64-style control speculation
before register allocation, but I can't think of a reason why check-free loads
would pose a problem.
Alexander
tion is no longer used. Forcing initialisation of stack
> variables would put it in the wrong place, when the stack space is reused.
>
> And the code generated here is as good as it gets - no efficiency is lost.
>
>
> So as far as I can see, gcc has all the bits it needs - it just needs a
> nicer and simpler syntax. Something like an attribute "secure" which
> will generate and use an appropriately sized zeroing function on scope
> exit. Ideally, this could be attached to a type as well as a variable.
>
> (I have no idea how simple or difficult this task might be.)
>
>
--
Alexander Potapenko
Software Engineer
Google Germany GmbH
Erika-Mann-Straße, 33
80636 München
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
treat them specially.
Another example is mips64, where even non-PIC PLT is special (but looks like
LLVM does not do any tailcalls on mips64 at all).
Alexander
n future)
> conversion specifier.
>
> (But I am only guessing.)
%p (not %n) allows the pointer to escape.
Alexander
From: Vincent MAILHOL
Date: Wed, 27 Apr 2022 11:58:58 +0900
> + Alexander Lobakin
I was okay even with the previous solution to modify
GENMASK_INPUT_CHECK() and this one is fine to me as well.
The presense of warnings on W=1 doesn't mean we shouldn't fix W=12
etc. Especially when
On Wed, 20 Jul 2022, Sebastian Huber wrote:
> How does Ada get its default TLS model?
You shouldn't need to do anything special, GCC automatically selects
initial-exec or local-exec for non-PIC (including PIE).
Alexander
On Wed, 20 Jul 2022, Sebastian Huber wrote:
> On 20/07/2022 13:41, Alexander Monakov wrote:
> > On Wed, 20 Jul 2022, Sebastian Huber wrote:
> >
> >> How does Ada get its default TLS model?
> > You shouldn't need to do anything special, GCC automatically sel
g it up so it doesn't die indexing the codebase
(e.g. adding the entire toplevel directory probably won't work: it will
try to index the testsuites).
FWIW, CLion documentation shows how to select GNU coding style, but as
above, that's not the main worry:
https://www.jetbrains.com/help/clion/predefined-code-styles.html
Alexander
oken with a few lists,
as clicking on a thread results in a 404 page, e.g. any top link from
https://inbox.sourceware.org/gcc-bugs/
Alexander
#x27;m probably missing something, why autoconf
> can't use that idiom instead. But perhaps the (historic?) reasons why it
> couldn't be used are gone now?
Ironically, modern GCC and LLVM optimize '&foobar != 0' to '1' even at -O0,
and thus no symbol reference remains in the resulting assembly.
Alexander
7;s the other way around).
Opinions? Does anybody envision problems with going the DWIM way?
Thanks.
Alexander
[1]
https://inbox.sourceware.org/gcc-patches/2552ab22-916f-d0fe-2c78-d482f6ad8...@lauterbach.com/
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48088#c5
ing
-Warray-bounds=2 -Werror=array-bounds=1
(errors for most certain OOB accesses, warnings otherwise).
Alexander
seful for libraries, which might for example require
> C99 or C11 to work. They would be able to specify -minstd=c11 in their pc(5)
> file (for use with pkgconf(1)).
There's already a standard, portable way to check:
#if __STDC_VERSION__ < 201710
#error C17 required
#endif
Alexander
, but yes, it's
> portable.
I don't see why you'd need that in "every public header". Public headers
should be so simple they would have no need to check C version at all, no?
Alexander
e that is the
> signed or unsigned type corresponding to the effective type of the object
The standard allows aliasing, but not assigning pointers without a cast.
This is valid:
unsigned x;
int *p = (void *)&x;
*p = 0;
This is not valid (constraint violation):
unsigned x;
int *p = &x;
In GCC this is diagnosed under -Wpointer-sign:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25892
Alexander
ame way?
Another one is -Wpointer-arith (pointer arithmetic on 'void *').
Alexander
nd on the expected usefulness?
Alexander
essages are not available there)
Alexander
}
the narrowing conversion is represented with NOP_EXPR, and it is definitely
not a no-op.
Does some clear distinction remain, and is it possible to clarify the
definitions?
Thanks.
Alexander
which is
currently available via the Wayback Machine, but not its original URL:
https://web.archive.org/web/20230316072811/http://embed.cs.utah.edu/csmith/using.html
It was written by the developers of Csmith.
Alexander
en BB is executed, then *all* its dominators
were executed, and some of its post-dominators too, except when a call could
terminate the program? So instrumenting the entry BB is necessary only if it's
the only block in a function, or contains a possible-terminating call. And
this can be generalized to BBs of the dominator tree?
Alexander
201 - 287 of 287 matches
Mail list logo
