From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 494 invoked by alias); 9 May 2015 18:47:37 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 468 invoked by uid 48); 9 May 2015 18:47:32 -0000 From: "mikael at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/66089] elemental dependency mishandling when derived types are involved Date: Sat, 09 May 2015 18:47:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 6.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: mikael at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-05/txt/msg00762.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D66089 --- Comment #1 from Mikael Morin --- Draft patch: Index: trans-array.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- trans-array.c (r=C3=A9vision 222968) +++ trans-array.c (copie de travail) @@ -2449,13 +2449,6 @@ gfc_scalar_elemental_arg_saved_as_reference (gfc_s && ss_info->expr->ts.type =3D=3D BT_CLASS) return true; - /* If the expression is a data reference of aggregate type, - avoid a copy by saving a reference to the content. */ - if (ss_info->expr->expr_type =3D=3D EXPR_VARIABLE - && (ss_info->expr->ts.type =3D=3D BT_DERIVED - || ss_info->expr->ts.type =3D=3D BT_CLASS)) - return true; - /* Otherwise the expression is evaluated to a temporary variable before = the scalarization loop. */ return false; >>From gcc-bugs-return-485923-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat May 09 19:01:55 2015 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 84493 invoked by alias); 9 May 2015 19:01:54 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 84457 invoked by uid 48); 9 May 2015 19:01:51 -0000 From: "iains at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug debug/61352] gcc 4.9.0 fails to execute dsymutil when linking executables on darwin Date: Sat, 09 May 2015 19:01:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: debug X-Bugzilla-Version: 4.9.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: iains at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-05/txt/msg00763.txt.bz2 Content-length: 2449 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D61352 --- Comment #14 from Iain Sandoe --- (In reply to Joel Brobecker from comment #13) > Sorry guys, but dsymutil is not working very well. I have a couple of > examples where, either dsymutil is excluding some DIEs from the DWARF ima= ge, > or where dsymutil actually segfaults.=20 I think we all see this to some degree-or-other... >There is also the fact that dsymutil > doesn't know about recent DWARF enhancements, and doesn't work well when > compiling code with -gno-strict-dwarf. I think that's pretty much "not supported" with dsymutil; even the LLVM pro= ject makes concessions to the need to support older DWARF output for OS X=E2=80= =A6=20=20 I'd also wonder if it's 100% safe w.r.t ld64, and other items from the DWARFutils package (although objdump & friends are pretty good for mach-o, = they are not a standard build for most folks). however >Since we do not control dsymutil and its quality level (or lack thereof),= =20 Yeah .. 'tis the one thing we can't fix at present... =E2=80=A6 (let's cross fingers for llvm-dsymutil maturing quickly). > GDB should be able to use the debug info from the object files without > requiring the use of dsymutil.=20 >I suggest the best course of action is > trying to figure out why GDB doesn't pick the debugging info up from the = .o > files, and then fix that. That's a good idea. My experience is that it's quite variable, sometimes using GDB on the *.o w= orks better =E2=80=A6 sometimes the .dSYM works better. > In the meantime, I suggest we revert this change, or else make it optional > at the very least. case 1. gcc foo.o bar.o baz.o =E2=80=A6 <=3D should *not* invoke dsymutil = - should work "as expected" with the .o files. case 2. gcc foo.o bar.o bad.c <=3D should invoke dsymutil. In this case, you don't have baz.o, since it's a temporary file - so you ca= n't use it for debug (hence the secondary purpose of dsymutil). You'd need 'save-temps' on the c/l to ensure this... So we we could try amending the link spec to suppress the call of dsymutil = if "save-temps" is on the c/l? I'm kinda in favour of this, since we *don't* have control over dsymutil an= d it won't be fixed for darwin < bleeding edge even if a radar is filed - I assu= me radar(s) have been filed for the issues? > PS: Our experiments are on Darwin 13.4 and 14.3. It's much the same across the board Darwin9+ >>From gcc-bugs-return-485924-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat May 09 21:29:28 2015 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 12409 invoked by alias); 9 May 2015 21:29:28 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 12366 invoked by uid 48); 9 May 2015 21:29:24 -0000 From: "aaron at aarongraham dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/58931] condition_variable::wait_until overflowed by large time_point Date: Sat, 09 May 2015 21:29:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libstdc++ X-Bugzilla-Version: 4.8.2 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: aaron at aarongraham dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-05/txt/msg00764.txt.bz2 Content-length: 1780 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58931 Aaron Graham changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aaron at aarongraham dot com --- Comment #3 from Aaron Graham --- This is still a problem in current gcc trunk. The bug is in the condition_variable::wait_until clock conversion. It doesn't check for overflow in that math. Since the steady_clock and system_clock epochs can be very different, it's likely to overflow with values much less than max(). template cv_status wait_until(unique_lock& __lock, const chrono::time_point<_Clock, _Duration>& __atime) { // DR 887 - Sync unknown clock to known clock. const typename _Clock::time_point __c_entry = _Clock::now(); const __clock_t::time_point __s_entry = __clock_t::now(); const auto __delta = __atime - __c_entry; const auto __s_atime = __s_entry + __delta; return __wait_until_impl(__lock, __s_atime); } I modified my version of gcc to use steady_clock as condition_variable's "known clock" (__clock_t). This is more correct according to the C++ standard and most importantly it makes condition_variable resilient to clock changes when used in conjunction with steady_clock. Because of this, in my case, it works fine with steady_clock::time_point::max(), but fails with system_clock::time_point::max(). Because I made that change and since I don't do timed waits on system_clock (which is unsafe), the overflow hasn't been a problem for me and I haven't fixed it.