[Bug lto/48200] Implement function attribute for symbol versioning (.symver)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200 --- Comment #25 from Xi Ruoyao --- This attribute should also apply to objects.

[Bug lto/48200] linking shared library with LTO results in different exported symbols

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200 --- Comment #22 from Xi Ruoyao --- Created attachment 44126 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44126=edit Patch to add symver attribute, highly experimental, C++ only

[Bug lto/48200] linking shared library with LTO results in different exported symbols

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200 --- Comment #21 from Xi Ruoyao --- I made up a (highly immature) patch in the days. This "thing" works with simple source code files but I believe there are many bugs in the patch. And I suggest to make "weakref" attribute to output ".symver"

[Bug lto/48200] linking shared library with LTO results in different exported symbols

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200 --- Comment #19 from Xi Ruoyao --- I think the best result would be like FMV, for e.g. int foo(void) __attribute__((symver("@1.1"))) { return 0; } int foo(void) __attribute__((symver("@@1.2"))) { return 1; } Would produce two symbols

[Bug lto/48200] linking shared library with LTO results in different exported symbols

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200 --- Comment #18 from Xi Ruoyao --- (In reply to Xi Ruoyao from comment #17) > I prefer > > int pci_fill_info(struct pci_dev *, int) > __attribute__((symver_alias("@LIBPCI_3.0", "pci_fill_info_v31"))); But then what should we do for int

[Bug lto/48200] linking shared library with LTO results in different exported symbols

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200 --- Comment #17 from Xi Ruoyao --- (In reply to Richard Biener from comment #16) > We might want to add a function attribute to allow to specify symver, so like > > int pci_fill_info_v31(struct pci_dev *d, int flags) >

[Bug lto/48200] linking shared library with LTO results in different exported symbols

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200 --- Comment #15 from Xi Ruoyao --- (In reply to Jan Hubicka from comment #13) > Concerning comment #11, if you have toplevel asms you need to disable LTO > for that unit, as there is no way to tell for gcc what the asm statement is > doing.

[Bug lto/48200] linking shared library with LTO results in different exported symbols

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200 --- Comment #14 from Xi Ruoyao --- (In reply to Jan Hubicka from comment #13) > What is status of this bug in general? I must admit I thought we have issues > long solved here :( It still exists in 8.1. Libstdc++ uses top level asm statement

[Bug lto/48200] linking shared library with LTO results in different exported symbols

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200 Xi Ruoyao changed: What|Removed |Added CC||ryxi at stu dot xidian.edu.cn --- Comment

[Bug c++/80038] [6/7 Regression] Random segfault using local vectors in Cilk function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80038 --- Comment #34 from Xi Ruoyao --- On 2017-12-04 11:05 +, paolo.carlini at oracle dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80038 > > Paolo Carlini changed: > >    What|Removed |Added >

[Bug rtl-optimization/82602] IRA considers volatile asm to be moveable

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82602 --- Comment #8 from Xi Ruoyao --- (In reply to David Brown from comment #7) > There is no intention to make "asm volatile" a barrier, as you get with a > memory clobber. The intention is to stop it moving past other volatile code > (such as

[Bug rtl-optimization/82602] IRA considers volatile asm to be moveable

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82602 --- Comment #4 from Xi Ruoyao --- By the way, in kernel code (compiler-gcc.h) there is a comment: /* The "volatile" is due to gcc bugs */ #define barrier() __asm__ __volatile__("": : :"memory") So the developer(s) actually think "volatile" is

[Bug rtl-optimization/82602] IRA considers volatile asm to be moveable

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82602 Xi Ruoyao changed: What|Removed |Added CC||ryxi at stu dot xidian.edu.cn --- Comment

[Bug c++/81932] Template arguments of type unsigned generate incorrect debugging information

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81932 --- Comment #27 from Xi Ruoyao --- (In reply to Jonathan Wakely from comment #26) > The demangled names are not in a canonical/standardized format, or > unambiguous, or portable between different compilers, so that isn't a > complete solution.

