December 2019 - tor-commits - lists.torproject.org

[translation/tails-persistence-setup] https://gitweb.torproject.org/translation.git/commit/?h=tails-persistence-setup
by translation＠torproject.org 13 Dec '19

13 Dec '19

commit da31704fcc08e178b1331b941168c6a240a01352 Author: Translation commit bot <translation(a)torproject.org> Date: Fri Dec 13 13:50:52 2019 +0000 https://gitweb.torproject.org/translation.git/commit/?h=tails-persistence-s… --- ar/ar.po | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/ar/ar.po b/ar/ar.po index f4b29d752d..06316c9acb 100644 --- a/ar/ar.po +++ b/ar/ar.po @@ -4,6 +4,7 @@ # # Translators: # kraim <biskraim(a)gmail.com>, 2013 +# Ahmed Essam, 2019 # Ash <ali.shatrieh(a)gmail.com>, 2014 # ButterflyOfFire, 2018 # ButterflyOfFire, 2018 @@ -22,9 +23,9 @@ msgid "" msgstr "" "Project-Id-Version: Tor Project\n" "Report-Msgid-Bugs-To: Tails developers <tails(a)boum.org>\n" -"POT-Creation-Date: 2019-10-07 08:43+0200\n" -"PO-Revision-Date: 2019-10-07 13:48+0000\n" -"Last-Translator: erinm\n" +"POT-Creation-Date: 2019-10-21 09:06+0200\n" +"PO-Revision-Date: 2019-12-13 13:36+0000\n" +"Last-Translator: Ahmed Essam\n" "Language-Team: Arabic (http://www.transifex.com/otf/torproject/language/ar/)\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" @@ -96,7 +97,7 @@ msgstr "جهاز %s غير ضوئي" #: ../lib/Tails/Persistence/Setup.pm:444 #, perl-format msgid "Device %s was not created using a USB image or Tails Installer." -msgstr "" +msgstr "الجهاز %s لم يتم انشاؤه باستخدام نسخة USB او مثبت تيلز." #: ../lib/Tails/Persistence/Setup.pm:688 msgid "Persistence wizard - Finished"

1 0

[translation/tails-iuk] https://gitweb.torproject.org/translation.git/commit/?h=tails-iuk
by translation＠torproject.org 13 Dec '19

13 Dec '19

commit 3c99e031cb09a4f427a723252599d61b39f85ccd Author: Translation commit bot <translation(a)torproject.org> Date: Fri Dec 13 13:49:37 2019 +0000 https://gitweb.torproject.org/translation.git/commit/?h=tails-iuk --- ar.po | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/ar.po b/ar.po index cb46959f85..6bebc71c12 100644 --- a/ar.po +++ b/ar.po @@ -4,6 +4,7 @@ # # Translators: # skygazer <abudayeh.saleh(a)gmail.com>, 2014 +# Ahmed Essam, 2019 # Amr Syria <3amrx(a)hmamail.com>, 2015 # Arwa, 2014 # emad0d <emad.moussa95(a)gmail.com>, 2016 @@ -19,8 +20,8 @@ msgstr "" "Project-Id-Version: Tor Project\n" "Report-Msgid-Bugs-To: Tails developers <tails(a)boum.org>\n" "POT-Creation-Date: 2019-11-28 16:51+0100\n" -"PO-Revision-Date: 2019-11-29 03:10+0000\n" -"Last-Translator: carolyn <carolyn(a)anhalt.org>\n" +"PO-Revision-Date: 2019-12-13 13:47+0000\n" +"Last-Translator: Ahmed Essam\n" "Language-Team: Arabic (http://www.transifex.com/otf/torproject/language/ar/)\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" @@ -54,7 +55,7 @@ msgstr "التحديث التلقائي غير متوفر في موقعنا له #: ../lib/Tails/IUK/Frontend.pm:242 msgid "your device was not created using a USB image or Tails Installer" -msgstr "" +msgstr "جهازك لم يتم انشاؤه باستخدام نسخة USB أو مثبت تيلز" #: ../lib/Tails/IUK/Frontend.pm:247 msgid "Tails was started from a DVD or a read-only device" @@ -142,7 +143,7 @@ msgid "" "It is not possible to automatically upgrade your device to this new version: %{explanation}s.\n" "\n" "To learn how to do a manual upgrade, go to https://tails.boum.org/doc/upgrade/#manual" -msgstr "" +msgstr "<b> يجب عليك أن تطور الإصدار بطريقة يدوية إلى %{name}s %{version}s.</b>\n\nلمزيد من المعلومات عن هذا الإصدار الجديد، اذهب إلى %{details_url}s\n\nلبس من الممكن تطوير جهازك اوتوماتيكيا إلى الإصدار الجديد: %{explanation}s.\n\nلتتعلم كيف تعمل تطويرا يدويا، اذهب إلى https://tails.boum.org/doc/upgrade/#manual" #: ../lib/Tails/IUK/Frontend.pm:412 msgid "New version available"

1 0

[community/master] one sentence per line, needed for localization
by emmapeel＠torproject.org 13 Dec '19

13 Dec '19

