Re: [RFC/RFA][PATCH 00/12] CRC optimization

[NightStrike]

On Fri, May 24, 2024, 04:42 Mariam Arutunian 
wrote:

> Hello!
> This patch set detects bitwise CRC implementation loops (with branches) in
> the GIMPLE optimizers and replaces them with more optimal CRC
> implementations in RTL. These patches introduce new internal functions,
> built-in functions, and expanders for CRC generation, leveraging hardware
> instructions where available. Additionally, various tests are included to
> check CRC detection and generation. Main Features:
>
>1.
>
>CRC Loop Detection and Replacement:
>- Detection of CRC loops involves two stages: fast checks to identify
>   potential candidates and verification using symbolic execution. The
>   algorithm detects only CRCs (8, 16, 32, and 64 bits, both bit-forward 
> and
>   bit-reversed) with constant polynomials used without the leading 1. This
>   part can be improved to detect more implementation types.
>   - Once identified, the CRC loops are replaced with calls to newly
>   added internal functions. These internal functions use target-specific
>   expanders if available, otherwise generating table-based CRCs.
>2.
>
>Architecture-Specific Expanders:
>- Expanders are added for RISC-V, aarch64, and i386 architectures.
>   - These expanders generate CRCs using either carry-less
>   multiplication instructions or direct CRC instructions, based on the 
> target
>   architecture's capabilities.
>3.
>
>New Internal and Built-In Functions:
>- Introduces internal functions and built-in functions for CRC
>   generation, supporting various CRC and data sizes (8, 16, 32, and 64 
> bits).
>
> I presented this work during the GNU Tools Cauldron 2023. You can view the
> presentation here: GCC CRC optimization presentation
> 
> .
>
> Previously, I submitted a patch to GCC upstream that included built-in
> parts and expanders for RISC-V. However, the main component of the
> previously sent patch has been changed. You can find the patch here:
> https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626279.html
>
>
> Best regards,
> Mariam
>

Could this detect a specific CRC32C calculation as well (vs any urge CRC)
and replace it with optimized calls to the dedicated crc32c hardware
instructions via __builtin_ia32_crc32*i? I'm asking because ironically I
was just a few days ago trying to see how current GCC optimizes simpler but
slower approaches compared to hand tuning. For example,
https://github.com/htot/crc32c. Almost every implementation I found was
ultimately based on Mark Adler's (of zlib and that fun Mars mission fame)
implementation posted to stack overflow here:
https://stackoverflow.com/a/17646775

Because so many current libraries are based on that, it would be nice to
see if GCC can improve upon it with your patch. Or if they are no longer
necessary, because your patch optimizes the simpler software approach to
basically yield Mark's solution.

>

Re: [PATCH v2 2/3] diagnostics: Don't hardcode auto_enable_urls to false for mingw hosts

[NightStrike]

On Thu, May 9, 2024 at 1:03 PM Peter Damianov  wrote:
>
> Windows terminal and mintty both have support for link escape sequences, and 
> so
> auto_enable_urls shouldn't be hardcoded to false. For older versions of the
> windows console, mingw_ansi_fputs's console API translation logic does mangle
> these sequences, but there's nothing useful it could do even if this weren't
> the case, so check if the ansi escape sequences are supported at all.
>
> conhost.exe doesn't support link escape sequences, but printing them does not
> cause any problems.

Are there any issues when running under the Wine console, such as when
running the testsuite?

Re: [PATCH 03/21] testsuite: Add more allocation size tests for conjured svalues [PR110014]

[NightStrike]

On Thu, May 9, 2024 at 1:47 PM David Malcolm  wrote:
>
> From: Tim Lange 
>
> This patch adds the reproducers reported in PR 110014 as test cases. The
> false positives in those cases are already fixed with PR 109577.
>
> 2023-06-09  Tim Lange  
>
> PR analyzer/110014
>
> gcc/testsuite/ChangeLog:
>
> * gcc.dg/analyzer/realloc-pr110014.c: New tests.
>



> diff --git a/gcc/testsuite/gcc.dg/analyzer/realloc-pr110014.c 
> b/gcc/testsuite/gcc.dg/analyzer/realloc-pr110014.c
> new file mode 100644
> index 000..d76b8781413
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/analyzer/realloc-pr110014.c
> @@ -0,0 +1,25 @@
> +void *realloc (void *, unsigned long)
> +  __attribute__((__nothrow__, __leaf__))
> +  __attribute__((__warn_unused_result__)) __attribute__((__alloc_size__ 
> (2)));

This change missed my comment about the wrong type for realloc from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110014#c3

Can you please fix this on all branches?

Re: [PATCH 02/21] analyzer: Fix allocation size false positive on conjured svalue [PR109577]

[NightStrike]

On Thu, May 9, 2024 at 1:45 PM David Malcolm  wrote:
>
> From: Tim Lange 
>
> Currently, the analyzer tries to prove that the allocation size is a
> multiple of the pointee's type size.  This patch reverses the behavior
> to try to prove that the expression is not a multiple of the pointee's
> type size.  With this change, each unhandled case should be gracefully
> considered as correct.  This fixes the bug reported in PR 109577 by
> Paul Eggert.
>



> diff --git a/gcc/testsuite/gcc.dg/analyzer/pr109577.c 
> b/gcc/testsuite/gcc.dg/analyzer/pr109577.c
> new file mode 100644
> index 000..a6af6f7019f
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/analyzer/pr109577.c
> @@ -0,0 +1,16 @@
> +void *malloc (unsigned long);

This change missed my comment here describing this mistake:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109577#c5

Can you please fix this on all branches?

Re: [PATCH v2 00/13] Add aarch64-w64-mingw32 target

[NightStrike]

On Wed, Mar 20, 2024, 07:50 Radek Barton  wrote:

> Hello, everyone.
>
> I've re-run the `x86_64-w64-mingw32` target tests with all the languages
> enabled, except of Ada and JIT, which are harder to bootstrap, and Go,
> which is not supported by MinGW. The summarized results are:
>
> 536176 of expected passes
> 13859 of unexpected failures
> 188 of unexpected successes
> 4537 of expected failures
> 8271 of unresolved testcases
> 20958 of unsupported tests
> 97.40% of tests completes in expected way
>

You can generate an integrated summary using dejagnu report card:

https://www.gnu.org/software/dejagnu/manual/Invoking-dejagnu-report-card.html


> and, again, zero regressions were detected.
>
> The detailed results can be reviewed at
> https://github.com/Windows-on-ARM-Experiments/mingw-woarm64-build/actions/runs/8349019387
>
> Best regards,
>
> Radek Bartoň
>
> 
> From: Radek Barton 
> Sent: Monday, March 18, 2024 10:05 PM
> To: Evgeny Karpov; gcc-patches@gcc.gnu.org
> Cc: richard.sandif...@arm.com; Richard Earnshaw (lists); Andrew Pinski
> (QUIC); Maxim Kuvyrkov
> Subject: Re: [PATCH v2 00/13] Add aarch64-w64-mingw32 target
>
> Hello, everyone.
>
> Currently, we are able to provide results of regression testing for
> `x86_64-w64-mingw32` target with `--enable-languages=c,lto,c++,fortran`
> running in WSL only.
>
> The summarized results, both for the branch with patch set applied and its
> corresponding base branch, show:
>
> 517501 expected passes
> 4537 of expected failures
> 10828 unexpected failures
> 180 of unexpected successes
> 5934 of unresolved testcases
> 19113 of unsupported tests
>
> which means that 98% of the tests ends in an expected way and we haven't
> detected a single regression between the branches.
>
> The detailed results can be downloaded and reviewed at
> https://github.com/Windows-on-ARM-Experiments/mingw-woarm64-build/actions/runs/8327889403
>
> Best regards,
>
> Radek Bartoň
>

Re: [PATCH] c-c++-common/Wrestrict.c: fix some typos and enable for LLP64

[NightStrike]

On Sat, Mar 2, 2024, 08:24 Jonathan Yong <10wa...@gmail.com> wrote:

> On 2/15/24 14:08, Jonathan Yong wrote:
> > Attached patch OK?
> >
> > Copy/pasted for review convenience.
> Ping.
>

Pinging this for Jon. It's been a couple months, and this should be mostly
obvious if someone has a spare minute.

>

Re: [PATCH v1 00/13] Add aarch64-w64-mingw32 target

[NightStrike]

On Thu, Feb 29, 2024 at 11:26 AM Evgeny Karpov
 wrote:
>
> Monday, February 26, 2024 2:30 AM
> NightStrike wrote:
>
> > To be clear, because of the refactoring, it will affect x86/x64 Windows 
> > targets.
> > Can you do a testsuite run before and after and see that it doesn't get 
> > worse?
> > The full testsuite for all languages for Windows isn't in great shape, but 
> > it's not
> > awful.  Some languages, like Rust and Fortran, have ~10 FAILs.  C and C++ 
> > have
> > several thousand.
> >
> > In particular, there are quite a few testsuite test FAILs regarding MS ABI 
> > that
> > hopefully do not get worse.
> >
>
> Thank you for bringing it up! Our CI will be extended to test the x64
> mingw target and calculate a delta, starting from patch series v2.

Thanks.  You should probably include x86 also, at least for all the
areas that overlap.  I would like to compare my own test results with
yours when you have that ready.

You can send test results to the gcc mailing list setup for this
purpose: https://gcc.gnu.org/mailman/listinfo/gcc-testresults, and
there are scripts in contrib/ to help automate the process.  I
personally stopped, because the clusters I used had their mail sending
capabilities cut off, but I'm working on fixing that.

> > Lastly, I don't think I see in the current patch series where you add new
> > testsuite coverage for aarch64-specific bits.  I probably missed it, so 
> > feel free to
> > helpfully correct me there :)  I'd be curious to see how the tests were 
> > written to
> > take into account target differences (using for example the dejagnu feature
> > procs) and other nuances.
>
> Tests have not been added yet. This does not mean they do not exist
> or are not used. They are implemented and used in our CI, and will be
> contributed to the aarch64-w64-mingw32 target in the next patch
> series.
> https://github.com/Windows-on-ARM-Experiments/mingw-woarm64-build/tree/main/tests

Awesome!  These tests look like they are handled by your own custom
test harness, so hopefully it won't be too difficult to convert it all
to dejagnu.  Honestly, the sooner you do that, the better, because the
task is going to balloon.  You'll find that Deja offers all kinds of
neat and useful features that allow you to test all kinds of things,
so it'll result in better coverage in the end.

Re: [PATCH v1 08/13] aarch64: Add Cygwin and MinGW environments for AArch64

[NightStrike]

> -Original Message-
> Friday, February 23, 2024 6:16 PM
> Richard Sandiford wrote:
>
> > +
> > +#undef TARGET_SEH
> > +#define TARGET_SEH 0
> > +
> > +#define SSE_REGNO_P(N) 0
> > +#define GENERAL_REGNO_P(N) 0
>
> Could you add a comment to explain how these two macros are consumed?
> What is the effect of saying that everything is neither a general register 
> nor an SSE register?
>
> > +#define SEH_MAX_FRAME_SIZE 0

On Tue, Feb 27, 2024 at 4:17 PM Evgeny Karpov
 wrote:
>
> SEH is not implemented yet and needs to be disabled in mingw/winnt.cc. 
> Disabling every SEH function that uses references to these macros might 
> trigger significant refactoring, and to avoid this, required macros are 
> defined with 0. It is needed only for compilation. A comment with an 
> explanation will be added.

This is all the more reason why you need to show the full testsuite
run for x86/x64 mingw as per my previous message.  We do use SEH by
default on x64.

Also, this is a friendly reminder that the GCC list is a bottom
posting list, not top posting, which is the default for your email
client.  I fixed this email for you.

Re: Ping: Re: [PATCH] libgcc: fix SEH C++ rethrow semantics [PR113337]

[NightStrike]

On Wed, Feb 7, 2024 at 4:23 AM Matteo Italia  wrote:
>
> Il 06/02/24 10:17, Jonathan Yong ha scritto:
> > On 2/6/24 05:31, NightStrike wrote:
> >> On Mon, Feb 5, 2024, 06:53 Matteo Italia  wrote:
> >>
> >>> Il 31/01/24 04:24, LIU Hao ha scritto:
> >>>> 在 2024-01-31 08:08, Jonathan Yong 写道:
> >>>>> On 1/24/24 15:17, Matteo Italia wrote:
> >>>>>> Ping! That's a one-line fix, and you can find all the details in the
> >>>>>> bugzilla entry. Also, I can provide executables built with the
> >>>>>> affected toolchains, demonstrating the problem and the fix.
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Matteo
> >>>>>>
> >>>>>
> >>>>> I was away last week. LH, care to comment? Changes look fine to me.
> >>>>>
> >>>>
> >>>> The change looks good to me, too.
> >>>>
> >>>> I haven't tested it though. According to a similar construction around
> >>>> 'libgcc/unwind.inc:265' it should be that way.
> >>>
> >>> Hello,
> >>>
> >>> thank you for the replies, is there anything else I can do to help push
> >>> this forward?
> >>>
> >>
> >> Remember to mention the pr with the right syntax in the ChangeLog so the
> >> bot adds a comment field. I didn't see it in yours, but I might have
> >> missed
> >> it.
> >>
> >>>
> >>
> >
> > Thanks all, pushed to master branch.
>
> Thanks all :-) do you think this warrants backports? On one hand this is
> a pretty niche feature, and I am probably the first to notice the
> problem in ~12 years since that code was written, OTOH Win64/SEH was not
> super widespread for a long time, and seems like a safe enough change.

It's mostly up to you whether you want to make the patch and test it.

> Also: should I explicitly mark PR113337 as resolved? The bot added the
> reference to the commit, but the PR is still marked as "UNCONFIRMED".

Looks like Jon did that a few days ago.

Re: [PATCH v1 00/13] Add aarch64-w64-mingw32 target

[NightStrike]

