https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89951
--- Comment #2 from Uroš Bizjak ---
These two flags are irrelevant without -mavx.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89954
--- Comment #2 from Andreas Schwab ---
Doesn't aarch64 always implicitly zero-extend when the dest is a 32-bit reg?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89955
--- Comment #1 from Andreas Schwab ---
In which way is STARTFILE_PREFIX_SPEC interfering with sysroot? The sysroot is
expected to use the standard layout, and the directories in
STARTFILE_PREFIX_SPEC are prefixed with the sysroot before being us
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89958
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46590
--- Comment #54 from rsandifo at gcc dot gnu.org
---
Author: rsandifo
Date: Thu Apr 4 07:35:34 2019
New Revision: 270142
URL: https://gcc.gnu.org/viewcvs?rev=270142&root=gcc&view=rev
Log:
DF usage in loop-invariant.c (PR46590)
- df_live is al
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89956
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89959
Bug ID: 89959
Summary: gcov: "--long-file-names" is ignored when used in
combination with "--hash-filenames"
Product: gcc
Version: 8.3.1
Status: UNCONFIRMED
Sev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89937
--- Comment #3 from Jonathan Wakely ---
(In reply to Walt Karas from comment #2)
> Hmmm it seems you are saying that inline (or weak linkage by any other name)
> in C++ somehow prohibits inlining.
I think in this instance, the inlining heuristic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89929
--- Comment #8 from Martin Liška ---
Ok, let me first focus on the functional part of the patch.
If I'm correct feature_list in get_builtin_code_for_version function should be
basically aligned with isa_names_table in fold_builtin_cpu. Difference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89959
--- Comment #1 from Cristian Morales Vega ---
At the end of my previous comment
.gcov
should actually be
##.gcov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89893
--- Comment #11 from Martin Liška ---
(In reply to 康 珊 from comment #10)
> Hi Martin Liška, I tried to build it with "-O3 -fno-strict-aliasing
> -falign-functions=32 -fno-math-errno -fno-semantic-interposition
> -fno-trapping-math", but it still
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89937
--- Comment #4 from Jonathan Wakely ---
But more generally, Andrew's point is that you're comparing apples and oranges.
If you declare the function "extern inline" then it has similar semantics in
both C and C++, and you get similar code (with a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89951
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89951
--- Comment #4 from Alexander ---
(In reply to Uroš Bizjak from comment #2)
> These two flags are irrelevant without -mavx.
But, for example, when i build Qt5 gcc give error about these two instructions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89951
--- Comment #5 from Martin Liška ---
(In reply to Alexander from comment #4)
> (In reply to Uroš Bizjak from comment #2)
> > These two flags are irrelevant without -mavx.
>
> But, for example, when i build Qt5 gcc give error about these two
> in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89956
--- Comment #3 from rsandifo at gcc dot gnu.org
---
Created attachment 46087
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46087&action=edit
Candidate patch
Testing the attached.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89959
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89893
--- Comment #12 from 康 珊 ---
Yes, I built it with LDFLAGS="${LDFLAGS} -fno-lto". Moreover, I tried
"__attribute__((noipa)) uv_unref(uv_handle_t*);" and it could solve the issue.
So it may not be caused by the alias, right?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89893
--- Comment #13 from Martin Liška ---
(In reply to 康 珊 from comment #12)
> Yes, I built it with LDFLAGS="${LDFLAGS} -fno-lto". Moreover, I tried
> "__attribute__((noipa)) uv_unref(uv_handle_t*);" and it could solve the
> issue. So it may not be c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79861
Dominique d'Humieres changed:
What|Removed |Added
Priority|P3 |P4
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #22 from Iain Sandoe ---
(In reply to Erik Schnetter from comment #21)
> https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00162.html
Additional to the comments on list.
Perhaps this is just unfixable :(
I suspect that Apple will want
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89960
Bug ID: 89960
Summary: Implicit derived to base conversion considered type
punning.
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89960
Andrew Pinski changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89937
--- Comment #5 from Andrew Pinski ---
(In reply to Jonathan Wakely from comment #3)
> (In reply to Walt Karas from comment #2)
> > Hmmm it seems you are saying that inline (or weak linkage by any other name)
> > in C++ somehow prohibits inlining.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89961
Bug ID: 89961
Summary: When "--intermediate-format" is used
"--preserve-paths"/"--hash-filenames" is ignored
Product: gcc
Version: 8.3.1
Status: UNCONFIRMED
Sev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89961
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89893
--- Comment #14 from 康 珊 ---
Yes, I built it with LDFLAGS="${LDFLAGS} -fno-lto". Moreover, I tried
"__attribute__((noipa)) uv_unref(uv_handle_t*);" and it could solve the issue.
So it may not be caused by the alias, right?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89893
--- Comment #15 from Martin Liška ---
(In reply to 康 珊 from comment #14)
> Yes, I built it with LDFLAGS="${LDFLAGS} -fno-lto". Moreover, I tried
> "__attribute__((noipa)) uv_unref(uv_handle_t*);" and it could solve the
> issue. So it may not be c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89924
Jan Hubicka changed:
What|Removed |Added
CC||jason at redhat dot com
--- Comment #2 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89893
--- Comment #16 from 康 珊 ---
OK. Our latest release nodejs package build steps are:
export CFLAGS="$CFLAGS -O3 -falign-functions=32 -fno-math-errno
-fno-semantic-interposition -fno-trapping-math "
export CXXFLAGS="$CXXFLAGS -O3 -falign-functions=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89893
--- Comment #17 from Martin Liška ---
> ./configure --prefix=/usr --shared-openssl --shared-zlib --use-largepages
> --enable-lto --shared-nghttp2
Why are you enabling LTO here if you don't want to use it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89924
--- Comment #3 from Jan Hubicka ---
OK, C++ FE can't do that because virtual call is wrapper by foo_virtual_inner.
After inlining we see:
Determining dynamic type for call: OBJ_TYPE_REF(_5;(struct A)p_2(D)->0)
(p_2(D), p_2(D));
Starting walk at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89924
--- Comment #4 from Jan Hubicka ---
And to answer the question about why GCC produces more code, it is
actually speculative devirtualization of the call. GCC determines
the most likely target and inlines it.
foo_virtual(Aint*):
# this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89893
--- Comment #18 from 康 珊 ---
Sorry, actually I don't know the reason, and I failed to find any git comment
for that configuration. It is involved from 10.14.2 build.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89962
Bug ID: 89962
Summary: likely/unlikely attributes don't work on a
compound-statement
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89963
Bug ID: 89963
Summary: Compile-time hog when compiling
gcc/testsuite/gcc.dg/autopar/uns-outer-6.c
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: compil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89951
--- Comment #6 from Alexander ---
(In reply to Martin Liška from comment #5)
> What kind of error? Can you please provide a test-case?
Like these:
> cd gui/ && ( test -e Makefile ||
> /tmp/qt-everywhere-src-5.12.1/qtbase/bin/qmake -o Makefile
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89964
Bug ID: 89964
Summary: Remove the "First, you must pick a product on which to
enter a bug:" page
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89965
Bug ID: 89965
Summary: [9 Regression] wrong code with -O -mtune=nano-x2
-fcaller-saves -fexpensive-optimizations -fno-tree-dce
-fno-tree-ter
Product: gcc
Version:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #23 from Jürgen Reuter ---
This patch still doesn't work for me:
libtool: compile: /usr/local/packages/gcc_9.0/_build/./gcc/xgcc -shared-libgcc
-B/usr/local/packages/gcc_9.0/_build/./gcc -nostdinc++
-L/usr/local/packages/gcc_9.0/_bui
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #24 from Erik Schnetter ---
On Thu, Apr 4, 2019 at 5:43 AM iains at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
>
> --- Comment #22 from Iain Sandoe ---
> (In reply to Erik
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #25 from Erik Schnetter ---
> On Thu, Apr 4, 2019 at 5:43 AM iains at gcc dot gnu.org <
> gcc-bugzi...@gcc.gnu.org> wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
> >
> > --- Comment #22 from Iain Sandoe ---
> > (In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #26 from Iain Sandoe ---
(In reply to Erik Schnetter from comment #25)
> > On Thu, Apr 4, 2019 at 5:43 AM iains at gcc dot gnu.org <
> > gcc-bugzi...@gcc.gnu.org> wrote:
> > _Atomic is used only in a single struct, which is marked "t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89582
--- Comment #6 from Yichao Yu ---
For the vfloat test case, isn't the optimum code just
```
addps %xmm2, %xmm0
addps %xmm3, %xmm1
retq
```
It's not making full use of the vector but I assume not having to spill is a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #27 from Jürgen Reuter ---
In order to proceed bootstrapping I had also to fix
libsanitize/sanitizer_common/sanitizer_platform_limits_posix.cc
and
libsanitize/asan/asan_mac.cc
by correspondingly wrapping include statements.
Hello, Dear Manager,
Good day,
This is Kevin from INSTARGO, original CCTV Accessories supplier.
We are factory produce a wide range of CCTV Accessories, POE switch, Tester,
Power Supply, IR Lighting, BNC Connector, CCTV Housing & Bracket,Wire/Cable,
Microphone,Video Balun, Lens, package etc.
All
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89964
--- Comment #1 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #0)
> classpath is no longer maintained,
Correction: This is not true.
> and almost nobody reports bugs for it.
But this is true.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #28 from Erik Schnetter ---
On Thu, Apr 4, 2019 at 8:11 AM iains at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
>
> --- Comment #26 from Iain Sandoe ---
> (In reply to Eri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89965
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #29 from Erik Schnetter ---
On Thu, Apr 4, 2019 at 8:11 AM iains at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
>
> --- Comment #26 from Iain Sandoe ---
> (In reply to Eri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89965
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89965
--- Comment #3 from Martin Liška ---
(In reply to Martin Liška from comment #2)
> I see the problem also with GCC 8.2.1. Are you sure Jan that it's a 9
> regression?
Sorry, I meant Zdenek :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89965
--- Comment #4 from Zdenek Sojka ---
(In reply to Martin Liška from comment #3)
> (In reply to Martin Liška from comment #2)
> > I see the problem also with GCC 8.2.1. Are you sure Jan that it's a 9
> > regression?
>
> Sorry, I meant Zdenek :)
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: p...@gcc-bugzilla.mail.kapsi.fi
Target Milestone: ---
Build: 9.0.1 20190404
Hi.
This has appeared within the last four weeks or so. It seems that not all
operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89893
--- Comment #19 from 康 珊 ---
I tried the following experiments:
1)Tried "__attribute__((noinline)) uv_unref(uv_handle_t*)", it could solve the
issue.
2)Tried "__attribute__((noipa)) uv_unref(uv_handle_t*)", it could solve the
issue.
2)Tried "-O2"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89922
--- Comment #2 from Antony Polukhin ---
The estimation is very close to the actual result for the loop.
But it does not take into the account the instructions before the loop that are
eliminated due to unrolling. Some heuristic like "initializin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89893
--- Comment #20 from Martin Liška ---
(In reply to 康 珊 from comment #19)
> I tried the following experiments:
> 1)Tried "__attribute__((noinline)) uv_unref(uv_handle_t*)", it could solve
> the issue.
> 2)Tried "__attribute__((noipa)) uv_unref(uv_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #30 from Jürgen Reuter ---
In addition to Erik's changes I have to do as well:
--- asan_mac.cc 2019-04-04 15:02:48.0 +0200
+++ asan_mac.cc.orig2019-04-04 16:44:32.0 +0200
@@ -32,13 +32,7 @@
#include // for free(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56293
Dominique d'Humieres changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89078
Bug 89078 depends on bug 56293, which changed state.
Bug 56293 Summary: Segfault when trying to access pass-by-reference value of a
not-word-aligned REAL(16) / -fno-align-commons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56293
Wha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86960
Alexandre Oliva changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|aoliva at gcc d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89965
Martin Liška changed:
What|Removed |Added
Keywords||needs-bisection
--- Comment #5 from Marti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #31 from Erik Schnetter ---
Here is an updated version of the patch that fixincludes both
and , and does not need to touch any sources
files in GCC any more:
Index: fixincludes/inclhack.def
==
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47720
Dominique d'Humieres changed:
What|Removed |Added
CC||eh.toussaint at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84513
Dominique d'Humieres changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #32 from Jürgen Reuter ---
(In reply to Erik Schnetter from comment #31)
> Here is an updated version of the patch that fixincludes both
> and , and does not need to touch any sources
> files in GCC any more:
>
What about the chan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89967
Bug ID: 89967
Summary: Inefficient code generation for vld2q_lane_u8 under
aarch64
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56643
--- Comment #4 from Paolo Carlini ---
This is fixed in trunk, I'm adding the testcase and closing the bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56643
--- Comment #5 from paolo at gcc dot gnu.org ---
Author: paolo
Date: Thu Apr 4 15:15:59 2019
New Revision: 270144
URL: https://gcc.gnu.org/viewcvs?rev=270144&root=gcc&view=rev
Log:
2019-04-04 Paolo Carlini
PR c++/56643
* g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56643
Paolo Carlini changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65608
Bug 65608 depends on bug 56643, which changed state.
Bug 56643 Summary: Failure to match noexcept specifier of friend template
function in template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56643
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #33 from Erik Schnetter ---
Here is an updated version of the patch that fixincludes both
and , and does not need to touch any sources
files in GCC any more:
Index: fixincludes/inclhack.def
=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89961
--- Comment #2 from Martin Liška ---
Note that the intermediate format provides 'current_working_directory' value
that should be easily used to distinguish among same files in different
folders?
Does it work for you?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89968
Bug ID: 89968
Summary: attribute packed fails to reduce char vector member
alignment
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89968
Martin Sebor changed:
What|Removed |Added
Keywords||ABI, diagnostic
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89529
--- Comment #4 from Alexandre Oliva ---
Yeah, consumer issue, GDB can't deal with location views yet, so it can't tell
apart the views just before the return from that at the return proper. It's
actually a textbook situation of the kind that led
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #34 from Erik Schnetter ---
Here is an updated version of the patch that fixincludes both
and , and does not need to touch any
sources files in GCC any more:
Index: fixincludes/inclhack.def
=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61327
--- Comment #4 from paolo at gcc dot gnu.org ---
Author: paolo
Date: Thu Apr 4 15:38:05 2019
New Revision: 270145
URL: https://gcc.gnu.org/viewcvs?rev=270145&root=gcc&view=rev
Log:
2019-04-04 Paolo Carlini
PR c++/61327
* g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61327
Paolo Carlini changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65608
Bug 65608 depends on bug 61327, which changed state.
Bug 61327 Summary: Problem with friend template object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61327
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89969
Bug ID: 89969
Summary: [OPENACC] private clause does not work with fortran
automatic array
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89530
--- Comment #10 from Alexandre Oliva ---
We'd need to add VTA notes to addressable objects, that currently only get
older var-tracking treatment. It's usually enough, because, being addressable,
they can't really change locations, and, because o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89528
Alexandre Oliva changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89961
--- Comment #3 from Cristian Morales Vega ---
I have just took a look inside one of the intermediate format .gcov files and
didn't see any "current_working_directory". There is a full path "file"
variable though.
Not sure if that's what you mean
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65619
--- Comment #2 from paolo at gcc dot gnu.org ---
Author: paolo
Date: Thu Apr 4 15:49:30 2019
New Revision: 270146
URL: https://gcc.gnu.org/viewcvs?rev=270146&root=gcc&view=rev
Log:
2019-04-04 Paolo Carlini
PR c++/65619
* g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65619
Paolo Carlini changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65608
Bug 65608 depends on bug 65619, which changed state.
Bug 65619 Summary: friend declaration with template template parameter not
recognized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65619
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89893
--- Comment #21 from 康 珊 ---
All of the experiments were did in according to the build steps I just gave to
you.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84382
Dominique d'Humieres changed:
What|Removed |Added
Priority|P3 |P5
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89970
Bug ID: 89970
Summary: [8/9 Regression] ICE in dispatch_function_versions, at
config/i386/i386.c:32347
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89971
Bug ID: 89971
Summary: [8/9 Regression] ICE: unspellable token PADDING
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89937
--- Comment #6 from Walt Karas ---
Yes, very sorry, I didn't realize inline was so different in C, and I also
didn't read the generated machine code carefully enough. It does seem
extremely surprising that, for C, the body of an inline function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89969
Dominique d'Humieres changed:
What|Removed |Added
Priority|P3 |P4
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89972
Bug ID: 89972
Summary: [8/9 Regression] ICE in expand_call, at calls.c:4229
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89844
--- Comment #3 from Dominique d'Humieres ---
> This PR seems also fixed by revision r270037.
Is a new test needed? If yes, would it help if I do the packaging?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #35 from Jürgen Reuter ---
The latest fix doesn't work. It fails at the darwin-driver.c. So yes, all the
files mentioned before have to be modified, asan_mac.cc, sanitizer_mac.cc,
sanitizer_platform_limits_posix.cc, darwin-driver.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89973
Bug ID: 89973
Summary: [9 Regression] ICE in
check_address_or_pointer_of_packed_member, at
c-family/c-warn.c:2769
Product: gcc
Version: 9.0
Status: UN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87919
--- Comment #4 from Dominique d'Humieres ---
What is the status of this PR? Is it FIXED or not?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #36 from Iain Sandoe ---
(In reply to Jürgen Reuter from comment #35)
> The latest fix doesn't work. It fails at the darwin-driver.c. So yes, all
> the files mentioned before have to be modified, asan_mac.cc,
> sanitizer_mac.cc,
> san
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55591
--- Comment #8 from Dominique d'Humieres ---
Testing the updated patch
--- ../_clean/gcc/fortran/options.c 2019-03-11 15:11:11.0 +0100
+++ gcc/fortran/options.c 2019-04-04 18:55:50.0 +0200
@@ -166,6 +166,8 @@ gfc_init_o
1 - 100 of 172 matches
Mail list logo
