On Thu, 19 Dec 2019 at 00:02, Joseph Myers wrote:
>
> On Wed, 18 Dec 2019, Joseph Myers wrote:
>
> > On Mon, 18 Nov 2019, Richard Earnshaw (lists) wrote:
> >
> > > I've attached a sample from the start of the fixed list - the full list
> > > is far
> > > too big to post to give a flavour of how t
On Sat, 14 Dec 2019 at 07:19, 刘 加权 wrote:
>
> cmd 1 : ./configure --disable-multilib --prefix=/usr/local
> --with-mpc=/usr/local --with-mpfr=/usr/local --with-gmp=/usr/local && make
> -j4 && sudo make install
> cmd 2 : ./configure --disable-multilib --prefix=/usr/local && make -j4
> &&
On Thu, 19 Dec 2019 at 09:27, Jonathan Wakely wrote:
>
> On Thu, 19 Dec 2019 at 00:02, Joseph Myers wrote:
> >
> > On Wed, 18 Dec 2019, Joseph Myers wrote:
> >
> > > On Mon, 18 Nov 2019, Richard Earnshaw (lists) wrote:
> > >
> > > > I've attached a sample from the start of the fixed list - the fu
On Thu, Dec 19, 2019 at 12:01:28AM +, Joseph Myers wrote:
> re PR c/92324 (ICE in expand_direct_optab_fn, at internal-fn.c:2890 [checkme:
> tree-optimization SVN r277822])
> re PR c/92324 (ICE in expand_direct_optab_fn, at internal-fn.c:2890 [checkme:
> tree-optimization SVN r277955])
> re PR
On 19/12/2019 09:27, Jonathan Wakely wrote:
On Thu, 19 Dec 2019 at 00:02, Joseph Myers wrote:
On Wed, 18 Dec 2019, Joseph Myers wrote:
On Mon, 18 Nov 2019, Richard Earnshaw (lists) wrote:
I've attached a sample from the start of the fixed list - the full list is far
too big to post to give
On 19/12/2019 11:50, Richard Earnshaw (lists) wrote:
On 19/12/2019 09:27, Jonathan Wakely wrote:
On Thu, 19 Dec 2019 at 00:02, Joseph Myers
wrote:
On Wed, 18 Dec 2019, Joseph Myers wrote:
On Mon, 18 Nov 2019, Richard Earnshaw (lists) wrote:
I've attached a sample from the start of the fixe
On Thu, 19 Dec 2019 at 11:50, Richard Earnshaw (lists)
wrote:
>
> On 19/12/2019 09:27, Jonathan Wakely wrote:
> > On Thu, 19 Dec 2019 at 00:02, Joseph Myers wrote:
> >>
> >> On Wed, 18 Dec 2019, Joseph Myers wrote:
> >>
> >>> On Mon, 18 Nov 2019, Richard Earnshaw (lists) wrote:
> >>>
> I've
On 19/12/2019 12:23, Jonathan Wakely wrote:
On Thu, 19 Dec 2019 at 11:50, Richard Earnshaw (lists)
wrote:
On 19/12/2019 09:27, Jonathan Wakely wrote:
On Thu, 19 Dec 2019 at 00:02, Joseph Myers wrote:
On Wed, 18 Dec 2019, Joseph Myers wrote:
On Mon, 18 Nov 2019, Richard Earnshaw (lists) w
On Thu, 19 Dec 2019 at 12:33, Richard Earnshaw (lists)
wrote:
>
> On 19/12/2019 12:23, Jonathan Wakely wrote:
> > On Thu, 19 Dec 2019 at 11:50, Richard Earnshaw (lists)
> > wrote:
> >>
> >> On 19/12/2019 09:27, Jonathan Wakely wrote:
> >>> On Thu, 19 Dec 2019 at 00:02, Joseph Myers
> >>> wrote:
On 19/12/2019 12:35, Jonathan Wakely wrote:
On Thu, 19 Dec 2019 at 12:33, Richard Earnshaw (lists)
wrote:
On 19/12/2019 12:23, Jonathan Wakely wrote:
On Thu, 19 Dec 2019 at 11:50, Richard Earnshaw (lists)
wrote:
On 19/12/2019 09:27, Jonathan Wakely wrote:
On Thu, 19 Dec 2019 at 00:02, Jos
On Thu, 19 Dec 2019 at 12:42, Richard Earnshaw (lists)
wrote:
>
> On 19/12/2019 12:35, Jonathan Wakely wrote:
> > On Thu, 19 Dec 2019 at 12:33, Richard Earnshaw (lists)
> > wrote:
> >>
> >> On 19/12/2019 12:23, Jonathan Wakely wrote:
> >>> On Thu, 19 Dec 2019 at 11:50, Richard Earnshaw (lists)
>
Hi,
On Wed, 2019-12-18 at 21:55 +, Joseph Myers wrote:
> On Tue, 17 Dec 2019, Joseph Myers wrote:
> > I've made test conversions of the GCC repository with reposurgeon
> > available (gcc.gnu.org / sourceware.org account required to access
> > these git+ssh repositories, it doesn't need to be o
Mark Wielaard :
> Do we already have a new date for when we are making that decision?
I believe Joseph was planning on Dec 31st.
My team's part will be ready - the enabling reposurgeon changes should
done in a week or so, with most of that being RFEs that could be
dropped if there were real time
On Thu, 19 Dec 2019, Richard Earnshaw (lists) wrote:
> Best of all would be a pull request on
> https://gitlab.com/esr/gcc-conversion/tree/master to update bugdb.py directly.
Note if doing that, it helps to check "Allow commits from members who can
merge to the target branch." when creating the
On Thu, 19 Dec 2019, Eric S. Raymond wrote:
> There are other problems that might cause a delay beyond the
> 31st, however. Best if I let Joseph nd Richard explain those.
I presume that's referring to the checkme: bug annotations where the PR
numbers in commit messages seem suspicious. I don't
On 19/12/2019 11:16, Jakub Jelinek wrote:
On Thu, Dec 19, 2019 at 12:01:28AM +, Joseph Myers wrote:
re PR c/92324 (ICE in expand_direct_optab_fn, at internal-fn.c:2890 [checkme:
tree-optimization SVN r277822])
re PR c/92324 (ICE in expand_direct_optab_fn, at internal-fn.c:2890 [checkme:
tr
On Thu, 19 Dec 2019 at 14:29, Joseph Myers wrote:
>
> On Thu, 19 Dec 2019, Richard Earnshaw (lists) wrote:
>
> > Best of all would be a pull request on
> > https://gitlab.com/esr/gcc-conversion/tree/master to update bugdb.py
> > directly.
>
> Note if doing that, it helps to check "Allow commits f
On 19/12/2019 15:17, Jonathan Wakely wrote:
On Thu, 19 Dec 2019 at 14:29, Joseph Myers wrote:
On Thu, 19 Dec 2019, Richard Earnshaw (lists) wrote:
Best of all would be a pull request on
https://gitlab.com/esr/gcc-conversion/tree/master to update bugdb.py directly.
Note if doing that, it he
These scraped "INVALID" as the component from the changelog, because
it said "libgfortran/24685":
revert: re PR libfortran/24685 (real(16) formatted input is broken for
huge values (gfortran.dg/default_format_2.f90) [checkme: INVALID SVN
r142840])
revert: re PR libfortran/24685 (real(16) formatted
On Thu, 19 Dec 2019, Jonathan Wakely wrote:
> These scraped "INVALID" as the component from the changelog, because
> it said "libgfortran/24685":
"INVALID" means the PR was closed as INVALID rather than FIXED, which
makes it suspect for a commit to claim to be fixing it. (Though since
those ar
On Thu, 19 Dec 2019 at 15:47, Joseph Myers wrote:
>
> On Thu, 19 Dec 2019, Jonathan Wakely wrote:
>
> > These scraped "INVALID" as the component from the changelog, because
> > it said "libgfortran/24685":
>
> "INVALID" means the PR was closed as INVALID rather than FIXED, which
> makes it suspect
On 19/12/2019 15:44, Jonathan Wakely wrote:
These scraped "INVALID" as the component from the changelog, because
it said "libgfortran/24685":
revert: re PR libfortran/24685 (real(16) formatted input is broken for
huge values (gfortran.dg/default_format_2.f90) [checkme: INVALID SVN
r142840])
reve
On Thu, 19 Dec 2019, Richard Earnshaw (lists) wrote:
> > Done. https://gitlab.com/esr/gcc-conversion/merge_requests/25 fixes
> > (most of?) the most egregious ones, like fortran fixes with c++ PR
> > numbers and vice versa. Jakub and I have several whitelist commits
> > too, but I think they're al
On Thu, 19 Dec 2019, Jason Merrill wrote:
> So a 30% space savings; that's pretty significant. Though I wonder how
> much of that is refs/dead and refs/deleted, which seem unnecessary to carry
> over to git at all. I wonder if it would make sense to put them in a
> separate repository that refer
Joseph Myers :
> On Thu, 19 Dec 2019, Eric S. Raymond wrote:
>
> > There are other problems that might cause a delay beyond the
> > 31st, however. Best if I let Joseph nd Richard explain those.
>
> I presume that's referring to the checkme: bug annotations where the PR
> numbers in commit messag
On Thu, 19 Dec 2019, Jonathan Wakely wrote:
> It might be reasonable to assume rtl-optimization and
> tree-optimization are aliases, and not treat it as suspicious if those
> two appear mixed up. And anything where bugzilla has component debug
> or lto and the commit is tree-optimization is probab
On 19/12/2019 16:00, Eric S. Raymond wrote:
Joseph Myers :
On Thu, 19 Dec 2019, Eric S. Raymond wrote:
There are other problems that might cause a delay beyond the
31st, however. Best if I let Joseph nd Richard explain those.
I presume that's referring to the checkme: bug annotations where t
On 19/12/2019 16:00, Joseph Myers wrote:
On Thu, 19 Dec 2019, Jonathan Wakely wrote:
It might be reasonable to assume rtl-optimization and
tree-optimization are aliases, and not treat it as suspicious if those
two appear mixed up. And anything where bugzilla has component debug
or lto and the c
Richard Earnshaw (lists) :
> > No, I was thinking more of rearnsha bailing out to handle a family emergency
> > and muttering something about not being back for a couple of weeks. If
> > that's
> > been resolved I haven't heard about it.
>
> I don't think that should affect things, as I think Jos
On Thu, 19 Dec 2019 at 15:49, Joseph Myers wrote:
>
> On Thu, 19 Dec 2019, Richard Earnshaw (lists) wrote:
>
> > > Done. https://gitlab.com/esr/gcc-conversion/merge_requests/25 fixes
> > > (most of?) the most egregious ones, like fortran fixes with c++ PR
> > > numbers and vice versa. Jakub and I
On Thu, 19 Dec 2019 at 16:26, Jonathan Wakely wrote:
>
> On Thu, 19 Dec 2019 at 15:49, Joseph Myers wrote:
> >
> > On Thu, 19 Dec 2019, Richard Earnshaw (lists) wrote:
> >
> > > > Done. https://gitlab.com/esr/gcc-conversion/merge_requests/25 fixes
> > > > (most of?) the most egregious ones, like
On Wed, 18 Dec 2019, Joseph Myers wrote:
> There are now four more repositories available.
>
> git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-2a.git
> git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-2b.git
> git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-3a.git
> git+ssh://gcc.gnu.o
On Thu, 19 Dec 2019, Jonathan Wakely wrote:
> On Thu, 19 Dec 2019 at 15:49, Joseph Myers wrote:
> >
> > On Thu, 19 Dec 2019, Richard Earnshaw (lists) wrote:
> >
> > > > Done. https://gitlab.com/esr/gcc-conversion/merge_requests/25 fixes
> > > > (most of?) the most egregious ones, like fortran fix
On 2019-12-18 1:33 p.m., Erick Ochoa wrote:
>
>
> On 2019-12-18 6:02 a.m., Richard Biener wrote:
>> On December 17, 2019 8:31:00 PM GMT+01:00, Erick Ochoa
>> wrote:
>>> Hi,
>>>
>>> I'm interested in printing VAR_DECL trees that are of type
>>> RECORD_TYPE. I am using the function print_gener
Hi,
When using GCC to compile a very large routine with -O2, it failed with out of
memory during run time. (O1 is Okay)
As I checked within gdb, when “cc1” was consuming around 95% of the memory,
it’s at :
(gdb) where
#0 0x00ddbcb3 in df_chain_create (src=0x631006480f08,
dst=
On Thu, 19 Dec 2019 at 16:33, Joseph Myers wrote:
>
> On Thu, 19 Dec 2019, Jonathan Wakely wrote:
>
> > On Thu, 19 Dec 2019 at 15:49, Joseph Myers wrote:
> > >
> > > On Thu, 19 Dec 2019, Richard Earnshaw (lists) wrote:
> > >
> > > > > Done. https://gitlab.com/esr/gcc-conversion/merge_requests/25
On Thu, 19 Dec 2019, Jonathan Wakely wrote:
> Jakub and I came up with the following list of suggestions for
> component changes:
Since we don't normally review changes to individual bugs, if you think
the new component is better than the old one (is a better representation
of the subject area
Eric Curtin writes:
> I want to add a compiler warning, if it will get accepted. It's a
> -Wlines warning. My employer bans the __LINE__ macro as well as the
> ones warned by the -Wdate-time warning, because there is a consensus
> that the addition of whitespace or comments should not yield differ
Why not just add "-D__LINE__=LinkerError_LineMacroUsed_DoNotDoThat()" to
CFLAGS?
Best Regards,
Dmitry Grinberg
On Mon, Dec 16, 2019 at 3:51 AM Eric Curtin wrote:
> I want to add a compiler warning, if it will get accepted. It's a
> -Wlines warning. My employer bans the __LINE__ macro as w
Hi,
I'm looking to create new tests for an LTO pass that I'm working on.
So, I started by trying to run the tests under the folder:
$gcc/gcc/testsuite/gcc.dg/lto
Looking at the documentation available here:
https://gcc.gnu.org/install/test.html
It says the following
In order to run sets of t
On Thu, Dec 19, 2019 at 12:48 PM Erick Ochoa
wrote:
>
> Hi,
>
> I'm looking to create new tests for an LTO pass that I'm working on.
> So, I started by trying to run the tests under the folder:
> $gcc/gcc/testsuite/gcc.dg/lto
>
> Looking at the documentation available here:
> https://gcc.gnu.org/i
On 2019-12-19 3:50 p.m., Andrew Pinski wrote:
> On Thu, Dec 19, 2019 at 12:48 PM Erick Ochoa
> wrote:
>>
>> Hi,
>>
>> I'm looking to create new tests for an LTO pass that I'm working on.
>> So, I started by trying to run the tests under the folder:
>> $gcc/gcc/testsuite/gcc.dg/lto
>>
>> Looking
Hello,
I am working on testing an optimization. I am starting to write
tests in the GCC testing suite. However, I want to develop some
fine grain testing for my own sake.
This optimization I am working on, is a variant of struct reordering.
One way I would like to test my pass is for example, mak
On Thu, 19 Dec 2019 16:47:42 -0500
Erick Ochoa wrote:
> Hello,
>
> I am working on testing an optimization. I am starting to write
> tests in the GCC testing suite. However, I want to develop some
> fine grain testing for my own sake.
>
> This optimization I am working on, is a variant of struc
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92905
The patch was successfully bootstrapped on x86-64 and ppc64 and
benchmarked on SPEC2000 on x86-64.
Committed as r279596
Index: ChangeLog
===
--- Change
On 2019-12-19 5:01 p.m., Jozef Lawrynowicz wrote:
> On Thu, 19 Dec 2019 16:47:42 -0500
> Erick Ochoa wrote:
>
>> Hello,
>>
>> I am working on testing an optimization. I am starting to write
>> tests in the GCC testing suite. However, I want to develop some
>> fine grain testing for my own sake
On Thu, 2019-12-19 at 16:47 -0500, Erick Ochoa wrote:
> Hello,
>
> I am working on testing an optimization. I am starting to write
> tests in the GCC testing suite. However, I want to develop some
> fine grain testing for my own sake.
>
> This optimization I am working on, is a variant of struct
This issue is well-known in research/scientific software. The problem of
compiler hang or RAM overconsumption is actually not about the routine
size, but about too complicated control flow. When optimizing, the compiler
traverses the control flow graph, which may have the misfortune to explode
in t
Hi, Dmitry,
Thanks for the responds.
Yes, routine size only cannot determine the complexity of the routine.
Different compiler analysis might have different formula with multiple
parameters to compute its complexity.
However, the common issue is: when the complexity of a specific routine for
On Wed, Dec 18, 2019 at 7:58 AM Segher Boessenkool
wrote:
>
> On Sun, Dec 15, 2019 at 09:43:20AM -0800, Ian Lance Taylor wrote:
> > On Sat, Dec 14, 2019 at 11:25 PM Segher Boessenkool
> > wrote:
> > >
> > > On Sat, Dec 14, 2019 at 10:51:50AM -0800, Ian Lance Taylor via gcc wrote:
> > > > I'm seei
On Thu, Dec 19, 2019 at 04:08:39PM -0800, Ian Lance Taylor wrote:
> On Wed, Dec 18, 2019 at 7:58 AM Segher Boessenkool
> wrote:
> >
> > On Sun, Dec 15, 2019 at 09:43:20AM -0800, Ian Lance Taylor wrote:
> > > On Sat, Dec 14, 2019 at 11:25 PM Segher Boessenkool
> > > wrote:
> > > >
> > > > On Sat,
On Thu, 2019-12-19 at 17:06 -0600, Qing Zhao wrote:
> Hi, Dmitry,
>
> Thanks for the responds.
>
> Yes, routine size only cannot determine the complexity of the routine.
> Different compiler analysis might have different formula with multiple
> parameters to compute its complexity.
>
> Howev
On Thu, Dec 19, 2019 at 7:41 PM Jeff Law wrote:
>
> On Thu, 2019-12-19 at 17:06 -0600, Qing Zhao wrote:
> > Hi, Dmitry,
> >
> > Thanks for the responds.
> >
> > Yes, routine size only cannot determine the complexity of the routine.
> > Different compiler analysis might have different formula with
Trying to plan memory consumption ahead-of-work contradicts with the nature
of the graph traversal. Estimation may work very well for something simple
like linear or log-linear behavior. But many compiler algorithms are known
to be polynomial or exponential (or even worse in case of bugs). So,
esti
I need a sanity check here.
Given this code:
> typedef union { long double value; unsigned int word[4]; } memory_long_double;
> static unsigned int ored_words[4];
> static void add_to_ored_words (long double x)
> {
> memory_long_double m;
> size_t i;
> memset (&m, 0, sizeof (m));
> m.valu
On December 20, 2019 3:20:40 AM GMT+01:00, Jeff Law wrote:
>I need a sanity check here.
>
>Given this code:
>
>> typedef union { long double value; unsigned int word[4]; }
>memory_long_double;
>> static unsigned int ored_words[4];
>> static void add_to_ored_words (long double x)
>> {
>> memory_l
On Fri, 2019-12-20 at 08:09 +0100, Richard Biener wrote:
> On December 20, 2019 3:20:40 AM GMT+01:00, Jeff Law wrote:
> > I need a sanity check here.
> >
> > Given this code:
> >
> > > typedef union { long double value; unsigned int word[4]; }
> > memory_long_double;
> > > static unsigned int or
On Thu, Dec 19, 2019 at 11:25 PM Jeff Law wrote:
>
> On Fri, 2019-12-20 at 08:09 +0100, Richard Biener wrote:
> > On December 20, 2019 3:20:40 AM GMT+01:00, Jeff Law wrote:
> > > I need a sanity check here.
> > >
> > > Given this code:
> > >
> > > > typedef union { long double value; unsigned int
58 matches
Mail list logo