commit 07fae35ad17d630b3e0e035fbc2aeacac9e00c0e Author: emma peel <emma.peel(a)riseup.net> Date: Wed Dec 11 10:52:54 2019 +0100 one sentence per line, needed for localization --- .../eff-tor-legal-faq/contents.lr | 62 ++++++++++++++++------ .../relays-requirements/contents.lr | 2 +- content/training/best-practices/contents.lr | 3 +- 3 files changed, 49 insertions(+), 18 deletions(-) diff --git a/content/relay-operations/community-resources/eff-tor-legal-faq/contents.lr b/content/relay-operations/community-resources/eff-tor-legal-faq/contents.lr index acc857c..385a255 100644 --- a/content/relay-operations/community-resources/eff-tor-legal-faq/contents.lr +++ b/content/relay-operations/community-resources/eff-tor-legal-faq/contents.lr @@ -6,7 +6,10 @@ title: The Legal FAQ for Tor Relay Operators --- body: -NOTE: This FAQ is for informational purposes only and does not constitute legal advice. Our aim is to provide a general description of the legal issues surrounding Tor in the United States. Different factual situations and different legal jurisdictions will result in different answers to a number of questions. Therefore, please do not act on this information alone; if you have any specific legal problems, issues, or questions, seek a complete review of your situation with a lawyer licensed to practice in your jurisdiction. +NOTE: This FAQ is for informational purposes only and does not constitute legal advice. +Our aim is to provide a general description of the legal issues surrounding Tor in the United States. +Different factual situations and different legal jurisdictions will result in different answers to a number of questions. +Therefore, please do not act on this information alone; if you have any specific legal problems, issues, or questions, seek a complete review of your situation with a lawyer licensed to practice in your jurisdiction. Also, if you received this document from anywhere besides the EFF web site or https://community.torproject.org/relay/community-resources/eff-tor-legal-faq, it may be out of date. Follow the link to get the latest version. @@ -24,25 +27,36 @@ Got a DMCA notice? Check out our [sample response letter](/relay/community-resou ### Can EFF promise that I won't get in trouble for running a Tor relay? -**No**. All new technologies create legal uncertainties, and Tor is no exception. We cannot guarantee that you will never face any legal liability as a result of running a Tor relay. However, EFF believes so strongly that those running Tor relays shouldn't be liable for traffic that passes through the relay that we're running our own middle relay. +**No**. All new technologies create legal uncertainties, and Tor is no exception. +We cannot guarantee that you will never face any legal liability as a result of running a Tor relay. +However, EFF believes so strongly that those running Tor relays shouldn't be liable for traffic that passes through the relay that we're running our own middle relay. ### Will EFF represent me if I get in trouble for running a Tor relay? -**Maybe**. While EFF cannot promise legal representation for all Tor relay operators, it will assist relay operators in assessing the situation and will try to locate qualified legal counsel when necessary. Inquiries to EFF for the purpose of securing legal representation or referrals should be directed to our intake coordinator by sending an email to info(a)eff.org . Such inquiries will be kept confidential subject to the limits of the attorney/client privilege. Note that although EFF cannot practice law outside of the United States, it will still try to assist non-U.S. relay operators in finding local representation. +**Maybe**. While EFF cannot promise legal representation for all Tor relay operators, it will assist relay operators in assessing the situation and will try to locate qualified legal counsel when necessary. +Inquiries to EFF for the purpose of securing legal representation or referrals should be directed to our intake coordinator by sending an email to info at eff.org. +Such inquiries will be kept confidential subject to the limits of the attorney/client privilege. +Note that although EFF cannot practice law outside of the United States, it will still try to assist non-U.S. relay operators in finding local representation. ### Should I contact the Tor developers when I have legal questions about Tor or to inform them if I suspect Tor is being used for illegal purposes? -**No**. Tor's developers are available to answer technical questions, but they are not lawyers and cannot give legal advice. Nor do they have any ability to prevent illegal activity that may occur through Tor relays. Furthermore, your communications with Tor's developers are not protected by any legal privilege, so law enforcement or civil litigants could subpoena and obtain any information you give to them. +**No**. Tor's developers are available to answer technical questions, but they are not lawyers and cannot give legal advice. Nor do they have any ability to prevent illegal activity that may occur through Tor relays. +Furthermore, your communications with Tor's developers are not protected by any legal privilege, so law enforcement or civil litigants could subpoena and obtain any information you give to them. You can contact info(a)eff.org if you face a specific legal issue. We will try to assist you, but given EFF's small size, we cannot guarantee that we can help everyone. ### Do Tor's core developers make any promises about the trustworthiness or reliability of Tor relays that are listed in their directory? -**No**. Although the developers attempt to verify that Tor relays listed in the directory maintained by the core developers are stable and have adequate bandwidth, neither they nor EFF can guarantee the personal trustworthiness or reliability of the individuals who run those relays. Tor's core developers further reserve the right to refuse a Tor relay operator's request to be listed in their directory or to remove any relay from their directory for any reason. +**No**. Although the developers attempt to verify that Tor relays listed in the directory maintained by the core developers are stable and have adequate bandwidth, neither they nor EFF can guarantee the personal trustworthiness or reliability of the individuals who run those relays. +Tor's core developers further reserve the right to refuse a Tor relay operator's request to be listed in their directory or to remove any relay from their directory for any reason. ## Exit Relays -Exit relays raise special concerns because the traffic that exits from them can be traced back to the relay's IP address. While we believe that running an exit relay is legal, it is statistically likely that an exit relay will at some point be used for illegal purposes, which may attract the attention of private litigants or law enforcement. An exit relay may forward traffic that is considered unlawful, and that traffic may be attributed to the operator of a relay. If you are not willing to deal with that risk, a bridge or middle relay may be a better fit for you. These relays do not directly forward traffic to the Internet and so can't be easily mistaken for the origin of allegedly unlawful content. +Exit relays raise special concerns because the traffic that exits from them can be traced back to the relay's IP address. +While we believe that running an exit relay is legal, it is statistically likely that an exit relay will at some point be used for illegal purposes, which may attract the attention of private litigants or law enforcement. +An exit relay may forward traffic that is considered unlawful, and that traffic may be attributed to the operator of a relay. +If you are not willing to deal with that risk, a bridge or middle relay may be a better fit for you. +These relays do not directly forward traffic to the Internet and so can't be easily mistaken for the origin of allegedly unlawful content. The Tor Project's blog has some excellent [recommendations](https://blog.torproject.org/blog/tips-running-exit-node) for running an exit with as little risk as possible. We suggest that you review their advice before setting up an exit relay. @@ -56,27 +70,38 @@ Of course, you should avoid keeping any sensitive or personal information on the ### Should I tell my ISP that I'm running an exit relay? -**Yes**. Make sure you have a Tor-friendly ISP that knows you're running an exit relay and supports you in that goal. This will help ensure that your Internet access isn't cut off due to abuse complaints. The Tor community maintains a list of ISPs that are particularly Tor-savvy, as well as ones that aren't. +**Yes**. Make sure you have a Tor-friendly ISP that knows you're running an exit relay and supports you in that goal. +This will help ensure that your Internet access isn't cut off due to abuse complaints. +The Tor community maintains a list of ISPs that are particularly Tor-savvy, as well as ones that aren't. ### Is it a good idea to let others know that I'm running an exit relay? -**Yes**. Be as transparent as possible about the fact that you're running an exit relay. If your exit traffic draws the attention of the government or disgruntled private party, you want them to figure out quickly and easily that you are part of the Tor network and not responsible for the content. This could mean the difference between having your computer seized by law enforcement and being left alone. +**Yes**. Be as transparent as possible about the fact that you're running an exit relay. +If your exit traffic draws the attention of the government or disgruntled private party, you want them to figure out quickly and easily that you are part of the Tor network and not responsible for the content. +This could mean the difference between having your computer seized by law enforcement and being left alone. The Tor Project [suggests](https://blog.torproject.org/blog/tips-running-exit-node) the following ways to let others know that you're running an exit relay: * Set up a reverse DNS name for the IP address that makes clear that the computer is an exit relay. * Set up a notice like [this](https://blog.torproject.org/blog/tips-running-exit-node) to explain that you're running an exit relay that's part of the Tor network. - * If possible, get an [ARIN](https://www.arin.net/) registration for your exit relay that displays contact information for you, not your ISP. This way, you'll receive any abuse complaints and can respond to them directly. Otherwise, try to ensure that your ISP forwards abuse complaints that it receives to you. + * If possible, get an [ARIN](https://www.arin.net/) registration for your exit relay that displays contact information for you, not your ISP. + This way, you'll receive any abuse complaints and can respond to them directly. Otherwise, try to ensure that your ISP forwards abuse complaints that it receives to you. ### Should I snoop on the plaintext traffic that exits through my Tor relay? -**No**. You may be technically capable of modifying the Tor source code or installing additional software to monitor or log plaintext that exits your relay. However, Tor relay operators in the United States can possibly create civil and even criminal liability for themselves under state or federal wiretap laws if they monitor, log, or disclose Tor users' communications, while non-U.S. operators may be subject to similar laws. Do not examine anyone's communications without first talking to a lawyer. +**No**. You may be technically capable of modifying the Tor source code or installing additional software to monitor or log plaintext that exits your relay. +However, Tor relay operators in the United States can possibly create civil and even criminal liability for themselves under state or federal wiretap laws if they monitor, log, or disclose Tor users' communications, while non-U.S. operators may be subject to similar laws. +Do not examine anyone's communications without first talking to a lawyer. ### If I receive a subpoena or other information request from law enforcement or anyone else related to my Tor relay, what should I do? -**Educate them about Tor**. In most instances, properly configured Tor relays will have no useful data for inquiring parties, and you should feel free to educate them on this point. To the extent you do maintain logs, however, you should not disclose them to any third party without first consulting a lawyer. In the United States, such a disclosure may violate the Electronic Communications Privacy Act, and relay operators outside of the United States may be subject to similar data protection laws. +**Educate them about Tor**. In most instances, properly configured Tor relays will have no useful data for inquiring parties, and you should feel free to educate them on this point. +To the extent you do maintain logs, however, you should not disclose them to any third party without first consulting a lawyer. +In the United States, such a disclosure may violate the Electronic Communications Privacy Act, and relay operators outside of the United States may be subject to similar data protection laws. -You may receive legal inquiries where you are prohibited by law from telling anyone about the request. We believe that, at least in the United States, such gag orders do not prevent you from talking to a lawyer, including calling a lawyer to find representation. Inquiries to EFF for the purpose of securing legal representation should be directed to our intake coordinator (info at eff.org) Such inquiries will be kept confidential subject to the limits of the attorney/client privilege. +You may receive legal inquiries where you are prohibited by law from telling anyone about the request. We believe that, at least in the United States, such gag orders do not prevent you from talking to a lawyer, including calling a lawyer to find representation. +Inquiries to EFF for the purpose of securing legal representation should be directed to our intake coordinator (info at eff.org) +Such inquiries will be kept confidential subject to the limits of the attorney/client privilege. For more information about responding to abuse complaints and other inquiries, check out the [Tor Abuse FAQ](https://2019.www.torproject.org/docs/faq-abuse.html.en) and the collection of [abuse response templates](/tor-abuse-templates/) on the Tor Project's website. @@ -84,13 +109,18 @@ For information on what to do if law enforcement seeks access to your digital de ### My ISP, university, etc. just sent me a DMCA notice. What should I do? -EFF has written a [short template](tor-dmca-response) to help you write a response to your ISP, university, etc., to let them know about the details of the Digital Millennium Copyright Act's safe harbor, and how Tor fits in. Note that template only refers to U.S. jurisdictions, and is intended only to address copyright complaints that are based on a relay of allegedly infringing material through the Tor node. +EFF has written a [short template](tor-dmca-response) to help you write a response to your ISP, university, etc., to let them know about the details of the Digital Millennium Copyright Act's safe harbor, and how Tor fits in. +Note that template only refers to U.S. jurisdictions, and is intended only to address copyright complaints that are based on a relay of allegedly infringing material through the Tor node. -If you like, you should consider submitting a copy of your notice to [Chilling Effects](https://www.chillingeffects.org/). This will help us recognize trends and issues that the lawyers might want to focus on. Chilling Effects encourages submissions from people outside the United States too. +If you like, you should consider submitting a copy of your notice to [Chilling Effects](https://www.chillingeffects.org/). +This will help us recognize trends and issues that the lawyers might want to focus on. Chilling Effects encourages submissions from people outside the United States too. -EFF believes that Tor relays should be protected from copyright liability for the acts of their users because a Tor relay operator can raise an immunity defense under the DMCA as well as defenses under copyright's secondary liability doctrines. However, no court has yet addressed these issues in the context of Tor itself. If you are uncomfortable with this uncertainty, you may consider using a reduced exit policy (such as the default policy suggested by the Tor Project) to try to minimize traffic types that are often targeted in copyright complaints. +EFF believes that Tor relays should be protected from copyright liability for the acts of their users because a Tor relay operator can raise an immunity defense under the DMCA as well as defenses under copyright's secondary liability doctrines. +However, no court has yet addressed these issues in the context of Tor itself. +If you are uncomfortable with this uncertainty, you may consider using a reduced exit policy (such as the default policy suggested by the Tor Project) to try to minimize traffic types that are often targeted in copyright complaints. -If you are a Tor relay operator willing to stand up and help set a clear legal precedent establishing that merely running a relay does not create copyright liability for either operators or their bandwidth providers, EFF is interested in hearing from you. Read more [here](https://lists.torproject.org/pipermail/tor-talk/2005-October/016301.h… about being EFF's test case. +If you are a Tor relay operator willing to stand up and help set a clear legal precedent establishing that merely running a relay does not create copyright liability for either operators or their bandwidth providers, EFF is interested in hearing from you. +Read more [here](https://lists.torproject.org/pipermail/tor-talk/2005-October/016301.h… about being EFF's test case. --- html: two-columns-page.html diff --git a/content/relay-operations/relays-requirements/contents.lr b/content/relay-operations/relays-requirements/contents.lr index 0c1808e..5ad16cc 100644 --- a/content/relay-operations/relays-requirements/contents.lr +++ b/content/relay-operations/relays-requirements/contents.lr @@ -8,7 +8,7 @@ _template: layout.html --- title: Relay requirements --- -subtitle: Requirements for Tor relays depend on the type of relay and the bandwidth they provide. Learn more about specific relay requirements. +subtitle: Requirements for Tor relays depend on the type of relay and the bandwidth they provide. Learn more about specific relay requirements. --- key: 2 --- diff --git a/content/training/best-practices/contents.lr b/content/training/best-practices/contents.lr index 19c7946..91bb2dd 100644 --- a/content/training/best-practices/contents.lr +++ b/content/training/best-practices/contents.lr @@ -48,7 +48,8 @@ Once you've answered those questions, you're ready to plan your training! This includes downloads and PDFs of handouts. You'll share this link list on a whiteboard or project it at the training. 6. Determine how you'll do hands-on assistance at your training. - Will you be able to handle this alone? Or will you require partners? If you need more help, make sure the partners you're bringing in are aware of the safety needs of the community, and communicate with your contacts in the community to make sure they're okay with you bringing in additional trainers. + Will you be able to handle this alone? Or will you require partners? + If you need more help, make sure the partners you're bringing in are aware of the safety needs of the community, and communicate with your contacts in the community to make sure they're okay with you bringing in additional trainers. 7. Make sure your presentation is up-to-date (both information and screenshots) and save your presentation in two file formats -- for example, odp and pdf -- and on at least one additional device -- for example, on your computer and on a USB stick. 8. Decide how you will facilitate a safer space. We recommend using the [Tor Code of Conduct](/training/code-of-conduct/).

1 0

[translation/tbmanual-contentspot] https://gitweb.torproject.org/translation.git/commit/?h=tbmanual-contentspot
by translation＠torproject.org 13 Dec '19

13 Dec '19

