https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85662
Bug ID: 85662
Summary: regression since 6: "error: non-constant condition for
static assertion" from __builtin_offsetof in C++
Product: gcc
Version: unknown
Status: UNCON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85661
Bug ID: 85661
Summary: double comparison illegally statically reduced
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85660
Bug ID: 85660
Summary: Signed Integer Overflow (79257474)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: demangler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85618
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85659
Bug ID: 85659
Summary: ICE with inline assembly inside virtual function
Product: gcc
Version: 6.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85658
--- Comment #2 from Sergei Trofimovich ---
Created attachment 44074
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44074&action=edit
93_all_arm-arch.patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85658
--- Comment #1 from Sergei Trofimovich ---
Looks like the bug is in operator precedence in awk between '!' and 'in'.
This makes above tests to recover:
diff --git a/gcc/config/arm/parsecpu.awk b/gcc/config/arm/parsecpu.awk
index 56c762b3b..1135
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85658
Bug ID: 85658
Summary: gcc-8.0.1 stopped validating --with-arch= flag
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: dr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85657
Michael Meissner changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85657
Bug ID: 85657
Summary: Make __ibm128 a separate type, even if long double
uses the IBM double-double format
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85407
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85587
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85305
--- Comment #3 from Jason Merrill ---
Author: jason
Date: Fri May 4 20:20:16 2018
New Revision: 259959
URL: https://gcc.gnu.org/viewcvs?rev=259959&root=gcc&view=rev
Log:
PR c++/85305 - pack in lambda init-capture.
* parser.c (c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85305
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85629
--- Comment #5 from Stefan ---
(In reply to Ian Lance Taylor from comment #4)
> Which version of which linker are you running?
# ld -v
GNU ld version 2.20.51.0.2-5.47.el6_9.1 20100205
> For that matter, which version of which assembler?
# as -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85638
--- Comment #12 from Eric Botcazou ---
> I wonder why this doesn't seem to happen with DWARF-2 exception handling.
OK, the difference is that dw2_build_landing_pads does:
lp->landing_pad = gen_label_rtx ();
emit_label (lp->landing_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85629
--- Comment #4 from Ian Lance Taylor ---
Thanks. Which version of which linker are you running? For that matter, which
version of which assembler? I don't see the warnings and errors that you are
seeing, with GNU as 2.30 and GNU gold 2.30.51.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85629
--- Comment #3 from Stefan ---
Created attachment 44073
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44073&action=edit
gotools/cmd_vet-testlog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85407
--- Comment #2 from Harald Anlauf ---
(In reply to Dominique d'Humieres from comment #1)
> The trunk is now at 9.0. The patch can be committed if accepted.
It was my understanding that Steve OK'd it and said that he'd commit,
but then did not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85638
--- Comment #11 from xantares09 at hotmail dot com ---
Oh, ok
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85638
--- Comment #10 from Eric Botcazou ---
> Yes, I applied your patch, now the build fails with another error:
This one is yours, you need to compile the 8.1 cross with the 8.1 native.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85638
--- Comment #9 from xantares09 at hotmail dot com ---
Yes, I applied your patch, now the build fails with another error:
gcc -c -I./ -I/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/adalib/../adainclude
-I/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/adalib -I.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85630
Ian Lance Taylor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85630
--- Comment #3 from ian at gcc dot gnu.org ---
Author: ian
Date: Fri May 4 17:07:20 2018
New Revision: 259945
URL: https://gcc.gnu.org/viewcvs?rev=259945&root=gcc&view=rev
Log:
PR go/85630
* Makefile.am (CHECK_ENV): Set GOCACHE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85512
--- Comment #13 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Fri May 4 16:37:30 2018
New Revision: 259941
URL: https://gcc.gnu.org/viewcvs?rev=259941&root=gcc&view=rev
Log:
[AArch64] PR target/85512: Tighten SIMD right shift immed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82518
--- Comment #60 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Fri May 4 16:35:32 2018
New Revision: 259940
URL: https://gcc.gnu.org/viewcvs?rev=259940&root=gcc&view=rev
Log:
[arm] PR target/82518: Return false in ARRAY_MODE_SUPPORT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85575
--- Comment #10 from Jürgen Reuter ---
(In reply to Dominique d'Humieres from comment #9)
> AFAICT
>
> (1) The behavior is present even without module: add
>
> implicit none
> integer :: cl
>
> to the test in comment 4 and it compiles if -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85638
--- Comment #8 from Eric Botcazou ---
Another (checking) assertion triggers in fix_up_crossing_landing_pad:
rtx_insn *insn = BB_END (e->src);
rtx note = find_reg_note (insn, REG_EH_REGION, NULL_RTX);
gcc_assert (note !=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85630
--- Comment #2 from ian at gcc dot gnu.org ---
Author: ian
Date: Fri May 4 16:23:51 2018
New Revision: 259937
URL: https://gcc.gnu.org/viewcvs?rev=259937&root=gcc&view=rev
Log:
PR go/85630
* Makefile.am (CHECK_ENV): Set GOCACHE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85575
Dominique d'Humieres changed:
What|Removed |Added
Priority|P3 |P4
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85629
--- Comment #2 from Ian Lance Taylor ---
What are the contents of gotools/cmd_vet-testlog?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38960
--- Comment #5 from joseph at codesourcery dot com ---
Since any non-const function can examine floating-point state, I'd expect
significant effects on code generation. (Whether this also applies to
asms depends on the architecture; some archi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85635
--- Comment #13 from Eric Botcazou ---
> Those "many" people don't build gnat. Very few people do according to the
> testsuite results page.
That's a clear misconception. The Ada compiler is regularly built and tested
on Linux, Darwin, Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85616
--- Comment #3 from ktkachov at gcc dot gnu.org ---
Though the example code given breaks C's strict aliasing rules, doesn't it?
bug_start is an array of chars (byte-aligned) but the stores to it are done as
ints, which expect word alignment, so th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85656
Bug ID: 85656
Summary: gcc.dg/ipa/ipa-icf-38.c FAILs
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85655
Bug ID: 85655
Summary: ICE with -flto and -O2 during IPA pass: cp lto1:
internal compiler error: Segmentation fault
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85593
Ramana Radhakrishnan changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85654
Rainer Orth changed:
What|Removed |Added
Version|8.0 |9.0
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85654
Bug ID: 85654
Summary: gcc.dg/vect/pr85586.c FAILs
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85649
Tom de Vries changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85575
--- Comment #8 from Jürgen Reuter ---
module foo
implicit none
contains
function constr_quark_loopline(ho,sho) result(cl)
integer, dimension(sho), intent(in) :: ho
integer, dimension(sho) :: hor
integer, intent(in)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85575
--- Comment #7 from Dominique d'Humieres ---
Please provide code showing the problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85653
Bug ID: 85653
Summary: [nvptx] Work around subsequent bar.sync JIT/ptxas bug
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85575
--- Comment #6 from Jürgen Reuter ---
In addition, it also throws the error
Error: GNU Extension: Symbol ‘sho’ is used before it is typed at (1)
for the case of a contained module procedure with implicit none as in comment
#5.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85575
--- Comment #5 from Jürgen Reuter ---
Yes, as external function the error is thrown, but not as module procedure.
So do
module foo
implicit none
contains
function quark ...
end function ...
end module ...
This will compile.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85651
--- Comment #1 from Gabriel Burca ---
I suspect the "for" loop in appendAux() is being optimized and replaced with a
memcpy(), which then leads to the warning.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85652
--- Comment #1 from Andrew Pinski ---
I suspect this is due to inlining decision of b::h into f. In PIC mode, b::h
is consider overwritable so it is not inclined while in non pic mode it is
inlined.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85652
Bug ID: 85652
Summary: -Wformat-overflow warning silenced by -fpic/-fPIC
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85651
Bug ID: 85651
Summary: Invalid -Warray-bounds warning with -O3
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85635
--- Comment #12 from John Marino ---
yeah, my problem is that I was thinking cpp was complaining this whole time,
but it was actually the c compiler. Once I realized that, the misconception
cleared up. My fault, should've known better.
And I s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85650
--- Comment #1 from Franz Sirl ---
Created attachment 44068
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44068&action=edit
testcase 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85650
Bug ID: 85650
Summary: Additional warnings when -fsanitize=undefined is used
with -Wstringop-truncation
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Keywords
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85635
--- Comment #11 from Jakub Jelinek ---
Those many people do build gnat. I do it in all my bootstraps, many other
people working on gcc do.
And if you don't know how the C preprocessor works in this case, why don't you
just try that out?
#if defi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85635
--- Comment #10 from John Marino ---
ah, i see you explained what technically happened in the comment above. I
missed that at first.
That's how the QNX line was visibly limited to the BSD platforms then. cpp
didn't consider it a macro. got it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85635
--- Comment #9 from John Marino ---
Those "many" people don't build gnat. Very few people do according to the
testsuite results page.
link.c code was:
#if defined (__WIN32)
(block 1)
#elif defined (__hpux__)
(block 2)
#elif defined (__FreeBSD_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85635
--- Comment #8 from Jakub Jelinek ---
No, for non-BSD the preprocessor sees:
#elif defined (__FreeBSD__) || defined (__DragonFly__) \
|| defined (__NetBSD__) || defined (__OpenBSD__)
and if not one of these 4, it skips all the tokens until the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85635
--- Comment #7 from John Marino ---
It's a condition ladder.
The windows and hpux conditions are first on the ladder. The cpp bug would
have been short-circuited on those platforms. For any platform that has the
condition test fall to BSD first
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85649
Bug ID: 85649
Summary: [og7, nvptx, openacc] Too much workers chosen for
launch
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85407
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85648
Bug ID: 85648
Summary: Name mangling using decltype omits namespace
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85575
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84362
Matthias Noack changed:
What|Removed |Added
CC||ma.noack.pr at gmail dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85645
--- Comment #7 from Segher Boessenkool ---
Or actually, rnreg is the culprit (it was reg 0, rnreg moved this to reg 25)?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85645
--- Comment #6 from Segher Boessenkool ---
It goes wrong in cprop_hardreg, which replaces
insn/f 482 43 483 5 (set (reg:SI 25 25)
(reg:SI 65 lr)) 502 {*movsi_internal1}
(expr_list:REG_DEAD (reg:SI 65 lr)
(expr_list:REG_CFA_R
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85637
--- Comment #5 from petschy at gmail dot com ---
Thanks, in this specific case __restrict works indeed.
On a side note, is it possible to achieve the same when a char is stored
through a char* member, and also incremented? eg:
if (m_cur < m_end)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85645
--- Comment #5 from Segher Boessenkool ---
saw edge from trace 1 to 4 (via jump_insn 42)
...
Processing trace 3 : start at code_label 507
saw edge from trace 3 to 4 (via fallthru 0)
Inconsistent CFI state!
SHOULD have:
.cfi_def_cf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71484
James Legg changed:
What|Removed |Added
CC||jlegg at feralinteractive dot
com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85645
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85645
Jakub Jelinek changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85645
--- Comment #2 from Arseny Solokha ---
One remarkable thing about this testcase is that in my setup it makes gcc ICE
w/ almost any valid argument to -mcpu. gcc successfully compiles it only w/
-mcpu={power6,power6x,power7,power8,power9,powerpc64l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85638
Eric Botcazou changed:
What|Removed |Added
Attachment #44060|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85638
--- Comment #6 from Eric Botcazou ---
The key point is that several elements of cfun->eh->lp_array can share the same
landing pad:
(gdb) p *cfun->eh->lp_array->m_vecdata[1]
$11 = {next_lp = 0x0, region = 0x7695c898,
post_landing_pad = 0x7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85645
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85642
Jonathan Wakely changed:
What|Removed |Added
Keywords||rejects-valid
Status|ASSIG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85638
--- Comment #5 from Eric Botcazou ---
It's a direct fallout of the fix for PR rtl-optimization/85393:
FOR_EACH_EDGE (e, ei, bb->preds)
{
gcc_assert (e->flags & EDGE_EH);
if (BB_PARTITION (bb) ==
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85647
--- Comment #2 from Sagar Shah ---
thanks for your prompt response.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85642
--- Comment #3 from Jonathan Wakely ---
Author: redi
Date: Fri May 4 09:57:42 2018
New Revision: 259930
URL: https://gcc.gnu.org/viewcvs?rev=259930&root=gcc&view=rev
Log:
PR libstdc++/85642 fix is_nothrow_default_constructible>
Add missing noe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85647
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81091
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85647
Bug ID: 85647
Summary: gcc 5.4.0 always takes c++11 string
Product: gcc
Version: 5.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85646
--- Comment #2 from Duarte ---
I forgot to add that it compiles successfully without -fvisibility=hidden, and
without the template.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85646
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85642
--- Comment #2 from Jonathan Wakely ---
Author: redi
Date: Fri May 4 08:57:23 2018
New Revision: 259928
URL: https://gcc.gnu.org/viewcvs?rev=259928&root=gcc&view=rev
Log:
PR libstdc++/85642 fix is_nothrow_default_constructible>
Add missing noe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15210
Dennis Clarke changed:
What|Removed |Added
CC||dclarke at blastwave dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85639
Tom de Vries changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85638
Eric Botcazou changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85639
--- Comment #3 from Tom de Vries ---
Author: vries
Date: Fri May 4 08:29:08 2018
New Revision: 259927
URL: https://gcc.gnu.org/viewcvs?rev=259927&root=gcc&view=rev
Log:
[expand] Handle null target in expand_builtin_goacc_parlevel_id_size
2018-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85646
Richard Biener changed:
What|Removed |Added
Keywords||rejects-valid
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85646
Bug ID: 85646
Summary: Incorrect lambda visibility with -fvisibility=hidden
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85640
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Target Milestone|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85637
--- Comment #4 from Richard Biener ---
Err, wrong function assembly pasted. Note you also can make this * restrict
via
__attribute__((noinline))
void Update(const void* b, unsigned int len) __restrict
{
i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85641
Dominique d'Humieres changed:
What|Removed |Added
Keywords||ice-on-valid-code
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85637
--- Comment #3 from Richard Biener ---
__restrict should work fine for char pointers. With
__attribute__((noinline))
void Update(const void* __restrict b, unsigned int len)
{
if (len) {
...
I get with -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85636
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Status|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85638
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85634
Richard Biener changed:
What|Removed |Added
Keywords||ice-on-valid-code
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85639
Tom de Vries changed:
What|Removed |Added
Keywords||ice-on-valid-code, openacc,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38960
--- Comment #4 from Richard Biener ---
Note that a not too disruptive "implementation" of the dependences would be
to add outgoing abnormal edges to the fenv* calls. Not too
disruptive in terms of implementation - the effect on code generation m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85633
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-*, i?86-*-*
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38960
Richard Biener changed:
What|Removed |Added
CC||jtaylor.debian at googlemail
dot c
1 - 100 of 115 matches
Mail list logo
