Re: [RFC, testsuite/guality] Use relative line numbers in gdb-test

On Jun 28, 2018, at 12:39 PM, Tom de Vries wrote: > This patch adds a dg-final override that passes it's first argument to the > gdb-test action. This allows us to use relative line numbers in gdb-test. > > Tested pr45882.c. > > Any comments? > 2018-06-28 Tom de Vries > > * gcc.dg/gu

Re: [PATCH] testsuite: Allow general skips/requires in PCH tests

On Oct 26, 2023, at 5:34 AM, Richard Sandiford wrote: > dg-pch.exp handled dg-require-effective-target pch_supported_debug > as a special case, by grepping the source code. This patch tries > to generalise it to other dg-require-effective-targets, and to > dg-skip-if. > > There also seemed to b

Re: [PATCH] testsuite: Force use of -c when precompiling headers

On Oct 27, 2023, at 8:11 AM, Christophe Lyon wrote: > > In some configurations of our validation setup, we always call the > compiler with -Wl,-rpath=XXX, which instructs the driver to invoke the > linker if none of -c, -S or -E is used. > > This happens to be the case in the PCH tests, where dg

Re: testsuite: introduce hostedlib effective target

On Nov 1, 2023, at 6:11 PM, Alexandre Oliva wrote: > > Several C++ tests fail with --disable-hosted-libstdcxx, whether > because stdc++ext gets linked in despite not being built, because > standard headers are included but that are unavailable in this mode, > or because headers are (mistakenly?)

Re: [PATCH 1/2] testsuite: Add and use thread_fence effective-target

On Oct 2, 2023, at 1:24 AM, Christophe Lyon wrote: > > ping? > > On Sun, 10 Sept 2023 at 21:31, Christophe Lyon > wrote: > Some targets like arm-eabi with newlib and default settings rely on > __sync_synchronize() to ensure synchronization. Newlib does not > implement it by default, to make u

Re: [PATCH] testsuite: check for and use -mno-strict-align where needed

On Oct 19, 2023, at 8:16 PM, Alexandre Oliva wrote: > > On Mar 10, 2021, Alexandre Oliva wrote: > >> ppc configurations that have -mstrict-align enabled by default fail >> gcc.dg/strlenopt-80.c, because some memcpy calls don't get turned into >> MEM_REFs, which defeats the tested-for strlen opt

Re: [PATCH] Testsuite, i386: Mark test as requiring dfp

On Nov 5, 2023, at 12:33 PM, FX Coudert wrote: > > kind ping for this easy patch > > >> Le 30 oct. 2023 à 15:19, FX Coudert a écrit : >> >> Hi, >> >> The test is currently failing on x86_64-apple-darwin with "decimal >> floating-point not supported for this target”. >> Marking the test as r

Re: [PATCH] RFC: testsuite: add minimium version to dg-require-dot (PR analyzer/93293)

On Jan 17, 2020, at 2:07 PM, David Malcolm wrote: > > I ran into difficulties with the Graphviz format changing from under > me during an upgrade, where the new version of "dot" would reject .dot > files generated by the analyzer. > > Thoughts? [ consider this a peanut gallery comment ] Another

Re: [PATCH] analyzer: ensure that all DejaGnu tests have unique names

On Jan 17, 2020, at 1:30 PM, David Malcolm wrote: > > Jeff noticed various name collisions of test names in the analyzer > testsuite, due to me using empty comment strings when using line > offsets in test directives. > > This patch adds non-empty comment strings to such DejaGnu directives > thr

Re: [PATCH] testsuite: effective_target_march_option: support checking for -march=*

> On Jan 18, 2020, at 4:35 AM, Hans-Peter Nilsson wrote: > > testsuite: > * lib/target-supports.exp (effective_target_march_option): New. > > I see no (other) way to, depending on the absence of an option, > add an option for a specific target. Specifically, I don't see > how to do this

Re: [PATCH 1/2] analyzer: g++ testsuite support

On Feb 6, 2020, at 12:27 PM, David Malcolm wrote: > > PR analyzer/93288 reports a C++-specific ICE with -fanalyzer. > > This patch creates the beginnings of a C++ test suite for the analyzer, > so that there's a place to put test coverage for the fix. > It adds a regression test for PR analyzer/

Re: [RFC c-common PATCH] PR c++/40752 - useless -Wconversion with short +=.

On Jan 24, 2020, at 9:45 AM, David Edelsohn wrote: > > On Fri, Jan 24, 2020 at 12:00 PM Jason Merrill wrote: >> >> On 1/24/20 8:45 AM, David Edelsohn wrote: >>> There is no ChangeLog entry for the testsuite changes. >> >> I don't believe in ChangeLog entries for testcases, but I'll add one for

Re: [PATCH 00/14] rs6000: Begin replacing built-in support

