[all-commits] [llvm/llvm-project] 5ddfea: [docs] Bump minimum GCC version to 7.4

Jon Roelofs via All-commits all-commits at lists.llvm.org
Mon Aug 7 00:06:49 PDT 2023


  Branch: refs/heads/release/17.x
  Home:   https://github.com/llvm/llvm-project
  Commit: 5ddfea3e8ef6c1484dcbd108a3946b3663f140e0
      https://github.com/llvm/llvm-project/commit/5ddfea3e8ef6c1484dcbd108a3946b3663f140e0
  Author: Fangrui Song <i at maskray.me>
  Date:   2023-08-07 (Mon, 07 Aug 2023)

  Changed paths:
    M llvm/cmake/modules/CheckCompilerVersion.cmake
    M llvm/docs/GettingStarted.rst

  Log Message:
  -----------
  [docs] Bump minimum GCC version to 7.4

GCC 7.3 cannot build 16.x releases.
```
In file included from /tmp/llvm-16/llvm/lib/Transforms/IPO/AttributorAttributes.cpp:14:0:
/tmp/llvm-16/llvm/include/llvm/Transforms/IPO/Attributor.h:1137:32: error: duplicate initialization of ‘llvm::AnalysisGetter::HasLegacyWrapper<Analysis, std::void_t<typename Analysis::Lega
cyWrapper> >’
 constexpr bool AnalysisGetter::HasLegacyWrapper<
                                ^~~~~~~~~~~~~~~~~
       Analysis, std::void_t<typename Analysis::LegacyWrapper>> = true;
       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/tmp/llvm-16/llvm/include/llvm/Transforms/IPO/Attributor.h:1137:32: error: got 1 template parameters for ‘constexpr const bool llvm::AnalysisGetter::HasLegacyWrapper< <template-parameter-1
-1>, <template-parameter-1-2> >’
/tmp/llvm-16/llvm/include/llvm/Transforms/IPO/Attributor.h:1137:32: error:   but 2 required
```

The 17.x and main branches have more failures, e.g.

```
llvm/lib/Transforms/Vectorize/LoopVectorize.cpp: `error: cannot decompose class type ‘std::pair<llvm::Value*, const llvm::SCEV*>’: ...`
```

We probably should just give up 7.1 and say that GCC<=7.3 is unsupported.
There is evidence that GCC 7.4 works.
I have verified that GCC 7.5 is able to build `check-{llvm,clang,clang-tools,lldb,lld,polly,mlir,bolt}`,
but not flang due to at least `flang/Common/enum-class.h` and a `<charconv`> in a unittest.

Link: https://discourse.llvm.org/t/require-gcc-7-5-as-gcc-7-3-cannot-build-llvm/72310

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D156286

(cherry picked from commit 1e06b82bded69fe627d6cd62ecff236fca15f39b)


  Commit: e4ea24d2ab6e032263bf4c95022e5610b0c89c9f
      https://github.com/llvm/llvm-project/commit/e4ea24d2ab6e032263bf4c95022e5610b0c89c9f
  Author: Aaron Ballman <aaron at aaronballman.com>
  Date:   2023-08-07 (Mon, 07 Aug 2023)

  Changed paths:
    M llvm/docs/GettingStarted.rst

  Log Message:
  -----------
  Remove stale info and fix superscript numbering

This amends 1e06b82bded69fe627d6cd62ecff236fca15f39b

(cherry picked from commit 80e80fa79bf66a74caf959bc420823e2b544dee9)


  Commit: 44ce1f829921b63712ed43ad743680a75befcf6d
      https://github.com/llvm/llvm-project/commit/44ce1f829921b63712ed43ad743680a75befcf6d
  Author: Richard Smith <richard at metafoo.co.uk>
  Date:   2023-08-07 (Mon, 07 Aug 2023)

  Changed paths:
    M clang/docs/ReleaseNotes.rst
    M clang/lib/Serialization/ASTReaderDecl.cpp

  Log Message:
  -----------
  Commit to a primary definition for a class when we load its first
member.

Previously, we wouldn't do this if the first member loaded is within a
definition that's added to a class via an update record, which happens
when template instantiation adds a class definition to a declaration
that was imported from an AST file.

