up' pass before
the '*free_cfg' pass. It's the moment when the stack frame size is
already final, function prologues and epilogues are generated, and the
machine-dependent code transformations are not done.
[1] https://www.openwall.com/lists/kernel-hardening/2018/11/23/2
Report
code?
This is invalid code, GCC documentation is clear that the compiler
may duplicate inline asm statements (passes other than tracer can do
that too, loop unswitching just to give one example).
We don't provide a way to write an asm that wouldn't be duplicated.
Alexander
and the 'gcc' command actually invokes Clang/LLVM.
Clang does not implement this builtin (there's __builtin_shufflevector with
a different interface — see Clang documentation for details).
Alexander
gt; > program?
>
> I assume i is signed int. Even then GCC may not do this unless it knows
> the loop is entered (start < limit).
Additionally, the compiler needs to prove that 'foo' always returns normally
(i.e. cannot invoke exit/longjmp or such).
Alexander
Hi there! I hope, this message will go to where it's expected to go, since
I'm not really familiar with e-mail threads.
I was the one who brought https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81806
issue about sub-optimal implementation of split function in pbds. The
reason why I did so is clearly
I hoped it would attach to
https://gcc.gnu.org/ml/libstdc++/2019-05/msg00107.html but it didn't happen
:(
ср, 10 июл. 2019 г. в 01:39, Alexander Kulkov :
> Hi there! I hope, this message will go to where it's expected to go, since
> I'm not really familiar with e-mail threa
see that it may not emit
a call to this function), then teaching ICF to check that when deciding to
fold by creating a wrapper.
(would it be possible to tell ICF that addresses of interrupt functions are
not significant so it can fold them by creating aliases?)
Alexander
say explicitly, but that was meant more as a remark to IPA
maintainers: currently in GCC "address taken" implies "address significant",
so "address not significant" would have to be a new attribute, or a new decl
bit (maybe preferable for languages where function addresses are not significant
by default).
Alexander
ice here in how I may contribute
would be much appreciated.
вт, 23 июл. 2019 г. в 19:21, Jonathan Wakely :
> Sorry for the late reply that wasn't "tomorrow".
>
> On Tue, 9 Jul 2019 at 23:40, Alexander Kulkov wrote:
> >
> > Hi there! I hope, this message will g
d alignment on
a typedef'ed scalar type goes way earlier than gcc-9)
Alexander
e new documentation promises a more
sensible approach)
In portable code one can also use memcpy to move unaligned data, the compiler
should translate it like an unaligned load/store when size is a suitable
constant:
int val;
memcpy(&val, ptr, sizeof val);
(or __builtin_memcpy when -ffreestanding is in effect)
Alexander
t;
> Yes. But last I tried, optimizing that for > 1 alignment is problematic
> because that information often doesn't make it down to the target code even
> though it is documented to do so.
Thanks, indeed this memcpy solution is not so well suited for that.
Alexander
/tc-i386.c;h=d0b8f2624a1885d83d2595474bfd78ae844f48f2;hb=HEAD#l1441
>
> I'm not sure how worthy would it be to implement that?
Huh? Surely the right move would be to ask Binutils to expose that via
a new pseudo-op, like .balign but requesting a specific space rather
than aligning up to a boundary.
Alexander
-nodefaultlibs next to -nostartfiles in its Makefile, and
write a trivial loop in place of __builtin_strlen.
Alexander
odes with the floating-point type 'kind' such as IEEE binary, IEEE
decimal, accum/fract/sat, or IBM double-double.
For our original goal, I think we'll switch to the other solution I've outlined
in the opening mail, i.e. propagating mode tables at WPA stage and keeping
enough information to know if the section comes from the host or native
compiler.
Thanks.
Alexander
s' arguments will be
remapped. And I believe it wouldn't be acceptable to unpack/remap/repack
function bodies at WPA stage (it's contrary to LTO scalability goal).
Alexander
and thus need no remapping, and the sections
coming from the host compiler all need remapping (and will use the same
mapping). Prefixes of per-function section names already carry the distinction
(".gnu.lto_foo" vs. ".gnu.offload_lto_foo").
Alexander
concerns are guaranteed to not
arise: when the callee is not externally visible, and does not have its address
taken. And there's a question of how well it's going to work after time passes,
since other compilers always use the verbose form (and thus the .reg calling
style is not frequently exercised).
Alexander
of HSAIL/PTX assembly to GPU binary code takes place when the
host executable runs, on user's machine, by invoking corresponding libraries (in
case of PTX it's NVIDIA's CUDA driver library).
There is no support for translating HSAIL/PTX on the developer's machine and
linking the resulting GPU binary code into GCC-produced executable.
Hope that helps.
Alexander
Can you explain a bit more, what projects you've tested?.. 10+% looks
surprisingly high to me.
> What do you think?
I wonder if it's possible to reap most of the compile time benefit with a bit
more modest gc threshold increase?
Thanks.
Alexander
On Fri, 14 Jul 2017, Yuri Gribov wrote:
> I've also detect transitiveness violation compare_assert_loc
> (tree-vrp.c), will send fix once tests are done.
There are more issues still, see the thread starting at
https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00899.html
Alexander
zed implementation of a [potentially
not stable, e.g. qsort] sorting routine, and that would be sufficient
to eliminate this source of codegen differences.
Alexander
[*] nor would it be sufficient, given our current practice of passing
invalid comparators to libc sort, at which point anything can hap
n-stable sort.
I think you mean '(slightly faster)'.
> That is just a plain bug, undefined behaviour even (C11 7.22.5/4).
> Of course it needs to be fixed.
I've posted patches towards this goal.
Alexander
e std::stable_sort, is that what
you meant, or are there more places?
Alexander
uiltins and VLAs.
The description at https://gcc.gnu.org/wiki/MiddleEndArrays refers to
http://www.suse.de/~rguenther/guenther.pdf
but this redirects to users.suse.de, for which DNS resolution fails.
The Web Archive doesn't seem to have a copy.
Any chance this might be available elsewhere?
Thanks.
Alexander
ure if -fno-common is made default - thus, is there anybody in
position to trigger a full-distro rebuild with gcc patched to enable
-fno-common, and compare before/after build failure stats?
Thanks.
Alexander
hould work from gcc-8 onwards (PR 80640).
Alexander
On Fri, 20 Oct 2017, Torvald Riegel wrote:
> On Thu, 2017-10-19 at 15:31 +0300, Alexander Monakov wrote:
> > On Thu, 19 Oct 2017, Andrew Haley wrote:
> > > No, you did not. This looks like a bug. Please report it.
> >
> > This bug is fixed on trunk, so should wor
d that may cause codegen differences.
(in other words, bootstrapping on a libc with randomized qsort has
a good chance to run into bootstrap miscompares even if qsort_chk-clean)
Alexander
rns 0 if and only if the items being compared are
bitwise identical'.
Otherwise qsort, not being a guaranteed-stable sort, has a choice as to how
reorder non-identical items that compare equal.
> But, if the comparison functions are fixed, then the implementation
> differences between
On Fri, 12 Jan 2018, Joseph Myers wrote:
> On Fri, 12 Jan 2018, Alexander Monakov wrote:
>
> > No. The qsort_chk effort was limited to catching instances where comparators
> > are invalid, i.e. lack anti-commutativity (may indicate A < B < A) or
> > transitivity pr
Hi,
As I understand from this
https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html current master
branch doesn't have support of double-precision FPv5 floating-point
instructions for ARMv8-R (Cortex-r52).
If yes, are there any chances to see them in GCC 8 ?
Alex
Thank you Thomas
So in order to set dp+Neon for armv8-r I should to use switch
"neon-fp-armv8". Not an fpv5-d16. Right ?
On Fri, Jan 26, 2018 at 12:52 PM, Thomas Preudhomme
wrote:
> Hi Alexander,
>
> As mentioned in [1], Arm Cortex-R52 can have either single precision or
homas
>
>
> On 26/01/18 16:44, Alexander Fedotov wrote:
>>
>> Thank you Thomas
>>
>> So in order to set dp+Neon for armv8-r I should to use switch
>> "neon-fp-armv8". Not an fpv5-d16. Right ?
>>
>> On Fri, Jan 26, 2018 at 12:52 PM, Thomas
Hi guys,
we have faced an error while using the gcov tool.
We have the following C-code:
LC_TD_DINT caseSelector;
caseSelector = LC_this->LC_VD_X;
if
((caseSelector==(LC_TD_DINT)1L)||(caseSelector==(LC_TD_DINT)2L)||((caseSelector>=(LC_TD_DINT)33L)
&& (caseSelector<=(LC_TD_DIN
hg16b availability and redirect 128-bit atomics to
lock-free RMW implementations if so. (I don't like this solution)
Thanks.
Alexander
e is that libatomic is not guaranteed to work like that.
Today it relies on IFUNC for redirection, so you may (and not "will") get the
desired behavior on Glibc (implying Linux), not on other OSes, and neither on
Linux with non-GNU libc (nor on bare metal, for that matter).
Alexander
due to IFUNC redirection mentioned
in the other subthread.
Alexander
Thanks Martin!
I've seen that the target milestone for this bug is 8.0.
When is 8.0 going to be released?
Thanks and kind regards,
Alexander
-Ursprüngliche Nachricht-
Von: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] Im Auftrag von Martin
Liška
Gesendet: Montag, 26. Fe
Ok, thanks for the info.
I just saw the description in the bug-report.
When we document this for our customers, it's ok, I think.
Thanks and kind regards,
Alexander
-Ursprüngliche Nachricht-
Von: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] Im Auftrag von Martin
Liška
Ges
e-Coverage,
so it is important for us to know if there are any bugs which could compromise
the reported test coverage.
Thanks and kind regards,
Alexander
-Ursprüngliche Nachricht-
Von: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] Im Auftrag von Martin
Liška
Gesendet: Dienstag, 2
Ok, thank you.
Alexander
-Ursprüngliche Nachricht-
Von: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] Im Auftrag von Martin
Liška
Gesendet: Dienstag, 27. Februar 2018 13:39
An: Alexander Fichtinger ; gcc@gcc.gnu.org
Betreff: Re: AW: AW: AW: AW: Problem using gcov
On 02/27/2018
s the setjmp by forcing
> the pseudos to interfere all hardregs. That can't be good for performance.
> What am I missing?
FWIW there's a similar issue with exceptions where IRA chooses memory
for pseudos inside the loop even though the throwing call is outside:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82242#c3
Alexander
On Fri, 13 Apr 2018, Vivek Kinhekar wrote:
> The mfence instruction with memory clobber asm instruction should create a
> barrier between division and printf instructions.
No, floating-point division does not touch memory, so the asm does not (and
need not) restrict its motion.
Alexander
been fixed in gcc-8, but some remain (you
can search the bugzilla for qsort_chk issues). Since the comparator is
invalid, different qsort implementations reorder the ready list differently.
In gcc-9 qsort calls use gcc_qsort instead and thus wouldn't diverge.
Alexander
should say what a function currently does, but
> isn't the place for a history lesson. That data belongs only in ChangeLog
GCC ChangeLogs don't record the purpose of the change. They say what changed,
but not why.
As far as I know, this ChangeLog style helped in pre-Subversion times when
source control tools tracked changes per-file, not per-tree.
Alexander
re's no need to split this quality-of-life change between the
repository and the user's setup - it can be done once by a user and will work
for all future checkouts)
Alexander
uninitialized
arrays there's this sparse set algorithm (which GCC itself also uses):
https://research.swtch.com/sparse
I think good benchmarks sets should be able to evolve to account for newly
discovered bugs, rather then remain frozen (which sounds like a reason to
become obsolete sooner rather than later).
Alexander
up.
What should work is (re)declaring memcpy with hidden visibility:
__attribute__((visibility("hidden")))
void *memcpy(void *, const void *, size_t);
or via the pragma, but today this doesn't work. I've opened a GCC bugreport
for this: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86695
Alexander
binding and/or allocation
(not sure which exactly) of TLS symbols.
Lazy binding doesn't buy anything for gcov, and that would be a cheap way
to avoid a regression.
On the other hand, it's not gcov's responsibility to work around
long-standing bugs in Glibc, so I don't insist.
Alexander
ses directly to my address, not the list.
If you prefer Google Forms, please fill https://goo.gl/forms/1sLhMtLLhorvzDm42
Development policies touched upon in items 2-6 is what I'd invite to
discuss on the BoF.
Thank you.
Alexander
You are wearing:
[*] Distribution maintainer's hat
ngeLog-{year} files)
> and I see:
Note that some files in your list appear only because they have
12 spaces indenting the second author in a multi-author change,
which is intentional and probably does not need changing.
Alexander
ecution
unit (A), the second has to wait.
Alexander
d to additionally generate comparison instructions).
Hope that helps,
Alexander
Given this piece of code (gcc-4.7-20120114):
static void Test(Batch* block,Batch* new_block,const uint32 offs)
{
T* __restrict old_values
=(T*)__builtin_assume_aligned(block->items,16);
T* __restrict new_values
=(T*)__builtin_assume_aligned(new_block->items,16);
lex
On 01/19/2012 11:29 AM, Richard Guenther wrote:
On Wed, Jan 18, 2012 at 6:37 PM, Alexander Herz wrote:
Given this piece of code (gcc-4.7-20120114):
static void Test(Batch* block,Batch* new_block,const uint32 offs)
{
T* __restrict old_values
=(T*)__builtin_assume_aligned(bl
On Aug 17, 2009, at 10:50 AM, Bernd Roesch wrote:
[..]
There is no need for much detail, just compile any bigger
sourcecode with
-O3 -fno-.. and after that with -O2 When the object files are
not
identical, something is wrong and I can start a bug report.
how much is size diffrent ?
. }
};
in *any* circumstances or not?
Thanks in advance.
--
Best regards,
Alexander Shabanov
Hi,
On Tue, 27 Oct 2009, Markus L wrote:
Hi,
I recently read the articles about the selective scheduling
implementation and found it quite interesting, I especially liked the
idea of how neatly software pipelining is integrated. The target I am
working on is a VLIW DSP so obviously these thing
(libgomp only includes the latter).
This can be fixed by making configure use -Werror (I believe that
adding --with-pthread= option is out of the question).
Bootstraps on affected systems should probably use
make CFLAGS_FOR_TARGET='-g -O2 -I/usr/include/nptl'
as a clean workaround.
--
, at present SMS is not able to schedule any loops on x86 at all. This
is due to implementation detail: SMS operates on loops that end with
decrement-and-branch instruction, and GCC does not generate such
instructions on x86.
Sorry.
Alexander Monakov
o tell whether you
tested it.
Best regards,
Alexander Monakov
bed in http://gcc.gnu.org/bugs/ . Posting bug reports to gcc-bugs@ does
not register them in the bugzilla, and thus is not recommended.
Thanks.
Alexander Monakov
break, which IMHO is fine.
--
Alexander Monakov
On Fri, 26 Jun 2009, Joe Buck wrote:
On Fri, Jun 26, 2009 at 03:38:31AM -0700, Alexander Monakov wrote:
1. Add bool field `modified_p' in bitmap structure.
2. Make iterator setup functions (e.g. bmp_iter_set_init) reset it to
false.
3. Make functions that modify the bitmap set it to tr
use it would be much harder to extract the instruction placement from the
automaton (which I think tracks all of the mentioned constraints internally).
Alexander
On May 20, 2010, at 8:04 AM, Steven Bosscher wrote:
> On Mon, May 17, 2010 at 8:44 AM, Maxim Kuvyrkov
> wrote:
>> CodeSourcery is working on improving performance for Intel's Core 2 and Core
>> i7 families of processors.
>>
>> CodeSourcery plans to add support for unaligned vector instructions
h for the libgcov bug [1], but it was not reviewed and does not
apply anymore due to build_constructor changes).
[1] http://gcc.gnu.org/ml/gcc-patches/2010-05/msg00292.html
Cheers,
Alexander
in cfganal.c. It computes topological sort order
(which is what you need) in reverse: nodes that must be visited last come
first in the array.
Hope that helps.
Alexander
rtx.c so that 'infinite
if' condition cannot be simplified and proven to be always false. Zdenek once
had to improve simplify-rtx.c for this reason, as the audit trail shows.
[1] http://gcc.gnu.org/PR32283
Hope that helps,
Alexander
for me with -fschedule-insns, -frename-registers or
-fselective-scheduling2 (all of which are disabled by default on x86-64 -O2).
Without those flags, second scheduler alone cannot lift the load due to
dependency on %eax.
Hope that helps.
Alexander
is quite complicated even without considering issues like this.
Thanks to Vladimir's pressure-sensitive scheduling patches, pre-RA scheduling
should solve this.
Alexander
hat is the norm when compiling for ia64, for example. I
don't think the backend should specifically care about it: the anti-dependency
gets zero latency, and the scheduler is able to issue the second instruction
on the same cycle after issuing the first.
Alexander
Hello,
As the title says, how can I remove articles posted
under my name "Alexander Verhaeghe" or e-mailaddress
"alexanderverhaeghe at yahoo dot com"
When I do a search in http://gcc.gnu.org/lists.html I
get 8 results which I would like to have removed,
espcially wh
"Free as in Freedom" in
http://www.gnu.org/home.html#ContactInfo
You're not even able to remove a couple of messages,
so how "free" am I now?
[EMAIL PROTECTED] wanted $300 for removal!
How "free" am I now? You should be ashamed of
yourselves!
Not only privacy is not respected, [EMAIL PROTECTED]
a
Quote Jan-Benedict Glaw "So please shut up now."
Quite friendly I must say, it's the german way I
suppose of handling things?
To Jan-Benedict Glaw I WON'T SHUT UP because of "Free
as in Freedom"!
--- Jan-Benedict Glaw <[EMAIL PROTECTED]> wrote:
> On Su
Always threatening, you're even worse than
Microsoft...
Once again "Free as in Freedom", how dare you to use
this? Please don't forget to mention that you want to
rip me off $300!
--- Robert Dewar <[EMAIL PROTECTED]> wrote:
> Alexander Verhaeghe wrote:
> > Quot
out someone, and when they
> do that, all your old posts will appear. Again,
> that's
> not a threat, just a statement of a fact that should
> be clear to anyone posting on any list.
>
> Alexander Verhaeghe wrote:
> > Go ahead threatening people, it's all what you
n 25, 2006 at 05:16:37PM -0700, Alexander
> Verhaeghe wrote:
> > Always threatening, you're even worse than
> > Microsoft...
> > Once again "Free as in Freedom", how dare you to
> use
> > this? Please don't forget to mention that you want
> to
>
* add documentation to the GCC site, how to build GCC with PGO
optimizations
* (if GCC community provides prebuilt gcc binaries) use PGO for the
prebuilt binaries. E.g. Clang and rustc already uses this approach.
Any feedback is appreciated.
Thanks in advance!
--
Best regards,
Alexander
a worked example where -ffp-contract=fast
caused a correctness issue in a widely used FOSS image processing application
that was quite hard to debug.
Obviously -Ofast and -ffast-math will still imply -ffp-contract=fast if we
make the change, so SPEC scores won't be affected.
Thanks.
Alexander
Hi Florian,
On Thu, 14 Sep 2023, Alexander Monakov wrote:
>
> On Thu, 14 Sep 2023, Florian Weimer via Gcc wrote:
>
> > While rebuilding CentOS Stream with -march=x86-64-v3, I rediscovered
> > several packages had test suite failures because x86-64 suddenly gained
&g
quirk about sNaNs and qNaNs.
Sorry, do you mean contracting 'x + x - x' to 'x'? That is not allowed
due to different result and lack of FP exception for infinities.
Contracting 'x + x - x' to fma(x, 2, -x) would be fine.
Alexander
hard to implement for C. But I was somewhat discouraged by the lack of
front-end maintainers reaction to the patch implementing the =standard,
so I didn't pursue that.
The hardest part would be popping the pragma state when leaving a block,
which didn't seem difficult (at least for C).
Alexander
ult when x is so large that 'x + x' is
not representable (exponent would overflow), but that's exactly what
contraction is about?
Alexander
ound statements (!= blocks).
Thanks for the clarification. Let me note that the standard somehow
decided to make out-of-place pragma a (compile-time) UB rather than
a constraint violation, leaving us free to make it work for blocks
(or launch Nethack).
Alexander
example off-hand, since apart from FMA
fused operations are rarely available in instruction sets.
Alexander
is compiled.
>
> Makes sense. The target-specific macro `_WIN32` serves that purpose.
>
> However `fork()` doesn't actually exist there, and linking should indeed fail.
> Maybe `__gcov_fork()` shouldn't be defined at all.
A possible stop-gap solution is using __builtin_fork() instead.
Alexander
cdir)/libgcov.h
> > $(gcc_compile) -DL$* -c $(srcdir)/libgcov-interface.c
> >
> > It looks like this is done to emulate -Wl,--gc-sections without separate
> > source files. Unfortunately, this is all built unconditionally.
>
> Hmm, so why's it then referenced and not "GCed"?
On MinGW the corresponding .o file is not unpacked by the linker from libgcov.a
when fork is not referenced, so it used to work fine. The problem is that now
building the .o fails due to undeclared fork.
> The classical "solution" is to make the reference weak via sth like
>
> extern typeof(fork) fork () __attribute__((weak));
This won't help here since fork is undeclared. Using __builtin_fork, as
mentioned in adjacent sub-thread, should work.
Alexander
uiltin_constant_p(nonzero)) {
res = -1;
asm("bsf %1, %0" : "+r"(res) : "rm"(x));
} else if (nonzero) {
asm("bsf %1, %0" : "=r"(res) : "rm"(x));
} else {
res = -1;
}
return res;
}
Does it work for you?
HTH
Alexander
s
the __kernel_vsyscall entrypoint, which provides whichever of
{ int 0x80, sysenter, syscall } methods is available and fastest.
Or am I missing something?
Alexander
On Mon, 8 Apr 2024, Florian Weimer wrote:
> * Alexander Monakov:
>
> >> There is quite a bit of variance in how the kernel is entered. On
> >> x86-64, one once popular mechanism is longer present in widely-used
> >> kernels.
> >
> > I assu
rhaps somebody remembers where it was (I'm thinking Bugzilla) and could point
me to it? My attempts to search for it aren't turning anything up so far.
If someone knows what semantics GCC implements, that also would be welcome.
Thank you.
Alexander
in
> > tree_node_structure_for_code, at tree:527"
> >
> > How should I approach reporting this to get it fixed?
>
> It sounds you might got faulty memory in your system.
Allan, what CPU is that on? If Intel 13th or 14th gen, that's not entirely
unexpected, unfortunately, due to voltage management issues (or manufacturing,
on some earlier samples).
Alexander
ng it twice to Maxim - new google interface made
my text too "rich")
thank you in advance,
Alexander
must somehow let the user know about that (btw linux dynamic
loader silently allows copy against DT_SYMBOLIC).
thanks,
Alexander
2013/4/3 Andrew Haley :
> On 03/29/2013 06:55 PM, Alexander Ivchenko wrote:
>
>> When compiling a shared library with "-mandroid -shared" the
reak BC, so fixing them was considered the best option.
> (I think the initial support predates the default Bsymbolic setting.)
Oh, I see now. Since x86 port started when Bsymbolic was the default I
don't see any point of implementing R_386_COPY relocation in dynamic
loader for it. (same can be applied for R_MIPS_COPY)
best regards,
Alexander
;std::pointer_to_binary_function,
const Expr, bool>'
I don't know how these errors can be fixed. The GCC bug 1773 was closed,
but g++ 4.7 is still broken in OpenIndiana/illumos environment. Need
your advices. If you wish I can share dejagnu logs somewhere (with
patched illumos
to set flag_shlib
without -fPIC is entirely intended and WONTFIX.
Thanks.
Alexander
give them a smoother rope. I'd do the latter, but I don't
see if there were any reasons for the current implementation to be the way it
is, and hence I'm asking on the mailing list.
Thanks.
Alexander
101 - 200 of 286 matches
Mail list logo
