Paulo Matos
> -Original Message-
> From: Alan Modra [mailto:amo...@gmail.com]
> Sent: 22 November 2013 04:42
> To: Paulo Matos
> Cc: gcc@gcc.gnu.org
> Subject: Re: rs6000: load_multiple code
>
> On Wed, Nov 20, 2013 at 05:06:13PM +, Paulo Matos wrote:
> > I am looking into how rs60
Is the version of texinfo buggy to generate online documentation?
Sorry for the delayed response. I was hoping the gcc expert on docs
would respond so I could see who that was.
I have been doing some work on Extended-Asm.html (see the work in
progress at
http://www.limegreensocks.com/gcc
Well, in your modified example, it is still due to jump threading that produce
code of bad control flow that cannot be if-converted and vectorized, though in
tree-vrp pass this time.
Try this
~/install-4.8/bin/gcc vect-ifconv-2.c -O2 -fdump-tree-ifcvt-details
-ftree-vectorize -save-temps -fno
On Fri, Nov 22, 2013 at 1:57 AM, Jonathan Wakely wrote:
> On 21 November 2013 21:17, Peter Bergner wrote:
>> On Thu, 2013-11-21 at 16:03 -0500, David Edelsohn wrote:
>>> Looks like another issue for the libsanitizer maintainers.
>>
>> I've been doing bootstraps, but didn't see this because the
>>
> >>> Looks like another issue for the libsanitizer maintainers.
> >>
> >> I've been doing bootstraps, but didn't see this because the
> >> kernel header linux/vt.h use on the RHEL6 system I was doing
> >> builds on has that field renamed. Looking at our SLES11
> >> devel system I do see the probl
Status
==
The trunk is now in Stage 3. To repeat what that means: the trunk
is open for general bugfixing, no new features should be added
at this point. For exceptions consult your friendly release
managers.
We have been in Stage 1 for 8 months now. Now is time to look
into one of the g
On Fri, Nov 22, 2013 at 11:03:22AM +, Bingfeng Mei wrote:
> Well, in your modified example, it is still due to jump threading that produce
> code of bad control flow that cannot be if-converted and vectorized, though in
> tree-vrp pass this time.
>
> Try this
> ~/install-4.8/bin/gcc vect-ifc
> Would appreciate a fix/work around!
Configure with --disable-libsanitizer.
--
Eric Botcazou
> > Would appreciate a fix/work around!
>
> Configure with --disable-libsanitizer.
Will do, thanks.
On Fri, Nov 22, 2013 at 12:47:17PM +0100, Arnaud Charlet wrote:
> > >>> Looks like another issue for the libsanitizer maintainers.
> > >>
> > >> I've been doing bootstraps, but didn't see this because the
> > >> kernel header linux/vt.h use on the RHEL6 system I was doing
> > >> builds on has that
Yes, it can be vectorized with your suggestion.
~/install-4.8/bin/gcc vect-ifconv-2.c -O2 -fdump-tree-ifcvt-details
-ftree-vectorize -save-temps --param max-jump-thread-duplication-stmts=0
See attached assemble file.
Bingfeng
-Original Message-
From: James Greenhalgh [mailto:james.g
> As my bugreport is being ignored it would help if one ouf our
Sorry. Which one?
> partners (hint! hint!) would raise this issue via the appropriate
> channel ;)
>
> Richard.
On Fri, Nov 22, 2013 at 3:56 PM, Jakub Jelinek wrote:
> On Fri, Nov 22, 2013 at 12:47:17PM +0100, Arnaud Charlet wrote:
>> > >>> Looks like another issue for the libsanitizer maintainers.
>> > >>
>> > >> I've been doing bootstraps, but didn't see this because the
>> > >> kernel header linux/vt.h u
On Fri, Nov 22, 2013 at 4:31 PM, Konstantin Serebryany
wrote:
> On Fri, Nov 22, 2013 at 3:56 PM, Jakub Jelinek wrote:
>> On Fri, Nov 22, 2013 at 12:47:17PM +0100, Arnaud Charlet wrote:
>>> > >>> Looks like another issue for the libsanitizer maintainers.
>>> > >>
>>> > >> I've been doing bootstrap
On Fri, Nov 22, 2013 at 04:19:26PM +0400, Konstantin Serebryany wrote:
> > As my bugreport is being ignored it would help if one ouf our
>
> Sorry. Which one?
I believe richi meant
https://bugzilla.novell.com/show_bug.cgi?id=849180
Martin
>
> > partners (hint! hint!) would raise this issue via
On Fri, Nov 22, 2013 at 4:35 PM, Martin Jambor wrote:
> On Fri, Nov 22, 2013 at 04:19:26PM +0400, Konstantin Serebryany wrote:
>> > As my bugreport is being ignored it would help if one ouf our
>>
>> Sorry. Which one?
>
> I believe richi meant
> https://bugzilla.novell.com/show_bug.cgi?id=849180
On Fri, 22 Nov 2013, DJ Delorie wrote:
> If I come up with some table-driven API to register
> "integer-like-types" and search/sort/choose from them, would that be a
> good starting point? Then we can #define *_type_node to a function
> call perhaps.
I am doubtful that it's appropriate for e.g.
On Fri, Nov 22, 2013 at 12:03 PM, Bingfeng Mei wrote:
> Well, in your modified example, it is still due to jump threading that produce
> code of bad control flow that cannot be if-converted and vectorized, though in
> tree-vrp pass this time.
>
> Try this
> ~/install-4.8/bin/gcc vect-ifconv-2.c -
On Fri, Nov 22, 2013 at 1:36 PM, Konstantin Serebryany
wrote:
> On Fri, Nov 22, 2013 at 4:35 PM, Martin Jambor wrote:
>> On Fri, Nov 22, 2013 at 04:19:26PM +0400, Konstantin Serebryany wrote:
>>> > As my bugreport is being ignored it would help if one ouf our
>>>
>>> Sorry. Which one?
>>
>> I bel
On Fri, Nov 22, 2013 at 09:31:18AM +, Paulo Matos wrote:
> > From: Alan Modra [mailto:amo...@gmail.com]
> > On Wed, Nov 20, 2013 at 05:06:13PM +, Paulo Matos wrote:
> > > I am looking into how rs6000 implements load multiple code
> > [snip]
> >
> > No pseudos are involved for the destinati
Hi,
On Fri, Nov 22, 2013 at 04:36:47PM +0400, Konstantin Serebryany wrote:
> On Fri, Nov 22, 2013 at 4:35 PM, Martin Jambor wrote:
> > On Fri, Nov 22, 2013 at 04:19:26PM +0400, Konstantin Serebryany wrote:
> >> > As my bugreport is being ignored it would help if one ouf our
> >>
> >> Sorry. Which
On Fri, 2013-11-22 at 12:30 +0100, Richard Biener wrote:
> On Fri, Nov 22, 2013 at 1:57 AM, Jonathan Wakely
> wrote:
> > Yes, it only seems to be a problem with SUSE kernels:
> > http://gcc.gnu.org/ml/gcc/2013-11/msg00090.html
>
> As my bugreport is being ignored it would help if one ouf our
> p
> /users/charlet/fsf/trunk/libsanitizer/sanitizer_common/sanitizer_linux.cc:
> Assembler messages:
> /users/charlet/fsf/trunk/libsanitizer/sanitizer_common/sanitizer_linux.cc:821:
> Error: .cfi_endproc without corresponding .cfi_startproc
> :21485: Error: open CFI at the end of file; missing .cfi
On Fri, Nov 22, 2013 at 7:00 PM, FX wrote:
>> /users/charlet/fsf/trunk/libsanitizer/sanitizer_common/sanitizer_linux.cc:
>> Assembler messages:
>> /users/charlet/fsf/trunk/libsanitizer/sanitizer_common/sanitizer_linux.cc:821:
>> Error: .cfi_endproc without corresponding .cfi_startproc
>> :21485:
I did this in order to build gcc, libgcc and libstdc++ independently.
when I do the simple integrated build process (following
http://gcc.gnu.org/install) :
cd $(GCC_OBJDIR); CFLAGS="-g -O0" $(GCC_SRCDIR)/configure
-quiet
--prefix=$(INSTALLDIR)
--target=$(TARGET)
Hi,
I encountered a bug in cselib.c:2360 using gnat7.1.2 (gcc4.7.3)
/* The register should have been invalidated. */
gcc_assert (REG_VALUES (dreg)->elt == 0);<<==
assert(false)
I investigated the dump and found that the crash occurred during 207r.dse2 pass.
On Fri, Nov 22, 2013 at 8:43 AM, BELBACHIR Selim
wrote:
> I did this in order to build gcc, libgcc and libstdc++ independently.
OK, fair enough.
Sorry, I don't know what is happening with your original bug report.
Ian
On 11/22/2013 04:43 PM, BELBACHIR Selim wrote:
>
> So, to build libgcc I would need --without-header to compensate for my small
> libc, and to build libstdc++ I would have to use --with-header in order to
> provide stdio.h ...
>
>
> Do you know a better way to solve that than building gcc, li
>>
>> So, to build libgcc I would need --without-header to compensate for my small
>> libc, and to build libstdc++ I would have to use --with-header in order to
>> provide stdio.h ...
>>
>>
>> Do you know a better way to solve that than building gcc, libgcc & libstdc++
>> independently ?
> W
On 11/22/13 09:43, BELBACHIR Selim wrote:
Hi,
I encountered a bug in cselib.c:2360 using gnat7.1.2 (gcc4.7.3)
/* The register should have been invalidated. */
gcc_assert (REG_VALUES (dreg)->elt == 0);<<==
assert(false)
I investigated the dump and found th
On 11/22/13 04:03, Bingfeng Mei wrote:
Well, in your modified example, it is still due to jump threading that produce
code of bad control flow that cannot be if-converted and vectorized, though in
tree-vrp pass this time.
Try this
~/install-4.8/bin/gcc vect-ifconv-2.c -O2 -fdump-tree-ifcvt-deta
Ok so I should avoid the auto_inc alternatives in PARALLEL. It's certainly a
quite rare RTL and I doubt the effort worth it.
-Message d'origine-
De : Jeff Law [mailto:l...@redhat.com]
Envoyé : vendredi 22 novembre 2013 17:55
À : BELBACHIR Selim; gcc@gcc.gnu.org
Objet : Re: post_inc mem
On 11/22/13 10:03, BELBACHIR Selim wrote:
Ok so I should avoid the auto_inc alternatives in PARALLEL. It's certainly a
quite rare RTL and I doubt the effort worth it.
That'd be my inclination as well.
I'm not sure what chip you're working on, but those kind of
multiple-output instructions ten
So if we are about to fix this in if-conversion, we need to do both in tree &
rtl as both ifcvt & ce passes cannot handle it.
I am still not convinced jump threading is good for target with predicated
execution (assuming no fix for if-conversion). I am doing benchmarking on our
target now.
B
On 11/22/13 10:13, Bingfeng Mei wrote:
So if we are about to fix this in if-conversion, we need to do both in tree & rtl
as both ifcvt & ce passes cannot handle it.
I am still not convinced jump threading is good for target with predicated
execution (assuming no fix for if-conversion). I am do
On 11/22/2013 04:54 PM, BELBACHIR Selim wrote:
>>>
>>> So, to build libgcc I would need --without-header to compensate for my
>>> small libc, and to build libstdc++ I would have to use --with-header in
>>> order to provide stdio.h ...
>>>
>>>
>>> Do you know a better way to solve that than buildi
On Nov 22, 2013, at 4:31 AM, Konstantin Serebryany
wrote:
> These CFI directives were completely removed in upstream at
> http://llvm.org/viewvc/llvm-project?rev=192196&view=rev
> Strangely, this did not get into the last merge...
>
> Anyway, these cfi_* will (should, at least) disappear with th
On Fri, Nov 22, 2013 at 10:11:18AM -0800, Mike Stump wrote:
> On Nov 22, 2013, at 4:31 AM, Konstantin Serebryany
> wrote:
> > These CFI directives were completely removed in upstream at
> > http://llvm.org/viewvc/llvm-project?rev=192196&view=rev
> > Strangely, this did not get into the last merge
> This is exactly the patch referenced in the pointer to the upstream repo.
> Arno, does this fix the build for you?
Well now I encounter:
/users/charlet/fsf/trunk/libsanitizer/sanitizer_common/sanitizer_linux.cc: In
function '__sanitizer::uptr __sanitizer::internal_filesize(__sanitizer::fd_t)':
I understand what jump threading does. In theory it reduces number of
instructions executed. But it creates messy program structure and prevents
further optimizations, at least for target we have (VLIW-based DSP with
predicated execution).
I just ran through 8 audio codecs we use as internal b
Hey,
What is jump threading? I've not heard of it before (
http://en.wikipedia.org/wiki/Jump_threading is basically the description
of the compiler flag )
Alec
On 22/11/13 19:06, Bingfeng Mei wrote:
I understand what jump threading does. In theory it reduces number of
instructions executed
> (more precisely, for int128_integer_type_node to cease to exist and
> for any front-end places needing it to call a function, with a type
> size that should not be a constant 128).
The complications I've seen there is, for example, when you're
iterating through types looking for a "best" type,
On Fri, Nov 22, 2013 at 6:16 PM, Jeff Law wrote:
>> I am still not convinced jump threading is good for target with predicated
>> execution (assuming no fix for if-conversion). I am doing benchmarking on
>> our target now.
Try disabling only jump threading of back edges, loop latches, and
jump thr
On Fri, Nov 22, 2013 at 07:21:07PM +0100, Arnaud Charlet wrote:
> > This is exactly the patch referenced in the pointer to the upstream repo.
> > Arno, does this fix the build for you?
>
> Well now I encounter:
>
> /users/charlet/fsf/trunk/libsanitizer/sanitizer_common/sanitizer_linux.cc: In
> f
On Nov 22, 2013, at 10:13 AM, Jakub Jelinek wrote:
>> This is exactly the patch referenced in the pointer to the upstream repo.
>> Arno, does this fix the build for you?
>>
>> Ok?
>
> Yes
Committed revision 205285.
On Fri, 22 Nov 2013, DJ Delorie wrote:
> > (more precisely, for int128_integer_type_node to cease to exist and
> > for any front-end places needing it to call a function, with a type
> > size that should not be a constant 128).
>
> The complications I've seen there is, for example, when you're
>
> In general you need to analyze each such case individually to produce a
> reasoned argument for what it should logically be doing. Given such
> analyses, maybe then you can identify particular tables of types in
> particular orders (for example) that should be set up to iterate through.
Ok,
I am building a cross GCC (targeting MIPS) on an x86-64 Linux system but I
want to build the compiler as a 32 bit executable. I thought the right way
to do this was to do:
export CFLAGS='-O2 -g -m32'
export CXXFLAGS-'-O2 -g -m32'
before running configure and make.
This is working in that it cr
On Fri, Nov 22, 2013 at 1:24 PM, Steve Ellcey wrote:
>
> I am building a cross GCC (targeting MIPS) on an x86-64 Linux system but I
> want to build the compiler as a 32 bit executable. I thought the right way
> to do this was to do:
>
> export CFLAGS='-O2 -g -m32'
> export CXXFLAGS-'-O2 -g -m32'
> I am building a cross GCC (targeting MIPS) on an x86-64 Linux system but I
> want to build the compiler as a 32 bit executable. I thought the right way
> to do this was to do:
>
> export CFLAGS='-O2 -g -m32'
> export CXXFLAGS-'-O2 -g -m32'
>
> before running configure and make.
>
> This is wo
On Fri, 2013-11-22 at 13:48 -0800, H.J. Lu wrote:
> On Fri, Nov 22, 2013 at 1:24 PM, Steve Ellcey wrote:
> >
> > I am building a cross GCC (targeting MIPS) on an x86-64 Linux system but I
> > want to build the compiler as a 32 bit executable. I thought the right way
> > to do this was to do:
> >
On Fri, 22 Nov 2013, DJ Delorie wrote:
> > Does the target with __int20 actually have __int128 (i.e. pass
> > targetm.scalar_mode_supported_p (TImode))? But you should indeed be able
> > to have an arbitrary number of such types.
>
> It doesn't support it, but it does *have* it. In that the c
52 matches
Mail list logo
