https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92410
Martin Liška changed:
What|Removed |Added
Keywords||needs-bisection
Status|UNCONF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92401
Richard Biener changed:
What|Removed |Added
Assignee|rguenth at gcc dot gnu.org |jakub at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92132
Kewen Lin changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92132
--- Comment #4 from Kewen Lin ---
Author: linkw
Date: Fri Nov 8 07:37:07 2019
New Revision: 277947
URL: https://gcc.gnu.org/viewcvs?rev=277947&root=gcc&view=rev
Log:
[rs6000]Fix PR92132 by adding vec_cmp and vcond_mask supports
To support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92406
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92409
--- Comment #5 from Martin Liška ---
>
> I have to leave the office now but I am testing the attached fix on an
> x86_64 - I have lost connection to the i686 I was using (gcc45).
I would recommend here to use your machine and set up a KVM where
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92100
Jerry DeLisle changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91388
Eric Gallager changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92398
--- Comment #3 from Xiong Hu XS Luo ---
Power8 BE generates:
L.bar:
.LFB1:
.cfi_startproc
mtvsrd 0,4
mtvsrd 1,5
xxpermdi 12,0,1,0
xxlnor 0,12,12
stxvd2x 0,0,3
blr
.long 0
.by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92398
Xiong Hu XS Luo changed:
What|Removed |Added
CC||luoxhu at cn dot ibm.com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91227
--- Comment #20 from Eric Gallager ---
(In reply to Martin Sebor from comment #19)
> That's a valid concern. Issuing a warning (either at the same time as or in
> lieu of the folding) would be a way to detect and prevent these kinds of
> problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92295
--- Comment #2 from liuhongt at gcc dot gnu.org ---
Author: liuhongt
Date: Fri Nov 8 05:34:25 2019
New Revision: 277946
URL: https://gcc.gnu.org/viewcvs?rev=277946&root=gcc&view=rev
Log:
Fix inefficient vector constructor.
Changelog
gcc/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87569
Eric Gallager changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
0][0][0] should be 61344 or opt-out. However, with
"-O2", gdb outputs "l_1162[0][0][0]=3".
$ gcc-trunk -v
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.0.0 20191107 (experimental) [trunk revision 277920] (GCC)
#expected output
$ gcc-trunk -O1 -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87313
Martin Sebor changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87731
Martin Sebor changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78352
--- Comment #10 from Eric Gallager ---
This bug means we now have to leave out a part of libsanitizer that uses
blocks:
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00262.html
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00268.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87736
Martin Sebor changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #29 from Rich Felker ---
For reference, here are the affected functions in musl (fmax, fmaxf, fmin,
fminf):
https://git.musl-libc.org/cgit/musl/tree/src/math/powerpc64?id=v1.1.24
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #28 from Segher Boessenkool ---
(In reply to A. Wilcox (awilfox) from comment #25)
> GCC typically announces deprecations for publicly-documented interfaces
> being removed versions ahead of time, and I'm surprised that wasn't followe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #27 from Rich Felker ---
> Have I already mentioned that if any program "in the wild" will use "ws" with
> GCC 10, then of course we can add an alias (to "wa") for it? No program
> should
> use "ws" in inline assembler, ever, but if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #26 from Segher Boessenkool ---
(In reply to Rich Felker from comment #24)
> > Sure, and I'll do that, *if there are users*, *after they fix their stuff*.
>
> Nothing is broken on our side here. We are using the documented
> function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92090
--- Comment #15 from Peter Bergner ---
Author: bergner
Date: Fri Nov 8 00:34:09 2019
New Revision: 277942
URL: https://gcc.gnu.org/viewcvs?rev=277942&root=gcc&view=rev
Log:
Add another test case to exercise the previous MODE_PARTIAL_INT change.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92416
Bug ID: 92416
Summary: ICE with spaceship and vector types
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priorit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92409
--- Comment #4 from Jakub Jelinek ---
Sadly, neither of those regressions is fixed on i686-linux.
Still the same
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/cast-function-1.c:49:1: error:
non-trivial conversion in 'ssa_name'
struct str_t
int
{} = ar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
A. Wilcox (awilfox) changed:
What|Removed |Added
CC||awilfox at adelielinux dot org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92090
Peter Bergner changed:
What|Removed |Added
Known to work||7.0
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92415
Bug ID: 92415
Summary: new test case g++.dg/cpp2a/spaceship-scalar1-neg.C
introduced in r277925 fails
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #24 from Rich Felker ---
> Sure, and I'll do that, *if there are users*, *after they fix their stuff*.
Nothing is broken on our side here. We are using the documented functionality
from gcc 9 going all the way back to whatever versio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92414
--- Comment #2 from Jakub Jelinek ---
Created attachment 47196
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47196&action=edit
gcc10-pr92414.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92414
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92414
Marek Polacek changed:
What|Removed |Added
Keywords||ice-on-invalid-code
Status|U
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92414
Bug ID: 92414
Summary: internal compiler error: tree check: expected
constructor, have error_mark in
cxx_eval_store_expression, at cp/constexpr.c:4009
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91370
--- Comment #1 from Jakub Jelinek ---
Author: jakub
Date: Thu Nov 7 20:24:38 2019
New Revision: 277929
URL: https://gcc.gnu.org/viewcvs?rev=277929&root=gcc&view=rev
Log:
PR c++/91370 - Implement P1041R4 and P1139R2 - Stronger Unicode re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #23 from Segher Boessenkool ---
(In reply to rsand...@gcc.gnu.org from comment #21)
> > I am saying it is a mistake that GCC ever documented this for public
> > use. Every use of "ws" in inline asm should be "wa".
>
> But it was a m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92409
--- Comment #3 from Martin Jambor ---
Created attachment 47195
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47195&action=edit
Hopefully the fix
I have to leave the office now but I am testing the attached fix on an x86_64 -
I have lost c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92090
--- Comment #13 from Peter Bergner ---
Author: bergner
Date: Thu Nov 7 18:48:45 2019
New Revision: 277928
URL: https://gcc.gnu.org/viewcvs?rev=277928&root=gcc&view=rev
Log:
Allow MODE_PARTIAL_INT modes for integer constant input operands.
gcc/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92413
David Blaikie changed:
What|Removed |Added
CC||dblaikie at gmail dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92413
Bug ID: 92413
Summary: [temp.explicit] Explicit template instantiations
should not define member functions that are not
defined at the point of instantiation
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92412
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92409
Martin Jambor changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92412
Bug ID: 92412
Summary: excessive errno aliasing assumption defeats
optimization
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92411
Bug ID: 92411
Summary: conformance issue with reinterpret_cast in constant
expressions
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #22 from Rich Felker ---
And to be clear, pretty much all gcc versions from 3.4.6 to present, and all
clang/LLVM versions since they fixed some critical bugs (like -ffreestanding
not working, which was a show-stopper), are supported c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #20 from Rich Felker ---
> After both musl and LLVM are fixed, if you then *still* feel you
> need "ws", then we can talk of course. Deal?
No, it's not a deal. Your proposal is *breaking all currently-working versions*
of clang beca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #21 from rsandifo at gcc dot gnu.org
---
(In reply to Segher Boessenkool from comment #19)
> (In reply to Rich Felker from comment #16)
> > > Using "ws" in inline asm never made sense. It was always the same as
> > > "wa", for all c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92088
--- Comment #7 from joseph at codesourcery dot com ---
Yes, pointers to VLA are variably modified (but are OK in function
arguments even for extern functions, as VLAs there get treated as [*]).
So maybe you should use C_TYPE_VARIABLE_SIZE as th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92333
--- Comment #5 from Martin Sebor ---
The ICE is caused by int_const_binop (TRUNC_DIV_EXPR, maxbound, eltsize)
returning a nul for constant arguments, and caller assuming it's non-null. The
poly_int_binop function apparently doesn't know how to d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #19 from Segher Boessenkool ---
(In reply to Rich Felker from comment #16)
> > Using "ws" in inline asm never made sense. It was always the same as
> > "wa", for all cases where either could be used in inline asm at all.
>
> It made
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #18 from Rich Felker ---
> So use "wa" instead of "ws" in the two files you use it, and can we get
> on with our lives?
Translation: Introduce a regression on all existing versions of clang because
GCC broke a documented public inter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #17 from Segher Boessenkool ---
(In reply to Rich Felker from comment #13)
> > That does not look at types. It complains that "x" lives in memory,
> > while the constraint requires a register (a floating point register).
>
> That do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92406
--- Comment #7 from Jan Hubicka ---
Author: hubicka
Date: Thu Nov 7 17:08:11 2019
New Revision: 277927
URL: https://gcc.gnu.org/viewcvs?rev=277927&root=gcc&view=rev
Log:
PR ipa/92406
* ipa-fnsummary.c (analyze_function_body): U
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92409
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92410
Bug ID: 92410
Summary: Invalid access to df->insns[] in
regstat_bb_compute_calls_crossed (caught by hwasan)
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Sever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92408
Martin Sebor changed:
What|Removed |Added
Keywords||missed-optimization
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92362
Eric Botcazou changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|ebotcazou at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92362
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #16 from Rich Felker ---
> Using "ws" in inline asm never made sense. It was always the same as
> "wa", for all cases where either could be used in inline asm at all.
It made sense insomuch as it was documented and was the most clea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92401
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92409
Bug ID: 92409
Summary: [10 regression] r277920 causes ICE in
gcc.dg/cast-function-1.c
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92408
Bug ID: 92408
Summary: strlen(s) != 0 not folded into *s
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #15 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #12)
> (In reply to Segher Boessenkool from comment #10)
> > No, they are not. The constraints are an implementation detail. And
> > they *have* to be, or we co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92398
seurer at gcc dot gnu.org changed:
What|Removed |Added
CC||wschmidt at gcc dot gnu.org
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #14 from Rich Felker ---
> So, if "ws" has been documented in the user documentation, perhaps just
> (define_register_constraint "ws" "rs6000_constraints[RS6000_CONSTRAINT_wa]"
> "Compatibility alias to wa")
> could be added? If it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #13 from Rich Felker ---
> That does not look at types. It complains that "x" lives in memory,
> while the constraint requires a register (a floating point register).
That does not sound accurate. An (in this case lvalue since it's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #12 from Jakub Jelinek ---
(In reply to Segher Boessenkool from comment #10)
> No, they are not. The constraints are an implementation detail. And
> they *have* to be, or we could never again improve anything.
>
> Unfortunately we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #11 from Segher Boessenkool ---
(In reply to Rich Felker from comment #9)
> And ok, to be more productive rather than just angry about the regression,
> if you really think the "ws" constraint should be removed, what is the
> proper p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92123
--- Comment #2 from Tobias Burnus ---
Submitted and approved patch:
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00072.html – still to be
committed by the author.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #10 from Segher Boessenkool ---
(In reply to Rich Felker from comment #8)
> > Then LLVM has more to fix. Constraints never look at types. A register
> > constraint (like "wa") simply says what registers are valid.
>
> This is blate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89134
--- Comment #14 from fxue at gcc dot gnu.org ---
Author: fxue
Date: Thu Nov 7 15:43:01 2019
New Revision: 277923
URL: https://gcc.gnu.org/viewcvs?rev=277923&root=gcc&view=rev
Log:
Loop split on semi-invariant conditional statement
2019-11-07 F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92090
--- Comment #12 from Peter Bergner ---
(In reply to Peter Bergner from comment #11)
> I've been working on allowing in the rs6000 patterns.
This fixes the ICE for me. I have not regtested the patch though:
Index: gcc/config/rs6000/predicates.m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92407
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92407
--- Comment #4 from Dave Poston ---
Yep, also changing problem()/foo() to void and not returning the struct, works
properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91253
Tobias Burnus changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92090
--- Comment #11 from Peter Bergner ---
(In reply to Xiong Hu XS Luo from comment #10)
> This could fix the ICE, but I am not sure whether it is reasonable:
>
> diff --git a/gcc/lra-constraints.c b/gcc/lra-constraints.c
> index 0db6d3151cd..32590
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92407
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84402
--- Comment #32 from Giuliano Belinassi ---
(In reply to Eric Gallager from comment #31)
> I think this came up at Cauldron, but I forget what exactly people said
> about it...
Actually this PR comes before Cauldron 2019. One way to fix this iss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #9 from Rich Felker ---
And ok, to be more productive rather than just angry about the regression, if
you really think the "ws" constraint should be removed, what is the proper
preprocessor/configure-time check to determine the right
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #8 from Rich Felker ---
> Then LLVM has more to fix. Constraints never look at types. A register
> constraint (like "wa") simply says what registers are valid.
This is blatently false. For x86:
int foo(int x)
{
__asm__("" : "+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92396
--- Comment #4 from Trass3r ---
Nice! Btw the traces can be viewed independently of the browser using
https://www.speedscope.app.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92283
--- Comment #11 from Richard Biener ---
Created attachment 47194
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47194&action=edit
diff for results.f
So with the attached diff for results.f and a simple
> cat t.f
subroutine foobar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92283
--- Comment #10 from Richard Biener ---
Adding
!GCC$ unroll 0
before line 848 or adding a call to an empty function after the loop nest
(after 857) fixes the miscompare. GIMPLE level difference with the function
call
is one missed invariant mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92406
--- Comment #6 from Jan Hubicka ---
> > Hi,
> > does this patch fix the problem?
> > Honza
>
> Yes, it fixed the issue.
Great, thanks. I was overzealous here with getting rid of get_create :)
Honza
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92406
--- Comment #5 from Martin Liška ---
(In reply to Jan Hubicka from comment #4)
> Created attachment 47193 [details]
> Proposed patch
>
> Hi,
> does this patch fix the problem?
> Honza
Yes, it fixed the issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92407
--- Comment #2 from Richard Biener ---
The goto defeats finalization here but construction happens multiple times.
Not sure if that's allowed by the standard, but I'd say you invoke undefined
behavior here?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92396
Martin Liška changed:
What|Removed |Added
Target Milestone|--- |11.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92406
--- Comment #4 from Jan Hubicka ---
Created attachment 47193
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47193&action=edit
Proposed patch
Hi,
does this patch fix the problem?
Honza
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92407
--- Comment #1 from Dave Poston ---
In fact, fill() isn't even needed.
Smaller repro:
https://godbolt.org/z/ubXl7Y
---
#include
struct MyStruct
{
MyStruct() {
std::cout << "Constructed" << std::endl;
}
~
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92396
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92407
Bug ID: 92407
Summary: Destruction of objects returned from functions skipped
by goto
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92406
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |10.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92405
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92405
--- Comment #4 from Richard Biener ---
Author: rguenth
Date: Thu Nov 7 11:49:09 2019
New Revision: 277921
URL: https://gcc.gnu.org/viewcvs?rev=277921&root=gcc&view=rev
Log:
2019-11-07 Richard Biener
PR tree-optimization/92405
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92365
--- Comment #6 from Bernd Edlinger ---
I tried this, and it contradicts what above comment says:
$ cat test1.cc
void foo()
{
char *x = int();
}
gcc -Wall -S -std=c++17 test1.cc
test1.cc: In function ‘void foo()’:
test1.cc:3:9: warning: unus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92365
--- Comment #5 from Bernd Edlinger ---
Some insight, why the crash only happens with -std=c++98:
-Wshadow=compatible-local tries to find out if there is an
implicit conversion between the "int16_t f" and "a f".
The only candidate is a::a(char *)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92388
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|2019
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92333
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70929
--- Comment #15 from Martin Jambor ---
Author: jamborm
Date: Thu Nov 7 10:55:43 2019
New Revision: 277920
URL: https://gcc.gnu.org/viewcvs?rev=277920&root=gcc&view=rev
Log:
Remove gimple_call_types_likely_match_p (PR 70929)
2019-11-07 Martin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92406
Martin Liška changed:
What|Removed |Added
Assignee|marxin at gcc dot gnu.org |hubicka at gcc dot
gnu.org
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92405
Martin Liška changed:
What|Removed |Added
Keywords||ice-on-valid-code
Target|i386
1 - 100 of 116 matches
Mail list logo
