https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490
Andy Lutomirski changed:
What|Removed |Added
CC||luto at kernel dot org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490
--- Comment #7 from H. Peter Anvin ---
Thinking about this some more, this is really not an aspect of __seg_* but
rather the section the symbol is placed in. An embedded system kernel, for
example, could quite possibly want to access an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490
--- Comment #6 from H. Peter Anvin ---
It is probably inappropriate to generate non-absolute address references for
these symbols for any kind of PIC or PIE output (as that would require unwanted
relocation!), so #2 is probably not really
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490
--- Comment #5 from H. Peter Anvin ---
The test case was compiled with:
gcc -fno-plt -fpie -fvisibility=hidden -mcmodel=small -O2
(note: no code changes between -fpie and -fpic)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490
--- Comment #4 from H. Peter Anvin ---
Created attachment 41801
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41801=edit
Test case: assembly output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490
--- Comment #3 from H. Peter Anvin ---
Created attachment 41800
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41800=edit
Test case: preprocessor output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490
--- Comment #2 from H. Peter Anvin ---
Created attachment 41799
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41799=edit
Test case: object file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490
--- Comment #1 from H. Peter Anvin ---
Created attachment 41798
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41798=edit
Test case: source code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490
Bug ID: 81490
Summary: x86: Handling of symbol ranges for __seg_fs/__seg_gs
Product: gcc
Version: 6.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65254
egallager at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81317
--- Comment #22 from Randy MacLeod ---
Yes, the host is an x86-64-linux system running Ubuntu-16.04.1.
The cross-compiler was built using the Open Embedded (OE) build system so of
course, it's not part of Ubuntu.
I did get a better backtrace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49582
egallager at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81478
--- Comment #6 from Sean McAllister ---
FWIW, it seems the compute, check, re-compute if necessary is what clang does.
Rather than "setp %al" and "jne" on that, they just use the "jp" instruction
directly after ucomiss:
0x004005d5
Snapshot gcc-6-20170719 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/6-20170719/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 6 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48097
egallager at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |SUSPENDED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69601
egallager at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69818
egallager at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81317
--- Comment #21 from Segher Boessenkool ---
Hrm, those ?? are a bit worrying, is that normal on x86_64-linux
(that is what this is, as host?)
I also don't see line numbers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25470
egallager at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63773
egallager at gcc dot gnu.org changed:
What|Removed |Added
CC||egallager at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65294
egallager at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last
On 07/19/2017 11:53 AM, Wilco Dijkstra wrote:
> Hi Jeff,
>
> There is an issue with your AArch64 patch, it fails to apply properly and does
> so silently using 'patch'. I also noticed some odd control characters in the
> other
> patches, but they didn't appear to fail (or at least everything
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81193
--- Comment #15 from Michael Meissner ---
Author: meissner
Date: Wed Jul 19 22:05:20 2017
New Revision: 250371
URL: https://gcc.gnu.org/viewcvs?rev=250371=gcc=rev
Log:
[gcc]
2017-07-19 Michael Meissner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62273
egallager at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81489
--- Comment #3 from Tom de Vries ---
Created attachment 41797
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41797=edit
Patch with more strict checking in gimple_phi_arg, bootstrapped and reg-tested
This is the patch with which this PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57607
egallager at gcc dot gnu.org changed:
What|Removed |Added
CC||egallager at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81489
--- Comment #2 from Tom de Vries ---
Created attachment 41796
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41796=edit
Patch, bootstrapped and reg-tested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81489
--- Comment #1 from Tom de Vries ---
Created attachment 41795
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41795=edit
trigger and assert patch
This patch uses the bit that makes the bug easier to trigger, and adds an
assert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81489
Bug ID: 81489
Summary: invalid phi argument used in
find_implicit_erroneous_behavior
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81463
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
Hi Steve,
On Wed, Jul 19, 2017 at 10:14:01AM -0500, Steven Munroe wrote:
> This it part 2/2 for contributing PPC64LE support for X86 MMX
> instrisics. This patch adds the DG tests to verify the headers contents.
> Oddly there are very few MMX specific included in i386 so I had to adapt
> some the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53905
egallager at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81331
Jan Hubicka changed:
What|Removed |Added
Summary|[8 Regression] FAIL:|[5/6/7 Regression] missed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81331
--- Comment #13 from Jan Hubicka ---
Author: hubicka
Date: Wed Jul 19 21:06:55 2017
New Revision: 250370
URL: https://gcc.gnu.org/viewcvs?rev=250370=gcc=rev
Log:
PR middle-end/81331
* except.c (execute): Fix ordering issue.
On Wed, Jul 19, 2017 at 8:19 PM, Alexander Monakov wrote:
> On Wed, 19 Jul 2017, Yuri Gribov wrote:
>> So to reiterate, your logic here is that someone would wipe dlsym type
>> (e.g. by casting to void *), then later cast to another type which
>> lacks tailcall attribute. So
Here is the revisited version passing all tests successfully except 2
that are also failing without the patch:
FAIL: 21_strings/basic_string/modifiers/insert/char/1.cc execution test
FAIL: 21_strings/basic_string/modifiers/insert/wchar_t/1.cc execution test
This is a rather mechanical change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80969
--- Comment #4 from Daniel Santos ---
Created attachment 41794
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41794=edit
proposed fix (still needs cleanup and tests)
This still needs cleanup and tests as well as some explanations, but it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81354
Bill Schmidt changed:
What|Removed |Added
Target|x86_64-pc-linux-gnu |x86_64-pc-linux-gnu,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81393
Ian Lance Taylor changed:
What|Removed |Added
Attachment #41791|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81476
--- Comment #17 from Marc Glisse ---
(In reply to Jonathan Wakely from comment #14)
> The advantage of doing it as in comment 13, rather than:
> [comment #11]
> is that when inserting the inputrange causes reallocations we only have to
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81318
Yury Gribov changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81317
--- Comment #20 from Randy MacLeod ---
I can try! ;) How's this:
$ gdb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81193
--- Comment #14 from Michael Meissner ---
Author: meissner
Date: Wed Jul 19 20:31:53 2017
New Revision: 250368
URL: https://gcc.gnu.org/viewcvs?rev=250368=gcc=rev
Log:
[gcc]
2017-07-19 Michael Meissner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81393
--- Comment #10 from Jakub Jelinek ---
https://kojipkgs.fedoraproject.org//work/tasks/6506/20616506/build.log
That fails to build:
../../../../libgo/go/syscall/syscall_linux_s390.go:28:33: error: reference to
undefined name 'regs'
On Wed, 19 Jul 2017, Alexander Monakov wrote:
> > The one and only advantage of attribute compared to Jakubs approach
> > (or yours, they share the same idea of wrapping dlsym calls) is that
> > it forces user to carry it around when taking address of function.
>
> It's an inconvenience. People
On Wed, 19 Jul 2017, Jonathan Wakely wrote:
The PR shows a fairly pathological case where ranges of InputIterators
are repeatedly inserted at the start of a vector. Each insertion from
an InputIterator moves every element after the insertion point by a
single position. So if we insert 1000
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81147
--- Comment #6 from Felipe Magno de Almeida ---
NRVO: Named Return Value Optimization
RVO: Return Value Optiomization
It is the eliminiation of copying when returning objects by value (or passed
by-value as parameters for rvalues).
The
On Wed, 19 Jul 2017, Jakub Jelinek wrote:
>> This fixes it. Okay to apply to GCC?
> Ok, thanks.
Thanks for the quick response, Jakub!
> glibc uses u_int32_t in all the places of *powl.c where libquadmath
> uses uint32_t, and various other files, so I guess it is intentional.
Ah, I see. I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81476
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81318
--- Comment #10 from David Binderman ---
I am not so sure this one is fixed.
I have this code:
__attribute__((__cold__)) a();
b() { a(); }
c() {
b();
if (d())
e();
}
derived from Linux kernel and it does this with revision 250361:
The PR shows a fairly pathological case where ranges of InputIterators
are repeatedly inserted at the start of a vector. Each insertion from
an InputIterator moves every element after the insertion point by a
single position. So if we insert 1000 elements at the start we move
each existing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51063
egallager at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25537
egallager at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81354
--- Comment #6 from Bill Schmidt ---
Hm, the symptom looks very much like another issue I've been looking at on
trunk. There may be an issue with the statement->candidate mapping hash table
that's responsible for both. It appears to be a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81484
--- Comment #5 from Arnd Bergmann ---
(In reply to Marek Polacek from comment #4)
> (In reply to Arnd Bergmann from comment #3)
> > It seems I got a little confused when I only looked at the initial patch
> > that was proposed, which was
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37041
egallager at gcc dot gnu.org changed:
What|Removed |Added
CC||gdr at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21759
egallager at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
On Wed, Jul 19, 2017 at 08:57:02AM +0200, Martin Liška wrote:
> On 07/18/2017 04:49 PM, Segher Boessenkool wrote:
> >On Tue, Jul 18, 2017 at 12:49:06PM +0200, Martin Liška wrote:
> >>Solved, tail call was responsible for dead RTL instructions.
> >
> >This seems similar to
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37704
egallager at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48839
egallager at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81317
--- Comment #19 from Segher Boessenkool ---
(In reply to Randy MacLeod from comment #18)
> 2. The "smaller reproducer with manual work-around " DOES STILL result in an
> ICE as does the libjpeg-turbo build as you'd expect.
I still cannot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36994
egallager at gcc dot gnu.org changed:
What|Removed |Added
Target|any |
On Wed, Jul 19, 2017 at 09:35:36PM +0200, Gerald Pfeifer wrote:
> Hi Jakub,
>
> r250343 | jakub | 2017-07-19 13:12:58 + (Wed, 19 Jul 2017) | 48 lines
>
> PR libquadmath/65757
> * quadmath-imp.h (math_opt_barrier, math_force_eval,
> math_narrow_eval,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81423
--- Comment #8 from Segher Boessenkool ---
Author: segher
Date: Wed Jul 19 19:31:26 2017
New Revision: 250365
URL: https://gcc.gnu.org/viewcvs?rev=250365=gcc=rev
Log:
combine: Fix for PR81423
We here have an AND of a SUBREG of an LSHIFTRT. If
Hi Jakub,
r250343 | jakub | 2017-07-19 13:12:58 + (Wed, 19 Jul 2017) | 48 lines
PR libquadmath/65757
* quadmath-imp.h (math_opt_barrier, math_force_eval,
math_narrow_eval, math_check_force_underflow,
math_check_force_underflow_nonneg): Define.
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81476
--- Comment #15 from Jonathan Wakely ---
Author: redi
Date: Wed Jul 19 19:32:15 2017
New Revision: 250366
URL: https://gcc.gnu.org/viewcvs?rev=250366=gcc=rev
Log:
PR libstdc++/81476 Optimise vector insertion from input iterators
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81423
--- Comment #7 from Segher Boessenkool ---
Author: segher
Date: Wed Jul 19 19:28:41 2017
New Revision: 250363
URL: https://gcc.gnu.org/viewcvs?rev=250363=gcc=rev
Log:
simplify-rtx: The truncation of an IOR can have all bits set (PR81423)
...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81478
--- Comment #5 from Sean McAllister ---
(In reply to Richard Biener from comment #3)
> Confirmed. It shouldn't be very difficult to do,
> gcc/tree-complex.c:expand_complex_multiplication would need to emit if
> (isnan(rr) || isnan(ri)) .
>
>
On Wed, Jul 19, 2017 at 12:33:03PM -0500, Segher Boessenkool wrote:
> On Tue, Jul 18, 2017 at 04:24:47PM -0400, Michael Meissner wrote:
> > This patch modifies the change I made on July 12th. It modifies the test
> > for
> > the __builtin_cpu_is and __builtin_cpu_supports built-in functions to
On Wed, 19 Jul 2017, Yuri Gribov wrote:
> So to reiterate, your logic here is that someone would wipe dlsym type
> (e.g. by casting to void *), then later cast to another type which
> lacks tailcall attribute. So proposed solution won't protect against
> situation like this.
No, it's not "my
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81324
--- Comment #4 from Segher Boessenkool ---
That works fine. Thanks Ian!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81488
Bug ID: 81488
Summary: gcc goes off the limits allocating memory in
gimple-ssa-strength-reduction.c
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50909
egallager at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81487
Bug ID: 81487
Summary: [mingw32] ld.exe: error: asprintf failed
Product: gcc
Version: 7.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
On Wed, Jul 19, 2017 at 12:19:32AM -0600, Jeff Law wrote:
> On 07/18/2017 01:36 PM, Segher Boessenkool wrote:
> > ... if it is an IOR with a constant with all bits set in the mode
> > that is truncated to, for example. Handle that case.
> >
> > With this patch the problematic situation for the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
egallager at gcc dot gnu.org changed:
What|Removed |Added
CC||j.d.pryce at ntlworld dot
On 7/19/17, Yuri Gribov wrote:
> On Wed, Jul 19, 2017 at 7:15 PM, Eric Gallager
> wrote:
>> On 7/18/17, Yuri Gribov wrote:
>>> On Tue, Jul 18, 2017 at 3:54 PM, Martin Sebor wrote:
On 07/17/2017 02:25 PM,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34261
egallager at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
On Wed, Jul 19, 2017 at 7:15 PM, Eric Gallager wrote:
> On 7/18/17, Yuri Gribov wrote:
>> On Tue, Jul 18, 2017 at 3:54 PM, Martin Sebor wrote:
>>> On 07/17/2017 02:25 PM, Yuri Gribov wrote:
On Mon, Jul 17, 2017 at 4:23 PM,
On 19 July 2017 at 19:15, Eric Gallager wrote:
> On 7/18/17, Yuri Gribov wrote:
>> Jonathan also mentioned something not immediately obvious in IRC:
>> logging into BZ with gcc.gnu.org account provides elevated privileges.
>> So if you have write access, you should get extra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68988
--- Comment #4 from Yury Gribov ---
(In reply to Alexander Monakov from comment #3)
> Not a commit, merely a proposed patch at this point. Sorry I missed this bug
> when preparing the patch.
Yes, I should avoid working too late in the evening.
On Wed, Jul 19, 2017 at 4:30 PM, Alexander Monakov wrote:
> On Wed, 19 Jul 2017, Jeff Law wrote:
>> > Glibc people were worried that attribute would be lost when taking a
>> > pointer to function
>> > (https://sourceware.org/ml/libc-alpha/2017-01/msg00482.html). I think
>> >
On 7/18/17, Yuri Gribov wrote:
> On Tue, Jul 18, 2017 at 3:54 PM, Martin Sebor wrote:
>> On 07/17/2017 02:25 PM, Yuri Gribov wrote:
>>>
>>> On Mon, Jul 17, 2017 at 4:23 PM, Martin Sebor wrote:
On 07/17/2017 02:14 AM, Yuri Gribov
Hi,
On 19/07/2017 02:17, Jonathan Wakely wrote:
This fixes a crash that happens in std::filebuf when a large read
consumes the entire get area and is followed by a write, which is then
synced to the file by a call to overflow.
The problem is that xsgetn calls _M_set_buffer(0) after reading
On July 19, 2017 6:10:28 PM GMT+02:00, Andrew Pinski wrote:
>On Mon, Jul 17, 2017 at 3:02 AM, Richard Biener
> wrote:
>> On Thu, Jul 13, 2017 at 6:18 AM, Andrew Pinski
>wrote:
>>> On Wed, Jul 12, 2017 at 9:10 PM, Marc Glisse
On Wed, 2017-07-19 at 12:45 -0500, Segher Boessenkool wrote:
> On Tue, Jul 18, 2017 at 05:10:42PM -0500, Steven Munroe wrote:
> > On Tue, 2017-07-18 at 16:54 -0500, Segher Boessenkool wrote:
> > > On Mon, Jul 17, 2017 at 01:28:20PM -0500, Steven Munroe wrote:
> > > > After a resent GCC change the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81331
--- Comment #12 from Jan Hubicka ---
Author: hubicka
Date: Wed Jul 19 18:08:07 2017
New Revision: 250358
URL: https://gcc.gnu.org/viewcvs?rev=250358=gcc=rev
Log:
PR middle-end/81331
* except.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81393
--- Comment #9 from Ian Lance Taylor ---
Created attachment 41791
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41791=edit
Possible patch
I agree that the simplest approach is to not try to pick up the definitions
from the header files
Hi Jeff,
There is an issue with your AArch64 patch, it fails to apply properly and does
so silently using 'patch'. I also noticed some odd control characters in the
other
patches, but they didn't appear to fail (or at least everything builds).
Anyway with -Ofast -static the overall codesize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68988
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
On Tue, Jul 18, 2017 at 05:10:42PM -0500, Steven Munroe wrote:
> On Tue, 2017-07-18 at 16:54 -0500, Segher Boessenkool wrote:
> > On Mon, Jul 17, 2017 at 01:28:20PM -0500, Steven Munroe wrote:
> > > After a resent GCC change the previously submitted BMI/BMI2 intrinsic
> > > test started to fail
On Tue, Jul 18, 2017 at 04:24:47PM -0400, Michael Meissner wrote:
> This patch modifies the change I made on July 12th. It modifies the test for
> the __builtin_cpu_is and __builtin_cpu_supports built-in functions to use an
> #ifdef instead of target-requires for doing the tests. One motavation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81483
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81486
Bug ID: 81486
Summary: Class template argument deduction fails with (),
succeeds with {}
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81484
--- Comment #4 from Marek Polacek ---
(In reply to Arnd Bergmann from comment #3)
> It seems I got a little confused when I only looked at the initial patch
> that was proposed, which was supposed to cover specifically the comparison
> followed
On Wed, 19 Jul 2017, Jakub Jelinek wrote:
> > 1) recognize dlsym by name and suppress tailcalls to it
> >
> >this would solve >99% cases because calling dlsym by pointer would be
> > rare,
> >and has the benefit of not requiring libc header changes;
>
> Recognizing by name is IMNSHO
Hi,
this patch makes an assert in gimple_phi_set_arg more strict.
The current assert allows 'index == phi->nargs'. While it's true that
there are access functions that currently use the nargs..(capacity-1)
inclusive range, this is not one of them (and if it was, the condition
should be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81317
--- Comment #18 from Randy MacLeod ---
With both patches applied:
1. The "minimal testcase produced by the delta utility" no longer ICEs the
toolchain.
2. The "smaller reproducer with manual work-around " DOES STILL result in an
ICE as does the
On 07/19/2017 12:42 AM, Jeff Law wrote:
On 07/02/2017 02:00 PM, Martin Sebor wrote:
The attached patch enhances the -Wrestrict warning to detect more
than just trivial instances of overlapping copying by sprintf and
related functions.
The meat of the patch is relatively simple but because it
On Mon, Jul 17, 2017 at 3:02 AM, Richard Biener
wrote:
> On Thu, Jul 13, 2017 at 6:18 AM, Andrew Pinski wrote:
>> On Wed, Jul 12, 2017 at 9:10 PM, Marc Glisse wrote:
>>> On Wed, 12 Jul 2017, Andrew Pinski wrote:
>>>
Hi,
1 - 100 of 189 matches
Mail list logo