Re: [PATCH RFA] build: drop target libs from LD_LIBRARY_PATH [PR105688]

On 2/8/24 18:16, Jason Merrill wrote: Hmm.  In stage 1, when we build with the system gcc, I'd think we want the just-built gnat1 to find the system libgcc. In stage 2, when we build with the stage 1 gcc, we want the just-built gnat1 to find the stage 1 libgcc. In neither case do we

Re: CSE deletes valid REG_EQUAL?

On 17/11/20 02:12, Jeff Law wrote: Removing all REG_EQUAL notes for regs that become dead anywhere That's not what it does. seems to just be a thinko? All pseudos are dead somewhere! (Yeah okay, infinite loops, but other than that.) Yea, but the code which wipes the notes probably has no

Re: Fallout: PR84340

On 13/02/2018 14:35, Jakub Jelinek wrote: > On Tue, Feb 13, 2018 at 12:21:55PM +0100, Jakub Jelinek wrote: >> On Tue, Feb 13, 2018 at 12:15:36PM +0100, Paolo Bonzini wrote: >>> The issue is that the ASAN_CHECK doesn't exist at early DSE time, and >>> thus ca

Re: [PATCH] Improve dead code elimination with -fsanitize=address (PR84307)

On 13/02/2018 14:00, Jakub Jelinek wrote: >> Certainly, for now I'll revert. > Reversion is not the right thing, the "fn spec" attributes were clearly > incorrect. So, we should change them to something more conservative that > will work. That would only be "all dots", that is no fnspec at all.

Re: [PATCH] Improve dead code elimination with -fsanitize=address (PR84307)

On 13/02/2018 00:49, Jakub Jelinek wrote: > On Tue, Feb 13, 2018 at 12:41:28AM +0100, Paolo Bonzini wrote: >> On 09/02/2018 19:07, Jakub Jelinek wrote: >>> On Fri, Feb 09, 2018 at 07:01:08PM +0100, Richard Biener wrote: >>>>> which indeed fixes the testcas

Re: Fallout: PR84340

On 13/02/2018 10:32, Martin Liška wrote: > Hello. > > It caused PR84340, I'm suggesting following fix: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84340#c3 I don't think EAF_DIRECT is the issue. You could think of ASAN_MARK as writing a global variable, which it can do because it's not

Re: [PATCH] Improve dead code elimination with -fsanitize=address (PR84307)

On 09/02/2018 19:07, Jakub Jelinek wrote: > On Fri, Feb 09, 2018 at 07:01:08PM +0100, Richard Biener wrote: >>> which indeed fixes the testcase and seems not to break asan.exp. >> >> Huh. Need to double check why that makes sense ;) > > I think it does, for both ASAN_CHECK and ASAN_MARK the

Re: [PATCH] Improve dead code elimination with -fsanitize=address (PR84307)

On 12/02/2018 09:56, Richard Biener wrote: >>> I think it does, for both ASAN_CHECK and ASAN_MARK the pointer argument >>> is the second one, the first one is an integer argument with flags. >>> And ASAN_MARK, both poison and unpoison, works kind like a clobber on >>> the >>> referenced variable,

Re: [PATCH] Improve dead code elimination with -fsanitize=address (PR84307)

On 09/02/2018 17:40, Richard Biener wrote: > On February 9, 2018 5:08:24 PM GMT+01:00, Paolo Bonzini <bonz...@gnu.org> > wrote: >> Another possibility which I considered but did not implement is to mark >> the UNPOISON calls so that they do not cause the paramete

[PATCH] Improve dead code elimination with -fsanitize=address (PR84307)

which I considered but did not implement is to mark the UNPOISON calls so that they do not cause the parameter to escape. Any suggestions on how to proceed here (or approval is welcome too :))? Paolo 2018-02-09 Paolo Bonzini <bonz...@gnu.org> * passes.def: add pass_sandce before

Re: [PATCH] Fix r242743 change of gcc/system.h

On 19/03/2017 22:17, Gunther Nikl wrote: > Hello Paolo! > > Building older GCC releases with clang tends to issue warnings. This > can be annoying especially when they originate from a header. While > backporting r242743 I noticed that the non-C++ cases of the changed > macro definitions in

Re: [PATCH] Fix A < 0 ? C : 0 optimization (PR tree-optimization/78720)