commit 26e39af384ee7d8e9895a62d250852a983e5075d Author: Translation commit bot <translation(a)torproject.org> Date: Fri Dec 13 13:21:19 2019 +0000 https://gitweb.torproject.org/translation.git/commit/?h=tbmanual-contentspot --- contents+ru.po | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/contents+ru.po b/contents+ru.po index d25896d9fb..05057a38b4 100644 --- a/contents+ru.po +++ b/contents+ru.po @@ -7,9 +7,9 @@ # erinm, 2019 # Мария Романенко <mary.romanenko(a)gmail.com>, 2019 # IvanLykov <chabib(a)list.ru>, 2019 -# diana azaryan <dianazryn(a)gmail.com>, 2019 # Sergey Smirnov <cj75300(a)gmail.com>, 2019 # Emma Peel, 2019 +# diana azaryan <dianazryn(a)gmail.com>, 2019 # msgid "" msgstr "" @@ -17,7 +17,7 @@ msgstr "" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2019-11-29 10:58+CET\n" "PO-Revision-Date: 2018-11-14 12:31+0000\n" -"Last-Translator: Emma Peel, 2019\n" +"Last-Translator: diana azaryan <dianazryn(a)gmail.com>, 2019\n" "Language-Team: Russian (https://www.transifex.com/otf/teams/1519/ru/)\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" @@ -546,7 +546,7 @@ msgstr "" #: https//tb-manual.torproject.org/running-tor-browser/ #: (content/running-tor-browser/contents+en.lrtopic.body) msgid "### CONNECT" -msgstr "" +msgstr "### СОЕДИНИТЬСЯ" #: https//tb-manual.torproject.org/running-tor-browser/ #: (content/running-tor-browser/contents+en.lrtopic.body)

1 0

[translation/tbmanual-contentspot] https://gitweb.torproject.org/translation.git/commit/?h=tbmanual-contentspot
by translation＠torproject.org 13 Dec '19

13 Dec '19

commit a94694fce00a9d7cea0b06e8dec7b4831e16a02d Author: Translation commit bot <translation(a)torproject.org> Date: Fri Dec 13 11:51:10 2019 +0000 https://gitweb.torproject.org/translation.git/commit/?h=tbmanual-contentspot --- contents+ar.po | 4 ++-- contents+ro.po | 6 +++--- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/contents+ar.po b/contents+ar.po index 50fa48ad1f..51c749c49d 100644 --- a/contents+ar.po +++ b/contents+ar.po @@ -1339,7 +1339,7 @@ msgid "" "connections)." msgstr "" "*جميع الحركات المروريّة بين مستخدمي Tor و خدمات البصلة مشفّرة من طرف لطرف، " -"لذا لا تقلقوا بشأن [الاتصال عبر HTTPS](ar/secure-connections/)." +"لذا لا تقلقوا بشأن [الاتصال عبر HTTPS](/ar/secure-connections/)." #: https//tb-manual.torproject.org/onion-services/ #: (content/onion-services/contents+en.lrtopic.body) @@ -1705,7 +1705,7 @@ msgid "" "(see the [Uninstalling](/uninstalling) section for more information)." msgstr "" "قوموا بإزالة متصفّح تور (Tor) من نظامكم عن طريق حذف المجلّد الذي يحتويه " -"(انظروا إلى قسم [إزالة التثبيت](ar/uninstalling/) للمزيد من المعلومات.) " +"(انظروا إلى قسم [إزالة التثبيت](/ar/uninstalling/) للمزيد من المعلومات.) " #: https//tb-manual.torproject.org/updating/ #: (content/updating/contents+en.lrtopic.body) diff --git a/contents+ro.po b/contents+ro.po index aa1d8b6f46..6799180577 100644 --- a/contents+ro.po +++ b/contents+ro.po @@ -1653,9 +1653,9 @@ msgid "" " fonts and math symbols are disabled; audio and video (HTML5 media) are " "click-to-play." msgstr "" -"* JavaScript este dezactivat pe toate site-urile non- [HTTPS](/ro/conexiuni " -"sigure); unele fonturi și simboluri matematice sunt dezactivate; audio și " -"video (HTML5 media) sunt clicuri pentru a reda." +"* JavaScript este dezactivat pe toate site-urile non- [HTTPS](/ro/secure-" +"connections); unele fonturi și simboluri matematice sunt dezactivate; audio " +"și video (HTML5 media) sunt clicuri pentru a reda." #: https//tb-manual.torproject.org/security-settings/ #: (content/security-settings/contents+en.lrtopic.body)

1 0

[tor-browser-build/master] Bug 32053: Fix LLVM reproducibility issues
by boklm＠torproject.org 13 Dec '19

13 Dec '19