This would lead to classes having member functions whose getParent
returned a class declaration that wasn't the primary definition, which
in turn caused the vtable builder to build broken vtables.

I don't yet have a reduced testcase for the wrong-code bug here, because
the setup required to get us into the broken state is very subtle, but
have confirmed that this fixes it.

(cherry picked from commit 61c7a9140becb19c5b1bc644e54452c6f782f5d5)


  Commit: 79d850a1d19bb298337d08de2187cc11fc75318c
      https://github.com/llvm/llvm-project/commit/79d850a1d19bb298337d08de2187cc11fc75318c
  Author: Yeting Kuo <yeting.kuo at sifive.com>
  Date:   2023-08-07 (Mon, 07 Aug 2023)

  Changed paths:
    M llvm/lib/Target/RISCV/RISCVFrameLowering.cpp
    M llvm/test/CodeGen/RISCV/callee-saved-gprs.ll

  Log Message:
  -----------
  [RISCV] Use max pushed register to get pushed register number.

Previously we used the number of registers needed saved and pushable as the
number of pushed registers. We also use pushed register number to caculate
the stack size. It is not correct because Zcmp pushes registers from $ra to the
max register needed saved and there is no gurantee that the needed saved
registers are a sequenced list from $ra.

There is an example about that. PushPopRegs should be 6 (ra,s0 - s4)= instead of 1.
```
; llc -mtriple=riscv32 -mattr=+zcmp
define void @foo() {
entry:
; Old:    .cfi_def_cfa_offset 16
; New:    .cfi_def_cfa_offset 32
  tail call void asm sideeffect "li s4, 0", "~{s4}"()
  ret void
}
```

Reviewed By: Jim, kito-cheng

Differential Revision: https://reviews.llvm.org/D156407

(cherry picked from commit f68c6879ad0e08e6509b89f60ed436d3be409f9c)


  Commit: 219cef0881be0088c77e326eb4ab22d58bca28a5
      https://github.com/llvm/llvm-project/commit/219cef0881be0088c77e326eb4ab22d58bca28a5
  Author: Christian Trott <crtrott at sandia.gov>
  Date:   2023-08-07 (Mon, 07 Aug 2023)

  Changed paths:
    M libcxx/include/__mdspan/layout_left.h
    M libcxx/test/std/containers/views/mdspan/layout_left/stride.pass.cpp

  Log Message:
  -----------
  [libc++][mdspan] Fix layout_left::stride(r)

It was using the stride calculation of layout_right.

Reviewed By: philnik

Differential Revision: https://reviews.llvm.org/D157065

(cherry picked from commit 0f4d7d81c9d08512a3871596fa2a14b737233c80)


  Commit: 1d07708c186f249074973e62878e99c326aeaa59
      https://github.com/llvm/llvm-project/commit/1d07708c186f249074973e62878e99c326aeaa59
  Author: Konstantin Varlamov <varconsteq at gmail.com>
  Date:   2023-08-07 (Mon, 07 Aug 2023)

  Changed paths:
    M libcxx/test/std/input.output/iostream.format/print.fun/no_file_description.pass.cpp
    M libcxx/test/std/input.output/iostream.format/print.fun/print.sh.cpp
    M libcxx/test/std/input.output/iostream.format/print.fun/println.sh.cpp
    M libcxx/test/std/input.output/iostream.format/print.fun/vprint_nonunicode.sh.cpp
    M libcxx/test/std/input.output/iostream.format/print.fun/vprint_unicode.sh.cpp
    M libcxx/test/std/language.support/support.limits/support.limits.general/print.version.compile.pass.cpp
    M libcxx/utils/generate_feature_test_macro_components.py
    M libcxx/utils/libcxx/test/header_information.py

  Log Message:
  -----------
  [libc++][print] Make `<print>` tests require file system support.

`print` functions require `FILE` and `stdout` to be available and cause
compilation errors on platforms that don't support the file system.

Differential Revision: https://reviews.llvm.org/D156585