On 09/12/2016 20:26, Jakub Jelinek wrote: > +tree ctype = TREE_TYPE (@1); > + } > + (if (shift >= 0) > +(bit_and > + (convert (rshift @0 { build_int_cst (integer_type_node, shift); })) > + @1) > +(bit_and > + (lshift (convert:ctype @0) { build_int_cst

Re: [PATCH] ira: Don't substitute into TRAP_IF insns (PR78610)

On 30/11/2016 13:46, Segher Boessenkool wrote: >if (JUMP_P (use_insn)) > continue; > > + /* Also don't substitute into a conditional trap insn -- it can become > + an unconditional trap, and that is a flow control insn. */ > + if (GET_CODE (PATTERN (use_insn)) ==

[PATCH v2] improve folding of expressions that move a single bit around

mitted already. Bootstrapped/regtested x86_64-pc-linux-gnu, ok? Paolo 2016-11-26 Paolo Bonzini <bonz...@gnu.org> * match.pd: Simplify X ? C : 0 where C is a power of 2 and X tests a single bit. 2016-11-26 Paolo Bonzini <bonz...@gnu.org> * gcc.dg/fold

Re: [PATCH] improve folding of expressions that move a single bit around

On 29/11/2016 11:16, Richard Biener wrote: >>> >> (bit_and >>> >> (if (shift > 0) >>> >>(lshift (convert @0) { build_int_cst (integer_type_node, shift); }) >>> >>(convert (rshift @0 { build_int_cst (integer_type_node, -shift); }))) >>> >> @3) >>> >> >>> >> What do you think? >> > >>

Re: [PATCH] improve folding of expressions that move a single bit around

On 27/11/2016 00:28, Marc Glisse wrote: > On Sat, 26 Nov 2016, Paolo Bonzini wrote: > >> --- match.pd(revision 242742) >> +++ match.pd(working copy) >> @@ -2554,6 +2554,19 @@ >> (cmp (bit_and@2 @0 integer_pow2p@1) @1) >> (icm

[PATCH] improve folding of expressions that move a single bit around

ll$7, %eax Bootstrapped/regtested x86_64-pc-linux-gnu, ok? Paolo 2016-11-26 Paolo Bonzini <bonz...@gnu.org> * combine.c (simplify_if_then_else): Simplify IF_THEN_ELSE that isolates a single bit, even if the condition involves subregs. * match.pd: Simplif

Re: [PATCH] combine: Convert subreg-of-lshiftrt to zero_extract properly (PR78390)

On 24/11/2016 15:01, Michael Matz wrote: >> > (set (reg:DI 69) >> > (zero_extract:DI (reg:DI 65 [ v_x ]) <- >> > (const_int 32 [0x20]) >> > (const_int 20 [0x14]))) > Hmm, this transformation (from v_x>>12 to zext(v_x,32,20) is only valid > when the top 20 bits of

Re: [patch] Fix PR rtl-optimization/78437

On 23/11/2016 11:26, Eric Botcazou wrote: >> Does it really do that with a (set (reg1:QI)), as opposed to a >> (set (strict_low_part (subreg:QI (reg1:DI)))? > > That's the question (note that REE runs after register allocation). IIRC, strict_low_part is required even after register allocation,

Re: [patch] Fix PR rtl-optimization/78437

On 23/11/2016 10:35, Eric Botcazou wrote: > I now wonder > whether this also matters for !WORD_REGISTER_OPERATIONS targets, e.g. x86: > > (set (reg1:DI) ... > ... >(set (reg1:QI) (expression:QI)) >... >(set (reg2:DI) (any_extend:DI (reg1:QI))) >

Re: [PATCH v3] cpp/c: Add -Wexpansion-to-defined

> It's not obvious to me whether this belongs in -Wextra. After all, this > is a perfectly reasonable and useful GNU C feature, or at least some cases > of it are (like "#define FOO (BAR || defined something)"). Is the > argument that there are too many details of it that differ between >

Re: [PATCH v3] cpp/c: Add -Wexpansion-to-defined

On 10/08/2016 15:53, Paolo Bonzini wrote: > From: Paolo Bonzini <bonz...@gnu.org> > > clang recently added a new warning -Wexpansion-to-defined, which > warns when `defined' is used outside a #if expression (including the > case of a macro that is then used in a #if expr

Re: [PATCH v2] cpp/c: Add -Wexpansion-to-defined

On 10/08/2016 17:58, Joseph Myers wrote: > On Wed, 10 Aug 2016, Paolo Bonzini wrote: > >> There are indeed many pedwarn(loc, 0, ...) occurrences in C++ (most, but >> not all, are "foo only available with -std=bar" which in the C front-end >> would use OPT_

Re: [PATCH v2] cpp/c: Add -Wexpansion-to-defined

On 10/08/2016 17:33, Joseph Myers wrote: > On Wed, 10 Aug 2016, Paolo Bonzini wrote: > >> - stuff that is not enabled by anything should use OPT_Wpedantic, and > > No, lots of pedwarns are for usages that are (a) dubious enough we want to > diagnose them by defa

Re: [PATCH v2] cpp/c: Add -Wexpansion-to-defined

On 10/08/2016 17:24, Manuel López-Ibáñez wrote: > Perhaps we need something like -Wextra-pedantic, for things that are > undefined by ISO C but defined by GNU. Thus, they would not trigger > pedwarns and no error with -pedantic-errors. I think this is overengineering it a bit. If they are

Re: [PATCH v2] cpp/c: Add -Wexpansion-to-defined

On 10/08/2016 16:42, Manuel López-Ibáñez wrote: > > > My only fear is that people not using -Wpedantic nor -pedantic-errors > > > expect that GNU extensions work. This is a GNU extension that defines > > > something that is undefined according to ISO. Enabling the warning > > > with -Wextra is

[PATCH v3] cpp/c: Add -Wexpansion-to-defined

From: Paolo Bonzini <bonz...@gnu.org> clang recently added a new warning -Wexpansion-to-defined, which warns when `defined' is used outside a #if expression (including the case of a macro that is then used in a #if expression). While I disagree with their inclusion of the warning to -W

Re: [PATCH v2] cpp/c: Add -Wexpansion-to-defined

On 10/08/2016 13:31, Manuel López-Ibáñez wrote: > My only fear is that people not using -Wpedantic nor -pedantic-errors > expect that GNU extensions work. This is a GNU extension that defines > something that is undefined according to ISO. Enabling the warning > with -Wextra is just annoying

[PATCH v2] cpp/c: Add -Wexpansion-to-defined

-to-defined, and enables it automatically for -Wextra instead of -pedantic. Bootstrapped and regression tested x86_64-pc-linux-gnu, ok? Paolo libcpp: 2016-08-09 Paolo Bonzini <bonz...@gnu.org> * include/cpplib.h (struct cpp_options): Add new member warn_expansion_to_d

Re: [PATCH] cpp/c: Add -Wexpansion-to-defined

On 10/08/2016 02:48, Manuel López-Ibáñez wrote: > TL;DR If the warning is enabled by -Wpedantic, it should be an error > with -Werror=pedantic and it should use cpp_pedwarning. Whether it > should be enabled by -Wpedantic is more difficult to say. > > -pedantic is equivalent to -Wpedantic. If

Re: [PATCH] cpp/c: Add -Wexpansion-to-defined

On 09/08/2016 20:44, Eric Gallager wrote: > Hi, I'm just a lurker, but... > > On 8/9/16, Paolo Bonzini <bonz...@gnu.org> wrote: >> Index: gcc/c-family/c.opt >> === >> --- gcc/c-family/c.opt

Re: [PATCH] cpp/c: Add -Wexpansion-to-defined

On 09/08/2016 20:30, Manuel López-Ibáñez wrote: >> >> >> + cpp_opts->warn_expansion_to_defined = cpp_warn_expansion_to_defined; >> + if (cpp_warn_expansion_to_defined == -1) >> +cpp_warn_expansion_to_defined = pedantic || extra_warnings; >> + > > Instead of the above, plase use

[PATCH] cpp/c: Add -Wexpansion-to-defined

-pedantic (as before) and -Wextra. Bootstrapped and regression tested x86_64-pc-linux-gnu, ok? Paolo libcpp: 2016-08-09 Paolo Bonzini <bonz...@gnu.org> * include/cpplib.h (struct cpp_options): Add new member warn_expansion_to_defined. (CPP_W_EXPANSION_TO_DEFINED

Re: [PATCH] Do not sanitize left shifts for -fwrapv (PR68418)

On 04/12/2015 23:48, Jeff Law wrote: >> >> Why would pointer types be shifted at all (at the ubsan level, >> which is basically the AST)? > BTW, if you argument is that we can never get into this code with a > shift of a pointer object, I'd like to see some kind of analysis to back > up that

[PATCH v2] Do not sanitize left shifts for -fwrapv (PR68418)

Left shifts into the sign bit is a kind of overflow, and the standard chooses to treat left shifts of negative values the same way. However, the -fwrapv option modifies the language to one where integers are defined as two's complement---which also defines entirely the behavior of shifts.

Re: [PATCH] Do not sanitize left shifts for -fwrapv (PR68418)

On 25/11/2015 14:55, Paolo Bonzini wrote: > Left shifts into the sign bit is a kind of overflow, and the > standard chooses to treat left shifts of negative values the > same way. > > However, the -fwrapv option modifies the language to one where > integers are defined a

Re: [PATCH] Do not sanitize left shifts for -fwrapv (PR68418)

> >> gcc: > >>PR sanitizer/68418 > >>* c-family/c-ubsan.c (ubsan_instrument_shift): Disable > >>sanitization of left shifts for wrapping signed types as well. > >> > >> gcc/testsuite: > >>PR sanitizer/68418 > >>* gcc.dg/ubsan/c99-wrapv-shift-1.c, > >>

[PATCH] -Wshift-overflow: Warn for shifting sign bit out of a negative number

maybe_warn_shift_overflow is checking for patterns such as (1 << 31) and not warning for them. However, if the shifted value is negative, a shift by a non-zero amount will always shift *out* of the sign bit rather than into it. Thus it should be warned about, even if the value only requires one

Re: GCC 5.3 Status Report (2015-11-20)

On 24/11/2015 16:57, David Edelsohn wrote: > > > We plan to do a GCC 5.3 release candidate at the end of next week > > > followed by the actual release a week after that. > > > > > > So now is the time to look at your regression bugs in bugzilla and > > > do some backporting for things already

Re: GCC 5.3 Status Report (2015-11-20)

On 24/11/2015 16:57, David Edelsohn wrote: > > > We plan to do a GCC 5.3 release candidate at the end of next week > > > followed by the actual release a week after that. > > > > > > So now is the time to look at your regression bugs in bugzilla and > > > do some backporting for things already

[PATCH v2] Clarify promises about undefined behavior with signed <

GCC's -fwrapv option does not affect code generation for shifts because currently GCC does not rely on the fact that certain signed shifts trigger undefined behavior. However, the definition of signed arithmetic overflow does extend to shifts; it is only code generation that is limited to

[PATCH] Do not sanitize left shifts for -fwrapv (PR68418)

Left shifts into the sign bit is a kind of overflow, and the standard chooses to treat left shifts of negative values the same way. However, the -fwrapv option modifies the language to one where integers are defined as two's complement---which also defines entirely the behavior of shifts.

Re: [PATCH] PR 68192 Export AIX TLS symbols

Eric, can you help committing this patch to libtool? http://article.gmane.org/gmane.comp.gcc.patches/356566 Thanks, Paolo On 03/11/2015 15:23, David Edelsohn wrote: > TLS symbols in AIX display a new, different symbol type in nm output. > Libtool explicitly creates a list of exported symbols

Re: GCC 5.3 Status Report (2015-11-20)

On 20/11/2015 14:14, David Edelsohn wrote: > On Fri, Nov 20, 2015 at 7:53 AM, Richard Biener wrote: >> >> Status >> == >> >> We plan to do a GCC 5.3 release candidate at the end of next week >> followed by the actual release a week after that. >> >> So now is the time to

Re: GCC 5.3 Status Report (2015-11-20)

On 20/11/2015 14:14, David Edelsohn wrote: > On Fri, Nov 20, 2015 at 7:53 AM, Richard Biener wrote: >> >> Status >> == >> >> We plan to do a GCC 5.3 release candidate at the end of next week >> followed by the actual release a week after that. >> >> So now is the time to

[RFC PATCH] Do not sanitize left shifts for -fwrapv

Left shifts into the sign bit is a kind of overflow, and the standard chooses to treat left shifts of negative values the same way. However, the -fwrapv option modifies the language to one where integers are defined as two's complement---which also defines entirely the behavior of shifts.

Re: [PATCH] Clarify that -fwrapv covers all signed arithmetic overflow

On 17/11/2015 13:58, Joseph Myers wrote: >> > GCC's -fwrapv option does not affect code generation for shifts >> > because currently GCC does not rely on the fact that certain >> > signed shifts trigger undefined behavior. However, the definition >> > of signed arithmetic overflow does extend

[PATCH] Clarify that -fwrapv covers all signed arithmetic overflow

GCC's -fwrapv option does not affect code generation for shifts because currently GCC does not rely on the fact that certain signed shifts trigger undefined behavior. However, the definition of signed arithmetic overflow does extend to shifts; it is only code generation that is limited to

Re: [PATCH] Clarify that -fwrapv covers all signed arithmetic overflow

On 17/11/2015 16:27, Joseph Myers wrote: > > Can you suggest a wording for "if the GNU C language definition changes > > [which, no matter how unlikely, is explicitly not ruled out by the > > manual] -fwrapv will be extended to signed shifts, and shifts of > > negative numbers would return A*2^B

Re: [PATCH] Clarify that -fwrapv covers all signed arithmetic overflow

On 17/11/2015 17:02, Joseph Myers wrote: > On Tue, 17 Nov 2015, Paolo Bonzini wrote: > >> * it doesn't promise that GCC will never rely on undefined behavior >> rules for signed left shifts > > I think we should remove the ", but this is subject to change&q

Re: [PATCH] Clarify that -fwrapv covers all signed arithmetic overflow

On 17/11/2015 17:02, Joseph Myers wrote: > On Tue, 17 Nov 2015, Paolo Bonzini wrote: > >> * it doesn't promise that GCC will never rely on undefined behavior >> rules for signed left shifts > > I think we should remove the ", but this is subject to change&q

Re: [PATCH] PR 68192 Export AIX TLS symbols

On 05/11/2015 17:28, David Edelsohn wrote: > [Explicitly copying build maintainers.] > > Paolo and Alexandre, > > Could you review and help with this patch? > > TLS symbols in AIX display a new, different symbol type in nm output. > Libtool explicitly creates a list of exported symbols for

Re: [PATCH] PR 68192 Export AIX TLS symbols

On 05/11/2015 17:38, David Edelsohn wrote: > On Thu, Nov 5, 2015 at 8:34 AM, Paolo Bonzini <bonz...@gnu.org> wrote: >> >> >> On 05/11/2015 17:28, David Edelsohn wrote: >>> [Explicitly copying build maintainers.] >>> >>> Paolo and Alexan

Re: [PATCH 5/9] i386: Add address spaces for fs/gs segments

On 08/10/2015 06:59, Richard Henderson wrote: > +/* Address space support. > + > + This is not "far pointers" in the 16-bit sense, but an easy way > + to use %fs and %gs segment prefixes. Therefore: > + > +(a) All address spaces have the same modes, > +(b) All address spaces have

[PATCH] Remove pointless -fPIC warning on Windows platforms

There are plenty of targets that do not require -fPIC because they always generate position independent code, but none of them feels the need to complain with the user about an unnecessary but perfectly valid option, on each and every .c-.o rule, and without a way to disable it. Adding insult to

Re: [PATCH] PR/66760, ipa-inline-analysis.c compile-time hog

On 15/07/2015 18:01, Martin Jambor wrote: So unless Martin objects consider the patch approved for trunk and for backporting after 5.2 is released and trunk shows no issues. Martin - can you take care of committing if you are fine with it? I have commitred the patch to trunk (and

Re: [PATCH] PR/66760, ipa-inline-analysis.c compile-time hog

On 13/07/2015 13:55, Martin Jambor wrote: I can't approve it, but FWIW, I'm generally fine with the patch. Although the original idea was to share one func_body_info in between ipa-cp and ipa-inline analyses, this is certainly better than what we have now and perhaps even good enough

Re: [PATCH] PR/66760, ipa-inline-analysis.c compile-time hog

On 13/07/2015 14:34, Martin Jambor wrote: You might want to use Martin's shiny new function_summary class in symbol-summary.c. That is a mechanism specifically designed to append to a cgraph_node information specific to an optimization pass (or two, as ipa-cp and ipa-inline already both

Re: [PATCH] PR/66760, ipa-inline-analysis.c compile-time hog

On 13/07/2015 15:45, Richard Biener wrote: It would be nice to have a patch that can be backported to the GCC 5 branch as well. We can improve this on trunk as followup,no? The patch I've already posted can be backported. O:-) Paolo

[PATCH] PR/66760, ipa-inline-analysis.c compile-time hog

From: bonz...@gnu.org In this PR, a lot of time is spent doing the same ipa_load_from_parm_agg query over and over. Luckily a memoization scheme is already there, it's just not used by ipa-inline-analysis.c. The patch moves the cache struct (struct func_body_info) to ipa-prop.h and modify

Re: [PR25530] Convert (unsigned t / 2) * 2 into (unsigned t ~1)

On 07/07/2015 11:08, Richard Biener wrote: Also I am not sure ceil_div and floor_div can be handled this way. (5 /[ceil] 2) * 2 == 6 but you compute it as 4. So I am only convinced trunc_div works this way. Of course also floor_div for unsigned arguments. For signed arguments, ceil_div

Re: [PATCH] top-level for libvtv: use normal (not raw_cxx) target exports

On 09/06/2015 16:22, Michael Haubenwallner wrote: Hi build machinery maintainers, since we always build the C++ compiler now, I fail to see the need to still use RAW_CXX_TARGET_EXPORTS for libvtv. The situation to expose the problem is: * Use a multilib-enabled x86_64-linux box. * Use

undefined behavior of signed left shifts (was Re: [PULL 00/40] ppc patch queue 2015-06-03)

On 05/06/2015 17:45, Peter Maydell wrote: ...but things like (1U 31) are entirely valid. They're only valid until someone does a ~ on them. I think it's reasonable to forbid them in our coding standards, if we want to fix ubsan's warning of (1 31). I don't think it's reasonable for

Re: patch to fix rtl documentation for new floating point comparisons

On 10/02/2015 22:46, Joseph Myers wrote: It may make sense to define LTGT as exactly !UNEQ, and so quiet, but the choice of definition is a matter of what's convenient for the implementation (and which choice you make determines which existing code in GCC should be considered incorrect).

Re: [PATCH, FT32] initial support

On 03/02/2015 07:05, Andrew Pinski wrote: Likewise of: +(define_insn abssi2 + [(set (match_operand:SI 0 register_operand =r) + (abs:SI (match_operand:SI 1 register_operand r))) + (clobber (match_scratch:SI 2 =r))] + + ashr.l\t%2,%1,31\;xor.l\t%0,%1,%2\;sub.l\t%0,%0,%2) optabs.c's

Re: Patch RFA: Support for building Go tools

On 09/01/2015 15:24, Ian Lance Taylor wrote: This should work automatically, the only difference is that you must omit $(LIBGODEP) from the dependencies. What will happen if there is no installed gccgo at the right version? Compilation fails. What should happen? Compilation fails. :)

Re: Patch RFA: Support for building Go tools

On 08/01/2015 22:35, Ian Lance Taylor wrote: +if NATIVE + +# For a native build we build the programs using the newly built libgo +# and install them as regular programs. + +bin_PROGRAMS = go$(EXEEXT) gofmt$(EXEEXT) +libexecsub_PROGRAMS = cgo$(EXEEXT) + +go$(EXEEXT):

Re: [ping] [PATCH] combine: Do not allow identical insns for I0,I1 and/or I2 (PR64268)

On 19/12/2014 16:13, Segher Boessenkool wrote: Hi, Sorry for the quick ping, but this fixes bootstrap on AIX, powerpc-darwin, and 32-bit PowerPC Linux. Could a gentle soul please spare a minute to review, before the holidays? Thanks in advance! I cannot approve it, but the patch is

Re: [PATCH] combine: If a parallel I2 was split, do not allow a new I2 (PR64268)

On 15/12/2014 17:24, Segher Boessenkool wrote: On Mon, Dec 15, 2014 at 04:51:14PM +0100, Paolo Bonzini wrote: Random questions: 1) did you check that it never triggers on e.g. an x86 bootstrap, and that it doesn't trigger too often on PPC64? I have checked on my largish connection

Re: [PATCH] combine: If a parallel I2 was split, do not allow a new I2 (PR64268)

On 15/12/2014 12:05, Segher Boessenkool wrote: If combine is given a parallel I2, it splits it into separate I1 and I2 insns in some cases (one case since the beginning of time; more cases since my r218248). It gives the new I1 the same UID as the I2 already has; there is a comment that

Re: [patch, build] Restore bootstrap in building libcc1 on darwin

On 05/12/2014 23:47, Jakub Jelinek wrote: On Fri, Dec 05, 2014 at 11:34:28PM +0100, Dominique Dhumieres wrote: As I've tried to explain, that is IMHO wrong though. If what you are after is the -B stuff too, then perhaps: ... Sorry but it does not work: Sorry, make that (just removed 4x

Re: [patch, build] Restore bootstrap in building libcc1 on darwin

On 05/12/2014 23:47, Jakub Jelinek wrote: On Fri, Dec 05, 2014 at 11:34:28PM +0100, Dominique Dhumieres wrote: As I've tried to explain, that is IMHO wrong though. If what you are after is the -B stuff too, then perhaps: ... Sorry but it does not work: Sorry, make that (just removed 4x

Re: libcc1

On 10/29/2014 09:10 PM, Jakub Jelinek wrote: On Wed, Oct 29, 2014 at 11:45:51AM +0100, Jakub Jelinek wrote: On Wed, Oct 29, 2014 at 11:37:26AM +0100, Paolo Bonzini wrote: On 10/29/2014 11:31 AM, Jakub Jelinek wrote: shouldn't libcc1 be in build_tools instead? I mean, it is a library meant

Re: libcc1

On 10/29/2014 11:31 AM, Jakub Jelinek wrote: It would be nice to have libcc1 built just once, not bootstrap it, but it is a build module, is that possible? In toplevel configure.ac I'm seeing: host_tools=texinfo flex bison binutils gas ld fixincludes gcc cgen sid sim gdb gprof etc

Re: [PATCH 5/5] add libcc1

On 10/29/2014 11:28 AM, Jakub Jelinek wrote: If this passes bootstrap/regtest, is it ok for trunk (should fix two bootstrap issues)? Is the https://gcc.gnu.org/ml/gcc-patches/2014-10/msg02936.html patch ok too (that one already tested; another bootstrap issue)? Both seem okay, though I'd

Re: libcc1

On 10/29/2014 11:45 AM, Jakub Jelinek wrote: On Wed, Oct 29, 2014 at 11:37:26AM +0100, Paolo Bonzini wrote: On 10/29/2014 11:31 AM, Jakub Jelinek wrote: shouldn't libcc1 be in build_tools instead? I mean, it is a library meant to be dlopened by gdb and gcc plugin that uses that library, so

Re: [PATCH 5/5] add libcc1

On 10/29/2014 11:51 AM, Jakub Jelinek wrote: On Wed, Oct 29, 2014 at 11:37:42AM +0100, Paolo Bonzini wrote: On 10/29/2014 11:28 AM, Jakub Jelinek wrote: If this passes bootstrap/regtest, is it ok for trunk (should fix two bootstrap issues)? Is the https://gcc.gnu.org/ml/gcc-patches/2014

Re: libcc1

On 10/29/2014 11:58 AM, Phil Muldoon wrote: My archaeology into the source repository has not revealed why we needed bootstrap. Perhaps we included it out of a sense of paranoia for testing. I've CC'd Tom on this, so he may have an opinion or insight. From my point of view, I see no value

Re: [PATCH 5/5] add libcc1

On 10/29/2014 11:59 AM, Jakub Jelinek wrote: Ah, got it. Is it hard to move the inclusion to the actual users? I think it is hard. I think it has been moved to system.h very much intentionally, as including gmp.h only in selected headers was causing lots of troubles, e.g. because of #pragma

Re: PATCH: fix breakage from [PATCH] Fix genmatch linking

On 10/24/2014 06:32 AM, Hans-Peter Nilsson wrote: It seems more correct to just disable the config.cache sharing between the differently-configured build-subdirectories, as is already is done for host-libraries and target-libraries, even if that may slow down the builds. Yes, please do.

Re: libffi patch RFA: Pass -Qunused-arguments for asm files

Il 30/09/2014 02:12, Ian Lance Taylor ha scritto: Similar to a recent patch to libgo, this patch to the libffi configure script checks whether the compiler support -Qunused-arguments. If it does, it passes -Qunused-arguments when invoking the compiler on .s files. This is because the clang

Re: [kyukhin/gomp4-offload] DESTDIR issues

Il 17/09/2014 15:31, Jakub Jelinek ha scritto: It seems building of the host compiler requires the offloading compiler to be installed directly in the prefix, which is something really undesirable e.g. for distro builds where things are installed with non-empty $(DESTDIR). Is the offloading

Re: [kyukhin/gomp4-offload] DESTDIR issues

Il 17/09/2014 16:09, Jakub Jelinek ha scritto: Is the offloading compiler built together with GCC or previously? If the latter, what's the difference between the offloading compiler and say gmp? Setting the LD_LIBRARY_PATH would be the responsibility of whoever builds GCC; it would be

Re: Does anyone use Ada on Alpha?

Il 24/07/2014 19:32, Uros Bizjak ha scritto: Hello! Well, I was lucky enough to gain access to an alpha pca56 for a day (I say lucky, this may not be repeatable!). However I was not able to build the Ada frontend, due (AFAICT) to the image being too big for relocations. (Moreover, my

Re: [build, driver] RFC: Support compressed debug sections

Il 26/06/2014 15:16, Rainer Orth ha scritto: Hi Gerald, sorry for the delay, I've been away for a couple of days. On Tue, 3 Jun 2014, Rainer Orth wrote: It's been another week, and I still need approval for the build, doc, and Darwin changes:

Re: PING: PATCH [4/n]: Prepare x32: Permute the conversion and addition if one operand is a constant

Il 29/05/2014 19:20, pins...@gmail.com ha scritto: What is your Pmode? Pmode is dimode while ptr_mode is simode. Pointers are zero extended when converting between si and di modes. As you noted, the fundamental difference between x32 and aarch64 is that aarch64 will still use 64-bit

Re: Code emitted was bloated with no optimisation.

Il 11/04/2014 07:05, Richard Sandiford ha scritto: Sure, but this is a bit extreme. I don't see off-hand how a[i] would generate a branch, for starters. That's an HI+HI-SI addition, with the higher half stored in (SP+2). The jump is emitted by cstore in order to compute the carry.

Re: [PATCH] Fix --with-build-config=bootstrap-ubsan bootstrap of fixincludes (PR sanitizer/56781)

Il 25/03/2014 20:24, Jakub Jelinek ha scritto: Hi! This patch fixes a problem where build of host fixincludes fails with --with-build-config=bootstrap-ubsan (and bootstrap-asan). The problem is that fixincludes is linked against host libiberty that is bootstrapped, but fixincludes is not

Re: [Build, Driver] Add -lcilkrts for -fcilkplus

Il 26/03/2014 00:28, Tobias Burnus ha scritto: Paolo Bonzini wrote: Il 11/03/2014 07:42, Tobias Burnus ha scritto: +XPCFLAGS= +CFLAGS=$CFLAGS -pthread +AC_LINK_IFELSE( ... + [XPCFLAGS= -Wc,-pthread], XPCFLAGS is dead, I think? Yes - contrary to libgomp, from which I have taken that code

Re: [Build, Driver] Add -lcilkrts for -fcilkplus

Il 11/03/2014 07:42, Tobias Burnus ha scritto: +# Check to see if -pthread or -lpthread is needed. Prefer the former. +# In case the pthread.h system header is not found, this test will fail. +XPCFLAGS= +CFLAGS=$CFLAGS -pthread +AC_LINK_IFELSE( + [AC_LANG_PROGRAM( + [#include pthread.h +

Re: [PATCH] Don't bootstrap libsanitizer or libvtv unless needed

Il 20/03/2014 13:24, Jakub Jelinek ha scritto: Hi! We currently bootstrap both libsanitizer and libvtv, the former just in case somebody decides to --with-build-config=bootstrap-asan (or --with-build-config=bootstrap-ubsan), the latter if somebody decides to --enable-vtable-verify. This patch

Re: [build] Have s-macro_list depend on cc1

Il 23/03/2014 09:24, Rainer Orth ha scritto: The following patch adds it and indeed macro_list now is non-empty, as expected. I'm just not sure if cc1 is the correct one in gcc/Makefile.in, or if it should rather be $(COMPILERS) instead. Anyway, with that patch a i386-pc-solaris2.10

Re: [build] Have s-macro_list depend on cc1

Il 21/03/2014 18:05, Rainer Orth ha scritto: The following patch adds it and indeed macro_list now is non-empty, as expected. I'm just not sure if cc1 is the correct one in gcc/Makefile.in, or if it should rather be $(COMPILERS) instead. Anyway, with that patch a i386-pc-solaris2.10 bootstrap

Re: [Build] libcilkrts/Makefile.am: Install cilk.h

Il 09/03/2014 07:24, Tobias Burnus ha scritto: The attached patch installs cilk.h such that #include cilk/cilk.h works. Bootstrapped on x86-64-gnu-linux. OK for the trunk? (If you wonder about the other changes in the generated-files diff: I think they are due to r205357, where configure.ac

Re: [build, i386] Disable local dynamic TLS model on Solaris/x86 if as/ld cannot handle it

Il 05/03/2014 16:53, Rainer Orth ha scritto: When using GNU as with Solaris ld, the TLS local dynamic tests (gcc.dg/torture/tls/run-ld.c etc.) FAIL to execute before Solaris 11: the programs crash with an illegal instruction: e.g. in the gcc.dg/lto/20090210 test, we have 0x8050ce0 main+48: mov

Re: [PATCH] Fix up make bootstrap-lean; make install (PR bootstrap/58572)

Il 07/03/2014 11:45, Jakub Jelinek ha scritto: On Fri, Mar 07, 2014 at 08:26:47AM +0100, Paolo Bonzini wrote: Il 06/03/2014 19:58, Jakub Jelinek ha scritto: Bootstrapped/regtested on x86_64-linux and i686-linux and tested also with make bootstrap-lean; make install, ok for trunk? Nice

Re: [build, libgcc] Don't install vtv_*.o unless --enable-vtable-verify (PR libgcc/59339)

Il 06/03/2014 12:55, Rainer Orth ha scritto: Uros pointed me at PR libgcc/59339 where make install tries to install the vtv_*.o files even if they aren't built, leading to install warnings. The following patch fixes this by ensuring that the files are only installed if built. Tested with make

Re: [PATCH] Fix up make bootstrap-lean; make install (PR bootstrap/58572)

Il 06/03/2014 19:58, Jakub Jelinek ha scritto: Hi! As discussed in the PR, doing make bootstrap-lean make install right now may fail (if host compiler is too old), or recompile various objects of the compiler with system gcc before it is installed. This happens because starting with the

Re: [build, libgcc] Ensure libgcc_s unwinder is always used on 64-bit Solaris 10+/x86 (PR target/59788)

Il 17/01/2014 15:21, Rainer Orth ha scritto: As described in the PR, the 64-bit Solaris 10+/x86 libc contains an implementation of those _Unwind_* functions required by the AMD64 ABI, i.e. those contained in libgcc_s.so.1 at version GCC_3.0. If by some circumstance (use of -Bdirect, -z

Re: [RFC, patch] Detect lack of 32-bit devel environment on x86_64-linux targets

Il 09/12/2013 12:08, Gerald Pfeifer ha scritto: On Mon, 9 Dec 2013, FX wrote: Look at this as a diagnostics bug: our current diagnostics for this pretty common situation sucks. It comes late in the compilation, and the message itself isn’t helpful. Totally seconded. Paolo, I have been

  1   2   3   4   5   6   7   8   9   10   >