[Bug c++/81932] Template arguments of type unsigned generate incorrect debugging information

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81932 --- Comment #24 from Xi Ruoyao --- (In reply to Paul Smith from comment #23) > The lookup_type() was just to show the problem more clearly: I don't do that > in my actual Python code. This part (or something similar) is what I use: > > class

[Bug c++/81932] Template arguments of type unsigned generate incorrect debugging information

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81932 --- Comment #20 from Xi Ruoyao --- (In reply to Martin Sebor from comment #18) > GDB already has a C++ parser. It just isn't good enough. It understands > that B and B are one and the same type but it > interprets A<2> and A<2u> as distinct.

[Bug driver/81829] [7 Regression] /usr/bin/gcc-{ar,nm,ranlib} segfault without arguments

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81829 --- Comment #5 from Xi Ruoyao --- (In reply to Martin Liška from comment #4) > (In reply to Xi Ruoyao from comment #3) > > marxin's patch: > > > > http://gcc.gnu.org/ml/gcc-patches/2017-08/msg01116.html > > > > But this patch doesn't work

[Bug driver/81829] [7 Regression] /usr/bin/gcc-{ar,nm,ranlib} segfault without arguments

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81829 --- Comment #3 from Xi Ruoyao --- marxin's patch: http://gcc.gnu.org/ml/gcc-patches/2017-08/msg01116.html But this patch doesn't work while /my_bin/bin contains a symlink.

[Bug driver/81991] gcc-ar segfaults if we run it with the full path

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81991 --- Comment #2 from Xi Ruoyao --- > --- Comment #1 from Andrew Pinski --- > Dup. > Oh. Only searched with term gcc-ar and didn't find PR81829.

[Bug driver/81991] New: gcc-ar segfaults if we run it with the full path

: driver Assignee: unassigned at gcc dot gnu.org Reporter: ryxi at stu dot xidian.edu.cn Target Milestone: --- From r238089: $ /usr/bin/gcc-ar Segmentation fault (core dumped) This issue prevents the building of ATLAS. Its configure script tries to run gcc-ar with the full

[Bug c++/81932] Template arguments of type unsigned generate incorrect debugging information

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81932 --- Comment #17 from Xi Ruoyao --- (In reply to Martin Sebor from comment #15) > (In reply to Xi Ruoyao from comment #14) > > The symbols in your example are the result/ouput of demangling but the issue > reported here is with the symbols that

[Bug c++/81932] Template arguments of type unsigned generate incorrect debugging information

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81932 --- Comment #14 from Xi Ruoyao --- (In reply to Martin Sebor from comment #13) > (In reply to Xi Ruoyao from comment #11) > > The target demangler is (or can be) different on each target and, as I said, > different producers use different

[Bug c++/81932] Template arguments of type unsigned generate incorrect debugging information

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81932 --- Comment #11 from Xi Ruoyao --- (In reply to Martin Sebor from comment #10) > Unless the exact format for non-type template arguments is specified in > DWARF (I don't think it is) it seems that a more robust solution is to > enhance GDB to be

[Bug c++/81932] Template arguments of type unsigned generate incorrect debugging information

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81932 --- Comment #9 from Xi Ruoyao --- (In reply to Xi Ruoyao from comment #8) > I'll try more -gxxx options to see if we need a new flag. This works for: -g -g2 -g3 -ggdb -ggdb2 -ggdb3 -gdwarf -gdwarf-{2,3,4} -gdwarf -gstrict-dwarf -g -gz Not

[Bug c++/81932] Template arguments of type unsigned generate incorrect debugging information

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81932 --- Comment #8 from Xi Ruoyao --- (In reply to Paul Smith from comment #7) > I'm not sure what the impacts of "if (pp->flags & pp_c_flag_gnu_v3)" are; > does this mean it only works if you specify -ggdb3? Is that the right > thing? I don't

[Bug c++/81932] Template arguments of type unsigned generate incorrect debugging information

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81932 --- Comment #6 from Xi Ruoyao --- Created attachment 42038 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42038=edit patch proposal This patch turn on the type suffix of integer constants in debug info. It's not tested well yet.

[Bug c++/81932] Template arguments of type unsigned generate incorrect debugging information

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81932 --- Comment #5 from Xi Ruoyao --- Martin said Clang doesn't output the suffix at all, so I tested Clang 4.0. It also suffers this warning.

