Hello,
I want to begin by apologizing because I know from first hand experience
that scheduling can be an immensely painful job.
The Cauldron 2023 schedule[1] looks packed and I noticed that Qing and
David's talks on security features and diagnostics respectively are in
the same time slot.
On 2023-08-08 20:14, enh wrote:
(bionic maintainer here, mostly by accident...)
yeah, we tried the GCC attributes once before with _disastrous_
results (because GCC saw it as an excuse to delete explicit null
checks, it broke all kinds of things). the clang attributes are
AFAICT based on earli
On 2023-02-17 17:58, Alejandro Colomar wrote:
On 2/17/23 22:41, Siddhesh Poyarekar wrote:
On 2023-02-17 16:39, Siddhesh Poyarekar wrote:
You've got the customs right as far as submission is concerned; gcc
Oh, one correction: patches typically go to gcc-patches at gcc dot gnu
dot org.
On 2023-02-17 16:39, Siddhesh Poyarekar wrote:
You've got the customs right as far as submission is concerned; gcc
Oh, one correction: patches typically go to gcc-patches at gcc dot gnu
dot org.
Thanks,
Sid
Iker Pedrosa
Cc: Jens Gustedt
Cc: Jonathan Wakely
Cc: Mark Wielaard
Cc: Martin Uecker
Cc: Michael Kerrisk
Cc: Paul Eggert
Cc: Sam James
Cc: Siddhesh Poyarekar
Cc: Yann Droneaud
Signed-off-by: Alejandro Colomar
---
Hi Siddhesh,
Here's a patch for it. It is untested yet. Please have
On 2023-02-17 09:01, Mark Wielaard wrote:
The reason people might not know about it, is that the documentation is
somewhat unclear. -Wall says it already includes -Wuse-after-free=3:
https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wall
Yeah I posted a patch to fix it only a few mi
On 2023-02-17 08:44, David Malcolm wrote:
This is possibly a silly question, but what *are* these safe
alternatives? [1] How does one test to see if an object has been
reallocated?
Oops sorry, I snipped off that part when pasting from the man page.
Typically such conditionals are used to updat
On 2023-02-17 06:22, Alejandro Colomar wrote:
Hi Siddhesh,
On 2/17/23 04:48, Siddhesh Poyarekar wrote:
On 2023-02-16 10:15, David Malcolm via Gcc wrote:
I'm not convinced that it's useful to the end-user to warn about the
"use of q itself" case.
FWIW, -Wuse-after-free
On 2023-02-17 06:24, Jonathan Wakely wrote:
Please be aware that in C++ it's implementation-defined, not undefined.
That means that an implementation without trap representations for
pointers can choose to make it behave just like using (uintptr_t)p.
https://cplusplus.github.io/CWG/issues/143
On 2023-02-16 10:15, David Malcolm via Gcc wrote:
I'm not convinced that it's useful to the end-user to warn about the
"use of q itself" case.
FWIW, -Wuse-after-free=3 already should do this:
At level 3, the warning also diagnoses uses of indeterminate pointers in
equality expressions. All u
On 2022-10-23 13:09, Frank Ch. Eigler wrote:
[...] To be specific, gcc steering committee and glibc FSF stewards
have announced the decision for their projects [...]
I may be missing something. All I've seen so far were some of the
leaders of some of the projects being joint signatories to a
On 2022-10-23 17:59, Christopher Faylor wrote:
On Sun, Oct 23, 2022 at 05:17:40PM -0400, Siddhesh Poyarekar wrote:
On 2022-10-23 16:57, Christopher Faylor wrote:
On Thu, Oct 13, 2022 at 02:25:29PM -0400, Christopher Faylor wrote:
Re: https://sourceware.org/pipermail/overseers/2022q4/018981
at 09:27:26AM -0400, Siddhesh Poyarekar wrote:
Given that the current sourceware admins have decided to block migration of
all sourceware assets to the LF IT, I don't have a stake on how they'd like
to handle this for sourceware. I could however, as a member of TAC (and as
member of projects
On 2022-10-23 12:07, Siddhesh Poyarekar via Overseers wrote:
sourceware, I assume that means he'd like to use sourceware as a mirror
or something similar) but gdb folks have been silent so far. Given how
gdb and binutils are coupled, the gdb conversation really needs to
happen at some
On 2022-10-23 07:33, Ian Kelling wrote:
Siddhesh Poyarekar via Overseers writes:
I personally do not think the current sourceware infrastructure, even
with the roadmap it promises is a viable alternative to what LF IT can
provide. There is a significant resource gap (e.g.
established
On 2022-10-23 11:16, Frank Ch. Eigler wrote:
Hi -
[...] Given that the current sourceware admins have decided to
block migration of all sourceware assets to the LF IT [...]
If you're trying to say that projects have not unanimously shown
interest in moving infrastructure to LF IT, just say t
g the hardware management to one of many companies (usually by
renting a physical server), but that is all totally feasible and not a
big cost.
Siddhesh Poyarekar via Overseers writes:
I want us to migrate
services to infrastructure with better funding (that's not just limite
On 2022-10-18 14:13, Siddhesh Poyarekar wrote:
only Job Corbet's questions to Carlos/David are pending an answer; I
s/Job/Jon/ sorry about misspelling your name.
Sid
On 2022-10-18 12:42, Christopher Faylor wrote:
On Tue, Oct 18, 2022 at 11:17:15AM -0400, Siddhesh Poyarekar wrote:
That is not true, Mark. Your objections and questions have been answered at
every stage, privately as well as publicly.
Actually, going back through this thread, I see
On 2022-10-18 05:50, Mark Wielaard wrote:
Hi Siddhesh,
On Mon, Oct 17, 2022 at 12:11:53PM -0400, Siddhesh Poyarekar wrote:
There seems to be little to discuss from the GNU toolchain perspective IMO;
Yes, it is clear you don't want any discussion or answer any questions
about the prop
On 2022-10-17 11:10, Mark Wielaard via Overseers wrote:
In the last year we did some really nice work for the sourceware
infrastructure. We setup the shared buildbot, got various companies and
I feel like you're taking this personally as an overseer; the proposal
to transition to LF IT is not
On 2022-10-13 14:25, Christopher Faylor via Overseers wrote:
Also, the FSF, being the existing fiscal sponsor to these projects,
surely needs to review the formal agreements before we sunset our
infrastructural offerings to glibc, gcc, binutils, and gdb and hand
control of the projects' infrastru
On 2022-10-06 18:57, Frank Ch. Eigler wrote:
[...] so that we continue to have them involved in the technical
direction of GNU toolchain infrastructure? [...]
"continue"? If the nature & degree of involvement we had so far in
the LF/GTI process is representative of the future, I'm not sure I
On 2022-10-06 17:36, Frank Ch. Eigler wrote:
[...] Or alternatively, "sourceware overseers" could become a body
that maintains sourceware and is able to get funding through SFC for
its activities?
Great idea -- and this is roughly what's happening. This "body"
consisting of key individuals has
On 2022-10-06 16:12, Christopher Faylor via Overseers wrote:
The silence from the proponents of this project is puzzling. I wonder
if this means there are more non-public negotiations going on somewhere,
leaving the community out of the loop.
The proponents of this project are members of the G
On 2022-10-06 16:02, Mark Wielaard wrote:
I had in fact missed the websites mention, sorry I overreacted to your
comment. In that case, I don't know if the GNU websites are actually part
of this proposal.
No worries. It seems everybody is somewhat unclear on the details of
this proposal. Makin
On 2022-10-04 15:05, Mark Wielaard wrote:
I did indeed. Both the proposal and these minutes mention migrating
websites without mentioning any specifics. Knowing which websites are
meant and why they need migration is useful information.
The FSF tech team is helping us coordinating things on over
On 2022-10-04 13:10, Christopher Faylor wrote:
On Tue, Oct 04, 2022 at 09:46:08AM -0400, Siddhesh Poyarekar wrote:
I made and shared this copy to dispel any further false speculation of
scope creep of the GTI proposal.
Who is doing the false speculation? Do you have a mailing list link
On 2022-10-04 10:41, Frank Ch. Eigler wrote:
I'm afraid I don't understand then what the point of comparing to LLVM
with respect to competitiveness or freedom was. AIUI, infrastructure
is an enabler, not really a competitive differentiator.
I suppose that's a difference in our perception then.
On 2022-10-04 10:19, Frank Ch. Eigler wrote:
I don't see a risk to freedom. The GNU toolchain is quite underfunded
compared to llvm/clang and IMO it's a major risk to maintain status quo on
that front. The GTI opens new avenues for funding aspects of the GNU
toolchain without affecting its core
On 2022-10-04 10:01, Frank Ch. Eigler wrote:
Hi -
[...] I think the LF proposal is the best long term way forward for
the GNU toolchain projects to remain competitive *and* Free. [...]
Can you elaborate what risks in terms of competitiveness or freedom
you foresee with the status quo? This i
On 2022-10-02 16:47, Mark Wielaard via Overseers wrote:
I've published the current GTI TAC meeting minutes to the glibc website:
https://www.gnu.org/software/libc/gti-tac/index.html
The slides from the LF IT are a good overview:
https://www.gnu.org/software/libc/gti-tac/LF%20IT%20Core%20Projects
Hello,
FYI, I'm working on a django and patchwork upgrade on sourceware today
so you might see some downtime in the morning and afternoon EDT.
Sid
a decl, or the attribute itself is appended to a
singly-linked list on that decl (for those things that don't directly
relate to fields of a decl).
I believe Siddhesh Poyarekar has been looking at attributes from the
glibc side of things, so I'm CCing him in case he has input on this.
I'
On 6/9/21 10:39 AM, Valentino Giudice wrote:
I was aware of that announcement, but it doesn't mention the mission
statement at all.
It appears that the decision in question was, at the time, in contrast
with the mission statement (rather than guided by it).
If the Steering Committee updates the
On 6/9/21 10:13 AM, Valentino Giudice via Gcc wrote:
Hi.
The Mission Statement of the GCC project recently changed without any
announcement.
Well there was an announcement; the changes in the mission statement
reflect the new reality introduced by that announcement:
https://gcc.gnu.org/pipe
On 4/18/21 1:08 PM, Christopher Dimech wrote:
The cause IMO is accessibility to other projects, most notably compiler
researchers and students who find it a lot easier to target llvm than
gcc because compiler-as-a-library. License may have been a factor for
some of those uses (e.g. I know some w
On 4/18/21 1:15 PM, Gabriel Ravier via Gcc wrote:
I'd like to see a source for that. It certainly seems like complete
bullshit to me, unless you're trying to tell me that they simultaneously
do not fund anything related to free software while also having policy
that mandates at least 20 percent
On 4/17/21 12:11 AM, NightStrike via Gcc wrote:
I was under the (likely incorrect, please enlighten me) impression
that the meteoric rise of LLVM had more to do with the license
allowing corporate contributors to ship derived works in binary form
without sharing proprietary code. Intel, IBM, nVi
On 4/12/21 12:55 PM, John Darrington wrote:
In GNU, there are no "senior" (or junior) developers/maintainers. Maintainers
have some specific responsibilities, with which developers are not emcumbered.
In almost all projects, the maintainers are also developers, but this need not
be the case. Bu
On 4/12/21 7:13 AM, Alexandre Oliva via Gcc wrote:
On Apr 11, 2021, Adhemerval Zanella wrote:
All the other active maintainers suggested you shouldn't have done that, but you
ignored it anyway.
How could I possibly have ignored something that hadn't happened yet?
There are irreconcilable d
On 4/6/21 3:57 PM, Richard Biener via Gcc wrote:
Seeing the word "dysfunction" I don't remember using I want to clarify
the non-openess which I intended to criticize. The SC is not "open" because:
- it appoints itself (new members, that is) - in fact in theory it
should be appointed
by the FS
On 3/28/21 8:20 PM, Alexandre Oliva wrote:
Thanks for clarifying your understanding of Nathan's goal.
I may indeed have misread and mistaken Nathan's goal and means.
I thought the goal was to improve the GCC community by addressing the
gender imbalance, and that the means (misguided, IMHO) was
On 3/27/21 7:08 PM, Alexandre Oliva via Gcc wrote:
It may be very convenient to paint a boogey-man and expel it because
that became fashionable. But sacrificing a goat or a lamb does not
expiate our own sins, and expelling someone who hasn't even been present
in the community can't be expected t
On 11/27/20 5:01 PM, Florian Weimer wrote:
I think the last part (the “bug”) is new. I welcome a consensus along
those lines. I just want to highlight this aspect.
Should we consider fixing behaviour if the bug manifests in a user
application and not in glibc itself? i.e. a crash because gl
On 11/26/20 12:57 AM, Joseph Myers wrote:
I think it would be a pain to maintain test coverage for unnormals (and
presumably all the other kinds of unsupported operands, and you'd need to
work out what semantics you want for pseudo-denormals as well since those
are the one kind of such representa
On 11/25/20 2:58 AM, Joseph Myers wrote:
glibc effectively treats them as unspecified behavior - we don't expect
them to produce any particular meaningful function return value (this
includes the possibility that such an invalid encoding might be returned
by a function given such an encoding as i
On 11/24/20 8:13 PM, Richard Biener wrote:
compiling isnanl to a quiet fp compare is wrong with
-fsignalling-nans: classification is not supposed to
signal exceptions for snan.
Can you open a bugreport for this? Note that the option is likely
to invoke isnanl from libm ...
I believe Szabolcs
On 11/24/20 7:46 PM, Adhemerval Zanella wrote:
Which is the currently take from gcc developers on this semantic change of
__builtin_isnanl? Are they considering current behavior of non classifying
the 'unnormal' as NAN the expected behavior and waiting glibc to follow
it or are they willing to al
On 11/24/20 7:11 PM, Szabolcs Nagy wrote:
ideally fpclassify (and other classification macros) would
handle all representations.
architecturally invalid or trap representations can be a
non-standard class but i think classifying them as FP_NAN
would break the least amount of code.
That's my im
Hi,
The Intel 80-bit long double format has a concept of "unnormal" numbers
that have a non-zero exponent and zero integer bit (i.e. bit 63) in the
mantissa; all valid long double numbers have their integer bit set to 1.
Unnormal numbers are mentioned in "8.2.2 Unsupported Double
Extended-Pr
On 17/05/20 05:15, Maciej W. Rozycki wrote:
> Siddhesh, would you care to tell us how much effort it would be to set up
> fresh patchwork? The patch traffic is surely much lower with DejaGnu than
> it is with glibc, and there would be no data to migrate (but we might want
> to feed a couple of
On 11/01/20 6:55 pm, Segher Boessenkool wrote:
> -ffreestanding means you might not have any of the C standard library,
> and -nostartfiles means you do not do any of the standard initialisation.
> Why then would you expect any ifunc to work?
>
Agreed, based on Alexander's feedback I have suggest
On 10/01/20 10:25 pm, Alexander Monakov wrote:
> On Fri, 10 Jan 2020, Siddhesh Poyarekar wrote:
>
>> I spent some time thinking about this and while it's trivial to fix by
>> disabling ifuncs for static glibc, I wanted a solution that wasn't such
>> a big hamm
Hello,
Ref: https://bugs.linaro.org/show_bug.cgi?id=5479
Statically built independent programs that implement their own program
entry points (i.e. -ffreestanding -nostartfiles) and call __builtin_*
functions break when the builtin function in question is implemented as
an IFUNC in glibc and the b
On 07/10/2018 08:19 PM, Frank Ch. Eigler wrote:
siddhesh wrote:
[...] We had discussed making addition of ChangeLog entries into the
commit message mandatory but the issue there is that commit logs
cannot be (or more precisely, should not be) modified after they're
pushed so errors in ChangeL
On 07/05/2018 05:02 PM, Richard Biener wrote:
I assumed you just want to remove the ChangeLog files, not change contents.
Thus I assumed the commit message would simply contain the ChangeLog
entry as we requie it today? In that case git log --grep would still provide
everything grepping ChangeLo
On Wednesday 17 January 2018 05:52 PM, Nathan Sidwell wrote:
> That was a local decision between (I presume) linaro and the FSF. A
> single assignment may cover multiple specific projects, or specify any.
I didn't sign my copyright papers through Linaro; I've had an individual
assignment on file
On 17-Jan-2018 02:02, "Jim Wilson" wrote:
On Tue, Jan 16, 2018 at 12:01 PM, Siddhesh Poyarekar
wrote:
> You need a separate assignment for every GNU project you intend to
> contribute to, so separate assignments for GCC, glibc, binutils, etc.
The form is the same for all GNU p
Hi Shahid,
You need a separate assignment for every GNU project you intend to
contribute to, so separate assignments for GCC, glibc, binutils, etc.
Siddhesh
On 17-Jan-2018 01:25, "Shahid Khan" wrote:
Thanks for the info, Jim.
Siddhesh,
Is there a separate copyright assignment for glibc or th
On Friday 22 December 2017 06:06 PM, Florian Weimer wrote:
> I cannot agree with that. Full commit review is an absolute requirement
> before we can eliminate ChangeLogs because the review needs to cover the
> author attribution.
We have agreed on doing full commit reviews multiple times (at leas
On Friday 22 December 2017 05:57 PM, Florian Weimer wrote:
> The Linux community does not have a tool-based solution for that. I
> think it mainly relies on lack of commit access for contributors.
Sure, but that's a minor detail to implement once we decide we don't
need ChangeLogs. As far as gli
On Friday 22 December 2017 05:41 PM, Florian Weimer wrote:
> *However*, my main problem with getting rid of ChangeLogs is that
> without a pull-request-based contribution procedure or some tool support
> like Gerrit, it's impossible to tell which parts of a patch submission> make
> it into a commi
On Wed, Nov 26, 2014 at 02:59:34PM -0800, Andrew Pinski wrote:
> Hi all,
> I am getting the following failure on the 32bit x86 glibc with the
> top of the trunk gcc 5.0 and glibc from the commit
> (e5e0d9a4f632735cf3bb440eecb5caee5eea44c1). While building
Is that the right commit?
Siddhesh
p
64 matches
Mail list logo