On Wed, Feb 21, 2024 at 12:48 PM Evgeny Karpov
 wrote:
>
> Hello,
>
> We would like to take your attention to the review of changes for the
> new GCC target, aarch64-w64-mingw32. The new target will be
> supported, tested, added to CI, and maintained by Linaro. This marks
> the first of three planned patch series contributing to the GCC C
> compiler's support for Windows Arm64.
>
> 1. Minimal aarch64-w64-mingw32 C implementation to cross-compile
> hello-world with libgcc for Windows Arm64 using MinGW.
> 2. Extension of the aarch64-w64-mingw32 C implementation to
> cross-compile OpenSSL, OpenBLAS, FFmpeg, and libjpeg-turbo. All
> packages successfully pass tests.
> 3. Addition of call stack support for debugging, resolution of
> optimization issues in the C compiler, and DLL export/import for the
> aarch64-w64-mingw32 target.
>
> This patch series introduces the 1st point, which involves building
> hello-world for the aarch64-w64-mingw32 target. The patch depends on
> the binutils changes for the aarch64-w64-mingw32 target that have
> already been merged.
>
> The binutils should include recent relocation fixes.
> f87eaf8ff3995a5888c6dc4996a20c770e6bcd36
> aarch64: Add new relocations and limit COFF AArch64 relocation offsets
>
> The series is structured in a way to trivially show that it should not
> affect any other targets.

To be clear, because of the refactoring, it will affect x86/x64
Windows targets.  Can you do a testsuite run before and after and see
that it doesn't get worse?  The full testsuite for all languages for
Windows isn't in great shape, but it's not awful.  Some languages,
like Rust and Fortran, have ~10 FAILs.  C and C++ have several
thousand.

In particular, there are quite a few testsuite test FAILs regarding MS
ABI that hopefully do not get worse.

Lastly, I don't think I see in the current patch series where you add
new testsuite coverage for aarch64-specific bits.  I probably missed
it, so feel free to helpfully correct me there :)  I'd be curious to
see how the tests were written to take into account target differences
(using for example the dejagnu feature procs) and other nuances.

Re: Ping: Re: [PATCH] libgcc: fix SEH C++ rethrow semantics [PR113337]

[NightStrike]

On Mon, Feb 5, 2024, 06:53 Matteo Italia  wrote:

> Il 31/01/24 04:24, LIU Hao ha scritto:
> > 在 2024-01-31 08:08, Jonathan Yong 写道:
> >> On 1/24/24 15:17, Matteo Italia wrote:
> >>> Ping! That's a one-line fix, and you can find all the details in the
> >>> bugzilla entry. Also, I can provide executables built with the
> >>> affected toolchains, demonstrating the problem and the fix.
> >>>
> >>> Thanks,
> >>> Matteo
> >>>
> >>
> >> I was away last week. LH, care to comment? Changes look fine to me.
> >>
> >
> > The change looks good to me, too.
> >
> > I haven't tested it though. According to a similar construction around
> > 'libgcc/unwind.inc:265' it should be that way.
>
> Hello,
>
> thank you for the replies, is there anything else I can do to help push
> this forward?
>

Remember to mention the pr with the right syntax in the ChangeLog so the
bot adds a comment field. I didn't see it in yours, but I might have missed
it.

>

Re: [PATCH v2 0/5] A small Texinfo refinement

[NightStrike via Gcc-patches]

On Fri, Mar 10, 2023, 14:00 Gerald Pfeifer  wrote:

> On Fri, 10 Mar 2023, Sandra Loosemore wrote:
> > AFAIK we have not knowingly changed any specific requirements beyond the
> > stated 4.7 and 4.9 for PDF output, but it concerns me that nobody is
> > likely to be using versions that old on a regular basis to make sure
> > they continue to work and we haven't unknowingly introduced dependencies
> > on newer Texinfo features.
>
> I'm generally very interested in ensuring we do not hurt users who do not
> have the latest and greatest of the day. On the other hand, if there's a
> few people using (more or less deliberately abandonware) we should not
> feel too bad if something breaks.
>

Can you include texinfo in a top-level directory and have it built with the
build, like you can with dejagnu? That's generally a decent path for
building new gcc on older systems.

>

Re: [PATCH][stage1] Remove conditionals around free()

[NightStrike via Gcc-patches]

On Fri, Mar 3, 2023 at 10:14 PM Jerry D via Fortran  wrote:

> I am certainly not a C++ expert but it seems to me this all begs for
> automatic finalization where one would not have to invoke free at all.
> I suspect the gfortran frontend is not designed for such things.

+1 for RAII

Re: [PATCH] Fix PR target/90458

[NightStrike via Gcc-patches]

The reason would be to show that they continue to not ICE as they used to.
No go paths are just as useful as go paths.

On Sat, Mar 11, 2023, 10:57 Jeff Law  wrote:

>
>
> On 2/16/23 01:16, Eric Botcazou via Gcc-patches wrote:
> >> This fixes dg.exp/stack-check-2.c, -7, 8, and -16.c, which is great!
> >
> > Try the attached patch.
> I'd suggest going ahead and applying the fix to
> check_effective_target_supports_stack_clash_protection.
>
> There's really not a strong reason to run those tests on a cygwin or
> mingw target given how probing is done (out of line).
>
> Jeff
>

Re: [PATCH] gcc: Remove size limit of PCH for *-*-mingw32 hosts

[NightStrike via Gcc-patches]

On Thu, Feb 16, 2023, 11:10 LIU Hao via Gcc-patches 
wrote:

>
> --
> Best regards,
> LIU Hao
>

Ping

>

Re: [Patch] More LLP64 fixes and __PIC__ values fixes for PE targets

[NightStrike via Gcc-patches]

On Tue, Feb 14, 2023, 05:42 Jonathan Yong via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:

> Attached patches OK?


Ping

Re: [Patch] harden-sls-6.c: fix warning on LLP64

[NightStrike via Gcc-patches]

On Wed, Feb 15, 2023, 08:45 Jonathan Yong via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:

> gcc/testsuite/ChangeLog:
>
>  * gcc.target/i386/harden-sls-6.c: fix warning on LLP64
>  targets.
>
> Attached patch OK?


Ping

Re: [pushed] wwwdocs: gcc-12: Simplify a sentence in the OpenMP section

[NightStrike via Gcc-patches]

On Sat, Feb 18, 2023, 17:32 Gerald Pfeifer  wrote:

> That was a bit too much in terms of additions things. :-)
>
> Pushed.
>
> Gerald
> ---
>  htdocs/gcc-12/changes.html | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html
> index 32403579..fd4062e6 100644
> --- a/htdocs/gcc-12/changes.html
> +++ b/htdocs/gcc-12/changes.html
> @@ -153,7 +153,7 @@ You may also want to check out our
>
>  OpenMP 5.0 support has been extended: The close map
>modifier and the affinity clause are now supported.
> -  In addition Fortran gained additionally the following features
> which were
> +  In addition Fortran gained the following features which were
>

Missing a comma after "in addition" and "features". For the latter, "x that
y" > no comma. "X, which y" > comma. For the former, it's required to
separate the prepositional phrase from the subject.

>

Re: [PATCH] Fix PR target/90458

[NightStrike via Gcc-patches]

On Thu, Feb 16, 2023 at 3:16 AM Eric Botcazou  wrote:
>
> > This fixes dg.exp/stack-check-2.c, -7, 8, and -16.c, which is great!
>
> Try the attached patch.

Well... that patch just marks all of the tests as unsupported.  But
for example, the ones quoted above run, work, and pass.  And when they
didn't pass, they highlighted the ICE that you fixed.  So running the
test despite the nature of stack protection on Windows still has
value.  It is useful to ensure for example that stack protection
continues to work even if options are passed to disable it.  But the
tests that remain are looking for rtl patterns that (I assume)
shouldn't exist.  So it's perhaps useful to modify the test to say
that on windows, the scan-rtl-dump-times check should have zero hits.
If it found a match, that would be an error.

Is there a way to say that the test results should be inverted on a
particular platform (instead of purely unsupported)?

Re: [PATCH] Fix PR target/90458

[NightStrike via Gcc-patches]

On Wed, Feb 15, 2023 at 10:24 AM Eric Botcazou via Gcc-patches
 wrote:
>
> Hi,
>
> this is the incompatibility of -fstack-clash-protection with Windows SEH.  Now
> the Windows ports always enable TARGET_STACK_PROBE, which means that the stack
> is always probed (out of line) so -fstack-clash-protection does nothing more.
>
> Tested on x86-64/Windows and Linux, OK for all active branches?
>
>
> 2023-02-15  Eric Botcazou  
>
> * config/i386/i386.cc (ix86_compute_frame_layout): Disable the
> effects of -fstack-clash-protection for TARGET_STACK_PROBE.
> (ix86_expand_prologue): Likewise.

This fixes dg.exp/stack-check-2.c, -7, 8, and -16.c, which is great!

-6 no longer ICEs, but still fails.

-3, -4, -5, and -9 didn't ICE, and still fail:

gcc.dg/stack-check-10.c: pattern found 0 times
FAIL: gcc.dg/stack-check-10.c scan-rtl-dump-times pro_and_epilogue
"Stack clash no probe" 2
gcc.dg/stack-check-10.c: pattern found 0 times
FAIL: gcc.dg/stack-check-10.c scan-rtl-dump-times pro_and_epilogue
"Stack clash not noreturn" 2
gcc.dg/stack-check-10.c: pattern found 0 times
FAIL: gcc.dg/stack-check-10.c scan-rtl-dump-times pro_and_epilogue
"Stack clash residual allocation in prologue" 2
gcc.dg/stack-check-10.c: pattern found 0 times
FAIL: gcc.dg/stack-check-10.c scan-rtl-dump-times pro_and_epilogue
"Stack clash no frame pointer needed" 2
gcc.dg/stack-check-3.c: pattern found 0 times
FAIL: gcc.dg/stack-check-3.c scan-rtl-dump-times expand "allocation
and probing residuals" 7
gcc.dg/stack-check-3.c: pattern found 0 times
FAIL: gcc.dg/stack-check-3.c scan-rtl-dump-times expand "allocation
and probing in loop" 7
gcc.dg/stack-check-4.c: pattern found 0 times
FAIL: gcc.dg/stack-check-4.c scan-rtl-dump-times pro_and_epilogue
"Stack clash noreturn" 1
gcc.dg/stack-check-4.c: pattern found 0 times
FAIL: gcc.dg/stack-check-4.c scan-rtl-dump-times pro_and_epilogue
"Stack clash not noreturn" 1
gcc.dg/stack-check-5.c: pattern found 0 times
FAIL: gcc.dg/stack-check-5.c scan-rtl-dump-times pro_and_epilogue
"Stack clash no probe" 4
gcc.dg/stack-check-5.c: pattern found 0 times
FAIL: gcc.dg/stack-check-5.c scan-rtl-dump-times pro_and_epilogue
"Stack clash not noreturn" 4
gcc.dg/stack-check-5.c: pattern found 0 times
FAIL: gcc.dg/stack-check-5.c scan-rtl-dump-times pro_and_epilogue
"Stack clash no frame pointer needed" 4
gcc.dg/stack-check-5.c: pattern found 0 times
FAIL: gcc.dg/stack-check-5.c scan-rtl-dump-times pro_and_epilogue
"Stack clash no residual allocation in prologue" 1
gcc.dg/stack-check-5.c: pattern found 0 times
FAIL: gcc.dg/stack-check-5.c scan-rtl-dump-times pro_and_epilogue
"Stack clash residual allocation in prologue" 3
gcc.dg/stack-check-6.c: pattern found 0 times
FAIL: gcc.dg/stack-check-6.c scan-rtl-dump-times pro_and_epilogue
"Stack clash inline probes" 2
gcc.dg/stack-check-6.c: pattern found 0 times
FAIL: gcc.dg/stack-check-6.c scan-rtl-dump-times pro_and_epilogue
"Stack clash probe loop" 2
gcc.dg/stack-check-6.c: pattern found 0 times
FAIL: gcc.dg/stack-check-6.c scan-rtl-dump-times pro_and_epilogue
"Stack clash residual allocation in prologue" 4
gcc.dg/stack-check-6.c: pattern found 0 times
FAIL: gcc.dg/stack-check-6.c scan-rtl-dump-times pro_and_epilogue
"Stack clash not noreturn" 4
gcc.dg/stack-check-6.c: pattern found 0 times
FAIL: gcc.dg/stack-check-6.c scan-rtl-dump-times pro_and_epilogue
"Stack clash no frame pointer needed" 4
gcc.dg/stack-check-6a.c: pattern found 0 times
FAIL: gcc.dg/stack-check-6a.c scan-rtl-dump-times pro_and_epilogue
"Stack clash residual allocation in prologue" 4
gcc.dg/stack-check-6a.c: pattern found 0 times
FAIL: gcc.dg/stack-check-6a.c scan-rtl-dump-times pro_and_epilogue
"Stack clash not noreturn" 4
gcc.dg/stack-check-6a.c: pattern found 0 times
FAIL: gcc.dg/stack-check-6a.c scan-rtl-dump-times pro_and_epilogue
"Stack clash no frame pointer needed" 4
gcc.dg/stack-check-9.c: pattern found 0 times
FAIL: gcc.dg/stack-check-9.c scan-rtl-dump-times pro_and_epilogue
"Stack clash inline probes" 1
gcc.dg/stack-check-9.c: pattern found 0 times
FAIL: gcc.dg/stack-check-9.c scan-rtl-dump-times pro_and_epilogue
"Stack clash residual allocation in prologue" 1
gcc.dg/stack-check-9.c: pattern found 0 times
FAIL: gcc.dg/stack-check-9.c scan-rtl-dump-times pro_and_epilogue
"Stack clash not noreturn" 1
gcc.dg/stack-check-9.c: pattern found 0 times
FAIL: gcc.dg/stack-check-9.c scan-rtl-dump-times pro_and_epilogue
"Stack clash no frame pointer needed" 1


