https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98167
--- Comment #17 from Andrew Pinski ---
(In reply to Hongtao.liu from comment #16)
> typedef int v4si __attribute__ ((vector_size(16)));
>
> v4si f(v4si a, v4si b) {
> v4si a1 = __builtin_shufflevector (a, a, 2, 3 ,1 ,0);
> v4si b1 = __bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55153
--- Comment #7 from Andrew Pinski ---
*** Bug 43056 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43056
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102072
--- Comment #6 from Jiu Fu Guo ---
(In reply to Richard Earnshaw from comment #5)
> (In reply to Jiu Fu Guo from comment #4)
>
> > I did not find arm big-endian yet, I'm trying to reproduce this issue on
> > other targets...
>
> For testing pu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43056
Andrew Pinski changed:
What|Removed |Added
Known to work||4.8.0
--- Comment #7 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98167
--- Comment #16 from Hongtao.liu ---
typedef int v4si __attribute__ ((vector_size(16)));
v4si f(v4si a, v4si b) {
v4si a1 = __builtin_shufflevector (a, a, 2, 3 ,1 ,0);
v4si b1 = __builtin_shufflevector (b, a, 2, 3 ,1 ,0);
return a1 *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94589
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63315
--- Comment #3 from Andrew Pinski ---
So I looked and I suspect in the end was the same issue as PR 69838.
I have no way to prove this though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98167
--- Comment #15 from Hongtao.liu ---
(In reply to Andrew Pinski from comment #14)
> (In reply to Hongtao.liu from comment #13)
> > fold shulfps to vec_perm_exp, but still 2 shulfps are generated.
> >
> > __m128 f (__m128 a, __m128 b)
> > {
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65056
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48128
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |4.8.0
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101472
--- Comment #5 from Hongtao.liu ---
Fixed in GCC12, backport to GCC11 and GCC10.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101472
--- Comment #4 from CVS Commits ---
The releases/gcc-10 branch has been updated by hongtao Liu
:
https://gcc.gnu.org/g:fab014ecf9f7faf3b607a1e0892d0aeabe556661
commit r10-10073-gfab014ecf9f7faf3b607a1e0892d0aeabe556661
Author: konglin1
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101472
--- Comment #3 from CVS Commits ---
The releases/gcc-11 branch has been updated by hongtao Liu
:
https://gcc.gnu.org/g:b186040b468f6da512b9b123e1d4549f44396993
commit r11-8934-gb186040b468f6da512b9b123e1d4549f44396993
Author: konglin1
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101472
--- Comment #2 from CVS Commits ---
The master branch has been updated by hongtao Liu :
https://gcc.gnu.org/g:44a545a6abdd330083c1d12ad70092defbba702a
commit r12-3181-g44a545a6abdd330083c1d12ad70092defbba702a
Author: konglin1
Date: Mon Aug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102080
--- Comment #11 from Hongtao.liu ---
Created attachment 51363
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51363&action=edit
Proposed patch
I'm testing this patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83636
--- Comment #2 from YunQiang Su ---
Patch has been sent to:
https://gcc.gnu.org/pipermail/gcc-patches/2021-August/578243.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102089
--- Comment #3 from YunQiang Su ---
https://gcc.gnu.org/pipermail/gcc-patches/2021-August/578240.html
Patch has been sent to gcc-patches.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102090
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102090
--- Comment #4 from friedkeenan at protonmail dot com ---
I think you're correct. That's really strange, but I guess that's what
std::construct_at is for? But that also confuses me, how is GCC's
implementation of std::construct_at working if plac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102090
--- Comment #3 from Andrew Pinski ---
DR 1312 also mentions something similar with respect to casting to void*.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102090
--- Comment #2 from Andrew Pinski ---
clang produces:
:3:16: error: consteval function never produces a constant expression
[-Winvalid-constexpr]
consteval auto fuck() {
^
:5:23: note: call to placement 'operator new'
const a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102090
--- Comment #1 from Andrew Pinski ---
I don't think inplacement new is valid for constexpr. See PR 61105 also.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102089
--- Comment #2 from YunQiang Su ---
(In reply to Andrew Pinski from comment #1)
> Patches should be sent to gcc-patches@ after reading
> https://gcc.gnu.org/contribute.html
Yes. the patch will be send just now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102089
Andrew Pinski changed:
What|Removed |Added
Target||mips*-*-linux-gnuabi64
--- Comment #1 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102090
Bug ID: 102090
Summary: Placement-new is not constexpr
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102030
--- Comment #4 from Joe Eagar ---
I hadn't realized the nonnull attribute is 1-based. That makes sense.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102089
Bug ID: 102089
Summary: MIPS: use N64 ABI by default if the triple end with
-gnuabi64
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102080
Andrew Pinski changed:
What|Removed |Added
Component|target |middle-end
--- Comment #10 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67170
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |6.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102080
--- Comment #9 from Hongtao.liu ---
(In reply to Andrew Pinski from comment #8)
> That is the mask is a vector mode still for these patterns according to the
> internals doc.
> Rather than the scalar mode you have:
> (match_operand: 1 "register_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102080
--- Comment #8 from Andrew Pinski ---
That is the mask is a vector mode still for these patterns according to the
internals doc.
Rather than the scalar mode you have:
(match_operand: 1 "register_operand")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102080
--- Comment #7 from Andrew Pinski ---
The operation works elementwise if the operands are vectors.
No I think x86's cond_* patterns are not correct.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102080
--- Comment #6 from Andrew Pinski ---
This is the match pattern which does it:
(for uncond_op (UNCOND_BINARY)
cond_op (COND_BINARY)
(simplify
(vec_cond @0 (view_convert? (uncond_op@4 @1 @2)) @3)
(with { tree op_type = TREE_TYPE (@4); }
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102080
Andrew Pinski changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
Ke
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102080
--- Comment #4 from Hongtao.liu ---
diff --git a/test.c.032t.ccp1 b/test.c.033t.forwprop1
index 5b18739..c6f0587 100644
--- a/test.c.032t.ccp1
+++ b/test.c.033t.forwprop1
@@ -31,11 +31,12 @@ void EncodedFromDisplay ()
__m256 __trans_tmp_11;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28662
Bug 28662 depends on bug 67623, which changed state.
Bug 67623 Summary: interaction between cpp and Fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67623
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58334
Andrew Pinski changed:
What|Removed |Added
CC||Joost.VandeVondele at mat dot
ethz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67623
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87737
--- Comment #3 from Andrew Pinski ---
GCC 10+ rejects this code with:
/app/example.f90:2:9:
2 | program p
| 1
Error: Entity 'master.0.f' at (1) has a deferred type parameter and requires
either the POINTER or ALLOCATABLE attrib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55210
Andrew Pinski changed:
What|Removed |Added
CC||Melven.Roehrig-Zoellner@DLR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91237
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55210
--- Comment #3 from Andrew Pinski ---
*** Bug 68968 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68968
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55210
Andrew Pinski changed:
What|Removed |Added
CC||siteg at mathalacarte dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65025
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102068
--- Comment #2 from CVS Commits ---
The master branch has been updated by David Edelsohn :
https://gcc.gnu.org/g:5faf7120398c9bf290758891a975da1f727d631a
commit r12-3178-g5faf7120398c9bf290758891a975da1f727d631a
Author: David Edelsohn
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98167
--- Comment #14 from Andrew Pinski ---
(In reply to Hongtao.liu from comment #13)
> fold shulfps to vec_perm_exp, but still 2 shulfps are generated.
>
> __m128 f (__m128 a, __m128 b)
> {
> vector(4) float _3;
> vector(4) float _5;
> vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43147
--- Comment #20 from Hongtao.liu ---
Fixed in GCC12, now gcc generate optimal codes.
main:
.LFB532:
.cfi_startproc
subq$8, %rsp
.cfi_def_cfa_offset 16
movaps .LC0(%rip), %xmm0
callprintv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98167
--- Comment #13 from Hongtao.liu ---
fold shulfps to vec_perm_exp, but still 2 shulfps are generated.
__m128 f (__m128 a, __m128 b)
{
vector(4) float _3;
vector(4) float _5;
vector(4) float _6;
;; basic block 2, loop depth 0
;;pred:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98167
--- Comment #12 from CVS Commits ---
The master branch has been updated by hongtao Liu :
https://gcc.gnu.org/g:0fa4787bf34b173ce6f198e99b6f6dd8a3f98014
commit r12-3177-g0fa4787bf34b173ce6f198e99b6f6dd8a3f98014
Author: liuhongt
Date: Fri Dec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43147
--- Comment #19 from CVS Commits ---
The master branch has been updated by hongtao Liu :
https://gcc.gnu.org/g:0fa4787bf34b173ce6f198e99b6f6dd8a3f98014
commit r12-3177-g0fa4787bf34b173ce6f198e99b6f6dd8a3f98014
Author: liuhongt
Date: Fri Dec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66995
Andrew Pinski changed:
What|Removed |Added
Blocks||94404
Summary|First declarati
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93625
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93625
Andrew Pinski changed:
What|Removed |Added
Summary|inline specifier in a |[DR281] inline specifier in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102080
--- Comment #3 from Hongtao.liu ---
(In reply to H.J. Lu from comment #2)
> It is caused by r12-2679.
Mine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67633
--- Comment #2 from Andrew Pinski ---
GCC, clang and MSVC all argree here but ICC disagrees.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90960
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89687
Andrew Pinski changed:
What|Removed |Added
Known to work||10.1.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83249
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64519
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79531
--- Comment #2 from Andrew Pinski ---
Since GCC 8, we produce:
:8:16: error: 'virtual void derived::method2()' marked 'override', but
does not override
virtual void method2() override;
^~~
:11:6: error: no declaration match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70476
--- Comment #3 from Andrew Pinski ---
GCC, clang, ICC, and MSVC all agree they have external linkage.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95407
--- Comment #2 from Andrew Pinski ---
I think PR 67943 is also related. But then DR 472 is also related to that one.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67943
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2021-08-26
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52953
Andrew Pinski changed:
What|Removed |Added
CC||jtcash at ucsd dot edu
--- Comment #5 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89616
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91609
--- Comment #4 from Andrew Pinski ---
Seems fixed in GCC 11+.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101243
--- Comment #5 from Jonathan Wakely ---
For the attachment in comment 3 trunk now says:
In file included from /home/jwakely/gcc/12/include/c++/12.0.0/functional:59,
from /tmp/pr-1.cc:2:
/home/jwakely/gcc/12/include/c++/12.0.0/b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92193
--- Comment #2 from Jonathan Wakely ---
This makes the diagnostics for std::vector diabolical.
We hit a nice static assertion saying something like:
/home/jwakely/gcc/12/include/c++/12.0.0/bits/stl_uninitialized.h:90:56: error:
static assertion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95484
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69855
--- Comment #10 from Andrew Pinski ---
(In reply to Nathan Sidwell from comment #9)
> Reopening. I think I'm on the path of getting this right ...
I think r11-3699 fixed it the right way.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81609
--- Comment #5 from Andrew Pinski ---
Was fixed by r11-3699.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32042
--- Comment #3 from Andrew Pinski ---
Was fixed by r11-3699.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102088
--- Comment #2 from Martin Sebor ---
At -O0 the warning looks right although not as nice as what the analyzer prints
(but the analyzer doesn't catch it at -O1 or higher):
$ gcc -S -Wall -fanalyzer z.c
z.c: In function ‘f’:
z.c:5:7: warning: ‘x’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102088
--- Comment #1 from Martin Sebor ---
The patch below changes the latest warning to the following without any dg.exp
test failures:
z.c: In function ‘f’:
z.c:9:3: warning: ‘x’ may be used uninitialized [-Wmaybe-uninitialized]
9 | return z;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94405
--- Comment #1 from Andrew Pinski ---
Only MSVC rejects this code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102088
Bug ID: 102088
Summary: poor uninitialized warning points to an initialized
variable, no note to uninitialized
Product: gcc
Version: 12.0
Status: UNCONFIRMED
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89898
--- Comment #3 from Andrew Pinski ---
This was implemented by r9-3836 which is P0732R2:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0732r2.pdf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89898
--- Comment #2 from Andrew Pinski ---
This is valid C++ 20 too:
struct A { int t; };
template struct X { int d = a.t; };
template a > int f () { return a.d; }
int g(void)
{
return f{1}>();
}
Yes I know it looks off but it is valid now and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89898
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88344
--- Comment #2 from Andrew Pinski ---
The same is true for C2x and C++11 style attributes:
struct B {
[[gnu::always_inline]];
};
The C front-end warns:
:3:3: warning: 'always_inline' attribute ignored [-Wattributes]
3 | [[gnu::always_inl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88344
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2021-08-26
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32042
Andrew Pinski changed:
What|Removed |Added
Known to work||11.1.0
--- Comment #2 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81609
--- Comment #4 from Andrew Pinski ---
Seems fixed for GCC 11.
--enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210826 (experimental) [master revision
352d5e85a70:96f76144c4d:5a6c626710ad2ac4baa2dba02fac0750177e3305] (GCC)
[541] %
[541] % gcctk -O2 small.c
[542] %
[542] % gcctk -O3 small.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102084
--- Comment #6 from Sergio Losilla ---
Thank you for taking the time in explaining it, appreciated :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102084
--- Comment #5 from Andrew Pinski ---
(In reply to Sergio Losilla from comment #4)
> I see, thanks! The second version (constant_ref) which returns the reference
> to the captured does not trigger the sanitizer, so returning a reference to
> tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102084
--- Comment #4 from Sergio Losilla ---
I see, thanks! The second version (constant_ref) which returns the reference to
the captured does not trigger the sanitizer, so returning a reference to that
is valid?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102085
--- Comment #1 from Andrew Pinski ---
It might be useful to submit this upstream too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101997
--- Comment #4 from anlauf at gcc dot gnu.org ---
I have run the testcase under the debugger and the longest arguments to
sprintf I have found is
"m2345678901234567890123456789012345678901234567890123456789_123.n234567890123456789012345678901234
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102084
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102084
--- Comment #2 from Andrew Pinski ---
So we have in original:
< = (const double &) &TARGET_EXPR (const
double&)::&> (<<< Unknown tree: empty_class_expr >>>,
std::forward(const double&)::&> ((struct
type &) __fn))>;, 0>>;
Note the ,0 there.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102084
--- Comment #1 from Andrew Pinski ---
With -fsanitize=undefined I get:
/opt/compiler-explorer/gcc-trunk-20210826/include/c++/12.0.0/bits/invoke.h:116:38:
runtime error: reference binding to null pointer of type 'const double'
/op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88220
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |10.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98411
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98411
--- Comment #17 from CVS Commits ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:d9887f6d99fe435dd63e1c0eefa820b24c7f4100
commit r10-10071-gd9887f6d99fe435dd63e1c0eefa820b24c7f4100
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067
--- Comment #17 from Matt Godbolt ---
This is proprietary code (that the App and Sentry files didn't really contain
anything I was concerned about), and it links with a number of other libraries
which are much more proprietary (e.g. lwave env/li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102059
Michael Meissner changed:
What|Removed |Added
CC||meissner at gcc dot gnu.org
--- Comm
1 - 100 of 183 matches
Mail list logo
