On July 9, 2018 10:20:39 PM GMT+02:00, "Eric S. Raymond"
wrote:
>Richard Biener :
>> 12 hours from remote I guess? The subversion repository is available
>through rsync so you can create a local mirror to work from (we've been
>doing that at suse for years)
>
>I'm saying I see rsync plus local
On 07/09/2018 07:22 PM, Soul Studios wrote:
On 07/05/2018 05:14 PM, Soul Studios wrote:
Simply because a struct has a constructor does not mean it isn't a
viable target/source for use with memcpy/memmove/memset.
As the documentation that Segher quoted explains, it does
mean exactly that.
Ping #2: https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01509.html
On 07/03/2018 08:12 PM, Martin Sebor wrote:
Ping: https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01509.html
On 06/24/2018 03:05 PM, Martin Sebor wrote:
Storing integer command line option arguments in type int
limits options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86450
Fritz Reese changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
On 07/05/2018 05:14 PM, Soul Studios wrote:
Simply because a struct has a constructor does not mean it isn't a
viable target/source for use with memcpy/memmove/memset.
As the documentation that Segher quoted explains, it does
mean exactly that.
Some classes have user-defined copy and default
On Jul 9, 2018, Jeff Law wrote:
> On 07/09/2018 01:57 PM, Eric S. Raymond wrote:
>> Jeff Law :
>>> I'm not aware of any such merges, but any that occurred most likely
>>> happened after mid-April when the trunk was re-opened for development.
>> I'm pretty certain things were still good at
This patch to the Go frontend by Cherry Zhang fixes the compiler to
avoid a double evaluation of an interface field expression. In
Interface_field_reference_expression, the interface expression is used
in two places, so a temporary variable is used. Previously, we used a
This patch uses the opt_result framework throughout the vectorizer
(and a few other places) so that specific details on problems are
propagated back up to the top-level of the vectorizer.
The changes are mostly fairly mechanical.
There are various FIXMEs in the code: for example, in various
gcc/ChangeLog:
* opt-problem.h: New file.
* tree-vectorizer.h (opt_loop_vec_info): New typedef.
---
gcc/opt-problem.h | 326 ++
gcc/tree-vectorizer.h | 6 +
2 files changed, 332 insertions(+)
create mode 100644
gcc/ChangeLog:
* Makefile.in (OBJS): Add opt-problem.o.
* opt-problem.cc: New file.
---
gcc/Makefile.in| 1 +
gcc/opt-problem.cc | 96 ++
2 files changed, 97 insertions(+)
create mode 100644 gcc/opt-problem.cc
diff --git
gcc/ChangeLog:
* tree-vectorizer.c: Include "opt-problem.h".
(try_vectorize_loop_1): Convert "loop_vinfo" from loop_vec_info to
opt_loop_vec_info loop_vinfo, and use opt_report to report any
opt_problem thus captured. Use opt_report ro report on successful
In particular, note how this allows us to highlight specific loops in
testcases (via dg-remark), and to highlight the specific lines that cause
problems to the vectorizer (via dg-message).
gcc/testsuite/ChangeLog:
* gcc.dg/vect/vect-alias-check-4.c: Add -fremarks to options. Add
On Mon, 2018-06-25 at 11:10 +0200, Richard Biener wrote:
> On Fri, 22 Jun 2018, David Malcolm wrote:
>
> > NightStrike and I were chatting on IRC last week about
> > issues with trying to vectorize the following code:
> >
> > #include
> > std::size_t f(std::vector> const & v) {
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86450
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P1
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86415
Martin Sebor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819
Bug 83819 depends on bug 86415, which changed state.
Bug 86415 Summary: strlen() not folded for substrings within constant arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86415
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86415
--- Comment #4 from Martin Sebor ---
Author: msebor
Date: Tue Jul 10 00:02:36 2018
New Revision: 262528
URL: https://gcc.gnu.org/viewcvs?rev=262528=gcc=rev
Log:
PR tree-optimization/86415 - strlen() not folded for substrings within constant
GCC Maintainers:
The following patch is a back port for a commit to mainline prior to
GCC 8 release. Note, the code fixed by this patch was later modified
in commit 256798 as part of adding vec_xst_len support. The sldi
instruction gets replaced by an ashift of the operand for the stxvl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86446
--- Comment #8 from Dominique d'Humieres ---
> > The correct invocation of a GCC testsuite is "make -k check-blah", otherwise
> > the recursive Make processes will stop on errors.
> >
>
> Since when? I've been doing 'gmake check-fortran' and
>
On 07/09/2018 10:38 AM, Richard Earnshaw wrote:
>
> The patches I posted earlier this year for mitigating against
> CVE-2017-5753 (Spectre variant 1) attracted some useful feedback, from
> which it became obvious that a rethink was needed. This mail, and the
> following patches attempt to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86446
--- Comment #7 from Steve Kargl ---
On Mon, Jul 09, 2018 at 10:21:20PM +, ebotcazou at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86446
>
> --- Comment #6 from Eric Botcazou ---
> > 'gmake -j6 check-fortran' has
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86446
--- Comment #6 from Eric Botcazou ---
> 'gmake -j6 check-fortran' has never died on an error
> like the one I've shown in the 15+ years that I've been
> contributing to GCC. Needing -k now, means someone has
> broken the build infrastructure.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86446
--- Comment #5 from Steve Kargl ---
On Mon, Jul 09, 2018 at 10:05:23PM +, ebotcazou at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86446
>
> --- Comment #4 from Eric Botcazou ---
> > Since when?
>
> The dawn of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86446
--- Comment #4 from Eric Botcazou ---
> Since when?
The dawn of time, see https://gcc.gnu.org/contribute.html#testing
On 07/09/2018 06:40 AM, Richard Biener wrote:
On Sun, Jul 8, 2018 at 4:56 AM Martin Sebor wrote:
On 07/06/2018 09:52 AM, Richard Biener wrote:
On Fri, Jul 6, 2018 at 1:54 AM Martin Sebor wrote:
GCC folds accesses to members of constant aggregates except
for character arrays/strings. For
On 07/09/2018 08:36 AM, Aldy Hernandez wrote:
{ dg-do run }
{ do-options "-O2 -fno-tree-strlen" } */
I don't think this is doing anything.
If you look at the test run you can see that -fno-tree-strlen is never
passed (I think you actually mean -fno-optimize-strlen for that
matter).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86417
--- Comment #11 from Thomas Koenig ---
(In reply to janus from comment #10)
> (In reply to janus from comment #9)
> > The following patch seems to be sufficient to fix the regression:
>
>
> ... however, it lacks a safety check for the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86450
Bug ID: 86450
Summary: Bootstrap failure due to -Wabi
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
On 07/06/2018 02:59 PM, Peter Bergner wrote:
> On 7/5/18 2:36 PM, Jeff Law wrote:
>> On 07/02/2018 03:50 PM, Peter Bergner wrote:
>>> I'd like to PING:
>>>
>>> https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01713.html
>>>
>>> I've included the entire patch below, since I missed the test cases in
On 07/09/2018 01:51 PM, Jeff Law wrote:
On 07/09/2018 08:36 AM, Aldy Hernandez wrote:
{ dg-do run }
{ do-options "-O2 -fno-tree-strlen" } */
I don't think this is doing anything.
If you look at the test run you can see that -fno-tree-strlen is never
passed (I think you actually
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819
Bug 83819 depends on bug 86428, which changed state.
Bug 86428 Summary: strlen of const array initialized with a string of the same
length not folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86428
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86428
Martin Sebor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77357
Martin Sebor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819
Bug 83819 depends on bug 77357, which changed state.
Bug 77357 Summary: strlen of constant strings not folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77357
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77357
--- Comment #6 from Martin Sebor ---
Author: msebor
Date: Mon Jul 9 20:33:48 2018
New Revision: 262522
URL: https://gcc.gnu.org/viewcvs?rev=262522=gcc=rev
Log:
PR middle-end/77357 - strlen of constant strings not folded
gcc/ChangeLog:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86428
--- Comment #3 from Martin Sebor ---
Author: msebor
Date: Mon Jul 9 20:33:48 2018
New Revision: 262522
URL: https://gcc.gnu.org/viewcvs?rev=262522=gcc=rev
Log:
PR middle-end/77357 - strlen of constant strings not folded
gcc/ChangeLog:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86449
Bug ID: 86449
Summary: GCC 8 compiler generates slower code for spec 2006
calculix on a power9 using -mcpu=power9 than using
-mcpu=power8
Product: gcc
Version:
On 07/09/2018 01:28 PM, Qing Zhao wrote:
Hi, Martin,
thanks a lot for your comments.
On Jul 5, 2018, at 11:30 AM, Martin Sebor wrote:
One of the basic design principles that I myself have
accidentally violated in the past is that warning options
should not impact the emitted object code. I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86448
Bug ID: 86448
Summary: GCC 9 compiler generates slower code for spec 2006
milc on a power9 using -mcpu=power9 than using
-mcpu=power8
Product: gcc
Version: 9.0
Richard Biener :
> 12 hours from remote I guess? The subversion repository is available through
> rsync so you can create a local mirror to work from (we've been doing that at
> suse for years)
I'm saying I see rsync plus local checkout take 10-12 hours. I asked Jason
about this and his
Jeff Law :
> > I'm pretty certain things were still good at r256000. I've started that
> > check running. Not expecting results in less than twelve hours.
> r256000 would be roughly Christmas 2017. I'd be very surprised if any
> merges to the trunk happened between that point and early April.
On July 9, 2018 9:19:11 PM GMT+02:00, e...@thyrsus.com wrote:
>Last time I did a comparison between SVN head and the git conversion
>tip they matched exactly. This time I have mismatches in the following
>files.
>
>libtool.m4
>libvtv/ChangeLog
>libvtv/configure
>libvtv/testsuite/lib/libvtv.exp
Florian Weimer :
> * Eric S. Raymond:
>
> > The bad news is that my last test run overran the memnory capacity of
> > the 64GB Great Beast. I shall have to find some way of reducing the
> > working set, as 128GB DD4 memory is hideously expensive.
>
> Do you need interactive access to the
On 07/09/2018 01:57 PM, Eric S. Raymond wrote:
> Jeff Law :
>>> There are brute-force ways to pin down such malformations, but none of
>>> them are practical at the huge scale of this repository. The main
>>> problem here wouldn't reposurgeon itself but the fact that Subversion
>>> checkouts on a
Bernd Schmidt :
> On 07/09/2018 09:19 PM, Eric S. Raymond wrote:
> > Last time I did a comparison between SVN head and the git conversion
> > tip they matched exactly. This time I have mismatches in the following
> > files.
>
> So what are the diffs? Are we talking about small differences (like
Jeff Law :
> > There are brute-force ways to pin down such malformations, but none of
> > them are practical at the huge scale of this repository. The main
> > problem here wouldn't reposurgeon itself but the fact that Subversion
> > checkouts on a repo this large are very slow. I've seen a
On 07/09/2018 01:19 AM, Aldy Hernandez wrote:
>>
>> I'd like decisions about how to expand branches deferred until rtl
>> expansion. Kai was poking at this in the past but never really got any
>> traction.
>
> For the record, the problem in this testcase is that switch lowering is
> riddled with
=== gfortran Summary ===
# of expected passes8017
# of expected failures 3
# of unsupported tests 24
/safe/sgk/gcc/obj/gcc/gfortran version 9.0.0 20180709 (experimental) (GCC)
gmake[2]: Leaving directory '/safe/sgk/gcc/obj/gcc'
gmake[1]: Leavin
On 07/09/2018 08:36 AM, Aldy Hernandez wrote:
>{ dg-do run }
>{ do-options "-O2 -fno-tree-strlen" } */
>
> I don't think this is doing anything.
>
> If you look at the test run you can see that -fno-tree-strlen is never
> passed (I think you actually mean -fno-optimize-strlen for
* Eric S. Raymond:
> The bad news is that my last test run overran the memnory capacity of
> the 64GB Great Beast. I shall have to find some way of reducing the
> working set, as 128GB DD4 memory is hideously expensive.
Do you need interactive access to the machine, or can we run the job
for
On 07/09/2018 09:19 PM, Eric S. Raymond wrote:
> Last time I did a comparison between SVN head and the git conversion
> tip they matched exactly. This time I have mismatches in the following
> files.
So what are the diffs? Are we talking about small differences (like one
change missing) or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86447
Bug ID: 86447
Summary: gcc 9.0 from r262456 can't build cross compiler for
mingw-w64 target
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
On 07/09/2018 01:19 PM, Eric S. Raymond wrote:
> Last time I did a comparison between SVN head and the git conversion
> tip they matched exactly. This time I have mismatches in the following
> files.
>
> libtool.m4
> libvtv/ChangeLog
> libvtv/configure
> libvtv/testsuite/lib/libvtv.exp
>
or. The last few line are
=== gfortran Summary ===
# of expected passes6413
# of expected failures 18
# of unsupported tests 2
/safe/sgk/gcc/obj8/gcc/gfortran version 8.1.1 20180709 (GCC)
gmake[2]: Leaving directory '/safe/sgk/gcc/obj8/gcc'
gmake[1]: Leaving directory '
Hi, Martin,
thanks a lot for your comments.
> On Jul 5, 2018, at 11:30 AM, Martin Sebor wrote:
>
> One of the basic design principles that I myself have
> accidentally violated in the past is that warning options
> should not impact the emitted object code. I don't think
> your patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86446
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
Last time I did a comparison between SVN head and the git conversion
tip they matched exactly. This time I have mismatches in the following
files.
libtool.m4
libvtv/ChangeLog
libvtv/configure
libvtv/testsuite/lib/libvtv.exp
ltmain.sh
lto-plugin/ChangeLog
lto-plugin/configure
Hi,
Add support for early gimple folding of vec_perm. Testcases are already
in-tree as
gcc.target/powerpc/fold-vec-perm-*.c
OK for trunk?
Thanks,
-Will
[gcc]
2018-07-09 Will Schmidt
* gcc/config/rs6000/rs6000.c (rs6000_gimple_fold_builtin): Add support
for
Hi,
Testcases to exercise the vec_unpack intrinsics.
Tested clean across assorted systems.
OK for trunk?
Thanks,
-Will
[testsuite]
2018-07-09 Will Schmidt
* gcc.target/powerpc/fold-vec-unpack-char.c: New.
* gcc.target/powerpc/fold-vec-unpack-float.c:
Hi,
Add support for gimple folding for vec_pack(), vec_unpackh() and
vec_unpackl().
Testcases for vec_pack are already in tree. Tests for vec_unpack
have been posted separately.
OK for trunk?
Thanks,
-Will
[gcc]
2018-07-09 Will Schmidt
* config/rs6000/rs6000.c
Hi,
Re-posting. Richard provided feedback on a previous version of this
patch, I wanted to make sure he was/is OK with the latest. :-)
Add support for Gimple folding for unaligned vector loads and stores.
Regtest completed across variety of systems, P6,P7,P8,P9.
[v2] Added the type
At the same time, merge several related frame computing functions.
Recall that HWI is now always 64-bit, so merge IMASK and FMASK,
which allows merging of several loops within prologue and epilogue.
Full regression testing will take some time, but a quick browse
suggests no change in generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86438
--- Comment #2 from Uroš Bizjak ---
Here is what happens:
compare operators in (insn 66) are substituted with their defs from (insn 64)
and (insn 14). The CC mode is calculated from SELECT_CC_MODE, which really
returns CCCmode. The flags reg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86446
Bug ID: 86446
Summary: 'gmake check-fortran' broken in libgomp
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86445
Bug ID: 86445
Summary: [9 regression] Missing warning for test case
gcc/testsuite/gcc.dg/pr84100.c starting with r262513
Product: gcc
Version: 9.0
Status: UNCONFIRMED
On Mon, 2018-07-09 at 06:16 -0400, Eric S. Raymond wrote:
> Janus Weil :
> > > The bad news is that my last test run overran the memnory
> > > capacity of
> > > the 64GB Great Beast. I shall have to find some way of reducing
> > > the
> > > working set, as 128GB DD4 memory is hideously expensive.
On Mon, 2018-07-09 at 10:57 -0600, Jeff Law wrote:
> On 07/09/2018 10:53 AM, Janus Weil wrote:
> > 2018-07-09 18:35 GMT+02:00 Eric S. Raymond :
> > > David Edelsohn :
> > > > > The truth is we're near the bleeding edge of what conventional tools
> > > > > and hardware can handle gracefully. Most
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86440
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86421
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86444
Bug ID: 86444
Summary: [X86] Implementation of SSE comi/ucomi intrinsics does
not match recent versions of icc, clang, or MSVC
Product: gcc
Version: 9.0
Status:
On Mon, Jul 9, 2018 at 12:35 PM Eric S. Raymond wrote:
>
> David Edelsohn :
> > > The truth is we're near the bleeding edge of what conventional tools
> > > and hardware can handle gracefully. Most jobs with working sets as
> > > big as this one's do only comparatively dumb operations that can
On 07/09/2018 10:53 AM, Janus Weil wrote:
> 2018-07-09 18:35 GMT+02:00 Eric S. Raymond :
>> David Edelsohn :
The truth is we're near the bleeding edge of what conventional tools
and hardware can handle gracefully. Most jobs with working sets as
big as this one's do only
2018-07-09 18:35 GMT+02:00 Eric S. Raymond :
> David Edelsohn :
>> > The truth is we're near the bleeding edge of what conventional tools
>> > and hardware can handle gracefully. Most jobs with working sets as
>> > big as this one's do only comparatively dumb operations that can be
>> >
The CB[N]Z and TB[N]Z instructions do not expose the comparison through
the condition code flags. This makes it impossible to track speculative
execution through such a branch. We can handle this relatively easily
by simply disabling the patterns in this case.
A side effect of this is that the
This patch is the main part of the speculation tracking code. It adds
a new target-specific pass that is run just before the final branch
reorg pass (so that it can clean up any new edge insertions we make).
The pass is only run with -mtrack-speculation is passed on the command
line.
One thing
In this final patch, now that we can track speculation through conditional
branches, we can use this information to use a less expensive CSDB based
speculation barrier.
* config/aarch64/iterators.md (ALLI_TI): New iterator.
* config/aarch64/aarch64.md (despeculate_copy): New
This patch defines a new intrinsic function
__builtin_speculation_safe_value. A generic default implementation is
defined which will attempt to use the backend pattern
"speculation_safe_barrier". If this pattern is not defined, or if it
is not available, then the compiler will emit a warning,
This patch doesn't do anything useful, it simply adds a new command-line
option -mtrack-speculation to AArch64. Subsequent patches build on this.
* config/aarch64/aarch64.opt (mtrack-speculation): New target option.
---
gcc/config/aarch64/aarch64.opt | 4
1 file changed, 4
Similar to Arm, this adds an unconditional speculation barrier for AArch64.
* config/aarch64.md (unspecv): Add UNSPECV_SPECULAION_BARRIER.
(speculation_barrier): New insn.
---
gcc/config/aarch64/aarch64.md | 10 ++
1 file changed, 10 insertions(+)
diff --git
This patch defines a speculation barrier for AArch32.
* config/arm/unspecs.md (unspecv): Add VUNSPEC_SPECULATION_BARRIER.
* config/arm/arm.md (speculation_barrier): New expand.
(speculation_barrier_insn): New pattern.
---
gcc/config/arm/arm.md | 21
The patches I posted earlier this year for mitigating against
CVE-2017-5753 (Spectre variant 1) attracted some useful feedback, from
which it became obvious that a rethink was needed. This mail, and the
following patches attempt to address that feedback and present a new
approach to mitigating
David Edelsohn :
> > The truth is we're near the bleeding edge of what conventional tools
> > and hardware can handle gracefully. Most jobs with working sets as
> > big as this one's do only comparatively dumb operations that can be
> > parallellized and thrown on a GPU or supercomputer. Most
On Mon, Jul 9, 2018 at 6:21 AM Andre Vieira (lists)
wrote:
>
> Hi,
>
> This patch adds support for the Statistical Profiling Extension (SPE) on
> AArch64. Even though the compiler will not generate code any differently
> given this extension, it will need to pass it on to the assembler in
> order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86422
--- Comment #13 from rguenther at suse dot de ---
On July 9, 2018 5:40:31 PM GMT+02:00, "boris.staletic at gmail dot com"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86422
>
>--- Comment #12 from Boris Staletic
>---
>If you're
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86426
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86422
--- Comment #12 from Boris Staletic ---
If you're wondering about clang, it hangs too, but doesn't hog memory.
> That's to be expected when it runs into swap.
Anything else I should try?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86442
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86397
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86422
--- Comment #11 from rguenther at suse dot de ---
On July 9, 2018 5:18:40 PM GMT+02:00, "boris.staletic at gmail dot com"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86422
>
>--- Comment #10 from Boris Staletic
>---
>Running "g++ -S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86442
--- Comment #1 from Jan Hubicka ---
> Following wrong error is printed with LTO:
>
> $ cat global.cpp
> register int a __asm__("r12");
>
> class b {
> public:
> b();
> };
>
> b c;
>
> int main() { a = 3; }
>
> $ g++ global.cpp -O2 -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86422
--- Comment #10 from Boris Staletic ---
Running "g++ -S -fno-exceptions CodePoint.cpp" didn't run into OOM killer, but
gcc still hanged. The memory usage at maximum was 15.6GB. What I find strange
is that "htop" reported the g++ process as dead
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86443
Bug ID: 86443
Summary: ICEs on #pragma omp distribute parallel for with class
iterators
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
On 07/09/2018 07:16 AM, Rainer Orth wrote:
and several more. This seems to be the only backend that uses the
additional bool * argument to wi::neg etc.
Fixed as follows, bootstrapped on sparc-sun-solaris2.11.
Thanks. Sorry for the oversight.
Aldy
{ dg-do run }
{ do-options "-O2 -fno-tree-strlen" } */
I don't think this is doing anything.
If you look at the test run you can see that -fno-tree-strlen is never
passed (I think you actually mean -fno-optimize-strlen for that
matter). Also, the builtins.exp harness runs your test
On Sat, Jul 7, 2018 at 11:47 PM Martin Sebor wrote:
>
> While working on other string folding improvements (PR 77357)
> I came across another distinct case where GCC could do better:
> it doesn't consider as candidates strings that have as many
> elements as the size of the array they are stored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86441
--- Comment #1 from Boris Kolpackov ---
Created attachment 44366
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44366=edit
Test case that shows the problem if compiled with ODB
For the record, a test case that triggers the error if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86442
Bug ID: 86442
Summary: Wrong error: global register variable follows a
function definition when using LTO
Product: gcc
Version: 9.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86441
Bug ID: 86441
Summary: instantiate_class_template() unable to re-execute
constexpr function
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86438
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86438
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
1 - 100 of 159 matches
Mail list logo