target/i386.exp/stack-check-12.c no longer ICEs but still fails.

-11, -18 and -19 still fail:

gcc.target/i386/stack-check-11.c: sub[ql] found 1 times
FAIL: gcc.target/i386/stack-check-11.c scan-assembler-times sub[ql] 4
gcc.target/i386/stack-check-11.c: or[ql] found 0 times
FAIL: gcc.target/i386/stack-check-11.c scan-assembler-times or[ql] 3

ia32882847.c:2:13: error: size of array 'dummy' is negative^M
ia32882847.c:4:55: error: '__i386__' undeclared here (not in a function)^M
compiler exited with status 1
FAIL: 

Re: [patch, gfortran.dg] Allow test to pass on mingw

[NightStrike via Gcc-patches]

On Fri, Jan 20, 2023 at 10:21 PM Jerry DeLisle via Fortran
 wrote:
>
> Hi all,
>
> Similar to a patch I committed a while ago for Cygwin, the attached
> patch allows it to pass on the mingw version of gfortran.
>
> It is trivial.
>
> Ok for trunk?
>
> Regards,
>
> Jerry

ping

Re: realpath() patch to fix symlinks resolution for win32

[NightStrike via Gcc-patches]

On Sat, Feb 11, 2023 at 3:52 AM Gerald Pfeifer  wrote:
>
> On Sat, 11 Feb 2023, Jonathan Yong via Gcc-patches wrote:
> >> could you please close the corresponding BR too?:
> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
> > I can't close it, but I put a note that it has been committed.
>
> I closed the report.
>
> Gerald

I would have expected the PR to have been automatically updated based on
the commit email. Any idea why that didn't happen? Not to change the state
to closed, but to add the commit information as a reply.

Re: [Patch] pr65658.c: fix excess warnings on LLP64 targets

[NightStrike via Gcc-patches]

ping

On Sat, Jan 28, 2023 at 1:16 PM Jonathan Yong <10wa...@gmail.com> wrote:
>
> Patch OK?
>
> gcc/testsuite/ChangeLog:
>
> * gcc.dg/pr65658.c: fix LLP64 test.

Re: libquadmath fix for 94756 and 87204

[NightStrike via Gcc-patches]

Is it too soon to ping again?  :)  I think Nixman needs some feedback as to
whether he's on the right track in addressing your concerns.

On Sun, Feb 5, 2023, 12:39 NightStrike  wrote:

> Jakub, ping
>
> On Thu, Jan 26, 2023, 12:50 i.nixman--- via Gcc-patches <
> gcc-patches@gcc.gnu.org> wrote:
>
>> hello,
>>
>> could someone look at the patch attached please?
>>
>> https://gcc.gnu.org/pipermail/gcc-patches/2023-January/610392.html
>>
>

Re: libquadmath fix for 94756 and 87204

[NightStrike via Gcc-patches]

Jakub, ping

On Thu, Jan 26, 2023, 12:50 i.nixman--- via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:

> hello,
>
> could someone look at the patch attached please?
>
> https://gcc.gnu.org/pipermail/gcc-patches/2023-January/610392.html
>

Re: [pushed] analyzer: fix uses of alloca in testsuite

[NightStrike via Gcc-patches]

On Tue, Jan 31, 2023 at 9:27 PM David Malcolm  wrote:
>
> Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
> Pushed to trunk as r13-5615-gd03ae4be2c6d48.
>
> gcc/testsuite/ChangeLog:
> * gcc.dg/analyzer/call-summaries-2.c: Add
> dg-require-effective-target alloca.
> * gcc.dg/analyzer/imprecise-floating-point-1.c: Likewise.
> * gcc.dg/analyzer/infinite-recursion-alloca.c: Likewise.
> * gcc.dg/analyzer/malloc-callbacks.c: Likewise.
> * gcc.dg/analyzer/out-of-bounds-5.c: Likewise.  Remove includes
> of  and .  Use "__builtin_free" rather than
> "free", to match uses of "__builtin_malloc".
> * gcc.dg/analyzer/putenv-1.c: Add dg-require-effective-target
> alloca.
> * gcc.dg/analyzer/write-to-string-literal-5.c: Likewise.

Thanks for this fix, these all pass now on Windows.

I hope I'm not being pedantic, but there's still a remaining
inconsistency in that some parts of the test use memcpy (like test6),
and others use __builtin_memcpy (like test98).  There isn't a call to
__builtin_memset(), but there is a call to memset().  Maybe these
differences are intentional, though.  If they aren't, and you wanted
to reduce it further, you could remove string.h and use the builtins.
You could also include stddef.h instead of stdlib.h, if all you need
is size_t.

Re: [patch, gfortran.dg] Adjust numerous tests so that they pass on line endings

[NightStrike via Gcc-patches]

On Sat, Jan 21, 2023, 18:59 Jerry D via Fortran  wrote:

>
> Proposed ChangeLog entry using git gcc-commit-mklog:
>
> Author: Jerry DeLisle 
> Date:   Sat Jan 21 15:47:19 2023 -0800
>
>  Revise the line end tests to pass on certain windows test environments
>  which inject spurious /r characters. Adjust (\n|\r\n|\r) to (\r*\n+).
>

Just to be clear, all simulators inject the spurious r's. I replicated the
problem on Linux.

Re: [PATCH] modula2/108144 - Fix multilib install of libgm2

[NightStrike via Gcc-patches]

On Fri, Jan 20, 2023 at 1:40 PM Gaius Mulley via Gcc-patches
 wrote:
>
> Richard Biener  writes:
>
> > The following adjusts libgm2 to properly use the multilib build
> > infrastructure, thereby fixing the install with
> > --enable-version-specific-runtime-libs
> >
> > In particular config-ml.pl needs to be applied to generated Makefiles
> > as documented in the manual and we have to avoid clobbering the
> > variables via make arguments.  The explicit install rules used different
> > ways to construct the multilib dir which isn't necessary and breaks
> > when MUTLIDIR is now finally set correctly.  Instead use
> > $(toolexeclibdir).
> >
> > This results in some dead variables in the Makefile.am (and there were
> > some before), I refrained from doing even more changes here.
> >
> > Verified with an install with and without 
> > --enable-version-specific-runtime-libs
> > and checking the result.
> >
> > OK?
> >
> > Thanks,
> > Richard.
>
> Many thanks for this fix - and the deep magic AC_FOREACH config-ml.in
> recursion rhunes.  LGTM
>
> regards,
> Gaius

AC_FOREACH is obsolete and shouldn't be used in new code.  It's been
replaced with m4_foreach_w:
https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Obsolete-Macros.html

Re: [committed] testsuite: Add testcases from PR108292 and PR108308

[NightStrike via Gcc-patches]

On Wed, Jan 11, 2023 at 7:14 AM Jakub Jelinek  wrote:

> I've committed following after regtesting it on x86_64-linux and i686-linux:
...
> +/* { dg-do run { target int32 } } */

Ah, I didn't realize you meant literally int32.  I didn't see that as
a choice here:
https://gcc.gnu.org/onlinedocs/gccint/Effective-Target-Keywords.html

Is that a case of missing documentation?

Re: [committed] testsuite: Add testcases from PR108292 and PR108308

[NightStrike via Gcc-patches]

On Wed, Jan 11, 2023 at 4:43 AM Jakub Jelinek  wrote:
>
> On Wed, Jan 11, 2023 at 04:27:11AM -0500, NightStrike wrote:
> > On Wed, Jan 11, 2023 at 4:07 AM Jakub Jelinek  wrote:
> > >
> > > On Wed, Jan 11, 2023 at 03:58:40AM -0500, NightStrike wrote:
> > > > On Fri, Jan 6, 2023 at 4:56 AM Jakub Jelinek via Gcc-patches
> > > >  wrote:
> > > > > --- gcc/testsuite/gcc.dg/pr108308.c.jj  2023-01-06 10:43:45.793009294 
> > > > > +0100
> > > > > +++ gcc/testsuite/gcc.dg/pr108308.c 2023-01-06 10:43:40.218090375 
> > > > > +0100
> > > > > @@ -0,0 +1,39 @@
> > > > > +/* PR target/108308 */
> > > > > +/* { dg-do run { target { ilp32 || lp64 } } } */
> > > >
> > > > This test passes on Windows, and I don't see anything in the test that
> > > > jumps out at me as being affected by storing pointers in longs.  Is
> > > > there something I'm missing about why this would be disabled on LLP64?
> > >
> > > Maybe the test just needs int32, it didn't look important enough to me.
> > > ilp32 || lp64 covers most of important targets.
> >
> > Could you change to int32plus, then?
>
> I think int32plus would be wrong, the testcase has some overlarge constant
> and I doubt it would work correctly on the hypothetical target with 64-bit
> ints where the overlarge constant would fit into int.

Ok, then:

/* { dg-do run { target { { ilp32 || lp64 } || llp64 } } } */

or even:

/* { dg-do run { target { ! int16 } } } */

Though I'd point out that in your original message, you only cared
about the "important targets".  I don't think nonexistent ones where
sizeof(int) == 8 qualifies :)

Re: [committed] testsuite: Add testcases from PR108292 and PR108308

[NightStrike via Gcc-patches]

On Wed, Jan 11, 2023 at 4:07 AM Jakub Jelinek  wrote:
>
> On Wed, Jan 11, 2023 at 03:58:40AM -0500, NightStrike wrote:
> > On Fri, Jan 6, 2023 at 4:56 AM Jakub Jelinek via Gcc-patches
> >  wrote:
> > > --- gcc/testsuite/gcc.dg/pr108308.c.jj  2023-01-06 10:43:45.793009294 
> > > +0100
> > > +++ gcc/testsuite/gcc.dg/pr108308.c 2023-01-06 10:43:40.218090375 
> > > +0100
> > > @@ -0,0 +1,39 @@
> > > +/* PR target/108308 */
> > > +/* { dg-do run { target { ilp32 || lp64 } } } */
> >
> > This test passes on Windows, and I don't see anything in the test that
> > jumps out at me as being affected by storing pointers in longs.  Is
> > there something I'm missing about why this would be disabled on LLP64?
>
> Maybe the test just needs int32, it didn't look important enough to me.
> ilp32 || lp64 covers most of important targets.

Could you change to int32plus, then?

-/* { dg-do run { target { ilp32 || lp64 } } } */
+/* { dg-do run { target { int32plus } } } */

Windows is still a secondary platform, so it'd be nice to keep as many
tests working (and supported) as possible.  I don't know what
qualifies as "important targets", but this is an easy win (pun
intended!)

Re: [committed] testsuite: Add testcases from PR108292 and PR108308

[NightStrike via Gcc-patches]

On Fri, Jan 6, 2023 at 4:56 AM Jakub Jelinek via Gcc-patches
 wrote:
> --- gcc/testsuite/gcc.dg/pr108308.c.jj  2023-01-06 10:43:45.793009294 +0100
> +++ gcc/testsuite/gcc.dg/pr108308.c 2023-01-06 10:43:40.218090375 +0100
> @@ -0,0 +1,39 @@
> +/* PR target/108308 */
> +/* { dg-do run { target { ilp32 || lp64 } } } */

This test passes on Windows, and I don't see anything in the test that
jumps out at me as being affected by storing pointers in longs.  Is
there something I'm missing about why this would be disabled on LLP64?

Re: Adding a new thread model to GCC

[NightStrike via Gcc-patches]

On Fri, Dec 23, 2022 at 7:00 PM Jonathan Yong via Gcc-patches
 wrote:
>
> On 12/22/22 12:28, i.nix...@autistici.org wrote:
> > On 2022-12-22 12:21, Jonathan Yong wrote:
> >
> > hello,
> >
> >> On 12/16/22 19:20, Eric Botcazou wrote:
>  The libgcc parts look reasonable to me, but I can't approve them.
>  Maybe Jonathan Yong can approve those parts as mingw-w64 target
>  maintainer, or maybe a libgcc approver can do so.
> >>>
> >>> OK.
> >>>
>  The libstdc++ parts are OK for trunk. IIUC they could go in
>  separately, they just wouldn't be very much use without the libgcc
>  changes.
> >>>
> >>> Sure thing.
> >>>
> >>
> >> Ping, need help to commit it?
> >
> > yes, it would be great if we can merge the path into gcc-13!
> >
> > I've tested it on gcc-12-branch and gcc-master for i686/x86_64 windows,
> > with msvcrt and ucrt runtime - works as it should!
> >
> > Eric ^^^
> >
> >
> >
> > best!
>
> Done, pushed to master branch. Thanks Eric.


I think this might have broken fortran.  I'm assuming because the
backtrace includes gthr.h, and I just did a git pull:

In file included from /tmp/rtmingw/mingw/include/windows.h:71,
 from ../libgcc/gthr-default.h:606,
 from ../../../libgfortran/../libgcc/gthr.h:148,
 from ../../../libgfortran/io/io.h:33,
 from ../../../libgfortran/runtime/error.c:27:
