Krishna Myneni <[EMAIL PROTECTED]> wrote:
Under "gcc (GCC) 4.1.0 (SUSE Linux)", with CFLAGS = -m32 -S, and under all of
the optimization levels (O0 through O3), the following is produced :
flds .LC2
fldz
fxch %st(1)
fucompp
fnstsw %ax
:
The FXCH instruction is unnecessary if the FLDS and FLDZ
Hello!
Following are the results of povray 3.6.1 official benchmark
(benchmark.ini) on:
vendor_id : AuthenticAMD
cpu family : 15
model : 47
model name : AMD Athlon(tm) 64 Processor 3000+
stepping: 2
cpu MHz : 1809.278
cache size : 512 KB
Base com
Hello!
Does anybody else get these errors in libgfortran during clean bootstrap:
...
...
.libs/environ.o(.text+0x10d0):/usr/include/stdlib.h:401: first defined here
.libs/in_unpack_generic.o(.text+0x730): In function `atol':
/usr/include/stdlib.h:336: multiple definition of `atol'
.libs/environ
Michael James wrote:
Conceptually, the code is:
double sum = 0;
for(i=0; i
I have tried a half dozen variants at the source level in attempt to
get gcc to do this without branching (and without calling a helper
function isnan). I was not really able to succeed at either of these.
You
Michael James wrote:
And recompiled with the same flags. The assembly code for the loop
portion is identical to the one I posted above. Now though the code is
actually capable of producing NANs.
Just to be sure, I also tested this on my modified loop:
int main(void) {
printf("test(4, 6,
Denis Vlasenko wrote:
The following macro expands to some rather frightful code on the AVR:
#define BSWAP_16(x) \
x) >> 8) & 0xff) | (((x) & 0xff) << 8))
Sometimes gcc is generating better code if you cast
values instead of masking. Try:
( (uint8_t)((x) >> 8) | ((uint8_t)(x))
Hello!
At least on x86_64 and i686 SPEC score [1] and polyhedron [2] scores
dropped noticeably. For SPEC benchmarks, mgrid, galgel, ammp and
sixtrack tests are affected and for polygedron, ac (second regression
in the peak) and protein (?) regressed in that time frame.
[1] http://www.suse.de/~aj
H. J. Lu wrote:
Gcc 4.3 revision 119497 has very poor SPEC CPU 2006 FP performance
regressions on P4, Pentium M and Core Duo, comparing aganst
gcc 4.2 20060910. With -O2, the typical regressions look like
I think that you are looking at the same problem as
http://gcc.gnu.org/ml/gcc/2006-12/
Hello!
I'm particularly interested in this patch
(http://gcc.gnu.org/ml/gcc-patches/2005-07/msg01128.html); pretty
nice for
users of Pentium 3 and Athlon. Has it been or will it be integrated into
mainline?
This patch heavily depends on the functionality of optimize mode
switching pass. Unf
Hello!
There is a fixme in config/i386/driver-i386.c:
--cut here--
if (arch)
{
/* FIXME: i386 is wrong for 64bit compiler. How can we tell if
we are generating 64bit or 32bit code? */
cpu = "i386";
}
else
--cut here--
Couldn't simple "sizeof(long)" do the trick here,
David Edelsohn wrote:
I am pleased to announce that the GCC Steering Committee has
appointed Jan Hubicka and Uros Bizjak as co-maintainers of the i386 port.
Thank you!
Please find attached the patch that updates my MAINTAINERS entry.
2007-01-09 Uros Bizjak <[EMAIL PROTEC
Hello!
Recent committed patch breaks i386ssefp-2.c testcase, where maxsd is
not generated anymore.
I have looked a bit into this failure and noticed that for some reason
we don't perform ifcvt transformations during ce1 RTL pass. The second
transformation is still performed during ce2 pass, but
On 3/15/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> Recent committed patch breaks i386ssefp-2.c testcase, where maxsd is
> not generated anymore.
FWIW, I saw it both before and after the patch for PR 31127. I've
just tried reverting PR 30643 as well, but the problem remains. So
it's unre
On 3/15/07, Steven Bosscher <[EMAIL PROTECTED]> wrote:
On 3/15/07, Uros Bizjak <[EMAIL PROTECTED]> wrote:
> compile this with -O2 -msse2 -mfpmath=sse, and this testcase should
> compile to maxsd.
I'll look into it this weekend.
Thanks!
BTW: Your patch also cause
Hello!
Here are some effects of newly introduced -mpcX flag on a povray-3.6.1
(as kind of representative FP-heavy application to measure FP
performance).
The code was compiled using:
-O3 -march=native -funroll-all-loops -ffast-math -D__NO_MATH_INLINES
-malign-double -minline-all-stringops
(32b
On 4/3/07, Richard Guenther <[EMAIL PROTECTED]> wrote:
> It should be noted, that rendered picture in -mpc32 case developed a
> strange halo around rendered object (nice special effect ;), and this
> is clearly the effect of too low FP precision. -mpc64 and -mpc80
> rendered pictures were equal,
Hello!
> I was wondering, if:
>
> /* X86_TUNE_USE_INCDEC */
> ~(m_PENT4 | m_NOCONA | m_CORE2 | m_GENERIC),
>
> is correct. Should it be:
>
> /* X86_TUNE_USE_INCDEC */
> ~(m_PENT4 | m_NOCONA | m_GENERIC),
>
> ?
inc/dec has the same performance as add/sub on Core 2 Duo. But
inc/de
H. J. Lu wrote:
inc/dec has the same performance as add/sub on Core 2 Duo. But
inc/dec is shorter.
What about partial flag register dependency of inc/dec?
There is no partial flag register dependency on inc/dec.
My docs say that "INC/DEC does not change the carry flag". But
Mike Stump wrote:
But you have better resources that I, so if you think that C2D should
be left out of X86_TUNE_USE_INCDEC, then the patch is pre-approved
for mainline.
I'm confused again, it isn't that it should be left out, it is that it
should be included. My patch adds inc/dec selection
Hello!
typedef float v4sf __attribute__((vector_size(16)));
void foo(v4sf *a, v4sf *b, v4sf *c)
{
*a = *b + *c;
}
we no longer (since 4.0) synthesize v2sf (aka sse) operations
for f.i. -march=athlon (not that we were too successful at this
in 3.4 - we generated horrible code instead). Inste
Richard Guenther wrote:
Oh, so we used to expand to 3dnow? I see with gcc 3.4 produced:
foo:
pushl %ebp
movl%esp, %ebp
pushl %ebx
subl$84, %esp
movl12(%ebp), %eax
movl16(%ebp), %edx
[...]
movq-64(%ebp), %mm0
movl%e
Hello!
If I compile with
$ ~/usr/bin/gcc-4.0.0 -S Com_Code.cc -ffast-math -O2
the relevant generated code section is
#APP
fldln2; fxch; fyl2x
#NO_APP
fmulp %st, %st(2)
fxch%st(1)
#APP
fsqrt
#NO_APP
fld %st(1)
#APP
fsin
#NO_APP
fxch
Hello Scott!
Specifically, the -funsafe-math-optimizations flag doesn't work
correctly on AMD64 because the default on that platform is
-mfpmath=sse. Without specifying -mfpmath=387,
-funsafe-math-optimizations does not generate inline processor
instructions for most floating-point functions.
Hello!
It looks that i387 control word register definition is missing from register
definitions for i386 processor. Inside i386.h, we have:
#define FIXED_REGISTERS \
/*ax,dx,cx,bx,si,di,bp,sp,st,st1,st2,st3,st4,st5,st6,st7*/ \
{ 0, 0, 0, 0, 0, 0, 0, 1
Hello!
It looks that i387 control word register definition is missing from register
definitions for i386 processor. Inside i386.h, we have:
#define FIXED_REGISTERS \
/*ax,dx,cx,bx,si,di,bp,sp,st,st1,st2,st3,st4,st5,st6,st7*/ \
{ 0, 0, 0, 0, 0, 0, 0, 1
Hello!
> I'm writing an extensive article about floating-point programming on
> Linux, including a focus on GCC's compilers. This is an outgrowth of
> many debates about topics like -ffast-math and -mfpmath=sse|387, and I
> hope it will prove enlightening for myself and others.
I would like to
Hello!
> Well you really want both the fpcr and the mxcsr registers, since the fpcr
> only controls the x87 and the mxcsr controls the xmm registers. Note, in
> adding these registers, you are going to have to go through all of the
> floating
> point patterns to add (use:HI FPCR_REG) and (use:SI
Hello Evandro!
x87 registers. In contrast, x86_64 ABI specifies that FP
values are passed in SSE registers, so they avoid costly SSE
reg->stack moves. Until i386 ABI (together with supporting
math functions) is changed to something similar to x86_64,
use of -mfpmath=sse won't show all its pow
Quoting Jan Hubicka <[EMAIL PROTECTED]>:
> If you make FPCTR/MXCSR real registers, you will need to add use to all
> the arithmetic and move pattern that would consume quite some memory and
> confuse optimizers. I think you can get better around simply using volatile
> unspecs inserted by LCM pas
Hello!
Fair enough, so with 64 bit floats you have no right to expect an
accurate answer for sin(2^90). However, you DO have a right to expect
an answer in the range [-1,+1] rather than the 1.2e+27 that Richard
quoted. I see no words in the description of
-funsafe-math-optimizations to lead me
Hello Scott!
I do know this: Many, many scientific and mathematical programmers find
GCC frustrating and annoying, and most of those folk know far more about
numbers than I do. I wish more of these people would feel comfortable
posting to the GCC list, rather than sending private e-mails to my
i
Hello!
A sse function that gets its parameters via xmm regs and returns its result in
xmm reg is defined as:
__m128
func_sse (__m128 x, __m128 y)
{
__m128 xmm;
xmm = _mm_add_ss (x, y);
return xmm;
}
The RTL code that is used to call this function is produced as:
(call_insn/u:HI 30 29 31
Hello!
There is an interesting comparison of SPEC scores between gcc and icc:
http://people.redhat.com/dnovillo/spec2000.i686/gcc/individual-run-ratio.html
. A quick look at the graphs shows a big differences in achieved scores
between gcc and icc, mostly in SpecFP tests. I was trying to find
Hello!
> Iam trying to merge the following two instructions
> 1. addu r2, r3,r4
> 2. ld r5 ,mem(r2) # load from address calculated
> in the prev. instruction
> in to one single isntruction.
> 3. ldx r5 , mem(r3(r4)) # indexed load.
> I managed to do it with a define_peephole pattern
>
Hello!
> There's const0_rtx, const1_rtx and const2_rtx. How can I create a
> const rtx other than 0, 1, 2? I want to use it in md file, like
> operand[1] = 111.
> I know I must use const rtx here. How can I do it? A simple question,
> but just no idea where to find the answer.
operand[1] = GEN_
Hello!
With -march=pentium4 -mfpmath=sse -O2, we get an extra move for code like
double d = atof(foo);
int i = d;
callatof
fstpl -8(%ebp)
movsd -8(%ebp), %xmm0
cvttsd2si %xmm0, %eax
(This is Linux, Darwin is similar.) I think the difficulty is
Hello!
> I am using MMX built-ins and gcc-4.0-20050825 and I am experiencing generation
> of uneeded movq (at least I guess so, I am no assembler pro). I don't know
> which gcc snapshot introduced this, but a I know that some pre-release gcc 4.0
> didn't show this bad behaviour. (It's been some ti
Hello Paolo!
> Heh, I'm quite at a loss regarding PR22480. I don't know exactly what
> to do because i386 does not support, e.g. { 2, 4 } << { 1, 2 } (which
> would give {4, 16} as a result). There is indeed a back-end problem,
> because ashl3 is supposed to have two operands of the same mode,
>
implement your suggested approach:
-march=prescott enables fisttp
-msse3enables fisttp
-march=prescott -mno-sse3 enables fisttp
Otherwise fisttp is disabled.
2005-10-05 Uros Bizjak <[EMAIL PROTECTED]>
* config/i386/i386.h (TARGET_FISTTP): Enable for TARGET_SSE3.
Uros.
Quoting Uros Bizjak <[EMAIL PROTECTED]>:
> Following simple patch should implement your suggested approach:
>
> -march=prescott enables fisttp
> -msse3enables fisttp
> -march=prescott -mno-sse3 enables fisttp
>
> Otherwise fisttp is dis
Quoting steven at gcc dot gnu dot org <[EMAIL PROTECTED]>:
> --- Comment #5 from steven at gcc dot gnu dot org 2005-10-19 13:13
> ---
> That patch is yet another example of why we constantly keep having compile
> time
> problems. Just add more, and more, and more, and more. And act surp
Hello Steven!
> And FWIW, it is IMHO bad practice in general to just add new passes,
> instead of investigating why existing passes don't do the job and how
> they can be enhanced to do the job better.
There is no post-reload cse_condition_code_reg () pass, so perhaps we
have to add one. A cse_co
Ian Lance Taylor wrote:
Uros Bizjak <[EMAIL PROTECTED]> writes:
There is no post-reload cse_condition_code_reg () pass, so perhaps we
have to add one. A cse_condition_code_reg () walks all instructions by
itself, so I'm not sure if some existing post-reload CSE pass could
Paolo Bonzini wrote:
> I would like that svn print the URL of each file in the diff output, like
> CVS's
> `RCS file'. One of the scripts I use to test GCC (which I have not contributed
> yet because of the svn transition) used it to detect the directory in which
the > patch should apply.
Is it
Hello!
libgomp's configure checks -pthread option using following commands:
--cut here--
# Check to see if -pthread or -lpthread is needed. Prefer the former.
XPCFLAGS=""
CFLAGS="$CFLAGS -pthread"
AC_LINK_IFELSE(
[AC_LANG_PROGRAM(
[#include
void *g(void *d) { return NULL; }],
[pthread_t
Hello!
> Mark Mitchell's @file documentation change adds a @set directive to
> gcc-vers.texi in the build directory, but that file only depends on
> DEV-PHASE and BASE-VER, so it will never be correctly rebuilt using
> the new make rule. Just deleting it will remedy the problem.
Another problem
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
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
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 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!
> 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
[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:
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.
>>> >>
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 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 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 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, 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 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
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 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
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 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 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 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 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
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.
> 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!
> 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
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 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 -
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!
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 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!
> 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
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
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
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 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 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_
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
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_
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
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
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
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
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 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, 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 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 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 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 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 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 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 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 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
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 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 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
1 - 100 of 266 matches
Mail list logo
