[ was: Re: [RFC] Add check_effective_target_vect_min_max ]
On 12-08-15 12:06, Richard Biener wrote:
On Wed, 12 Aug 2015, Rainer Orth wrote:
Tom de Vries writes:
On 12/08/15 10:51, Rainer Orth wrote:
Tom de Vries writes:
This follow-up patch introduces a new effective target vect_min_max
10-day *ping* for my 3 Fortran patches:
- Handle invalid command line in EXECUTE_COMMAND_LINE
(https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00758.html)
- Use libbacktrace in libgfortran
(https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00762.html)
- Fix configure test for weakref support
(https:/
On 2015.08.20 at 17:49 +0200, Markus Trippelsdorf wrote:
> On 2015.08.13 at 12:31 +0300, Yuri Rumyantsev wrote:
> > Hi All,
> >
> > Here is patch for adding march/mtune options for Skylake.
>
> http://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/desktop-6th-gen-core-
I've committed this patch, which fixes gcc.dg/compat/struct-by-value-11
That test passes 'complex char', which is split into two char arguments. We
fail to promote the type in one place, leading to a PTX type mismatch where we
claim an 8 bit type is a 32 bit type.
nathan
2015-08-23 Nathan
linemap_position_for_loc_and_offset() tries to generate a location_t
encoding a column offset from the current location, for example, point
to a certain character inside a string. This is trivial to do when the
new location "fits within" the map of the original location. However,
it may happen that
On Sat, 2015-08-22 at 18:04 +0100, Pedro Alves wrote:
> I noticed that regenerating binutils/configure or gdb/configure
> undoes the libiconv changes done here:
[snip]
> However, that commit does not include any config/iconv.m4/AM_ICONV
> change. Looks like you forgot to attach the config/iconv.m
On Fri, Aug 14, 2015 at 10:54 AM, FX wrote:
> The attached patch fixes PR 62296
> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62296). The Fortran
> interpretation there was a bit confused (see links to comp.lang.fortran
> thread from the PR), but the consensus is that the standard makes a
>
On Fri, Aug 14, 2015 at 5:18 PM, FX wrote:
>>> Use libbacktrace (instead of our own unwind-based code) to display
>>> backtraces from libgfortran
>>> upon error or user request.
>>>
>>> 1. In toplevel Makefile.def, make libgfortran depend on libbacktrace (needs
>>> global reviewer
>>> approval)
> Awesome! Looks good. I only have one small bikeshed request: Can you
> make the output format match the existing code?
Problem with that is that ad the new backtrace uses full path for file names,
the one-line format easily wraps in 80 column and make the output harder to
read (in my opinion)
On Sun, Aug 23, 2015 at 11:14 PM, FX wrote:
>
>> Awesome! Looks good. I only have one small bikeshed request: Can you
>> make the output format match the existing code?
>
> Problem with that is that ad the new backtrace uses full path for file names,
> the one-line format easily wraps in 80 colum
> Otherwise looks good, but strncat is C99, and we support targets which
> don't have a C99 libc (been there, done that..). Since in this case
> you're dealing with string literals rather than user input, it ought
> to be safe to just use plain strcat (or strlen+memcpy, if you prefer).
Nope, strnc
> Ah, I didn't realize that. I guess you're right, it's better to split
> the filename:linenumber to a separate line. But still, I think it's
> clearer if you keep the "in" and "at" like the current code & gdb
> does. Thus, something like
>
> #framenumber 0xADDRESS in funcname
>at filename:lin
12 matches
Mail list logo
