Re: Usage of C11 Annex K Bounds-checking interfaces on GCC

On Mon, Dec 9, 2019 at 10:14 PM li zi wrote: > > Hi All, > We are using gcc in our projects and we found some of the C standard > functions (like memcpy, strcpy) used in gcc may induce security > vulnerablities like buffer overflow. Currently we have not found any > instances which causes such

Re: [PATCH] implement pre-c++20 contracts

On 12/10/19 12:58 AM, Jason Merrill wrote: On 11/13/19 2:07 PM, Jeff Chapman wrote: Attached is a patch that implements pre-c++20 contracts. This comes from a long running development branch which included ChangeLog entries as we went, which are included in the patch itself. The repo and

Usage of C11 Annex K Bounds-checking interfaces on GCC

Hi All, We are using gcc in our projects and we found some of the C standard functions (like memcpy, strcpy) used in gcc may induce security vulnerablities like buffer overflow. Currently we have not found any instances which causes such issues. But we feel better to change these calls to Cll

Re: [PATCH] implement pre-c++20 contracts

On 11/13/19 2:07 PM, Jeff Chapman wrote: Attached is a patch that implements pre-c++20 contracts. This comes from a long running development branch which included ChangeLog entries as we went, which are included in the patch itself. The repo and initial wiki are located here:

[PATCH] Fix unrecognizable insn of pr92865

Hi jakub: This patch is to enable integer mask cmp/cmov under AVX512F even with TARGET_XOP . Bootstrap and regression test on i386/x86_64 backend is ok. Changelog: PR target/92865 * gcc/config/i386/i386-expand.c (ix86_valid_mask_cmp_mode): Enable integer mask cmov when available

[Bug target/92865] [10 Regression] error: unrecognizable insn: in extract_insn, at recog.c:2294 since r279107

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92865 --- Comment #6 from Hongtao.liu --- The missing point of my patch is for 512-bit vector compare, integer mask vector compare still should be used even with target_xop, that's the root cause of this issue. Refer to this part. --- -

[Bug tree-optimization/92879] incorrect warning of __builtin_memset offset is out of the bounds on zero-size allocation and initialization

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92879 Andrew Pinski changed: What|Removed |Added Keywords||diagnostic Target|

[Bug c++/92879] New: incorrect warning of __builtin_memset offset is out of the bounds on zero-size allocation and initialization

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92879 Bug ID: 92879 Summary: incorrect warning of __builtin_memset offset is out of the bounds on zero-size allocation and initialization Product: gcc Version: 10.0 Status:

libbacktrace patch committed: Remove duplication of address handling

Before this patch libbacktrace duplicated the handling of DW_AT_low_pc, DW_AT_high_pc, and DW_AT_ranges, once to build a mapping from addresses to compilation units, and then again to build a mapping from addresses to functions within a compilation unit. This patch removes the duplication into a

[RFC] ipa-cp: Fix PGO regression caused by r278808

The performance of exchange2 built with PGO will decrease ~28% by r278808 due to profile count set incorrectly. The cloned nodes are updated to a very small count caused later pass cunroll fail to unroll the recursive function in exchange2, This patch enables adding orig_sum to the new nodes for

Usage of C11 Annex K Bounds-checking interfaces on GCC

Hi All, We are using gcc in our projects and we found some of the C standard functions (like memcpy, strcpy) used in gcc may induce security vulnerablities like buffer overflow. Currently we have not found any instances which causes such issues. But we feel better to change these calls to Cll

[Bug libfortran/90374] Fortran 2018: Support d0.d, e0.d, es0.d, en0.d, g0.d and ew.d e0 edit descriptors for output

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90374 --- Comment #11 from Jerry DeLisle --- (In reply to Thomas Henlich from comment #10) --- snip --- > > 13.7.2.3.3 E and D editing > ... If e is positive the exponent part contains e digits, otherwise it > contains the minimum number of digits

Re: [PATCH 03/49] diagnostic_show_locus: move initial newline to callers

