Re: [PATCH 3/3] Introduce gimple_switch and use it in various places

On 05/02/14 15:56, David Malcolm wrote: gcc/ * gimple.h (gimple_switch): New subclass of gimple_stmt_with_ops, adding the invariant that stmt->code == GIMPLE_SWITCH. (is_a_helper ::test): New. (is_a_helper ::test): New. (gimple_try): Likewise. * co

Re: [PATCH 2/3] Autogenerated part of conversion of "gimple" to "gimple_stmt *"

On 05/02/14 15:56, David Malcolm wrote: This autogenerated patch is 1.2M in size, so I've uploaded it to: http://dmalcolm.fedorapeople.org/gcc/large-patches/e5a7d209a8789e6df9eccb9210d4a6dbe26d0fd4-0002-Autogenerated-part-of-conversion-of-gimple-to-gimple.patch to avoid being anti-social on the

Re: [PATCH 1/3] Handwritten part of conversion of "gimple" to "gimple_stmt *"

On 05/02/14 15:56, David Malcolm wrote: gcc/ * coretypes.h (gimple): Drop typedef. (const_gimple): Likewise. (gimple_seq): Convert from being a "gimple" to a "gimple_stmt *". So instead, we just want to convert from "gimple" to "gimple *", right? That was my understandin

Re: [PATCH, 1/2] shrink wrap a function with a single loop: copy propagation

On 05/08/14 02:06, Zhenqiang Chen wrote: Hi, Similar issue was discussed in thread http://gcc.gnu.org/ml/gcc-patches/2013-04/msg01145.html. The patches are close to Jeff's suggestion: "sink just the moves out of the incoming argument registers". The patch and following one try to shrink wrap a

Re: [RFC][PING^2] Do not consider volatile asms as optimization barriers #1

> It has been two weeks since Richard commited this to trunk. Perhaps it's > ok to backport to 4.8 branch now? Richard, can you do that before the 4.8.3 release? Thanks in advance. -- Eric Botcazou

Re: [PATCH, 2/2] shrink wrap a function with a single loop: split live_edge

On 9 May 2014 14:08, Jeff Law wrote: > On 05/08/14 02:07, Zhenqiang Chen wrote: >> >> Hi, >> >> The patch splits the live_edge for move_insn_for_shrink_wrap to sink >> the copy out of the entry block. >> >> Bootstrap and no make check regression on X86-64 and ARM. >> >> OK for trunk? >> >> Thanks!

Re: [PATCH 0/3] Compile-time gimple checking, without typedefs

On 05/02/14 15:56, David Malcolm wrote: This patch series demonstrates a way of reimplementing the 89-patch series: "[PATCH 00/89] Compile-time gimple-checking" http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01148.html whilst avoiding introducing a pair of "gimple_foo/const_gimple_foo" ty

Re: [PATCH 19/89] Const-correctness of gimple_call_builtin_p

On 04/21/14 10:56, David Malcolm wrote: gcc/ * gimple.h (gimple_builtin_call_types_compatible_p): Accept a const_gimple, rather than a gimple. (gimple_call_builtin_p): Likewise, for the three variants. * gimple.c (gimple_builtin_call_types_compatible_p): Likewise.

Re: [patch] Shorten Windows path

On 04/25/14 04:16, Joey Ye wrote: Ping I've spoke with Kai a bit about this and he thinks it's appropriate and desirable to shorten paths on these kinds of filesystems. Ok for the trunk. Thanks and sorry for the wait, Jeff

Re: [PATCH Ping v2] Extend -fstack-protector-strong to cover calls with return slot

On 05/05/14 05:58, Florian Weimer wrote: On 02/03/2014 10:05 AM, Florian Weimer wrote: On 01/17/2014 11:26 AM, Florian Weimer wrote: On 01/08/2014 03:57 PM, Florian Weimer wrote: What about the attached version? It still does not exactly match your original suggestion because gimple_call_lhs

Re: [PATCH] copyprop_hardreg_forward needs to check HARD_REGNO_CALL_PART_CLOBBERED

On 05/07/14 09:52, Matthew Fortune wrote: The MIPS O32 FPXX ABI exposes a bug in regcprop where call part clobbered information is not checked when calculating clobbered registers. This is only one of many places that regs_invalidated_by_call is used without also checking HARD_REGNO_CALL_PART_CLO

Re: RFC: Faster for_each_rtx-like iterators

On 05/07/14 14:52, Richard Sandiford wrote: I noticed for_each_rtx showing up in profiles and thought I'd have a go at using worklist-based iterators instead. So far I have three: FOR_EACH_SUBRTX: iterates over const_rtx subrtxes of a const_rtx FOR_EACH_SUBRTX_VAR: iterates over rtx subrt