commit 5cafc16c0e5af59f95f685025b487b306c10bd01 Author: Georg Koppen <gk(a)torproject.org> Date: Fri Dec 6 13:43:24 2019 +0000 Bug 32053: Fix LLVM reproducibility issues This patch contains two backports for reproducibility issues found and fixed in LLVM's optimization code. The patch from bug 42574 might not be necessary in our context as I only witnessed problems when compiling Stylo with an older Rust (1.32.0) and then omptimizing with LLVM 8. However, it's hard to exclude any mismatching builds we encountered so far from being affected by that issue, so I think it is safer to backport that patch as well. Bug 43909 is an issue we and Mozilla definitely hit and very likely responsible for at least the vast majority of different builds we got over the course of the last weeks and months. Many thanks to Alex Crichton for the invaluable help in tracking this issue down. --- projects/clang/42574.patch | 236 ++++++++++++++++++++++++++++++++++++++++++ projects/clang/43909.patch | 252 +++++++++++++++++++++++++++++++++++++++++++++ projects/clang/build | 4 + projects/clang/config | 2 + projects/rust/42574.patch | 236 ++++++++++++++++++++++++++++++++++++++++++ projects/rust/43909.patch | 252 +++++++++++++++++++++++++++++++++++++++++++++ projects/rust/build | 7 ++ projects/rust/config | 2 + 8 files changed, 991 insertions(+) diff --git a/projects/clang/42574.patch b/projects/clang/42574.patch new file mode 100644 index 0000000..285d254 --- /dev/null +++ b/projects/clang/42574.patch @@ -0,0 +1,236 @@ +From 3757213db371dcea53cae357cf9c56d1b0604f98 Mon Sep 17 00:00:00 2001 +From: Alina Sbirlea <asbirlea(a)google.com> +Date: Fri, 12 Jul 2019 22:30:30 +0000 +Subject: [PATCH] [MemorySSA] Use SetVector to avoid nondeterminism. + +Summary: +Use a SetVector for DeadBlockSet. +Resolves PR42574. + +Reviewers: george.burgess.iv, uabelho, dblaikie + +Subscribers: jlebar, Prazek, mgrang, llvm-commits + +Tags: #llvm + +Differential Revision: https://reviews.llvm.org/D64601 + +llvm-svn: 365970 + +diff --git a/llvm/include/llvm/Analysis/MemorySSAUpdater.h b/llvm/include/llvm/Analysis/MemorySSAUpdater.h +index 169d5bd9fa8..276620bd445 100644 +--- a/llvm/include/llvm/Analysis/MemorySSAUpdater.h ++++ b/llvm/include/llvm/Analysis/MemorySSAUpdater.h +@@ -32,6 +32,7 @@ + #ifndef LLVM_ANALYSIS_MEMORYSSAUPDATER_H + #define LLVM_ANALYSIS_MEMORYSSAUPDATER_H + ++#include "llvm/ADT/SetVector.h" + #include "llvm/ADT/SmallPtrSet.h" + #include "llvm/ADT/SmallSet.h" + #include "llvm/ADT/SmallVector.h" +@@ -239,7 +240,7 @@ public: + /// Deleted blocks still have successor info, but their predecessor edges and + /// Phi nodes may already be updated. Instructions in DeadBlocks should be + /// deleted after this call. +- void removeBlocks(const SmallPtrSetImpl<BasicBlock *> &DeadBlocks); ++ void removeBlocks(const SmallSetVector<BasicBlock *, 8> &DeadBlocks); + + /// Get handle on MemorySSA. + MemorySSA* getMemorySSA() const { return MSSA; } +diff --git a/llvm/lib/Analysis/MemorySSAUpdater.cpp b/llvm/lib/Analysis/MemorySSAUpdater.cpp +index 6c817d20368..a6c7142a697 100644 +--- a/llvm/lib/Analysis/MemorySSAUpdater.cpp ++++ b/llvm/lib/Analysis/MemorySSAUpdater.cpp +@@ -1101,7 +1101,7 @@ void MemorySSAUpdater::removeMemoryAccess(MemoryAccess *MA) { + } + + void MemorySSAUpdater::removeBlocks( +- const SmallPtrSetImpl<BasicBlock *> &DeadBlocks) { ++ const SmallSetVector<BasicBlock *, 8> &DeadBlocks) { + // First delete all uses of BB in MemoryPhis. + for (BasicBlock *BB : DeadBlocks) { + Instruction *TI = BB->getTerminator(); +diff --git a/llvm/lib/Transforms/Scalar/LoopSimplifyCFG.cpp b/llvm/lib/Transforms/Scalar/LoopSimplifyCFG.cpp +index 2e5927f9a06..f464df26a02 100644 +--- a/llvm/lib/Transforms/Scalar/LoopSimplifyCFG.cpp ++++ b/llvm/lib/Transforms/Scalar/LoopSimplifyCFG.cpp +@@ -388,8 +388,8 @@ private: + void deleteDeadLoopBlocks() { + DomTreeUpdater DTU(DT, DomTreeUpdater::UpdateStrategy::Eager); + if (MSSAU) { +- SmallPtrSet<BasicBlock *, 8> DeadLoopBlocksSet(DeadLoopBlocks.begin(), +- DeadLoopBlocks.end()); ++ SmallSetVector<BasicBlock *, 8> DeadLoopBlocksSet(DeadLoopBlocks.begin(), ++ DeadLoopBlocks.end()); + MSSAU->removeBlocks(DeadLoopBlocksSet); + } + for (auto *BB : DeadLoopBlocks) { +diff --git a/llvm/lib/Transforms/Scalar/SimpleLoopUnswitch.cpp b/llvm/lib/Transforms/Scalar/SimpleLoopUnswitch.cpp +index 5a67178cef3..814cf814989 100644 +--- a/llvm/lib/Transforms/Scalar/SimpleLoopUnswitch.cpp ++++ b/llvm/lib/Transforms/Scalar/SimpleLoopUnswitch.cpp +@@ -1436,8 +1436,8 @@ deleteDeadClonedBlocks(Loop &L, ArrayRef<BasicBlock *> ExitBlocks, + + // Remove all MemorySSA in the dead blocks + if (MSSAU) { +- SmallPtrSet<BasicBlock *, 16> DeadBlockSet(DeadBlocks.begin(), +- DeadBlocks.end()); ++ SmallSetVector<BasicBlock *, 8> DeadBlockSet(DeadBlocks.begin(), ++ DeadBlocks.end()); + MSSAU->removeBlocks(DeadBlockSet); + } + +@@ -1455,7 +1455,7 @@ static void deleteDeadBlocksFromLoop(Loop &L, + MemorySSAUpdater *MSSAU) { + // Find all the dead blocks tied to this loop, and remove them from their + // successors. +- SmallPtrSet<BasicBlock *, 16> DeadBlockSet; ++ SmallSetVector<BasicBlock *, 8> DeadBlockSet; + + // Start with loop/exit blocks and get a transitive closure of reachable dead + // blocks. +diff --git a/llvm/lib/Transforms/Utils/Local.cpp b/llvm/lib/Transforms/Utils/Local.cpp +index 499e611acb5..83dabcd7952 100644 +--- a/llvm/lib/Transforms/Utils/Local.cpp ++++ b/llvm/lib/Transforms/Utils/Local.cpp +@@ -2211,7 +2211,7 @@ bool llvm::removeUnreachableBlocks(Function &F, LazyValueInfo *LVI, + assert(Reachable.size() < F.size()); + NumRemoved += F.size()-Reachable.size(); + +- SmallPtrSet<BasicBlock *, 16> DeadBlockSet; ++ SmallSetVector<BasicBlock *, 8> DeadBlockSet; + for (Function::iterator I = ++F.begin(), E = F.end(); I != E; ++I) { + auto *BB = &*I; + if (Reachable.count(BB)) +diff --git a/llvm/test/Analysis/MemorySSA/nondeterminism.ll b/llvm/test/Analysis/MemorySSA/nondeterminism.ll +new file mode 100644 +index 00000000000..0bb3df30b58 +--- /dev/null ++++ b/llvm/test/Analysis/MemorySSA/nondeterminism.ll +@@ -0,0 +1,122 @@ ++; RUN: opt -simplifycfg -enable-mssa-loop-dependency -S --preserve-ll-uselistorder %s | FileCheck %s ++; REQUIRES: x86-registered-target ++; CHECK-LABEL: @n ++; CHECK: uselistorder i16 0, { 3, 2, 4, 1, 5, 0, 6 } ++ ++; Note: test was added in an effort to ensure determinism when updating memoryssa. See PR42574. ++; If the uselistorder check becomes no longer relevant, the test can be disabled or removed. ++ ++%rec9 = type { i16, i32, i32 } ++ ++@a = global [1 x [1 x %rec9]] zeroinitializer ++ ++define i16 @n() { ++ br label %..split_crit_edge ++ ++..split_crit_edge: ; preds = %0 ++ br label %.split ++ ++bb4.us4: ; preds = %bb2.split.us32, %bb6.us28 ++ %i.4.01.us5 = phi i16 [ %_tmp49.us30, %bb6.us28 ] ++ br label %g.exit4.us21 ++ ++bb1.i.us14: ; preds = %bb4.us4 ++ br label %g.exit4.us21 ++ ++g.exit4.us21: ; preds = %bb1.i.us14, %g.exit4.critedge.us9 ++ %i.4.02.us22 = phi i16 [ %i.4.01.us5, %bb4.us4 ], [ %i.4.01.us5, %bb1.i.us14 ] ++ br label %bb6.us28 ++ ++bb5.us26: ; preds = %g.exit4.us21 ++ br label %bb6.us28 ++ ++bb6.us28: ; preds = %bb5.us26, %g.exit4.us21 ++ %i.4.03.us29 = phi i16 [ %i.4.02.us22, %bb5.us26 ], [ %i.4.02.us22, %g.exit4.us21 ] ++ %_tmp49.us30 = add nuw nsw i16 %i.4.03.us29, 1 ++ br label %bb4.us4 ++ ++bb4.us.us: ; preds = %bb2.split.us.us, %bb6.us.us ++ %i.4.01.us.us = phi i16 [ %_tmp49.us.us, %bb6.us.us ] ++ br label %bb1.i.us.us ++ ++bb1.i.us.us: ; preds = %bb4.us.us ++ br label %g.exit4.us.us ++ ++g.exit4.us.us: ; preds = %bb1.i.us.us, %g.exit4.critedge.us.us ++ %i.4.02.us.us = phi i16 [ %i.4.01.us.us, %bb1.i.us.us ] ++ br label %bb5.us.us ++ ++bb5.us.us: ; preds = %g.exit4.us.us ++ br label %bb6.us.us ++ ++bb6.us.us: ; preds = %bb5.us.us, %g.exit4.us.us ++ %i.4.03.us.us = phi i16 [ %i.4.02.us.us, %bb5.us.us ] ++ %_tmp49.us.us = add nuw nsw i16 %i.4.03.us.us, 1 ++ br label %bb4.us.us ++ ++ ++.split: ; preds = %..split_crit_edge ++ br label %bb2 ++ ++bb2: ; preds = %.split, %bb7 ++ %h.3.0 = phi i16 [ undef, %.split ], [ %_tmp53, %bb7 ] ++ br label %bb2.bb2.split_crit_edge ++ ++bb2.bb2.split_crit_edge: ; preds = %bb2 ++ br label %bb2.split ++ ++bb2.split.us: ; preds = %bb2 ++ br label %bb4.us ++ ++bb4.us: ; preds = %bb6.us, %bb2.split.us ++ %i.4.01.us = phi i16 [ 0, %bb2.split.us ] ++ br label %bb1.i.us ++ ++g.exit4.critedge.us: ; preds = %bb4.us ++ br label %g.exit4.us ++ ++bb1.i.us: ; preds = %bb4.us ++ br label %g.exit4.us ++ ++g.exit4.us: ; preds = %bb1.i.us, %g.exit4.critedge.us ++ %i.4.02.us = phi i16 [ %i.4.01.us, %g.exit4.critedge.us ], [ %i.4.01.us, %bb1.i.us ] ++ br label %bb5.us ++ ++bb5.us: ; preds = %g.exit4.us ++ br label %bb7 ++ ++bb2.split: ; preds = %bb2.bb2.split_crit_edge ++ br label %bb4 ++ ++bb4: ; preds = %bb2.split, %bb6 ++ %i.4.01 = phi i16 [ 0, %bb2.split ] ++ %_tmp16 = getelementptr [1 x [1 x %rec9]], [1 x [1 x %rec9]]* @a, i16 0, i16 %h.3.0, i16 %i.4.01, i32 0 ++ %_tmp17 = load i16, i16* %_tmp16, align 1 ++ br label %g.exit4.critedge ++ ++bb1.i: ; preds = %bb4 ++ br label %g.exit4 ++ ++g.exit4.critedge: ; preds = %bb4 ++ %_tmp28.c = getelementptr [1 x [1 x %rec9]], [1 x [1 x %rec9]]* @a, i16 0, i16 %h.3.0, i16 %i.4.01, i32 1 ++ %_tmp29.c = load i32, i32* %_tmp28.c, align 1 ++ %_tmp30.c = trunc i32 %_tmp29.c to i16 ++ br label %g.exit4 ++ ++g.exit4: ; preds = %g.exit4.critedge, %bb1.i ++ %i.4.02 = phi i16 [ %i.4.01, %g.exit4.critedge ], [ %i.4.01, %bb1.i ] ++ %_tmp41 = getelementptr [1 x [1 x %rec9]], [1 x [1 x %rec9]]* @a, i16 0, i16 %h.3.0, i16 %i.4.02, i32 2 ++ br label %bb6 ++ ++bb5: ; preds = %g.exit4 ++ br label %bb6 ++ ++bb6: ; preds = %bb5, %g.exit4 ++ %i.4.03 = phi i16 [ %i.4.02, %bb5 ], [ %i.4.02, %g.exit4 ] ++ %_tmp49 = add nuw nsw i16 %i.4.03, 1 ++ br label %bb7 ++ ++bb7: ; preds = %bb7.us-lcssa.us, %bb7.us-lcssa ++ %_tmp53 = add nsw i16 %h.3.0, 1 ++ br label %bb2 ++} +-- +2.24.0 + diff --git a/projects/clang/43909.patch b/projects/clang/43909.patch new file mode 100644 index 0000000..78d2a75 --- /dev/null +++ b/projects/clang/43909.patch @@ -0,0 +1,252 @@ +From c95310f2d4fd3c88241c3b5d6dbf6251d34a3256 Mon Sep 17 00:00:00 2001 +From: Nikita Popov <nikita.ppv(a)gmail.com> +Date: Sat, 16 Nov 2019 16:22:18 +0100 +Subject: [PATCH] Restructure caching + +Variant on D70103. The caching is switched to always use a BB to +cache entry map, which then contains per-value caches. A separate +set contains value handles with a deletion callback. This allows us +to properly invalidate overdefined values. + +A possible alternative would be to always cache by value first and +have per-BB maps/sets in the each cache entry. In that case we could +use a ValueMap and would avoid the separate value handle set. I went +with the BB indexing at the top level to make it easier to integrate +D69914, but possibly that's not the right choice. + +Differential Revision: https://reviews.llvm.org/D70376 + +diff --git a/llvm/lib/Analysis/LazyValueInfo.cpp b/llvm/lib/Analysis/LazyValueInfo.cpp +index 110c085d3f3..aa6862cb588 100644 +--- a/llvm/lib/Analysis/LazyValueInfo.cpp ++++ b/llvm/lib/Analysis/LazyValueInfo.cpp +@@ -133,12 +133,9 @@ namespace { + /// A callback value handle updates the cache when values are erased. + class LazyValueInfoCache; + struct LVIValueHandle final : public CallbackVH { +- // Needs to access getValPtr(), which is protected. +- friend struct DenseMapInfo<LVIValueHandle>; +- + LazyValueInfoCache *Parent; + +- LVIValueHandle(Value *V, LazyValueInfoCache *P) ++ LVIValueHandle(Value *V, LazyValueInfoCache *P = nullptr) + : CallbackVH(V), Parent(P) { } + + void deleted() override; +@@ -152,89 +149,63 @@ namespace { + /// This is the cache kept by LazyValueInfo which + /// maintains information about queries across the clients' queries. + class LazyValueInfoCache { +- /// This is all of the cached block information for exactly one Value*. +- /// The entries are sorted by the BasicBlock* of the +- /// entries, allowing us to do a lookup with a binary search. +- /// Over-defined lattice values are recorded in OverDefinedCache to reduce +- /// memory overhead. +- struct ValueCacheEntryTy { +- ValueCacheEntryTy(Value *V, LazyValueInfoCache *P) : Handle(V, P) {} +- LVIValueHandle Handle; +- SmallDenseMap<PoisoningVH<BasicBlock>, ValueLatticeElement, 4> BlockVals; ++ /// This is all of the cached information for one basic block. It contains ++ /// the per-value lattice elements, as well as a separate set for ++ /// overdefined values to reduce memory usage. ++ struct BlockCacheEntryTy { ++ SmallDenseMap<AssertingVH<Value>, ValueLatticeElement, 4> LatticeElements; ++ SmallDenseSet<AssertingVH<Value>, 4> OverDefined; + }; + +- /// This tracks, on a per-block basis, the set of values that are +- /// over-defined at the end of that block. +- typedef DenseMap<PoisoningVH<BasicBlock>, SmallPtrSet<Value *, 4>> +- OverDefinedCacheTy; +- /// Keep track of all blocks that we have ever seen, so we +- /// don't spend time removing unused blocks from our caches. +- DenseSet<PoisoningVH<BasicBlock> > SeenBlocks; +- +- /// This is all of the cached information for all values, +- /// mapped from Value* to key information. +- DenseMap<Value *, std::unique_ptr<ValueCacheEntryTy>> ValueCache; +- OverDefinedCacheTy OverDefinedCache; +- ++ /// Cached information per basic block. ++ DenseMap<PoisoningVH<BasicBlock>, BlockCacheEntryTy> BlockCache; ++ /// Set of value handles used to erase values from the cache on deletion. ++ DenseSet<LVIValueHandle, DenseMapInfo<Value *>> ValueHandles; + + public: + void insertResult(Value *Val, BasicBlock *BB, + const ValueLatticeElement &Result) { +- SeenBlocks.insert(BB); +- ++ auto &CacheEntry = BlockCache.try_emplace(BB).first->second; + // Insert over-defined values into their own cache to reduce memory + // overhead. + if (Result.isOverdefined()) +- OverDefinedCache[BB].insert(Val); +- else { +- auto It = ValueCache.find_as(Val); +- if (It == ValueCache.end()) { +- ValueCache[Val] = make_unique<ValueCacheEntryTy>(Val, this); +- It = ValueCache.find_as(Val); +- assert(It != ValueCache.end() && "Val was just added to the map!"); +- } +- It->second->BlockVals[BB] = Result; +- } +- } +- +- bool isOverdefined(Value *V, BasicBlock *BB) const { +- auto ODI = OverDefinedCache.find(BB); +- +- if (ODI == OverDefinedCache.end()) +- return false; ++ CacheEntry.OverDefined.insert(Val); ++ else ++ CacheEntry.LatticeElements.insert({ Val, Result }); + +- return ODI->second.count(V); ++ auto HandleIt = ValueHandles.find_as(Val); ++ if (HandleIt == ValueHandles.end()) ++ ValueHandles.insert({ Val, this }); + } + + bool hasCachedValueInfo(Value *V, BasicBlock *BB) const { +- if (isOverdefined(V, BB)) +- return true; +- +- auto I = ValueCache.find_as(V); +- if (I == ValueCache.end()) ++ auto It = BlockCache.find(BB); ++ if (It == BlockCache.end()) + return false; + +- return I->second->BlockVals.count(BB); ++ return It->second.OverDefined.count(V) || ++ It->second.LatticeElements.count(V); + } + + ValueLatticeElement getCachedValueInfo(Value *V, BasicBlock *BB) const { +- if (isOverdefined(V, BB)) ++ auto It = BlockCache.find(BB); ++ if (It == BlockCache.end()) ++ return ValueLatticeElement(); ++ ++ if (It->second.OverDefined.count(V)) + return ValueLatticeElement::getOverdefined(); + +- auto I = ValueCache.find_as(V); +- if (I == ValueCache.end()) ++ auto LatticeIt = It->second.LatticeElements.find(V); ++ if (LatticeIt == It->second.LatticeElements.end()) + return ValueLatticeElement(); +- auto BBI = I->second->BlockVals.find(BB); +- if (BBI == I->second->BlockVals.end()) +- return ValueLatticeElement(); +- return BBI->second; ++ ++ return LatticeIt->second; + } + + /// clear - Empty the cache. + void clear() { +- SeenBlocks.clear(); +- ValueCache.clear(); +- OverDefinedCache.clear(); ++ BlockCache.clear(); ++ ValueHandles.clear(); + } + + /// Inform the cache that a given value has been deleted. +@@ -248,23 +219,18 @@ namespace { + /// OldSucc might have (unless also overdefined in NewSucc). This just + /// flushes elements from the cache and does not add any. + void threadEdgeImpl(BasicBlock *OldSucc,BasicBlock *NewSucc); +- +- friend struct LVIValueHandle; + }; + } + + void LazyValueInfoCache::eraseValue(Value *V) { +- for (auto I = OverDefinedCache.begin(), E = OverDefinedCache.end(); I != E;) { +- // Copy and increment the iterator immediately so we can erase behind +- // ourselves. +- auto Iter = I++; +- SmallPtrSetImpl<Value *> &ValueSet = Iter->second; +- ValueSet.erase(V); +- if (ValueSet.empty()) +- OverDefinedCache.erase(Iter); ++ for (auto &Pair : BlockCache) { ++ Pair.second.LatticeElements.erase(V); ++ Pair.second.OverDefined.erase(V); + } + +- ValueCache.erase(V); ++ auto HandleIt = ValueHandles.find_as(V); ++ if (HandleIt != ValueHandles.end()) ++ ValueHandles.erase(HandleIt); + } + + void LVIValueHandle::deleted() { +@@ -274,18 +240,7 @@ void LVIValueHandle::deleted() { + } + + void LazyValueInfoCache::eraseBlock(BasicBlock *BB) { +- // Shortcut if we have never seen this block. +- DenseSet<PoisoningVH<BasicBlock> >::iterator I = SeenBlocks.find(BB); +- if (I == SeenBlocks.end()) +- return; +- SeenBlocks.erase(I); +- +- auto ODI = OverDefinedCache.find(BB); +- if (ODI != OverDefinedCache.end()) +- OverDefinedCache.erase(ODI); +- +- for (auto &I : ValueCache) +- I.second->BlockVals.erase(BB); ++ BlockCache.erase(BB); + } + + void LazyValueInfoCache::threadEdgeImpl(BasicBlock *OldSucc, +@@ -303,10 +258,11 @@ void LazyValueInfoCache::threadEdgeImpl(BasicBlock *OldSucc, + std::vector<BasicBlock*> worklist; + worklist.push_back(OldSucc); + +- auto I = OverDefinedCache.find(OldSucc); +- if (I == OverDefinedCache.end()) ++ auto I = BlockCache.find(OldSucc); ++ if (I == BlockCache.end() || I->second.OverDefined.empty()) + return; // Nothing to process here. +- SmallVector<Value *, 4> ValsToClear(I->second.begin(), I->second.end()); ++ SmallVector<Value *, 4> ValsToClear(I->second.OverDefined.begin(), ++ I->second.OverDefined.end()); + + // Use a worklist to perform a depth-first search of OldSucc's successors. + // NOTE: We do not need a visited list since any blocks we have already +@@ -320,10 +276,10 @@ void LazyValueInfoCache::threadEdgeImpl(BasicBlock *OldSucc, + if (ToUpdate == NewSucc) continue; + + // If a value was marked overdefined in OldSucc, and is here too... +- auto OI = OverDefinedCache.find(ToUpdate); +- if (OI == OverDefinedCache.end()) ++ auto OI = BlockCache.find(ToUpdate); ++ if (OI == BlockCache.end() || OI->second.OverDefined.empty()) + continue; +- SmallPtrSetImpl<Value *> &ValueSet = OI->second; ++ auto &ValueSet = OI->second.OverDefined; + + bool changed = false; + for (Value *V : ValsToClear) { +@@ -333,11 +289,6 @@ void LazyValueInfoCache::threadEdgeImpl(BasicBlock *OldSucc, + // If we removed anything, then we potentially need to update + // blocks successors too. + changed = true; +- +- if (ValueSet.empty()) { +- OverDefinedCache.erase(OI); +- break; +- } + } + + if (!changed) continue; +-- +2.24.0 + diff --git a/projects/clang/build b/projects/clang/build index c1afa6d..825b21e 100644 --- a/projects/clang/build +++ b/projects/clang/build @@ -20,6 +20,10 @@ tar -xf $rootdir/[% c('input_files_by_name/libcxxabi') %] tar -xf $rootdir/[% c('input_files_by_name/lld') %] tar -xf $rootdir/[% c('input_files_by_name/compiler-rt') %] mv llvm-* llvm +# LLVM has reproducibility issues when optimizing bitcode, which we need to +# patch. See: #32053 for more details. +patch -p1 < $rootdir/42574.patch +patch -p1 < $rootdir/43909.patch mv cfe-* llvm/tools/clang mv libcxx-* llvm/projects/libcxx mv libcxxabi-* llvm/projects/libcxxabi diff --git a/projects/clang/config b/projects/clang/config index 67798f8..cf4dcb0 100644 --- a/projects/clang/config +++ b/projects/clang/config @@ -45,3 +45,5 @@ input_files: enable: '[% c("var/windows") %]' - filename: timestamp.patch enable: '[% c("var/windows") %]' + - filename: 42574.patch + - filename: 43909.patch diff --git a/projects/rust/42574.patch b/projects/rust/42574.patch new file mode 100644 index 0000000..285d254 --- /dev/null +++ b/projects/rust/42574.patch @@ -0,0 +1,236 @@ +From 3757213db371dcea53cae357cf9c56d1b0604f98 Mon Sep 17 00:00:00 2001 +From: Alina Sbirlea <asbirlea(a)google.com> +Date: Fri, 12 Jul 2019 22:30:30 +0000 +Subject: [PATCH] [MemorySSA] Use SetVector to avoid nondeterminism. + +Summary: +Use a SetVector for DeadBlockSet. +Resolves PR42574. + +Reviewers: george.burgess.iv, uabelho, dblaikie + +Subscribers: jlebar, Prazek, mgrang, llvm-commits + +Tags: #llvm + +Differential Revision: https://reviews.llvm.org/D64601 + +llvm-svn: 365970 + +diff --git a/llvm/include/llvm/Analysis/MemorySSAUpdater.h b/llvm/include/llvm/Analysis/MemorySSAUpdater.h +index 169d5bd9fa8..276620bd445 100644 +--- a/llvm/include/llvm/Analysis/MemorySSAUpdater.h ++++ b/llvm/include/llvm/Analysis/MemorySSAUpdater.h +@@ -32,6 +32,7 @@ + #ifndef LLVM_ANALYSIS_MEMORYSSAUPDATER_H + #define LLVM_ANALYSIS_MEMORYSSAUPDATER_H + ++#include "llvm/ADT/SetVector.h" + #include "llvm/ADT/SmallPtrSet.h" + #include "llvm/ADT/SmallSet.h" + #include "llvm/ADT/SmallVector.h" +@@ -239,7 +240,7 @@ public: + /// Deleted blocks still have successor info, but their predecessor edges and + /// Phi nodes may already be updated. Instructions in DeadBlocks should be + /// deleted after this call. +- void removeBlocks(const SmallPtrSetImpl<BasicBlock *> &DeadBlocks); ++ void removeBlocks(const SmallSetVector<BasicBlock *, 8> &DeadBlocks); + + /// Get handle on MemorySSA. + MemorySSA* getMemorySSA() const { return MSSA; } +diff --git a/llvm/lib/Analysis/MemorySSAUpdater.cpp b/llvm/lib/Analysis/MemorySSAUpdater.cpp +index 6c817d20368..a6c7142a697 100644 +--- a/llvm/lib/Analysis/MemorySSAUpdater.cpp ++++ b/llvm/lib/Analysis/MemorySSAUpdater.cpp +@@ -1101,7 +1101,7 @@ void MemorySSAUpdater::removeMemoryAccess(MemoryAccess *MA) { + } + + void MemorySSAUpdater::removeBlocks( +- const SmallPtrSetImpl<BasicBlock *> &DeadBlocks) { ++ const SmallSetVector<BasicBlock *, 8> &DeadBlocks) { + // First delete all uses of BB in MemoryPhis. + for (BasicBlock *BB : DeadBlocks) { + Instruction *TI = BB->getTerminator(); +diff --git a/llvm/lib/Transforms/Scalar/LoopSimplifyCFG.cpp b/llvm/lib/Transforms/Scalar/LoopSimplifyCFG.cpp +index 2e5927f9a06..f464df26a02 100644 +--- a/llvm/lib/Transforms/Scalar/LoopSimplifyCFG.cpp ++++ b/llvm/lib/Transforms/Scalar/LoopSimplifyCFG.cpp +@@ -388,8 +388,8 @@ private: + void deleteDeadLoopBlocks() { + DomTreeUpdater DTU(DT, DomTreeUpdater::UpdateStrategy::Eager); + if (MSSAU) { +- SmallPtrSet<BasicBlock *, 8> DeadLoopBlocksSet(DeadLoopBlocks.begin(), +- DeadLoopBlocks.end()); ++ SmallSetVector<BasicBlock *, 8> DeadLoopBlocksSet(DeadLoopBlocks.begin(), ++ DeadLoopBlocks.end()); + MSSAU->removeBlocks(DeadLoopBlocksSet); + } + for (auto *BB : DeadLoopBlocks) { +diff --git a/llvm/lib/Transforms/Scalar/SimpleLoopUnswitch.cpp b/llvm/lib/Transforms/Scalar/SimpleLoopUnswitch.cpp +index 5a67178cef3..814cf814989 100644 +--- a/llvm/lib/Transforms/Scalar/SimpleLoopUnswitch.cpp ++++ b/llvm/lib/Transforms/Scalar/SimpleLoopUnswitch.cpp +@@ -1436,8 +1436,8 @@ deleteDeadClonedBlocks(Loop &L, ArrayRef<BasicBlock *> ExitBlocks, + + // Remove all MemorySSA in the dead blocks + if (MSSAU) { +- SmallPtrSet<BasicBlock *, 16> DeadBlockSet(DeadBlocks.begin(), +- DeadBlocks.end()); ++ SmallSetVector<BasicBlock *, 8> DeadBlockSet(DeadBlocks.begin(), ++ DeadBlocks.end()); + MSSAU->removeBlocks(DeadBlockSet); + } + +@@ -1455,7 +1455,7 @@ static void deleteDeadBlocksFromLoop(Loop &L, + MemorySSAUpdater *MSSAU) { + // Find all the dead blocks tied to this loop, and remove them from their + // successors. +- SmallPtrSet<BasicBlock *, 16> DeadBlockSet; ++ SmallSetVector<BasicBlock *, 8> DeadBlockSet; + + // Start with loop/exit blocks and get a transitive closure of reachable dead + // blocks. +diff --git a/llvm/lib/Transforms/Utils/Local.cpp b/llvm/lib/Transforms/Utils/Local.cpp +index 499e611acb5..83dabcd7952 100644 +--- a/llvm/lib/Transforms/Utils/Local.cpp ++++ b/llvm/lib/Transforms/Utils/Local.cpp +@@ -2211,7 +2211,7 @@ bool llvm::removeUnreachableBlocks(Function &F, LazyValueInfo *LVI, + assert(Reachable.size() < F.size()); + NumRemoved += F.size()-Reachable.size(); + +- SmallPtrSet<BasicBlock *, 16> DeadBlockSet; ++ SmallSetVector<BasicBlock *, 8> DeadBlockSet; + for (Function::iterator I = ++F.begin(), E = F.end(); I != E; ++I) { + auto *BB = &*I; + if (Reachable.count(BB)) +diff --git a/llvm/test/Analysis/MemorySSA/nondeterminism.ll b/llvm/test/Analysis/MemorySSA/nondeterminism.ll +new file mode 100644 +index 00000000000..0bb3df30b58 +--- /dev/null ++++ b/llvm/test/Analysis/MemorySSA/nondeterminism.ll +@@ -0,0 +1,122 @@ ++; RUN: opt -simplifycfg -enable-mssa-loop-dependency -S --preserve-ll-uselistorder %s | FileCheck %s ++; REQUIRES: x86-registered-target ++; CHECK-LABEL: @n ++; CHECK: uselistorder i16 0, { 3, 2, 4, 1, 5, 0, 6 } ++ ++; Note: test was added in an effort to ensure determinism when updating memoryssa. See PR42574. ++; If the uselistorder check becomes no longer relevant, the test can be disabled or removed. ++ ++%rec9 = type { i16, i32, i32 } ++ ++@a = global [1 x [1 x %rec9]] zeroinitializer ++ ++define i16 @n() { ++ br label %..split_crit_edge ++ ++..split_crit_edge: ; preds = %0 ++ br label %.split ++ ++bb4.us4: ; preds = %bb2.split.us32, %bb6.us28 ++ %i.4.01.us5 = phi i16 [ %_tmp49.us30, %bb6.us28 ] ++ br label %g.exit4.us21 ++ ++bb1.i.us14: ; preds = %bb4.us4 ++ br label %g.exit4.us21 ++ ++g.exit4.us21: ; preds = %bb1.i.us14, %g.exit4.critedge.us9 ++ %i.4.02.us22 = phi i16 [ %i.4.01.us5, %bb4.us4 ], [ %i.4.01.us5, %bb1.i.us14 ] ++ br label %bb6.us28 ++ ++bb5.us26: ; preds = %g.exit4.us21 ++ br label %bb6.us28 ++ ++bb6.us28: ; preds = %bb5.us26, %g.exit4.us21 ++ %i.4.03.us29 = phi i16 [ %i.4.02.us22, %bb5.us26 ], [ %i.4.02.us22, %g.exit4.us21 ] ++ %_tmp49.us30 = add nuw nsw i16 %i.4.03.us29, 1 ++ br label %bb4.us4 ++ ++bb4.us.us: ; preds = %bb2.split.us.us, %bb6.us.us ++ %i.4.01.us.us = phi i16 [ %_tmp49.us.us, %bb6.us.us ] ++ br label %bb1.i.us.us ++ ++bb1.i.us.us: ; preds = %bb4.us.us ++ br label %g.exit4.us.us ++ ++g.exit4.us.us: ; preds = %bb1.i.us.us, %g.exit4.critedge.us.us ++ %i.4.02.us.us = phi i16 [ %i.4.01.us.us, %bb1.i.us.us ] ++ br label %bb5.us.us ++ ++bb5.us.us: ; preds = %g.exit4.us.us ++ br label %bb6.us.us ++ ++bb6.us.us: ; preds = %bb5.us.us, %g.exit4.us.us ++ %i.4.03.us.us = phi i16 [ %i.4.02.us.us, %bb5.us.us ] ++ %_tmp49.us.us = add nuw nsw i16 %i.4.03.us.us, 1 ++ br label %bb4.us.us ++ ++ ++.split: ; preds = %..split_crit_edge ++ br label %bb2 ++ ++bb2: ; preds = %.split, %bb7 ++ %h.3.0 = phi i16 [ undef, %.split ], [ %_tmp53, %bb7 ] ++ br label %bb2.bb2.split_crit_edge ++ ++bb2.bb2.split_crit_edge: ; preds = %bb2 ++ br label %bb2.split ++ ++bb2.split.us: ; preds = %bb2 ++ br label %bb4.us ++ ++bb4.us: ; preds = %bb6.us, %bb2.split.us ++ %i.4.01.us = phi i16 [ 0, %bb2.split.us ] ++ br label %bb1.i.us ++ ++g.exit4.critedge.us: ; preds = %bb4.us ++ br label %g.exit4.us ++ ++bb1.i.us: ; preds = %bb4.us ++ br label %g.exit4.us ++ ++g.exit4.us: ; preds = %bb1.i.us, %g.exit4.critedge.us ++ %i.4.02.us = phi i16 [ %i.4.01.us, %g.exit4.critedge.us ], [ %i.4.01.us, %bb1.i.us ] ++ br label %bb5.us ++ ++bb5.us: ; preds = %g.exit4.us ++ br label %bb7 ++ ++bb2.split: ; preds = %bb2.bb2.split_crit_edge ++ br label %bb4 ++ ++bb4: ; preds = %bb2.split, %bb6 ++ %i.4.01 = phi i16 [ 0, %bb2.split ] ++ %_tmp16 = getelementptr [1 x [1 x %rec9]], [1 x [1 x %rec9]]* @a, i16 0, i16 %h.3.0, i16 %i.4.01, i32 0 ++ %_tmp17 = load i16, i16* %_tmp16, align 1 ++ br label %g.exit4.critedge ++ ++bb1.i: ; preds = %bb4 ++ br label %g.exit4 ++ ++g.exit4.critedge: ; preds = %bb4 ++ %_tmp28.c = getelementptr [1 x [1 x %rec9]], [1 x [1 x %rec9]]* @a, i16 0, i16 %h.3.0, i16 %i.4.01, i32 1 ++ %_tmp29.c = load i32, i32* %_tmp28.c, align 1 ++ %_tmp30.c = trunc i32 %_tmp29.c to i16 ++ br label %g.exit4 ++ ++g.exit4: ; preds = %g.exit4.critedge, %bb1.i ++ %i.4.02 = phi i16 [ %i.4.01, %g.exit4.critedge ], [ %i.4.01, %bb1.i ] ++ %_tmp41 = getelementptr [1 x [1 x %rec9]], [1 x [1 x %rec9]]* @a, i16 0, i16 %h.3.0, i16 %i.4.02, i32 2 ++ br label %bb6 ++ ++bb5: ; preds = %g.exit4 ++ br label %bb6 ++ ++bb6: ; preds = %bb5, %g.exit4 ++ %i.4.03 = phi i16 [ %i.4.02, %bb5 ], [ %i.4.02, %g.exit4 ] ++ %_tmp49 = add nuw nsw i16 %i.4.03, 1 ++ br label %bb7 ++ ++bb7: ; preds = %bb7.us-lcssa.us, %bb7.us-lcssa ++ %_tmp53 = add nsw i16 %h.3.0, 1 ++ br label %bb2 ++} +-- +2.24.0 + diff --git a/projects/rust/43909.patch b/projects/rust/43909.patch new file mode 100644 index 0000000..78d2a75 --- /dev/null +++ b/projects/rust/43909.patch @@ -0,0 +1,252 @@ +From c95310f2d4fd3c88241c3b5d6dbf6251d34a3256 Mon Sep 17 00:00:00 2001 +From: Nikita Popov <nikita.ppv(a)gmail.com> +Date: Sat, 16 Nov 2019 16:22:18 +0100 +Subject: [PATCH] Restructure caching + +Variant on D70103. The caching is switched to always use a BB to +cache entry map, which then contains per-value caches. A separate +set contains value handles with a deletion callback. This allows us +to properly invalidate overdefined values. + +A possible alternative would be to always cache by value first and +have per-BB maps/sets in the each cache entry. In that case we could +use a ValueMap and would avoid the separate value handle set. I went +with the BB indexing at the top level to make it easier to integrate +D69914, but possibly that's not the right choice. + +Differential Revision: https://reviews.llvm.org/D70376 + +diff --git a/llvm/lib/Analysis/LazyValueInfo.cpp b/llvm/lib/Analysis/LazyValueInfo.cpp +index 110c085d3f3..aa6862cb588 100644 +--- a/llvm/lib/Analysis/LazyValueInfo.cpp ++++ b/llvm/lib/Analysis/LazyValueInfo.cpp +@@ -133,12 +133,9 @@ namespace { + /// A callback value handle updates the cache when values are erased. + class LazyValueInfoCache; + struct LVIValueHandle final : public CallbackVH { +- // Needs to access getValPtr(), which is protected. +- friend struct DenseMapInfo<LVIValueHandle>; +- + LazyValueInfoCache *Parent; + +- LVIValueHandle(Value *V, LazyValueInfoCache *P) ++ LVIValueHandle(Value *V, LazyValueInfoCache *P = nullptr) + : CallbackVH(V), Parent(P) { } + + void deleted() override; +@@ -152,89 +149,63 @@ namespace { + /// This is the cache kept by LazyValueInfo which + /// maintains information about queries across the clients' queries. + class LazyValueInfoCache { +- /// This is all of the cached block information for exactly one Value*. +- /// The entries are sorted by the BasicBlock* of the +- /// entries, allowing us to do a lookup with a binary search. +- /// Over-defined lattice values are recorded in OverDefinedCache to reduce +- /// memory overhead. +- struct ValueCacheEntryTy { +- ValueCacheEntryTy(Value *V, LazyValueInfoCache *P) : Handle(V, P) {} +- LVIValueHandle Handle; +- SmallDenseMap<PoisoningVH<BasicBlock>, ValueLatticeElement, 4> BlockVals; ++ /// This is all of the cached information for one basic block. It contains ++ /// the per-value lattice elements, as well as a separate set for ++ /// overdefined values to reduce memory usage. ++ struct BlockCacheEntryTy { ++ SmallDenseMap<AssertingVH<Value>, ValueLatticeElement, 4> LatticeElements; ++ SmallDenseSet<AssertingVH<Value>, 4> OverDefined; + }; + +- /// This tracks, on a per-block basis, the set of values that are +- /// over-defined at the end of that block. +- typedef DenseMap<PoisoningVH<BasicBlock>, SmallPtrSet<Value *, 4>> +- OverDefinedCacheTy; +- /// Keep track of all blocks that we have ever seen, so we +- /// don't spend time removing unused blocks from our caches. +- DenseSet<PoisoningVH<BasicBlock> > SeenBlocks; +- +- /// This is all of the cached information for all values, +- /// mapped from Value* to key information. +- DenseMap<Value *, std::unique_ptr<ValueCacheEntryTy>> ValueCache; +- OverDefinedCacheTy OverDefinedCache; +- ++ /// Cached information per basic block. ++ DenseMap<PoisoningVH<BasicBlock>, BlockCacheEntryTy> BlockCache; ++ /// Set of value handles used to erase values from the cache on deletion. ++ DenseSet<LVIValueHandle, DenseMapInfo<Value *>> ValueHandles; + + public: + void insertResult(Value *Val, BasicBlock *BB, + const ValueLatticeElement &Result) { +- SeenBlocks.insert(BB); +- ++ auto &CacheEntry = BlockCache.try_emplace(BB).first->second; + // Insert over-defined values into their own cache to reduce memory + // overhead. + if (Result.isOverdefined()) +- OverDefinedCache[BB].insert(Val); +- else { +- auto It = ValueCache.find_as(Val); +- if (It == ValueCache.end()) { +- ValueCache[Val] = make_unique<ValueCacheEntryTy>(Val, this); +- It = ValueCache.find_as(Val); +- assert(It != ValueCache.end() && "Val was just added to the map!"); +- } +- It->second->BlockVals[BB] = Result; +- } +- } +- +- bool isOverdefined(Value *V, BasicBlock *BB) const { +- auto ODI = OverDefinedCache.find(BB); +- +- if (ODI == OverDefinedCache.end()) +- return false; ++ CacheEntry.OverDefined.insert(Val); ++ else ++ CacheEntry.LatticeElements.insert({ Val, Result }); + +- return ODI->second.count(V); ++ auto HandleIt = ValueHandles.find_as(Val); ++ if (HandleIt == ValueHandles.end()) ++ ValueHandles.insert({ Val, this }); + } + + bool hasCachedValueInfo(Value *V, BasicBlock *BB) const { +- if (isOverdefined(V, BB)) +- return true; +- +- auto I = ValueCache.find_as(V); +- if (I == ValueCache.end()) ++ auto It = BlockCache.find(BB); ++ if (It == BlockCache.end()) + return false; + +- return I->second->BlockVals.count(BB); ++ return It->second.OverDefined.count(V) || ++ It->second.LatticeElements.count(V); + } + + ValueLatticeElement getCachedValueInfo(Value *V, BasicBlock *BB) const { +- if (isOverdefined(V, BB)) ++ auto It = BlockCache.find(BB); ++ if (It == BlockCache.end()) ++ return ValueLatticeElement(); ++ ++ if (It->second.OverDefined.count(V)) + return ValueLatticeElement::getOverdefined(); + +- auto I = ValueCache.find_as(V); +- if (I == ValueCache.end()) ++ auto LatticeIt = It->second.LatticeElements.find(V); ++ if (LatticeIt == It->second.LatticeElements.end()) + return ValueLatticeElement(); +- auto BBI = I->second->BlockVals.find(BB); +- if (BBI == I->second->BlockVals.end()) +- return ValueLatticeElement(); +- return BBI->second; ++ ++ return LatticeIt->second; + } + + /// clear - Empty the cache. + void clear() { +- SeenBlocks.clear(); +- ValueCache.clear(); +- OverDefinedCache.clear(); ++ BlockCache.clear(); ++ ValueHandles.clear(); + } + + /// Inform the cache that a given value has been deleted. +@@ -248,23 +219,18 @@ namespace { + /// OldSucc might have (unless also overdefined in NewSucc). This just + /// flushes elements from the cache and does not add any. + void threadEdgeImpl(BasicBlock *OldSucc,BasicBlock *NewSucc); +- +- friend struct LVIValueHandle; + }; + } + + void LazyValueInfoCache::eraseValue(Value *V) { +- for (auto I = OverDefinedCache.begin(), E = OverDefinedCache.end(); I != E;) { +- // Copy and increment the iterator immediately so we can erase behind +- // ourselves. +- auto Iter = I++; +- SmallPtrSetImpl<Value *> &ValueSet = Iter->second; +- ValueSet.erase(V); +- if (ValueSet.empty()) +- OverDefinedCache.erase(Iter); ++ for (auto &Pair : BlockCache) { ++ Pair.second.LatticeElements.erase(V); ++ Pair.second.OverDefined.erase(V); + } + +- ValueCache.erase(V); ++ auto HandleIt = ValueHandles.find_as(V); ++ if (HandleIt != ValueHandles.end()) ++ ValueHandles.erase(HandleIt); + } + + void LVIValueHandle::deleted() { +@@ -274,18 +240,7 @@ void LVIValueHandle::deleted() { + } + + void LazyValueInfoCache::eraseBlock(BasicBlock *BB) { +- // Shortcut if we have never seen this block. +- DenseSet<PoisoningVH<BasicBlock> >::iterator I = SeenBlocks.find(BB); +- if (I == SeenBlocks.end()) +- return; +- SeenBlocks.erase(I); +- +- auto ODI = OverDefinedCache.find(BB); +- if (ODI != OverDefinedCache.end()) +- OverDefinedCache.erase(ODI); +- +- for (auto &I : ValueCache) +- I.second->BlockVals.erase(BB); ++ BlockCache.erase(BB); + } + + void LazyValueInfoCache::threadEdgeImpl(BasicBlock *OldSucc, +@@ -303,10 +258,11 @@ void LazyValueInfoCache::threadEdgeImpl(BasicBlock *OldSucc, + std::vector<BasicBlock*> worklist; + worklist.push_back(OldSucc); + +- auto I = OverDefinedCache.find(OldSucc); +- if (I == OverDefinedCache.end()) ++ auto I = BlockCache.find(OldSucc); ++ if (I == BlockCache.end() || I->second.OverDefined.empty()) + return; // Nothing to process here. +- SmallVector<Value *, 4> ValsToClear(I->second.begin(), I->second.end()); ++ SmallVector<Value *, 4> ValsToClear(I->second.OverDefined.begin(), ++ I->second.OverDefined.end()); + + // Use a worklist to perform a depth-first search of OldSucc's successors. + // NOTE: We do not need a visited list since any blocks we have already +@@ -320,10 +276,10 @@ void LazyValueInfoCache::threadEdgeImpl(BasicBlock *OldSucc, + if (ToUpdate == NewSucc) continue; + + // If a value was marked overdefined in OldSucc, and is here too... +- auto OI = OverDefinedCache.find(ToUpdate); +- if (OI == OverDefinedCache.end()) ++ auto OI = BlockCache.find(ToUpdate); ++ if (OI == BlockCache.end() || OI->second.OverDefined.empty()) + continue; +- SmallPtrSetImpl<Value *> &ValueSet = OI->second; ++ auto &ValueSet = OI->second.OverDefined; + + bool changed = false; + for (Value *V : ValsToClear) { +@@ -333,11 +289,6 @@ void LazyValueInfoCache::threadEdgeImpl(BasicBlock *OldSucc, + // If we removed anything, then we potentially need to update + // blocks successors too. + changed = true; +- +- if (ValueSet.empty()) { +- OverDefinedCache.erase(OI); +- break; +- } + } + + if (!changed) continue; +-- +2.24.0 + diff --git a/projects/rust/build b/projects/rust/build index 9a6b54a..8b45e3f 100644 --- a/projects/rust/build +++ b/projects/rust/build @@ -51,6 +51,13 @@ mkdir /var/tmp/build tar -C /var/tmp/build -xf [% c('input_files_by_name/rust') %] cd /var/tmp/build/rustc-[% c('version') %]-src +# LLVM has reproducibility issues when optimizing bitcode, which we need to +# patch. See: #32053 for more details. +cd src/llvm-project +patch -p1 < $rootdir/42574.patch +patch -p1 < $rootdir/43909.patch +cd ../../ + [% IF c("var/windows-i686") %] # Cross-compiling for Windows 32bit is currently not possible without any # patches. The reason for that is libstd expecting DWARF unwinding while most diff --git a/projects/rust/config b/projects/rust/config index 03d7be0..848ccd0 100644 --- a/projects/rust/config +++ b/projects/rust/config @@ -106,3 +106,5 @@ input_files: gpg_keyring: rust.gpg - filename: unwind.patch enable: '[% c("var/windows-i686") %]' + - filename: 42574.patch + - filename: 43909.patch