On Feb 4, 2020, at 9:40 AM, Segher Boessenkool wrote: >> My intent is to make adding new built-in functions as simple as adding >> a few lines to a couple of files, and automatically generating as much >> of the initialization, overload resolution, and expansion logic as >> possible. This patch

Re: [PATCH v2 0/4] Fix library testsuite compilation for build sysroot

On Feb 13, 2020, at 3:36 PM, Maciej W. Rozycki wrote: > > This is v2 of patch series, originally posted here: > > > > >

Re: [PATCH v2 0/4] Fix library testsuite compilation for build sysroot

On Feb 14, 2020, at 11:57 AM, Maciej W. Rozycki wrote: > > Mike, Chung-Lin -- > >>> In the end I have decided to use the documented `--tool_exec' option to >>> `runtest' to contain the change within the testsuite's Makefile and its >>> `check' goal, which is inherent to the build tree and as s

Re: [PATCH 00/14] rs6000: Begin replacing built-in support

On Feb 14, 2020, at 1:26 PM, Segher Boessenkool wrote: > It remains to be seen how much of it can be used by other targets. > Pretending something is generic while it in fact is just a mass of > special cases isn't useful, it's just costly. Oh, yeah, of course. Ours was designed in two pieces,

Re: [PING^4][PATCH 0/4] Fix library testsuite compilation for build sysroot

On Dec 16, 2019, at 4:06 PM, Maciej W. Rozycki wrote: > > On Mon, 11 Nov 2019, Maciej W. Rozycki wrote: > >> This patch series addresses a problem with the testsuite compiler being >> set up across libatomic, libffi, libgo, libgomp with no correlation >> whatsoever to the target compiler being

Re: [PING][PATCH v2 2/2] testsuite: Fix run-time tracking down of `libgcc_s'

