https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93004
Bug ID: 93004
Summary: Suspicious code in tree-ssa-loop-ivopts.c
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
> On 16 Dec 2019, at 14:54, Richard Sandiford wrote:
>> We have local patches adding
>>
>> dg-require-effective-target fpic
>>
>> directives to these.
>>
>> Is that the correct thing to do ?
>
> Yeah. Adding that to tests that use -fpic or -fPIC is OK/preapproved.
>
> Personally, I
on 2019/12/19 上午12:49, visda.vokhsho...@microchip.com wrote:
> Hello,
>
> In GCC documentation, 3.1 Options that Control Optimization: it is indicated
> -Os disables alignment of functions, jumps, labels, and loops. However, with
> -v -Q passed to the compile step, I see all these options
Hello world,
the attached patch fixes an ICE on valid for INDEX (see test case).
The problem was that the KIND argument was still present during
scalarization, which caused the ICE.
The fix is to remove the KIND argument, and the best place
to do this is in resolution. I did try to do this in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93000
--- Comment #2 from Andrew Pinski ---
This seems like a GDB bug which should be reported there:
http://sourceware.org/bugzilla .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93003
kargl at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93003
Bug ID: 93003
Summary: internal compiler error: Segmentation fault
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
I've updated the gccgo branch to revision 279561 of trunk.
Ian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93002
Andrew Pinski changed:
What|Removed |Added
Target||x86_64-linux-gnu
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92794
--- Comment #7 from fxue at gcc dot gnu.org ---
I tested it locally, passed. You can have a try to confirm that.
On Wed, Dec 18, 2019 at 1:17 PM Joseph Myers
wrote:
> On Wed, 18 Dec 2019, Jason Merrill wrote:
>
> > On Tue, Dec 17, 2019 at 4:39 PM Joseph Myers
> > wrote:
> >
> > > Points for consideration:
> > >
> > > 1. Do we want some kind of rearrangement of refs as in the 1b
> > > repository or not?
>
Joseph Myers :
> On Wed, 18 Dec 2019, Eric S. Raymond wrote:
>
> > And that, ladies and gentlemen, is why reposurgeon has to be as
> > large and complex as it is.
>
> And, in the end, it *is* complex software on which you build simple
> scripts. gcc.lift is a simple script, written in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93002
Bug ID: 93002
Summary: while(i--) optimization
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee:
On Wed, 18 Dec 2019, Eric S. Raymond wrote:
> And that, ladies and gentlemen, is why reposurgeon has to be as
> large and complex as it is.
And, in the end, it *is* complex software on which you build simple
scripts. gcc.lift is a simple script, written in the domain-specific
reposurgeon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92794
--- Comment #6 from Arseny Solokha ---
Can this PR be fixed now?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93001
--- Comment #1 from Marek Polacek ---
I think the problem is in dfs_accessible_post:
757 tree scope = current_nonlambda_scope ();
will for this line:
enum class S::E : S::T { X };
give "::" so dfs_accessible_post returns NULL_TREE. But if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93001
Bug ID: 93001
Summary: bogus is private within this context error with scoped
enum
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92794
--- Comment #5 from fxue at gcc dot gnu.org ---
Author: fxue
Date: Thu Dec 19 02:54:40 2019
New Revision: 279561
URL: https://gcc.gnu.org/viewcvs?rev=279561=gcc=rev
Log:
Handle aggregate pass-through for self-recursive call (PR ipa/92794)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92980
--- Comment #5 from Hongtao.liu ---
(In reply to Andrew Pinski from comment #4)
> But that is not true any more. So I think this optimization can be removed
> as it is too early. Just double check the above testcase and the C++
> testcase
>> +static bool
>> +self_recursive_agg_pass_through_p (cgraph_edge *cs, ipa_agg_jf_item *jfunc,
>> +int i)
>> +{
>> + if (cs->caller == cs->callee->function_symbol ()
> I don't know if self-recursive calls can be interposed at all, if yes
> you need to add the
[New thread]
Segher Boessenkool :
> > And the "simple scripts" argument dismisses the fact that those scripts
> > are built on top of complex software. It just doesn't hold water IMHO.
>
> This is the Unix philosophy though!
I'm now finishing a book in which I have a lot to say about this,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93000
--- Comment #1 from Yibiao Yang ---
the compilation command is as follows:
$ gcc -w -g -O0 small.c -o small.obj
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93000
Bug ID: 93000
Summary: [gdb] gdb failed to break on an executed address
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
On Sat, 2019-12-07 at 07:45 -0700, Jeff Law wrote:
> On Fri, 2019-11-15 at 20:22 -0500, David Malcolm wrote:
> > This patch adds support for associating a "diagnostic_path" with a
> > diagnostic: a sequence of events predicted by the compiler that
> > leads
> > to
> > the problem occurring, with
On 2019/12/18 23:48, Jan Hubicka wrote:
>> The size_info of ipa_size_summary are created by r277424. It should be
>> duplicated for cloned nodes, otherwise self_size and
>> estimated_self_stack_size
>> would be 0, causing param large-function-insns and large-function-growth
>> working
>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92999
Bug ID: 92999
Summary: [armhf] struct with adjacent __fp16's copies wrongly
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
On Thu, 19 Dec 2019, Bernd Schmidt wrote:
> On 12/18/19 10:55 PM, Joseph Myers wrote:
> > git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-3a.git
>
> I cloned this one and started trying random things again.
> The previous one had some strange-looking merge commits, but it sounded like
> that
Joseph Myers :
> Nor do I think reposurgeon (or at least the SVN reader, which is the main
> part engaged here) is significantly more complicated than implied by the
> task it's performing of translating between the different conceptual
> models of SVN and git. I've found it straightforward to
Jeff Law :
> But it's not that freshly constructed, at least not in my mind. All
> the experience ESR has from the python implementation carries to the Go
> implementation.
Not only do you have reposurgeon, you have me. I wish this mattered
less than it does.
I have *far* more experience doing
On 12/18/19 10:55 PM, Joseph Myers wrote:
git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-3a.git
I cloned this one and started trying random things again.
The previous one had some strange-looking merge commits, but it sounded
like that was a known issue, and indeed the ones I had seen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91165
--- Comment #10 from Jason Merrill ---
Author: jason
Date: Thu Dec 19 00:10:47 2019
New Revision: 279557
URL: https://gcc.gnu.org/viewcvs?rev=279557=gcc=rev
Log:
PR c++/91165 follow-on tweak
I talked in the PR about possibly stripping
I talked in the PR about possibly stripping the location from the args in
the hash table, since if we use the cache the locations would be wrong, but
didn't actually do anything about that. Then I noticed that there's already
unshare_expr_without_location...
Tested x86_64-pc-linux-gnu, applying
This patch adds support for associating a diagnostic message with an
optional diagnostic_metadata object, so that plugins can add extra data
to their diagnostics (e.g. mapping a diagnostic to a taxonomy or coding
standard such as from CERT or MISRA).
Currently this only supports associating a CWE
On Wed, 18 Dec 2019, Joseph Myers wrote:
> On Mon, 18 Nov 2019, Richard Earnshaw (lists) wrote:
>
> > I've attached a sample from the start of the fixed list - the full list is
> > far
> > too big to post to give a flavour of how the script currently works. Note
> > that annotations of the
Hi!
convert_arg_to_ellipsis used to call decay_conversion for all types
(which calls mark_rvalue_use), but it doesn't anymore in GCC 10,
and while for INTEGRAL_OR_ENUMERATION_TYPE_P args it calls
cp_perform_integral_promotions which does that too and for aggregate
args keeps calling
On Mon, 18 Nov 2019, Richard Earnshaw (lists) wrote:
> I've attached a sample from the start of the fixed list - the full list is far
> too big to post to give a flavour of how the script currently works. Note
> that annotations of the form [checkme: ] in the summary are for diagnostic
>
Hi!
While looking at PR92666, I've spotted a wrong-code issue where we ignore
any side-effects on arguments passed to ellipsis if they have
decltype(nullptr) type.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk and release branches?
2019-12-19 Jakub Jelinek
Hi!
Similarly to EXEC_OMP_WORKSHARE, EXEC_OMP_ATOMIC has also very tight rules
what can and can't appear in the block, enforced through parsing and
resolving, so e.g. inserting EXEC_BLOCK there leads to ICEs. In theory, one
could add such a BLOCK around the atomic rather than inside of it, but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92977
--- Comment #4 from Jakub Jelinek ---
Author: jakub
Date: Wed Dec 18 23:33:54 2019
New Revision: 279554
URL: https://gcc.gnu.org/viewcvs?rev=279554=gcc=rev
Log:
PR fortran/92977
* frontend-passes.c (in_omp_atomic): New variable.
Hi!
As mentioned in the PR, I believe we should use long double float suffixes
in the test testing long double and Q suffixes in the test that tests
__float128, both because PowerPC doesn't allow mixing them and because only
the latter test is guarded on float128 support.
Bootstrapped/regtested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86416
--- Comment #13 from Jakub Jelinek ---
Author: jakub
Date: Wed Dec 18 23:27:28 2019
New Revision: 279552
URL: https://gcc.gnu.org/viewcvs?rev=279552=gcc=rev
Log:
PR middle-end/86416
* testsuite/libgomp.c/pr86416-1.c (main): Use
On 12/18/19 7:04 AM, Julian Brown wrote:
This part contains the Fortran front-end support for parsing the new
attach and detach clauses, as well as derived-type members on other
data-movement clauses (copyin, copyout, etc.).
I browsed the patch and it looks mostly fine to me. However, I do have
In the patch:
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01201.html
Segher Boessenkool asked me to submit a patch to rename the macros used to see
if a number is a valid signed 16 or 34-bit value:
> Please follow up with a patch to not call random numbers "OFFSET".
This patch does this,
On Tue, 17 Dec 2019, Joseph Myers wrote:
> I've made test conversions of the GCC repository with reposurgeon
> available (gcc.gnu.org / sourceware.org account required to access
> these git+ssh repositories, it doesn't need to be one in the gcc group
> or to have shell access). More information
On Tue, Dec 17, 2019 at 12:02:46PM -0600, Segher Boessenkool wrote:
> > ;; Variable V2DI/V2DF extract
> > (define_insn_and_split "vsx_extract__var"
> > - [(set (match_operand: 0 "gpc_reg_operand" "=v,wa,r")
> > - (unspec: [(match_operand:VSX_D 1 "input_operand" "v,m,m")
> > -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86416
--- Comment #12 from Thomas Schwinge ---
(In reply to Jakub Jelinek from comment #11)
> because e.g. for x86_64-intelmicemul-linux-gnu offloading the error will not
> be emitted. If nvptx or gcn offloading is configured, it will be, for hsa
>
Hi Tobias!
On 2019-12-18T13:36:29+0100, Tobias Burnus wrote:
> libgomp/target.c's gomp_map_vars_internal: it now uses the normal code
> path in the upper loop, except that one directly bails out when the
> 'key' has not been found (skipping the adjacent MAP_POINTER as well).
> The 'case' in
On Wed, 2019-12-18 at 13:50 -0600, Segher Boessenkool wrote:
> On Wed, Dec 18, 2019 at 11:07:11AM -0700, Jeff Law wrote:
> > > That isn't what I said. I said that freshly constructed complex software
> > > will have more and deeper errors than stupid simple scripts do (or I
> > > implied that at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86416
--- Comment #11 from Jakub Jelinek ---
Indeed, the q and L suffixes are swapped, I believe Tobias meant:
--- libgomp/testsuite/libgomp.c/pr86416-1.c.jj 2019-12-18 21:25:02.856131826
+0100
+++ libgomp/testsuite/libgomp.c/pr86416-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92987
--- Comment #3 from joseph at codesourcery dot com ---
On Wed, 18 Dec 2019, lhyatt at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92987
>
> --- Comment #2 from Lewis Hyatt ---
> (In reply to jos...@codesourcery.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92998
--- Comment #1 from Andrew Pinski ---
gcc.target/aarch64/torture/simd-abi-8.c fails simular but due to arm_neon.h
instead.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92998
Bug ID: 92998
Summary: aarch64/sve/acle/general/dupq_1.c fails on big-endian
linux
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92919
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86416
Thomas Schwinge changed:
What|Removed |Added
Status|RESOLVED|REOPENED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92568
Bug 92568 depends on bug 86416, which changed state.
Bug 86416 Summary: [OpenMP] Offloading - better lto1 error message if mode not
supported on offloading target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86416
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92987
--- Comment #2 from Lewis Hyatt ---
(In reply to jos...@codesourcery.com from comment #1)
> I think -finput-charset may only be usable for character sets that are
> valid locale character sets (we don't implement the POSIX rule of
>
On Wed, Dec 18, 2019 at 11:07:11AM -0700, Jeff Law wrote:
> > That isn't what I said. I said that freshly constructed complex software
> > will have more and deeper errors than stupid simple scripts do (or I
> > implied that at least, maybe it wasn't clear). And I only say this
> > because the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92996
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92996
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92996
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92952
Martin Sebor changed:
What|Removed |Added
CC||seurer at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92958
Martin Sebor changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
On Wed, Dec 18, 2019 at 08:47:31AM +, Mark Eggleston wrote:
>
> It is a bit confusing that the Fortran FE source files have the .c
> extension implying C when they are C++ and are compiled using C++.
It is not puzzling at all. gfortran was added to GCC some 15
years ago. gfortran was
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92905
--- Comment #5 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #3)
> Note, it isn't about , using rm in the first alternative of the
> reverted define_insn works well too, as well as swapping the alternatives
> (that is in that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92958
--- Comment #3 from seurer at gcc dot gnu.org ---
I don't see the failure in my most current test run
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92997
Bug ID: 92997
Summary: [10 regression] gcc.dg/torture/ftrapv-1.c fails
starting with r279523
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92661
--- Comment #14 from Peter Bergner ---
Author: bergner
Date: Wed Dec 18 18:46:05 2019
New Revision: 279542
URL: https://gcc.gnu.org/viewcvs?rev=279542=gcc=rev
Log:
Fix POWER dfp test case target tests.
PR bootstrap/92661
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92996
Bug ID: 92996
Summary: ICE in gfc_conv_array_constructor_expr, at
fortran/trans-expr.c:7590
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
e guarded by the ‘if’
7 | g ("\n"); // warns
| ^
$ /opt/gcc/bin/gcc --version
gcc (GCC) 10.0.0 20191218 (experimental)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92994
G. Steinmetz changed:
What|Removed |Added
Keywords||ice-on-invalid-code
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92994
Bug ID: 92994
Summary: [10 Regression] ICE in gfc_get_class_from_expr, at
fortran/trans-expr.c:486
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87908
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92692
--- Comment #8 from Andrew Pinski ---
(In reply to Jakub Jelinek from comment #7)
> So, are you going to post a patch for that?
I dont have time to work on it right now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92993
Bug ID: 92993
Summary: ICE in maybe_canonicalize_comparison_1, at
fold-const.c:8845
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
On 2019-12-18 6:02 a.m., Richard Biener wrote:
> On December 17, 2019 8:31:00 PM GMT+01:00, Erick Ochoa
> wrote:
>> Hi,
>>
>> I'm interested in printing VAR_DECL trees that are of type
>> RECORD_TYPE. I am using the function print_generic_decl
>> for debugging and found this interesting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92692
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #7
The SVE port needs to maintain a different type identity for
GNU vectors and "SVE vectors" even during LTO, since the types
use different ABIs. The easiest way of doing that seemed to be
to use type attributes. However, these type attributes shouldn't
be user-facing; they're just a convenient
On Wed, 18 Dec 2019, Jeff Law wrote:
> > That isn't what I said. I said that freshly constructed complex software
> > will have more and deeper errors than stupid simple scripts do (or I
> > implied that at least, maybe it wasn't clear). And I only say this
> > because the opposite was claimed,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92958
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
On Wed, 18 Dec 2019, Jason Merrill wrote:
> On Tue, Dec 17, 2019 at 4:39 PM Joseph Myers
> wrote:
>
> > Points for consideration:
> >
> > 1. Do we want some kind of rearrangement of refs as in the 1b
> > repository or not?
> >
>
> Maybe? How much space does that save in a clone? How much
On Mon, 2019-12-16 at 16:42 -0600, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Dec 16, 2019 at 03:13:49PM -0700, Jeff Law wrote:
> > On Mon, 2019-12-16 at 15:59 -0600, Segher Boessenkool wrote:
> > > In particular, we should look carefully at the commit
> > > > attributions in both conversions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92987
--- Comment #1 from joseph at codesourcery dot com ---
On Wed, 18 Dec 2019, lhyatt at gmail dot com wrote:
> I was about to work on adding support for -finput-charset into diagnostics
> infrastructure (it currently ignores it), however it seems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92958
--- Comment #1 from Thomas Koenig ---
Also seen on x86_64-pc-linux-gnu.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92992
--- Comment #1 from Jakub Jelinek ---
Created attachment 47522
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47522=edit
gcc10-pr92992.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92666
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92785
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
Hi!
On 2019-12-17T22:02:25-0800, Julian Brown wrote:
> This patch series provides support for OpenACC 2.6's manual deep copy
> (attach/detach) feature.
Thanks.
There is high pressure to get this functionality into GCC 10, but
remaining time is short, given upcoming winter holidays, and GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92958
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92986
--- Comment #7 from Jakub Jelinek ---
We could in theory save the tokens of each method and compare them, but it
would be quite costly.
Normally people don't cut'n'paste classes between TUs, but rather just declare
them once in a header they
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92992
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92992
Bug ID: 92992
Summary: Side-effects dropped when decltype(nullptr) typed
expression is passed to ellipsis
Product: gcc
Version: 10.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92986
--- Comment #6 from Andrew Pinski ---
Yes, this is a vague linkage function so as jakub mentioned, comparing the ir
even between optimization levels is hard. Yes we could in theory it could be
done but for gcc, it would mean ripping up most of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92982
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Committed to trunk as r279541.
libcpp/ChangeLog:
PR preprocessor/92982
* charset.c
(cpp_string_location_reader::cpp_string_location_reader): Delete
initialization of m_line_table.
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92986
--- Comment #5 from Jakub Jelinek ---
Yes, you haven't read my comment which explained what -Wodr does and doesn't
and why.
On Mon, Dec 16, 2019 at 06:19:26PM -0500, Eric S. Raymond wrote:
> Segher Boessenkool :
> > There is absolutely no reason to trust a system that supposedly was
> > already very mature, but that required lots of complex modifications,
> > and even a complete rewrite in a different language, that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92982
--- Comment #2 from David Malcolm ---
Author: dmalcolm
Date: Wed Dec 18 17:26:01 2019
New Revision: 279541
URL: https://gcc.gnu.org/viewcvs?rev=279541=gcc=rev
Log:
Drop unused member from cpp_string_location_reader (PR preprocessor/92982)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92986
--- Comment #4 from Geetesh More ---
I tried with -flto, but I'm not seeing any warning messages:
g++ -std=c++0x -g -flto -Wodr main.cpp file2.cpp
Am I missing anything here?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92991
Bug ID: 92991
Summary: [10 regression] g++.dg/ubsan/vptr-4.C fails starting
with r279473
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Hi!
On 2019-12-11T18:22:00+0100, I wrote:
> On 2019-10-29T12:15:01+, Julian Brown wrote:
>> I've removed the special-case handling
>> of pointers in the enter/exit data code, and combined the
>> gomp_acc_remove_pointer code (which now iterated over mappings
>> one-at-a-time anyway) with the
1 - 100 of 224 matches
Mail list logo
