Hello, Sebastian,
On Jun 22, 2022, Sebastian Huber wrote:
> On 22/06/2022 08:24, Alexandre Oliva via Libstdc++ wrote:
>> rtems6's rename() implementation errors with EEXIST when the rename-to
>> filename exists, even when renaming a file to itself or when renaming
>> a nonexisting file. Adjust
On Wed, Jun 22, 2022 at 04:17:45AM +0200, Mohamed Atef wrote:
> I forgot the DCO line. And I edited the commit message, but I can't push,
> even forced push doesn't work.
No, once you push, it will remain as is.
Don't forget next time...
Jakub
On Tue, Jun 21, 2022 at 11:59:56PM -0400, Jason Merrill wrote:
> PR c++/104642
>
> gcc/ChangeLog:
>
> * common.opt: Add -funreachable-traps.
> * doc/invoke.texi (-funreachable-traps): Document it.
> * opts.cc (finish_options): Enable at -O0 or -Og.
> * tree.cc (build
Hi,
This patch uses CC instead of CCFP for all BCD operations. Thus, infinite
math flag has no impact on BCD operations. To support BCD overflow and
invalid coding, an UNSPEC is defined to move the bit to a general register.
The patterns of condition branch and return with overflow bit are define
Hello,
On Mon, Jun 20, 2022 at 04:05:17PM -0700, Andrew Pinski wrote:
> > new file mode 100644
> > index 000..e8f1044a36b
> > --- /dev/null
> > +++ b/gcc/testsuite/c-c++-common/Wpadded.c
> > @@ -0,0 +1,10 @@
> > +/* { dg-do compile } */
> > +/* { dg-options "-Wpadded" } */
> > +
> > +/*
>
Alexandre Oliva writes:
> On Jun 21, 2022, Richard Sandiford wrote:
>
>> Could we instead have a new target selector for whether the memory
>> map includes xGB of RAM?
>
> How about this? Testing on aarch64-rtems6.0. Ok to install?
>
>
> aarch64: testsuite: symbol-range fallback to compile
>
>
On Wed, Jun 22, 2022 at 1:34 AM Vit Kabele wrote:
>
> Hello,
>
> On Mon, Jun 20, 2022 at 04:05:17PM -0700, Andrew Pinski wrote:
> > > new file mode 100644
> > > index 000..e8f1044a36b
> > > --- /dev/null
> > > +++ b/gcc/testsuite/c-c++-common/Wpadded.c
> > > @@ -0,0 +1,10 @@
> > > +/* { dg
On 22/06/2022 08:22, Sebastian Huber wrote:
On 22/06/2022 08:01, Alexandre Oliva via Gcc-patches wrote:
On rtems under qemu, the frequently-interrupted nanosleep ends up
sleeping shorter than expected, by a margin of less than 0,3%.
I figured failing the library test over a system (emulator?)
On Wed, 22 Jun 2022 at 06:25, Alexandre Oliva via Libstdc++
wrote:
>
>
> Networking functions that net_ts tests rely on are defined in libbsd
> on RTEMS, so link with it.
>
> Regstrapped on x86_64-linux-gnu, also tested with a cross to
> aarch64-rtems6. Ok to install?
OK, thanks.
On Wed, 22 Jun 2022 at 06:26, Alexandre Oliva via Libstdc++
wrote:
>
>
> Though sleep, nanosleep and clock_nanosleep are all POSIX cancellation
> points, not all target systems follow this POSIX requirement.
> 30_threads/thread/native_handle/cancel.cc will run until it times out
> on such systems.
On Wed, 22 Jun 2022 at 07:05, Alexandre Oliva via Libstdc++
wrote:
>
>
> This patch was originally meant to reduce the likelihood that
> nonexistent_path() returns the same pathname for from and to.
>
> It was prompted by a target system with a non-random implementation of
> mkstemp, that returns
On Wed, 22 Jun 2022 at 07:14, Alexandre Oliva via Libstdc++
wrote:
>
>
> Several filesystem tests expect to be able to create symlinks even
> when !defined (_GLIBCXX_HAVE_SYMLINK), and fail predictably, reducing
> the amount of testing of other filesystem features.
>
> They are already skipped for
On Wed, 22 Jun 2022 at 07:20, Alexandre Oliva via Libstdc++
wrote:
>
>
> On some target systems (e.g. rtems6.0), removing directory components
> while iterating over directory entries may cause some of the directory
> entries to be skipped, which prevents the removal of the parent
> directory from
On Wed, 22 Jun 2022 at 07:28, Alexandre Oliva via Libstdc++
wrote:
>
>
> The do_space function is defined in ways that are useful, or that fail
> immediately, depending on various macros. When it fails immediately,
> the filesystem space.cc tests fail noisily, but the fail is entirely
> expected.
On Wed, 22 Jun 2022 at 07:43, Alexandre Oliva via Libstdc++
wrote:
>
>
> rtems6.0 has fdopendir, and fcntl.h defines AT_FDCWD and declares
> openat, but there's no openat in libc. Adjust dir-common.h to not
> assume ::openat just because of AT_FDCWD.
>
> Regstrapped on x86_64-linux-gnu (detects a
On Wed, 22 Jun 2022 at 08:02, Alexandre Oliva via Libstdc++
wrote:
>
> Hello, Sebastian,
>
> On Jun 22, 2022, Sebastian Huber wrote:
>
> > On 22/06/2022 08:24, Alexandre Oliva via Libstdc++ wrote:
> >> rtems6's rename() implementation errors with EEXIST when the rename-to
> >> filename exists, ev
On Wed, 22 Jun 2022 at 10:25, Jonathan Wakely wrote:
>
> On Wed, 22 Jun 2022 at 07:14, Alexandre Oliva via Libstdc++
> wrote:
> >
> >
> > Several filesystem tests expect to be able to create symlinks even
> > when !defined (_GLIBCXX_HAVE_SYMLINK), and fail predictably, reducing
> > the amount of t
On Wed, 22 Jun 2022 at 07:35, Alexandre Oliva via Libstdc++
wrote:
>
>
> The last_write_time functions are defined in ways that are useful, or
> that fail immediately, depending on various macros. When they fail
> immediately, the filesystem last_write_time.cc tests fail noisily, but
> the fail i
> @Honza: PING
>
> On 5/20/22 09:46, Martin Liška wrote:
> > On 5/19/22 17:02, Jan Hubicka wrote:
> >>> Similarly to cgraph_nodes, it may happen that body_removed is set
> >>> during merging of symbols.
> >>>
> >>> PR ipa/105600
> >>>
> >>> Patch can bootstrap on x86_64-linux-gnu and survives re
This patch addresses PR target/105930 which is an ia32 stack frame size
regression in high-register pressure XOR-rich cryptography functions
reported by Linus Torvalds. The underlying problem is once the limited
number of registers on the x86 are exhausted, the register allocator
has to decide wh
On Tue, Jun 21, 2022 at 11:03 PM H.J. Lu via Gcc-patches
wrote:
>
> When memchr is applied on a constant string of no more than the bytes of
> a word, inline memchr by checking each byte in the constant string.
>
> int f (int a)
> {
>return __builtin_memchr ("eE", a, 2) != 0;
> }
>
> is simpl
Hello,
I added the ! default_packed directive, and now the test is properly
skipped on the targets with that property. I tested with cris-elf
target and the test behaves properly.
Best regards,
Vit Kabele
-- >8 --
Subject: [PATCH v2] c: Extend the -Wpadded message with actual padding size
When t
The only reason I chose to use DECL_UID on this hash table was to make
it stable against ASLR and perturbations due to other allocations.
It's not required for correctness, as the comment mentions the
equality fn uses pointer identity.
nathan
--
Nathan SidwellFrom d844478ab47a16c8ae65f253fd1cdc6
Hi,
This patch merges the D front-end with upstream dmd 6203135dc, and the D
run-time library with upstream druntime e150cca1, and phobos a4a18d21c.
D front-end changes:
- Input parameters can now be applied on extern(C++) functions to
bind to `const &' when the `-fpreview=in' flag is
On Wed, Jun 22, 2022 at 4:39 AM Richard Biener
wrote:
>
> On Tue, Jun 21, 2022 at 11:03 PM H.J. Lu via Gcc-patches
> wrote:
> >
> > When memchr is applied on a constant string of no more than the bytes of
> > a word, inline memchr by checking each byte in the constant string.
> >
> > int f (int a
Hi,
Since around GCC 10, the condition `j < (INTMAX_MAX / 10)' will get
optimized into `j != 922337203685477580', which will result in an
infinite loop for certain inputs of `j'.
This patch just copies the condition already used by the -DTILEPRO
generator code, which doesn't fall into the same tr
On 6/22/2022 11:30 AM, Iain Buclaw via Gcc-patches wrote:
Hi,
Since around GCC 10, the condition `j < (INTMAX_MAX / 10)' will get
optimized into `j != 922337203685477580', which will result in an
infinite loop for certain inputs of `j'.
This patch just copies the condition already used by th
On Linux/x86_64,
038b077689bb5310386b04d40a2cea234f01e6aa is the first bad commit
commit 038b077689bb5310386b04d40a2cea234f01e6aa
Author: Richard Sandiford
Date: Wed Jun 22 11:27:15 2022 +0100
data-ref: Improve non-loop disambiguation [PR106019]
caused
FAIL: gcc.dg/tree-ssa/slsr-39.c sca
> On 22 Jun 2022, at 01:36, Alexandre Oliva via Gcc-patches
> wrote:
>
> On Jun 21, 2022, Fangrui Song wrote:
>
>> Is this similar to clang -nostdlib++ ?
>> When libstdc++ is selected, clang -nostdlib++ removes -lstdc++.
>
> Sounds like they're the same indeed, but the clang option you men
Hello, Eric,
On Jun 21, 2022, Eric Gallager wrote:
> https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596654.html
> (cc-ing the build machinery maintainers listed in MAINTAINERS this time)
Thanks
> On Tue, Jun 14, 2022 at 3:51 PM Eric Gallager wrote:
>> So, in investigating PR target/3442
In r12-1273 for PR91706, I removed the code in get_class_binding that
stripped BASELINK. This testcase demonstrates that we still need to strip
it in outer_binding before putting the overload set in IDENTIFIER_BINDING,
for compatibility with bindings added directly for declarations.
Tested x86_64
gcc/ChangeLog:
* diagnostic-core.h (emit_diagnostic): New overload.
(emit_diagnostic_valist): New overload.
* diagnostic.cc (emit_diagnostic): New overload.
(emit_diagnostic_valist): New overload.
Signed-off-by: David Malcolm
---
gcc/diagnostic-core.h | 7 +++
Obviously this isn't quite ready for trunk yet.
libcpp/ChangeLog:
* include/line-map.h (rich_location::maybe_add_fixit): Make
public.
* line-map.cc (linemap_add): Hack away assertion about LC_RENAME
for now.
Signed-off-by: David Malcolm
---
libcpp/include/line-ma
gcc/ChangeLog:
* common.opt (fdiagnostics-show-rules): New option.
* diagnostic-format-json.cc (diagnostic_output_format_init_json):
Fix up context->show_rules.
* diagnostic-format-sarif.cc
(diagnostic_output_format_init_sarif): Likewise.
* diagnostic
We currently have a couple of formats into which our diagnostics can
be serialized: (a) gcc's own json format and (b) SARIF, via:
-fdiagnostics-format=json-stderr (and -fdiagnostics-format=json)
-fdiagnostics-format=json-file
-fdiagnostics-format=sarif-stderr
-fdiagnostics-format=sarif-fil
gcc/ChangeLog:
* diagnostic-client-data-hooks.h
(class diagnostic_client_plugin_info): Move to...
* diagnostic-client-plugin.h: ...this new file.
* diagnostic-format-sarif.cc: Include "diagnostic-client-plugin.h".
(class sarif_tool_component): New class.
libcpp requires locations to be created as if by a tokenizer, creating
them by filename, in ascending order of line/column.
This patch adds support classes that allow the creation of locations
in arbitrary orders, by deferring all location creation,
grouping things up by filename/line, and then cr
This patch adds classes that better integrate the JSON parser with
GCC's diagnostic subsystem (e.g. line_maps).
gcc/ChangeLog:
* json-reader.cc: New file.
* json-reader.h: New file.
Signed-off-by: David Malcolm
---
gcc/json-reader.cc | 122 +++
I believe these are needed by one of the rule-handling patches.
gcc/ChangeLog:
* diagnostic-format-sarif.cc (sarif_builder::sarif_builder):
Defer population of m_driver_obj until...
(sarif_builder::make_tool_object): ...here.
(sarif_builder::make_driver_tool_compone
Doing so allows for multiline directives to contain things like
"note: " which would otherwise already have been pruned.
gcc/testsuite/ChangeLog:
* lib/prune.exp (prune_gcc_output): Move multiline-handling to
before other pruning.
Signed-off-by: David Malcolm
---
gcc/testsuite/l
This work-in-progress hacks up the file_cache code in input.cc so that
it can have an optional path remapper, which can map e.g. paths in a
.sarif file to paths relative to that .sarif file, so that the
sarif-replayer can locate and display sources.
gcc/ChangeLog:
* input.cc (file_cache::g
This patch implements JSON parsing support.
It's based on the parsing parts of the patch I posted here:
https://gcc.gnu.org/legacy-ml/gcc-patches/2017-08/msg00417.html
with the parsing moved to a separate source file and header, and heavily
rewritten to capture source location information for JS
This patch adds a new json frontend: json-replayer, which the gcc driver
can invoke on .json files saved with -fdiagnostics-format=json-file.
gcc/ChangeLog:
* json/Make-lang.in: New file.
* json/config-lang.in: New file.
* json/json-frontend.cc: New file.
* json/jso
On Jun 22, 2022, Iain Sandoe wrote:
> It makes some sense to have the option named -nostdlib++ if a target
> might add multiple libs (and/or make other changes) for linking C++.
if it was nostdlibc++, I'd agree. lib++ is not something that brings
C++ to (my) mind.
> (so, fo example, if libstdc
On Wed, Jun 22, 2022 at 4:29 PM Alexandre Oliva wrote:
>
> On Jun 22, 2022, Iain Sandoe wrote:
>
> > It makes some sense to have the option named -nostdlib++ if a target
> > might add multiple libs (and/or make other changes) for linking C++.
>
> if it was nostdlibc++, I'd agree. lib++ is not so
On Jun 22, 2022, Sebastian Huber wrote:
> The clock_nanosleep() uses the coarse resolution
Thanks for looking into this. So, is it missing a rounding-up to ensure
the sleep time is >= the requested time, or is it even more elaborate
than that?
--
Alexandre Oliva, happy hackerh
On Jun 22, 2022, Sebastian Huber wrote:
> The clock_nanosleep() uses the coarse resolution which may give a time
> before now().
Uhh, sorry, hit send too early.
I also meant to ask whether you'd like me to file an RTEMS ticket about
this issue.
--
Alexandre Oliva, happy hacker
On Jun 22, 2022, Jonathan Wakely wrote:
> It looks like it would be possible for this to livelock.
True
> The current
> implementation will fail with an error in that case, rather than
> getting stuck forever in a loop.
In the equivalent livelock scenario, newly-added dir entries are added
to
<>
Hi,
Gentle ping https://gcc.gnu.org/pipermail/gcc-patches/2022-May/594699.html
BR,
Kewen
> on 2022/5/13 13:29, Kewen.Lin via Gcc-patches wrote:
>> Hi,
>>
>> PR105485 exposes that new builtin function framework doesn't handle
>> unresolved overloaded builtin function well. With new builtin
>> f
Hi,
Gentle ping https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595208.html
BR,
Kewen
>> Hi,
>>
>> As PR104482 shown, it's one regression about the handlings when
>> the argument number is more than the one of built-in function
>> prototype. The new bif support only catches the case that the
Hi,
Gentle ping https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595209.html
BR,
Kewen
>> Hi,
>>
>> As PR103353 shows, we may want to continue to expand a MMA built-in
>> function like a normal function, even if we have already emitted
>> error messages about some missing required conditions.
Hi,
Gentle ping https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596212.html
BR,
Kewen
on 2022/6/6 14:20, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> PR105459 exposes one issue in inline_call handling that when it
> decides to copy FP flags from callee to caller and rebuild the
> optimization
There is a corner case for speculative multiple targets, that if speculative
edges are streamed to different ltrans units, and then edges are expanded
in one ltrans unit but the speculative property is not cleared by
resolve_speculation in other ltrans unit finally cause ICE. This patch
fixes this
Fix typo and commit as obvious.
Signed-off-by: Xionghu Luo
gcc/ChangeLog:
* cgraph.cc (cgraph_edge::redirect_call_stmt_to_callee): Fix
typo.
* tree-ssa-loop-ivopts.cc (struct iv_cand): Likewise.
* tree-switch-conversion.h: Likewise.
---
gcc/cgraph.cc
helper::c isn't dependent just because we haven't deduced its return
type yet. type_dependent_expression_p already knows how to deal with that
for bare FUNCTION_DECL, but needs to learn to look through a BASELINK.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/105964
gcc/cp/Chang
While looking at PR105964 I noticed that we were unnecessarily repeating
the deduction loop because of seeing a non-type parameter with type 'auto'.
It is indeed dependent, but not on any other deductions.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
* pt.cc (type_uni
Hi:
This is follow-up to [1], return INVALID_REGNUM instead of gcc_assert,
also adjust some conditions guarded for reg_or_subregno.
>OK, but I think that reg_or_subregno should be improved to return
>INVALID_REGNUM when the subreg of memory is processed.
>
>Thanks,
>Uros.
[1] https://gcc.gnu.
On Jun 22, 2022, Jonathan Wakely wrote:
> On Wed, 22 Jun 2022 at 08:02, Alexandre Oliva via Libstdc++
> wrote:
>>
>> Hello, Sebastian,
>>
>> On Jun 22, 2022, Sebastian Huber wrote:
>>
>> > On 22/06/2022 08:24, Alexandre Oliva via Libstdc++ wrote:
>> >> rtems6's rename() implementation errors
On Jun 22, 2022, Jonathan Wakely wrote:
> P.S. there's a typo in the Subject: "symlnks" not "symlinks". I don't
> know if you intend to use that as the Git commit summary line.
Thanks, I would have, fixed. I ended up introducing the feature
abstraction macros in testsuite_fs.h, so I'll shortly
On Jun 22, 2022, Jonathan Wakely wrote:
> Otherwise, if rterms defines HAVE_DIRFD this function will return a
> file descriptor and a filename (not a full path) but then
> _Dir_base::openat doesn't use ::openat and so ignores the file
> descriptor, and needs a full path.
Yuck. It does. This ma
On Wed, Jun 22, 2022 at 7:13 PM H.J. Lu wrote:
>
> On Wed, Jun 22, 2022 at 4:39 AM Richard Biener
> wrote:
> >
> > On Tue, Jun 21, 2022 at 11:03 PM H.J. Lu via Gcc-patches
> > wrote:
> > >
> > > When memchr is applied on a constant string of no more than the bytes of
> > > a word, inline memchr
On Jun 22, 2022, Jonathan Wakely wrote:
> "If the old argument and the new argument resolve to either the same
> existing directory entry or different directory entries for the same
> existing file, rename() shall return successfully and perform no other
> action." and "If the link named by the n
On 23/06/2022 02:19, Alexandre Oliva wrote:
On Jun 22, 2022, Sebastian Huber wrote:
The clock_nanosleep() uses the coarse resolution which may give a time
before now().
Uhh, sorry, hit send too early.
I also meant to ask whether you'd like me to file an RTEMS ticket about
this issue.
I alr
64 matches
Mail list logo