https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98845
--- Comment #12 from Richard Biener ---
(In reply to Arseny Solokha from comment #11)
> It should be labeled [12 Regression] again, then, as the issue is still
> there on trunk.
w/ -O2 -fno-tree-dce -fno-tree-dse (possibly with -fno-tree-dse al
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90115
--- Comment #17 from CVS Commits ---
The master branch has been updated by Thomas Schwinge :
https://gcc.gnu.org/g:004fc4f2fc686d3366c9e1a2d8b9183796073866
commit r12-7684-g004fc4f2fc686d3366c9e1a2d8b9183796073866
Author: Thomas Schwinge
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103984
--- Comment #18 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:7276a18aba41eed65c0cf535ae029e0ceeca6c77
commit r12-7686-g7276a18aba41eed65c0cf535ae029e0ceeca6c77
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103984
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104960
--- Comment #2 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:3a7ba8fd0cda387809e4902328af2473662b6a4a
commit r12-7687-g3a7ba8fd0cda387809e4902328af2473662b6a4a
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102841
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #4 from Thomas Schwinge ---
> Can't (easily) test due to corresponding Solaris/Darwin system
> non-availability, but I think I understand the issue, and it should now be
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104948
--- Comment #13 from dagelf ---
Yes, I seem to have had a hole in my head. Sorry. For reference, to summarise
then:
& returns only the bits that are the same (bitwise AND) (or the bits that are
left after AND) (which will evaluate to true unles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104964
Bug ID: 104964
Summary: Wrong *** buffer overflow detected ***: terminated -
acl
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104964
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2022-03-17
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104964
--- Comment #1 from Martin Liška ---
Likely related to PR101836?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104964
--- Comment #2 from Martin Liška ---
Note the test-case is reduced from acl package (with -D_FORTIFY_SOURCE=3) that
used to work with -D_FORTIFY_SOURCE=2. So maybe my reduction was too aggressive
or should the current master support trailing arr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101134
--- Comment #14 from Jonathan Wakely ---
(In reply to Giuseppe D'Angelo from comment #13)
> Does this make sense?
Yes, perfect sense, and many of us agree 100%.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104960
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104952
Tom de Vries changed:
What|Removed |Added
Keywords||openmp
--- Comment #1 from Tom de Vries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104948
--- Comment #14 from Jonathan Wakely ---
(In reply to dagelf from comment #13)
> Although I would love to find counter examples, I would be willing to wager
> that && mixed with non bools, will almost always be done in error.
No, this is valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578
--- Comment #33 from Jonathan Wakely ---
(In reply to Martin Sebor from comment #31)
> As I mentioned in comment #25 and elsewhere, I envisioned that code would
> annotate these hardwired addresses somehow, ideally using an attribute like
> addr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578
--- Comment #34 from Jonathan Wakely ---
(In reply to Goswin von Brederlow from comment #29)
> There is no garantee in the C standard that '(type *)CONSTANT' will actually
> point to the hardware address 'CONSTANT'. It's just how gcc happens to d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102943
--- Comment #48 from Richard Biener ---
(In reply to Andrew Macleod from comment #47)
> Created attachment 52637 [details]
> new patch
>
> I am working on a alternative cache for GCC 13, but along the way, I have
> changes to the ranger_cache::
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104964
Martin Liška changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104964
Martin Liška changed:
What|Removed |Added
Priority|P1 |P3
--- Comment #4 from Martin Liška ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13071
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #9 from Jonathan W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104964
Siddhesh Poyarekar changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |siddhesh at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13071
--- Comment #10 from Harald van Dijk ---
(In reply to Jonathan Wakely from comment #9)
> (In reply to Harald van Dijk from comment #8)
> > (In reply to Andrew Pinski from comment #7)
> > > Isn't doing the extern "C" around standard C++ headers de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104952
--- Comment #2 from Tom de Vries ---
I think the problem can be seen already at omp-lower, in the body of the
butterfly loop.
Let's first look at what we have if we use reduction op '|':
...
D.2173 = .GOMP_SIMT_VF ();
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104965
Bug ID: 104965
Summary: Yet another -Warray-bounds false positive
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99555
--- Comment #13 from Thomas Schwinge ---
Thanks -- I'm confirming:
PASS: libgomp.c/../libgomp.c-c++-common/task-detach-6.c (test for excess
errors)
[-XFAIL:-]{+PASS:+} libgomp.c/../libgomp.c-c++-common/task-detach-6.c
execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104966
Bug ID: 104966
Summary: [11/12 Regression] Yet another bogus -Warray-bounds
warning in libstdc++ headers
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keyword
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104912
--- Comment #6 from Richard Biener ---
Created attachment 52640
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52640&action=edit
patch
Like this - this counts the number of vector stmts and the number of strided
loads/stores and then when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104966
--- Comment #1 from Jonathan Wakely ---
Created attachment 52641
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52641&action=edit
Partially reduced preprocessed source for second issue
-std=gnu++20 -Wall gives:
3.ii: In member function '
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104967
Bug ID: 104967
Summary: ICE: Segmentation fault (in find_instance)
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104966
--- Comment #2 from Jonathan Wakely ---
Oops, I forgot to add that these all need -O2 to trigger the warnings.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104966
--- Comment #3 from Jonathan Wakely ---
Created attachment 52642
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52642&action=edit
Preprocessed source for the first issue
This is the original unreduced preprocessed output for the test
libs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104952
--- Comment #3 from Tom de Vries ---
Hmm, that seems to be actually due to:
...
if (sctx.is_simt)
{
if (!simt_lane)
simt_lane = create_tmp_var (u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104966
--- Comment #4 from Richard Biener ---
Well, the IL definitely has
tem = operator new[] (0);
/* some magic computing with 'positive_sign_size' */
if (min (positive-sign-size, something) != 0)
if (__n == 1)
;
else
{
tem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104854
--- Comment #9 from David Malcolm ---
(In reply to Siddhesh Poyarekar from comment #8)
> (In reply to Martin Sebor from comment #7)
> > Moving warnings into the analyzer and scaling it up to be able to run by
> > default, during development, sou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104966
--- Comment #5 from Richard Biener ---
Ah, so we have
this_42(D)->_M_positive_sign_size = 0;
_62 = operator new [] (0);
(possible EH)
[local count: 268220751]:
_6 = this_42(D)->_M_positive_sign_size;
_192 = MEM[(long unsigned int *)&D.28166
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104966
--- Comment #6 from Richard Biener ---
(In reply to Richard Biener from comment #5)
> and 'new' is now (after some "recent" fix)
PR101480
> possibly clobbering this->_M_positive_sign_size.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104966
--- Comment #7 from Jonathan Wakely ---
N.B. with no warning options the test fails with -Wstringop-overflow warnings
(enabled by default) and with -Wall the same exact same line of correct code
gives -Warray-bounds warnings. So I need to disabl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578
--- Comment #35 from Jakub Jelinek ---
Created attachment 52643
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52643&action=edit
gcc12-pr99578-wip.patch
What we could do is differentiate between the invalid constant addresses
from pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104965
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |11.3
--- Comment #1 from Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104952
--- Comment #4 from Tom de Vries ---
This fixes it:
...
diff --git a/gcc/omp-low.cc b/gcc/omp-low.cc
index d932d74cb03..f2ac8f98e32 100644
--- a/gcc/omp-low.cc
+++ b/gcc/omp-low.cc
@@ -6734,7 +6734,21 @@ lower_rec_input_clauses (tree clauses, gi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104966
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |11.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104952
--- Comment #5 from Jakub Jelinek ---
Note, I guess this is related to PR94366 and r12-438-g1580fc764423bf89e9b which
was fixing it for non-SIMT and quite possibly left out the SIMT stuff out.
Using the TRUTH_{AND,OR}_EXPR instead of TRUTH_{AND,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102943
--- Comment #49 from Andrew Macleod ---
Let me clean it up a little and I'll post it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104952
--- Comment #6 from Jakub Jelinek ---
And yes, #c1 is valid. But would be nice to have similar test with && and
initial result = 2; and arr[] say { 1, 2, 3, 4, 5, 6, 7, ..., 32 } and test
result is 1 at the end to make sure we don't actually do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104952
--- Comment #7 from Tom de Vries ---
Alternative fix that doesn't require fiddling with the 'code' var:
...
diff --git a/gcc/omp-low.cc b/gcc/omp-low.cc
index d932d74cb03..d0ddd4a6142 100644
--- a/gcc/omp-low.cc
+++ b/gcc/omp-low.cc
@@ -6734,7 +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104952
--- Comment #8 from Tom de Vries ---
(In reply to Jakub Jelinek from comment #6)
> And yes, #c1 is valid.
Thanks for confirming.
> But would be nice to have similar test with && and
> initial result = 2; and arr[] say { 1, 2, 3, 4, 5, 6, 7, ..
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104931
--- Comment #7 from Richard Biener ---
Created attachment 52644
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52644&action=edit
GIMPLE testcase
This is a GIMPLE testcase created from the cddce2 IL of the respective ltrans
unit from trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104931
--- Comment #8 from Richard Biener ---
Created attachment 52645
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52645&action=edit
ivcanon dump as seen from LTO (with bug)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104965
--- Comment #2 from Jonathan Wakely ---
In this case s.size() reads a local variable that can't be altered by new.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104968
Bug ID: 104968
Summary: [nvptx][OpenMP] SIGSEGV / ICE in final_scan_insn_1
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, openmp
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104931
--- Comment #9 from Richard Biener ---
Created attachment 52646
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52646&action=edit
ivcanon dump from the GIMPLE testcase (without bug)
The difference is that with LTO we have expanded expressi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13071
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104937
--- Comment #6 from Jakub Jelinek ---
What we could for _Complex int just use the standard
(a + b*i) / (c + d*i) = (a*c + b*d) / (c*c + d*d) + ((b*c - a*d) / (c*c +
d*d))*i
which would be 6 multiplications and 2 divisions instead of the current
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104969
Bug ID: 104969
Summary: Likely a false positive of -D_FORTIFY_SOURCE=3
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104969
Martin Liška changed:
What|Removed |Added
Target Milestone|--- |12.0
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104952
--- Comment #9 from Tom de Vries ---
Created attachment 52647
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52647&action=edit
Tentative patch with test-cases, rationale and changelog
I'll put this through testing, and submit if no proble
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104952
--- Comment #10 from Jakub Jelinek ---
Comment on attachment 52647
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52647
Tentative patch with test-cases, rationale and changelog
Please change arr[5] = 1; to arr[5] = 42; or so also to test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102943
--- Comment #50 from hubicka at kam dot mff.cuni.cz ---
> It helps quite a bit, the worst case is now
>
> tree VRP : 5.14 ( 7%) 0.02 ( 3%) 5.15 (
> 7%)
>2
> 9M ( 3%)
> backwards jump threading
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104968
--- Comment #1 from Tom de Vries ---
Can't reproduce.
It this not fixed by:
...
commit 7862f6ccd85a001e4d70abb00bb95d8c7846ba80
Author: Tom de Vries
Date: Wed Feb 23 09:33:33 2022 +0100
[nvptx] Fix dummy location in gen_comment
...
?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102426
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104969
--- Comment #1 from Andreas Schwab ---
Passing a max len bigger than the available space is already an error. The
whole point of snprintf is to never overflow no matter how large the output.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104931
--- Comment #10 from Richard Biener ---
The bug also shows in a -flto-partition=max build where the offending function
ends up in ltrans unit 23 (and only this function) which might enable
side-by-side debugging if desired.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104968
--- Comment #2 from Tom de Vries ---
(In reply to Tom de Vries from comment #1)
> Can't reproduce.
>
> It this not fixed by:
> ...
> commit 7862f6ccd85a001e4d70abb00bb95d8c7846ba80
> Author: Tom de Vries
> Date: Wed Feb 23 09:33:33 2022 +010
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104968
--- Comment #3 from Tom de Vries ---
(In reply to Tom de Vries from comment #2)
> (In reply to Tom de Vries from comment #1)
> > Can't reproduce.
> >
> > It this not fixed by:
> > ...
> > commit 7862f6ccd85a001e4d70abb00bb95d8c7846ba80
> > Auth
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102772
--- Comment #8 from Jakub Jelinek ---
Does libgomp.fortran/pointer2.f90 still FAIL?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104968
--- Comment #4 from Tom de Vries ---
This ( https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591912.html )
proposed patch fixes this ICE, pinged again.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94680
Roger Sayle changed:
What|Removed |Added
Target Milestone|--- |12.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102772
--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #8 from Jakub Jelinek ---
> Does libgomp.fortran/pointer2.f90 still FAIL?
It does.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98198
Roger Sayle changed:
What|Removed |Added
Target Milestone|11.3|12.0
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104970
Bug ID: 104970
Summary: ICE in execute_todo, at passes.cc:2133 since
r12-6480-gea19c8f33a3a8d2b
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104970
Martin Liška changed:
What|Removed |Added
Priority|P3 |P1
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104965
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104961
--- Comment #2 from Vladimir Makarov ---
I've reproduced the bug. The mentioned patch is not the cause but a trigger.
The origin of the problem is actually a removal of hard reg propagation before
RA which happened about year ago.
I hope the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103039
--- Comment #6 from Jakub Jelinek ---
unshare_expr doesn't do anything wrong.
The problem is that because of the select we have firstprivate(__tmp_class_a)
clause where __tmp_class_a has type which has struct __class_seltype_A_p *
type. Before
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104969
--- Comment #2 from Siddhesh Poyarekar ---
(In reply to Martin Liška from comment #0)
> The original code is defective a bit as it wrongly assumes that
> (char*)str + (2 * i) is at maximum 'len' big. It's actually len - (2 * i)
> big. But it sho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104970
Siddhesh Poyarekar changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |siddhesh at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:1d47c0512a265d4bb3ab9e56259fd1e4f4d42c75
commit r12-7689-g1d47c0512a265d4bb3ab9e56259fd1e4f4d42c75
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104966
--- Comment #8 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:38ce4489635f2d65de965af3ec5d5c4adf7762d9
commit r12-7690-g38ce4489635f2d65de965af3ec5d5c4adf7762d9
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92546
--- Comment #26 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:00df7ee4474faca91d3460fe78a88e280c6c1126
commit r12-7691-g00df7ee4474faca91d3460fe78a88e280c6c1126
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104971
Bug ID: 104971
Summary: Optimisation for __builtin_ia32_readeflags corrupts
the stack
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104971
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |9.5
Summary|Optimisation for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102426
--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #7 from Jakub Jelinek ---
> So, shouldn't we instead of the -export-symbols-regex use a version script?
We certainly could, but IIUC this would lose the functionality on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104969
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102426
--- Comment #9 from Jakub Jelinek ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #8)
> > --- Comment #7 from Jakub Jelinek ---
> > So, shouldn't we instead of the -export-symbols-regex use a version script?
>
> We certainly could,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40635
Martin Sebor changed:
What|Removed |Added
Assignee|msebor at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41540
Martin Sebor changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|msebor at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67872
Martin Sebor changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|msebor at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70076
Martin Sebor changed:
What|Removed |Added
Assignee|msebor at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70588
Martin Sebor changed:
What|Removed |Added
Assignee|msebor at gcc dot gnu.org |unassigned at gcc dot
gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80420
Martin Sebor changed:
What|Removed |Added
Blocks||85741
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83430
Martin Sebor changed:
What|Removed |Added
CC|msebor at gcc dot gnu.org |
Assignee|msebor at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84318
Martin Sebor changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|msebor at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84050
Martin Sebor changed:
What|Removed |Added
Assignee|msebor at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104076
Martin Sebor changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|msebor at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069
Martin Sebor changed:
What|Removed |Added
Assignee|msebor at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101665
Martin Sebor changed:
What|Removed |Added
Assignee|msebor at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104971
Jakub Jelinek changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99475
Martin Sebor changed:
What|Removed |Added
Assignee|msebor at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99295
Martin Sebor changed:
What|Removed |Added
Assignee|msebor at gcc dot gnu.org |unassigned at gcc dot
gnu.org
1 - 100 of 162 matches
Mail list logo
