https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66186
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66189
Bug ID: 66189
Summary: Block loops for inline matmul
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66015
chrbr at gcc dot gnu.org changed:
What|Removed |Added
Target|aarch64, alpha |aarch64, alpha,ia64
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66187
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66186
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |4.9.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66178
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66185
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66157
--- Comment #9 from Luca Stoppa ---
I see.
Thanks again for your answer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66190
Bug ID: 66190
Summary: [5/6 Regression] ICE: tree code ‘call_expr’ is not
supported in LTO streams with -fsanitize=null
Product: gcc
Version: 6.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66110
Richard Biener changed:
What|Removed |Added
CC||jsm28 at gcc dot gnu.org
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66168
--- Comment #3 from Thomas Preud'homme ---
I have a patch that pass bootstrap. Trying the testsuite now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59626
--- Comment #25 from Arseny Solokha ---
I observe it when building gcc-6.0.0_alpha20150517 snapshot using gcc 5.1.0
without LTO:
/bin/bash ./libtool --tag=CXX --mode=compile powerpc-e500v2-linux-gnuspe-c++
-B/usr/powerpc-e500v2-linux-gnuspe/tm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66187
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66122
--- Comment #8 from Denis Vlasenko ---
If you try to reproduce this with kernel build, be sure to not select
CONFIG_OPTIMIZE_INLINING (it forces inlining by making all iniline functions
__always_inline).
I didn't mention it before, but the recen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66122
--- Comment #9 from Jakub Jelinek ---
(In reply to Denis Vlasenko from comment #8)
> If you try to reproduce this with kernel build, be sure to not select
> CONFIG_OPTIMIZE_INLINING (it forces inlining by making all iniline functions
> __always_i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66147
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |5.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66148
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |6.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66163
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |4.0.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66163
Richard Biener changed:
What|Removed |Added
Target Milestone|4.0.1 |6.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66165
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66191
Bug ID: 66191
Summary: GCC optimizes away if clause checking similar but not
same condition
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: major
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66191
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66191
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66191
--- Comment #3 from Nenad Mikša ---
Thanks for info.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66190
--- Comment #1 from Martin Liška ---
w/o -flto one gets:
test2.ii:14:56: internal compiler error: in expand_expr_real_1, at expr.c:10766
GrAAHairLinePathRenderer::~GrAAHairLinePathRenderer() {}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66191
Jonathan Wakely changed:
What|Removed |Added
Severity|major |normal
--- Comment #4 from Jonathan Wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66181
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |6.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66180
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |6.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66185
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66190
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |5.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66190
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66190
--- Comment #3 from Marek Polacek ---
Started with r213406.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65637
--- Comment #8 from vries at gcc dot gnu.org ---
Author: vries
Date: Mon May 18 13:22:26 2015
New Revision: 223291
URL: https://gcc.gnu.org/viewcvs?rev=223291&root=gcc&view=rev
Log:
Fix inner loop phi in expand_omp_for_static_chunk
2015-05-18 T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65637
--- Comment #9 from vries at gcc dot gnu.org ---
Author: vries
Date: Mon May 18 13:22:36 2015
New Revision: 223292
URL: https://gcc.gnu.org/viewcvs?rev=223292&root=gcc&view=rev
Log:
Handle 2 preds for fin_bb in expand_omp_for_static_chunk
2015-0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65637
--- Comment #7 from vries at gcc dot gnu.org ---
Author: vries
Date: Mon May 18 13:22:15 2015
New Revision: 223290
URL: https://gcc.gnu.org/viewcvs?rev=223290&root=gcc&view=rev
Log:
Fix gcc_assert in expand_omp_for_static_chunk
2015-05-18 Tom d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66190
--- Comment #4 from Marek Polacek ---
So
static int & b = (int &) (UBSAN_NULL (&a, 2B, 0);, &a;);
survives it to the expansion. It appears that we shouldn't instrument statics
like that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66163
--- Comment #6 from Martin Liška ---
According to -fsanitize=null, there are many places in Firefox that produce
undefined behavior in followin way:
https://bugzilla.mozilla.org/show_bug.cgi?id=1165904
One common example:
static size_t off
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66165
--- Comment #3 from Richard Biener ---
Also a missed optimization due to dependence analysis issues.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66192
Bug ID: 66192
Summary: C++ static initializer unnecessary __cxa_guard_acquire
for TARGET_RELAXED_ORDERING
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66163
--- Comment #7 from Jan Hubicka ---
> According to -fsanitize=null, there are many places in Firefox that produce
> undefined behavior in followin way:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1165904
>
> One common example:
>
> st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66192
David Edelsohn changed:
What|Removed |Added
Target||powerpc*-*, sparc*-*-*,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66193
Bug ID: 66193
Summary: ICE for initialisation of some non-zero-sized arrays
Product: gcc
Version: 5.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66163
Jan Hubicka changed:
What|Removed |Added
CC||jason at redhat dot com
--- Comment #8 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66194
Bug ID: 66194
Summary: emit vectorization instruction for not aligned
data(amd64), -fno-strict-aliasing not help
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66193
--- Comment #1 from Gerhard Steinmetz
---
For integer instead of real ...
program p
integer :: z(2)
z = 1.2 + [integer :: 3.5, 4.5]
print *, z
end
it compiles with gfortran snippet.f90
but running ./a.out prints an unexp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66102
Mikael Morin changed:
What|Removed |Added
Attachment #35518|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66193
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66136
--- Comment #5 from Szabolcs Nagy ---
patch that uses awk:
https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01578.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66110
--- Comment #10 from Kevin OConnor ---
I've looked through the C specs (both C99 and C11) and I don't see anything
that requires uint8_t (nor int8_t) to be considered "character types". I do
see three relevant sections in the spec which I'm incl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66110
--- Comment #11 from Andreas Schwab ---
Since typedef does not create a new type the effect of uint8_t is exactly the
same as the type it is defined from. Thus if uint8_t is defined from unsigned
char then uint8_t is a character type.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66110
--- Comment #12 from Kevin OConnor ---
(In reply to Andreas Schwab from comment #11)
> Since typedef does not create a new type the effect of uint8_t is exactly
> the same as the type it is defined from. Thus if uint8_t is defined from
> unsigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66195
Bug ID: 66195
Summary: Optimize _GLIBCXX_GUARD_TEST_AND_ACQUIRE and
_GLIBCXX_GUARD_SET_AND_RELEASE for PowerPC
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Sev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66195
David Edelsohn changed:
What|Removed |Added
Target||powerpc*-*-*
Status|UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57032
--- Comment #15 from uros at gcc dot gnu.org ---
Author: uros
Date: Mon May 18 16:34:23 2015
New Revision: 223298
URL: https://gcc.gnu.org/viewcvs?rev=223298&root=gcc&view=rev
Log:
PR target/57032
* config/alpha/constraints.md (Q)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66190
--- Comment #5 from Marek Polacek ---
So maybe the following? Not sure how well it plays with weak vars/fns
though...
--- a/gcc/c-family/c-ubsan.c
+++ b/gcc/c-family/c-ubsan.c
@@ -433,8 +433,9 @@ ubsan_maybe_instrument_reference_or_call (locati
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66193
--- Comment #3 from Gerhard Steinmetz
---
Hmm, no observable difference with option -fno-frontend-optimize, sorry.
Of course I probed some combinations for several options.
One example for a more extensive "debug" run :
gfortran \
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
Chung-Kil Hur changed:
What|Removed |Added
CC||gil.hur at sf dot snu.ac.kr
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66049
--- Comment #7 from vekumar at gcc dot gnu.org ---
(In reply to ktkachov from comment #3)
> Venkat, are you planning to submit this patch to gcc-patches?
> Also, does this mean we can remove the patterns that do arith+shift using
> MULT rtxes? (li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57032
Uroš Bizjak changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66194
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66194
--- Comment #2 from Evgeniy Dushistov ---
(In reply to H.J. Lu from comment #1)
> Which gcc did you use? Please provide a run-time test.
I try gcc 4.6.4, 4.7.4, 4.9.2, 5.1.0.
If you compile attachment on linux/amd64 and run:
./thash
then it gi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66194
--- Comment #3 from Evgeniy Dushistov ---
So step to reproduce:
1)Download attachment
2)Extract
tar xvf dummy_hash.tar
3)Build
cd dummy_hash && make
4)Run
./thash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66194
Markus Trippelsdorf changed:
What|Removed |Added
CC||trippels at gcc dot gnu.org
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66194
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66193
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66103
--- Comment #2 from Jan Hubicka ---
I committed the patch to block debug info for slim LTO. This testcase will need
-ffat-lto-objects to reproduce.
I suppose the practical approach is to allow the mismatch here with
flat_fat_lto_objects && !in_lt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66194
--- Comment #6 from Evgeniy Dushistov ---
(In reply to Andrew Pinski from comment #5)
> C standard says this is undefined code.
Where? there is two issues aliasing (but I use -fno-strict-aliasing),
and alignment, c99 of course do not mention exa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66181
--- Comment #6 from Jan Hubicka ---
I suppose the problem here is that stor-layout adds TYPE_NO_FORCE_BLK on the
main variant.
I suppose either we can copy it consistently:
Index: stor-layout.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66122
--- Comment #10 from Denis Vlasenko ---
(In reply to Jakub Jelinek from comment #9)
> If you expect that all functions with inline keyword must be always inlined,
> then you really should use __always_inline__ attribute. Otherwise, inline
> keyw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66194
--- Comment #7 from Markus Trippelsdorf ---
6.3.2.3 p7:
»A pointer to an object type may be converted to a pointer to a different
object type. If the resulting pointer is not correctly aligned for the
referenced type, the behavior is undefined.«
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65890
--- Comment #5 from frankhb1989 at gmail dot com ---
(In reply to Jonathan Wakely from comment #3)
> This was changed by
> http://open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#613
>
> It was a defect in the original standard. What possible ad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66194
--- Comment #8 from Evgeniy Dushistov ---
(In reply to Markus Trippelsdorf from comment #7)
> 6.3.2.3 p7:
> »A pointer to an object type may be converted to a pointer to a different
> object type. If the resulting pointer is not correctly aligned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66122
Markus Trippelsdorf changed:
What|Removed |Added
CC||trippels at gcc dot gnu.org
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66122
--- Comment #12 from Andrew Pinski ---
(In reply to Markus Trippelsdorf from comment #11)
> The compiler isn't psychic, e.g. it doesn't parse asm statements at all (so
> it cannot know how many insn it contains).
Actually it does some parsing ju
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66194
--- Comment #9 from Andrew Pinski ---
(In reply to Evgeniy Dushistov from comment #8)
> (In reply to Markus Trippelsdorf from comment #7)
> > 6.3.2.3 p7:
> > »A pointer to an object type may be converted to a pointer to a different
> > object typ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66196
Bug ID: 66196
Summary: Wrong type incompatibility warning for -flto and C
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66194
--- Comment #10 from Evgeniy Dushistov ---
>ABI requirements are not C requirements always. This paragraph is talking
>about >memory accesses but really it did not take into account other
>requirements of C >correctly.
But where then I can ge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64925
--- Comment #3 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Mon May 18 19:25:49 2015
New Revision: 223313
URL: https://gcc.gnu.org/viewcvs?rev=223313&root=gcc&view=rev
Log:
2015-05-18 Steven G. Kargl
PR fortran/64925
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66178
Mikhail Maltsev changed:
What|Removed |Added
CC||miyuki at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66110
--- Comment #13 from joseph at codesourcery dot com ---
I concur that it would be valid to define those typedefs to be extended
integer types withing the special aliasing properties. The first
suggestion of that on the GCC lists that I know of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66039
--- Comment #2 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Mon May 18 21:04:33 2015
New Revision: 223315
URL: https://gcc.gnu.org/viewcvs?rev=223315&root=gcc&view=rev
Log:
2015-05-18 Steven G. Kargl
PR fortran/66039
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66181
Oleg Endo changed:
What|Removed |Added
CC||olegendo at gcc dot gnu.org
--- Comment #7 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66040
--- Comment #5 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Mon May 18 21:16:05 2015
New Revision: 223318
URL: https://gcc.gnu.org/viewcvs?rev=223318&root=gcc&view=rev
Log:
2015-05-18 Steven G. Kargl
PR fortran/66040
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65874
--- Comment #2 from Matthias Klose ---
is there an easy way to implement this scenario with a patch? I don't have
access anymore to ia64 machines, the only resource is a buildd building
distribution packages.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66043
--- Comment #4 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Mon May 18 21:52:03 2015
New Revision: 223320
URL: https://gcc.gnu.org/viewcvs?rev=223320&root=gcc&view=rev
Log:
2015-05-18 Steven G. Kargl
PR fortran/66043
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66044
--- Comment #3 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Mon May 18 22:06:48 2015
New Revision: 223321
URL: https://gcc.gnu.org/viewcvs?rev=223321&root=gcc&view=rev
Log:
2015-05-18 Steven G. Kargl
PR fortran/66044
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66045
--- Comment #2 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Mon May 18 22:21:08 2015
New Revision: 223322
URL: https://gcc.gnu.org/viewcvs?rev=223322&root=gcc&view=rev
Log:
2015-05-18 Steven G. Kargl
PR fortran/66045
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66110
--- Comment #14 from Kevin OConnor ---
(In reply to jos...@codesourcery.com from comment #13)
> I concur that it would be valid to define those typedefs to be extended
> integer types withing the special aliasing properties. The first
> sugges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66052
--- Comment #2 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Mon May 18 22:52:52 2015
New Revision: 223324
URL: https://gcc.gnu.org/viewcvs?rev=223324&root=gcc&view=rev
Log:
2015-05-18 Steven G. Kargl
PR fortran/66052
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65890
--- Comment #6 from Jonathan Wakely ---
(In reply to frankhb1989 from comment #5)
> Mainly for testing of the conformance.
I don't understand what this means. Testing what? G++? G++ does not exist for
you to test its conformance to a standard. M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66057
--- Comment #2 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Mon May 18 23:09:49 2015
New Revision: 223325
URL: https://gcc.gnu.org/viewcvs?rev=223325&root=gcc&view=rev
Log:
2015-05-18 Steven G. Kargl
PR fortran/66057
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66057
--- Comment #3 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Mon May 18 23:26:38 2015
New Revision: 223326
URL: https://gcc.gnu.org/viewcvs?rev=223326&root=gcc&view=rev
Log:
2015-05-18 Steven G. Kargl
PR fortran/66057
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66181
Thomas Preud'homme changed:
What|Removed |Added
CC||thopre01 at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66168
--- Comment #4 from Thomas Preud'homme ---
Testsuite came back ok. Will post patch shortly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66197
Bug ID: 66197
Summary: c++1z generic function wrong type for auto
Product: gcc
Version: 5.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66197
--- Comment #1 from theonetruekenny at yahoo dot com ---
This might be another symptom of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64969
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66163
--- Comment #9 from Jeffrey A. Law ---
We don't thread because we don't lower UBSAN_NULL to actual conditionals until
the end of the gimple/ssa pipeline. ie, in DOM2 we have:
int test::foo(int&) (struct test * const this, int & b)
{
int _5;
97 matches
Mail list logo
