On Thu, 22 Jul 2021 at 20:29, Richard Earnshaw
wrote:
>
>
>
> On 22/07/2021 14:47, Prathamesh Kulkarni via Gcc-patches wrote:
> > On Thu, 22 Jul 2021 at 17:28, Richard Earnshaw
> > wrote:
> >>
> >>
> >>
> >> On 22/07/2021 12:32, Prathamesh Kulkarni wrote:
> >>> On Thu, 22 Jul 2021 at 16:03, Richa
On 23/07/2021 08:52, Martin Liška wrote:
+#ifdef NEED_L_GCOV_INFO_TO_GCDA
+/* Convert the gcov info to a gcda data stream. It is intended for
+ free-standing environments which do not support the C library
file I/O. */
+
+void
+__gcov_info_to_gcda (const struct gcov_info *gi_ptr,
+
On 7/23/21 9:06 AM, Sebastian Huber wrote:
On 23/07/2021 08:52, Martin Liška wrote:
+#ifdef NEED_L_GCOV_INFO_TO_GCDA
+/* Convert the gcov info to a gcda data stream. It is intended for
+ free-standing environments which do not support the C library file I/O. */
+
+void
+__gcov_info_to_gcda (
Hi!
Our documentation says that paradoxical subregs shouldn't appear
in strict_low_part:
'(strict_low_part (subreg:M (reg:N R) 0))'
This expression code is used in only one context: as the
destination operand of a 'set' expression. In addition, the
operand of this expression must b
Hi Harald,
On 22.07.21 21:03, Harald Anlauf wrote:
you are right in that I was barking up the wrong tree.
I was focussed too much on the testcase in the PR.
[...]
Well, I tried and this does not work.
Which makes sense if one thinks about it:
When using 'a(5,:)', the parser already sets e->ra
Hi!
As the following testcase shows, we don't parse properly
C++11 attribute-declaration:
https://eel.is/c++draft/dcl.dcl#nt:attribute-declaration
cp_parser_toplevel_declaration just handles empty-declaration parsing
(with diagnostics for C++98) and otherwise calls cp_parser_declaration
which on
Hi!
The OpenMP 5.1 spec says that the attribute and pragma syntax directives
should not be mixed on the same statement. The following patch adds diagnostic
for that,
[[omp::directive (...)]]
#pragma omp ...
is always an error and for the other order
#pragma omp ...
[[omp::directive (...)]
Hi!
Now that the C++ FE supports these attributes, but not through registering
them in the attributes tables (they work quite differently from other
attributes), this teaches c_common_has_attributes about those.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk.
2021-07-2
Hi,
Sorry It looks like I forgot to ask if OK for backport to GCC 9, 10, 11 after
some stew.
Thanks,
Tamar
> -Original Message-
> From: Richard Sandiford
> Sent: Thursday, July 22, 2021 7:11 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
> ; Marcus Shawc
Hi Harald,
On 22.07.21 21:50, Harald Anlauf wrote:
I am afraid we're really opening a can of worms here
which is not too bad if there are only two earthworms in there ;-)
Additionally, I wonder whether that will work with:
I think a "working" testcase for this could be:
program p
impl
Hi,
This patch uses __builtin_memcpy to copy vector structures instead of
building a new opaque structure one vector at a time in each of the
vqtbl[234] Neon intrinsics in arm_neon.h. This simplifies the header file
and also improves code generation - superfluous move instructions
were emitted for
Hi,
This patch uses __builtin_memcpy to copy vector structures instead of
building a new opaque structure one vector at a time in each of the
vqtbx[234] Neon intrinsics in arm_neon.h. This simplifies the header
file and also improves code generation - superfluous move
instructions were emitted for
Hi,
This patch uses __builtin_memcpy to copy vector structures instead of
building a new opaque structure one vector at a time in each of the
vtbl[34] Neon intrinsics in arm_neon.h. This simplifies the header file
and also improves code generation - superfluous move instructions
were emitted for e
Hi,
Comparing to v2, this v3 removed the new CTOR with struct loops *loops
as Richi clarified. I'd like to support it in a separated follow up
patch by extending the existing CTOR with an optional argument loop_p
root.
Bootstrapped and regtested again on powerpc64le-linux-gnu P9,
x86_64-redhat-l
on 2021/7/22 下午8:56, Richard Biener wrote:
> On Tue, Jul 20, 2021 at 4:37
> PM Kewen.Lin wrote:
>>
>> Hi,
>>
>> This v2 has addressed some review comments/suggestions:
>>
>> - Use "!=" instead of "<" in function operator!= (const Iter &rhs)
>> - Add new CTOR loops_list (struct loops *loops, un
Hi Jason,
I found a few regressions from the last patch in the meantime. Version 4 of
the patch is attached.
Questions:
1. I simplified the condition for calling dump_template_parms in
dump_function_name. !DECL_FRIEND_PSEUDO_TEMPLATE_INSTANTIATION (t) is
equivalent to DECL_USE_TEMPLATE (t) in
Hi,
This patch uses __builtin_memcpy to copy vector structures instead of
building a new opaque structure one vector at a time in each of the
vtbx4 Neon intrinsics in arm_neon.h. This simplifies the header file
and also improves code generation - superfluous move instructions
were emitted for ever
Hi Jonathan,
> -Original Message-
> From: Jonathan Wright
> Sent: 23 July 2021 09:22
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov ; Richard Sandiford
>
> Subject: [PATCH 1/8] aarch64: Use memcpy to copy vector tables in
> vqtbl[234] intrinsics
>
> Hi,
>
> This patch uses __builti
On 23/07/2021 08:52, Martin Liška wrote:
It would be nice having a test-case that can test your approach.
The problem is that you need the linker set to get access to the gcov
information. The test program of the commit message works on my Linux
machine. I am not sure if it is generic enoug
Hi,
This patch uses __builtin_memcpy to copy vector structures instead of
building a new opaque structure one vector at a time in each of the
vst4[q] Neon intrinsics in arm_neon.h. This simplifies the header file
and also improves code generation - superfluous move instructions
were emitted for ev
Hi,
This patch uses __builtin_memcpy to copy vector structures instead of
building a new opaque structure one vector at a time in each of the
vst3[q] Neon intrinsics in arm_neon.h. This simplifies the header file
and also improves code generation - superfluous move instructions
were emitted for ev
> -Original Message-
> From: Jonathan Wright
> Sent: 23 July 2021 09:27
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov ; Richard Sandiford
>
> Subject: [PATCH 2/8] aarch64: Use memcpy to copy vector tables in
> vqtbx[234] intrinsics
>
> Hi,
>
> This patch uses __builtin_memcpy to
> -Original Message-
> From: Jonathan Wright
> Sent: 23 July 2021 09:30
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov ; Richard Sandiford
>
> Subject: [PATCH 3/8] aarch64: Use memcpy to copy vector tables in vtbl[34]
> intrinsics
>
> Hi,
>
> This patch uses __builtin_memcpy to c
> -Original Message-
> From: Jonathan Wright
> Sent: 23 July 2021 10:15
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov ; Richard Sandiford
>
> Subject: [PATCH 4/8] aarch64: Use memcpy to copy vector tables in vtbx4
> intrinsics
>
> Hi,
>
> This patch uses __builtin_memcpy to copy
Kyrylo Tkachov writes:
>> -Original Message-
>> From: Jonathan Wright
>> Sent: 23 July 2021 09:30
>> To: gcc-patches@gcc.gnu.org
>> Cc: Kyrylo Tkachov ; Richard Sandiford
>>
>> Subject: [PATCH 3/8] aarch64: Use memcpy to copy vector tables in vtbl[34]
>> intrinsics
>>
>> Hi,
>>
>> This p
> -Original Message-
> From: Jonathan Wright
> Sent: 23 July 2021 10:22
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov ; Richard Sandiford
>
> Subject: [PATCH 5/8] aarch64: Use memcpy to copy vector tables in vst4[q]
> intrinsics
>
> Hi,
>
> This patch uses __builtin_memcpy to co
Kyrylo Tkachov writes:
>> -Original Message-
>> From: Jonathan Wright
>> Sent: 23 July 2021 10:15
>> To: gcc-patches@gcc.gnu.org
>> Cc: Kyrylo Tkachov ; Richard Sandiford
>>
>> Subject: [PATCH 4/8] aarch64: Use memcpy to copy vector tables in vtbx4
>> intrinsics
>>
>> Hi,
>>
>> This patc
On 23/07/2021 11:17, Sebastian Huber wrote:
On 23/07/2021 08:52, Martin Liška wrote:
It would be nice having a test-case that can test your approach.
The problem is that you need the linker set to get access to the gcov
information. The test program of the commit message works on my Linu
On 23/07/2021 08:04, Prathamesh Kulkarni via Gcc-patches wrote:
> On Thu, 22 Jul 2021 at 20:29, Richard Earnshaw
> wrote:
>>
>>
>>
>> On 22/07/2021 14:47, Prathamesh Kulkarni via Gcc-patches wrote:
>>> On Thu, 22 Jul 2021 at 17:28, Richard Earnshaw
>>> wrote:
On 22/07/2021 12:
I haven't added test cases here because these intrinsics don't map to
a single instruction (they're legacy from Armv7) and would trip the
"scan-assembler not mov" that we're using for the other tests.
Jonathan
From: Richard Sandiford
Sent: 23 July 2021 10:29
To: K
> -Original Message-
> From: Jonathan Wright
> Sent: 23 July 2021 10:25
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov ; Richard Sandiford
>
> Subject: [PATCH 6/8] aarch64: Use memcpy to copy vector tables in vst3[q]
> intrinsics
>
> Hi,
>
> This patch uses __builtin_memcpy to co
Hi,
This patch uses __builtin_memcpy to copy vector structures instead of
building a new opaque structure one vector at a time in each of the
vst2[q] Neon intrinsics in arm_neon.h. This simplifies the header file
and also improves code generation - superfluous move instructions
were emitted for ev
Add __gcov_info_to_gcda() to libgcov to get the gcda data for a gcda info in a
freestanding environment. It is intended to be used with the
-fprofile-info-section option. A crude test program which doesn't use a linker
script is (use "gcc -coverage -fprofile-info-section -lgcc test.c" to compile
Hi,
This patch uses __builtin_memcpy to copy vector structures instead of
using a union in each of the vst1[q]_x4 Neon intrinsics in arm_neon.h.
Add new code generation tests to verify that superfluous move
instructions are not generated for the vst1q_x4 intrinsics.
Regression tested and bootstr
> -Original Message-
> From: Jonathan Wright
> Sent: 23 July 2021 10:38
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov ; Richard Sandiford
>
> Subject: [PATCH 7/8] aarch64: Use memcpy to copy vector tables in vst2[q]
> intrinsics
>
> Hi,
>
> This patch uses __builtin_memcpy to co
Jonathan Wright writes:
> I haven't added test cases here because these intrinsics don't map to
> a single instruction (they're legacy from Armv7) and would trip the
> "scan-assembler not mov" that we're using for the other tests.
Ah, OK, fair enough. Thanks for the explanation.
Richard
>
> Jo
Same explanation as for patch 3/8:
I haven't added test cases here because these intrinsics don't map to
a single instruction (they're legacy from Armv7) and would trip the
"scan-assembler not mov" that we're using for the other tests.
Thanks,
Jonathan
From: Richa
> -Original Message-
> From: Jonathan Wright
> Sent: 23 July 2021 10:42
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov ; Richard Sandiford
>
> Subject: [PATCH 8/8] aarch64: Use memcpy to copy vector tables in
> vst1[q]_x4 intrinsics
>
> Hi,
>
> This patch uses __builtin_memcpy to
Hi all,
this patch implements the omp_get_device_num API function, which appears
to be a missing piece in the library routines implementation.
The host-side implementation is simple, which by specification is equivalent
to omp_get_initial_device.
Inside offloaded regions, the preferred way to sh
On Fri, Jul 23, 2021 at 06:21:41PM +0800, Chung-Lin Tang wrote:
> --- a/libgomp/icv-device.c
> +++ b/libgomp/icv-device.c
> @@ -61,8 +61,17 @@ omp_is_initial_device (void)
>return 1;
> }
>
> +int
> +omp_get_device_num (void)
> +{
> + /* By specification, this is equivalent to omp_get_initia
On Fri, 23 Jul 2021 at 15:02, Richard Earnshaw
wrote:
>
> On 23/07/2021 08:04, Prathamesh Kulkarni via Gcc-patches wrote:
> > On Thu, 22 Jul 2021 at 20:29, Richard Earnshaw
> > wrote:
> >>
> >>
> >>
> >> On 22/07/2021 14:47, Prathamesh Kulkarni via Gcc-patches wrote:
> >>> On Thu, 22 Jul 2021 at
The comments in describe problems that were solved
years ago (for GCC 3.1). The comparison operators in are no
longer ambiguous with the rel_ops ones, so the linked mailing list
thread and FAQ entry aren't relevant now. The reference to std_utility.h
is also outdated as it's just called utility n
On 23.07.21 12:21, Chung-Lin Tang wrote:
Inside offloaded regions, the preferred way to should be that the device
already has this information initialized (once) when the device is
initialized.
And the function merely returns the stored value.
...
+++ b/libgomp/testsuite/libgomp.c-c++-common/ta
On 23/07/2021 09:16, Martin Liška wrote:
On 7/23/21 9:06 AM, Sebastian Huber wrote:
On 23/07/2021 08:52, Martin Liška wrote:
+#ifdef NEED_L_GCOV_INFO_TO_GCDA
+/* Convert the gcov info to a gcda data stream. It is intended for
+ free-standing environments which do not support the C library
f
The header only needs std::atomic_flag, so can include
instead of the whole of .
libstdc++-v3/ChangeLog:
* include/std/future: Include instead of
.
Tested powerpc64le-linux. Committed to trunk.
commit 3ea62a2b2ed739209936e0ed27539965ae4c9840
Author: Jonathan Wakely
Date: F
Ping again.
On Mon, 2021-06-21 at 21:42 +0800, Xi Ruoyao wrote:
> Middle-end started to emit vec_cmp and vec_cmpu since GCC 11, causing
> ICE on MIPS with MSA enabled. Add the pattern to prevent it.
>
> Bootstrapped and regression tested on mips64el-linux-gnu.
> Ok for trunk?
>
> gcc/
>
>
Bootstrapped and regtested on s390x-redhat-linux. Ok for master?
gcc/testsuite/ChangeLog:
* gcc.target/s390/global-array-element-pic2.c: Add -mzarch, add
an expectation for 31-bit mode.
* gcc.target/s390/load-imm64-1.c: Use unsigned long long.
* gcc.target/s390/
Ping again.
On Wed, 2021-06-23 at 11:11 +0800, Xi Ruoyao wrote:
> Commit message shamelessly copied from 1777beb6b129 by jakub:
>
> This function, because it is sometimes called even outside of function
> bodies, uses create_tmp_var_raw rather than create_tmp_var. But in order
> for that to work
Hi Sandra,
On 21.07.21 12:17, Tobias Burnus wrote:
On 13.07.21 23:28, Sandra Loosemore wrote:
ISO_Fortran_binding.h is now generated in the libgfortran build
directory where it is on the default include path. Adjust includes in
the gfortran testsuite not to include an explicit path pointing at
Hi,
This patch uses __builtin_memcpy to copy vector structures instead of
building a new opaque structure one vector at a time in each of the
vst1[q]_x3 Neon intrinsics in arm_neon.h. This simplifies the header file
and also improves code generation - superfluous move instructions
were emitted for
Hi,
This patch uses __builtin_memcpy to copy vector structures instead of
building a new opaque structure one vector at a time in each of the
vst1[q]_x2 Neon intrinsics in arm_neon.h. This simplifies the header
file and also improves code generation - superfluous move
instructions were emitted for
> -Original Message-
> From: Jonathan Wright
> Sent: 23 July 2021 15:22
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov ; Richard Sandiford
>
> Subject: [PATCH] aarch64: Use memcpy to copy vector tables in vst1[q]_x3
> intrinsics
>
> Hi,
>
> This patch uses __builtin_memcpy to cop
> -Original Message-
> From: Jonathan Wright
> Sent: 23 July 2021 15:25
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov ; Richard Sandiford
>
> Subject: [PATCH] aarch64: Use memcpy to copy vector tables in vst1[q]_x2
> intrinsics
>
> Hi,
>
> This patch uses __builtin_memcpy to cop
Now that all dependencies of array_bounds_checker take a range_query, we
can sever the relationship with vr_values. Changing this will allow us
to use the array_bounds_checker with VRP, evrp, or the ranger.
Tested on x86-64 Linux.
Pushed.
gcc/ChangeLog:
* gimple-array-bounds.h (class a
On 7/23/21 2:35 AM, Kewen.Lin wrote:
Hi,
Comparing to v2, this v3 removed the new CTOR with struct loops *loops
as Richi clarified. I'd like to support it in a separated follow up
patch by extending the existing CTOR with an optional argument loop_p
root.
Looks very nice (and quite a bit work
On 7/23/2021 1:49 AM, Jakub Jelinek wrote:
Hi!
Our documentation says that paradoxical subregs shouldn't appear
in strict_low_part:
'(strict_low_part (subreg:M (reg:N R) 0))'
This expression code is used in only one context: as the
destination operand of a 'set' expression. In ad
On 7/23/21 2:41 AM, Kewen.Lin wrote:
on 2021/7/22 下午8:56, Richard Biener wrote:
On Tue, Jul 20, 2021 at 4:37
PM Kewen.Lin wrote:
Hi,
This v2 has addressed some review comments/suggestions:
- Use "!=" instead of "<" in function operator!= (const Iter &rhs)
- Add new CTOR loops_list (st
On 7/22/2021 7:04 AM, Richard Biener via Gcc-patches wrote:
On Thu, Jul 22, 2021 at 9:02 AM Bin.Cheng via Gcc-patches
wrote:
Gentle ping. Any suggestions would be appreciated.
So just to say something - does the existing code mean that any use of
the alias info on prologue/epilogue insns i
On 7/14/2021 3:14 AM, bin.cheng via Gcc-patches wrote:
Hi,
I ran into a wrong code bug in code with deep template instantiation when
working on sdx::simd.
The root cause as described in commit summary is we skip prologue insns in
init_alias_analysis.
This simple patch fixes the issue, howeve
On 7/22/2021 5:15 PM, Sergei Trofimovich via Gcc-patches wrote:
From: Sergei Trofimovich
r12-1804 ("cp: add support for per-location warning groups.") among other
things removed warning suppression from a few places including ptrmemfuncs.
Currently ptrmemfuncs don't have valid BINFO attache
In r12-569 I accidentally applied the LWG 3533 change that
was intended for elements_view::iterator::base to
elements_view::base instead.
This patch corrects this, and also applies the corresponding LWG 3533
change to lazy_split_view::inner-iter::base now that we implement P2210.
Tested on x86_64
Tested on x86_64-pc-linux-gnu, does this look OK for trunk/branches?
PR libstdc++/101483
libstdc++-v3/ChangeLog:
* include/std/ranges (join_view::_Iterator::_Iterator): Add
missing std::move.
---
libstdc++-v3/include/std/ranges | 2 +-
1 file changed, 1 insertion(+), 1 d
In r12-569 I accidentally applied the LWG 3533 change that
was intended for elements_view::iterator::base to
elements_view::base instead.
This patch corrects this, and also applies the corresponding LWG 3533
change to lazy_split_view::inner-iter::base now that we implement P2210.
Tested on x86_64
In passing, this also renames the template parameter _O2 to _Out2 in
ranges::partition_copy and uglify its function parameters out_true
and out_false.
Tested on x86_64-pc-linux-gnu, does this look OK for trunk+branches?
PR libstdc++/101599
libstdc++-v3/ChangeLog:
* include/bits/
On Fri, 23 Jul 2021 at 17:36, Patrick Palka via Libstdc++
wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk/branches?
Yes, thanks.
>
> PR libstdc++/101483
>
> libstdc++-v3/ChangeLog:
>
> * include/std/ranges (join_view::_Iterator::_Iterator): Add
> mi
On 7/22/2021 3:58 PM, Martin Sebor via Gcc-patches wrote:
The code that computes the size of an access to an object in
-Wuninitialized is limited to declared objects and so doesn't
apply to allocated objects, and doesn't correctly account for
an offset into the object and the access size. Thi
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575377.html
On 7/15/21 4:39 PM, Martin Sebor wrote:
A number of access warnings as well as their supporting
infrastructure (compute_objsize et al.) are implemented in
builtins.{c,h} where they (mostly) operate on trees and run
just befor
On 7/22/2021 6:34 AM, Richard Biener wrote:
We can improve uninit warnings from the early pass by looking
at PHI arguments on fallthru edges that are uninitialized and
have uses that are before a possible loop exit. This catches
some cases earlier that we'd only warn in a more confusing
way a
On 7/20/2021 4:01 PM, Marek Polacek via Gcc-patches wrote:
This quashes -Wundef warnings in ansidecl.h when compiled in C or C++.
In C, __cpp_constexpr and __cplusplus aren't defined so we evaluate
them to 0; conversely, __STDC_VERSION__ is not defined in C++.
This has caused grief when -Wunde
On 7/15/2021 4:08 AM, Jiufu Guo via Gcc-patches wrote:
Refine code for V2 according to review comments:
* Use if check instead assert, and refine assert
* Use better RE check for test case, e.g. (?n)/(?p)
* Use better wording for target.def
Currently, doloop.xx variable is using the type as n
Hi!
On Fri, Jul 23, 2021 at 07:47:54AM +0200, Martin Liška wrote:
> On 7/12/21 7:20 PM, Segher Boessenkool wrote:
> +static __attribute__ ((optimize ("-fno-stack-protector"))) __typeof
> (f) *
> >>>
> >>>-fno-stack-protector is default.
> >>
> >>Yes, but one needs an optimize attribute in
Hi!
On Tue, Jun 01, 2021 at 03:39:14PM +0200, Martin Liska wrote:
> * config/rs6000/rs6000.c (rs6000_option_override_internal): When
> a target option is restored, it can have
> rs6000_long_double_type_size set to FLOAT_PRECISION_TFmode
> and error should not be emitted.
>
I've been experimenting with this patch, which removes the need to use
std::tuple_element and std::get to access the members of a std::pair
in unordered_{map,multimap}.
I'm in the process of refactoring the header to reduce
header dependencies throughout the library, and this is the only use
of
Hi Tobias,
> > However, an additional plain check on e->rank != 0 also in the
> > CLASS cases fixes the original issue as well as your example:
> [...]
> > And regtests ok. :-)
> > See attached updated patch.
>
> I think you still need to remove the 'return true;' from
> the 'if (e->rank != 0 &&
Ping https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555760.html
I've done a current bootstrap/regtest on powerpc64/powerpc64le with no
regressions.
-Pat
From: Andrew Pinski
The problem here is the x86_64 back-end uses a signed integer
for alignment and then divides by BITS_PER_UNIT so if we had
INT_MIN (which is what 1<<28*8 is), we would get the wrong result.
This fixes the problem by using unsigned for the argument to
x86_output_aligned_bss an
On 7/23/21 8:15 AM, Tobias Burnus wrote:
Hi Sandra,
On 21.07.21 12:17, Tobias Burnus wrote:
On 13.07.21 23:28, Sandra Loosemore wrote:
ISO_Fortran_binding.h is now generated in the libgfortran build
directory where it is on the default include path. Adjust includes in
the gfortran testsuite n
On Fri, 23 Jul 2021 10:33:09 -0600
Jeff Law wrote:
> On 7/22/2021 5:15 PM, Sergei Trofimovich via Gcc-patches wrote:
> > From: Sergei Trofimovich
> >
> > r12-1804 ("cp: add support for per-location warning groups.") among other
> > things removed warning suppression from a few places including p
78 matches
Mail list logo
