https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106558
--- Comment #17 from Yuri Gribov ---
Fix has been approved
(https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606858.html), I hope
to merge it soon.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106558
--- Comment #13 from Yuri Gribov ---
Posted to gcc-patches:
https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601041.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106558
--- Comment #11 from Yuri Gribov ---
Created attachment 53493
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53493&action=edit
Updated patch
Here is an updated patch which passes bootstrap-asan (I haven't run the
testsuite yet).
It resul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106558
--- Comment #8 from Yuri Gribov ---
(In reply to Jakub Jelinek from comment #7)
I've started work on this but I'll probly only have enough time to cook a patch
on weekend.
> Perhaps either a quick check that for base ptrs that live in memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106558
Yuri Gribov changed:
What|Removed |Added
CC||tetra2005 at gmail dot com
--- Comment
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: tetra2005 at gmail dot com
CC: jakub at gcc dot gnu.org
Target Milestone: ---
Created attachment 51811
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51811&action=edit
Re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95550
--- Comment #2 from Yuri Gribov ---
The promised repro:
SUBROUTINE FOO()
INTEGER :: I
COMPLEX(8), ALLOCATABLE :: GWORK(:)
ALLOCATE(GWORK(512))
!$ACC PARALLEL LOOP PRIVA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93554
Yuri Gribov changed:
What|Removed |Added
CC||tetra2005 at gmail dot com
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95550
Yuri Gribov changed:
What|Removed |Added
CC||tetra2005 at gmail dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102310
Yuri Gribov changed:
What|Removed |Added
CC||tetra2005 at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85822
--- Comment #9 from Yuri Gribov ---
Thanks for commiting this. Review on gcc-patches went stale...
On Wed, May 23, 2018 at 8:41 AM, marxin at gcc dot gnu.org
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85822
>
> --- Comment #8 from Ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85822
--- Comment #6 from Yuri Gribov ---
(In reply to Richard Biener from comment #5)
> Created attachment 44145 [details]
> patch I am testing
>
> I am testing the attached. Please check how negative values can be handled
> correctly or why exactly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85822
--- Comment #3 from Yuri Gribov ---
It seems these lines in is_masked_range_test should be removed:
if (wi::neg_p (val, TYPE_SIGN (type)))
std::swap (*low, *high);
Sadly there were no tests which tested negative constants. I'll bootstrap an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85822
Yuri Gribov changed:
What|Removed |Added
CC||tetra2005 at gmail dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59521
--- Comment #14 from Yuri Gribov ---
Patch posted in https://gcc.gnu.org/ml/gcc-patches/2017-07/msg01016.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54123
Yuri Gribov changed:
What|Removed |Added
CC||tetra2005 at gmail dot com
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81376
Yuri Gribov changed:
What|Removed |Added
CC||tetra2005 at gmail dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59521
Yuri Gribov changed:
What|Removed |Added
Attachment #41737|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59521
--- Comment #10 from Yuri Gribov ---
(In reply to Martin Liška from comment #9)
> The patch works for me for the described case, but does not for PGO, which
> should do the same based on real numbers:
Problem here is that we optimize only very_l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59521
Yuri Gribov changed:
What|Removed |Added
Attachment #41698|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59521
--- Comment #7 from Yuri Gribov ---
(In reply to Martin Liška from comment #5)
> Apart from that I added code that preserves
> that probability in combine_predictions_for_bb.
Yes, I did pretty much the same locally)
> But still there's a missin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41992
Yuri Gribov changed:
What|Removed |Added
CC||tetra2005 at gmail dot com
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80027
--- Comment #7 from Yuri Gribov ---
(In reply to Michael Thayer from comment #6)
> Yuri, my initial description should still apply, though I haven't tested
> this recently. The follow-up comments were Maxim trying to help me with a
> work-around
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69908
--- Comment #7 from Yuri Gribov ---
(In reply to Marc Glisse from comment #6)
> (In reply to Yuri Gribov from comment #5)
> > Well, as we all know there are a lot of missing optimizations in GCC :) I
> > think the real question is whether it's ev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69908
--- Comment #5 from Yuri Gribov ---
(In reply to Marc Glisse from comment #4)
> (In reply to Yuri Gribov from comment #3)
> > As noted in comments, this is more about adding new API to Glibc than GCC
> > (they have corresponding
> > https://sourc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69908
--- Comment #3 from Yuri Gribov ---
As noted in comments, this is more about adding new API to Glibc than GCC (they
have corresponding https://sourceware.org/bugzilla/show_bug.cgi?id=19920 about
this). So can this be closed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55546
Yuri Gribov changed:
What|Removed |Added
CC||tetra2005 at gmail dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80027
Yuri Gribov changed:
What|Removed |Added
CC||tetra2005 at gmail dot com
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78028
Yuri Gribov changed:
What|Removed |Added
CC||tetra2005 at gmail dot com
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61995
Yuri Gribov changed:
What|Removed |Added
CC||tetra2005 at gmail dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60892
Yuri Gribov changed:
What|Removed |Added
CC||tetra2005 at gmail dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61771
Yuri Gribov changed:
What|Removed |Added
CC||tetra2005 at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63245
Yuri Gribov changed:
What|Removed |Added
CC||tetra2005 at gmail dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61693
Yuri Gribov changed:
What|Removed |Added
CC||tetra2005 at gmail dot com
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78654
Yuri Gribov changed:
What|Removed |Added
CC||tetra2005 at gmail dot com
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62307
Yuri Gribov changed:
What|Removed |Added
CC||tetra2005 at gmail dot com
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55316
Yuri Gribov changed:
What|Removed |Added
CC||tetra2005 at gmail dot com
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58841
Yuri Gribov changed:
What|Removed |Added
CC||tetra2005 at gmail dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59521
Yuri Gribov changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #3 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59521
Yuri Gribov changed:
What|Removed |Added
CC||tetra2005 at gmail dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77631
Yuri Gribov changed:
What|Removed |Added
CC||tetra2005 at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67165
Yuri Gribov changed:
What|Removed |Added
CC||tetra2005 at gmail dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57371
Yuri Gribov changed:
What|Removed |Added
CC||tetra2005 at gmail dot com
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80565
--- Comment #8 from Yuri Gribov ---
(In reply to H.J. Lu from comment #5)
> Why isn't the testcase checked into gcc testsuite?
Sorry, forgot... Thanks for adding.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79224
Yuri Gribov changed:
What|Removed |Added
CC||tetra2005 at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80565
--- Comment #4 from Yuri Gribov ---
Chengnian, is this resolved?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80565
Yuri Gribov changed:
What|Removed |Added
CC||tetra2005 at gmail dot com
--- Comment #2
,
||tetra2005 at gmail dot com
--- Comment #2 from Yuri Gribov ---
There is a more important optimization hiding here.
Standard suggests (in 3.8.7, in n3690.pdf) that when the same source variable
is used for the instance pointer, it's dynamic type should not c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67328
--- Comment #8 from Yuri Gribov ---
Alan,(In reply to Alan Modra from comment #0)
> It looks like gcc incorrectly prefers a range test.
Alan, can we close this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59454
--- Comment #5 from Yuri Gribov ---
(In reply to Martin Liška from comment #4)
> I'm pasting here Jakub's opinion which I agree with:
>
> ```
> I'm strongly against the blacklist, that is not the way things are done in
> GCC, you have correspond
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81089
--- Comment #8 from Yuri Gribov ---
(In reply to Markus Trippelsdorf from comment #7)
> You could try again: https://cfarm.tetaneutral.net/users/new/
> From what I understand they have a new admin team in place.
> In the past the account creatio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81089
--- Comment #6 from Yuri Gribov ---
(In reply to Markus Trippelsdorf from comment #5)
> (In reply to Yuri Gribov from comment #4)
> > Created attachment 41551 [details]
> > Draft patch
> >
> > Here's a draft patch. It fixes the repro but bootstr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81089
--- Comment #4 from Yuri Gribov ---
Created attachment 41551
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41551&action=edit
Draft patch
Here's a draft patch. It fixes the repro but bootstrapping will take some time
on my notebook.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81089
--- Comment #3 from Yuri Gribov ---
Mine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67731
--- Comment #6 from Yuri Gribov ---
(In reply to rguent...@suse.de from comment #5)
> On Fri, 9 Jun 2017, tetra2005 at gmail dot com wrote:
>
> > This should probly go to reassoc? Or better keep it in folder?
>
> As loa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67731
Yuri Gribov changed:
What|Removed |Added
CC||tetra2005 at gmail dot com
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61118
--- Comment #11 from Yuri Gribov ---
(In reply to Tavian Barnes from comment #10)
> > I think it is - __cancel_arg is assigned inside a while loop
>
> Specifically a do { } while(0); loop, which obviously has only one iteration.
Actually I was
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61118
--- Comment #9 from Yuri Gribov ---
(In reply to Tavian Barnes from comment #7)
> But this condition is not met:
>
>> - They are changed between the setjmp() invocation and longjmp() call.
I think it is - __cancel_arg is assigned inside a while
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61118
--- Comment #8 from Yuri Gribov ---
(In reply to Yuri Gribov from comment #6)
> the warning is issued for variables which are alive after return
> from longjmp
Meant setjmp of course.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61118
Yuri Gribov changed:
What|Removed |Added
CC||tetra2005 at gmail dot com
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56727
--- Comment #12 from Yuri Gribov ---
(In reply to Jakub Jelinek from comment #10)
> (In reply to Yuri Gribov from comment #9)
> > (In reply to Alexander Monakov from comment #8)
> > > Well, if my argument is correct, then GCC generates wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67328
--- Comment #6 from Yuri Gribov ---
(In reply to Oleg Endo from comment #5)
> PR 67731 maybe related or dup?
Related but not a dup. This bug is caused by frontend folding two bitfield
accesses to a single comparison which prevented generation of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67328
Yuri Gribov changed:
What|Removed |Added
CC||tetra2005 at gmail dot com
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40528
Yuri Gribov changed:
What|Removed |Added
CC||tetra2005 at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56727
--- Comment #9 from Yuri Gribov ---
(In reply to Alexander Monakov from comment #8)
> Well, if my argument is correct, then GCC generates wrong code for the very
> first example in comment #0.
I believe it does (see my #5, most probly author of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56727
--- Comment #7 from Yuri Gribov ---
(In reply to Alexander Monakov from comment #6)
> Note that even without symbol aliases, such calls are not necessarily
> self-recursive when 'f' is first called via dlsym with RTLD_NEXT or a
> specific module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56727
Yuri Gribov changed:
What|Removed |Added
CC||tetra2005 at gmail dot com
--- Comment #5
,
||tetra2005 at gmail dot com
--- Comment #1 from Yuri Gribov ---
Sounds like an important use-case. I did some basic debugging and it turns out
that "&d[3] - 10" is represented as POINTER_PLUS_EXPR with (size_t)-10 offset.
For some reason tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66826
--- Comment #6 from Yuri Gribov ---
(In reply to Rich Felker from comment #5)
> maybe there are workarounds glibc could do to prevent tco without needing a
> new attribute...
X-posted to Glibc BZ: https://sourceware.org/bugzilla/show_bug.cgi?id=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67336
Yuri Gribov changed:
What|Removed |Added
CC||tetra2005 at gmail dot com
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58120
Yuri Gribov changed:
What|Removed |Added
CC||tetra2005 at gmail dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66826
--- Comment #4 from Yuri Gribov ---
As this is not a GCC bug I suggest you
* close this issue (as not-a-bug?)
* report to Glibc folks (perhaps they could do more checking of return address
or at least document their calling convention assumptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66826
Yuri Gribov changed:
What|Removed |Added
CC||tetra2005 at gmail dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69908
Yuri Gribov changed:
What|Removed |Added
CC||tetra2005 at gmail dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71445
Yuri Gribov changed:
What|Removed |Added
CC||tetra2005 at gmail dot com
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69050
Yuri Gribov changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
: other
Assignee: unassigned at gcc dot gnu.org
Reporter: tetra2005 at gmail dot com
Target Milestone: ---
Libbacktrace performs a bsearch with unit_addrs_search over address range
array. Prior to this list is qsorted with unit_addrs_compare. The algorithms in
these two functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66046
--- Comment #2 from Yuri Gribov ---
The question is what's more appropriate. Doing this repetative work like this
demotivates folks. But if Marek promises to never add newlines to his regexps
again we can submit another cleanup patch :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57271
Yuri Gribov changed:
What|Removed |Added
CC||tetra2005 at gmail dot com
--- Comment #8
,
||tetra2005 at gmail dot com
--- Comment #3 from Yuri Gribov ---
This is probably duplicate of #61897 .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61875
Yuri Gribov changed:
What|Removed |Added
CC||tetra2005 at gmail dot com
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62141
Yuri Gribov changed:
What|Removed |Added
CC||tetra2005 at gmail dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62060
Yuri Gribov changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62060
Yuri Gribov changed:
What|Removed |Added
CC||kcc at gcc dot gnu.org
--- Comment #4 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61547
Yuri Gribov changed:
What|Removed |Added
CC||tetra2005 at gmail dot com
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61530
Yuri Gribov changed:
What|Removed |Added
CC||tetra2005 at gmail dot com
--- Comment #5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60681
--- Comment #3 from Yuri Gribov ---
(In reply to Yuri Gribov from comment #2)
> I think this needs to be fixed (or rather implemented) in QEMU.
QEMU bug: https://bugs.launchpad.net/qemu/+bug/1299190
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60681
Yuri Gribov changed:
What|Removed |Added
CC||tetra2005 at gmail dot com
--- Comment #2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59585
--- Comment #4 from Yuri Gribov ---
Yup, thanks.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59454
--- Comment #2 from Yuri Gribov ---
Proper link to Fortran attr bug:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41209
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59454
Yuri Gribov changed:
What|Removed |Added
CC||tetra2005 at gmail dot com
--- Comment #1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58718
--- Comment #7 from Yuri Gribov ---
(In reply to Kostya Serebryany from comment #6)
> Can we keep this bug in one place, please?
> Let https://code.google.com/p/address-sanitizer/issues/detail?id=239 be the
> primary one
Ok, will do. I'm a littl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58680
--- Comment #2 from Yuri Gribov ---
/* Answering from my personal account */
According to http://marc.info/?t=13645834152 this may not be a problem for
Android. It seems that NDK links shared libs with -Bsymbolic which should
prevent interpos
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41809
Yuri Gribov changed:
What|Removed |Added
CC||tetra2005 at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41809
--- Comment #3 from Yuri Gribov 2012-10-18
11:38:45 UTC ---
Created attachment 28481
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28481
Another testcase
Testcase which demonstrates more issues.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53831
--- Comment #23 from Yuri Gribov 2012-07-10
15:34:02 UTC ---
The C++ Standard says that "an inline function shall be defined in every
translation unit in which it is used" (n1905, 7.1.2). The test in question
violates this rule: definition for C:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53831
--- Comment #22 from Yuri Gribov 2012-07-04
12:32:08 UTC ---
> For non fat ("slim") LTO builds you need to use these tools yes
So it seems that original testcase with fat files which used plain ar is indeed
correct and we have a real bug.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53831
--- Comment #19 from Yuri Gribov 2012-07-03
16:55:27 UTC ---
(In reply to comment #18)
> The testcase is fixed when using -fno-fat-lto-objects and gcc-ar
For me x64_64-linux version works if I use gcc-ar (both with and without
-fno-fat-lto-obje
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53831
--- Comment #14 from Yuri Gribov 2012-07-03
13:31:28 UTC ---
> you need to use the LTO aware nm that gcc installs, gcc-nm. It says
My bad.
> Btw, removing the 'inline' keyword everywhere still reproduces the issue.
> That makes the testcase ce
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53831
--- Comment #10 from Yuri Gribov 2012-07-03
12:59:01 UTC ---
> if I use -fno-fat-lto-objects I get a maybe more easily to debug linker
> failure
I guess that's because in this case archive symtab doesn't reference any
symbols at all (which is a
1 - 100 of 108 matches
Mail list logo