On Sat, 2019-12-07 at 07:30 -0700, Jeff Law wrote: > On Fri, 2019-11-15 at 20:22 -0500, David Malcolm wrote: > > diagnostic_show_locus adds a newline before doing anything > > (including > > the do-nothing-else case). > > > > This patch removes this initial newline, adding it to all callers > >

[Bug testsuite/92398] [10 regression] error in update of gcc.target/powerpc/pr72804.c in r277872

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92398 Li Jia He changed: What|Removed |Added Status|NEW |RESOLVED CC|

Re: [PATCH 29/49] analyzer: new files: tristate.{cc|h}

On 11/15/19 6:23 PM, David Malcolm wrote: gcc/ChangeLog: * analyzer/tristate.cc: New file. * analyzer/tristate.h: New file. --- gcc/analyzer/tristate.cc | 222 +++ gcc/analyzer/tristate.h | 82 + 2 files changed,

Re: [PATCH 26/49] analyzer: new files: digraph.{cc|h} and shortest-paths.h

On 11/15/19 6:23 PM, David Malcolm wrote: This patch adds template classes for directed graphs, their nodes and edges, and for finding the shortest path through such a graph. Just a few mostly minor comments from me, in a similar vein as on some of the other patches. gcc/ChangeLog:

Re: [PATCH] add -Wmismatched-tags (PR 61339)

On 12/6/19 12:08 PM, Jason Merrill wrote: On 12/5/19 6:47 PM, Jakub Jelinek wrote: On Thu, Dec 05, 2019 at 04:33:10PM -0700, Martin Sebor wrote: It's hard to distinguish between this type and the previous one by name; this one should probably have "map" in its name. +static GTY (())

[Bug tree-optimization/92116] Potential null pointer dereference in 'gomp_acc_remove_pointer'

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92116 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug c/92875] GCC ignores the floating-point 'f' suffix in C11 mode

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92875 Vincent Lefèvre changed: What|Removed |Added CC||vincent-gcc at vinc17 dot net ---

Re: [PATCH 28/49] analyzer: new files: analyzer.{cc|h}

On Fri, 2019-12-06 at 22:38 -0500, Eric Gallager wrote: > On 11/15/19, David Malcolm wrote: [...] > > diff --git a/gcc/analyzer/analyzer.h b/gcc/analyzer/analyzer.h > > new file mode 100644 > > index 000..ace8924 > > --- /dev/null > > +++ b/gcc/analyzer/analyzer.h > > @@ -0,0 +1,126 @@ > >

[Bug c/92875] GCC ignores the floating-point 'f' suffix in C11 mode

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92875 --- Comment #7 from Vincent Lefèvre --- (In reply to jos...@codesourcery.com from comment #5) > Lack of direct float and double arithmetic requires FLT_EVAL_METHOD == 2 No, FLT_EVAL_METHOD could also be negative, in which case GCC would be

[Bug c/92875] GCC ignores the floating-point 'f' suffix in C11 mode

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92875 --- Comment #6 from anders at wahrzeichnen dot de --- (In reply to jos...@codesourcery.com from comment #3) > This is as specified in the C standard. I guess you are referring to the C18 section 6.3.1.8 (2) "The values of floating operands

[PR92116, PR92877] [OpenACC] Replace 'openacc.data_environ' by standard libgomp mechanics (was: [PATCH] OpenACC reference count overhaul)

Hi! \o/ Yay for the first split-out piece of the big "OpenACC reference count overhaul" going in: On 2019-10-29T12:15:01+, Julian Brown wrote: > On Mon, 21 Oct 2019 16:14:11 +0200 > Thomas Schwinge wrote: >> Remeber to look into "Potential null >> pointer

Re: [PATCH 17/49] Support for adding selftests via a plugin

On Sat, 2019-12-07 at 07:40 -0700, Jeff Law wrote: > On Fri, 2019-11-15 at 20:23 -0500, David Malcolm wrote: > > This patch provides a plugin callback for invoking selftests, so > > that > > a > > plugin can add tests to those run by -fself-test=DIR. The callback > > invocation uses