[Bug c++/81932] Template arguments of type unsigned generate incorrect debugging information

, ||ryxi at stu dot xidian.edu.cn --- Comment #4 from Xi Ruoyao --- It starts form r243461: PR c/78165 - avoid printing type suffix for constants in %E output gcc/c-family/ChangeLog: PR c/78165 * c-pretty-print (pp_c_integer_constant): Avoid

[Bug other/32415] libgcc_s not found in library search path with --enable-version-specific-runtime-libs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32415 Xi Ruoyao changed: What|Removed |Added CC||ryxi at stu dot xidian.edu.cn --- Comment

[Bug middle-end/81172] Expected new warning option -Warray-bounds-pointer-arithmetic

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81172 --- Comment #5 from Xi Ruoyao --- (In reply to Martin Sebor from comment #4) > Clang diagnoses the the cases where the offset or index is a constant > expression (and under the expected option) but it doesn't diagnose others > where the

[Bug middle-end/81172] Expected new warning option -Warray-bounds-pointer-arithmetic

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81172 Xi Ruoyao changed: What|Removed |Added Summary|Improve -Warray-bounds for |Expected new warning option

[Bug middle-end/81172] Improve -Warray-bounds for address arithmetic

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81172 --- Comment #2 from Xi Ruoyao --- (In reply to Andrew Pinski from comment #1) > The first one is well defined by C/C++. [expr.add] para 4: When an expression that has integral type is added to or subtracted from a pointer, the result has the

[Bug middle-end/81172] New: Improve -Warray-bounds for address arithmetic

: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: ryxi at stu dot xidian.edu.cn Target Milestone: --- The address arithmetics producing pointers out of the array bound is undefined behaviour and should be warned by -Warray-bounds. For example > int a[] = {1,2,

[Bug c++/62181] [C/C++] Expected new warning: "adding 'char' to a string does not append to the string" [-Wstring-plus-int]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62181 --- Comment #10 from Xi Ruoyao --- A series of patch sent to gcc-patches:

[Bug c++/80683] Exceptions don't propagate through default member initializer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80683 --- Comment #5 from Xi Ruoyao --- The issue is in cp/method.c: /* If that user-written default constructor would satisfy the requirements of a constexpr constructor (7.1.5), the implicitly-defined default constructor is constexpr.

[Bug c++/80683] Exceptions don't propagate through default member initializer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80683 --- Comment #3 from Xi Ruoyao --- For debug purpose, compiled this code in C++98 mode (non-static data member initializers is a GNU extension in C++98 and would be warned). The result is still buggy. Defaulted B::B() is marked noexcept.

[Bug c++/80683] Exceptions don't propagate through default member initializer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80683 --- Comment #2 from Xi Ruoyao --- I don't think it's PR66139. In PR66139, the exception is caught, but some destructors aren't called. In this PR, the exception is not caught at all. For this PR, the problem is: 1) GCC created "constexpr

[Bug c++/66139] destructor not called for members of partially constructed anonymous struct/array

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66139 --- Comment #12 from Xi Ruoyao --- (In reply to Jaak Ristioja from comment #9) > [1]: http://stackoverflow.com/a/43892501/3919155 I don't think this is the same bug. This bug seems happening because GCC created "constexpr B::B(void)", but

[Bug c++/66139] destructor not called for members of partially constructed anonymous struct/array

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66139 --- Comment #11 from Xi Ruoyao --- This happens for all TARGET_EXPRs with the third operand (cleanup expression), as an INIT_EXPR's rhs. The cleanup sequence are pushed in gimplify_target_expr, which doesn't handle TARGET_EXPRs as the

[Bug c++/66139] destructor not called for members of partially constructed anonymous struct/array

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66139 --- Comment #7 from Xi Ruoyao --- std::basic_string<...> is too large. Replace it with a dummy default constructable and copyable class Foo. Then get GIMPLE: _1 = &->a; _2 = std::vector::at (, 0); Foo::Foo (_1,

