[Bug c/54006] __atomic_always_lock_free inconsistent with __GCC_ATOMIC_INT_LOCK_FREE et al.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54006 --- Comment #6 from Hans-Peter Nilsson --- On Fri, 28 Jul 2017, egallager at gcc dot gnu.org wrote: > Testcase compiles, runs, and exits with 0 for me on i386-apple-darwin9.8.0. I'm not sure how that target is relevant? (I forgot to set a target and can't edit the bug at present other than replying by email, but see the original description for a list of targets where the test was known to fail or expected to fail. Note also that the test is brittle and may be undesirably optimized to always pass.) > Can you try again? Not for a couple of weeks, sorry. brgds, H-P
[Bug testsuite/62250] FAIL: gfortran.dg/coarray/alloc_comp_1.f90 -fcoarray=lib -O2 -lcaf_single
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62250 --- Comment #13 from Hans-Peter Nilsson hp at bitrange dot com --- On Fri, 9 Jan 2015, dje at gcc dot gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62250 David Edelsohn dje at gcc dot gnu.org changed: What|Removed |Added Target|hppa*-*-hpux* |hppa*-*-hpux*, ||powerpc-ibm-aix* CC||dje at gcc dot gnu.org Host|hppa*-*-hpux* |hppa*-*-hpux*, ||powerpc-ibm-aix* Build|hppa*-*-hpux* |hppa*-*-hpux*, ||powerpc-ibm-aix* --- Comment #12 from David Edelsohn dje at gcc dot gnu.org --- This also was failing on AIX. The failures returned after the latest patches. Please quote the top of gfortran.log, the first lines with -latomic where libatomic_avail is misidentified as missing. (There's likely an error that's misidentified as libatomic being missing.) brgds, H-P
[Bug middle-end/36177] [4.4 Regression] g++.dg/opt/pr23714.C ICEs with 135041 - 135057
--- Comment #6 from hp at bitrange dot com 2008-05-09 03:49 ---
Subject: Re: [4.4 Regression] g++.dg/opt/pr23714.C
ICEs with 135041 - 135057
On Thu, 8 May 2008, zadeck at naturalbridge dot com wrote:
I am testing this patch on x86. But hp needs to test it on the cris
before i will ask for approval.
For the record, anyone can test this target using
gcc.gnu.org/simtest-howto.html and
http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01571.html.
Anyway, I'm doing it; I just made a baseline run.
The patch was malformed; applying it gave:
patching file doc/rtl.texi
patching file dce.c
Hunk #1 succeeded at 99 with fuzz 2.
Hunk #3 FAILED at 388.
1 out of 3 hunks FAILED -- saving rejects to file dce.c.rej
Apparently TABs had been expanded or something. I applied the
rejected part manually and I'm testing the patch in the
attachment, which I hope is the same as what you have.
(I suggest attaching patches to the PR's by uploading them or
sending them as attachments; not cutnpasting into the web form
or whatever happened. I sure hope the same doesn't happen to
this one!)
Thanks for your quick action!
brgds, H-PIndex: doc/rtl.texi
===
--- doc/rtl.texi(revision 135097)
+++ doc/rtl.texi(working copy)
@@ -559,14 +559,37 @@
perhaps with the help of base registers.
Stored in the @code{unchanging} field and printed as @samp{/u}.
[EMAIL PROTECTED] CONST_OR_PURE_CALL_P
[EMAIL PROTECTED] RTL_CONST_CALL_P
@cindex @code{call_insn} and @samp{/u}
@cindex @code{unchanging}, in @code{call_insn}
[EMAIL PROTECTED] CONST_OR_PURE_CALL_P (@var{x})
-In a @code{call_insn}, @code{note}, or an @code{expr_list} for notes,
-indicates that the insn represents a call to a const or pure function.
-Stored in the @code{unchanging} field and printed as @samp{/u}.
[EMAIL PROTECTED] RTLCONST_OR_PURE_CALL_P (@var{x})
+In a @code{call_insn} indicates that the insn represents a call to a
+const function. Stored in the @code{unchanging} field and printed as
[EMAIL PROTECTED]/u}.
[EMAIL PROTECTED] RTL_PURE_CALL_P
[EMAIL PROTECTED] @code{call_insn} and @samp{/i}
[EMAIL PROTECTED] @code{return_val}, in @code{call_insn}
[EMAIL PROTECTED] RTLCONST_OR_PURE_CALL_P (@var{x})
+In a @code{call_insn} indicates that the insn represents a call to a
+pure function. Stored in the @code{return_val} field and printed as
[EMAIL PROTECTED]/i}.
+
[EMAIL PROTECTED] RTL_CONST_OR_PURE_CALL_P
[EMAIL PROTECTED] @code{call_insn} and @samp{/u} or @samp{/i}
[EMAIL PROTECTED] RTL_CONST_OR_PURE_CALL_P (@var{x})
+In a @code{call_insn}, true if @code{RTL_CONST_CALL_P} or
[EMAIL PROTECTED] is true.
+
[EMAIL PROTECTED] RTL_LOOPING_CONST_OR_PURE_CALL_P
[EMAIL PROTECTED] @code{call_insn} and @samp{/c}
[EMAIL PROTECTED] @code{call}, in @code{call_insn}
[EMAIL PROTECTED] RTL_LOOPING_CONST_OR_PURE_CALL_P (@var{x})
+In a @code{call_insn} indicates that the insn represents a possibly
+infinite looping call to a const or pure function. Stored in the
[EMAIL PROTECTED] field and printed as @samp{/c}. Only true if one of
[EMAIL PROTECTED] or @code{RTL_PURE_CALL_P} is true.
+
@findex INSN_ANNULLED_BRANCH_P
@cindex @code{jump_insn} and @samp{/u}
@cindex @code{call_insn} and @samp{/u}
@@ -869,6 +892,9 @@
@item call
In a @code{mem}, 1 means that the memory reference will not trap.
+In a @code{call}, 1 means that this pure or const call may possibly
+infinite loop.
+
In an RTL dump, this flag is represented as @samp{/c}.
@findex frame_related
@@ -938,6 +964,8 @@
In @code{symbol_ref} expressions, 1 means the referenced symbol is weak.
+In @code{call} expressions, 1 means the call is pure.
+
In an RTL dump, this flag is represented as @samp{/i}.
@findex jump
@@ -967,8 +995,8 @@
In a @code{symbol_ref} expression, 1 means that this symbol addresses
something in the per-function constant pool.
-In a @code{call_insn}, @code{note}, or an @code{expr_list} of notes,
-1 means that this instruction is a call to a const or pure function.
+In a @code{call_insn} 1 means that this instruction is a call to a const
+function.
In an RTL dump, this flag is represented as @samp{/u}.
Index: dce.c
===
--- dce.c (revision 135097)
+++ dce.c (working copy)
@@ -99,11 +99,16 @@
rtx body, x;
int i;
- /* We can delete dead const or pure calls as long as they do not
- infinite loop and are not sibling calls. The problem with
- sibling calls is that it is hard to see the result. */
- if (CALL_P (insn)
+ if (CALL_P (insn)
+ /* We cannot delete calls inside of the recursive dce because
+this may cause basic blocks to be deleted and this messes up
+the rest of the stack of optimization passes. */
+ (!df_in_progress)
+ /* We cannot delete pure or const sibling calls because it is
+hard to see the result. */
(!SIBLING_CALL_P (insn))
+ /* We can delete dead
[Bug middle-end/24750] [4.1 regression] global-alloc (reload) trips over own confusion for unexpected addressing modes
--- Comment #9 from hp at bitrange dot com 2005-11-11 01:06 --- Subject: Re: [4.1 regression] global-alloc (reload) trips over own confusion for unexpected addressing modes On Thu, 10 Nov 2005, janis at gcc dot gnu dot org wrote: --- Comment #8 from janis at gcc dot gnu dot org 2005-11-10 23:40 --- A regression hunt using a cris-axis-elf cross compiler on powerpc-linux identified this patch: r95823 | hp | 2005-03-03 03:53:29 + (Thu, 03 Mar 2005) | 40 lines http://gcc.gnu.org/viewcvs?view=revrev=95823 (Wherein SRP and MOF are first described as actual registers.) Yeah, well, sort-of. Cause of exposure, but not the bug. Nice to know that the reghunt scripts work, though! brgds, H-P -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24750
[Bug libfortran/24342] [4.1 regression] testsuite failure:gfortran.fortran-torture/execute/in-pack.f90 exe
--- Comment #7 from hp at bitrange dot com 2005-11-09 10:24 --- Subject: Re: [4.1 regression] testsuite failure:gfortran.fortran-torture/execute/in-pack.f90 exe On Wed, 9 Nov 2005, fxcoudert at gcc dot gnu dot org wrote: --- Comment #6 from fxcoudert at gcc dot gnu dot org 2005-11-09 10:08 --- OK, I see. I was only stating that glibc specifies that the feenableexcept/fedisableexcept should be available, even if they actually can't do anything (and in that case, calling them with argument 0 is fine). That's why I wasn't expecting this issue, and still think the warning not conforming to the documented behaviour. Yes, that's a valid point. OK, I guess if it removes that warning it's OK. It shouldn't break anything. I'll do it when I have some time. Thanks in advance! brgds, H-P -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24342
[Bug libfortran/24342] [4.1 regression] testsuite failure:gfortran.fortran-torture/execute/in-pack.f90 exe
--- Comment #5 from hp at bitrange dot com 2005-11-09 01:08 --- Subject: Re: [4.1 regression] testsuite failure:gfortran.fortran-torture/execute/in-pack.f90 exe On Tue, 8 Nov 2005, fxcoudert at gcc dot gnu dot org wrote: --- Comment #4 from fxcoudert at gcc dot gnu dot org 2005-11-08 11:08 --- (In reply to comment #2) In function `*_gfortrani_set_fpu':.\ /fpu-target.h:42: warning: warning: fedisableexcept is not implemented and will always fail^M You're seeing this warning only for the in-pack testcase ? No, I see it for seemingly *all* test-cases. Can you try to compile and run another testcase (not inside the library framework) and tell us what the compiler/linker says? I haven't, but please, it's unimportant; don't get hung up on the warning. See below. Since the in-pack testcase has nothing to do with the set_fpu function, I don't see how on earth this could happen... Don't worry, I do. :-) It comes from the linker, trigged by the source code for fedisableexcept, using machinery that's set up by to warn for functions that shouldn't be used, like in this case, where it's not (can't be) implemented as the warning says. So I guess you'd see it for targets where floating point rounding cannot be changed (usually, no hardware support and implemented through fp-bit.c). Well, even in that case, that shouldn't happen. If I read the doc correctly, in that case the FE_* macros are supposed not to be defined, You seem to think they are defined? They're not, except for a single: #define FE_ALL_EXCEPT 0 Looking at libgfortran/config/fpu-glibc.h::set_fpu(), I guess it'd help to, instead of an (unwrapped): fedisableexcept (FE_ALL_EXCEPT); do a: if (FE_ALL_EXCEPT != 0) fedisableexcept (FE_ALL_EXCEPT); and let gcc automatically discard the call and reference. but no warning should be issued. Not when the function is *called*, but when it's *linked in*. I'll look into it (but can't promise anything, I don't have access to such target). This warning is a red herring. The problem is elsewhere. Though I'm not likely to look at fortran FAILs myself for a while. I just thought it's be better to log it than not. brgds, H-P -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24342
[Bug tree-optimization/21638] [4.1 regression] ADDR_EXPR invariancy not recomputed
--- Additional Comments From hp at bitrange dot com 2005-05-19 14:07 --- Subject: Re: [4.1 regression] ADDR_EXPR invariancy not recomputed On Thu, 19 May 2005, giovannibajo at libero dot it wrote: --- Additional Comments From giovannibajo at libero dot it 2005-05-19 10:10 --- HP: people are expected to provide preprocessed source code even for bootstrap failures, let alone unified source tree builds for fancy platforms. This very bug shows how providing a preprocessed source made a quick fix possible. Certainly, but it would have been even quicker if people were already having simulator toolchains at hand, for testing their patches or to verify bugs. Thus I somewhat thought all bugmasters would be familiar enough with them; hopefully using them, but at least not one accusing me that I shortcut rules when not immediately providing preprocessed source for a target library there. Newlib *is* special; it's part of the toolchain and builds naturally together with simulator, binutils and gcc in one fell swoop. Much like one of the target libraries provided with gcc. Would you ask people for preprocessed source for, say, libgcc? Hm, maybe you would, by your indication of bootstrap failures. So what are you exactly complaining for? What complaint? I'm replying to *your* complaint, and attempt to lecture me on your interpretation of some rule you read, presumably that we ask people for preprocessed source when reporting bugs. If you want a bug fixed, be helpful like everybody does. Eh, I think I was/did. :-) The fact that you are a maintainer does not buy you to shortcut rules and expect people to do the work in your place. What? Where did you get *that* from? I resent that accusation! I certainly don't expect bugs to be fixed just because I report them in bugzilla. I also don't expect a bugmaster to start an inproductive argument, but that might be just because I'm a maintainer. ;-) I never expect people to fix a bug exposed by the targets I maintain unless they're the one that made the bug or to some extent when they write code that expose a bug. So many thanks to pinskia! Much unexpected, very much appreciated. Worth the enormous amount of work it takes to upload the preprocessed sources. ;-) brgds, H-P -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21638
[Bug target/18701] [4.0 regression] mmix-knuth-mmixware gcc.c-torture/execute failures: 20010224-1.c, 20020216-1.c, 20040218-1.c, 20040709-2.c
--- Additional Comments From hp at bitrange dot com 2004-12-20 01:00 --- Subject: Re: [4.0 regression] mmix-knuth-mmixware gcc.c-torture/execute failures: 20010224-1.c, 20020216-1.c, 20040218-1.c, 20040709-2.c On Sun, 20 Dec 2004, steven at gcc dot gnu dot org wrote: --- Additional Comments From steven at gcc dot gnu dot org 2004-12-20 00:54 --- This is not assigned. Likely because of a bug in bugzilla: I pressed the verify-and-assign-to-me button. Then again... brgds, H-P -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18701
[Bug target/18347] [3.4/4.0 regression] mmix-knuth-mmixware testsuite failure: gcc.dg/uninit-C.c
--- Additional Comments From hp at bitrange dot com 2004-11-13 01:25 --- Subject: Re: [3.4/4.0 regression] mmix-knuth-mmixware testsuite failure: gcc.dg/uninit-C.c On Fri, 12 Nov 2004, pinskia at gcc dot gnu dot org wrote: --- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-12 23:03 --- This is definitely a target bug, mmix_function_outgoing_value does not support TI mode at all. Nope. The target isn't supposed to have to support TImode. What makes you think it has to support TImode? brgds, H-P -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18347
[Bug target/18347] [3.4/4.0 regression] mmix-knuth-mmixware testsuite failure: gcc.dg/uninit-C.c
--- Additional Comments From hp at bitrange dot com 2004-11-13 05:36 --- Subject: Re: [3.4/4.0 regression] mmix-knuth-mmixware testsuite failure: gcc.dg/uninit-C.c On Sat, 13 Nov 2004, pinskia at gcc dot gnu dot org wrote: --- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-13 05:25 --- Because that is what the testcase is testing :). That doesn't make it a target-bug, i.e. in the target description. If the target hasn't asked to see TImode, it shouldn't have to handle it. I suggest you leave the analysis to me. brgds, H-P -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18347
