https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10980
Alejandro Colomar changed:
What|Removed |Added
CC||colomar.6.4.3 at gmail dot com
---
* Segher Boessenkool:
> On Thu, Jul 04, 2019 at 01:27:27PM +0200, Florian Weimer wrote:
>> Implicit function declarations were removed from C99, more than twenty
>> years ago. So far, GCC only warns about them because there were too
>> many old configure scripts where an error would lead to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91088
--- Comment #1 from Marc Glisse ---
I am surprised we don't have a match.pd transformation for v * 2 < 6 with
undefined overflow. But that's only a side remark, not important for your
report.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91091
Bug ID: 91091
Summary: [missed optimization] Missing aliasing optimization
Product: gcc
Version: 5.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91090
Bug ID: 91090
Summary: A suspicious code in tree-ssa-dom.c
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #39 from The Written Word
---
(In reply to EML from comment #25)
> I have applied the patch and tried your other suggestions, still the stage1
> compiler has the same problems generating executables.
>
> In analyzing the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #38 from The Written Word
---
I rebuilt 8.3.0 with minimal patches and am seeing the same failure as before.
From /ia64-hp-hpux11.31/libstdc++-v3/config.log:
configure:7964: checking for ANSI C header files
configure:7984:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91089
Bug ID: 91089
Summary: IPA-cp does setup proper cost model for switch default
case in function versioning
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89976
--- Comment #1 from Eric Gallager ---
could you be a bit more specific about which lines exactly you're expecting the
warnings to go on?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91088
Bug ID: 91088
Summary: IPA-cp cost evaluation is too conservative for "if
(f(param) cmp const_val)" condition
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #37 from EML ---
I wonder if is this patch is related:
https://gcc.gnu.org/ml/gcc-patches/2015-12/msg02193.html
"Before the patch generated code uses .GOT entry:
addl r14 = @ltoffx(a#), r1
ld8.mov r14 = [r14], a#
On 7/5/19 9:24 AM, Jim Wilson wrote:
On 7/4/19 11:08 PM, Christopher Faylor wrote:
On Thu, Jul 04, 2019 at 02:44:05PM +0800, Jim Wilson wrote:
Yes, I mentioned in another thread that this might be an SEO attempt,
and that the right solution is to report them as bad actors to the
search
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #36 from dave.anglin at bell dot net ---
On 2019-07-03 6:06 p.m., elowe at elowe dot com wrote:
> The non-working .s file does this:
>
> .LC0:
> stringz "Hellos World"
>
>
>
> movl r36 = @gprel(.LC0)
> ;;
>
On 7/4/19 11:08 PM, Christopher Faylor wrote:
On Thu, Jul 04, 2019 at 02:44:05PM +0800, Jim Wilson wrote:
On 7/3/19 8:02 PM, Tara Hamilton wrote:
Every time these links show up in an email message they get archived and
amplified for posterity. I wonder if that wasn't the actual intent of
the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #35
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91086
--- Comment #3 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #2)
> Yes, I think G++ used to not to this, and it was changed to the current
> behaviour to avoid such problems.
Just to be clear, my "yes" was intended to mean
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91086
--- Comment #2 from Jonathan Wakely ---
Yes, I think G++ used to not to this, and it was changed to the current
behaviour to avoid such problems.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78747
Jan Engelhardt changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
On Thu, Jul 4, 2019 at 11:39 PM Jakub Jelinek wrote:
> On Thu, Jul 04, 2019 at 10:40:15AM -0700, Paul E. McKenney wrote:
> > > I think fully guaranteeing this is hard (besides when you use
> > > volatile), we have the very same issue when dealing with
> > > pointer provenance rules, known for
On Thu, Jul 04, 2019 at 01:32:59PM +0100, Jozef Lawrynowicz wrote:
> The attached patch allows the case of register names used in an asm statement
> clobber list to be disregarded when checking the validity of the register
> names.
>
> Currently, the register name used in asm statement clobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90756
--- Comment #17 from Mike Hommey ---
(In reply to Mike Hommey from comment #16)
> Similar ICE with 7.3.
And 7.4 (and to be clear, this is similar ICE as comment 14)
Snapshot gcc-7-20190704 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/7-20190704/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 7 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-7
On 07/04/2019 03:43 AM, Richard Biener wrote:
On Thu, Jul 4, 2019 at 2:36 AM Indu Bhagat wrote:
[...]
RE subset of C : It is true that CTF format currently does leave out a very
small subset of C like FIXED_POINT as you noted ( CTF does have representation
for COMPLEX_TYPE, if my code paths
On Thu, Jul 04, 2019 at 01:27:27PM +0200, Florian Weimer wrote:
> Implicit function declarations were removed from C99, more than twenty
> years ago. So far, GCC only warns about them because there were too
> many old configure scripts where an error would lead to incorrect
> configure check
On Wed, 3 Jul 2019, Richard Biener wrote:
On July 3, 2019 4:53:30 PM GMT+02:00, "Martin Liška" wrote:
On 7/2/19 7:15 PM, Marc Glisse wrote:
On Tue, 2 Jul 2019, Martin Liška wrote:
After the discussion with Richi and Nathan, I made a place in
tree_function_decl
and I rebased the original
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91030
--- Comment #35 from Jerry DeLisle ---
(In reply to Thomas Koenig from comment #34)
> There is another point to consider.
>
> I suppose not very many people use big-endian data formats
> these days. Little-endian dominates these days, and
Hi!
This fixes an ICE in the gimplifier, for VLAs we really can't call
omp_add_variable with GOVD_PRIVATE before the DECL_EXPR is actually
gimplified.
Furthermore, there is really no hope in actually vectorizing such loops and
when we make it just GOVD_LOCAL, we shouldn't mark the loop as
Hi,
> diff --git a/gcc/config/msp430/msp430.c b/gcc/config/msp430/msp430.c
> index 365e9eb..8266fa0 100644
> --- a/gcc/config/msp430/msp430.c
> +++ b/gcc/config/msp430/msp430.c
> @@ -1807,7 +1807,6 @@ const char * const ATTR_CRIT = "critical";
> const char * const ATTR_LOWER = "lower";
>
Hi!
This patch fixes worksharing loops containing both conditional lastprivate
and inscan reduction(s). Furthermore, it for nowait omp for ensures there
is GOMP_loop_end_nowait call at the end after the second loop in scan
and not after the first one.
Bootstrapped/regtested on x86_64-linux and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78884
--- Comment #9 from Jakub Jelinek ---
Author: jakub
Date: Thu Jul 4 21:41:49 2019
New Revision: 273096
URL: https://gcc.gnu.org/viewcvs?rev=273096=gcc=rev
Log:
PR middle-end/78884
* gimplify.c (struct gimplify_omp_ctx): Add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91030
--- Comment #34 from Thomas Koenig ---
There is another point to consider.
I suppose not very many people use big-endian data formats
these days. Little-endian dominates these days, and people
who require that conversion on a regular basis (why
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #34 from dave.anglin at bell dot net ---
On 2019-07-04 4:43 p.m., elowe at elowe dot com wrote:
> Could the problem be with "AS"?
>
> Maybe that assembler is technically ok, but AS is generating bad machine code?
That's easy to check.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #33 from EML ---
Could the problem be with "AS"?
Maybe that assembler is technically ok, but AS is generating bad machine code?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91087
--- Comment #1 from Iain Sandoe ---
sorry about the typos.
a) I meant to say that priorities would work in the case of single TU or LTO,
because that does the same thing.
b) the SysV spec says:
"Termination functions specified by users via
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91087
Iain Sandoe changed:
What|Removed |Added
Keywords||ABI
Target|
On 04.07.2019 12:21, rguenth at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91084
>
> Richard Biener changed:
>
>What|Removed |Added
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91087
Bug ID: 91087
Summary: g++.dg/gcov/pr16855.C fails everywhere on Darwin.
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78884
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91084
--- Comment #7 from Jonathan Wakely ---
Or you could always just download the packages and untar them by hand. The
script isn't mandatory, it's just a convenience.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91084
--- Comment #6 from Jonathan Wakely ---
Or without the overlong line:
--- a/contrib/download_prerequisites
+++ b/contrib/download_prerequisites
@@ -241,9 +241,15 @@ unset ar
for ar in $(echo_archives)
do
package="${ar%.tar*}"
+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91084
--- Comment #5 from Jonathan Wakely ---
This is not a BSD problem, it's just a case of writing a portable shell script.
This should work:
--- a/contrib/download_prerequisites
+++ b/contrib/download_prerequisites
@@ -241,9 +241,15 @@ unset ar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91084
--- Comment #4 from Thomas Koenig ---
~/trunk $ svn diff contrib/
Index: contrib/download_prerequisites
===
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91084
--- Comment #3 from Thomas Koenig ---
~/trunk $ svn diff contrib/
Index: contrib/download_prerequisites
===
---
On Thu, Jul 04, 2019 at 10:40:15AM -0700, Paul E. McKenney wrote:
> > I think fully guaranteeing this is hard (besides when you use
> > volatile), we have the very same issue when dealing with
> > pointer provenance rules, known for years and not fixed
> > (and I don't see a good way to fix these
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Ukrainian team of translators. The file is available at:
https://translationproject.org/latest/gcc/uk.po
(This file, 'gcc-9.1.0.uk.po', has
On Thu, Jul 04, 2019 at 01:00:18PM +0200, Richard Biener wrote:
> On Wed, Jul 3, 2019 at 6:33 PM Paul E. McKenney wrote:
> >
> > On Wed, Jul 03, 2019 at 05:47:56PM +0200, Richard Biener wrote:
> > > On July 3, 2019 5:14:58 PM GMT+02:00, "Paul E. McKenney"
> > > wrote:
> > > >On Wed, Jul 03,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91050
--- Comment #12 from Segher Boessenkool ---
Ah, common/config/aarch64/aarch64-common.c .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91050
--- Comment #11 from Segher Boessenkool ---
Such a rewrite function would be great I think. I don't want the -mdejagnu-cpu
thing to need any deeper code changes, but this attacks the one problem the
simple -mcpu override did not: specs.
(I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91027
--- Comment #3 from Jan Hubicka ---
Hi,
this patch triggers another confusion in ipa-devirt.
It tries to build type inheritnace graph but since D frotnend produces
only functions with DECL_VIRTUAL but no BINFOs and other things it
segfaults
Andrea Corallo writes:
> David Malcolm writes:
>
>>> Hi David,
>>> I can work on to get the SVN commit access.
>>> As a maintainer has to sponsor it would you mind being the one?
>>
>> https://www.gnu.org/software/gcc/svnwrite.html says:
>> "a well-established GCC maintainer (including
Hi,
while working on subsetquent changes I noticed that I got worng
the boundary condition while we collect refs.
We know that match1 and match2 are the same which means that we want
to start disambiguating until the last ref that reach the match.
For example when one is MEM_REF and other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91086
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Never mind, if the target has reg+offset addressing, the add should be
tried in preference to post_modify, since this enables
reload_combine_recognize_const_pattern .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91027
--- Comment #2 from Jan Hubicka ---
Hi,
the reason is that type "struct C264" has DECL_ASSEMBLER_NAME (TYPE_NAME
(type))
set to
which makes LTO to consider this type to be C++ type conforming ODR
rule.
I am not really fluent with d. Does d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78884
--- Comment #7 from Jakub Jelinek ---
We should accept it, but of course it is completely fine to force not to
vectorize it (i.e. force safelen(1)), there is no hope that we'd actually
vectorize it at least in the not too distant future.
> Hi.
>
> The patch makes a loop upper bound estimation based on
> __builtin_expect_with_probability.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> The patch is pre-approved by Honza.
> Thanks,
> Martin
>
> gcc/ChangeLog:
>
> 2019-07-04 Martin Liska
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78884
Alexander Monakov changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Remove the XFAIL on arm in cunroll-15.c since the test passes on trunk.
Committed as obvious.
ChangeLog:
2019-07-04 Wilco Dijkstra
testsuite/
* gcc.dg/tree-ssa/cunroll-15.c: Remove XFAIL on arm.
--
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/cunroll-15.c
Hi.
The patch makes a loop upper bound estimation based on
__builtin_expect_with_probability.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
The patch is pre-approved by Honza.
Thanks,
Martin
gcc/ChangeLog:
2019-07-04 Martin Liska
* tree-ssa-loop-niter.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91030
--- Comment #33 from Jerry DeLisle ---
Well, I am not opposed to it. What we do not want is to pessimize older smaller
machines where it does matter a lot. However if Thomas strategy above is
adjusted from 32768 to 65536 then out of the box it
Andrea Corallo writes:
> Hi Dave,
> last version for this patch addressing the suggestion about the
> JIT_BIT_FIELD macros comment description.
>
> Thank you for all the suggestions.
>
> Regarding the write access please see my previous answer into the binary
> op patch thread.
>
> Bests
>
On 7/4/19 5:03 PM, David Edelsohn wrote:
> On Thu, Jul 4, 2019 at 10:38 AM Martin Liška wrote:
>>
>> Hi.
>>
>> Recently I've introduced a new .gnu.lto_.lto section that
>> is supposed to provide meta information about a LTO bytecode.
>>
>> As a further step, I'm planning to teach binutils about
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91030
--- Comment #32 from David Edelsohn ---
If the performance measured by Jerry is hitting limits of the 4 x 32KiB L1
D-Cache of the Ryzen 2500U, then the system has bigger problems than FORTRAN
I/O buffer size.
What is the target audience /
On Thu, 4 Jul 2019 17:27:28 +0200
Christophe Lyon wrote:
> Finally, I tested on arm-eabi, but not on msp430 for which I do not
> have the environment, so advice from msp430 maintainers is
> appreciated. Since msp430 does not use the same default helpers as
> arm, I left the "noinit" handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91050
--- Comment #10 from Peter Bergner ---
(In reply to Alan Modra from comment #8)
> Created attachment 46555 [details]
> assembler command line fixes
>
> I'll happily handle the assembler command line problems. Here's a lightly
> tested patch.
Hi,
Similar to what already exists for TI msp430 or in TI compilers for
arm, this patch adds support for the "noinit" attribute.
It is convenient for embedded targets where the user wants to keep the
value of some data when the program is restarted: such variables are
not zero-initialized. It is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91030
--- Comment #31 from David Edelsohn ---
What is the PAGESIZE on the Ryzen system? On the POWER systems, the PAGESIZE
is 64K. Maybe the optimal buffer size (write size) allows the filesystem to
perform double-buffering at the PAGESIZE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91030
--- Comment #30 from Thomas Koenig ---
> Why are you opposed to the larger 65536 or 131072 as a default?
Please look at Jerry's numbers from comment #24.
They show a severe regression (for his system) for blocksizes > 32768.
On Thu, Jul 04, 2019 at 02:44:05PM +0800, Jim Wilson wrote:
>On 7/3/19 8:02 PM, Tara Hamilton wrote:
>>I’ve just been looking at your website and I came across this webpage:
>>...
>>
>>Unfortunately, when I click the link ‘...’ it redirects me to a payday
>>loan site.
Every time these links show
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90883
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #14 from
On Thu, Jul 4, 2019 at 10:38 AM Martin Liška wrote:
>
> Hi.
>
> Recently I've introduced a new .gnu.lto_.lto section that
> is supposed to provide meta information about a LTO bytecode.
>
> As a further step, I'm planning to teach binutils about
> existence of the section and I'll remove in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91030
--- Comment #29 from David Edelsohn ---
> For formatted files, chose the value that the user supplied
> via an environment variable. If the user supplied nothing, then
>
> - query the recommended block size via calling fstat and evaluating
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91086
Bug ID: 91086
Summary: std namespace symbols can get their visibility
degraded
Product: gcc
Version: 9.1.1
Status: UNCONFIRMED
Severity: normal
Hi.
Recently I've introduced a new .gnu.lto_.lto section that
is supposed to provide meta information about a LTO bytecode.
As a further step, I'm planning to teach binutils about
existence of the section and I'll remove in the future
emission of __gnu_lto_slim and __gnu_lto_v1 symbols.
The
This patch has now been backported to openacc-gcc-9-branch (git).
Andre
On 01/07/2019 12:16, Andrew Stubbs wrote:
Improve OpenMP map diagnostics.
2019-07-01 Andrew Stubbs
gcc/cp/
* cp-tree.h (cp_omp_emit_unmappable_type_notes): New prototype.
* decl.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91062
Richard Biener changed:
What|Removed |Added
Known to work||10.0
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91062
--- Comment #5 from Richard Biener ---
Author: rguenth
Date: Thu Jul 4 13:56:12 2019
New Revision: 273083
URL: https://gcc.gnu.org/viewcvs?rev=273083=gcc=rev
Log:
2019-07-04 Richard Biener
PR ipa/91062
* tree-pass.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90911
--- Comment #3 from Richard Biener ---
Author: rguenth
Date: Thu Jul 4 13:55:15 2019
New Revision: 273082
URL: https://gcc.gnu.org/viewcvs?rev=273082=gcc=rev
Log:
2019-07-04 Richard Biener
PR tree-optimization/90911
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90911
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 90911, which changed state.
Bug 90911 Summary: [10 Regression] 456.hmmer regression with r272239
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90911
What|Removed |Added
> checked in. Ok for the gcc-9 branch as well?
Yes.
On 04.07.19 08:50, Arnaud Charlet wrote:
> OK, thanks.
checked in. Ok for the gcc-9 branch as well?
Matthias
>> From: James Clarke
>>
>> Monotonic_Clock and RT_Resolution in the recently-added s-tpopmo.adb
>> call clock_gettime/clock_getres with the integral constants from OSC and
>> thus rely
Hi all,
The 8th HelloLLVM / HelloGCC social in China will happen on July 20, 2019.
The location is at Hangzhou.
Everyone interested in LLVM/GCC Toolchain related projects is invited to join.
Event details is at https://mp.weixin.qq.com/s/qK9V62atBpXyTKNP_J7A8Q
Presentations are welcome :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90756
--- Comment #16 from Mike Hommey ---
Similar ICE with 7.3.
Hi,
On 27/06/19 23:19, Jason Merrill wrote:
Ah, thanks. Then perhaps we want to change the CLASSTYPE_FINAL in
build_over_call to resolves_to_fixed_type_p (arg), to also handle the
other reasons we might know the dynamic type of the argument, and
remove the related code from
>
> Why does this only happen in fre3?!
After fre1 we have
test (int i, int j, int k, int l)
{
struct c * cptr.0_1;
struct c * cptr2.1_2;
int _11;
:
cptr.0_1 = cptr;
cptr.0_1->b[i_5(D)].a[j_6(D)].val = 123;
cptr2.1_2 = cptr2;
cptr2.1_2->b[k_8(D)].a2[l_9(D)].val = 2;
_11 =
> I don't have commit access so could you please do so on my behalf?
No, I won't be able to do that unfortunately.
By the way do you have a copyright assignment in place?
Arno
The attached patch allows the case of register names used in an asm statement
clobber list to be disregarded when checking the validity of the register names.
Currently, the register name used in asm statement clobber list must exactly
match those defined in the targets REGISTER_NAMES macro.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91077
--- Comment #5 from Dominique d'Humieres ---
The failure of the test in comment 4 is a different issue, likely
caused/exposed by revision r269962.
> On Tue, 25 Jun 2019, Richard Biener wrote:
>
> >
> > PR90911 reports a slowdown of 456.hmmer with the recent introduction
> > of vectorizer versioning of outer loops, more specifically the case
> > of re-using if-conversion created versions.
> >
> > The patch below fixes things up to adjust
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #32 from dave.anglin at bell dot net ---
On 2019-07-03 9:08 p.m., elowe at elowe dot com wrote:
> This macro only seems to control whether you use ltoffx or ltoff.
>
> I can confirm I am using bash, and #define
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89330
--- Comment #11 from Martin Liška ---
(In reply to Martin Jambor from comment #10)
> Created attachment 46544 [details]
> WIP patch
>
> I have written another patch that removes the edges from the vector at
> the time speculation is resolved
>
> The following avoids GC collecting during pass execution when a pass
> calls cgraph::get_body.
>
> Bootstrapped / tested on x86_64-unknown-linux-gnu.
>
> OK?
>
> Thanks,
> Richard.
>
> 2019-07-03 Richard Biener
>
> PR ipa/91062
> * tree-pass.h (execute_all_ipa_transforms):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91050
--- Comment #9 from Alan Modra ---
Created attachment 46556
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46556=edit
more assembler command line fixes
Another one for targets that default to altivec.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91050
--- Comment #8 from Alan Modra ---
Created attachment 46555
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46555=edit
assembler command line fixes
I'll happily handle the assembler command line problems. Here's a lightly
tested patch.
On 03/07/2019 18:58, Jason Merrill wrote:
OK, thanks.
Committed.
Thanks for the reviews.
Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91078
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91078
--- Comment #4 from Martin Liška ---
Author: marxin
Date: Thu Jul 4 11:38:28 2019
New Revision: 273077
URL: https://gcc.gnu.org/viewcvs?rev=273077=gcc=rev
Log:
Fix loading of lto_section on strict alignment targets (PR lto/91078).
2019-07-04
Implicit function declarations were removed from C99, more than twenty
years ago. So far, GCC only warns about them because there were too
many old configure scripts where an error would lead to incorrect
configure check failures.
I can try to fix the remaining configure scripts in Fedora and
I don't have commit access so could you please do so on my behalf?
This bug applies to the 9 branch too, so please consider backporting it.
Thanks,
James
> On 4 Jul 2019, at 07:50, Arnaud Charlet wrote:
>
> OK, thanks.
>
>> From: James Clarke
>>
>> Monotonic_Clock and RT_Resolution in the
1 - 100 of 171 matches
Mail list logo
