https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84637
Bug ID: 84637
Summary: gcc/dbxout.c:684:14: runtime error: negation of
-9223372036854775808 cannot be represented in type
'long int'; cast to an unsigned type to negate this
:38880
0x15a51f5 c_common_parse_file()
/home/vegard/git/gcc/gcc/c-family/c-opts.c:1132
$ xgcc --version
xgcc (GCC) 8.0.1 20180228 (experimental)
Built from git fd1990b25777e5f1307eac1447e8fb5fefe747b4 (r258063).
Seems like versions all the way back to 4.4.7 (the oldest gcc on godbolt.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84635
Bug ID: 84635
Summary: gcc/regrename.c:1706:64: runtime error: index -1 out
of bounds for type 'machine_mode [30]'
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84634
Martin Liška changed:
What|Removed |Added
Target Milestone|--- |8.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84634
Bug ID: 84634
Summary: [8 Regression] gcc/tree-vect-stmts.c:6786:19: runtime
error: member access within null pointer of type
'struct _loop_vec_info
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84631
--- Comment #2 from Jay ---
Err oops let me look again. Failure must be something else then.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84628
--- Comment #9 from Andrew Pinski ---
deprecated
deprecated (msg)
The deprecated attribute results in a warning if the function is used anywhere
in the source file. This is useful when identifying functions that are expected
to be removed in a fu
/git/gcc/gcc/cp/parser.c:12879
0x1001295 cp_parser_declaration
/home/vegard/git/gcc/gcc/cp/parser.c:12776
$ xgcc --version
xgcc (GCC) 8.0.1 20180228 (experimental)
Built from git fd1990b25777e5f1307eac1447e8fb5fefe747b4 (r258063).
Similar message to #52596 but that is an old bug.
7.3.0 seems fin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84628
--- Comment #8 from Jay ---
Aha, kinda the same thing, but before or after analysis.
And this “deprecated” somewhat matches msvc - I was wondering about that but
didn’t see it.
It’d be nice to be able to customize the deprecated message but hope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84631
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84616
--- Comment #2 from michael at moekadu dot de ---
Created attachment 43532
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43532&action=edit
Preprocessed test-program
Here the preprocessed test-programmed
(g++ -Ieigen test.cpp -O3 -funsafe-
3 cp_parser_translation_unit
/home/vegard/git/gcc/gcc/cp/parser.c:4559
0xff9893 c_parse_file()
/home/vegard/git/gcc/gcc/cp/parser.c:38880
0x15a51f5 c_common_parse_file()
/home/vegard/git/gcc/gcc/c-family/c-opts.c:1132
$ xgcc --version
xgcc (GCC) 8.0.1 20180228 (e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84630
Andrew Pinski changed:
What|Removed |Added
Keywords||error-recovery,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84628
--- Comment #7 from Jakub Jelinek ---
The warning/error attributes have been added for purposes like glibc memset
inline, which does:
if (__builtin_constant_p (__len) && __len == 0
&& (!__builtin_constant_p (__ch) || __ch != 0))
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84631
Bug ID: 84631
Summary: make check in fixincludes fails seemingly due to star
in directory names, on WSL
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Severity
/home/vegard/git/gcc/gcc/cp/parser.c:13061
0xfae548 cp_parser_block_declaration
/home/vegard/git/gcc/gcc/cp/parser.c:12879
$ xgcc --version
xgcc (GCC) 8.0.1 20180228 (experimental)
Built from git fd1990b25777e5f1307eac1447e8fb5fefe747b4 (r258063).
7.3.0 says:
:2:13: error: ISO C++ f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84628
--- Comment #6 from Jay ---
Misplaced comment:
But, the thing is, because optimization can remove the use of such functions,
people are now advocating that we noinline along with the attribute, which
hypothetically is unwarranted damage. Noinline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84629
--- Comment #4 from Jay ---
-disable-multilib fixed the errors.
I didn't watch for the warnings.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44002
--- Comment #4 from Jay ---
Incorrect bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84628
--- Comment #5 from Jay ---
I know. We just noticed and were surprised. It isn't clear if this is what
users would expect or not. Warn because they wrote code that "merely looks
bad", or only if the compiler decides after analysis that it really
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84628
--- Comment #4 from Andrew Pinski ---
(In reply to Jay from comment #3)
> The original case said something about "localalias" in the error, so aliases
> don't seem to address it. I can dig that up probably.
>
> Shouldn't it warn for:
> if (0)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44002
--- Comment #3 from Jay ---
But, the thing is, because optimization can remove the use of such functions,
people are now advocating that we noinline along with the attribute, which
hypothetically is unwarranted damage. Noinline being a partial di
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84628
--- Comment #3 from Jay ---
The original case said something about "localalias" in the error, so aliases
don't seem to address it. I can dig that up probably.
Shouldn't it warn for:
if (0)
banned_function()
?
I believe we want it to.
You kn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84625
Jakub Jelinek changed:
What|Removed |Added
Keywords||ice-on-invalid-code
Status|U
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84625
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Summ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84629
--- Comment #3 from Jay ---
This is ubuntu xenial I think, on WSL.
Which doesn't have multi-arch.
So I'll try configure -disable-multilib.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84628
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84629
--- Comment #2 from Jakub Jelinek ---
The __NR_* macros are actually provided by kernel headers rather than glibc,
/usr/include/asm*/unistd*.h
So this looks like a distro bug to me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84629
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71657
Tom de Vries changed:
What|Removed |Added
Status|SUSPENDED |NEW
--- Comment #13 from Tom de Vries --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84623
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84629
Bug ID: 84629
Summary: sanitizer warnings and errors on Linux
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83327
Tom de Vries changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83327
--- Comment #13 from Tom de Vries ---
Author: vries
Date: Thu Mar 1 05:51:08 2018
New Revision: 258093
URL: https://gcc.gnu.org/viewcvs?rev=258093&root=gcc&view=rev
Log:
Fix liveness analysis in lra for spilled-into hard regs
2018-03-01 Tom d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84628
--- Comment #1 from Jay ---
Also occurs with git trunk ef8d0c5bff3c11a5d67617df2f43775f7a26fad2 8.0.1
20180228.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84628
Bug ID: 84628
Summary: attribute(warning/error) should be evaluated before
optimization
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84627
--- Comment #2 from Nicholas Piggin ---
Ah sorry, target is powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84627
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84627
Bug ID: 84627
Summary: powerpc excess padding generated for POWER9 target
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84626
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84626
Bug ID: 84626
Summary: powerpc toc register is reloaded unnecessarily
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84625
Bug ID: 84625
Summary: ICE with constexpr and inline asm
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84624
Bug ID: 84624
Summary: bogus -Wstringop-truncation in a catch statement and
nul assignment outside it
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84623
Bug ID: 84623
Summary: [8 Regression] "-fcompare-debug failure (length)"
testing pr46066.c start with r257826 on mips
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84622
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84622
Bug ID: 84622
Summary: [F08] gfortran accepts invalid intent(out) polymorphic
dummy argument with coarray component
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84294
Martin Sebor changed:
What|Removed |Added
Keywords||patch
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84621
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
Summary|bogus -Wres
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84621
Bug ID: 84621
Summary: bogus -Wresturn-type on a template instantiated on a
function
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71784
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71784
--- Comment #17 from Jason Merrill ---
Author: jason
Date: Wed Feb 28 21:34:56 2018
New Revision: 258087
URL: https://gcc.gnu.org/viewcvs?rev=258087&root=gcc&view=rev
Log:
PR c++/71784 - ICE with ref-qualifier and explicit specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71784
--- Comment #15 from Jason Merrill ---
Author: jason
Date: Wed Feb 28 21:34:07 2018
New Revision: 258085
URL: https://gcc.gnu.org/viewcvs?rev=258085&root=gcc&view=rev
Log:
PR c++/71784 - ICE with ref-qualifier and explicit specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71784
--- Comment #16 from Jason Merrill ---
Author: jason
Date: Wed Feb 28 21:34:31 2018
New Revision: 258086
URL: https://gcc.gnu.org/viewcvs?rev=258086&root=gcc&view=rev
Log:
PR c++/71784 - ICE with ref-qualifier and explicit specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52285
--- Comment #21 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #20)
> Vlad, your thoughts on this? Can it be done in LRA or postreload-gcse or
> some other post-LRA pass (if they do have loops)?
I don't think it can be done e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84610
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Target Milest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84614
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Target Milest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84618
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Target Milest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52991
--- Comment #34 from Benjamin Robin ---
Thank you a lot for the fix.
I have no idea what I did yesterday when I did test bf-ms-layout-2.c (Yes the
test was wrong, and by default cannot compile under Visual Studio VC)
The test can be slightly imp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71784
Jason Merrill changed:
What|Removed |Added
Priority|P4 |P2
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70321
--- Comment #17 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #16)
> We didn't do that in stage1, stage4 is too risky for that. Can somebody
> from Intel try that for GCC9 stage1?
> I'm willing to help, but will have lots of work on O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84014
--- Comment #4 from David Edelsohn ---
Author: dje
Date: Wed Feb 28 19:53:24 2018
New Revision: 258081
URL: https://gcc.gnu.org/viewcvs?rev=258081&root=gcc&view=rev
Log:
PR target/84014
* gcc.target/powerpc/pr84014.c: Use ilp32,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82258
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P4
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84616
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70321
Jakub Jelinek changed:
What|Removed |Added
CC||itsimbal at gcc dot gnu.org
Target Mil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84610
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84609
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84618
--- Comment #2 from David Malcolm ---
Failing here in build_capture_proxy (member=,
init=) at ../../src/gcc/cp/lambda.c:458:
458 gcc_assert (VAR_P (init) || TREE_CODE (init) == PARM_DECL);
where init is a component_ref.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84611
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84609
--- Comment #5 from Jakub Jelinek ---
Author: jakub
Date: Wed Feb 28 18:57:38 2018
New Revision: 258080
URL: https://gcc.gnu.org/viewcvs?rev=258080&root=gcc&view=rev
Log:
PR c++/84609
* parser.c (cp_parser_attributes_opt): Format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83503
--- Comment #23 from Jakub Jelinek ---
Author: jakub
Date: Wed Feb 28 18:56:36 2018
New Revision: 258079
URL: https://gcc.gnu.org/viewcvs?rev=258079&root=gcc&view=rev
Log:
PR c++/83871
PR c++/83503
* pt.c (INCLUDE_STRING)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83871
--- Comment #6 from Jakub Jelinek ---
Author: jakub
Date: Wed Feb 28 18:56:36 2018
New Revision: 258079
URL: https://gcc.gnu.org/viewcvs?rev=258079&root=gcc&view=rev
Log:
PR c++/83871
PR c++/83503
* pt.c (INCLUDE_STRING):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80293
Jakub Jelinek changed:
What|Removed |Added
CC||peter at cordes dot ca
--- Comment #11 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80837
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84618
David Malcolm changed:
What|Removed |Added
Keywords||error-recovery,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84617
Martin Sebor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84617
--- Comment #3 from Martin Sebor ---
Author: msebor
Date: Wed Feb 28 18:28:53 2018
New Revision: 258077
URL: https://gcc.gnu.org/viewcvs?rev=258077&root=gcc&view=rev
Log:
PR testsuite/84617 - new test cases g++.dg/ext/attr-const.C and
g++.dg/ext
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84562
--- Comment #8 from rguenther at suse dot de ---
On February 28, 2018 6:44:43 PM GMT+01:00, "jnordholz at sect dot tu-berlin.de"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84562
>
>--- Comment #7 from Jan Nordholz
>---
>(In reply to R
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84594
--- Comment #5 from Steve Kargl ---
On Wed, Feb 28, 2018 at 04:41:00PM +, dominiq at lps dot ens.fr wrote:
>
> Do you at least agree that
>
> (a) || flag_default_real_10 || flag_default_real_16 should be added
> to flag_default_integer || f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84562
--- Comment #7 from Jan Nordholz ---
(In reply to Richard Biener from comment #5)
> Btw, the behavior is the way you describe since forever. That GCC looks at
> the constant initializer for the array is just a direct consequence of it
> looking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80899
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84612
--- Comment #2 from Jonathan Wakely ---
For completeness, the standard says that the operator is defined like this:
template valarray operator*(const valarray&, const T&);
That's what libstdc++ provides, and it fails to deduce T in your example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57534
Jeffrey A. Law changed:
What|Removed |Added
Target Milestone|6.5 |9.0
--- Comment #30 from Jeffrey A. Law
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83901
--- Comment #3 from Paul Thomas ---
Author: pault
Date: Wed Feb 28 17:36:20 2018
New Revision: 258076
URL: https://gcc.gnu.org/viewcvs?rev=258076&root=gcc&view=rev
Log:
2018-02-28 Paul Thomas
PR fortran/83901
* trans-stmt.c (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83344
--- Comment #14 from Paul Thomas ---
Author: pault
Date: Wed Feb 28 17:36:20 2018
New Revision: 258076
URL: https://gcc.gnu.org/viewcvs?rev=258076&root=gcc&view=rev
Log:
2018-02-28 Paul Thomas
PR fortran/83901
* trans-stmt.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52285
--- Comment #20 from Jakub Jelinek ---
Vlad, your thoughts on this? Can it be done in LRA or postreload-gcse or some
other post-LRA pass (if they do have loops)?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84294
Martin Sebor changed:
What|Removed |Added
Keywords||missed-optimization
Status|UN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84620
Bug ID: 84620
Summary: DW_AT_GNU_entry_view should not use address class
forms, but constant forms
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84619
--- Comment #2 from Janne Blomqvist ---
size_t is the documented type, but for various reasons due to idiosyncrasies in
the gfortran frontend, for the moment it emits a signed type the same size as
size_t.
Just use size_t, that should work fine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52991
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52991
--- Comment #32 from Jakub Jelinek ---
Author: jakub
Date: Wed Feb 28 17:17:29 2018
New Revision: 258075
URL: https://gcc.gnu.org/viewcvs?rev=258075&root=gcc&view=rev
Log:
PR target/52991
* stor-layout.c (update_alignment_for_fie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57534
--- Comment #29 from amker at gcc dot gnu.org ---
(In reply to Jeffrey A. Law from comment #28)
> BTW, ISTM that we need Bin to chime in on the complexity of improving this
> in IVOPTS -- ie, is it gcc-8 or gcc-9 material. If the latter, then we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84617
Martin Sebor changed:
What|Removed |Added
Keywords||patch
--- Comment #2 from Martin Sebor -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84609
--- Comment #4 from Jason Merrill ---
(In reply to Jakub Jelinek from comment #3)
> Created attachment 43529 [details]
> gcc8-pr84609.patch
>
> Untested fix.
Looks good.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84619
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84590
--- Comment #5 from Jason Merrill ---
(In reply to Jakub Jelinek from comment #3)
> assumes that at least for non-vector cp_fully_fold of a CONSTRUCTOR will
> yield again a CONSTRUCTOR as well, but that is generally not the case.
> It could (at l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57534
--- Comment #28 from Jeffrey A. Law ---
BTW, ISTM that we need Bin to chime in on the complexity of improving this in
IVOPTS -- ie, is it gcc-8 or gcc-9 material. If the latter, then we should
adjust the target milestone.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57534
--- Comment #27 from Jeffrey A. Law ---
WRT c#21. There is a good paper from Click on an integrated GVN/GCM/reassoc.
"Combining Analyses, Combining Optimizations" It was published in PLDI. I've
probably got a copy here if you want it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84594
--- Comment #4 from Dominique d'Humieres ---
> > (1) AFAICT this not documented. Is NUMERIC_STORAGE_SIZE the only parameter
> > in
> > ISO_FORTRAN_ENV triggering a warning?
>
> Don't know. But, it is obviously a correct warning
> as -fdefault-
ibquadmath --disable-libquadmath-support
Thread model: posix
gcc version 8.0.1 20180228 (experimental) (GCC)
> /Gcc/8.0.1/bin/gcc -c -m64 -march=nocona -O1 lnx_c.c
> /Gcc/8.0.1/bin/gfortran -o z_lnx -m64 -march=nocona lnx_c.o lnx_f.f
> ./z_lnx
Segmentation fault (core dumped)
(2) macOS
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84550
--- Comment #6 from Pedro Alves ---
I see the same thing with your reduced testcase:
~~~
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x400580
infrun: stepped into subroutine
infrun: inserting step-resume breakpoint at 0x400410
infrun: resu
1 - 100 of 193 matches
Mail list logo