On Thu, Oct 13, 2022 at 11:14 PM Vineet Gupta wrote:
>
>
>
> On 10/13/22 13:30, Uros Bizjak wrote:
>
> OTOH, for x86 (same default toggles) there's no barriers at all.
>
> _Z10bar_seqcstiPi:
> endbr64
> movlg(%rip), %eax
>
On Thu, Oct 13, 2022 at 9:31 PM Vineet Gupta wrote:
>
> Hi,
>
> I have a testcase (from real workloads) involving C++ atomics and trying
> to understand the codegen (gcc 12) for RVWMO and x86.
> It does mix atomics with non-atomics so not obvious what the behavior is
> intended to be hence some ex
On Wed, Jun 16, 2021 at 6:08 PM Liu Hao wrote:
>
> 在 2021-06-16 23:22, Jonathan Wakely via Gcc 写道:
> >> Is there someone who an dig into the commit below
> >> and try to find out how the author field was incorrectly set?
> >
> > That gets set when the local commit is done, before pushing it to the
The build currently fails to build for me on x86_64 in fixincludes:
/home/uros/gcc-build/./gcc/xgcc -B/home/uros/gcc-build/./gcc/
-B/usr/local/x86_64-pc-linux-gnu/bin/
-B/usr/local/x86_64-pc-linux-gnu/lib/ -isystem
/usr/local/x86_64-pc-linux-gnu/include -isystem
/usr/local/x86_64-pc-linux-gnu/sys-
Sorry for spamming gcc-patches@ ML, this message should go to gcc@.
-- Forwarded message -
From: Uros Bizjak
Date: Tue, Jan 5, 2021 at 3:04 PM
Subject: git commit hook does not record my patches to PRs
To: gcc-patc...@gcc.gnu.org
Cc: Martin Liska
Hello!
For some reason git
On Thu, Nov 5, 2020 at 2:39 PM Alexander Monakov wrote:
>
> 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
> > >
On Thu, Nov 5, 2020 at 1:32 PM Uros Bizjak wrote:
>
> On Thu, Nov 5, 2020 at 1:24 PM Richard Biener
> wrote:
>
> > > This is even worse undefined behavior compared to my solution above:
> > > this code references memory in uintptr_t type, while mine preserves the
&g
On Thu, Nov 5, 2020 at 1:24 PM Richard Biener
wrote:
> > This is even worse undefined behavior compared to my solution above:
> > this code references memory in uintptr_t type, while mine preserves the
> > original type via __typeof. So this can visibly break with TBAA (though
> > the kernel uses
On Thu, Nov 5, 2020 at 1:14 PM Alexander Monakov wrote:
> > I was also thinking of introducing of operand modifier, but Richi
> > advises the following:
> >
> > --cut here--
> > typedef __UINTPTR_TYPE__ uintptr_t;
> >
> > __seg_fs int x;
> >
> > uintptr_t test (void)
> > {
> > uintptr_t *p = (ui
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?
> >
> > Please see the end of [2], where the offset to is pas
On Thu, Nov 5, 2020 at 10:36 AM Alexander Monakov wrote:
>
> On Thu, 5 Nov 2020, Uros Bizjak via Gcc wrote:
>
> > > Looks like writing
> > >
> > > typeof((typeof(_var))0) tmp__;
> > >
> > > makes it work. Assumes there's a literal
On Thu, Nov 5, 2020 at 10:36 AM Alexander Monakov wrote:
>
> On Thu, 5 Nov 2020, Uros Bizjak via Gcc wrote:
>
> > > Looks like writing
> > >
> > > typeof((typeof(_var))0) tmp__;
> > >
> > > makes it work. Assumes there's a literal
On Thu, Nov 5, 2020 at 8:26 AM Richard Biener
wrote:
>
> On Wed, Nov 4, 2020 at 7:33 PM Uros Bizjak via Gcc wrote:
> >
> > Hello!
> >
> > I was looking at the recent linux patch series [1] where segment
> > qualifiers (named address spaces) were introduced to
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--
Unfortunately, gcc does not provide a way to remove segment
qualifiers, which is needed to use ty
On Sun, Nov 1, 2020 at 2:04 PM Iain Sandoe wrote:
>
> Hi Uros,
>
> I was looking into the test fails for the new keylocker-* testcases.
>
> Many are because of missing “_” (which seems to happen more often than
> not). These I can fix trivially.
>
> But some are because we have:
>
> name+constant
I would like to inform GCC community, that I decided to step down from
maintaining x86 vector ISA part. x86 vector ISA has its own
non-responsive maintainer, but I have filled the maintainers role
nevertheless, until gcc-10 was released.
Unfortunately, maintaining the whole x86 target has been too
On Thu, May 7, 2020 at 8:16 AM Richard Biener
wrote:
>
> On May 6, 2020 11:15:08 PM GMT+02:00, Uros Bizjak via Gcc
> wrote:
> >Hello!
> >
> >I wonder, if the build process really needs to build all multilibs in
> >stage-1 bootstrap build. IIRC, stage-1 uses sy
Hello!
I wonder, if the build process really needs to build all multilibs in
stage-1 bootstrap build. IIRC, stage-1 uses system compiler to build
stage-1 gcc, so there is no need for multilibs, apart from library
that will be used by stage-1 gcc during compilation of stage-2
compiler.
Uros.
Hello!
> Over at RTEMS, we have had a report that this very old code has quit
> compiling:
>
> #ifdef __SSE__
> #define _CPU_Context_restore_fp(fp_context_pp) \
> do { \
>__asm__ __volatile__( \
> "fldcw %0"
$ git clone https://gcc.gnu.org/git/gcc.git
Cloning into 'gcc'...
fatal: repository 'https://gcc.gnu.org/git/gcc.git/' not found
Uros.
On Tue, Jan 14, 2020 at 11:34 AM Jonathan Wakely wrote:
>
> On Tue, 14 Jan 2020 at 09:22, Uros Bizjak wrote:
> >
> > gcc_update, when called from newly initialized and pulled tree does not
> > work:
>
> Initialized how?
1035 mkdir gcc
1036 cd gcc
1037
gcc_update, when called from newly initialized and pulled tree does not work:
--cut here--
$ contrib/gcc_update
Updating GIT tree
There is no tracking information for the current branch.
Please specify which branch you want to rebase against.
See git-pull(1) for details.
git pull
If you wi
>> Looks like I spoke too soon. It's hanging/spinning again. Do you
>> have any suggestion for how I can help debug it?
>
> Send the spinning process a SIGQUIT. It should crash with a stack
> backtrace showing what it is doing at that point.
I see a segfault in seemingly a random place, even wi
On Thu, Jun 27, 2019 at 2:14 PM Jan Beulich wrote:
>
> >>> On 27.06.19 at 14:07, wrote:
> > On Thu, Jun 27, 2019 at 1:31 PM Jan Beulich wrote:
> >>
> >> >>> On 27.06.19 at 13:02, wrote:
> >> > On Thu, Jun 27, 2019 at 12:47 PM Jan Beulich wrote:
> >> >>
> >> >> >>> On 27.06.19 at 12:22, wrote:
On Thu, Jun 27, 2019 at 1:31 PM Jan Beulich wrote:
>
> >>> On 27.06.19 at 13:02, wrote:
> > On Thu, Jun 27, 2019 at 12:47 PM Jan Beulich wrote:
> >>
> >> >>> On 27.06.19 at 12:22, wrote:
> >> > On Thu, Jun 27, 2019 at 11:10 AM Jan Beulich wrote:
> >> >>
> >> >> >>> On 27.06.19 at 11:03, wrote
On Thu, Jun 27, 2019 at 12:47 PM Jan Beulich wrote:
>
> >>> On 27.06.19 at 12:22, wrote:
> > On Thu, Jun 27, 2019 at 11:10 AM Jan Beulich wrote:
> >>
> >> >>> On 27.06.19 at 11:03, wrote:
> >> > With just an "m" constraint misaligned memory operands won't be forced
> >> > into a register, and h
On Thu, Jun 27, 2019 at 11:10 AM Jan Beulich wrote:
>
> >>> On 27.06.19 at 11:03, wrote:
> > With just an "m" constraint misaligned memory operands won't be forced
> > into a register, and hence cause #GP. So far this was guaranteed only
> > in the case that CVT{,T}PD2DQ were chosen (which looks
On Tue, May 21, 2019 at 6:15 PM Iain Sandoe wrote:
>
> Hi Uros,
>
> It seems to me that (even if it was working “properly”, which it isn't)
> ‘-mfentry’ would break ABI on Darwin for both 32 and 64b - which require
> 16byte stack alignment at call sites.
>
> For Darwin, the dynamic loader enfor
On Tue, Mar 12, 2019 at 9:54 PM Jeff Law wrote:
>
> On 3/12/19 2:50 PM, Eric Gallager wrote:
> > On 3/12/19, Martin Liška wrote:
> >> Hi.
> >>
> >> I've thinking about the file split about quite some time, mainly
> >> in context of PR84402. I would like to discuss if it's fine for
> >> maintainer
Hello!
Currently, CET is enabled by default for linux if target supports
multi-byte NOPs and if assembler supports CET insn. Effectively, with
newer binutils, CET support is an opt-out feature.
I don't think this should be the case, and I propose to consider CET
as an opt-in feature. Multi-byte N
On Mon, Sep 5, 2016 at 1:45 PM, Joseph Myers wrote:
> On Sun, 4 Sep 2016, Uros Bizjak wrote:
>
>> It looks that different handling of _Complex char, _Complex short and
>> _Complex float is there on purpose. Is (was?) there a limitation in a
>> c language standard that p
On Fri, Sep 2, 2016 at 2:11 PM, Jakub Jelinek wrote:
> On Fri, Sep 02, 2016 at 12:09:30PM +, Joseph Myers wrote:
>> On Fri, 2 Sep 2016, Uros Bizjak wrote:
>>
>> > argument. Passing _Complex float as a variable argument never
>> > worked on
On Wed, Apr 27, 2016 at 4:39 PM, Uros Bizjak wrote:
> On Wed, Apr 27, 2016 at 4:26 PM, Ilya Enkovich wrote:
>
>>>> >> > X86_TUNE_GENERAL_REGS_SSE_SPILL: Try to spill general regs to SSE
>>>> >> > regs
>>>> >> instead of memory.
On Wed, Apr 27, 2016 at 4:26 PM, Ilya Enkovich wrote:
>>> >> > X86_TUNE_GENERAL_REGS_SSE_SPILL: Try to spill general regs to SSE
>>> >> > regs
>>> >> instead of memory.
>>> >> >
>>> >> > I tried enabling the above tuning with -march=bdver4 -Ofast -mtune-
>>> >> ctrl=general_regs_sse_spill.
>>> >>
[1] still says in its third paragraph:
--q--
Important: GCC's support for C++11 is still experimental. Some
features were implemented based on early proposals, and no attempt
will be made to maintain backward compatibility when they are updated
to match the final C++11 standard.
--/q--
[1] https:
Hello!
> The patch was bootstrapped and tested on x86/x86-64.
>
> Committed as rev. 225618.
>
> 2015-07-09 Vladimir Makarov
>
> PR rtl-optimization/66782
> * lra-int.h (struct lra_insn_recog_data): Add comment about
> clobbered hard regs for arg_hard_regs.
> * lr
On Mon, Jul 6, 2015 at 11:49 AM, FX wrote:
> Many of the floating point-related builtins are type-generic, including
> __builtin_{isfinite,isinf_sign,isinf,isnan,isnormal,isgreater,islesser,isunordered}.
> However, __builtin_signbit is not. It would make life easier for the
> implementation of
Hello!
Recent commit introduced following build warning:
/home/uros/gcc-svn/trunk/lto-plugin/lto-plugin.c: In function
‘claim_file_handler’:
/home/uros/gcc-svn/trunk/lto-plugin/lto-plugin.c:930:16: warning:
implicit declaration of function ‘asprintf’
[-Wimplicit-function-declaration]
t = hi
On Wed, Jun 3, 2015 at 2:47 PM, Kumar, Venkataramanan
wrote:
> Hi,
>
> I was going through the "monitor" and "mwait" builtin implementation.
> I need clarification on the parameters passed to _mm_mwait intrinsic.
>
> Should the constraint be swaped for the operands in the pattern?
Please swap th
On Wed, May 13, 2015 at 8:17 PM, Alexander Monakov wrote:
> Can you also tell me why ..._pop call and sibcall instructions are predicated
> on !TARGET_64BIT?
Because " /* None of the 64-bit ABIs pop arguments. */ ".
Please see call_pop documentation and ix86_return_pops_args from
config/i386/
On Thu, May 7, 2015 at 6:24 PM, Richard Henderson wrote:
> On 04/24/2015 06:32 PM, Jan Hubicka wrote:
>> Also I believe it was kind of Richard's design deicsion to avoid use of
>> (paradoxical) subregs for vector conversions because these have funny
>> implications.
>
> Yes indeed.
>
>> The code f
On Fri, Apr 24, 2015 at 12:14 PM, Uros Bizjak wrote:
>>>>> I was looking into PR65105 and tried to generate SSE computation for a
>>>>> simple 64bit a + b + c sequence. Having no scalar integer instructions in
>>>>> SSE I have to use vector varia
On Fri, Apr 24, 2015 at 12:09 PM, Ilya Enkovich wrote:
I was looking into PR65105 and tried to generate SSE computation for a
simple 64bit a + b + c sequence. Having no scalar integer instructions in
SSE I have to use vector variants.
>>>
>>> Is this approach really better that ha
On Fri, Apr 24, 2015 at 11:45 AM, Uros Bizjak wrote:
> On Fri, Apr 24, 2015 at 11:22 AM, Ilya Enkovich
> wrote:
>
>> I was looking into PR65105 and tried to generate SSE computation for a
>> simple 64bit a + b + c sequence. Having no scalar integer instructions in
>&g
On Fri, Apr 24, 2015 at 11:22 AM, Ilya Enkovich wrote:
> I was looking into PR65105 and tried to generate SSE computation for a
> simple 64bit a + b + c sequence. Having no scalar integer instructions in
> SSE I have to use vector variants.
Is this approach really better that having two add/add
On Tue, Jan 20, 2015 at 3:23 PM, H.J. Lu wrote:
>>> > ia32 is confusing because ia64 (a well known term) sounds related but
>>> > can't be farther away from it, and it's also vendor specific. Our
>>> > traditional i386 seems better to me (although it has its own problems,
>>> > but I'm not aware
On Tue, Jan 20, 2015 at 3:26 AM, Sandra Loosemore
wrote:
>> I've noticed that the GCC user documentation is quite inconsistent about
>> the name(s) it uses for i386/x86-64/etc targets. invoke.texi has a
>> section for "i386 and x86-64 Options", but in other places the manual
>> uses x86, X86, i?
On Tue, Nov 4, 2014 at 1:00 AM, Ian Taylor wrote:
> On Mon, Nov 3, 2014 at 9:02 AM, Dominik Vogt wrote:
>> On Thu, Oct 30, 2014 at 08:05:14AM -0700, Ian Taylor wrote:
>>> On Thu, Oct 30, 2014 at 5:46 AM, Dominik Vogt
>>> wrote:
>>> > I'm not quite sure about the best approach. The attempt to
>
On Thu, Oct 30, 2014 at 8:40 AM, Uros Bizjak wrote:
> Recent go changes broke alpha bootstrap:
> $files/space/homedirs/uros/gcc-svn/trunk/libgo/go/os/stat_atim.go:22:29:
> error: reference to undefined field or method ‘Mtim’
>modTime: timespecTo
Hello!
Recent go changes broke alpha bootstrap:
/bin/mkdir -p .; files=`echo
/space/homedirs/uros/gcc-svn/trunk/libgo/go/os/dir_largefile.go
/space/homedirs/uros/gcc-svn/trunk/libgo/go/os/dir.go
/space/homedirs/uros/gcc-svn/trunk/libgo/go/os/doc.go
/space/homedirs/uros/gcc-svn/trunk/libgo/go/os/e
html
>
> Yeah, old glibcs are totally incompatible with -fno-gnu89-inline.
> Not sure if it is easily fixincludable, if yes, then -fgnu89-inline should
> be used for code like libgcc which is built with the newly built compiler
> before it is fixincluded.
> Or we need -fgnu89-inline by def
On Thu, Oct 16, 2014 at 11:25 AM, Uros Bizjak wrote:
> Recent change caused bootstrap failure on CentOS 5.11:
>
> /usr/bin/ld: Dwarf Error: found dwarf version '4', this reader only
> handles version 2 information.
> unwind-dw2-fde-dip_s.o: In function `__pthread_clean
Hello!
Recent change caused bootstrap failure on CentOS 5.11:
/usr/bin/ld: Dwarf Error: found dwarf version '4', this reader only
handles version 2 information.
unwind-dw2-fde-dip_s.o: In function `__pthread_cleanup_routine':
unwind-dw2-fde-dip.c:(.text+0x1590): multiple definition of
`__pthread_
Hello!
>> The consensus seems to be to go forward with this change. I will
>> commit the patch in 24 hours unless I hear objections.
>
> I made the change. Please report any fallout to me.
i686-linux-gnu testsuite trivially regressed [1]:
FAIL: gcc.dg/20020122-2.c (test for excess errors)
FAIL
On Sun, Oct 12, 2014 at 7:44 PM, Uros Bizjak wrote:
>>> Right. And my question is what happens if we aren't as aggressive here.
>>> What happens if before this check we return nonzero if X or Y is a VALUE?
>>> Do we then get into memrefs_conflict_
On Fri, Oct 10, 2014 at 8:37 PM, Uros Bizjak wrote:
>> Right. And my question is what happens if we aren't as aggressive here.
>> What happens if before this check we return nonzero if X or Y is a VALUE?
>> Do we then get into memrefs_conflict_p and does it do the rig
On Fri, Oct 10, 2014 at 8:18 PM, Jeff Law wrote:
I'd like to bring PR 63475 to the attention of RTL maintainers. The
problem in the referred PR exposed the RTL infrastructure problem,
where VALUE expressions are leaked instead of MEM expresions into
various parts of aliasing-d
On Fri, Oct 10, 2014 at 7:56 PM, Jeff Law wrote:
> On 10/09/14 06:14, Uros Bizjak wrote:
>>
>> Hello!
>>
>> I'd like to bring PR 63475 to the attention of RTL maintainers. The
>> problem in the referred PR exposed the RTL infrastructure problem,
>> w
Hello!
I'd like to bring PR 63475 to the attention of RTL maintainers. The
problem in the referred PR exposed the RTL infrastructure problem,
where VALUE expressions are leaked instead of MEM expresions into
various parts of aliasing-detecting support functions.
As an example, please consider fol
Hello!
> I have just submitted a patch emitting some new floating-point code from the
> Fortran front-end,
> improving our IEEE support there:
> https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02444.html
>
> However, in one of the cases where we emit a call to __builtin_remainderf(),
> we get wro
On Tue, Sep 23, 2014 at 7:13 PM, Joseph S. Myers
wrote:
>> Joseph, is there any support for underflow control in soft-fp library?
>> >From a private correspondence with FX about implementing gfortran IEEE
>> support for extended modes, soft-fp that implements 128bit support on
>> x86 could read t
Hello!
Joseph, is there any support for underflow control in soft-fp library?
>From a private correspondence with FX about implementing gfortran IEEE
support for extended modes, soft-fp that implements 128bit support on
x86 could read this setting from FPU control registers and handle
denormals ac
On Tue, Sep 23, 2014 at 3:54 PM, Ilya Enkovich wrote:
> Here is a patch which combines results of my and Vladimir's work on EBX
> enabling.
>
> It works OK for SPEC2000 and SPEC2006 on -Ofast + LTO. It passes bootstrap
> but there are few new failures in make check.
>
> gcc.target/i386/pic-1.c
Hello!
> I ran into this non-reproducible failure while testing a non-bootstrap build
> on x86_64:
>
> ...
> PASS: g++.dg/ubsan/align-2.C -Os (test for excess errors)
I found the same problem on x86_64 CentOS 5.10 when testing with -m32:
gcc unix/-m32:
FAIL: c-c++-common/ubsan/align-2.c -
Hello!
> While I'm here, in i386.md some of the flag setting operations specify a mode
> and some don't . Eg
>
> (define_expand "cmp_1"
> [(set (reg:CC FLAGS_REG)
> (compare:CC (match_operand:SWI48 0 "nonimmediate_operand")
>
>
> (define_insn "*add_3"
> [(set (reg FLAGS_REG)
> (compar
Hello!
> I added code to GCC Bugzilla last night to collect IP addresses from
> requests for new accounts. 80% - 90% of requests are coming from the
> following IP ranges:
>
> 62.122.72.x - 62.122.79.x
> 91.229.229.x
> 185.2.32.x
> 185.44.77.x - 185.44.79.x
> 188.72.126.x - 188.72.127.x
> 188.72.9
> I again disabled account creation on GCC Bugzilla due to spammers being
> still very active. 117 user accounts have been created since yesterday.
Please immediately disable account creation on Bugzilla until an
effective solution to prevent spam is found. There is another spam
attack going on w
Hello!
> 311 bugs have been created on GCC Bugzilla since yesterday. Only 2 are
> valid bugs. The remaining 309 ones are all spam and have been moved into
> the 'spam' component and marked as INVALID.
We can also avoid archiving bugs with "spam" component to gcc-bugs@ ML.
Uros.
On Fri, Aug 22, 2014 at 2:21 PM, Ilya Enkovich wrote:
> On Cauldron 2014 we had a couple of talks about relaxation of ebx usage in
> 32bit PIC mode. It was decided that the best approach would be to not fix
> ebx register, use speudo register for GOT base address and let allocator do
> the re
On Thu, Aug 28, 2014 at 3:29 PM, Ilya Enkovich wrote:
>>> diff --git a/gcc/calls.c b/gcc/calls.c
>>> index 4285ec1..85dae6b 100644
>>> --- a/gcc/calls.c
>>> +++ b/gcc/calls.c
>>> @@ -1122,6 +1122,14 @@ initialize_argument_information (int num_actuals
>>> ATTRIBUTE_UNUSED,
On Thu, Aug 28, 2014 at 2:54 PM, Ilya Enkovich wrote:
> diff --git a/gcc/calls.c b/gcc/calls.c
> index 4285ec1..85dae6b 100644
> --- a/gcc/calls.c
> +++ b/gcc/calls.c
> @@ -1122,6 +1122,14 @@ initialize_argument_information (int num_actuals
> ATTRIBUTE_UNUSED,
>
On Fri, Aug 22, 2014 at 2:21 PM, Ilya Enkovich wrote:
> Hi,
>
> On Cauldron 2014 we had a couple of talks about relaxation of ebx usage in
> 32bit PIC mode. It was decided that the best approach would be to not fix
> ebx register, use speudo register for GOT base address and let allocator do
>
On Thu, Aug 28, 2014 at 10:37 AM, Ilya Enkovich wrote:
> 2014-08-28 1:39 GMT+04:00 Jeff Law :
>> On 08/26/14 15:42, Ilya Enkovich wrote:
>>>
>>> diff --git a/gcc/calls.c b/gcc/calls.c
>>> index 4285ec1..85dae6b 100644
>>> --- a/gcc/calls.c
>>> +++ b/gcc/calls.c
>>> @@ -1122,6 +1122,14 @@ initializ
On Thu, Aug 21, 2014 at 8:18 AM, Uros Bizjak wrote:
> It looks that gmake-4.0 terminates gcc testrun immediately after one
> of the jobs fails. Does anybody else see this behavior? Do I need to
> update gmake invocation or is "gmake -j 4 -k check" from the toplevel
> bu
Hello!
It looks that gmake-4.0 terminates gcc testrun immediately after one
of the jobs fails. Does anybody else see this behavior? Do I need to
update gmake invocation or is "gmake -j 4 -k check" from the toplevel
build directory still OK?
Uros.
On Mon, Jul 7, 2014 at 1:47 PM, Jakub Jelinek wrote:
> On Mon, Jul 07, 2014 at 03:35:06PM +0400, Evgeny Stupachenko wrote:
>> The key problem here is that EBX is not used in register allocation.
>> If we relax the restriction on EBX the performance is back, but there
>> are several fails.
>> Some
On Thu, Jul 3, 2014 at 9:14 AM, Uros Bizjak wrote:
> On Wed, Jul 2, 2014 at 11:13 PM, FX wrote:
>> I’ve recently added IEEE support for the Fortran front-end and library. As
>> part of that, the front-end should be able to determine which of the
>> available floating
On Wed, Jul 2, 2014 at 11:13 PM, FX wrote:
> I’ve recently added IEEE support for the Fortran front-end and library. As
> part of that, the front-end should be able to determine which of the
> available floating-point types are IEEE-conforming [1]. Right now, I’ve taken
> a conservative approac
On Thu, Feb 6, 2014 at 8:01 PM, Xinliang David Li wrote:
> It is a bug in the help message dump. You can see that
> ftree-loop-vectorize ftree-slp-vectorize are indeed enabled.
I see. It would be also nice to fix -O3 entry in doc/invoke.texi that
currently reads:
--cut here--
@item -O3
@opindex
Hello!
4.9 does not enable -ftree-vectorize for -O3 (and Ofast) anymore. Is
this intentional?
$/ssd/uros/gcc-build/gcc/xgcc -B /ssd/uros/gcc-build/gcc -O3 -Q
--help=optimizers
...
-ftree-vectorize [disabled]
...
This is the reason for low scores on SciMark v2.0 as conducted
Hello!
> I have been seeing 3 libstdc++ tests:
>
> FAIL: 17_intro/headers/c++200x/stdc++.cc (test for excess errors)
> FAIL: 17_intro/headers/c++200x/stdc++_multiple_inclusion.cc (test for excess
> errors)
> FAIL: 30_threads/async/async.cc execution test
>
> fail/pass at random on a fast machine.
On Sun, Aug 4, 2013 at 2:34 AM, NightStrike wrote:
> On Mon, Jul 22, 2013 at 5:22 AM, Igor Zamyatin wrote:
>> Hi All!
>>
>> Unfortunately now the compiler generates wrong code for i686 target
>> when options -O3 and -flto are used. It started more than a month ago
>> and reflected in PR57602.
>>
Hello!
c-c++-common/asan/null-deref-1.c test can generate read-modify-write
instruction ("incl 40(%eax)") when compiled with -Os. However,
address-sanitizer only calls __asan_report_load4 in this case. With
-O2, load of value, modification and store are different instructions,
and address-sanitize
Hello!
x86_64 has particularly interesting address mode limitations when
"high" 8bit registers (%ah, %dh, %ch and %bh) are handled. Following
examples are all valid:
movb (%rdx), %ah
addb (%rdx), %ah
but when extended register is part of a memory address, insn requires
REX prefix
Hello!
> Compare the log file of the test runs from my lto bootstrap:
>
> http://gcc.gnu.org/ml/gcc-testresults/2012-11/msg00832.html
Platform: x86_64-unknown-linux-gnu
configure flags: ... --with-arch=native --with-tune=native
> to that of a "normal" x86_64 bootstrap:
>
> http://gcc.gnu.org/ml/
Hello!
Recent patch introduced 10% runtime regression on x86_64 targets in
rnflow Polyhedron benchmark [1]. Did somebody alread bisected to the
offending patch?
[1] http://gcc.opensuse.org/c++bench/polyhedron/polyhedron-summary.txt-2-0.html
Uros.
Hello!
> I've seen this today both for alpha and s390 cross from x86_64:
> > libtool: compile: /home/rth/work/gcc/bld-s390/./gcc/xgcc -shared-libgcc
> > -B/home/rth/work/gcc/bld-s390/./gcc -nostdinc++
> > -L/home/rth/work/gcc/bld-s390/s390x-linux/libstdc++-v3/src
> > -L/home/rth/work/gcc/bld-
Hello!
> Since r188786, expmed.c has this code:
> This results in warnings for expmed.c during bootstrap on
> powerpc64-unknown-linux-gnu:
>
> ../../trunk/gcc/expmed.c: In function ‘rtx_def* expand_mult(machine_mode, rtx,
> rtx, rtx, int)’:
> ../../trunk/gcc/expmed.c:3215:7: warning: ‘is_neg’ may
Hello!
I would like to point out that in libjava/sysdep/*/locks.h many
targets still implement atomics in assembly. These utility functions
can be implemented with new atomic builtins, avoiding quite some
compexity.
Maintaniers of unconverted targets (m68k, pa, powerpc, s390, sh and sparc) CC'd.
Hello!
I would like to point out that many targets get atomic_orM named
patterns wrong. The name should be atomic_orM, not atomic_iorM. These
targets are mostly these that were converted from sync named patterns
to atomic ones automatically.
This warning applies to 4.7 branch and current mainline
Hello!
>>> SSE ABI entries for i?86 in glibc were rejected. ?I proposed them like
>>> 4-5 years ago to make -mfpmath=sse not suck.
>>
>> With the new libm hopefully this can be revisited.
>>
>> But there's the ABI and there's the internal implementation.
>>
>> My point was just that relying on x87
On Mon, Feb 27, 2012 at 10:45 AM, Richard Guenther
wrote:
Well, at least with my cross it does.
this change, or something like it:
http://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=09a77c2ea0b41fdff8820cbcbe41b35762db5c45
introduces a reference to TS_TYPED into t
On Mon, Feb 27, 2012 at 10:08 AM, Richard Guenther
wrote:
>> Well, at least with my cross it does.
>>
>> this change, or something like it:
>>
>> http://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=09a77c2ea0b41fdff8820cbcbe41b35762db5c45
>>
>> introduces a reference to TS_TYPED into the 4.6 branch f
Hello!
> > For the math functions, this is normally more a libc feature, so you might
> > get very different results on different OS. Then again, by using
> > -ffast-math, you allow the math functions to return any random value, so I
> > can think of ways to make it even faster ;-)
>
> Also for ma
Hello!
For some reason bootstrap on Fedora 16 fails when compiling 32bit
libjava with undefined reference to `__cxa_call_unexpected':
libtool: link: /home/uros/gcc-build/./gcc/xgcc -shared-libgcc
-B/home/uros/gcc-build/./gcc -nostdinc++
-L/home/uros/gcc-build/x86_64-unknown-linux-gnu/32/libstdc++
On Wed, Nov 16, 2011 at 10:46 PM, Richard Henderson wrote:
>> +/* Checks for an atomic sequence of instructions beginning with a
>> LWARX/LDARX
>> + instruction and ending with a STWCX/STDCX instruction. If such a
>> sequence
>> + is found, attempt to step through it. A breakpoint is place
On Sun, Nov 13, 2011 at 10:41 PM, Richard Henderson wrote:
> On 11/12/2011 07:38 AM, Uros Bizjak wrote:
>> On Fri, Nov 11, 2011 at 8:58 PM, Dominique Dhumieres
>> wrote:
>>
>>> For the record, Jakub's comment on IRC:
>>>
>>>> with older
On Fri, Nov 11, 2011 at 8:58 PM, Dominique Dhumieres wrote:
> For the record, Jakub's comment on IRC:
>
>> with older gdb you simply had to find the stwcx
>> or whatever SC insn is, put a breakpoint after
>> it and continue instead of single stepping
I'm not familiar enough with gdb scripting to
On Fri, Nov 11, 2011 at 6:51 PM, Dominique Dhumieres wrote:
> Is your patch dealing with gcc.dg/simulate-thread/atomic-other-* running
> for ever without timeout? If yes, I have seen the same problem on
> powerpc-apple-darwin9. Could you add powerpc*-apple-darwin* to your
> patch?
Yes, the probl
On Thu, Oct 27, 2011 at 9:29 PM, Ian Lance Taylor wrote:
>> This testfile:
>>
>> #define aa 2
>> #undef aa
>> #define aa 3
>>
>> does not generate correct output with -fdump-go-spec. The result is:
>>
>> const _aa = 2
>> // undef _aa
>>
>> One would expect:
>>
>> const _aa = 2
>> // undef _aa
>>
1 - 100 of 266 matches
Mail list logo
