Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #148799 > unrolled thread

Warning in LLVM Clang

Back to article view | Back to comp.lang.c

Contents

  Warning in LLVM Clang Mehdi Amini <atorrses@gmail.com> - 2020-01-06 17:57 +0330
    Warning in LLVM Clang chad <cdalten@gmail.com> - 2020-01-06 07:47 -0800
    Re: Warning in LLVM Clang Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-06 15:58 +0000
      Re: Warning in LLVM Clang Mehdi Amini <atorrses@gmail.com> - 2020-01-07 15:32 +0330
        Which compiler is it, anyway??? (Was: Warning in LLVM Clang) gazelle@shell.xmission.com (Kenny McCormack) - 2020-01-07 12:58 +0000
        Re: Warning in LLVM Clang Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-07 14:33 +0000
          Re: Warning in LLVM Clang Mehdi Amini <atorrses@gmail.com> - 2020-01-08 16:35 +0330
            Re: Warning in LLVM Clang David Brown <david.brown@hesbynett.no> - 2020-01-08 15:11 +0100
              Re: Warning in LLVM Clang Mehdi Amini <atorrses@gmail.com> - 2020-01-09 16:15 +0330
                Re: Warning in LLVM Clang David Brown <david.brown@hesbynett.no> - 2020-01-09 14:34 +0100
                  Re: Warning in LLVM Clang Mehdi Amini <atorrses@gmail.com> - 2020-01-09 17:49 +0330
                    Re: Warning in LLVM Clang Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-09 19:35 +0000
                      Re: Warning in LLVM Clang David Brown <david.brown@hesbynett.no> - 2020-01-10 10:28 +0100
                        Re: Warning in LLVM Clang Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-10 12:39 +0000
                          Re: Warning in LLVM Clang Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-10 12:57 +0000
                            Re: Warning in LLVM Clang Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-10 13:23 +0000
                          Re: Warning in LLVM Clang David Brown <david.brown@hesbynett.no> - 2020-01-10 14:09 +0100
                            Re: Warning in LLVM Clang Mehdi Amini <atorrses@gmail.com> - 2020-01-10 16:45 +0330
                            Re: Warning in LLVM Clang Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-10 13:20 +0000
                          Re: Warning in LLVM Clang Mehdi Amini <atorrses@gmail.com> - 2020-01-10 17:20 +0330
                            Re: Warning in LLVM Clang Mehdi Amini <atorrses@gmail.com> - 2020-01-10 17:24 +0330
                            Re: Warning in LLVM Clang Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-10 23:52 +0000
                          Re: Warning in LLVM Clang scott@slp53.sl.home (Scott Lurndal) - 2020-01-10 15:29 +0000
                            Re: Warning in LLVM Clang Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-10 23:28 +0000
                      Re: Warning in LLVM Clang Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-11 14:21 +0000
                Re: Warning in LLVM Clang James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-09 22:08 -0500
                  Not exactly an "alias", but that's just being a CLC pedant... (Was: Warning in LLVM Clang) gazelle@shell.xmission.com (Kenny McCormack) - 2020-01-10 09:52 +0000
                    Re: Not exactly an "alias", but that's just being a CLC pedant... (Was: Warning in LLVM Clang) David Brown <david.brown@hesbynett.no> - 2020-01-10 11:26 +0100
                  Re: Warning in LLVM Clang Mehdi Amini <atorrses@gmail.com> - 2020-01-10 16:48 +0330
                    Re: Warning in LLVM Clang Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-10 09:34 -0800
                      Re: Warning in LLVM Clang Mehdi Amini <atorrses@gmail.com> - 2020-01-11 14:41 +0330
    Re: Warning in LLVM Clang Guillaume <message@bottle.org> - 2020-01-06 17:23 +0100
      Re: Warning in LLVM Clang Mehdi Amini <atorrses@gmail.com> - 2020-01-07 15:39 +0330

Page 2 of 2 — ← Prev page 1 [2]

#148907

On 1/10/20 5:20 PM, Mehdi Amini wrote:
> On 1/10/20 4:09 PM, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:

[...]