Re: [PATCH 29/49] analyzer: new files: tristate.{cc|h}

On Sat, 2019-12-07 at 08:03 -0700, Jeff Law wrote: > On Fri, 2019-11-15 at 20:23 -0500, David Malcolm wrote: > > gcc/ChangeLog: > > * analyzer/tristate.cc: New file. > > * analyzer/tristate.h: New file. > Nothing really concerning here. Seems like a generic facility we'd > like to be able

Re: [PATCH 26/49] analyzer: new files: digraph.{cc|h} and shortest-paths.h

On Sat, 2019-12-07 at 07:58 -0700, Jeff Law wrote: > On Fri, 2019-11-15 at 20:23 -0500, David Malcolm wrote: > > This patch adds template classes for directed graphs, their nodes > > and edges, and for finding the shortest path through such a graph. > > > > gcc/ChangeLog: > > *

Re: [PATCH 25/49] analyzer: new files: graphviz.{cc|h}

On Sat, 2019-12-07 at 07:54 -0700, Jeff Law wrote: > On Fri, 2019-11-15 at 20:23 -0500, David Malcolm wrote: > > This patch adds a simple wrapper class to make it easier to > > write human-readable .dot files. > > > > gcc/ChangeLog: > > * analyzer/graphviz.cc: New file. > > *

[Bug c/92875] GCC ignores the floating-point 'f' suffix in C11 mode

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92875 --- Comment #5 from joseph at codesourcery dot com --- Most architectures use FLT_EVAL_METHOD == 0. It's specific to x87 (and older m68k) that FLT_EVAL_METHOD == 2 because x87 doesn't support direct arithmetic on float or double. Lack of

[Bug c++/92878] Parenthesized aggregate initialization doesn't work in a new-expression

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92878 --- Comment #1 from Ville Voutilainen --- Wishlist item: please add a C++2a mode libstdc++ test that verifies that make_unique and make_shared work with aggregates. Bonus points for std::allocator_traits>::construct.

[Bug c++/92878] Parenthesized aggregate initialization doesn't work in a new-expression

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

[PR92503] [OpenACC] Don't silently 'acc_unmap_data' in 'acc_free'

Hi! See attached "[PR92503] [OpenACC] Don't silently 'acc_unmap_data' in 'acc_free'", committed to trunk in r279146. As mentioned in PR92503, further work can be done later on, incrementally, to avoid "expensive device-to-host-address lookup": possibly "we might actually keep such

Re: [PATCH] Fix multibyte-related issues in pretty-print.c (PR 91843)

On Mon, Dec 9, 2019 at 4:58 PM David Malcolm wrote: > > On Thu, 2019-10-10 at 16:27 -0400, Lewis Hyatt wrote: > > Hello- > > > > This short patch addresses > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91843 > > by adding the needed multibyte awareness to pretty-print.c. > > Together with my

Re: [PATCH] Multibyte awareness for diagnostics (PR 49973)

On Mon, Dec 09, 2019 at 03:12:31PM -0500, David Malcolm wrote: > On Fri, 2019-12-06 at 15:31 -0500, Lewis Hyatt wrote: > > On Fri, Dec 06, 2019 at 10:54:30AM -0500, David Malcolm wrote: > > [...] > > > > The patch is OK for trunk with the nits above fixed. Do you have > > > commit access?

Re: Questions about IPA/clones and new LTO pass

Hello, this is an update on the LTO pass we've been working on. The optimization is called ipa-initcall-cp because it propagates constant values written to variables with static lifetimes (such as ones initialized in initialization functions). This patch can be applied to: commit

[Bug target/92841] Optimize -fstack-protector-strong code generation a bit

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92841 --- Comment #5 from Boris --- Hohumm, looks good - this is the same site it generated with your patch: # arch/x86/kernel/cpu/scattered.c:48: { movq%gs:40, %rax# MEM[( long unsigned int *)40B], prephitmp_18 movq%rax,