(cherry picked from commit 1cf970db4e5499f6b38d9c6644935a78d758802c)


  Commit: a6bc75058b183a31e79e3c62577058972760e04a
      https://github.com/llvm/llvm-project/commit/a6bc75058b183a31e79e3c62577058972760e04a
  Author: Simon Tatham <simon.tatham at arm.com>
  Date:   2023-08-07 (Mon, 07 Aug 2023)

  Changed paths:
    M llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
    A llvm/test/CodeGen/Thumb2/jump-table-bti.ll

  Log Message:
  -----------
  Retain all jump table range checks when using BTI.

This modifies the switch-statement generation in SelectionDAGBuilder,
specifically the part that generates case clusters of type CC_JumpTable.

A table-based branch of any kind is at risk of being a JOP gadget, if
it doesn't range-check the offset into the table. For some types of
table branch, such as Arm TBB/TBH, the impact of this is limited
because the value loaded from the table is a relative offset of
limited size; for others, such as a MOV PC,Rn computed branch into a
table of further branch instructions, the gadget is fully general.

When compiling for branch-target enforcement via Arm's BTI system,
many of these table branch idioms use branch instructions of types
that do not require a BTI instruction at the branch destination. This
avoids the need to put a BTI at the start of each case handler,
reducing the number of available gadgets //with// BTIs (i.e. ones
which could be used by a JOP attack in spite of the BTI system). But
without a range check, the use of a non-BTI-requiring branch also
opens up a larger range of followup gadgets for an attacker's use.

A defence against this is to avoid optimising away the range check on
the table offset, even if the compiler believes that no out-of-range
value should be able to reach the table branch. (Rationale: that may
be true for values generated legitimately by the program, but not
those generated maliciously by attackers who have already corrupted
the control flow.)

The effect of keeping the range check and branching to an unreachable
block is that no actual code is generated at that block, so it will
typically point at the end of the function. That may still cause some
kind of unpredictable code execution (such as executing data as code,
or falling through to the next function in the code section), but even
if so, there will only be //one// possible invalid branch target,
rather than giving an attacker the choice of many possibilities.

This defence is enabled only when branch target enforcement is in use.
Without branch target enforcement, the range check is easily bypassed
anyway, by branching in to a location just after it. But with
enforcement, the attacker will have to enter the jump table dispatcher
at the initial BTI and then go through the range check. (Or, if they
don't, it's because they //already// have a general BTI-bypassing
gadget.)

Reviewed By: MaskRay, chill

Differential Revision: https://reviews.llvm.org/D155485

(cherry picked from commit 60b98363c7ed0a549be4d51ee07c32dc2bf47d2f)


  Commit: e96c444fd725661e6273d1708dfd10f2b6c3de6b
      https://github.com/llvm/llvm-project/commit/e96c444fd725661e6273d1708dfd10f2b6c3de6b
  Author: Steven Wu <stevenwu at apple.com>
  Date:   2023-08-07 (Mon, 07 Aug 2023)

  Changed paths:
    M llvm/lib/Object/SymbolSize.cpp

  Log Message:
  -----------
  [SymbolSize] Improve the performance of SymbolSize computation

The current algorithm to compute the symbol size is quadratic if there
are lots of symbols sharing the same addresses. This happens in a debug
build when lots of debug symbols get emitted in the symtab.

This patch improves the performance like `llvm-symbolizer` that relies
on the symbol size computation. Symbolizing a release+assert clang with
DebugInfo sees significant improvements from 3:40min to less than 1s.

Reviewed By: pete, mehdi_amini, arsenm, MaskRay

Differential Revision: https://reviews.llvm.org/D156603

(cherry picked from commit f5974e80653db977913bceffca7e900e818ef872)


  Commit: e67ec170e37423328d1b6b13ef27fbcca6de01c3
      https://github.com/llvm/llvm-project/commit/e67ec170e37423328d1b6b13ef27fbcca6de01c3
  Author: Jon Roelofs <jonathan_roelofs at apple.com>
  Date:   2023-08-07 (Mon, 07 Aug 2023)

  Changed paths:
    M clang/lib/ARCMigrate/CMakeLists.txt

  Log Message:
  -----------
  cmake: add missing dependencies on ClangDriverOptions tablegen

This is a follow-up to 2fb1c1082c01

(cherry picked from commit 3d756c32cdf005d0f4c05f561fec4a37b64b7ddd)


Compare: https://github.com/llvm/llvm-project/compare/d6417ad67d94...e67ec170e374


More information about the All-commits mailing list