Hi Martin!
On 11/12/22 16:56, Martin Uecker wrote:
Am Samstag, den 12.11.2022, 14:54 + schrieb Joseph Myers:
On Sat, 12 Nov 2022, Alejandro Colomar via Gcc wrote:
Since it's to be used as an rvalue, not as a lvalue, I guess a
postfix-expression wouldn't be the right one.
Several forms o
Hi Martin,
On 11/13/22 14:19, Alejandro Colomar wrote:
But there are not only syntactical problems, because
also the type of the parameter might become relevant
and then you can get circular dependencies:
void foo(char (*a)[sizeof *.b], char (*b)[sizeof *.a]);
This seems to be a difficult sto
On 11/13/22 14:33, Alejandro Colomar wrote:
Hi Martin,
On 11/13/22 14:19, Alejandro Colomar wrote:
But there are not only syntactical problems, because
also the type of the parameter might become relevant
and then you can get circular dependencies:
void foo(char (*a)[sizeof *.b], char (*b)[s
Am Sonntag, den 13.11.2022, 15:02 +0100 schrieb Alejandro Colomar:
>
> On 11/13/22 14:33, Alejandro Colomar wrote:
> > Hi Martin,
> >
> > On 11/13/22 14:19, Alejandro Colomar wrote:
> > > > But there are not only syntactical problems, because
> > > > also the type of the parameter might become re
Hi Martin,
On 11/13/22 15:58, Martin Uecker wrote:
Am Sonntag, den 13.11.2022, 15:02 +0100 schrieb Alejandro Colomar:
On 11/13/22 14:33, Alejandro Colomar wrote:
On 11/13/22 14:19, Alejandro Colomar wrote:
But there are not only syntactical problems, because
also the type of the parameter m
Am Sonntag, den 13.11.2022, 16:15 +0100 schrieb Alejandro Colomar:
> Hi Martin,
>
> On 11/13/22 15:58, Martin Uecker wrote:
> > Am Sonntag, den 13.11.2022, 15:02 +0100 schrieb Alejandro Colomar:
> > > On 11/13/22 14:33, Alejandro Colomar wrote:
> > > > On 11/13/22 14:19, Alejandro Colomar wrote:
>
On 11/11/22 22:10, Sandra Loosemore wrote:
> On 11/11/22 13:52, Gerald Pfeifer wrote:
>> On Tue, 8 Nov 2022, Martin Liška wrote:
>>> After the migration, people should be able to build (and install) GCC
>>> even if they miss Sphinx (similar happens now if you miss makeinfo).
>>
>> My nightly *insta
Based on discussions in the last few weeks, aren't most of the cases in
tree_call_nonnegative_warnv_p() wrong when honoring NANS?
For example:
CASE_CFN_ACOS:
CASE_CFN_ACOS_FN:
CASE_CFN_ACOSH:
CASE_CFN_ACOSH_FN:
...
...
/* Always true. */
return true;
But are we guar
Hi Martin,
On 11/13/22 16:32, Martin Uecker wrote:
Am Sonntag, den 13.11.2022, 16:15 +0100 schrieb Alejandro Colomar:
Hi Martin,
On 11/13/22 15:58, Martin Uecker wrote:
Am Sonntag, den 13.11.2022, 15:02 +0100 schrieb Alejandro Colomar:
On 11/13/22 14:33, Alejandro Colomar wrote:
On 11/13/22
SYNOPSIS:
unary-operator: . identifier
DESCRIPTION:
- It is not an lvalue.
- This means sizeof() and _Lengthof() cannot be applied to them.
- This prevents ambiguity with a designator in an initializer-list within a
nested braced-initializer.
- The type of a .identifier is alway
On 11/13/22 17:28, Alejandro Colomar wrote:
SYNOPSIS:
unary-operator: . identifier
DESCRIPTION:
- It is not an lvalue.
- This means sizeof() and _Lengthof() cannot be applied to them.
Sorry, the above is a thinko.
I wanted to say that, like sizeof() and _Lengthof(), you can't ass
On 11/13/22 17:31, Alejandro Colomar wrote:
On 11/13/22 17:28, Alejandro Colomar wrote:
SYNOPSIS:
unary-operator: . identifier
DESCRIPTION:
- It is not an lvalue.
- This means sizeof() and _Lengthof() cannot be applied to them.
Sorry, the above is a thinko.
I wanted to say tha
On 11/13/22 17:34, Alejandro Colomar wrote:
On 11/13/22 17:31, Alejandro Colomar wrote:
On 11/13/22 17:28, Alejandro Colomar wrote:
SYNOPSIS:
unary-operator: . identifier
DESCRIPTION:
- It is not an lvalue.
- This means sizeof() and _Lengthof() cannot be applied to them.
Sor
Hi,
While discussing some idea for a new feature, I tested the following example
program:
int main(void)
{
int i = i;
return i;
}
It seems obvious that it should give a warning, and in Clang it does:
$ clang --version | head -n1
Debian clang version 14.
On Sun, Nov 13, 2022 at 10:36 AM Alejandro Colomar via Gcc
wrote:
>
> Hi,
>
> While discussing some idea for a new feature, I tested the following example
> program:
>
>
> int main(void)
> {
> int i = i;
> return i;
> }
This is NOT a bug but a documented way of ha
On Sun, Nov 13, 2022 at 10:40 AM Andrew Pinski wrote:
>
> On Sun, Nov 13, 2022 at 10:36 AM Alejandro Colomar via Gcc
> wrote:
> >
> > Hi,
> >
> > While discussing some idea for a new feature, I tested the following example
> > program:
> >
> >
> > int main(void)
> > {
> > int i
Hi Andrew!
On 11/13/22 19:41, Andrew Pinski wrote:
On Sun, Nov 13, 2022 at 10:40 AM Andrew Pinski wrote:
On Sun, Nov 13, 2022 at 10:36 AM Alejandro Colomar via Gcc
wrote:
Hi,
While discussing some idea for a new feature, I tested the following example
program:
int main(void)
On Sun, Nov 13, 2022 at 10:41 AM Andrew Pinski wrote:
>
> On Sun, Nov 13, 2022 at 10:40 AM Andrew Pinski wrote:
> >
> > On Sun, Nov 13, 2022 at 10:36 AM Alejandro Colomar via Gcc
> > wrote:
> > >
> > > Hi,
> > >
> > > While discussing some idea for a new feature, I tested the following
> > > ex
I suppose most of the calls to tree_expr_nonnegative_p that apply to
floats in match.pd and tree-ssa-math-opts.cc are guarded by
!HONOR_NANS || tree_expr_nonnegative_p. Still feels kinda delicate...
Aldy
On Sun, Nov 13, 2022 at 4:56 PM Aldy Hernandez wrote:
>
> Based on discussions in the last
On 11/13/22 17:56, Alejandro Colomar wrote:>>> On 11/13/22 17:28, Alejandro
Colomar wrote:
SYNOPSIS:
unary-operator: . identifier
DESCRIPTION:
- It is not an lvalue.
- This means sizeof() and _Lengthof() cannot be applied to them.
Sorry, the above is a thinko.
I wanted to say that,
Hi!
I'd like to get warnings if I write the following code:
char foo[3] = "foo";
It's hard to keep track of sizes to make sure that the string literals always
initialize to terminated strings. It seems something that should be easy to
implement in the compiler.
A morecomplex case where it'
On Sun, Nov 13, 2022 at 1:57 PM Alejandro Colomar via Gcc
wrote:
>
> Hi!
>
> I'd like to get warnings if I write the following code:
>
> char foo[3] = "foo";
This should be easy to add as it is already part of the -Wc++-compat
option as for C++ it is invalid code.
:2:19: warning: initializer-str
Snapshot gcc-13-20221113 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/13-20221113/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 13 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
Hi.
The situation with the Sphinx migration went out of control. The TODO list
overwhelmed me and there are road-blocks that can't be easily fixed with what
Sphinx currently supports. That would require addition of an upstream support
and
a possible new Sphinx release.
Let me summarize the bigge
> On 21 Oct 2022, at 09:40, Florian Weimer via Gcc wrote:
>
> What should we do about these when they are not relevant to what's being
> tested? For example, gcc/testsuite/gcc.c-torture/execute/ieee/mzero6.c
> has this:
>
> int main ()
> {
>if (__builtin_copysign (1.0, func (0.0 / -5.0,
25 matches
Mail list logo