[PR92840] [OpenACC] Refuse 'acc_unmap_data' unless mapped by 'acc_map_data'

Hi! See attached "[PR92840] [OpenACC] Refuse 'acc_unmap_data' unless mapped by 'acc_map_data'", committed to trunk in r279145. As mentioned in the patch, some further checking can be applied, later, incrementally. Grüße Thomas From bea573cb7ea13cece9c51ca9eb1cc9c34005dedf Mon Sep 17

[Bug c++/92878] New: Parenthesized aggregate initialization doesn't work in a new-expression

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92878 Bug ID: 92878 Summary: Parenthesized aggregate initialization doesn't work in a new-expression Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal

[Bug libgomp/92877] [OpenACC] Failure to resolve back via 'acc_hostptr' an 'acc_deviceptr' retrieved for a structured mapping

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92877 --- Comment #1 from Thomas Schwinge --- Author: tschwinge Date: Mon Dec 9 22:52:56 2019 New Revision: 279147 URL: https://gcc.gnu.org/viewcvs?rev=279147=gcc=rev Log: [PR92116, PR92877] [OpenACC] Replace 'openacc.data_environ' by standard

[Bug tree-optimization/92116] Potential null pointer dereference in 'gomp_acc_remove_pointer'

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92116 --- Comment #3 from Thomas Schwinge --- Author: tschwinge Date: Mon Dec 9 22:52:56 2019 New Revision: 279147 URL: https://gcc.gnu.org/viewcvs?rev=279147=gcc=rev Log: [PR92116, PR92877] [OpenACC] Replace 'openacc.data_environ' by standard

[Bug libgomp/92503] [OpenACC] Behavior of 'acc_free' if the memory space is still used in a mapping

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92503 --- Comment #4 from Thomas Schwinge --- Author: tschwinge Date: Mon Dec 9 22:52:47 2019 New Revision: 279146 URL: https://gcc.gnu.org/viewcvs?rev=279146=gcc=rev Log: [PR92503] [OpenACC] Don't silently 'acc_unmap_data' in 'acc_free'

[Bug libgomp/92840] [OpenACC] Disallow 'acc_unmap_data' for everything other than 'acc_map_data'

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92840 --- Comment #3 from Thomas Schwinge --- Author: tschwinge Date: Mon Dec 9 22:52:36 2019 New Revision: 279145 URL: https://gcc.gnu.org/viewcvs?rev=279145=gcc=rev Log: [PR92840] [OpenACC] Refuse 'acc_unmap_data' unless mapped by 'acc_map_data'

[Bug lto/83967] LTO removes C functions declared as weak in assembler(depending on files order in linking)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83967 eitan at mosenkis dot net changed: What|Removed |Added CC||eitan at mosenkis dot net

[Bug c/92875] GCC ignores the floating-point 'f' suffix in C11 mode

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92875 --- Comment #4 from anders at wahrzeichnen dot de --- I don't know about other archs, but on amd64, GCC emits comiss insns (SSE2 single-precision scalar compare) for f0, f1, and f2 and comisd insns (SSE2 double-precision scalar compare) for f3.

[Bug target/92807] gcc generate extra move for the snippet code along with lea instruction.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92807 --- Comment #5 from Sunil Pandey --- Patch link: https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00450.html

[Bug c/92875] GCC ignores the floating-point 'f' suffix in C11 mode

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92875 --- Comment #3 from joseph at codesourcery dot com --- The value of FLT_EVAL_METHOD applies to constants as well as to operations. That is, when FLT_EVAL_METHOD == 2, 0.1f has the precision of long double but the semantic type of float, and

[Bug c/92875] GCC ignores the floating-point 'f' suffix in C11 mode

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92875 --- Comment #2 from anders at wahrzeichnen dot de --- No, -ffloat-store does not help. And this has little if anything to do with 323, imho. The asm generated for f3 is instructive: There, GCC wants to load a double constant 0x3fba

