Thanks for the help, Martin!
On 05/03/2017 03:42 AM, Martin Jambor wrote:
Hi,
On Sat, Apr 29, 2017 at 06:28:31AM -0500, Daniel Santos wrote:
Brievity is not my forte, so let me start with the questions. Can somebody
please point me to the pass and/or function where gcc
1.) decides rather or
The following program gives a warning under GCC 7.1 (built on cygwin, 64 bit)
#include
int main()
{
std::vector c {1,2,3,0};
while(c.size() > 0 && c.back() == 0)
{
auto sz = c.size() -1;
c.resize(sz);
}
return 0;
}
$ c++7.1 -O3 tt.cxx
In Funktion »int main()
(I think you are looking for gcc-h...@gcc.gnu.org, or gcc's bugzilla,
rather than this mailing list)
On Fri, 5 May 2017, Helmut Zeisel wrote:
The following program gives a warning under GCC 7.1 (built on cygwin, 64 bit)
#include
int main()
{
std::vector c {1,2,3,0};
while(c.size() > 0
I added it to bugzilla, Bug 80641
Helmut
> On 05/04/2017 08:31 AM, Jeff Law wrote:
> >On 05/04/2017 07:26 AM, Дмитрий Дьяченко wrote:
> >>Fedora 26 x86_64
> >>r247595
> >>
> >>~/src/gcc_current/configure --prefix=/usr/local/gcc_current
> >>--enable-static --enable-checking=no --enable-languages=c,c++,lto
> >>--enable-plugin --disable-mult
> > On 05/04/2017 08:31 AM, Jeff Law wrote:
> > >On 05/04/2017 07:26 AM, Дмитрий Дьяченко wrote:
> > >>Fedora 26 x86_64
> > >>r247595
> > >>
> > >>~/src/gcc_current/configure --prefix=/usr/local/gcc_current
> > >>--enable-static --enable-checking=no --enable-languages=c,c++,lto
> > >>--enable-plugi
> > I wonder how that patch can cause mismatches. Does it reproduce on one of
> > compile farm machines (my x86-64 bootstrap works fine so does ia64 on
> > terbium
> > after fixing the gcc 4.1 issue yeterday).
> > It would be great to have -fdump-ipa-inline-details dumps of the mismatching
> > run
On May 5, 2017 3:03:43 PM GMT+02:00, Jan Hubicka wrote:
>> > I wonder how that patch can cause mismatches. Does it reproduce on
>one of
>> > compile farm machines (my x86-64 bootstrap works fine so does ia64
>on terbium
>> > after fixing the gcc 4.1 issue yeterday).
>> > It would be great to have
I see the following error during bootstrap on x86_64 configured
with:
--enable-languages=ada,all,c,c++,fortran,go,lto,objc,obj-c++
In file included from ./plugin-version.h:1:0,
from /src/gcc-trunk/gcc/plugin.c:34:
./configargs.h:7:33: error: expected primary-expression before ‘;
Sorry my apologies. I see that Nathan already fixed it. Must have slipped in
during a conflict resolution during one of the many rebase between testing and
commit approval.
Best regards,
Thomas
On 05/05/17 18:27, Martin Sebor wrote:
I see the following error during bootstrap on x86_64 config
I'm in the middle of adding support for the target_clone attribute to the
PowerPC. At the moment, the x86_64/i386 port is the only port that supports
target_clone. I added the arm/s390 port maintainers to this query, because
those ports might also consider supporting target_clones in the future.
This message is separated from the question about moving code, as it is a
questions about the functionality of target_clone support.
Right now it looks like target_clone only generates the ifunc handler if there
is a call to the function in the object file. It does not generate the ifunc
handler
A minor feature that also should be considered is if you have two clone
functions, one that calls the other, we should optimize the call to avoid using
the indirect call setup by ifunc.
I.e.
extern __attribute__((target_clones("default","avx","avx2"))) int
caller ();
extern __att
On Fri, May 05, 2017 at 12:32:03PM -0700, Evgeny Stupachenko wrote:
> Hi Michael,
>
> On Fri, May 5, 2017 at 11:45 AM, Michael Meissner
> wrote:
> > This message is separated from the question about moving code, as it is a
> > questions about the functionality of target_clone support.
> >
> > Rig
On 05/05/2017 12:18 PM, Michael Meissner wrote:
I'm in the middle of adding support for the target_clone attribute to the
PowerPC. At the moment, the x86_64/i386 port is the only port that supports
target_clone. I added the arm/s390 port maintainers to this query, because
those ports might also
I just submitted two patches against trunk. I'd like to also have them on the
7 branch, so when 7.2 comes out we'll have them. These patches only touch the
RISC-V backend, which I'm a maintainer of. Is there a branch maintainer I'm
supposed to have sign off on the patches or am I meant to just d
On Fri, May 05, 2017 at 01:38:03PM -0700, Evgeny Stupachenko wrote:
> On Fri, May 5, 2017 at 12:48 PM, Michael Meissner
> wrote:
> > On Fri, May 05, 2017 at 12:32:03PM -0700, Evgeny Stupachenko wrote:
> >> Hi Michael,
> >>
> >> On Fri, May 5, 2017 at 11:45 AM, Michael Meissner
> >> wrote:
> >> >
I have a simple question about dump_printf and dump_printf_loc. I notice
that most (all?) of the uses of these function are of the form:
if (dump_enabled_p ())
dump_printf_loc (MSG_*, ..);
Since dump_enabled_p() is just checking to see if dump_file or alt_dump_file
is
On 05/05/2017 08:53 AM, Richard Biener wrote:
On May 5, 2017 3:03:43 PM GMT+02:00, Jan Hubicka wrote:
Aha, --enable-checking=no. I will check what effect it have.
It does reproduce for me. Time estimates are very slightly different
between
checking and non-checking build. I am investigati
19 matches
Mail list logo
