atches failed it.
Where the current script is located? These checks would be useful for all GNU
Toolchain projects -- binutils/GDB, GCC, Glibc and, maybe, Newlib -- so it
would be useful to put it in a separate "gnutools" repo. I think Siddhesh and
Carlos are looking into creating such a repo on gitlab?
Thanks,
--
Maxim Kuvyrkov
https://www.linaro.org
al compiler error: Segmentation
fault)
FAIL: g++.dg/modules/map-2.C -std=c++2b (test for excess errors)
===
Thanks,
--
Maxim Kuvyrkov
https://www.linaro.org
>
> [P1689R5]: https://isocpp.org/files/papers/P1689R5.html
>
> I've also added patches to include imported module
> On 8 Oct 2021, at 13:22, Martin Jambor wrote:
>
> Hi,
>
> On Fri, Oct 01 2021, Gerald Pfeifer wrote:
>> On Wed, 29 Sep 2021, Maxim Kuvyrkov via Gcc wrote:
>>> Configurations that track master branches have 3-day intervals.
>>> Configurations that
> On 29 Sep 2021, at 21:21, Andrew MacLeod wrote:
>
> On 9/29/21 7:59 AM, Maxim Kuvyrkov wrote:
>>
>>> Does it run like once a day/some-time-period, and if you note a
>>> regression, narrow it down?
>> Configurations that track master branches have 3-
> On 27 Sep 2021, at 19:02, Andrew MacLeod wrote:
>
> On 9/27/21 11:39 AM, Maxim Kuvyrkov via Gcc wrote:
>>> On 27 Sep 2021, at 16:52, Aldy Hernandez wrote:
>>>
>>> [CCing Jeff and list for broader audience]
>>>
>>> On 9/27/21 2:53 PM, Max
> On 27 Sep 2021, at 16:52, Aldy Hernandez wrote:
>
> [CCing Jeff and list for broader audience]
>
> On 9/27/21 2:53 PM, Maxim Kuvyrkov wrote:
>> Hi Aldy,
>> Your patch seems to slow down 471.omnetpp by 8% at -O3. Could you please
>> take a look if this is som
> On Jan 10, 2020, at 6:15 PM, Joseph Myers wrote:
>
> On Fri, 10 Jan 2020, Maxim Kuvyrkov wrote:
>
>> To me this looks like cherry-picks of r182541 and r182547 from
>> redhat/gcc-4_7-branch into redhat/gcc-4_8-branch.
>
> r182541 is the first commit on /branch
> On Jan 10, 2020, at 10:33 AM, Maxim Kuvyrkov
> wrote:
>
>> On Jan 9, 2020, at 5:38 AM, Segher Boessenkool
>> wrote:
>>
>> On Wed, Jan 08, 2020 at 11:34:32PM +, Joseph Myers wrote:
>>> As noted on overseers, once Saturday's DATESTAMP
ions and will post my
results later today.
Unfortunately, the comparison is complicated by the fact that you uploaded only
"b" version of gcc-reposurgeon-8 repository, which uses modified branch layout
(or confirm that there are no substantial differences between "7" and "8"
reposurgeon conversions).
--
Maxim Kuvyrkov
https://www.linaro.org
> On Dec 30, 2019, at 7:08 PM, Richard Earnshaw (lists)
> wrote:
>
> On 30/12/2019 15:49, Maxim Kuvyrkov wrote:
>>> On Dec 30, 2019, at 6:31 PM, Richard Earnshaw (lists)
>>> wrote:
>>>
>>> On 30/12/2019 13:00, Maxim Kuvyrkov wrote:
>>&g
> On Dec 30, 2019, at 6:31 PM, Richard Earnshaw (lists)
> wrote:
>
> On 30/12/2019 13:00, Maxim Kuvyrkov wrote:
>>> On Dec 30, 2019, at 1:24 AM, Richard Earnshaw (lists)
>>> wrote:
>>>
>>> On 29/12/2019 18:30, Maxim Kuvyrkov wrote:
>>>
> On Dec 30, 2019, at 1:24 AM, Richard Earnshaw (lists)
> wrote:
>
> On 29/12/2019 18:30, Maxim Kuvyrkov wrote:
>> Below are several more issues I found in reposurgeon-6a conversion comparing
>> it against gcc-reparent conversion.
>>
>> I am sure, these an
he SVN commit touched more than one SVN branch or
> tag and so has to be split to represent it in git (there are about 1500
> such SVN commits, most of them automatic datestamp updates in the CVS era
> that cvs2svn turned into mixed-branch commits).
Thanks for catching this. This is fallout from incremental rebuilds (rather
than fresh builds) of gcc-reparent repository. Incremental builds take about
1h and full rebuilds take about 30h. I'll switch to doing full rebuilds.
--
Maxim Kuvyrkov
https://www.linaro.org
s ===
Reposurgeon-6a conversion uses default "@gcc.gnu.org" emails for many commits
where svn-git conversion manages to extract valid email from commit data. This
happens for hundreds of author entries.
Regards,
--
Maxim Kuvyrkov
https://www.linaro.org
> On Dec 26, 2019, at 7:11
gcc-reparent beyond r195087.
So, while we are evaluating the conversion candidates, it is best to disable
conversion features that cause hard-to-workaround differences.
>
> I'll do another GCC conversion run to pick up all the accumulated fixes
> and improvements (including many more PR whitelist entries / fixes in
> Richard's script), once another ChangeLog-related fix is in.
--
Maxim Kuvyrkov
https://www.linaro.org
onfigure: Regenerate.
* configure.in: Likewise.
* Makefile.in: Likewise.
* src/Makefile.in: Likewise.
* libsup++/Makefile.in: Likewise.
* po/Makefile.in: Likewise.
* doc/Makefile.in: Likewise.
Legacy-ID: 138087
--
Maxim Kuvyrkov
https://www.linaro.org
27;t
looked at this in depth.
Q4: Is it possible to integrate Richard E.'s script to rewrite commit log
messages?
A5: Yes, absolutely. The scripts have a pass to rewrite commit
author/committer entries, and log rewrite easily fits in there. It would be
very helpful to have a version of Richard's script that runs on per-commit
basis, suitable for "git filter-branch" consumption.
Regards,
--
Maxim Kuvyrkov
https://www.linaro.org
velopers have expressed the same view:
1. all we care about is history of trunk and recent release branches
2. current gcc-mirror is really all we need
3. having vendor branches and author info would be nice, but not so nice as to
delay the switch any longer
Granted, the above is not the /offic
> On Sep 19, 2019, at 6:34 PM, Maxim Kuvyrkov wrote:
>
>> On Sep 17, 2019, at 3:02 PM, Richard Earnshaw (lists)
>> wrote:
>>
>> At the Cauldron this weekend the overwhelming view for the move to GIT soon
>> was finally expressed.
>>
> ...
>&g
gt; e) other general development branches in refs/{heads/tags}/devt
>>
>> What does this mean? "other", "general"?
>
> Anything that's not vendor/user specific and not a release - a topic
> branch most likely
>>
>>> That probably means the
#x27;t want to convert some of the branches or tags to git, then
we should delete them from SVN repository before conversion.
Otherwise it will (a) complicate comparison or repos converted by different
tools, and (b) will require us to remember why parts of SVN history were not
converted to g
hers feel that slipping a few days (but not weeks) would make
> things significantly easier.
The timetable looks entirely reasonable to me.
I have regenerated my primary version this week, and it's up at
https://git.linaro.org/people/maxim-kuvyrkov/gcc-pretty.git/ . So far I have
received
> On Apr 29, 2018, at 2:11 PM, Florian Weimer wrote:
>
> * Maxim Kuvyrkov:
>
>>> On Apr 28, 2018, at 9:22 PM, Florian Weimer wrote:
>>>
>>> * Thomas Preudhomme:
>>>
>>>> Yes absolutely, CSE needs to be avoided. I made memory acces
akes several loads so had to modify some more
>> patterns. Anyway, regardless of the proper fix, do you have any objection
>> to raising a CVE for that issue?
>
> Please file a bug in Bugzilla first and use that in the submission to
> MITRE.
Thomas filed https://gcc.gnu.org/bugzil
nd it a bit painful to maintain.
>
> Any comments are welcome.
I have also investigated several races on I/O in the gfortran testsuite, and my
preference is to go with [1]. Specifically, if a fortran test does I/O with
filenames that can clash with some other test, then the test should be located
in a sub-directory of gfortran.dg testsuite that runs its test in-order.
--
Maxim Kuvyrkov
www.linaro.org
Hi,
The feedback in this thread was overall positive with good suggestions
on implementation details. I'm starting to work on the first draft,
and plan to post something in 2-4 weeks.
Thanks.
On 28 May 2015 at 11:39, Maxim Kuvyrkov wrote:
> Hi,
>
> Akashi-san and I have b
> On May 28, 2015, at 11:59 AM, Richard Biener
> wrote:
>
> On May 28, 2015 10:39:27 AM GMT+02:00, Maxim Kuvyrkov
> wrote:
>> Hi,
>>
>> Akashi-san and I have been discussing required GCC changes to make
>> kernel's livepatching work for AArch6
stinct is to stick with a single option for
now, since we can always add more later.
[2] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-May/346905.html
--
Maxim Kuvyrkov
www.linaro.org
t SVN branches
to see it).
Thank you,
--
Maxim Kuvyrkov
www.linaro.org
Hi Thomas,
Tobias will be GSoC admin for GCC this year. He has submitted GSoC application
today.
Tobias, would you please CC gcc@ for future GSoC-related news and updates?
Thank you,
--
Maxim Kuvyrkov
www.linaro.org
> On Feb 19, 2015, at 11:11 AM, Thomas Schwinge wrote:
>
> H
On Nov 14, 2014, at 9:00 PM, H.J. Lu wrote:
> On Sun, Apr 15, 2012 at 5:08 PM, David Edelsohn wrote:
>>I am pleased to announce that the GCC Steering Committee has
>> appointed Maxim Kuvyrkov as reviewer for the Android sub-port.
>>
>>Please join me
few people, and there are good comments and thoughts there that deserve
a wider audience.
Thank you, [your friendly GSoC admin signing off]
--
Maxim Kuvyrkov
www.linaro.org
GSoC Mentors and Students,
Please remember that the deadline for final evaluations is August 22 19:00UTC.
Both mentors and students should submit their evaluations on GSoC website [*]
by that time.
So far we have only 2 evaluations (out of 10) submitted.
Thank you,
--
Maxim Kuvyrkov
elegates to the GSoC Reunion un-conference
this year -- sponsored by Google.
--
Maxim Kuvyrkov
www.linaro.org
P_CON/DEP_PRO correct? (or, at least, consistent
> with other gcc developers' views on the matter :)) My patch kit [2] has
> this expressed in the type system as of [3], so if I'm incorrect about
> this I'd prefer to know ASAP.
Yes, it is correct.
>
> Simila
ldron!
--
Maxim Kuvyrkov
www.linaro.org
the period June
23-27.
For evaluations, you might find this guide helpful:
http://en.flossmanuals.net/GSoCMentoring/evaluations/ .
On another note, copyright assignments are now completed for 4 out of 5
students. I have pinged the last student to get his assignment in order.
--
Maxi
On May 17, 2014, at 10:41 AM, Tobias Grosser wrote:
>
>
> On 17/05/2014 00:27, Maxim Kuvyrkov wrote:
>> Hi Community,
>>
>> The community bonding period is coming to a close, students can officially
>> start coding on Monday, May 19th.
>>
>> In t
ed in going to
GSoC Reunion, please let me know.
Thank you,
--
Maxim Kuvyrkov
www.linaro.org
gisters when there are a lot of instructions
in the ready list.
Charles, can you finish your patch in the next several days and post it for
review?
Thank you,
--
Maxim Kuvyrkov
www.linaro.org
one elaborate on this? Was it just empirically noticed on x86_64?
+ Richard Sandiford who wrote SCHED_PRESSURE_MODEL
--
Maxim Kuvyrkov
www.linaro.org
table working in GCC community and figure out how to get stuff done. To
this end mentors and I will be assigning simple test tasks (fixing easy PRs,
documentation fixes, etc) which will result in a committed patch.
Any questions, comments or suggestions?
I will send next status update in t
On Apr 11, 2014, at 2:47 AM, Kyrill Tkachov wrote:
> On 10/04/14 02:50, Maxim Kuvyrkov wrote:
>> On Apr 9, 2014, at 4:15 AM, Kyrill Tkachov wrote:
>>
>>> Hi all,
>>>
>>> I'm looking at some curious pre-reload scheduling behaviour and I noticed
&
ge.com/gsoc/homepage/google/gsoc2014
--
Maxim Kuvyrkov
www.linaro.org
does not "accidentally" place something after those "special"
sequences thus creating a corrupted basic block.
--
Maxim Kuvyrkov
www.linaro.org
rt for garbage collection
Thank you,
--
Maxim Kuvyrkov
www.linaro.org
On Mar 15, 2014, at 6:50 PM, Maxim Kuvyrkov wrote:
> Hi,
>
> You are receiving this message because you are in top 50 contributors to GCC
> [1]. Congratulations!
>
> Since you are a top contributor to GCC
wrong in my assumptions above, and you can commit to the GSoC project
being your first priority for the summer months, please apply with your
proposal on the GSoC website. There is very little time left, so move fast.
Thank you,
--
Maxim Kuvyrkov
www.linaro.org
lly, please don't cross-post to several lists, gcc@gcc.gnu.org is the
correct list for development discussions (with gcc-patc...@gcc.gnu.org being
the list for discussion of specific patches).
Thank you,
--
Maxim Kuvyrkov
www.linaro.org
vice code
> optimizations?
Guray
Do you have a proposal for a GSoC GCC project? If you do want to apply, please
make sure you are registered at the GSoC website and have a application filed
by end of Thursday (only 2 days left!).
Thank you,
--
Maxim Kuvyrkov
www.linaro.org
or a GSoC GCC project? If you do want to apply, please
make sure you are registered at the GSoC website and have a application filed
by end of Thursday (only 2 days left!).
--
Maxim Kuvyrkov
www.linaro.org
he GSoC website and have a application filed
by end of Thursday (only 2 days left!).
Thank you,
--
Maxim Kuvyrkov
www.linaro.org
!). You will be able to update details of
the proposal later.
Thank you,
--
Maxim Kuvyrkov
www.linaro.org
Thank you,
[1] irc://irc.oftc.net/#gcc
--
Maxim Kuvyrkov
www.linaro.org
eas/choices for
a week or so.
For GSoC 2014 timeline see
https://www.google-melange.com/gsoc/events/google/gsoc2014 .
Thank you,
--
Maxim Kuvyrkov
www.linaro.org
ys I will be bugging past GCC GSoC admins and mentors to
get an idea of what I'm getting myself into. Please send me a note if you
haven't been GSoC mentor in the past years, but want to try this year.
Thank you,
--
Maxim Kuvyrkov
www.linaro.org
On 11/12/2013, at 3:45 pm, Ramana Radhakrishnan
wrote:
> On Wed, Dec 11, 2013 at 12:02 AM, Maxim Kuvyrkov wrote:
>> On 11/12/2013, at 11:14 am, Ramana Radhakrishnan
>> wrote:
>>
>>> On Tue, Dec 10, 2013 at 9:44 PM, Maxim Kuvyrkov
>>> wrote:
On 11/12/2013, at 11:14 am, Ramana Radhakrishnan
wrote:
> On Tue, Dec 10, 2013 at 9:44 PM, Maxim Kuvyrkov wrote:
>> On 11/12/2013, at 5:17 am, Ramana Radhakrishnan
>> wrote:
>>
>>> On Mon, Jul 1, 2013 at 5:31 PM, Paulo Matos wrote:
>>>> Hi,
&
On 6/12/2013, at 9:44 pm, shmeel gutl wrote:
> On 06-Dec-13 01:34 AM, Maxim Kuvyrkov wrote:
>> On 6/12/2013, at 8:44 am, shmeel gutl wrote:
>>
>>> On 05-Dec-13 02:39 AM, Maxim Kuvyrkov wrote:
>>>> Dependency type plays a role for estimating costs and latenci
sched-ebb and sel-sched is not the best and one will likely get
weird artefacts by trying out non-default settings.
I believe that only IA64 backend supports selective scheduling reliably. I've
other ports trying out selective scheduling, but I don't know whether those
efforts got positive results.
--
Maxim Kuvyrkov
www.kugelworks.com
On 10/12/2013, at 7:28 am, Steve Ellcey wrote:
> On Mon, 2013-12-09 at 08:21 +1300, Maxim Kuvyrkov wrote:
>
>> I'm looking into this.
>>
>> Thanks,
>>
>> --
>> Maxim Kuvyrkov
>> www.kugelworks.com
>
>
> My mips-mti-linux-gnu bu
ily/c-cppbuiltin.c: In function ‘void
> c_cpp_builtins(cpp_reader*)’:
> /home/jbglaw/repos/gcc/gcc/c-family/c-cppbuiltin.c:1014:370: error:
> ‘ANDROID_TARGET_OS_CPP_BUILTINS’ was not declared in this scope
> make[1]: *** [c-family/c-cppbuiltin.o] Error 1
I'm looking into this.
Thanks,
--
Maxim Kuvyrkov
www.kugelworks.com
On 6/12/2013, at 8:44 am, shmeel gutl wrote:
> On 05-Dec-13 02:39 AM, Maxim Kuvyrkov wrote:
>> Dependency type plays a role for estimating costs and latencies between
>> instructions (which affects performance), but using wrong or imprecise
>> dependency type does not aff
On 6/12/2013, at 4:25 am, Michael Matz wrote:
> Hi,
>
> On Thu, 5 Dec 2013, Maxim Kuvyrkov wrote:
>
>> Output dependency is the right type (write after write). Anti
>> dependency is write after read, and true dependency is read after write.
>>
>> Depende
problem is coming from. Add -fdump-tree-all and -fdump-rtl-all to
the compilation flags and find which optimization pass makes the wrong
decision. Then you trace that optimization pass or file a bug report in hopes
that someone (optimization maintainer) will look at it.
Read through GCC wiki for information on debugging and troubleshooting GCC:
- http://gcc.gnu.org/wiki/GettingStarted
- http://gcc.gnu.org/wiki/FAQ
- http://gcc.gnu.org/wiki/
Thanks,
--
Maxim Kuvyrkov
www.kugelworks.com
uses a performance problem for you. You can add better handling of this
situation by remembering whether last_pending_memory_flush is memory read or
memory write and then use it to select correct dependency type for insn 90:
output, anti or true.
Let me know whether you want to pursue this and I can help with advice and
patch review.
Thanks,
--
Maxim Kuvyrkov
www.kugelworks.com
Thank you!
--
Maxim Kuvyrkov
www.kugelworks.com
; http://toolchain.lug-owl.de/buildbot/showlog.php?id=10520&mode=view
Jan-Benedict,
Mn10300-linux does not appear to be supporting linux. Mn10300-linux target
specifier expands into mn10300-unknown-linux-gnu, where *-gnu implies using
Glibc library, which doesn't have mn10300
configured for a hard-float target, but eglibc is being compiled
for a soft-float target. [For hard-float targets there is no need for FP
helpers in libgcc since processor is assumed to handle that in silicon.]
Good luck,
--
Maxim Kuvyrkov
KugelWorks
e how your patch fixes
the problem. You write how and which architectures your patch was tested on.
5. You ping your submission every 2 weeks to one of the maintainers until they
review your patch.
Good luck!
--
Maxim Kuvyrkov
KugelWorks
developed
for ia64.
Regards,
--
Maxim Kuvyrkov
KugelWorks
On 27/06/2013, at 8:35 PM, Paulo Matos wrote:
> Let me add to my own post saying that it seems that the problem is that the
> list scheduler is greedy in the sense that it will take an instruction from
> the ready list no ma
rojects (e.g., GCC, Binutils, GDB, glibc -- or just
blanket ALL) you wish to contribute to.
Usually the FSF copyright office replies within 1-2 days, and feel free to ping
us back here at gcc@ if FSF legal stalls.
Thank you,
--
Maxim Kuvyrkov
KugelWorks
able.
Ard, you committed 5ae44f302b7d1d19f25c4c6f125e32dc369961d9 to Bionic that adds
handling of ARM COPY relocations. Can you comment on why COPY relocations from
executables to DT_SYMBOLIC libraries are forbidden?
Thank you,
--
Maxim Kuvyrkov
KugelWorks
opportunity to ...
- Hack on the toolchain;
- Develop your engineering, managerial, and communication skills;
- Gain experience in product development;
- Get public recognition for your open-source work;
- Become open-source maintainter.
Contact:
- Maxim Kuvyrkov
- Email: ma
st
blanket ALL) you wish to contribute to.
Usually the FSF copyright office replies within 1-2 days, and feel free to ping
us back here at gcc@ if FSF legal stalls.
Thanks,
--
Maxim Kuvyrkov
ere.
> 3. Please tell us how to create our Linux for C++ because we have no
> information about it.
For this you want to specify "--enable-languages=c,c++" when configuring the
compiler.
Thank you,
--
Maxim Kuvyrkov
CodeSourcery / Mentor Graphics
On 27/11/2012, at 4:34 AM, Greg McGary wrote:
> On 11/25/12 23:33, Maxim Kuvyrkov wrote:
>> You essentially need a fix-up pass just before the end of compilation
>> (machine-dependent reorg, if memory serves me right) to space instructions
>> consuming values from CPRs fro
ld set the appropriate
registers (probably just assign the register to itself), and you will have a
bypass (see define_bypass) between these dummy instructions and consumers to
guarantee the 2-cycle delay.
--
Maxim Kuvyrkov
CodeSourcery / Mentor Graphics
acks of PIC, there is a
reason why -fPIE is not the most common way of building applications. I don't
think Android is too security-concious a platform to warrant -fPIE (does
Android even use address-space randomization?). Performance is a more serious
consideration for its target m
to use -fPIE for most normal user-space
applications when -fno-pic would suffice and provide better code.
Am I missing something?
Thank you,
--
Maxim Kuvyrkov
CodeSourcery / Mentor Graphics
vior the default, and for Android that happens to be building shared
libraries that can then be called through JNI.
I think the right fix here is to add "-fno-pic" to dg-options for affected
tests in gcc.target/i386. For architecture-independent test, it may be more
prudent to use
will also always work for
> single-precision. */
> strong_alias (__isnan, __isnanf)
> -hidden_def (__isnanf)
> -weak_alias (__isnanf, isnanf)
> +weak_alias (__isnan, isnanf)
> +
> +/* ??? GCC 4.8 fails to look through chains of aliases with asm names
> + attached. Work around this for now. */
> +hidden_ver (__isnan, __isnanf)
Why do you need both weak_alias and hidden_ver here? Maybe hidden_weak is what
you want instead? Again, this may be easier to understand from "-E -dD" output.
--
Maxim Kuvyrkov
CodeSourcery / Mentor Graphics
. And, as
long as your changes preserve the status quo of mips-*-* being big-endian by
default and mipsel-*-* being little-endian by default, there should be no major
obstacles to merge those in.
Thank you,
--
Maxim Kuvyrkov
CodeSourcery / Mentor Graphics
On 29/03/2012, at 5:38 PM, Maxim Kuvyrkov wrote:
> I volunteer as the reviewer for Android sub-port.
>
> Android/Bionic support is an extension over Linux port and is being gradually
> added for more and more architectures. I wrote the original Android GCC
> support for ARM (u
together.
As adding Android support to a new architecture requires changes to that
architecture, the architecture maintainer will have the power of veto for the
Android-related changes.
Thank you,
--
Maxim Kuvyrkov
CodeSourcery / Mentor Graphics
>
> > BE_IN_DATA flags are set for consumers of the memory load that was
> > data-speculated, i.e., it started a data-speculation block. All consumers
> > of data-speculative memory load must be tracked for the case when
> > speculation fails and recovery needs to be executed to preserve program
> > correctness.
> >
> > This is a very redacted description of the data speculation optimization,
> > and you need to refer my original submissions to gcc-patches@ and to IA64
> > architecture documentation.
> >
> > --
> > Maxim Kuvyrkov
> >
On 2/12/2011, at 9:45 PM, Jakub Jelinek wrote:
> On Fri, Dec 02, 2011 at 03:33:06PM +1300, Maxim Kuvyrkov wrote:
>> I'm looking at a missed optimizations in combine and it is similar to the
>> one you've fixed in PR18942
>> (http://thread.gmane.org/gmane.comp.gcc.pa
two instructions into one, but fails. This causes an
extra 'add' instruction per switch statement in the final assembly. The target
I'm working with is MIPS, but, I imagine, other architectures are affected as
well.
Thank you,
--
Maxim Kuvyrkov
CodeSourcery / Mentor Graphics
ipa-cp.c to
clearly describe the type information lattice [*]. Having information
represented as lattice is advantageous as it makes it easier to reuse
devirtualization analysis in other optimization passes.
[*] http://gcc.gnu.org/ml/gcc/2010-12/msg00461.html
--
Maxim Kuvyrkov
CodeSourcery
+7-812-677-6839
t-2.C, inline-devirt-3.C are also
fully optimized.
Let me know if you have suggestions for tackling the other cases.
Do you think committing the testcases mainline, XFAIL'ed as necessary, would be
useful?
Thanks,
--
Maxim Kuvyrkov
CodeSourcery
+1-650-331-3385 x724
0005-Testc
to fix the problem may be to move Tom's
extension elimination pass /after/ loop optimizers. Do you (or anyone reading
this thread) have suggestions on what would be a good spot in the optimization
pipeline for sign- and zero-extension elimination pass?
Thanks,
--
Maxim Kuvyrkov
CodeSourcery
+1-650-331-3385 x724
atches/2010-10/msg01529.html
Thanks,
--
Maxim Kuvyrkov
CodeSourcery
+1-650-331-3385 x724
On 10/19/10 6:16 PM, Andrey Belevantsev wrote:
...
I agree that ISSUE_POINTS can be removed, as it was not used (maybe
Maxim can comment more on this).
I too agree with removing ISSUE_POINTS, it never found any use.
Regards,
--
Maxim Kuvyrkov
CodeSourcery
ma...@codesourcery.com
(650) 331
On 8/13/10 11:40 PM, Jack Howarth wrote:
On Mon, May 17, 2010 at 10:44:57AM +0400, 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, to
provide
On 7/22/10 3:34 AM, Steven Bosscher wrote:
On Wed, Jul 21, 2010 at 10:09 PM, Maxim Kuvyrkov wrote:
Cselib can /always/ be used during second scheduling pass
Except with the selective scheduler when it works on regions that are
not extended basic blocks, I suppose?
Right, I was considering
ht surface, the only reason not to
enable cselib for single-block regions in sched-rgn may be increased
compile time. That requires some benchmarking, but my gut feeling is
that the benefits would outweigh the compile-time cost.
--
Maxim Kuvyrkov
CodeSourcery
ma...@codesourcery.com
(650) 331-3385 x724
On 7/9/10 3:22 PM, Anthony Green wrote:
Hi Maxim,
Recent changes to config.gcc are preventing me from building a
moxie-uclinux toolchain.
Anthony,
What is the error the build process is failing on?
Thanks,
--
Maxim Kuvyrkov
CodeSourcery
ma...@codesourcery.com
(650) 331-3385 x724
On 5/21/10 9:06 PM, Vladimir N. Makarov wrote:
On 05/17/2010 02:44 AM, Maxim Kuvyrkov wrote:
...
If your favorite benchmark significantly under-performs on Core 2 or
Core i7 CPUs, don't hesitate asking us to take a look at it.
What I saw is people complaining about -mtune=core2 for polyh
On 5/20/10 4:04 PM, 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, to
provide fine-
appreciate Intel sponsoring this project.
Thank you,
--
Maxim Kuvyrkov
CodeSourcery
ma...@codesourcery.com
(650) 331-3385 x724
Richard Guenther wrote:
...
Yes, though we should probably try to catch the DECL_ABSTRACT case
further up the call chain - there shouldn't be any location lists for abstract
function. Thus, see why
static dw_die_ref
gen_formal_parameter_die (tree node, tree origin, dw_die_ref context_die)
...
1 - 100 of 133 matches
Mail list logo