[Bug rtl-optimization/92796] [10 Regression] ICE in lra_assign, at lra-assigns.c:1646 on powerpc64le-linux-gnu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92796 --- Comment #10 from Vladimir Makarov --- (In reply to Vladimir Makarov from comment #7) > > > I'm guessing this was never a problem before I added the code to not add > conflicts for copies. Before then, any two pseudos/registers that were

[Bug ipa/92538] Proposal for IPA init() constant propagation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92538 Erick Ochoa changed: What|Removed |Added Attachment #47278|0 |1 is obsolete|

[Bug fortran/92863] ICE in gfc_typename

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92863 --- Comment #2 from Thomas Koenig --- This looks reasonable: Index: misc.c === --- misc.c (Revision 279064) +++ misc.c (Arbeitskopie) @@ -164,9 +164,17 @@ gfc_typename

[Bug rtl-optimization/92796] [10 Regression] ICE in lra_assign, at lra-assigns.c:1646 on powerpc64le-linux-gnu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92796 --- Comment #9 from Peter Bergner --- (In reply to Vladimir Makarov from comment #7) > A very interesting case, Peter. I reproduced the case too. I can take it > from here if you don't mind. The solution I see for this problem is to > check

Re: Proposal for the transition timetable for the move to GIT

Bernd Schmidt : > On 12/9/19 7:19 PM, Joseph Myers wrote: > > > > For any conversion we're clearly going to need to run various validation > > (comparing properties of the converted repository, such as contents at > > branch tips, with expected values of those properties based on the SVN > >

[Bug target/52451] gcc w/i387 float generates fucom rather than fcom for floating point comparsons

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52451 --- Comment #13 from joseph at codesourcery dot com --- On Fri, 6 Dec 2019, vgupta at synopsys dot com wrote: > However I'm curious that the test uses qNaN. What is the expected behavior for > sNaN. If you tweak the testcase slightly as

Re: [PATCH] Fix multibyte-related issues in pretty-print.c (PR 91843)

On Thu, 2019-10-10 at 16:27 -0400, Lewis Hyatt wrote: > Hello- > > This short patch addresses > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91843 > by adding the needed multibyte awareness to pretty-print.c. > Together with my other patch awaiting review >

[Bug tree-optimization/92116] Potential null pointer dereference in 'gomp_acc_remove_pointer'

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92116 Thomas Schwinge changed: What|Removed |Added Keywords|openacc | Component|libgomp

[PING][PATCH v3] Add `--with-toolexeclibdir=' configuration option

On Mon, 2 Dec 2019, Maciej W. Rozycki wrote: > Provide means, in the form of a `--with-toolexeclibdir=' configuration > option, to override the default installation directory for target > libraries, otherwise known as $toolexeclibdir. This is so that it is > possible to get newly-built

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

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 used in GCC compilation. > Consequently there in no

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

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 all test cases fail the execution > stage, giving output

[Bug rtl-optimization/92796] [10 Regression] ICE in lra_assign, at lra-assigns.c:1646 on powerpc64le-linux-gnu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92796 --- Comment #8 from Vladimir Makarov --- (In reply to Vladimir Makarov from comment #7) > A very interesting case, Peter. I reproduced the case too. I can take it > from here if you don't mind. The solution I see for this problem is to >

Re: [PATCH][Hashtable 0/6] Code review

This patch also require an update of the printers.py file. Here is an updated version. François On 11/17/19 9:42 PM, François Dumont wrote: This is the begining of a patch series for _Hashtable Initial patch to clarify code. I was tired to see true/false or true_type/false_type without

[Bug rtl-optimization/92796] [10 Regression] ICE in lra_assign, at lra-assigns.c:1646 on powerpc64le-linux-gnu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92796 --- Comment #7 from Vladimir Makarov --- (In reply to Peter Bergner from comment #6) > > Vlad (or Jeff), can you point me to where this is supposed to be handled? > I don't think I see where LRA verifies the reg_renumber[regno] values are >

