Hi,
This patch adds a combine pattern for "CA minus one". As CA only has two
values (0 or 1), we could convert following pattern
(sign_extend:DI (plus:SI (reg:SI 98 ca)
(const_int -1 [0x]
to
(plus:DI (reg:DI 98 ca)
(const_int -1
On Sun, May 15, 2022 at 8:07 PM Alexander Monakov wrote:
>
> On Sun, 15 May 2022, Rui Ueyama wrote:
>
> > > Regarding files, as far as I can tell, GCC plugin will leave a
> > > 'resolution file'
> > > on disk, but after re-exec it would recreate it anyway.
> >
> > Does it recreate a temporary
ping.
On Sat, May 7, 2022 at 1:05 PM liuhongt via Gcc-patches
wrote:
>
> This is adjusted patch only for OImode.
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
> Ok for trunk?
>
> gcc/ChangeLog:
>
> PR target/104610
> * config/i386/i386-expand.cc
Hi,
Upstream dmd has now released v2.100.0, this patch merges in the
latest bug fixes since the last sync-up of the release branch.
D front-end changes:
- Import dmd v2.100.0 release.
- The new behavior of issuing deprecation messages for scope
violations has been reverted until
const_int_operand and other const*_operand predicates do not need
constraints when the constraint is inherited from the range of
constant integer predicate. Remove the constraint in case all
alternatives use the same inherited constraint.
2022-05-15 Uroš Bizjak
gcc/ChangeLog:
*
It has come up several times that Clang considers hidden friends of a class
to be sufficiently memberly to be covered by a friend declaration naming the
class. This is somewhat unclear in the standard: [class.friend] says
"Declaring a class to be a friend implies that private and protected
While I was backporting the patch for PR102300, it occurred to me that it
would be cleaner to look through the injected-class-name earlier in the
function. I don't think this changes any test results.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
* parser.cc
My patch for 105191 made us use build_value_init more frequently from
build_vec_init_expr, but build_value_init doesn't like to be called to
initialize a class in a template. That's caused trouble in the past, and
seems like a strange restriction, so let's fix it.
Tested x86_64-pc-linux-gnu,
في الأحد، ١٥ مايو، ٢٠٢٢ ٤:١٨ م Mohamed Atef كتب:
> Ping
>
> في الجمعة، ١٣ مايو، ٢٠٢٢ ٩:١٩ م Mohamed Atef
> كتب:
>
>> Hello Jakub,
>>I am sorry, but should #ifdef __ELF__ put and separate file and also
>> the actual functions (e.g. extern ompd_dll_location_valid (void))
>> I mean both in the
Ping
في الجمعة، ١٣ مايو، ٢٠٢٢ ٩:١٩ م Mohamed Atef
كتب:
> Hello Jakub,
>I am sorry, but should #ifdef __ELF__ put and separate file and also
> the actual functions (e.g. extern ompd_dll_location_valid (void))
> I mean both in the same files or the functions should be in the
> omp-tools.h but
Excerpts from Marc Aurèle La France's message of Mai 12, 2022 10:29 pm:
> Greetings.
>
> No compiler has any business rejecting files for the sole crime of being
> symlinked to. The following applies, modulo patch fuzz, to the 9, 10 and 11
> series of compilers.
>
> Given my use of shadow
On Sun, 15 May 2022, Rui Ueyama wrote:
> > Regarding files, as far as I can tell, GCC plugin will leave a 'resolution
> > file'
> > on disk, but after re-exec it would recreate it anyway.
>
> Does it recreate a temporary file with the same file name so that
> there's no temporary file left on
On Sun, May 15, 2022 at 7:37 PM Alexander Monakov wrote:
>
> On Sun, 15 May 2022, Rui Ueyama wrote:
>
> > > Can you simply restart the linker on first call to get_symbols_v2 instead?
> >
> > I could, but it may not be a safe timing to call exec(2). I believe we
> > are expected to call
On Sun, 15 May 2022, Rui Ueyama wrote:
> > Can you simply restart the linker on first call to get_symbols_v2 instead?
>
> I could, but it may not be a safe timing to call exec(2). I believe we
> are expected to call cleanup_hook after calling all_symbols_read_hook,
> and it is not clear what
GCC's f732bf6a603721f61102a08ad2d023c7c2670870 merged LLVM's
315d792130258a9b7250494be8d002ebb427b08f, which added sanitizers support for
PowerPC on FreeBSD, so this commit only enables building it.
Enabled sanitizers are the same as on powerpc*-*-linux*.
libsanitizer
* configure.tgt:
On Sun, May 15, 2022 at 6:09 PM Alexander Monakov wrote:
>
> On Sun, 15 May 2022, Rui Ueyama wrote:
>
> > > Makes sense, but I still don't understand why mold wants to discover in
> > > advance whether the plugin is going to use get_symbols_v3. How would it
> > > help with what mold does today to
On Sun, 15 May 2022, Rui Ueyama wrote:
> > Makes sense, but I still don't understand why mold wants to discover in
> > advance whether the plugin is going to use get_symbols_v3. How would it
> > help with what mold does today to handle the _v2 case?
>
> Currently, mold restarts itself to reset
On Sun, May 15, 2022 at 4:51 PM Alexander Monakov wrote:
>
> On Sun, 15 May 2022, Rui Ueyama wrote:
>
> > > Is that a good tradeoff in the LTO case though? I believe you cannot
> > > assume
> > > the plugin to be thread-safe, so you're serializing its API calls, right?
> > > But the plugin is
GCC's f732bf6a603721f61102a08ad2d023c7c2670870 merged LLVM's
315d792130258a9b7250494be8d002ebb427b08f, which added sanitizers support for
PowerPC on FreeBSD, so this commit only enables building it.
Enabled sanitizers are the same as on powerpc*-*-linux*.
libsanitizer
* configure.tgt:
On Sun, 15 May 2022, Rui Ueyama wrote:
> > Is that a good tradeoff in the LTO case though? I believe you cannot assume
> > the plugin to be thread-safe, so you're serializing its API calls, right?
> > But the plugin is doing a lot of work, so using the index to feed it with as
> > few LTO objects
On Sun, May 15, 2022 at 3:53 PM Alexander Monakov wrote:
>
> On Sun, 15 May 2022, Rui Ueyama wrote:
>
> [snip]
> > > So get_symbols_v3 allows the linker to discard an LTO .o file to solve
> > > this.
> > >
> > > In absence of get_symbols_v3 mold tries to ensure correctness by
> > > restarting
>
On Sun, 15 May 2022, Rui Ueyama wrote:
[snip]
> > So get_symbols_v3 allows the linker to discard an LTO .o file to solve this.
> >
> > In absence of get_symbols_v3 mold tries to ensure correctness by restarting
> > itself while appending a list of .o files to be discarded to its command
> >
On Fri, May 6, 2022 at 10:47 PM Alexander Monakov wrote:
>
>
>
> On Thu, 5 May 2022, Martin Liška wrote:
>
> > On 5/5/22 12:52, Alexander Monakov wrote:
> > > Feels a bit weird to ask, but before entertaining such an API extension,
> > > can we step back and understand the v3 variant of
23 matches
Mail list logo