../../../libgfortran/io/io.h:298:24: error: expected identifier before
numeric constant
  298 | { CC_LIST, CC_FORTRAN, CC_NONE,
  |^~~

Re: Adding a new thread model to GCC

[NightStrike via Gcc-patches]

On Fri, Oct 21, 2022 at 8:33 AM Jacek Caban via Gcc-patches
 wrote:
>
> On 2022-10-21 11:44, Eric Botcazou via Libstdc++ wrote:
> >>>/How does this compare with Eric B's proposal at 
> >>>/>>>/https://gcc.gnu.org/legacy-ml/gcc-patches/2019-06/msg01840.html ? 
> >>>/>>//>>/My proposal was to reimplement (and extend) the native thread 
> >>>model />>/(win32) />>/instead of adding a new one, the advantage being 
> >>>that you don't need an />>/extra />/> threading layer between GCC and 
> >>>Windows. />
> > I agree!
>
> I agree as well and I expressed that on mingw-w64 ML when the patch was 
> introduced [1]. My main concern with the new threading model is that instead 
> of solving root of the problem, it introduces more fragmentation with no 
> clear benefit.
>
> On top of that, mcfgthread library is way more invasive than it needs to be. 
> It requires maintaining per-thread struct and reimplements a number of things 
> instead of leveraging OS capabilities. Author also plans to make invasive 
> changes to mingw-w64-crt, which go against it current approach of being 
> agnostic to threading model.
>
> Jacek
>
> [1] https://sourceforge.net/p/mingw-w64/mailman/message/37719727/

FWIW, Eric's proposal makes more practical sense.  Right now, people
ship many permutations of the compiler:
x86, x64, x86+x64
dw2, sjlj (rarely), seh
win32, posix+winpthread

This is not sustainable, and certain combinations are largely
incompatible (which makes for instance providing a windows release of
MySpecialLibrary.dll confusing).  We used to have a matrix of
combinations on the website, but I see that that's no longer present.
In any case, it took a long time for sjlj to fall out of vogue (maybe
old habits die hard?).  That implies, to me, that winpthreads
similarly won't be deprecated, it'll just be yet another set of
archives to download and confuse people with.

Re: [PATCH 1/1] [PATCH] Fix canadian compile for mingw-w64 copies the wrong dlls for mingw-w64 multilibs [PR100427]

[NightStrike via Gcc-patches]

On Thu, Jan 6, 2022, 18:31 cqwrteur via Gcc-patches 
wrote:

> When building GCC hosted on windows with Canadian/native compilation
> (host==target), the build scripts in GCC would override DLLs with each
> other. For example, for MinGW-w64, 32-bit DLLs would override 64 bits
> because build scripts copy them both to /bin.
>
> This patch fixes the issue by avoiding copying DLLs with multilibs.
> However, it would still copy when we do not build multilibs, usually the
> native build for GCC on windows.
> ---
>  gcc/configure  | 26 ++
>

You should probably not be modifying configure directly.

>

Re: [PATCH] Port libgccjit to Windows.

[NightStrike via Gcc-patches]

On Thu, May 28, 2020, 4:25 PM David Malcolm via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:

> On Wed, 2020-05-27 at 22:27 -0300, Nicolas Bértolo wrote:
> > > New C++ source files should have a .cc extension.
> > > I hope that at some point we'll rename all the existing .c ones
> > > accordingly.
> >
> > I just couldn't get Make to generate jit-w32.o from jit-w32.cc.
> > It looks for jit-w32.c.
> >
> > I had to leave it with the .c extension.
>
> Fair enough.
>

That's not a good reason to leave it like this. You should get a make
expert to help here.

I was able to successfully bootstrap and regression test with your
>
patch on x86_64-pc-linux-gnu.  I also verified that the result of "make
> install" was not affected for my configuration.
>
> I've pushed your patch to master as
> c83027f32d9cca84959c7d6a1e519a0129731501.
>
> (I had to do a little fixup of the ChangeLog entries to get them to
> work with the new hooks on our git repo)
>
> Thanks again for the patch
> Dave
>
> [1]
> https://docs.microsoft.com/en-us/previous-versions/windows/desktop/legacy/aa379560(v=vs.85)


I don't want to sound confrontational, but I don't think testing this on
linux and reviewing it by non windows experts is correct. At the very
least, a windows maintainer (Jon, Kai) should review it for correctness.
I've cc'd them here.

Re: [committed] analyzer: remove -Wanalyzer-use-of-uninitialized-value for GCC 10

[NightStrike via Gcc-patches]

On Tue, Apr 28, 2020 at 10:37 AM David Malcolm via Gcc-patches
 wrote:

> I'm working on a rewrite of the region_model code for GCC 11 that I
> hope will fix these issues, and allow this warning to be reintroduced.

If that's the case, why remove the warning just to add it back? You
could leave it in but have it do nothing for GCC 10.

Re: [PATCH] Fix 2 clang warnings.

[NightStrike]

On Thu, Jun 27, 2019 at 11:16 AM Martin Sebor  wrote:
>
> On 6/27/19 8:03 AM, Martin Liška wrote:
> > Hi.
> >
> > This reduces 2 warnings reported by clang.
> >
> > Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> >
> > Ready to be installed?
> > Thanks,
> > Martin
> >
> > gcc/ChangeLog:
> >
> > 2019-06-27  Martin Liska  
> >
> >   * edit-context.c (test_applying_fixits_unreadable_file): Do not
> >   use () for a constructor call.
> >   (test_applying_fixits_line_out_of_range): Likewise.
> >   * ggc-page.c (free_page): Use (char *) for %p printf format
> >   argument.
> > ---
> >   gcc/edit-context.c | 4 ++--
> >   gcc/ggc-page.c | 2 +-
> >   2 files changed, 3 insertions(+), 3 deletions(-)
>
> Just as a side note:
>
> diff --git a/gcc/edit-context.c b/gcc/edit-context.c
> index d3246ab0334..93d10664ae9 100644
> --- a/gcc/edit-context.c
> +++ b/gcc/edit-context.c
> @@ -1639,7 +1639,7 @@ static void
>   test_applying_fixits_unreadable_file ()
>   {
> const char *filename = "this-does-not-exist.txt";
> -  line_table_test ltt ();
> +  line_table_test ltt;
> linemap_add (line_table, LC_ENTER, false, filename, 1);
>
> location_t loc = linemap_position_for_column (line_table, 1);
>
> I'm guessing the warning above is about declaring a function
> returning line_table_test rather than declaring an object of
> the type.  (It would be helpful to show those warnings when
> fixing them.  A small test case confirms it's -Wvexing-parse:
> warning: empty parentheses interpreted as a function declaration.)
>
> This is a common mistake to make so it would be a useful
> warning to add to GCC as well.  And in fact, I see at least
> one request for it in Bugzilla: 25814 (with the related
> pr86564).
>
> Martin

Realistically, if it's worth fixing any warning that clang outputted
and that GCC doesn't. then perhaps the right fix is to add the
warning to GCC.  Or, if it's there but not in -Wall, add it to -Wall.
You're pointing out this specific case, but there've been several of
these patches that are all different.

Re: [PATCH] Use proper print formatter in main function in fixincl.c

[NightStrike]

On Mon, Jan 7, 2019 at 10:57 AM Jonathan Wakely  wrote:
>
> On 20/12/18 17:23 -0500, Nicholas Krause wrote:
> >This fixes the bug id, 71176 to use the proper known
> >code print formatter type, %lu for size_t rather than
> >%d which is considered best pratice for print statements.
>
> Well the proper specifier for size_t is %zu, but since you cast to
> unsigned long then %lu is right.

Wouldn't the right fix be to not cast to unsigned long and use %zu?

Re: introduce --enable-mingw-full32 to default to --large-address-aware

[NightStrike]

On Wed, Oct 10, 2018 at 7:37 PM JonY <10wa...@gmail.com> wrote:
>
> On 10/10/2018 04:58 AM, Alexandre Oliva wrote:
> > On Oct 10, 2018, JonY <10wa...@gmail.com> wrote:
> >
> >> On 10/10/2018 03:24 AM, Alexandre Oliva wrote:
> >>> On Oct  9, 2018, JonY <10wa...@gmail.com> wrote:
> >
> >>> Now, if you wish it to affect Cygwin as well, I could implement that,
> >>> and drop -mingw from the option name.  I'd retain the current defaults
> >>> of each target, unless there's a strong reason to change them.
> >
> >> In that case, no objections then.
> >
> > Thanks.  Now, before I proceed, please clarify: did you mean you had no
> > objections to the patch I last proposed, or to the plan in my last
> > paragraph above?
> >
>
> Your last proposed plan to use --enable-mingw-large-address-aware to
> affect only mingw. If there are more targets in the future that need
> this, we can always drop the mingw part in the configure option.

Except that options typically don't get removed, just deprecated.  It
seems cleaner to me to drop mingw from the name and make it default to
enabled for cygwin.

Re: [PATCH] Remove -Wunsafe-loop-optimizations option (PR middle-end/86095)

[NightStrike]

On Fri, Jun 15, 2018 at 3:08 PM, Jakub Jelinek  wrote:
> Hi!
>
> As mentioned in the PR, all traces of this warning option except these
> were removed earlier, so the warning option does nothing.

This is unfortunate.  As noted here:

https://gcc.gnu.org/ml/gcc-patches/2016-07/msg01057.html

The warning is (or, it used to be) good at finding code areas to
rewrite, and it's MUCH easier to use than the giant walls of text from
-fopt-info.  Is it possible to recreate this functionality in some
other way (or has that already been done, and I missed it)?

Re: dejagnu version update?

[NightStrike]

On Sat, May 13, 2017 at 4:39 PM, Jeff Law  wrote:
> On 05/13/2017 04:38 AM, Jakub Jelinek wrote:
>>
>> On Sat, May 13, 2017 at 12:24:12PM +0200, Bernhard Reutner-Fischer wrote:
>>>
>>> I guess neither redhat
>>> (https://access.redhat.com/downloads/content/dejagnu/ redirects to a
>>> login page but there seem to be 1.5.1 packages) nor SuSE did update
>>> dejagnu in the meantime.
>>
>>
>> Fedora has dejagnu-1.6 in Fedora 25 and later, dejagnu-1.5.3 in Fedora 24,
>> older
>> Fedora versions are EOL.  RHEL 7 has dejagnu-1.5.1, RHEL 6 as well as RHEL
>> 5 has
>> dejagnu-1.4.4, older RHEL versions are EOL.
>
> RHEL-5 is old enough that IMHO it ought not figure into this discussion.
> RHEL-6 is probably close to if not past that same point as well.

FWIW, I still run the testsuite on RHEL 6.

Re: [Patch, libgfortran, committed] Don't use rand_s on CYGWIN

[NightStrike]

On Mon, Mar 13, 2017 at 5:01 AM, Janne Blomqvist
<blomqvist.ja...@gmail.com> wrote:
> On Sun, Mar 12, 2017 at 10:46 PM, Janne Blomqvist
> <blomqvist.ja...@gmail.com> wrote:
>> On Sun, Mar 12, 2017 at 7:26 PM, NightStrike <nightstr...@gmail.com> wrote:
>>> On Mon, Feb 27, 2017 at 6:15 AM, Janne Blomqvist
>>> <blomqvist.ja...@gmail.com> wrote:
>>>> Don't try to use rand_s on CYGWIN
>>>>
>>>> CYGWIN seems to include _mingw.h and thus __MINGW64_VERSION_MAJOR is
>>>> defined even though rand_s is not available. Thus add an extra check
>>>> for __CYGWIN__.
>>>>
>>>> Thanks to Tim Prince and Nightstrike for bringing this issue to my 
>>>> attention.
>>>>
>>>> Committed as r245755.
>>>>
>>>> 2017-02-27  Janne Blomqvist  <j...@gcc.gnu.org>
>>>>
>>>> * intrinsics/random.c (getosrandom): Don't try to use rand_s on
>>>> CYGWIN.
>>>
>>> 1) There was no patch attached to the email.
>>
>> Oh, sorry. Well, you can see it at
>> https://gcc.gnu.org/viewcvs/gcc?view=revision=245755

Thanks.  You know, this is actually better than attaching a patch (as
a general thing for emails sent after things are already committed),
as there can be no difference between what was emailed and what was
committed.

>>> 2) As mentioned on IRC, I don't think this is the right fix.  The real
>>> problem is that time_1.h includes windows.h on CYGWIN, which it
>>> shouldn't be doing.  This then pollutes the translation unit with all
>>> sorts of MINGW-isms that aren't exactly appropriate for cygwin.
>>> Removing the include in time_1.h and then adjusting a few ifdefs in
>>> system_clock.c that also had the same bug fixes the problem.  The
>>> testsuite is running right now on this.
>>
>> It used to be something like that, but IIRC there were some complaints
>> about SYSTEM_CLOCK on cygwin that were due to the cygwin
>> clock_gettime() or something like that, and after some discussion with
>> someone who knows something about cygwin/mingw (since you apparently
>> have no memory of it, I guess it was Kai), it was decided to use
>> GetTickCount & QPC also on cygwin.
>
> I searched a bit, and it seems the culprit is the thread starting at
>
> https://gcc.gnu.org/ml/fortran/2013-04/msg00033.html
>
> So it turned out that clock_gettime(CLOCK_MONOTONIC, ...) always
> returned 0 on cygwin, hence the code was changed to use the windows
> API functions GetTickCount and QPC also on cygwin at
>
> https://gcc.gnu.org/ml/fortran/2013-04/msg00124.html
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56919

That all led me to this thread:

https://cygwin.com/ml/cygwin/2013-04/msg00184.html

which led me to:

https://cygwin.com/ml/cygwin/2013-04/msg00191.html

where Corinna fixed Angelo's original issue that sparked the whole
thing.  So, from my perspective, Cygwin hasn't had this problem in
about 4 years.

To be complete, though, I took Angelo's original code and compiled it
with a GCC built with the change I suggested, and I received this:

$ ./a.exe
   9.50646996E-02  0.435180306  0.939791977  0.851783216
0.308901191  0.447312355  0.766363919  0.163527727
1.25432014E-02

$ ./a.exe
  0.445786893   9.30446386E-03  0.880381405  0.123394549
1.23693347E-02  0.485788047  0.623361290  0.921140671
0.119319797

$ ./a.exe
  0.378171027  0.439836979  0.440582573   1.17767453E-02
0.427448869  0.530438244  0.182108700  0.147965968
0.668991745

$ ./a.exe
   2.73125172E-02  0.916011810  0.854288757  0.913502872
0.508077919  0.210798383   8.76839161E-02  0.120695710
0.337186754


I then tried Janus' enhanced version from
https://gcc.gnu.org/ml/fortran/2013-04/msg00034.html