[Bug middle-end/92761] hash_table::expand invokes assignment on invalid objects

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92761 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug bootstrap/92762] hash_table::empty_slow invokes assignment on invalid objects

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92762 --- Comment #4 from Martin Sebor --- Author: msebor Date: Mon Dec 9 20:54:11 2019 New Revision: 279139 URL: https://gcc.gnu.org/viewcvs?rev=279139=gcc=rev Log: PR middle-end/92761 - hash_table::expand invokes assignment on invalid objects PR

[Bug middle-end/92761] hash_table::expand invokes assignment on invalid objects

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92761 --- Comment #11 from Martin Sebor --- Author: msebor Date: Mon Dec 9 20:54:11 2019 New Revision: 279139 URL: https://gcc.gnu.org/viewcvs?rev=279139=gcc=rev Log: PR middle-end/92761 - hash_table::expand invokes assignment on invalid objects PR

Re: Proposal for the transition timetable for the move to GIT

On Mon, 9 Dec 2019, Bernd Schmidt wrote: > On 12/9/19 7:19 PM, Joseph Myers wrote: > > > > For any conversion we're clearly going to need to run various validation > > (comparing properties of the converted repository, such as contents at > > branch tips, with expected values of those properties

[Bug libgomp/92877] [OpenACC] Failure to resolve back via 'acc_hostptr' an 'acc_deviceptr' retrieved for a structured mapping

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92877 Thomas Schwinge changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed|

[Bug libgomp/92503] [OpenACC] Behavior of 'acc_free' if the memory space is still used in a mapping

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92503 Thomas Schwinge changed: What|Removed |Added Keywords||patch Status|UNCONFIRMED

[Bug preprocessor/49973] Column numbers count multibyte characters as multiple columns

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49973 --- Comment #21 from David Malcolm --- (In reply to David Malcolm from comment #20) > I've committed r279137 on Lewis's behalf, which fixes the issues identified > in patch #13. comment #13, I meant to say

[Bug libgomp/92877] New: [OpenACC] Failure to resolve back via 'acc_hostptr' an 'acc_deviceptr' retrieved for a structured mapping

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92877 Bug ID: 92877 Summary: [OpenACC] Failure to resolve back via 'acc_hostptr' an 'acc_deviceptr' retrieved for a structured mapping Product: gcc Version: unknown Status:

[Bug other/92871] new test case g++.dg/ext/temp-extend1.C fails starting with its introduction in r279069

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92871 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug preprocessor/49973] Column numbers count multibyte characters as multiple columns

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49973 --- Comment #20 from David Malcolm --- I've committed r279137 on Lewis's behalf, which fixes the issues identified in patch #13. As noted in review of the patch, we didn't attempt to change the behavior of diagnostic_get_location_text with this

Re: [PATCH] rs6000: Fix 2 for PR92661, Do not define builtins that overload disabled builtins

On 12/6/19 5:12 PM, Segher Boessenkool wrote: > On Thu, Dec 05, 2019 at 08:44:57AM +, Iain Sandoe wrote: >> .. or I can just force a false return from effective_target_dfp as we >> do for other cases where assembler support does not imply system >> support. > > That's what I would do, yes.

Re: [PATCH] Multibyte awareness for diagnostics (PR 49973)

On Fri, 2019-12-06 at 15:31 -0500, Lewis Hyatt wrote: > On Fri, Dec 06, 2019 at 10:54:30AM -0500, David Malcolm wrote: [...] > > The patch is OK for trunk with the nits above fixed. Do you have > > commit access? (I've got my own patch [1] that touches diagnostic- > > show-locus.c which I'll

[Bug preprocessor/49973] Column numbers count multibyte characters as multiple columns

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49973 --- Comment #19 from David Malcolm --- Author: dmalcolm Date: Mon Dec 9 20:03:47 2019 New Revision: 279137 URL: https://gcc.gnu.org/viewcvs?rev=279137=gcc=rev Log: Byte vs column awareness for diagnostic-show-locus.c (PR 49973)

[Bug c/92857] -Wsign-conversion flag issues false positives for expression using typedef'ed unsigned types

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92857 Joshua Saxby changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug c/92875] GCC ignores the floating-point 'f' suffix in C11 mode

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92875 Andrew Pinski changed: What|Removed |Added Target||i?86-linux-gnu Depends on|

