Enquiry
Hello, We are interested in importing your products to Costa Rica. Please send your product catalog to (epicr...@protonmail.com) for further information. Awaiting... Regards, Paul
C:\Program Files (x86)\Dev-Cpp\MinGW64\x86_64-w64-mingw32\lib32\libmingw32.a(lib32_libmingw32_a-crt0_c.o) In function `main': 18 C:\crossdev\src\mingw-w64-v3-git\mingw-w64-crt\crt\crt0_c.c undefined r
unsubscribe
> -Original Message-
> From: gcc-announce On Behalf Of Richard
> Biener
> Sent: Tuesday, June 01, 2021 4:42 AM
> To: gcc-annou...@gcc.gnu.org; gcc@gcc.gnu.org; info-...@gnu.org
> Subject: [EXT] GCC 9.4 Released
>
> [Actual Sender is gcc-announce-boun...@gcc.gnu.org]
>
> The GNU Compiler Collection version 9.4 has been released.
>
> GCC 9.4 is a bug-fix release from the GCC 9 branch containing important
> fixes for regressions and serious bugs in GCC 9.3 with more than 190 bugs
> fixed since the previous release.
>
> This release is available from the WWW and FTP servers listed here:
>
> https://sourceware.org/pub/gcc/releases/gcc-9.4.0/
> https://gcc.gnu.org/mirrors.html
>
>
> Please do not contact me directly regarding questions or comments
> about this release. Instead, use the resources available from
> http://gcc.gnu.org.
>
> As always, a vast number of people contributed to this GCC release
> -- far too many to thank them individually!
Confidentiality Notice: This electronic message transmission, including any
attachment(s), may contain confidential, proprietary, or privileged information
from CAS, a division of the American Chemical Society ("ACS"). If you have
received this transmission in error, be advised that any disclosure, copying,
distribution, or use of the contents of this information is strictly
prohibited. Please destroy all copies of the message and contact the sender
immediately by either replying to this message or calling 614-447-3600.
Re: RFC: Sphinx for GCC documentation
> On Jun 4, 2021, at 3:55 AM, Tobias Burnus wrote: > > Hello, > > On 13.05.21 13:45, Martin Liška wrote: >> On 4/1/21 3:30 PM, Martin Liška wrote: >>> That said, I'm asking the GCC community for a green light before I >>> invest >>> more time on it? >> So far, I've received just a small feedback about the transition. In >> most cases positive. >> >> [1] https://splichal.eu/scripts/sphinx/ > > The HTML output looks quite nice. > > What I observed: > > * Looking at > > https://splichal.eu/scripts/sphinx/gfortran/_build/html/intrinsic-procedures/access-checks-file-access-modes.html > why is the first argument description in bold? > It is also not very readable to have a scollbar there – linebreaks would be > better. > → I think that's because the assumption is that the first line contains a > header > and the rest the data Explicit line breaks are likely to be wrong depending on the reader's window size. I would suggest setting the table to have cells with line-wrapped contents. That would typically be the default in HTML, I'm curious why that is not happening here. paul
Re: GCC documentation: porting to Sphinx
> On Jun 11, 2021, at 11:50 AM, Joseph Myers wrote: > > ... > > "make" at top level should build all the info manuals and man pages, as at > present (if a suitable Sphinx version is installed), and "make install" > should install them, in the same directories as at present. > > "make html" at top level should build all the HTML manuals, and "make > install-html" should install them. > > "make pdf" and "make install-pdf" at top level should work likewise. > > "make install-html" and "make install-pdf" should put things under > $(DESTDIR)$(htmldir) and $(DESTDIR)$(pdfdir) as at present. And in addition, it would be nice to have additional make and make install- targets for other output formats that Sphinx can generate for us, at least some of them. "epub" comes to mind as an example I would like to have. paul
Re: Benefits of using Sphinx documentation format
> On Jul 12, 2021, at 12:36 PM, David Malcolm via Gcc-patches > wrote: > > On Mon, 2021-07-12 at 15:25 +0200, Martin Liška wrote: >> ... > > I think the output formats we need to support are: > - HTML > - PDF > - man page (hardly "modern", but still used) Also info format (for the Emacs info reader). And ebook formats (epub and/or mobi). Having good quality ebook output is a major benefit in my view; it would be very good for the standard makefiles to offer make targets for these formats. paul
unsubscribe
-Original Message-
From: gcc-announce On Behalf
Of Richard Biener via gcc-announce
Sent: Thursday, April 21, 2022 5:13 AM
To: gcc-annou...@gcc.gnu.org; gcc@gcc.gnu.org; info-...@gnu.org
Cc: Richard Biener
Subject: [EXT] GCC 11.3 Released
[Actual Sender is gcc-announce-bounces+pdubuc=cas@gcc.gnu.org]
The GNU Compiler Collection version 11.3 has been released.
GCC 11.3 is a bug-fix release from the GCC 11 branch containing important fixes
for regressions and serious bugs in GCC 11.2 with more than 189 bugs fixed
since the previous release.
This release is available from the WWW and FTP servers listed here:
https://sourceware.org/pub/gcc/releases/gcc-11.3.0/
https://gcc.gnu.org/mirrors.html
Please do not contact me directly regarding questions or comments about this
release. Instead, use the resources available from http://gcc.gnu.org.
As always, a vast number of people contributed to this GCC release
-- far too many to thank them individually!
Confidentiality Notice: This electronic message transmission, including any
attachment(s), may contain confidential, proprietary, or privileged information
from CAS, a division of the American Chemical Society ("ACS"). If you have
received this transmission in error, be advised that any disclosure, copying,
distribution, or use of the contents of this information is strictly
prohibited. Please destroy all copies of the message and contact the sender
immediately by either replying to this message or calling 614-447-3600.
Setting test suite not to try debug output cases
Given that pdp11 no longer supports debug output, I get a lot more test failures, like this: spawn -ignore SIGHUP /Users/pkoning/Documents/svn/build/pdp/gcc/xgcc -B/Users/pkoning/Documents/svn/build/pdp/gcc/ -mlra -fdiagnostics-plain-output -Og -g -w -c -o 2105-1.o /Users/pkoning/Documents/svn/gcc/gcc/testsuite/gcc.c-torture/compile/2105-1.c xgcc: warning: target system does not support debug output cc1: warning: target system does not support debug output FAIL: gcc.c-torture/compile/2105-1.c -Og -g (test for excess errors) I assume there is some way in the test suite machinery to globally skip all "debug output" cases. How would I do that? paul
Re: Setting test suite not to try debug output cases
> On Sep 5, 2022, at 5:29 AM, Richard Biener wrote:
>
>
> [EXTERNAL EMAIL]
>
> On Fri, Sep 2, 2022 at 8:57 PM Koning, Paul via Gcc wrote:
>>
>> Given that pdp11 no longer supports debug output, I get a lot more test
>> failures, like this:
>>
>> spawn -ignore SIGHUP /Users/pkoning/Documents/svn/build/pdp/gcc/xgcc
>> -B/Users/pkoning/Documents/svn/build/pdp/gcc/ -mlra
>> -fdiagnostics-plain-output -Og -g -w -c -o 2105-1.o
>> /Users/pkoning/Documents/svn/gcc/gcc/testsuite/gcc.c-torture/compile/2105-1.c
>> xgcc: warning: target system does not support debug output
>> cc1: warning: target system does not support debug output
>> FAIL: gcc.c-torture/compile/2105-1.c -Og -g (test for excess errors)
>>
>> I assume there is some way in the test suite machinery to globally skip all
>> "debug output" cases. How would I do that?
>
> Hmm. In testsuite/lib/prune.exp there's
>
># Ignore stabs obsoletion warnings
>regsub -all "(^|\n)\[^\n\]*\[Ww\]arning: STABS debugging
> information is obsolete and not supported anymore\[^\n\]*" $text ""
> text
>
> maybe you can (selectively for pdp11) add similar pruning of the
> 'target system does not support debug output' message?
> I think you should be able to use
>
> if { [istarget pdp11-*-*] } then {
> regsub -all " ... " ...
> }
Thanks, I'll look into that. Should it be more general to cover any other
targets that don't have debug output? I think pdp11 isn't the only one but I'm
not sure.
paul
Re: [GSoC][Static Analyzer] Some questions and request for a small patch to work on
On 27/02/2023 14:49, Iain Sandoe wrote: Hi Shengyu, By the way, is it expected that I need to configure with `--with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk`? Yes. - for some time now macOS no longer installs headers in /usr/include (and on newer versions most of the libraries are omitted from /usr/lib). The libs are now squirreled away in the DSC (dylib shared cache). For our protection. If you want to script the detection of sysroot you can use xcrun --sdk macosx --show-sdk-path (but that doesn't work with old versions of XCode). A+ Pau
Re: Safe transposition of logical and operands
Hi Richard and Jonathan On 18/09/2023 10:00, Richard Biener wrote: On Mon, Sep 18, 2023 at 9:24 AM Jonathan Wakely via Gcc wrote: Yes, GCC assumes that the reference is bound to a valid object, because C++ requires that to be true. Of course memcheck can't assume that, because one of its main reasons to exist is to find undefined behaviour where that isn't true! It's even worse than that. This transformation is being done in VEX (which unfortunately is also the bit I know the least). Not normally where we'd do accessibility checks. I think what GCC is doing is a valid transformation, in the context of a valid C++ program. But I'm not sure that helps valgrind, which doesn't have the liberty of assuming a valid program. More specifically GCC thinks it's fine to speculate loads (given it can prove doing so doesn't trap) I don't think that will be easy for us to prove. We just don't know enough about stack variables. A+ Paui