[Bug c++/80038] [6/7 Regression] Random segfault using local vectors in Cilk function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80038 --- Comment #29 from Xi Ruoyao --- https://gcc.gnu.org/ml/gcc-patches/2017-03/msg01563.html Patch proposal

[Bug c++/80038] Random segfault using local vectors in Cilk function [Regression 6/7]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80038 --- Comment #28 from Xi Ruoyao --- Created attachment 41028 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41028=edit testcase

[Bug c++/80038] Random segfault using local vectors in Cilk function [Regression 6/7]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80038 --- Comment #27 from Xi Ruoyao --- Created attachment 41027 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41027=edit patch proposal Now I've prepared a patch. It reverted r227423 (but preserved its testcase) and used a more conforming

[Bug c++/80038] Random segfault using local vectors in Cilk function [Regression 6/7]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80038 --- Comment #26 from Xi Ruoyao --- Reverting r227423 makes both Florent's and NumericMonoid code work. But it reintroduced pr60586. Trying to solve it.

[Bug c++/80038] Random segfault using local vectors in Cilk function [Regression 6/7]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80038 --- Comment #25 from Xi Ruoyao --- I confirmed that r227423 broke NumericMonoid.

[Bug c++/80038] Random segfault using local vectors in Cilk function [Regression 6/7]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80038 --- Comment #24 from Xi Ruoyao --- The cilkplus spec described an "unsymmetrical" construct/destruct of temp variables. It seems difficult to implement in GCC. I'm trying to find a solution.

[Bug middle-end/60586] [Cilk+] Parameters evaluation happens inside spawn worker

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60586 --- Comment #5 from Xi Ruoyao --- (In reply to Xi Ruoyao from comment #4) > Balaji's commit caused PR80038. However without this commit, PR80038's > test case just ICE. More analysis required. Sorry I misunderstood the commit log. Ignore

[Bug c++/80038] Random segfault using local vectors in Cilk function [Regression 6/7]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80038 --- Comment #23 from Xi Ruoyao --- Sorry. I was too tired so I misunderstood r227423. Now I am not sure whether it introduced the bug. I'll test it with NumericMonoid code.

[Bug c++/80038] Random segfault using local vectors in Cilk function [Regression 6/7]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80038 --- Comment #22 from Xi Ruoyao --- PR 60586 is a false PR to an expected behaviour... Unfortunately nobody noticed that and someone "fixed" it. But without r227423 GCC just ICE on the testcase.

[Bug middle-end/60586] [Cilk+] Parameters evaluation happens inside spawn worker

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60586 Xi Ruoyao changed: What|Removed |Added CC||ryxi at stu dot xidian.edu.cn --- Comment

[Bug c++/80038] Random segfault using local vectors in Cilk function [Regression 6/7]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80038 --- Comment #21 from Xi Ruoyao --- Start from r227423. Fix spawned function with lambda function Make sure that the spawned function's arguments will not be pushed into lambda function. gcc/c-family/ 2015-09-02 Balaji V. Iyer

[Bug c++/80038] Random segfault using local vectors in Cilk function [Regression 6/7]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80038 --- Comment #20 from Xi Ruoyao --- On 2017-03-16 12:31 +, cont...@edgar-fournival.fr wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80038 > > --- Comment #19 from Edgar Fournival --- > Thanks for your

[Bug c++/80038] Random segfault using local vectors in Cilk function [Regression 6/7]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80038 --- Comment #18 from Xi Ruoyao --- > Compile with '-fcilkplus -S'. According to cilkplus spec, x() should be > evaluated in the child (for the asm produced by GCC, in _cilk_spn_0). > If you find "call x" in the asm of "z" instead of

[Bug c++/80038] Random segfault using local vectors in Cilk function [Regression 6/7]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80038 --- Comment #17 from Xi Ruoyao --- A simple test case for bisecting: extern "C" { int x(); int y(int); int z(); } int z() { int ret = _Cilk_spawn y(x()); return ret; } Compile with '-fcilkplus -S'. According to cilkplus spec, x() should

