https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88994
--- Comment #2 from Robin ---
Nice :)
Feel free to ask me any additionnal things if it may help.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88994
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88993
--- Comment #4 from Florian Weimer ---
(In reply to Jakub Jelinek from comment #3)
> Rather than warning about this the bugs should be fixed, there is no reason
> why glibc needs to malloc memory for these cases.
I completely agree. The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89004
Martin Liška changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89004
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89004
Bug ID: 89004
Summary: mtype.c:2329:33: error: comparison of integer
expressions of different signedness: ‘int’ and
‘size_t’ {aka ‘long unsigned int’}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88993
--- Comment #3 from Jakub Jelinek ---
Rather than warning about this the bugs should be fixed, there is no reason why
glibc needs to malloc memory for these cases. For "%.65535s" I don't actually
see where it would allocate memory, I see memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88998
David Zmick changed:
What|Removed |Added
CC||dpzmick at gmail dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88985
Martin Liška changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40598
Jürgen Reuter changed:
What|Removed |Added
CC||juergen.reuter at desy dot de
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88713
--- Comment #33 from Marc Glisse ---
(In reply to Chris Elrod from comment #32)
> (In reply to Marc Glisse from comment #31)
> > What we need to understand is why gcc doesn't try to generate rsqrt
Without -mavx512er, we do not have an expander
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88713
--- Comment #32 from Chris Elrod ---
(In reply to Marc Glisse from comment #31)
> (In reply to Chris Elrod from comment #30)
> > gcc caclulates the rsqrt directly
>
> No, vrsqrt14ps is just the first step in calculating sqrt here (slightly
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89003
Bug ID: 89003
Summary: Return inside a statement expression while
initializing a static local variable fails to cleanup
cxa_guard
Product: gcc
Version: 5.4.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88998
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88713
--- Comment #31 from Marc Glisse ---
(In reply to Chris Elrod from comment #30)
> gcc caclulates the rsqrt directly
No, vrsqrt14ps is just the first step in calculating sqrt here (slightly
different formula than rsqrt). vrcp14ps shows that it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88713
--- Comment #30 from Chris Elrod ---
gcc still (In reply to Marc Glisse from comment #29)
> The main difference I can see is that clang computes rsqrt directly, while
> gcc first computes sqrt and then computes the inverse. Also gcc seems afraid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88713
--- Comment #29 from Marc Glisse ---
The main difference I can see is that clang computes rsqrt directly, while gcc
first computes sqrt and then computes the inverse. Also gcc seems afraid of
getting NaN for sqrt(0) so it masks out this value.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89002
Bug ID: 89002
Summary: ICE in scan_omp_1_op, at omp-low.c:3166
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Keywords: openmp
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88975
--- Comment #1 from Arseny Solokha ---
--- xsihfn9u.c 2019-01-23 09:46:02.954589253 +0700
+++ msyweyyj.c 2019-01-23 09:46:13.439477032 +0700
@@ -4,7 +4,7 @@
int ij[gy];
int sk;
-#pragma omp taskloop reduction(+:ij)
+#pragma omp taskloop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88986
--- Comment #2 from Marek Polacek ---
Started with r244246.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88986
Marek Polacek changed:
What|Removed |Added
Keywords||ice-on-invalid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88987
--- Comment #2 from Marek Polacek ---
Started with r266874.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88987
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89001
Bug ID: 89001
Summary: g++ uses wrong mangling for lifetime-extended
temporaries
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88985
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88996
--- Comment #6 from emsr at gcc dot gnu.org ---
Created attachment 45502
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45502=edit
New patch, C++20 only, several fixes, no memory_order ops.
Retesting.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88996
--- Comment #5 from emsr at gcc dot gnu.org ---
I was a bit surprised I "needed" these. There are apparently some uses of
these.
I'll roll back and show you...
/home/ed/obj/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/atomic_base.h:104:7:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89000
Bug ID: 89000
Summary: gcov --function-summaries says No branches/No calls,
only the File summary is correct
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88713
--- Comment #28 from Chris Elrod ---
Created attachment 45501
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45501=edit
Minimum working example of the rsqrt problem. Can be compiled with: gcc -Ofast
-S -march=skylake-avx512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88999
Bug ID: 88999
Summary: [9 Regression] testcases using in_avail() fail on
nios2-elf
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88998
Bug ID: 88998
Summary: bad codegen with mmx instructions for unordered_map
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88996
--- Comment #4 from Jonathan Wakely ---
+ inline constexpr memory_order
+ operator&(memory_order __m1, memory_order __m2)
+ { return memory_order(int(__m1) & int(__m2)); }
+
+ inline constexpr memory_order
+ operator|(memory_order __m1,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88997
Bug ID: 88997
Summary: Implicit constructors created with line numbers
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88996
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88993
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
--- Comment #2 from Martin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88916
--- Comment #3 from Wojciech Mula ---
A similar case:
---sign.c---
int different_sign(long a, long b) {
return (a >= 0 && b < 0) || (a < 0 && b >= 0);
}
---eof--
This is compiled into:
different_sign:
notq%rdi
movq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88989
--- Comment #2 from Iain Buclaw ---
I thought that the test case looked familiar.
https://issues.dlang.org/show_bug.cgi?id=18057
I had fixed this before in the D implementation branch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88965
--- Comment #8 from Jakub Jelinek ---
Fixed on the trunk so far.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88968
Jakub Jelinek changed:
What|Removed |Added
Summary|[8/9 Regression] Stack |[8 Regression] Stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88965
--- Comment #7 from Jakub Jelinek ---
Author: jakub
Date: Tue Jan 22 22:30:44 2019
New Revision: 268166
URL: https://gcc.gnu.org/viewcvs?rev=268166=gcc=rev
Log:
PR target/88965
* config/rs6000/rs6000.c: Include tree-vrp.h and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88968
--- Comment #5 from Jakub Jelinek ---
Author: jakub
Date: Tue Jan 22 22:28:42 2019
New Revision: 268165
URL: https://gcc.gnu.org/viewcvs?rev=268165=gcc=rev
Log:
PR middle-end/88968
* gimplify.c (gimplify_omp_atomic): Handle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87064
--- Comment #24 from Jakub Jelinek ---
Author: jakub
Date: Tue Jan 22 22:27:32 2019
New Revision: 268164
URL: https://gcc.gnu.org/viewcvs?rev=268164=gcc=rev
Log:
PR target/87064
* config/rs6000/vsx.md (*vsx_reduc__v2df_scalar):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88995
H.J. Lu changed:
What|Removed |Added
Known to work||8.2.0
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88996
--- Comment #2 from emsr at gcc dot gnu.org ---
Still testing BTW.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88996
emsr at gcc dot gnu.org changed:
What|Removed |Added
CC||emsr at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88981
--- Comment #3 from Tom de Vries ---
Thomas,
any comments to add from OpenACC perspective? What is correct or desirable
behaviour?
Thanks,
- Tom
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88996
Bug ID: 88996
Summary: Implement P0439R0 - Make std::memory_order a scoped
enumeration.
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88995
Bug ID: 88995
Summary: [8/9 Regression] internal compiler error: in
lookup_template_class_1, at cp/pt.c:9471
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88579
--- Comment #5 from Thomas Koenig ---
Author: tkoenig
Date: Tue Jan 22 21:23:57 2019
New Revision: 268163
URL: https://gcc.gnu.org/viewcvs?rev=268163=gcc=rev
Log:
2019-01-22 Harald Anlauf
PR fortran/88579
* trans-expr.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57553
--- Comment #7 from Harald Anlauf ---
Patch submitted for review:
https://gcc.gnu.org/ml/fortran/2019-01/msg00201.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88994
Bug ID: 88994
Summary: [GCOV] encoding (or unicode) error with gcov/gcc9 when
generating filename
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87999
Justin Meyer changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88993
--- Comment #1 from Richard W.M. Jones ---
Sorry, forgot the version. It's:
gcc-9.0.0-0.3.fc30.x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88993
Bug ID: 88993
Summary: GCC 9 -Wformat-overflow=2 should reflect real libc
limits
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88497
--- Comment #7 from kelvin at gcc dot gnu.org ---
Here is the original program that motivated my simplified reproducer:
extern void first_dummy ();
extern void dummy (double sacc, int n);
extern void other_dummy ();
extern float opt_value;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88989
--- Comment #1 from Iain Buclaw ---
Thanks.
Out of curiosity, are you fuzz testing?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88347
David Malcolm changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88963
--- Comment #10 from Devin Hussey ---
I also want to add that aarch64 shouldn't even be spilling; it has 32 NEON
registers and with 128 byte vectors it should only use 24.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88984
--- Comment #2 from Jakub Jelinek ---
Created attachment 45498
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45498=edit
gcc9-pr88984.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88347
--- Comment #2 from David Malcolm ---
*** Bug 88423 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88423
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88991
Martin Sebor changed:
What|Removed |Added
Blocks||88443
--- Comment #2 from Martin Sebor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88992
Bug ID: 88992
Summary: missing -Warray-bounds indexing into a zero-length
array
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88979
--- Comment #2 from 19Sebastian95 at gmx dot de ---
I'm sorry if I'm misinterpreting this, but the program I wrote does compile
with gcc 9.0, as the "error" part is commented out, so I'll just write what to
do to get the descriped error:
If my
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88991
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88991
Bug ID: 88991
Summary: missing warning on a strcpy and strlen from a
zero-length array
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88967
--- Comment #10 from Jakub Jelinek ---
firstprivate is that each thread will have its own copy of the variable,
initialized from the original.
shared means there is just one copy.
E.g. if you take the address of the variable within the region,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88469
--- Comment #8 from Richard Earnshaw ---
Author: rearnsha
Date: Tue Jan 22 17:56:02 2019
New Revision: 268160
URL: https://gcc.gnu.org/viewcvs?rev=268160=gcc=rev
Log:
[arm] Further fixes for PR88469
A bitfield that is exactly the same size as
gcc-bugs@gcc.gnu.org
+
氏瑚优 惠 办 理 正 规 税 票，认 证 后 付 款。
详 电：李 生，136—6075— 4190，
业 q：157— 533— 2698
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39795
Dominique d'Humieres changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57297
Dominique d'Humieres changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80257
Dominique d'Humieres changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #23 from Wilco ---
Author: wilco
Date: Tue Jan 22 17:49:46 2019
New Revision: 268159
URL: https://gcc.gnu.org/viewcvs?rev=268159=gcc=rev
Log:
Fix vect-nop-move.c test
Fix a failing test - changes in Combine mean the test now fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88981
--- Comment #2 from Tom de Vries ---
A good thing to note here, when adding #pragma acc wait, the program (compiled
with -O0) takes ~10 seconds to finish on my quadro 1200m.
Without the pragma acc wait, it still takes 10 seconds.
When
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88990
Bug ID: 88990
Summary: ICE in get_symbol_decl, at d/decl.cc:1097
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86164
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88989
Bug ID: 88989
Summary: ICE in resolvePropertiesX, at d/dmd/expression.c:251
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #22 from Wilco ---
(In reply to Steve Ellcey from comment #21)
> If I look at this specific example:
>
> int f2 (int x, int y)
> {
> return (x & ~0x0ff000) | ((y & 0x0ff) << 12);
> }
>
> Is this because of x0 (a hard register)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83754
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88985
Bug ID: 88985
Summary: [9 Regression] ICE in estimate_edge_devirt_benefit, at
ipa-fnsummary.c:2585
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88987
Bug ID: 88987
Summary: [9 Regression] ICE: unexpected expression '(bool)sm'
of kind implicit_conv_expr
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88986
Bug ID: 88986
Summary: [9 Regression] ICE: tree check: expected tree that
contains 'decl minimal' structure, have 'error_mark'
in member_vec_binary_search, at cp/name-lookup.c:1136
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88988
Bug ID: 88988
Summary: [8/9 Regression] ICE: Segmentation fault (in
lookup_name_real_1)
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88967
--- Comment #9 from Roman Lebedev ---
(In reply to Jakub Jelinek from comment #8)
> Well, in your case firstprivate is really what you want, unless the compiler
> figures that out for you magically you want to firstprivatize these
> variables.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84774
Bug 84774 depends on bug 88973, which changed state.
Bug 88973 Summary: [8/9 Regression] New -Wrestrict warning since r268048
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88973
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88973
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88967
--- Comment #8 from Jakub Jelinek ---
Well, in your case firstprivate is really what you want, unless the compiler
figures that out for you magically you want to firstprivatize these variables.
A different thing is of course if you have a large
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88967
--- Comment #7 from Roman Lebedev ---
(In reply to Jakub Jelinek from comment #6)
> No, gcc always implements just one OpenMP version, the latest one that has
> support written.
E.g. because of this everyone affected will need to either just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88294
--- Comment #5 from Marek Polacek ---
I can try. Unfortunately, the patch for 86476 doesn't fix this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88911
--- Comment #3 from David Malcolm ---
Candidate patch: https://gcc.gnu.org/ml/gcc-patches/2019-01/msg01311.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #21 from Steve Ellcey ---
If I look at this specific example:
int f2 (int x, int y)
{
return (x & ~0x0ff000) | ((y & 0x0ff) << 12);
}
Before the combine change, I see in x.c.260r.combine:
Trying 8, 9 -> 15:
8:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88967
--- Comment #6 from Jakub Jelinek ---
No, gcc always implements just one OpenMP version, the latest one that has
support written.
Defaulting to almost 8 years old OpenMP version is weird.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88979
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88973
--- Comment #3 from Martin Sebor ---
Created attachment 45497
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45497=edit
canonicalize_pathname function extracted from the translation unit.
Attached is the canonicalize_pathname function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88909
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88973
Martin Sebor changed:
What|Removed |Added
Blocks||84774
--- Comment #2 from Martin Sebor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88967
--- Comment #5 from Roman Lebedev ---
(In reply to Jakub Jelinek from comment #1)
> I've asked the ifort/clang maintainers about why they keep violating the
> standard, but haven't heard back from them. And I must say I was trying
> hard to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88947
--- Comment #7 from Tomalak Geret'kal ---
(In reply to Tim Shen from comment #5)
> For the original test case, have you tried regex_match() with "what.*"?
That behaves as I'd expect
(http://quick-bench.com/AKdMnnhA03T1vwfN9sf53xlbD6s).
> Do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88938
Uroš Bizjak changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88984
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
1 - 100 of 256 matches
Mail list logo
