[Bug libstdc++/67403] std::regex is not matching

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67403 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

Re: [c++-delayed-folding] fold_simple

On 08/31/2015 03:43 PM, Kai Tietz wrote: 2015-08-31 21:29 GMT+02:00 Jason Merrill : On 08/31/2015 03:08 PM, Kai Tietz wrote: I will need to verify that this patch doesn't introduce regressions. The wacky thing here is the encapsulation of overflowed-arguments in

Re: [PING] Re: [PATCH] c/66516 - missing diagnostic on taking the address of a builtin function

Attached is an updated patch that avoids diagnosing taking the address of implicitly declared library builtins like abs, bootstrapped and tested on ppc64le with no regressions. The tweak below was added to reject_gcc_builtin make it possible. Since the expression is in c-family/c-common.c, the

Re: Acceptance criteria for the git conversion

On Tue, Sep 1, 2015 at 10:26 AM, Mikhail Maltsev wrote: > On 09/01/2015 01:54 PM, Eric S. Raymond wrote: >> With the machinery for the git conversion now in reasonable shape, it's >> time to ask GCC's developers in general: what do you want this >> conversion to accomplish? >

[PATCH, PR67405, committed] Avoid NULL pointer dereference

Hi, This fixes an ICE by adding a NULL check. Bootstrapped and regtested for x86_64-unknown-linux-gnu. Applied to trunk. Does this need to be ported to gcc-5-branch? Thanks, Ilya -- gcc/ 2015-09-01 Ilya Enkovich PR target/67405 * tree-chkp.c

[Bug libstdc++/67408] assumes that __gthread_mutex_t and__gthread_recursive_mutex_t are the same types

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67408 --- Comment #2 from Jonathan Wakely --- Created attachment 36276 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36276=edit Handle recursive mutexes with different types. Does this work for your target?

[Bug preprocessor/55115] [4.9/5/6 Regression] missing headers as fatal breaks cproto logic

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55115 RGomes changed: What|Removed |Added CC||Robert.Gomes at igt dot com --- Comment #16

[Bug libstdc++/67408] assumes that __gthread_mutex_t and__gthread_recursive_mutex_t are the same types

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67408 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed|

[PATCH] Add __builtin_argument_pointer

On Wed, Aug 19, 2015 at 3:35 PM, Segher Boessenkool wrote: > On Wed, Aug 19, 2015 at 03:18:46PM -0700, H.J. Lu wrote: >> @deftypefn {Built-in Function} {void *} __builtin_argument_pointer (void) >> This function is similar to @code{__builtin_frame_address} with an >>

[Bug libstdc++/67408] assumes that __gthread_mutex_t and__gthread_recursive_mutex_t are the same types

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67408 --- Comment #1 from Jonathan Wakely --- I didn't think that code was usable on non-POSIX systems, and for POSIX they are the same type. I'll see what I can do about it.

[Bug regression/67415] [5/6 Regression] -mcpu= breaks -print-file-name for ARM crosscompilers

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67415 Richard Earnshaw changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed|

[PATCH][optabs][ifcvt][0/3] Define negcc, notcc optabs and use for if-conversion

Hi all, This patch series aims to improve the use of conditional negate and conditional invert instructions when if-converting code of the form: x := test ? -a : a; or x := test ? ~a : a; I'd like to generate something like: x := a; if (test) x := -x; where the latter if-statement can be

[PATCH][AArch64][2/3] Implement negcc, notcc optabs

Hi all, This second patch implements the new optabs for aarch64. The new expander is almost identical to the movcc expander except that operand 2 has a neg or a not before it to reflect the fact that it should be negated if the comparison in operand 1 holds. These patterns will eventually match

[PATCH][ARM][3/3] Implement negsicc, notsicc optabs

Hi all, This third patch implements the new optabs for arm. Conveniently, we can reuse the recently refactored *if_neg_move pattern and extend it to cover the conditional NOT case. Although arm has conditional execution capabilities I have found that performing the transformation from patch 1/3

[PATCH][optabs][ifcvt][1/3] Define negcc, notcc optabs

Hi all, This first patch introduces the negcc and notcc optabs that should expand to a conditional negate or a conditional bitwise complement operation. These are used in ifcvt.c to transform code of the form: if (test) x = -A; else x = A; into: x = A; if (test) x = -x; where the "if (test) x

Re: [committed] taking transactional credits