Re: [PATCH, 2/2] shrink wrap a function with a single loop: split live_edge

On 05/08/14 02:07, Zhenqiang Chen wrote: Hi, The patch splits the live_edge for move_insn_for_shrink_wrap to sink the copy out of the entry block. Bootstrap and no make check regression on X86-64 and ARM. OK for trunk? Thanks! -Zhenqiang ChangeLog: 2014-05-08 Zhenqiang Chen * fu

Merge from GCC 4.9 branch to gccgo branch

I merged GCC 4.9 branch revision 210256 to the gccgo branch. Ian

[gomp4] Merge trunk r210100 (2014-05-06) into gomp-4_0-branch

Hi! In r210257, I have committed a merge from trunk r210100 (2014-05-06) into gomp-4_0-branch. The LTO regression that appeared with the last merge, , remains to be resolved: PASS: gcc.dg/lto/save-temps c_

Re: [ping] [PATCH] config-list.mk: `show' target to show all considered targets

On 05/08/14 02:10, Jan-Benedict Glaw wrote: On Mon, 2014-05-05 14:05:40 +0200, Jan-Benedict Glaw wrote: I'd like to install this patch, which would help me to run the build robot (http://toolchain.lug-owl.de/buildbot/): 2014-05-05 Jan-Benedict Glaw contrib/ * config-list.mk (show):

Re: Contributing new gcc targets: i386-*-dragonfly and x86-64-*-dragonfly

On 05/03/14 01:11, John Marino wrote: revised patchset : http://leaf.dragonflybsd.org/~marino/gcc-df-target/patches/patch-dragonfly-target revised changelog : http://leaf.dragonflybsd.org/~marino/gcc-df-target/changelog_entries/gcc_ChangeLog_entry.txt revised commit msg: http://leaf.dragonfly

Re: [PATCH] Windows libibery: Don't quote args unnecessarily

On Tue, May 6, 2014 at 11:56 PM, Ray Donnelly wrote: > We only quote arguments that contain spaces, \t or " > characters to prevent wasting 2 characters per > argument of the CreateProcess() 32,768 limit. This is OK. Thanks. Ian > libiberty/pex-win32.c | 46 ++

libbacktrace patch committed: Fixes for large binaries

While testing on a large Google binary, I noticed that libbacktrace is allocating an inordinate amount of memory. The binary winds up with 377,944 entries in the unit_addrs vector. Each entry is 24 bytes, so this is 9,070,656 bytes, which is not too terrible. Unfortunately, for some reason I tho

[PR tree-optimization/61009] Do not use a block as a joiner if it is too big for threading

This was yet another problem issue with threading through a loop backedge and finding equivalences that should have been invalidated. In this instance, we were trying to thread through a large block. When we hit the statement threshold, thread_through_normal_block returned and thus stateme

Re: [RS6000] Fix PR61098, Poor code setting count register

On Thu, May 08, 2014 at 09:48:35AM -0400, David Edelsohn wrote: > The history is 32 bit HWI. Right. > The ChangeLog does not mention the changes to rs6000.md nor rs6000-protos.h. Oops, added. * config/rs6000/rs6000.md (movsi_internal1_single+1): Update call to rs6000_emit_set_co

Re: [patch] change specific int128 -> generic intN

> Assuming that the formula sizeof(type)*char_bit==precision works for all It doesn't. THe MSP430 has __int20 for example. Would it be acceptable for the compiler to always define a set of macros for each of the intN types? I would have thought that would be discouraged, but it would be an ea

Re: [patch] change specific int128 -> generic intN

On Thu, 8 May 2014, DJ Delorie wrote: The libstdc++v3 headers have __int128 hard-coded all over the place. Any suggestions on parameterizing those for the __intN types that are actually supported by the target? (adding libstdc++@ in Cc:) The first idea that comes to mind (so possibly not such

Re: [patch] change specific int128 -> generic intN

The libstdc++v3 headers have __int128 hard-coded all over the place. Any suggestions on parameterizing those for the __intN types that are actually supported by the target?

UTItype fallout (was: wide-int fallout)

On Fri, 2014-05-09 00:48:39 +0200, Jan-Benedict Glaw wrote: > Just found this for iq2000: > > g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions > -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing > -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverlo

Re: iq2000-elf: wide-int fallout (was: we are starting the wide int merge)

On Fri, 2014-05-09 at 00:48 +0200, Jan-Benedict Glaw wrote: > [...] > > Just found this for iq2000: > > g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions > -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing > -Wwrite-strings -Wcast-qual -Wmissing-format-attribut

iq2000-elf: wide-int fallout (was: we are starting the wide int merge)

[...] Just found this for iq2000: g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno

Re: [PATCH] Fix PR c++/60994 gcc does not recognize hidden/shadowed enumeration as valid nested-name-specifier

Nit: normally, ChangeLog entries are not submitted as diffs, part of the patch proper, but separately (also because the ChangeLog files keep changing quite fast). Paolo.

Re: [patch] fix impliedness of -Wunused-parameter depending on -Wexta option ordering

On Thu, 8 May 2014, Matthias Klose wrote: > This fixes a regression introduced with 4.8, where the option ordering > of -Wextra and -Wunused-parameter emits a warning, which is not emitted > with 4.7. No regressions with the trunk, the 4.9 and 4.8 branches. Ok to > check in for these? OK. --

[patch] fix impliedness of -Wunused-parameter depending on -Wexta option ordering

This fixes a regression introduced with 4.8, where the option ordering of -Wextra and -Wunused-parameter emits a warning, which is not emitted with 4.7. No regressions with the trunk, the 4.9 and 4.8 branches. Ok to check in for these? Matthias 2014-05-08 Manuel Lpez-Ibez Matthi

Re: [C PATCH] Make attributes accept enum values (PR c/50459)

On Fri, 2 May 2014, Marek Polacek wrote: > Yeah, that was a weird thing to do. I yanked that particular test to > a new testcase. Otherwise no changes. > > Tested again x86_64-linux, ok now? > > 2014-05-02 Marek Polacek > > PR c/50459 > c-family/ > * c-common.c (check_user_alig

Re: [wide-int] Add fast path for hosts with HWI widening multiplication

"H.J. Lu" writes: > On Thu, May 8, 2014 at 1:12 PM, Richard Sandiford > wrote: >> "H.J. Lu" writes: >>> On Thu, May 8, 2014 at 12:42 PM, Jakub Jelinek wrote: On Thu, May 08, 2014 at 12:34:28PM -0700, H.J. Lu wrote: > On Thu, May 8, 2014 at 12:18 PM, Richard Sandiford > wrote:

RE: [PATCH GCC]Add 'force-dwarf-lexical-blocks' command line option

On Thu, 8 May 2014, Herman, Andrei wrote: > > > Declarations that would fall into the scope of a newly created label > > > scope are moved into the enclosing "normal" (non label) scope, where > > they actually belong. > > > > Shouldn't you be able to do something like that for the other cases as

Re: [PATCH] Fix PR c++/60994 gcc does not recognize hidden/shadowed enumeration as valid nested-name-specifier

Ping. previous post: http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01938.html Again bootstrapped/regtested/diffed against xg++ (GCC) 4.10.0 20140508 (experimental) [master revision ed50168:49aa3a5:e79f58c7b12f37014efb7425399c93814cddb4c4] On 29.04.2014 12:58, Momchil Velikov wrote: > He

Re: [wide-int] Add fast path for hosts with HWI widening multiplication

On Thu, May 8, 2014 at 1:12 PM, Richard Sandiford wrote: > "H.J. Lu" writes: >> On Thu, May 8, 2014 at 12:42 PM, Jakub Jelinek wrote: >>> On Thu, May 08, 2014 at 12:34:28PM -0700, H.J. Lu wrote: On Thu, May 8, 2014 at 12:18 PM, Richard Sandiford wrote: > Kenneth Zadeck writes: >

[Fortran-caf] Merge of the trunk into the branch

Hi all, I have now merged the trunk into the branch. The main change is the new co_min/max/sum feature but also a patch which has reduced the differences between the trunk and the branch. - And of course, all the other trunk changes such as the wide-int patch. Committed as Rev. 210244. Tobi

Re: [google gcc-4_8] fix lipo ICE

ok. David On Thu, May 8, 2014 at 1:33 PM, Rong Xu wrote: > Hi, > > This patch fixed lipo ICE triggered by an out-of-bound access. > > This is google specific patch and tested with bootstrap and the > program exposed the issue. > > Thanks, > > -Rong

[google gcc-4_8] fix lipo ICE

Hi, This patch fixed lipo ICE triggered by an out-of-bound access. This is google specific patch and tested with bootstrap and the program exposed the issue. Thanks, -Rong 2014-05-08 Rong Xu * tree-inline.c (add_local_variables): Check if the debug_expr is a decl_node before

Re: [wide-int] Add fast path for hosts with HWI widening multiplication

"H.J. Lu" writes: > On Thu, May 8, 2014 at 12:42 PM, Jakub Jelinek wrote: >> On Thu, May 08, 2014 at 12:34:28PM -0700, H.J. Lu wrote: >>> On Thu, May 8, 2014 at 12:18 PM, Richard Sandiford >>> wrote: >>> > Kenneth Zadeck writes: >>> >> everyone who has a private port will hate you forever. no

Re: [patch] libstdc++/61117 FAQ should use "free software"

On 08/05/14 20:52 +0100, Jonathan Wakely wrote: Committed to 4.8, 4.9 and trunk. And 4.7 since that branch is still open too.

[patch] libstdc++/61117 FAQ should use "free software"

Committed to 4.8, 4.9 and trunk.

Re: [wide-int] Add fast path for hosts with HWI widening multiplication

On Thu, May 8, 2014 at 12:42 PM, Jakub Jelinek wrote: > On Thu, May 08, 2014 at 12:34:28PM -0700, H.J. Lu wrote: >> On Thu, May 8, 2014 at 12:18 PM, Richard Sandiford >> wrote: >> > Kenneth Zadeck writes: >> >> everyone who has a private port will hate you forever. note that i >> >> have 2 of

Re: [PATCH, Pointer Bounds Checker 1/x] Pointer bounds type and mode

On Thu, May 8, 2014 at 12:28 PM, Jeff Law wrote: > On 05/08/14 02:17, Ilya Enkovich wrote: >>> >>> >>> Right. Richi explicitly wanted the entire set approved before staging in >>> any of the bits. >> >> >> I thought it would be useful to have approved codes in the trunk to >> reveal some possible

Re: [wide-int] Add fast path for hosts with HWI widening multiplication

On Thu, May 08, 2014 at 12:34:28PM -0700, H.J. Lu wrote: > On Thu, May 8, 2014 at 12:18 PM, Richard Sandiford > wrote: > > Kenneth Zadeck writes: > >> everyone who has a private port will hate you forever. note that i > >> have 2 of them. > > > > Got any other ideas though? I suppose if we're

[patch] fix some comments in libstdc++ files

Update an old URL and an old pathname. Tested x86_64-linux, committed to 4.8, 4.9 and trunk. commit 4692e5802722954c4dda17e8b7f4ed4b78bcc272 Author: Jonathan Wakely Date: Thu May 8 19:38:42 2014 +0100 * include/std/iostream: Fix URL in comment. * src/c++98/ios_init.cc: Fix path in

Re: [wide-int] Add fast path for hosts with HWI widening multiplication

On Thu, May 8, 2014 at 12:18 PM, Richard Sandiford wrote: > Kenneth Zadeck writes: >> everyone who has a private port will hate you forever. note that i >> have 2 of them. > > Got any other ideas though? I suppose if we're prepared to break > compatibility with whatever the upstream of longlon

Re: [PATCH, Pointer Bounds Checker 1/x] Pointer bounds type and mode

On 05/08/14 02:17, Ilya Enkovich wrote: Right. Richi explicitly wanted the entire set approved before staging in any of the bits. I thought it would be useful to have approved codes in the trunk to reveal some possible problems on earlier stages. It also requires significant effort to keep ev

Re: [PATCH] Add support for MIPS r3 and r5

Andrew Bennett writes: > diff --git a/gcc/config/mips/mips-cpus.def b/gcc/config/mips/mips-cpus.def > index 07fbf9c..f2e23c6 100644 > --- a/gcc/config/mips/mips-cpus.def > +++ b/gcc/config/mips/mips-cpus.def > @@ -44,9 +44,13 @@ MIPS_CPU ("mips4", PROCESSOR_R8000, 4, 0) > isn't tuned to a spec

Re: [wide-int] Add fast path for hosts with HWI widening multiplication

Kenneth Zadeck writes: > everyone who has a private port will hate you forever. note that i > have 2 of them. Got any other ideas though? I suppose if we're prepared to break compatibility with whatever the upstream of longlong.h is, we could make more use of intN_t and uintN_t. Having a whi

[PATCH, i386]: Fix PR59952, -march=core-avx2 should not enable RTM

Hello! Apparently, not all Haswell processors have TSX. Attached patch removes PTA_RTM from default Haswell flags. PTA_HLX still makes sense for Haswell processors, since the prefix is ignored on non-TSX processors. 2014-05-08 Uros Bizjak PR target/59952 * config/i386/i386.c (PTA_HASW

[jit] Introduce params_c_finalize

Attempting to repeatedly compile in-process led to assertion failures in a release build on the 2nd compile within a process: 156 void 157 set_default_param_value (compiler_param num, int value) 158 { 159 gcc_assert (!params_finished); 160 161 compiler_params[(int) num].def

Re: [wide-int] Add fast path for hosts with HWI widening multiplication

everyone who has a private port will hate you forever. note that i have 2 of them. On 05/08/2014 02:31 PM, Richard Sandiford wrote: "Joseph S. Myers" writes: On Thu, 8 May 2014, Ramana Radhakrishnan wrote: Ramana Radhakrishnan * wide-int.cc (UTItype): Define. (UDWtype)

Re: [C PATCH] Make attributes accept enum values (PR c/50459)

Ping. On Fri, May 02, 2014 at 11:28:54AM +0200, Marek Polacek wrote: > On Thu, May 01, 2014 at 11:20:25PM +, Joseph S. Myers wrote: > > On Wed, 23 Apr 2014, Marek Polacek wrote: > > > > > diff --git gcc/testsuite/c-c++-common/attributes-1.c > > > gcc/testsuite/c-c++-common/attributes-1.c > >

Re: [wide-int] Add fast path for hosts with HWI widening multiplication

"Joseph S. Myers" writes: > On Thu, 8 May 2014, Ramana Radhakrishnan wrote: > >> Ramana Radhakrishnan >> >>* wide-int.cc (UTItype): Define. >>(UDWtype): Define for appropriate W_TYPE_SIZE. > > This breaks builds for 32-bit hosts, where TImode isn't supported. You > can only

[patch] libstdc++/13860 enforce requirements on traits

Add static assertions to enforce requirements on the traits used with basic_filebuf, improving the diagnostics for invalid traits. Tested x86_64-linux, committed to trunk. commit 78df7e78e805c873883e63d9df4e6befa32ddac5 Author: Jonathan Wakely Date: Thu May 8 18:20:37 2014 +0100 PR libs

Re: [C PATCH] Don't reject valid code with _Alignas (PR c/61053)

On Wed, May 07, 2014 at 11:31:38AM -0700, H.J. Lu wrote: > > OK, though I'm not sure if the "lp64" conditions are right in the testcase > > It should be !ia32 instead of lp64. Ok, I changed lp64 to ! { ia32 } and committed the patch now. Marek

RE: [PATCH GCC]Add 'force-dwarf-lexical-blocks' command line option

> -Original Message- > From: Joseph Myers [mailto:jos...@codesourcery.com] > Sent: Thursday, May 08, 2014 8:27 PM > To: Herman, Andrei > Cc: gcc-patches@gcc.gnu.org > Subject: RE: [PATCH GCC]Add 'force-dwarf-lexical-blocks' command line > option > > On Thu, 8 May 2014, Herman, Andrei wrote

[PATCH, AArch64] Fix macro in vdup_lane_2 test case

This patch fixes a defective macro definition, based on correct definition in similar testcases. The test currently passes through luck rather than correctness. OK for commit? Cheers, Ian 2014-05-08 Ian Bolton gcc/testsuite * gcc.target/aarch64/vdup_lane_2.c (force_simd): Emit an

[PATCH, AArch64] Use MOVN to generate 64-bit negative immediates where sensible

Hi, It currently takes 4 instructions to generate certain immediates on AArch64 (unless we put them in the constant pool). For example ... long long beefcafebabe () { return 0xBEEFCAFEBABEll; } leads to ... mov x0, 0x47806 mov x0, 0xcafe, lsl 16 mov x0, 0xbeef, lsl 32

Re: [C PATCH] Warn for _Alignas + main (PR c/61077)

On Thu, 8 May 2014, Marek Polacek wrote: > Joseph pointed out that we don't warn when the return type of > main or the parameter type of main have the _Atomic qualifier. > This patch adds such warning. > > Regtested/bootstrapped on x86_64-linux, ok for trunk? OK. -- Joseph S. Myers jos...@code

RE: [PATCH GCC]Add 'force-dwarf-lexical-blocks' command line option

On Thu, 8 May 2014, Herman, Andrei wrote: > The changes in gcc/c/c-decl.c are meant to deal with this problem. > Declarations > that would fall into the scope of a newly created label scope are moved into > the > enclosing "normal" (non label) scope, where they actually belong. Shouldn't you

Re: [PATCH] Add support for MIPS r3 and r5

On Thu, 8 May 2014, Andrew Bennett wrote: > Hi, > > This patch adds support for MIPS r3 and r5 to GCC. I have updated the msgid > strings in the .po files for the error message I changed. Can I assume the > actual msgstr entries will be updated later on? Never modify .po files in GCC; they sh

[patch] libstdc++/57394 - copy operations for basic_streambuf

This patch isn't very useful on its own, but fixes the PR and should be useful when adding move operations to the derived streambufs. The mem-initializer for basic_streambuf::_M_out_end was initialized from __sb._M_out_cur, which I assume was not intentional. Those initializers were only added to

Re: [PATCH, ARM] Fix PR60609 (Error: value of 256 too large for field of 1 bytes)

On 25 April 2014 16:31, Ramana Radhakrishnan wrote: > On Fri, Apr 25, 2014 at 4:29 PM, Charles Baylis > wrote: >> OK to backport to 4.8 and 4.7? > > Ok by me but give 24 "working" hours for an RM to object. Committed to 4.7 as r210227. Committed to 4.8 as r210226. 2014-05-08 Charles Baylis

[PING] [PATCH, wwwdocs, AArch64] Document issues with singleton vector types

Ping~ Originally posted here: http://gcc.gnu.org/ml/gcc-patches/2014-05/msg00019.html Thanks, Yufeng On 05/01/14 17:57, Yufeng Zhang wrote: Hi, This patch documents issues with singleton vector types in the 4.9 AArch64 backend. "On AArch64, the singleton vector types int64x1_t, uint64x1_t a

Re: [wide-int] Add fast path for hosts with HWI widening multiplication

On Thu, 8 May 2014, Ramana Radhakrishnan wrote: > Ramana Radhakrishnan > >* wide-int.cc (UTItype): Define. >(UDWtype): Define for appropriate W_TYPE_SIZE. This breaks builds for 32-bit hosts, where TImode isn't supported. You can only use TImode on the host if it's 64-bit.

Re: RFA: Fix calculation of size of builtin setjmp buffer

On May 8, 2014, at 7:24 AM, Nicholas Clifton wrote: > > What do you think of this version ? Now we just need a __builtin_setjmp style of maintainer to review…

Re: [C PATCH] Warn for _Alignas + main (PR c/61077)

Sorry, the subject should say _Atomic instead of _Alignas. Marek

[C PATCH] Warn for _Alignas + main (PR c/61077)

Joseph pointed out that we don't warn when the return type of main or the parameter type of main have the _Atomic qualifier. This patch adds such warning. Regtested/bootstrapped on x86_64-linux, ok for trunk? 2014-05-08 Marek Polacek PR c/61077 c-family/ * c-common.c (check_ma

Re: [PATCH, PR58066] preferred_stack_boundary update for tls expanded call

On Thu, May 8, 2014 at 12:59 AM, Wei Mi wrote: > The calls added in the templates of tls_local_dynamic_base_32 and > tls_global_dynamic_32 in pr58066-3.patch are used to prevent sched2 > from moving sp setting across implicit tls calls, but those calls make > the combine of UNSPEC_TLS_LD_BASE and

Re: [Patch, PR 60158] Generate .fixup sections for .data.rel.ro.local entries.

Rohit, The subject line and thread may confuse people that this is a PowerPC-specific issue. You need approval from a reviewer with authority over varasm.c. Thanks, David On Thu, May 8, 2014 at 9:54 AM, rohitarul...@freescale.com wrote: >> -Original Message- >> From: Alan Modra [mailto:

Re: Fix some tests for TARGET_SSE_PACKED_SINGLE_INSN_OPTIMAL

On Thu, May 8, 2014 at 3:10 AM, Joseph S. Myers wrote: > Having fixed TARGET_SSE_PACKED_SINGLE_INSN_OPTIMAL to apply only to > 128-bit vectors, some --with-arch=bdver3 --with-cpu=bdver3 > scan-assembler failures relating to that tuning remain, because of > different choices of instructions for 128

Fwd: [PATCH, alpha]: Fix PR61092, wide-int merge broke alpha bootstrap

Hello! Wide-int merge triggered following ICE: In file included from ../../gcc-svn/trunk/gcc/wide-int.cc:37:0: ../../gcc-svn/trunk/gcc/wide-int.cc: In function ‘unsigned int wi::mul_internal(long int*, const long int*, unsigned int, const long int*, unsigned int, unsigned int, signop, bool*, bool

RE: [PATCH GCC]Add 'force-dwarf-lexical-blocks' command line option

> -Original Message- > From: Joseph Myers [mailto:jos...@codesourcery.com] > Sent: Wednesday, May 07, 2014 9:01 PM > To: Herman, Andrei > Cc: gcc-patches@gcc.gnu.org; herman_and...@mentor.com > Subject: Re: [PATCH GCC]Add 'force-dwarf-lexical-blocks' command line > option > > On Wed, 7 May

Re: emit __float128 typeinfo

Ping http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01651.html On Fri, 25 Apr 2014, Marc Glisse wrote: On Fri, 25 Apr 2014, Marc Glisse wrote: the previous patch had to be reverted as it broke the strange handling of vectors in the ARM target. This new patch should be much more conservative I

Re: RFA: Fix calculation of size of builtin setjmp buffer

Hi Mike, How about GET_MODE_SIZE (STACK_SAVEAREA_MODE (SAVE_NONLOCAL)) / GET_MODE_SIZE (Pmode) + 2 + /* slop for mips, see builtin_setjmp_setup */ 1 - 1. This retains the slop for mips, and fixes ports like ia64 and s390 (see STACK_SAVEAREA_MODE on those ports, it is larger one might expect)

RE: [Patch, PR 60158] Generate .fixup sections for .data.rel.ro.local entries.

> -Original Message- > From: Alan Modra [mailto:amo...@gmail.com] > Sent: Saturday, April 26, 2014 11:52 AM > To: Dharmakan Rohit-B30502 > Cc: gcc-patches@gcc.gnu.org; dje@gmail.com; Wienskoski Edmar-RA8797 > Subject: Re: [Patch, PR 60158] Generate .fixup sections for > .data.rel.ro.loc

Re: [C++ Patch] PR 13981 (resend)

OK. Jason

Re: [RS6000] Fix PR61098, Poor code setting count register

On Wed, May 7, 2014 at 9:48 PM, Alan Modra wrote: > On powerpc64, to set a large loop count we have code like the > following after split1: > > (insn 67 14 68 4 (set (reg:DI 160) > (const_int 99942400 [0x5f5])) /home/amodra/unaligned_load.c:14 -1 > (nil)) > (insn 68 67 42 4 (set (

Re: Contributing new gcc targets: i386-*-dragonfly and x86-64-*-dragonfly

On 5/8/2014 15:32, Jeff Law wrote: > On 05/08/14 07:14, Jonathan Wakely wrote: >> >> Anyone willing to give it an overall approval? > I'll take a look at the rest. I mostly wanted someone else to deal with > stddef.h :-) Thanks Jeff! I'm am very appreciative of that. John

Re: Contributing new gcc targets: i386-*-dragonfly and x86-64-*-dragonfly

On 05/08/14 07:14, Jonathan Wakely wrote: Ian's approved the libiberty.h change, Joseph's approved the stddef.h change, I've approved the libstdc++ parts. IIUC it still needs explicit approval for the rest, e.g. trivial adjustments to configuration stuff in libitm and libcilkrts. Are there spec

Re: [RFA/dwarf v2] Add DW_AT_GNAT_use_descriptive_type flag for Ada units.

Ping? I understand there was a freeze period for a while, but the patch has been out for a little over 3 months, now, and is fairly trivial. Can someone review it for me? Suggest also including it in 4.9. Thank you! > On Tue, Feb 19, 2013 at 10:50:46PM -0500, Jason Merrill wrote: > > On 02/19/20

Re: Contributing new gcc targets: i386-*-dragonfly and x86-64-*-dragonfly

On 3 May 2014 08:11, John Marino wrote: > On 5/2/2014 22:15, Joseph S. Myers wrote: >> On Fri, 2 May 2014, John Marino wrote: >> >>> 1) I don't know which type definitions are missing (iow, the important >>> ones from sys/type.h that are required to build gcc) >> >> The default presumption should b

Re: [wide-int] Add fast path for hosts with HWI widening multiplication

Ramana Radhakrishnan writes: > diff --git a/gcc/ChangeLog b/gcc/ChangeLog > index 354cdb9..8ef9a0f 100644 > --- a/gcc/ChangeLog > +++ b/gcc/ChangeLog > @@ -1,3 +1,8 @@ > +2014-05-08 Ramana Radhakrishnan > + > + * wide-int.cc (UTItype): Define. > + (UDWtype): Define for appropriate W_TYP

[patch,avr] Fix PR61055: Wrong branch instruction after INC, DEC.

Some instructions like INC, DEC, NEG currently set cc0 to set_zn which is not the whole story because they also set the V flag. This leads to a wrong branch instruction in the remainder as cc0 is used. Fix is to do same as clobber cc0. For the matter of clarity, I added a new cc0 alternative

Re: [Fortran, Patch] Some prep patches for coarray communication

Dear Tobias, This one is fine for trunk. Thanks for the patch. Paul

Re: [wide-int] Add fast path for hosts with HWI widening multiplication

On Wed, Dec 4, 2013 at 12:56 PM, Richard Sandiford wrote: > Richard Sandiford writes: >> This patch handles multiplications using a single HWIxHWI->2HWI >> multiplication >> on hosts that have one. This removes all uses of the slow (half-HWI) path >> for insn-recog.ii. The slow path is still u

[libgcc, build] Don't build libgcc-unwind.map with --disable-shared (PR libgcc/61097)

As reported in the PR, libgcc fails to build on Solaris with --disable-shared: the creation of libgcc-unwind.map depends on libgcc-std.ver which isn't built in this case. Fixed as follows, tested by verifying that a --disable-shared i386-pc-solaris2.10 build gets into stage2 without trying to buil

Re: [Patch, Fortran] Add support for TS18508's CO_SUM/MAX/MIN (part 1/2)

Dear Tobias, OK for trunk with one slight quibble: I would rather see + /* Generate the function call. */ + if (code->resolved_isym->id == GFC_ISYM_CO_MAX) +fndecl = gfor_fndecl_co_max; + else if (code->resolved_isym->id == GFC_ISYM_CO_MIN) +fndecl = gfor_fndecl_co_min; + else if (c

[PATCH][1/n][RFC] Make FRE/PRE somewhat predicate aware

Ok, not really predicate aware, but this makes value-numbering pessimistically handle non-executable edges. In the following patch groundwork is laid and PHI value-numbering is adjusted to take advantage of edges known to be not executable. SCCVN is not well-suited to be control aware, but we st

Re: [C++ Patch] PR 13981 (resend)

... Manuel suggested to also use DECL_SOURCE_LOCATION, while we are at it. Thus I'm retesting the below. Thanks, Paolo. // Index: cp/typeck.c === --- cp/typeck.c (revision 210205) +++ cp/typeck.c (working copy) @@ -

Re: RFC: Faster for_each_rtx-like iterators

On Thu, May 08, 2014 at 07:25:50AM +0100, Richard Sandiford wrote: > Trevor Saunders writes: > > On Wed, May 07, 2014 at 09:52:49PM +0100, Richard Sandiford wrote: > >> I noticed for_each_rtx showing up in profiles and thought I'd have a go > >> at using worklist-based iterators instead. So far I

[C++ Patch] PR 13981 (resend)

Hi, some time ago I worked a bit on this very old diagnostic enhancement issue: http://gcc.gnu.org/ml/gcc-patches/2013-08/msg01588.html and yesterday we got a duplicate. Adding an inform to convert_for_assignment still makes sense to me, thus I resurrected the patch, tightened a bit the c

[PATCH] Improve and simplify VN expression combining

The following gets rid of SCCVNs valueize_expr which was used on GENERIC expressions built via vn_get_expr_for which is used for stmt combining via fold (yeah, I know ...). The odd way was that it first folded and built the expression and then valueized it (and not folding again), resulting in un

[PATCH] Fix oversight in call gimplification

When gimplifying a call we now remember the original function type used and record it in gimple_call_fntype. But we fail to use exactly that type for looking at TYPE_ARG_TYPES. The following fixes that. Bootstrapped and tested on x86_64-unknown-linux-gnu, applied. Richard. 2014-05-08 Richard

[PATCH] Remove old pointer conversion special-case

This removes special-casing of pointer conversion handling in gimple_fold_stmt_to_constant_1 - this was from times where most pointer conversions were not useless (only conversions to function/method pointers from other kinds are considered not useless - which I'll change with a followup). Bootst

Re: [gomp4] Add tables generation

On 05/06/2014 05:32 PM, Ilya Verbin wrote: On 05 Apr 17:22, Bernd Schmidt wrote: Things seemed to work over here, but now I'm not certain whether the __start_/__stop_ functionality is GNU ld specific? Maybe we should just go back to the previous version of this patch which didn't try to use this

[gomp4] Mark __OPENMP_TARGET__ as addressable (was: Offloading patches (2/3): Add tables generation)

Hi! On Tue, 17 Dec 2013 15:39:57 +0400, "Michael V. Zolotukhin" wrote: > in this patch we > start to pass '__OPENMP_TARGET__' symbol to GOMP_target calls. > --- a/gcc/omp-low.c > +++ b/gcc/omp-low.c > @@ -8371,19 +8372,22 @@ expand_omp_target (struct omp_region *region) > } > >gimple

Re: [PATCH GCC]Pick up more address lowering cases for ivopt and tree-affine.c

On Tue, May 6, 2014 at 6:44 PM, Richard Biener wrote: > On Tue, May 6, 2014 at 10:39 AM, Bin.Cheng wrote: >> On Fri, Dec 6, 2013 at 6:19 PM, Richard Biener >> wrote: >> Hi, >> I split the patch into two and updated the test case. >> The patches pass bootstrap/tests on x86/x86_64, also pass test

Re: [PATCH, 2/2] shrink wrap a function with a single loop: split live_edge

On Thu, May 8, 2014 at 10:07 AM, Zhenqiang Chen wrote: > The patch splits the live_edge for move_insn_for_shrink_wrap to sink > the copy out of the entry block. Maybe also time to take the shrink-wrapping code out of function.c and put it in its own file? Ciao! Steven

  1   2   >