> Code1:
> if(gameNr < 0 || appData.tourneyType < 1 ||  // gauntlet engine can 
> always stay loaded as first engine

Complete line is:
if(gameNr < 0 || appData.tourneyType < 1 ||  // gauntlet engine can 
always stay loaded as first engine
	 appData.tourneyType > 1 && nextGame/round != gameNr/round) // in 
multi-gauntlet change only after round

[...]

-- 
www.my-c-codes.com/

Farewell.

[toc] | [prev] | [next] | [standalone]

#148917

Mehdi Amini <atorrses@gmail.com> writes:

> On 1/10/20 4:09 PM, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>> <cut>
>>> I'd say "fix the code", rather than living with the warnings.
>>
>> In this case, I'm not sure that's the right approach.  If I recall
>> correctly the code is old and stable (some X-Windows program or other)
>> so leaving it well alone might be the safest option.
>>
>> <cut>
>>
>
> Code is a chess GUI which is open-source here available:
>
> https://www.gnu.org/prep/ftp.html
>
> Select a mirror from the list , choose "xboard" package. For now latest
> version is 4.9.1 .
>
> I remember compiling/installing it was not easy job though.
>
> Now some typical warnings from original code:
>
> Code1:
> if(gameNr < 0 || appData.tourneyType < 1 ||  // gauntlet engine can always stay loaded as first engine
>
> Warns1:
>   CC       backend.o
> backend.c: In function ‘ReserveGame’:
> backend.c:1538:7: warning: this ‘if’ clause does not guard... [-Wmisleading-indentation]
>        if(gameNr < 0 || appData.tourneyType < 1 ||  // gauntlet engine can always stay loaded as first engine
>        ^~

This warning is about code the looks like this:

  if (C)
    S1;
    S2;

The warning is asking you to check if it should be

  if (C) {
    S1;
    S2;
  }

or

  if (C)
    S1;
  S2;

> Code2:
>   { "x", ArgInt, (void *) &wpMain.x, TRUE, (ArgIniType) CW_USEDEFAULT },
> Warns2:
> ./args.h:791:44: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
>    { "x", ArgInt, (void *) &wpMain.x, TRUE, (ArgIniType) CW_USEDEFAULT },
>                                             ^

This one is less interesting.  CW_USEDEFAULT is (probably) a constant of
type int and ArgIniType is (probably) a 64-bit pointer type.  You can
fix this one by including stdint.h and writing

  { "x", ArgInt, (void *) &wpMain.x, TRUE, (ArgIniType)(intptr_t)CW_USEDEFAULT },

> Can I fix such warnings ?

Sure, but is it worth it?  Some might be bugs so you would be helping
out and your patches to the source would be welcome, but others might be
considered as adding noise to the code so you'd be doing it for your own
satisfaction.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#148911

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>David Brown <david.brown@hesbynett.no> writes:
><cut>
>> I'd say "fix the code", rather than living with the warnings.
>
>In this case, I'm not sure that's the right approach.  If I recall
>correctly the code is old and stable (some X-Windows program or other)
>so leaving it well alone might be the safest option.

Since most of that code was written in a 32-bit world, if you're building
it in 64-bit worlds  -Wall is probably a good idea to sort out any
pointer casting issues.

[toc] | [prev] | [next] | [standalone]

#148916

scott@slp53.sl.home (Scott Lurndal) writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>David Brown <david.brown@hesbynett.no> writes:
>><cut>
>>> I'd say "fix the code", rather than living with the warnings.
>>
>>In this case, I'm not sure that's the right approach.  If I recall
>>correctly the code is old and stable (some X-Windows program or other)
>>so leaving it well alone might be the safest option.
>
> Since most of that code was written in a 32-bit world, if you're building
> it in 64-bit worlds  -Wall is probably a good idea to sort out any
> pointer casting issues.

Yes, good point.  But I don't think the code is abandoned, it just has
some old parts (that's my guess anyway).  In other words, he might be
wise to assume that such issues have been addressed at some point in the
last decade or two.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#148934

On Thu, 2020-01-09, Jorgen Grahn wrote:
> On Thu, 2020-01-09, Mehdi Amini wrote:
...

>> Can I change the Makefile as I originally intended , that is , is it
>> safe to change these :
>>
>> CC = gcc
>> CCDEPMODE = depmode=gcc3
>> CFLAGS =   -Wall -Wno-parentheses
>>
>> to
>>
>> CC = gcc
>> CCDEPMODE = depmode=gcc3
>> CFLAGS =
>>
>> Then enable warnings on a specific part of code with what you said ? or 
>> even other warnings like -Wextra ?
>>
>> #pragma GCC diagnostic warning "-Wall"
>
> I strongly recommend enabling maximum warnings in the Makefile (in
> CFLAGS), and if it's really necessary, disabling warnings for certain
> files, also in the Makefile:
>
>   my_weird_file.o: CFLAGS+=-Wno-parentheses

It later turned out the OP wasn't using Make but the Autoconf stuff
(which happens to generate a temporary Makefile).  So the advice above
is not really applicable.  I don't know how to deal with Autoconf,
e.g. if it's possible to tell it to use different compiler options for
different files.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#148892

On 1/9/20 7:45 AM, Mehdi Amini wrote:
...
> https://www.tutorialspoint.com/compile_c_online.php
> 
> Code:
> // pragma problem
> #include <stdlib.h>
> 
> #pragma clang diagnostic push
> #pragma clang diagnostic warning "-Wall" // -Weverything
> int main(void)
> {
>      //exit(1);
>      return 0;
> }
> #pragma clang diagnostic pop
> 
> Result:
> $gcc -o main *.c -Wall -Wno-parentheses
> main.c:4:0: warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
>   #pragma clang diagnostic push
> 
> main.c:5:0: warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
>   #pragma clang diagnostic warning "-Wall" // -Weverything
> 
> main.c:11:0: warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
>   #pragma clang diagnostic pop
> 
> $main

I've heard that there are platforms where "gcc" is actually an alias for
clang. Do you have any reason to believe that's the case on the system
you're using? It doesn't look like it. Try "gcc --version".

[toc] | [prev] | [next] | [standalone]

#148896 — Not exactly an "alias", but that's just being a CLC pedant... (Was: Warning in LLVM Clang)

In article <qv8pro$a4d$1@dont-email.me>,
James Kuyper  <jameskuyper@alumni.caltech.edu> wrote:
...
>I've heard that there are platforms where "gcc" is actually an alias for
>clang. Do you have any reason to believe that's the case on the system
>you're using? It doesn't look like it. Try "gcc --version".

I think the "He's on a Mac" theory, originally floated by me, has now been
put to rest.  Apparently, he's on Ubuntu.  It looks like he just has some
code that was written for Clang, and he now wants to compile it on a Ubuntu
system.

Also, "gcc" is not exactly an "alias" - in the usual sense of "alias",
i.e., a shell (bash or [t]csh) alias - on the Mac.  Rather, it is a small
(compiled) driver program that converts GCC style command line args into
their Clang equivalents, then invokes Clang, in a way that makes it seem
seamless (heh heh).  The point is that this conversion is necessary, since
Clang is *not* command line compatible with GCC (I.e, it is *not* a drop-in
replacement).

-- 
The randomly chosen signature file that would have appeared here is more than 4
lines long.  As such, it violates one or more Usenet RFCs.  In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
	http://user.xmission.com/~gazelle/Sigs/InsaneParty

[toc] | [prev] | [next] | [standalone]

#148897 — Re: Not exactly an "alias", but that's just being a CLC pedant... (Was: Warning in LLVM Clang)

On 10/01/2020 10:52, Kenny McCormack wrote:
> In article <qv8pro$a4d$1@dont-email.me>,
> James Kuyper  <jameskuyper@alumni.caltech.edu> wrote:
> ...
>> I've heard that there are platforms where "gcc" is actually an alias for
>> clang. Do you have any reason to believe that's the case on the system
>> you're using? It doesn't look like it. Try "gcc --version".
> 
> I think the "He's on a Mac" theory, originally floated by me, has now been
> put to rest.  Apparently, he's on Ubuntu.  It looks like he just has some
> code that was written for Clang, and he now wants to compile it on a Ubuntu
> system.

Yes, I think that is the case, from his posts.

> 
> Also, "gcc" is not exactly an "alias" - in the usual sense of "alias",
> i.e., a shell (bash or [t]csh) alias - on the Mac.  Rather, it is a small
> (compiled) driver program that converts GCC style command line args into
> their Clang equivalents, then invokes Clang, in a way that makes it seem
> seamless (heh heh).  The point is that this conversion is necessary, since
> Clang is *not* command line compatible with GCC (I.e, it is *not* a drop-in
> replacement).
> 

I did not realise that this "converter driver" was necessary.  Clang is
not a complete drop-in replacement for gcc, either in respect to the
command-line arguments or the way it handles code (especially for
implementation-dependent stuff and extensions), but it is quite close to
being compatible for a good many uses.

[toc] | [prev] | [next] | [standalone]

#148903

On 1/10/20 6:38 AM, James Kuyper wrote:
> On 1/9/20 7:45 AM, Mehdi Amini wrote:

[...]
> 
> I've heard that there are platforms where "gcc" is actually an alias for
> clang. Do you have any reason to believe that's the case on the system
> you're using? It doesn't look like it. Try "gcc --version".
> 
> 

Actually I wrote the clang specific #pragma 's. For one way , I can
change them to GCC specific ones.


-- 
www.my-c-codes.com/

Farewell.

[toc] | [prev] | [next] | [standalone]

#148914

Mehdi Amini <atorrses@gmail.com> writes:
> On 1/10/20 6:38 AM, James Kuyper wrote:
>> On 1/9/20 7:45 AM, Mehdi Amini wrote:
>
> [...]
>>
>> I've heard that there are platforms where "gcc" is actually an alias for
>> clang. Do you have any reason to believe that's the case on the system
>> you're using? It doesn't look like it. Try "gcc --version".
>
> Actually I wrote the clang specific #pragma 's. For one way , I can
> change them to GCC specific ones.

It sounds like you're still not certain whether you're using gcc or
clang.  James is correct, on some systems the "gcc" command invokes the
clang compiler.  I believe MacOS is one such system.  (Apple decided
they preferred clang over gcc, but a lot of build scripts assume the C
compiler is named "gcc".)

What OS are you on?  What does "gcc --version" print?  (That will tell
you whether "gcc" invokes gcc or clang.)  When you invoke your Makefile,
does it print the commands as it executes them, and does that tell you
what compiler command it's invoking?

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
    [Note updated email address]
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#148931

On 1/10/20 9:04 PM, Keith Thompson wrote:
> Mehdi Amini <atorrses@gmail.com> writes:
>> On 1/10/20 6:38 AM, James Kuyper wrote:
>>> On 1/9/20 7:45 AM, Mehdi Amini wrote:

[...]

> What OS are you on?  What does "gcc --version" print?  (That will tell
> you whether "gcc" invokes gcc or clang.)  When you invoke your Makefile,
> does it print the commands as it executes them, and does that tell you
> what compiler command it's invoking?
> 

:~$ sudo lsb_release -a
[sudo] password for mehdi:
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 18.04.3 LTS
Release:	18.04
Codename:	bionic

:~$ gcc --version
gcc (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I just have access to Makefile. I compile using Code::Blocks IDE "custom
makefile" feature. So I do not just use a text editor and terminal to
compile the code.From Makefile:

# Makefile.in generated by automake 1.15 from Makefile.am.
# Makefile.  Generated from Makefile.in by configure.

In "configure" beginning:
#! /bin/sh
# Guess values for system-dependent variables and create Makefiles.
# Generated by GNU Autoconf 2.69 for xboard 4.9.1.

-- 
www.my-c-codes.com/

Farewell.

[toc] | [prev] | [next] | [standalone]

#148803

Le 06/01/2020 à 15:27, Mehdi Amini a écrit :
> I have set the -w flag for Clang compiler , on one project I still get
> about 100 warnings ; why ?

Likely because the source code is atrociously non-conforming C.
Which IMO would be the first thing to fix before trying to shut up Clang 
about it...

[toc] | [prev] | [next] | [standalone]

#148833

On 1/6/20 7:53 PM, Guillaume wrote:
> Le 06/01/2020 à 15:27, Mehdi Amini a écrit :
>> I have set the -w flag for Clang compiler , on one project I still get
>> about 100 warnings ; why ?
> 
> Likely because the source code is atrociously non-conforming C.
> Which IMO would be the first thing to fix before trying to shut up Clang 
> about it...

I already posted a past thread about this project. Part of the code is
written for pre C89/C90 standard. As I have no alternative to this
project (called "XBoard") , I may continue working on it. My idea is to
disable warnings for others code and enable it for my own added code. In
future I may try to actually fix all warnings.

-- 
www.my-c-codes.com/

Farewell.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c

csiph-web