Hi,
the test for the presence of variables (really symbols) does not work when you
add -Ox -flto to CFLAGS:
for v in $vars; do
AC_MSG_CHECKING([for $v])
AC_CACHE_VAL(libiberty_cv_var_$v,
[AC_LINK_IFELSE([AC_LANG_PROGRAM([[int *p;]],[[extern int $v []; p =
$v;]])],
Hi,
the patch for libiberty itself I posted is not sufficient to link the library
for MinGW platforms in LTO mode, as there is another link failures for stpcpy.
The symbol is both referenced by libiberty's pex-win32.c and provided by
libiberty's stpcpy.c so it needs to have a linkage to be resol
Outstanding but submitted patches:
* [Patch] OpenMP/Fortran: Handle polymorphic scalars in data-sharing
FIRSTPRIVATE [PR86470]
(March 10, 2021)
https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566529.html
* [Patch] OpenMP: Fix combined-target handling for lastprivate/reduction/linear
[PR99
Hi,
when a call to a function is inlined and takes a parameter whose type is not
gimple_reg, a variable is created in the caller to hold a copy of the argument
passed in the call with the following comment:
/* We may produce non-gimple trees by adding NOPs or introduce
invalid shar
On Fri, Apr 30, 2021 at 8:30 PM Richard Sandiford via Gcc-patches
wrote:
>
> "H.J. Lu via Gcc-patches" writes:
> > On Fri, Apr 30, 2021 at 5:49 AM H.J. Lu wrote:
> >>
> >> On Fri, Apr 30, 2021 at 5:42 AM Richard Sandiford
> >> wrote:
> >> >
> >> > "H.J. Lu via Gcc-patches" writes:
> >> > > On
On Sun, May 2, 2021 at 3:27 PM H.J. Lu wrote:
>
> On Tue, Mar 23, 2021 at 3:39 PM H.J. Lu wrote:
> >
> > Check if host supports multi-byte NOPs before enabling CET on host.
> >
> > config/
> >
> > PR binutils/27397
> > * cet.m4 (GCC_CET_HOST_FLAGS): Check if host supports multi-by
On Mon, May 3, 2021 at 9:51 AM Eric Botcazou wrote:
>
> Hi,
>
> the test for the presence of variables (really symbols) does not work when you
> add -Ox -flto to CFLAGS:
>
> for v in $vars; do
> AC_MSG_CHECKING([for $v])
> AC_CACHE_VAL(libiberty_cv_var_$v,
> [AC_LINK_IFELSE([AC_LAN
On Mon, May 3, 2021 at 9:58 AM Eric Botcazou wrote:
>
> Hi,
>
> the patch for libiberty itself I posted is not sufficient to link the library
> for MinGW platforms in LTO mode, as there is another link failures for stpcpy.
> The symbol is both referenced by libiberty's pex-win32.c and provided by
Prior to this commit GCC -O2 generated quite bad code for this
function:
bool f()
{
return __builtin_cpu_supports("popcnt")
&& __builtin_cpu_supports("ssse3");
}
f:
movl__cpu_model+12(%rip), %eax
xorl%r8d, %r8d
testb $4, %al
je .L1
On Fri, Apr 30, 2021 at 4:42 PM Jeff Law wrote:
>
>
> On 4/28/2021 10:26 PM, Alexandre Oliva wrote:
> > On Feb 22, 2021, Richard Biener wrote:
> >
> >> On Fri, Feb 19, 2021 at 9:08 AM Alexandre Oliva wrote:
> >>> Here's an improved version of the patch. Regstrapped on
> >>> x86_64-linux-gnu, wi
Hi!
The new DCE code inside of tree DSE removes in -fnon-call-exceptions
go code a load from NULL pointer the testcase relies on throwing an
exception and so the test hangs.
The following patch just repeats a check that e.g. tree-ssa-dce.c
uses to prevent this.
Bootstrapped/regtested on x86_64-l
On Fri, 30 Apr 2021, David Faust wrote:
>
> On 4/30/21 9:11 AM, Jose E. Marchesi via Gcc-patches wrote:
> >
> >>> For a moment, for the sake of this question, if we establish that CTF/BTF
> >>> generation always feeds off DWARF DIEs (so there is no need to access
> >>> type/decl tree nodes), wha
As GCC 11 is released and the development of GCC 12 begins I would like
to send this patch again.
It is basically unchanged since the previous submission in February. The
only change I made is fixing formatting by adding a space after gcc_assert.
Please note, that the original author of the co
Ping!
Ok for trunk?
I have looked at other patches, but none was patching any location I have
worked on previously. Therefore I can't return the favor of reviewing any
currently open patches and have to ask for volunteers here.
- Andre
On Mon, 26 Apr 2021 12:36:36 +0200
Andre Vehreschild via Fo
This patch fixes an issue in the compiler whereby a spurious
accessibility error regarding actuals for explicitly aliased formals in
a function call within a return statement gets triggered during
compilation when the return type of the function call in question has
implicit dereference specified.
When a function has "in out" parameters and a postcondition which does
not reference 'Result, a potentially spurious warning is emitted. The
necessary logic was actually already there in
Sem_Util.Check_Result_And_Post_State but was using a local
Has_In_Out_Parameter function instead of using simply
Compiler aborts on an aggregate with limited components, when the
aggregate is a formal in a function call that is the right-hand side of
an assignment, possibly coming from an object declaration.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* exp_aggr.adb (Expand_Array_Agg
When using e.g. pragma Assert (X'Initialized) combined with pragma
Restrictions (No_Implicit_Loops), a violation is flagged when assertions
are disabled, which is undesirable. Fixed by recognizing simple forms of
dead paths used by pragma Assert when assertions are disabled.
Tested on x86_64-pc-li
This patch fixes an issue in the compiler whereby extra flags and tests
added to the internally generated _postconditions procedure confused and
caused issues with CodePeer due to it treating the procedure as coming
from source.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
"exporting" a type may seem useless but is actually useful to set its
convention and sometimes its external name.
So simply remove this warning.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* sem_prag.adb (Set_Exported): Do not warn on exporting a type.diff --git a/gcc/ada
Compiler emits a warning on a selected component that is an actual in a
function call, when the enclosing object has no explicit initialization
and no discriminants, but the component type itself has partial
initialization. Such a warning should be suppressed.
Tested on x86_64-pc-linux-gnu, commi
Replace calls to Error_Msg_NE whose Msg parameters have no insertion
characters corresponding to the E parameter with equivalent but simpler
calls to Error_Msg_N. Code cleanup; behaviour is unaffected.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* freeze.adb (Freeze_Profil
Package GNAT.Case_Util contained routines renamed from System.Case_Util.
Few routines were missed. Renames entire package instead of renaming
each routine separately.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* libgnat/g-casuti.adb: Replace with "pragma No_Body".
Prefix of attributes Version and Body_Version denotes any program unit,
including protected entries, which were wrongly rejected this context.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* sem_attr.adb (Check_Program_Unit): Replace tests for Task_Kind
and Protected
Attributes Version and Body_Version can be prefixed by program units,
which include protected units and task units. Those attributes were
wrongly accepted when prefixed by protected subtype, task subtype and by
any object of a concurrent type.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc
Remove trailing space in calls to Error_Msg_N routines. Cleanup only.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* exp_disp.adb, sem_aggr.adb, sem_cat.adb, sem_ch10.adb,
sem_ch12.adb, sem_ch3.adb, sem_ch4.adb, sem_ch5.adb,
sem_ch6.adb, sem_ch8.adb, sem_ch9
When the prefix of a call denotes an overloaded primitive operation, all
possible interpretations are analyzed to determine the intended one. If
all of them fail, then if the All_Errors flag is on all interpretations
are analyzed anew to indicate why each one is illegal. If All_Errors is
not set th
Default initialization of a local Fname variable was never used. Code
cleanup only; semantics is unaffected.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* exp_dist.adb (Build_From_Any_Call): Remove initial value for
Fnam; fix style.
(Build_To_Any_Call): Rem
The current version of Set_String is no longer used and not very useful
and even unsafe with the introduction of a-stunau__shared.adb.
Replace it with a more useful and safer version taking a callback to set
the string.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* libgna
A local counter objects that are initialized with 0 and only incremented
now have type Nat instead of Int. Code cleanup; semantics is unaffected.
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* exp_ch7.adb (Build_Finalize_Statements): Refine type of a
local counter v
Replace expression of the form "X = RTE (...)" with "Is_RTE (X, ...)",
which avoids loading of the unit where the ... entity is defined. In
particular, a sequence of RTE_Available and RTE load the target unit
where Is_RTE doesn't.
This patch is primarily a code cleanup, but it also avoids unnecess
On Mon, 3 May 2021, Jakub Jelinek wrote:
> Hi!
>
> The new DCE code inside of tree DSE removes in -fnon-call-exceptions
> go code a load from NULL pointer the testcase relies on throwing an
> exception and so the test hangs.
>
> The following patch just repeats a check that e.g. tree-ssa-dce.c
>
The following changes the post-dominator domwalk done by GIMPLE DSE
to a reverse program order walk. This enables 2% more stmts do be
DSEd during bootstrap and in particular for testcases like the one
added where it is important to visit post dominators in a particular
order.
Bootstrapped on x86_
Hi,
The test-case included in this patch contains this target region:
...
for (int i0 = 0 ; i0 < N0 ; i0++ )
counter_N0.i += 1;
...
When running with nvptx accelerator, the counter variable is expected to
be N0 after the region, but instead is N0 / 32. The problem is that rather
than getti
On Mon, May 03, 2021 at 12:24:10PM +0200, Tom de Vries wrote:
> The test-case included in this patch contains this target region:
> ...
> for (int i0 = 0 ; i0 < N0 ; i0++ )
> counter_N0.i += 1;
> ...
>
> When running with nvptx accelerator, the counter variable is expected to
> be N0 after t
Hi Stafford, All,
I've backported this patchset for Buildroot to versions:
- 9.3.0
- 10.3.0
Does it make sense to send them? I don't know if those version will have
minor versions where these backported patches can be applied.
Best regards
--
Giulio Benetti
Benetti Engineering sas
On 5/1/21
On Fri, 2021-04-30 at 08:49 +0200, Andreas Krebbel wrote:
> On 4/28/21 3:48 AM, Ilya Leoshkevich wrote:
> > Bootstrapped and regtested on s390x-redhat-linux. Tested with
> > valgrind
> > too (PR 100278 is now fixed). Ok for master?
> >
> > v1:
> > https://gcc.gnu.org/pipermail/gcc-patches/2021-A
On Mon, May 3, 2021 at 11:02 AM Eric Botcazou wrote:
>
> Hi,
>
> when a call to a function is inlined and takes a parameter whose type is not
> gimple_reg, a variable is created in the caller to hold a copy of the argument
> passed in the call with the following comment:
>
> /* We may produc
On Thu, 29 Apr 2021, Bernd Edlinger wrote:
> Hi!
>
>
> I've re-based and re-tested this patch on current trunk.
> Otherwise the patch is unchanged, from the previous v2 version.
>
> This patch is fixing two issues with functions where we
> do not have proper debug info:
>
> 1. Functions withou
On Thu, 29 Apr 2021, Jiufu Guo wrote:
> When there is the possibility that overflow may happen on the loop index,
> a few optimizations would not happen. For example code:
>
> foo (int *a, int *b, unsigned k, unsigned n)
> {
> while (++k != n)
> a[k] = b[k] + 1;
> }
>
> For this code, if
This improves handling of PHI defs when walking uses in
dse_classify_store to track two PHI defs. This happens
when there are CFG merges and one PHI feeds into another.
If we decide to want more then using a sbitmap for this might be
the way to go.
Bootstrapped and tested on x86_64-unknown-linux-
There is -fdelete-dead-exceptions now and we're tracking
nothrow and const/pure bits separately and I do remember that
const or pure does _not_ imply nothrow.
Now, in the light of the PR100382 fix which added a
stmt_unremovable_because_of_non_call_eh_p guard to DSEs "DCE"
I wondered how -fdelete-d
> note that if you wrap foo () into another noinline
> wrap_foo () { foo (); return 1; } function then we need to make
> sure to not DCE this call either even though it only throws
> externally. Now the question is whether this testcase is valid
> (it should not abort). The documentation of 'pure
On 3/23/21 9:04 AM, Thomas Schwinge wrote:
> From eac0d3458f38cd5bb4c930b2887a547b64b046ef Mon Sep 17 00:00:00 2001
> From: Thomas Schwinge
> Date: Wed, 13 Jan 2021 09:04:47 +0100
> Subject: [PATCH] [nvptx] Let nvptx-as figure out the target architecture
> [PR97348]
>
> ... now that it has been
On Mon, 3 May 2021, Jan Hubicka wrote:
> > note that if you wrap foo () into another noinline
> > wrap_foo () { foo (); return 1; } function then we need to make
> > sure to not DCE this call either even though it only throws
> > externally. Now the question is whether this testcase is valid
> >
> So - what is it? Are pure functions allowed to throw or not?
We keep going back to this every N years and I'm not sure why... In Ada the
answer is definitely yes, we have entire library units marked Pure and thus
containing bunch of pure functions but they can throw like any other function.
On Mon, 3 May 2021, Eric Botcazou wrote:
> > So - what is it? Are pure functions allowed to throw or not?
>
> We keep going back to this every N years and I'm not sure why... In Ada the
> answer is definitely yes, we have entire library units marked Pure and thus
> containing bunch of pure fu
Hello,
On Mon, 3 May 2021, Jan Hubicka wrote:
> > (it should not abort). The documentation of 'pure' must be read
> > as that 'pure' is not valid for 'foo' since throwing an exception
> > is obviously an observable effect on the state of the program
> > (in particular for the testcase at hand).
On Mon, 3 May 2021, Michael Matz wrote:
> Hello,
>
> On Mon, 3 May 2021, Jan Hubicka wrote:
>
> > > (it should not abort). The documentation of 'pure' must be read
> > > as that 'pure' is not valid for 'foo' since throwing an exception
> > > is obviously an observable effect on the state of the
> Yes, I prefer the configure fix too. If we state we require C99 in
> binutils then we ought to be able to use C99..
>
> Nick, does the configure.ac change also need to go in all subdirs, to
> support people running make in say ld/ rather than running make in the
> top build dir?
For GDB, it's
Hi,
on s390 a warning test fails:
inline int ATTR ((cold, aligned (8)))
finline_hot_noret_align (int);
inline int ATTR ((warn_unused_result))
finline_hot_noret_align (int);
inline int ATTR ((aligned (4)))
finline_hot_noret_align (int); /* { dg-warning "ignoring attribute
.aligned \\(4\\).
Richi's recent work twiddles dse1's actions for these targets. This
patch just updates the expected output. I'll keep an eye on other
targets as their results trickle in.
Committed to the trunk,
Jeff
commit 4d8a13cad842e7822fa29d0aa93799033a0f7847
Author: Jeff Law
Date: Mon May 3 07:5
> Hmm, instead of (ab-)using debug_map can we instead use sth like setting
> TREE_VISITED on the argument decl (not the value - it might be passed
> multiple tiimes)? IIRC TREE_VISITED state is undetermined thus we can
> clear it at the start of setup_one_parameter and set it when we want to
> avo
Following up, this patch removes the s390-specific check for the warning
and adds a new test.
Is it OK after the common-code changes are in?
Regards
Robin
--
gcc/testsuite/ChangeLog:
* c-c++-common/Wattributes.c: Remove s390-specific case and new
test.
* gcc.dg/Wattributes
On Mon, May 03, 2021 at 11:21:10AM +0200, Andre Vehreschild wrote:
> Ping!
>
> Ok for trunk?
>
> I have looked at other patches, but none was patching any location I have
> worked on previously. Therefore I can't return the favor of reviewing any
> currently open patches and have to ask for volun
On 4/28/21 9:53 PM, Marek Polacek wrote:
This patch removes a FIXME I left for myself for GCC 12, along with
adjusting the relevant test.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
OK.
gcc/cp/ChangeLog:
DR 1312
* constexpr.c (cxx_eval_constant_expression):
On 4/30/21 2:53 PM, Patrick Palka wrote:
My r11-295 patch for PR68942 didn't consider that the callee of an
ADL-eligible function call can be a TEMPLATE_ID_EXPR, and we don't want
to disable mark_used when substituting into the template arguments of
this TEMPLATE_ID_EXPR because the arguments are
> "Simon" == Simon Marchi via Gcc-patches writes:
Simon> For GDB, it's not supported to run gdb/configure directly, you need to
Simon> use the top-level configure. Is it supported from some of the other
Simon> projects in the repo?
It can be done sometimes but I think it isn't really a scen
On 4/28/21 4:55 PM, Marek Polacek wrote:
This fixes a crash on invalid requires-expression: in this test,
current_template_parms is null so accessing TEMPLATE_PARMS_CONSTRAINTS
is going to fail. So don't crash, but make sure we've complained
already.
Bootstrapped/regtested on x86_64-pc-linux-gn
Jakub Jelinek writes:
> The new DCE code inside of tree DSE removes in -fnon-call-exceptions
> go code a load from NULL pointer the testcase relies on throwing an
> exception and so the test hangs.
>
> The following patch just repeats a check that e.g. tree-ssa-dce.c
> uses to prevent this.
Than
From: Thomas Rodgers
This should also be backported to gcc-11
libstdc++/ChangeLog:
* include/bits/atomic_wait.h (__waiter::_M_do_wait_v): loop
until observe value change.
(__waiter_base::_M_laundered): New member.
(__watier_base::_M_notify): Check _M_laundered to
My r11-6815 change to defer access checking when processing a
base-clause removed a pair of pushclass / popclass calls that seemed to
be unnecessary now that we'd also defer access checking while parsing
the base-clause.
But it turns out this makes a difference in the below testcase, where we
have
On 5/3/21 12:48 PM, Patrick Palka wrote:
My r11-6815 change to defer access checking when processing a
base-clause removed a pair of pushclass / popclass calls that seemed to
be unnecessary now that we'd also defer access checking while parsing
the base-clause.
But it turns out this makes a diff
On 5/3/21 12:31 PM, Jakub Jelinek wrote:
> On Mon, May 03, 2021 at 12:24:10PM +0200, Tom de Vries wrote:
>> The test-case included in this patch contains this target region:
>> ...
>> for (int i0 = 0 ; i0 < N0 ; i0++ )
>> counter_N0.i += 1;
>> ...
>>
>> When running with nvptx accelerator, th
On Mon, May 03, 2021 at 07:03:24PM +0200, Tom de Vries wrote:
> + if (sctx->is_simt && !known_eq (sctx->max_vf, 1U))
> + {
> + tree c = omp_find_clause (gimple_omp_for_clauses (ctx->stmt),
> + OMP_CLAUSE_REDUCTION);
> + if (c && OMP_CLAUSE_REDUCT
On Sat, May 01, 2021 at 01:12:15AM +0200, Tobias Burnus wrote:
> gcc/c/ChangeLog:
>
> * c-typeck.c (c_finish_omp_clauses): Accept float + complex for || and
> &&
> reductions.
>
> gcc/cp/ChangeLog:
>
> * semantics.c (finish_omp_reduction_clause): Accept float + complex for
>
On Linux/x86_64,
ed3c43224cc4e378dbab066122bc63536ccb1276 is the first bad commit
commit ed3c43224cc4e378dbab066122bc63536ccb1276
Author: Richard Biener
Date: Mon May 3 09:17:55 2021 +0200
Perform reverse program order walk for GIMPLE DSE
caused
FAIL: gcc.dg/tree-ssa/ssa-dse-26.c scan-tr
Is it too early to consider this patch ? Or just lack of time ?
Considering the patch I would really appreciate that, if validated, it
gets in as early as possible in next release.
Thanks,
François
On 24/04/21 3:46 pm, François Dumont wrote:
Hi
Here is the patch to add backtrace generat
dg-do must come before dg-skip-if, this patch fixes this oversight in
these two tests.
Committed as obvious.
2021-05-03 Christophe Lyon
gcc/testsuite/
* gcc.target/aarch64/advsimd-intrinsics/vmla_float_not_fused.c:
Fix dg directives order.
* gcc.target/aarch64/
On 03/05/21 22:17 +0200, François Dumont via Libstdc++ wrote:
Is it too early to consider this patch ? Or just lack of time ?
I haven't had time to review it yet, but my general feeling hasn't
changed. I still don't like the idea of executing additional code
after undefined behaviour is detecte
Ping:
https://gcc.gnu.org/pipermail/gcc-patches/2021-April/568901.html
On 4/27/21 9:52 AM, Martin Sebor wrote:
On 4/27/21 8:04 AM, Richard Biener wrote:
On Tue, Apr 27, 2021 at 3:59 PM Martin Sebor wrote:
On 4/27/21 1:58 AM, Richard Biener wrote:
On Tue, Apr 27, 2021 at 2:46 AM Martin Sebo
On Mon, May 03, 2021 at 10:47:15AM -0400, Simon Marchi wrote:
> > Yes, I prefer the configure fix too. If we state we require C99 in
> > binutils then we ought to be able to use C99..
> >
> > Nick, does the configure.ac change also need to go in all subdirs, to
> > support people running make in
On 2021-05-03 5:51 p.m., Alan Modra wrote:
> I wasn't talking about running configure, I was talking about running
> make. For example, you configure and make binutils as usual, then
> after making a change to ld/ files, run make in the ld build dir. I
> don't tend to do that myself but I do run
On May 3, 2021, Richard Biener wrote:
> On Fri, Apr 30, 2021 at 4:42 PM Jeff Law wrote:
>>
>>
>> On 4/28/2021 10:26 PM, Alexandre Oliva wrote:
>> > On Feb 22, 2021, Richard Biener wrote:
>> >
>> >> On Fri, Feb 19, 2021 at 9:08 AM Alexandre Oliva wrote:
>> >>> Here's an improved version of t
x86-vx7r2 needs svr4_dbx_register_map, but the default in i386/i386.h
was dbx_register_map, partially swapping ebp and esp in unwind info.
i386/vxworks.h had a correct overrider, but it was conditional for
vxworks < 7. This patch reenables the overrider unconditionally.
Tested on x86_64-linux-
This patch adds ctype and locale support to libstdc++ on vxworks7.
We've been using this for a while internally. It was tested with
various vx7r2 targets. Ok to install?
From: Corentin Gay
for libstdc++-v3/ChangeLog
* acinclude.m4: Add VxWorks-specific case for the
configu
On Tue, 4 May 2021 at 07:30, Alexandre Oliva wrote:
>
> On May 3, 2021, Richard Biener wrote:
>
> > On Fri, Apr 30, 2021 at 4:42 PM Jeff Law wrote:
> >>
> >>
> >> On 4/28/2021 10:26 PM, Alexandre Oliva wrote:
> >> > On Feb 22, 2021, Richard Biener wrote:
> >> >
> >> >> On Fri, Feb 19, 2021 at
On 03/05/21 11:06 pm, Jonathan Wakely wrote:
On 03/05/21 22:17 +0200, François Dumont via Libstdc++ wrote:
Is it too early to consider this patch ? Or just lack of time ?
I haven't had time to review it yet, but my general feeling hasn't
changed. I still don't like the idea of executing additi
On May 4, 2021, Prathamesh Kulkarni wrote:
> It looks like constfun's prototype had a typo with missing 2nd param for void
> *.
Ugh, the patch for https://gcc.gnu.org/PR90773 added the param the day
after I retested the patch, and I did not give it yet another spin
before checking it in :-(
>
On 3/23/21 9:04 AM, Thomas Schwinge wrote:
> What is your opinion about backporting that (plus Tobias' documentation
> update, plus corresponding web 'changes.html' updates?) to release
> branches, so that nvptx offloading users may use GCC 10/9/8 with CUDA
> 11.0+?
Hmm, so you're talking about ma
80 matches
Mail list logo