$ ./a.exe
 n=  33
 clock:   744091787
 seed:744091787   744091824   744091861   744091898   744091935
744091972   744092009   744092046   744092083   744092120   744092157
 744092194   744092231   744092268   744092305   744092342   744092379
  744092416   744092453   744092490   744092527   744092564
744092601   744092638   744092675   744092712   744092749   744092786
 744092823   744092860   744092897   744092934   744092971
 random:   0.801897824  0.180594921  0.280960143
8.65536928E-03  0.122029424  0.473693788  0.161536098
0.228073180  0.441518903

$ ./a.exe
 n=  33
 clock:   744093409
 seed:744093409   744093446   744093483   744093520   744093557
744093594   744093631   744093668   744093705   744093742   744093779
 744093816   744093853   744093890   744093927   744093964   744094001
  744094038   744094075   744094112   744094149   744094186
74409

Re: [Patch, libgfortran, committed] Don't use rand_s on CYGWIN

[NightStrike]

On Sun, Mar 12, 2017 at 1:26 PM, NightStrike <nightstr...@gmail.com> wrote:
> On Mon, Feb 27, 2017 at 6:15 AM, Janne Blomqvist
> <blomqvist.ja...@gmail.com> wrote:
>> Don't try to use rand_s on CYGWIN
>>
>> CYGWIN seems to include _mingw.h and thus __MINGW64_VERSION_MAJOR is
>> defined even though rand_s is not available. Thus add an extra check
>> for __CYGWIN__.
>>
>> Thanks to Tim Prince and Nightstrike for bringing this issue to my attention.
>>
>> Committed as r245755.
>>
>> 2017-02-27  Janne Blomqvist  <j...@gcc.gnu.org>
>>
>> * intrinsics/random.c (getosrandom): Don't try to use rand_s on
>> CYGWIN.
>
> 1) There was no patch attached to the email.
>
> 2) As mentioned on IRC, I don't think this is the right fix.  The real
> problem is that time_1.h includes windows.h on CYGWIN, which it
> shouldn't be doing.  This then pollutes the translation unit with all
> sorts of MINGW-isms that aren't exactly appropriate for cygwin.
> Removing the include in time_1.h and then adjusting a few ifdefs in
> system_clock.c that also had the same bug fixes the problem.  The
> testsuite is running right now on this.

Testsuite run completed with no change in results:

=== gfortran Summary ===

# of expected passes44633
# of unexpected failures55
# of unexpected successes   6
# of expected failures  85
# of unsupported tests  187
/tmp/build/gcc/testsuite/gfortran/../../gfortran  version 7.0.1
20170312 (experimental) (GCC)

make[1]: Leaving directory '/tmp/build/gcc'

Those 55 unexpected failures are unrelated to this change, and occur
before and after.

Re: [Patch, libgfortran, committed] Don't use rand_s on CYGWIN

[NightStrike]

On Mon, Feb 27, 2017 at 6:15 AM, Janne Blomqvist
<blomqvist.ja...@gmail.com> wrote:
> Don't try to use rand_s on CYGWIN
>
> CYGWIN seems to include _mingw.h and thus __MINGW64_VERSION_MAJOR is
> defined even though rand_s is not available. Thus add an extra check
> for __CYGWIN__.
>
> Thanks to Tim Prince and Nightstrike for bringing this issue to my attention.
>
> Committed as r245755.
>
> 2017-02-27  Janne Blomqvist  <j...@gcc.gnu.org>
>
> * intrinsics/random.c (getosrandom): Don't try to use rand_s on
> CYGWIN.

1) There was no patch attached to the email.

2) As mentioned on IRC, I don't think this is the right fix.  The real
problem is that time_1.h includes windows.h on CYGWIN, which it
shouldn't be doing.  This then pollutes the translation unit with all
sorts of MINGW-isms that aren't exactly appropriate for cygwin.
Removing the include in time_1.h and then adjusting a few ifdefs in
system_clock.c that also had the same bug fixes the problem.  The
testsuite is running right now on this.

See the following diff for reference:

Index: ../gccsvn/libgfortran/intrinsics/random.c
===
--- ../gccsvn/libgfortran/intrinsics/random.c   (revision 246075)
+++ ../gccsvn/libgfortran/intrinsics/random.c   (working copy)
@@ -304,7 +304,7 @@
 getosrandom (void *buf, size_t buflen)
 {
   /* rand_s is available in MinGW-w64 but not plain MinGW.  */
-#if defined(__MINGW64_VERSION_MAJOR) && !defined(__CYGWIN__)
+#ifdef __MINGW64_VERSION_MAJOR
   unsigned int* b = buf;
   for (unsigned i = 0; i < buflen / sizeof (unsigned int); i++)
 rand_s ([i]);
Index: ../gccsvn/libgfortran/intrinsics/system_clock.c
===
--- ../gccsvn/libgfortran/intrinsics/system_clock.c (revision 246075)
+++ ../gccsvn/libgfortran/intrinsics/system_clock.c (working copy)
@@ -29,7 +29,7 @@
 #include "time_1.h"


-#if !defined(__MINGW32__) && !defined(__CYGWIN__)
+#if !defined(__MINGW32__)

 /* POSIX states that CLOCK_REALTIME must be present if clock_gettime
is available, others are optional.  */
@@ -121,7 +121,7 @@
 system_clock_4 (GFC_INTEGER_4 *count, GFC_INTEGER_4 *count_rate,
   GFC_INTEGER_4 *count_max)
 {
-#if defined(__MINGW32__) || defined(__CYGWIN__)
+#if defined(__MINGW32__)
   if (count)
 {
   /* Use GetTickCount here as the resolution and range is
@@ -174,7 +174,7 @@
 system_clock_8 (GFC_INTEGER_8 *count, GFC_INTEGER_8 *count_rate,
 GFC_INTEGER_8 *count_max)
 {
-#if defined(__MINGW32__) || defined(__CYGWIN__)
+#if defined(__MINGW32__)
   LARGE_INTEGER cnt;
   LARGE_INTEGER freq;
   bool fail = false;
Index: ../gccsvn/libgfortran/intrinsics/time_1.h
===
--- ../gccsvn/libgfortran/intrinsics/time_1.h   (revision 246075)
+++ ../gccsvn/libgfortran/intrinsics/time_1.h   (working copy)
@@ -101,7 +101,7 @@
CPU_TIME intrinsics.  Returns 0 for success or -1 if no
CPU time could be computed.  */

-#if defined(__MINGW32__) || defined(__CYGWIN__)
+#if defined(__MINGW32__)

 #define WIN32_LEAN_AND_MEAN
 #include 

Re: [patch] update zlib to the 1.2.10 release.

[NightStrike]

On Sun, Jan 22, 2017 at 1:00 PM, Matthias Klose <d...@ubuntu.com> wrote:
> NightStrike proposed to revert to the 1.2.8 release until zlib stabilizes 
> again;
> I'm open for that, but didn't want to stay with the 1.2.10 release.

I don't recall making that proposal.  I thought I just suggested that
since modern zlib now supports having a separate build and source
directory (at least according to the December changelog: "Allow
building zlib outside of the source directory"), you should check to
see if the gcc build system had any hacks to accomplish the same thing
that could now be removed.

Re: [PATCH] Delete GCJ

[NightStrike]

On Mon, Sep 5, 2016 at 11:13 AM, Andrew Haley  wrote:
> As discussed.  I think I should ask a Global reviewer to approve this
> one.  For obvious reasons I haven't included the diffs to the deleted
> gcc/java and libjava directories.  The whole tree, post GCJ-deletion,
> is at svn+ssh://gcc.gnu.org/svn/gcc/branches/gcj/gcj-deletion-branch
> if anyone would like to try it.
>
> Andrew.

For what little (to nothing) it's worth, I still use gcj, and I like
the ease of adding small bits of java to a project without involving
additional compilers.  It optimizes extremely well, is easy to use,
and adds to the completeness of the GNU Compiler *Collection*.

Could we at least reach out and see if there's someone else who could
be the maintainer?  I noticed gcj patches recently, so there's still
interest.

Re: [libstdc++] Add C++17clamp

[NightStrike]

Would it be possible to fix the missed optimization to give the better
asm without having to do -ffast-math as mentioned here:

https://gcc.gnu.org/ml/gcc-help/2014-11/msg00034.html

If so, then the proposed implementation would be optimized for the simple case.


On Fri, Jul 22, 2016 at 3:55 AM, Jonathan Wakely <jwak...@redhat.com> wrote:
> On 22/07/16 08:51 +0100, Jonathan Wakely wrote:
>>
>> On 21/07/16 19:38 -0400, NightStrike wrote:
>>>
>>> On Thu, Jul 14, 2016 at 7:50 PM, Ed Smith-Rowland <3dw...@verizon.net>
>>> wrote:
>>>>
>>>> Here is an implementation of P0025
>>>> An algorithm to "clamp" a value between a pair of boundary values.
>>>>
>>>> Testing is almost finished - looks good so far.
>>>>
>>>> OK if testing passes?
>>>>
>>>> I didn't see a feature test in any of the SD-6 papers or P0025.
>>>>
>>>
>>> This is not an efficient implementation.  See here:
>>>
>>> https://gcc.gnu.org/ml/gcc-help/2014-10/msg00112.html
>>>
>>> Which I derived from this SO answer (which is sadly not the accepted
>>> answer at this time):
>>>
>>> http://stackoverflow.com/a/16659263
>>>
>>> I suggest using the very efficient method that requires a temporary.
>>
>>
>> That isn't a valid implementation of std::clamp, since it performs a
>> copy. The template argument might not even be copyable.
>
>
>
> We could possibly dispatch to such an implementation for arithmetic
> types, but we wouldn't want to do it for all copyable types. There's
> no way you can know whether making that local copy is expensive for an
> arbitrary type, and making a copy isn't allowed anyway.
>

Re: [libstdc++] Add C++17clamp

[NightStrike]

On Thu, Jul 14, 2016 at 7:50 PM, Ed Smith-Rowland <3dw...@verizon.net> wrote:
> Here is an implementation of P0025
> An algorithm to "clamp" a value between a pair of boundary values.
>
> Testing is almost finished - looks good so far.
>
> OK if testing passes?
>
> I didn't see a feature test in any of the SD-6 papers or P0025.
>

This is not an efficient implementation.  See here:

https://gcc.gnu.org/ml/gcc-help/2014-10/msg00112.html

Which I derived from this SO answer (which is sadly not the accepted
answer at this time):

http://stackoverflow.com/a/16659263

I suggest using the very efficient method that requires a temporary.

Re: [PATCH GCC]Remove support for -funsafe-loop-optimizations

[NightStrike]

On Mon, Jul 18, 2016 at 3:55 AM, Bin.Cheng <amker.ch...@gmail.com> wrote:
> On Sat, Jul 16, 2016 at 6:28 PM, NightStrike <nightstr...@gmail.com> wrote:
>> On Fri, Jul 15, 2016 at 1:07 PM, Bin Cheng <bin.ch...@arm.com> wrote:
>>> Hi,
>>> This patch removes support for -funsafe-loop-optimizations, as well as 
>>> -Wunsafe-loop-optimizations.  By its name, this option does unsafe 
>>> optimizations by assuming all loops must terminate and doesn't wrap.  
>>> Unfortunately, it's not as useful as expected because:
>>> 1) Simply assuming loop must terminate isn't enough.  What we really want 
>>> is to analyze scalar evolution and loop niter bound under such assumptions. 
>>>  This option does nothing in this aspect.
>>> 2) IIRC, this option generates bogus code for some common programs, that's 
>>> why it's disabled by default even at Ofast level.
>>>
>>> After I sent patches handling possible infinite loops in both (scev/niter) 
>>> analyzer and vectorizer, it's a natural step to remove such options in GCC. 
>>>  This patch does so by deleting code for -funsafe-loop-optimizations, as 
>>> well as -Wunsafe-loop-optimizations.  It also deletes the two now useless 
>>> tests, while the option interface is preserved for backward compatibility 
>>> purpose.
>>
>> There are a number of bugs opened against those options, including one
>> that I just opened rather recently:
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71769
>>
>> but some go back far, in this case 9 years:
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34114
>>
>> If you are going to remove the options, you should address open bugs
>> related to those options.
> Hi,
> Thanks for pointing me to these PRs, I will have a look at them.

I only highlighted two PRs, I was suggesting that you look for all of them.

> IMHO, the old one reports weakness in loop niter analyzer, the issue
> exists whether I remove unsafe-loop-optimization or not.  The new one
> is a little bit trickier, I will put some comments on PR, and again,
> the issue (if it is) is in niter analyzer which has nothing to do with
> the option really.

Well, one thing to note is that the warning is an easy way to get a
notice of a possible missed optimization (and I have many more
occurrences of it in a particular code base that I use).  If the
warning is highlighted potential issues that aren't due to the -f
option but are issues nonetheless, and we remove the warning, then how
should I go about finding these missed opportunities in the future?
Is there a different mechanism that does the same thing?

Re: [PATCH GCC]Remove support for -funsafe-loop-optimizations

[NightStrike]

On Fri, Jul 15, 2016 at 1:07 PM, Bin Cheng  wrote:
> Hi,
> This patch removes support for -funsafe-loop-optimizations, as well as 
> -Wunsafe-loop-optimizations.  By its name, this option does unsafe 
> optimizations by assuming all loops must terminate and doesn't wrap.  
> Unfortunately, it's not as useful as expected because:
> 1) Simply assuming loop must terminate isn't enough.  What we really want is 
> to analyze scalar evolution and loop niter bound under such assumptions.  
> This option does nothing in this aspect.
> 2) IIRC, this option generates bogus code for some common programs, that's 
> why it's disabled by default even at Ofast level.
>
> After I sent patches handling possible infinite loops in both (scev/niter) 
> analyzer and vectorizer, it's a natural step to remove such options in GCC.  
> This patch does so by deleting code for -funsafe-loop-optimizations, as well 
> as -Wunsafe-loop-optimizations.  It also deletes the two now useless tests, 
> while the option interface is preserved for backward compatibility purpose.

