On Tue, Oct 9, 2018 at 1:53 PM Joseph Myers wrote:
>
> On Tue, 9 Oct 2018, Richard Biener wrote:
>
> > It was repeatedly suggested that we _could_ derive alignment info from
> > function parameter types since we rely on precise typing there for example
> > for points-to analysis (albeit only for
On Tue, 9 Oct 2018, Richard Biener wrote:
> It was repeatedly suggested that we _could_ derive alignment info from
> function parameter types since we rely on precise typing there for example
> for points-to analysis (albeit only for restrict qualification processing and
> for DECL_BY_REFERENCE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63155
--- Comment #45 from Richard Biener ---
Author: rguenth
Date: Tue Oct 9 11:43:46 2018
New Revision: 264956
URL: https://gcc.gnu.org/viewcvs?rev=264956=gcc=rev
Log:
2018-10-09 Richard Biener
PR tree-optimization/63155
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77698
Martin Liška changed:
What|Removed |Added
Status|REOPENED|ASSIGNED
--- Comment #6 from Martin
Hi Eric,
>> Besides, the patch seems to have produced more fallout on Solaris: I see
>> many new Go testsuite failures on Solaris 10 which probably are related,
>> and Solaris bootstrap with Ada included is broken due to the extended
>> usage of string merging. I'm currently investigating what's
This helps us throw away constraints from uninitialized stuff earlier.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2018-10-09 Richard Biener
PR tree-optimization/63155
* tree-ssa-structalias.c: Include tree-ssa.h.
On 10/9/18 11:03 AM, Rainer Orth wrote:
> Hi Martin,
>
>> rename from gcc/testsuite/g++.dg/ext/pr82625.C
>> rename to gcc/testsuite/g++.target/i386/pr82625.C
>> index 59b174f8c51..0eb70baed5e 100644
>> --- a/gcc/testsuite/g++.dg/ext/pr82625.C
>> +++ b/gcc/testsuite/g++.target/i386/pr82625.C
>> @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 87564, which changed state.
Bug 87564 Summary: Missing -Wuninitialized with -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87564
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87564
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87544
--- Comment #10 from Marc Glisse ---
(In reply to Jonathan Wakely from comment #9)
> Do we want something like this as well? (and for malloc_allocator too)
I think so. Changing allocator_traits as LWG seems likely to agree won't help
much until
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87551
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> ---
>> --- Comment #1 from Bernd Edlinger ---
>> Rainer, can you try this?
>
> Looks good so far: an
Committed as obvious.
Richard.
2018-10-09 Richard Biener
* tree-vectorizer.c (dump_stmt_cost): Fix cut missing
replacements.
diff --git a/gcc/tree-vectorizer.c b/gcc/tree-vectorizer.c
index 0ab366b79a3..60ee7f6380c 100644
--- a/gcc/tree-vectorizer.c
+++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87561
--- Comment #2 from Richard Biener ---
OK, so on haswell I see (- is bad, + is good):
-0x2342ca0 _40 + _45 1 times scalar_stmt costs 12 in body
+0x2342ca0 _40 + _45 1 times scalar_stmt costs 4 in body
so a simple add changes cost from 4 to 12
On 09/10/18 07:25 +0200, François Dumont wrote:
As we talked one day I would like to make all iterator operators
global for consistency. So here is the patch to do so for std::list
iterators.
By "global" you mean "non-member", right?
Thanks to this change the operators ==(iterator,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57832
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85870
--- Comment #8 from Ramana Radhakrishnan ---
(In reply to Martin Liška from comment #5)
> (In reply to Ramana Radhakrishnan from comment #4)
> > (In reply to Martin Liška from comment #3)
> > > Can't reproduce with GCC 7.3.0 on x86_64:
> > >
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85870
--- Comment #7 from sudi at gcc dot gnu.org ---
It is not failing on x86_64 trunk anymore but with 8.0.1
+ TARGET=x86_64-pc-linux-gnu
+ GCC_INSTALL=/work/x86-trunk/bld
+ GCC=/work/x86-trunk/bld/bin/x86_64-pc-linux-gnu-gcc-8.0.1
+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87544
--- Comment #9 from Jonathan Wakely ---
Do we want something like this as well? (and for malloc_allocator too)
--- a/libstdc++-v3/include/ext/new_allocator.h
+++ b/libstdc++-v3/include/ext/new_allocator.h
@@ -130,7 +130,13 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85870
--- Comment #6 from sudi at gcc dot gnu.org ---
Still fails for me on aarch64-none-linux-gnu-gcc and aarch64-none-elf-gcc on
trunk and gcc-8.2.1 with the same error
Reading object files: test_1.o test_2.olto1: internal compiler error: in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85114
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87564
Bug ID: 87564
Summary: Missing -Wuninitialized with -O0
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87563
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
CC||ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84487
--- Comment #9 from Martin Liška ---
Can please anybody from Fotran community dig into this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85114
Martin Liška changed:
What|Removed |Added
Keywords|needs-reduction |
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85870
--- Comment #5 from Martin Liška ---
(In reply to Ramana Radhakrishnan from comment #4)
> (In reply to Martin Liška from comment #3)
> > Can't reproduce with GCC 7.3.0 on x86_64:
> >
> > + gcc-7 -O2 -flto -c test_1.i -o test_1.o
> > + gcc-7 -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85870
Ramana Radhakrishnan changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #4 from Ramana
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85870
Martin Liška changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #3 from Martin Liška
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84191
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
Known to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87553
--- Comment #9 from Martin Liška ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #8)
> > --- Comment #7 from Martin Liška ---
> [...]
> > You can use gcov-dump -l to dump content of the files. However, it's not
> > problem as the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87562
--- Comment #1 from David Malcolm ---
linemap_position_for_line_and_column(line_maps*, line_map_ordinary const*,
unsigned int, unsigned int) at libcpp/line-map.c:848
is:
linemap_assert (ORDINARY_MAP_STARTING_LINE_NUMBER (ord_map) <= line);
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87547
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87559
--- Comment #4 from Jonathan Wakely ---
Yes. Started to ICE with r253266 and was fixed by r261121.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87563
Ramana Radhakrishnan changed:
What|Removed |Added
Target||aarch64-none-elf
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87563
Ramana Radhakrishnan changed:
What|Removed |Added
Keywords||ice-on-valid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87563
Bug ID: 87563
Summary: [9 regression ] ICE with -march=armv8-a+sve
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87559
--- Comment #3 from Jakub Jelinek ---
Yeah. I think it is r261121 aka PR85761 that fixed the ICE.
Wonder if it would be useful to add the #c1 testcase into testsuite or if
lambda-const8.C is close enough that it covers it.
Hi,
gently pinging the below...
On 29/09/18 21:27, Paolo Carlini wrote:
Hi again,
On 9/28/18 9:15 PM, Paolo Carlini wrote:
Thanks. About the location, you are certainly right, but doesn't seem
trivial. Something we can do *now* is using
declspecs->locations[ds_typedef] and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87559
--- Comment #2 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #1)
> But GCC 8 gets them all right
8.1 crashes with an ICE (which makes bisection hard), 8.2 gets them right.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58787
--- Comment #14 from Jürgen Reuter ---
(In reply to Dominique d'Humieres from comment #13)
> > (null):0: confused by earlier errors, bailing out
>
> Your compiler is configured with --enable-checking=release (either
> explicitly or because your
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58787
--- Comment #13 from Dominique d'Humieres ---
> (null):0: confused by earlier errors, bailing out
Your compiler is configured with --enable-checking=release (either explicitly
or because your are using a release). The above message is the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87553
--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #7 from Martin Liška ---
[...]
> You can use gcov-dump -l to dump content of the files. However, it's not
> problem as the file exists. The warning should be only shown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87559
--- Comment #1 from Jonathan Wakely ---
Any gcc bugs seem to be fixed in current trunk. As a single testcase:
extern "C" int puts(const char*);
constexpr char top_doc[] = "";
void f1() {
constexpr auto& doc = top_doc;
[](int) { puts(doc);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58787
--- Comment #12 from Jürgen Reuter ---
(In reply to Dominique d'Humieres from comment #11)
> > I can confirm that this ICEs on Linux, but not on MACOSX.
>
> I get the ICE with MACOSX:
>
> ...
> Error: Expecting END SUBROUTINE statement at (1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58787
--- Comment #11 from Dominique d'Humieres ---
> I can confirm that this ICEs on Linux, but not on MACOSX.
I get the ICE with MACOSX:
...
Error: Expecting END SUBROUTINE statement at (1)
f951: internal compiler error: Segmentation fault: 11
On 10/09/2018 04:59 AM, Alexandre Oliva wrote:
> On Oct 5, 2018, Joseph Myers wrote:
>
>> A new configure option needs documenting in install.texi.
>
> Ah, yes, thanks for the reminder.
>
> On Oct 6, 2018, JonY <10wa...@gmail.com> wrote:
>
>> They're both OK as far as I can see. I just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86576
--- Comment #4 from Paul Thomas ---
(In reply to Dominique d'Humieres from comment #3)
> AFAICT the test in comment 2 has been fixed between revisions r264451
> (2018-09-20) and r264486 (2018-09-21), may be r264485 (pr87359).
Unfortunately, the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58787
Jürgen Reuter changed:
What|Removed |Added
CC||juergen.reuter at desy dot de
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86576
Dominique d'Humieres changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
---
On Tue, Oct 9, 2018 at 11:23 AM Jakub Jelinek wrote:
>
> On Tue, Oct 09, 2018 at 11:08:44AM +0200, Richard Biener wrote:
> > On Tue, Oct 9, 2018 at 11:00 AM Alexander Monakov
> > wrote:
> > >
> > > On Tue, 9 Oct 2018, Richard Biener wrote:
> > > >
> > > > then we cannot set the alignment of i_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63155
--- Comment #44 from Richard Biener ---
(In reply to Richard Biener from comment #43)
> This makes CCP the main
> offender again but as said the rectification would probably mean pulling
> back the SSA SCC discovery code from SCCVN and use that
On Tue, Oct 09, 2018 at 11:08:44AM +0200, Richard Biener wrote:
> On Tue, Oct 9, 2018 at 11:00 AM Alexander Monakov wrote:
> >
> > On Tue, 9 Oct 2018, Richard Biener wrote:
> > >
> > > then we cannot set the alignment of i_1 at/after k = *i_1 because doing
> > > so would
> > > affect the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87410
Martin Liška changed:
What|Removed |Added
Keywords||ice-on-valid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55735
--- Comment #10 from Jürgen Reuter ---
Interestingly, nagfor rejects this code with the message "Inconsistent
definitions of COMMON block FOO in program-units $block and BAR". Both ifort
and pgfortran compile the code, and the program issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87561
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-*, i?86-*-*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86740
Martin Liška changed:
What|Removed |Added
Keywords|needs-reduction |
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87562
Bug ID: 87562
Summary: ICE in in linemap_position_for_line_and_column, at
libcpp/line-map.c:848
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87562
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |9.0
Summary|ICE
On Tue, Oct 9, 2018 at 11:00 AM Alexander Monakov wrote:
>
> On Tue, 9 Oct 2018, Richard Biener wrote:
> >
> > then we cannot set the alignment of i_1 at/after k = *i_1 because doing so
> > would
> > affect the alignment test which we'd then optimize away. We'd need to
> > introduce
> > a SSA
Hi Martin,
> rename from gcc/testsuite/g++.dg/ext/pr82625.C
> rename to gcc/testsuite/g++.target/i386/pr82625.C
> index 59b174f8c51..0eb70baed5e 100644
> --- a/gcc/testsuite/g++.dg/ext/pr82625.C
> +++ b/gcc/testsuite/g++.target/i386/pr82625.C
> @@ -1,7 +1,7 @@
> /* { dg-do compile } */
> /* {
On Tue, 9 Oct 2018, Richard Biener wrote:
>
> then we cannot set the alignment of i_1 at/after k = *i_1 because doing so
> would
> affect the alignment test which we'd then optimize away. We'd need to
> introduce
> a SSA copy to get a new SSA name but that would be optimized away quickly.
We
Hi.
There's another move of C++ tests, this time these that have dg-require-ifunc.
Key question is whether we want to make subfolders for i386 tests (ext, other,
..)?
Survives make check -k RUNTESTFLAGS="i386.exp"
Martin
>From d36db4d5b8306dcbe2d63762bc8596e05132e46a Mon Sep 17 00:00:00 2001
On 09/10/2018 09:27, Mihail Ionescu wrote:
> Hi all,
>
> This patch removes some of the machine mode checks from the arm backend when
> emitting instructions by using the '@' construct (Parameterized Names[2]). It
> is based on the previous AArch64 patch[1].
>
>
> It was repeatedly suggested that we _could_ derive alignment info from
> function parameter types since we rely on precise typing there for example
> for points-to analysis (albeit only for restrict qualification processing
> and for DECL_BY_REFERENCE "pointers"). That would fix the simple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87561
Bug ID: 87561
Summary: [9 Regression] 416.gamess is slower by ~10% starting
from r264866 with -Ofast
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55735
--- Comment #9 from Paul Thomas ---
(In reply to Jürgen Reuter from comment #7)
> Ah sorry, I think I moved around the block data and then it wasn't valid
> Fortran anymore. I think, both the block data and the subroutine are
> external to the
On Tue, Oct 9, 2018 at 10:02 AM Andrew Haley wrote:
>
> On 10/08/2018 07:38 PM, Paul Koning wrote:
> >
> >
> >> On Oct 8, 2018, at 1:29 PM, Andrew Haley wrote:
> >>
> >> On 10/08/2018 06:20 PM, Michael Matz wrote:
> >>> Only if you somewhere visibly add accesses to *i and *j. Without them you
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55735
--- Comment #8 from Paul Thomas ---
(In reply to Jürgen Reuter from comment #7)
> Ah sorry, I think I moved around the block data and then it wasn't valid
> Fortran anymore. I think, both the block data and the subroutine are
> external to the
PING^1
On 9/26/18 11:33 AM, Martin Liška wrote:
> On 9/25/18 5:53 PM, Jakub Jelinek wrote:
>> On Tue, Sep 25, 2018 at 05:26:44PM +0200, Martin Liška wrote:
>>> The only missing piece is how to implement asan_emit_redzone_payload more
>>> smart.
>>> It means doing memory stores with 8,4,2,1 sizes
On Tue, Oct 9, 2018 at 8:41 AM Eric Botcazou wrote:
>
> > It's not quite obvious what SSE has to do with this - any hint please?
>
> SSE introduced alignment constraints into the non-strict-alignment target x86
> so people didn't really want to play by the rules of strict-alignment targets.
On Thu, Sep 27, 2018 at 10:55:10AM +0200, Martin Liška wrote:
> @@ -1281,15 +1284,30 @@ asan_emit_stack_protection (rtx base, rtx pbase,
> unsigned int alignb,
>pp_space (_pp);
>pp_wide_integer (_pp, offsets[l - 1] - offsets[l]);
>pp_space (_pp);
> +
> +
Hi.
Utilizing rtags' --find-dead-functions I'm suggesting a removal of part
of the functions reported with the script. I built all cross compilers
defined in contrib/config-list.mk and I fixed VMS targets that I broke
in previous removal.
If the folks are happy with the removal, I can probably
PING^1
On 9/27/18 10:55 AM, Martin Liška wrote:
> Hi.
>
> I've noticed ASAN can inform user about location of stack variables
> when a stack violation is detected.
>
> Sample example:
>
> ...
> This frame has 3 object(s):
> [32, 36) 'counter' (line 3) <== Memory access at offset 36
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63155
--- Comment #43 from Richard Biener ---
We're now down to
tree PTA : 3.92 ( 16%) 0.12 ( 36%) 4.02 ( 16%)
12445 kB ( 2%)
tree CCP : 7.43 ( 30%) 0.02 ( 6%) 7.44 ( 29%)
646
On 10/08/2018 07:38 PM, Paul Koning wrote:
>
>
>> On Oct 8, 2018, at 1:29 PM, Andrew Haley wrote:
>>
>> On 10/08/2018 06:20 PM, Michael Matz wrote:
>>> Only if you somewhere visibly add accesses to *i and *j. Without them you
>>> only have the "accesses" via memcpy, and as Richi says, those
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80931
--- Comment #9 from Paul Thomas ---
Author: pault
Date: Tue Oct 9 07:46:48 2018
New Revision: 264949
URL: https://gcc.gnu.org/viewcvs?rev=264949=gcc=rev
Log:
2018-10-09 Paul Thomas
PR fortran/87151
* trans-array.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87151
--- Comment #5 from Paul Thomas ---
Author: pault
Date: Tue Oct 9 07:46:48 2018
New Revision: 264949
URL: https://gcc.gnu.org/viewcvs?rev=264949=gcc=rev
Log:
2018-10-09 Paul Thomas
PR fortran/87151
* trans-array.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87550
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87557
--- Comment #2 from Martin Liška ---
Yes, but I forgot to move the file to newly created
./gcc/testsuite/g++.target/i386/
I'll do that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87554
Martin Liška changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87560
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87557
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
On Tue, 9 Oct 2018, Tamar Christina wrote:
> Hi All,
>
> I'm looking for permission to backport this patch to the GCC-8 branch
> to fix PR86486.
>
> OK for backport?
This doesn't seem to fix a regression and it's been on trunk only
for a few days.
Richard.
> Thanks,
> Tamar
>
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87553
--- Comment #7 from Martin Liška ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #6)
> > --- Comment #5 from Martin Liška ---
> [...]
> >> Sorry, I've been doing too many things at once and not been paying close
> >> enough
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86383
--- Comment #9 from Martin Liška ---
Any progress on that please?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87554
--- Comment #4 from Martin Liška ---
I'm reducing that ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87560
Bug ID: 87560
Summary: ICE in curr_insn_transform, at lra-constraints.c:3892
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Resend to gcc@gcc.gnu.org to avoid spam filter
> From: Michael Matz
> > Sent: 07 October 2018 16:53
> ...
> > I think the examples I saw from Boris were all indirect inlines:
> >
> > static inline void foo() { asm("large-looking-but-small-asm"); }
> > static void bar1() { ... foo() ... }
> >
> It's not quite obvious what SSE has to do with this - any hint please?
SSE introduced alignment constraints into the non-strict-alignment target x86
so people didn't really want to play by the rules of strict-alignment targets.
> (according to my quick check this changed between gcc-4.5 and
Hi All,
I'm looking for permission to backport this patch to the GCC-8 branch
to fix PR86486.
OK for backport?
Thanks,
Tamar
> -Original Message-
> From: Jeff Law
> Sent: Friday, August 3, 2018 19:03
> To: Tamar Christina ; Joseph Myers
>
> Cc: gcc-patches@gcc.gnu.org; nd ;
Hi All,
I'm looking for permission to backport this patch to the GCC-8 branch
to fix PR86486.
OK for backport?
Thanks,
Tamar
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org
> On Behalf Of Tamar Christina
> Sent: Friday, September 28, 2018 17:36
> To: Jeff Law ;
Hi All,
I'm looking for permission to backport this patch to the GCC-8 branch
to fix PR86486.
OK for backport?
Thanks,
Tamar
> -Original Message-
> From: James Greenhalgh
> Sent: Tuesday, July 31, 2018 22:02
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
>
Hi All,
I'm looking for permission to backport this patch to the GCC-8 branch
to fix PR86486.
OK for backport?
Thanks,
Tamar
> -Original Message-
> From: Jeff Law
> Sent: Wednesday, July 11, 2018 19:53
> To: Tamar Christina ; gcc-patches@gcc.gnu.org
> Cc: nd ; rguent...@suse.de;
Hi All,
I'm looking for permission to backport this patch to the GCC-8 branch
to fix PR86486.
OK for backport?
Thanks,
Tamar
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org
> On Behalf Of Tamar Christina
> Sent: Wednesday, September 26, 2018 09:30
> To:
Hi All,
I'm looking for permission to backport this patch to the GCC-8 branch
to fix PR86486.
OK for backport?
Thanks,
Tamar
> -Original Message-
> From: James Greenhalgh
> Sent: Tuesday, August 7, 2018 17:18
> To: Tamar Christina
> Cc: Jeff Law ; gcc-patches@gcc.gnu.org; nd
> ;
Hi All,
I'm looking for permission to backport this patch to the GCC-8 branch
to fix PR86486.
OK for backport?
Thanks,
Tamar
> -Original Message-
> From: James Greenhalgh
> Sent: Tuesday, September 11, 2018 16:56
> To: Tamar Christina
> Cc: Richard Sandiford ; Jeff Law
> ;
Hi All,
I'm looking for permission to backport this patch to the GCC-8 branch
to fix PR86486.
OK for backport?
Thanks,
Tamar
> -Original Message-
> From: Richard Sandiford
> Sent: Friday, September 28, 2018 18:18
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; James
101 - 196 of 196 matches
Mail list logo