On Tue, Sep 1, 2015 at 4:10 PM, Aldy Hernandez wrote: > On 09/01/2015 07:03 AM, Richard Henderson wrote: >> >> On 09/01/2015 06:55 AM, Aldy Hernandez wrote: >>> >>> If you don't like it, sue me. =) >> >> >> Share the blame... ;-) > > > That's right! I ain't going down in

Re: [Patch, libstdc++] Fix data races in basic_string implementation

On 01/09/15 16:56 +0200, Dmitry Vyukov wrote: I don't understand how a new gcc may not support __atomic builtins on ints. How it is even possible? That's a portable API provided by recent gcc's... The built-in function is always defined, but it might expand to a call to an external function in

Re: [committed] taking transactional credits

On 09/01/2015 08:05 AM, Patrick Marlier wrote: On Tue, Sep 1, 2015 at 4:10 PM, Aldy Hernandez wrote: On 09/01/2015 07:03 AM, Richard Henderson wrote: On 09/01/2015 06:55 AM, Aldy Hernandez wrote: If you don't like it, sue me. =) Share the blame... ;-) That's right!

Re: Action stamps

On 1 September 2015 at 10:21, Eric S. Raymond wrote: > Jason Merrill : >> Given git aliases: >> >> >stamp = show -s --format='%cI!%ce' >> >scommit = "!f(){ d=${1%%!*}; a=${1##*!}; arg=\"--until=$d -1\"; if >> > [ $a != $1 ]; then arg=\"$arg --committer=$a\"; fi;

Re: Repository for the conversion machinery

On Fri, 28 Aug 2015 17:50:53 + Joseph Myers wrote: > shinwell = Mark Shinwell > (Jane Street) Mark's current address is mshinw...@janestreet.com. Julian

Re: [Patch, libstdc++] Fix data races in basic_string implementation

On Tue, Sep 1, 2015 at 4:27 PM, Jonathan Wakely wrote: > On 01/09/15 14:51 +0200, Dmitry Vyukov wrote: >> >> Hello, >> >> The refcounted basic_string implementation contains several data races >> on _M_refcount: >> 1. _M_is_leaked loads _M_refcount concurrently with mutations

Re: [PATCH][ARM][3/3] Implement negsicc, notsicc optabs

> On Sep 1, 2015, at 11:04 PM, Kyrill Tkachov wrote: > > Hi all, > > This third patch implements the new optabs for arm. > Conveniently, we can reuse the recently refactored *if_neg_move pattern > and extend it to cover the conditional NOT case. > Although arm has

[PATCH][ARM][3/3] Implement negsicc, notsicc optabs

[Resending with patch attached] Hi all, This third patch implements the new optabs for arm. Conveniently, we can reuse the recently refactored *if_neg_move pattern and extend it to cover the conditional NOT case. Although arm has conditional execution capabilities I have found that performing

[Bug fortran/67419] gfortran.dg/large_real_kind_2.F90 FAILs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67419 --- Comment #3 from Francois-Xavier Coudert --- (In reply to r...@cebitec.uni-bielefeld.de from comment #2) > The result is identical for both the mainline libgfortran.so.3 and the > bundled gcc 4.8 libgfortran.so.3, so this might well be a libm

[RFC] Try vector as a new representation for vector masks

On 27 Aug 09:55, Richard Biener wrote: > On Wed, Aug 26, 2015 at 5:51 PM, Ilya Enkovich wrote: > > > > Yes, I want to try it. But getting rid of bool patterns would mean > > support for all targets currently supporting vec_cond. Would it be OK > > to have vector mask

[Bug fortran/67419] gfortran.dg/large_real_kind_2.F90 FAILs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67419 --- Comment #7 from Francois-Xavier Coudert --- (In reply to r...@cebitec.uni-bielefeld.de from comment #5) > If I drop the __builtin_ and include and instead, I > get the expected Then the math.h header is playing tricks and GCC is not

Re: [testsuite] Don't xfail gcc.dg/vect/no-scevccp-outer-11.c

On Tue, 1 Sep 2015, Rainer Orth wrote: > It seems that since 20150717, gcc.dg/vect/no-scevccp-outer-11.c XPASSes > everywhere: > > XPASS: gcc.dg/vect/no-scevccp-outer-11.c scan-tree-dump-times vect "OUTER > LOOP VECTORIZED." 1 > > To reduce testsuite noise, I'd like to remove the xfail as

Re: [PATCH] gcc/fold-const.c: Correct the report warning position.