[Bug fortran/92876] New: ICE in expand_UNIQUE, at internal-fn.c:2599

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92876 Bug ID: 92876 Summary: ICE in expand_UNIQUE, at internal-fn.c:2599 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

[Bug c/92875] New: GCC ignores the floating-point 'f' suffix in C11 mode

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92875 Bug ID: 92875 Summary: GCC ignores the floating-point 'f' suffix in C11 mode Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3

[Bug fortran/92874] New: ICE in gfc_dep_compare_expr, at fortran/dependency.c:36

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92874 Bug ID: 92874 Summary: ICE in gfc_dep_compare_expr, at fortran/dependency.c:36 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal

[Bug fortran/92873] New: ICE in unmodified_parm_or_parm_agg_item, at ipa-fnsummary.c:1166

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92873 Bug ID: 92873 Summary: ICE in unmodified_parm_or_parm_agg_item, at ipa-fnsummary.c:1166 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal

[Bug fortran/92872] New: [10 Regression] ICE in build_fold_indirect_ref_loc, at fold-const.c:14842

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92872 Bug ID: 92872 Summary: [10 Regression] ICE in build_fold_indirect_ref_loc, at fold-const.c:14842 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity:

[Bug fortran/88624] [Coarray] Rejects allocatable coarray passed as a dummy argument

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88624 G. Steinmetz changed: What|Removed |Added CC||gs...@t-online.de --- Comment #2 from G.

Re: Proposal for the transition timetable for the move to GIT

Joseph Myers : > I think we should fix whatever the remaining relevant bugs are in > reposurgeon and do the conversion with reposurgeon being used to read and > convert the SVN history and do any desired surgical operations on it. On behalf of the reposurgeon crew - Julien Rivaud, Daniel

Re: [C++ Patch] Improve build_*_cast locations

On 12/9/19 7:06 AM, Paolo Carlini wrote: Hi, On 08/12/19 18:51, Jason Merrill wrote: Hmm, is the change to cp_expr really necessary vs. using protected_set_expr_location? Yes, using protected_set_expr_location works fine in this case, I suppose because we are dealing with expressions anyway

Re: Status of C++11 support

>From the earlier email thread, I think the plan is to switch to C++11 for GCC 11. Jason On Mon, Dec 9, 2019 at 1:43 PM Nicholas Krause wrote: > > > On 12/9/19 1:31 PM, Paul Smith wrote: > > On Mon, 2019-12-09 at 18:09 +, Andrew Haley wrote: > >> On 12/9/19 5:03 PM, Nicholas Krause wrote:

[Bug libgomp/92854] [OpenACC] Always-true conditional in 'libgomp/oacc-mem.c:acc_unmap_data'?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92854 --- Comment #6 from jules at gcc dot gnu.org --- Created attachment 47453 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47453=edit Patch for acc_map_data-device_already-3.c problem This patch fixes the acc_map_data-device_already-3.c

[PATCH] PR 92846: [ARC] generate signaling FDCMPF for hard float comparisons

ARC gcc generates FDCMP instructions which raises Invalid operation for signaling NaN only. This causes glibc iseqsig() primitives to fail (in the current ongoing glibc port to ARC) So split up the hard float compares into two categories and for unordered compares generate the FDCMPF instruction

[Bug target/92841] Optimize -fstack-protector-strong code generation a bit

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92841 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned

Re: [PING^3] Re: [PATCH 1/2] Add a pass to automatically add ptwrite instrumentation

