https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86141
--- Comment #5 from Andrew Pinski ---
Try renaming main first. Gcc knows that main is only called once ever so gcc's
inling heuristics are different inside main.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86141
--- Comment #4 from ASA ---
Comment on attachment 44270
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44270
Assembly output from g++ 7.3.0
g++ -O -S gccbug.cpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86142
Bug ID: 86142
Summary: hard error for bad delete-expression in SFINAE context
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86141
--- Comment #3 from ASA ---
Comment on attachment 44271
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44271
Assembly output from clang++ 5.0.0
clang++ -O -S gccbug.cpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86135
--- Comment #12 from Sabetay Toros ---
Created attachment 44272
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44272=edit
Testi case for crashed initialiazer list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86141
--- Comment #2 from ASA ---
Created attachment 44271
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44271=edit
Assembly output from clang++ 5.0.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86141
--- Comment #1 from ASA ---
Created attachment 44270
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44270=edit
Assembly output from GCC 7.3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86141
Bug ID: 86141
Summary: C++ Related Optimization Problem
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86135
--- Comment #11 from Sabetay Toros ---
Here is my test case. The issue is in line 30. Please change the line
commented with direct initilization.
It wont crash.
If you are right list initializers is not usable.
I hope you have an answer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86140
Bug ID: 86140
Summary: constprop clones with identical bodies
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77609
--- Comment #5 from roland at gcc dot gnu.org ---
Author: roland
Date: Thu Jun 14 01:18:59 2018
New Revision: 261581
URL: https://gcc.gnu.org/viewcvs?rev=261581=gcc=rev
Log:
PR other/77609: Let the assembler choose ELF section types for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86139
Bug ID: 86139
Summary: [7/8/9 Regression] ICE in in store_constructor, at
expr.c:6849 on aarch64-linux-gnu and
arm-linux-gnueabihf
Product: gcc
Version: 8.1.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86099
--- Comment #5 from Jason Merrill ---
Author: jason
Date: Thu Jun 14 00:02:42 2018
New Revision: 261576
URL: https://gcc.gnu.org/viewcvs?rev=261576=gcc=rev
Log:
PR c++/86099 - ICE with trivial copy and non-trivial default ctor.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86099
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86099
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83982
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86110
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86134
--- Comment #3 from Martin Sebor ---
As per the recent discussion:
https://gcc.gnu.org/ml/gcc-patches/2018-06/msg00422.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86134
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86110
--- Comment #5 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Wed Jun 13 22:40:46 2018
New Revision: 261575
URL: https://gcc.gnu.org/viewcvs?rev=261575=gcc=rev
Log:
2018-06-13 Steven G. Kargl
PR fortran/86110
* array.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130
--- Comment #16 from Paul Sanders ---
Interesting, I can see why you don't want to change the behaviour again. It's
just a shame it ever did anything other than SEGFAULT in the first place but as
you point out, it's been the way it is for a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86138
--- Comment #2 from Jonathan Wakely ---
Only the std::string and std::wstring instantiations are problematic for C++17.
This should be a better fix, i.e. allow the getline instantiations to be used
even in C++17 mode:
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86138
--- Comment #1 from Jonathan Wakely ---
(In reply to Christian Franke from comment #0)
> As a consequence, no C++17 compatible code for this getline() is generated
> and the old getline() from cygstdc++-6.dll is called instead.
Why is the one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130
--- Comment #15 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #13)
> This is not an accident, it's a supported feature (and arguably documented,
> by the code and the test).
See also Bug 6518 which changed the segfault to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130
--- Comment #14 from Jonathan Wakely ---
(In reply to Paul Sanders from comment #12)
> Any interest?
Good grief, no.
That would generate even worse code than what we have now, and it's possible to
test for badbit without enabling exceptions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130
--- Comment #13 from Jonathan Wakely ---
(In reply to Martin Sebor from comment #10)
> As a data point, calling printf ("%s", p) does lead to a segfault in Glibc
> for a null p because GCC turns the call into puts(p)
Only when optimization is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130
--- Comment #12 from Paul Sanders ---
Sorry, I posted that in a bit of a rush. I took a proper look and the null
pointers that set badbit actually make excellent sense.
So I'll suggest a way out of the backwards compatibility conundrum when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86114
Martin Sebor changed:
What|Removed |Added
Summary|[8/9 Regression] ICE in |ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86114
--- Comment #5 from Martin Sebor ---
Author: msebor
Date: Wed Jun 13 20:39:50 2018
New Revision: 261569
URL: https://gcc.gnu.org/viewcvs?rev=261569=gcc=rev
Log:
PR tree-optimization/86114 - ICE in gimple_fold_builtin_strlen with an invalid
call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130
--- Comment #11 from Paul Sanders ---
> I think most users prefer invalid uses of pointers to fail loudly so they can
> be caught early. Few users expect output functions to fail, and even fewer
> bother to check for failures when writing to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86114
Martin Sebor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86114
--- Comment #3 from Martin Sebor ---
Author: msebor
Date: Wed Jun 13 20:29:04 2018
New Revision: 261567
URL: https://gcc.gnu.org/viewcvs?rev=261567=gcc=rev
Log:
PR tree-optimization/86114 - ICE in gimple_fold_builtin_strlen with an invalid
call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86110
--- Comment #4 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Wed Jun 13 20:17:58 2018
New Revision: 261565
URL: https://gcc.gnu.org/viewcvs?rev=261565=gcc=rev
Log:
2018-06-13 Steven G. Kargl
PR fortran/86110
* array.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86135
--- Comment #10 from Jonathan Wakely ---
You didn't provide a proper testcase so nobody can possibly explain why your
code crashes.
If it's similar to the code in comment 3 then model_t>
tries to construct a vector from a vector using list-init
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86135
--- Comment #9 from Sabetay Toros ---
I´ve examined your link. This is not the same case as you are stating. I am
not initializing a vector with an initializer list, rather I am trying to
initialize only one object member with a universal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86138
Bug ID: 86138
Summary: C++17: getline(istream, string) crashes on Cygwin
because incompatible C++14 function is called
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86090
--- Comment #3 from chefmax at gcc dot gnu.org ---
Author: chefmax
Date: Wed Jun 13 19:51:42 2018
New Revision: 261564
URL: https://gcc.gnu.org/viewcvs?rev=261564=gcc=rev
Log:
2018-06-13 Denis Khalikov
libsanitizer/
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130
--- Comment #10 from Martin Sebor ---
As a data point, calling printf ("%s", p) does lead to a segfault in Glibc for
a null p because GCC turns the call into puts(p) which doesn't have the same
feature (see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86094
--- Comment #9 from Jason Merrill ---
Author: jason
Date: Wed Jun 13 19:39:36 2018
New Revision: 261562
URL: https://gcc.gnu.org/viewcvs?rev=261562=gcc=rev
Log:
PR c++/86094 - wrong code with defaulted move ctor.
gcc/c-family/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86094
--- Comment #10 from Jason Merrill ---
Author: jason
Date: Wed Jun 13 19:39:53 2018
New Revision: 261563
URL: https://gcc.gnu.org/viewcvs?rev=261563=gcc=rev
Log:
PR c++/86094 - wrong code with defaulted move ctor.
gcc/c-family/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86137
--- Comment #1 from joseph at codesourcery dot com ---
Yes, this code needs to be fixed to avoid undefined overflow (if argnum >
INT_MAX / 10 || (argnum == INT_MAX / 10 && *fcp - '0' > INT_MAX % 10),
record that overflow has occurred and don't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130
--- Comment #9 from Jonathan Wakely ---
(In reply to Paul Sanders from comment #8)
> Thanks for your comments. I can see there are two sides to this.
>
> I was in the middle of composing the tract below. I'll include that anyway
> because it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86110
--- Comment #3 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Wed Jun 13 19:37:50 2018
New Revision: 261561
URL: https://gcc.gnu.org/viewcvs?rev=261561=gcc=rev
Log:
2018-06-13 Steven G. Kargl
PR fortran/86110
* array.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130
--- Comment #8 from Paul Sanders ---
Thanks for your comments. I can see there are two sides to this.
I was in the middle of composing the tract below. I'll include that anyway
because it took me ages to type. There's a bit at the end about
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86137
Bug ID: 86137
Summary: ubsan runtime error in c-format.c
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86085
--- Comment #2 from Martin Sebor ---
To make use of the Glibc printf hooks users have to disable the GCC built-ins.
Otherwise the hooks might interfere with the sprintf optimization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130
--- Comment #7 from Jonathan Wakely ---
I don't know the original reason for handling null pointers here, but it's
consistent with glibc's printf which prints "(null)" when a null pointer is
provided for a %s specifier.
Removing this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86127
--- Comment #10 from Jonathan Wakely ---
As I said in comment 6, I've already removed the copies that forward_list does
on destruction.
As I said in comment 3, there are no copies in the default constructor, they're
in the initializer-list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130
--- Comment #6 from Jonathan Wakely ---
And they don't test for iostream operations failing?
The program has undefined behaviour, i.e. a bug. Whether it's better to
identify that and treat it as a corrupt stream state (setting badbit, and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86129
--- Comment #4 from Paul Sanders ---
Sorry, that didn't happen on purpose. I edited the title, maybe that's what
caused it, or maybe it's because someone (Martin?) changed the component from
gcc to libstdc++.
Anyway, I won't post anything
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86127
--- Comment #9 from Scott Constable ---
(In reply to Jonathan Wakely from comment #8)
> (In reply to Scott Constable from comment #7)
> > (In reply to Jonathan Wakely from comment #1)
> > > The allocator requirements say that move construction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207
--- Comment #12 from Steve Kargl ---
On Wed, Jun 13, 2018 at 03:55:02PM +, guez at lmd dot ens.fr wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207
>
> --- Comment #11 from Lionel GUEZ ---
> And what about my suggestion that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130
--- Comment #5 from Jonathan Wakely ---
*** Bug 86129 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86129
Jonathan Wakely changed:
What|Removed |Added
Resolution|INVALID |DUPLICATE
--- Comment #3 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86135
--- Comment #8 from Jonathan Wakely ---
http://en.cppreference.com/w/cpp/language/list_initialization#Notes shows a
similar example, demonstrating the different behaviour for initializer_list
constructors. std::vector has an initializer-list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130
--- Comment #4 from Paul Sanders ---
@Johnathon Crashing the program is the right thing to do, because it means that
the developer (or the test department) will get to find out about the problem
before the customer does.
Does that help you see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86129
--- Comment #2 from Paul Sanders ---
The program should crash. That way, the developer (or the test department)
gets to find out about the problem before the customer.
I would have thought this was obvious.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86127
--- Comment #8 from Jonathan Wakely ---
(In reply to Scott Constable from comment #7)
> (In reply to Jonathan Wakely from comment #1)
> > The allocator requirements say that move construction must be equivalent to
> > copy construction, and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86135
--- Comment #7 from Jonathan Wakely ---
(In reply to Sabetay Toros from comment #6)
> the rules may be different but results must be the same.
No, that's not true. The point of the different rules is to do different
things.
> There is a flaw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86127
--- Comment #7 from Scott Constable ---
(In reply to Jonathan Wakely from comment #1)
> The allocator requirements say that move construction must be equivalent to
> copy construction, and allocators should be cheap to copy anyway. I don't
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86135
--- Comment #6 from Sabetay Toros ---
Hi,
*Because the rules for direct-initialization (with parentheses)
andlist-initialization (with braces) are different. Different rules
meansdifferent things happen. *
the rules may be different but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86107
--- Comment #6 from rsandifo at gcc dot gnu.org
---
(In reply to Uroš Bizjak from comment #5)
> (In reply to rsand...@gcc.gnu.org from comment #4)
>
> > > but should not fail verification even for !TARGET_INTER_UNIT_MOVES_TO_VEC
> > > targets.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86048
--- Comment #7 from Eric Botcazou ---
To give a bit more information about the bug: it's a bad interaction between
SEH, -freorder-blocks-and-partition (default) and
__builtin_{frame,return}_address.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130
--- Comment #3 from Jonathan Wakely ---
Arguably crashing the program is more unfriendly.
We could add the nonnull attribute to the relevant ostream members, or add
assertions that can be optionally enabled, but I'm not convinced that crashing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86135
--- Comment #5 from Jonathan Wakely ---
(In reply to Sabetay Toros from comment #4)
> If it is not a bug then why the parenthesis version is working.
Because the rules for direct-initialization (with parentheses) and
list-initialization (with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86127
Jonathan Wakely changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86129
Bug ID: 86129
Summary: Expect SIGBUS but program just silently exits
Product: gcc
Version: 8.1.0
Status: RESOLVED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86124
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207
--- Comment #11 from Lionel GUEZ ---
And what about my suggestion that ieee_support_nan(0.) should return false for
the time being?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86123
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86122
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86121
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86114
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86113
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130
--- Comment #2 from Paul Sanders ---
Hi Martin,
Thanks very much for your prompt reply, and I completely agree with your
viewpoint.
I therefore hereby request that libstc++ stops behaving like that and just lets
the SIGSEGV happen. The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86135
--- Comment #4 from Sabetay Toros ---
*" --- Comment #2 from Jonathan Wakely http://gnu.org/>> ---This is not a bug, GCC is correct. With
list-initialization the compiler doesnot always select a copy/move
constructor even when the argument is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86108
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86109
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |8.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86104
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-*, i?86-*-*
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86097
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86089
Martin Sebor changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86128
Martin Sebor changed:
What|Removed |Added
Keywords||ice-on-valid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86094
--- Comment #8 from Richard Biener ---
Note if there's any ABI change between 8.1 and 8.2 please adjust changes.html
to note this as a caveat (even if the 7.3 -> 8.1 change was unintended).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86094
--- Comment #7 from Richard Biener ---
Fixed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86093
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86092
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86091
--- Comment #1 from Richard Biener ---
I can't reproduce the slowness.
> /usr/bin/time g++-8 t.C -std=gnu++1z -Wall -Wextra
0.23user 0.04system 0:00.27elapsed 99%CPU (0avgtext+0avgdata 44028maxresident)k
0inputs+1568outputs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86127
--- Comment #5 from Jonathan Wakely ---
Author: redi
Date: Wed Jun 13 15:14:48 2018
New Revision: 261554
URL: https://gcc.gnu.org/viewcvs?rev=261554=gcc=rev
Log:
PR libstdc++/86127 avoid unnecessary allocator conversions
There is no need to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86090
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86085
Richard Biener changed:
What|Removed |Added
Keywords||alias, missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85703
cesar at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85702
cesar at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86136
--- Comment #1 from MCCCS ---
Note: It can notice (a * n) % k = 0 if n is a multiple of k. The bug happens
only if n % k != 0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86135
--- Comment #3 from Jonathan Wakely ---
Based on the names I'm assuming your code is the same as a case I analysed
recently, which reduces to:
#include
#include
struct object_t {
template
object_t(T object)
:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86136
Bug ID: 86136
Summary: Modular multiplication optimization
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85577
Jonathan Wakely changed:
What|Removed |Added
CC||sabetaytoros at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86135
Jonathan Wakely changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85703
--- Comment #4 from cesar at gcc dot gnu.org ---
Author: cesar
Date: Wed Jun 13 14:31:17 2018
New Revision: 261551
URL: https://gcc.gnu.org/viewcvs?rev=261551=gcc=rev
Log:
PR fortran/85703
gcc/fortran/
* parse.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85702
--- Comment #2 from cesar at gcc dot gnu.org ---
Author: cesar
Date: Wed Jun 13 14:29:04 2018
New Revision: 261550
URL: https://gcc.gnu.org/viewcvs?rev=261550=gcc=rev
Log:
PR fortran/85702
gcc/fortran/
* openmp.c
1 - 100 of 131 matches
Mail list logo
