https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86067
Paul Hua changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86128
Bug ID: 86128
Summary: ice in get_string_length, at tree-ssa-strlen.c:653
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130
Bug ID: 86130
Summary: Expect SIGBUS but program just silently exits
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86118
--- Comment #4 from Александр Кроль ---
1. tar -x -M --file=idfs1.tar.gz ./idfs.ii.bz2
Prepare volume #2 for ‘idfs1.tar.gz’ and hit return: n idfs2.tar.gz
2. bunzip2 ./idfs.ii.bz2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86131
Bug ID: 86131
Summary: powerpc: gcc uses costly multiply instead of shift
left
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669
--- Comment #5 from Douglas Mencken ---
Bisecting is hard, because commits before
15adae8bbeb4579910eadf636e3b06f3dae4a342 “ PR bootstrap/82939
* line-map.c (linemap_init): Avoid broken value-init when compiling with GCC
4.2 ”
segfault on genmatc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86132
Bug ID: 86132
Summary: Failure to elide condition known to be non-null
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: mid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86048
--- Comment #4 from Eric Botcazou ---
Author: ebotcazou
Date: Wed Jun 13 11:20:23 2018
New Revision: 261544
URL: https://gcc.gnu.org/viewcvs?rev=261544&root=gcc&view=rev
Log:
PR target/86048
* config/i386/winnt.c (i386_pe_seh_col
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86048
--- Comment #5 from Eric Botcazou ---
Author: ebotcazou
Date: Wed Jun 13 11:22:17 2018
New Revision: 261545
URL: https://gcc.gnu.org/viewcvs?rev=261545&root=gcc&view=rev
Log:
PR target/86048
* config/i386/winnt.c (i386_pe_seh_col
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86048
Eric Botcazou changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86134
Bug ID: 86134
Summary: earlier error causes followup diagnostic about unknown
-Wno-* options
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Keywords: diagnosti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86133
Bug ID: 86133
Summary: powerpc (-mcpu=8548) internal compiler error for
double variables
Product: gcc
Version: 6.4.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86134
Richard Biener changed:
What|Removed |Added
Summary|earlier error causes|earlier diagnostic causes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86133
--- Comment #1 from Kiran Alladi ---
I am trying to compile the code with -mno-spe but still it seems that compiler
is generating spe instructions.
~/kiran$ cat test.c
double var_double = 0;
long var_long = 0;
void my_func( double var_val )
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86127
--- Comment #1 from Jonathan Wakely ---
The allocator requirements say that move construction must be equivalent to
copy construction, and allocators should be cheap to copy anyway. I don't
consider this a bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86120
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86127
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86117
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86127
--- Comment #3 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #2)
> Also your test is flawed.
>
> (In reply to Scott Constable from comment #0)
> > forward_list test
> > ==
>
> These all come from the default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86115
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86116
Dominique d'Humieres changed:
What|Removed |Added
Priority|P3 |P4
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86099
Marek Polacek changed:
What|Removed |Added
Keywords||ice-on-valid-code
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86127
Jonathan Wakely changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86119
Dominique d'Humieres changed:
What|Removed |Added
Priority|P3 |P4
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86135
Bug ID: 86135
Summary: At run time, when the constructor tries to construct
an objects element with a initializer-list (using
c++11 style) is giving segmentation fault. The old
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86135
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85702
--- Comment #2 from cesar at gcc dot gnu.org ---
Author: cesar
Date: Wed Jun 13 14:29:04 2018
New Revision: 261550
URL: https://gcc.gnu.org/viewcvs?rev=261550&root=gcc&view=rev
Log:
PR fortran/85702
gcc/fortran/
* openmp.c (gfc_m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85703
--- Comment #4 from cesar at gcc dot gnu.org ---
Author: cesar
Date: Wed Jun 13 14:31:17 2018
New Revision: 261551
URL: https://gcc.gnu.org/viewcvs?rev=261551&root=gcc&view=rev
Log:
PR fortran/85703
gcc/fortran/
* parse.c (decode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86135
Jonathan Wakely changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85577
Jonathan Wakely changed:
What|Removed |Added
CC||sabetaytoros at gmail dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86136
Bug ID: 86136
Summary: Modular multiplication optimization
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimizati
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86135
--- Comment #3 from Jonathan Wakely ---
Based on the names I'm assuming your code is the same as a case I analysed
recently, which reduces to:
#include
#include
struct object_t {
template
object_t(T object)
: obj{std::make_shared>(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86136
--- Comment #1 from MCCCS ---
Note: It can notice (a * n) % k = 0 if n is a multiple of k. The bug happens
only if n % k != 0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85702
cesar at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85703
cesar at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86085
Richard Biener changed:
What|Removed |Added
Keywords||alias, missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86090
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86127
--- Comment #5 from Jonathan Wakely ---
Author: redi
Date: Wed Jun 13 15:14:48 2018
New Revision: 261554
URL: https://gcc.gnu.org/viewcvs?rev=261554&root=gcc&view=rev
Log:
PR libstdc++/86127 avoid unnecessary allocator conversions
There is no n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86091
--- Comment #1 from Richard Biener ---
I can't reproduce the slowness.
> /usr/bin/time g++-8 t.C -std=gnu++1z -Wall -Wextra
0.23user 0.04system 0:00.27elapsed 99%CPU (0avgtext+0avgdata 44028maxresident)k
0inputs+1568outputs (0major+14354minor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86092
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86093
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86094
--- Comment #7 from Richard Biener ---
Fixed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86094
--- Comment #8 from Richard Biener ---
Note if there's any ABI change between 8.1 and 8.2 please adjust changes.html
to note this as a caveat (even if the 7.3 -> 8.1 change was unintended).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86128
Martin Sebor changed:
What|Removed |Added
Keywords||ice-on-valid-code
Status|UNCO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86089
Martin Sebor changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment #15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86097
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86104
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-*, i?86-*-*
--- Comment #3 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86109
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |8.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86135
--- Comment #4 from Sabetay Toros ---
*" --- Comment #2 from Jonathan Wakely http://gnu.org/>> ---This is not a bug, GCC is correct. With
list-initialization the compiler doesnot always select a copy/move
constructor even when the argument is th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86108
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130
--- Comment #2 from Paul Sanders ---
Hi Martin,
Thanks very much for your prompt reply, and I completely agree with your
viewpoint.
I therefore hereby request that libstc++ stops behaving like that and just lets
the SIGSEGV happen. The current
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86113
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86114
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86121
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86122
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86123
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207
--- Comment #11 from Lionel GUEZ ---
And what about my suggestion that ieee_support_nan(0.) should return false for
the time being?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86124
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86129
Bug ID: 86129
Summary: Expect SIGBUS but program just silently exits
Product: gcc
Version: 8.1.0
Status: RESOLVED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86127
Jonathan Wakely changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86135
--- Comment #5 from Jonathan Wakely ---
(In reply to Sabetay Toros from comment #4)
> If it is not a bug then why the parenthesis version is working.
Because the rules for direct-initialization (with parentheses) and
list-initialization (with br
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130
--- Comment #3 from Jonathan Wakely ---
Arguably crashing the program is more unfriendly.
We could add the nonnull attribute to the relevant ostream members, or add
assertions that can be optionally enabled, but I'm not convinced that crashing
i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86048
--- Comment #7 from Eric Botcazou ---
To give a bit more information about the bug: it's a bad interaction between
SEH, -freorder-blocks-and-partition (default) and
__builtin_{frame,return}_address.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86107
--- Comment #6 from rsandifo at gcc dot gnu.org
---
(In reply to Uroš Bizjak from comment #5)
> (In reply to rsand...@gcc.gnu.org from comment #4)
>
> > > but should not fail verification even for !TARGET_INTER_UNIT_MOVES_TO_VEC
> > > targets.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86135
--- Comment #6 from Sabetay Toros ---
Hi,
*Because the rules for direct-initialization (with parentheses)
andlist-initialization (with braces) are different. Different rules
meansdifferent things happen. *
the rules may be different but res
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86127
--- Comment #7 from Scott Constable ---
(In reply to Jonathan Wakely from comment #1)
> The allocator requirements say that move construction must be equivalent to
> copy construction, and allocators should be cheap to copy anyway. I don't
> cons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86135
--- Comment #7 from Jonathan Wakely ---
(In reply to Sabetay Toros from comment #6)
> the rules may be different but results must be the same.
No, that's not true. The point of the different rules is to do different
things.
> There is a flaw he
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86127
--- Comment #8 from Jonathan Wakely ---
(In reply to Scott Constable from comment #7)
> (In reply to Jonathan Wakely from comment #1)
> > The allocator requirements say that move construction must be equivalent to
> > copy construction, and alloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86129
--- Comment #2 from Paul Sanders ---
The program should crash. That way, the developer (or the test department)
gets to find out about the problem before the customer.
I would have thought this was obvious.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130
--- Comment #4 from Paul Sanders ---
@Johnathon Crashing the program is the right thing to do, because it means that
the developer (or the test department) will get to find out about the problem
before the customer does.
Does that help you see w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86135
--- Comment #8 from Jonathan Wakely ---
http://en.cppreference.com/w/cpp/language/list_initialization#Notes shows a
similar example, demonstrating the different behaviour for initializer_list
constructors. std::vector has an initializer-list cons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86129
Jonathan Wakely changed:
What|Removed |Added
Resolution|INVALID |DUPLICATE
--- Comment #3 from Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130
--- Comment #5 from Jonathan Wakely ---
*** Bug 86129 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207
--- Comment #12 from Steve Kargl ---
On Wed, Jun 13, 2018 at 03:55:02PM +, guez at lmd dot ens.fr wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207
>
> --- Comment #11 from Lionel GUEZ ---
> And what about my suggestion that ieee_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86127
--- Comment #9 from Scott Constable ---
(In reply to Jonathan Wakely from comment #8)
> (In reply to Scott Constable from comment #7)
> > (In reply to Jonathan Wakely from comment #1)
> > > The allocator requirements say that move construction mu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86129
--- Comment #4 from Paul Sanders ---
Sorry, that didn't happen on purpose. I edited the title, maybe that's what
caused it, or maybe it's because someone (Martin?) changed the component from
gcc to libstdc++.
Anyway, I won't post anything furth
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130
--- Comment #6 from Jonathan Wakely ---
And they don't test for iostream operations failing?
The program has undefined behaviour, i.e. a bug. Whether it's better to
identify that and treat it as a corrupt stream state (setting badbit, and
option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86127
--- Comment #10 from Jonathan Wakely ---
As I said in comment 6, I've already removed the copies that forward_list does
on destruction.
As I said in comment 3, there are no copies in the default constructor, they're
in the initializer-list const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130
--- Comment #7 from Jonathan Wakely ---
I don't know the original reason for handling null pointers here, but it's
consistent with glibc's printf which prints "(null)" when a null pointer is
provided for a %s specifier.
Removing this longstandin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86085
--- Comment #2 from Martin Sebor ---
To make use of the Glibc printf hooks users have to disable the GCC built-ins.
Otherwise the hooks might interfere with the sprintf optimization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86137
Bug ID: 86137
Summary: ubsan runtime error in c-format.c
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130
--- Comment #8 from Paul Sanders ---
Thanks for your comments. I can see there are two sides to this.
I was in the middle of composing the tract below. I'll include that anyway
because it took me ages to type. There's a bit at the end about p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86110
--- Comment #3 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Wed Jun 13 19:37:50 2018
New Revision: 261561
URL: https://gcc.gnu.org/viewcvs?rev=261561&root=gcc&view=rev
Log:
2018-06-13 Steven G. Kargl
PR fortran/86110
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130
--- Comment #9 from Jonathan Wakely ---
(In reply to Paul Sanders from comment #8)
> Thanks for your comments. I can see there are two sides to this.
>
> I was in the middle of composing the tract below. I'll include that anyway
> because it t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86137
--- Comment #1 from joseph at codesourcery dot com ---
Yes, this code needs to be fixed to avoid undefined overflow (if argnum >
INT_MAX / 10 || (argnum == INT_MAX / 10 && *fcp - '0' > INT_MAX % 10),
record that overflow has occurred and don't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86094
--- Comment #10 from Jason Merrill ---
Author: jason
Date: Wed Jun 13 19:39:53 2018
New Revision: 261563
URL: https://gcc.gnu.org/viewcvs?rev=261563&root=gcc&view=rev
Log:
PR c++/86094 - wrong code with defaulted move ctor.
gcc/c-family
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86094
--- Comment #9 from Jason Merrill ---
Author: jason
Date: Wed Jun 13 19:39:36 2018
New Revision: 261562
URL: https://gcc.gnu.org/viewcvs?rev=261562&root=gcc&view=rev
Log:
PR c++/86094 - wrong code with defaulted move ctor.
gcc/c-family/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130
--- Comment #10 from Martin Sebor ---
As a data point, calling printf ("%s", p) does lead to a segfault in Glibc for
a null p because GCC turns the call into puts(p) which doesn't have the same
feature (see https://sourceware.org/bugzilla/show_bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86090
--- Comment #3 from chefmax at gcc dot gnu.org ---
Author: chefmax
Date: Wed Jun 13 19:51:42 2018
New Revision: 261564
URL: https://gcc.gnu.org/viewcvs?rev=261564&root=gcc&view=rev
Log:
2018-06-13 Denis Khalikov
libsanitizer/
PR sani
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86138
Bug ID: 86138
Summary: C++17: getline(istream, string) crashes on Cygwin
because incompatible C++14 function is called
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86135
--- Comment #9 from Sabetay Toros ---
I´ve examined your link. This is not the same case as you are stating. I am
not initializing a vector with an initializer list, rather I am trying to
initialize only one object member with a universal initi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86135
--- Comment #10 from Jonathan Wakely ---
You didn't provide a proper testcase so nobody can possibly explain why your
code crashes.
If it's similar to the code in comment 3 then model_t>
tries to construct a vector from a vector using list-init
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86110
--- Comment #4 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Wed Jun 13 20:17:58 2018
New Revision: 261565
URL: https://gcc.gnu.org/viewcvs?rev=261565&root=gcc&view=rev
Log:
2018-06-13 Steven G. Kargl
PR fortran/86110
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86114
--- Comment #3 from Martin Sebor ---
Author: msebor
Date: Wed Jun 13 20:29:04 2018
New Revision: 261567
URL: https://gcc.gnu.org/viewcvs?rev=261567&root=gcc&view=rev
Log:
PR tree-optimization/86114 - ICE in gimple_fold_builtin_strlen with an inv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86114
Martin Sebor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130
--- Comment #11 from Paul Sanders ---
> I think most users prefer invalid uses of pointers to fail loudly so they can
> be caught early. Few users expect output functions to fail, and even fewer
> bother to check for failures when writing to s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86114
--- Comment #5 from Martin Sebor ---
Author: msebor
Date: Wed Jun 13 20:39:50 2018
New Revision: 261569
URL: https://gcc.gnu.org/viewcvs?rev=261569&root=gcc&view=rev
Log:
PR tree-optimization/86114 - ICE in gimple_fold_builtin_strlen with an inv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86114
Martin Sebor changed:
What|Removed |Added
Summary|[8/9 Regression] ICE in |ICE in
|gimple_fold_bui
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130
--- Comment #12 from Paul Sanders ---
Sorry, I posted that in a bit of a rush. I took a proper look and the null
pointers that set badbit actually make excellent sense.
So I'll suggest a way out of the backwards compatibility conundrum when
`os
1 - 100 of 128 matches
Mail list logo
