Re: Setting up editors for the GNU/GCC coding style?
On Thu, Jul 28, 2022 at 08:53:37PM +0100, Jonathan Wakely via Gcc wrote: > On Thu, 28 Jul 2022 at 20:49, Tim Lange wrote: > > > > > > > > On Thu, Jul 28 2022 at 02:46:58 PM -0400, David Malcolm via Gcc > > wrote: > > > Is there documentation on setting up text editors to work with our > > > coding style? A lot of the next generation of developers aren't using > > > vi or emacs; they's using VS Code, CLion, and other editors. Does > > > anyone have docs on e.g. how to set up VS Code, CLion, etc (IntelliJ > > > ?) > > > to work well on GCC's own code base. FWIW I use Emacs; I've dabbed > > > with VS Code but haven't used it "for real". > > > > I did prepare my first patch(es) with vscode. For debugging, I set up > > vscode to launch gcc with gdbserver as wrapper and then let the vscode > > debugger to connect to the gdbserver. At first, I tried to get the gnu > > coding style to work in the hacky way by using tabSize=8 and rebinding > > tab to 2 spaces but later ditched that because it bothered me more than > > doing just spaces and replacing 8 spaces with 1 tab before sending the > > patch. That still wastes time because all files that I didn't touch > > look ugly unless I temporarily change the tabSize and some comments > > don't use tabs so I can't just replace all 8 spaces with 1 tab. > > That's what unexpand(1) is for: > https://pubs.opengroup.org/onlinepubs/9699919799/utilities/unexpand.html I gave unexpand from GNU coreutils 8.32 a try. Looks like it cannot deal with form feeds or maybe I'm missing something? $ bash -c "printf 'foo\n\f\nbar\n'" | unexpand - foo unexpand: input line is too long
Re: Setting up editors for the GNU/GCC coding style?
On 7/28/22 21:49, Tim Lange wrote: > > > On Thu, Jul 28 2022 at 02:46:58 PM -0400, David Malcolm via Gcc > wrote: >> Is there documentation on setting up text editors to work with our >> coding style? A lot of the next generation of developers aren't using >> vi or emacs; they's using VS Code, CLion, and other editors. Does >> anyone have docs on e.g. how to set up VS Code, CLion, etc (IntelliJ ?) >> to work well on GCC's own code base. FWIW I use Emacs; I've dabbed >> with VS Code but haven't used it "for real". > > I did prepare my first patch(es) with vscode. For debugging, I set up vscode > to launch gcc with gdbserver as wrapper and then let the vscode debugger to > connect to the gdbserver. At first, I tried to get the gnu coding style to > work in the hacky way by using tabSize=8 and rebinding tab to 2 spaces but > later ditched that because it bothered me more than doing just spaces and > replacing 8 spaces with 1 tab before sending the patch. That still wastes > time because all files that I didn't touch look ugly unless I temporarily > change the tabSize and some comments don't use tabs so I can't just replace > all 8 spaces with 1 tab. For reference, my config files for gcc are available > at [0]. There's a vscode issue that is about the unsupported expansion of 8 spaces to a tab: https://github.com/microsoft/vscode/issues/42740 Btw. can we for the future leave this weird mix usage? Is it really an useful selection? Cheers, Martin > > - Tim > > [0] https://gist.github.com/timll/1c4c542c7c98e3610c14aec19cdf7e91 > >> >> I'm hoping to add this to my newbies guide. >> >> Thanks >> Dave >> > >
Re: Setting up editors for the GNU/GCC coding style?
On Mon, 1 Aug 2022 at 09:24, Stefan Schulze Frielinghaus wrote: > I gave unexpand from GNU coreutils 8.32 a try. Looks like it cannot > deal with form feeds or maybe I'm missing something? > > $ bash -c "printf 'foo\n\f\nbar\n'" | unexpand - > foo > unexpand: input line is too long Which linux distro are you using? I see this error on Fedora and Centos 8 but not on recent Debian or Ubuntu systems. I've reported a bug: https://bugzilla.redhat.com/show_bug.cgi?id=2112870
Re: Setting up editors for the GNU/GCC coding style?
On Mon, Aug 01, 2022 at 12:25:21PM +0100, Jonathan Wakely wrote:
> On Mon, 1 Aug 2022 at 09:24, Stefan Schulze Frielinghaus wrote:
> > I gave unexpand from GNU coreutils 8.32 a try. Looks like it cannot
> > deal with form feeds or maybe I'm missing something?
> >
> > $ bash -c "printf 'foo\n\f\nbar\n'" | unexpand -
> > foo
> > unexpand: input line is too long
>
> Which linux distro are you using? I see this error on Fedora and
> Centos 8 but not on recent Debian or Ubuntu systems.
I can reproduce this on Fedora {33,34,35} and on Ubuntu 20.04 it seems
to work.
[no subject]
rajaraju6...@gmail.co
Re: Setting up editors for the GNU/GCC coding style?
On Mon, 1 Aug 2022 at 13:16, Stefan Schulze Frielinghaus wrote:
>
> On Mon, Aug 01, 2022 at 12:25:21PM +0100, Jonathan Wakely wrote:
> > On Mon, 1 Aug 2022 at 09:24, Stefan Schulze Frielinghaus wrote:
> > > I gave unexpand from GNU coreutils 8.32 a try. Looks like it cannot
> > > deal with form feeds or maybe I'm missing something?
> > >
> > > $ bash -c "printf 'foo\n\f\nbar\n'" | unexpand -
> > > foo
> > > unexpand: input line is too long
> >
> > Which linux distro are you using? I see this error on Fedora and
> > Centos 8 but not on recent Debian or Ubuntu systems.
>
> I can reproduce this on Fedora {33,34,35} and on Ubuntu 20.04 it seems
> to work.
There's a fix in Fedora rawhide now, which will also make it into
RHEL, CentOS, and (I assume) F35 and F36.
Possible wrong-code bug in GCC?
Dear developers,
May I seek your confirmation to check whether the following program
triggers a true wrong-code issue in GCC? The following piece of code looks
too simple and I am not quite sure whether it's a bug or not.
Here is the test program (s.c):
```
int a = 0, b = 0;
int main() {
for (; a <= 6; a++) {
c:
b++;
if (b) {
goto c;
}
}
return 0;
}
```
$ gcc-trunk -O1 s.c ; ./a.out
(infinite loop)
$ gcc-trunk -O2 s.c ;./a.out
Godbolt: https://godbolt.org/z/dx6efvv7x
I guess the behavior of -O2 is normal as the if statement inside the
for-loop will be 0 after certain iterations. It's worth noting that almost
all versions of GCC behave the same in this case. Also, note that LLVM
behaves the same under the two optimization options; they all terminate the
execution in seconds.
So, before I make any noise in the GCC bug repo, may I quickly check with
you and see whether the `s.c` is a potential wrong code bug in GCC, or
did I miss any important information here? I will file a new bug report
for this issue if it is a true bug.
Thank you so much and looking forward to your reply!
Best regards,
Haoxin
Re: Possible wrong-code bug in GCC?
Oh, sorry for the noise, there is an integer overflow that may cause
undefined behavior.
Haoxin Tu 于2022年8月2日周二 11:23写道：
> Dear developers,
>
> May I seek your confirmation to check whether the following program
> triggers a true wrong-code issue in GCC? The following piece of code looks
> too simple and I am not quite sure whether it's a bug or not.
>
> Here is the test program (s.c):
> ```
> int a = 0, b = 0;
> int main() {
> for (; a <= 6; a++) {
> c:
> b++;
> if (b) {
> goto c;
> }
> }
> return 0;
> }
>
> ```
> $ gcc-trunk -O1 s.c ; ./a.out
> (infinite loop)
> $ gcc-trunk -O2 s.c ;./a.out
>
> Godbolt: https://godbolt.org/z/dx6efvv7x
>
> I guess the behavior of -O2 is normal as the if statement inside the
> for-loop will be 0 after certain iterations. It's worth noting that almost
> all versions of GCC behave the same in this case. Also, note that LLVM
> behaves the same under the two optimization options; they all terminate the
> execution in seconds.
>
> So, before I make any noise in the GCC bug repo, may I quickly check with
> you and see whether the `s.c` is a potential wrong code bug in GCC, or
> did I miss any important information here? I will file a new bug report
> for this issue if it is a true bug.
>
> Thank you so much and looking forward to your reply!
>
>
> Best regards,
> Haoxin
>
Re: Possible wrong-code bug in GCC?
On Tue, 2 Aug 2022 at 05:45, Haoxin Tu via Gcc wrote: > > Oh, sorry for the noise, there is an integer overflow that may cause > undefined behavior. You should check with UBsan before reporting something as a bug: s.c:5:2: runtime error: signed integer overflow: 2147483647 + 1 cannot be represented in type 'int'