1 0

[translation/support-portal] https://gitweb.torproject.org/translation.git/commit/?h=support-portal
by translation＠torproject.org 13 Dec '19

13 Dec '19

commit 84fb27a9d15838955f9d8b03c23f126e9b0b459f Author: Translation commit bot <translation(a)torproject.org> Date: Fri Dec 13 11:25:12 2019 +0000 https://gitweb.torproject.org/translation.git/commit/?h=support-portal --- contents+ru.po | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/contents+ru.po b/contents+ru.po index 4bd640a9df..cef6f16992 100644 --- a/contents+ru.po +++ b/contents+ru.po @@ -11,8 +11,8 @@ # erinm, 2019 # solokot <solokot(a)gmail.com>, 2019 # Мария Романенко <mary.romanenko(a)gmail.com>, 2019 -# Emma Peel, 2019 # Sergey Smirnov <cj75300(a)gmail.com>, 2019 +# Emma Peel, 2019 # msgid "" msgstr "" @@ -20,7 +20,7 @@ msgstr "" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2019-11-14 16:04+CET\n" "PO-Revision-Date: 2018-10-02 22:41+0000\n" -"Last-Translator: Sergey Smirnov <cj75300(a)gmail.com>, 2019\n" +"Last-Translator: Emma Peel, 2019\n" "Language-Team: Russian (https://www.transifex.com/otf/teams/1519/ru/)\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" @@ -3326,7 +3326,7 @@ msgid "" "to make the signature, and the package’s checksum." msgstr "" "GetTor вышлет сообщение со ссылками, откуда можно скачать Tor Browser, " -"криптографическую подпись (нужна для [проверки скачанной программы](/tbb" +"криптографическую подпись (нужна для [проверки скачанной программы](/ru/tbb" "/how-to-verify-signature/)), отпечаток ключа, которым подписана программа, и" " контрольную сумму."