There are a number of bugs opened against those options, including one
that I just opened rather recently:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71769

but some go back far, in this case 9 years:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34114

If you are going to remove the options, you should address open bugs
related to those options.

Re: [PATCH, contrib] download_prerequisites: check for existing symlinks before making new ones

[NightStrike]

On Thu, Jul 14, 2016 at 6:57 AM, Eric Gallager  wrote:
> On 7/13/16, Jeff Law  wrote:
>> On 06/27/2016 08:10 PM, Eric Gallager wrote:
>>> The last time I ran ./contrib/download_prerequisites, I already had
>>> previous symlinks set up from a previous run of the script, so `ln`
>>> followed the existing symlinks and created the new ones in the
>>> directories to which the symlinks pointed. This patch should fix that
>>> by removing the old symlinks before creating new ones. (For some
>>> reason the `-f` flag to `ln` that was already there wasn't enough for
>>> me.) Tested by running the script and ensuring that the new isl
>>> symlink pointed to the correct directory, and that there were no bad
>>> symlinks in the old isl directory. Could someone commit this trivial
>>> patch for me, or something like it? I don't have write access.
>> I'd really rather know why the "-f" flag didn't work for you.  The whole
>> point of -f is to remove the destination file first.
>>
>> Jeff
>>
>
> Reading my ln manpage, it describes the "-f" flag like this:
>
>
>  -fIf the target file already exists, then unlink it so that the
>link may occur.  (The -f option overrides any previous -i
>options.)
>
> Okay, so that seems like it should do what you say, but the manpage
> also describes a separate uppercase "-F" option:
>
>  -FIf the target file already exists and is a directory, then
>remove it so that the link may occur.  The -F option should be
>used with either -f or -i options.  If none is specified, -f is
>implied.  The -F option is a no-op unless -s option is speci-
>fied.
>
> So it seems to imply that "-f" will only remove the destination file
> if it's a regular file, while "-F" is needed if the destination file
> is a directory. The page also has this to say about "-F" later:
>
>  The -F option is FreeBSD extention and should not be used in portable
>  scripts.
>
> So this could be a BSD vs. GNU thing.

On GNU, -F means:

   -d, -F, --directory
  allow the superuser to attempt to hard link directories
(note: will probably fail due to system restrictions, even for the
superuser)

Re: [PATCH, contrib] download_prerequisites: check for existing symlinks before making new ones

[NightStrike]

On Wed, Jul 13, 2016 at 5:36 PM, Jeff Law  wrote:
> On 06/27/2016 08:10 PM, Eric Gallager wrote:
>>
>> The last time I ran ./contrib/download_prerequisites, I already had
>> previous symlinks set up from a previous run of the script, so `ln`
>> followed the existing symlinks and created the new ones in the
>> directories to which the symlinks pointed. This patch should fix that
>> by removing the old symlinks before creating new ones. (For some
>> reason the `-f` flag to `ln` that was already there wasn't enough for
>> me.) Tested by running the script and ensuring that the new isl
>> symlink pointed to the correct directory, and that there were no bad
>> symlinks in the old isl directory. Could someone commit this trivial
>> patch for me, or something like it? I don't have write access.
>
> I'd really rather know why the "-f" flag didn't work for you.  The whole
> point of -f is to remove the destination file first.
>
> Jeff
>

FWIW, it doesn't work for me, either:

$ mkdir d
$ ln -s d a
$ ls -la a
lrwxrwxrwx 1 owner owner 1 Jul 14 09:48 a -> d
$ mkdir e
$ ln -sf e a
$ ls -la a
lrwxrwxrwx 1 owner owner 1 Jul 14 09:48 a -> d

But adding the -n option does:

$ ln -sfn e a
$ ls -la a
lrwxrwxrwx 1 owner owner 1 Jul 14 09:51 a -> e


So perhaps add -n?

Re: Implement -Wswitch-fallthrough

[NightStrike]

On Mon, Jul 11, 2016 at 4:34 PM, Jakub Jelinek  wrote:
> On Mon, Jul 11, 2016 at 10:23:30PM +0200, Marek Polacek wrote:
>> On Mon, Jul 11, 2016 at 01:18:02PM -0700, Andi Kleen wrote:
>> > > I explained why supporting the classic lint style comment wouldn't fly.
>> >
>> > Not convincing, it worked fine for 30+ years of lints.
>>
>> So how can the compiler handle
>> /* Never ever fall through here */
>> ?
>
> It can't.  But it perhaps could handle a couple of documented most common
> comment styles, perhaps only if followed by break token, and turn say
> /* FALLTHROUGH */
> break
> (and say:
> /* FALL THROUGH */
> /* FALLTHRU */
> /* FALL THRU */
> /*-fallthrough*/
> /* Fallthrough */
> /* Fall through */
> /* Fallthru */
> /* Fall thru */
> /* fallthrough */
> /* fall through */
> /* fallthru */
> /* fall thru */
> // FALLTHROUGH
> // FALL THROUGH
> // FALLTHRU
> // FALL THRU
> //-fallthrough
> // Fallthrough
> // Fall through
> // Fallthru
> // Fall thru
> // fallthrough
> // fall through
> // fallthru
> // fall thru

>From http://security.coverity.com/blog/2013/Sep/gimme-a-break.html:

We also suppress a case label if there is a comment that matches
[^#]fall.?thro?u, even if it's not on the last line.

Maybe that's enough?

The page has other exclusions that might be desirable.

Re: Implement -Wswitch-fallthrough

[NightStrike]

On Mon, Jul 11, 2016 at 3:43 PM, Marek Polacek  wrote:
> But then the [[fallthrough]] attribute was
> approved for C++17 [1], and that's what has got me to do all this.
>  ...
> I added a new builtin,
> __builtin_fallthrough, that prevents the warning from occurring.  It can only
> be used in a switch; the compiler will issue an error otherwise.  The new C++
> attribute can then be implemented in terms of this builtin.

This is a stupid question I'm sure, but if C++ can have the attribute
version, why can't C have __attribute__((fallthrough)) ?

Re: [patch testsuite]: Fix gcc.target/i386 cases for mingw-targets

[NightStrike]

On Fri, Mar 8, 2013 at 8:21 AM, Rainer Orth r...@cebitec.uni-bielefeld.de 
wrote:
 Hi Kai,

 Index: gcc.target/i386/pr20020-1.c
 ===
 --- gcc.target/i386/pr20020-1.c   (Revision 196507)
 +++ gcc.target/i386/pr20020-1.c   (Arbeitskopie)
 @@ -1,5 +1,6 @@
  /* Check that 128-bit struct's are represented as TImode values.  */
  /* { dg-do compile { target int128 } } */
 +/* { dg-skip-if  { x86_64-*-mingw* } { * } {  } } */

 Please omit the default { * } {  } here and in other tests below.
 And again: explain why the test is skipped.

 Hmm, why shall I omit here the default.  I checked in tree and most
 statements for dg-skip-if are expressing default too.

 just because support for omitting the default isn't that old.  There's
 certainly opportunity for cleanup, but we shouldn't spread this any
 further.

 Well, to skip here x64 mingw is caused by the fact that it has a
 different ABI as x86_64.  I will add it to skip message.

 Thanks.  It's always far easier to have this in the testsuite to spare
 the next guy from doing software archaeology.

 Ok to apply with those changes?

 Again, I prefer to defer to the target maintainers.

Ping

Re: [patch libada]: PR target/52122

[NightStrike]

Ping

On Wed, Feb 6, 2013 at 12:10 AM, Kai Tietz ktiet...@googlemail.com wrote:
 Hi,

 this patch fixes an issue about recursice LN_S for mingw-host.  The
 issue was already addressed by autotools, but an upgrade of version
 isn't suitable right now.
 For further information see the bug-report PR 52122.

 ChangeLog libada/

 PR target/52122
 * Makefile.in (LN_S_RECUSIVE): New.
 (adainclude, adalib): Use LN_S_RECURSIVE for copy.

 Patch see at http://gcc.gnu.org/bugzilla/attachment.cgi?id=29176

 Ok for apply?

 Regards,
 Kai

Re: [patch stmt.c]: 6 of 7 Fix of PR target/53912 bootstrap fails using default c++ mode in stage 2 and 3 for native x86_64-w64-mingw32

[NightStrike]

On Sat, Dec 1, 2012 at 11:13 PM, Kai Tietz ktiet...@googlemail.com wrote:
 Ping

 2012/11/29 Kai Tietz ktiet...@googlemail.com:
 Hello,

 this trivial patch fixes a bootstrap issue on LLP64 hosts.

 ChangeLog

 2012-11-29 Kai Tietz

 PR target/53912
 * stmt.c (compute_cases_per_edge): Cast from pointer via intptr_t.
 (expand_case): Likewise.

 Tested for i686-w64-mingw32, x86_64-w64-mingw32, and
 x86_64-unknown-gnu-linux. Ok for apply?

 Regards,
 Kai

 Index: stmt.c
 ===
 --- stmt.c  (Revision 193925)
 +++ stmt.c  (Arbeitskopie)
 @@ -2061,7 +2061,7 @@ compute_cases_per_edge (gimple stmt)
tree lab = CASE_LABEL (elt);
basic_block case_bb = label_to_block_fn (cfun, lab);
edge case_edge = find_edge (bb, case_bb);
 -  case_edge-aux = (void *)((long)(case_edge-aux) + 1);
 +  case_edge-aux = (void *)((intptr_t)(case_edge-aux) + 1);
  }
  }

 @@ -2176,7 +2176,7 @@ expand_case (gimple stmt)
edge case_edge = find_edge (bb, case_bb);
case_list = add_case_node (
case_list, low, high, lab,
 -  case_edge-probability / (long)(case_edge-aux),
 +  case_edge-probability / (intptr_t)(case_edge-aux),
case_node_pool);
  }
pointer_set_destroy (seen_labels);

Ping x2

Re: [patch stmt.c]: Fix SjLj exception handling

[NightStrike]

