Where should I report security related issues?
Dear maintainers, Recently I found some vulnerabilities in one of the GCC libraries. Is there any private list or something like that to report it or should I use the GCC bug tracker? Thanks in advance, Charo
Re: Where should I report security related issues?
* Charo: > Is there any private list or something like that to report it > or should I use the GCC bug tracker? You could pick one of the distributions and let them handle this: * Debian * Red Hat * SUSE Just contacting one distribution is sufficient.
Re: Problems in IPA passes
On 11/01/2017 12:31 AM, Richard Biener wrote:
In my local tree I'm just passing around the vrp_bitmap_obstack right
now. Nobody's accessing it via a global anymore. So at least we know
what routines directly or indirectly want to touch vrp_bitmap_obstack.
Maybe that's not necessary in most places given existing bitmaps know their
obstack? IIRC most places do sth to equivalences only if a range already
contains some.
I'd think that would help significantly if we're willing to make the
assumption that all the bitmap allocations come from the same bitmap
obstack.
For example set_value_range:
/* Since updating the equivalence set involves deep copying the
bitmaps, only do it if absolutely necessary. */
if (vr->equiv == NULL
&& equiv != NULL)
vr->equiv = BITMAP_ALLOC (equiv_obstack);
If we assume that the equivalences always allocate from the same
obstack, we can recover equiv_obstack from equiv->obstack when vr->equiv
is NULL.
We see a similar pattern in vrp_intersection_ranges_1:
/* The resulting set of equivalences for range intersection is the
union of
the two sets. */
if (vr0->equiv && vr1->equiv && vr0->equiv != vr1->equiv)
bitmap_ior_into (vr0->equiv, vr1->equiv);
else if (vr1->equiv && !vr0->equiv)
{
vr0->equiv = BITMAP_ALLOC (equiv_obstack);
bitmap_copy (vr0->equiv, vr1->equiv);
}
We can use vr1->equiv->obstack to get to the obstack when vr0->equiv is
NULL.
But the first, in set_value_range is probably the most important.
This may also enable certain functions to remain as free functions
rather than having to move into a class. They should be easy to spot as
well.
Again, the positive is this can be tested very quickly now. The joys of
losing the global and getting some refactoring in done :-)
Jeff
Re: Problems in IPA passes
On November 1, 2017 3:12:05 PM GMT+01:00, Jeff Law wrote:
>On 11/01/2017 12:31 AM, Richard Biener wrote:
>
>>> In my local tree I'm just passing around the vrp_bitmap_obstack
>right
>>> now. Nobody's accessing it via a global anymore. So at least we
>know
>>> what routines directly or indirectly want to touch
>vrp_bitmap_obstack.
>>
>> Maybe that's not necessary in most places given existing bitmaps know
>their obstack? IIRC most places do sth to equivalences only if a range
>already contains some.
>I'd think that would help significantly if we're willing to make the
>assumption that all the bitmap allocations come from the same bitmap
>obstack.
I think we can. Maybe add a comment with respect to that to the equiv field.
>For example set_value_range:
>
> /* Since updating the equivalence set involves deep copying the
> bitmaps, only do it if absolutely necessary. */
> if (vr->equiv == NULL
> && equiv != NULL)
> vr->equiv = BITMAP_ALLOC (equiv_obstack);
>
>If we assume that the equivalences always allocate from the same
>obstack, we can recover equiv_obstack from equiv->obstack when
>vr->equiv
>is NULL.
>
>We see a similar pattern in vrp_intersection_ranges_1:
>
> /* The resulting set of equivalences for range intersection is the
>union of
> the two sets. */
> if (vr0->equiv && vr1->equiv && vr0->equiv != vr1->equiv)
> bitmap_ior_into (vr0->equiv, vr1->equiv);
> else if (vr1->equiv && !vr0->equiv)
> {
> vr0->equiv = BITMAP_ALLOC (equiv_obstack);
> bitmap_copy (vr0->equiv, vr1->equiv);
> }
>
>We can use vr1->equiv->obstack to get to the obstack when vr0->equiv is
>
>NULL.
>
>But the first, in set_value_range is probably the most important.
>
>This may also enable certain functions to remain as free functions
>rather than having to move into a class. They should be easy to spot
>as
>well.
>
>Again, the positive is this can be tested very quickly now. The joys
>of
>losing the global and getting some refactoring in done :-)
:)
Thanks for doing this work! (... Strikes one item from too long todo list...)
Richard.
>Jeff
Re: Problems in IPA passes
On 11/01/2017 08:24 AM, Richard Biener wrote: On November 1, 2017 3:12:05 PM GMT+01:00, Jeff Law wrote: On 11/01/2017 12:31 AM, Richard Biener wrote: In my local tree I'm just passing around the vrp_bitmap_obstack right now. Nobody's accessing it via a global anymore. So at least we know what routines directly or indirectly want to touch vrp_bitmap_obstack. Maybe that's not necessary in most places given existing bitmaps know their obstack? IIRC most places do sth to equivalences only if a range already contains some. I'd think that would help significantly if we're willing to make the assumption that all the bitmap allocations come from the same bitmap obstack. I think we can. Maybe add a comment with respect to that to the equiv field. Sounds wise :-) Again, the positive is this can be tested very quickly now. The joys of losing the global and getting some refactoring in done :-) :) Thanks for doing this work! (... Strikes one item from too long todo list...) Glad to help. So with new way to find the obstack we can do away with passing around the equiv_obstack entirely. Not sure what the biggest wart is now... Hmm, I guess that's a good place to be. There's still certainly cleanup to do, but it's coming together nicely. It's probably time to carve off some chunks that are ready to commit. Like the obstack cleanup :-) Jeff
Re: Where should I report security related issues?
On 11/01/2017 03:22 AM, Florian Weimer wrote: * Charo: Is there any private list or something like that to report it or should I use the GCC bug tracker? You could pick one of the distributions and let them handle this: * Debian * Red Hat * SUSE Just contacting one distribution is sufficient. Or he could just report them into the GCC bugzilla. jeff
libmvec simd math functions in fortran
is there a way to get vectorized math functions in fortran? in c code there is attribute simd declarations or openmp declare simd pragma to tell the compiler which functions have simd variant, but i see no such thing in fortran. some targets have -mveclibabi=type which allows vectorizing a set of math functions, but this does not support the libmvec abi of glibc.
Re: libmvec simd math functions in fortran
On Wed, Nov 01, 2017 at 04:23:11PM +, Szabolcs Nagy wrote: > is there a way to get vectorized math functions in fortran? > > in c code there is attribute simd declarations or openmp > declare simd pragma to tell the compiler which functions > have simd variant, but i see no such thing in fortran. !$omp declare simd should work fine in fortran (with -fopenmp or -fopenmp-simd). Jakub
Re: Where should I report security related issues?
* Jeff Law: > On 11/01/2017 03:22 AM, Florian Weimer wrote: >> * Charo: >> >>> Is there any private list or something like that to report it >>> or should I use the GCC bug tracker? >> >> You could pick one of the distributions and let them handle this: >> >> * Debian >> * Red Hat >> * SUSE >> >> Just contacting one distribution is sufficient. > Or he could just report them into the GCC bugzilla. Sure, it's the likely outcome of contacting the distros first, assuming the issue is not critical. If it is critical (which admittedly is unlikely), then giving distros time to prepare fixes might be warranted. The distro security teams usually can make this determination quickly, so contacting them is just a minor detour.
Re: libmvec simd math functions in fortran
On 01/11/17 16:26, Jakub Jelinek wrote: > On Wed, Nov 01, 2017 at 04:23:11PM +, Szabolcs Nagy wrote: >> is there a way to get vectorized math functions in fortran? >> >> in c code there is attribute simd declarations or openmp >> declare simd pragma to tell the compiler which functions >> have simd variant, but i see no such thing in fortran. > > !$omp declare simd should work fine in fortran (with -fopenmp > or -fopenmp-simd). > 1) i don't want to change the fortran. 2) it does not work for me. i want this to call vector powf in libmvec: subroutine foo(a,b,c) real(4) a(8000),b(8000),c(8000) do j=1,8000 a(j)=b(j)**c(j) end do end where do i put !$omp declare simd (powf) ?
gcc-6-20171101 is now available
Snapshot gcc-6-20171101 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/6-20171101/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-6-branch revision 254328 You'll find: gcc-6-20171101.tar.xzComplete GCC SHA256=5f50ecd5ba9e3bb3196ad68f1572afe0f21ae2c509e620fc4780f6bbd5c9093a SHA1=75736b80ba56eee5784077f051f4052e2911981f Diffs from 6-20171025 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-6 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
