On Sat, Mar 28, 2020 at 06:46:54PM +, Maciej W. Rozycki wrote:
>I think being software developers we are in this comfortable position
>that we can actually make changes to software ourselves if we find
>problems or usability issues...
>
>For example I found it useful on a couple of occasions
On Sat, Mar 28, 2020 at 6:42 AM Richard Sandiford
wrote:
>
> David Edelsohn via Gcc-patches writes:
> > This patch is for an AIX problem, but the only robust solution is in
> > common code: calls.c:precompute_register_parameters().
> >
> > AIX, like other platforms, needs to call a function to
Enable big-endian suffixed dynamic linker per glibc multi-abi support.
And to avoid a future churn and version pairingi hassles, also allow
arc700 although glibc for ARC currently doesn't support it.
gcc/
-xx-xx Vineet Gupta
+
+ * config/arc/linux.h: GLIBC_DYNAMIC_LINKER support
On 3/26/20 3:40 AM, Martin Liška wrote:
Hi.
I'm suggesting to provide a warning when one uses -flto=jobserver
but we can't detect job server for some reason.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed in next stage1?
Thanks,
Martin
On 3/28/20 2:22 PM, Segher Boessenkool wrote:
> On Fri, Mar 27, 2020 at 05:41:36PM -0500, Peter Bergner wrote:
>> A different (ie, safer) approach would be to just rerun lower-subreg at
>> its old location, regardless of whether we used -fsplit-wide-types-early.
>
> That is my preference, for a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87163
--- Comment #11 from Peter Bergner ---
(In reply to Bill Seurer from comment #8)
> Cross:
> ;;
> ;; Full RTL generated for this function:
> ;;
> (note 1 0 4 NOTE_INSN_DELETED)
> (note 4 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
> (insn 2 4 3 2 (set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94385
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93946
--- Comment #13 from sandra at gcc dot gnu.org ---
Well, no. The problem is that the scheduler is moving
ldw r2, 0(r4)
ahead of
stw zero, 0(r5)
which is incorrect because the pointers in r4 and r5 are aliases.
So at
Snapshot gcc-9-20200328 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/9-20200328/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 9 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87163
--- Comment #10 from Peter Bergner ---
(In reply to Segher Boessenkool from comment #9)
> So what causes this TF vs. IF? Cross and native should be exactly the same,
> but perhaps there is a difference in the configurations you have for the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94379
Martin Sebor changed:
What|Removed |Added
Last reconfirmed||2020-03-28
CC|
On 28/03/20 00:16 +, Jonathan Wakely wrote:
On 27/03/20 23:29 +, Jonathan Wakely wrote:
@@ -403,6 +428,49 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
operator>=(const reverse_iterator<_IteratorL>& __x,
const reverse_iterator<_IteratorR>& __y)
{ return !(__x < __y); }
+#else
* testsuite/20_util/is_constructible/value-2.cc: Fix test to account
for changes due to parenthesized aggregate-initialization in C++20.
* testsuite/20_util/time_point/cons/81468.cc: Fix test to not clash
with std::chrono::sys_time in C++20.
Tested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94377
--- Comment #2 from Fred Krogh ---
I'm sorry, I made an error when making up this code from a much bigger one.
There was a missing ')' at line 8. I've corrected this in the code below.
Same kind of error here, but that code compiles on both
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94385
Bug ID: 94385
Summary: Internal compiler error for __builtin_convertvector +
statement expr
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94384
Bug ID: 94384
Summary: FAIL: gfortran.dg/fmt_f_default_field_width_3.f90 -O
(test for excess errors)
Product: gcc
Version: 10.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94381
H.J. Lu changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
Change -falign-functions=N to
Align the start of functions to the next power-of-two greater than
or equal to N.
Add
If '-falign-labels' is greater than this value, then its value is
used instead.
to -falign-loops=N and -falign-jumps=N.
OK for master?
H.J.
--
PR
Hi,
Christophe Lyon wrote 2020-03-27 19:53:
Hi,
On Fri, 20 Mar 2020 at 11:56, Roman Zhuykov via Gcc-patches
wrote:
Hi all!
12.03.2020 6:17, Jeff Law wrote:
>> Current modulo-sched implementation is a bit faulty from -fcompile-debug
>> perspective.
>>
>> But right now I see that when I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90794
--- Comment #7 from Jonathan Wakely ---
(In reply to Nicholas Krause from comment #6)
> I can confirm about building trunk from yesterday that this code no longer
> ICEs on 03. Can someone please close this bug as it no longer blocks C++ VLA
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90794
Nicholas Krause changed:
What|Removed |Added
CC||xerofoify at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87163
--- Comment #9 from Segher Boessenkool ---
So what causes this TF vs. IF? Cross and native should be exactly the same,
but perhaps there is a difference in the configurations you have for the two?
Hi!
On Sat, Mar 28, 2020 at 09:27:09AM +1030, Alan Modra wrote:
> The only difference
> besides mode between call_local32 and call_local64, dating back to
> 1998 commit a260abc996, is that call_local64 has TARGET_64BIT in the
> predicate. That alone doesn't seem reason enough to need separate
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94383
Andrew Pinski changed:
What|Removed |Added
Keywords||wrong-code
Target Milestone|---
On Fri, Mar 27, 2020 at 05:41:36PM -0500, Peter Bergner wrote:
> Given we're late in stage4, the above patch (assuming it's ok) probably
> shouldn't go in until stage1, since it is changing lower-subreg's behaviour
> slightly.
>
> A different (ie, safer) approach would be to just rerun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35014
Amir Shahmoradi changed:
What|Removed |Added
CC||a.shahmoradi at gmail dot com
---
On Fri, 27 Mar 2020, Jeff Law via Gcc wrote:
> As an ex IT guy, I've gone both directions depending on the project I was
> supporting and certainly see the pros and cons of going highly customized vs
> as
> generic as possible. In my opinion Chris & Frank are doing the right thing
> here
> and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94383
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94383
--- Comment #4 from Jonathan Wakely ---
That would be consistent with the new field being introduced in gcc-7 (by
r241187).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94383
--- Comment #3 from Jonathan Wakely ---
Is the difference maybe related to the empty field that is added for c++17
mode, mentioned in Bug 89358 comment 12?
Is the aarch64 back end not ignoring that field?
On Sat, Mar 28, 2020 at 08:10:38AM +0100, Tobias Burnus wrote:
> Two remarks:
>
> * As the file trigd_lib.inc is shared between libgfortran
> and gcc/fortran, I wonder whether it should be placed
> under include/ (under the GCC toplevel directroy)
The original name and location were chosen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94372
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84475
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |8.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94359
--- Comment #5 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #4)
> So not sure how to proceed here at the moment (I wonder if this works for
> PPC on the clang impl).
It does work for X86 (and ironically, on PPC Darwin too - where
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94383
--- Comment #2 from Jonathan Wakely ---
https://godbolt.org/z/BnTEsn is an example with both functions in the same
translation unit, showing the generated code is different for both caller and
callee. If the caller and callee are not in the same
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94383
Jonathan Wakely changed:
What|Removed |Added
Known to work||6.4.0
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94383
Bug ID: 94383
Summary: [8/9/10 Regression] class with empty base passed
incorrectly with -std=c++17
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94382
Bug ID: 94382
Summary: conflicting function types should show more context
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94349
--- Comment #9 from Jonathan Wakely ---
I created a pull request for the patch, it's linked to from that issue now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94381
H.J. Lu changed:
What|Removed |Added
Last reconfirmed||2020-03-28
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94381
Bug ID: 94381
Summary: -falign-function/-falign-labels/-falign-loops
documentation is inaccurate
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity:
On Sat, 28 Mar 2020 11:35:36 +0100
Andreas Schwab wrote:
> On Mär 28 2020, Sergei Trofimovich via Gcc wrote:
>
> > x86_64-linux-musl targets do not support multilib layout as-is
> > and usually expects libdir=lib. glibc target usually uses libdir=lib64.
>
> If x86_64-linux-musl doesn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94348
--- Comment #3 from CVS Commits ---
The master branch has been updated by Tobias Burnus :
https://gcc.gnu.org/g:3fb7f2fbd5f109786922deb5af8fd8dd594a7ba6
commit r10-7443-g3fb7f2fbd5f109786922deb5af8fd8dd594a7ba6
Author: Tobias Burnus
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94306
Patrick Palka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94252
Patrick Palka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94306
--- Comment #2 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:7981c06ae92548bd66f07121db1802eb6aec73ed
commit r10-7442-g7981c06ae92548bd66f07121db1802eb6aec73ed
Author: Patrick Palka
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94252
--- Comment #3 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:a7ea3d2ced786c4544fa625f34f515d89ed074fe
commit r10-7441-ga7ea3d2ced786c4544fa625f34f515d89ed074fe
Author: Patrick Palka
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94349
--- Comment #8 from Frédéric Buclin ---
Created attachment 48139
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48139=edit
Fix taint issue in Template/Provider.pm
I wrote a trivial patch to fix the taint issue reported in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94380
Bug ID: 94380
Summary: Nested associate+select type blocks cause compiler
segfault
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
pskocik at gmail dot com changed:
What|Removed |Added
CC||pskocik at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94379
Bug ID: 94379
Summary: Feature request: like clang, support
__attribute((__warn_unused_result__)) on structs,
unions, and enums
Product: gcc
Version: unknown
David Edelsohn via Gcc-patches writes:
> This patch is for an AIX problem, but the only robust solution is in
> common code: calls.c:precompute_register_parameters().
>
> AIX, like other platforms, needs to call a function to obtain the
> pointer to thread-local storage. If the thread local
On Mär 28 2020, Sergei Trofimovich via Gcc wrote:
> x86_64-linux-musl targets do not support multilib layout as-is
> and usually expects libdir=lib. glibc target usually uses libdir=lib64.
If x86_64-linux-musl doesn't support multilib then it should not use
i386/t-linux64 as tmake_file.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90077
Sergei Trofimovich changed:
What|Removed |Added
CC||slyfox at inbox dot ru
--- Comment
x86_64-linux-musl targets do not support multilib layout as-is
and usually expects libdir=lib. glibc target usually uses libdir=lib64.
In https://bugs.gentoo.org/675954 (also touched on https://gcc.gnu.org/PR90077)
Gentoo discovered the following discrepancy when gcc is built with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93573
--- Comment #6 from Jakub Jelinek ---
Fixed the error-recovery bug on the trunk, but the ice on the #c4 testcase is
still there (and the question is if it is valid or not). If it is valid,
probably the FE or gimplifier needs to turn that cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93573
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:c6a562de88c44a555e1688c212869b20b02151bc
commit r10-7438-gc6a562de88c44a555e1688c212869b20b02151bc
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94329
Jakub Jelinek changed:
What|Removed |Added
Summary|[8/9/10 Regression] error: |[8/9 Regression] error:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94329
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:679becf175c5d7f6b323cd3af0a09c6039b4123d
commit r10-7437-g679becf175c5d7f6b323cd3af0a09c6039b4123d
Author: Jakub Jelinek
Date:
> I'm forced to fall back to a targeted patch in
> calls.c:precompute_register_parameters() that tests exactly for TLS
> symbols on AIX instead of using the legitimate_constant_p hook to test
> for TLS symbols.
>
> I could create a new target hook for this specific use in calls.c and
> define it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94359
--- Comment #4 from Iain Sandoe ---
so, it seems:
rs6000_function_ok_for_sibcall ()
calls rs6000_decl_ok_for_sibcall ()
which gets a NULL decl and thus this returns false
/* Under the AIX or ELFv2 ABIs we can't allow calls to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93946
--- Comment #12 from rguenther at suse dot de ---
On March 27, 2020 9:19:33 PM GMT+01:00, "sandra at gcc dot gnu.org"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93946
>
>--- Comment #11 from sandra at gcc dot gnu.org ---
>RTL before
On March 28, 2020 1:50:59 AM GMT+01:00, Jakub Jelinek wrote:
>Hi!
>
>The following testcase FAILs with -fcompare-debug, because
>reassociate_bb
>mishandles the case when the last stmt in a bb has zero uses. In that
>case
>reassoc_remove_stmt (like gsi_remove) moves the iterator to the next
Two remarks:
* As the file trigd_lib.inc is shared between libgfortran
and gcc/fortran, I wonder whether it should be placed
under include/ (under the GCC toplevel directroy)
* All included files need dependency; I do not quickly
see whether that' the case.
Cheers,
Tobias
On 3/28/20
64 matches
Mail list logo
