On Fri, 2008-09-19 at 09:41 +1000, Ben Elliston wrote:
> On Thu, 2008-09-18 at 10:44 -0600, Tom Tromey wrote:
> > Yeah, this seems necessary. Ideally the order ought to be stable, too.
>
> Do you think that the current order of .exps should be preserved in the
> resultant .sum and .logs? I guess
On Sat, 2007-06-02 at 07:35 -0700, H. J. Lu wrote:
> When was decimal floating point added to gcc? I couldn't find it
> in any gcc changes.html. Shouldn't it be mentioned somewhere?
I think these were the merges from the dfp-branch:
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01919.html
http
On Fri, 2007-08-17 at 09:32 -0400, Kenneth Zadeck wrote:
> The problem comes where you have a store that uses 2 or more hard regs
> but one or more of those hardregs is unused.
>
> In a forwards scan, ALL of the set regs will interfere with anything
> live until the last set reg goes dead. In a b
As a somewhat related follow on to Kenny's new interference graph
builder patch (which is still waiting for a full review):
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01729.html
I'd like to squeeze in a new representation of the interference graph
that in some cases can save a significant a
On Tue, 2007-09-04 at 19:40 -0700, Mark Mitchell wrote:
> Are there Stage 1 or Stage 2 patches in need of review? I'll do my best
> to either (a) convince someone to review them, or (b) review them myself.
It has only been four days since I posted the patch, but I am
waiting for a review of the n
On 3/20/20 12:37 PM, Frank Ch. Eigler via Gcc wrote:
> Hi -
>
> Both svn: and ssh+svn: now work for your archeological needs.
> Further, URLs such as
>
> https://gcc.gnu.org/viewcvs?rev=279160&root=gcc&view=rev
> https://gcc.gnu.org/r123456
>
> are mapped to gitweb searches that try to locate th
On 3/24/20 12:06 PM, Frank Ch. Eigler wrote:
>> Thanks for working on this!!! However, I still see at least one issue
>> in the following bugzilla entry:
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94123#c4
>>
>> The first two git style links work, but the last one which points
>> to th
On 4/20/21 4:20 PM, Jakub Jelinek via Gcc wrote:
> On Tue, Apr 20, 2021 at 03:27:08PM -0500, William Seurer via Gcc wrote:
>> /tmp/cc8zG8DV.s: Assembler messages:
>> /tmp/cc8zG8DV.s:2566: Error: unsupported relocation against r13
>> /tmp/cc8zG8DV.s:2570: Error: unsupported relocation against r14
[s
uthor when
committing that, so we're wondering whether there might be a bug in one
of the commit hooks. Is there someone who an dig into the commit below
and try to find out how the author field was incorrectly set?
Peter
commit a325bdd195ee96f826b208c3afb9bed2ec077e12
Author: Pet
On 6/16/21 1:32 PM, Uros Bizjak wrote:
> On Wed, Jun 16, 2021 at 6:08 PM Liu Hao wrote:
>> It looks like Uroš was on 00d07ec6e12, committed his changes mistakenly with
>> `git commit --amend`
>> (which changed the commit message but did not reset the author), then
>> rebased the modified commit
On 10/6/21 12:50 PM, Segher Boessenkool wrote:
> So we have three options (well, four):
>
> 0) Do nothing. We will stay in this hell forever. Not my choice :-)
> 1) Use a soft-float-like parameter passing everywhere. This works but
>will be horridly slow on newer systems. We can do better
On 11/19/21 1:28 AM, Jojo R via Gcc wrote:
> We know gcc supply earlyclobber function to avoid register overlap,
>
> but it can not describe explicitly for specific source operand, is it
> right ?
You add the early clobber to the OUTPUT operand(s) that can clobber any of the
input so
On 12/4/21 9:25 AM, Michael Meissner wrote:
> On Sat, Dec 04, 2021 at 02:42:13PM +0100, Thomas Koenig wrote:
> Note, the system ldd does not tend to accurately report the library
> dependencies for AT libraries:
And using AT15's ldd, it shows your a.out is linked to the correct libc:
ubuntu@gcc-f
On 12/4/21 9:37 AM, Peter Bergner wrote:
> On 12/4/21 9:25 AM, Michael Meissner wrote:
> ubuntu@gcc-fortran:/home/tkoenig/Tst$ ldd ./a.out
> ./a.out: /lib/powerpc64le-linux-gnu/libc.so.6: version `GLIBC_2.34' not found
> (required by ./a.out)
> linux-vdso64.so.1
On 12/4/21 10:19 AM, Jakub Jelinek wrote:
> But when Thomas is working on the vanilla gcc tree, trying to make it work
> for Fortran, I think he'll need to patch that gcc tree too to use the
> AT15's dynamic linker and rpath like the AT15 gcc is.
That is part of the magic that happens when you con
On 12/4/21 11:40 AM, Thomas Koenig wrote:
> OK, what I have now is
>
> tkoenig@gcc-fortran:~$ echo $PATH
> /home/tkoenig/bin:/opt/at15.0/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
> tkoenig@gcc-fortran:~$ echo $LD_LIBRARY_PATH
> /home/tko
On 5/20/22 12:15 AM, Nicholas Piggin via Gcc wrote:
> +PPC_FEATURE_HAS_ALTIVEC
> +Vector (aka Altivec, VSX) facility is available.
Slight typo. s/VSX/VMX/
Peter
On 3/8/24 7:16 AM, Richard Biener via Gcc wrote:
> I CCed Jeff who is on the commitee to forward the maintainer proposal
> though I guess this will not go forward as a first step. Instead
> you are probably expected to show activity on the port, for example
> post the patch series to make ia64 use
On 3/8/24 5:30 AM, Jonathan Wakely via Gcc wrote:
> Patches should be sent to the gcc-patches list instead of this one,
> and should be against trunk not an old gcc-11 RC. See
> https://gcc.gnu.org/contribute.html#patches for more details - thanks!
And you need to CC the rs6000/powerpc port mainta
On 3/8/24 5:28 PM, Jonathan Wakely wrote:
> On Fri, 8 Mar 2024 at 22:35, Frank Scheiner via Gcc wrote:
>>
>> On 08.03.24 23:00, Peter Bergner wrote:
>>> On 3/8/24 7:16 AM, Richard Biener via Gcc wrote:
>>>> I CCed Jeff who is on the commitee to forward the mai
101 - 120 of 120 matches
Mail list logo