On 8/31/15 19:12, Richard Biener wrote: > On Sat, Aug 29, 2015 at 2:57 PM, Chen Gang > wrote: >> >> It is about bug63510: current input_location isn't precise for reporting >> warning. The correct location is gimple location of current statement. > > Looks ok to me.

Re: [PATCH] add initial support for J2 core to sh target

Hi Rich, On 01 Sep 2015, at 02:49, Rich Felker wrote: > The J2 Core is an open hardware cpu implementing the SH-2 instruction > set, with the addition of barrel shift instructions and an atomic > compare-and-swap instruction. This patch adds a cpu model option -mj2 > to the sh

[Bug fortran/67422] memcpy incorrectly used to copy (potentially) overlapping assumed-size arrays

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67422 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug fortran/67422] memcpy incorrectly used to copy (potentially) overlapping assumed-size arrays

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67422 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org

[Bug middle-end/67295] [ARM][6 Regression] FAIL: gcc.target/arm/builtin-bswap-1.c scan-assembler-times revshne\\t 1

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67295 --- Comment #2 from ktkachov at gcc dot gnu.org --- (In reply to Alexandre Oliva from comment #1) > I get exactly the same code with r226900, before the copyrename patch: > > cmp r1, #0 > rev16ne r0, r0 > uxthne r0,

[Bug target/67417] powerpc64 bootstrap with -mcmodel=small results in linker error

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67417 --- Comment #3 from Alan Modra --- Yes, exactly. When a COMDAT group in another file is chosen, the rs6000 predicate current_file_function_operand gets the wrong answer. COMDAT group functions use weak symbols, and weak symbols more generally

[Bug fortran/67419] gfortran.dg/large_real_kind_2.F90 FAILs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67419 --- Comment #6 from Francois-Xavier Coudert --- (In reply to r...@cebitec.uni-bielefeld.de from comment #4) >> int main (void) >> { >> long double x; >> x = 789.1356; >> __builtin_printf ("%.30Lg\n", x); >> __builtin_printf ("%.30Lg\n",

[Bug fortran/67419] gfortran.dg/large_real_kind_2.F90 FAILs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67419 --- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #6 from Francois-Xavier Coudert --- > (In reply to r...@cebitec.uni-bielefeld.de from comment #4) >>> int main (void) >>> { >>> long double x; >>> x = 789.1356; >>>

[Bug fortran/67420] gfortran.dg/norm2_3.f90 FAILs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67420 Francois-Xavier Coudert changed: What|Removed |Added Status|UNCONFIRMED |SUSPENDED Last reconfirmed|

Re: getrlimit compatibility issues

On Tue, 1 Sep 2015, Jan Hubicka wrote: > > On Tue, 1 Sep 2015, Jan Hubicka wrote: > > > > > > > Yep, this looks like a resonable direction. It will break the one > > > > > declaration > > > > > rule in a more wild sense than current frontends does so, because if > > > > > a builtin > > > > >

Re: [PATCH][GCC] Algorithmic optimization in match and simplify

Hi Marc, On 28/08/15 19:07, Marc Glisse wrote: (not a review, I haven't even read the whole patch) On Fri, 28 Aug 2015, Andre Vieira wrote: 2015-08-03 Andre Vieira * match.pd: Added new patterns: ((X {&,<<,>>} C0) {|,^} C1) {^,|} C2) (X {|,^,&}

Re: [c++-delayed-folding] fold_simple

2015-09-01 13:17 GMT+02:00 Kai Tietz : > 2015-09-01 10:43 GMT+02:00 Kai Tietz : >> 2015-09-01 10:15 GMT+02:00 Kai Tietz : >>> 2015-08-31 22:19 GMT+02:00 Kai Tietz : 2015-08-31 21:43 GMT+02:00

[committed] taking transactional credits

I've had too many sleepless nights caused by this code, not to warrant tattooing my name on it. If you don't like it, sue me. =) Aldy commit 7d92b913093c35cb6fb322d4dc9acb237cecabfe Author: Aldy Hernandez Date: Tue Sep 1 06:51:45 2015 -0700 + * trans-mem.c: Add

[Bug target/61578] [4.9 regression] Code size increase for ARM thumb compared to 4.8.x when compiling with -Os

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578 --- Comment #20 from Vladimir Makarov --- (In reply to Fredrik Hederstierna from comment #19) > I'm not sure why bug 59535 was closed, same problem might still exist, quote: > > > Zhenqiang Chen 2014-09-03 06:17:44 UTC > > > > Here is a small