[Bug c++/80038] Random segfault using local vectors in Cilk function [Regression 6/7]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80038 --- Comment #16 from Xi Ruoyao --- On 2017-03-16 10:16 +, cont...@edgar-fournival.fr wrote: > Bisection? I am bisecting now.

[Bug c++/80038] Random segfault using local vectors in Cilk function [Regression 6/7]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80038 --- Comment #14 from Xi Ruoyao --- (In reply to Florent Hivert from comment #13) > I've not yet been able to find a small example that shows the regression due > to GCC5 ICE. In particular, I'm not sure the problem mentioned by Fournival > is

[Bug c++/80038] Random segfault using local vectors in Cilk function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80038 --- Comment #12 from Xi Ruoyao --- (In reply to Edgar Fournival from comment #11) > It is also interesting to note that GCC 5.x is not impacted. > > Even if the given example code will not compile on GCC 5 (ICE in lower_stmt, > at

[Bug c++/62181] [C/C++] Expected new warning: "adding 'char' to a string does not append to the string" [-Wstring-plus-int]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62181 --- Comment #8 from Xi Ruoyao --- (In reply to Xi Ruoyao from comment #7) > We should make a new PR requesting for clang -Warray-bounds as well. It's > a part of meta-bug PR30334. Sorry. We have -Warray-bounds, but not as well as clang's.

[Bug c++/62181] [C/C++] Expected new warning: "adding 'char' to a string does not append to the string" [-Wstring-plus-int]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62181 --- Comment #7 from Xi Ruoyao --- (In reply to Martin Sebor from comment #6) > With constant arguments (or those whose value or range is known), GCC should > warn on the first declaration in comment #0 (copied below) not necessarily > because

[Bug c++/80038] Random segfault using local vectors in Cilk function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80038 --- Comment #10 from Xi Ruoyao --- (In reply to Richard Biener from comment #3) > which means the spawned copies use a shared vnew and a single destructor > is run "afterwards". If there's no synchronization then all threads will > call the

[Bug c++/80038] Random segfault using local vectors in Cilk function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80038 Xi Ruoyao changed: What|Removed |Added CC||ryxi at stu dot xidian.edu.cn --- Comment

[Bug c++/80045] [cilkplus] The destruction of the temporary variable is not in the child

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80045 Xi Ruoyao changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug c++/80045] [cilkplus] The destruction of the temporary variable is not in the child

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80045 --- Comment #2 from Xi Ruoyao --- On 2017-03-15 10:50 +, florent.hivert at lri dot fr wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80045 > > --- Comment #1 from Florent Hivert --- > I'm not sure why you created a new report. I

[Bug c++/80045] New: [cilkplus] The destruction of the temporary variable is not in the child

Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ryxi at stu dot xidian.edu.cn Target Milestone: --- The cilkplus spec <https://www.cilkplus.org/sites/default/files/open_specifications/Intel_Cilk_plus_lang_spec_1.2.htm>

[Bug c++/62181] [C/C++] Expected new warning: "adding 'char' to a string does not append to the string" [-Wstring-plus-int]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62181 --- Comment #5 from Xi Ruoyao --- Some clang-5.0 warning case: ~~~ Wstring-plus-int.c:20:24: warning: adding 'int' to a string does not append to the string [-Wstring-plus-int] const char *a = "aa" + 'a'; /* { dg-warning "does not append" }

[Bug c++/62181] [C/C++] Expected new warning: "adding 'char' to a string does not append to the string" [-Wstring-plus-int]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62181 Xi Ruoyao changed: What|Removed |Added CC||ryxi at stu dot xidian.edu.cn --- Comment

[Bug libstdc++/67578] std::random_device::entropy() always returns 0

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67578 --- Comment #2 from Xi Ruoyao --- (In reply to Xi Ruoyao from comment #1) > Or maybe we should keep the ABI unchanged and put all the implementation > in the header random.h? No. It would then pollute the global namespace with sys/ioctl.h and

[Bug libstdc++/67578] std::random_device::entropy() always returns 0

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67578 Xi Ruoyao changed: What|Removed |Added CC||ryxi at stu dot xidian.edu.cn --- Comment