1 0

[translation/tbmanual-contentspot] https://gitweb.torproject.org/translation.git/commit/?h=tbmanual-contentspot
by translation＠torproject.org 13 Dec '19

13 Dec '19

commit 35f38d7677fb6f4e9593b2040e336da57b0c098b Author: Translation commit bot <translation(a)torproject.org> Date: Fri Dec 13 11:21:12 2019 +0000 https://gitweb.torproject.org/translation.git/commit/?h=tbmanual-contentspot --- contents+ar.po | 2 +- contents+ro.po | 2 +- contents+ru.po | 8 ++++---- 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/contents+ar.po b/contents+ar.po index 2eb7744683..50fa48ad1f 100644 --- a/contents+ar.po +++ b/contents+ar.po @@ -1705,7 +1705,7 @@ msgid "" "(see the [Uninstalling](/uninstalling) section for more information)." msgstr "" "قوموا بإزالة متصفّح تور (Tor) من نظامكم عن طريق حذف المجلّد الذي يحتويه " -"(انظروا إلى قسم (ar/uninstalling/) [إزالة التثبيت] للمزيد من المعلومات.) " +"(انظروا إلى قسم [إزالة التثبيت](ar/uninstalling/) للمزيد من المعلومات.) " #: https//tb-manual.torproject.org/updating/ #: (content/updating/contents+en.lrtopic.body) diff --git a/contents+ro.po b/contents+ro.po index c48bfeec98..aa1d8b6f46 100644 --- a/contents+ro.po +++ b/contents+ro.po @@ -1653,7 +1653,7 @@ msgid "" " fonts and math symbols are disabled; audio and video (HTML5 media) are " "click-to-play." msgstr "" -"* JavaScript este dezactivat pe toate site-urile non- [HTTPS](/ conexiuni " +"* JavaScript este dezactivat pe toate site-urile non- [HTTPS](/ro/conexiuni " "sigure); unele fonturi și simboluri matematice sunt dezactivate; audio și " "video (HTML5 media) sunt clicuri pentru a reda." diff --git a/contents+ru.po b/contents+ru.po index ceb2bbd82b..d25896d9fb 100644 --- a/contents+ru.po +++ b/contents+ru.po @@ -1,7 +1,6 @@ # Translators: # Sergey Leschina <mail(a)putnik.tech>, 2019 # Valentine Bobrovsy <vbabrouski(a)outlook.com>, 2019 -# Emma Peel, 2019 # Legenden Rifk <rekytcsgo(a)gmail.com>, 2019 # Andrey Kostrikov <yavinav(a)gmail.com>, 2019 # solokot <solokot(a)gmail.com>, 2019 @@ -10,6 +9,7 @@ # IvanLykov <chabib(a)list.ru>, 2019 # diana azaryan <dianazryn(a)gmail.com>, 2019 # Sergey Smirnov <cj75300(a)gmail.com>, 2019 +# Emma Peel, 2019 # msgid "" msgstr "" @@ -17,7 +17,7 @@ msgstr "" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2019-11-29 10:58+CET\n" "PO-Revision-Date: 2018-11-14 12:31+0000\n" -"Last-Translator: Sergey Smirnov <cj75300(a)gmail.com>, 2019\n" +"Last-Translator: Emma Peel, 2019\n" "Language-Team: Russian (https://www.transifex.com/otf/teams/1519/ru/)\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" @@ -226,7 +226,7 @@ msgid "" msgstr "" "По умолчанию Tor Browser не сохраняет историю посещений сайтов. Файлы cookie" " хранятся лишь в течение сеанса (пока вы не закроете Tor Browser или не " -"запросите [New Identity](/managing-identities/#new-identity))." +"запросите [New Identity](/ru/managing-identities/#new-identity))." #: https//tb-manual.torproject.org/about/ #: (content/about/contents+en.lrtopic.body) @@ -293,7 +293,7 @@ msgid "" "Your connection to the site will be secured using [HTTPS](/secure-" "connections), which makes it much harder for somebody to tamper with." msgstr "" -" Соединение с сайтом использует протокол безопасности [HTTPS(/ru/secure-" +" Соединение с сайтом использует протокол безопасности [HTTPS](/ru/secure-" "connections), что усложняет перехват вашего трафика сторонними " "пользователями. "