Re: [RS6000] Weak functions may not be file local

On Tue, Sep 1, 2015 at 3:51 AM, Alan Modra wrote: > A weak symbol defined in the current object file may not turn out to > be the definition used at link time, if other copies of the symbol > exist. This means they can't be considered file local; Calls to > weak functions need

[Bug target/61578] [4.9 regression] Code size increase for ARM thumb compared to 4.8.x when compiling with -Os

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578 --- Comment #21 from Fredrik Hederstierna --- Great, thanks! Just a note as you are looking into this, neither GCC 4.8.x nor GCC 5.2.x produces the optimal code I think for this case, isn't it better

Re: [Patch, libstdc++] Fix data races in basic_string implementation

On 01/09/15 14:51 +0200, Dmitry Vyukov wrote: Hello, The refcounted basic_string implementation contains several data races on _M_refcount: 1. _M_is_leaked loads _M_refcount concurrently with mutations of _M_refcount. This loads needs to be memory_order_relaxed load, as _M_is_leaked predicate

Re: Acceptance criteria for the git conversion

On 09/01/2015 01:54 PM, Eric S. Raymond wrote: > With the machinery for the git conversion now in reasonable shape, it's > time to ask GCC's developers in general: what do you want this > conversion to accomplish? There was some discussion concerning file renaming:

[Bug fortran/67422] memcpy incorrectly used to copy (potentially) overlapping assumed-size arrays

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67422 --- Comment #1 from Andrew Pinski --- > memcpy is not guaranteed to work if the memory locations for a and b overlap, > which could be the case here. In Fortran code, they cannot be the same location and if they are then it is undefined code.

[Bug fortran/67419] gfortran.dg/large_real_kind_2.F90 FAILs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67419 --- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE --- >> --- Comment #3 from Francois-Xavier Coudert >> --- >> (In reply to r...@cebitec.uni-bielefeld.de from comment #2) >>> The result is identical for both the mainline libgfortran.so.3

Re: [libstdc++] dg-require-atomic-builtins on ARM

On 01/09/15 14:22, Andreas Schwab wrote: Sebastian Huber writes: How do the other ARM testers tackle this issue? Would it be possible to add for example a "-march=armv7-a" option if the target selector contains "arm"?

Re: [testsuite] Don't xfail gcc.dg/vect/no-scevccp-outer-11.c

Richard Biener writes: > On Tue, 1 Sep 2015, Rainer Orth wrote: > >> It seems that since 20150717, gcc.dg/vect/no-scevccp-outer-11.c XPASSes >> everywhere: >> >> XPASS: gcc.dg/vect/no-scevccp-outer-11.c scan-tree-dump-times vect "OUTER >> LOOP VECTORIZED." 1 >> >> To reduce

Re: [PATCH][GCC] Algorithmic optimization in match and simplify