[Bug c++/69138] Woverflow not triggered for constexpr within template class

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69138 --- Comment #4 from Xi Ruoyao --- Created attachment 40950 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40950=edit Another way to show this bug This test case also exploits this bug. In this lim should be the same as limlong, but g++

[Bug c++/69138] Woverflow not triggered for constexpr within template class

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69138 Xi Ruoyao changed: What|Removed |Added CC||ryxi at stu dot xidian.edu.cn --- Comment

[Bug libstdc++/79833] std::put_time has the wrong values for 2 digit years

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79833 Xi Ruoyao changed: What|Removed |Added CC||ryxi at stu dot xidian.edu.cn --- Comment

[Bug libstdc++/67214] undefined behaviour in std::num_get::_M_extract_int()

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67214 --- Comment #2 from Xi Ruoyao --- Created attachment 40946 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40946=edit patch for this PR Since GCC 7 is in stage 4, this patch will be committed in GCC 8 stage 1.

[Bug libstdc++/67214] undefined behaviour in std::num_get::_M_extract_int()

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67214 Xi Ruoyao changed: What|Removed |Added CC||ryxi at stu dot xidian.edu.cn --- Comment

[Bug libstdc++/62045] [5/6/7 Regression] __gnu_pbds::priority_queue<int, less, binary_heap_tag> is too slow

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62045 --- Comment #9 from Xi Ruoyao --- > Please note that libstdc++ patches need to be sent to the libstdc++ list as > well, see the policies at https://gcc.gnu.org/lists.html Sorry. I didn't notice that. Resent thread:

[Bug libstdc++/62045] __gnu_pbds::priority_queue<int, less, binary_heap_tag> is too slow

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62045 --- Comment #6 from Xi Ruoyao --- Created attachment 40941 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40941=edit performance test result with the patch

[Bug libstdc++/62045] __gnu_pbds::priority_queue<int, less, binary_heap_tag> is too slow

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62045 --- Comment #5 from Xi Ruoyao --- Patch proposal: https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00516.html

[Bug libstdc++/62045] __gnu_pbds::priority_queue<int, less, binary_heap_tag> is too slow

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62045 --- Comment #4 from Xi Ruoyao --- > This is certainly a bug making priority_queue::push O(n^2). > Since it works correctly in GCC 4.6, it's a regression. Sorry. s/O(n^2)/O(n)/.

[Bug libstdc++/62045] __gnu_pbds::priority_queue<int, less, binary_heap_tag> is too slow

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62045 --- Comment #3 from Xi Ruoyao --- Both Tobias' and my thought was wrong. In the entry of __gnu_pbds::detail::binary_heap::push_heap, the array m_a_entries[0..m_size-2] contains a heap, and m_a_entries[m_size-1] contains the element being pushed

[Bug libstdc++/62045] __gnu_pbds::priority_queue<int, less, binary_heap_tag> is too slow

, ||ryxi at stu dot xidian.edu.cn --- Comment #1 from Xi Ruoyao --- A simple stupid test case: ~~~ #include #include __gnu_pbds::priority_queue<int, std::less, __gnu_pbds::binary_heap_tag> pq; extern "C" unsigned alarm (unsi

[Bug libstdc++/79162] [7 Regression] [C++17] ambiguity in string assignment due to string_view overload

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79162 --- Comment #2 from Xi Ruoyao --- > Seems similar to LWG 2758. http://cplusplus.github.io/LWG/lwg-defects.html#2758

[Bug libstdc++/79162] [7 Regression] [C++17] ambiguity in string assignment due to string_view overload

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79162 Xi Ruoyao changed: What|Removed |Added CC||ryxi at stu dot xidian.edu.cn --- Comment

[Bug rtl-optimization/79728] [7 Regression] ICE in setup_pressure_classes, at ira.c:912

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79728 --- Comment #5 from Xi Ruoyao --- (In reply to Bernd Schmidt from comment #4) > Actually here's mine from last week: > https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00176.html So please ignore my mumble...

[Bug rtl-optimization/79728] [7 Regression] ICE in setup_pressure_classes, at ira.c:912

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79728 Xi Ruoyao changed: What|Removed |Added CC||ryxi at stu dot xidian.edu.cn --- Comment