Andi Kleen writes: Ping! > Andi Kleen writes: > > Ping! > >> Andi Kleen writes: >> >> Ping! >> >>> From: Andi Kleen >>> >>> [v4: Rebased on current tree. Avoid some redundant log statements >>> for locals and a few other fixes. Fix some comments. Improve >>> documentation. Did some studies

Re: Proposal for the transition timetable for the move to GIT

On 12/9/19 7:19 PM, Joseph Myers wrote: For any conversion we're clearly going to need to run various validation (comparing properties of the converted repository, such as contents at branch tips, with expected values of those properties based on the SVN repository) and fix issues shown up by

Re: Status of C++11 support

On 12/9/19 1:31 PM, Paul Smith wrote: On Mon, 2019-12-09 at 18:09 +, Andrew Haley wrote: On 12/9/19 5:03 PM, Nicholas Krause wrote: https://gcc.gnu.org/projects/cxx-status.html#cxx11 I'm asking of what support exists in the gcc codebase itself not for other projects using gcc. That is

Re: Status of C++11 support

On 12/9/19 1:09 PM, Andrew Haley wrote: On 12/9/19 5:03 PM, Nicholas Krause wrote: https://gcc.gnu.org/projects/cxx-status.html#cxx11 I'm asking of what support exists in the gcc codebase itself not for other projects using gcc. That is what you got. No its not  as its just talking

Re: Status of C++11 support

On Mon, 2019-12-09 at 18:09 +, Andrew Haley wrote: > On 12/9/19 5:03 PM, Nicholas Krause wrote: > > > https://gcc.gnu.org/projects/cxx-status.html#cxx11 > > > > I'm asking of what support exists in the gcc codebase itself not > > for other projects using gcc. > > That is what you got. IIUC

[Bug other/92871] New: new test case g++.dg/ext/temp-extend1.C fails starting with its introduction in r279069

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92871 Bug ID: 92871 Summary: new test case g++.dg/ext/temp-extend1.C fails starting with its introduction in r279069 Product: gcc Version: 10.0 Status: UNCONFIRMED

[Bug other/92870] New: new test case gcc.dg/vect/vect-shift-5.c fails starting with its introduction in r279114

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92870 Bug ID: 92870 Summary: new test case gcc.dg/vect/vect-shift-5.c fails starting with its introduction in r279114 Product: gcc Version: 10.0 Status: UNCONFIRMED

[Bug c++/92869] g++ wrongly reports aggregate type as not-aggregate (when explicitly defaulted ctors are added)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92869 Andrew Pinski changed: What|Removed |Added Keywords||wrong-code --- Comment #1 from Andrew

Re: Proposal for the transition timetable for the move to GIT

On Fri, 6 Dec 2019, Eric S. Raymond wrote: > Reposurgeon has been used for several major conversions, including groff > and Emacs. I don't mean to be nasty to Maxim, but I have not yet seen > *anybody* who thought they could get the job done with ad-hoc scripts > turn out to be correct.

[Bug go/92861] Passes relative time to sem_timedwait on GNU/Hurd

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92861 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug c++/92869] New: g++ wrongly reports aggregate type as not-aggregate (when explicitly defaulted ctors are added)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92869 Bug ID: 92869 Summary: g++ wrongly reports aggregate type as not-aggregate (when explicitly defaulted ctors are added) Product: gcc Version: 10.0 Status: UNCONFIRMED

Re: Status of C++11 support

On 12/9/19 5:03 PM, Nicholas Krause wrote: >> https://gcc.gnu.org/projects/cxx-status.html#cxx11 > I'm asking of what support exists in the gcc codebase itself not for other > projects using gcc. That is what you got. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd.

[Bug go/92861] Passes relative time to sem_timedwait on GNU/Hurd

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92861 --- Comment #6 from ian at gcc dot gnu.org --- Author: ian Date: Mon Dec 9 18:03:53 2019 New Revision: 279136 URL: https://gcc.gnu.org/viewcvs?rev=279136=gcc=rev Log: PR go/92861 runtime: don't define CLOCK_REALTIME in os_hurd.go

  1   2   3   >