https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87318
Bug ID: 87318
Summary: gfortran.dg/dtio_1.f90 is invalid
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
expand.c (expand_gimple_basic_block): Be prepared for a BARRIER
before and after a JUMP_TABLE_DATA.
Added:
trunk/gcc/testsuite/gcc.c-torture/compile/20180915-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgexpand.c
trunk/gcc/testsuite/ChangeLog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86864
Eric Botcazou changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86990
Eric Botcazou changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87315
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87310
--- Comment #3 from Róbert Kohányi ---
Created attachment 44697
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44697&action=edit
/usr/lib/gcc/x86_64-pc-msys/7.3.0/include/stdbool.h
Here's the referenced on Windows using gcc 7.3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87310
--- Comment #4 from Róbert Kohányi ---
Created attachment 44698
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44698&action=edit
/usr/lib/gcc/x86_64-linux-gnu/5/include/stdbool.h
Here's the on Ubuntu using gcc 5.4.0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87310
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87209
Manuel López-Ibáñez changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87315
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55060
Manuel López-Ibáñez changed:
What|Removed |Added
Known to work||9.0
--- Comment #6 from Manuel Lóp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87316
--- Comment #5 from David ---
I've isolated the compilation and the results are still as above -- new
versions of gcc are significantly slower compiling the attached test.i.
Using this command: gcc -std=gnu99 -O0 -c test.i
gcc 7.3.0 (Ubuntu 18.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65158
Manuel López-Ibáñez changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165
--- Comment #19 from Manuel López-Ibáñez ---
(In reply to Vincent Lefèvre from comment #18)
> OK, but then, this means that the first sentence of the
> -Wmaybe-uninitialized documentation is incorrect. That's probably the "there
> exists" that is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87299
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87299
Manuel López-Ibáñez changed:
What|Removed |Added
Keywords|diagnostic |
--- Comment #2 from Manuel López-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165
--- Comment #20 from Marc Glisse ---
(In reply to Vincent Lefèvre from comment #18)
> OK, but then, this means that the first sentence of the
> -Wmaybe-uninitialized documentation is incorrect. That's probably the "there
> exists" that is problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87319
Bug ID: 87319
Summary: When vector is wrapped, expression is not optimized.
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65158
--- Comment #4 from Martin Sebor ---
(In reply to Manuel López-Ibáñez from comment #3)
> void foo(void) {
> __builtin_printf("%ñ%中");
> __builtin_printf ("%\x1B$B"); /* Taken from PR33748 */
> }
>
> : In function 'void foo()':
> :2:22:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87319
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87140
Emiliano Silvestri changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87316
--- Comment #6 from David ---
clang 6 does the compilation in under 1 second on the same container.
$ clang-6.0 -v
clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87318
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87318
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87320
Bug ID: 87320
Summary: Last iteration of vectorized loop not executed when
peeling for gaps
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87315
--- Comment #4 from Martin Sebor ---
To be clear: besides the missing warning this is also about the kind of code
GCC emits for the uninitialized read -- a missed-optimization for lack of a
better term/keyword. It would be safer to do what Clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87209
--- Comment #3 from Martin Sebor ---
(As suggested in bug 87315) besides issuing a warning it would be safer to do
what Clang does in cases like this and either replace the code with a trap, or
simply eliminate the access (and the malloc call) al
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86484
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86484
janus at gcc dot gnu.org changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87322
Bug ID: 87322
Summary: [GCC 8.1+] GCC fails to parse captured lambda of 2nd
inner lambda if the captured lambda has "," (having 2
arguments)
Product: gcc
Version:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86484
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86551
janus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||ice-on-invalid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86551
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86484
--- Comment #5 from janus at gcc dot gnu.org ---
(In reply to janus from comment #4)
> The following draft patch fixes both this one and PR 84543:
... and regtests cleanly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87323
Bug ID: 87323
Summary: More complicated assembly for sode with custom copy
constructor
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87315
--- Comment #5 from Manuel López-Ibáñez ---
(In reply to Martin Sebor from comment #4)
> To be clear: besides the missing warning this is also about the kind of code
> GCC emits for the uninitialized read -- a missed-optimization for lack of a
>
/9.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/absozero/trunk/root-gcc
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 9.0.0 20180915 (experimental) [trunk revision 264342] (GCC)
$ g++-trunk abc.C
abc.C:9:18
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65158
--- Comment #5 from Manuel López-Ibáñez ---
(In reply to Martin Sebor from comment #4)
> What follows the percent sign must one of the C or POSIX conversion
> specifiers (after any optional flags etc.) and those are all single byte
> characters i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87323
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Component|c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87318
--- Comment #3 from Jerry DeLisle ---
Created attachment 44700
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44700&action=edit
Revised dtio_1.f90
Will this attached version suffice? When we wrote the test case we were not
going for valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70082
--- Comment #7 from Carlos O'Donell ---
(In reply to Martin Sebor from comment #6)
> Carlos, do you still feel diagnosing some of the [mis]uses would be helpful,
> e.g., by a warning? (I ask because I've been doing some work in this area
> -- pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87317
H.J. Lu changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87317
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87323
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87319
--- Comment #2 from Marc Glisse ---
*** Bug 87323 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71157
Eric Gallager changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87317
--- Comment #4 from Marc Glisse ---
> (match_operand:DI 1 "nonimmediate_operand" "m,*m,m")
Does it have to come from memory, can't it also come from a (sub)register?
int f(__m64 x){
__m128i y = _mm_movpi64_epi64(x); // or harder _mm_set1_epi6
47 matches
Mail list logo
