From: Vladimir Mezentsev
When weakref_targets is not empty a target cannot be removed from weak_decls.
A small example is below when 'wv12' is removed from the weak list on aarch64:
static vtype Wv12 __attribute__((weakref ("wv12")));
extern vtype wv12 __attribute__((weak));
Bootstrapped on
The powerpc versions of _mm_slli_epi32 and __mm_slli_epi64 in emmintrin.h
do not properly handle shift values between 16 and 31, inclusive.
These were setting up the shift with vec_splat_s32, which only accepts
*5 bit signed* shift values, or a range of -16 to 15. Values above 15
produced an error
Attached is a minor update that avoids additional duplicate
warnings exposed by more extensive testing (for PR 85369).
On 04/12/2018 02:52 PM, Martin Sebor wrote:
The attached patch makes a small tweak to avoid issuing a duplicate
warning for calls to strcmp with a nonstring argument. The most
PR 85369 notes that the c-c++-common/attr-nonstring-3.c fails
on IBM Z (and other similar targets) whose back-end provides
the movstr expander. The failure is cause by an expected
warning failing to trigger because the strcpy call is expanded
early and the checker never runs.
The attached patch
PR c++/85385 reports an issue where we emit bogus "macro had not yet been
defined" notes when a macro is mis-used:
$ cat test.c
#define MACRO(X,Y)
void test ()
{
MACRO(42);
}
$ ./xg++ -B. -c test.c
test.c:5:11: error: macro "MACRO" requires 2 arguments, but only 1 given
MA
On Thu, Apr 12, 2018 at 6:39 AM, H.J. Lu wrote:
> On Thu, Apr 12, 2018 at 5:17 AM, Jan Hubicka wrote:
>>> On Thu, Apr 12, 2018 at 1:29 PM, H.J. Lu wrote:
>>> > Since IFUNC resolver is called indirectly, don't mark IFUNC resolver as
>>> > only called directly.
>>> >
>>> > OK for trunk?
>>> >
>>>
On Thu, Apr 12, 2018 at 07:37:22PM +0200, Jakub Jelinek wrote:
> On Thu, Apr 12, 2018 at 05:29:35PM +, Wilco Dijkstra wrote:
> > > Depending on what you mean old, I see e.g. in 2010 power7 mempcpy got
> > > added,
> > > in 2013 other power versions, in 2016 s390*, etc. Doing a decent mempcpy
On Thu, Apr 12, 2018 at 04:51:21PM -0400, David Malcolm wrote:
> Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
>
> OK for trunk?
>
> config/ChangeLog:
> PR jit/85384
> * acx.m4 (GCC_BASE_VER): Remove \$\$ from sed expression.
>
> gcc/ChangeLog:
> PR jit/85384
>
Hi!
The following testcase is miscompiled, because due to various disabled
optimization passes we end up with a dead bsf instruction (CTZ) of a
register known to be zero.
fold_rtx uses simplify_unary_operation, which has in this case:
case CTZ:
if (wi::ne_p (op0, 0))
Hi!
As mentioned in the PR, we need to unpoison the red zones when leaving a
scope with VLA variable(s); this is done through __asan_allocas_unpoison
call, unfortunately it is called after the __builtin_stack_restore which
restores the stack pointer; now, if an interrupt comes in between the stack
On Thu, Apr 12, 2018 at 11:14:45PM +0200, Thomas Koenig wrote:
> 2018-04-12 Thomas Koenig
>
> PR fortran/83064
> PR testsuite/85346
> * trans-stmt.c (gfc_trans_forall_loop): Use annot_expr_ivdep_kind
> for annotation and remove dependence on -ftree-parallelize-lo
Well, here's a variation which actually passes regression-test.
Seems I implicitly believed that the implicit save on main program
variables actually works... well, it turns out that it doesn't,
which is now PR85364.
OK for trunk?
Thomas
2018-04-12 Thomas Koenig
PR fortran/
This fixes some comments with misspelled files and classes.
Committed to trunk and gcc-7-branch.
It occurred to me that the name of the new __ios_failure type is
visible in the verbose terminate handler messages:
terminate called after throwing an instance of 'std::__ios_failure'
what(): basic
The attached patch makes a small tweak to avoid issuing a duplicate
warning for calls to strcmp with a nonstring argument. The most
onerous part of this was figuring out how to test for the absence
of duplicate warnings. The "hack" I used (dg-regexp) is in place
until a more straightforward solu
This patch updates gcc/configure.ac to use gcc_base_ver.
I had to drop the \$\$ from the sed expression to get it to work
within the configure script; I'm not entirely sure what their purpose
is. Without them, it's still matching on the first group of numeric
characters in BASE-VER.
Tested with
On Thu, Apr 12, 2018 at 11:39:43AM -0700, Cesar Philippidis wrote:
> Strange. I didn't observe any regressions when I tested it. But, then
> again, I was testing against revision
>
> r259092 | jason | 2018-04-04 09:42:55 -0700 (Wed, 04 Apr 2018) | 4 lines
>
> which is over a week old. I'll revert
We weren't instantiating exception-specifications when a template
referred to them, but that won't fly in the C++17 world where they're
part of the type, so we need to resolve them to do overload resolution
for non-dependent expressions.
The change to check_redeclaration_exception_specification is
OK.
On Thu, Apr 12, 2018 at 1:47 PM, Marek Polacek wrote:
> This is a crash on invalid which started when we changed
> decl_maybe_constant_var_p
> to say true for references. Then in tsubst_copy we take this branch:
> if (decl_maybe_constant_var_p (r))
> {
This fixes an ICE with -mno-direct-move.
Tested etc.; committing.
Segher
2018-04-12 Segher Boessenkool
* config/rs6000/rs6000.md (fix_truncsi2): Use legacy code if
asked to not generate direct moves.
(fix_truncsi2_stfiwx): Similar.
(fix_truncsi2_internal): S
On Wed, Apr 11, 2018 at 3:37 AM, H.J. Lu wrote:
> When -fcf-protection -mcet is used, I got
>
> FAIL: g++.dg/eh/sighandle.C
>
> (gdb) bt
> #0 _Unwind_RaiseException (exc=exc@entry=0x416ed0)
> at /export/gnu/import/git/sources/gcc/libgcc/unwind.inc:140
> #1 0x77d9936b in __cxxabiv1:
On 11 April 2018 13:05:52 CEST, Claudiu Zissulescu
wrote:
>Hi,
>
>Please find the ARC's gcc8 changes entry section as committed to
>wwwdocs.
s/qualifer/qualifier/
thanks,
On 04/12/2018 11:27 AM, H.J. Lu wrote:
> On Wed, Apr 11, 2018 at 12:30 PM, Cesar Philippidis
> wrote:
>> On 04/09/2018 04:31 AM, Richard Biener wrote:
>>> On Fri, 6 Apr 2018, Jakub Jelinek wrote:
>>>
On Fri, Apr 06, 2018 at 06:48:52AM -0700, Cesar Philippidis wrote:
> 2018-04-06 Cesar Ph
On Thu, Apr 12, 2018 at 03:46:26PM +0200, Jan Hubicka wrote:
> If you make C++ inline and get the idea to use target cloning attribute on
> this,
> this will likely lead to link error if you compile multiple files because you
> turn comdat to non-comdat.
>
> For comdats this woudl effectivly need
On Thu, Apr 12, 2018 at 07:53:35PM +0200, Jakub Jelinek wrote:
> On Thu, Apr 12, 2018 at 03:46:26PM +0200, Jan Hubicka wrote:
> > If you make C++ inline and get the idea to use target cloning attribute on
> > this,
> > this will likely lead to link error if you compile multiple files because
> >
On Wed, Apr 11, 2018 at 12:30 PM, Cesar Philippidis
wrote:
> On 04/09/2018 04:31 AM, Richard Biener wrote:
>> On Fri, 6 Apr 2018, Jakub Jelinek wrote:
>>
>>> On Fri, Apr 06, 2018 at 06:48:52AM -0700, Cesar Philippidis wrote:
2018-04-06 Cesar Philippidis
PR middle-end/84955
>>
On 04/12/2018 02:41 AM, Richard Biener wrote:
> On Thu, 12 Apr 2018, Jakub Jelinek wrote:
>
>> Hi!
>>
>> I'd like to ping the
>>
>> http://gcc.gnu.org/ml/gcc-patches/2018-03/msg01244.html
>> - PR83157 - improve debug info for x86 setcc peepholes
>>
>> patch. Thanks.
>
> OK for stage1 and backp
This is a crash on invalid which started when we changed
decl_maybe_constant_var_p
to say true for references. Then in tsubst_copy we take this branch:
if (decl_maybe_constant_var_p (r))
{
/* We can't call cp_finish_decl, so handle the
On Thu, Apr 12, 2018 at 05:29:35PM +, Wilco Dijkstra wrote:
> > Depending on what you mean old, I see e.g. in 2010 power7 mempcpy got added,
> > in 2013 other power versions, in 2016 s390*, etc. Doing a decent mempcpy
> > isn't hard if you have asm version of memcpy and one spare register.
>
On Thu, Apr 12, 2018 at 04:30:07PM +, Wilco Dijkstra wrote:
> Jakub Jelinek wrote:
> > On Thu, Apr 12, 2018 at 03:53:13PM +, Wilco Dijkstra wrote:
>
> >> The tailcall issue is just a distraction. Historically the handling of
> >> mempcpy
> >> has been horribly inefficient in both GCC and
On Thu, Apr 12, 2018 at 05:17:29PM +0200, Richard Biener wrote:
> >For -Os that is easily measurable regression, for -O2 it depends on the
> >relative speed of memcpy vs. mempcpy and whether one or both of them
> >are in
> >I-cache or not.
>
> Well, then simply unconditionally not generate a libca
Jakub Jelinek wrote:
>On Thu, Apr 12, 2018 at 04:30:07PM +, Wilco Dijkstra wrote:
>> Jakub Jelinek wrote:
>> Frankly I don't see why it is a P1 regression. Do you have a benchmark that
>
>That is how regression priorities are defined.
How can one justify considering this a release blocker wit
On April 12, 2018 4:18:47 PM GMT+02:00, Eric Botcazou
wrote:
>This makes -g work again in LTO mode for Windows targets by kludging
>around
>the missing support for copying PE-COFF debug sections in the simple
>object
>module of libiberty, thus effectively disabling early debug in LTO
>mode.
>Th
This new test case required a dejagnu qualifier to restrict its
execution on big-endian platforms.
The patch bootstrapped and tested without regressions. Was committed as
obvious.
gcc/testsuite/ChangeLog:
2018-04-12 Kelvin Nilsen
PR target/85347
* gcc.target/powerpc/vec-ldl-1.c: Ch
On Thu, Apr 12, 2018 at 03:53:13PM +, Wilco Dijkstra wrote:
> Jakub Jelinek wrote:
> > On Thu, Apr 12, 2018 at 03:52:09PM +0200, Richard Biener wrote:
> >> Not sure if I missed some important part of the discussion but
> >> for the testcase we want to preserve the tailcall, right? So
> >> it w
Jakub Jelinek wrote:
> On Thu, Apr 12, 2018 at 03:53:13PM +, Wilco Dijkstra wrote:
>> The tailcall issue is just a distraction. Historically the handling of
>> mempcpy
>> has been horribly inefficient in both GCC and GLIBC for practically all
>> targets.
>> This is why it was decided to def
On Thu, Apr 12, 2018 at 8:53 AM, Wilco Dijkstra wrote:
> So generally it's a good idea to change mempcpy into memcpy by default. It's
> not slower than calling mempcpy even if you have a fast implementation, it's
> faster
> if you use an up to date GLIBC which calls memcpy, and it's significantl
On 10 April 2018 at 00:36, Jonathan Wakely wrote:
> Define a new exception type derived from std::ios::failure[abi:cxx11]
> which also aggregates an object of the gcc4-compatible ios::failure
> type. Make __throw_ios_failure throw this new type for iostream errors
> that raise exceptions. Provide c
On April 12, 2018 5:38:44 PM GMT+02:00, Jakub Jelinek wrote:
>On Thu, Apr 12, 2018 at 05:17:29PM +0200, Richard Biener wrote:
>> >For -Os that is easily measurable regression, for -O2 it depends on
>the
>> >relative speed of memcpy vs. mempcpy and whether one or both of them
>> >are in
>> >I-cache
Jakub Jelinek wrote:
> On Thu, Apr 12, 2018 at 03:52:09PM +0200, Richard Biener wrote:
>> Not sure if I missed some important part of the discussion but
>> for the testcase we want to preserve the tailcall, right? So
>> it would be enough to set avoid_libcall to
>> endp != 0 && CALL_EXPR_TAILCALL
On April 12, 2018 4:31:12 PM GMT+02:00, Jakub Jelinek wrote:
>On Thu, Apr 12, 2018 at 04:19:38PM +0200, Richard Biener wrote:
>> Well, but that wouldn't be a fix for a regression and IMHO there's
>> no reason for a really lame mempcpy. If targets disgree well,
>
>It is a regression as well, in th
On 12.04.2018 0:55, Alexander Monakov wrote:
> As noted in PR 85354, we cannot simply invoke cfg_cleanup after dominators are
> computed, because they may become invalid but neither freed nor recomputed, so
> this trips checking in flow_loops_find.
>
> We can move cleanup_cfg earlier (and run it f
On Thu, Apr 12, 2018 at 04:19:38PM +0200, Richard Biener wrote:
> Well, but that wouldn't be a fix for a regression and IMHO there's
> no reason for a really lame mempcpy. If targets disgree well,
It is a regression as well, in the past we've emitted mempcpy when user
wrote mempcpy, now we don't.
On Thu, Apr 12, 2018 at 03:52:09PM +0200, Richard Biener wrote:
> Not sure if I missed some important part of the discussion but
> for the testcase we want to preserve the tailcall, right? So
> it would be enough to set avoid_libcall to
> endp != 0 && CALL_EXPR_TAILCALL (exp) (and thus also handle
On Thu, 12 Apr 2018, Jakub Jelinek wrote:
> On Thu, Apr 12, 2018 at 03:52:09PM +0200, Richard Biener wrote:
> > Not sure if I missed some important part of the discussion but
> > for the testcase we want to preserve the tailcall, right? So
> > it would be enough to set avoid_libcall to
> > endp !
This makes -g work again in LTO mode for Windows targets by kludging around
the missing support for copying PE-COFF debug sections in the simple object
module of libiberty, thus effectively disabling early debug in LTO mode.
The patch also contains a fixlet for a related oversight in the LTO wrap
Hi,
Currently, when we enable -mlong-vector-in-workers in gemm.f90, we get:
...
{
.reg.u32%tidy;
.reg.u64%t_bcast;
.reg.u64%y64;
mov.u32 %tidy, %tid.y;
cvt.u64.u32 %y64, %tidy;
add.u64 %y64, %y64, 1;
cvta.shared.u64 %t_bcas
On Thu, 12 Apr 2018, Martin Liška wrote:
> Hi.
>
> I'm reminding review request from Richi for generic part
> and Uros/Honza for target part.
Not sure if I missed some important part of the discussion but
for the testcase we want to preserve the tailcall, right? So
it would be enough to set avo
> 2018-04-12 Martin Liska
>
> PR ipa/85329
> * multiple_target.c (create_dispatcher_calls): Set apostrophes
> for target_clone error message.
> (separate_attrs): Add new argument and check for an emptry
> string.
> (expand_target_clones): Handle it.
> (
> Hi.
>
> I'm reminding review request from Richi for generic part
> and Uros/Honza for target part.
OK for i386 bits.
Honza
>
> Thanks,
> Martin
Hi,
this patch simplifies the logic in nvptx_single.
Build x86_64 with nvptx accelerator and tested libgomp.
Thanks,
- Tom
[nvptx] Simplifly logic in nvptx_single
2018-04-12 Tom de Vries
* config/nvptx/nvptx.c (nvptx_single): Simplify init of vector variable.
Add and use variable use_par
On Thu, Apr 12, 2018 at 5:17 AM, Jan Hubicka wrote:
>> On Thu, Apr 12, 2018 at 1:29 PM, H.J. Lu wrote:
>> > Since IFUNC resolver is called indirectly, don't mark IFUNC resolver as
>> > only called directly.
>> >
>> > OK for trunk?
>> >
>> >
>> > H.J.
>> > ---
>> > gcc/
>> >
>> > PR target
On Thu, Apr 12, 2018 at 5:13 AM, Richard Biener
wrote:
> On Thu, Apr 12, 2018 at 1:29 PM, H.J. Lu wrote:
>> Since IFUNC resolver is called indirectly, don't mark IFUNC resolver as
>> only called directly.
>>
>> OK for trunk?
>>
>>
>> H.J.
>> ---
>> gcc/
>>
>> PR target/85345
>> *
Forgot to add the patch.
Martin
>From fb1bbf142af6668eeb1bdfeec96920de2f0edb21 Mon Sep 17 00:00:00 2001
From: marxin
Date: Thu, 12 Apr 2018 12:15:17 +0200
Subject: [PATCH] Make redirection only for target_clones: V2 (PR ipa/85329).
gcc/ChangeLog:
2018-04-12 Martin Liska
PR ipa/85329
* mul
Hi.
I'm sending V2. The patch adjusts:
- make redirection just for target_clones, done simply by recording nodes
where expand_target_clones return true
- reset various DECL_* flags on default version, needed for ipa-visibility
assert I've seen
- handle empty string in target_clones: __attribute
Program received signal SIGSEGV, Segmentation fault.
__stack_split_initialize ()
at /export/gnu/import/git/sources/gcc/libgcc/config/i386/morestack.S:751
751 leaq-16000(%rsp),%rax # We should have at least 16K.
Missing separate debuginfos, use: dnf debuginfo-install
libgc
On Wed, Apr 11, 2018 at 10:02 PM, Martin Sebor wrote:
> On 04/04/2018 05:03 PM, Paolo Carlini wrote:
>>
>> Hi Martin
>>
>> On 05/04/2018 00:28, Martin Sebor wrote:
>>>
>>> + implementations do suppresses the warning.
>>
>> suppress
>
>
> I was about to fix this but re-reading the full sentenc
Hi.
I'm reminding review request from Richi for generic part
and Uros/Honza for target part.
Thanks,
Martin
On Thu, Apr 12, 2018 at 01:46:40PM +0300, Kirill Yukhin wrote:
>
> Hello Jakub!
>
> > On 11 Apr 2018, at 16:27, Jakub Jelinek wrote:
> > In lots of patterns we assume that we never see xmm16+ hard registers
> > with 128-bit and 256-bit vector modes when not -mavx512vl, because
> > HARD_REGNO_MOD
> On Thu, Apr 12, 2018 at 1:29 PM, H.J. Lu wrote:
> > Since IFUNC resolver is called indirectly, don't mark IFUNC resolver as
> > only called directly.
> >
> > OK for trunk?
> >
> >
> > H.J.
> > ---
> > gcc/
> >
> > PR target/85345
> > * cgraph.h: Include stringpool.h" and "attribs
On Thu, Apr 12, 2018 at 1:29 PM, H.J. Lu wrote:
> Since IFUNC resolver is called indirectly, don't mark IFUNC resolver as
> only called directly.
>
> OK for trunk?
>
>
> H.J.
> ---
> gcc/
>
> PR target/85345
> * cgraph.h: Include stringpool.h" and "attribs.h".
> (cgraph_nod
On Thu, 12 Apr 2018, Jakub Jelinek wrote:
> On Thu, Apr 12, 2018 at 01:35:46PM +0200, Richard Biener wrote:
> >
> > The following disables split-dwarf for the LTO part of the early debug
> > (keeping it for the fat part) and makes sure the driver doesn't
> > see -gsplit-dwarf in effect.
> >
> >
On Thu, Apr 12, 2018 at 01:35:46PM +0200, Richard Biener wrote:
>
> The following disables split-dwarf for the LTO part of the early debug
> (keeping it for the fat part) and makes sure the driver doesn't
> see -gsplit-dwarf in effect.
>
> That works for all but the compile stage and slim objects
On Thu, Apr 12, 2018 at 10:41:22AM +0200, Richard Biener wrote:
> On Thu, 12 Apr 2018, Jakub Jelinek wrote:
> > I'd like to ping the
> >
> > http://gcc.gnu.org/ml/gcc-patches/2018-03/msg01244.html
> > - PR83157 - improve debug info for x86 setcc peepholes
> >
> > patch. Thanks.
>
> OK for sta
The following disables split-dwarf for the LTO part of the early debug
(keeping it for the fat part) and makes sure the driver doesn't
see -gsplit-dwarf in effect.
That works for all but the compile stage and slim objects
(the default) which then ends up generating an empty .dwo file.
I'm not sur
Since IFUNC resolver is called indirectly, don't mark IFUNC resolver as
only called directly.
OK for trunk?
H.J.
---
gcc/
PR target/85345
* cgraph.h: Include stringpool.h" and "attribs.h".
(cgraph_node::only_called_directly_or_aliased_p): Return false
for IFUNC r
> On 12 Apr 2018, at 13:53, Jakub Jelinek wrote:
>
> On Thu, Apr 12, 2018 at 01:46:40PM +0300, Kirill Yukhin wrote:
>>
>> Hello Jakub!
>>
>>> On 11 Apr 2018, at 16:27, Jakub Jelinek wrote:
>>> In lots of patterns we assume that we never see xmm16+ hard registers
>>> with 128-bit and 256-bit
On 07/03/18 14:15, Arnaud Charlet wrote:
The $(GNATLIBCFLAGS) are already included in $(GNATLIBCFLAGS_FOR_C).
We must call the C compiler with the right machine flags. So, add
$(GNATLIBCFLAGS_FOR_C) to $(OSCONS_EXTRACT). For example, on a
bi-arch
compiler supporting 32-bit and 64-bit instructi
This fixes crashes on Darwin with -flto -g because we pass the wrong
(NULL) debug_line_section in
case dw_val_class_lineptr:
dw2_asm_output_offset (DWARF_OFFSET_SIZE, AT_lbl (a),
debug_line_section, "%s", name);
break;
which is because
Hello Jakub!
> On 11 Apr 2018, at 16:27, Jakub Jelinek wrote:
>
> Hi!
>
> In lots of patterns we assume that we never see xmm16+ hard registers
> with 128-bit and 256-bit vector modes when not -mavx512vl, because
> HARD_REGNO_MODE_OK refuses those.
> Unfortunately, as this testcase and patch s
The CFI magic we emit as part of the indirect branch thunks in order to
have somewhat sane unwind information must not be emitted with
-fno-dwarf2-cfi-asm.
Committed to mainline, gcc-7-branch, and gcc-6-branch.
gcc/ChangeLog:
2018-04-12 Andreas Krebbel
* config/s390/s390.c (s390_outp
Hi!
I'd like to ping the
http://gcc.gnu.org/ml/gcc-patches/2018-03/msg01244.html
- PR83157 - improve debug info for x86 setcc peepholes
patch. Thanks.
Jakub
On Thu, 12 Apr 2018, Jakub Jelinek wrote:
> Hi!
>
> I'd like to ping the
>
> http://gcc.gnu.org/ml/gcc-patches/2018-03/msg01244.html
> - PR83157 - improve debug info for x86 setcc peepholes
>
> patch. Thanks.
OK for stage1 and backporting after it soaked there for a while.
I'm too unfamilia
On Wed, 11 Apr 2018, Jakub Jelinek wrote:
> Hi!
>
> When switching regcprop.c to use validate_* and apply_change_group,
> I have added code to restore recog_data.operands[i] if they have been
> replaced after apply_change_group failure. That is bogus though, when
> apply_change_group fails, reco
On Wed, Apr 11, 2018 at 9:30 PM, Cesar Philippidis
wrote:
> On 04/09/2018 04:31 AM, Richard Biener wrote:
>> On Fri, 6 Apr 2018, Jakub Jelinek wrote:
>>
>>> On Fri, Apr 06, 2018 at 06:48:52AM -0700, Cesar Philippidis wrote:
2018-04-06 Cesar Philippidis
PR middle-end/84955
>>>
On 04/11/2018 11:20 PM, Martin Sebor wrote:
> On 04/11/2018 06:47 AM, Andreas Krebbel wrote:
>> On 04/11/2018 10:02 AM, Jakub Jelinek wrote:
>>> On Wed, Apr 11, 2018 at 09:48:05AM +0200, Andreas Krebbel wrote:
c-c++-common/attr-nonstring-3.c fails on IBM Z. The reason appears to be
that w
Hi,
for the recently added test-case pr85244-1.c, we run into the following
failure with the standalone nvptx toolchain:
...
spawn nvptx-none-run ./pr85244-1.exe
error : Size doesn't match for 'val' in 'input file 2 at offset 3047',
first specified in 'input file 1 at offset 1805'
nvptx-run
On 11.04.2018 20:55, Jakub Jelinek wrote:
> On Wed, Apr 11, 2018 at 06:07:17PM +0200, Matthias Klose wrote:
>> On 11.04.2018 12:31, Jakub Jelinek wrote:
>>> Hi!
>>>
>>> As discussed, using --as-needed and --no-as-needed is dangerous, because
>>> it results in --no-as-needed even for libraries after
On Wed, Apr 11, 2018 at 09:47:22PM +0200, Thomas Koenig wrote:
> Am 11.04.2018 um 20:33 schrieb Jakub Jelinek:
>
> > > I have attached updated patch which moves the test case to
> > > gfortran.dg/gomp (where it actually passes).
> >
> > How could it pass there? dg-do run tests don't belong into
78 matches
Mail list logo
