GSOC
In the given link I shared My GSOC 2020 Project Proposal And Tell Me If Any Other Extra Point I have to Add on it. Any Give Me feedback About My Project Proposal . https://docs.google.com/document/d/1J2lCtkDPoU0gwp5zk8Ygy0Vg82fNn-ZH0gsv5dBkKok/edit?usp=sharing
Re: [GSoC 2020] Automatic Detection of Parallel Compilation Viability
On Fri, 13 Mar 2020, Giuliano Belinassi wrote:
> Hi, all
>
> I want to propose and apply for the following GSoC project: Automatic
> Detection of Parallel Compilation Viability.
>
> Here is the proposal, and I am attaching a pdf file for better
> readability:
>
> **Automatic Detection of Parallel Compilation Viability**
>
> [Giuliano Belinassi]{style="color: darkgreen"}\
> Timezone: GMT$-$3:00\
> University of São Paulo -- Brazil\
> IRC: giulianob in \#gcc\
> Email: [`giuliano.belina...@usp.br`](mailto:giuliano.belina...@usp.br)\
> Github:
Re: GSOC
Hi, Shivan. On 03/15, shivam tiwari via Gcc wrote: > In Which Format I have to Send Gsoc Proposal On this Mail PDF or DOC Format Perhaps the best way to write your proposal is to write LaTeX, and then convert it to Markdown using pandoc, and attach it to the mailing list. One example of this approach is: https://gcc.gnu.org/pipermail/gcc/2020-March/231825.html Thank you, Giuliano.
Not usable email content encoding
Hello.
I noticed some emails reaching gcc-patc...@gcc.gnu.org use the following
quoting:
```
case UNGT_EXPR:
case UNGE_EXPR:
case UNEQ_EXPR:
+case MEM_REF:
/* Binary operations evaluating both arguments (increment and
=09 decrement are binary internally in GCC). */
orig_op0 =3D op0 =3D TREE_OPERAND (expr, 0);
@@ -435,6 +436,14 @@ c_fully_fold_internal (tree expr, bool i
=09 || TREE_CODE (TREE_TYPE (orig_op0)) =3D=3D FIXED_POINT_TYPE)
=09 && TREE_CODE (TREE_TYPE (orig_op1)) =3D=3D INTEGER_TYPE)
=09warn_for_div_by_zero (loc, op1);
+ if (code =3D=3D MEM_REF
+=09 && ret !=3D expr
+=09 && TREE_CODE (ret) =3D=3D MEM_REF)
+=09{
+=09 TREE_READONLY (ret) =3D TREE_READONLY (expr);
+=09 TREE_SIDE_EFFECTS (ret) =3D TREE_SIDE_EFFECTS (expr);
+=09 TREE_THIS_VOLATILE (ret) =3D TREE_THIS_VOLATILE (expr);
+=09}
```
It's probably related to the following email tag:
Content-Transfer-Encoding: quoted-printable
The format is problematic when copying a patch.
Email example:
https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542053.html
Thank you,
Martin
Re: Not usable email content encoding
On 16/03/2020 13:45, Martin Liška wrote:
Hello.
I noticed some emails reaching gcc-patc...@gcc.gnu.org use the following
quoting:
```
case UNGT_EXPR:
case UNGE_EXPR:
case UNEQ_EXPR:
+ case MEM_REF:
/* Binary operations evaluating both arguments (increment and
=09 decrement are binary internally in GCC). */
orig_op0 =3D op0 =3D TREE_OPERAND (expr, 0);
@@ -435,6 +436,14 @@ c_fully_fold_internal (tree expr, bool i
=09 || TREE_CODE (TREE_TYPE (orig_op0)) =3D=3D FIXED_POINT_TYPE)
=09 && TREE_CODE (TREE_TYPE (orig_op1)) =3D=3D INTEGER_TYPE)
=09warn_for_div_by_zero (loc, op1);
+ if (code =3D=3D MEM_REF
+=09 && ret !=3D expr
+=09 && TREE_CODE (ret) =3D=3D MEM_REF)
+=09{
+=09 TREE_READONLY (ret) =3D TREE_READONLY (expr);
+=09 TREE_SIDE_EFFECTS (ret) =3D TREE_SIDE_EFFECTS (expr);
+=09 TREE_THIS_VOLATILE (ret) =3D TREE_THIS_VOLATILE (expr);
+=09}
```
It's probably related to the following email tag:
Content-Transfer-Encoding: quoted-printable
The format is problematic when copying a patch.
Email example:
https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542053.html
Thank you,
Martin
This isn't new. It's usually the sender that controls that, though it's
often automatic in their email client.
R.
Re: Not usable email content encoding
On 3/16/20 2:47 PM, Richard Earnshaw wrote: This isn't new. It's usually the sender that controls that, though it's often automatic in their email client. Jakub told me that he sees: Ten mail byl: Content-Type: text/plain; charset=us-ascii Content-Disposition: inline while the email reaching the mailing list has: Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Martin
Re: Not usable email content encoding
Hi - > I noticed some emails reaching gcc-patc...@gcc.gnu.org use the following > quoting: > It's probably related to the following email tag: > Content-Transfer-Encoding: quoted-printable This is not something that the mailing list system does. This content-transfer-encoding comes from the original email (as evident in the /var/lib/mailman/archives/private/gcc-patches.mbox/gcc-patches.mbox file). - FChE
Re: Not usable email content encoding
* Martin Liška: > It's probably related to the following email tag: > Content-Transfer-Encoding: quoted-printable > > The format is problematic when copying a patch. > Email example: > https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542053.html This is a known issue in the redhat.com email infrastructure.
Re: Not usable email content encoding
On Mon, 16 Mar 2020, Martin Liška wrote: > It's probably related to the following email tag: > Content-Transfer-Encoding: quoted-printable > > The format is problematic when copying a patch. > Email example: > https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542053.html I'm surprised it's an issue for you: normally your email client would transform quoted-printable and copying would do the right thing (i.e. select actual patch contents, without whitespace munging). Are you trying to copy from the raw message representation? Alexander
Re: Not usable email content encoding
On 3/16/20 2:54 PM, Alexander Monakov wrote: Are you trying to copy from the raw message representation? Exactly. Martin
Re: Not usable email content encoding
On Mon, 16 Mar 2020 at 14:13, Martin Liška wrote: > > On 3/16/20 2:54 PM, Alexander Monakov wrote: > > Are you trying to copy from the raw message representation? > > Exactly. That's never been reliable.
Compilation speed notes
Hi all; thanks for the help recently with sysroot compilers. I was able to get things building following advice from Joseph and Jonathan. I did want to mention that I noticed that GCC got non-trivially slower between my previous version (8.1) and this new version (9.3). I have a decently-sized C++14 or so code base, configured to use pre- compiled headers and unity builds (we pass 20 .cpp files to each invocation of the compiler). The system is GNU/Linux with 8 cores and 32G memory, on an older but still usable Intel Xeon E3-1270 3.5GHz and I use "make -j8" to build it. I built it 5 times in a row (although I can't believe caching would be an issue with code this size) with a git clean before each build, and no ccache or anything. The GCC 8.1 builds took about 14m35s. The GCC 9.3 builds took about 16m40s, so that's a drop of about 13%. I used the same binutils for both. Both compiles used the same compile options of course; in particular they used -ggdb3 -O2. I did discover that if I build GCC 9.3 with profiledbootstrap-lean, I gained back that loss and got the compile times back down to almost the same as GCC 8.1... but I assume that if I'd built GCC 8.1 with profiledbootstrap then that would have been even faster. Note I haven't tried to compare the performance of the resulting code (yet...) This is just looking at compile speed. Anyway I know that detail-free messages like this are more annoying than helpful and I don't mean to be annoying. If anyone wants to ask for more details or for me to do more testing I'm amenable. Otherwise this is just one data point to consider, or not. Thanks for the new release!
Integrating GCC with oss-fuzz
Hi! My name is David Korczynski and I have been doing some work on integrating fuzzing by way of OSS-Fuzz into the gcc project. This came out of fuzzing libiberty within the binutils project where we found several bugs within libiberty. However, the binutils owners are not working on libiberty so we dont get much results from reporting to them. I was wondering if we could set up a similar project, namely by integrating gcc to the OSS-Fuzz project and the errors found will then automatically be sent to gcc-b...@gcc.gnu.org? We can either add the fuzzers upstream to gcc or do as binutils and adding them to OSS-Fuzz. I have already done the work so we should be good to go with continuous fuzzing if you are interested! You can see the current binutils project here: https://github.com/google/oss-fuzz/tree/master/projects/binutils Here the binutils owners outline their interest in the project: https://github.com/google/oss-fuzz/pull/2617 Kind regards, David
Re: Fw: GSoC topic: Implement hot cold splitting at GIMPLE IR level
> > 2) ipa-split is very simplistic and only splits when there is no value >computed in header of function used in the tail. We should support > adding extra parameters for values computed and do more general SESE >outlining > Note that we do SESE outlining for openMP but this code is not > interfaced very generically to be easilly used by ipa-split. This sounds like a good GSoC project to work on. We could have a SESE/SEME based ipa-split, that could help with function splitting as well as openMP. >Original implementation of ipa-split was kind of "first cut" trying >to clean up interfaces to rest of the compiler and implement more >fancy features later. This never happened so there is certainly >space for imrovements here. I see ` TODO: We might support multiple return blocks. ' in ipa-split.c which could achieved once we have SEME based function splitting. >We also do all splitting before actual IPA optimization while it may >be more reasonable to identify potential split points and make IPA >optimization to decide on transforms (currently we rely on inliner >to inline back useless splits). If a student has enough bandwidth, we could allow them to work on this. Thanks for showing various places of improvement. I'd be happy to mentor on the above project. Please let me know your thoughts. Sorry I could not reply earlier because of various reasons. Best, -Aditya
Re: Fw: GSoC topic: Implement hot cold splitting at GIMPLE IR level
On Mon, Mar 16, 2020 at 11:11:14PM +, Aditya K via Gcc wrote: > > > > 2) ipa-split is very simplistic and only splits when there is no value > >computed in header of function used in the tail. We should support > > adding extra parameters for values computed and do more general SESE > >outlining > > Note that we do SESE outlining for openMP but this code is not > > interfaced very generically to be easilly used by ipa-split. > > This sounds like a good GSoC project to work on. We could have a SESE/SEME > based ipa-split, that > could help with function splitting as well as openMP. No, OpenMP region outlining needs to be done where it is done currently, ipa-split is way too late for that. Jakub
Mrb .....
Bu mesajın metin bölümüdür. Eski tip email müşteri kullanıcıları için gösterilir.
Attribute visibility
Hello,
In configuring gcc, there's a check to determine if the linker has support for
STV_Hidden. It determines support by checking for the date in the linker's
version string.
On the other hand, the version string for the linker is constructed without a
date, bfd/Makefile.am recipe for bfdver.h.
I am enclosing the lines I am referring to in this email.
It looks like there's a disconnect. This results in incorrectly identifying a
linker with support for STV_HIDDEN as one that doesn't.
This is from GCC 8.3.1 and Binutils 2.31.1. Is this known/intended?
Thanks,
Visda
gcc/configure
if test $in_tree_ld != yes ; then
ld_ver=`$gcc_cv_ld --version 2>/dev/null | sed 1q`
if echo "$ld_ver" | grep GNU > /dev/null; then
if test x"$ld_is_gold" = xyes; then
# GNU gold --version looks like this:
#
# GNU gold (GNU Binutils 2.21.51.20110225) 1.11
#
# We extract the binutils version which is more familiar and specific
# than the gold version.
ld_vers=`echo $ld_ver | sed -n \
-e 's,^[^)]*[ ]\([0-9][0-9]*\.[0-9][0-9]*[^)]*\)) .*$,\1,p'`
else
# GNU ld --version looks like this:
#
# GNU ld (GNU Binutils) 2.21.51.20110225
ld_vers=`echo $ld_ver | sed -n \
-e 's,^.*[ ]\([0-9][0-9]*\.[0-9][0-9]*.*\)$,\1,p'`
fi
ld_date=`echo $ld_ver | sed -n
's,^.*\([2-9][0-9][0-9][0-9]\)[-]*\([01][0-9]\)[-]*\([0-3][0-9]\).*$,\1\2\3,p'`
<---looking for a -MM-DD
ld_vers_major=`expr "$ld_vers" : '\([0-9]*\)'`
ld_vers_minor=`expr "$ld_vers" : '[0-9]*\.\([0-9]*\)'`
ld_vers_patch=`expr "$ld_vers" : '[0-9]*\.[0-9]*\.\([0-9]*\)'`
else
case "${target}" in
*-*-solaris2*)
# Solaris 2 ld -V output looks like this for a regular version:
...
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking linker for .hidden support"
>&5
$as_echo_n "checking linker for .hidden support... " >&6; }
if test "${gcc_cv_ld_hidden+set}" = set; then :
$as_echo_n "(cached) " >&6
else
if test $in_tree_ld = yes ; then
gcc_cv_ld_hidden=no
if test "$gcc_cv_gld_major_version" -eq 2 -a "$gcc_cv_gld_minor_version" -ge
13 -o "$gcc_cv_gld_major_version" -gt 2 \
&& test $in_tree_ld_is_elf = yes; then
gcc_cv_ld_hidden=yes
fi
else
gcc_cv_ld_hidden=yes
if test x"$ld_is_gold" = xyes; then
:
elif echo "$ld_ver" | grep GNU > /dev/null; then
case "${target}" in
mmix-knuth-mmixware)
# The linker emits by default mmo, not ELF, so "no" is appropriate.
gcc_cv_ld_hidden=no
;;
esac
if test 0"$ld_date" -lt 20020404; then <- linker released
before 20020404 doesn't support .hidden
if test -n "$ld_date"; then
# If there was date string, but was earlier than 2002-04-04, fail
gcc_cv_ld_hidden=no
bfd/Makefile.am
the default in development.sh is development=false
bfdver.h: $(srcdir)/version.h $(srcdir)/development.sh $(srcdir)/Makefile.in
@echo "creating $@"
@bfd_version=`echo "$(VERSION)" | $(SED) -e
's/\([^\.]*\)\.*\([^\.]*\)\.*\([^\.]*\)\.*\([^\.]*\)\.*\([^\.]*\).*/\1.00\2.00\3.00\4.00\5/'
-e 's/\([^\.]*\)\..*\(..\)\..*\(..\)\..*\(..\)\..*\(..\)$$/\1\2\3\4\5/'` ;\
bfd_version_string="\"$(VERSION)\"" ;\
bfd_soversion="$(VERSION)" ;\
bfd_version_package="\"$(PKGVERSION)\"" ;\
report_bugs_to="\"$(REPORT_BUGS_TO)\"" ;\
. $(srcdir)/development.sh ;\
if test "$$development" = true ; then \
bfd_version_date=`$(SED) -n -e 's/.*DATE //p' < $(srcdir)/version.h`
;\
bfd_version_string="\"$(VERSION).$${bfd_version_date}\"" ;\
bfd_soversion="$(VERSION).$${bfd_version_date}" ;\
fi ;\
$(SED) -e "s,@bfd_version@,$$bfd_version," \
-e "s,@bfd_version_string@,$$bfd_version_string," \
-e "s,@bfd_version_package@,$$bfd_version_package," \
-e "s,@report_bugs_to@,$$report_bugs_to," \
< $(srcdir)/version.h > $@; \
echo "$${bfd_soversion}" > libtool-soversion
Message undeliverable: Directorio Empresarial Mexico - Edicion 2020.
Your message did not reach some or all of the intended recipients. Sent: 9 Mar 2020 01:38:16 -0600 Subject: Directorio Empresarial Mexico - Edicion 2020. The following recipient(s) could not be reached: gcc@gcc.gnu.org Error Type: SMTP Remote server (8.43.85.97) issued an error. hMailServer sent: . Remote server replied: 550 5.7.1 Blocked by SpamAssassin hMailServer
