Broken links in INSTALL/specific.html
Hi!
PR web/85578 complains about broken links in INSTALL/specific.html inside of
the rc tarballs, I've looked at past releases and at least the releases I've
checked (4.7.0, 6.1, 7.1, 7.3, 8.1rc2) all have the broken links,
e.g.
aarch64*-*-*
and
aarch64*-*-*
Looking at online docs, they are ok.
I think this has been fixed for the online docs with:
Index: preprocess
===
RCS file: /cvs/gcc/wwwdocs/bin/preprocess,v
retrieving revision 1.38
retrieving revision 1.39
diff -u -p -r1.38 -r1.39
--- preprocess 28 Aug 2003 13:05:38 - 1.38
+++ preprocess 5 Sep 2004 21:50:02 - 1.39
@@ -144,7 +144,10 @@ process_file()
cat $STYLE > $TMPDIR/input
printf '\n' `pwd` >>
$TMPDIR/input
cat $f >> $TMPDIR/input
-${MHC} $TMPDIR/input > $TMPDIR/output
+# Use sed to work around makeinfo 4.7 brokenness.
+${MHC} $TMPDIR/input \
+| sed -e 's/_002d/-/g' -e 's/_002a/*/g' \
+> $TMPDIR/output
# Copy the page only if it's new or there has been a change, and,
# first of all, if there was no problem when running MetaHTML.
revision 1.39
date: 2004/09/05 21:50:02; author: gerald; state: Exp; lines: +4 -1
Use sed to work around makeinfo 4.7 brokenness.
Isn't this something we should be doing in gcc/doc/install.texi2html
too (or somewhere else)?
Bugzilla is down, so can't discuss it there...
Jakub
Fast and Unlimited Satellite Internet Subscription
http://iccsat.com?&utm_source=newsletter&utm_medium=email&utm_campaign=vsat_satellite_service_data_voice_internet&utm_term=2017-10-31 ** ICCSAT (http://www.iccsat.com?&utm_source=newsletter&utm_medium=email&utm_campaign=vsat_satellite_service_data_voice_internet&utm_term=2017-10-31) We continue to expand across a broad range of industries as we leverage our expertise and advanced technology to meet the varied needs of these customers from remote offices, support mobile connectivity across land, sea and air, providing high-speed broadband access anywhere in the world. ** ICCSAT SERVICES http://www.iccsat.net/?page_id=10491&utm_source=newsletter&utm_medium=email&utm_campaign=vsat_satellite_service_data_voice_internet&utm_term=2017-10-31 ** Point to Point (http://www.iccsat.net/?page_id=10491&utm_source=newsletter&utm_medium=email&utm_campaign=vsat_satellite_service_data_voice_internet&utm_term=2017-10-31) Link is a dedicated link that connects exactly two communication facilities. http://www.iccsat.net/?page_id=10507&utm_source=newsletter&utm_medium=email&utm_campaign=vsat_satellite_service_data_voice_internet&utm_term=2017-10-31 ** Point to Multipoint (http://www.iccsat.net/?page_id=10507&utm_source=newsletter&utm_medium=email&utm_campaign=vsat_satellite_service_data_voice_internet&utm_term=2017-10-31) Communication which is accomplished via a specific and distinct type of multipoint connection. ** 100% Secured Enjoy and have a peace of mind with our 100% Secured Connection services - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - http://www.iccsat.net/?page_id=10446&utm_source=newsletter&utm_medium=email&utm_campaign=vsat_satellite_service_data_voice_internet&utm_term=2017-10-31 ** SCPC/SCPC (http://www.iccsat.net/?page_id=10446&utm_source=newsletter&utm_medium=email&utm_campaign=vsat_satellite_service_data_voice_internet&utm_term=2017-10-31) Cost effective solution for broadband connectivity, can be mounted on smaller vehicles. http://www.iccsat.net/?page_id=10512&utm_source=newsletter&utm_medium=email&utm_campaign=vsat_satellite_service_data_voice_internet&utm_term=2017-10-31 ** SCPC/DVB (http://www.iccsat.net/?page_id=10512&utm_source=newsletter&utm_medium=email&utm_campaign=vsat_satellite_service_data_voice_internet&utm_term=2017-10-31) SCPC-DVB Dedicated Services SCPC/DVB is widely used for access to internet services. http://www.iccsat.net/?page_id=10515&utm_source=newsletter&utm_medium=email&utm_campaign=vsat_satellite_service_data_voice_internet&utm_term=2017-10-31 ** Mesh Service (http://www.iccsat.net/?page_id=10515&utm_source=newsletter&utm_medium=email&utm_campaign=vsat_satellite_service_data_voice_internet&utm_term=2017-10-31) A type of networking wherein each site in the network may act as an independent router. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - http://www.iccsat.net/?page_id=10509&utm_source=newsletter&utm_medium=email&utm_campaign=vsat_satellite_service_data_voice_internet&utm_term=2017-10-31 ** Internet Services (http://www.iccsat.net/?page_id=10509&utm_source=newsletter&utm_medium=email&utm_campaign=vsat_satellite_service_data_voice_internet&utm_term=2017-10-31) Provide internet broadband connection to the end customer based on their requirements. http://www.iccsat.net/?page_id=10509&utm_source=newsletter&utm_medium=email&utm_campaign=vsat_satellite_service_data_voice_internet&utm_term=2017-10-31 ** IP Connectivity (http://www.iccsat.net/?page_id=10509&utm_source=newsletter&utm_medium=email&utm_campaign=vsat_satellite_service_data_voice_internet&utm_term=2017-10-31) Provide internet broadband connection to the end customer based on their requirements. http://www.iccsat.net/?page_id=10446&utm_source=newsletter&utm_medium=email&utm_campaign=vsat_satellite_service_data_voice_internet&utm_term=2017-10-31 ** Mobile VSAT (http://www.iccsat.net/?page_id=10446&utm_source=newsletter&utm_medium=email&utm_campaign=vsat_satellite_service_data_voice_internet&utm_term=2017-10-31) Cost effective solution for broadband connectivity, can be mounted on smaller vehicles. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ICCSAT Jeddah, Kingdom Saudi Arabia. Tel.: +966 92 000 1445 Fax: +966 12 6067356 Email: sa...@iccsat.com www.iccsat.
Re: Broken links in INSTALL/specific.html
The reason I was looking at the versions in the RC tarball was that I
have never been clear as to what release the website
install/prerequisite/target info actually applies to.
It would be much better if this info was on a per release basis on the
web site, like the changelog and manuals. Thus any target
specific stuff which was removed wouldn't affect older releases
documentation.
Speaking of manuals, it might be worth documenting the make commands for
the documentation (make html, install-html and pdf, install-pdf) on the
build.html page.
The documentation can only get checked before the release if people are
aware how to build it.
Andrew
On 01/05/18 08:27, Jakub Jelinek wrote:
Hi!
PR web/85578 complains about broken links in INSTALL/specific.html inside of
the rc tarballs, I've looked at past releases and at least the releases I've
checked (4.7.0, 6.1, 7.1, 7.3, 8.1rc2) all have the broken links,
e.g.
aarch64*-*-*
and
aarch64*-*-*
Looking at online docs, they are ok.
I think this has been fixed for the online docs with:
Index: preprocess
===
RCS file: /cvs/gcc/wwwdocs/bin/preprocess,v
retrieving revision 1.38
retrieving revision 1.39
diff -u -p -r1.38 -r1.39
--- preprocess 28 Aug 2003 13:05:38 - 1.38
+++ preprocess 5 Sep 2004 21:50:02 - 1.39
@@ -144,7 +144,10 @@ process_file()
cat $STYLE > $TMPDIR/input
printf '\n' `pwd` >>
$TMPDIR/input
cat $f >> $TMPDIR/input
-${MHC} $TMPDIR/input > $TMPDIR/output
+# Use sed to work around makeinfo 4.7 brokenness.
+${MHC} $TMPDIR/input \
+| sed -e 's/_002d/-/g' -e 's/_002a/*/g' \
+> $TMPDIR/output
# Copy the page only if it's new or there has been a change, and,
# first of all, if there was no problem when running MetaHTML.
revision 1.39
date: 2004/09/05 21:50:02; author: gerald; state: Exp; lines: +4 -1
Use sed to work around makeinfo 4.7 brokenness.
Isn't this something we should be doing in gcc/doc/install.texi2html
too (or somewhere else)?
Bugzilla is down, so can't discuss it there...
Jakub
Re: "position independent" vs "position-independent" in documentation
On 30/04/18 22:12 -0600, Sandra Loosemore wrote:
On 04/30/2018 05:56 AM, Jonathan Wakely wrote:
Should we standardize on "position-independent" and add it to
https://gcc.gnu.org/codingconventions.html#Spelling ?
The same generic English usage rules apply here as to other compound
phrases; hyphenate when immediately before a noun, don't hyphenate in
other contexts. So "the compiler generates position-independent code"
and "the compiler generates code that is position independent" are
both correct.
Or we could decide that "position-independent" should always be
hyphenated as it's a commonly established adjective. I'm not arguing
in favour of that, but it's how it's used in some of the docs already.
However, I don't think it's common to use "position
independent" (hyphenated or not) except as a modifier for "code", so
you could add "position-independent code" (rather than just
"position-independent") to the glossary.
We have several of uses of "position independent executable" and
one "position independent data" which should be hyphenated.
Ignoring all the uses of "position-independent code" that already have
a hyphen we're left with the following and none of them is correct!
--
gcc/doc/invoke.texi-@opindex pie
gcc/doc/invoke.texi:Produce a dynamically linked position independent
executable on targets
gcc/doc/invoke.texi-that support it. For predictable results, you must also
specify the same
--
gcc/doc/invoke.texi-@opindex no-pie
gcc/doc/invoke.texi:Don't produce a dynamically linked position independent
executable.
gcc/doc/invoke.texi-
--
gcc/doc/invoke.texi-@opindex static-pie
gcc/doc/invoke.texi:Produce a static position independent executable on targets
that support
gcc/doc/invoke.texi:it. A static position independent executable is similar to
a static
gcc/doc/invoke.texi-executable, but can be loaded at any address without a
dynamic linker.
--
gcc/doc/invoke.texi-but not for the Sun 386i. Code generated for the IBM
RS/6000 is always
gcc/doc/invoke.texi:position-independent.
gcc/doc/invoke.texi-
--
gcc/doc/invoke.texi-Generate code that does not use a global pointer register.
The result
gcc/doc/invoke.texi:is not position independent code, and violates the IA-64
ABI@.
gcc/doc/invoke.texi-
--
gcc/doc/invoke.texi-@itemx -mno-shared
gcc/doc/invoke.texi:Generate (do not generate) code that is fully
position-independent,
gcc/doc/invoke.texi-and that can therefore be linked into shared libraries.
This option
--
gcc/doc/invoke.texi-
gcc/doc/invoke.texi:All @option{-mabicalls} code has traditionally been
position-independent,
gcc/doc/invoke.texi-regardless of options like @option{-fPIC} and
@option{-fpic}. However,
--
gcc/doc/invoke.texi-@opindex mno-pid
gcc/doc/invoke.texi:Enables the generation of position independent data. When
enabled any
gcc/doc/invoke.texi-access to constant data is done via an offset from a base
address
--
gcc/doc/md.texi-Constant for arithmetic/logical operations.
gcc/doc/md.texi:This is like @code{i}, except that for position independent
code,
gcc/doc/md.texi-no symbols / expressions needing relocations are allowed.
--
gcc/doc/tm.texi-* Sections::Dividing storage into text, data, and
other sections.
gcc/doc/tm.texi:* PIC:: Macros for position independent code.
gcc/doc/tm.texi-* Assembler Format::Defining how to write insns and
pseudo-ops to output.
--
gcc/doc/tm.texi-@section Position Independent Code
gcc/doc/tm.texi:@cindex position independent code
gcc/doc/tm.texi-@cindex PIC
--
gcc/doc/tm.texi-A C expression that is nonzero if @var{x} is a legitimate
immediate
gcc/doc/tm.texi:operand on the target machine when generating position
independent code.
gcc/doc/tm.texi-You can assume that @var{x} satisfies @code{CONSTANT_P}, so you
need not
--
gcc/doc/tm.texi-(including @code{SYMBOL_REF}) can be immediate operands when
generating
gcc/doc/tm.texi:position independent code.
gcc/doc/tm.texi-@end defmac
--
gcc/doc/tm.texi.in-* Sections::Dividing storage into text, data,
and other sections.
gcc/doc/tm.texi.in:* PIC:: Macros for position independent code.
gcc/doc/tm.texi.in-* Assembler Format::Defining how to write insns and
pseudo-ops to output.
--
gcc/doc/tm.texi.in-@section Position Independent Code
gcc/doc/tm.texi.in:@cindex position independent code
gcc/doc/tm.texi.in-@cindex PIC
--
gcc/doc/tm.texi.in-A C expression that is nonzero if @var{x} is a legitimate
immediate
gcc/doc/tm.texi.in:operand on the target machine when generating position
independent code.
gcc/doc/tm.texi.in-You can assume that @var{x} satisfies @code{CONSTANT_P}, so
you need not
--
gcc/doc/tm.texi.in-(including @code{SYMBOL_REF}) can be immediate operands when
generating
gcc/doc/tm.texi.in:position independent code.
gcc/doc/tm.texi.in-@end defmac
Re: gcc 8.0.1 RC documentation broken
On 1 May 2018 at 05:42, Andrew Roberts wrote: > I filed this under 'web' as I couldn't see any documentation component. It > doesn't appear to have been looked at, There's a "documentation" keyword instead, but I'm often not sure which component doc bugs should be filed under.
Re: Stack protector: leak of guard's address on stack
> On Apr 29, 2018, at 2:11 PM, Florian Weimer wrote: > > * Maxim Kuvyrkov: > >>> On Apr 28, 2018, at 9:22 PM, Florian Weimer wrote: >>> >>> * Thomas Preudhomme: >>> Yes absolutely, CSE needs to be avoided. I made memory access volatile because the change was easier to do. Also on Arm Thumb-1 computing the guard's address itself takes several loads so had to modify some more patterns. Anyway, regardless of the proper fix, do you have any objection to raising a CVE for that issue? >>> >>> Please file a bug in Bugzilla first and use that in the submission to >>> MITRE. >> >> Thomas filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85434 couple >> of weeks ago. > > Is there a generic way to find other affected targets? > > If we only plan to fix 32-bit Arm, we should make the CVE identifier > specific to that, to avoid confusion. The problem is fairly target-dependent, so architecture maintainers need to look at how stack-guard canaries and their addresses are handled and whether they can be spilled onto stack. It appears we need to poll architecture maintainers before filing the CVE. -- Maxim Kuvyrkov www.linaro.org
Re: Stack protector: leak of guard's address on stack
* Maxim Kuvyrkov: > The problem is fairly target-dependent, so architecture maintainers > need to look at how stack-guard canaries and their addresses are > handled and whether they can be spilled onto stack. > > It appears we need to poll architecture maintainers before filing the CVE. One CVE ID by identified affected architecture would work as well. MITRE cares about affected software *versions* as well, and since the targets were added at different GCC versions (or stack protector support was added), the CVE IDs should be split in most cases anyway.
Re: Second GCC 8.1 Release Candidate available from gcc.gnu.org
On Fri, 2018-04-27 at 23:39 +0200, Jakub Jelinek wrote: > The second release candidate for GCC 8.1 is available from > > ftp://gcc.gnu.org/pub/gcc/snapshots/8.0.1-RC-20180427 > > and shortly its mirrors. It has been generated from SVN revision > 259731. > > I have so far bootstrapped and tested the release candidate on > x86_64-linux and i686-linux. Please test it and report any issues to > bugzilla. > > If all goes well, I'd like to release 8.1 on Wednesday, May 2nd. Hello! I would like to bring this strange issue to your attention too. https://sourceware.org/bugzilla/show_bug.cgi?id=23126#c3 This is not (at least not entirely) a GCC problem, but with previous versions (back to GCC 5 at least) it was working fine, because GCC did not explicitly set `.arch` directive in assembly files - just `.cpu`. Regards, FCh
Should GCC emit the same code for compilation with '-g' and without '-g'
Hi, Does gcc have a requirement about the impact of emitting debug info on the generated code? Should the code be the same no matter whether '-g' is specified? Thank you. -- Best Regards. Chengnian
Re: Should GCC emit the same code for compilation with '-g' and without '-g'
On Tue, May 01, 2018 at 12:53:45PM -0700, Chengnian Sun wrote:
> Does gcc have a requirement about the impact of emitting debug info on the
> generated code? Should the code be the same no matter whether '-g' is
> specified?
Yes (except for selective scheduling, but that warns if you combine
-fselecting-scheduling{,2} together with -fvar-tracking-assignments
and disables the latter by default).
Jakub