On Dec 9, 2019, at 1:30 PM, Maciej W. Rozycki wrote: > > On Fri, 29 Nov 2019, Maciej W. Rozycki wrote: > >> Fix a catastrophic libgo testsuite failure in cross-compilation where >> the shared `libgcc_s' library cannot be found by the loader at run time >> in build-tree testing and consequently

Re: undefine OFFSET in testsuite/gcc.dg/vect/tree-vect.h

On Dec 20, 2019, at 10:11 AM, Olivier Hainque wrote: > > The attached patch is a proposal for a basic solution > to an issue which might be an improper thing done by a > system header on VxWorks, but which is a big pain to fix > at this level and very simple to address super locally. > Is this O

Re: [patch] Prevent redefinition of WCHAR_MAX from testsuite/gcc.dg/cpp/ucs.c

On Dec 20, 2019, at 9:27 AM, Olivier Hainque wrote: > gcc/testsuite/gcc.dg/cpp/ucs.c #include > and then crafts a definition of WCHAR_MAX depending > on __WCHAR_TYPE__. > Ok to commit ? Ok.

Re: [patch] allow $ in scan-tree-dump expressions matching symbol names

On Dec 20, 2019, at 8:13 AM, Olivier Hainque wrote: > > This change adjusts a few scan-tree-dump expressions > to allow '$' as well as '.' when matching symbol names, > > Ok to commit ? Ok.

Re: [PATCH] c-c++-common/Wrestrict.c: fix some typos and enable for LLP64

On Feb 15, 2024, at 6:08 AM, Jonathan Yong <10wa...@gmail.com> wrote: > > Attached patch OK? Ok. > Copy/pasted for review convenience. > > diff --git a/gcc/testsuite/c-c++-common/Wrestrict.c > b/gcc/testsuite/c-c++-common/Wrestrict.c > index 4d005a618b3..57a3f67e21e 100644 > --- a/gcc/testsuit

Re: [PATCH] testsuite: Define _POSIX_C_SOURCE for test

On Mar 10, 2024, at 10:26 AM, Torbjörn SVENSSON wrote: > > Ok for trunk? Ok. > As the tests assume that strndup() is visible (only part of > POSIX.1-2008) define the guard to ensure that it's visible. Currently, > glibc appears to always have this defined in C++, newlib does not. > > Without

Re: [PATCH] testsuite, Objective-C++: Update link flags [PR112863].

On Jan 28, 2024, at 7:03 AM, Iain Sandoe wrote: > > Tested on i686, x86_64, aarch64 Darwin, x86_64, aarch64 Linux, > OK for trunk? Ok. If you discover needed updates, please feel free to drop them in.

Re: [PATCH] testsuite, ubsan: Add libstdc++ deps where required.

On Jan 30, 2024, at 2:31 AM, Iain Sandoe wrote: > > tested on i686, x86_64 (and aarch64) Darwin, x86_64, aarch64 Linux, > OK for trunk? Ok. If the ubsan people want to review this, certainly, happy to have them chime in.

Re: [PATCH] testsuite, asan, hwsan: Add libstdc++ deps where required.

On Jan 30, 2024, at 2:30 AM, Iain Sandoe wrote: > > tested on i686, x86_64 (and aarch64) Darwin, x86_64, aarch64 Linux, > OK for trunk? Ok. If asan people want to chime in...

Re: [PATCH] testsuite: i386: Fix gcc.target/i386/avx512vl-stv-rotatedi-1.c on 32-bit Solaris/x86

On Jan 24, 2024, at 1:12 AM, Rainer Orth wrote: > > gcc.target/i386/avx512vl-stv-rotatedi-1.c FAILs on 32-bit Solaris/x86 > since its introduction in > > commit 4814b63c3c2326cb5d7baa63882da60ac011bd97 > Author: Roger Sayle > Date: Mon Jul 10 09:04:29 2023 +0100 > >i386: Add AVX512 suppo

Re: [PATCH] testsuite: i386: Fix gcc.target/i386/pr70321.c on 32-bit Solaris/x86

On Jan 24, 2024, at 1:01 AM, Rainer Orth wrote: > > gcc.target/i386/pr70321.c FAILs on 32-bit Solaris/x86 since its > introduction in > > commit 43201f2c2173894bf7c423cad6da1c21567e06c0 > Author: Roger Sayle > Date: Mon May 30 21:20:09 2022 +0100 > >PR target/70321: Split double word equ

Re: [PATCH] testsuite: Pattern does not match when using --specs=nano.specs

On Feb 6, 2024, at 8:58 AM, Torbjörn SVENSSON wrote: > > Ok for trunk and releases/gcc-13? Ok. If .* goes across newlines, you might want to not use .. > -if {![regexp -- "/${compiler}(\\.exe)? -quiet.*$compiler_pattern" > $gcc_output]} { > +if {![regexp -- "/${compiler}(\\.exe)? .*-

Re: [PATCH v2] testsuite: Pattern does not match when using --specs=nano.specs

On Feb 8, 2024, at 9:44 AM, Torbjörn SVENSSON wrote: > > Changes since v1: > - Replaced .* with [^\r\n]* to avoid matching newline. > > Ok for trunk and releases/gcc-13? Ok.

Re: [PATCH] testsuite: Update test case to comply with GCC14 changes

On Feb 10, 2024, at 7:21 AM, Torbjörn SVENSSON wrote: > > I have confirmed that this updated pr97969.c file still hangs with > gcc-arm-none-eabi-9-2020-q2-update as mentioned in comment 2 of PR97969. > > Ok for trunk? Ok.

Re: [PATCH] i386, testsuite: adjust asm patterns

On Feb 10, 2024, at 10:07 AM, FX Coudert wrote: > > The new testcase gcc.target/i386/asm-raw-symbol.c fails on darwin. This is > partly because symbols are prefixed with underscore, and also because the > order of operands in the addition is reversed (but I think it’s valid still). > The code

Re: Unreviewed c++ and libgomp testsuite patches

> On Feb 12, 2024, at 5:27 AM, Rainer Orth > wrote: > > The following patches have remained unreviewed for a week or more: > > testsuite: Fix c-c++-common/pr103798-2.c on Solaris [PR113706] >https://gcc.gnu.org/pipermail/gcc-patches/2024-February/644842.html Jason commented.

Re: [PATCH] testsuite: Define _POSIX_SOURCE for tests [PR113278]

On Feb 15, 2024, at 9:03 AM, Torbjörn SVENSSON wrote: > > Ok for trunk? Ok. > gcc/testsuite/ChangeLog: > PR113278 > * c-c++-common/analyzer/fileno-1.c: Define _POSIX_SOURCE. > * c-c++-common/analyzer/flex-with-call-summaries.c: Same. > * c-c++-common/analyzer/flex-witho

Re: [PATCH] testsuite: Add support for scanning assembly with comparitor

On Feb 12, 2024, at 11:38 AM, Edwin Lu wrote: > > There is currently no support for matching at least x lines of assembly > (only scan-assembler-times). This patch would allow setting upper or lower > bounds. > > Use case: using different scheduler descriptions and/or cost models will > change

Re: [PATCH] testsuite: Fix up lra effective target

On Feb 16, 2024, at 2:16 AM, Jakub Jelinek wrote: > > Given the recent discussions on IRC started with Andrew P. mentioning that > an asm goto outputs test should have { target lra } and the lra effective > target in GCC 11/12 only returning 0 for PA and in 13/14 for PA/AVR, while > we clearly ha

Re: [PATCH] testsuite: Fix up lra effective target

On Feb 16, 2024, at 2:16 AM, Jakub Jelinek wrote: > > There is one special case, NVPTX, which is a TARGET_NO_REGISTER_ALLOCATION > target. I think claiming for it that it is a lra target is strange (even > though it effectively returns true for targetm.lra_p ()), unsure if it > supports asm goto

Re: [PATCH v5 RESEND] C, ObjC: Add -Wunterminated-string-initialization

On Feb 6, 2024, at 2:45 AM, Alejandro Colomar wrote: > > Warn about the following: > >char s[3] = "foo"; No ObjC specific impact here, so no need for ObjC review. As a member of the peanut gallery, I like the patch. Joseph, this is been submitted 5 times over the past year. Any thoughts

Re: [PATCH v5 RESEND] C, ObjC: Add -Wunterminated-string-initialization

On Feb 26, 2024, at 7:56 AM, Alejandro Colomar wrote: > > I don't see an obvious order in that file. Where would you put the > option? The best place, would be to put it just after: -Warray-bounds -Warray-bounds=n This is a functional style grouping that best mirrors the existing orde

Re: Ping [PATCH] testsuite: Reduce gcc.dg/torture/inline-mem-cpy-1.c by 11 for simulators

On Jan 12, 2024, at 2:52 AM, Hans-Peter Nilsson wrote: > > Ping. (Don't miss the gcc.dg/torture/inline-mem-cpy-1.c part.) > > On Mon, 1 Jan 2024, Hans-Peter Nilsson wrote: > >> Tested mmix-knuth-mmixware (where all torture-variants of >> gcc.dg/torture/inline-mem-cpy-1.c now pass) and native >

Re: [PATCH] Allow overriding EXPECT

On Dec 21, 2023, at 8:49 AM, Christophe Lyon wrote: > > While investigating possible race conditions in the GCC testsuites > caused by bufferization issues, I wanted to investigate workarounds > similar to GDB's READ1 [1], and I noticed it was not always possible > to override EXPECT when running

Re: [PATCH] testsuite: skip gcc.target/i386/pr106910-1.c test when using newlib

On Nov 6, 2023, at 2:57 AM, Marc Poulhiès wrote: > > Using newlib produces a different codegen because the support for c99 > differs (see libc_has_function hook). > > gcc/testsuite/ChangeLog: > > * gcc.target/i386/pr106910-1.c: Disable for newlib. > --- > Tested on x86_64-linux and x86_64

Re: [PATCH] testsuite: refine gcc.dg/analyzer/fd-4.c test for newlib

On Nov 6, 2023, at 3:01 AM, Marc Poulhiès wrote: > > Contrary to glibc, including stdio.h from newlib defines mode_t which > conflicts with the test's type definition. > > .../gcc/testsuite/gcc.dg/analyzer/fd-4.c:19:3: error: redefinition of typedef > 'mode_t' with different type > ... > .../in

Re: [PATCH] testsuite: require avx_runtime for some tests

On Nov 6, 2023, at 2:59 AM, Marc Poulhiès wrote: > > These 3 tests fails parsing the 'vect' dump when not using -mavx. Make > the dependency explicit. > > gcc/testsuite/ChangeLog: > > * gcc.dg/vect/vect-ifcvt-18.c: Add dep on avx_runtime. > * gcc.dg/vect/vect-simd-clone-16f.c: Likew

Re: [PATCH] Testsuite: restrict test to nonpic targets

On Dec 11, 2023, at 12:29 AM, FX Coudert wrote: > > The test is currently failing on x86_64-apple-darwin. This patch requires > nonpic, as suggested in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112297 > by Andrew Pinski. > > OK to commit? Ok.

Re: [PATCH] testsuite: arg-pushing reqs -mno-accumulate-outgoing-args

On Nov 8, 2023, at 7:55 AM, Alexandre Oliva wrote: > > gcc.target/i386/pr95126-m32-[34].c expect push instructions that are > only present with -mno-accumulate-outgoing-args, so make that option > explicit rather than dependent on tuning. > > Regstrapped on x86_64-linux-gnu, also tested with gcc

Re: testsuite: introduce hostedlib effective target

On Nov 8, 2023, at 8:29 AM, Alexandre Oliva wrote: > > On Nov 5, 2023, Mike Stump wrote: > >> that, otherwise, I'll approve this version. > > FWIW, this version is not usable as is. Something went wrong in my > testing, and several regressions only visib

Re: [PATCH] testsuite: tsan: add fallback overload for pthread_cond_clockwait

On Nov 8, 2023, at 5:49 PM, Alexandre Oliva wrote: > > LTS GNU/Linux distros from 2018, still in use, don't have > pthread_cond_clockwait. There's no trivial way to detect it so as to > make the test conditional, but there's an easy enough way to silence > the fail due to lack of the function in

Re: [PATCH #4/4] testsuite: discard c++ exclusion on underaligned pointer warning

On Nov 19, 2023, at 6:34 PM, Alexandre Oliva wrote: > > Having extended check_and_warn_address_or_pointer_of_packed_member to > find the packed (short) enum pointer in the cast expression coming > from the C++ front-end, and amended the C++ front end to mark short > enums as TYPE_PACKED, C++ issu

Re: [PATCH] testsuite/gcc.dg/uninit-pred-9_b.c:20: Fix XPASS for various targets

On Nov 24, 2023, at 7:15 PM, Hans-Peter Nilsson wrote: > > While looking at the various targets, I found that the m32r > target has two options implemented as opposites: > -mbranch-cost=1 and -mbranch-cost=2, that have a bug that > makes them yield their functionally opposite effect; > i.e. -mbra

Re: [PATCH] [testsuite] conditionalize dg-additional-sources on target and type

On May 23, 2024, at 6:28 AM, Alexandre Oliva wrote; > I came up with an entirely different approach: > > > g++.dg/vect/pr95401.cc has dg-additional-sources, and that fails when > check_vect_support_and_set_flags finds vector support lacking for > execution tests: tests decay to compile tests, an

Re: More variants of C/C++ test cases for 'constructor', 'destructor' function attributes with priority

On Jun 4, 2024, at 11:30 AM, Thomas Schwinge wrote: > > For my recent work on > "nvptx target: Global constructor, destructor support, via nvptx-tools 'ld'", > I needed more variants of C/C++ test cases for 'constructor', > 'destructor' function attributes with priority: in particular, split into

Re: [PATCH] [c++] [testsuite] adjust contracts9.C for negative addresses

On Apr 15, 2024, at 8:20 PM, Alexandre Oliva wrote: > > The test expected the address of a literal string, converted to long > long, to yield a positive value. That expectation doesn't necessarily > hold, and the test fails where it doesn't. > > Adjust the test to use a pointer that will compar

Re: [PATCH] [testsuite] [arm] accept empty init for bfloat16

On Apr 15, 2024, at 8:50 PM, Alexandre Oliva wrote: > > Complete r13-2205, adjusting an arm-specific test that expects a > no-longer-issued error at an empty initializer. > > Regstrapped on x86_64-linux-gnu. Also tested with gcc-13 on arm-, > aarch64-, x86- and x86_64-vxworks7r2. Ok to install

Re: [PATCH] [testsuite] introduce strndup effective target

On Apr 18, 2024, at 4:32 AM, Alexandre Oliva wrote: > > On Apr 16, 2024, Alexandre Oliva wrote: > >> * gcc.dg/builtin-dynamic-object-size-1.c: Likewise. >> * gcc.dg/builtin-dynamic-object-size-2.c: Likewise. >> * gcc.dg/builtin-dynamic-object-size-3.c: Likewise. >> * gcc.dg/

Re: [PATCH v2] [testsuite] require sqrt_insn effective target where needed

On Apr 22, 2024, at 2:56 AM, Alexandre Oliva wrote: > > This patch takes feedback received for 3 earlier patches, and adopts a > simpler approach to skip the still-failing tests, that I believe to be > in line with ppc maintainers' expressed preferences. > https://gcc.gnu.org/pipermail/gcc-patche

Re: [PATCH] vax: resolve long-standing documentation bugs re floating-point codegen [PR79646]

On Apr 26, 2024, at 11:17 AM, Abe Skolnik wrote: You never need to do any work in .po files, omit that part and repost.

Re: [PATCH] testsuite: Prune compilation messages for modules tests

On Aug 18, 2024, at 3:28 PM, Hans-Peter Nilsson wrote: > > As noticed when verifying the dejagnu fix. Tested cris-elf > with a new newlib that arranges to emit the mentioned > warning, with/without the update in dejagnu to handle the > miniscule "in". Ok to commit? Ok.

Re: [PATCH] testsuite: Rename scanltranstree.exp -> scanltrans.exp

On Aug 29, 2024, at 9:07 AM, Alex Coplan wrote: > > Since r15-3254-g3f51f0dc88ec21c1ec79df694200f10ef85915f4 > added scan-ltrans-rtl* variants to scanltranstree.exp, it no longer > makes sense to have "tree" in the name. This renames the file > accordingly and updates users. > > Tested on aarch

Re: [PATCH v2] [testsuite] add linkonly to dg-additional-sources [PR115295]

On Jun 11, 2024, at 10:56 PM, Alexandre Oliva wrote: > > On Jun 11, 2024, Andrew Pinski wrote: > >> I think we should just fully revert the changes to >> dg-additional-sources and add an explicit `dg-do run` to pr95401.cc > > I don't suppose an explicit "dg-do run" would make things work relia

Re: [PING^3] [PATCH] PR116080: Fix test suite checks for musttail

On Sep 2, 2024, at 4:23 PM, Andi Kleen wrote: > > Andi Kleen writes: > > PING^3 Ok. >> Andi Kleen writes: >> >> PING^2 for https://gcc.gnu.org/pipermail/gcc-patches/2024-July/658602.html >> >> This fixes some musttail related test suite failures that cause noise on >> various targets. >>

Re: [PATCH v2] testsuite: introduce hostedlib effective target

On Sep 3, 2024, at 11:44 PM, Alexandre Oliva wrote: > > On Nov 9, 2023, Mike Stump wrote: > >> On Nov 8, 2023, at 8:29 AM, Alexandre Oliva wrote: >>> >>> On Nov 5, 2023, Mike Stump wrote: >>> >>>> that, otherwise, I'll approve th

Re: [PATCH] Make 'target-supports.exp' additions for nvptx target generally available

Ok. Though, some of these files are so littered with target bits that essentially it doesn't make too much a difference. On Jul 18, 2024, at 4:44 AM, Thomas Schwinge wrote: > > OK to push (once testing completes) the attached > "Make 'target-supports.exp' additions for nvptx target generally a

Re: [PATCH v2] testsuite: introduce hostedlib effective target

On Sep 3, 2024, at 11:44 PM, Alexandre Oliva wrote: > > Here's an updated and refreshed version that gets trunk built with > --disable-hosted-libstdcxx on x86_64-linux-gnu to not get any spurious > fails during in-tree testing. Also bootstrapped on hosted > x86_64-linux-gnu. Ok to install? Ok.

Re: [PATCH] testsuite: a few more hostedlib adjustments

On Sep 12, 2024, at 6:08 PM, Alexandre Oliva wrote: > > On Sep 12, 2024, Mike Stump wrote: > >> On Sep 3, 2024, at 11:44 PM, Alexandre Oliva wrote: >>> >>> Here's an updated and refreshed version that gets trunk built with >>> --disable-host

Re: [committed] libstdc++: Add .editorconfig files

On Sep 16, 2024, at 2:23 AM, Jonathan Wakely wrote: > > Arsen mentioned that he has some similar emacs config for formatting > libstdc++ code which should probably be added to the repo somewhere (I > don't know enough about emacs to know where that should be, or how to > make it only apply to the

Re: [PATCH v3 08/18] convert the ObjC++ front end to automatic dependencies

On Aug 20, 2013, at 6:59 AM, Tom Tromey wrote: > This converts the ObjC++ front end. Ok.

Re: [PATCH v3 07/18] convert the ObjC front end to automatic dependencies

On Aug 20, 2013, at 6:59 AM, Tom Tromey wrote: > This converts the ObjC front end. Ok.

Re: RFC - Refactor tree.h

On Aug 21, 2013, at 10:23 AM, Andrew MacLeod wrote: > On 08/10/2013 06:03 AM, Richard Biener wrote: >> Mike Stump wrote: >>> On Aug 9, 2013, at 3:36 PM, Diego Novillo wrote: >>>> This patch is still WIP. It builds stage1, but I'm getting ICEs >>>&

Re: Symtab cleanup 10/17 remove unnecesary DECL_ARGUMENTS and DECL_RESULT

On Aug 1, 2013, at 8:09 AM, Jan Hubicka wrote: > Now when we have abstract origins tracked, this patch makes DECL_ARGUMENTS and > DECL_RESULT to be removed from FUNCTION_DECLs that are never passed to symbol > table. This reduces LTO streaming effort (by about 1/3rd of PARM_DECls) So, I was trac

Re: [C++ patch] Set attributes for C++ runtime library calls

On Aug 22, 2013, at 9:45 AM, Gabriel Dos Reis wrote: >> I.e. can I have something like >> >> int a; >> test() >> { >> int *b=new (int); >> } >> >> with custom implementation of new that returns &a? > > If the user-supplied operator new returns &a, then it must > also ensure that 'a' is not us

Re: [C++ patch] Set attributes for C++ runtime library calls

On Aug 22, 2013, at 2:28 PM, Gabriel Dos Reis wrote: > On Thu, Aug 22, 2013 at 4:14 PM, Mike Stump wrote: >> On Aug 22, 2013, at 9:45 AM, Gabriel Dos Reis >> wrote: >>>> I.e. can I have something like >>>> >>>> int a; >>>> tes

Re: [C++ patch] Set attributes for C++ runtime library calls

On Aug 22, 2013, at 6:10 PM, Gabriel Dos Reis wrote: > I think we must distinguish what is "wrong" according to the standards > we are implementing from what is "wrong" from a QoI point of view. Not if they match, we don't. > My reasoning (for C++98, but the same is true for C++11) is based > o

Re: wide-int branch now up for public comment and review

On Aug 23, 2013, at 8:02 AM, Richard Sandiford wrote: >> /* Negate THIS. */ >> inline wide_int_ro >> wide_int_ro::operator - () const >> { >> wide_int_ro r; >> r = wide_int_ro (0) - *this; >> return r; >> } >> >> /* Negate THIS. */ >> inline wide_int_ro >> wide_int_ro::neg () const >> { >>

Re: [C++ patch] Set attributes for C++ runtime library calls

On Aug 22, 2013, at 7:16 PM, Gabriel Dos Reis wrote: >>> My reasoning (for C++98, but the same is true for C++11) is based >>> on 3.8/1: >>> […] >>> The lifetime of an object of type T ends when: >>> -- if T is a class type with a non-trivial destructor (12.4), >>> the destructor call st

Re: wide-int branch now up for public comment and review

On Aug 23, 2013, at 8:02 AM, Richard Sandiford wrote: >> #define addr_max_bitsize (64) >> #define addr_max_precision \ > > These should either be lower-case C++ constants or upper-case macros. Fixed: diff --git a/gcc/wide-int.h b/gcc/wide-int.h index 9ccdf7c..b40962c 100644 --- a/gcc/wide-int.

Re: wide-int branch now up for public comment and review

On Aug 23, 2013, at 8:02 AM, Richard Sandiford wrote: >> * When a constant that has an integer type is converted to a >>wide-int it comes in with precision 0. For these constants the >>top bit does accurately reflect the sign of that constant; this >>is an exception to the normal ru

Re: [C++ patch] Set attributes for C++ runtime library calls

On Aug 23, 2013, at 5:53 PM, Gabriel Dos Reis wrote: > If you quoted the standard to back up your assertions, I would have been > able to "feel free to point this out" :-) > > The thing is I am still trying to figure out what (1) what you would have > liked; I've directly stated it, not sure h

Re: wide-int branch now up for public comment and review

On Aug 23, 2013, at 8:02 AM, Richard Sandiford wrote: > We really need to get rid of the #include "tm.h" in wide-int.h. > MAX_BITSIZE_MODE_ANY_INT should be the only partially-target-dependent > thing in there. If that comes from tm.h then perhaps we should put it > into a new header file instea

Re: wide-int branch now up for public comment and review

On Aug 25, 2013, at 11:29 AM, Richard Sandiford wrote: > Mike Stump writes: >> On Aug 23, 2013, at 8:02 AM, Richard Sandiford >> wrote: >>> We really need to get rid of the #include "tm.h" in wide-int.h. >>> MAX_BITSIZE_MODE_ANY_INT should be the o

Re: wide-int branch now up for public comment and review

On Aug 25, 2013, at 11:29 AM, Richard Sandiford wrote: > Looks like wide-int is just using BITS_PER_UNIT to get the number of > bits in "char". That's a host thing, so it should be CHAR_BIT instead. Oh, Kenny did point out one sin: diff --git a/gcc/wide-int.cc b/gcc/wide-int.cc index 37ce5b3..

Re: wide-int branch now up for public comment and review

On Aug 25, 2013, at 1:11 PM, "Joseph S. Myers" wrote: > On Sun, 25 Aug 2013, Mike Stump wrote: >> On Aug 23, 2013, at 8:02 AM, Richard Sandiford >> wrote: >>> We really need to get rid of the #include "tm.h" in wide-int.h. >>> MAX_BIT

Re: wide-int branch now up for public comment and review

On Aug 25, 2013, at 12:26 AM, Richard Sandiford wrote: > (2) Adding a new namespace, wi, for the operators. So far this >just contains the previously-static comparison functions >and whatever else was needed to avoid cross-dependencies >between wi and wide_int_ro (except for the debu

Re: powerpc64le multilibs and multiarch dir

On Aug 25, 2013, at 8:32 PM, Alan Modra wrote: > We (IBM) don't intend to support running both big and little-endian > processes on the same system in the near future. Perhaps I'm jumping > the gun in defining the multi-os dirs like /lible and /lib64le. I'd recommend against multilibs, unless yo

Re: [C++ patch] Set attributes for C++ runtime library calls

On Aug 23, 2013, at 9:36 PM, Gabriel Dos Reis wrote: > You made a statement. It was not clear whether it was what you want > or whether it is what the standards mandate. Both. >>> (2) what you believe the standards mandate, with appropriate quote; and >> >> The life of the original object doe

[wide-int] Add missing ()

[wide-int] Add missing () diff --git a/gcc/genmodes.c b/gcc/genmodes.c index a27993a..946dcc9 100644 --- a/gcc/genmodes.c +++ b/gcc/genmodes.c @@ -874,14 +874,14 @@ emit_max_int (void) max = i->bytesize; if (max > mmax) mmax = max; - printf ("#define MAX_BITSIZE_MODE_ANY_INT %d*BI

Re: ELF interposition and One Definition Rule

On Aug 26, 2013, at 8:21 AM, Jan Hubicka wrote: > My understanding of C++ One Definition Rule, in a strict sense, does not a > allow in to define two functions of the same name and different semantics in a > valid program . I also think that all DSOs eventually linked together or > dlopenned are p

Re: [PATCH 1/2] Convert symtab, cgraph and varpool nodes into a real class hierarchy

On Aug 27, 2013, at 4:08 AM, Richard Biener wrote: >> and converts: >> struct GTY(()) cgraph_node >> to: >> struct GTY((user)) cgraph_node : public symtab_node_base GTY didn't like single inheritance for me in in wide-int.h. I extended GTY to support it better. See the wide-int branch, if y

[wide-int] fix mips build error

Since we use these in a cpp #if, we have to use #define for them. Index: wide-int.h === --- wide-int.h (revision 202032) +++ wide-int.h (working copy) @@ -249,15 +249,15 @@ along with GCC; see the file COPYING3. on any platfor

Re: opt-info message change for vectorizer

On Aug 27, 2013, at 11:22 AM, Xinliang David Li wrote: > Does this one look ok? We don't capitalize text after error:, warning: or note:. > thanks, > > David > > On Thu, Aug 22, 2013 at 4:20 PM, Xinliang David Li wrote: >> Hi, In this patch, loop alignment peeling and loop versioning >> trans

Re: wide-int branch now up for public comment and review

On Aug 28, 2013, at 3:22 AM, Richard Biener wrote: > Btw, rtl.h still wastes space with > > struct GTY((variable_size)) hwivec_def { > int num_elem; /* number of elements */ > HOST_WIDE_INT elem[1]; > }; > > struct GTY((chain_next ("RTX_NEXT (&%h)"), >chain_prev ("RTX_PREV

Re: wide-int branch now up for public comment and review

On Aug 28, 2013, at 5:48 AM, Richard Biener wrote: >> Only if the precision is > HOST_BITS_PER_WIDE_INT. If the precision >> is HOST_BITS_PER_WIDE_INT then both are { -1U }. > > That wasn't my understanding on how things work. You are thinking about prec==0 numbers. These are useful and import

Re: [PATCH 1/2] Convert symtab, cgraph and varpool nodes into a real class hierarchy

On Aug 28, 2013, at 2:34 AM, Richard Biener wrote: > Huh? Why should wide-int need to be marked GTY at all?! Can I answer with a question? Why would nb_iter_bound be GTYed? Why would dw_val_struct be GTYed? The first makes little sense to me. The second, well, it is used to generate debug

Re: wide-int branch now up for public comment and review

On Aug 28, 2013, at 1:41 PM, Kenneth Zadeck wrote: > On 08/28/2013 12:45 PM, Mike Stump wrote: >> >> tree t; >> wide_int w = t; >> >> wide_int_to_tree needs an additional type, so, the spelling is not as short >> out of necessity. > i made wide_int

gcc_update fix build error

. This is with svn: $ svn --version svn, version 1.8.1 (r1503906) which required an upgrade on the old repository. I checked this in. 2013-08-29 Mike Stump * gcc_update (configure): Update to handle svn 1.8.1. Index: contrib/gcc_update

Re: wide-int branch now up for public comment and review

On Aug 29, 2013, at 12:36 AM, Richard Biener wrote: > On Wed, 28 Aug 2013, Mike Stump wrote: > >> On Aug 28, 2013, at 3:22 AM, Richard Biener wrote: >>> Btw, rtl.h still wastes space with >>> >>> struct GTY((variable_size)) hwivec_def { >>

Re: Folding (a ? b : c) op d

On Aug 30, 2013, at 2:38 AM, Marc Glisse wrote: > There is no undoing here, it is just a recursion that gets very slow for > nested conditions: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55219 Gosh, such simple and small code. :-)

Re: [PATCH, c++ testsuite]: Improve g++.dg/abi/mangle33.C scan-asm pattern

it works without problems. > > OK for mainline? Ok. > BTW: There are a couple of similar problems with Tcl 8.6: > [1] http://sourceforge.net/p/tcl/bugs/5178/ :-( closed. I've amended the Tcl pointer with the bug pointer: 2013-08-30 Mike Stump * doc/install.texi (Prere

Re: [PATCH, libvtv] Fix most of the testsuite.

On Aug 30, 2013, at 2:55 PM, Caroline Tice wrote: > The attached patch fixes most of the libvtv testsuite tests to run in > the dejagnu test harness. > Since I am supposedly the libvtv maintainer, I am not sure how this > patch is supposed to be reviewed...Guidance would be appreciated… We prefe

Re: [PATCH, libvtv] Fix most of the testsuite.

[ sorry for the dup, if you see two. ] On Aug 30, 2013, at 2:55 PM, Caroline Tice wrote: > The attached patch fixes most of the libvtv testsuite tests to run in > the dejagnu test harness. > Since I am supposedly the libvtv maintainer, I am not sure how this > patch is supposed to be reviewed...

  1   2   3   4   5   6   7   8   9   10   >