On Sat, Dec 1, 2012 at 12:28 PM, Steven Bosscher stevenb@gmail.com wrote:
 On Sat, Dec 1, 2012 at 10:59 PM, Kai Tietz wrote:
 Hi,

 recent 4,8 has regressions in g++.old-deja/g++.eh for the catch*.C
 tests, if exception-mechanism is SjLj.  This is due an off by one
 failure in an decreasing loop.

 ChangeLog

 2012-12-01  Kai Tietz

 * stmt.c (expand_sjlj_dispatch_table): Fix off by one.

 Tested for i686-w64-mingw32, x86_64-unknown-linux-gnu.  Ok for apply?

 Regards,
 Kai


 Index: stmt.c
 ===
 --- stmt.c  (Revision 193985)
 +++ stmt.c  (Arbeitskopie)
 @@ -2282,7 +2282,7 @@ expand_sjlj_dispatch_table (rtx dispatch_index,
tree range = maxval;
rtx default_label = gen_label_rtx ();

 -  for (int i = ncases - 1; i  0; --i)
 +  for (int i = ncases - 1; i = 0; --i)
 {
   tree elt = dispatch_table[i];
   tree low = CASE_LOW (elt);


 I can't approve this, but it's obvious. The normal switch expander
 (expand_case) expects the default case in slot 0, but the SJLJ
 dispatch table doesn't have a default case.

 Ciao!
 Steven

Ping.

Re: [patch print-tree.c]: 5 of 7 Fix of PR target/53912 bootstrap fails using default c++ mode in stage 2 and 3 for native x86_64-w64-mingw32

[NightStrike]

On Sat, Dec 1, 2012 at 11:12 PM, Kai Tietz ktiet...@googlemail.com wrote:
 Ping

 2012/11/29 Kai Tietz ktiet...@googlemail.com:
 Hello,

 this trivial patch fixes a bootstrap issue on LLP64 hosts.

 ChangeLog

 2012-11-29 Kai Tietz

 PR target/53912
 * print-tree.c (print_node): Cast from pointer via uintptr_t.

 Tested for i686-w64-mingw32, x86_64-w64-mingw32, and
 x86_64-unknown-gnu-linux. Ok for apply?

 Regards,
 Kai

 Index: print-tree.c
 ===
 --- print-tree.c(Revision 193925)
 +++ print-tree.c(Arbeitskopie)
 @@ -255,7 +255,7 @@ print_node (FILE *file, const char *prefix, tree n
/* Allow this function to be called if the table is not there.  */
if (table)
  {
 -  hash = ((unsigned long) node) % HASH_SIZE;
 +  hash = ((uintptr_t) node) % HASH_SIZE;

/* If node is in the table, just mention its address.  */
for (b = table[hash]; b; b = b-next)

Ping.

Re: handle isl and cloog in contrib/download_prerequisites

[NightStrike]

On Sat, Oct 6, 2012 at 7:30 AM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
 Hi,

 GCC now requires ISL and a very new CLOOG but download_prerequisites
 does not download those. Also, there is only one sensible place to

As of what version is isl/cloog no longer optional?

Re: Bump minimum gmp version to 4.2.3

[NightStrike]

On Thu, Sep 6, 2012 at 2:13 PM, Diego Novillo dnovi...@google.com wrote:
 Doug was trying to build with gmp 4.2.1 and ran into this error:

 gmp-4.2.1/include/gmp.h:515:12: error: 'std::FILE' has not been declared

 This bug was fixed in gmp 4.2.3, so I've bumped the minimum
 acceptable version in configure.ac

 Tested on x86_64 with gmp 4.2.3.  Committed to trunk.

Don't you also have to modify the contrib/download_prerequisites
script, as well as the contents of
ftp://gcc.gnu.org/pub/gcc/infrastructure ?

Re: Bump minimum gmp version to 4.2.3

[NightStrike]

On Thu, Sep 6, 2012 at 3:13 PM, NightStrike nightstr...@gmail.com wrote:
 On Thu, Sep 6, 2012 at 2:13 PM, Diego Novillo dnovi...@google.com wrote:
 Doug was trying to build with gmp 4.2.1 and ran into this error:

 gmp-4.2.1/include/gmp.h:515:12: error: 'std::FILE' has not been declared

 This bug was fixed in gmp 4.2.3, so I've bumped the minimum
 acceptable version in configure.ac

 Tested on x86_64 with gmp 4.2.3.  Committed to trunk.

 Don't you also have to modify the contrib/download_prerequisites
 script, as well as the contents of
 ftp://gcc.gnu.org/pub/gcc/infrastructure ?

Actually, on closer inspection, other places list the minimum version
as 4.3.2, including:
http://gcc.gnu.org/install/prerequisites.html

as well as the two locations that I mention above.  Perhaps configure
should do likewise.

Re: CXX conversion: min g++ version pre-requisite?

[NightStrike]

On Fri, Aug 17, 2012 at 9:51 PM, Richard Guenther
richard.guent...@gmail.com wrote:
 On Sat, Aug 18, 2012 at 3:36 AM, Gary Funck g...@intrepid.com wrote:

 Paul Hargrove noted the following build failure on
 an older x86-32 Linux (Redhat 8.0) system.

 g++ -c   -g -O2 -DIN_GCC   -fno-exceptions -fno-rtti -W -Wall
 -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -fno-common
  -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild
 -I/usr/local/pkg/upc/nightly/compiler/gupc-src/gcc
 -I/usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/build
 -I/usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/../include
 -I/usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/../libcpp/include
 -I/usr/local/pkg/gmp-4.2.4/include -I/usr/local/pkg/mpfr-2.4.2/include
 -I/usr/local/pkg/mpc-0.8/include
  -I/usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/../libdecnumber
 -I/usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/../libdecnumber/bid
 -I../libdecnumber\
 -o build/genoutput.o
 /usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/genoutput.c
 /usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/genoutput.c: In function
 `void note_constraint(rtx_def*, int)':
 /usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/genoutput.c:1178: error:
 reinterpret_cast from type `const char (*)[1]' to type `char*' casts away
 constness
 make[2]: *** [build/genoutput.o] Error 1
 make[2]: Leaving directory `/usr/local/pkg/upc/nightly/compiler/bld/gcc'
 make[1]: *** [all-gcc] Error 2
 make[1]: Leaving directory `/usr/local/pkg/upc/nightly/compiler/bld'
 make: *** [all] Error 2


 The g++ version is: g++ (GCC) 3.4.0

 Currently, install.texi states:

 @heading Tools/packages necessary for building GCC
 @table @asis
 @item ISO C90 compiler
 Necessary to bootstrap GCC, although versions of GCC prior
 to 3.4 also allow bootstrapping with a traditional (KR) C compiler.

 To build all languages in a cross-compiler or other configuration where
 3-stage bootstrap is not performed, you need to start with an existing
 GCC binary (version 2.95 or later) because source code for language
 frontends other than C might use GCC extensions.

 This appears to be out-of-date with respect to new C++ stage 1
 build requirement.

 Please advise.

 The code is clearly buggy and should use CONST_CAST - well, or now,
 finally, const_cast to cast const char * to char *.

 Richard.

 Thanks,
 - Gary

Why do newer compilers not error out?

Re: [Patch] Don't test for pr53425 on mingw

[NightStrike]

On Mon, Jun 18, 2012 at 10:09 AM, Kai Tietz ktiet...@googlemail.com wrote:
 2012/6/18 JonY jo...@users.sourceforge.net:
 Hi,

 I am told that this ABI test does not apply to mingw targets. OK to apply?

 Hi JonY,

 The test doesn't apply to x64 windows targets, as for it sse is part of its 
 ABI.
 As test already checks for !ia32, we could simply check for
 x86_64/i?86-*-mingw* targets instead.  We don't need to check for
 ilp32 here again.

The test needs to be skipped if the target is:
x86_64-*-mingw*
i*86-*-mingw* with -m64 multilib option

and it needs to run if the target is:
i*86-*-mingw*
x86_64-*-mingw* with -m32 multilib option

Does anyone know how to make that happen?

Ping: [PATCH] Add implicit C linkage for win32-specific entry points

[NightStrike]

Eric,

Jacek Caban sent this:

http://gcc.gnu.org/ml/gcc-patches/2012-03/msg01987.html

in response to this:

http://gcc.gnu.org/ml/gcc-patches/2012-03/msg01986.html

But it never got reviewed.  Could you review and commit?

Re: [cxx-conversion] New Hash Table (issue6244048)

[NightStrike]

On Fri, May 25, 2012 at 11:07 AM, Diego Novillo dnovi...@google.com wrote:
 On 12-05-25 11:06 , Michael Matz wrote:

 Hi,

 On Fri, 25 May 2012, Diego Novillo wrote:

 That's one of my fears, namely that those used to the libstdc++
 style impose that on the compiler source base.  Because IMHO the
 libstdc++ style isn't very appealing.


 Seconded.


 I don't care how ugly coding conventions look.


 Perhaps people who don't care about uglyness shouldn't then be defining
 the style?  Half-way :-/


 Who says I am?  I *explicitly* said that Lawrence, Ian and Gaby are working
 on it.

Didn't Ian already create a style for writing gold in c++?

Re: [cxx-conversion] New Hash Table (issue6244048)

[NightStrike]

On Fri, May 25, 2012 at 12:50 PM, Gabriel Dos Reis
g...@integrable-solutions.net wrote:
 On Fri, May 25, 2012 at 11:44 AM, Paweł Sikora pl...@agmk.net wrote:

 so, why you just don't use the hash table implementation from libstdc++?

 we have agreed on C++03 as a bootstrap compiler.
 There is unfortunately no hash table in C++03.

That's a shame.  C++11 makes life wonderful.

Re: [cxx-conversion] New Hash Table (issue6244048)

[NightStrike]

On Fri, May 25, 2012 at 12:42 PM, Gabriel Dos Reis
g...@integrable-solutions.net wrote:
 with the current implementation language.  Consequently, I think
 we should retain the binding suggested by the C++ standard.
 I realize that the existing GNU C convention says the opposite -- but
 then it is written for C.

This point of yours should be stressed.  Using writing standards of
one language to develop in another language is a fundamentally bad
idea.  C and C++ kind of look the same, but they are not:
http://www.research.att.com/~bs/bs_faq.html#C-slash

You wouldn't use the GNU C Coding conventions to write in tcl, and you
shouldn't use them to write in C++.  You should just create the GNU
C++ Coding Standards new, and not base them off of the former.

What I see happening in this and in other recent threads is people
starting to apply C ideas to C++ code formatting.  Aren't there other
people out there that already did a pretty good job of painting that
shed green?  (I'm asking in earnest, I really don't know.)  I know in
the defense world that the JSF project did a very in depth and very
strict standard (http://www.jsf.mil/downloads/down_documentation.htm),
but that's as much as I know.

Re: [Patch] tree-parloops.c (eliminate_local_variables): Add braces to suppress warnings

[NightStrike]

On Wed, Apr 11, 2012 at 4:46 AM, Richard Guenther
richard.guent...@gmail.com wrote:
 On Tue, Apr 10, 2012 at 9:08 PM, NightStrike nightstr...@gmail.com wrote:
 On Tue, Apr 10, 2012 at 10:38 AM, Richard Guenther
 richard.guent...@gmail.com wrote:
 On Tue, Apr 10, 2012 at 3:06 PM, JonY jo...@users.sourceforge.net wrote:
 On 4/10/2012 20:37, Richard Guenther wrote:
 On Tue, Apr 10, 2012 at 2:15 PM, JonY wrote:
 Hi,

 Patch OK?

 What kind of warning?


 Oops, I forgot to mention gcc was complaining about missing braces.

 Not for me.  And I fail to see why it should.

 This is the warning:

 ../../../../build/gcc/src/gcc/tree-parloops.c:724: warning: suggest
 explicit braces to avoid ambiguous `else'

 ./xgcc -B. -c   -g -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual 
 -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute 
 -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings 
 -Wold-style-definition -Wc++-compat -fno-common  -DHAVE_CONFIG_H -I. -I. 
 -I/space/rguenther/src/svn/trunk/gcc -I/space/rguenther/src/svn/trunk/gcc/. 
 -I/space/rguenther/src/svn/trunk/gcc/../include 
 -I/space/rguenther/src/svn/trunk/gcc/../libcpp/include  
 -I/space/rguenther/src/svn/trunk/gcc/../libdecnumber 
 -I/space/rguenther/src/svn/trunk/gcc/../libdecnumber/bid -I../libdecnumber   
  /space/rguenther/src/svn/trunk/gcc/tree-parloops.c -o tree-parloops.o

 no warning from trunk.  Which GCC version emits this warning?  Note that
 we do not try to keep stage1 warning-free but only later stages (which is
 why we use -Werror there).

 Richard.

Looks like cygwin gcc 3.4.4

Re: [Patch] tree-parloops.c (eliminate_local_variables): Add braces to suppress warnings

[NightStrike]

On Fri, Apr 13, 2012 at 10:20 AM, Mike Stump mikest...@comcast.net wrote:
 On Apr 13, 2012, at 5:30 AM, NightStrike wrote:
 no warning from trunk.  Which GCC version emits this warning?

 Looks like cygwin gcc 3.4.4

 3.4.4 is a little old now..  We'd encourage an upgrade to a fine new 
 compiler...  :-)

Yeah, not sure why cygwin doesn't make the gcc4 packages the default.

Re: [Patch] tree-parloops.c (eliminate_local_variables): Add braces to suppress warnings

[NightStrike]

On Fri, Apr 13, 2012 at 10:33 AM, Bernd Schmidt ber...@codesourcery.com wrote:
 On 04/13/2012 04:20 PM, Mike Stump wrote:
 On Apr 13, 2012, at 5:30 AM, NightStrike wrote:
 no warning from trunk.  Which GCC version emits this warning?

 Looks like cygwin gcc 3.4.4

 3.4.4 is a little old now..  We'd encourage an upgrade to a fine new 
 compiler...  :-)

 The thing is, the else really is ambiguous, so it looks like we have a
 warning regression.

I'd agree here.  It's why I didn't think to try with a new compiler.

Re: [Patch] tree-parloops.c (eliminate_local_variables): Add braces to suppress warnings

[NightStrike]

On Tue, Apr 10, 2012 at 10:38 AM, Richard Guenther
richard.guent...@gmail.com wrote:
 On Tue, Apr 10, 2012 at 3:06 PM, JonY jo...@users.sourceforge.net wrote:
 On 4/10/2012 20:37, Richard Guenther wrote:
 On Tue, Apr 10, 2012 at 2:15 PM, JonY wrote:
 Hi,

 Patch OK?

 What kind of warning?


 Oops, I forgot to mention gcc was complaining about missing braces.

 Not for me.  And I fail to see why it should.

This is the warning:

../../../../build/gcc/src/gcc/tree-parloops.c:724: warning: suggest
explicit braces to avoid ambiguous `else'

Re: [patch] --enable-dynamic-string default for mingw-w64 v2

[NightStrike]

On Thu, Oct 13, 2011 at 9:47 AM, Paolo Carlini pcarl...@gmail.com wrote:

 Ping, did this go in trunk already?

 I would be surprised to see this happening if nobody like you or Kai actually 
 does the commit ;)

 P


Does Jon have commit access?

Re: [patch tree-optimization]: Fix regression about vrp47.c (and co)

[NightStrike]

Ping

On Thu, Jul 21, 2011 at 9:20 AM, Kai Tietz ktiet...@googlemail.com wrote:
 Hello,

 this patch adds the ability for bitwise-truth operations to sink into
 use-statement, if it is a cast, if type of it is compatible.

 By this we can sink cases like

 _Bool D1, D2, D3;
 int R, x, y;

 D1 = (bool) x;
 D2 = (bool) y;
 D3 = D1  D2
 R = (int) D3;

 into R-statment as
 R = x  y;

 This fixes known vrp47.c regression.

 ChangeLog gcc

 2011-07-21  Kai Tietz  kti...@redhat.com

        * tree-vrp.c (ssa_name_get_inner_ssa_name_p): New helper.
        (ssa_name_get_cast_to_p): Likewise.
        (simplify_truth_ops_using_ranges): Try to use type-cast
        for simplification of bitwise-binary expressions.
        (simplify_stmt_using_ranges): Try to sink into cast for
        bitwise-truth operations.

 2011-07-21  Kai Tietz  kti...@redhat.com

        * gcc.dg/tree-ssa/vrp47.c: Adjust testcase.

 Bootstrapped and regression tested for all standard languages
 (including Ada and Obj-C++) on
 host x86_64-pc-linux-gnu.  Ok for apply?


 Regards,
 Kai

 Index: gcc-head/gcc/tree-vrp.c
 ===
 --- gcc-head.orig/gcc/tree-vrp.c
 +++ gcc-head/gcc/tree-vrp.c
 @@ -6747,19 +6746,92 @@ varying:
   return SSA_PROP_VARYING;
  }

 +/* Returns operand1 of ssa-name with SSA_NAME as code, Otherwise it
 +   returns NULL_TREE.  */
 +static tree
 +ssa_name_get_inner_ssa_name_p (tree op)
 +{
 +  gimple stmt;
 +
 +  if (TREE_CODE (op) != SSA_NAME
 +      || !is_gimple_assign (SSA_NAME_DEF_STMT (op)))
 +    return NULL_TREE;
 +  stmt = SSA_NAME_DEF_STMT (op);
 +  if (gimple_assign_rhs_code (stmt) != SSA_NAME)
 +    return NULL_TREE;
 +  return gimple_assign_rhs1 (stmt);
 +}
 +
 +/* Returns operand of cast operation, if OP is a type-conversion. Otherwise
 +   return NULL_TREE.  */
 +static tree
 +ssa_name_get_cast_to_p (tree op)
 +{
 +  gimple stmt;
 +
 +  if (TREE_CODE (op) != SSA_NAME
 +      || !is_gimple_assign (SSA_NAME_DEF_STMT (op)))
 +    return NULL_TREE;
 +  stmt = SSA_NAME_DEF_STMT (op);
 +  if (!CONVERT_EXPR_CODE_P (gimple_assign_rhs_code (stmt)))
 +    return NULL_TREE;
 +  return gimple_assign_rhs1 (stmt);
 +}
 +
  /* Simplify boolean operations if the source is known
    to be already a boolean.  */
  static bool
  simplify_truth_ops_using_ranges (gimple_stmt_iterator *gsi, gimple stmt)
  {
   enum tree_code rhs_code = gimple_assign_rhs_code (stmt);
 +  gimple stmt2 = stmt;
   tree val = NULL;
   tree op0, op1;
   value_range_t *vr;
   bool sop = false;
   bool need_conversion;
 +  location_t loc = gimple_location (stmt);

   op0 = gimple_assign_rhs1 (stmt);
 +  op1 = NULL_TREE;
 +
 +  /* Handle cases with prefixed type-cast.  */
 +  if (CONVERT_EXPR_CODE_P (rhs_code)
 +       INTEGRAL_TYPE_P (TREE_TYPE (op0))
 +       TREE_CODE (op0) == SSA_NAME
 +       is_gimple_assign (SSA_NAME_DEF_STMT (op0))
 +       INTEGRAL_TYPE_P (TREE_TYPE (gimple_assign_lhs (stmt
 +    {
 +      stmt2 = SSA_NAME_DEF_STMT (op0);
 +      op0 = gimple_assign_rhs1 (stmt2);
 +      if (!INTEGRAL_TYPE_P (TREE_TYPE (op0)))
 +       return false;
 +      rhs_code = gimple_assign_rhs_code (stmt2);
 +      if (rhs_code != BIT_NOT_EXPR
 +          rhs_code != BIT_AND_EXPR
 +          rhs_code != BIT_IOR_EXPR
 +          rhs_code != BIT_XOR_EXPR
 +          rhs_code != NE_EXPR  rhs_code != EQ_EXPR)
 +       return false;
 +
 +      if (rhs_code != BIT_NOT_EXPR)
 +       op1 = gimple_assign_rhs2 (stmt2);
 +
 +      if (gimple_has_location (stmt2))
 +        loc = gimple_location (stmt2);
 +    }
 +  else if (CONVERT_EXPR_CODE_P (rhs_code))
 +    return false;
 +  else if (rhs_code != BIT_NOT_EXPR)
 +    op1 = gimple_assign_rhs2 (stmt);
 +
 +  /* ~X is only equivalent to !X, if type-precision is one and X has
 +     an integral type.  */
 +  if (rhs_code == BIT_NOT_EXPR
 +       (!INTEGRAL_TYPE_P (TREE_TYPE (op0))
 +         || TYPE_PRECISION (TREE_TYPE (op0)) != 1))
 +    return false;
 +
   if (TYPE_PRECISION (TREE_TYPE (op0)) != 1)
     {
       if (TREE_CODE (op0) != SSA_NAME)
 @@ -6775,19 +6847,83 @@ simplify_truth_ops_using_ranges (gimple_
         return false;
     }

 -  if (rhs_code == BIT_NOT_EXPR  TYPE_PRECISION (TREE_TYPE (op0)) == 1)
 +  need_conversion =
 +    !useless_type_conversion_p (TREE_TYPE (gimple_assign_lhs (stmt)),
 +                               TREE_TYPE (op0));
 +  /* As comparisons X != 0 getting folded to (bool) X by VRP,
 +     but X == 0 might be not folded for none boolean type of X
 +     to (bool) (X ^ 1), we need to handle this case special
 +     to simplify this.
 +     For bitwise-binary operations we have three cases to handle:
 +     a) ((bool) X) op ((bool) Y)
 +     b) ((bool) X) op (Y == 0) -OR- (X == 0) op ((bool) Y)
 +     c) (X == 0) op (Y == 0)
 +     The later two cases can't be handled for now, as we would beed to
 +     insert new statements.  */
 +  if (need_conversion
 +       (rhs_code == BIT_XOR_EXPR
 +         || rhs_code == 

Re: PATCH: Use long long for 64bit int in config/i386/64/sfp-machine.h

[NightStrike]

On Thu, Jul 28, 2011 at 3:45 PM, H.J. Lu hongjiu...@intel.com wrote:
 Hi Ian,

 For 64bit x86 targets, long is 32bit for x32 and win64.  But long long
 is always 64bit.  This patch removes _WIN64 check.  OK for trunk?

Isn't that what int64_t is for?

Re: Unreviewed libgcc patches

[NightStrike]

On Mon, Jul 18, 2011 at 8:21 AM, Rainer Orth
r...@cebitec.uni-bielefeld.de wrote:
 The following two libgcc patches have seen almost no comments, and
 certainly neither testing or review in a week:

        CFT: [build] Move fp-bit support to toplevel libgcc
        http://gcc.gnu.org/ml/gcc-patches/2011-07/msg00927.html

        CFT: [build] Move soft-fp support to toplevel libgcc
        http://gcc.gnu.org/ml/gcc-patches/2011-07/msg00931.html

 This patch will need to be updated for the recent addition of the c6x
 port.

 Both will probably need build and libgcc maintainers and either a bunch
 of target maintainers or a global reviewer.  I wonder how to proceed
 here: I've got a bunch of further libgcc patches in the works or
 planned, but if I can't get them reviewed, there's no point in
 continuing that work.

Do you still need support?

Re: [patch fold-const.c]: Add some missing optimizations about binary and and truth-not

[NightStrike]

On Mon, Jun 20, 2011 at 8:06 AM, Jakub Jelinek ja...@redhat.com wrote:
 On Mon, Jun 20, 2011 at 01:50:26PM +0200, Kai Tietz wrote:
  Ok.
  Richard.

 Applied at revision 175206 to trunk.

 There is no need to post such notices to gcc-patches, we have the gcc-cvs
 mailing list where this is automatically posted to.
 On gcc-patches it just adds unnecessary noise.

        Jakub


Until there is some way to easily map an email on gcc-patches to an
email on gcc-cvs, or a legitimate patch tracker instead of just
mailing lists, then it is very useful noise.  I've found at least a
hundred dropped patches so far for our project alone.  You can always
just delete the email instead of reading it.

Re: [patch fold-const.c]: Add some missing optimizations about binary and and truth-not

[NightStrike]

On Mon, Jun 20, 2011 at 10:47 AM, Jakub Jelinek ja...@redhat.com wrote:
 On Mon, Jun 20, 2011 at 10:37:30AM -0400, NightStrike wrote:
 On Mon, Jun 20, 2011 at 8:06 AM, Jakub Jelinek ja...@redhat.com wrote:
  On Mon, Jun 20, 2011 at 01:50:26PM +0200, Kai Tietz wrote:
  Applied at revision 175206 to trunk.
 
  There is no need to post such notices to gcc-patches, we have the gcc-cvs
  mailing list where this is automatically posted to.
  On gcc-patches it just adds unnecessary noise.

 Until there is some way to easily map an email on gcc-patches to an
 email on gcc-cvs, or a legitimate patch tracker instead of just
 mailing lists, then it is very useful noise.  I've found at least a
 hundred dropped patches so far for our project alone.  You can always
 just delete the email instead of reading it.

 No, our guidelines say that such mails shouldn't be sent:

 http://gcc.gnu.org/svnwrite.html
 When you have checked in a patch exactly as it has been approved, you do
 not need to tell that to people -- including the approver. People
 interested in when a particular patch is committed can check SVN or the
 gcc-cvs list.

do not need != cannot


 This has been discussed several times.  So no, this noise isn't at all
 useful nor welcome.

useful or welcome TO YOU.  Obviously, it's useful to us.

        Jakub

Re: [PING] Fix PR46399 - missing mode promotion for libcall args

[NightStrike]

On Wed, May 4, 2011 at 9:45 AM, Richard Guenther
richard.guent...@gmail.com wrote:
 On Wed, May 4, 2011 at 3:45 PM, Kai Tietz ktiet...@googlemail.com wrote:
 2011/5/4 Richard Guenther richard.guent...@gmail.com:
 On Mon, Apr 18, 2011 at 10:17 AM, Andreas Krebbel
 kreb...@linux.vnet.ibm.com wrote:
 Hi,

 the attached patch uses the existing promote_function_mode hook.  For
 a libcall neither TYPE nor FNTYPE is available so I had to change a
 few related function in order to deal with that.

 The patch also fixes the s390 DFP problems.

 Bye,

 -Andreas-


 2011-04-18  Andreas Krebbel  andreas.kreb...@de.ibm.com

        * calls.c (emit_library_call_value_1): Invoke
        promote_function_mode hook on libcall arguments.
        * explow.c (promote_function_mode, promote_mode): Handle TYPE
        argument being NULL.
        * targhooks.c (default_promote_function_mode): Lisewise.
        * config/s390/s390.c (s390_promote_function_mode): Likewise.
        * config/sparc/sparc.c (sparc_promote_function_mode): Likewise.

        * doc/tm.texi: Document that TYPE argument might be NULL.


 Index: gcc/calls.c
 ===
 *** gcc/calls.c.orig
 --- gcc/calls.c
 *** emit_library_call_value_1 (int retval, r
 *** 3484,3489 
 --- 3484,3490 
      {
        rtx val = va_arg (p, rtx);
        enum machine_mode mode = (enum machine_mode) va_arg (p, int);
 +       int unsigned_p = 0;

        /* We cannot convert the arg value to the mode the library wants 
 here;
         must do it earlier where we know the signedness of the arg.  */
 *** emit_library_call_value_1 (int retval, r
 *** 3531,3539 
          val = force_operand (XEXP (slot, 0), NULL_RTX);
        }

 !       argvec[count].value = val;
        argvec[count].mode = mode;
 !
        argvec[count].reg = targetm.calls.function_arg (args_so_far, mode,
                                                      NULL_TREE, true);

 --- 3532,3540 
          val = force_operand (XEXP (slot, 0), NULL_RTX);
        }

 !       mode = promote_function_mode (NULL_TREE, mode, unsigned_p, 
 NULL_TREE, 0);
        argvec[count].mode = mode;
 !       argvec[count].value = convert_modes (mode, GET_MODE (val), val, 0);
        argvec[count].reg = targetm.calls.function_arg (args_so_far, mode,
                                                      NULL_TREE, true);

 Index: gcc/config/s390/s390.c
 ===
 *** gcc/config/s390/s390.c.orig
 --- gcc/config/s390/s390.c
 *** s390_promote_function_mode (const_tree t
 *** 8742,8748 
    if (INTEGRAL_MODE_P (mode)
         GET_MODE_SIZE (mode)  UNITS_PER_LONG)
      {
 !       if (POINTER_TYPE_P (type))
        *punsignedp = POINTERS_EXTEND_UNSIGNED;
        return Pmode;
      }
 --- 8742,8748 
    if (INTEGRAL_MODE_P (mode)
         GET_MODE_SIZE (mode)  UNITS_PER_LONG)
      {
 !       if (type != NULL_TREE  POINTER_TYPE_P (type))
        *punsignedp = POINTERS_EXTEND_UNSIGNED;
        return Pmode;
      }
 Index: gcc/explow.c
 ===
 *** gcc/explow.c.orig
 --- gcc/explow.c
 *** enum machine_mode
 *** 771,776 
 --- 771,787 
  promote_function_mode (const_tree type, enum machine_mode mode, int 
 *punsignedp,
                       const_tree funtype, int for_return)
  {
 +   /* Called without a type node for a libcall.  */
 +   if (type == NULL_TREE)
 +     {
 +       if (INTEGRAL_MODE_P (mode))
 +       return targetm.calls.promote_function_mode (NULL_TREE, mode,
 +                                                   punsignedp, funtype,
 +                                                   for_return);
 +       else
 +       return mode;
 +     }
 +
    switch (TREE_CODE (type))
      {
      case INTEGER_TYPE:   case ENUMERAL_TYPE:   case BOOLEAN_TYPE:
 *** enum machine_mode
 *** 791,796 
 --- 802,813 
  promote_mode (const_tree type ATTRIBUTE_UNUSED, enum machine_mode mode,
              int *punsignedp ATTRIBUTE_UNUSED)
  {
 +   /* For libcalls this is invoked without TYPE from the backends
 +      TARGET_PROMOTE_FUNCTION_MODE hooks.  Don't do anything in that
 +      case.  */
 +   if (type == NULL_TREE)
 +     return mode;
 +

 This broke bootstrap

 /space/rguenther/src/svn/trunk/gcc/explow.c: In function 'promote_mode':
 /space/rguenther/src/svn/trunk/gcc/explow.c:815:3: error: ISO C90
 forbids mixed declarations and code [-Werror=edantic]
 cc1: all warnings being treated as errors


    /* FIXME: this is the same logic that was there until GCC 4.4, but we
       probably want to test POINTERS_EXTEND_UNSIGNED even if PROMOTE_MODE
       is not defined.  The affected targets are M32C, S390, SPARC.  */
 Index: gcc/config/sparc/sparc.c
 ===
 *** gcc/config/sparc/sparc.c.orig
 --- 

Re: [ping] 3 unreviewed patches

[NightStrike]

Ping again.  Still no review.

On Fri, Apr 15, 2011 at 7:08 AM, Eric Botcazou ebotca...@adacore.com wrote:
 Fix annoying gcov filename handling:
  http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01380.html

 (rs6000) Fix thinko in output_profile_hook:
  http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01624.html

 Introduce -Wstack-usage:
  http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01992.html

 Thanks in advance.

 --
 Eric Botcazou