https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82461
Bug ID: 82461
Summary: Temporary required for brace-initializing
(non-literal-type) member variable
Product: gcc
Version: 7.2.1
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82322
Konstantinos Margaritis changed:
What|Removed |Added
Status|RESOLVED|VERIFIED
--- Comment #4 from K
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82317
Konstantinos Margaritis changed:
What|Removed |Added
Status|RESOLVED|VERIFIED
--- Comment #4 from K
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82463
Bug ID: 82463
Summary: vec_madd does not map to __builtin_s390_vfmasb for z14
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82464
Bug ID: 82464
Summary: s390x z14: vector float: invalid parameter combination
for intrinsic '__builtin_s390_vec_xor'
Product: gcc
Version: 8.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82463
Konstantinos Margaritis changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82462
Bug ID: 82462
Summary: vec_madd does not map to __builtin_s390_vfmasb for z14
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78549
--- Comment #16 from Thomas Koenig ---
Jerry,
what do you think of this approach? This creates a local copy
of the gfc_unit, without putting it into the tree.
Index: transfer.c
===
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78549
--- Comment #17 from Thomas Koenig ---
I mean apart from the fact that this creates a huge memory leak :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49232
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49232
--- Comment #3 from Thomas Koenig ---
Author: tkoenig
Date: Sat Oct 7 11:48:28 2017
New Revision: 253509
URL: https://gcc.gnu.org/viewcvs?rev=253509&root=gcc&view=rev
Log:
2017-10-07 Thomas Koenig
PR fortran/49232
* expr.c (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82464
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68546
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|NEW
--- Comment #4 from Thomas Koenig -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82461
Jonathan Wakely changed:
What|Removed |Added
Keywords||rejects-valid
Status|UNCON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50518
fabien at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79709
--- Comment #9 from Thomas Koenig ---
The generated code for the loop seems to be on par with what
clang and icc do, so that part is fixed.
Initialization is strange for icc. For clang, it really quite short:
foo:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82461
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78549
--- Comment #18 from Dominique d'Humieres ---
I do not see any timing difference between 7.2.1 (r253502) and trunk.
g++ (GCC) 6.3.1 20170216 (Red Hat 6.3.1-3)
In the below case compile_test_asm_inside_loop invokes test_asm_inside_loop and
ignores results.
The call into test_asm_inside_loop is expected to be eliminated since return
value is not used and there is no side effect
The call elimination works fine w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80805
--- Comment #2 from paolo at gcc dot gnu.org ---
Author: paolo
Date: Sat Oct 7 16:10:02 2017
New Revision: 253510
URL: https://gcc.gnu.org/viewcvs?rev=253510&root=gcc&view=rev
Log:
2017-10-07 Paolo Carlini
PR c++/80805
* g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80805
--- Comment #3 from paolo at gcc dot gnu.org ---
Author: paolo
Date: Sat Oct 7 16:10:21 2017
New Revision: 253511
URL: https://gcc.gnu.org/viewcvs?rev=253511&root=gcc&view=rev
Log:
2017-10-07 Paolo Carlini
PR c++/80805
* g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80805
Paolo Carlini changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71397
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68628
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81614
--- Comment #8 from Jan Hubicka ---
I have tried the attached change at our periodic tester for haswell. It
switches codegen to one similar for pentimpro (assuming that renaming happens
on register parts as opposed to full registers).
Relevant r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67878
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
Bug 67491 depends on bug 67878, which changed state.
Bug 67878 Summary: [concepts] when processing a valid concept check, gcc errors
trying to expand variadic in unrelated code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67878
What
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82420
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71973
Paolo Carlini changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71973
--- Comment #8 from Bernd Edlinger ---
Yes. fixed in 7.1.0
However, I wonder if I should do something when a variable
is declared with the same name as a builtin function.
Currently that aborts at runtime, but while C does warn,
C++ does not war
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78549
--- Comment #19 from Thomas Koenig ---
Created attachment 42320
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42320&action=edit
patch which failes with dtio_14 and dtio_15, among others
Well, this one doesn't work yet.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71973
--- Comment #9 from Paolo Carlini ---
I see, maybe for clarity you could open a separate enhancement-type PR.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82465
Bug ID: 82465
Summary: vec_sqrt() for vector double erroneously fails for z13
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82466
Bug ID: 82466
Summary: Missing warning for re-declaration of built-in
function as variable
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71973
--- Comment #10 from Bernd Edlinger ---
(In reply to Paolo Carlini from comment #9)
> I see, maybe for clarity you could open a separate enhancement-type PR.
Done: pr82466
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78549
--- Comment #20 from Jerry DeLisle ---
(In reply to Thomas Koenig from comment #19)
> Created attachment 42320 [details]
> patch which failes with dtio_14 and dtio_15, among others
>
> Well, this one doesn't work yet.
Do you want to continue wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82466
Jonathan Wakely changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIR
On Sat, Oct 7, 2017 at 8:39 AM, Saldyrkine, Mikhail
wrote:
> g++ (GCC) 6.3.1 20170216 (Red Hat 6.3.1-3)
>
> In the below case compile_test_asm_inside_loop invokes test_asm_inside_loop
> and ignores results.
> The call into test_asm_inside_loop is expected to be eliminated since return
> value is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82466
--- Comment #1 from Paolo Carlini ---
Thanks. I don't think there is *much* more than the below to it:
Index: decl.c
===
--- decl.c (revision 253509)
+++ decl.c (working c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82466
--- Comment #2 from Bernd Edlinger ---
Thanks for looking at this.
I think your patch is fine.
My thought was that it could also be enabled by
OPT_Wbuiltin_declaration_mismatch,
which is default-enabled but can be disabled
in the test case, if n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82420
--- Comment #2 from Mikael Pettersson ---
Started with r145586, but that may simply have exposed a latent issue.
BTW, the configuration of the reporter's gcc
> $ m68k-elf-gcc -v
> Using built-in specs.
> COLLECT_GCC=m68k-elf-gcc
> COLLECT_LTO_WR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82130
Heiko Eißfeldt changed:
What|Removed |Added
CC||heiko at hexco dot de
--- Comment #1 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82467
Bug ID: 82467
Summary: name mangling error when using constrained an
specialized template functions
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78581
Heiko Eißfeldt changed:
What|Removed |Added
CC||heiko at hexco dot de
--- Comment #2 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82375
--- Comment #5 from Paul Thomas ---
Author: pault
Date: Sat Oct 7 21:14:06 2017
New Revision: 253514
URL: https://gcc.gnu.org/viewcvs?rev=253514&root=gcc&view=rev
Log:
2017-10-07 Paul Thomas
PR fortran/82375
* class.c (gfc_f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82468
Bug ID: 82468
Summary: ICE with deduction guide template
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Ass
The " uint64_t test_noasm(uint64_t idx)" has same loop and the function is
optimized out.
I've changed code to constraint the loop iterations and compiler:
- unrolled loop
- did not eliminate the function as it does when asm is not used
It looks like the " infinite loop" is not root cause.
inl
On Sat, Oct 7, 2017 at 2:22 PM, Saldyrkine, Mikhail
wrote:
> The " uint64_t test_noasm(uint64_t idx)" has same loop and the function is
> optimized out.
There is a difference there, objects is limited to 1024. Loading past
the array bounds is undefined.
Thanks,
Andrew
> I've changed code to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78549
--- Comment #21 from Thomas Koenig ---
Jerry,
I think you know more about this than I do, so please go ahead.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82469
Bug ID: 82469
Summary: ICE in _cpp_process_line_notes, at libcpp/lex.c:1066
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82450
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Status|U
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82470
Bug ID: 82470
Summary: Structured bindings don't work with std::tuple if a
type has a get member function
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82471
Bug ID: 82471
Summary: do concurrent is much slower the ordinary do!
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82466
--- Comment #3 from Paolo Carlini ---
Yes. Recycling the warning-name that you added seems fine, but we should
probably extend the description to something like: "Warn if a built-in function
is declared with the wrong signature or as non-function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82466
Paolo Carlini changed:
What|Removed |Added
CC||paolo.carlini at oracle dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82472
Bug ID: 82472
Summary: [8 Regression] ICE in generate_code_for_partition, at
tree-loop-distribution.c:1145
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keyword
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82473
Bug ID: 82473
Summary: [8 Regression] ICE in vect_get_vec_def_for_stmt_copy,
at tree-vect-stmts.c:1524
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: i
57 matches
Mail list logo