On Tue, Sep 1, 2015 at 3:40 PM, Andre Vieira wrote: > Hi Marc, > > On 28/08/15 19:07, Marc Glisse wrote: >> >> (not a review, I haven't even read the whole patch) >> >> On Fri, 28 Aug 2015, Andre Vieira wrote: >> >>> 2015-08-03 Andre Vieira

Re: [libstdc++] dg-require-atomic-builtins on ARM

Sebastian Huber writes: > Thanks for this hint. Do you know the magic to use more than one machine > option, e.g. -march=armv7-a -mthumb? RUNTESTFLAGS=--target_board=unix\{,-march=armv7-a/-mthumb\} Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG

Re: [committed] taking transactional credits

On 09/01/2015 07:03 AM, Richard Henderson wrote: On 09/01/2015 06:55 AM, Aldy Hernandez wrote: If you don't like it, sue me. =) Share the blame... ;-) That's right! I ain't going down in posterity alone on this.

Re: [PATCH] add initial support for J2 core to sh target

On Tue, Sep 01, 2015 at 10:45:10PM +0900, Oleg Endo wrote: > Hi Rich, > > On 01 Sep 2015, at 02:49, Rich Felker wrote: > > > The J2 Core is an open hardware cpu implementing the SH-2 instruction > > set, with the addition of barrel shift instructions and an atomic > >

[Bug fortran/67419] gfortran.dg/large_real_kind_2.F90 FAILs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67419 --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #1 from Francois-Xavier Coudert --- > Can you run the following test and paste the output here? [...] Sure: 16 789.1356201171875

[Bug fortran/67419] gfortran.dg/large_real_kind_2.F90 FAILs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67419 --- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #3 from Francois-Xavier Coudert --- > (In reply to r...@cebitec.uni-bielefeld.de from comment #2) >> The result is identical for both the mainline libgfortran.so.3 and the

Re: Acceptance criteria for the git conversion

On Tue, 2015-09-01 at 06:54 -0400, Eric S. Raymond wrote: > With the machinery for the git conversion now in reasonable shape, it's > time to ask GCC's developers in general: what do you want this > conversion to accomplish? > > There are some obvious things we might expect it to accomplish,

[Bug fortran/67419] gfortran.dg/large_real_kind_2.F90 FAILs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67419 --- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> --- >> --- Comment #7 from Francois-Xavier Coudert >> --- >> (In reply to r...@cebitec.uni-bielefeld.de

Re: [committed] taking transactional credits

On 09/01/2015 06:55 AM, Aldy Hernandez wrote: If you don't like it, sue me. =) Share the blame... ;-) r~

Re: getrlimit compatibility issues

> On Tue, 1 Sep 2015, Jan Hubicka wrote: > > > > > Yep, this looks like a resonable direction. It will break the one > > > > declaration > > > > rule in a more wild sense than current frontends does so, because if a > > > > builtin > > > > win as a prevailing declaration, we end up with no

[Bug fortran/67419] gfortran.dg/large_real_kind_2.F90 FAILs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67419 --- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #7 from Francois-Xavier Coudert --- > (In reply to r...@cebitec.uni-bielefeld.de from comment #5) >> If I drop the __builtin_ and include and instead, I >> get the

Re: [testsuite] Clean up effective_target cache

On 25 August 2015 at 17:31, Mike Stump wrote: > On Aug 25, 2015, at 1:14 AM, Christophe Lyon > wrote: >> Some subsets of the tests override ALWAYS_CXXFLAGS or >> TEST_ALWAYS_FLAGS and perform effective_target support tests using >> these

[Bug fortran/50555] synonymous namelist/statement function dummy argument not allowed (r178939)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50555 --- Comment #4 from Vittorio Zecca --- Sorry, you are right, the compiler should emit an error message instead it wrongly accepts the code. I was confused, this time the right behaviour is to emit an error message.

Re: [RFC] Try vector as a new representation for vector masks

On Tue, Sep 1, 2015 at 3:08 PM, Ilya Enkovich wrote: > On 27 Aug 09:55, Richard Biener wrote: >> On Wed, Aug 26, 2015 at 5:51 PM, Ilya Enkovich >> wrote: >> > >> > Yes, I want to try it. But getting rid of bool patterns would mean >> > support for

[Bug c/67423] printf.h does not compile with O1 or above

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67423 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed|

Re: [c++-delayed-folding] fold_simple

On 09/01/2015 11:27 AM, Kai Tietz wrote: I rewrote binary/unary overflow-check logic so, that we avoid double checking-s. I think this address things as you intend, beside the checking for constant value. We would need to check for *_CST tree-codes. Is there a macro we could use, which is

[Bug c/67423] printf.h does not compile with O1 or above

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67423 sl at dataconnection dot com changed: What|Removed |Added Status|WAITING |RESOLVED

Re: GTY / gengtype question - adding a new header file

On Tue, 2015-09-01 at 08:11 +0100, Richard Sandiford wrote: > config.gcc would need to add mips-private.h to target_gtfiles. OK, that was what I missed. > I'm not sure splitting the file is a good idea though. At the moment > the definitions of all target hooks must be visible to a single TU.

[Bug c/67423] New: printf.h does not compile with O1 or above

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67423 Bug ID: 67423 Summary: printf.h does not compile with O1 or above Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c

[Bug libstdc++/67408] assumes that __gthread_mutex_t and__gthread_recursive_mutex_t are the same types

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67408 --- Comment #3 from Jonathan Wakely --- Created attachment 36277 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36277=edit Handle recursive mutexes with different types. Or this, which is probably easier on the compiler.

Re: [c++-delayed-folding] fold_simple

2015-09-01 16:47 GMT+02:00 Jason Merrill : > On 08/31/2015 03:43 PM, Kai Tietz wrote: >> >> 2015-08-31 21:29 GMT+02:00 Jason Merrill : >>> >>> On 08/31/2015 03:08 PM, Kai Tietz wrote: I will need to verify that this patch doesn't introduce

Re: Acceptance criteria for the git conversion

Joseph Myers : > With 227369 revisions I don't think adding git-style summary lines is > really practical without some very reliable automation to match commits to > corresponding gcc-patches messages (whose Subject: headers would be the > natural choice for such

[Bug c/67423] printf.h does not compile with O1 or above

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67423 --- Comment #2 from Jonathan Wakely --- (In reply to sl from comment #0) > If I have a test file consisting of > > #include > > and I do "gcc -c -O1 ", the compile fails with > > /usr/include/printf.h:116:68: error: expected initializer

[Bug libstdc++/67408] assumes that __gthread_mutex_t and__gthread_recursive_mutex_t are the same types

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67408 --- Comment #5 from Sebastian Huber --- (In reply to Sebastian Huber from comment #4) > I think the your second version doesn't work in case the types are equal, it > looks similar to my first attempt to fix

[Bug libstdc++/67408] assumes that __gthread_mutex_t and__gthread_recursive_mutex_t are the same types

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67408 --- Comment #6 from Jonathan Wakely --- (In reply to Sebastian Huber from comment #4) > Sorry, I should have linked my patch: > > https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00028.html AH yes, that would work too, and doesn't require the

Re: [Patch, libstdc++] Fix data races in basic_string implementation

On Tue, Sep 1, 2015 at 5:08 PM, Jonathan Wakely wrote: > On 01/09/15 16:56 +0200, Dmitry Vyukov wrote: >> >> I don't understand how a new gcc may not support __atomic builtins on >> ints. How it is even possible? That's a portable API provided by >> recent gcc's... > > > The

Re: [PATCH] Fix ICE when generating a vector shift by scalar

On Tue, 2015-09-01 at 11:01 +0200, Richard Biener wrote: > On Mon, Aug 31, 2015 at 10:28 PM, Bill Schmidt > wrote: > > Hi, > > > > The following simple test fails when attempting to convert a vector > > shift-by-scalar into a vector shift-by-vector. > > > > typedef

Re: Action stamps

Jason Merrill : > Here's an improved version: You wrote: # git scommit - list most recent commit that matches . # Must also specify a branch to search or --all. Where must the branch argument appear with respect to the other arguments? Am I correct that this should be

Re: Acceptance criteria for the git conversion

"Eric S. Raymond" writes: > There is no way to maintain those links for git, so yes, you want to > keep a read-only Subversion instance around. The mapping can also be put in some git notes tree for use by bugzilla. That would only need to be set up once. Andreas. --

[gomp4] ptx assembler formatting

In looking at some ptx output, OCD kicked in and I couldn't tolerate the formatting inconsistencies. Fixed with this patch. Also, the mechanism of providing scratch regs to the spin lock and reset insns, caused the optimizers to want to insert initializations. Fixed by making these patterns

Re: [c++-delayed-folding] fold_simple

2015-09-01 17:31 GMT+02:00 Jason Merrill : > On 09/01/2015 11:27 AM, Kai Tietz wrote: >> >> I rewrote binary/unary overflow-check logic so, that we avoid double >> checking-s. I think this address things as you intend, beside the >> checking for constant value. We would need to

[Bug libstdc++/67408] assumes that __gthread_mutex_t and__gthread_recursive_mutex_t are the same types

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67408 --- Comment #4 from Sebastian Huber --- Sorry, I should have linked my patch: https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00028.html I think the your second version doesn't work in case the types are

Re: Acceptance criteria for the git conversion

David Malcolm : > > What kind of mechanical transformation or hand-editing would add value for > >you? > > Will the resulting git commits have some kind of metadata identifying > the corresponding SVN revision? That's what the --legacy option does. I think Jason plans to

[Bug c/67423] printf.h does not compile with O1 or above

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67423 Jonathan Wakely changed: What|Removed |Added Resolution|FIXED |MOVED --- Comment #4 from Jonathan

[Bug fortran/67419] gfortran.dg/large_real_kind_2.F90 FAILs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67419 Rainer Orth changed: What|Removed |Added Target Milestone|--- |6.0

Re: Fix intelmic-mkoffload.c if the temp path contains a '-'

On Tue, Sep 01, 2015 at 11:35:15 +, Hahnfeld, Jonas wrote: > > during my test of OpenMP 4.0 offloading features I have found a bug in > > intelmic-mkoffload.c when the temp path contains a '-'. > > objcopy will in this case replace it with a '_' which wasn't reflected in > > the original code

<    1   2   3