https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92410
Martin Liška changed:
What|Removed |Added
Keywords||needs-bisection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92401
Richard Biener changed:
What|Removed |Added
Assignee|rguenth at gcc dot gnu.org |jakub at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92132
Kewen Lin changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92132
--- Comment #4 from Kewen Lin ---
Author: linkw
Date: Fri Nov 8 07:37:07 2019
New Revision: 277947
URL: https://gcc.gnu.org/viewcvs?rev=277947=gcc=rev
Log:
[rs6000]Fix PR92132 by adding vec_cmp and vcond_mask supports
To support full
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92406
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92409
--- Comment #5 from Martin Liška ---
>
> I have to leave the office now but I am testing the attached fix on an
> x86_64 - I have lost connection to the i686 I was using (gcc45).
I would recommend here to use your machine and set up a KVM
Hi Jakub,
On 06.11.19 14:00, Jakub Jelinek wrote:
> On Wed, Nov 06, 2019 at 01:41:47PM +0100, frede...@codesourcery.com wrote:
>> --- a/gcc/omp-low.c
>> +++ b/gcc/omp-low.c
>> @@ -128,6 +128,12 @@ struct omp_context
>> [...]
>> + /* A tree_list of the reduction clauses in this context. */
>> +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92100
Jerry DeLisle changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91388
Eric Gallager changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92398
--- Comment #3 from Xiong Hu XS Luo ---
Power8 BE generates:
L.bar:
.LFB1:
.cfi_startproc
mtvsrd 0,4
mtvsrd 1,5
xxpermdi 12,0,1,0
xxlnor 0,12,12
stxvd2x 0,0,3
blr
.long 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92398
Xiong Hu XS Luo changed:
What|Removed |Added
CC||luoxhu at cn dot ibm.com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91227
--- Comment #20 from Eric Gallager ---
(In reply to Martin Sebor from comment #19)
> That's a valid concern. Issuing a warning (either at the same time as or in
> lieu of the folding) would be a way to detect and prevent these kinds of
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92295
--- Comment #2 from liuhongt at gcc dot gnu.org ---
Author: liuhongt
Date: Fri Nov 8 05:34:25 2019
New Revision: 277946
URL: https://gcc.gnu.org/viewcvs?rev=277946=gcc=rev
Log:
Fix inefficient vector constructor.
Changelog
gcc/
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87569
Eric Gallager changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
[0] should be 61344 or opt-out. However, with
"-O2", gdb outputs "l_1162[0][0][0]=3".
$ gcc-trunk -v
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.0.0 20191107 (experimental) [trunk revision 277920] (GCC)
#expected output
$ gcc-trunk -O1 -g a
On 11/7/19 12:41 PM, Tobias Burnus wrote:
This fixes the gfortran.dg/continuation_6.f fails testsuite fails with newer
GLIBC.
The continuation line handling assumes that the line number starts at 0 (→
continue_line) and then can be incremented, if needed.
The problem came up with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87313
Martin Sebor changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
Hi Segher,
on 2019/11/8 上午8:07, Segher Boessenkool wrote:
> Hi!
>
>>> Half are pretty simple:
>>>
>>> lt(a,b) = gt(b,a)
>>> gt(a,b) = gt(a,b)
>>> eq(a,b) = eq(a,b)
>>> le(a,b) = ge(b,a)
>>> ge(a,b) = ge(a,b)
>>>
>>> ltgt(a,b) = ge(a,b) ^ ge(b,a)
>>> ord(a,b) = ge(a,b) | ge(b,a)
>>>
>>> The
Hi Richard,
Thanks for the review.
On Tue, 5 Nov 2019 at 23:08, Richard Biener wrote:
>
> On Tue, Nov 5, 2019 at 12:17 AM Kugan Vivekanandarajah
> wrote:
> >
> > Hi,
> > Thanks for the review.
> >
> > On Tue, 5 Nov 2019 at 03:57, H.J. Lu wrote:
> > >
> > > On Sun, Nov 3, 2019 at 6:45 PM Kugan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87731
Martin Sebor changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78352
--- Comment #10 from Eric Gallager ---
This bug means we now have to leave out a part of libsanitizer that uses
blocks:
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00262.html
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00268.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87736
Martin Sebor changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
Hi Segher,
on 2019/11/8 上午6:36, Segher Boessenkool wrote:
> On Thu, Nov 07, 2019 at 11:22:12AM +0800, Kewen.Lin wrote:
>> One updated patch to enable it everywhere attached.
>
>> 2019-11-07 Kewen Lin
>>
>> * config/rs6000/rs6000.c (rs6000_builtin_vectorization_cost): Make
>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #29 from Rich Felker ---
For reference, here are the affected functions in musl (fmax, fmaxf, fmin,
fminf):
https://git.musl-libc.org/cgit/musl/tree/src/math/powerpc64?id=v1.1.24
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #28 from Segher Boessenkool ---
(In reply to A. Wilcox (awilfox) from comment #25)
> GCC typically announces deprecations for publicly-documented interfaces
> being removed versions ahead of time, and I'm surprised that wasn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #27 from Rich Felker ---
> Have I already mentioned that if any program "in the wild" will use "ws" with
> GCC 10, then of course we can add an alias (to "wa") for it? No program
> should
> use "ws" in inline assembler, ever, but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #26 from Segher Boessenkool ---
(In reply to Rich Felker from comment #24)
> > Sure, and I'll do that, *if there are users*, *after they fix their stuff*.
>
> Nothing is broken on our side here. We are using the documented
>
C2x removes support for old-style function definitions with identifier
lists, changing () in function definitions to be equivalent to (void)
(while () in declarations that are not definitions still gives an
unprototyped type).
This patch updates GCC accordingly. The new semantics for () are
This change revises the memory barrier patterns to use the ldcw instruction
instead of
the sync instruction. The sync instruction performs better and I have more
confidence
in it than sync.
We use a location just above the top of the stack for these operations. The
stack address
is aligned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92090
--- Comment #15 from Peter Bergner ---
Author: bergner
Date: Fri Nov 8 00:34:09 2019
New Revision: 277942
URL: https://gcc.gnu.org/viewcvs?rev=277942=gcc=rev
Log:
Add another test case to exercise the previous MODE_PARTIAL_INT change.
Also process it with Doxygen.
* doc/doxygen/user.cfg.in (INPUT): Add header.
* include/precompiled/stdc++.h: Include header.
Tested powerpc64le-linux, committed to trunk.
commit ed86b7c065df6b33dfee86fba3bee089386ac4a8
Author: Jonathan Wakely
Date: Thu Nov 7 23:20:51 2019
* libsupc++/compare (common_comparison_category)
(common_comparison_category_t): Define for C++20.
* testsuite/18_support/comparisons/common/1.cc: New test.
Tested powerpc64le-linux, committed to trunk.
commit cb48e7e6d0bbed9eadc34b4318511f3e05ec1b64
Author: Jonathan
On Thu, 2019-11-07 at 21:37 +, Jozef Lawrynowicz wrote:
> The code size bloat added by building C++ programs using libraries containing
> support for exceptions is significant. When using simple constructs such as
> static variables, sometimes many kB from the libraries are unnecessarily
>
Hi!
On Thu, Nov 07, 2019 at 06:17:53PM +0800, Kewen.Lin wrote:
> on 2019/11/7 上午7:49, Segher Boessenkool wrote:
> > The expander named "one_cmpl3":
> >
> > Erm. 2, not 3 :-)
> Ah, sorry I didn't notice we have one cmpl**3** but actually for one
> cmpl**2** expand, a bit surprised. Done.
After the simplify-rtx patch, we can now be asked about conditions we
wouldn't be asked about before. This is perfectly fine, except we
have a little over-eager assert. Remove that one.
I originally had this patch before the simplify-rtx one, but I reordered
them without retesting every step.
There is one place in the C parser that already handles a subset of
the C2x [[]] attribute syntax: c_parser_transaction_attributes.
This patch factors C2x attribute parsing out of there, extending it to
cover the full C2x attribute syntax (although currently only called
from that one place in the
On Thu, 7 Nov 2019, Richard Sandiford wrote:
> Tested on aarch64-linux-gnu and x86_64-linux-gnu. OK to install?
OK.
--
Joseph S. Myers
jos...@codesourcery.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92416
Bug ID: 92416
Summary: ICE with spaceship and vector types
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
On Thu, Nov 07, 2019 at 05:05:16PM +, Jason Merrill wrote:
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/cpp2a/spaceship-scalar1-neg.C
> @@ -0,0 +1,25 @@
> +// { dg-do run { target c++2a } }
> +
> +#include
> +
> +#define assert(X) do { if (!(X)) __builtin_abort(); } while(0)
> +
> +void f(){}
Hi!
I've noticed a comment typo in build_vec_delete_1 and when grepping
around if the same typo isn't elsewhere, I found a different typo
elsewhere.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
committed to trunk as obvious.
2019-11-08 Jakub Jelinek
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92409
--- Comment #4 from Jakub Jelinek ---
Sadly, neither of those regressions is fixed on i686-linux.
Still the same
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/cast-function-1.c:49:1: error:
non-trivial conversion in 'ssa_name'
struct str_t
int
{} =
The Library Working Group have approved a change to std::for_each_n that
requires it to handle negative N gracefully, which we were not doing for
random access iterators.
* include/bits/stl_algo.h (for_each_n): Handle negative count.
*
On 11/7/19 7:57 PM, Segher Boessenkool wrote:
Hi!
On Thu, Nov 07, 2019 at 06:44:17PM +0100, Egeyar Bagcioglu wrote:
On 11/7/19 9:03 AM, Segher Boessenkool wrote:
+ ASM_OUTPUT_ASCII(asm_out_file, cmdline, cmdline_length);
+}
+ cmdline[0] = 0;
+ ASM_OUTPUT_ASCII(asm_out_file,
Over a month ago, I wrote , about SPEC2017:
Of the 7 benchmarks that are (partly) written in Fortran, Cactus is free
software (LGPL'd) and the 3 geological ones (wrf, cam4 and roms) are
"obtainable" (need to register to get the source code). Of course, that
means you get "a" version of the
Snapshot gcc-7-20191107 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/7-20191107/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 7 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-7
On Nov 7, 2019, Richard Biener wrote:
> (also raises the question why we have both -dumpbase and -auxbase ...)
https://gcc.gnu.org/ml/gcc-patches/2002-08/msg00294.html
This was before -dumpdir, however.
Here's the current logic for aux_base_name:
-c or -S with -o [odir/]obase.oext:
On Thu, Nov 07, 2019 at 11:22:12AM +0800, Kewen.Lin wrote:
> One updated patch to enable it everywhere attached.
> 2019-11-07 Kewen Lin
>
> * config/rs6000/rs6000.c (rs6000_builtin_vectorization_cost): Make
> scalar_load, vector_load, unaligned_load and vector_gather_load cost
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
A. Wilcox (awilfox) changed:
What|Removed |Added
CC||awilfox at adelielinux dot org
On Wed, Nov 06, 2019 at 10:46:06AM -0700, Jeff Law wrote:
> BTW, I think there's enough overlap between simplify-rtx and combine
> that if you wanted to maintain simplify-rtx as well that I'd fully
> support it. Thoughts?
I'd be honoured, thanks for the offer!
Segher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92090
Peter Bergner changed:
What|Removed |Added
Known to work||7.0
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92415
Bug ID: 92415
Summary: new test case g++.dg/cpp2a/spaceship-scalar1-neg.C
introduced in r277925 fails
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity:
Support for the MSP430 -minrt option has been removed from Newlib, since all the
associated behaviour is now dynamic. Initialization code run before main is only
included when needed.
This patch removes the final traces of -minrt from GCC.
-minrt used to modify the linking process in the
The MSP430 target does not need to support dynamic shared objects so
__cxa_atexit does not need to be used - atexit is sufficient.
Newlib atexit is a fine replacement as it also supports registration of more
than 32 functions.
By not using __cxa_atexit, we can define
The code size bloat added by building C++ programs using libraries containing
support for exceptions is significant. When using simple constructs such as
static variables, sometimes many kB from the libraries are unnecessarily
pulled in.
So this patch disable exceptions by default for MSP430 when
Given that MSP430 is a resource constrained, embedded target disabling
transactional memory by default is a good idea to save on code size in
the runtime library.
It can still be enabled by passing --enable-tm-clone-registry (although as far
as I understand the feature is fundamentally
When building small programs for MSP430, the impact of the unused
functions pulled in from the CRT libraries is quite noticeable. Most of these
relates to feature that will never be used for MSP430 (Transactional memory,
supporting shared objects and dynamic linking), or rarely used (exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #24 from Rich Felker ---
> Sure, and I'll do that, *if there are users*, *after they fix their stuff*.
Nothing is broken on our side here. We are using the documented functionality
from gcc 9 going all the way back to whatever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92414
--- Comment #2 from Jakub Jelinek ---
Created attachment 47196
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47196=edit
gcc10-pr92414.patch
Untested fix.
This test uses -masm=intel, which isn't supported by Darwin, so add the
necessary dg-require-effective-target.
tested on x86_64-darwin16,
applied as obvious to mainline,
thanks
Iain
gcc/testsuite/ChangeLog:
2019-11-07 Iain Sandoe
* gcc.target/i386/pr92258.c: Add dg-requires for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92414
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92414
Marek Polacek changed:
What|Removed |Added
Keywords||ice-on-invalid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92414
Bug ID: 92414
Summary: internal compiler error: tree check: expected
constructor, have error_mark in
cxx_eval_store_expression, at cp/constexpr.c:4009
Product: gcc
This fixes the gfortran.dg/continuation_6.f fails testsuite fails with
newer GLIBC.
The continuation line handling assumes that the line number starts at 0
(→ continue_line) and then can be incremented, if needed.
The problem came up with -pre_include, which is used with newer GLIBC to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91370
--- Comment #1 from Jakub Jelinek ---
Author: jakub
Date: Thu Nov 7 20:24:38 2019
New Revision: 277929
URL: https://gcc.gnu.org/viewcvs?rev=277929=gcc=rev
Log:
PR c++/91370 - Implement P1041R4 and P1139R2 - Stronger Unicode reqs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #23 from Segher Boessenkool ---
(In reply to rsand...@gcc.gnu.org from comment #21)
> > I am saying it is a mistake that GCC ever documented this for public
> > use. Every use of "ws" in inline asm should be "wa".
>
> But it was a
OK.
On 11/7/19 3:38 PM, Jakub Jelinek wrote:
Hi!
GCC does use UTF-16 and UTF-32 for char16_t and char32_t string literals
already, so P1041R4 is I believe already implemented with no changes needed.
While going through P1139R2, I've realized that we weren't handling
"If the value is not
Güvenli Filo Kiralama Bu maili düzgün görüntüleyemiyorsanız tıklayınız
Seyyare Otomotiv Filo ve Araç Kiralama Seyyare Otomotiv Filo ve Araç
Kiralama www.seyyareotomotiv.com Tel: 0312 442 36 66 Tel: 0542 442 36 66 Mail:
i...@seyyareotomotiv.com Adres: Çankaya Cad. Çankaya Mah 14/1 Çankaya
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92409
--- Comment #3 from Martin Jambor ---
Created attachment 47195
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47195=edit
Hopefully the fix
I have to leave the office now but I am testing the attached fix on an x86_64 -
I have lost
From what I understood from recent fix the unordered containers need to
be updated the same way.
I hope you'll appreciate the usage of rvalue forwarding. Containers node
values are moved as soon as _M_assign is called with a rvalue reference
to the source container.
Additionnaly this patch
Before, LRA, we have an insn that sets a TImode pseudo with an integer
constant and a following insn that copies that TImode pseudo to a PTImode
pseudo. During LRA spilling, we generate a new insn that sets a PTImode
pseudo to that constant directly and we ICE because we do not recognize
that as
Hi!
On Thu, Nov 07, 2019 at 06:44:17PM +0100, Egeyar Bagcioglu wrote:
> On 11/7/19 9:03 AM, Segher Boessenkool wrote:
> >>+ ASM_OUTPUT_ASCII(asm_out_file, cmdline, cmdline_length);
> >>+}
> >>+ cmdline[0] = 0;
> >>+ ASM_OUTPUT_ASCII(asm_out_file, cmdline, 1);
> >>+
> >>+ /* The return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92090
--- Comment #13 from Peter Bergner ---
Author: bergner
Date: Thu Nov 7 18:48:45 2019
New Revision: 277928
URL: https://gcc.gnu.org/viewcvs?rev=277928=gcc=rev
Log:
Allow MODE_PARTIAL_INT modes for integer constant input operands.
gcc/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92413
David Blaikie changed:
What|Removed |Added
CC||dblaikie at gmail dot com
--- Comment
Adding hwasan tests.
Frankly, these could be tidied up a little.
I will be tidying them up while getting feedback on the hwasan introduction.
gcc/testsuite/ChangeLog:
2019-11-07 Matthew Malcomson
* c-c++-common/hwasan/arguments.c: New test.
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92413
Bug ID: 92413
Summary: [temp.explicit] Explicit template instantiations
should not define member functions that are not
defined at the point of instantiation
Product: gcc
Handling stack variables has three features.
1) Ensure HWASAN required alignment for stack variables
When tagging shadow memory, we need to ensure that each tag granule is
only used by one variable at a time.
This is done by ensuring that each tagged variable is aligned to the tag
granule
There are four main features to this change:
1) Check pointer tags match address tags.
In the new `hwasan` pass we put HWASAN_CHECK internal functions around
all memory accesses, to check that tags in the pointer being used match
the tag stored in shadow memory for the memory region being used.
These flags can't be used at the same time as any of the other
sanitizers.
We add an equivalent flag to -static-libasan in -static-libhwasan to
ensure static linking.
The -fsanitize=kernel-hwaddress option is for compiling targeting the
kernel. This flag has defaults that allow compiling KASAN
This patch does tries to tie libhwasan into the GCC build system in the
same way that the other sanitizer runtime libraries are handled.
libsanitizer/ChangeLog:
2019-11-07 Matthew Malcomson
* Makefile.am: Build libhwasan.
* Makefile.in: Build libhwasan.
*
This is an analogous option to --bootstrap-asan to configure. It allows
bootstrapping GCC using HWASAN.
For the same reasons as for ASAN we have to avoid using the HWASAN
sanitizer when compiling libiberty and the lto-plugin.
Also add a function to query whether -fsanitize=hwaddress has been
Though the library has limited support for x86, we don't have any
support for generating code targeting x86 so there is no point building
for that target.
libsanitizer/ChangeLog:
2019-11-07 Matthew Malcomson
* Makefile.am: Condition building hwasan directory.
* Makefile.in:
I have rebased this series onto Martin Liska's patches that take the most
recent libhwasan from upstream LLVM.
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00340.html
I've also cleared up some nomenclature (I had previously used the word 'colour'
a few times instead of the word 'tag' and that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92412
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92409
Martin Jambor changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92412
Bug ID: 92412
Summary: excessive errno aliasing assumption defeats
optimization
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Clang has a function level attribute,
__attribute__((no_sanitize("hwaddress")))
a feature macro
#if __has_feature(hwaddress_sanitizer)
and a blacklist section
[hwaddress]
https://clang.llvm.org/docs/SanitizerSpecialCaseList.html
I think it makes sense for the compiler to err on the side
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92411
Bug ID: 92411
Summary: conformance issue with reinterpret_cast in constant
expressions
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #22 from Rich Felker ---
And to be clear, pretty much all gcc versions from 3.4.6 to present, and all
clang/LLVM versions since they fixed some critical bugs (like -ffreestanding
not working, which was a show-stopper), are supported
Hello again Segher!
On 11/7/19 9:03 AM, Segher Boessenkool wrote:
Hi!
On Wed, Nov 06, 2019 at 06:21:34PM +0100, Egeyar Bagcioglu wrote:
+static const char *
+record_gcc_command_line_spec_function(int argc ATTRIBUTE_UNUSED, const char
**argv)
+{
+ const char *filename = argv[0];
+ FILE *out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #20 from Rich Felker ---
> After both musl and LLVM are fixed, if you then *still* feel you
> need "ws", then we can talk of course. Deal?
No, it's not a deal. Your proposal is *breaking all currently-working versions*
of clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #21 from rsandifo at gcc dot gnu.org
---
(In reply to Segher Boessenkool from comment #19)
> (In reply to Rich Felker from comment #16)
> > > Using "ws" in inline asm never made sense. It was always the same as
> > > "wa", for all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92088
--- Comment #7 from joseph at codesourcery dot com ---
Yes, pointers to VLA are variably modified (but are OK in function
arguments even for extern functions, as VLAs there get treated as [*]).
So maybe you should use C_TYPE_VARIABLE_SIZE as
Hello
On AMD GCN, I encountered the following situation in the following
testcases using the compilation flags '-O2 -ftracer -fsplit-paths':
libgomp.oacc-fortran/reduction-1.f90
libgomp.oacc-fortran/reduction-2.f90
libgomp.oacc-fortran/reduction-3.f90
gcc.c-torture/execute/ieee/pr50310.c
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92333
--- Comment #5 from Martin Sebor ---
The ICE is caused by int_const_binop (TRUNC_DIV_EXPR, maxbound, eltsize)
returning a nul for constant arguments, and caller assuming it's non-null. The
poly_int_binop function apparently doesn't know how to
On 11/7/19 6:17 PM, jose.march...@oracle.com wrote:
On 11/7/19 8:47 AM, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Nov 06, 2019 at 06:21:33PM +0100, Egeyar Bagcioglu wrote:
>> gcc/testsuite/ChangeLog:
>> 2019-11-06 Egeyar Bagcioglu
>>
>>
On 11/7/19 8:47 AM, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Nov 06, 2019 at 06:21:33PM +0100, Egeyar Bagcioglu wrote:
>> gcc/testsuite/ChangeLog:
>> 2019-11-06 Egeyar Bagcioglu
>>
>> * lib/target-supports-dg.exp: Define
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #19 from Segher Boessenkool ---
(In reply to Rich Felker from comment #16)
> > Using "ws" in inline asm never made sense. It was always the same as
> > "wa", for all cases where either could be used in inline asm at all.
>
> It
Richard Biener writes:
> On Wed, Nov 6, 2019 at 3:01 PM Richard Sandiford
> wrote:
>>
>> Richard Biener writes:
>> > On Tue, Nov 5, 2019 at 3:29 PM Richard Sandiford
>> > wrote:
>> >>
>> >> This patch adds a mode in which the vectoriser tries each available
>> >> base vector mode and picks the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #18 from Rich Felker ---
> So use "wa" instead of "ws" in the two files you use it, and can we get
> on with our lives?
Translation: Introduce a regression on all existing versions of clang because
GCC broke a documented public
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91886
--- Comment #17 from Segher Boessenkool ---
(In reply to Rich Felker from comment #13)
> > That does not look at types. It complains that "x" lives in memory,
> > while the constraint requires a register (a floating point register).
>
> That
1 - 100 of 233 matches
Mail list logo