1 0

[tor-browser-build/master] Merge remote-tracking branch 'JeremyRand/reproducible-go'
by boklm＠torproject.org 13 Dec '19

13 Dec '19

commit 0c7a319ca0be61832c3c1d0cec769f0feb089c8d Merge: 7e179ed 0ab4900 Author: Nicolas Vigier <boklm(a)torproject.org> Date: Fri Dec 13 12:04:37 2019 +0100 Merge remote-tracking branch 'JeremyRand/reproducible-go' projects/go/build | 4 ++++ 1 file changed, 4 insertions(+)

1 0

[tor-browser-build/master] Bug 32520: go: Remove go/pkg/obj/go-build/ from output
by boklm＠torproject.org 13 Dec '19

13 Dec '19

commit 0ab49005efd962074e80cafb52fe4dd9cb286229 Author: JeremyRand <biolizard89(a)gmail.com> Date: Mon Dec 2 02:55:33 2019 +0000 Bug 32520: go: Remove go/pkg/obj/go-build/ from output --- projects/go/build | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/projects/go/build b/projects/go/build index 2ebfd58..06af067 100644 --- a/projects/go/build +++ b/projects/go/build @@ -73,6 +73,10 @@ cd /var/tmp/dist/go/src CGO_ENABLED=1 CC_FOR_TARGET=[% c("var/CC") %] CGO_CFLAGS='-D__ANDROID_API__=[% c("var/android_min_api") %]' CC= CFLAGS= LDFLAGS= ./make.bash [% END -%] +# This directory is non-reproducible and doesn't exist in official Go releases, +# so remove it to preserve reproducibility of the output. +rm -rf /var/tmp/dist/go/pkg/obj/go-build/ + cd /var/tmp/dist [% c('tar', { tar_src => [ project ],

1 0